Seven Steps to Deal With Spectre and Meltdown

Security and risk management leaders must take a pragmatic and risk-based approach to the ongoing threats posed by an entirely new class of vulnerabilities, according to Gartner. "Spectre" and "Meltdown" are the code names given to different strains of a new class of attacks that target an underlying exploitable design implementation inside the majority of computer chips manufactured over the last 20 years.

Security researchers revealed three major variants of attacks in January 2018. The first two are referred to as Spectre, the third as Meltdown, and all three variants involve speculative execution of code to read what should have been protected memory and the use of subsequent side-channel-based attacks to infer the memory contents.

Gartner has identified seven steps security leaders can take to mitigate risk:

1. Modern operating systems and hypervisors depend on structured, layered permission models to deliver security isolation and separation. Because this exploitable design implementation is in hardware, all software layers above are affected and vulnerable. However, memory can only be read, but not altered. Exploitation of the flaw requires untrusted code to be introduced and executed on the target system, which should be extremely difficult on a well-managed server or appliance such as a network or storage appliance. There is also an advantage in not rushing to "panic patch." Early patches created conflicts with some antivirus offerings and locked up Windows desktops. Some conflicted with the use of AMD microprocessors, so that the systems would not boot. Other early patches had performance impacts that have been improved by subsequent patches.
2. Nearly every modern IT system will be affected to some extent. Not since Y2K has a vulnerability affected so many systems required a deliberate, phased plan of action for remediation efforts. The starting point for security leaders must be an inventory of affected systems. In some cases, the risk-appropriate decision will be not to patch. However, in all cases, the roadmap for security leaders will be the inventory. For each system, a detailed database or spreadsheet is needed to track the device or workload, the version of its microprocessor, firmware version and OS.
3. The vulnerabilities are not directly remotely exploitable. A successful attack requires the attacker to execute code on the system. As such, application control and whitelisting on all systems greatly reduce the risk of unknown code execution. However, shared infrastructure as a service (IaaS) infrastructure is particularly vulnerable until the cloud providers update their underlying firmware and hypervisor layer. Strong separation of duties and privileged account management reduce the risk of the introduction of untrusted code.
4. When devising a remediation strategy, Gartner recommends breaking the strategy into prioritized phases, because the risk, performance implications and potential hardware upgrades required will vary greatly among use cases. Start with systems that represent the most risk: desktops, virtual desktop infrastructure, smartphones and externally facing servers.
5. Information security leaders need to be prepared for scenarios in which the appropriate decision is not to patch. In some cases, this will be due to lack of patches on older systems. In other cases, the impact on performance is not offset by the reduction in risk, so patches will not be applied. Even for some well-managed servers, the decision may be made to forgo patches to protect performance until future patches have demonstrably acceptable impacts. However, for server workloads, when the performance characteristics allow, Gartner recommends patching and firmware upgrades.
6. For systems that are not patched or only partially patched, multiple mitigating controls can reduce risk. The single most important issue to address is restricting the ability to place unknown or untrusted code onto the device. By reducing this, risks are significantly lowered, because attacks require local code execution. For all systems, this means taking a "default deny" approach, and application control and whitelisting greatly reduce the risk.
7. Spectre and Meltdown represent an entirely new class of vulnerabilities, and this is just the beginning. The underlying exploitable implementation will remain for years to come.