PCI DSS – What’s new in v3.0?
If the Payment Card Industry Data Security Standard (PCI DSS) applies to your business you should also know that it has been updated [PDF].
This article will focus on some of the changes and their impact on the standard.
If you are not familiar with this document, you can read our primer or read the document for yourself from the PCI Security Standards Council – something I highly recommend should PCI DSS apply to your business.
Back in November, the folks behind the standard decided it was time for another update.
→ Based on feedback from the industry, the Council moved from a two-year to a three-year standards development lifecycle. This additional year provides a longer period to gather feedback and more time for organizations to implement the changes before a new version is released.
The previous version was the PCI DSS v2.0.
With nearly 100 changes, the current version has incremented one full revision and stands at v3.0.
When the council decides to make changes, it assigns each change to one of three main categories:
I will focus mainly on the evolving requirements (ER) because most of them are additions to the standard.
I will also touch on clarifications (C) and additional guidance (AG) where I feel some important or interesting changes were made.
Here’s a reminder of the high level requirements:
So, what’s new?
The first notable change was to remove the columns for “In Place”, “Not in Place” and “Target Date/Comments” in the requirements table.
This was replaced with a “Guidance” column which aims to assist the reader in better understanding the requirement.
I was pleased to see this change because it does add some needed clarification to many of the requirements.
Requirement 1
1.1.2/1.1.3 (C): Clarified what the network diagram must include and added new requirement at 1.1.3 for a current diagram that shows cardholder data flows.
When defining the cardholder data environment (CDE) it’s important to document which systems are in scope and how they interconnect.
A network diagram is a great way to do this.
When creating network diagrams for a previous employer, I would frequently walk the server room and physically trace network connections in addition to using software tools.
While this may not be feasible in all environments, I can tell you that this method did uncover some hidden surprises from time to time.
The addition of requirement 1.1.3 is important because it forces you to look at how the data moves around the CDE.
By going through this exercise, you may discover that some data is being copied to a system which, while you may be aware of its existence, you didn’t know contained cardholder data.
Requirement 2
2.1 (C): Clarified that the requirement for changing vendor default passwords applies to all default passwords, including systems, applications, security software, terminals, etc. and that unnecessary default accounts are removed or disabled.
This is just plain common sense – as much of the standard tends to be – but unfortunately too many companies still get this wrong.
Requirement 3
3.5.2/3.5.3 (C): Split requirement 3.5.2 into two requirements to focus separately on storing cryptographic keys in a secure form (3.5.2), and in the fewest possible locations (3.5.3). Requirement 3.5.2 also provides flexibility with more options for secure storage of cryptographic keys.
These two requirements have added some needed guidance on key handling.
Requirement 3.5.2 even provides some examples:
- Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
- Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)
- As at least two full-length key components or key shares, in accordance with an industry-accepted method
While the above are not required, it is good practice to use the strongest key storage method at your disposal whenever possible.
Requirement 5
5.1.2 (ER): New requirement to evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software.
5.3 (ER): New requirement to ensure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis.
Continuously evaluating systems for vulnerability and exploitability is good security practice.
Including systems that are not thought to be compromisable is even better.
I’m not suggesting that everyone become a vulnerability researcher but every security practitioner should be well educated in today’s threats.
There a plenty of resources that are on the leading edge of vulnerability discovery. Here are three:
As for requirement 5.3, we shouldn’t need to be told.
If properly implemented and managed, it might just save your assets.
Requirement 6
6.5x (ER): Address common coding vulnerabilities in software-development processes as follows:
- Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.
- Develop applications based on secure coding guidelines.
Make sure your coders are keeping their knowledge up-to-date and using industry best practices. There are some great resources available for them too.
Apparently Oracle has them as well. Who knew?
Requirement 8
8.2.3 (ER): Combined minimum password complexity and strength requirements into single requirement, and increased flexibility for alternatives that meet the equivalent complexity and strength.
8.3 (C): Clarified requirement for two-factor authentication applies to users, administrators, and all third parties, including vendor access for support or maintenance.
8.5.1 (ER): New requirement for service providers with remote access to customer premises, to use unique authentication credentials for each customer. Effective July 1, 2015*
8.6 (ER): New requirement where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) that the mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism.
We’ve said it before and I’ll say it again use strong, unique passwords and two-factor authentication whenever and wherever possible.
Requirement 9
9.3 (ER): New requirement to control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination.
9.9.x (ER): New requirements to protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. Effective July 1, 2015*
These are good requirements indeed and similar measures have reduced the amount of ATM fraud but there’s still the human element to account for.
We are only as secure as our weakest links and a disgruntled employee can be the weakest link of all.
Requirement 11
11.3.4 (ER): New requirement, if segmentation is used to isolate the CDE from other networks, to perform penetration tests to verify that the segmentation methods are operational and effective.
This is an important addition and one that I believe should underpin the entirety of the document.
Controls are put in place to ensure breaches don’t occur.
Only testing will validate whether those controls are implemented correctly and acting as intended.
It’s important to test for failures but also for unexpected results.
Just because a control is supposed to behave a certain way doesn’t mean always will when stressed.
Requirement 12
12.9 (ER): New requirement for service providers to provide the written agreement/acknowledgment to their customers as specified at requirement 12.8. Effective July 1, 2015*
This last point is reflective of the idea that there is no proverbial get out of jail free card.
Whether it’s your company or a service provider that is handling the sensitive data there will always be accountability.
What does this mean?
This was not intended as an exhaustive list of changes but rather a representative sample.
As we’ve just seen, the PCI DSS is evolving document.
As such, your involvement with the standard should evolve as well, if for no other reason than to keep pace with new technologies and a changing threat landscape.
Overall, I think the changes in this version have made the standard more robust and less arbitrary.
If you think the standard still doesn’t pass muster get involved!
*Just because the requirement doesn’t come into effect until July 1, 2015 doesn’t mean you shouldn’t implement the control now.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/7nb7ADCMPEQ/