“Use of a PA-DSS compliant application by itself does not make an entity PCI DSS compliant, since that application must be implemented into a PCI DSS compliant environment and according to the PA-DSS Implementation Guide” – this is useful for ..ahem… reminding merchants about it.
“verify that no cardholder data exists outside of the currently defined cardholder data environment” – scoping stuff became much better and this also smells like DLP to me. In any case, I head DLP vendors are partying over this already
“Where virtualization technologies are in use, implement only one primary function per virtual system component” – this is what got added to 2.2.1 and it is great! Virtualization now officially in.
“Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities” – my guess is a lot of people read too much into this change of 6.2. It pretty much means the same: “bad vuln? fix it!” I don’t believe it will lead to reduced patching and increased risk acceptance. But I am sure some vendors that mix up firewall rules with vulnerability data will be ecstatic over this one…
“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes” – lack of change here in 6.6 which lead a lot of merchants to think that web app scanners needs to be run ANNUALLY is sad. My guess is that ‘after ANY change’ will be conveniently missed…
“Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time” – updates to 10.4 are interesting; there are no new requirements (you still need to sync time), but there are more details here now. There is definitely more importance placed on this one in PCI 2.0!
“Methods that may be used in the process [or wireless ‘scanning’] include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.” – this sure kicked some wireless IDS/IPS vendors in the balls (or so I’ve heard
) as this can be interpreted as ‘wireline AP detection is just fine’“Perform quarterly internal vulnerability scans” - a new 11.2.1 which used to be rolled into 11.2 is a good idea: internal scanning was completely ignored by many merchants, sadly. And now this req got its own number. Same happened to scanning after changes (a new 11.2.3) which is good too. Finally, ‘rescan internal until fixed’ is a useful reminder for merchants who sometimes just scan for scanning’s sake.
“Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. (Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.)” – adding example to 12.1.2 as well as a testing procedure are handy. We don’t need people creating their own idiotic “risk” “assessment” methods…
“Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises.” – this made 11.4 more palatable to merchant, I am sure; adding ‘at critical points in CDE’ is useful.
So, is it perfect now? Come on… But there are many small but useful changes that will help merchants protect the cardholder data. I can see how this version can survive for 3 years just fine.
Enjoy!
