Automated Analysis: Design and Implementation

Weatherman provides an automated analysis of configuration and topology changes in virtualized in-

frastructures. Its architecture, as shown in Fig. 8.5, obtains all the necessary inputs for the analysis and invokes GROOVE as the graph transformation engine. Based on this architecture, we describe two application scenarios for change management (Section 8.4.3) as well as for run-time enforcement of security policies and the mitigation of misconfigurations (Section 8.4.2).

Figure 8.5.: The system architecture consists of i) Configuration Discovery & Translation on the left, which extracts the infrastructure configuration and builds the Realization model; ii) the Orchestrator in the middle, which prepares the graph grammar for the analysis based on all inputs; iii) and the Graph Transformation on the right that employs GROOVE .

8.4.1 System Architecture

The system architecture, as shown in Fig. 8.5, consists of i) Configuration Discovery & Translation on the left, which extracts the infrastructure configuration and builds the Realization model; ii) the Orchestrator in the middle, which prepares the graph grammar for the analysis based on all inputs; iii) and the Graph

Transformation on the right that employs GROOVE.

The architecture is an extension to the analysis architecture originally proposed in Chapter 5. The orchestrator now also includes the user-configurable information flow rules as well as the operations transition model. We employ a different analysis backend, that is a graph transformation engine rather than set-rewriting model checkers or FOL theorem provers.

Configuration Discovery & Translation

The configuration extraction and model population for the virtualized infrastructure is based on the method of Chapter 3 and also incorporates the updating of the model when the infrastructures changes (cf. Chapter 7). This is crucial for the run-time enforcement of security policies as the underlying infrastructure constantly changes and the change operations have to be evaluated against a model of the latest infrastructure configuration.

Orchestrator

The orchestrator prepares the graph grammar for the analysis with GROOVE and includes the following elements:

• Host Graph: The initial graph for the graph transformation is the latest Realization model, which is serialized into an XML graph format for GROOVE.

• Transformation Rules: The transformation rules for the information flow analysis as well as for the operations transition model.

• Graph Matches: The security policies are expressed as graph matches, i.e., graph transformation rules that neither add nor remove elements from the graph.

• Control Program: The control program guides the application of the information flow and operations rules. The program specifies the order of operations as well as their parameters.

With regard to obtaining the required inputs, the involvement of the user is kept to a minimum as we are striving for an automated approach. The rules for the automated information flow analysis as well as the security policies come as pre-defined sets, and only in specific cases can/need to be extended or modified by the user. Security policies may require further input from the user, such that virtual resources need to be assigned to security zones for the zone isolation policy.

Graph Transformation

We employ GROOVE for the graph transformation and analysis once the orchestrator prepared the graph grammar and control program. GROOVE will interpret and execute the control program for the given grammar. It will apply the information flow rules as well as the rules for the operations that are specified in the control program with their parameters.

Of particular interest is the potential violation of a given security policy once the operations have been applied and the information flow computed. Recall that a policy is violated if a propositional formula of the formAttackPolicy₁∨ ¬PositivePolicy1∨ AttackPolicy2. . . is satisfied, i.e., either an attack policy is

satisfied or a positive policy is no longer matched. GROOVE provides the concept of acceptors that indicate when such a state, a result state, is found. We employ different acceptors:

• Invariant Acceptor: Given a single transformation rule, this acceptor fires when either the rule is applicable (in positive mode) or the rule is no longer applicable (in negative mode). Note that the

given rule must only be applicable and not actually applied. GROOVE evaluates the acceptor for each new graph state. The acceptor only works for a single attack or positive security policy. The acceptor’s mode has to be set to positive for attack policies and negative for positive policies, that is, the acceptor succeeds when an attack policies is applicable or when a positive rule is no longer applicable.

• Application Acceptor: This acceptor succeeds if a single given rule has actually been applied. This differs to the invariant acceptor where a rule only has to be applicable or not. The acceptor only works for a single attack state policy and the control program needs to explicitly try to apply the attack state rule after the operations and information flow rules have been applied.

• Formula Acceptor: Unlike the previous acceptors, this one can match against multiple attack and positive policies. A propositional formula, in the previously discussed form, is given and the acceptor succeeds when the formula is satisfied. Similar to the invariant acceptor, the rules must either be applicable or not.

The difference between the acceptors in terms of rule applicability and actual application of rules is important for the efficiency of our analysis, because we differentiate between a greedy and non-greedy analysis. In the greedy variant, we try to find a policy violation as early as possible and may terminate the analysis early. In the non-greedy analysis we apply the operations and information flow rules and only then determine potential policy violations. Typically, the greedy analysis is preferred for its potential early termination. However, if the current infrastructure already contains a policy violation, the intended operations are not evaluated, although they may fix the cause of the current policy violation. Therefore, we have to use a non-greedy analysis in that case.

We can instruct GROOVE on how many result states should be found before terminating the application of further transformation rules. For the greedy analysis with its early termination, we want to find one possible violation of a security policy. In many use cases finding a policy violation as soon as possible is enough rather than finding all possible violations. Each result state is an instance of the infrastructure where a policy is violated. As discussed previously, attack state policies have an advantage in the root- cause analysis, since the analysis returns the matching part of the infrastructure that causes the violation, i.e., the attack state. Whereas for positive policies, the analysis does not provide a reason why a policy rule no longer matches.

GROOVE supports multiple different graph exploration strategies, i.e., the way how the transformation

rules are applied. In our case, we employ a linear exploration strategy, because our rule application is strictly guided by the control program. In terms of model checking, GROOVE also provides a full state space exploration that would analyze the interleaving of operations as well as evaluating potential operations that could have been applied and which would lead to a security policy violation. We consider this kind of analysis as future work that builds upon the modeling and analysis results of this work.

8.4.2 Run-time Analysis of Changes

Run-time analysis enables automated mitigation of misconfigurations and enforcement of security policies. To achieve this goal, we introduce an authorization proxy that acts as a reverse HTTPS proxy in front of the otherwise shielded management host. The proxy intercepts management operations and inspects them for the analysis. The proxy keeps sessions for each logged in administrators and associates the operations with them. Operations and configuration changes are only forwarded by the proxy to the management host if the Weatherman analysis indicates no security policy violation. In a secure deployment (cf. Section 8.5.1), it allows to protect virtualized infrastructures from malicious adversaries.

The communication in front of the manager is usually standardized: VMware and Amazon EC2 manage- ment operations are SOAP-based, whereas OpenStack is REST-based. These formats are easily inspected. In addition, the proxy tracks session states derived from the the user-login and the infrastructure manager

session cookie, to distinguish sessions of multiple administrators interacting with the infrastructure manager concurrently.

The Policy Decision Point (PDP) of the authorization proxy translates intercepted management operations into our operations transition model and into a change plan in the GROOVE control language. We have translation modules for all covered operations. For instance, from an UpdatePortGroup operation the proxy extracts the host, identifying port group name, new VLAN identifier, as well as new port group name. The PDP then delegates the change plan analysis to Weatherman, which analyzes the intended changes. The Policy Enforcement Point (PEP) only accepts the intercepted operations if they are compliant with the policies; otherwise, they are rejected. The authorization proxy refrains from forwarding the management operation in the reject case, i.e., they are not deployed in the actual infrastructure. It signals an error back to the administrator client, including the policy violation as data for diagnosis.

The run-time analysis might block management operations in two cases: Hard blocking occurs if the authorization proxy rejects a management operation, but the administrator might need to override the security policy in an emergency, which could be allowed by a trusted super-administrator. Soft blocking occurs due to the delay the analysis adds and may be precarious if the expected time between management operations is smaller than the expected analysis time.

8.4.3 Change Plan Analysis

The goal of the change plan analysis is to support the planning of complex configuration changes and to verify their security compliance. The focus of this complementary approach lies on the planning of potential changes and perform what-if analyses, whereas the run-time analysis inspects the operations that are currently deployed. In fact, change management, and change plans in particular, are often employed as part of IT infrastructure operation workflows and processes. In our case, an administrator drafts a sequence of desired changes that he wants to be provisioned.

The crucial question is: Will the proposed changes render the infrastructure insecure? To answer this question, the administrator submits a change plan that contains a sequence of operations with their parameters to Weatherman. The analysis system then uses GROOVE to apply the changes to the graph model of the infrastructure and verifies the resulting infrastructure state against the desired security policies. By that, the tool can establish a what-if analysis and determine what security impact the intended changes will have on the infrastructure.

If the new graph model obtained from the application of the changes violates the security goals, the tool notifies the administrator to reject the proposed change plan and provides the analysis output of the matched policy violation as diagnosis. Otherwise, the tool returns that the intended changes are compliant with the security goals, after which the administrator can provision the changes to the infrastructure.