Coming June 11th

The Ins and Outs of Cloud Workload Protection

Cloud applications are the vehicles for foundational business operations. Employees would be hard-pressed to function without access to and availability from these applications. As the balance is quickly shifting from primarily on-premises to cloud-native, cloud workload protection is becoming a top priority for security teams.

Cloud security is a sticky wicket. On the one hand, many cloud service providers (especially larger ones) have built-in security functionality beyond what an individual organization can accomplish. On the other hand, cloud providers are responsible for security of the cloud, not security of what’s resident in the cloud. Applications and workloads definitively are in the cloud.

While major cloud providers are bulking up security offerings, these capabilities continue to be largely focused on the environment instead of the data. Keeping the infrastructure secure is important, of course, but fundamentally it’s data that cyber adversaries are targeting.

Microsegmentation limitations

Microsegmentation has become a familiar strategy to create “secure zones” within a cloud network. Built on the traditional network security concept of implementing a firewall (or next-generation firewall) to slice the network into small chunks, microsegmentation relies on network constructs like IP addresses, ports, and protocols as the control gateway. While the concept is sound, the practicality of address-based microsegmentation is diminished in a cloud environment for two reasons.

Download a free copy of Zero Trust Security for Dummies today!

First, address-based controls are susceptible to change, especially in a cloud environment. Adversaires use this fact to hide in network traffic and move laterally, often remaining undetected for long periods of time. The relative ease with which IP addresses can be spoofed also make address-based controls less effective. Therefore, creating smaller and smaller sections of the network using address information doesn’t make the network more secure. It does, however, make it more complex to manage. The ephemeral nature of addresses in the cloud means that security teams are required to build growing numbers of rules to compensate for continual change.

The second reason address-based microsegmentation is impractical is because it persists in relying on distant perimeters as the control mechanism. True, microsegmentation brings the perimeter closer to the assets, but the protection is not of the asset itself, it’s of the environment in which the asset communicates. Tighter “fencing” is better than relying on edge-based perimeter protection, but it’s not the best we can do today.

More and more critical corporate data and applications are in the cloud. We know that many cloud providers have decent security for the environment (as stated above, often more than an individual company can provide for its own environment). Therefore, it doesn’t make sense to layer on additional protection where it’s already sufficient. Instead, security practitioners should be looking at cloud workload protection, that is, securing the data assets themselves — putting the data first, since that’s what adversaries are after. A data-centric cloud security plan—taking an inside-out approach—means that when an attacker exploits the perimeter, the user, or other easily-hacked control, the data or application remains protected.

SDP limitations

The software-defined perimeter (SDP) is another methodology considered viable for protecting data in a cloud environment. SDP has caught on primarily because security practitioners know the challenges of deploying a hardware-based control (i.e., firewalls, microsegmentation) where no physical boundary exists (i.e., in the cloud). In SDP, a software controller is the security gateway that determines if a client is allowed to communicate with and access applications inside the network perimeter. And because it’s zero trust, software, applications, and users must be verified based on “identity” before being allowed to connect.

As with microsegmentation, SDP models rely on addresses and ports as the “identity” of the communicating software and applications; all of the same address-based vulnerability problems that exist with firewalls and microsegmentation exist in the SDP model. As mentioned previously, IP addresses in the cloud are ever-changing, making results unreliable. Further, when a control decision depends on communication between hosts (client to gateway, client to server, server to server, etc.), contextual information about workloads, themselves, is absent if the system is only inspecting packets. In other words, it’s near-impossible for SDP controls to decipher when malware has been introduced or if an attacker is piggybacking on approved controls, even with zero trust verification added.

Inside-out without network constructs

Protecting cloud workloads requires organizations to put data first — placing security controls as close to valuable assets as is possible. Beyond an inside-out approach, however, is the need to abstract controls away from network constructs. It’s too risky to try to secure applications with controls that rely on network constructs that either don’t exist or are unreliable in a cloud context. Additionally, traditional security tools don’t supply context on cloud workloads, which means that organizations are unable to see what applications are being deployed in the cloud, how they’re being deployed, and by who. Since cloud applications are the backbone of business operations today, this contextual information is imperative.

Creating cryptographic identities for applications allows security teams to place context around how apps are being deployed and accessed. In this software-centric, environment-agnostic world, network constructs can change and protection remains with the asset. When an adversary enters the environment through a lax perimeter control or phished credentials, the asset is still wrapped in policies tied to its identity attributes. Whatever happens on the outside, the inside stays protected. And that’s how organizations can meet the demands of a cloud-centric business while retaining security control over the data.


Subscribe to our newsletter:

Katherine Teitler, Director of Content

Written by Katherine Teitler, Director of Content

Katherine Teitler leads content strategy and development for Edgewise Networks. In her role as Director of Content she is a storyteller; a translator; and liaison between sales, marketing, and the customer. Prior to Edgewise, Katherine was the Director of Content for MISTI, a global training and events company, where she was in charge of digital content strategy and programming for the company's cybersecurity events, and the Director of Content at IANS, where she built, managed, and contributed to the company's research portal.