Skip Navigation
BlackBerry Blog

Security: Getting Off the Patch - The Shining Hope

FEATURE / 05.29.18 / Pete Herzog

Part 2 of 2

Welcome to the sequel of “Getting Off the Patch” where we explore the point of patching for fun and profit. We are continuing with a part 2 because so much was left unsaid in part 1, like: “So what’s the deal, are you supposed to patch or aren’t you?” and “No, seriously, you gonna tell us?” and “Dude, quit it already, nobody likes you!”

In part 1 we discussed a lot of cool stuff like how patching may just be a form of brand recognition marketing. You should have read it. And we ended with how patching is a security tactic and not an Administrative control. So let’s pick up from there….

If patching is a tactic towards a particular security strategy, how can that be bad? I never said it was all bad. There are reasons where patching makes sense just like there are times when it makes sense to have that third diazepam pill, park diagonally across two parking spots, or hide in a dumpster - and not coincidentally they all involve raccoons.

For example, one overall business strategy is to have perfectly working operations to optimize returns. But optimized returns rely on freedom from costly efforts or unexpected losses (security), and freedom from unpleasant surprises (trust) that force you to drop what you're doing to deal with it. To achieve this, you can pick many tactics and just one of them is patching. So, consider this:

Patching may seem to be one of the cheaper tactics towards security since most patches are free and are no-brainers to install. But in what scenarios is it still cheaper after you count in the time of patching, testing, or not testing and fixing all the other software that breaks? Perhaps we can argue that the cost and ease to install makes it most suitable for home computers in this trade-off. So, home-users with non-critical missions feel free to breathe easy, it’s not about you.

The Problem of Patching

Patching may seem to be more secure because you are effectively interfering with a known vulnerability. But is it the most secure way since it isn't timely because patches come much after the fact and don't address zero days? We can argue that the modicum of protection provided by patching is better for the systems that apply no controls or poor controls, which is the case for many home users. We can also argue that the patch holds for the life of a system, so while it may come late, it never leaves. Other controls aren’t so gallant and require regular maintenance.

Patching may also seem to be the way of increasing trust in your service because it is addressing an uncovered flaw. That means you can have more confidence in it. But does adding unknown code and untested changes to your operations give you more reason to trust it, especially considering it is coming from the source that made it wrong to begin with?

Perhaps if your network is nearly perfectly homogeneous with only that company's software, so that their stuff is guaranteed to have been tested together (even that’s a rarity though) and therefore not break. Although ANY third-party drivers or applications - or your personally configured environment, or unique processes in how you use the patched application, or service - may still change.

Ask yourself if your own experience has shown you that by installing the patches, you're free from troublesome surprises? I don't think we can argue this even for home users because many of them are sick and tired of the undesirable side effects patching may bring. They just don't know how to get off the patch.

Patching vs. Balance of Controls

Now compare the previous considerations to you taking the time/money to install the right balance of controls so that you never have to patch again unless you want some new feature. You make sure the systems are properly hardened with least privilege, unneeded services off, processes separated, and then the systems separated over the network. You keep proper, regular, tested back-ups, encrypt important stuff, lock out generally writable directories, and so on. You know what I mean by now.

So if you do this, then you know which reasons you have to trust your operations, which means no surprises because you can prepare in advance for the problems you know you could have. For example, if you didn't install any continuity controls against DoS attacks due to cost, then you need to create emergency response procedures (an actual administrative control) for handling DoS attacks to get you back and running again as quickly as possible.

Most CISOs would love to have this! They would love to feel this safe, because they really are safer. They would love to have less surprises that are actually scares. Unfortunately, the more common way is NOT doing that and instead relying on a few purchased security devices and automatic patching.

So let me ask you: How many of the last thousand vulnerability notices went out that included information on which controls prevented or mitigated the exploit? When's the last time you saw a vuln report say, “Our tests showed that the bug in Application X lead to a remote root except when Application X directory is read-only?” They don't. If they did, the patch management staff hearing about it would think, "Damn, I should probably make sure all application directories are least privilege!” Instead, they’re programmed by best practices to think, "Damn, root access? Well, let me sit on my hands here while I wait for the patch and hope nothing happens."

Moving Beyond the Patch

Unfortunately, what it comes down to is how well people know their operations so that they can secure them. Most IT staff have no idea even of their own business processes in the organization, let alone the big picture of the entire operations. So, their implemented security is just the off-the-seat-of-their-pants variety. They patch because then it's crazy not to. And in that case, I completely agree. Because if you’re winging it, then every little bit towards security counts. Plus, if something breaks, they can always blame the patch.

What you have to think about here is that you should patch because you trust the software companies to know more about your operations than you do. Patch because you're so used to nasty surprises that you don't think another one will do anything to change your current self-medicated dosage of antacid and alprazolam. Patch because you know clearly that you are taking a short-cut now to save time for something more important until you get time to come back and do it right.

You can add your own excuse here now, or you could just start working towards getting yourself off the patch.

Pete Herzog

About Pete Herzog

Guest Research Contributor at BlackBerry

Pete Herzog knows how to solve very complex security problems. He's the co-founder of the non-profit research organization, the Institute for Security and Open Methodologies (ISECOM). He co-created the OSSTMM, the international standard in security testing and analysis, and Hacker High School, a free cybersecurity curriculum for teens. He's an active security researcher, investigator, and threat analyst, specializing in artificial intelligence (AI), threat analysis, security awareness, and electronic investigation.