Back
What’s New in PCI DSS 2.0 – No Surprise That There Are No Surprises
Some of the team from NetSPI spent the week in sunny Orlando at the 2010 PCI North American Community Meeting. As most are aware, this year’s meeting was particularly significant as a new version of the Data Security Standard, 2.0, which has now been released and effective as of 1/2011. The new standard is so advanced that it went from 1.2.1 to 2.0, incorporating a 0.7.9’s worth of changes in a single revision(!). The last few days’ sessions were a great opportunity to review the changes with the SSC and card brand representatives, catch up with others in the industry, and dispel rumors about the new DSS version (there will be no Requirement 13 mandating the use of ninjas to protect cardholder data, and Ouija boards cannot be used for wireless access point discovery). It should also be noted (if my wife is reading this), there was absolutely no beer consumed at Kook’s Sports Bar and all discussions were reasoned, civil discourses that ended promptly at 9:00 PM to allow for a full night’s sleep. As far as the changes to the DSS, it should come as no surprise that there were not many surprises to be found. As was pointed out several times throughout the course of our sessions, the DSS is a mature framework with a rising adoption rate throughout the world; major changes could have serious financial and operational repercussions on merchants and service providers who have already incorporated the DSS into their environments. Keeping that in mind, the intent of v2.0 is to provide additional guidance and clarification based on the (apparently) thousands of communications that the SSC received in response to their request for feedback, and my first impression is that it succeeds in that respect. Below are some of the highlights I picked up on from the meeting and SSC-supplied docs, in no particular order:
- Clarification that PAN is the primary element for applicability of the DSS to a merchant/service provider environment and is the definition of ‘cardholder data’
- Sampling requirements will be more detailed, and will require more justification as to why the sampling methodology used for an assessment is considered sufficient
- There are clarifications for issuers that have a business need to store sensitive authentication data (SAD), which should provide more specific guidelines for retention and protection of SAD
- Additional requirements to secure PAN if hashing and truncation are used in the same environment, to reduce the possibility of malicious users reconstructing full account numbers
- At this point, an automated or DLP-type solution is NOT required for data discovery and scoping of the cardholder data environment, though tools of this nature can/should be used where appropriate
- “System components” now includes virtual systems in the definition
- Requirement 6 has been overhauled to merge internal and web applications, and “industry best practices” no longer means just “OWASP”, and includes SANS, CIRT, CWE, etc.
- News flash- two passwords are not considered “2-factor”. Glad we got that one clarified.
- Requirement 11 allows for physical site inspection for rogue AP discovery if appropriate. I can’t see this working well in a large physical environment, but may work for mom-and-pop retailers who can see every wire on their router. I can’t wait for my first opportunity to write a comment for 11.1 that includes “Bob, the IT guy, climbs through air ducts and drop ceilings on a quarterly basis to identify potential rogue APs”
- IDS/IPS must be included at the perimeter of the cardholder data environment and ‘key points’, as opposed to monitoring all traffic in an environment
- There was some discussion around a new SAQ C that would be applicable to ‘virtual terminal’ environments. This is a work in progress, and I didn’t hear an official release date
There are many other tweaks not included above, but no real game-changers in my opinion. I know not everyone will be happy with all of the revisions, but the DSS is by its nature a compromise between global applicability for all types of environments and nuts-and-bolts implementation. There will still be requirements that have QSAs and clients scratching their heads, but my impressions are that many of the clarifications are long overdue and should make many of the requirements easier to interpret, test, and enforce. Ninjas will just have to wait for version 3; be sure to get your feedback in early.
