Browse Prior Art Database

Policy by Example: Transforming config into policy

IP.com Disclosure Number: IPCOM000180994D
Original Publication Date: 2009-Mar-23
Included in the Prior Art Database: 2009-Mar-23
Document File: 7 page(s) / 43K

Publishing Venue

IBM

Abstract

The present idea refers to allow normal users to specify an "ideal" system driven purely by functional and not security requirements, and then auto-generating appropriate security policies. The ideal system is specified by describing the desired topology and behavior by means of use-cases or solutions. The auto-generation of the security policy then ensures that this topology and use-cases are the only possible structure and behavior of the system. The idea is to implement a "nothing else" (least privilege) paradigm, i.e., to ensure that the given use-cases on the given topology are possible and nothing else. The preferred embodiment is a virtual infrastructure inside a data center. Here, the user can specify a use-case (or solution) by specifying a set of virtual machines, their network connections, and their storage requirements. This solution is then used to generate the exact system topology as well as the security configuration of the deployed system. In this case, the security configuration comprises network, storage, and virtual machine security policies that are consistent with each other and implement the "nothing else" rule for the given solution/use case. With "nothing else" it is meant that a user only specifies the business behavior of a system. The present approach then derives the actions that need to be permitted and denies everything else.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 7

Policy by Example :

: Transforming config into policy

Transforming config into policy

Security policies define what actions are permittedand what actions shall be denied. Since the behavior of systems is complex, specifying such policies is usually complicated & error-prone. This is even more so, if achieving overall security requires correct and consistent configuration of the security policies governing multiple subsystems that require different policy languages/formats. Even security experts often make mistakes specifying either incomplete, inconsistent, or overly restrictive policies.

As a consequence, the system is either insecure or it's usability is overly restricted. Examples include

firewall rules that conflict each other, virtual LANs that by accident connect two competitors in a datacenter, or disks that can be mounted by the wrong organizational unit.

There are three levels of abstractions that the present technology uses. The first level is a solutiontemplate (figure 1) that defines what components may be connected to each other. The second level (figure 2) is an actual instantiation of this template, i.e., a number of copies of each component that is deployed on a number of hosts. The third level is the actual implementation including security configuration andpolicies .

The details of the general flow are as follows:

User specifies a use case or solution. This includes a logical topology and desired usage of this topology. It can also


1.

include desired connectivity between solutions and user-level constraints on how the solutions may interact. This is essentially a policy specification "by example" of a ideal system. The solution may specify a class ofrealizations (e.g., allowing cloning of components or specifying clusters of n components). This specification can be done in a graphical fashion. This may include
dangling named connectors to connect networks to other solutions
replication specifiers (e.g. [1..x] clones are allowed) thus describing classes of systems.

A deployment planner generates a deployment of the solution. This deployment describes which components (

VM,

2.

Network, Storage) are placed onto which host and how they are configured and connected. The deploymentdefines the number of instances of each virtual component as well as their placement on physical resources (see Picture 2). This may include
placing the virtual machines on physical hosts
identifying the number of networks that are required by the given solution
connecting the virtual machines by networks. This can either be physical/dedicated networks or else virtual networks.

Virtual networks are usually implemented using vLANtechnology. In this case, the system configures the

switches to connect the hosts that host VMs of the solution to the corresponding vLANs provisioning storage and other resource

1

Page 2 of 7

matching dangling connectors and connecting them.

The system generates security policies th...