Intel revealed a new speculative execution vulnerability named ZombieLoad and it is yet another processor execution bug in the style of Spectre and Meltdown that were made public in January of 2018.
These vulnerabilities are really features in that they allow faster processing speeds by allowing the processor to access data across trust boundaries by determining where the likely next data read will be needed (hence being called speculative execution or “microarchitectural data sampling”).
Here’s the bad news: the same processor execution features result in significant gains in speed. Reports are showing that patching ZombieLoad (turning off these features) will result in up to 40% reduction in processor speeds. This vulnerability presents quite a conundrum for information security professionals: do we sacrifice availability for confidentiality?
Jack Freund is co-author with Jack Jones of the FAIR book, Measuring and Managing Information Risk: A FAIR Approach
Many organizations last year had to build board reporting that spoke about the progress they were making in patching and articulate the risk associated with the Spectre and Meltdown flaws. Invariably, those organizations will have to do the same this time but with the massive performance hit, they will have to answer a key question: What’s the risk?
Problems like these are custom-made for FAIR risk analysis. FAIR enables analysts to draw a fine line between competing concerns like: Should our website process requests slower for the sake of increased confidentiality of the data? In an ideal world, we want both absolute availability and confidentiality (and let’s throw integrity in there too while we are making a Christmas list), but in the real world we frequently make tradeoffs to accomplish our goals.
FAIR Quantitative Cyber Risk Analysis for ZombieLoad
And that’s where this assessment should start: What are the primary goals of you organization and how does the computing platforms you utilize (especially those affected by ZombieLoad) support those goals?
Assessing the risk associated with this new vulnerability requires that we analyze the path of attack. Intel has indicated that practical exploitation of this vulnerability in the wild requires a “highly complex” process and even if successful, there is no way to target which data is exfiltrated.
They further caution against turning off Hyper-Threading (which minimizes the performance impact). Speculation in the press is that this exploit will allow for attacker to break out of the hypervisors and access others’ servers in cloud environments.
As a result, for this risk analysis, you will need to scope 4 distinct scenarios:
Number 4 above is an important option, as doing nothing is always a choice, and many firms will have a delay in patching as they wait for the next patch window and patch systems in waves. That loss exposure will diminish as the attack window closes (systems get patched).
It may even be helpful to group your systems by risk and apply the above loss scenarios to them that way: Perhaps you prioritize externally facing, cloud-hosted systems first, then internal cloud systems, etc. You may also find it helpful to expand the breakdown by slicing them finer using business priorities, data exposure, and other service-level metrics (e.g. 1-4 above for systems supporting each of the critical business solutions your organization offers).
In the end, the resultant analyses will give you a view into what loss exposure looks like for this latest speculative execution vulnerability and allow you to confidently answer board and executive inquiries about how worried they should be and what needs to be done.
Overall, as exploitation is difficult and the performance hit so great, these series of analyses should show that slow, measured, risk-based approach to patching this vulnerability is prudent. When you have zombies at your door, FAIR gives you the support you need for a rational plan of action.
Join Jack Freund and more FAIR experts at the 2019 FAIR Conference, September 24-25, National Harbor, MD, near Washington, DC.