Unless you've been hiding under a rock for the past three weeks, you're probably familiar with CVE-2019-0708, also known as the "Bluekeep" vulnerability. This Remote Code Execution vulnerability in Remote Desktop Services (formerly known as Terminal Services) is particularly nasty as it it is pre-authentication and requires no user interaction. This makes it the perfect vulnerability to integrate into a self-propagating worm that would quickly spread around the world, just like WannaCry did in 2017. It also makes it an extremely interesting use case to illustrate how risk can change over time.
On May 14, 2019, we first heard of CVE-2019-0708 as part of Microsoft's patch Tuesday release. Prior to this point in time, we had no specific information that could have been used to create a risk for it. That said, worms have been a part of our Information Security vernacular since the "Creeper Worm" was designed to move between DEC PDP-10 mainframes back in 1971. While Creeper was experimental and caused no damage to the systems it spread to, it was the first in a long line of self-replicating worms, with later variants like ILOVEYOU, SQL Slammer, Conficker, Stuxnet, and WannaCry have caused immeasurable amounts of damage. What this means is that even though we didn't specifically know of the existence of Bluekeep prior to May 14, 2019, we probably should all be tracking a more generic risk around the spread of worms in our environments. Something like "Worm Spreads in Our Environment Potentially Affecting the Confidentiality, Integrity, and Availability of Critical Systems":
When it comes to calculating the risk score for something like this we have a lot of options: Classic, CVSS, DREAD, OWASP, Custom, and Contributing Risk are all supporting risk scoring methods in SimpleRisk. For something like this, I'd prefer to use CVSS scoring as it provides a decent breakdown between exploitability and impact with modifiers for temporal and environmental factors. The selected values can be a bit subjective, but here's what I used for this risk:
In the case of a worm, the attack vector would likely be network. There are a lot of variables involved so the complexity is high and by definition no authentication would be required. Since this risk is for a hypothetical worm, we have to guess a bit at the impact metrics. The reality is that a worm could impact our confidentiality, integrity, or availability so I selected a complete impact of all three. This gives us an impact subscore of 10.
The temporal score metrics is where things get especially interesting here. These are metrics that change over the course of time for this particular risk. Because we are unaware of any existing worm, we say that it is unproven that any exploit exists. The remediation level is unavailable because there cannot be a solution for something that doesn't exist yet and our confidence is unconfirmed because its purely hypothetical at this point.
You'll notice that CVSS also has environmental score metrics. These environmental metrics are based on the impacted environment of systems whereas the base score metrics above are generic for any environment. As an example, if this risk were to have a complete confidentiality impact but our environment has low or no confidentiality requirements, then our overall risk score can and should go down. I've just selected the maximum values for our hypothetical example.
Our risk score using the CVSS v2.0 calculator is 7.9:
With a risk score of 7.9, we now know how this risk stacks up against the other risks in our environment. It would be a good time for us to start planning out how we would mitigate it. Here's some initial thoughts on how to prepare your team for a worm like this:
- Hold a tabletop exercise (TTX) to ensure that your team is prepared to handle a worm outbreak in your environment and to run your playbook through its paces. You can read more about this in my blog post on What do Role Playing and Risk Management have in common?
- Build out a network segmentation strategy for your environment. Restrict the communication paths between these different networks and monitor for communication that falls outside of the traffic baselines.
- Invest in a next-generation anti-virus (NGAV) and endpoint detection and response (EDR) tool for your environment to prevent the execution of malware on your systems.
Now that we've tracked a risk and have worked through our mitigations, we are ready to handle the big show. Dateline May 14, 2019 and Microsoft has released their TechNet article describing CVE-2019-0708 and the recommended patching. Our first step should be to submit a new risk for this. A little-known feature of SimpleRisk is that you can enter a CVE number into the "External Reference ID" field and SimpleRisk will attempt to populate the subject, risk assessment, additional information, and scoring details for you:
We can see that CVE-2019-0708 is pretty bad here with a risk score of 10 out of 10:
This, of course, is without either the temporal or environmental modifiers so let's add those in. At this point, with a patch Tuesday release by Microsoft, I think we can safely say that there is some sort of proof-of-concept code out there. We also have an official fix and can say that our report confidence is confirmed. Where our environment is concerned, our collateral damage potential is likely limited to a loss of revenue or productivity. It's probably significant, but not catastrophic, so I selected Medium-High there. Most environments contain a fairly significant number of Windows systems and given that this particular exploit goes back to Windows XP, I think it's reasonable to say most enterprises would be a Medium or High target distribution. As for our CIA requirements, I again selected high for each of them. We now see that at the present time, with our environment taken into consideration, our risk score is a 6.5:
Our inherent risk score will likely stay near or at this level until a worm is eventually released. Our residual risk, however, will be changing as we put our mitigations in place. Now that we have more information about the kind of worm we are battling, we can look into some more specific mitigations. Here are some ideas on how to mitigate against CVE-2019-0708:
- Deploy the relevant Microsoft patches to all Windows systems in your environment.
- Deploy an active directory GPO to enable "Network Level Authentication" for your Windows systems to require a valid username and password before the connection negotiation starts.
- Block connectivity to port 3389 (RDP) in bound and outbound wherever possible. Monitor for increased network traffic to this port wherever we can.
Let's say we focus on mitigation #1 and are able to get it deployed to 90% of the Windows systems in our environment. We can handle this one of two different ways. First, we could plan a mitigation for this risk and set the mitigation percent to 90. This action will keep the inherent risk score at 6.5, but will set the residual risk score to 0.65:
Alternately, we could update the CVSS scoring for our inherent risk score and drop the collateral damage potential to Low-Medium and the target distribution down to Low (0-25%). This will have the affect of changing the inherent risk score to 2.1:
Personally, I'd prefer the former modification to the mitigation percent, but either of these is acceptable depending on your internal risk management practices. Here's what our mitigation looks like at this point:
The cool thing is that this entire time SimpleRisk has been tracking our changing risk posture. We can see this by expanding the Risk Scoring History chart:
Before we wrap up here, let's talk about what happens at some point in the future when this worm is no longer hypothetical and is actively spreading in the wild. At that point, we again will adjust our temporal score metrics to show the exploitability value of Widespread. That will bump the inherent risk score up a few notches to 6.9. Not enough to make a huge difference, but its important to keep our risk assessments as accurate as possible.
Now you've seen the evolution of a worm like Bluekeep in an enterprise environment and how our risk management function can capture those changes over time. Hopefully your organization already has processes in place to handle these events, but if not, everything that I've talked about is available in the free and open source SimpleRisk GRC software. You can download it and install it in your own environment or take it for a free 30 day trial in our SimpleRisk hosted environment.
