The long awaited revision to the credit card industry’s security standards was published last month. As expected, the latest version of Data Security Standard (or DSS) has clarified and strengthened existing requirements and has added a major new section forpenetration testing. Among the improvements are stronger rules for passwords, authentication, and audit trails.
If there’s an overall theme to PCI 3.0, it’s ‘back to basics’—i.e., straightforward block and tackle strategies—but this time with a renewed focus. There are, for example, several instances where the PCI standards committee got very specific in their language for changing default settings and passwords, and they were equally granular about who and what is covered by the auditing rules.
The default password rules have been in the older standard, but in 3.0, the PCI folks emphasize that this applies to everything: not just the usual suspects (apps and operating system), but point-of-sale (POS) terminals and wireless devices as well.
The new standard is much more explicit about what companies have to do to verify that the defaults were changed. New testing procedures (section 2.2) require organizations to not only interview IT personnel but also to examine the configurations, and review logs or other documents to confirm that the defaults were indeed swapped out.
A small checklist step for IT, a large step for data security.
One reason behind this focus on defaults has been the spate of major attacks in recent years that exploited vendors’ original settings on devices and software. As we now know, hackers can have very deep knowledge of the various backdoors and other standard configurations in retail POS devices, which they stand ready to exploit.
Authentication and Audit Trails
Two-factor authentication is something that we’ve been shouting about at the Metadata Era for some time. The DSS compliance group also feels strongly about it—it’s been in the requirements since at least version 2.0.
But in this latest incarnation of DSS, they have clarified who it applies to—“all remote personnel” and “all third parties and vendors” (section 8.3). This really closes any possible loopholes in the past rules that may have allowed companies, in good faith, to not apply this stronger form of authentication.
Just to be totally clear, the DSS committee means that not only will remote users be expected to provide a password, but also either something they have (smart card, token), or something they are (biometric).
Overall, the PCI standards group has (sensibly, IMO) tightened the requirement (section 10.1, 10.2) that all individual user access —not just customer access– to card holder data is logged. It’s a significant tweak of the existing language. They are also very explicit that companies have to do more than just “establish a process” to link access of any resource to specific users. Now, IT departments are expected to have this process implemented—important difference.
The Proof is in the Penetration Testing
Arguably, the most significant change in DSS 3.0, is the addition of an entire new section on penetration testing methodology (11.3). As with these other improvements, the core ideas have been in the standards, it’s mostly a matter of degree and detail.
In addition to long standing vulnerability scans and basic pen testing drills, PCI DSS 3.0 nudges the bar up a bit by asking companies to “implement a methodology for penetration testing”.
Translation: figure out real-word attack scenarios that exploit vulnerabilities, such as weak passwords, SQL injection attacks, etc., and then run the tests.
Previously, companies could meet DSS’s older pen-testing requirement without paying too much attention to what they were looking for. Now, the standard says that the testing drill has to conform to industry-standards—NIST SP800-115 is mentioned—as well as taking into account any actual threats and vulnerabilities that the company has experienced in the previous 12 months. Currently, developing a pen-testing methodology is a best practice, but starting in June 2015 it becomes a full-fledged requirement.
Some security pros, no doubt, will have their quibbles. But overall, it’s a solid step forward, and addresses less sexy, but still important low-hanging-fruit issues. In the arms race between hacker and company, the new rules will make the attacker’s job harder.