Photo by Travelling Runes

Photo by Travelling Runes

If you have not grabbed your copy yet (or had one emailed to you, as it were), go here to get your very own. As we expected, there are a number of important changes that companies will be dealing with over the next several months as they begin to prepare for PCI DSS 3.0. In this post, I wanted to do a quick highlight of some of the more critical changes now that they are public. If you want to read some of my earlier reservations, they all stand with the final version. Let’s dive in.

  • Periodics and shoulds: Yes, these are now a massive shift in the Council’s position toward ambiguity in the standard. Periodic now appears 20 times (up from 8, or just over 2 times more) and should now appears 103 times (up from 27, or just under 5 times more). In this article from Digital Transactions magazine, Troy counters that the standard is trying to be more flexible. Of course, you have two camps: one that wants more specificity and one that wants more flexibility. You won’t resolve that, so this is perhaps a more middle ground approach. That said, I don’t agree that this version represents the removal of ambiguity for this very reason. One balancing act that companies will deal with is more flexibility could make parts of complying easier, but they will run into interpretation problems with their QSAs. The continuum is real.
  • BAU Practices: I still don’t understand why the Council bothered to put this in the standard when every other guideline document is kept separate. Frankly, I think this section is a waste of space and discussion. There are no requirements around it (see the note at the end of that section), it oversteps the bounds of PCI DSS inside the company, and it reads like the Council is saying PCI DSS first, security second. If they wanted to really do this right, they would make a sub-requirement under 12.1 or 12.4 to state that the security policies and procedures should, at a minimum, incorporate the baseline requirements in PCI DSS. That way the intent of making PCI DSS a function of a larger program (the Council is very prominently on record stating that PCI DSS Compliance ≠ Security) is met instead of adding guidance information into the formal standard.
  • Combined Documents: One really nice thing about the new version is there is now standard reporting for QSAs as well as the added interpretation guidance into the standard documents. Companies and QSAs need to be careful to focus on the requirement first, gathering information to meet the testing procedures, and then finally leveraging guidance to help them with a judgement call. The guidance column is just that… guidance. It’s not a requirement. Just be sure we are all reading from right to left.
  • Documentation of Policy: The Council took the easy way out here by adding a requirement to the bottom of every major requirement that essentially states (it is verbatim across all for the most part) the QSA/ISA must ensure that all the documents are in place and known to all parties. No other alignment than that.
  • Requirement 1.4: Here’s the first instance of where we have gotten a bit sideways. According to the wording of the requirement, you will probably see QSA’s requiring firewall software on iPhones, iPads, and Android devices. A quick search of the Apple App Store turns up lots of VPN options as well as games. I am sure Google Play will be similar. This is going to be a cluster. The guidance column explains more of what the intent is, and I believe that a device managed with a security policy via a MDM should comply with this requirement. But expect that you will find QSAs asking you to put firewalls on your mobile devices and please do not punch them in the face. Let’s keep it civil, people.
  • Requirement 2.2.2: More ambiguity is now present here whereby the term “necessary” is included in the services, protocols, dæmons as required for the function of the system. When I was a QSA, I remember getting into arguments on what is necessary for the system to function because I spent time to learn the underlying function of said system. For example, if someone said that their linux system required portmap to be running yet they didn’t use any of the services associated with it (such as NFS), I would tell them to turn it off. Some operating systems make that very difficult to do, and some used to break if you were not careful. So is it necessary? QSAs, don’t let admins bully you into saying yes because they don’t want to change the system. And admins, be sure you are educating your QSA appropriately to get a good ruling on that one.
  • Requirement 3.2: I love the word usage here (not sarcasm). The word choice used is “unrecoverable” when discussing Secondary Auth Data post-authorization. This is the exact intent and I think this clarification is great.
  • Requirement 3.4.1: To read between the lines, don’t use disk-level encryption and don’t let cardholder data seep on to laptops. ‘Nuff said.
  • Requirement 5.1.2: I think this one is somewhat comical. It seems to me that this could have been wrapped into 6.1.b such that it doesn’t sound so ridiculous when read out loud. But good luck developing procedures to start looking for malware on your z/OS installation. And for those of you with Macs, just go install Sophos and be done with it.
  • Requirement 5.3: I feel like this one is needed, but will be abused. For example, A/V crashing Oracle is something that is terrifying. Not only that the A/V software could impact the business like that but also that the organization would allow something like this to even happen in the first place.
  • Requirement 6.2: I like where this is going from a business management perspective, but I believe its going to give companies fits when they deal with their QSAs. For example, some recent research suggests that vulnerabilities with exploits in Metasploit are much more likely to be the cause of a breach versus ones that are not. Therefore, the prioritization of patches should follow those that would fix bugs available for exploit inside of Metasploit.
  • Requirement 8: Tons of stuff fixed/changed here. Overall, I think this provides much of the needed flexibility in authentication and aligns issues between requirement and testing procedure.
  • Requirement 9.9: Here’s one that is a best practice until 30 June 2015, but even in spite of Troy’s comments in the above article it’s clear that this is one of those requirements that will be very difficult to implement. Let’s take, as an example, your standard level 1 retailer with the following assumptions: 400 stores with 10 cash lanes per store plus 2 additional terminals behind customer service. This requirement has a ton of “periodically” words in there, so let’s just say someone who is trying to be diligent selects quarterly. With scale here, we are discussing managing the audit logs and inspecting nearly 5,000 devices every single quarter. To be clear, I do like the requirement. It closes a serious loophole in the standard with respect to skimming and extends the requirements farther than the P2PE or PTS standards currently do. That said, implementing this on a large scale is going to be a pain. Through my company, I have a product I can offer you to solve this when you are ready. Just contact me and I can get you the details.
  • Requirement 10.6: I will defer to Dr. Chuvakin on this one, but I think the changes here are fantastic. Again, understanding the role of compliance vs. security, the Council is trying to delineate exactly what you need to review for PCI compliance. This should be a minor but useful change in your procedures.
  • Requirement 11.1.1: Keep in mind, this particular requirement can be pretty easy to meet as long as you don’t have any wireless in your CDE. If you do, good luck folks… you’re going to need it.
  • Requirement 11.3: I’m really mixed on this one. On one hand, this is so long overdue that it’s not remotely funny. On the other, getting this thing actually evaluated is going to be a challenge. I expect companies being assessed to take the absolute bare minimum approach (because this is a direct driver to a security cost) and I expect security-savvy QSAs to want to require much more.
  • Requirements 12.8.5 and 12.9: This is another one that is long overdue but will be a very helpful input to general risk management functions inside companies.

Ultimately, you should be grabbing your own copy and reviewing things specific to your organization (or hiring your friendly QSA to do this for you…) so you have a go-forward plan for implementation in 2014, and assessment in 2015. Comments are open below! I’d love to hear your thoughts!

This post originally appeared on BrandenWilliams.com.