Independence from security hardware
This is an extension of the everything is software model inherent within virtualization. This creates several operational advantages:
- Simplifies data center resiliency and failover
- Reduces upgrade costs
- Enables "designed-in" security across data center fabric
- Scaling enhanced due to elimination of architectural constraints
- Hardware refresh cycle and technology advance is accelerated due to shortened engineering cycle
- CPU resource pool remains uniform
Faithful reproduction of the physical network security model in the virtual space, including security for both physical and virtual workloads
There's a lot of room for argument here, mainly because we don't necessarily have broad agreement on the physical network security model. I'll assert the following requirements:
- Defense in depth
- Segmentation of data
- Access control
- Separation of duties
- Deliver at least the top five controls from the SANS top-20:
- Inventory of Authorized and Unauthorized Devices
- Inventory of Authorized and Unauthorized Software
- Secure Configurations for Hardware and Software
- Continuous Vulnerability Assessment and Remediation
- Malware Defenses
Additionally, these must all be applied to the network, software objects, management tools, and APIs within the virtualized data center
Follow the operational model of compute virtualization
Security Virtualization must enable scaling, elasticity, mobility, and seamless disaster recovery. It also requires the conversion of security tools into software objects and the creation of new tools and capabilities for deployment, automation, and recovery of security capabilities. These are obvious capabilities for virtualization architects but rather new for security. Until recently we could not have a conversation about the auto-deployment or orchestration of security tools, now there are COTS products ready to do this. This operational model challenges the "security way" of doing things and impacts the culture of security within IT. This requires the transition of security professionals into new operational roles that are more flexible than existing silos within typical large IT organizations.
Compatible with any hypervisor platform
Security virtualization must be platform independent and ultimately it must be capable of protecting virtualized workloads in any data center. While it's not clear how many platforms will be in common use, I assert that there will be at least four:
- RHEV (KVM)
- Mobile (ultimately there will be more than one here)
Therefore as workloads are established on multiple platforms in multiple locations by any given entity, security virtualization must support a single security policy model across these platforms.
Logical isolation of virtualized workloads, audit and security for control plane elements
At the hypervisor layer or above, everything is software. Logical isolation, rather than some form of physical segmentation, enables diverse workloads of differing sensitivity to run anywhere. Workloads will then run most efficiently when allowed to be run within common resource pools for CPU, Memory, Storage, and Networking. For example, fire walling must control access at the virtual NIC and be configured by policies that are not required to identify layer 3 or 4 attributes. This allows network segmentation of systems that share a single software switch, VLAN, or Host. In addition to isolation, security virtualization must also audit and protect the management objects, tools, and APIs that are utilized to provision, modify, or delete workloads, objects, and resources. In the ideal case, logical isolation enables multi-compartment zoning of workloads with the requisite capabilities for cross-domain security in both private or public clouds. This requires sophisticated capabilities for delineating a zone of trust that both isolates systems and applies common security policies within each specific trust zone, even when this zone spans multiple data centers.
Cloud performance and scale
Large-scale compute clouds are composed of thousands to millions of hypervisor instances. Security virtualization must enable resilient and protected operations at this scale. Security management tools, incident response, control automation, and event analysis must all be modified. This will require new security management architectures, analytics, and closed-loop controls that operate across millions of security objects in multiple locations. Additionally, cloud performance is not just IOPS or CPU cycles, it is also the capability to provision, modify, and decommissions hundreds or more systems with minutes or seconds. Security virtualization also enables security to accelerate operationally.
Open, programmatic security provisioning and control
Security virtualization must be integrated with provisioning, management, and operations of the data center. This must be a set of APIs that will fit into the management stacks developed and developing for each hypervisor platform. Security virtualization vendors will be able to differentiate on performance, complexity, completeness of solution, etc. However, each vendor must be able to interoperate with a common protocol like SCAP and must support their own orchestration by 3rd party or platform tools and management platforms. Specifically the API must, at minimum, support
- create/modify/delete for security policy elements
- create/modify/delete of security zones
- bidirectional updates of inventory attributes
- bidirectional event communication
- integration with workflow and incident escalation systems
Security virtualization has the potential to drastically improve the protection of sensitive data while at the same time simplifying the application of these protective capabilities. As with hardware virtualization, the most effective use of security virtualization will require changes to IT staffing, processes, and procedures. This will be disruptive to the way security "has always been doing it" -- something that is both necessary and good because the way we have been doing it has not been effective.