Dealing with the Fallout from Meltdown & Spectre

In the first of a three-part series, Ryan Green and Matthew Flanagan provide practical advice on how to deal with the discovery of a major security vulnerability that puts your environment at risk

The exposing of critical security vulnerabilities, like the recent Meltdown and Spectre attacks that exploited identified flaws in a range of CPU hardware architectures, highlight the need to regularly assess and update firmware, operating system and application patch levels across an organisation’s IT infrastructure.


Nearly all systems and devices are vulnerable

The approach to mitigating a vulnerability often requires special treatment. In the case of Meltdown and Spectre, the vulnerability affects the CPU in just about all systems built in the last 20 years. Therefore, any operating system running on that CPU is affected, along with many applications. The mitigations include firmware, operating system and hypervisor patches, CPU microcode updates, antivirus software updates and recompiling applications.

With most CPU manufacturers impacted to some degree, the fallout reaches almost all desktop and mobile devices, nearly every component in the datacenter, through to the IoT edge. The community is responding and most vendors are releasing updates to secure their systems..

Some patches are affecting performance

With the complex nature of the problem and the need to secure their clients quickly, it is not unexpected that some patches have resulted in instability, leading to the need for rework and redeployment of patches. It is also important to note that many of these workarounds result in higher CPU utilization, which in turn increases latency, leading to degraded application performance. In some rare cases, this has been reported to be as high as 35-40%, but in most workloads the impact seems to be much lower, in the range of 5-15%.

While these issues are broad reaching, the vulnerability requires local execution code to be exploited. This means that an attacker has to have already compromised a device through another unpatched vulnerability or in the case of end user devices, execute code in the user’s web browser via javascript. Systems exposed to untrusted networks, for example servers running in a DMZ, should also be given priority. However, a broad assessment must be made with a considered approach.

Start with an assessment – prioritise for your environment

Key areas for consideration include:

  1. Infrastructure and physical appliances – including servers, storage, switches, routers, firewalls, UPS, cooling systems, power distribution, etc.
  2. Virtualisation platforms – including VMware, HyperV, KVM, Xen, etc.
  3. Security and management tooling – including server and endpoint malware protection, VPN clients, etc.
  4. Datacenter workloads – including server and datacenter desktop operating systems, virtual appliances, etc.
  5. End-user computing and mobile devices – including desktop, workstation, laptop/notebook, tablet, smart phones, etc.
  6. Edge and Internet of Things devices – control systems, sensors, cameras and DVR, printers, scanners, etc.

It is also important to consider each vendor’s standpoint. For instance, a number of physical infrastructure and virtual appliance vendors are taking the position that their products are inherently secure because they do not allow the execution of code that is not theirs, therefore in theory, the vulnerability is more difficult to exploit. This is a defendable position that avoids the need to implement patches and workarounds, which may degrade the performance of their products, but this might not be good enough for some.

Risk profile will determine your course of action

Carefully assessing risk, cost and performance of each action, particularly for critical systems, allows the business to make an informed decision about what to do and, just as importantly, what not to do. If a critical system is known to take a heavy performance hit from the necessary patches and it is unable to be scaled (due to technical or financial implications), the business may need to accept and monitor the risk until a solution can be implemented.

Organisations remediating in an ad-hoc manner, because they don’t have the operational visibility, control and tooling in place when they started, should consider presenting a business case for such improvements, along with revising policies and processes, at completion. Not only is the risk top of mind, but the business is in a much better position from which to implement proactive patch management tooling, a CMDB, monitoring systems, and log management with a known release baseline.


How can CSA help?

We have a team of experts who can help you to assess your current environment and navigate a course of action. Conversely, if you don’t have the time or expertise to proactively manage your environment, you should consider a Managed Security or a Monitor + Manage solution that will take care of your ongoing security and patch management as a managed service. We offer flexible solutions for all types of organisations, contact us to talk to one of our specialists.


[pardot-form height=”400″ id=”2968″ title=”CSA-Web-Meltdown-Spectre-Contact-Form”]


Further Reading

About the Authors

Ryan Green is Portfolio Manager – Datacentre & Cloud at CSA and has over 20 years industry experience in a wide range of technologies. With a background supporting, operating (DevOps) and consulting in closed and open source environments, both locally and abroad, the last 10 years have seen him focus on Datacentre and Cloud solutions, Data Management and Disaster Recovery.  With habitual interest in keeping abreast of technology, Ryan specialises in identifying complementary technologies, architecting solution offerings.

Ryan Green

Portfolio Manager - Datacentre & Cloud, CSA

Matthew Flanagan is Platform Lead – Network and Security at CSA. Matt has over 20 years industry experience in a wide range of technologies focused around Internet and enterprise infrastructures. He specialises in Internet infrastructures, UNIX, security, network architecture and design. Matthew is a Member of the GIAC Advisory Board and holds the GIAC GXPN Certification for Exploit Research and Advanced Penetration Testing.

Matthew Flanagan

Platform Lead - Network and Security, CSA