You are currently browsing the monthly archive for April 2010.
So I was sitting with a group of people recently – experts, as it were – discussing “bad things on the internet”. Someone turned over his shoulder back towards us and asked “So, what exactly is a 0day?” In context, he was asking “Where does the term come from” because, in the conversation, it was being used to describe some exploits that we, as the “good guys”, all knew about – and had for some time. The answer he got disturbed me a bit: “Exploits and vulnerabilities that have not been patched.”
What gives? 0days/0-days/zero days used to mean (generally speaking) those exploits of which neither the vendor nor the “good guys” knew anything about. Ie, “zero days” had passed since a solution -could have- begun being developed. I like About.com’s phrasing:
“A zero day exploit is when the exploit for the vulnerability is created before, or on the same day as the vulnerability is learned about by the vendor.”
A flaw that the vendor and the response community have known about for months but which the vendor hasn’t addressed is NOT a 0day – it’s an unpatched problem :P (There are cases where the time from the issue being known about until the vendor patches it has exceeded, in some cases, a decade.)
I’m trying to figure out how we got to this perceived definition and I wonder if it’s our refusal to come to grips with the fact that there are hundreds/thousands of security flaws running around out there that “the bad guys” know about (and use) that the “good guys” dont have a clue about. We run around patching things like if only we could just reduce the time it takes to patch systems to near-zero that somehow we would be measurably more secure.
If we just write out the truly severe part of the vulnerability window – where there are vulnerabilities and exploits we don’t know about – from our language/definitions, it won’t exist right?
Say you want to buy a car to take your 5 kids and spouse around town. Now, suppose you start looking for a good, safe van with low gas mileage that fits the whole family and is relatively cheap. $20k? sure. Ok, now what if you go out to buy this van….but oh no! All you can find are corvette dealers selling $100,000 cars!!!
Would you buy a corvette? Hells no. You’d wait until you found something that met your minimum requirements: Moving the family around. If you got the vette, you would have gotten something that, even if it fit “some” of your requirements (moving some people around), doesn’t fit enough of them to actually solve the problem. Furthermore, if you did get the vette, you probably wouldnt be able to afford the van so your problem would go on even longer than if you hadnt gotten the corvette.
Welcome to the kind of security that says “we should do more of what we’ve been doing, even though we know the architectures don’t work…because something is better than nothing.” We can’t continue to add on layer after layer of security at ever increasing cost when no number of those layers, as modeled today, will ever get us to a comfortable place. Getting owned by X% fewer people is still getting owned and doesn’t really change your risk profile unless X is a much bigger number than today’s most common best practices get us.
Nothing is ever perfect, so I’m not suggesting no one should take action until they find a perfect solution. Rather, I’m suggesting we all take a close look at our solution sets and look at how good they’re ever going to get at the end of the day and make decisions appropriately. When selecting a “50%” solution architecture for $Y, dont get caught thinking $Yx2 will get you a 100% solution with the same architecture:)