Illumio Blog
December 22, 2014

“GuideRAELs” for Natural-language Security Policies

Alan S. Cohen,

Find me on:

 

Ask security/firewall administrators how they would describe a typical firewall rule, and the example they offer would be something like “Host A with IP address 192.168.1.101 is permitted to communicate with a destination Host B with IP address 190.35.1.17 on TCP port #80.” 

guideRAELs for Natural-Language Security Policies

Over the past few decades, the industry has become accustomed to specifying security policies this way. This model for security rules first started with perimeter firewalls and has since been extended to internal firewalls when specifying security rules inside data centers and even public clouds. It is also the approach that firewall vendors are actively advocating.

But what is the problem with this picture?

Security needs a grassroots rethinking of the approach to security policies.

Such security rules are inflexible and static in the context of dynamic data centers and clouds. What happens if an IP address is reassigned unbeknownst to the firewall administrator, or if the application workload needs to be moved to a different environment? These rules are bound to the network, difficult to track and maintain, manually administered, error prone, and do not account for the rate of change in dynamic computing environments.

It is an example of what I call a “we have always done it this way” problem. Its consequences have created an uneasy tension between security teams and the groups they support. To address this problem, security needs a grassroots rethinking of the approach to security policies.

Simplifying security with natural language policies

At Illumio, our founders started with the belief that for security to mirror the needs of modern data centers, it must be completely decoupled from the underlying infrastructure. Making security independent from the computing environment starts with policy specification. If security policies can be written in a universal way, then we can apply those policies to protect assets in any data center or cloud environment. Illumio’s unique natural-language policy specification model makes universal security policies possible.

If security policies can be written in a universal way, then we can apply those policies to protect assets in any data center or cloud environment.

RAELs: Persona-based labels for application workloads

The Illumio Adaptive Security Platform (ASP) starts with a policy model built to secure communications between application workloads running on any physical server or VM across any data center or cloud. To understand the Illumio policy model, it is useful to think in terms of the persona of an individual workload. Each workload in a multitier application, whether deployed across data centers or clouds, has a unique persona based on: 

  • Role (database, web server, etc.);
  • The Application (HR, Sales, Ordering, etc.) it serves;
  • Life cycle Environment (Testing, Staging, Production etc.); and
  • Location (Oregon data center, DC3-Rack2, AWS, Microsoft Azure, etc.).

This Role, Application, Environment, and Location (RAEL) combination uniquely identifies an application workload or a group of related workloads (for example, in a set of auto-scaled workloads) across any computing environment.

multi-dimensional-labels

Security adapts to the modern application environment

Once labels have been assigned to workloads, they can be used to specify fine-grained interactions permitted within and between applications.

In the example below, the security rules in the table specify the permitted interactions within the workloads of an HRM application. The rules themselves are written in the language of the application instead of network parameters. For example:

  • The first rule specifies that the Web servers provide the Apache service to Corp-HQ (representing a range of IP addresses).
  • The second rule specifies the use of the Tomcat service between the App and the Web tiers of the application.

The scope (HRM:Prod:US)—defined using the Application, Environment, and Location labels—specifies the extent to which the policies apply. Any interactions that are not explicitly specified in the rules are automatically blocked.

Administrators can easily extend the scope of the policies by adding additional scope statements to the same ruleset. For example, adding HRM:Staging:US would allow the policies to apply to the workloads that make up the HRM application in the staging environment in the United States. Administrators also can expand the scope of the policies along any dimension by specifying “Any” for the Application, Environment, or Location. For example, HRM:Prod:Any would allow the security policies to automatically apply to workloads across all locations. Rules for workload interactions between multiple applications can be specified in the same way.

extending-the-policy-scope

Infrastructure independence

Illumio’s policy model results in precise and portable security policies that provide a zero-trust approach to security in any environment.

The Illumio Policy Compute Engine (PCE) is the smart engine of Illumio ASP that helps to adapt security in real time. It combines the specified policies with dynamic context information received from each workload to orchestrate the computation and enforcement of the most accurate security. Security is no longer dependent upon whether the workloads are physical servers or VMs, or whether they are deployed in the private data center or any public cloud. The IP address of the web server may change or new web servers may be created as part of auto-scaling the web tier of the application (new workloads automatically inherit the correct labels through a pairing process), but the policies stay intact.

Illumio’s policy model results in precise and portable security policies that provide a zero-trust approach to security in any environment. Illumio ASP prevents attacks from spreading laterally and their ability to report back to the attacker.

Topics: Adaptive Security, DevOps

Share this post: