I don’t think I agree with the argument against patching everything

Some revolutionary advice surfaced this past week–stop patching everything. And while I understand the argument that people need to stop letting the difficulty of patching everything paralyze them and cause them to do nothing–as I’ve seen some organizations do–and I agree that some patches are more critical than others, as someone who once had to prioritize patches, I can assure you that prioritizing the patches was more work than deploying them and recovering from the fallout was. We eventually found it was much less work just to install all the missing patches every month.

And guess what? Nothing bad happened from doing that.

Now, I can understand applying high-criticality patches that don’t require a reboot and putting off less-critical patches that do require a reboot, hoping to get some increased uptime for free. That was something I wanted to do, but I rarely had time.

Patching in the DoD, you see, works something like this: Patches come out, and 1-30 days later, someone notices and issues an order, with a deadline, to deploy them. Not a great deal of thought goes into the deadline. Sometimes we’d get a month, sometimes we’d get a few days, and if any thought went into the length of the deadline, I never figured out the logic. The best way I found to handle the situation was to deploy all the new patches in the lab the day after Patch Tuesday, spend about a week testing them, then deploy them to production as fast as possible. If I beat the deadline, great. If I couldn’t beat the deadline, I would get an extension for however long I thought I needed plus a day or two in case something went wrong, then deploy as quickly as possible.

This alone stops a lot of bad things from happening. Not everything, of course. But the Australian Defence Signals Directorate (the Australian equivalent of the NSA) finds that patching operating systems and applications, application whitelisting, and minimizing excessive privileges–the DSD Top 4 as it’s known in security circles–stops 85% of malware.

Since selectively patching and patching everything are roughly equivalent in difficulty, why give any of that 85 percent back?

Reducing admin rights is easy. Just do it. If you bought Windows 7 Professional, you already paid for Applocker. Use it. WSUS 3.0 was so wonderful I derisively called it “Wuss,” but it’s a lot better than patching by hand, and I’m sure Wuss 4.0 is less wussy than Wuss 3.0 was. A third-party patch management application is better, but if you don’t want to spend the money, stand up a WSUS server and use it, too.

Then you just have to figure out what to do about third-party stuff, like Java patches. The reason I like third-party patch management applications better is because those will handle the third-party stuff too, and some of that stuff–like Java and Adobe products–is more dangerous than Microsoft software at this point. Shavlik Protect is the current version of the product I used for several years and really liked.

The thing about WSUS and competing products is that they allow you to remotely deploy patches. The difference in effort between deploying one patch and deploying the whole month’s patches is minimal. It might be more work to deploy a single patch than the whole month’s batch. You let it download the patches, approve the patches, set a deadline, and off they go. The guy who took over that duty after I got a higher-paying job had more trouble with it than I did, so maybe I was exceptionally talented at patch deployment–my former coworkers told me that–but it’s doable.

The question shouldn’t be how to cut back on that 85 percent. Instead, people need to be asking two questions: How do you get that 85% as cheaply and effectively as possible, and then, how to prioritize the rest of the DSD Top 35 to get as much of the remaining 15% of protection as possible with as little effort as possible.

I would start with firewalling (#8, 9, and 24), antivirus software (#25), and EMET (#21), personally. You’re probably already doing the first two anyway, just perhaps not quite as effectively as you could be, and EMET is low-cost, highly effective, and has low user resistance.

%d bloggers like this:
WordPress Appliance - Powered by TurnKey Linux