PCI Compliance – Issues and Solutions

While the first run results are usually unsatisfactory, the remedies are not difficult to implement at all. For the few customers that we have worked with, the problem can be categorized into three areas,

As indicated in the part 2, most merchants belong to level  2, 3 or 4. At these levels, especially level 4, the requirements are not nearly as demanding as level 1 merchants. For example, there is no Report on Compliance (ROC) needed. As anyone ever worked on this report can tell you, this report is painful to the IT.  In many cases, it requires completely re-architecturing of the Commerce infrastructure.

For level 4 merchants, not only the requirement of ROC is waived, but SAQ (Self-Assessment Questionnaire) is also optional. In fact, most merchants would only need to perform network scans on the Commerce server. From a security perspective,  This should be done regardless of the existence of the PCI requirements.  If your server cannot even pass some automated simple minded network scanners, it certainly will fall under the attackes of hackers. While the first run results from the network scanners are usually unsatisfactory for web sites that were architectured with security as one of the top requirements, the remedies are not difficult to implement at all. For the few customers that we have worked with, the problem can be categorized in three areas:

1.    Outdated HTTP servers. For WebSphere Commerce, it uses IBM HTTP server by default, which is a derivative work of Apache.  Some network scanner actually treat IBM HTTP server as Apache. This, however, will generate many false alerts. As any software, Apache does contain bugs. Apache also release patches to fix these issues. The same is also true for IBM HTTP server. There is one issue – When Apache servers get patched, the version number also changed. When IBM HTTP server is patched, the version number also gets updated – except the update happens to the IBM HTTP server version, not Apache. Many network scanners will just look for the Apache version number and then report issues. Dumb? Yes. But this is how many network scanners work, so we have to mark these issues false positive in the scanners.

2.    SSL v2. SSL v2 has been proven to be venerable to attacks for many years. However, it is still being enabled in the IBM HTTP servers by default. We need to disable it and uses SSLv3/TLS exclusively.  A similar issue also applies to weak crypto algorithms. In general, we should only use strong algorithms such as 3-DES.

3.    Trace. IBM HTTP server also enables TRACE function by default. This allows programmer to perform debugging works, but clearly it is a threat as it allows hackers to probe around. We should disable this function on production servers.