The seven steps of security

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, Inc. "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.

  • Friday, 16th February 2018 Posted 6 years ago in by Phil Alsop
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.
 
"Not all processors and software are vulnerable to the three variants in the same way, and the risk will vary based on the system's exposure to running unknown and untrusted code," said Neil MacDonald, vice president, distinguished analyst and Gartner fellow emeritus. "The risk is real, but with a clear and pragmatic risk-based remediation plan, security and risk management leaders can provide business leaders with confidence that the marginal risk to the enterprise is manageable and is being addressed."
 
Gartner has identified seven steps security leaders can take to mitigate risk:
 
1)     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.
 
2)     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.
 
3)     Develop a Risk-Prioritised 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 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 and privileged account management reduce the risk of the introduction of untrusted code.
 
4)     Prioritise 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, smartphones and externally facing servers.
 
5)     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.
 
6)     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.
 
7)     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.
 
"Ultimately, the complete elimination of the exploitable implementation will require new hardware not yet available and not expected for 12 to 24 months. This is why the inventory of systems will serve as a critical roadmap for future mitigation efforts," said Mr MacDonald. "To lessen the risk of future attacks against vulnerabilities of all types, we have long advocated the use of application control and whitelisting on servers. If you haven't done so already, now is the time to apply a default deny mindset to server workload protection — whether those workloads are physical, virtual, public cloud or container-based. This should become a standard practice and a priority for all security and risk management leaders in 2018."