Wednesday, July 07, 2010

Thoughts on "Application SOC" and New MSSPs

I'd like to briefly comment on a few ideas that appeared on lists I read.

First, in this Daily Dave post from June, Dave Aitel writes:

So when I gave the FIRST talk, one of the questions was "What is the solution?" ...

Immunity sees lots of success (and has for many years) with organizations that have done high level instrumentations [sic] against their applications, and then used powerful data mining tools to look at that data...

So what you see is the start up of what I like to call the "Application SOC". It's like a network SOC, but way more expensive, and with the chance of being actually useful!


On a related note, after discussing iTunes fraud, Stephen Northcutt adds the following comments in this SANS Newsbites post from yesterday:

I think we are seeing more and more market demand for a new type of MSSP, a cross between (1) a software security and quality consultant, (2) a monitoring company that focuses primarily on web logs and probably has some of their own routines (think Suhosin [a PHP hardening system] on steroids ) and (3) a high end code and configuration incident response capability.

Both Dave and Stephen mention an "application SOC" sort of idea, so let's talk about this first. I believe this already exists, and is indeed used effectively by a variety of organizations. It's certainly at the high end of maturity, but it's there.

Logs can be a supplementary data source, for forensic reference during incident response triggered by a traditional security indicator. Alternative, logs can provide the primary indicator. Unfortunately, logs alone may not necessarily contain the data needed to convince an analyst that a security incident has occurred.

There's also the problem of failing to build visibility in to applications. Gunnar, feel free to reply with a link to your latest logs for developers class!

Turning strictly to Stephen's remaining points, I think companies like Cigital already have the "a software security and quality consultant" space firmly in control.

Stephen's last point, however, seems really interesting. I may be misinterpreting what he said because I like my interpretation, but at the very least he may be advocating for an outsourced PSIRT. I think this is a cool idea. Create a MSSP who provides customer-facing support to vulnerability researchers and others who find software flaws. Work with the software developer to transform vulnerability reports into improved code, handling the public relations, disclosures, coordination with CERT, etc. I don't know of anyone who does that work, but I think every software provider needs a PSIRT. What do you think?

3 comments:

gunnar said...

Hi Richard,

Thanks for the shout out - here is the link to training for Building Visibility In for developers class

http://arctecgroup.net/training.htm

(Security people also welcome ;-P )

webjedi said...

Actually CERT/CC used to do that stuff, but they kind of self-neutered themselves into only doing it for "really important stuff" - seriously, if you saw the kind of stuff that comes into CERT on a daily basis and what and who has to weed through it, you'd be surprised ANY technical advisories or any applications are triaged and researched.

The model may have worked from 1988 up and until the 1990s, but the last 10-15 years, a place like CERT/CC can't keep up with the pace. We'd like to think that DHS's US-CERT could fill a role, but the bulk (like 90% or more) are still written by the small group of analysts in Pittsburgh.

It's now left to industry to step up (and by that, I mean the vendors who do this stuff on a day to day basis... as cited by Rich) to create such an entity.

Anybody willing to step up and flll the market niche?

dre said...

I like this.