Blog post

Briefly On PCI DSS 3.0

By Anton Chuvakin | November 08, 2013 | 0 Comments

standardssecurityPCI DSScompliance

So I’ve been sleeping on my copy of PCI DSS 3.0 for a few weeks already and now that it is finally public, I am ready to comment on it here.

As you can guess, I start my assessment from the position of being supportive of PCI DSS. Yes, there are things to be skeptical about, but overall I like both the direction as well as its current state. Also, one more high-level point to make is: this is a major numbered update (2.0-> 3.0), but it is not earth-shaking, “everything is different” kind of an update. With that said, there are some exciting changes, in both content and format.

Here are some of my faves, in no particular order:

  • “PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy” – so, I really like the BAU theme, but clearly it will take more the merchants to change how they think about PCI DSS (1/year –> daily and ongoing)
  • “11.3 Implement a methodology for penetration testing that includes the following […]” – I really hope the changed 11.3 will kill most shoddy pentests conducted in the name of PCI DSS (aka “monkey with a scanner” tests)
  • Another PT gem is this one: “11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective
  • “10.6.1 Review the following at least daily […]” – this made the log review requirement much cleaner and explains that one does not need to look at all logs daily, but instead (also see this for details)
  • Fortunately, the application security (Requirement 6, and, particularly 6.4 and 6.5) is expanded. But there is one FREAKY change: for Req 6.6 compliance, it is OK to have your WAF in monitoring mode. Specifically, they say: “Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows […] Is configured to either block web-based attacks, or generate an alert.” BTW, seeing this bit made me explode at the Council meeting …
  • Also, I love how the phase “operational procedures” snuck up in a lot of requirements (good thinking here!), for example: “5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties” or “1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties” and “10.8 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.”

Finally, the proverbial “Requirement 0” (=automated card data discovery) is still not in. Neither DLP nor other automated data discovery means are mentioned. Requirement 6.2 still contains this abomination: “Install critical security patches within one month of release” (see this for some useful discussion).

There you have it!

Related blog posts:

Comments are closed