v1.2: remediation requirements for application vulnerabilities?

[John A. Lee]

Hi,

I did an application penetration test for a customer - the application was developed in-house - to help them prepare for PCI compliance. I found the usual suspects: no input validation, no output sanitization, very poor password security (strength, max retry, etc).

But I scoured all of the PCI-DSS 1.2 docs, and I really don't see anything comparable to the PCI severity levels (1 thru 5) for scanning and that the high level vulnerabilities (level 3,4,5) have to be fixed.

I do see in Section 6.5 "6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. COVER PREVENTION of common coding vulnerabilities in software development processes, to include the following: [OWASP Top 10].", which applies to secure development.

And I have read "Requirement 11: Regularly test security systems and processes" in its entirety, which basically states that you need to run these scans and tests.

But, I don't see anywhere that it states that any serious vulnerabilities have to be fixed.

As an example, say that while pentesting I find a SQL injection vulnerability that when exploited dumps all customer cardholder data. Is there anywhere in PCI-DSS that says that it has to be fixed?

What am I missing? I am a newbie (if you haven't guessed :-)

Thanks in advance,
John A. Lee

[Eugene]

Hello,

How about 6.1-6.3 ?

Cheers

[jplee3]

Ditto on Eugene's comment. But in your specific scenario, I'd pay closest attention to req 6.3 and all it's sub-reqs.

6.3.1.1 explicitly states: "Validation of all input (to prevent XSS, injection flaws, malicious file execution, etc)."

Additionally, the main 6.3 req states: "Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle."

The key to understanding PCI isn't just reading off the checklist and checking off items, but to remember and practice the *intent* of the standard: to protect CHD.

EDIT: as far as how req 6.5 (for web apps) relates, if you are in fact specifically asking about "web apps," I'd say the same rules apply. If you read 6.5 carefully, you'll notice this: "Cover prevention of common coding vulnerabilities in software development processes..." and then all of 6.5's sub requirements are pretty explicit about what vulns you should look for to fix

[John A. Lee]

Ditto on Eugene's comment. But in your specific scenario, I'd pay closest attention to req 6.3 and all it's sub-reqs.

6.3.1.1 explicitly states: "Validation of all input (to prevent XSS, injection flaws, malicious file execution, etc)."

Additionally, the main 6.3 req states: "Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle."

The key to understanding PCI isn't just reading off the checklist and checking off items, but to remember and practice the *intent* of the standard: to protect CHD.

EDIT: as far as how req 6.5 (for web apps) relates, if you are in fact specifically asking about "web apps," I'd say the same rules apply. If you read 6.5 carefully, you'll notice this: "Cover prevention of common coding vulnerabilities in software development processes..." and then all of 6.5's sub requirements are pretty explicit about what vulns you should look for to fix

Thanks, guys, for the prompt response.

I guess the takeaway for me is *intent*.

But,
6.1 is about software patches
6.2, 6.3, and 6.5 are about processes and what to "cover".

The company I work with has developed their penetration testing framework for over 8 years, and there is a clear rating system of Low, Medium, and High vulnerabilities based on business impact. Almost always, Highs have to be fixed, Lows are fixed at the customer's discretion, and fixing Mediums are based on our recommendation with the consideration of compensating controls.

I don't see anything like this for in-house developed applications (which are outside of the scope of PA-DSS). The PCI Severity levels for vulnerability scanning are at least 5 years out of date and totally not applicable for applications; they focus on the old school, network/system-centric notion that the hacker wants to take over a system, while statistics show that more than 50% of reported attacks are at the application layer.

So, I guess that the conclusion that I should come to is that whether an application vulnerability is fixed or not is completely at the discretion of the auditor/reviewer.

Out of all of the PCI documentation that I've recently been absorbing, I just wanted to know whether I was missing something glaringly obvious.

Thanks again,
John

[alphonze]

John,

Something I would add is that the PCI severity levels for vulnerability scanning are deprecated and have been for some time. CVSS v.2 base scores are now used instead, and these provide a slightly better interpretation of risk in general, although they are still overly focused on impact in my opinion, and not enough on likelihood.

ASVs still need to map CVSS scores to a qualitative severity level (such as "high" or "low"). This is the PCI's way of acknowledging that not every finding is suitable for labelling with a CVSS score, and allowing vendors to use their own scoring system instead. Since the recipient of the report would not benefit from two incompatible scoring systems, the mapping between the two must be provided.

Web application vulnerabilities may or may not be suitable for tagging with a CVSS v.2 base score. Play with the CVSS calculator at http://nvd.nist.gov/cvss.cfm?calculator&version=2 and decide for yourself.

So here's an approach that works for scoring these kinds of vulnerabilities:

1) If there's a pre-calculated CVSS v.2 base score on nist.gov, use that
2) If there isn't, try to create one with the calculator
3) If that's not possible because of the nature of the problem, use your own system for generating a severity, and ensure that its clear how it maps to CVSS scores, and where the cut-off for compliant/non-compliant is.

If you do that, you'll find that you can identify, without guesswork, which application flaws need to be fixed *now*, which can be fixed later, and which can be accepted or mitigated elsewhere - and provide justification for those decisions.

HTH,
Al.

[John A. Lee]

Wow, I'm glad I asked because that PCI severity level chart was a real head-scratcher; it made my travel back in time to when I was writing CERT alerts.

A wealth of information in your post that fully answers my questions.

Thanks a lot (and thanks to the others),
John