June 05, 2008Security - Deconstructing PCI 6.6Organizations handling credit cards feel pressure building as the deadline for PCI Requirement 6.6 compliance, June 30, 2008, approaches. Most are still evaluating how to strategically ensure compliance with this requirement, while maintaining a strong security posture. Deconstructing PCI 6.6 - SC Magazine US The addition of stringent industry guidelines for web application security is long overdue. With the escalating threat of web attacks, organizations must remain vigilant. Web applications are a special breed of living code -- always online, always accessible, always being modified, and always subject to attack. Diligent web application security demands frequent assessment/attack research and findings targeting specific web applications are posted daily. Requirement 6.6 is currently the subject of debate due to confusing terminology and the objective has been veiled by clever vendor marketing campaigns promoting specific solutions. What does PCI Requirement 6.6 really say? Specifically, PCI Requirement 6.6 mandates the following: PCI DSS version 1.1 Requirement 6.6: Ensure that web-facing applications are protected against known attacks by applying either of the following methods: * Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security. PCI DSS version 1.1 Requirement 6.6 Testing Procedure: For web-based applications, ensure that one of the following methods are in place as follows: * Verify that custom application code is periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections. The confusion stems from the interpretation of the requirement. First, let's clear up some high-level misconceptions: * Requirement 6.6 is not just for “level ones.”
Some security vendors have marketed that PCI Requirement 6.6 may be met through either installing a web Application Firewall or outsourcing expensive source code reviews. This marketing distracts from what the PCI Council is seeking in Requirement 6.6. The intended outcome of Requirement 6.6 is the establishment of a web application vulnerability lifecycle – leading to the effective elimination of risk. Vulnerabilities must be detected, communicated, and corrected. This can be done through various measures such as: * Black box testing (run-time assessment)
Application security testing is complex, and resource intensive. The tools and expertise required to perform safe and accurate testing can be costly. Keep in mind both hard and soft costs associated with finding vulnerabilities -- hard costs for tools, training, consulting, employees, etc.; soft costs such as resource outages, development meetings, production outages, resources required to work outside hours, manual validation and elimination of false findings, among others. How to comply with Requirement 6.6 1) Find vulnerabilities in web-facing applications Regardless of your classification as a Merchant or Service Provider, if you have a web-facing application, it must be assessed. This will be far more exhaustive than a network vulnerability scan, and will require authentication to access the majority of application functionality. This testing requires human expertise to exercise the application, validate findings, and test for logical vulnerabilities and other threats a testing tool cannot identify. The PCI Council has not asserted itself as an authority on application security; it leaves the verification of compliance to approved auditors. What the PCI Auditors seek is evidence of due care. Demonstration of due care in testing requires: * Thorough coverage. Automated tools alone only cover roughly half of the web Application Security Consortium's Threat Classifications. If an application is worth protecting, test it thoroughly with both automated and human means. Vulnerabilities in custom application code can be found in a variety of ways. The Web Application Security Consortium has classified 24 different types of attacks targeting web applications. Half of those threats (13 technical vulnerability classes) can be identified at some level of effectiveness through automated means, including run time code testing as well as source code analysis. As with any detection technology, there is a certain signal-to-noise ratio; human validation is required to separate true vulnerabilities from false findings. There are many variables in application security testing, so your mileage will vary. There are 24 threat classifications, with two current appendices (HTTP Response Splitting and Cross Site Request Forgery), which have not yet been formally ratified into the WASC Threat Classification document.] Runtime assessments (referred to as “black box” testing), Source Code Reviews (“white box” testing), binary and static analysis, etc., are all effective methods to find vulnerabilities in web applications. There is a misconception that the detection techniques all try to achieve the same end goal and compete for the same budgetary dollars. The fact of the matter is that each testing ideology brings different benefits to the table at different price points, almost all of which are complementary and help paint a complete picture of application weaknesses. 2) Fix vulnerabilities PCI Requirements 11.3.2 and 6.6 require this. For context, reread PCI requirement 6.1. Proving you have installed a patch to commercial applications and operating systems is easy. Proving you have corrected a weakness in custom application code is a little more complicated. This is where having a consistent testing and reporting methodology will come in handy. There are two approaches to code fixes: * If you own the web application code -- fix it. Be aware that simply buying expensive WAF hardware does not meet this requirement. Configuring that application-layer firewall to fix known vulnerabilities is complex, and entails the risk of misconfiguration, and potentially blocking legitimate traffic to your website -- but you must configure the WAF in blocking mode to satisfy PCI 6.6 requirements that the vulnerability has been corrected. 3) Prove it After significant investment in managing the web application vulnerability lifecycle, an auditor (SOX, PCI, or any other auditor) needs documentation to prove the fix worked. Ensure the mitigation applied does in fact correct the vulnerability in practice and in writing. The PCI 6.6 compliance process of “Find, Fix, Prove” can be simplified further. If the “Find” process is done with sufficient precision and creates proper documentation, the “Find” process can be done in a continual or ongoing manner -- and will in turn document proof of the “Fix” actions as they occur. Auditors like to see trends, especially when they involve continual detection and removal of vulnerabilities -- this makes proving due care very easy. Find, fix, prove(n)
|