For those of you who keep up with the PCI DSS standard, the coucil today has issued an update titled: Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified.
The standard item 6.6 has been further clarified in one of two options, as before, being either Application Code Reviews or an Application Firewall. I'll address the first option, since that is the more logical one, but will briefly talk about the Application Firewall as well - just to clear the air a bit. While the Standards Council continues to add clarification, which makes the standard more usable, more opportunities for compliance surface with less cost and effort. No doubt the IT manager feels like this is a good thing because now the cost of compliance won't necessarily be astronomical - and thereby make it viable. As we all know, the issue of compliance to a non-government regulation is always a balancing act. Compliance, as with most security components, is an equation balancing risk against spending and business value. We all know the results... if the equation balances just right, the business benefits from the added security and sees value while not spending more money than the risk is worth - and security feels worthwhile because risk has been decreased by some factor which affects the business in a positive manner. Granted, it doesn't always work out quite so rosy - but the PCI DSS standard is going a long way to make sure that these equations that happen every day, in many businesses throughout the world - balance.
Now - on to the meat of the standards update. First off, let me address the Web Application Firewall issue. While this is a topic that deserves a whole article onto itself, the short version is this - web app firewalls are very expensive, complex band-aids. That's the reality. While many of them work phenomenally well, and in fact I can name a few that do, they are difficult to implement into an existing production environment, they are primarily signature-based (remember how well we stop "unknown" viruses?), or have some other architectural quirk that makes them an impossibility in your enterprise. Personally, at my previous company I started to implement a particular WAF ... but it took over a year and a half of research, testing, approvals, and more testing to get them into a newly built environment... not even into a legacy production environment where they would have provided the most value. Anyway... the point is - a WAF is a tool you use when you don't have the resources to "do it right"... fix the code itself.
Section 6.6 of the PCI DSS standards, option 1 (the Application Code Reviews) now has 4 basic alternatives. Candidates are urged to implement at least one of the following...
- Manual review of application source code
- Propse use of automated application source code analyzer tools (static code scanners)
- Manual web application security vulnerability assessment
- Propse use of automated web application security vulnerability assessment tools
First, a few things of note. The above does not necessarily call for a "penetration test" which exploits vulnerabilities by an ethical hacker... only an "assessment" (which identifies but does not exploit) vulnerabilities is required. The distincion is important because it means that you can now do this on production code, or a production environment without the risk of damaging your applications by necessity to prove their vulnerability.
I find it interesting that the update goes and directly says "In all cases, the individual(s) must have the proper skills and experience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings". The fact that the DSS requirement 6.6 now specifically addresses competence in the assessor should mean that there was some ... question... over the competence of assessors or possibly a need to specifically stamp out that only qualified people should be doing assessments. Interesting, at either angle. The same statement goes for assessors using automated tools - but now we have an interesting proposition. Do you (a) hire an extremely qualified application vulnerability tester, or (b) hire a knowledgeable user, and give him a software testing/scanning tool and some training... and are those even the same? Obviously the dollar amounts for the two are different... or are they? There is also the point about the testers having to be (the authors use the word "should be") organizationally separate from those writing the code... well that makes sense. No one wants the fox guarding the hen-house, right? You don't want the same developers that are potentially churning out insecure code to then review it and give themselves gold stars. So far so good.
So now we have 2 options for doing this internally - which will help our bottom line (external 3rd parties are typically very, very expensive)...
- First option is to do an SDLC-integrated code review... actually reviewing the application code before it gets compiled and leaves the development group's control. We have the option to do it manually, or with some tools - using only highly trained and knowledgeable people.
- Second option is to do a post-development analysis of the code. Once the code is written, built, and tested for usability issues it's time to security-test it with, again, either a human being, or some black-box testing tool(s) - but again, you must use trained and knowledgeable people here as well.
Well, if I'm a security manager...this is great! Thinking logically - you always want the security expertise in-house, and why in the world wouldn't you want to do application security throughout the application lifecycle? The DSS update also goes on to remind us of requirement 6.3, and the need to have an effective change-control process such that the security reviews are not bypassed, at any level. While the final sign-off must be done when the code is ready for production - it's imperative that the effectiveness of the application security policy be enacted to push as far back into the development (pre-development planning? requirements gathering?) lifecycle as possible (more on that in a separate article).
As a final note - the update talks about the need to stay current and abreast of new developments in application security testing. It's essential that whatever tools are purchased (whether they be the full SDLC suite from HP/ASC, or some other vendor) - that these tools and their users be continually updated from the brightest minds in the field. This is unfortunately a one-up battle against the "bad guys"... if you're behind you're sunk.
So what have we learned from the new Section 6.6 update?
- There are at least 4 ways to interpret the "Application Code Review" guideline
- You can have your code "reviewed" internally, as long as your assessor is trained and competent (but to who's qualifications?)
- You can use automated tools, either static code analysis or black-box testing software, if you have your people trained in those tools, and application security
- Your testers/assessors have to be organizationally separate from the development organization (but at what level?)
- Your organization should absolutely integrate application security as early into the SDLC as possible, using "tools and rules" in combination
- Your testers should always be up-to-date on the latest developments, techniques, and methods... otherwise you're bringing a knife to a gunbattle
Thanks for your attention!
