PCI DSS 2.0 is out!

The PCI SSC today released a new version (2.0) of the Data Security Standards. The previous version 1.2.1 was released July 2009. I attended the PCI council community meetings in September and October where the council went over the changes with the key stake holders in the process. While the change from 1.x to 2.0 might seem like a big change, in reality most of the changes are minor clarifications or some additional guidance. The council has settled on a 3 year update cycle to the DSS and seems like the major version of DSS with will revved up every three years so expect PCI DSS 3.0 in October 2013. This does show that the standards have matured enough now that major changes are not required regularly.
The council also talked about the work they are doing to look at emerging technologies like end-to-end encryption, tokenization and virtualization. You will see that some of the changes in this version already reflect recognition of the new technologies and I am sure more updates will be coming in these areas. The SSC now has a dedicated Chief Technology Officer who is actively working to make sure the DSS stays in step with rapid changes in technology.

The key dates associated with the new requirements are

October 28, 2010 – PCI DSS 2.0 published. Merchants get the opportunity to go through the new requirements. The council also updated the Navigating DSS guide and relevant changes to the Self Assessment Questionnaires (SAQ)
January 1, 2011 – PCI DSS 2.0 becomes effective. Merchants can chose to validate compliance against version 2.0 or 1.2.1 after this date. Remember that merchants can’t mix and match some requirements from 1.2.1 and some from 2.0
December 31, 2011 – PCI DSS 1.2.1 is retired and can no longer be used to validate compliance against.

Essentially for all of 2011 you can use either version as long as you are fully done with your assessment before end of 2011 if you decide to use 1.2.1

Of the various changes in the DSS the following really peaked my interest …

Requirement 6.2 : Assign risk ranking to vulnerabilities (Internal scanning)

DSS requires merchants to have a vulnerability management program in place to identify and fix vulnerabilities discovered in the cardholder data environment (CDE). With 1.2.1 the merchants were required to patch and rescan internal networks until ‘passing results are obtained’. This was a bit unclear as to what exactly a ‘passing result’ is and did not account for the criticality of the systems within the CDE. Now the SSC is going to require that merchants come up with a risk ranking for these vulnerabilities based on industry best practices like CVSS. At minimum there should be process in place to make critical high risk vulnerabilities as “HIGH”. In simple terms you should look at how critical is the impact of the vulnerability itself and does it appear on a critical component in your CDE. A low severity vulnerability on your database storing cards might be HIGH and a high severity vulnerability on a backend router might be a LOW.

While the council has left it open for merchants and assessors to agree upon which scoring methodology to use, in reality I expect most merchants to use CVSS 2.0 scoring with its base, temporal and environmental components to decide what is HIGH. While this does put an extra burden on the merchant, the good news is that once you have the process in place you only need to fix the HIGH vulnerabilities to pass validation for 11.2 internal scanning requirement. While it is still recommended to fix all vulnerabilities this at least helps prioritize the work load.

Note that this is a requirement after June 30, 2012. Recognizing the extra work needed to put process in place the council has given this extra time. Till then this is a best practice and you can chose to follow what is currently in 1.2.1.

It’s important to remember is that this scoring and fixing requirement does not apply to 11.2 external scanning to be performed by ASV every quarter. All vulnerabilities identified by ASV as failing PCI must be remediated within that quarter and rescanned till ASV passes the merchant.

Requirement 2.2.1 Virtualization and one primary function per server

In DSS 1.2.1 the requirement was to implement only one primary function per server. e.g. Not implement web server function and database server function on same ‘server’. It was not clear in a virtualized environment if two virtual machines (VMs)

running on the same physical hardware box was considered as two primary functions per ‘server’. Now in 2.0 the council makes it easy by saying that in virtualized environments you can have multiple VMs on same physical box as long as each image implements one primary function. So you can have a VM for a webserver and a VM for a database server running side by side but you can’t have one VM with a webserver and database server on the same image. This should definitely accelerate the use of virtualization in PCI CDE since clarity for compliance was an issue that was holding back the adoption of virtualization.

Requirement 6.5 Secure application development best practices
DSS 2.0 is not tied to OWASP guidelines anymore. There is now room to use other industry best practices like OWASP, CWE Top 25, CERT Secure Coding, etc.

Requirement 1.3.5 Outbound traffic from CDE to IPs outside DMZ
Language in DSS 1.2.1 seemed to indicate that there was no room to have any outbound connection from CDE to ips outside DMZ even of legitimate reasons like transmitting encrypted information from one network to another over SSL port 443. DSS 2.0 says merchants can have outbound access open as long as there is legitimate reason and the access has been explicitly authorized by the merchant.

Requirement 4.1.1 WEP as security control

DSS 1.2.1 indicated there should be no WEP in the CDE at all after June 30, 2010. But DSS 2.0 has modified the language to say mere presence of WEP in CDE does not fail you as long as the WEP is not used as the security control. You can have WEP in the CDE as long as it is considered like an open wire. This means you need to have another level of encryption to protect data sent across a WEP connection, it can’t be plain text because you have WEP. e.g. sending data over SSL on a WEP wireless connection would seem to be ok.

Requirement 8.3 Use of two-factor authentication

You might find it funny but some merchants were using the same authentication method twice, and folks that is NOT two-factor authentication. Having two different passwords is NOT two-factor authentication. To illustrate that think of a stealth key logger installed on your computer that will be able to steal both your passwords to login and steal data. Because of this, the council makes it clear you need to have TWO different methods of the following implemented. 1) Something you know, like a password. 2) Something you have, like a token or smart card 3) Something you are like biometric data.

All in all we see the number of merchants adopting PCI increasing. The council has done a great job at being reactive and responsive, in an open community based effort, to get the standards to a mature state. Now they are attempting to stay ahead of the curve with new technologies in a dedicated effort working with industry leaders. Ultimately we expect DSS 2.0 to help merchants improve the security of their PCI networks while providing flexibility with their compliance efforts given the many different implementations that are out there.

Please post your thoughts on the new version … what do you think?

** The views expressed in this blog are a reflection of the author’s thoughts on this topic. They should not be considered an authoritative interpretation of the new or old DSS for purpose of compliance.

Related

Comments Cancel reply