Last week the Payment Card Industry Security Standards Council (PCI SSC) released the first update to the Data Security Standard (DSS) in more than two years. Version 1.2 of the DSS provides some much needed updates and clarifications to the 1.1 version of the document and is the official document as of October 1, 2008. While the standards council claims not to have introduced any new requirements in this version of the document, some of the changes are significant and represent more than just clarification. During a recent PCI DSS security assessment, I found the following changes to be most noteworthy:
The PCI DSS version 1.2 has much stricter language with regards to compensating controls. Every compensating control must be reviewed, documented and validated by an assessor annually. Furthermore, for each compensating control the Compensating Control Worksheet must be completed. These changes clearly signal the security council’s intent to make it more difficult for merchants to use compensating controls rather than meeting the requirements of the DSS.
WEP encryption for wireless networks may no longer be implemented for new networks after March 31, 2009. And wireless networks currently using WEP encryption must migrate to industry best practices (e.g. 802.1x) by June 2010. While these requirements are not terribly difficult to meet, merchants need to be aware of this as they roll out new wireless networks or plan to upgrade current WEP enabled WiFi networks.
Both versions 1.1 and 1.2 of the PCI DSS state that anti-virus software must be deployed on “all
systems commonly affected by malicious software (particularly personal computers and servers).” However, in version 1.2 the security council removed a note stating that viruses typically do not affect Unix-based systems and mainframes. This has led some to interpret the requirement to mean that ALL systems must run anti-virus software. However, I would argue this is not the case. The requirement does state “systems commonly affected my malicious software.” To me this would not include mainframes or i-series systems from IBM for example. One could even argue that Solaris, Apple, and Linux systems are not commonly affected by malicious software. My advice would be to run it wherever possible and practical.
The new version of the standard provides more leeway in the patch installation process. Version 1.1 specifically required that security patches be applied within 1 month of release. The new version allows companies to apply a risk based approach which fits better into most enterprises’ vulnerability management programs and will ultimately lead better overall security. Patches can be applied to more critical systems first and less critical ones can be updated later.
Version 1.1 of the DSS required the use of video cameras to monitor sensitive areas. The new version provides the possibility of using other access control mechanisms to monitor access to sensitive areas. Potentially this could include card keys that would provide a date and time stamp each time someone entered a data center for example. Biometric access control mechanisms could also be employed. Standard keys and keypads would NOT meet this requirement as they do not provide the ability to monitor access to sensitive areas.
Version 1.2 of the DSS provides more detailed requirements when dealing with service providers that have access to cardholder data. The merchant must maintain a list of all such service providers, ensure that the service providers are PCI DSS compliant and monitor their compliance, maintain a written contract with the service provider stating that they are responsible for the cardholder data, and establish a process when selecting service providers to perform due diligence. These requirements force merchants to work much more closely with their service providers and be aware of their service providers’ PCI DSS compliance status.
To view the new version of the PCI DSS as well as other related documents, go the official PCI SSC web site at .