If your business takes credit cards, the Payment Card Industry Data Security Standard (PCI DSS) applies to your business. You should also know that it has been changed and the changes are effective next year.
I’ll tell you a little about some of the changes and their impact on the overall standard.
If you are not familiar with this the PCI DSS, you read the entire document for yourself from the PCI Security Standards Council. 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:
|Type of Change||Definition of Change|
|Clarification||Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.|
|Additional guidance||Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.|
|Evolving Requirement||Changes to ensure that the standards are up to date with emerging threats and changes in the market.|
We’ll focus mainly on the evolving requirements (ER) section because most of them are additions to the standard. We’ll also touch on clarifications (C) and additional guidance (AG) some some important or interesting changes were made.
Here’s a reminder of the basic high-level PCI DSS requirements:
|Control Objectives||PCI DSS Requirements|
|Build and Maintain a Secure Network||1. Install and maintain a firewall configuration to protect cardholder data|
|2. Do not use vendor-supplied defaults for system passwords and other security parameters|
|Protect Cardholder Data||3. Protect stored cardholder data|
|4. Encrypt transmission of cardholder data across open, public networks|
|Maintain a Vulnerability Management Program||5. Use and regularly update anti-virus software on all systems commonly affected by malware|
|6. Develop and maintain secure systems and applications|
|Implement Strong Access Control Measures||7. Restrict access to cardholder data by business need-to-know|
|8. Assign a unique ID to each person with computer access|
|9. Restrict physical access to cardholder data|
|Regularly Monitor and Test Networks||10. Track and monitor all access to network resources and cardholder data|
|11. Regularly test security systems and processes|
|Maintain an Information Security Policy||12. Maintain a policy that addresses information security|
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. This overall change in the document layout was intended to make the document easier to read.
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, but you might also want to diagram the flow of data as the credit card is scanned and moves through the systems for authorization and settlement.
The addition of requirement 1.1.3 is important because it forces you to look at how the data moves around and through your systems. This is also intended to document all the locations credit card data is stored, which may not be obvious without thinking through the entire process.
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, but unfortunately too many companies still misconfigure systems to keep default accounts they don’t use or fail to change default passwords. With the system documentation for just about any system being available on the internet, if you don’t change the vendor default passwords, just about anyone could find and use those default passwords to access your systems.
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
By the way, it is good practice to use the strongest key storage method at your disposal whenever possible. What seems like overkill today may save your company from a system breach tomorrow.
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 a security risk is also a best practice. You may not even be aware of a security threat if you aren’t actively looking for them..
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 have to ask why this is important. If your system is compromised by a virus or malware, those credit are transactions processed on those systems won’t be safe from a potential compromise.
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 software developers are keeping their knowledge and coding techniques up-to-date and that they always use industry best practices hen developing any custom software. You’ll have to demonstrate that your developers are using modern coding standards by producing evidence of those standards during any audit.
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.
You will want to use strong, unique passwords and force two-factor authentication whenever possible. Make sure people are using strong passwords and they change them at least every 90 days. Terminated employees should have their access immediately removed. This also includes any vendors that have access to your systems.
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. Anyone with physical access to the systems that process credit card data can be tampered with and that is a potential security risk.
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.
If you have specific controls in place to isolate you cardholder environment from the rest of your network, you must provide documentation on the design and configuration. You must also provide evidence the system configuration has been verified and tested.
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)
Whether it’s your company or a service provider that is handling the sensitive data there will always be accountability.
This list was not intended as an exhaustive list of all changes. This list is just a representative sample of the changes to this important and evolving document. You should read the entire document and consult a security specialist to make sure you understand the entire standard and have effectively implemented all the requirements. You can also read this article by Anthony Freed at Tripwire.