We hear endlessly about how we must keep our systems up to date with the latest, stable versions of applications and the most current security patches available. Indeed, nearly every security framework, standard, and set of mitigation strategies mention patching and updating in some format. Some businesses exist solely to provide patch management solutions and procedures, and these are often cornerstones in managed services offerings.
Even the Australian Cyber Security Centre (ACSC) Essential Eight includes two strategies that revolve around patching, including operating systems and applications. The advice provided by other governments around the world, including the other Five Eyes countries, Canada, New Zealand, The United Kingdom, and The United States of America, also heavily promotes patching as a critical activity.
So, what the hell do we do when patches are not available?
“Upgrade your systems!” you say smugly with a smirk while sipping your overpriced takeaway coffee in a non-recyclable cup with a plastic lid. Before the sales wheels start to turn in your head with ideas about how you can profit from our end-of-life systems, listen up, Captain Obvious. We know we should be patching, upgrading, and replacing systems as a security strategy. No amount of brochureware, colourful graphics, and shared articles on LinkedIn will make us doubt ourselves.
Here in the real world, my friend, we have these things called limitations. Regardless of our inability to exceed those limitations because you need to make your sales number before the end of the quarter, it’s a problem we must handle. So before you “smash” your target for the year, “make club”, and get hurt by patting yourself on the back, pay attention.
We must deal with these things called “budgets”, and despite years of technological breakthroughs, making money grow on trees is still a pipe dream. OpEx, CapEx; they’re all the same because money is a finite resource. Speaking of resources, people cost money, too, and we don’t have enough of them to go around. So even if we could buy your handy-dandy whizbang product or service, we may not have anyone to manage it — or afford a managed service to look after it either. You can call them excuses; I call them reasons and hey — my company, my money, budget, team, and unfortunately, my out-of-date systems and problems.
So, close your fancy sales PowerPoint presentation and give me that whiteboard marker. It’s time to get schooled, Ace.
Ask the right questions, and get the right people involved from your team because we’re going to make the most of your current investment before we spend another cent. Most of us had a big box of Lego as kids, and it had just about everything we needed to build, just about anything we wanted, yet we’re constantly “sold” the idea we need more of the same. You will never find your gaps until you identify your overlaps. More of the same never solve the same problems.
Let’s talk about the MATE principle for vulnerabilities (yes, I’m Australian. And Canadian, but stay with me here) — Mitigate, Accept, Transfer, and Eliminate. In the following sections, I won’t elaborate on how each strategy aligns, but I imagine you can conclude how each applies. The main objective is to prevent, contain, or at least detect exploitation of the security vulnerability, and a solid defence-in-depth approach will underpin this initiative.
Can I resolve the security vulnerability?
In some cases, yes, but it often involves disabling the functionality associated with the vulnerability, which means disabling the system or service. Unfortunately, this approach is an issue because we need the un-patchable system service, so turning it off altogether isn’t viable. The other options include engaging a developer to fix the vulnerability (which may or may not be possible depending on how accessible the code is and how much it costs) or changing to different software or hardware. This statement completely goes against what I’m trying to do here — but I will mention it to be thorough. If you could change, we wouldn’t be having this conversation, now would we?
Resolving the vulnerability isn’t an option. Can I prevent exploitation?
I’m glad you asked. This method could take a little work, but there are several things you can try. For example, input sanitisation could help if the input is the trigger for the exploit. Limiting what data can feed into a system, even something as simple as string length or type can help. This strategy does assume you understand how an exploit works and that you can change the parameters.
On the other side of the coin, you can try controlling the output of the vulnerable system by filtering or verifying the data. If an exploit seeks to exfiltrate specific information, you can implement pattern matching or similar. Explicitly defining acceptable sources and destinations can work, so data doesn’t end up in the wrong hands.
Another popular strategy is applying access controls that limit access to the vulnerability. If an exploit is unreachable, logically, it cannot exploit systems. This strategy is also where Role-Based Access Controls (RBAC) is essential because users should only have the bare minimum access needed to do their jobs. For goodness sakes, don’t hand out administrator access like candy!
Following on from the above, implement firewall rules that limit access and that gives another layer. So imagine a firewall rule supported by access controls. I never say “impossible”, but I prefer to look at “improbable”. I’m always happy to discuss further.
Well, those are great, but what about when I can’t prevent exploitation?
If you cannot practically prevent exploitation, then your next-best option is containment. There may be situations where you cannot apply any of the above measures and accept that exploitation is still possible, so limiting the damage and slowing the attack is the strategy.
Let’s go back to our firewall. Perhaps we can’t reasonably prevent infiltration by a nefarious entity, but if we control our environment, we should consider explicit rules preventing the exfiltration of data or communications. The vulnerable system would have an IP address to apply it to block and avoid egress traffic from the host. This activity also includes alerting when triggering the rules.
If the exploit doesn’t involve exfiltration but rather internal execution of code and applications, then implementing granular access controls to limit who can run the programs may help. Realistically, you should already be doing this for your trusted users, so limiting untrusted users should not be much more difficult. The problem may occur if an authorised user is compromised, so granular access controls is a must. Just because a user is a “trusted insider” doesn’t mean they can do whatever they want. The same goes for administrators.
After that, you can consider changing the default location of system elements and, if exceptionally skilled, where programs can execute in memory or access storage. Many exploits have default locations in mind, so even if an attacker gains access and runs a program, if it relies on default settings, permissions, and places, this strategy should make the exploit fail. Another idea in this area is to make sure an attacker cannot embed or write code to exploit it later.
Resolve, Prevent, Contain. Got it. Anything else?
In cyber, we know it’s “when” and not “if”, so even if you have everything in place to adequately secure your systems, bad things still happen to good people. The last area you can consider is detection, and visibility is vital. We have too many layers of technology that do not integrate well, which leads to a lack of visibility and all the headaches that come with it, like human error. If you cannot stop an attack, at the very least, you should be able to detect it so you can respond accordingly.
You may consider host-based or network-based intrusion detection systems. Most modern firewalls and perimeter security appliances provide a degree of intrusion detection and prevention to leverage this capability; please do so. The same holds for current endpoint protection products, up to and including endpoint detection and response solutions. This thinking goes back to my analogy of the Lego box we had as kids; you often have the building blocks you need, so why not use them?
Logging goes without saying, but I have to say it anyway. Anywhere you can enable logging, do so, but be sure to adjust and configure the logging to be relevant rather than overwhelming with useless information. Underpinning logging should be alerting and notifications, especially for systems you know you cannot patch of update.
After logging, look for any means by which you can detect exploits like monitoring network traffic, access activity, unusual user behaviour, regular scanning of systems for changes, and more. Detection is crucial as it can be several months or more between an exploit and becoming aware it occurred. Do everything you can to shorten the Mean Time To Detection and Mean Time To Response.
Ultimately, you will want to upgrade your systems for more than just security reasons, but security should still be a primary incentive for system upgrading, replacement, and maintenance. Sure, there is improved throughput, capacity, and features, but unless your data is adequately secure, these are all for naught. For now, do the best you can with what you have and make the most of your investments without breaking the bank — set that money aside for a future upgrade or replacement of your end of life systems.
Stay safe out there.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; do not rely upon it as such. Obtain appropriate legal advice in actual situations. All images, unless otherwise credited, are licensed through Shutterstock.