Meltdown and Spectre are Scary New Things That are More of the Same update from January 2018

Well, we made it about four days into the new year before new bugs came along and wrecked it for us. Meltdown and Spectre garnered a huge amount of press last week because they’re rather nasty, they impact a huge number of machines and at their heart, they represent fundamental problems with CPU architecture design. We saw something vaguely similar with the Row Hammer exploit in 2014 but other than that, these bugs are largely unprecedented.

But then, when you stop and think about what it means to the masses, they largely mean the same thing as always in terms of what we actually need to do about it. For example, you should patch your things. There’s already a great list of patches for various environments and this is precisely the same mitigation as we’ve had so many times before. Of recent prominent note was WannaCry last year; yes, it was bad, but it was only workable against unpatched machines. Whilst I wouldn’t want to imply that Meltdown and Spectre are insignificant bugs, following the same old advice we’ve always given around patching your things fundamentally changes the risk they represent.

Much of the press we’ve seen has been about weaponizing these bugs has focused on snatching passwords. If an arbitrary memory location can be read and a password snared then clearly that poses a problem. So how do we mitigate against that risk? Use unique passwords, limit the scope of what an account can do once authenticated and wherever possible, use multi-factor authentication. These are not specific Meltdown and Spectre defenses; they’re good old-fashioned advice that should prevail across all our information systems.

Related:From Patches to Performance: What Enterprises Need to Know About Meltdown and Spectre

Extend that thinking further to how we manage our environments; there’s a huge number of databases behind web applications that are sitting out there in publicly facing network segments. MongoDB instances in particular remain readily discoverable via the likes of Shodan and they sit facing the world not because they need to, but because it’s convenient. If bugs such as these potentially disclose credentials for those environments, getting them away from public accessibility dramatically changes the risk they represent.

The point of all this is that even though the Meltdown and Spectre bugs were unprecedented in so many ways, organizations should have been preparing for them for years by way of basic security practices. There’s a propensity when this stuff hits the news for it to all seem rather dire (and again, let’s not downplay the severity of these bugs), but there’s much more control in the hands of those defending against incidents like this than may be immediately apparent.

Related:How to Protect Against the Meltdown and Spectre Vulnerabilities

Next week or month or quarter there’ll be another incident that again will have us all rushing to protect ourselves against some new previously unseen threat. It’s always the case – there’s always something new – but those underlying principles don’t change and now, more than ever, is the time to think about getting these right.