Managing Third-Party Meltdown & Spectre Risk Exposure Strategic Recommendations Beyond Patching

Summary

The Meltdown and Spectre vulnerabilities represent an entirely new class of security flaws that are deeply rooted in long-standing CPU architecture. As such, Meltdown and Spectre are likely the first of many issues that will have to be dealt with quickly as research in CPU security flaws intensifies. Tactically, it is important that you ensure your third-parties implement the necessary patches. Strategically, it is essential that you reassess your standards governing third-party use of cloud-hosting providers and implement measures to bring your third-parties into compliance with the updated standards. 

In this document, we provide a brief explanation of the Meltdown and Spectre vulnerabilities and why they are so impactful, particularly to cloud computing. We also suggest a tactical plan for addressing the issue with your third-parties, and recommend strategic considerations for your larger third-party risk-governance program.

Vulnerability Background

The Meltdown and Spectre vulnerabilities (CVE-2017-5754 and CVE-2017-5753) are very serious security flaws that strike at a fundamental pillar of computing—isolation of memory from other running applications. These vulnerabilities affect Intel, ARM, and AMD microprocessors, and are rooted in the CPU feature known as "speculative execution" or "out of order execution." Exploitation of the vulnerability allows an application executing on the same CPU to gain unauthorized access to the mapped memory of other applications. In other words, anyone running code on a vulnerable CPU can steal your data. For more technical details, here are a few good resources:

• https://meltdownattack.com
• https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability) 
• P6 family microarchitecture

Several proof of concept exploits are publicly available on GitHub. Undoubtedly, private organizations have weaponized highly functional exploits that will come forward in future.

Unique Impact to Public Cloud

The impact of Meltdown and Spectre in public cloud computing is particularly poignant where organizations had become comfortable operating application workloads in intimate proximity to strangers. No longer can you assume that CPU safeguards will reliably prevent unauthorized access to your data. Your own ability to control risk is limited because the patches must be applied by the hosting provider to the infrastructure layers under their control.

Comparing two hosting scenarios, you can implement mitigating patches and other controls in the operating system in cases where you are hosting a dedicated operating system on a shared CPU (Diagram A). However, no mitigating controls can be implemented when hosting on a shared operating system and shared CPU (Diagram B). In both cases, you are entirely dependent on the hosting provider to patch the layers shaded in red.

Diagram A. Dedicated O/S on Shared CPU	Diagram B. Shared O/S on Shared CPU

Not all hosting providers are equal. In the immediate term, you can only hope that the hosting providers used by your third-parties are diligent in their patching. To effect strategic change, it is worth motivating your third-parties to deploy defensible architectures with trustworthy hosting providers.

Tactical Action Plan

The impacts of Spectre and Meltdown are directly mitigated through patching at the CPU firmware, hypervisor, and operating-system layers. While patching at the firmware layer addresses the vulnerabilities, patching is also strongly advised at the hypervisor or operating-system layers. As of mid-January 2018, firmware patches were proving to cause system instability (Intel Firmware Patch Issues). In all cases, patches should be deployed under the advice of the software and hardware manufacturers, and tested prior to implementation. 

Issue a risk advisory to your third-parties

It is dangerous to assume that all of your third-parties are giving Spectre and Meltdown the consideration that you think it deserves. While many of your third-parties will be diligent in their remediation, some less sophisticated vendors may not. Given this reality, RiskRecon recommends that you issue a written advisory to all of your third-parties that are under active security risk management. The advisory serves several purposes

• It brings attention to the issue that might not otherwise exist. The more advisories vendors receive from customers, the more likely the vendor will properly handle the issue.
• It communicates your concern and expectations regarding handling the Spectre and Meltdown vulnerability.
• It establishes a basic level of assurance that all of your vendors have some thoughtful information and suggested actions related to dealing with the issue.

Engage directly with your highest risk third-parties

In cases where your highest risk vendors have not provided proactive remediation communications, engage with them in direct dialog to validate they are giving the issue proper attention within their internal environment and their cloud-hosted systems. Give top priority to those third-parties that pose the highest level of inherent risk to your organization and that are doing significant hosting with cloud providers.

Strategic Action Plan

Strategically, third-party use of cloud hosting providers requires enhanced risk governance. The security of your third-parties is dependent on the security of their hosting providers. This dependency is even greater in the new threat landscape of fallible CPU security. Current risk governance of use of external hosting providers is generally inadequate, resulting in hosting of sensitive systems in cloud architectures and with hosting providers that are not capable of providing high security assurance.

From analysis of RiskRecon’s IT profile data of 10,000 enterprises, we observe that companies often create indefensible hosting scenarios where their systems are unnecessarily fragmented across tens of hosting providers. They are often hosting sensitive systems in cloud architectures that are inherently insecure. For example, companies with over 100 Internet-facing systems host their systems across an average of 30 different hosting providers. While some of these providers are necessary, the majority seem to have no unique value that necessitates the relationship.

Establish standards for use of cloud hosting by third-parties

Update your standards governing use of cloud hosting providers. Consider including the following criteria:

1. External system hosting is reasonably consolidated such that security controls can be successfully deployed and operated across the providers.
2. A process is implemented to ensure that systems are hosted only at approved hosting providers.
3. External hosting providers are held to a sufficient standard of security performance and are periodically assessed for compliance.
4. Systems hosted with external providers are subject to the same security control standards as internally hosted systems.
5. Use of free and low-grade hosting where tenants share the same operating system and the same hardware is not allowed. These hosting arrangements inherently limit the ability to implement system security controls and provide insufficient separation between your workloads and the workloads of co-tenants, particularly in a post-Meltdown threat landscape.
   
   While not calling out specific companies, low-budget hosting providers offer services such as hosting of a single website for $2.99 per month. Just search for 'cheap web hosting' and you will get a slew of companies that you and your third-parties would be wise to avoid.

Include hosting provider standards in your third-party assessments

From your hosting provider standards, create third-party security assessment criteria. Evaluate your third-parties against the criteria and begin enforcing remediation. As this may be a new standard to some third-parties, consider providing advanced communication of the requirement.

Maintain awareness of your third-party portfolio exposure to hosting providers—your fourth-parties

Identify hosting providers where you have high concentrations of risk. For these entities, consider developing hosting-provider-specific standards and including them in your third-party evaluation. For example, if your third-party uses AWS for hosting-sensitive systems, then assess them against an AWS security standard.

Assess your third-party portfolio for the presence of undesirable hosting providers

Identify undesirable hosting providers used by your third-parties. Maintain a list of hosting providers considered undesirable. These may include providers that are in the category of ‘bullet proof hosting’, ‘free hosting’, or generally provide ‘low budget’ hosting.' Where used, tactically engage your third-parties to remediate the issue. Alternatively, address the issue during your periodic assessment of the third-party.

Conclusion

The Meltdown and Spectre vulnerabilities are significant security flaws that require security patching at the firmware, hypervisor, and operating-system layers. The issue is particularly important for public cloud environments where strangers intermingle processes on the same CPU, any one of which could compromise another tenant’s data. RiskRecon recommends tactically engaging vendors to help ensure awareness and to communicate your expectations regarding handling the issue. RiskRecon also recommends strengthening risk governance of third-party use of public cloud hosting. Hosting providers can no longer be viewed as simply providing farms of inherently secure hardware. That is not the case in a post-Meltdown world.