Author, Todd Gifford – Chief Technology Officer (CISSP)
Background, context and audience
This is the first in a series of blog posts about techniques you can use when you just can’t patch a particular device or system. The posts are aimed at a ‘technical’ audience, but won’t go into lots of deep technical details, mostly as depending on your particular situation, device or system use and context, the details will likely vary. Instead, we’ll focus on some high and mid-level techniques you can use that can be adapted for your requirements.
What to do when you can’t patch
Well, it pains me to say, it depends. Mostly on context and your particular situation. That being said, all is not lost, there are plenty of things you can potentially do. I say potentially, that is the depends part. For this first post, I am going to talk about some common things that don’t regularly get patched, as well as the biggies so to speak – out of support operating systems and services (for instance, SQL).
First question – when you can’t patch
Why? Closely followed by: Why, why, why, why. Crazy as it sounds, 5 Why’s is a technique (one of many) for getting to the root of an issue. Once you get to the root cause of an issue, you can either understand the challenge and correct it, or find some way of mitigating it or working around it so it doesn’t then cause a problem (like an unpatched door control system being hacked for example). For me, this is fundamental to the process of mitigating unpatched systems. Often, once you get to the root cause, you may actually find you can patch the system or service, but the blocker is something easily fixed, like the risk of a system not coming back up, lack of paid maintenance/support subscription or just an old version of software that just hasn’t been updated, or some other easy work around (like a registry or config file change).
Root cause established, you still can’t patch
I’m not going to focus too much on the reason you really can’t patch. The focus is how you mitigate against unpatched ‘things’ on your network. Let’s look at the basics: Cyber Essentials asks you to patch all devices with high and critical patches within 14 days of them being available. Ouch. Moving on from that let’s say you have Cyber Essentials – what is the scope of that? More importantly – let’s take a look at how most systems are compromised: Two common ways – either from malware that is on your network, or directly for systems that are accessible to the internet or some other 3rd party network you don’t control (supplier risk, direct VPN security bypass attacks we’ll cover in other posts).
Looking at malware, typically, that approach will rely on some sort of command and control infrastructure on the internet somewhere. Direct attacks, against say exposed remote desktop, SSH, telnet or web pages, to name but a few, will also likely originate from somewhere on the wider internet.
Understand your risk
For me, putting aside insider threats, compromised user accounts etc. the likely biggest risk factor is unknown bad actors being able to connect to, or remotely control your unpatched devices. How they could compromise them will vary hugely, but the route of access is almost always the internet. If someone has access to your premises, server room or data centre, I would suggest patching is a lesser concern at this point.
Internet risk
Fundamentally, the easiest thing you can do is unplug/stop using your out of date systems. Not very practical in all circumstances of course. That XP machine that runs the door control system, that can’t be accessed remotely to use it, but is plugged into the network? Easy, just pull the network cable out.
Not so easy for your Windows 2008 server that runs your exchange 2013 platform for example.
A huge topic
Yes, this is an almighty can of worms that we could spend weeks discussing, hence breaking this down into a series of posts rather than a novel.
Security techniques for unpatched systems
In the upcoming posts, I’ll look at each of the below in some depth and explore the pros and cons of each, based on some realistic scenarios. Broadly speaking, here are some of things I have done to help mitigate un-patchable systems. If you were thinking that network security was a good thing, I would agree with you:
- Unplug them from the network – not always practical, but highly effective
- Segment them at the network level – best done using a firewall. Only permit access on the required ports. Ensure that any active security you have on the network is up to date (hopefully you are rocking some IPS capability in that firewall)
- Have lots of ‘good’ logging in place and make sure someone is on it like a hawk
- Block the devices from accessing the internet
- Block internet access to it
- Only let specific devices that are absolutely required to talk to the unpatched system do so, and only on specific ports
- Even better, if access is only allowed when required to those specific devices and shut down again afterwards – you might need a friendly network engineer if it’s a low use device, or some scripting or API calls if it’s a regular thing
- Don’t allow the device to initiate connections to other things if at all possible
- Is extended support an option? If funds allow, it is sometimes possible to pay the manufacturer for additional security patches beyond the public end of support date. Likely to be costly to encourage you to move of course.
In my opinion, getting your network security as good as it can be is really key. There will always be risk, patched or unpatched. So always get risk acceptance done at the highest level in your organisation – never accept the risk on your organisation’s behalf.
More on Windows 2008
For now at least, that Windows 2008 server you still have to use for whatever reason, could be good for a few more years security patch wise if you were to drop into Azure as one potential approach – something we have been doing a lot of in recent months. Follow up on our “What to do when you can’t patch Part 2”
Contact us with any of your specific questions – and keep an eye out for my series of posts. I’ll provide some more detail on network security with some examples and possibly even a diagram or two.
