Research

Announcing Project Quant: New Security Metrics Project (with Microsoft)

By Rich

We spend a lot of time talking about security metrics over here, and I've been pretty critical of both overly-broad initiatives that don't help people get their day to day jobs done, and "fluffy" models that try to put hard numbers on risks/threats and such. Well, it looks like it's time for me to put up or shut up.

I'm pleased to announce our latest metrics project, which we're currently calling Project Quant. (Yes we need a better name). We were approached by Jeff Jones at Microsoft to help build an independent model to measure the costs and effectiveness of patch management. This will be a hard metrics model, focused on measuring the operational processes associated with patch management. The goal is to provide IT organizations a tool they can use to measure how effective they are, and track that over time.

I'm excited about this project for two main reasons:

1. We get to focus on hard, practical metrics people can use to improve operations.
2. We are following a "radical" version of our Totally Transparent Research process to ensure objectivity.

We've set up a dedicated landing area for the project at http://securosis.com/projectquant where we will be posting all the materials. Here are the bits you might care about:

1. We are soliciting as much participation in the project as possible- including competing vendors, end users of all sizes, consultants, whoever.
2. The project has a deadline of late June, so this won't drag out indefinitely. The first version may not be perfect, but come the end of June there will be a first version.
3. We really need you to get involved. We'll be asking for survey participants, reviewers, and just plain 'ol grumpy commenters to keep us honest, and help produce a useful result.
4. The results will be released under a Creative Commons license in an open format.

We have the first two posts up at the landing site. The first, Introducing Project Quant, provides an overview of the project and the research process. The second, Project Quant: Goals delves into the project goals in more detail.

This is a pretty huge project, even though it's laser focused on one single operational area. Hopefully you like the idea, and are interested in participating.

–Rich

Security Inevitabilities

By Rich

Despite my intensive research into cryonics, I have to accept that someday I will die. Permanently. I don't know when, where, or how, but someday I will cease to exist. Heck, even if I do manage to freeze myself (did you know one of the biggest cryonincs companies is only 20 minutes from my house?), get resurrected into a cloned 20-year-old version of myself, and eventually upload my consciousness into a supercomputer (so I can play Skynet, since I don't really like most people) I have to accept that someday Mother Entropy will bitch slap me with the end of the universe.

There are many inevitabilities in life, and it's often far easier to recognize these end results than the exact path that leads us to them. Denial is often closely tied to the obscurity of these journeys; when you can't see how to get from point A to point B (or from Alice to Bob, for you security geeks), it's all too easy to pretend that Bob Can't Ever Happen. Thus we find ourselves debating the minutiae, since the result is too far off to comprehend.

(Note that I'd like credit for not going deep into an analogy about Bob and Alice inevitably making Charlie after a few too many mojitos).

Security includes no shortage of inevitabilities. Below are just a few that have been circling my brain lately, in no particular order. It's not a comprehensive list, just a few things that come to mind (and please add your own in the comments). I may not know when they'll happen, or how, but they will happen:

• Everyone will use some form of NAC on their networks.
• Despite PCI, we will move off credit card numbers to a more secure transaction system. It may not be chip and PIN, but it definitely won't be magnetic strips.
• Everyone will use some form of DLP, we'll call it CMP, and it will only include tools with real content analysis.
• Log management and SIEM will converge into single products. Completely.
• UTM will rule the day on the perimeter, and we won't buy separate boxes for every function anymore.
• Virtualization and information-centric security will totally fuck up network security, especially internally.
• Any critical SCADA network will be pulled off the Internet.
• Database encryption will be performed inside the database with native functionality, with keys managed externally.
• The WAF vs. secure development debate will end as everyone buys/implements both.
• We'll stop pretending web application and database security are different problems.
• We will encrypt all laptops. It will be built into the hardware.
• Signature AV will die. Mostly.
• Chris Hoff will break the cloud.

–Rich

Do You Use DLP? We Should Talk

By Rich

As an analyst, I've been covering DLP since before there was anything called DLP. I like to joke that I've talked with more people that have evaluated and deployed DLP than anyone else on the face of the planet. Yes, it's exactly as exciting as it sounds.

But all those references were fairly self-selected. They've either been Gartner clients, or our current enterprise clients, that were/are typically looking for help in product selection or dealing with some sort of problem. Many of the rest are vendor-supplied references. This combination skews the conversations towards people picking products, people with problems, or those a vendor think will make them look good.

I'm currently working on an article for Information Security magazine on "Real-World DLP", and I'm hunting for some new references to expand that field a bit. If you are using DLP, successfully or not, and are willing to talk confidentially, please drop me a line. I'm looking for real-world stories, good and bad. If you are willing to go on the record, we're also looking for good quote sources. The focus of the article is more on implementation than selection, and will be vendor-neutral.

To be honest, one reason I'm putting this out in the open is to see if my normal reference channels are skewed. It's time to see how our current positions and assumptions play out on the mean streets of reality.

Of course I'll be totally pissed if I've been wrong this entire time and have to retract everything I've ever written on DLP.

**Update - Oh yeah, my email address is rmogull, that is with two 'L's, at securosis dot com. Please let me know.

–Rich

Totally Transparent Research And Sponsorship

By Rich

Things seem a little strange over here at Securosis HQ- we're getting a ton of feedback on an old post from November of 2006, but so far only one person has left us any real comments on our Building a Web Application Security Program series.

Just to make it clear, once we are done with the series we will be pulling the posts together, updating them to incorporate feedback, and publishing it as a whitepaper. We already have some sponsorship lined up, with slots open for up to two more.

This is a research process we like to call "Totally Transparent Research". One of the criticisms against many analysts is that the research is opaque and potentially unduly influenced by vendors. The concern of vendor influence is especially high when the research carries a vendor logo on it somewhere. It's an absolutely reasonable and legitimate worry, especially when the research comes from a small shop like ours.

To counter this, we decided from the start to put all our research out there in the open. Not just the final product, but the process of writing it in the first place. With few exceptions, all of our whitepaper research, sponsored or otherwise, is put out as a series of blog posts as we write it. At each stage we leave the comments wide open for public peer review- and we never delete or filter comments unless they are both off topic and objectionable (not counting spam). Vendors, competitors, users, or anyone else can call us on our BS or complement our genius.

This is all of our pre-edited content that eventually comes together for the papers. We also require that even sponsored papers always be freely available here on the site. Sponsors may get to request a topic, but they don't get to influence the content (we do provide them with a rough outline so they know what to expect). We write the contracts so that if they don't like the content in the end, they can walk without penalties and we'll publish the work anyway. We do take the occasional suggestion from a sponsor when they catch something we miss, and it's still objective (hey, it happens).

While we realize this won't fully assuage the concerns of everyone out there, we really hope that by following a highly transparent process we can provide free research that's as objective as possible. We also find that public peer review is invaluable and produces less insular results than us just reviewing internally. Yes, we take end user and vendor calls like every other analyst, but we also prefer to engage in a direct dialog with our readers, friends, and others. We also like Open Source, kittens, and puppies.

Not that we'll be giving everything away for free- we have some stuff in development we'll be charging for (that won't be sponsored). But either we get sponsors, or we have to charge for everything. It's not ideal, but that's how the world works. Adrian has something like 12 dogs and I'm about to have a kid on top of 3 cats, and that food has to come from someplace.

So go ahead and correct us, insult us, or tell us a better way. We can handle it, and we won't hide it.

And if you want to sponsor a web application security paper...

–Rich

Must Be DefCon Time

By Rich

My kitchen table:

–Rich

New Poll (And Article) At Dark Reading

By Rich

Thanks to the unorthodox release of the DNS bug, there’s been a lot of debate in the past few weeks over disclosure. I posed a question here on the blog, and reading through the responses it became obvious that all of us base our positions on gut instinct, not empirical evidence. Andrew Jaquith, in the comments, suggested we take a more scientific approach to the problem, and this inspired my latest Dark Reading article, and a poll. Here’s an excerpt:

Sure, we all have plenty of anecdotal evidence to support our personal positions. We can all cite cases of this or that vendor tirelessly defending its customers, or putting them at mortal risk based on their handling of some vulnerability. We all know someone that suffered real losses at the hands of the latest random Metasploit exploit module, and someone else who used it to close critical holes in their security defenses before the bad guys made it in. We all talk about Blaster, Code Red, and other past incidents like they have any relevance in today’s world, which we all also admit has changed completely from a few years ago. There’s a word for picking and choosing examples to support a pre-existing belief without any scientific basis. It’s called religion. I propose that it’s long past time we brought some current science into the game. It’s time to move past anecdotal evidence or one-off cases into wider-ranging realm of epidemiological studies. It’s time to ask the users what they want, while developing risk metrics to allow them to make informed decisions despite their personal opinions. We may not reach definitive conclusions, and even if we do, they probably won’t last nor change the minds of the truly religious. But it’s always better to seek more data than to dismiss it before we even see it.

As a small first step, we attached a poll to the article to measure how different demographic groups, users, researchers/testers, and vendors, feel about disclosure. It’s not truly scientific, both due to the wording of the question and the self-bias of the readers, but I’ll always error more on the side of more data over less.

So take the poll, and we’ll get the results up in a couple of weeks. Until then, see ya at Black Hat and DefCon!

–Rich

A Question

By Rich

If you can tell, with absolute certainty, that systems are vulnerable to an exploit without needing to test the mechanism, what good is served by releasing weaponized attack code immediately after patches are released, but before most enterprises can patch?

Unless you're the bad guy, that is.

–Rich