For several months in early 2018, you could not open a browser without seeing news about Spectre and Meltdown – the variants of a vulnerability built in to just about every computer chip on the planet. Discovered in late 2017 by researcher Michael Schwarz at Graz University of Technology in Austria, Spectre and Meltdown actually comprise three vulnerabilities (CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754).
A remote attack based on Spectre (known as NetSpectre) was just made public last month. The exact impact of the attack is still unclear, as the exploit’s ability to leak data is quite limited. Moreover, the attack is reportedly difficult to implement, and can be easily detectable by widely-available anti-DDOS systems.
NetSpectre is an excellent example of how Spectre and Meltdown are serious vulnerabilities that deserve to be treated seriously. They also marked a critical checkpoint in the way we think about hardware security testing and vulnerabilities. These flaws could potentially expose critical information from nearly any computer system. Some six months after the fact, the flood of inflammatory reports, defiant denials, strongly-worded statements and counter-statements that swept the planet regarding these bugs can be seen in a very different light.
The mainstream press fed the hype surrounding Meltdown and Spectre. CNN reported that “…a U.S. government-backed body warned that the chips themselves need to be replaced to completely fix the problems.” The New York Times reported that “…the software patch needed to fix the issue could slow down computers by as much as 30 percent…”.
The tech community wasn’t far behind in its Armageddon-like predictions. “Since news of these attacks first broke, it has been clear that resolving them is going to have some performance impact,” noted Peter Bright of ARS Technica. And Nicole Perlroth, a senior cybersecurity reporter at The New York Times, tweeted that the exploits are “Basically, the motherlode. Meltdown can be exploited by any script kiddie with attack code. Spectre is harder to exploit, but nearly impossible to fix, short of shipping out new processors/hardware.”
But was the hype surrounding Spectre and Meltdown disproportionate, and was the hysteria warranted? What did we learn in preparation for the next catastrophic vulnerability?
Spectre and Meltdown in Perspective
To be fair, Spectre and Meltdown are going to cost a lot of money over the course of the next couple years – both in direct patching costs and the potential losses associated with malware and possible breaches.
However, it is now clear that the way these vulnerabilities were handled in the first weeks following their release was impractical, panic-fueled, actually caused problems, and ultimately resulted in a huge waste of money and resources.
For one, the vulnerabilities had not at that time been actively exploited. There was a public exploit published, but it was not proven that someone actually used this exploit – no malware or breach was discovered that leveraged it, and it was unclear how it could even be exploited remotely. Second, The unnecessary frenzy caused organizations and vendors to release untested patches that had not been validated; the rush to remediate translated to implementing unvalidated methodologies.
The point here is that the tech industry and mainstream press obsessed about Spectre and Meltdown owing to the vulnerabilities’ extreme technical severity, not their actual potential impact, and without a thought-out vulnerability remediation plan.
What’s worse, while the vulnerability management universe was imploding about Spectre and Meltdown, there were vulnerabilities actually being exploited that never made the headlines.
The Bottom Line
Vulnerability managers, CISOs, and other security stakeholders can draw actionable conclusions from a critical look at the handling of Spectre and Meltdown. First, Meltdown and Spectre were not exploitable; the urgency drew our needed attention away from other vulnerabilities causing damages involving widespread security flaws according to Intel. Second, because coordinating between teams to orchestrate remediation is always complex, we are plainly aware that we wasted time which caused damage; the Spectre and Meltdown cleanup was messy and ineffective. Moreover, efforts and energy could have been used to plan remediations in a much more timely and cost-effective manner.
So the key takeaway: short-term priorities should revolve around vulnerabilities that are either actually being exploited, or have the highest potential for exploitation and most serious level of potential detrimental impact.
We need to acknowledge that the plan to address this will be costly, and frustrating. Effective vulnerability remediation should offer integrated, intelligent and weighted insights derived from multiple systems. The ultimate goal should be to achieve precise, infrastructure-focused and context-sensitive prioritization of vulnerabilities – and not to be distracted by what’s making headlines. Even serious vulnerabilities which pose immediate threats (like WannaCry and Petya) should be handled strategically and without panic.
To correctly prioritize vulnerabilities in infrastructure, application, and code – security teams need to consider the overall status of the vulnerability within the larger landscape of vulnerabilities at that very snapshot in time. By determining each vulnerability’s impact on business processes and current exploitability compared to remediation efforts, significant wastage of resources, time, and money – not to mention panic – can be avoided.
