I attended my recertification training this past week in Chicago. Kudos to Jeff Foresman, the PCI SSC’s new internal trainer. Jeff is a great person with a great background as a former QSA and network security person. I could not think of anyone better to conduct the QSA training.
One of the implicit goals of QSA recertification training is to ensure that all QSAs are consistent in their interpretation of the PCI DSS. However, there are still a number of areas within the PCI DSS that are left up to the QSA for interpretation and their acceptance of risk. It is these areas where QSAs are going to vary on whether or not a given situation is compliant with the PCI DSS. It is with these areas that merchants and service providers ‘shop’ for a QSA that will interpret the PCI DSS the way the merchant of service provider wants them interpreted. Which is a problem the PCI SSC recognizes, but can only address through continued QSA training.
One such area is anti-virus. Requirement 5.1 states, “Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).” The QSA is left to interpret what is meant by “all systems commonly affected.” Almost all QSAs agree that all Windows systems require some sort of anti-virus (apparently there are still some ‘Windows-bigots’ out there that think Windows, properly hardened, is just fine). However, not all QSAs are in agreement with other operating systems. For example, using a QSA that is a ‘Linux-bigot’ could result in an organization being judged PCI compliant without having anti-virus on their Linux systems. Even though in our recertification training we were explicitly told that Linux systems must have an anti-virus solution, which put some QSAs in the room in a tizzy. The instructor’s response was that it was the QSA’s reputation that was on the line if they signed off on compliance and did not require Linux anti-virus.
Network segmentation is another area that is up for interpretation. I have stated in my Network Segmentation post that, “I know good network segmentation when I see it.” However, from class this week, it is apparent that not everyone agrees on what constitutes ‘good’ network segmentation. Therefore, this will continue to be an area that will constantly have consistency issues from one QSA to another.
Finally, we had a discussion in class regarding compensating controls. This is always a big area of discussion with clients and also a big area of inconsistency for QSAs. Since I work for an organization that does a lot of internal audit and Sarbanes Oxley work, our definition of compensating controls is a bit more structured and risk adverse than the PCI SSC’s view. We are able to work with clients to come up with acceptable, in our view, compensating controls. However, some of the examples provided in class this past week indicated that not everyone has the same view of compensating controls as we do. This will also be an area where there will be significant variance from one QSA to another.
The bottom line is that, unfortunately, merchants and service providers understand these inconsistencies and use them to get around PCI compliance issues by hiring QSAs that are like-minded and are willing to bend the rules. Therefore, until QSAs become consistent, breaches will likely occur because one QSA was willing to take on the risk of judging something compliant when it should not have been judged that way.
PCI Guru 
QSAs should not have to interpret any of the rules. They should have to interpret the client’s organisation and then apply the unambiguous rules of the standard to that.
If the PCI SSC can specify in their QSA training that Linux systems should have anti-virus installed, they should either include it in the standard specifically, or they should publish this kind of ‘auditing guidance’ or ‘technical addenda’ to the website, for everyone to see.
Look at it cynically: each of these requirements that need interpretation by a QSA, are sales opportunities for them, since there is no assessor independence.