PCI DSS

Comparison of PCI DSS 3.2.1 and 4.0 penetration testing requirements

Leave a Comment

The current version 3.2.1 and the newer version 4.0 of the security standard PCI DSS require penetration tests to be performed. The PCI standard establishes detailed requirements a penetration test needs to comply with. In PCI DSS 3.2.1, the requirement is regulated in Requirement 11.3 and in PCI DSS 4.0 in Requirement 11.4.

These requirements are basically identical in both versions 3.2.1 and 4.0:

  • based on industry-accepted penetration testing approaches
  • coverage of entire CDE perimeter and critical systems
  • testing from both inside and outside the network
  • validation of any segmentation and scope-reducting controls
  • testing network-layer and application-layer
  • including review and consideration of threats and vulnerabilities experienced last 12 month
  • perform external, internal and segmentation testing every 12 month and after any significant change
  • service provider only needs to perform segmenation testing every 6 month

There are two topics where both standards diverge, while PCI 4.0 has the more mature version. So PCI 4.0 has a slightly different approach for its requirements on the application layer penetration test:

  • PCI v3.2.1 includes requirement 6.5 for application layer testing to check for:
    • injection flaws (e.g. SQL, LDAP, OS Commant, XPath)
    • buffer overflows
    • insecure crypto storage, insecure communications
    • improper error handling
    • XSS
    • improper access controls
    • CSRF
    • broken authentication and session management
    • also include the current best practices (e.g. OWASP Top 10)
  • PCI v4.0: including requirement 6.2.4 for application layer testing to perform at least:
    • injection attacks (including SQL, LDAP, XPath, command parameters, object fault or injectiontype flaws)
    • attacks on data and data structures (for example manipulating buffers, input data)
    • attacks on cryptography usage
    • attacks on business logic including XSS and CSRF
    • attacks on access control mechanisms

In PCI 4.0 the segmentation test also needs to include confirming the effectiveness of any use of isolation techniques for different security levels (see requirement 2.2.3).

Of course, the applied penetration testing approach needs to include fixing and re-testing any relevant vulnerabilities previously identified independently of the PCI standard’s version.

The PCI Council’s response regarding a monitoring-only WAF (Req. 6.6, PCI DSS 3.0)

Leave a Comment

On July I wrote a blog post about the modified Requirement 6.6 in PCI DSS 3.0. I am not going into the details again, it’s sufficient to say that the new standard allows to operate a WAF in monitoring only mode without blocking requests:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
– Is configured to either block web-based attacks, or generate an alert.

That was a very strange change in PCI DSS 3.0 and I assumed it was some sort of typo error. I decided to send an E-Mail to the PCI Council to get some clarification about this change. It took some time, but I finally got a response. To sum up: It is no typo error.

The PCI Security Standards Council Response Team’s answer:

The intent of Requirement 6.6 is to ensure web-facing applications are protected from known attacks. One of the options defined by the requirement is to install an automated technical solution (such as WAF) that “detects and prevents” web-based attacks. The solution used can encompass a combination of technology and process. Where the solution includes a reliance on process, there must be mechanisms to ensure that processes are followed in order to prevent attacks and meet the intent of the requirement. For example, if a WAF is configured to “monitor only” rather than “block” attacks, there must also be real-time alerting and response procedures in place to react to, and thus prevent, incoming attacks in a timely manner.

The requirement wording is intended to allow organizations flexibility to choose protection methods that best meet their needs. Whichever mechanisms are employed, the required result is that attacks are prevented, not just identified.

I do understand the need of a company to not have an enforcing WAF. It’s about False Positive and how to handle this problem. Everyone who operates an Intrusion Detection System knows it: False Positives are a pain in the ass and it is really hard to get rid of them, but this problem will not disturb the business. When dealing with a WAF in enforcing mode this is different. A False Positive WAF block will indeed block legitimate traffic and can possibly disturb business processes. It’s quite hard to prevent this.

So now you can indeed operate a WAF in monitoring-only mode without violating PCI DSS, when having a 24/7 response team that is able to react on a WAF alert very quickly.

PCI DSS 3.0 – Requirement 6.6 (WAF): Monitoring Only – “Is configured to either block web-based attacks, or generate an alert.”

Leave a Comment

Today I was working on a presentation about PCI DSS 3.0. Since a major client of me is an international payment service provider doing credit card transaction, I am quite familiar with PCI DSS 2.0. I have already read the new Standard a few months ago, but today I stumbled about an interesting sentence in the Testing Procedure for PCI Requirement 6.6 (WAF) that makes me wonder about PCI DSS 3.0.

PCI DSS Requirement 6.6 forces companies to either use a Web Application Firewall (or some technical equivalent) or forces companies to perform manual or automated application vulnerability security assessments after every change:

6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
[..]
– Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Doing automated application vulnerability security assessment is a little bit tricky and needs a software development team and process on a high maturity level. I assume that most companies comply with Requirement 6.6 by using a Web Application Firewall (WAF). Companies can write their own rule sets for a WAF, use a rule set from the WAF’s vendor or use some rule set from OWASP (OWASP CRS Core Rule Set). Anyway it is useful to activate the blocking / enforcing mode of the WAF to actually prevent attacks. That is industry best practice and is or better maybe was required by PCI DSS when companies deployed a WAF to comply with Requirement 6.6

Despite a lot other changes there is a new sentence in the Testing Procedure of PCI Requirement 6.6, which seems a little awkward. Pay attention to the last sentence:

6.6 For public-facing web applications, ensure that either of the following methods is in place as follows:
[..]
Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
– Is situated in front of public-facing web applications to detect and prevent web-based attacks.
– Is actively running and up to date as applicable.
– Is generating audit logs.
– Is configured to either block web-based attacks, or generate an alert.

So, I want to repeat it: WAF “Is configured to either block web-based attacks, or generate an alert.” Sorry, but what the fuck? After years of PCI DSS now it is okay to deploy a WAF in monitoring mode. At least it needs to generate alerts…

If found two links on the web, which also states this as a problem. Someone in a high position at Gartner[1] and some slides about PCI 3.0[2]. I tried to clarify this with our QSA Company, but just did a short answer, that a WAF needs to block attacks and no comment to this last sentence in Testing Procedure of 6.6. I decided to write an E-Mail to the PCI DSS Council and hope to get an answer that explains it. I will post the answer, if and once I get one.

For the security of customers’ credit card information I really hope this is some sort of mistake or typing error. Anyway I assume there will be some QSAs out in the world, which will accept a WAF in monitoring mode – It doesn’t matter if it was an error, if PCI DSS is treated like a law text and not correctly interpreted. And if this is no error and done on purpose, I wouldn’t really understand that change of mind in the PCI Council.

[1] http://blogs.gartner.com/anton-chuvakin/2013/11/08/briefly-on-pci-dss-3-0/
[2] https://www.netspi.com/blog/entryid/207/things-not-to-overlook-in-the-new-pci-dss-3-0

10/30/2014: The Council’s response.