Here is a topic that gets very little discussion but is a big sticking point between a lot of organizations and their QSAs. I think there is an assumption that since there is a fairly detailed discussion regarding this topic in the PCI DSS that everyone understands the topic. However, for those of us out in the field, either people are not reading the dissertation in Appendix B of the PCI DSS or there is still confusion.
To review, a compensating control needs to:
- Meet the intent and rigor of the original PCI DSS requirement;
- Provide a similar level of defense as the original PCI DSS requirement;
- Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement; and
- Be “above and beyond” other PCI DSS requirements.
To be ‘above and beyond’ requires the following attributes.
- Existing PCI DSS requirements cannot be considered as compensating controls if they are already required for the item under review.
- Existing PCI DSS requirements may be considered as compensating controls if they are required for another area, but are not required for the item under review.
- Existing PCI DSS requirements may be combined with new controls to become a compensating control.
To explain these three principles, I think some real world examples are the best.
An organization has six character long passwords on one of their PCI in-scope systems. As a result, they needed a compensating control for PCI DSS requirement 8.5.10. One of their compensating controls was the fact that they required passwords to contain special characters. A lot of people would say that requirement 8.5.11 would rule out specifying special characters in passwords, however they would be wrong. Requirement 8.5.11 states, “Use passwords containing both numeric and alphabetic characters.” There is nothing in 8.5.11 requiring special characters, so therefore requiring special characters in a password is ‘above and beyond’. That said, this organization in their compensating control for 8.5.10 also stated that they required password changes every 90 days, which is already required by requirement 8.5.9. As a result, the organization either had to change their passwords more often than every 90 days or remove that from their compensating control document. They chose to remove the 90 day change requirement.
An organization does not have anti-virus on their Windows-based Web servers and therefore needed a compensating control for PCI DSS requirement 5.1. One of the areas where this organization was original was in their using their very strict monitoring of their network traffic, critical file monitoring console and their real-time event log analysis as ways they determine if malware is put on these systems. They also conduct daily vulnerability scans and monthly penetration testing. All of these go ‘above and beyond’ because while all of these items are required by the PCI DSS, the execution of these activities was at a greater frequency than required by the PCI DSS.
In an earlier post on wireless scanning compensating controls, I give a couple of examples of combining and using existing PCI DSS controls to provide ‘above and beyond’ compensating controls. One of the controls I mentioned was enabling MAC address filtering on the switch ports. Since MAC address filtering is not required by the PCI DSS, this control will go above and beyond. In addition, I suggested that there should be monitoring the network for any devices that do not respond to SNMP inquiries using your organization’s SNMP private community string. Monitoring of this sort is not even called out in requirement 10, so I would say that this sort of monitoring would go above and beyond.
These examples should give you some clarity on what is considered “above and beyond.”
PCI Guru 