Understanding Spectre and Meltdown
On January 3rd Microsoft released a bunch of security updates around a hardware vulnerability found in the Intel chipset. Within hours of the patch coming out news outlets and more had exploded with information about the patch and the challenge was weeding through all of it to answer two important questions.
- What do I need to do to make my organization secure
- What performance degradation might I experience and what applications will this impact?
To attempt to answer these questions and to help absorb all of the information out there around patches I’ve broken down my thoughts into several parts.
What is the vulnerability?
The first thing we need to firmly understand is exactly what the vulnerability is. Spectre and Meltdown are two separate methods to exploit the same flaw. That flaw one could almost go so far as to call it a ‘feature’ as it was initially designed to speed up computer processing. Think of this as your boss asking you to prepare certain materials for a meeting. You don’t know for sure if you’re going to need all of these materials and based on what happens in the meeting you might never use them but because of the possibility of needing them, you prepare ahead of time. In the event of an attack of this, the idea would be that an attacker would know that you specifically prepared something for a specific meeting and would find your presentation and steal that information before you either presented it in a secured room or threw it away. This is then exploited by someone knowing that you are preparing for a specific meeting and they break into your house to steal all of your notes before they are presented or secured. Installing the patch, and the BIOS fixes don’t fix the root issue of you having unsecured data in your home that can be stolen, but it does put a police detail at your front door to help prevent the break-in. Please note this is a drastic oversimplification and if you want to read about the real in-depth details you can do so here:
There are several other other methods but the core concept remains the same someone knows exactly where some information is and finds a way to steal it before it is used and deleted/secured.
How do I get secure?
This is the complicated question and unfortunately, there isn’t a 100% secure answer at this time. Yes, there is a Microsoft patch. Yes, there are firmware and Bios Updates, however, the unfortunate reality of all of these fixes is that they are software solutions to a hardware problem. Until the code itself that allows the behavior is resolved these are just preventative measures.
Now let’s talk about applying the patches because there is a ton and I mean a ton of information out there around if you should or shouldn’t apply the patches how and when they apply and what all you should or shouldn’t apply. If I talked about all of the patches I would need a ton more words and you would lose interest before I was done so I’m going to focus on Windows Operating System pieces and maybe see if I can get Maurice to do a follow-up discussion on BIOS.
So applying patches. The first thing you need to know is that Microsoft worked with vendors prior to releasing the patch and instilled a kind of ‘Fail-safe’ in the package. This fail-safe prevents your workstation from telling WSUS/SCCM/Windows Updates (etc) that the patch is applicable unless a registry key exists and has been set by your Anti-Virus provider. I cannot stress this enough, do not create this key on your own. Doing so risks blue-screen events and other unfortunate terrible things. If you are missing the registry key you should contact your Anti-Virus provider as soon as possible because the missing key will prevent this and future cumulative rollups from installing on your computer.
However, this is where desktop clients and server clients diverge. When you install the patch on a desktop or workstation operating system, the mitigation steps are enabled by default and there is an option to disable the CPU protections offered by the patch using registry key modifiers. This is the polar opposite of the behavior on a server. Instead, once the patch is successfully installed the server is not in a ‘secure’ state until after the required registry keys have been enabled. This was done by design to allow you to assess performance and flip the mitigation factors as needed. Furthermore, if the server is a Hyper-V host there is an additional registry key needed to enable the protection as it relates to the guests. You can find details about this here:
OK, you’ve confused me tell me what I actually need to do.
First, don’t panic. This is an important step you need to analyze the risk and determine what is an achievable goal for your organization within the next thirty days my recommendation would be to at least plan and carry out the following within the next thirty days.
- Validate your Anti-Virus vendor is compatible with the Microsoft Security updates by checking for the required registry key (You can find the requirement in this KB as an example
- Develop a configuration Item baseline (or use one that has been developed by Microsoft or the Configuration Manager Community check back later I might even make one)
- Leverage this baseline to check for if a desktop OR a server has the CPU mitigations enabled.
- Develop an action plan and a risk form to disable the CPU vulnerability if needed on desktops.
- Develop a plan to enable the CPU mitigations for servers across your enterprise as the patch is deployed and tested.
- Test the patch.
- Test the patch
- Pilot the patch
- Deploy the Patch to production in a slow controlled manner.
- Remediate any desktops that suffer performance hits and sign off on risk acceptance with registry key changes.
- Slowly Implement registry key changes to server and monitor performance to begin securing servers from the CPU vulnerability.
- Leverage your Configuration Manager Baseline and CI’s to continuously report and validate that devices are patched and the CPU vulnerability is enabled and that any device where the CPU vulnerability is disabled are accounted for.
The next part of the plan, of course, is to account for firmware and bios changes but that should be handled as a separate effort as its still unknown how and what exactly the firmware/BIOS/Intel Drivers will help address the vulnerability.
Hopefully, this helps gives you a general framework to better understand what this vulnerability actually is and how to start planning towards remediating the vulnerability.