PCI Requirement 6.6 – Confusing the confused
Thursday May 1, 2008 at 10:56 am CST
Posted by Vivek Chudgar
PCI Requirement #6.6 has been in the news for quite some time, primarily because complying with it is not trivial. PCI Security Council published a press release on April 22, 2008, hoping to clarify some of the requirements and help merchants comply before the upcoming deadline of June 30, 2008. Some of the clarifications are confusing, since they seem to go against basic application security concepts, as well as the principle of compensating controls already laid out by the PCI standard.
Requirement #6.6 aims to secure web sites against attacks, by requiring either of the following for all web-facing applications:
- Manual code review by experts
- Application Layer Firewall
Now this press release effectively says that the intent of code review requirement is met by:
- Manual web application security vulnerability assessments
- Proper use of automated web application security vulnerability assessment (scanning) tools
The million dollar question is: Can a vulnerability assessment or penetration test really deliver the same findings that a code review does? Is it OK to think that a code review can be replaced by a vulnerability assessment or a penetration test?
I don’t think so. Code review is a white box exercise, where as vulnerability assessment is a black box exercise. Code review allows a security expert to look under the hood and see the guts of the application, where as a vulnerability assessment looks at the application from outside and can only see the few security flaws that have actually manifested themselves into full blown exploitable vulnerabilities. Therefore a vulnerability assessment will leave out many other complex, subtle, yet serious flaws that only a code review could have discovered.
So I wonder why the council thinks that it meets the intent of the code review requirement.
Now here’s some background before you read about the next confusion.
The PCI standard clearly states that a compensating control must be in addition to controls required in the PCI DSS. Sounds complicated but it’s really simple. Let me explain with an example: Let’s take Requirement #3.3 which requires the PAN to be masked when displayed. If this requirement cannot be met then the merchant will have to propose a compensating control. However a compensating control which says that “this data is only accessible to a limited set of employees who need to work with this data” will not be acceptable, because this control is already covered under PCI Requirement #7 which says that data should be accessible only to those employees which have a business need.
Going by this logic, Requirement #11.2 and 11.3 already cover manual web application security vulnerability assessment as well as automated web application security vulnerability assessment (scanning) tools. So how can these be considered acceptable as a compensating control for Requirement #6.6?
I am surprised that such a proposal is made by none other than the Council, which is the champion of the PCI standard. I really hope the Council corrects this mistake.
- Vivek
Note: Vulnerability assessments and penetration tests can be interpreted differently by different audiences. So I should clarify that I am interpreting them as per PCI guidelines, which closely match how Foundstone interprets these services too.
May 1st, 2008 at 12:27
Slight clarification:
Now this press release effectively says that the intent of code review requirement is met by:
* Manual web application security vulnerability assessments
* Proper use of automated web application security vulnerability assessment (scanning) tools
The press release indicates that section 6.6 is satisfied by either black or white box techniques:
The first option for application code review for meeting Requirement 6.6 is now subdivided
into four alternatives designed to meet the intent of the requirement. They include:
* Manual review of application source code
* Proper use of automated source code analyzer (scanning) tools
* Manual web application security vulnerability assessments
* Proper use of automated web application security vulnerability assessment (scanning)
tools.
You’re absolutely right though – there are tons of security weaknesses that can be identified through white box testing that are impossible to test through black box techniques. Lot’s of those weaknesses have a direct impact on cardholder data. For example:
- “Does the application always encrypt cardholder data before storing it or logging it?”
- “How are the encryption algorithms implemented?”
- “Are there other interfaces to the application besides the ‘front door’?”
- “Are there are Trojans or backdoors in the code?”
And of course the list could go on for a while…
/eh
(Full Disclosure: I used to work at Foundstone, I know Vivek personally, I currently work at Ounce Labs which makes a source code analyzer, I have performed PCI assessments in the past, I have worked with Visa and others on defining PCI requirements in prior versions, and probably other conflicts of interest).