How to Handle Meltdown and Spectre: Patch, But Don’t Rush It

February 7, 2018 | Jack Danahy
X

Get the latest security news in your inbox.

Subscribe via Email

No thanks. Close this now.

Welcome to 2018. If you’re still catching up, one of the first things on your radar is probably Meltdown and Spectre — two massive CPU vulnerabilities that have sent the security and broader tech world spinning.

There is plenty of additional data to be found about the actual technologies involved and the likely attacks that will probably follow, but baseline what you need to know is that there is a flaw in one of the ways that Intel uses to improve the performance of their chips.  If you want a comprehensive technical view, including some descriptions of PoC’s of potential exploits, take a look at the original Google Project Zero post. If you are looking for something a little higher level, that includes more actionable pointers, I’d recommend this clear guide to Meltdown and Spectre patches.

As for this post, I’m not going to provide another analysis of Meltdown and Spectre, and I’m also not going to pass judgement. I’m mainly concerned with what organizations are doing to defend themselves. Despite all the press and publicity (a Google query for “meltdown and spectre” yielded nearly three million entries after only 14 days) there has been little in the way of solid recommendations to blunt the impact of the problem. Microsoft has provided patches to block access to vulnerable operations, but these are offered with warnings about side effects and potentially disruptive software interactions. Similarly, Intel has released, then issued warnings on, firmware updates that were intended to help. There is an overarching sense of confusion about the right next steps, especially around the right timing to adopt these remediations.

Seeing this, we kicked off a quick survey to find out how people were coping, and whether this critical and noisy problem was spurring rapid response, or whether those measures were being impacted by some of these negative reports. If you haven’t yet decided exactly what to do, you are not alone. Across the set of respondents, 95% of whom are directly responsible for security updates, only 21% had applied the Microsoft patch to more than 75% of their systems. Most of them, 51%, had patched less than a quarter of their systems, and 61% acknowledged that they were aware that these patches could cause adverse interactions with other products.

This does not need to be the fire drill it may currently feel like

The best advice for dealing with this situation is to recognize that the changes that major firms like Microsoft, Oracle, Apple, and others had to make are serious modifications to low-level system behaviors — changes that may impact their own performance, or that of other applications. These second-order consequences can be nearly as damaging as any eventual attack that exploits these flaws, particularly if widespread updates cause intermittent or widespread downtime.

This event provides security leaders with the opportunity to show balance. A knee-jerk reaction is to instantly apply the patches when available, cleaning up the fall-out as it happens. But why? Currently, there are no pressing exploits or campaigns that are taking advantage of this new weakness. Unfortunately, the lack of public compromises may also lull a trailing responder to wait until the patches have been around for a couple of months, assuming that the rough edges of the process will be worn down on the backs of other earlier adopters. This is a gamble that the patch will mature before the attacks do.

Instead of adopting either of these approaches, follow a middle course.  Take it prudently, but quickly. Treat these patches with a level of testing rigor that you would ordinarily reserve for a major OS upgrade, and be sure that your other dependent applications continue to run smoothly and securely in this new environment.

If you’d like more information, you can find a great set of stepwise mitigation recommendations here, along with more detailed survey information and Meltdown/Spectre details. This is a serious new kind of problem, but one that you can manage with proper planning and a cool head.

Jack Danahy

About the Author: Jack Danahy, Barkly
Jack Danahy is the co-founder and CTO of Barkly, the company advancing endpoint security by combining the strongest, smartest protection with the simplest management. A 25-year innovator in computer, network and data security, Jack was previously the founder and CEO of two successful security companies: Qiave Technologies (acquired by Watchguard Technologies in 2000) and Ounce Labs (acquired by IBM in 2009). Jack is a frequent writer and speaker on security and security issues, and has received multiple patents in a variety of security technologies. Prior to founding Barkly, he was the Director of Advanced Security for IBM, and led the delivery of security services for IBM in North America.
Read more posts from Jack Danahy ›

‹ BACK TO ALL BLOGS

Watch a Demo ›
GET PRICE FREE TRIAL CHAT