What Is It? One could probably argue that this is no different than Patching Applications, which I covered in Part 2 of this series. Yes, and no. Yes, because it is, in fact, applying updates and patches to your systems, and no, because the operating system is critical to making all the other parts operate in your environment. We seem to forget at times that our favourite applications, covered in part 2, must run on top of other software. We install applications into (or onto, depending on how you look at it) on operating systems. We also must think beyond just the ubiquitous “Windows” operating systems and consider Mac, Linux, Unix, and any of many other platforms (Novell, anyone? Don’t laugh…. it’s still out there!)
There are also the operating systems that run on our favourite mobile devices powered by Apple, Android, Blackberry, Microsoft, and more. We could also consider network devices and IoT, but I think I’ve made my point. Whether virtual or physical, the operating system is the heart of the computer. Think of it like a car: you may have the baddest hot rod on the block (app) but without the engine (operating system) it’s useless. Critical maintenance updates (think of safety recalls on cars), absolutely must be applied, or else bad things can happen to good people.
Like applications, operating systems don’t have the luxury to sit in QA for endless tests trying to sort out every little bug and detail that can and may go wrong when the stars align just right. So, surprise, surprise, operating systems have bugs. Some are an annoyance; some are a major security flaw. The vendors know this, and through their own means or through issues brought to them by people like you and me, they’re constantly seeking to make their product better, safer, and do more.
Unless you’ve been living under a rock, you’ve heard of WannaCry and Petya/NotPetya and how much of an impact it had globally. You’ve probably also heard how there was a patch that dealt with this available before the major outbreak even began yet, it cascaded around the world anyway despite there being a fix in place. I won’t go into the logistics nor will I play the “I told you so” card (there are many that have been doing this so why pile on?) but it highlighted the need for regular patching.
Where Do I Start? For Microsoft aficionados, Patch Tuesday is a thing and has been for a very long time, but that doesn’t mean that patches and updates aren’t available at other times. Find out from your team how patching is handled, how patches are acquired from the vendor, tested, and deployed. If it’s a case of just checking occasionally or whenever you have time, I’d suggest making this part of your regular security maintenance. Ask the questions and get the right people involved to understand your patching and updating strategy. Ideally, you want central control and distribution, so you don’t have 500 users downloading the same patch 500 times, let alone being a patch that may cause issues. Understand what the patch is, what it impacts, and if you even need it.
How I do I Make It Work? If you’re not patching your operating systems, start doing so. There are plenty of applications available that can scan your network, identify the patch levels of computers, and provide a report to advise which systems need which patches. Get those patches, test them, and deploy them but try to automate the process as much as possible. There will always be systems that cannot be updated or must be done manually. You may also need to get management involved to help enforce the idea that computers must be patched, and users cannot simply ignore the updates because they will put more than just themselves at risk. While it may be tempting to spend time evaluating every single patch that gets released, perhaps consider working with someone that understands your infrastructure, like a managed service provider, and have them either provide advice or look after the patching entirely.
Ask questions. Find out what your patch management strategy for operating systems is and ask if you can do anything better. Talk with managed services providers and specialists in patch management. Implement a regular, scheduled patching regime and allow for the occasional emergency update. Include change management process in the strategy. Decide which patches are needed, test, and deploy. Happy Days!
Pitfalls? Plenty, but probably more from the perspective of not actually doing ANY patching at all. Not every update fixes every problem and sometimes, they can cause other issues which is why patches should be tested prior to deployment unless it’s critical and you can’t wait. Scheduling of patches needs to be handled right because you don’t want to reboot someone’s computer when they’re trying to make a deadline or have open documents with a lot of unsaved changes. Things can and do go wrong, but like wearing your seatbelt, I prefer the odds of having it on over not doing anything.