Although security practitioners don’t like to admit it, segmentation attacks can and do happen in the cloud, and building in segmentation defense can be critical to the security of your cloud environment.

Over the past few years, for example, we’ve seen Rowhammer attacks in the cloud, specifically those leveraging the Flip Feng Shui technique to manipulate dynamic random-access memory (DRAM) from address spaces across a virtualization boundary. We’ve seen Cross-VM Address-Space Layout Introspection (CAIN), which can allow machines on the same hypervisor to infer the memory layout of other virtual machines (VMs) on the same host through a side-channel attack, potentially undermining the segmentation model. Even beyond hardware-aware techniques such as these, software vulnerabilities that impact the resiliency of the segmentation boundary can occur. This is true whether you’re using VMWare (e.g., CVE-2017-4903), Xen (e.g., CVE-2017-8905), Hyper-V (e.g., CVE-2017-0109) or any other virtualization platform.

The point is that segmentation attacks exist. They can impact cloud environments and are potentially devastating in a multitenant situation. Security professionals need to be alert to this risk because it can directly inform the strategies they employ to field their cloud applications.

Why Architect Segmentation Defense?

In light of this, the question is whether it is worth the time investment to architecturally account for possible weaknesses in the segmentation boundary when applications are to be fielded in a multitenant environment. In other words, when designing for the cloud, particularly infrastructure-as-a-service (IaaS) and container-oriented platform-as-a-service (PaaS), security teams must determine whether specifically targeting technical strategies to bolster segmentation adds value or constitutes an unnecessary time sink.

There are certainly situations where this strategy is, without question, advantageous, such as when unauthorized access to high-risk or business-critical applications could have catastrophic consequences for the enterprise. Beyond that, though, it’s fair to question whether a more general application of architectural techniques to enforce segmentation would better serve the organization. After all, these attacks don’t surface every day, and when they do, they tend to be fixed relatively quickly because they impact such a large segment of the community.

Having said that, there are a few reasons why these techniques are valuable. First, when they are built in from the outset, they provide added peace of mind. This is especially true when active attacks are occurring in the wild or when new vulnerabilities are discovered. In other words, there can be value in sleeping soundly when others are in hair-on-fire mode. Second, keep in mind that segmentation attacks are often known and executed before details of the issue are released to the public.

Despite these concerns, specifically thinking through and architecting in protective measures can assist with a layered defense approach. Seasoned veterans in the security world might remember the defense-in-depth approach, while more recent entrants to the profession are perhaps more familiar with the strategy of disrupting an adversary’s campaign — i.e., interrupting the kill chain. Either way, implementing such defenses is a prudent and effective strategy. Even in a more general context, efforts to bolster architectural segmentation can have value, particularly when they can be implemented at little or no additional cost.

Designing for Segmentation Failure

In terms of the actual mechanics of implementing a strategy like this, there are a few general approaches to consider. It goes without saying that every application is different based on organizational need and particular business requirements. Therefore, one of the most important steps is to evaluate segmentation issues during the design phase.

If you are already doing a systematic, formal threat modeling exercise for an application, this entails analyzing the segmentation model — and possible attack points should the segmentation model be compromised. You might elect to employ secure communication or remote execution of representational state transfer (RESTful) services, for example. Your provider may support this natively and transparently, or it may require specific action on your part to enable. Either way, it’s well worth your time to think it through in advance and ensure that functionality is employed.

There are also approaches to consider at the engineering level. First, it’s important to understand how the application works and what security features are available to you from your cloud provider. Consider a situation in which an application you’re fielding employs cryptography and cryptographic keys. In the Flip Feng Shui attack, for example, cryptographic keys were a particularly fruitful target for attackers. Since many cloud providers offer a hardware security module (HSM) to store cryptographic keys, architecting this functionality into the application design adds a potential vehicle for mitigation at relatively little additional cost.

In this scenario, you combine your knowledge of the application design (the fact that it uses cryptographic keys) with your knowledge of the functionality provided by your service provider (the fact that HSM functionality is a turnkey option) to realize a solution that enforces segmentation even if the environment itself proves untrustworthy. You might also consider the enablement of a more platform-agnostic security mechanism in an environment that supports it. The key here is to understand the specific features and services offered by the cloud provider and apply that to your team’s design-level knowledge of the application itself.

Architecting these strategies in can have a tremendous benefit. While the specific engineering-level considerations will vary by platform — and, of course, by application — the systematic analysis and preemptive design of architectures that support the behavior you want, even in the event of an attack, is both valuable and achievable. Putting it into practice simply requires you to think it through ahead of time, design for it and understand the ins and outs of the particular platform into which you intend to field the application.