When the Payment Card Industry (PCI) Security Standards Council released version 1.1 of the PCI Data Security Standard in September 2006, it clarified existing mandates and added, in Requirement 6.6, some new ones pertaining to the custom application code that handles protected payment card data.
Basically, the council offered enterprises a choice: have an application security organization review custom application code for common vulnerabilities, or install a Web application firewall in front of Web-facing applications.
In keeping with the council's measured approach to improving the security of payment card data, what was put forward as a "best practice" in 2006 will become a full-blown requirement on June 30, 2008. Many companies are already bemoaning the burdensome nature of PCI compliance and will no doubt chafe at paying for either more outside consultants or more security hardware and software.
On the other hand, there are plenty of security professionals who will say that what the PCI DSS requires is nothing more than the same application development and deployment approach that many companies have used for years. I can think of several financial and telecom companies that adopted a similar strategy when working with internally imposed PCI-comparable standards in 1999. Since then, there has been an increase both in the number of people qualified to conduct code reviews and in the availability of commercially supported application-layer firewalls.
Amid today's threat climate, where there is no shortage of people prepared to use whatever attacks they can to gather and exploit payment card data, a strong case can be made for both putting an application-layer firewall in front of Web-facing applications and having application code independently reviewed. However, in the real world, where cost constraints have never been tighter, some enterprises must choose one or the other.
The case for application firewalls
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
The main reason for an application firewall is that it will, if properly supported, actively protect against emerging threats, something a one-time code review will not. Sure, a code review might be able to list classes of attack against which the code is deemed secure, and a reviewer may be able to discount some emerging threats by referring to that list. A code review, however, does not provide a way to tweak application proxies in response to attacks.
One common argument against the application firewall is that it may be tricky to fit into an existing architecture. Another objection is that it may work out to be more expensive than a code review. Pricing varies between brands but you could easily be looking at a purchase cost of around $5,000 for something that will handle around 900 MB of throughput, rising to around $8,000 for 2 gigabites per second (Gbps). Total cost will depend upon the level of application traffic, ongoing licensing fees and personnel costs to manage and maintain your Web application firewall capability. However, if you have staff on hand with the skills to tune and manage an application firewall, like the folks who are already running your enterprise firewall, the additional cost may only be incremental.
The case for code review
A code review is not cheap. For whomever performs it, you are probably looking at tens of thousands of dollars in cost, although the exact figure will obviously depend upon application complexity. Bear in mind, though, that a code review doesn't require the same level of ongoing care and maintenance as a firewall (although future code revisions will need review).
However, enterprises should already be budgeting for code review as part of the software development process. Unfortunately, some earlier PCI guidelines gave the impression that internal code reviews would not be acceptable. Thankfully, we now know it's possible to use an internal staff for the review if it is a) trained and specialized in application-code assessments and b) not the same people who developed the application, this according to the Feb 2008 "Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified" document.
This clarification document approves, with the above caveat, the "proper use of automated application source code analyzer (scanning) tools" and the "proper use of automated web application security vulnerability assessment (scanning) tools."
Making the choice
So now it looks like there may be three avenues available, and in each case the choice may simply come down to people. Does the enterprise have staff who can:
a. Configure and maintain an application-layer firewall?
b. Perform a code review?
c. Use a third-party vulnerability detection tool and fix any problems the review uncovers?
Of course, the decision could also depend upon architecture considerations and how well an application-layer firewall would work with existing systems and devices.
Another factor to consider, particularly for those leaning toward a third-party code review, is how comfortable the organization may be with the status of its code. It is not unusual for payment card applications to develop over time and include some legacy code of unknown origin and unclear purpose. A security staff may not want to remove legacy code and run the risk of breaking a mission-critical application. Without suggesting that anyone should sweep potential bugs under the carpet, placing a firewall in front of an application might be less costly, or less disruptive, than re-writing it in light of a code review.
Finally, it has to be said that PCI DSS, admirable as its goals may be, has been far from perfect in practical terms. Not knowing exactly where the PCI Security Standards Council has drawn the line with Requirement 6.6 can be frustrating for those who are otherwise keen to toe that line. To a security professional who would normally urge the use of both code reviews and firewalls, it is another example of the compliance dilemma. If you promulgate a standard intended to increase security, you must be prepared to answer the question: "What must I do to comply with the standard?" The problem is, the question often becomes "What is the minimum I can do to be in compliance?" Just a few weeks ago, the PCI Council also released a clarification stating that companies can either perform the code review or install the application firewall, but that they would ideally like to see enterprises do both.
I recommend taking the time to understand PCI's Web application requirements, including the clarification documents, and consider how the approved options mesh with your architecture and resources. It is now clear that enterprises have multiple paths to compliance and, if executed properly, any of the options will not only help achieve compliance, but also improve Web application security.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
