PCI versions 3.0, 3.1 and your SecureSphere deployment.
Payment Card Industry Data Security Standard (PCI DSS) version 3.0 was released in November 2013 and partially took effect Jan. 1st, 2015. Several sub-requirements were added, but the 12 primary requirements remained the same. Thanks to SSL attacks like POODLE, Shellshock, BEAST, and Heartbleed, PCI 3.1 was recently announced and is expected to be released in April 2015, taking effect immediately. The drivers behind this round of changes are to clarify the intent of the requirements and add flexibility, which makes it easier for organizations achieve compliance. At the same time, PCI 3.0 adds more stringent guidelines for validating the implementation of the controls that are used to achieve PCI compliance. These modifications were in reaction to the evolving threat landscape, as well as addressing the difficulty in detection of security events.
Some of the PCI 2.0 requirements were more difficult to accomplish than others. Fortunately, Imperva’s customers have used SecureSphere over the years to address several of these, which include:
- 6.6 – Protect public-facing web applications
- 7 – Limit access to systems and data on a business need-to-know
- 8.5 (now 8.1.4)- Identify and disable dormant user accounts and access rights
- 10 – Track all access to cardholder data
- 11.5 – Alert personnel to unauthorized modification of files
Imperva’s customers can continue mitigating 8 of the 12 PCI 2.0 requirements, as well as several of the new 3.0 sub-requirements. Since PCI mitigation is a complex topic and should be conducted by PCI experts, such as our Professional Services Team, this blog entry will focus solely on new requirements that either affect SecureSphere, or requirements that Secure could affect. PCI 2.0 requirements that can be mitigated using SecureSphere are out of scope of this document.
PCI 3.0 has several new sub-requirements, mixed with a lot of clarifications. Some of these changes are relevant to our customer’s deployments. Not only can SecureSphere can be used to directly mitigate many of the new sub-requirements, it can also feed valuable information to other parts of the process – assisting other areas in achieving compliance. Let’s look at some key changes and how they affect SecureSphere deployments.
|New/ Updated PCI Requirement||Description of Change||Applicability to SecureSphere|
|1.1.3||Maintain a current diagram that shows cardholder data flows.||SecureSphere can discover the cardholder data on the servers to understand the root source of the regulated data and how the data is accessed. Additionally, SecureSphere can discover servers that weren’t documented, as well as validate the servers that are in existing diagrams.|
|2.4||Maintain an inventory of system components in scope for PCI DSS.||SecureSphere can discover servers that weren’t documented, as well as validate the servers that are in existing diagrams.|
|5.1.2||Evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software.
|The Profile in SecureSphere can assist in identifying systems infected with malware. Additionally, advanced Security Policies can be crafted that could prevent malware infected systems from accessing data. Finally, by leveraging Imperva’s malware detection partners, for example FireEye, proactive malware defenses can be implemented.|
|6.5.10||Secure the authentication and session management processes.||SecureSphere can be used to secure cookies and session tokens, encrypt session tokens, enforce time-outs, and prevent many types of attacks on the authentication mechanisms.|
|8.5.1||Service providers must use unique credentials to access each customer’s environment.||SecureSphere can be used to prevent the usage of shared accounts as well as detecting default passwords on user accounts.|
|8.6||Authentication mechanisms must be linked to an individual account and ensure only the intended user can gain access with that mechanism.
|SecureSphere can be used to prevent the usage of shared accounts.|
|9.9||Maintain list of devices that capture payment card data via direct physical interaction with the card, and protect those devices from tampering and substitution.||Devices using an Imperva protected payment application can be secured using a Profile combined with advanced Security Policies, which can assist in maintaining and validating the list of devices that were used, can detect some types of tampering of the devices, as well as lessen the damage of a device being compromised.|
|11.3||Implement a pen testing methodology.||SecureSphere integrates with 3rd party vulnerability scanning tools and can be used during the pen tests to mitigate any findings. Additionally, vulnerabilities from PCI Section 6.5 must be tested for, which SecureSphere can mitigate.|
|11.3.4||If segmentation is used to isolate the Card Data Environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective.||SecureSphere can be used to enforce and validate network segmentation using the Profile, Security policies, and Audit logs.|
|11.5.1||Implement a process to respond to Alerts generated by file integrity monitoring||SecureSphere’s Task Management feature provides SecureSphere administrators with the ability to track the response process, manage report reviews, and manage the review workflow for our SecureSphere FAM. Additionally, Security Alerts from FAM can be flagged.|
PCI 3.1 (to be released on April 15, 2015) is a lot smaller of an update, but with (potentially) a larger impact on the enterprise. This requirement stipulates that SSL is officially deprecated, as it does not meet the minimum requirements of what’s considered ‘secure’. Therefore, enterprises must move to more secure encryption, like TLS.
A SecureSphere WAF in proxy mode is able to directly mitigate PCI 3.1 by disabling SSL, as well as other weak ciphers like export ciphers or RC4.
Imperva PCI Portal: http://www.imperva.com/PCI/
Summary of proposed changes (not all changes made it into the final): https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_Summary_of_Changes.pdf