Yep, it’s out. Well, at the time I am writing this it is not out, but by the time you read this it will be! You can go download the standard and the summary of changes at the Council’s new site. I’m not going to go over EVERY change, but will highlight some of the more significant ones that will impact how companies approach PCI DSS. Here are some highlights that I think are interesting.
- Explanation of how and where PA-DSS applies is a key clarification that was well known in the industry but was not documented in the standard like this. Very helpful.
- VIRTUALIZATION is FINALLY included throughout the standard. From page 10 in the scoping guidance through to that pesky requirement 2.2.1 (now broken into sub-requirements where 2.2.1.b has the relevant clarification).
- Sampling is not allowed for third parties anymore? I don’t think that’s the intent, but the way it is worded, I can see QSAs interpreting this to mean that a service provider with 200 servers would need to have every single server reviewed for compliance.
- Sampling continues to be an issue in PCI DSS 2.0. Representative sampling is required, but not statistically valid sampling, and no real consistent and repeatable instructions have been included here. Assessors must determine on their own (as they have had to do for nearly a decade now going back to CISP) if the systems sampled give them enough feel-goodery to call it representative, and then somehow explain how you came up with that sample. My personal opinion is that this leaves too much room for error and variance among QSAs, and the Council should pick a sampling formula and go with it.
- Requirement 1.3.3 includes limits on outbound direct connections where in the past this used to be limited to just inbound direct connections. This may cause problems for smaller shops with less sophisticated infrastructure. (Disregard, this is an error! See comments below.)
- 1.3.8 now FINALLY addresses something most QSAs have long interpreted which is that shiny new third bullet under the requirement. You can use public IP space as long as it is not advertised.
- 3.1.1.e is designed to enforce the checking of the rest of 3.1 by QSAs.
- 3.2.1 added the verbiage “including but not limited to the following” to the list of things to inspect for track data, but most QSAs will never deviate from that list.
- 3.4 added a note which talks about the risk of rainbow tables.
- 3.6.4 removed the annual key change requirement, and most entities will drag this out as long as they can.
- 4.1.b now requires trusted keys and/or certs for everything, not just SSL/TLS. QSAs may over interpret this to mean that third party certs must be everywhere.
- The change in 5.2 made me giggle.
- Not a fan of requirement 6.4.3, though I understand its intent. Companies should be allowed to do this in special cases if they act responsibly.
- 8.5.9-13 finally have made the distinction for service providers around “non-consumer users.”
- 9.1.1 changes will probably have mixed reception. Merchants will love it, but security pros may not like it as much. I see lots of video cameras being ripped out of stores very soon.
- 9.1.3 has an interesting interpretation issue that may cause some heartburn. Again, understand the intent, but the interpretation of “appropriately restricted” is going to be interesting.
- 10.4.1.a, not sure why UTC is specifically called out. Most software is smart enough to either respond in UTC or understand what a time zone is.
What new things will you love to hate about PCI DSS 2.0? Drop them in the comments below.
Possibly Related Posts:
- PCI DSS 4.0 Released plus BOOK DETAILS!
- PCI Council Loses $600K in Revenue, PO Population on the Decline
- Why PCI DSS 4.0 Needs to be a Complete Rewrite
- Orfei Steps Down
- Should you be a PCI Participating Organization?