New PCI DSS (Credit Card Security) Standard
I’ve been asked by a couple of people to put forth my views on the latest PCI DSS (Payment Card Industry Data Security Standard) version, released last week. Several of the changes have hit topics close to my heart, so I’m overall happier with PCI DSS 1.2 than I was with PCI DSS 1.1.
You can read the whole of the new PCI DSS 1.2 document at https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html
The change document is interesting (https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf) – here are some changes I noted :
1.1.6 – Firewall rule reviews every six months instead of quarterly. In theory, firewall rules should be maintained adequately by good use of change management and configuration management processes and tools, in that new firewall rules are reviewed before going into place, old firewall rules are removed as applications are ‘sunset’, and temporary firewall rules are marked as such, and reviewed / removed as they expire. In reality, of course, unanticipated firewall rule changes get made, either through accident or as a deliberate undocumented change (not necessarily malicious, just “hey, that change didn’t work, we need another port open”), and applications drop into disuse without anyone reviewing the network changes that are made to accommodate them. As such, firewall reviews are well worthwhile, even if they are rather monotonous and difficult to interpret. Lesson learned: document your firewall rules well, so that reviews can be made quickly; confirm that your documentation matches your firewall, and remember to engage a project to ‘true-up’ the firewall rules when discrepancies are found.
1.3.8 – Requiring a NAT (Network Address Translation) device on internal-external network transitions, and RFC 1918 ‘non-routable’ addresses on internal networks. Still doesn’t apply to IPv6. [IP6 has _no_ NAT or equivalent, RFC 1918 doesn’t apply, but there are “link-local” and “site-local” address ranges that can be used] My opinion? A NAT offers no security advantages over a firewall whose default rule is to deny traffic. If you are supporting IPv6, don’t go looking for a NAT or PAT (Port / Address Translator) or NAPT (Network Address and Port Translator). The use of NAT has broken so many protocols, and required so many workarounds (each of which void any hiding of network address that you might have mistakenly thought was a security feature) that it’s more of a hardship than a feature. Remember that NATs (and RFC 1918 private addresses) were only intended as a short-term workaround for the inability of IPv4 address allocation to satisfy growing demand for IP addresses. It was never designed as a security feature.
2.1.1 – References to WEP have been removed – WPA or WPA2 appears to be the stuff, now. That’s as it should be – WEP can be easily and quickly broken with off-the-shelf hardware and freely-downloadable software. WPA and WPA2 are widely available, and kit that doesn’t support anything more than WEP should be considered ‘too old to be of use’ – particularly in an environment that handles credit card information.
2.1.1 – Disable SSID broadcasting is no longer seen as a security measure. Again, as it should be; the check mark for “disable SSID broadcasts” should really have been labeled “disable one quarter of the ways in which SSIDs are broadcast”. Clearly, you can still pick up SSIDs even with SSID broadcasts “disabled”. Hiding a network that runs across the public airwaves does nothing to secure it.
3.4.1 – Despite clarifications, the standard is still kind of flakey as to what it means by “encryption key tied to user accounts” – does it mean a PEM file with NTFS ACls on it, or a Certificate Store encrypted with a key derived from the password? [The former will give up its secrets to anyone that can has a token, the latter requires that you have the key, which requires that you had the password – somewhat stronger than ‘just’ having the user token.]
4.1a – The list of SSL tests doesn’t ask to test that where SSL certificates are accepted, they must be in their valid time range, and not revoked. Those two checks should be a part of all SSL transactions. Without those checks, some of SSL’s security is removed.
4.1.1 – WEP can’t be implemented in new wireless implementations after March 31, 2009, and must be removed from use in all PCI-related wireless implementations after June 30, 2010. Do yourselves a favour and remove it now.
5.1 – Removed the statement that “Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes”. Apparently UNIX doesn’t have anything technical, other than a lack of market penetration and a slightly better-educated user base (because you have to be), that prevents viruses.
5.1.1 – Antivirus measures should detect and address “all known types of malicious software”, not merely “other malicious software”. Presumably that means something – but the goal here, of course, is to remind you that there are many kinds of malicious software that you should prevent from infecting your systems, and particularly those systems involved in the processing of credit card data.
6.1 – Security patches no longer have to be installed in 30 days, you now have one month. What you gain in January, March, May, July, Octember and Decober, apparently you lose in February.
6.5b – A sampling of developers must be interviewed at testing time, to ensure that they are “knowledgeable in secure coding techniques”. This could be interesting – first you have to enumerate your developers, then you have to find them, then you have to randomly select some of them, then you have to hope that they can communicate.
6.5.1-10 – The OWASP top-ten are included specifically in the PCI DSS document, with a note that if the top-ten change, the new top-ten must be used in preference the 6.5.1-10. Always go and get the fresh OWASP top ten, because they’ll be out of date practically as soon as the ink is dry on the PCI DSS standard.
8.2 – “password” becomes “password or passphrase”; “token devices” and “biometrics” now are lumped under “two-factor authentication”. You should really be using passphrases in any kind of secure environment, and 2FA is well worth implementing in environments where risk is high.
8.5.5 – Inactive user accounts do not have to be removed – they can be disabled instead (yay! – now we have the ability to audit them!) When you delete an account, you do not delete all the references to it, so you can have any number of ACL entries, etc that refer to this “unknown SID”.
8.5.13/14 – Account lockout for 30 minutes is still required (boo, hiss – if passwords are long and/or complex, account lockout is nothing more than a self-inflicted denial of service). Better is to log and trace attempts to brute-force password guessing, and to enforce strong passwords and/or 2FA on the high-value accounts.
8.5.16 – SQL apparently isn’t the only database that needs authentication, so this requirement has been changed to refer to all databases now needing authentication for access. About time this standard was made a little less Microsoft-centric. I don’t trust my credit card information to be safe just because it’s been put on a system whose name ends in ‘X’.
9.1 – Systems requiring physical access control are now all those “in the cardholder data environment”, not just those “that store, process, or transmit cardholder data”. That way, you have to protect machines that can communicate directly with those machines that have credit card information in play.
11 – “Hackers” replaced by “malicious individuals”. Ho hum, that old sausage.
11.3 – added that penetration tests must be performed by qualified personnel (internal or external), and that these do not have to be QSA or ASVs. This is just a clarification, but apparently some QSAs had been looking to drum up more business by saying that pen testing had to be done by other QSAs.
12.3.8,9,10 – Acknowledging that very few of us use modems any more, they are now “remote access technologies”, covering more than just old fashioned POTS dial-up.
12.8 – Instead of contracts with third parties, “policies and procedures” are required – contracts being only one way in which those can be enshrined.
As ever with PCI DSS, you have to remember that it’s not a specification for perfect security – in some ways, it’s not even a gold standard, it’s just the level that the credit card companies think they can reasonably expect almost all credit card processors to attain in the course of the next couple of years. As such, it’s like the qualifying heats at a track meet – you haven’t won anything or competed in the final race, you’ve merely demonstrated that you’re worthy enough to keep going.
Build your systems and networks securely, and you’ll naturally exceed compliance. Aim just to reach compliance, and you’ll likely fail to be secure.