Closing the Gap between the Specification and Enforcement of Security Policies

Closing the Gap between the Specification and Enforcement of Security Policies José-Miguel Horcas, Mónica Pinto, and Lidia Fuentes CAOSD Group, Universidad de Málaga, Andalucía Tech, Spain {horcas,pinto,lff}@lcc.uma.es Abstract. Security policies are enforced through the deployment of certain security functionalities within the applications. Applications can have different levels of security and thus each security policy is enforced by different security functionalities. Thus, the secure deployment of an application is not an easy task, being more complicated due to the existing gap between the specification of a security policy and the deployment, inside the application, of the security functionalities that are required to enforce that security policy. The main goal of this paper is to close this gap. This is done by using the paradigms of Software Product Lines and Aspect-Oriented Programming in order to: (1) link the security policies with the security functionalities, (2) generate a configuration of the security functionalities that fit a security policy, and (3) weave the selected security functionalities into an application. We qualitatively evaluate our approach, and discuss its benefits using a case study. Keywords: Security enforcement, security policy, aspect-oriented programming, software product lines. 1 Introduction A security policy is a set of rules that regulate the nature and the context of actions that can be performed within a system according to specific roles (i.e. permissions, interdictions, obligations, availability, etc) to assure and enforce security [1]. The security policies have to be specified before being enforced. This specification can be based on different models, such as OrBAC [2], RBAC [3], MAC [4], etc. and describes the security properties that an application should meet. Once specified, a security policy is enforced through the deployment of certain security functionalities within the application. For instance, the security policy “the system has the obligation to use a digital certificate to authenticate the users that connect using a laptop” should be enforced by deploying, within the application, “an authentication module that supports authentication based on digital certificates”. This module must be executed before the user connects to the application using a laptop. In order to make explicit this relationship between the security policies and the security functionalities that are needed to enforce them, the links between both should be specified. This relationship is needed because, normally, the same application can be deployed with different security policies. This implies that a variable number of security functionalities will be used by the application, but not all of them simultaneously. For example, in this paper we use an e-voting case study where the administrator can create elections of different types (e.g. national elections, coorporative elections, social event elections, etc.). These elections are deployed with different security policies. For instance, in a national election, users must be authenticated by an X.509 digital certificate provided by a trusted certification authority before they are joined to the election. Votes must be encrypted and must preserve their integrity and authenticity. However, in a corporative election users must be authenticated by using a user/password mechanism, while in a social event election users do not need to authenticate. In other words, there are different levels of security depending on the kind of election, and thus, each security policy is enforced by different security functionalities. All this means that the secure deployment of an application is not an easy and straightforward task. Moreover, this is complicated even further due to the existing gap between the specification and the enforcement of a security policy. This gap is generated by the lack of a well-defined approach that would automatically introduce into an application, the security functionalities that are required to enforce the security policy. The main goal of this paper is to close this gap. We do this by using two advanced software engineering approaches, Software Product Lines (SPLs) [5] and Aspect-Oriented Programming (AOP) [6]. On the one hand, we use SPLs to: (1) model the commonalities and variabilities of the security properties represented in the security policies, (2) link the security properties to the modules that implement the security functionalities, and (3) automatically generate a security configuration including only the security functionalities that are required to enforce a particular security policy. On the other hand, we use AOP to: (1) design and implement the security functionalities separately from the applications (implementing them as aspects), and (2) deploy a security configuration in an application without modifying the original application. This work has been done in the context of the European project Inter-operable Trust Assurance Infrastructure (INTER-TRUST) [1] that aims to develop a framework to support trustworthy applications that are adapted at runtime to enforce changing security policies. The rest of the paper is organized as follow. Section 2 describes the SPL and AOP approaches, introducing the main terminology. Section 3 provides an overview of our approach, while Section 4 and Section 5 describe it in an exampledriven way using the e-voting case study. Section 6 evaluates our approach. The remaining sections present the related work, conclusions and future work. 2 Background Information This section introduces the SPL and AOP approaches, and the main terminology. 2.1 Software Product Lines In software engineering we usually need to create and maintain applications that contain: (1) a collection of similar functionalities from a shared set of software assets (i.e. commonalities) and (2) a collection of variant functionalities (i.e. variabilities). These applications require software developers to build a base on the application commonalities, and to efficiently express and manage the application variabilities, allowing the delivery of a wide variety of applications in a fast, comprehensive and consistent way. The enabling technology to do that is the Software Product Lines (SPLs) [5]. SPLs allow the specification and modeling of the commonalities and variabilities of applications in an abstract level, creating different configurations of those variabilities for the implemented functionalities, and generating final applications with the customized functionalities according to those configurations. The security functionalities that need to be deployed inside an application are clearly variable. One the one hand, security is composed by many concerns, such as authentication, authorization, encryption, and privacy concerns, among others, which are regarded as configurable functionalities of security. For instance, there are many possible mechanisms to authenticate users (e.g. digital certificate, password based, biometric based), or there are a variable number of places within an application where communications need to be encrypted. On the other hand, an application will require different levels of security, based on the requirements specified in different security policies. So, different security configurations for the same application can be generated by modeling security using an SPL. Between the methods, tools and techniques provided by SPLs to model variability with the guarantee of a formal basis, some of the most commonly used are feature models [7] in which the variability functionalities are specified in the abstract level by using tree-based diagrams that include optionals and mandatories features, multiplicity, cross-tree constraint, among other characteristics. In this paper, we will use the Common Variability Language (CVL) [8] that apart from providing the same characteristics of feature models, is a domain-independent language and allows modeling and resolving the variability over models defined in any language based on Meta-Object Facility (MOF) [9]. 2.2 Aspect-Oriented Programming In object-oriented programming and component-based software engineering, there are concerns of an application that are dispersed or replicated in multiple modules. This occurs even when the functionalities are well-encapsulated in a class or a component (e.g. an encryption component), because the rest of the modules requiring these concerns need to include implicit calls to them (e.g. all the components in the application need to call the encryption component in order to encrypt/decrypt their interactions). These kinds of properties are known as crosscutting concerns, and their direct incorporation into the main functionality of an application cause scattered (i.e. dispersion) and tangled (i.e. mixing) code. Security is a well-known crosscutting concern in the aspect-oriented community [10,11]. Figure 1 shows an example of how several security functionalities crosscut the base components of our e-voting application. For instance, Authentication is required for voters and administrators, so this functionality is scattered within the Voter Client and Admin Client components. In addition, the code of the authentication functionality is tangled with these main components. Integrity and Signature functionalities are also tangled within the Voting Ballot component; while Encryption is also dispersed in several Fig. 1. Security functionalities crosscutting an e-voting application places in the application. Modeling the variability of these security functionalities joinly with the base application is a difficult and error-prone task. One of the most advanced techniques for dealing with crosscutting concerns is Aspect-Oriented Programming (AOP) [6]. AOP separates crosscutting concerns from the base functionality of an application by first encapsulating them in entities called aspects,andbythenweaving (i.e. incorporating) these aspects into the existing code of the base application without modifying it. Aspects are described in terms of join points,pointcuts and advices. The points inside the code of the base application in which the crosscutting concerns come into play are known as join points;pointcuts are expressions that pick out certain join points; and advices is the crosscutting behaviour to be executed when a pointcut is reached. The mechanism in charge of weaving the main functionality of the application and the aspects is the weaver. Separating the security functionalities from the base functionality of the application smoothes coupling between modules and increases the cohesion of each of them. As a consequence of a low coupling and a high cohesion, the maintainability of the global system improves due to the fact that changes in a module affect only that module; and thus, the modeling of the security variability and consequent deployment and enforcement of different security policies is easier. Moreover, the reusability also improves because the three elements (the base code, the security functionalities and the security policies) can be more easily reused in different systems. 3 Our Approach As we presented in the introduction, an application can be deployed with different security policies and each security policy is enforced by different security functionalities. Top of Figure 2 shows the problem of the existing gap between the specification snd the enforcement of the security policies. Bottom of Figure 2 shows our solution to close this gap. As previously mentioned, our approach combines the use of SPL and AOP. Firstly, as shown in Figure 2, left side under the Solution label, we model the variability of the security functionalities in an abstract level by specifying all the possible features of each security functionality in a tree-based diagram (i.e. we Fig. 2. Problem overview and solution proposal specify the SPL). This variability model is linked to the complete implementation of the security functionalities, by linking each feature in the tree to the pieces of code that have to be included and configured (e.g. a class, a parameter, a value,...). Secondly, the right-hand side of Figure 2, under the Solution label, shows how, for each security policy, we create a configuration of the previously specified SPL by selecting those features inthetreethatmeetthesecuritypolicy — i.e. we instantiate the SPL. This step can be done by a security expert or can also be done automatically by a reasoning engine that extracts the knowledge of the security policy and selects the appropriate features. Using AOP, the security functionalities are implemented as aspects with the purpose of deploying them in the application without modifying the base code of the original application. Thus, the last step of our approach (see bottom half of Figure 2) is weaving the application and the aspects that implement a particular security configuration. The generated application includes the security functionalities that are needed to guarantee the enforcement of the security policy. The following sections describe our approach in more detail. 4 Variability Modeling of Security Functionalities In this section we explain how to specify the SPL for modeling the variability of the security functionalities. We use the variability model of CVL that comprises two parts: (1) the variability specifications (VSpecs) tree (i.e. the abstract level) <<aspect>> Encryption <<aspect>> Authorization TrustInteroperability [1..*] ChannelProtection [1..*] Fil tering [1..*] MessageSecurity [1..*] DataSecurity [1..*] Authentication Unlinkability Filtering Trust IPSec Authorization AccessControl [1..*] 1..1 Pseudonymity Privacy [1..*] 1..1 WifiSecurity 1..1 Signature Authenticity Hashing Integrity Confidentiality Cypher 1..* Authentication_CU Authorization_CU Trust_CU Unlinkability_CU Pseudonymity_CU IPSec_CU WifiSecurity_CU Signature_CU Filtering_CU Hashing_CU Confidentiality_CU <<aspect>> Trust <<aspect>> Unlinkability <<aspect>> Pseudonymity <<aspect>> IPSec <<aspect>> WifiSecurity <<aspect>> Filtering <<aspect>> Signature <<aspect>> Hashing Security Functionalities Cypher_CU <<aspect>> Authentication Security 0..* Variability specifications (VSpecs) treeVariation points Base model Authenticity implies Integrity Variability model ChoiceFeature [1..*] CompositeVariability_Cv Variable: Type 1..n between 1 and n selections Constraint ConfigurableUnit_CU mandatory feature optional feature reference between variation points and features binding between variation points and functionalities CVL Legend 1 or more instances yes/no decision specify a value of a type intricate relationships among features container of variation points container of specifications trees selections in a configuration Fig. 3. Modeling security concepts in CVL that allows us to specify the security features in a tree-structure with the relationships between them; and (2) the variation points, that allows us to link the features of the tree with the implementation of the security functionalities. Figure 3 shows the variability model with these two parts and the implementation of the security functionality encapsulated inside the aspects. In the VSpecs, security is decomposed into more specific concepts and configurable features. For instance, the AccessControl concept contains the Authentication and Authorization features. The multiplicity [1..*] beside the AccessControl concept indicates that we can create multiple instances of it, each of them will require the configuration of different Authentication or Authorization features. For each of these instances there will be an aspect instantiated with the appropriate security functionality configured. In this case, variation points link each feature with the aspect that contains the configurable functionality. Since security is composed by a lot of functionalities, and each of them has many configurable features, we define the variability model in two levels of detail using several related tree diagrams: (1) a high level VSpecs with all the main security functionalities represented as features (Figure 3); and (2) a VSpecs tree for each of these features in order to configure them appropriately. For instance, Figure 4 shows the part of the variability model that specifies the details to configure the Authentication functionality. Authentication is decomposed in a set of configurable features such as the authentication mechanism (DigitalCertificate or UserPassword) and the parameters and variables that contain the selected functionality (kind of certificate (Credentials), certificate authority (TrustedCA), ldots). These can be defined as optional features Authentication Functionality Identity: Object Country: String Organization: String OrganizationUnit: String CommonName: String DigitalCertificate UserPassword X.509Certificate TrustedCA Authentication 1..1 Credentials Digital Certificate X.509 Certificate Certificate Authority C:String = “ES” O:String = “ Fábrica Nacional de Moneda y Timbre” OU:String = “FNMT” CN:String = “CERT.FNMT.ES” CA Authent. Algorithm User Password Private Key alias:String = “voter001” keyStore:String = “VotersRepository” PK Variability specifications (VSpecs) treeVariation points Base model <<aspect>> Authentication Advice Pointcut SessionKey KeyAlias: String KeyStore: String :ParametricSlotAssignment slotIdentifier = “target” :ObjectSubstitution target = “Digital Certificate” :ParametricSlotAssignment slotIdentifier = “C” :ParametricSlotAssignment slotIdentifier = “O” ... :ObjectSubstitution target = “Authent. Algorithm” :ObjectSubstitution target = “Authent. Algorithm” ...... Variability model owner: Object = Voter Fig. 4. Variability Modeling of Authentication functionality (ObjectExistence variation point), variable features (ObjectSubstitution variation point), parameterizable features (ParametricSlotAssignment variation point), among others. In our case, we only need to use the ObjectSubstitution and the ParametricSlotAssignment variations point in order to substitute the selected authentication mechanism to be used (Authent. Algorithm)andto assign the values to the variables (e.g. parameters of the TrustedCA). Note that the main benefit of our approach is that this SPL specification, although it is complex, only needs to be specified once by a software engineer, expert on security. Then, application developers will only have to select those security functionalities that need to be used in their applications and, as explained in the next section, our approach will generate a security configuration that enforces the required security policy, and is ready to be used by the application. 5 Enforcement of Security Policies This section explains how to create a security configuration that enforces a security policy and how to deploy it within the application. 5.1 Configuring the security functionality In order to select and configure the proper functionality that enforces a security policy, the security rules specified in the policy need to be analyzed and interpreted. This can be done by a security expert, an administrator, or automatically, by a reasoning engine that extracts the security knowledge from the rules, selects the security features, and assigns the appropriate values in the VSpecs — i.e. we instantiate the SPL by creating a configuration for the VSpecs. Following our e-voting case study, Listing 1.1 shows an excerpt of a security policy defined in the OrBAC model for a national election in Spain. The first two rules specify that voters and administrators must be authenticated by a digital certificate in the spanish administration server (GOB_ES). The other rules specify permission for administrators and voters in order to create elections (rule 3) and to access the general elections (rule 4) respectively, to guarantee the authenticity and integrity of the votes (rule 5), and the encryption of all the interactions between the users and the server (rule 6). Listing 1.1. Excerpt of an OrBAC security policy 1Obligation(GOB_ES, User, Authenticate , Certificate , Authent_conditions) ∧ 2Obligation(GOB_ES, Admin , Authenticate , Certificate , Authent_conditions) ∧ 3Permission(GOB_ES, Admin , Create, Election, default) ∧ 4Permission(GOB_ES, User, Access, General_Election , default) ∧ 5Permission(GOB_ES, User , Sign, Votes , Signature_conditions) ∧ 6Permission(GOB_ES, User, Encrypt, Messages, Encrypt_conditions) From these rules a configuration of the VSpecs is created. Some elements of the security policies are used to select the desired functionality, while other elements are used to configure the selected functionality. Features in a dark color in Figure 3 represent the security features selected for those rules. From rules 1-4 we have selected the AccessControl security concept with the Authentication (rules 1-2) and Authorization (rules 3-4) functionality, and this requires providing two different configurations for each of these functionalities — i.e. this implies two different instances of the authentication aspect and two different instances of the authorization aspect, properly configured. For rule 5 we have selected the MessageSecurity concept that includes the Signature functionality, but also the Hashing functionality since there is a constraint in the SPL specification indicating that Authenticity implies Integrity. So, in order to enforce this requirement two different aspects should be configured: Signature and Hashing. Finally, for rule 6 we have selected the DataSecurity concept with the Cipher functionality in order to encrypt the information exchange between the users and the server, and thus, an encryption aspect should be configured. Each of these aspects contain the functionality that should be configured based on the knowledge specified in the policy. So, we have to provide a configuration for each instance of these aspects in the VSpecs. For example, features in a dark color in Figure 4 and concrete values assigned to the variables represent a configuration for the instance of the Authentication aspect corresponding to security rule 1 of the security policy1. For instance, the credential parameters and the trusted CA information are obtained from the context of the policy in the OrBAC model, but can also be manually assigned if the security model does not include that information. In order to resolve the variability and automatically generate the configured security aspects, the CVL engine is executed taking as inputs the security variability model, the particular configuration created for the variability model, and the implementation of the security functionalities encapsulated into aspects. 1For reasons of space, we represent the configuration directly over the VSpecs. 5.2 Deploying the Security Aspects into the Application Once the security aspects have been generated according the specifications of the security policy, the deployment of them inside the base application can be performed in a non-intrusive way —- i.e., without modifying the existing code of the application, by using the AOP. The mechanism in charge of composing the main functionality of the application and the aspects is the weaver, and how the weaver deploys the aspects within the application depends on the AOP framework chosen to define the aspects (e.g. AspectJ, Spring AOP, JBoss AOP, etc.). For instance, Figure 5 shows an example of the Authentication aspect (in AspectJ) woven with the e-voting application. This aspect encapsulates the authentication functionality (AuthenticationModule). The pointcut picks out the execution of the method vote and before it runs, the user is authenticated (advice code). We can observe how the application class Ballot does not contain any reference to the authentication functionality or to any other functionality related to security, which are all introduced as aspects. Fig. 5. Security functionality deployed within the e-voting application using AOP 6 Evaluation Results Our approach uses consolidated software engineering technologies (SPLs and AOP), and a proposed standard language (CVL). So, in this section we qualitatively discuss our work to argue the correctness, maintainability, extendibility, separation of concerns, reusability, and scalability of our approach. Correctness. SPLs and AOP do not improve the correctness of applications or security functionalities as such. Functionality in both cases is the same. However, modularizing security concerns in separate modules with AOP considerably facilitates the verification of the security properties of an application since a security expert does not have to check all the modules in the base application to ensure that all security requirements are correctly enforced. Instead, only the code of the aspects and the definition of the pointcuts where the aspects will be introduced need to be checked [10]. Maintainability and extendibility. On the one hand, due to the variability expressed in the SPL, changes of specifications in security policies are adapted easily by re-configuring the security functionality according to those changes.