The Goldilocks Zone: Six Characteristics for Successful Cloud Workload Protection

Navindra Yadav is a Cisco Fellow and Founder of Cisco Tetration.

Malware is becoming more vicious and difficult to combat.  We now face everything from network-based ransomware worms to devastating wiper malware. At the same time, adversaries are getting more adept at evading traditional sandboxing. This has resulted in broad breaches, such as Nyetya, which was installed on more than one million computers.

Most successful attacks come from exploiting vulnerabilities in the application and software stack – not from an attack in the network layer (TCP/IP). So even if you generate and implement a perfect whitelist network micro-segmentation policy, you’re still vulnerable. 

This makes security top of mind for CEOs and CIOs worldwide, but how do you protect your workloads?

The Australian Signals Directorate (ASD) published a set of comprehensive whitepapers based on their analysis of attacks across a wide set of workloads.  They mapped back to discover what would have prevented each attack and described three mitigation steps to prevent a breach:

Sounds simple, right? Yet following these guidelines is surprisingly difficult in practice. For example, whitelisting applications– their allowed system calls, interactions and application communication patterns– is a non-trivial problem for most IT departments.

NASA coined the term “Goldilocks Zone” to describe the critical factors necessary for life to evolve on planet Earth. Similarly, we can describe six key characteristics for a "Goldilocks Zone" to protect data center and cloud workloads from cyber intrusions.

Independence from how the workload is instantiated: The solution must be able to span containers at one end of the spectrum, and mainframes at the other. There must be a common policy enforcement and workload protection framework. For example, a PDP mainframe and a container have processes. The same concepts apply to both. The solution must cover mainframes, bare metal workloads, Virtual Machines, and containers, working across a variety of operating systems.

This makes life simpler. You should only have to worry about how to apply a policy to isolate workloads with a highly exploitable software package from high risk workloads. You shouldn’t have to worry about where that workload resides (cloud or on premise data center), what operating system it’s running, or whether it’s a container or a VM. The solution should be extensible to handle function as a service – something that’s on the horizon, but not in the mainstream yet.

Workload location independence – from public or private clouds to data centers: The solution must be able to handle workloads running both in on-premise data centers and in any public cloud. This enables you to simply push policies and actions without having to worry about where the workload resides.

Federation and scale: Every system has scale limits. A highly desirable solution, which could even be argued to be a mandatory requirement at scale, is to federate with other systems. Federation enables you to have multiple workload protection zones for availability and robustness, yet enable the zones to share information with each other.

Integrate with an ecosystem:The solution must be able to talk to other external systems, including:

Encourage multiple points of enforcement: Security is always best with layers of defense. Having just one enforcement point is risky – the more points of enforcement, the harder the target is to attack.

Visibility across multiple planes and domain boundaries: The solution must have visibility and an enforcement reach across multiple planes. It must be able to watch the network plane, storage plane, compute plane and user plane. It must be able to view things inside the workload (VM/container/bare metal) and also be able to see outside the workload to correlate and make sense across these boundaries.

For example, watching multiple domains helps when there is a kernel rootkit and the only presence of visibility is inside the VM. Chances are if the rootkit is well written, it will hide its signatures like the CnC channel from the agent watching the workload. However, if the infrastructure sees the flows and attributes them to the workload, the differential analysis can clearly trigger suspicion.

In a follow-up article, I’ll cover the basic building blocks of a robust cloud workload protection solution.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating.