ISACA Now Blog

Knowledge & Insights > ISACA Now > Posts > Meltdown/Spectre: Not Patching is Not an Option

Meltdown/Spectre: Not Patching is Not an Option

Alex Holden, President and CISO, Hold Security, LLC
| Posted at 1:38 PM by ISACA News | Category: Security | Permalink | Email this Post | Comments (1)

Alex HoldenThe most prominent data security events of 2017, such as WannaCry and Equifax, were direct results of poor patching practices. Now, 2018 is off to a menacing start with disclosure of two hardware vulnerabilities affecting most modern microprocessors and requiring a number of patches on several levels of defenses.

To clarify, Meltdown is a vulnerability that allows core system memory access by any user process, while Spectre allows an unprivileged application to access the memory space of others.

What can happen? In simplest terms, one program executed on your computer can gain access to data that belongs to other users or utilize the operating system to access data, including passwords and personal data. What is affected? Most personal computers, servers and mobile devices. What can we do about this? The simple answer: patch everything that is affected, including BIOS, OS and browsers.

If everything seems to be simple, why is this a such a big problem? The answer is not so simplistic. As far as the scope, possible vectors of attack and potential ramifications, these two vulnerabilities present perhaps the largest impact to our computer systems and networks that we have seen in a very long time.

Let’s start with the fact that it is likely that every computer and mobile device in your infrastructure is somehow affected, along with a significant number of IoT devices. Arguably, your shared environments (such as Citrix) present the greatest vulnerability, as these systems are designed for multiple users and the core design is a secure segregation between user resources.

Let’s consider the work of many of us in the security community. We need to identify all the systems and software that must be patched, test the patches, implement them and deal with “side effects.” This includes legacy systems, as the vulnerabilities include microprocessors manufactured all the way back to 1995.

Today, while there are challenges with some patches that introduce processing slowness and compatibility issues, not patching is not an option. We learned our lessons with the 2017 NotPetya ransomware, where the compromise of only one unpatched system would begin infecting the rest of the adjacent network devices.

As of now, there are no known mass exploitations of these vulnerabilities, but it is not because the hackers discounted these issues as “unexploitable.” In the world of hackers, exploitation of a vulnerability is only part of the equation. First, you must have a reliable distribution vector for the malware. Can an exploit be distributed in an email, on malicious sites or through other means to facilitate infection?

After malware is allowed to execute its exploit, it must deploy a malicious payload – a set of instructions of what to do next. Sometimes, it is an instruction set to allow victim system interaction with a Command & Control server, or it is simply used to deploy ransomware. At this stage, there must be a lot of consideration to bypass typical security controls such as anti-virus, IPS and other safety tools.

Lastly, there must be a mass monetization component – for ransomware, it is a setup to ask for a ransom, receive payments, release the encryption keys; in other cases, to facilitate data identification and exfiltration. None of these tasks are simple for the hackers and they can rarely be accomplished by a single person. Thus, nearly a month after the world became aware of the microprocessor vulnerabilities, there is still no mass exploitation.

Today on the dark web, the most common relevant conversation is not about abuse of Meltdown or Spectre. The most entrepreneurial hackers want to know if there are similar vulnerabilities in microprocessors that are not discovered and patched. Hacker bounties for these zero-day bugs are astronomical, and for good reason. No matter how good your system security is, if there is a fundamental hardware flaw, almost nothing will stop hackers from exploiting it on any vulnerable target of their choice.

Meanwhile, as hackers are regrouping and fantasizing about the unexploited data caches, let’s keep diligently patching and hope that the next vulnerability or wave of exploitation will not be brutal.


The value of caution

Although Meltdown/Spectre are very serious issues, the announcement led to a nonconstructive amount of panic and confusion in the industry. There was great uncertainty over precisely which systems were affected, what patches were available, and what the performance impact of those patches might be.

Those who patched very early learned the lesson the hard way; systems became unreliable with frequent reboots. Performance for certain workloads was severely affected. This added up to a great deal of risk to the business, and all of it in the absence of even a single known real-world exploitation of Meltdown/Spectre.

The IT industry's response to these vulnerabilities has been shocking in its ineptness. We need to do better than this. This comes at a time when software vendors have increasingly often been releasing urgent security patches which, thanks to a lack of testing by the vendor, end up damaging or even bricking computers.

As IT security/audit professionals, we need to take a mature view of this.

* Software quality risk exists. Even from Intel, even from Microsoft etc - the risk that a security patch will itself cause damage to your business is real. The more urgent the issue, the more serious the security issue it addresses, the less likely it is to have been adequately tested before release.

* Proper IT operational diligence does not consist in immediately installing every security patch that a vendor provides. Rather it consists in making good judgements about which to install immediately, which to install over after a suitable period of internal testing, and which are not appropriate in a particular environment, period.

In this case, the organizations who took a cautious view, performed risk analysis and determined that they could safely wait a few weeks before patching (perhaps with other mitigations in place) will emerge as the winners here, having let the brave and the foolhardy act as unpaid alpha testers for the poor quality patches from Intel.

Andrew407 at 1/30/2018 8:46 AM
You must be logged in and a member to post a comment to this blog.