The “Spectre” of a Meltdown

Ron Temske, Vice President of Security Solutions, Logicalis US, shares his thoughts about Meltdown and Spectre.

Many of you may have read about two new cyber vulnerabilities – Meltdown and Spectre. I want to spend a little time sharing my thoughts about these vulnerabilities and Vulnerability Management in general. The focus here is not to repeat the numerous articles that have already been created on this topic but to share thoughts and opinions on the topic. I will include links at the end of the article to some of the websites that I think provide particularly useful information on the topic.

Meltdown and Spectre - Close cousins?

There are many similarities between the two vulnerabilities.

Initially, Meltdown was reported to only affect Intel CPUs, though recent announcements suggest that IBM Power is also impacted.

Spectre affects virtually all processors.

At a high level, these exploits break traditional memory protection rules to allow access to other address spaces beyond the current running program (including direct access to kernel memory).  The attacks leverage side effects related to out-of-order instruction execution present on modern CPUs.

Meltdown enables access to privileged memory by using side-channel attacks against CPU cache. Intel processors utilise a technique called 'speculative execution' which allows the CPU to anticipate (speculate) which instructions will be requested next and execute them in advance.  If the speculation is wrong, the CPU simply deletes the info. The Meltdown attack allows access to that information while still in cache.

Spectre works by copying memory from other applications running on the infected machine. For example, it could copy passwords entered in websites that are still cached in the browser, copy data from a financial application and so on.

This is only a very brief overview – there is far more detail which, if you’re interested, is available via the links at the end of this article.

Cyber vulnerability - The right questions

Let’s focus on the broader perspective. The challenge that occurs when we, as an industry, focus on specific vulnerabilities is we risk missing the big picture.

This appears to be the case with Meltdown and Spectre and previously around WannaCry, Petya/NotPetya and others during 2017. The problem with focusing on specific vulnerabilities is that it causes us to ask questions like, “How can I protect myself from Meltdown?” or “Does your solution protect against WannaCry”? and “How can I tell if I’m vulnerable to Spectre?”

The question we should be asking is: “What can I do to ensure I have a holistic view of my environment so that I can properly identify known vulnerabilities?”

Once we have that information, we then ask, “How do I ensure that I’m properly prioritising my remediation efforts by considering the overall severity of the vulnerability, the business criticality of affected systems, the amount to which this vulnerability is being exploited in the wild and the risk to any existing applications?”

First some perspective: The National Vulnerability Database (https://nvd.nist.gov/) (NVD) is a US Government repository of known vulnerabilities.  In 2017, the NVD documented over 14,000 vulnerabilities!  While Spectre and Meltdown are very serious and deserve attention, it’s important that we don’t lose sight of the other 14,000 vulnerabilities that aren’t named Meltdown or Spectre.

So, to answer our first question above we must ensure we have an accurate inventory of all our devices and applications. This may seem obvious, but you might be surprised how few organisations actually meet this requirement.

As a side note, these are the two highest priority controls in the CIS 20 controls https://www.cisecurity.org/controls/.

Once we have our device and application inventory in place, we need to conduct regular evaluations to determine where known vulnerabilities exist. This is typically accomplished via a combination of regular scanning plus analysis against the inventory.  For example, if a new vulnerability is discovered that affects all Windows 10 machines, my inventory can tell me which machines are impacted even before I run an updated scan.

Constant threat evaluation

The next problem – and this is where most organisations fall down with their Vulnerability Management program –  is proper prioritisation of vulnerabilities.  It’s a simple fact that most organisations simply cannot patch or update for every vulnerability that comes out due to the labour effort, required downtime and potential application compatibility issues that make this goal unrealistic.  If we can’t patch everything, we better be sure we’re addressing the most important issues. In my opinion, proper Vulnerability Management will accomplish this prioritisation by evaluating several factors. Ideally, you should consider the following:

  • Common Vulnerability Scoring System (CVSS) Score – this is a rating documented in the NVD that provides an opinion on the relative impact of the vulnerability if compromised
  • Business Impact – a lower CVSS vulnerability that impacts a mission-critical system might be given priority over a higher CVSS vulnerability that only affects secondary systems that are not critical and/or isolated.
  • Threat Intelligence – A vulnerability that’s being actively exploited should have a higher priority than one where no known exploits exist. (That doesn’t mean you can ignore them – nor does it mean that Threat Intelligence is infallible, but it’s another factor in our decision-making process).
  • Risk to existing applications – An unfortunate fact is that sometimes patches break applications unintentionally. For example, if you’re applying a major patch to a system with a mission-critical application, you should verify there are no conflicts before placing in production.  If there are, you may need to explore concepts like virtual patching (essentially blocking the vulnerability without actually patching the underlying operating system or application).
  • Known mitigation is in place – For instance, if it’s a network-based attack and an IPS rule is in place that would prevent that attack

In conclusion, we’re seeing that a significant number of widespread attacks are leveraging known, documented vulnerabilities. A proper Vulnerability Management program can help move your organisation out of firefighting mode and be better prepared as new vulnerabilities are discovered.

LINKS

Tags Security, Cyber Vulnerability, cybersecurity, Meltdown, Cyber Security, Spectre, Business Strategy

CATEGORIES

We'd love to hear from you