Doug Lhotka

Technical Storyteller

Opinions and commentary are mine, and do not reflect those of my employer.

(C) Copyright 2019-2023
Doug Lhotka.
All Rights Reserved.
Use of text, images, or other content on this website in generative AI or other machine learning is prohibited.

Herd Immunity and Microsoft Legacy Patches

By

Microsoft just released patches for a ‘wormable’ vulnerability, and took the unusual step of including XP and Server 2003.  That’s prompted conversations and comments about legacy operating systems and ‘enabling’ tardy upgraders. While there are people who still have their head down in denial, there are other cases where it’s much more complicated.

Clearly end users shouldn’t be on XP these days (and soon shouldn’t be on Windows 7).  But what happens when that endpoint is controlling a multi-million dollar piece of industrial equipment?  Or when it’s embedded into devices like an ATM that require significant investment to replace across an environment In many cases the vendor doesn’t support an upgrade (or has gone out of business), and requires either a major overhaul or outright replacement of the entire system.

On the Server 2003 side, it can be similar – large scale applications have been built that cannot be upgraded easily (or at all), either because the vendor is out of business, or there isn’t sufficient capital available to replace the system.  In some cases, it’s a critical line of business application and the source code isn’t even available.

Security folks tend to default to a ‘replace it’ approach, and that’s definitely reasonable given the legacy nature of those platforms, but it’s never that simple.  Risk has to be balanced with cost, and often that results in lingering legacy environments.  In most of those cases, companies have either firewalled or airgapped those endpoints, sometimes moving to a virtual environment as well.  Unfortunately, some do require internet access for maintenance or functionality, so there may be ways in.

So when a vulnerability comes along that can be ‘wormable’ – autonomous spreading of malware without user intervention, there’s a small (but very important) set of infrastructure that’s at risk.  These systems can’t just be unplugged or disabled easily, as it can have significant impact to the business – potentially to the ‘go out of’ level.

That’s why Microsoft’s decision to issue the patches is commendable.  They’re protecting the ones that legitimately can’t upgrade from the tardy upgraders.  In some cases folks won’t, so a worm may still hit, but if a significant portion do, the effects will be contained and isolated – and that’s where herd immunity comes it.  If we can get most of the legacy systems patched, the risk to the entire environment drops.

If you have legacy systems, by all means, use this as a reason to have the conversation (again) with your stakeholders and vendors about upgrading.  But first, find the machines, and get the patches applied, courtesy of Microsoft’s good will.  Kudos to them for protecting the herd.

The Problem of Android

By

(c) Depositphotos / @abidal

I’m an Apple guy, and have a love-hate relationship with their recent product strategy, and the tight control they keep over the ecosystem.  The downside is that we’re stuck with some bad decisions (like building apps that expect to be online all the time), but the upside is that everyone gets access to updates at the same time – Apple has the most up-to-date user base of any major computing platform.  Android, not so much.

Android took the opposite approach – open code base, licensed to manufacturers to customize, and then further customized by carriers.  The advantage to that is lower cost and wider adoption, but it comes at a significant price for security.  When Google releases a new version of Android, only their own devices immediately receive the patch.  Everyone else has to wait for 1) the manufacturer to test, certify, and release the patch, and then 2) the carrier to do the same.   That assumes of course, that both actually bother to do the work to make updates available.  The net is that the vast majority of Android devices are running known-insecure versions of the OS.

I’m seeing a broad movement among businesses to tighten controls over mobile OS versions, and to apply the same policies to both corporate owned and BYOD devices:  If you’re not N or N-1, you can’t use your device.  That means that those old iPhone 4’s get retired too, by the way.

So what to do?  Well, some would say ‘jailbreak’ and install your own code.  There may be something to that, but you run into serious risks there too.  Most jailbreaking tools are from the shady side of the internet, so you never really know what you get.  Most companies block jailbroken devices from business use (all really should).  It’s also technically beyond most users, so let’s leave that off the table.

The next option is to only purchase devices that get updates directly from Google.  That limits choices significantly, but as a side benefit, you don’t get the pre-installed spyware that comes with many of the dirt cheap android phones – that’s how those companies subsidize the phone.  Buyer beware.    This is a hard choice for businesses because it largely erases one of the advantages of Android over iOS (cost), but it’s one I’m seeing a number of organizations do.  For individuals who buy Android devices, it’s the one I’d recommend.

Next is to buy cheap devices, and simply dispose of them when the OS expires.  That’s all well and good, but it’s expensive, time consuming, and you have a window of vulnerability during the transition.  Of course, banning Android completely is an option too, and I do see some of that happening.

But the most common approach I see these days is some form of risk limiting via containerization, or other restrictions on what the devices are allowed to do.  Containers can be bypassed (e.g. compromise the underlying device with a keylogger), but do provide reasonable protection for moderate risk content.  Organizations should leverage their data classification projects to determine what information is suitable for mobile device access, and potentially change that based on how current the OS is.

I know this challenge is top of mind for Google’s Android team, and they’re starting to look at separating the Carrier bloatware layer from the underlying OS as well as other measures to speed up manufacturer release.  I hope they succeed – we need an alternative to keep Apple on their toes.  In parallel, consumers shouldn’t buy devices without clear statements of patch release timelines from vendors and carriers.  Until all that happens, and we have a better option, Android users beware.