http://www.easycash.de/de/unternehmen/pressecenter/pressemitteilungen/pm-15-sepa-round-table.html

Based on PCI DSS customer discussions, I think, a lot of confusion exists about the value of a PCI PA-DSS validated payment application during a PCI DSS audit. Nearly all customers think, a PA-DSS validated software is completely out of scope in their PCI DSS audit. They think, their payment application has already been officially validated and does not need to be assessed again. Unfortunately that’s not correct. Every application that is storing, transmitting or processing cardholder data is always in scope of the PCI DSS assessment. At minimum, a PCI DSS auditor has to validate the correct implementation of the PA-DSS compliant software according to the Implementation Guide. Quite often, there is a PA-DSS validated software in place but the software was not implemented in a compliant way. In addition, the PCI DSS assessor must clearly identify which components were included in the PA-DSS assessment and which were out of scope. The PCI assessor has to ensure that all other components that support the application but were not in scope of the PA-DSS validation are assessed during the PCI DSS audit. E.g. a dedicated Hardware Security Module, which is used by a payment application may be deemed to be out of scope for the PA-DSS validation but is certainly in scope of the PCI DSS assessment (see PCI DSS Req. 3, Key Management).

A special situations exists, if the PA-DSS validated application is developed (and also sold to customers) by the same company, which is assessed during the PCI DSS audit. This means, a company is sometimes a software vendor according to PA-DSS and also a PCI DSS Service Provider. If the PA-DSS validated software is also used internally, I feel that it would be even necessary to audit the software development requirements (Req. 6) during the PCI DSS assessment, even if these processes had already been validated during their last PA-DSS assessment of the payment application.

Since years, the PCI Council has never finally clarified this topic. During PCI Re-Audits I am seeing companies that have implemented an Antivirus solution for their Linux/Unix systems because the PCI auditor told them they must have it. And other organisation did not have anything in place here and had been PCI DSS assessed by a QSA.

As long as there is no written statement from the Council about this topic, I am rating this situation as follows: there might be Linux/Unix systems where the installation of an Antivirus solution definitely makes sense, e.g. for SAMBA file servers.  But for these systems, the antivirus solution must be in place because it is scanning for Windows malware. I would say that for this kind of systems, antivirus is mandatory. For all other Linux/Unix systems I still feel that these systems are normally not “commonly affected” for malicious software. But I think it makes sense to operate an anti-rootkit software on these systems and that is the reason why I strongly recommend using a tool like chkrootkit or rkhunter on all Linux / Unix systems.

Another question that I was asked: Can mod_security be used to fulfil PCI DSS Requirement 6.6, if the WAF part was chosen to be implemented? After reading again the PCI DSS Supplement document on this requirement, I would say, in general mod_security may be acceptable for a PCI DSS auditor. But, besides the simple activation of the mod_security module within the Apache Web server, there are certainly a lot more requirements around the pure technical configuration of a WAF. There would definitely be a need to define and document Procedures and Processes. The PCI SSC supplement “Application Reviews and Web Application Firewalls Clarified” at least gives some more guidance, which additional requirements must be met e.g.:

• how mod_security is configured (documented configuration)
• who is responsible for maintenance of the configuration
• who defines procedures to ensure frequent update of  the WAF signatures or other configuration settings
• who will receive alerts and how will this person react
• is there a need for documenting a maintenance window process
• …

In addition, it is important to know that the WAF has to prevent Web Attacks, which means the monitoring mode of a WAF is generally not acceptable.

In summary, one can therefore say that mod_security to fulfil PCI DSS Req 6.6 may be accepted by your PCI Auditor. But if you just activate the module but cannot demonstrate the requirements around, you definitely would have an issue during your PCI DSS audit.

I was recently asked if WFP/WRP can be used to fulfil PCI DSS requirement 11.5 (File Integrity Monitoring). I would say, basically it is possible to answer this question yourself by reading the details defined in 11.5.a. Although WFP and especially WRP are able to monitor Windows system, they only monitor files that are installed by the Windows operating system (http://goo.gl/h8jnA). But PCI DSS defines the following files that should be monitored:

• System executables
• Application executables
• Configuration and parameter files
• Centrally stored, historical or archived, log and audit file

I think it is clear that a tool like WFP or WRP which was designed to monitor the integrity of operating system related files does not fully cover all of these items. Therefore WFP/WRP may be used to partly fulfil PCI 11.5 but an additional FIM solution is still required to fully address all of the items mentioned by the PCI DSS.

I like it: https://flavors.me/___chris___