Seven steps security leaders can take to deal with Spectre and Meltdown

Research firm Gartner advises security and risk management leaders to take a balanced approach to tackling a new class of vulnerabilities

Seven steps security leaders can take to deal with Spectre and Meltdown - CIO&Leader
Research firm Gartner advises security and risk management leaders to take a balanced approach to tackling a new class of vulnerabilities. Security researchers have revealed three major variants of attacks in January 2018. The first two are referred to as Spectre, the third as Meltdown. Gartner has identified seven steps security leaders can take to mitigate risk:
 
Acknowledge the Risk, but Don't Panic
 
Modern operating systems (OSs) and hypervisors depend on structured, layered permission models to deliver security isolation and separation. Because this exploitable design implementation is in hardware — below the OS and the hypervisor — 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.
 
Start With a Detailed Inventory
 
Nearly every modern IT system will be affected to some extent. Not since Y2K has a vulnerability affected so many systems — desktops, mobile devices, servers, virtual machines, network and storage appliances, operation technology and the Internet of Things devices — 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.
 
Develop a Risk-Prioritized Remediation Plan
 
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 (which the leading providers have done). Strong separation of duties (SOD) and privileged account management (PAM) reduce the risk of the introduction of untrusted code.
 
Prioritize Your Remediation Efforts
 
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 (VDI), smartphones and externally facing servers.
 
Acknowledge That Sometimes the Appropriate, Risk-Based Decision Is Not to Patch
 
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.
 
Implement Strong System Operational Hygiene and Mitigating Controls
 
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. To the extent that public attacks become known, traditional endpoint protection platforms and network-based intrusion prevention systems also mitigate the risk.
 
Plan for Further Mitigation Efforts Through the Next Few Years
 
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.

Add new comment