News that a fundamental security flaw impacting nearly every computer chip manufactured in last 20 years began spreading in the early days of 2018. Two variants – named Spectre and Meltdown – were identified. While their mechanisms are slightly different, both variants exploit a chipset hardware vulnerability allowing rogue programs to read protected memory. That means that attackers can obtain secret information from memory – previously considered completely protected – including passwords and encryption keys.
If a malicious actor has already successfully breached your network, the chance that they will attempt these attacks is pretty low. They have more efficient tools in their arsenal. These exploits pose the biggest threat to cloud services. Especially if the vendor is housing multiple client’s sensitive information because the reward for attackers is much greater.
This discovery is different than the typical everyday vulnerability though. It exposed a fundamental flaw in computing as we know it. Nearly every operating system and processor are affected. To completely mitigate the problem, new chipsets, applications, and operating systems need to be developed. However, there are steps you can take now to reduce your risk.
Spectre and Meltdown show us that the core architecture of chipsets, operating systems, and applications are not as secure as we always assumed. Vendors will have to work together to correct the current exposures over time, but how quickly and completely this happens is not known. Vendors may not be able to identify and correct other foundational gaps in design, and mitigation for legacy chipsets, operating systems, and application may not happen at all.
In the near future, mitigation efforts include vendors configuring microcode for the chipsets to remove the CPU memory management problem. Plus they have to rewrite operating systems kernel code to enforce execution protections against memory. Long term, architecture of the chipsets and operating systems need to be rebuilt to deal with this foundational gap in the design.
How to Move Forward
It’s unknown how long it will take before a long term mitigation solution is developed, so here are some steps your organization can do today to mitigate your risk of being exploited.
1. On-Premise Resources
When deploying solutions it’s important to determine when roll should start and at what pace. There have been some issues with the previously launched patches, so be sure you do your due diligence before deploying anything. Prioritize systems with the highest exposure to untrusted environments.
- Network. Know your network activity baseline and ensure network traffic analytics are being used to identify any unusual behaviors. Be sure to pay special attention to logging, monitoring, and alerting activities.
- Servers. Determine your inventory status for chips, firmware levels, operating system versions, and warranty status. Before installing any patches, be sure that your chipsets and computer manufacturers are in agreement on the solution. Determine which systems are exposed to the Internet or other untrusted network environments, and prioritize based on which systems are at the greatest risk.
- Laptops and Workstations. Determine the inventory status for chips, firmware levels, operating systems versions, and warranty for all your laptops and workstations. Again ensure chipsets and computer manufacturers are in agreement on solution before installing anything.
- Tablets, smartphones, IoT, etc. Inventory and validate solutions against vendor recommendations. Many of these types of devices will auto update with vendor patching.
Before any deployments, be sure you have a process in place – with recovery steps – in case the update breaks anything. Also, ensure antivirus / malware definitions, along with patches for operating systems, firmware, and hardware drivers are up-to-date.
2. Shared / Cloud Resources
Of course, if you haven’t heard from your vendor, you should reach out to them. You need to know what your ‘shared’ environment looks like. How is your vendor protecting you? Are you sharing a database? Do they follow the same compliance requirements that you are required to follow?
- Private Cloud / Infrastructure-as-a-Service (IaaS). Hopefully your vendor has already reached out concerning base hardware (physical / virtual) support. If you are accountable for patching, be sure to work with the vendor to identify their recommended procedures and patch packages. If your vendor is accountable, consult with them on patching and testing windows. In either case be sure to have a recovery / restore plan that is tested before proceeding.
- Platform-as-a-Service (PaaS) / Security-as-a-Service (SaaS) / Public Clouds. Your vendor is typically responsible for fixing their lower level issues. If you are accountable for other fixes, work with the vendor to identify their recommended procedures and patch packages. If your vendor is accountable, consult with them on patching and testing windows. In either case be sure to have a recovery / restore plan that is tested before proceeding.
- Microsoft Azure. At this time, Microsoft reports that their Azure cloud servers are fully mitigated at the Hypervisor level. Host systems should not need additional mitigations for Meltdown, however the mitigations deployed do not impact Spectre.
- Amazon. Mitigation has reportedly been rolled out at the hypervisor level. Guest systems must be patched by the owners.
Solutions are proving difficult because it’s a combination of hardware and software, especially for older systems. To completely mitigate the problem we’re going to have to look at redesigning chipsets, applications, and operating systems, which may alter their function and performance moving forward.
It’s also important to remember that predictions for further processor / chipset vulnerabilities in 2018 are several, so we’re likely to see this get worse before it gets better. Fixing this fundamental flaw in computing today is going to take time. So be sure to mitigate your risks wherever possible.