There's a lot of hype surrounding the June 30, 2008, compliance deadline for PCI Data Security Standard (DSS) Requirement 6.6. Is it warranted? Well, yes and no. Unlike many other regulations, PCI is getting the attention of management. There are some tangible consequences, but there's also some misunderstanding. Heck, some people don't even know that PCI DSS applies to them!
Reading through the application code reviews section of the PCI DSS 6.6 Information Supplement made me laugh out loud several times. Its intent was to clarify what's required, but it overlooks reality in a lot of places. Let's take a look at the first option: application code reviews. Testing Web applications for security holes is relatively straightforward, but there are several parts of this requirement that need to be clarified.
For starters, "application code reviews" was a poor choice of words by the PCI Security Standards Council. When people -- myself included -- hear "code review," the first thing that comes to mind is a source code analysis. That's not true in this situation, but many people assume that is what's needed. And the static analysis tool vendors are jumping all over this misconception. Requirement 6.6 Option 1 states, "Proper use of automated application source code analyzer (scanning) tools" is enough to satisfy the requirement. Ha - if only it were that simple!
In my work performing Web application assessments -- looking at both source code and the application itself -- I've yet to find serious flaws in source code that can be easily exploited by hacking the application from the outside. In fact, 95% of all security problems I find in Web applications were uncovered by automated vulnerability scanners and manual poking and prodding of the application.
 |
|
|
|
|
You're not going to find every application vulnerability by relying on just automated scans or just manual analysis.
|
|
|
|
|
|
|
|
|
|
From a source code analysis perspective, it's even more comical that the council recommends a "manual review of application source code" as a way to satisfy the requirement. It's unrealistic and downright ridiculous to believe that manual source code reviews are a reasonable way to find security flaws in all but the most basic Web applications. That's because developers don't have time, and many security professionals don't know what they're looking at. Maybe with enough time (months, if not years) and enough expertise (very rare), a good manual code review could be done -- but most organizations couldn't afford either.
The other two options for satisfying Requirement 6.6 are to perform automated scans and manual analysis. Again, this is something I feel very strongly about: You're not going to find every application vulnerability by relying on just one of those methods. You'll find roughly 50% of the application flaws with automated vulnerability scanners, and you'll find the rest with a malicious mindset and good understanding of how Web applications work and can be exploited.
The Information Supplement goes on to say that "individuals using automated tools must have the skills and knowledge to properly configure the tool and test environment, use the tool, and evaluate the results." This is a valid concern, but these are not things that can be learned overnight or even in six months for that matter. Most Web application vulnerability scanners are complex tools that can take years to master. If they're not that complex, well, then maybe they're not powerful enough for what you need.
Incorporating security in the SDLC
Another thing in the PCI DSS Information Supplement is the statement that reviews or assessments should be incorporated into the software development lifecycle (SDLC) and performed prior to the application being deployed into the production environment. Yeah, right. As much as I and others have been preaching about incorporating security into the SDLC, most development teams aren't on board. They're too busy, and management isn't making it happen.
Furthermore, can you imagine never deploying an application into production before it's thoroughly tested for security flaws? I know it happens sometimes, but in reality, the application has to get out there in the name of money and can be tested later or it's already been in production for years anyway. It's a nice suggestion, but it doesn't gel with how things really work.
There's also talk in Requirement 6.6 about adhering to all policies and procedures, including change controls, business continuity, and disaster recovery. These are certainly security best practices, but for most organizations, they're nice-to-haves that will have to come later. There's no shame in having security goals, and it is something to steer towards. You just can't expect to make these things happen -- and work reasonably well -- overnight in the name of PCI compliance.
So, the simplest, least-expensive, and most reasonable way to satisfy PCI DSS Requirement 6.6 application code reviews is to perform automated scanning and manual testing of the application. Do them from the perspectives of both an untrusted outsider and a trusted user.
Once you believe you have a relatively secure application, look into performing an automated source code analysis. You'll uncover weaknesses your developers never thought about and ultimately will have a stronger application. Just don't rely on the assumption that source code analysis alone is good enough. It may be the answer to Requirement 6.6 compliance, but it's not the answer to application security. No one thing is.
Think simple and reasonable and you'll be way ahead of the curve.
(Kevin's next article will focus on Web application firewalls, which are another option for complying with Requirement 6.6.)
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blogkbeaver@principlelogic.com.
