How to patch less

Last Updated on April 15, 2017 by Dave Farquhar

One of my former supervisors now works for a security vendor. He told me the other day that someone asked him, “Does your company have anything so I don’t have to patch anymore?”

The answer, of course, is that there’s nothing that gets you out of ever having to patch anymore. To some degree you can mitigate, but there’s no longer any such thing as a completely friendly network. The reasoning that you’re behind a firewall doesn’t work anymore. On corporate networks, there’s always something hostile roaming around behind the firewall, and you have to protect against it. If you’re on a home network with just a computer and a router, your computer and router attack each other from time to time. That’s the hostile world we live in right now. Patching is one of the fundamental things you have to do to keep those attacks from being successful.

That said, there are things you can do to patch less.

These days it’s called system hardening. I used to call it optimizing. It’s the same thing, only with slightly different intent. Some 20 years ago, I realized that if you shut off functionality that you weren’t using, you saved memory and CPU cycles and your computer ran faster. About 10 years ago, I took a job that involved system hardening–shutting off functionality you weren’t using in order to keep that functionality from being attacked.

Let’s say you have an Oracle server. Oracle has an optional http server component. A well-meaning administrator may have included the http server when setting the server up, just in case you need it someday. But that means you have something useless sitting on the server, waiting to be exploited. Remove it, and you reduce your attack surface.

The same mindset may lead to file servers with three web browsers on them. A file server has no reason to be visiting the Web. None. Internet Explorer is non-optional, unless you’re running Windows Server 2012, but at the very least, you can uninstall Firefox and Chrome from them. Uninstall Winzip and Microsoft Office too, while you’re at it. It might be nice to have those tools on the server, but you can work around it by pushing files down to your workstation and then back up to the server. Unless there’s some other application running on the server that needs those things, it’s more stuff to patch, and more patches to fail.

Look around for ridealong SQL Server installs, too. They happen. When you find them, find out if they’re serving any useful purpose, and if not, remove them.

Microsoft has done a pretty good job of slimming down their servers since Server 2003R2 but an overzealous admin can still check all the boxes and leave you with a server that’s running far more than it needs. Slim it back down to the services it needs to perform its role, and nothing more. In some cases, you can deploy Server 2012 without a GUI at all. That means if a font vulnerability drops, you’re immune. No patch necessary. Scaling down a modern server OS to its bare essentials can really reduce the number of patches you have to deploy.

DISA, the IT organization that serves the U.S. military, has some guides for hardening Windows called STIGs. Download and use them. If you follow the STIGs, your machines will be less vulnerable and need fewer patches. They’ll even run a little bit better too, because there will be less stuff on the system contending for CPU cycles and memory.

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

2 thoughts on “How to patch less

  • March 24, 2014 at 1:09 am
    Permalink

    Agreed, unless you use that function actively remove or disable it. Same goes for any and all ports, f it’s not a port you use turn it the heck off!.

    And now Dave, imagine yourself in hell. While I worked for AT&T’s Worldnet, everyone in the department, 5 to 15 on any day. had the system administrators worst nightmare. We had to have inside the firewall access to control the equipment down net ( we handled pop access ) AND to check the functionality of those POPs had to have outside our firewall access as well. I never looked into just how far you could push the dialup access side, however…..

    • March 24, 2014 at 7:34 pm
      Permalink

      Chuck, that’s interesting. In the interests of not limiting my career, I won’t speculate further about AT&T, and I won’t mention Weev. Oops.

Comments are closed.