By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I recently read an apologetic article about the Payment Card Industry Data Security Standard (PCI-DSS) arguing that having a flawed standard that fails to fully secure the enterprise is better than having no standard at all. Explain that to the CIO or CSO who studies the rules, makes an investment in compliance, and experiences a data breach and all the resulting negative media attention anyway.
The fact is you can be PCI-compliant and still be insecure. Look at online application vulnerabilities. They're arguably the fastest growing area of security, and for good reason — exposures in customer-facing applications pose a real danger of a security breach.
The PCI-DSS addresses the coding of online applications and review of custom code. Sections 6.3 and 6.5 are clear about secure coding practices as they pertain to the Online Web Application Security Project (OWASP) top 10 application security vulnerabilities, but they say nothing about the 50 to 60 other risks that may be introduced during application development efforts. PCI presumably has decided that if enterprises focus on these 10 vulnerabilities, the company will be "safe enough." But what about the vulnerabilities on the previous OWASP top 10 list that have been replaced by more recent discoveries? This omission exposes PCI-compliant enterprises to risk — risk that can be reduced by minor changes in the rules related to application security. Why not have it include any vulnerability that has ever been on the OWASP list?
A larger issue is the PCI DSS approach to application vulnerability assessment options. Security assessments are key to developing an effective risk management strategy. Knowing the current universe of all vulnerabilities allows you to prioritize and attack them with the limited resources available.
As the PCI DSS stands now, Section 6.6 makes two high-level compliance options available related to application security. Organizations with public-facing Web applications must either review applications using manual or automated vulnerability assessment techniques or install a Web Application Firewall (WAF) — an option that has created an excellent marketing opportunity for the vendors of these products. Regarding the first option —vulnerability assessment — PCI issued a clarification statement in April, citing four compliant alternatives:
- Manual review of application source code (white box analysis)
- Proper use of automated application source code analyzer tools (white box analysis)
- Manual Web application security vulnerability assessment (black box analysis)
- Proper use of automated Web application vulnerability assessment tools (black box analysis)
The result of this "clarification" was to give IT professionals the option of choosing an automated source code scan or external assessment (manual or automated) in lieu of the more stringent option, a manual source code analysis, making them equally comprehensive de facto. In fact, the differences in the results of these options are huge and should be made clear.
AsTech Consulting has found that an automated scan of source code using market-leading tools will find about 35% of the types of vulnerabilities that a manual analysis will discover. Most experts (including us) agree that a combination of automated and manual source code assessment gives the greatest bang for the buck. External assessments find even fewer vulnerabilities relative to a source code analysis. Some of the most important vulnerabilities external assessments won't find include the following:
- Inadequate or missing protection of sensitive data through encryption in the database, file system, or in communication with back-end or external systems. (OWASP Top 10: A8 - Insecure Cryptographic Storage, A9 - Insecure Communications)
- Internal logging of confidential data (OWASP: A6 - Information Leakage and Improper Error Handling)
- Flawed authentication and/or authorization logic
- Hard-coded resource credentials (database, Web service, etc.)
- An application backdoor that surreptitiously "phones home" to an unauthorized system with critical business information
- Non-production/test code included by mistake. An attacker could glean information about how an application works that may enable further attacks. This could also provide a mechanism for bypassing authentication, authorization, or entitlement mechanisms.
Essentially, PCI DSS says you can be compliant even though its approved testing options have been shown to miss three vulnerabilities on the OWASP top 10 application vulnerability list.
Obviously, manual code reviews are more labor-intensive and therefore more costly than automated analyses. But before they are dismissed as too expensive to consider, those responsible for security should recognize that application security doesn't have to be an either/or scenario. Applications are most vulnerable at certain points — authentication/authorization, user input fields, database queries, etc. A manual assessment of this "attack surface" coupled with an automated scan of the entire code base will give a high level of confidence that the most risky vulnerabilities have been discovered.
PCI rules have come a long way in the past couple of years. Web application firewalls are a relative newcomer to the application security scene. This option will be a good interim protective measure while source code remediation is undertaken. However, as a standalone security solution, a WAF is not sufficient protection. Optimal protection requires configuring the firewall for vulnerabilities that are found through source code assessment techniques, ideally manual plus automated, and then addressed by fixing the source code.
The recent PCI clarification on application security lulls IT professionals into a false sense of security. Since many companies use the PCI DSS as a roadmap to "security," I anticipate that we will see an increase in the number of breaches resulting from online applications unless more stringent rules are adopted.
You always do best for your enterprise by developing a strategy that effectively manages risk — not one that necessarily that eliminates risk. PCI standards fall short of protecting you and your customers, while many people assume that PCI compliance results in adequate security. They can and should do better.
About the author: Greg Reber is the CEO of AsTech Consulting, a San Francisco-based information security firm that has been providing security assessment services to Fortune 1000 companies since 1997. Greg can be reached at email@example.com.