ASD Essential Eight Explained – Part 4: Patching Operating Systems

The Essential Eight

The Australian Signals Directorate (ASD) Essential Eight has received considerable attention since it included an additional four strategies to the previously defined ‘Top 4 Strategies to Mitigate Cybersecurity Incidents’. Logan Daley continues the ASD Essential Eight Explained series below.

Patching Operating Systems

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, have to run on top of other software. We install applications into (or onto, depending on how you look at it) on operating systems. We also have to think beyond just the ubiquitous “Windows” operating systems and also consider Mac, Linux, Unix, and any of a number of 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 it’s no surprise that 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 but 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 once in a while 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 a patch that may cause issues. Understand what the patch is, what it impacts, and if you even need it.

Any 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 absolutely 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.

The ghost in the machine?

Human error will always be a factor. We will overlook patches, miss computers because they were offline, incorrectly assign patches to computers that don’t need them, and no doubt we will always find at least one user that simply cannot be interrupted or can’t be bothered rebooting their computer. Implementing some checks and balances can help mitigate these potential landmines.

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 have to 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.

Am I missing anything?

Just remember the non-Windows systems such as Linux, Unix, Mac, and mobile platforms like Apple, Android, and Blackberry. If you haven’t included network devices and IoT in your application patching strategy, include them here. They’re all part of your extended family!

How do I start?

Remember to 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!

Read more from the ASD Essential Eight Explained series.

Go to: Part 1: Application Whitelisting | Part 2: Patching Applications | Part 3: Restricting Administrative Privileges