Don't read this........

.........if you haven't got a problem with legacy apps

The Cyber-Security (or for us older folks, Information Security) industry has a tendency to offer newer, shiner solutions to problems - or silver bullets, as they're often called. In recent years, buzzwords like Next-Gen, AI, ML, etc. have peppered the marketing collateral of new (and existing) vendors, yet we still seem to have many of the same challenges we faced 10, 15 - even 20 years ago.

In fact, despite all of these "advances", most of the security professionals I speak to say that said solutions fall short, and there is an understandable air of cynicism and indifference towards any new solutions.

One challenge that has been around as long as I can remember, is how to deal with a legacy applications. In fact, I am guilty of causing this very problem, when I left the ranks of IT practitioners to chase a dream - having not fully and properly documented my 4GL programming endeavours. My penance for having an understanding boss during my tenure, was to go back in and modify the CRM system I wrote, in order to accommodate new reporting requirements from the government.....

Regardless of industry sector, there are legacy applications almost everywhere - be they written by a long since departed employee, or by a company that either has stopped developing the application - or wants to push the customer to a new, "improved" version.

Typically, the thing that goes hand-in-hand with a legacy application is a legacy operating system - and it is often Windows. I have lost count of the amount of organisations I have dealt with over the years that have an old creaking version of Windows, with an app they can't touch, that is important - even critical - to the business, and is now lighting up the risk register like a Christmas tree (and has the external auditors rubbing their hands).

Sound familiar? Read on.....

If you've read this far, chances are you recognise this problem - maybe you face it yourself? It's not exactly an exciting area, but for many it is the barrier to modernising, digital transformation, or whatever the strategic initiative is. If you cannot mitigate this risk and plug the monitoring & management into your wider tools, you're effectively losing your Wellington Boot in the quagmire. So you have to walk v-e-r-y s-l-o-w-l-y or even stand still.......

Now, back to the Cyber-Security Industry - what do we see and hear from the vendors, in terms of how you might go about solving this problem.

Anti-Virus (AV) vendors

These guys have been dining out on a 20th century approach to a problem for about 35 years! Once upon a time, in the BI (Before Internet) age of floppy disks, having signatures that you add/update into an anti-virus program seemed like a good idea. But, as we moved into the AG (After Google) era, those pesky viruses and malware could get around a damn sight more quickly, so even daily updates over the Internet were the equivalent of bolting the stable door.....

"But wait", they cry, "Heuristics, etc". Because a describing set of attributes that might suggest a file is malicious is going to work - right? Just like asking airport security to be on the lookout for a shifty rucksack wearing, young man from a certain part of the world is going to stop terrorists....

(NB: I am purposefully choosing this clumsy stereotype to make my point - not to be disrespectful, racist, or anything else)

Oh, and lets not forget that AV updates have occasionally be known to cause an issue or two

Next-Gen AV vendors

Aah - the bastard love-child of ex-AV vendor employees and Venture Capital investors! "We're doing things differently". We'll take that Heuristics idea and look at the behaviour - or intended behaviour. In fact, we use AI/ML to do this really cleverly (ask the sales guy to explain the difference and watch the look on their face - which will probably resemble a baby passing wind)

Joking aside, let's take the terrorist analogy again. This time, they're going to look at the behaviour of said caricature. Oh, he's looking nervous. Or, he's chanting under his breath....

You see the flaws here - potentially false positives and false negatives. And the CISOs I know, and chat groups I'm lucky enough to be part of have all debunked most of these new kids on the block, with cruel names (or emoji's) to show their disdain for the lack of efficacy

Host Intrusion Prevention/Detection Systems (HIPS/HIDS)

How on earth could I forget these relics from the mid 2000's? The Infosec world's noisiest and most expensive lucky heather. Of all of the solutions I was mandated to sell, they rank No.2 in my "I'd rather eat my own earwax than sell this" list. (Incidentally, Web Filtering ranks No.1, but that's one for another post)

On paper, they seem like a good idea, but the issue is the number of false positives they generate, the potential to stop a machine working by a well intended Level 1 helpdesk engineer (blocking a registry key triggered by a legitimate application), and many still use signatures.

And like the previous two approaches, they all have a fundamental flaw in this use case - the elephant in the room, if you will.

Legacy (and to a degree, current) Operating Systems

The problem with the mitigation approaches outlined, is that they are predicated on known or expected behaviours - and to an extent, the assumption that the Operating System is robust. Of course, when it's discovered that there is a vulnerability that could be exploited, they might update their signature or AI/ML/etc. to bridge the gap until a patch is ready, but this is typically looking for certain exploits - of which there could be a myriad; known and unknown! And what about when the legacy OS is out of support and no longer patched.

I've heard the term "virtual patching" bandied about, which in essence is similar to the steps above, but this has the potential to lead the customer into a false sense of security - and a lower sense of urgency to address the vulnerability in the code (or patch the OS).

Fundamentally, our approach to mitigating risks and how we approach protecting systems is hugely flawed because (as a CISO friend of mine summed up, when I said I was going to write this):

We give developers kernel-level and user-level access and say 'go do what you want'

So we are always playing catch-up - finding out that there's another gap that needs to be plugged, and so on. You only have to look at the amount of code in operating systems over the years to see why this is always going to be a challenge, if we continue to approach the problem in the same way.

It reminds me a little of a motorcycling buddy, who when a gang of us were out Green Laning in the Peak District, got a puncture, took off his wheel, and pulled out a patchwork quilt of an inner tube - to the mockery of us all. "How about you spend a tenner and buy a new inner tube - you must have spent that in puncture kits! And put some more pressure in your tyres!"

Not the greatest analogy, but you get the point. Continuing to put sticking plasters over a problem is not the answer

Enter "Allowlisting" (or as we old folks call it, whitelisting)

So anyone who's been around me and enjoyed/endured my pseudo-technical rants will know my dislike for AV. Borne out of being a CNE and a developer, I've always struggled to understand why we presume "all is ok, unless told otherwise" in computing terms - especially in this "always-on" age. Whilst Windows 10 and Microsoft in general have improved significantly in terms of security, it's still not ideal. Besides, if we now live in this "Zero Trust" era, then surely that should apply to everything? Including Operating Systems??

Imagine a world, where despite the Operating System, you can put a wrapper around it and unless explicitly allowed, simply prevent files from being executed, read, or written? Where despite the presumed privileges of a user, they have to be explicitly granted or no dice. Imagine if the same applied for the application(s).

This has been shied away from for years, because it's difficult, it requires upfront effort, and continuous monitoring in environments where applications change. But when implemented properly, it can provide a significantly more robust posture than the sticking plasters do - however sparkly they might be.

There are several sources that also recommend this approach; the NSA (Section 3 of their mitigation strategies pdf), the ACSC (see their pdf), and a great video from Rob Joyce of the NSA on this also.

How can you fix it?

There are tools that have been around for quite some time, tucked away in the dusty corner of one or two vendors (ignored in a world of ML & AI) that can deliver a significantly more robust security posture - albeit when properly implemented. So, if you've gotten to here, then maybe drop me a PM if it's of interest. (I've got proven, demonstrable examples of doing this across many industries; Financial Services, Healthcare, Gaming, and Utilities/Energy to name a few)

Equally, feel free to counter or debunk my assertions - I'm genuinely interested in opposing views!

(Footnote: Whilst I may have taken a swipe at AV vendors, I'm not suggesting they don't have a value or place - of course they do! However in the context of the subject (i.e Legacy apps & Operating Systems), I'd assert that the points are fair & valid)