Is it a patch, or just another problem for your network?

 In Security, Solutions

When is a patch not a patch? When it becomes another exploit on your network.

We sometimes lose sight of these obvious points when talking about patching and vulnerability management. At Tenable, we often discuss vulnerability management (it is what we do), which leads to conversations about patching and patch management (even though that is not what we do). Patch Tuesday has driven systems administrators and vulnerability management professionals into a myopic patch mentality; sometimes it works well, sometimes it works just well enough, and sometimes it leads to stupidity.

Patching isn’t always the answer. When vulnerabilities are found, there should be a logical process for dealing with them. While “slap a patch on that bad boy” is often a great answer, and frequently the easiest, it is not the only response to network vulnerabilities.

security patch

Doing nothing certainly isn’t a good answer: According to the 2015 Verizon Data Breach Investigations Report, 10 common vulnerabilities and exposures (CVEs) account for almost 97 percent of the exploits observed in their data for 2014, but another 7 million exploits were also used. These numbers illustrate the need to address the new and noteworthy vulnerabilities, but we cannot do so at the expense of comprehensive vulnerability mitigation.

How do you proceed? Let’s say you’ve found a vulnerability (or more likely thousands) in your environment. There are a handful of questions you need to answer, or at least consider, before installing a patch aimed at neutralizing the threat.

  • Is it real? Is your network facing an actual threat, or a false positive? The bottom line is that you need confidence in your findings. Acting on bad info is rarely a good idea (unless you are a politician).
  • Are the vulnerable systems exposed? We don’t always think about online exposure the way we should. We generally understand threats that come to us in the form of physical threats to our homes and offices, or services exposed to the Internet. Where it gets tricky is indirect exposures, or systems that are vulnerable but not directly exposed to outside threats. This sort of attack-path analysis can be challenging, but it does add context to our efforts at understanding exposures and mitigating vulnerabilities.
  • Do we care? Should you care about this new vulnerability? If so, how much? Do the vulnerabilities really expose any important data or content? How much exposure are you comfortable with?
  • What are other risks exist? What risks are posed by potential exploit of the vulnerability, and what risks are carried by the patch or mitigation?
  • Does it affect the bottom line? Does the cost of mitigating the vulnerability make sense? Spending a dollar to protect a dime is probably not the best use of limited resources.
  • Are there known exploits? Is there a real risk in this vulnerability? Are there exploits in the wild? There may be unknown exploits, but ignore known Bad Things™ at your own risk.
  • Is a patch the best answer? Maybe the best option is uninstalling or disabling the application or service. If you don’t need it, kill it. But there are other mitigations, like network segmentation or other ACLs, configuration settings, permissions restrictions, or tools like Microsoft’s Enhanced Mitigation Experience Toolkit that can reduce or eliminate the exposure. Taking this approach requires an understanding of the implications of each mitigation – patching is not without risks, but it is sometimes easiest to “just patch.”
  • Can the network recover quickly? No matter your course of action, can your network rebound? Sometimes unwinding a bad patch is as simple as logging into your patch or systems management server and removing the patch. Sometimes it involves re-imaging thousands of systems. If faced with the latter, how would you handle it (besides updating your resume)?

These questions should spark a conversation within all IT departments, and network professionals should internally debate these considerations before the next big patch is released. In the immortal words of Spock: “Patch well and prosper.” Or something like that.

About the author

Jack Daniel is Strategist for Tenable Network Security, and the co-host of Security Weekly. He served as director of the National Information Security Group (NAISG), and is co-founder of Security BSides. Jack’s Uncommon Sense Security blog has been named to the Security Bloggers Network Hall of Fame.

Related Posts: You may also be interested in...


Leave a Comment

four × 2 =

Pin It on Pinterest

mainframe computerSymantec Internet Security Threat Report