Recently, it has come to my attention that industry people I respect (and vice versa) have desired me to re-post some comments I've made on other blogs.
It's also high-time that we at TS-SCI/Security begin writing again. I can tell you that since March (our last post), Marcin and I have been involved heavily in our day-to-day work at client-sites and other community efforts/projects.
A lot of new research is going to begin to become available from BlackHat/Defcon. It's just that time of year where everyone starts to share their work with others. While we can't exactly reveal everything that we're working on quite yet, be sure to check
in for updates. I have been begging Marcin to post something on an HTTP-related argument we got into about the Post/Redirect/Get pattern, as one example.
Comment gone wrong #1
This particular News Podcast set off a blog post from Jeremiah Grossman where he says
on the appsec market maturity and potentiality prediction -- i rate [discount black-box appsec SaaS] as low-value, and in the future, will continue to be low-value.
selling discount app pen-tests hurts infosec management as a whole because you're trying to tell ciso's that they can buy some freedom for $25k/yr (or whatever it is). in reality, they need to spend millions of dollars over several years.
discount app pen-tests need to go out of style. here's why: because the middle-ground and potential high-value comes from partnering with a trusted adviser (i.e. an appsec consulting company), or attempting to retain this talent in-house (which most
companies -- including Microsoft who built lists of individual talent to target -- have pretty much failed).
every BPO (business process outsourcing) expert knows that the ideal is to avoid "discount" shops and focus on real partnerships, but don't give any single one partnership everything.
for example, attempt to retain 20% of your appsec program internally ASAP (this does take time -- don't expect it to happen overnight), while outsourcing initially 20% to one minor company (e.g. Gotham Digital Science, Aspect Security, Denim Group, Matasano,
Independent Security Evaluators), then adding a bigger company (e.g. Accenture/McAfee/Verisign) for another 20% to take over the smaller company's 20% if [expectations are not met -- or major changes occur, such as buyouts]. The next step is to figure out
a balance of adding more consulting companies somewhere in the 40-80% range, while growing your internal talent.
investing in this model is extremely expensive and extremely difficult to manage. ciso's are having problems finding/retaining talent, drafting RFI's, reading RFP's, following up on references, and deciding who is really talented and how that talent
applies to the applications in their appsec programs. most can't or won't even draft an appsec policy.
[low-bid/low-value app pen-test houses, especially SaaS-based ones] convolute and diminish the returns that are necessary to build or even start an efficient appsec program. that's EXACTLY what Andrew van der Stock was trying to say.
if you want software security ROI, go read Sadbury, Soo Hoo, and Jacquith's "Tangible ROI through secure software engineering" or follow any of the work that Steve McConnell has done, which this referenced paper was based on.
if you want to keep selling the idea that your McDonalds solution is the bread-and-butter of modern appsec innovation... best of luck to you. there's plenty of analysts, whole appsec consulting businesses, bloggers, and podcasters that are all saying
that a) you're wrong, b) you sell a one-size-fits-all solution to companies that "don't get it" which almost forces them to stay in the "don't get it" mode near-permanently, and c) the jury is out and the case is closed: appsec consulting is the correct path
and one-stop-shops that do one-off, cheap app pen-tests are so 2008.
Aftermath and reasoning
My comments were due in part to actual recent industry analyst research, so they were not unfounded or inappropriate. More to the point, they were factual and unbiased.
Chenxi Wang, Ph.D., Robert Whiteley, and Margaret Ryan of Forrester Research published a report entitled
In the report, several technologies were evaluated, including:
Application scanning
Application security consulting
Application security SaaS
Penetration testing
Protocol testing
Software protection
Source code analysis
Web application firewall
These topics and research are not new to our blog, where we have discussed many of them. Take these examples:
<a href="http://www.tssci-security.com/archives/2008/05/29/software-security-a-retrospective/">Software Security: a retrospective</a>
<a href="http://www.tssci-security.com/archives/2008/03/24/security-in-the-sdlc-is-not-just-code-review/">Security in the SDLC is not just code review</a>
<a href="http://www.tssci-security.com/archives/2008/02/28/owasp-hartford-tomorrow/">OWASP Hartford tomorrow</a>
<a href="http://www.tssci-security.com/archives/2007/12/02/why-pen-testing-doesnt-matter/">Why pen-testing doesn't matter</a>
<a href="http://www.tssci-security.com/archives/2007/12/02/why-crawling-doesnt-matter/">Why crawling doesn't matter</a>
<a href="http://www.tssci-security.com/archives/2008/01/21/baby-steps-with-web-application-security-scanners/">Baby steps with web application security scanners</a>
<a href="http://www.tssci-security.com/archives/2009/02/12/post-to-webappsec-mailing-list-on-waf-and-pen-test-dead-again/">Post to webappsec mailing-list on WAF and pen-test: dead again</a>
<a href="http://www.tssci-security.com/archives/2009/02/05/guests-on-owasp-podcast-6/">Guests on OWASP Podcast #6</a>
<a href="http://www.tssci-security.com/archives/2008/09/11/web-application-security-tomorrow/">Web Application Security Tomorrow</a>
<a href="http://www.tssci-security.com/archives/2008/06/15/what-web-application-security-really-is/">What web application security really is</a>
<a href="http://www.tssci-security.com/archives/2008/06/23/week-of-war-on-wafs-day-1-top-ten-reasons-to-wait-on-wafs/">Week of War on WAF's: Day 1 -- Top ten reasons to wait on WAF's</a>
<a href="http://www.tssci-security.com/archives/2008/06/25/week-of-war-on-wafs-day-2-a-look-at-the-past/">Week of War on WAF's: Day 2 -- A look at the past</a>
<a href="http://www.tssci-security.com/archives/2008/06/26/week-of-war-on-wafs-day-3-language-specific/">Week of War on WAF's: Day 3 -- Language specific</a>
<a href="http://www.tssci-security.com/archives/2008/06/26/week-of-war-on-wafs-day-4-closer-to-the-code/">Week of War on WAF's: Day 4 -- Closer to the code</a>
<a href="http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/">Week of War on WAF's: Day 5 -- Final thoughts</a>
<a href="http://www.tssci-security.com/archives/2008/06/23/web-application-firewalls-a-slight-change-of-heart/">Web application firewalls: A slight change of heart</a>
<a href="http://www.tssci-security.com/archives/2008/03/11/short-term-defenses-for-web-applications/">Short-term defenses for web applications</a>