The Next Cloud Frontier: True Software-Defined Security

In last post of this series, I described what a Software-Defined Data Center (SDDC) is, and asked the question, “In a SDDC environment, should security simply be treated as another layer in a software stack? If so, where should it go?” I presented the first scenario for creating Software-Defined Security (SDS), which is basically migrating security from physical to virtual, but found it lacking. Here, I’ll cover a better approach to SDS.

The next way to look at SDDC security is on a “per layer” basis. Security tools are integrated into the hypervisor layer (or compute layer), the storage layer, the networking layer, and the operating system and application layers. This extends the idea of a virtualized control model, with multiple integration points that may be collectively more capable than a single “layer”.

However, without some central control plane (one ring to rule them all, as it were), these may simply function as disparate controls that suffer from a lack of interoperability and integration, and still don’t mesh well with the new SDDC requirements of automation and orchestration. Adding in more and more virtual security tools and controls also has two definitive drawbacks - excessive resource consumption and possible instability within the hypervisor environment due to “too many cooks in the kitchen”.

Today, no holistic security frameworks and tools exist to make the “security layer” in a SDDC architecture a reality. To do so, there will need to be extensive integration between security controls and the hypervisor, as well as integration between the security tools. In addition, all security controls within the SDDC will need to natively support and integrate with automation and orchestration frameworks.

In many ways, the next generation of security controls will come down to APIs. As more and more tools become software-based, the need to send and receive data between hypervisors and security management platforms will increase exponentially. Currently, most security-focused APIs are vendor-specific (Citrix, Microsoft, VMware, etc.). This will need to change in the future, as the majority of enterprises will leverage numerous virtualization technologies, and also extend their infrastructure into public cloud environments.

 

To wrap up, let’s imagine what true SDDC security might look like:

• Hardware layer - CPU and BIOS security layer monitors hardware instruction set and boot instructions, as well as the hypervisor layer installed on the hardware.

• Hypervisor layer - Communicates with the hardware layer to verify integrity frequently. Extends APIs to virtual network, storage, and VM components to facilitate expedited communication and dynamic detection and response across the back end hypervisor kernel bus.

• Virtual storage layer - The storage layer takes advantage of APIs that allow all other components to monitor data related to the virtual machines and components themselves (as they are all files on a SAN), as well as data security within VMs like encryption, DLP, and file integrity monitoring.

• Virtual network layer - The network layer takes advantage of APIs that process and manage network traffic between VMs and coming from the physical network. This integration will support virtual firewalls, virtual network IDS/IPS, virtual network DLP, and virtual network anti-malware and anti-spam controls.

• Virtual machine layer - This layer will support all operating system and application controls, such as anti-malware, host-based IDS/IPS, host-based DLP, local file and folder encryption, and more. Local firewalls will interoperate with the virtual network layer, and local file security tools will integrate with the virtual storage layer.

This sounds a lot like the current state of things, though, right? It is, in fact, with some exceptions (notably the hardware layer integration and the interoperability between layers).

So what’s missing?

The final piece to the puzzle is a standalone security layer that binds them all. This could be a standalone “appliance”, or could be a transparent link between APIs that allows for communication and coordination between security tools and automation and orchestration.

Imagine a case where a developer requests a new virtual machine for two weeks to perform quality assurance (QA) testing. Here’s what happens:

1. The developer clicks a link in the self-service portal to have a new virtual machine created.

2. The hypervisor layer automatically creates:

    a. A new virtual disk file and related configuration files with security controls related to the hypervisor environment built in.

    b. A new OS and application build installed on the virtual machine files that includes all OS and app security controls

    c. New routing and firewall rules that support the types of traffic and communication needed for the VM

    d. A policy-based lifecycle on the virtual machine, firewall rules, etc. that destroys all new rules and objects in two weeks.

    e. New monitoring requirements for security tools and dashboards.

3. During the VM’s existence, all security layers automatically interoperate and coordinate, with little to no manual intervention needed at all.

Today, we’re not quite there. This is coming, though, and security professionals need to prepare for it. The data center of yesterday is fading fast, and we’d better start adapting security to the SDDC mentality of tomorrow.

{{cta('f3d4e3fc-af0f-441d-9eb9-deceb2dd3925','justifycenter')}}