Woody - Fotolia
VM isolation technique considerations for enterprises
VM isolation techniques are good strategies to prevent infections from spreading to the entire cloud environment. Ed Moyle explains what enterprises need to know about isolation.
Joseph Lister is known today as the father of modern surgery due to his pioneering work in antiseptic surgical methods. In 1865, Lister began the practice of applying phenol, or carbolic acid, to wounds, instruments, and to surgeon's hands and garments.
One of the more interesting things about Lister's story is the degree to which the medical establishment was unprepared for the changes Lister's techniques required. For example, surgical instruments at the time typically incorporated porous materials, like wood, that could trap disease; likewise, garments -- including gloves -- were often reused from operation to operation. Lister's methods, while revolutionary and leading directly to better outcomes for patients, were fairly unforgiving of the status quo; getting the full benefit required legwork, retrofitting and cultural repositioning on the part of those seeking to implement them.
The rise of Lister's methods makes for an interesting analogy to recent discussions in the security world about the use of virtual machine (VM) isolation techniques, like segmentation and sandboxing, to control risk in the cloud. For example, in his keynote address at Black Hat 2016, White Ops' co-founder Dan Kaminsky outlined a microsandboxing technology, called Autoclave, which seeks to limit the ability for applications to infect or be infected by systems or application components that run outside of a protected, isolated space. The gist of the technique is to create an isolated, controlled environment within which critical, security-relevant tasks could be carried out.
Additionally, VM isolation strategies that leverage containerization platforms like Docker or Rocket are more frequently employed for cloud security purposes, in addition to operational benefits. Because containerization technology can minimize manual configuration changes -- including one-off changes -- containers can be used as a way to minimize configuration drift from a known-good, reliable substrate upon which critical applications run; it can also be used as a strategy to streamline patching and to introduce additional segmentation in a running application.
Lastly, software-defined perimeter (SDP) and microsegmentation have emerged as options to help introduce VM isolation in a cloud context. SDP allows for the creation of a "black cloud," which is a virtual perimeterized network that can extend to a cloud environment, such as an infrastructure as a service. This allows potential extension of an organization's internal network into the cloud environment. Microsegmentation at the network level allows an organization to assign a security policy to a given workload and have confidence the policy will be enforced anywhere in the ecosystem -- this can include connectivity and allow security managers to govern security tool operation, such as intrusion detection systems or malware and vulnerability scanning.
The feasibility of VM isolation for enterprises
These approaches to VM isolation are not equivalent by any means; they are all different in scope and implementation. That said, they have a few things in common: First, they promise to help mitigate certain types of threats that arise in a cloud context. Second, in much the same way Lister's methods required legwork, so do these approaches. Meaning, it's not as simple as flipping a switch to move from a traditional, nonisolated approach to these VM isolation models that enforce cloud segmentation. For example, Kaminsky noted that none of the major vendors currently support Autoclave.
We've seen only slow and limited adoption of SDP over the years, and containers are often deployed because of development and data center benefits than they are for security purposes. So, are they a very real architectural option for organizations seeking to leverage VM isolation as a security measure? Absolutely. But, it's something an organization should only do if it is prepared and takes a few steps in advance to do the legwork.
With that in mind, what should organizations do if they wish to explore whether these approaches are right for them? What is required of an organization seeking to employ one of these strategies?
First and foremost, it is important to recognize any VM isolation strategy presupposes a certain level of sophistication on the part of the organization employing that strategy. For example, you moat likely know what you have fielded, what system components and applications do, and how they interact with each other. This is true regardless of the particular VM isolation or segmentation strategy that you decide upon -- it extends both to the applications involved, as well as the substrate upon which those applications run. Organizations can't, for example, randomly isolate components of a multi-tiered application without understanding how those components communicate and expect that application to function appropriately out of the gate.
It's important to understand the workings of the applications involved -- how they communicate, their normative operation and what the critical portions are that you want to isolate. If this is information that you don't currently have, or if there are significant gaps in your understanding, this is a situation to remedy before going down this road.
Likewise, implementing VM isolation strategies implies the organization understands the risk profile and landscape of the workloads, applications and systems to which it is looking to extend isolation techniques. There may be additional complexity associated with isolation in a situation where you're dealing with nonsensitive applications or systems that are otherwise less at risk than others. Meaning, if you don't have a solid understanding of the risks and threats those applications might be subject to, it becomes harder to make decisions about what needs to be isolated from what.
Lastly, it is important to commit to VM isolation for the long haul. Keep in mind that environments aren't static; they change regularly in response to new usage patterns, changes and updates in how they're used, business demands, architectural changes and for numerous other reasons. Spending time and energy in creating a VM isolation model now only to have it drift to an unknown, uncontrolled state later down the road is time not very well-spent.
