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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.