Why every breach is different

I’ve grown used to being asked what unpatched vulnerability was used in the most recent breach, in an effort to make sure some other company is protected.

I appreciate the desire to learn from other companies’ mistakes and not repeat them. But there are several reasons why the answer to that question is complicated, and not necessarily helpful.

First, let me define a few terms so you’ll understand what I’m talking about. A patch is a fix, released by a software vendor, to fix a defect in their software. The Microsoft updates your home PC gets every month are a good example of these. A vulnerability is one of these unpatched flaws. An exploitable vulnerability is a vulnerability that has software available that takes advantage of the flaw to allow someone to do things they normally could not do. Not all vulnerabilities have exploits right away. A zero-day exploit is an exploit that is discovered and developed before the vendor has patched the flaw.

For all the talk of zero-days, many patches come and go without a reliable exploit being released. The flaws are still a problem, but obviously less of a problem than one that actively gets exploited.

I spent nearly half my career loading large numbers of patches onto large numbers of systems, and after a few years I got to be rather good at it. I’ve spent approximately the last year of my career auditing these patches, and coaching the people who load those patches for my current employer. From time to time I’ve also been told to do things like steal a file, or gain access to information I’m not supposed to. It’s an exercise upper management has us do, both to strengthen our systems and to help us learn to think like attackers.

So that’s the perspective I’m writing from.

The first challenge is just getting in to the network. There are any number of ways to do that. One direct way to do it is to booby-trap a Microsoft Office or Adobe Acrobat document, e-mail it to someone in the company, and get that person to open the file. Another way is to use a web page that abuses a flaw in Adobe Flash and/or a popular web browser.

At that point, if the attack succeeds, you’re sitting there with a DOS prompt from some random person’s computer. A that point, you have to establish persistence somehow–at some point that person is going to shut off the computer and you’ve lost your access. So you find a server to jump to. But that random person probably doesn’t have much right to be on that server, so you exploit something to become an administrator, and then you can camp out on the server all you want.

One reason I like my sysadmins who reboot all of their systems once a week is because they make life more difficult for people who want to hang out on servers who shouldn’t be there. These days I take a very dim view of uptime contests.

A successful attack is likely to require several jumps, and several exploits to gain a foothold, find the interesting information, and then get that information out of the network.

Furthermore, not all exploits are created equal. No exploit is 100% reliable, and an exploit that worked in one environment might not work as well in another, whether by design or just plain dumb luck.

That’s why it’s my full-time job to tell people to patch their computer systems and to tell them how good or bad of a job they did last month. The more unpatched vulnerabilities that exist in a network, the more options an attacker has. The more things an attacker tries that fail, the more likely the attacker is to get caught before running off with the good stuff.

That’s why people like me get very upset when people brag about having 20-year-old computer systems still running. Yes, Windows NT 4.0 is still perfectly capable of many computing tasks, but unless you’re still paying for security patches, it’s nearly impossible to keep it secure. The same is true for ancient Unix systems.

Of course, it’s one thing to set out to patch every system on your network every month and quite another to succeed at it. You need good tools to do it, not all tools are good, and not all expensive tools are good. And even if you have great tools, there will be the occasional patch that’s stubborn and won’t apply everywhere, and you’ll be very lucky to get all of that resolved before the second Tuesday of the month rolls around again with a new round of patches.

Not to mention that sometimes emergencies happen and vendors release patches outside of the normal schedule. As I write this, we’re six weeks into the year and Adobe has already patched Flash three times.

Am I saying there’s a window of opportunity to get into any computer network? I guess that’s exactly what I’m saying. I just won’t tell you how long that window is open anyplace I’ve ever worked.

And finally, that’s why I don’t care what patch was missing on any breached company’s network. Enough time will pass by the time I hear about it that my employer had better have that patch down anyway. And since it’s frequently a series of patches, that’s why I rarely prioritize patches. If I must prioritize, I want the Four Horsemen of the Apocalypse patched: Flash, Java, Acrobat Reader, and Quicktime. Close behind those, I want the web browsers patched. Then we’ll talk about office suite and operating system patches.

But since a successful attack is likely to involve using several exploits and I can’t possibly know what phase any possible attacker is in, let alone every possible attacker, we have to find a way to get all of the patches down as quickly as we can while causing as little disruption to our customers as possible.

If you found this post informative or helpful, please share it!