Reading Time: 4 minutes

By Ron Temske, Vice President of Security Solutions, Logicalis US

At the start of the New Year, many of you 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.

There are many similarities between the two vulnerabilities.  Initially, Meltdown was reported to only affect Intel CPUs, though recent announcements would 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 utilize 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, etc.

This is obviously only a very brief overview – there is far more detail, if you’re interested, via the links at the end of this article. Let’s focus on a broader perspective.  The challenge that occurs when we, as an industry, focus on specific vulnerabilities is that 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?”

What 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 can ask, “How do I ensure that I’m properly prioritizing 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?”

Let’s unpack those concepts individually.   First, a little background will put things in 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.

With that background in place – let’s focus on the first question we should be asking: “What can I do to ensure I have a holistic view of my environment so that I can properly identify known vulnerabilities?”  To meet this objective, we must first ensure we have an accurate inventory of all our devices and applications.  This may seem obvious, but you might be surprised how few organizations can 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.

The next problem – and this is where most organizations fall down with their Vulnerability Management program –  is proper prioritization of vulnerabilities.  It’s a simple fact that most organizations simply cannot patch or update for every vulnerability that comes out due to the labor 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 prioritization by evaluating many factors.  Ideally, you should consider the following:

  • Common VulnerabilityScoring 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 organization out of firefighting mode and be better prepared as new vulnerabilities are discovered.

LINKS