Grossman's Unanswered Questions

Jeremiah Grossman, one of my favorite web application security bloggers, recently posed a few of his unanswered questions - here's my take on a few of them, but be sure to read the comments thread. Anton Chuvakin's note that "firewall + website = web application firewall" in the minds of some rings true after my own experiences with compliance efforts.

1. Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

For those not in the know, a QSA is a "Qualified Security Assessor" - a PCI approved assessor. PCI-DSS 6.6 (updated detail) says that you can use any of the following:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

The problem that Grossman points to here is that some vendors will use a vulnerability scanner that doesn't provide deep software analysis capabilities - using Nessus instead of WebInspect, for example. My answer here is a firm "No". The capabilities found in full featured application vulnerability scanning tools are far more advanced than those found in most standard host vulnerability scanners. Vendors like Qualys are expanding their capabilities here, and other vendors are or have already. My answer will likely change as these features become increasingly more capable, but for now unless the QSA explicitly explains it, this doesn't appear to be the right solution.

Does this mean that organizations without internal technical expertise won't take a QSA's analysis at face value? Not at all. One of the major reasons that QSAs exist is because organizations need or want 3rd party assessments, and they trust those assessors to help them meet their PCI requirements.

3. As a result of economic downturn, what notable security projects are being cut from last years budget?

Training is being slowed down, and colleagues at other organizations note that they are cutting major initiatives - SIM/SEM technology, new IDS/IPS deployments, and other major hardware and software purchases are being delayed or are being re-scoped to highly critical areas. They're also getting more push to build internally.

The number of vendor calls, and the aggressiveness of those vendors is also increasing. I'm fielding more cold calls, and we're seeing things like the quick Google AdWord snap-ups following High Tower's demise.

I'm looking at the pullbacks as an opportunity - the frenetic pace of security device and technology deployment over the past few years has resulted in a wealth of existing information that frequently isn't as well leveraged as it could be.

5. Will secure code purchasing standards lead to secure code?

Sadly, no. I've seen some efforts along these lines, but I think that we'll see more success by putting testing tools into the hands of developers, as well as greater organizational maturity - secure code re-use for example.

As penalties for security issues become a more frequent topic of contractual negotations, this may begin to change. I've been advocating such a change in my own organization for a while.