Published: 01 Nov 2013
"The future is already here -- it's just not very evenly distributed." -- William Gibson
In 2008 at the Black Hat security conference in Las Vegas, I presented the results of two years' worth of security research. "The Four Horsemen of the Virtualization [Security] Apocalypse" sought to educate the Black Hat audience about the past, present and future of the intersection of virtualization and security.
The presentation focused rather ruthlessly on the operational realities of how virtualized compute, storage and networking were fundamentally disrupting security; hence, the "Four Horsemen" rephrased succinctly:
- Consolidating physical appliance functions, and reconstituting them as a monolithic virtual appliance, will yield poorly performing solutions that are incapable of scale and difficult to manage.
- If virtual security solutions are not properly integrated with a virtual platform's security functionality and its orchestration systems, then performance, resiliency and scalability will suffer.
- Complex, highly available virtual security applications and network topologies will require fundamentally different architecture, technology and operational models to be effective.
- Virtualized security may initially steer spending away from hardware-centric capital expenditure to a more software-driven model, but the operational changes will require fundamental overhaul, and these soft costs often go unchecked.
Despite the promise of virtualization providing better security, early enthusiasm was dampened by the virtualization platform providers' general lack of IT security knowledge. These companies didn't fully grasp the operational models, trench-driven experience and operationally siloed barriers that networking experts, security practitioners and vendors had built up over 30+ years of deployments. Likewise, security practitioners had little to no experience with virtualization.
Why early efforts fell short
At the time I conducted my research, only a handful of traditional security vendors had begun to produce virtual versions of their physical appliances. These early solutions weren't well integrated into the "orchestration" workflow or the networked data paths of the virtualization platforms – nor were they "virtualization aware." Most solutions had little to no context about the environments or workloads, they were deployed to protect.
The same issues plagued traditional physical security that surrounded these virtualized deployments, but we made up for it by artificially corralling traffic through perimeter chokepoints and constructs, often steering traffic out of virtualized environments to physical appliances and back. While "containerized" and isolated, this approach made deploying and securing applications an inefficient and ineffective chore.
The majority of the newfangled virtual security solutions aimlessly tried to replicate -- in virtuo -- the deployment and operational constructs of non-virtualized environments. The agility and velocity at which virtual networks and workloads could be created, deployed or destroyed was not taken into consideration, however. Nor did these solutions factor in how the lack of visibility, and immaturity of the virtual networking constructs to which they were coupled, could render security controls blind.
These problems were further complicated by the failure to acknowledge the machinery and processes that security and compliance teams used to monitor, detect and mitigate threats. Security vendors' assumptions that security teams would be able to prescribe the solutions and integrate them into the process didn't help. Operational silos and a lack of virtualization skill sets made it unlikely, if not impossible. The ephemeral nature and outright mobility of workloads, coupled with the realization that the familiar physical architectures that formed perimeter models of security and trust were diffusing, meant that new models had to emerge.
Numerous startups worked to bring to market purpose-built virtualization-aware solutions, and to reframe the security discussion and operational models around security, in virtual constructs. Many of these efforts quickly ran aground, hampered by the poor integration touch points of platform providers that were attempting to offer modest security capabilities natively. Those who were previously responsible for "security" were no longer in control of how security policies were drafted, deployed and enforced in virtual environments.
The more things change ...
Five years later, there's been remarkably little progress in leveraging virtualization to improve our security posture overall. It's still, for the most part, a bolt-on affair rather than a service layer that is well-integrated into the infrastructure, or tied to workloads directly.
Players have come and gone, with many incumbents fundamentally disrupted by virtualized operational models. The virtualization/hypervisor platform players remain the lynchpin for enabling effective security. (I argued this would be the case in fondly remembered blog battles with the chief technology officers of popular virtualization platform providers, only to see my worst assessments for moving security forward in virtualized contexts come true.)
We have spent the last five years muddling our way through complex deployment scenarios, which uncomfortably -- and loosely -- integrate traditional security appliances. Combine that with the slow migration to a hybrid model with virtual appliances that suffer from many of the ills described by the "Four Horsemen" -- and the even slower progression and availability of platform-based security capabilities to enable seamless integration -- and it's not difficult to see why we have not seen large uplift by the security ecosystem.
It's interesting to note that the majority of virtualization security solutions -- an infrastructure-centric view of the world -- remain focused on replicating physical deployment and design patterns that utilize (virtual) networking-based appliance form factors and attempt to integrate with the hypervisor to become "virtualization aware." Recently, the impact of cloud computing and "software-defined everything" has caused some of the brittle constructs that were preventing the adoption of new security models to start to give way to more agile, automated and integrated security offerings.
Much of this is due to the virtualization platforms being disrupted, with the evolution from basic compute, network and server resource virtualization -- focused primarily on the hypervisor as the value-add -- to the automated, dynamic, agile and service-centric promises of cloud computing. This moves the focus, capability and the users that consume these solutions much further up the stack.
In the enterprise, the emergence of open source virtualization and orchestration platforms, such as OpenStack and Apache CloudStack, are driving the need to provide security across hypervisors beyond that of the dominant player, VMware.
Blast from the past: Who should secure virtual IT environments?
Chris Hoff and former Citrix CTO Simon Crosby, (now at Bromium) discuss whether security companies or virtualization vendors should be responsible for the security of virtual environments. Find out what's changed (if anything) in this two-part video interview: Part 1 and Part 2.
The realization that cloud will evolve to a hybrid model of interconnecting on-premises virtualized infrastructure and cloud-like programmatic application and service delivery platforms -- with resources in public cloud platforms -- exacerbates the need to elevate and accelerate our security architecture and operational practices.
While infrastructure is still very important to secure, this transition brings into focus the need to protect application workloads and the information they traffic in. This means focusing less on traditional policy enforcement criteria, like IP addresses and VLANs, and more on attaching policies to the workloads that are integrated fully into the orchestration systems of these platforms.
It takes a village ...
Frankly, the ability to provide risk-driven and well-adjusted security and compliance capabilities in virtualized environments has a lot to do with a reasoned understanding of the applications and information we need to protect. That entails appropriately factoring in threat models and business impact; adjusting architecture and approach; and aligning operational and technical implications. Virtualization and cloud are simply operational and deployment variables which factor into these equations.
There's no magic here. There's no silver bullet, just a lot of silver buckshot.
When I counsel IT security managers about what to think about with respect to "best practices" in virtualized environments, I highlight the complex interplay between the different types of providers that contribute to the menagerie of solutions:
- Virtualization platform (née hypervisor) providers,
- Cloud platform providers,
- Orchestration platform providers,
- Networking platform providers (including software-defined networking),
- Security industry ecosystem providers, and
- Governance, risk and compliance providers.
What many people astutely point out is that, in many cases, items 1-4 are offered as an integrated set of capabilities from some platform providers natively. And, like most things in IT, security in the virtualized realm involves tradeoffs in these bundled offers.
Multiple choices and vendor strategies often means complexity with potentially better coverage, while monoculture and a lack of diversity offers tighter integration and fewer moving parts. Depending upon the maturity of the security and compliance organizations -- and how well integrated they are with the rest of IT -- the tension between these elements can be empowering or ultimately quite destructive and inefficient.
The short answer is that you need security as a pervasive capability -- a service -- sprinkled throughout these components and tied together in a well-defined and abstracted consumption model.
The only thing that is constant is change ...
Security operations teams and auditors must deal with differences in approach, models, languages, capabilities and policies as they explore their choice of solutions. In today's world of innovative and advanced adversaries; new classes of threat actors; and swift adoption of new compute models, platforms, languages and application architecture; the choice of which path to take is often not an easy one.
Existing environments must balance the technology and operational models of today against disruption. This means that for a period of time -- and across multiple refreshes -- a hybrid model of security will persist, surfacing inefficiency and some of the same complications that we know now.
Compute virtualization has delivered us to a point where the developers, system administrators, security and compliance teams define the atomic unit of an enterprise virtualized datacenter as the virtual machine (VM). This has become our new perimeter.
Just as we finally evolve to embrace this new perimeter, we are disrupted by the emergence of automated and self-service cloud computing. These capabilities move the abstraction above VM containers and focus on programmatic platforms and interfaces that force us to reconcile an application- or workload-centric view of security.
As enlightened IT organizations make the turn and embrace a platform-centric and programmatic view of the enterprise -- leveraging the agile premise of continuous delivery and deployment of applications versus that of pure infrastructure -- the cultural and operational notion of DevOps makes us dig even deeper and re-examine our approach to security.
Security and compliance teams need training and investment in skill sets that are relevant to virtualization, cloud, Platform as a Service and application-centric security, and they need it now. As security leaders, if you don't make this turn and work to get ahead of the "software-defined everything" world, your relevance -- and that of your teams -- will be in jeopardy.
To understand how to address virtualization and security strategy, it's important to learn what virtualization platform providers can offer you and, based upon that assessment, what must be supplemented by the security ecosystem to fill the gaps and remain compliant.
Nobody ever said this was going to be easy ...
For more on virtualization security
About the author:
Chris Hoff is currently vice president of strategy and planning at Juniper Networks after serving as the company's chief security architect. He has held similar roles at Cisco, Unisys Corp. and Crossbeam Systems. Hoff is a founding member and technical advisor to the Cloud Security Alliance, founder of the CloudAudit project and HacKid conference and writes the Rational Survivability blog. Follow him on Twitter @Beaker.