A Practical Runtime Security Policy Transformation Framework for Software Defined Networks

According to the definitions of model-driven architecture (MDA), the model transformation refers to the process of transforming the platform independent model (PIM) to its corresponding platform specific model (PSM)[8]. As far as the literatures we have read, the researches towards the policy model transformation can be roughly divided into three categories, they are the template-based transformation, RBAC-oriented transformation as well as the transformation based on the system model and mapping rules[9]. Due to the limitation of template, the template-based model transformation has very limited transformation capability. Generally, RBAC-oriented model transformation[10] is only suitable for transforming RBAC (role-based access control) policies, and does not have enough capability to describe the complex system, so that these two methods are not suitable for SDN networks.

At present, the model transformation based on the system model and mapping rules has been widely used for transforming the policy models. The main idea of this method can be summarized as follows: (1) System Model: it defines the objects of system and the relationship between the system objects; (2) Policy Model: it defines the policy object and the relationship between the policy objects; (3) Mapping Rules: it establishes the mapping rules between the upper-level policy objects and the lower-level system objects[11][12]. The transformation based on the system model and mapping rules first establishes the policy model and the system model which can describe the underlying system, then establishes the mapping rules between the policy objects and the system objects, then transforms the upper-level policy model into its corresponding lower-level policy model by means of the established mapping rules. In particular, Davy et al.[13] proposed a policy model transformation method based on mapping rules, in which the policy model is defined as a tuple ( event, condition, behavior, subject, object ) and used the ontology to establish the mapping rules between the different system layers. Luck et al.[14] proposed a method to transform RBAC model defined in service layer into the policy model used in the system layer. In this method, the system model is divided into three layers: roles and object (RO), subject and resources (SR) and processes and hosts (PH), and the mapping rules between the three layers have been established. Based on the Luck’s research, Porto et al.[15] further decomposes the PH layer into two sub layers, namely DAS (diagram abstract subsystem) layer and PH layer. DAS layer is mainly used to describe the network topology in the original PH layer, while PH layer is used to describe the specific network information in DAS layer. In addition, the authors also proposed a policy verification framework, which can be used to verify the consistency problems in the process of policy transformation. In addition, Lampson et al.[16] proposed a network policy model transformation method for the distributed computing environment. Maullo et al.[17] proposed a policy transformation system based on the first-order predicate logics, which transforms the high-level policy model into the low-level network configuration policy through the network topology and other information. Nanxi et al.[18] proposed a SDN-oriented access control policy transformation framework. In this paper, In this paper, we also propose a security policy transformation framework based on the system model and mapping rules. We first establish the system model of security policy (SPM) and data plane, then establish the transformation rules between the policy objects of SPM and the objects of the data plane, thereby transforming SPM into the system model of flow entries automatically.

To assure the information systems running securely, security mechanisms of information system need to be validated whether it can satisfy the security properties defined by the security policy. The traditional validation methods based on the testing and simulation can only confirm the system can work properly under the different testing scenarios, but it is difficult to find some hidden scenarios that occur with little probability. Formal verification methods have been applied to overcome the shortcomings existed in the traditional validation methods. At present, the formal verification methods for validating the security policy mainly include theorem proving and model checking[19]. Theorem proving is unsuitable to validate the properties of complex systems due to its lower efficiency. Model checking[20] can be used to validate whether the system model can satisfy the expected dynamic behaviors and specific static properties. Model checking technique has been widely used for the security policy verification. For instances, Al-Shaer et al.[21] proposed a static policy inconsistency detection method for the firewall policies of network. Bandara et al.[22] proposed a security policy verification framework based on event calculus (EC) and used the reasoning techniques for the policy conflict identification. May et al.[23] verified the privacy policies by means of an asynchronous model checker. Rubio-Loyola et al.[24] proposed a goal-oriented policy refinement and conflict detection method by means of the model checking technique and linear temporal Logic (LTL). Graham et al.[25] proposed a policy conflict detection method with the model checking and an extended decision table. Baliosan and Serrat[26] proposed a specific finite automata based method for the policy conflict detection.

Based on the established system model, we propose a formal method to transform SPM into the system model of flow entries from the theoretical level. The method can be described as Figure 1 and summarized as follows: First of all, for $\forall R_{i}\in$ SPM, the subject $s_{i}\in R_{i}$ is transformed into a host $h(s_{i})$ in the data plane, the object $o_{j}\in R_{i}$ is transformed into a host $h(o_{i})$ in the data plane; Next, the access authorization $a\in R_{i}$ is transformed into a connected path $P_{i}$ between $h(s_{i})$ and $h(o_{j})$; After that, the connected path $P_{i}$ is transformed into a set of flow entries used by the switches which are passed by $P_{i}$; Finally, SPM is transformed into the set of flow entries $\Delta$ when all relationships of SPM have been transformed. As shown in Figure 1, the relationship $R_{1}\in$ SPM is transformed into the connected path $P_{1}$ between $h_{1}$ and $h_{2}$, thus $P_{1}$ is transformed into the flow entries deployed in $sw_{1}$, so as to implement the security policy transformation from the system model level. The soundness of the formal method has been proven in our previous paper[7]. That is, if the security properties defined by SPM is denoted as $\varphi$, the system model of data plane is denoted as $\mathcal{D}$, the flow entries generated by the method is denoted as $\Delta$, then the method can ensure the data plane $\mathcal{D}$ loaded with $\Delta$ can synchronously and continuously hold the security properties $\varphi$ at runtime, i.e., $\mathcal{D}(\Delta)$ $\models$ $\varphi$.

Specifically, the formal method to transform SPM into the system model of flow entries is defined as follows.

$\bullet$ Transforming the Subject Given an access control relationship $R_{i}\in$ SPM and the subject $s_{i}\in R_{i}$, then $s_{i}$ is transformed into a corresponding host existed in the data plane. The rule of transforming the subject of SPM is formally defined as follows:

where $h(s_{i})$ represents the host mapped with $s_{i}$ in the data plane, $ip_{src}$ represents the IP address of $h(s_{i})$ in the data plane, $sw_{src}$ represents the OpenFlow switch connected with $h(s_{i})$ in the data plane, $port_{src}^{in}$ represents the port connected with $h(s_{i})$ in $sw_{src}$.

$\bullet$ Transforming the Object Given an access control relationship $R_{i}\in$ SPM and the object $o_{j}\in R_{i}$, then $o_{j}$ is transformed into a corresponding host existed in the data plane. The rule of transforming the object of SPM is formally defined as follows:

where $h(o_{j})$ represents the host mapped with $o_{j}$ in the data plane, $ip_{dst}$ represents the IP address of $h(o_{j})$ in the data plane, $sw_{dst}$ represents the OpenFlow switch connected with $h(o_{j})$, $port_{dst}^{out}$ represents the port connected with $h(o_{j})$ in $sw_{dst}$.

$\bullet$ Transforming the Authorization Given an access control relationship $R_{i}\in$ SPM and the access authorization $a\in R_{i}$, if there existing a connected path $P_{i}$ between $h(s_{i})$ and $h(o_{j})$ in the topology, then $a$ is transformed into the connected $P_{i}$. The rule of transforming the authorization is formally defined as follows:

where $h(s_{i})\longmapsto h(o_{j})$ represents a directional connected path from $h(s_{i})$ to $h(o_{j})$ in the topology.

$\bullet$ Transforming the Path The connected path $h(s_{i})\longmapsto h(o_{j})$ is transformed into a set of flow entries deployed in the OpenFlow switches which are passed by the path. The rule of transforming the connected path is formally defined as follows:

where $f_{i}(k)$ =$($ $ip_{src}$, $ip_{dst}$, $port_{k}^{in}\Longrightarrow port_{k}^{out}$ $)$ represents a flow entry deployed in the switch $sw_{k}$ which is passed by $h(s_{i})\longmapsto h(o_{j})$. Leveraging the definitions of the system model, we can proof that the rule of transforming the connected path is sound.

Therefore, $\forall R_{i}\in$ SPM, the subject $s_{i}\in R_{i}$, the object $o_{j}\in R_{i}$ and the autherization $a\in R_{i}$, if $\exists P_{i}$ = $h(s_{i})\longmapsto h(o_{j})$ in the topology, then $R_{i}$ can be transformed into a corresponding set of flow entries $\bigcup\limits_{k=src}^{dst}f_{i}(k)$ by using the system model step by step, it can be formally defined as follows:

$\bullet$ Transforming SPM SPM is transformed into a corresponding set of flow entries $\Delta$ by using the equation (5). If $||$ SPM $||$ = $m$, then the rule of transforming SPM is formally defined as follows:

$\bullet$ Security policy module is deployed in the application plane and responsible for maintaining the security policy (SPM). Each access control relationship $R_{i}\in$ SPM is designed as a 3-tuple: $($ $s_{i}$, $o_{j}$, $fixed$ $)$ based on the system model, where $s_{i}$ is the subject; $o_{j}$ is the object; $fixed$=$\{$ 0, 1 $\}$ is a tag bit, $fixed$=1 represents the relationship has been updated by user, $fixed$=0 represents it is unchanged. SPM is stored as a text document and can be updated by the user at runtime.

$\bullet$ Topology discovery module is deployed in the control plane and responsible for creating a dynamic real-time topology of the entire data plane by capturing the link events transmitted from the OpenFlow switches. Based on the system model, each edge in the topology is designed as a tuple: $e_{i}$ = $($ $sw_{src}$, $port_{src}$, $sw_{dst}$, $port_{dst}$, $using$, $c$ $)$, where $using$=$\{$ $True$, $False$ $\}$ is a tag bit and can be changed by the real-time link events at runtime, $using$=$True$ represents the edge can be used now, $using$=$False$ represents the edge is interrupted now. For the convenient of researching, the cost of each edge is set to 1, i.e., $c$ =1. The generated topology is stored as a text document and can also be updated by the real-time link events at runtime.

$\bullet$ Runtime monitoring module is deployed in the control plane and responsible for monitoring all the traffics in the data plane by capturing the real-time packet-in events transmitted from the OpenFlow switches. When a new packet-in event arrives in the controller, the module first invokes the path generation module to transform the latest security policy (SPM) into a set of connected paths in the data plane, then invokes the flow entry generation module to transform all the connected paths into their corresponding flow entries deployed in the OpenFlow switches which are passed by these paths. As SPM and the topology of data plane will be evolved with the runtime environment, this module is designed to be triggered by the real-time packet-in events continuously, so that, when SPM is changed (i.e., occurring $fixed$=1) or the topology is changed (i.e., occurring $using$=$False$) at runtime, the module will first delete all the current flow entries deployed in the OpenFlow switches, then update all the flow tables by using the latest generated flow entries, so as to ensure the security properties defined by SPM can be synchronously and continuously hold in the data plane at runtime.

$\bullet$ Path generation module is deployed in the control plane and invoked by the runtime monitoring module at runtime. The module is responsible for transforming each $R_{i}\in$ SPM input from the runtime monitoring module into a corresponding path $P_{i}$ in the data plane by using the latest topology file and the path searching algorithm. Specifically, it first transforms the subject $s_{i}\in R_{i}$ and the object $o_{j}\in R_{i}$ into the hosts $h(s_{i})$ and $h(o_{j})$ in the data plane respectively, then finds a shortest connected path $P_{i}$ between $h(s_{i})$ and $h(o_{j})$ by using the path searching algorithm, finally all the connected paths transformed from SPM are returned to the runtime monitoring module.

$\bullet$ Flow entry generation module is also deployed in the control plane and invoked by the runtime monitoring module at runtime. The module is responsible for transforming the connected path into a set of flow entries deployed in the OpenFlow switches which are passed by the path, then utilizing the instructions provided by the controller to generate the practical flow entries and distributing these flow entries to the corresponding OpenFlow switches at runtime.

The runtime monitoring algorithm deployed in the runtime monitoring module plays the role of coordinator in the framework, and can be described as Algorithm 1 in pseudo code. First of all, the algorithm creates two dynamic lists $S$ and $T$ by reading the latest SPM and Topo file respectively. If there existing an access control relationship has been changed by user ($R_{i}$.$fixed$=1) or a edge has been shut down in the topology ($e_{i}$.$using$=$False$) at runtime, it will clear all the current flow entries deployed in the OpenFlow switches for ready of the updating. In the following, for each access control relationship $R_{i}\in S$, it maps the subject $s_{i}\in R_{i}$ and the object $o_{j}\in R_{i}$ with the switches $sw_{src}$ and $sw_{dst}$ in the data plane, then transforms $R_{i}$ into a corresponding connected path $P_{i}$ by invoking the path searching algorithm djk-route($sw_{src}$, $sw_{dst}$, $N$). Based on the transformation rules, $P_{i}$ can be further transformed into a set of flow entries. When all the relationships in the List $S$ having been transformed, SPM has been transformed into a corresponding set of flow entries $\Delta$, the algorithm invokes the flow entry generation module to update the data plane by using $\Delta$. Since the algorithm is designed to be triggered by the packet-in events at runtime, so that it ensures the framework can perceive any changes in time when the security policy or the topology of data plane has been evolved with the environment, and then update the data plane synchronously at runtime.

Another important algorithm in the framework is the path searching algorithm deployed in the path generation module. The algorithm is improved from the classic Dijkstra algorithm and can be described as the Algorithm 2 in pseudo code. First of all, the algorithm creates a dynamic matrix $djk$[$N$][$N$] by using the sum of Openflow switches $N$ and the topology file. In the following, it calculates a shortest connected path between $sw_{src}$ and $sw_{dst}$ in the data plane by using $djk$[$N$][$N$] and the created stacks. After multi-round calculating, the shortest path $P_{i}$ between $sw_{src}$ and $sw_{dst}$ is found and returned to the runtime monitoring module. As the cost of each edge has been set to 1 and not considering of the quality of services (QoS) of edges, so that the shortest path $P_{i}$ found by the algorithm is generated by calculating the minimum number of hops in the topology. Moreover, since the matrix $djk$[$N$][$N$] is dynamically created by the topology file, so that the searched shortest path will be evolved with the changing of the topology at runtime.

The security policy used for validating the effectiveness of the framework is shown in Table I. Since any effective interaction is bidirectional in SDN networks, i.e., the subject’s host and the object’s host must be ensured they can access each other in the data plane, so that we design the security policy as 4 access control relationships ($R_{1}\sim R_{4}$) to ensure $h_{1}$ (1) and $h_{5}$ (5) can access each other, $h_{2}$ (2) and $h_{4}$ (4) can access each other, and all the relationships of SPM are set as $fixed$=1, i.e., having been updated by user. In the following, the effectiveness evaluations towards the framework will be carried out under 4 different scenarios at runtime, they are the effectiveness after loading the flow entries, the effectiveness after cutting down the path and the effectiveness after changing SPM.

As the critical algorithm used for implementing the security policy transformation, the performance of the path searching algorithm, i.e., Algorithm 2, needs to be further evaluated. First of all, the sum of access control relationships of the security policy (SPM) is denoted as $M$, and the sum of OpenFlow switches in the topology is denoted as $N$ in this performance evaluation. Then by leveraging the Python programming, the execution time of Algorithm 2 have been recorded in milliseconds (ms) for calculating the shortest paths under setting the different value of $M$ and $N$. The experimental result is plotted in Figure 10. As shown in Figure 10, with gradually amplifying the value of $M$ from 2 to 10, and the value of $N$ from 11 to 400 respectively, the execution time of Algorithm 2 shows an obvious exponential upward trend. Moreover, according to the description of Algorithm 2, the time complexity for calculating only one shortest path will reach $\mathcal{O}$($N^{2}$), because the Algorithm 2 needs to create a dynamic matrix $djk[N][N]$ and further calculates the while loop, so that the time complexity for transforming all the access control relationships defined by SPM into their corresponding shortest paths will reach $\mathcal{O}$($M\times N^{2}$).