by Mukesh Gupta

When ONUG SDSS (Software Defined Security Services) working group brought together IT executives from large enterprises including Bank of America, Barclays, Cigna, Salesforce, Tesla, Visa, Wells Fargo, etc., they prioritized the following two security use cases to the top of their list:

1. 1. Policies should be bound to workloads: whether virtual machines, containers, applications, services or micro services

1. 2. Write security policy in one place and deploy in multiple places, where workload policy would then be enforced

The need for the first is driven from the fact that almost all enterprises today are running heterogeneous infrastructure – and that heterogeneity is growing. They are running their applications on bare-metal servers and virtual machines running on different hypervisors, and are now using or exploring containers. They are running private clouds in their own data centers, moving some applications to public cloud, and sometimes using multiple different public clouds. The only thing that’s common across all this hybridity is the workload itself. That’s why a key paradigm shift for security is making it less dependent on the infrastructure, including the network, hypervisor, or even the cloud platform. The policies are bound to workload, but can be enforced in a number of ways – including the infrastructure.

The second use case emerges from the fact that development cycles are faster and more fluid. Data centers are much more dynamic than they used to be. DevOps culture enables continuous integration and continuous deployment (CI/CD) pipelines that integrate application development, QA, deployment, and operations. This means that security must be part of that same continuous pipeline of code moving from inception through to deployment while more software is being developed.

The only way to integrate security into the CI/CD model is to allow the security policy to be written in the language of the applications – as the applications move through the pipeline, the security policy can follow. If the security was tied to the infrastructure (hypervisors, network firewalls, or even cloud provider), the policy would have to be updated or could break when the application is deployed in a different environment (e.g., public cloud) or as it moves from development to QA to staging to production. If there was a way to describe the security policy in the language of an application, it will be portable, adaptable and even elastic. It will keep working whenever and wherever the application is deployed, moved, or scaled up/down.

So, how could the vendor community fulfill this dream? The SDSS working group has now invited several vendors, including Illumio, Juniper, Nuage, Cisco, Huawei, and vArmour to come up with a solution to meet these use cases and requirements. The result of the collaboration among the vendors was the architecture shown in the picture below. The architecture is centered around a security controller – the central brain – that allows the customers to define security policies in an infrastructure/network agnostic way. It translates these intent-based policies into something the enforcement points would understand and could act upon (e.g., rules with IP addresses and ports).

Enforcing these policies on the workloads, as highlighted by the first use case, would make it independent from the infrastructure. However, following the security principle of defense-in-depth, it would deliver even stronger security if the same policies, described by an administrator once in the language of the applications, could be enforced on the hypervisors, network devices (switches, routers, firewalls), and cloud-native controls, such as AWS, Azure or OpenStack Security Groups.

This architectural dream of the security controller will be impossible to deliver in all practicality if the enforcement points don’t have a consistent API/interface that the security controller could use to program policies. Without this consistent interface, the security controller will have to deal with vendor-specific interfaces or CLI commands that change over time, making it impossible for the security controller to keep up with those changes.

The I2NSF Working Group in IETF is working on the specifications for a common data model and schema for both the north-bound and the south-bound interfaces of the security controller. Enterprises that would benefit from having this specification should join the working group to help define and move this standard forward.

Are you up for it? If yes, let’s join forces in ONUG SDSS and IETF I2NSF, and help in developing the specifications for this common interface/API that will allow the security administrators to define policies in an infrastructure agnostic way – enabling an intelligent and adaptive security controller to program those policies on the workloads, hypervisors, network devices, and other enforcement points.

Author bio

Mukesh Gupta

Illumio

Mukesh Gupta is Sr. Director of Product Management at Illumio, where he drives the Software Strategy and Roadmap for Illumio Adaptive Security Platform. Prior to joining Illumio, he was founder and CEO of LocalCircles, a social networking start up. He also managed the SRX and NetScreen products at Juniper Networks, the WiFi Mesh Networking products at Tropos Networks, and as a lead engineer on Nokia’s security product lines. He co-chaired VRRP WG at IETF for many years and co-authored RFC 4552 (Authentication/Confidentiality for OSPFv3) and RFC 4443 (ICMPv6 for IPv6). He has a Masters degree in Computer Science from Univ. of Toledo and an MBA from Haas School of Business, UC Berkeley.