PCI too prescriptive?
February 6th, 2007 by datasecurity Posted in Compliance, PCI DSS, QSA
I want to thank Ed at SecurityCurve for posting a clarification on his concerns about PCI. I think his statements are true and something to be discussed. The question is always posed, “Is PCI too detailed or not enough?“PCI is too detailed
Many people claim that PCI is too prescriptive in that it says specifically what actions must be done for security. Ed points out:
For example, PCI says that companies need to have a firewall. And they say that you have have to have anti-virus software, application-level firewall software (new version), etc. It’s up to the assessor to interpret if they have done it and if it is done appropriately.
This is true, and there is not much I can say to help ease the pain of prescription other than to say that, if it was vague people would almost always interpret it to mean the least amount of security. These requirements have the unfortunate role of applying to all companies across the board, large and medium sized.
I wonder if it is easier to pass an ISO 27001 audit or a PCI audit? I don’t know much about the ISO 27001 compliance audit but I’d imagine it would be tough. This is because it’s based on the ISO 17799 which is generally issued as a recommendation, due to the fact that it is not a certification.
From the card associations perspective, they want to: secure data, reduce compromises, increase consumer confidence, and prevent government intervention. How is this best accomplished? Are there changes to the PCI DSS requirements that would make things easier? Maybe a manual that was issued alongside the requirements? I think they need feedback on this issue, because they cannot secure the industry alone, so they look to the security assessors to use their judgement on many issues.
PCI is not detailed enough
People say the opposite is true as well, because of legal reasons rather than technical ones. One of the most common items people ask about is requirements 11.2 and 11.3. These two require (a) vulnerability scanning and (b) penetration testing respectively, but more people ask about them than any other. The question people ask, “How do you define a penetration test?”
Now everyone who asks this question knows what a penetration test is but they ask it because everyone has a slightly different perspective on what a penetration test includes. Does it include war-dialing, social engineering, or dumpster diving? Does it include physical or only electronic testing?
Instead of asking for more detail people should be focused on the intent of the requirements, “Secure Credit Card Data”. If the penetration test shows that credit card data is secured then you are meeting the requirements. If you want to know if a certain firewall configuration is acceptable, then ask yourself, “does it secure the credit card data?”
It is important to understand the goal of PCI and that compensating controls can be leveraged based on your expertise and understanding of the environment. Once people understand this they find the PCI requirements to be more flexible than ever before.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
3 Responses to “PCI too prescriptive?”
By Daniel on Feb 7, 2007
As with any security standard, wording is paramount and it seems that some of the requirements are lacking in any definite detail of what is required.
One area we, as a security consultancy, will have a degree of annoyance with is Requirement 6: Develop and maintain secure systems and applications. In version 1 of the standard, the PCI referenced the OWASP Top 10 project as a guideline of web application issues which need to be addressed. In version 1.1, the OWASP Top 10 was dropped in favor of a narrowed down requirement, namely:
6.3 Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.
This is a great approach at first and is a much needed requirement to force companies at adopting a Secure Development Life-Cycle. Where it starts to fail is the lack of detailed information with subsequent requirements, such as:
6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.
At no point in version 1.1 of the standard does it go into detail of what exactly customers are supposed to check for with their code, to ensure that no code vulnerabilities are present. Security code reviews have to be executed by companies, or individuals, who understand code flaws and also how to spot them. Requirement 6.3.7 could be a massive loophole that allows companies to obtain PCI Compliancy without any correct code reviews taking place.
6.6 Ensure all web-facing applications are protected against known attacks by applying either of the following methods:
- Having all custom application code review for common vulnerabilities by an organisation that specializes in application security
- Installing an application layer firewall in front of web-facing web applications.
Requirement 6.6 is a new addition that is sure to cause more upset than the initial version 1 ever did. Currently all companies offering PCI consultancy services to be Qualified Security Assessors. Whilst there is talk of a test option for these QSA’s, there is little mention of the requirements in performing full scale code audits to discover vulnerabilities and this could also be another loophole in which many companies obtain compliancy with insecure code. Furthermore many banking institutions are unable to deploy web application firewalls due to the complex nature of banking applications and the risk of the web application firewall stopping legitimate banking traffic as a suspected attack
By datasecurity on Feb 7, 2007
Daniel,
Let’s address your concerns one at a time. First, you claim that the OWASP requirements were dropped in the PCI SAP v1.1, but this is not true. Requirement 6.5 has been the same for many years and it states:
The second point you make is that the requirements do not specify what the security assessor should look for when reviewing code. The problem is that there are two different vectors to approach this: functional use risks (i.e. web based vs. middleware applications) and programmatic language (i.e. Java vs .NET). The assessor needs to understand the difference and review it appropriately. To get more specific would be a rabbit hole nobody wants to go down. Read our article on defining what a penetration test is.
Requirement 6.3.7 is NOT intended to force companies to have a formal code review in order to achieve PCI compliance. The requirement is intended to have the company integrate secure coding practices and secure code review as part of their internal SDLC process.
The push towards a web application firewall is to reduce the growing fraud from e-commerce merchants. Even with the other controls in place we are still seeing major compromises of web based applications. Requirement 6.6 is meant to address that. Don’t forget that this is a future requirement: