everythingpossible - Fotolia
The cloud is a powerful and transformative tool, but it does have some pitfalls. One of those pitfalls occurs when cloud users make incorrect assumptions about the underlying technology and design an implementation strategy around those assumptions.
Cloud services deliberately abstract from the customer much of the underlying technology substrate, like network infrastructure and hardware. As such, anything that happens below that abstraction layer typically doesn't factor into the security model.
This can be dangerous for security professionals, though, especially when the assumptions about the cloud security properties that are cornerstones of an organization's security model prove to be untrue.
Consider segmentation attacks, for example. In these attacks, one virtual image interacts directly with another on the same hypervisor or otherwise subverts the expected workload boundaries. Cloud customers generally build their security models around the idea that segmentation attacks can't or won't happen and deploy them accordingly. Therefore, when a segmentation attack arises, workloads are put at risk because they're encountering an exception condition that the original security model didn't account for. This remains true until the underlying issue is resolved.
When these situations arise, it's paramount for security professionals to pay attention. One recent incident is the NetSpectre vulnerability disclosure. NetSpectre is another example of speculative execution via side-channel attacks. While this particular issue may be unlikely to impact cloud workloads, it is still a useful lesson for security practitioners on how to design security protections that stay relevant regardless of changes to the underlying model.
What is NetSpectre?
Much like the Spectre and Meltdown attacks that came to light in early 2018, NetSpectre exploits the speculative execution features in modern microprocessors that are designed to read data through an out-of-band channel.
With speculative execution, a computer precomputes operations while waiting for operations that take longer to complete. If a decision must be made, the computer will attempt to anticipate the outcome of the decision based on what it has seen in the past. If it guesses wrong, it unwinds to the state it was in before it made the bad guess, leaving the performance to idle. But, if the computer guesses right, everything goes faster.
However, as researchers pointed out, sometimes information can be leaked via a side-channel. This is when the attacker can measure differences that occur as a result of changes in the machine's state. For example, if an attacker wants to know if data is cached, he might measure the time it takes to perform an access request; accessing memory data that is in the cache happens faster than data that is not.
This is a simplified explanation, but attackers can use these side-channel attacks to read information across boundaries.
In previous speculative execution attacks, the boundaries were on the same machine -- e.g., one application reading information from another application. The NetSpectre vulnerability extends this type of exploit to the network. Now, by measuring the difference in completion time for network requests, the attacker can discern arbitrary blocks of data, albeit quite slowly, at a rate of about 15 bits per hour.
Why cloud customers should care
While this is a serious issue, you should note two things. First, there haven't been any exploits of this technique as of this writing.
Second, there are already mitigations in place for these types of attacks, including those that were developed in response to the original Spectre and Meltdown vulnerabilities. Therefore, the likelihood of an organization being affected by this particular issue isn't high. However, this does illustrate that cloud customers don't control the underlying implementation in a cloud deployment, so accounting for issues outside of the organization's control in its security model is prudent.
One way to account for these issues with your security model is by using a systematic and well thought out threat model for cloud deployments that includes the systematic examination and analysis of segmentation attacks -- both those that pertain to hypervisor segmentation, as well as those that are accessible via the network -- and other attacks that might be germane to your particular workloads and deployment circumstances. If an organization is not already employing threat modeling as an analysis strategy and support technique for cloud deployments, NetSpectre could be a useful proof point as to why doing so is a good idea.
For situations in which a threat model highlights potential weaknesses to segmentation attacks in workloads, one option is to build a secret protection strategy. There are a few ways to do this. One might be to employ a hardware security model (HSM) for encryption keys if the cloud provider supports that -- such as AWS CloudHSM or Azure Key Vault.
Likewise, third-party tools that focus on secret protection, like CyberArk or kee.sh, can be useful. This way, even if the segmentation is subverted, the workload's secret information remains protected. This strategy, when extended to application secrets or situations like Secure Socket Shell keys, has value both in the normative case, as well as in situations in which a segmentation attack occurs.
If neither option is available, the security team can also incorporate a secret protection strategy into the organization's application development efforts to protect places where secrets are used.
Regardless of the approach an organization takes, awareness of the issue and the incorporation of these situations into threat analysis is a good idea.