Automatic Enforcement of Security Properties

Automatic Enforcement of Security Properties Jose-Miguel Horcas,M´onica Pinto, and Lidia Fuentes CAOSD Group, Universidad de M´alaga, Andaluc´ıa Tech, M´alaga, Spain {horcas,pinto,lff}@lcc.uma.es Abstract. Ensuring the security requirements of an application is not a straightforward task. Security properties (e.g., confidentiality, anonymity) need to be satisfied in different ways in different parts of the same application. Software architects are usually required to manually define security components and their dependencies with the base application, customize them to the application’s requirements, identify the points where security is incorporated, and verify that the selected places are correct. The last two steps are especially complex and errorprone. In our approach, we aim to provide a solution that helps software architects to identify the correct places to incorporate the security functionality and to verify the correctness of the composed application architecture. This is achieved by identifying a set of general structural patterns for incorporating security into the application architecture, and by providing a model-driven SPL solution to customize these patterns to each application’s requirements. Keywords: Encryption · Security pattern · Software architecture · SPL 1 Introduction It is well known that the development of applications that ensure their security requirements is not a straightforward task [1–3]. This is because security properties (e.g., confidentiality, authentication, etc.) need to be satisfied in different ways in different parts of the same application. Even the same security property usually needs to be satisfied differently in multiple parts of the same application. For instance, in order to preserve confidentiality the application’s sensitive data has to be encrypted. But, where and how does the data need to be encrypted? In our example, confidentiality is guaranteed by adding the encryption behavior in different places of the application. For instance, during the interaction of two components that exchange sensitive data, it could be added at the place where the data is encrypted, and the place where the same data is to be decrypted. However, encryption could be applied differently to different kinds of interactions. For example, only remote interactions, involving components that are deployed in different hosts, may be required to encrypt sensitive informa-tion. Sensitive data could be encrypted for all the interactions managing sensi-tive information, independently from the location of components. Or, encryption is required for all interactions managing sensitive data but providing different security levels — i.e., using different encryption algorithms, depending on the local or remote location of the components. Moreover, guaranteeing the secure storage of the information requires the data to be encrypted before storing it and decrypted after retrieving it. More variability is introduced if we consider that the sensitive data have to circulate securely — i.e., encrypted, through different components of the application. This means that the component where the data is encrypted and the component where the data is decrypted do not directly interact with each other, as there are third components between them. Finally, different kinds of sensitive data may require different levels of security, requiring the use of different encryption algorithms (e.g., RSA, AES,. . . ). Thus, it is not trivial for software architects to correctly answer the where-and-how question. A first step toward mitigating this problem is applying the separation of concerns principle to model the variability of security from the early stages of the software’s development. Thus, security concerns are modeled separately from the base applications and later customized to the application’s requirements and composed at particular points of the application model [4,5]. It has been demonstrated that this approach has many advantages [4–6], such as high reusability, low coupled components and high cohesive software architectures. Moreover, security can be more easily customized to the application’s requirements. Following this approach, our previous work [5] provided support to: (1) model the variability of security independently from the application, (2) instantiate the security model according to the requirements of a particular application, and (3) compose the customized security model with the application model. However, in order to compose the customized security model and the application model, first, the join points — i.e., points in the application model where the elements of the security model have to be injected/composed, have to be identified. In our previous work, the join points were identified completely manually. This resulted in a lack of support to guarantee the required security level, since analyzing whether the security components had been introduced in all and the correct places was not possible. Other similar approaches [4,6,7]havethe same limitation. Thus, the benefits of reusing the security models are lost. In this paper, we improve upon our previous approach by providing support to ensure that security is correctly incorporated in the applications. This is achieved by: (1) automatically identifying the places in the software architecture where a particular security functionality has to be incorporated, and (2) checking whether the security functionality was incorporated correctly to a software architecture. In order to automate the identification of the join points we need to understand that security models are not completely oblivious to the application models, and thus some dependencies between them need to be taken into account during both the security modeling and during the incorporation of the security functionality inside the application. Without this, the automatic identification of the join points is impossible. Concretely, as part of the variability of the security properties, we need to model the variability of the different structural and behavioral patterns (e.g., the remote/local direct/indirect interactions, data storage, etc. in the case of encryption) previously discussed. The main reason is that the identification of the join points and the definition of the composition rules largely depend on these patterns. Moreover, formally defining these patterns and the composition rules based on them will provide our approach with the support that is required to verify the correct deployment of security. In this paper we focus on confidentiality, although our ultimate goal is to identify a set of general structural and behavioral patterns to incorporate many other security properties into an application’s architecture, and to customize these patterns to each application’s requirements. We use a Software Product Line (SPL) [8] to specify the variability of the composition patterns, and model- to-model (M2M) transformations to identify the join points from the patterns and to guarantee that the final architecture satisfies the security requirements. The paper is structured as follows. Section 2motivates our work with a case study. Section 3presents our SPL to model and instantiate the variability of the security patterns. Section 4explains the automatic identification of join points from the patterns. Section 5qualitatively evaluates our approach. Section 6dis- cusses related work and Sect. 7sets out our conclusions and future work. 2 Motivating Case Study Our case study is an electronic payment (e-payment) application for making payments for different services (taxi, restaurants, donations,. . . ) and chasing up receipts. This kind of application requires strong security requirements such as preserving confidentiality of the user’s information, integrity of the data, and access control, among others. In this paper, we focus only on confidentiality. Figure 1shows a simplified UML software architecture with the basic functionality of the application. The PaymentApp component allows users to make payments for a specific service, and request the proof of payments by using the EPayment interface. The customer’s information (e.g., payment card details) is stored on the user’s device (CustomerProfileManager component). Additionally, this information can be synchronized between different user devices (SynchronizationData component). The server manages the payments through the EPaymentServer component that uses the ServiceDomainResolution and BankTransaction components to identify the service’s provider information and to complete the transactions with the banks, respectively. The server also tracks a history of the users’ transactions (TransactionsHistory component). Apart from this basic functionality shown in Fig. 1, it is of paramount importance to guarantee the following security requirements, among others: –Req. 1: Confidentiality. Sensitive information (i.e., payment card data) exchanged between the client and the server hosts must be encrypted (e.g., using the RSA algorithm). This means that it is required to encrypt the payment information (information of type PaymentMethod or the parameter payInfo in Fig. 1) when: (1) a payment is made — i.e., the PaymentApp client component calls the pay method of the EPayment interface; and when (2) the client synchronizes the list of payment methods — i.e., the component CustomerProfileManager calls the synchronize method of the SynchInfo interface. Then, the information has to be decrypted when the Fig. 1. Software architecture of the e-payment application. server receives it, in both EPaymentServer and SynchronizationData. Following our approach the software architect only needs to indicate that the payment card data is the sensitive data and then our automatic join point identification approach indicates those join points where encryption and decryption need to be incorporated in order to ensure the confidentiality of the sensitive data. –Req. 2: Confidentiality. All information exchanged between the EPayment- Server and BankTransaction components inside the server must also be encrypted, regardless of the type of information or the interface used. In this case, the software architect indicates that interactions between two specific components need to be encrypted and all the affected join points are automatically identified by our approach. –Req. 3: Confidentiality. The payment card details are stored in the user’s device using a different encryption algorithm from the one for communications (e.g., AES). Thus, another encryption algorithm is required to encrypt the payment methods information when they are stored/retrieved in the user’s device. In this case, both encrypting and decrypting functionalities are required by the same component (CustomerProfileManager). Here, our approach inspect the application looking for a structural pattern that represents a data storage and the join points would be automatically detected. 3 Capturing the Security Variability To accomplish the automatic identification of the joint points, we identify a set of structural patterns that specifies the relationships with the application. The variability of the patters is modelled in an SPL, together with the variability of the security functionality. Then, the software architect instantiates the patterns and the security functionality according to the application’s requirements. A security pattern describes a particular, recurring security problem (e.g., applying encryption) that arises in specific contexts, and presents a well-proven generic solution for it [9]. In the case of the confidentiality property, we need Fig. 2. Encryption pattern for secure communications. a set of patterns that allows to apply the encryption functionality to different parts of the application such as remote/local direct/indirect interactions, and data storage. Encryption is usually defined as a component that provides two main functionalities: encrypt and decrypt (see Fig. 2), which normally intercept (crosscut) the application functionality at specific points. For example, the pattern to apply encryption in a secure communication is shown in Fig.2 and states that the encrypt method intercepts a “sender component” (|C1) in order to encrypt the message information (|param) before sending it (i.e., calling the method |m), while the decrypt method crosscuts a “receiving component” (|C2) to decrypt the message information after receiving it. Figure 2 represents a parameterizable structural (a) and behavioral (b) view of this pattern for encrypted communications. The top of Fig. 2(a) shows the dependencies of the pattern with the architectural elements of the application architecture (Application components). The bottom of Fig. 2(a) shows the encryption component (EncryptionAlgorithm) with the provided functionality (Encryption interface). The pattern captures the information that is required to incorporate encryption into the interaction between two components. Throughout this paper, we only use the structural view for the sake of simplicity, but patterns can be complemented with additional views as shown in Fig.2(b). The partial or total instantiation of the parameters of this pattern, with information obtained from the application’s requirements, allows correctly applying encryption for straightforward communications — i.e., applying encryption to two communicating components that use a common interface. However, this pattern does not capture all the situations in which encryption may have to be incorporated. For instance, it does not allow applying encryption in situations that do not involve a communication, such as storing encrypted data in a device, or applying encryption to interactions between two non-adjacent components. Fig. 3. Variability model for the encryption patterns and encryption functionality. Thus, as it is impossible for only one pattern to cover all kinds of interactions with the application, we propose modeling the variability of the security patterns following a Software Product Line (SPL) [8]. Concretely, we extend the variability model modeling the security functionality in our previous work to enhance it with the variability of the security patterns. An SPL1allows us to specify the commonalities and variabilities of a product and then generate specific configurations of the product according to different requirements. Figure 3shows a variability model that specifies, using features in an abstract level (top of Fig. 3), the variability of the encryption patterns (left of the figure) and the variability of the encryption functionality (right of the figure). Then, specific models (e.g., the software architecture of encryption, the structural/behavioral patterns for encryption) are linked to the features of the abstract tree. Note that using existing tools for SPL (e.g., CVL [10], SPLOT [11]), the architectural models in the bottom of Fig. 3will be automatically instantiated according to the features selected from the abstract tree. Concretely, the bottom of Fig. 3shows two parameterizable encryption patterns and the model of the encryption functionality (Encryption Functionality Model), including all the 1http://www.sei.cmu.edu/productlines/. variable architectural elements. Notice that security properties are usually modeled by much more complex architectures, though in this example we only represent the encryption algorithms for the sake of simplicity. For the Encryption Functionality Model, a selection of a particular feature in the tree selects the encryption algorithm that will be used. The multiplicity feature (Encryption [1..*] in Fig. 3) indicates that both the algorithms and the patterns can be instantiated multiple times in order to use different algorithms and patterns. 3.1 Resolving the Variability of the Application Once all the variability of the security functionality and the patterns has been defined in the SPL (only once) by the domain experts, the software architect can use our approach to generate different configurations of the patterns and the security functionality according to each application’s requirements. A complete configuration of the variability model from requirements Req. 1, 2,and3of our case study is shown in Fig. 4. There are three instances of the encryption feature: one for each requirement. The first instance (Encryption for Req. 1) is configured with the RSA algorithm, and uses the Communication- Encryption pattern instantiated as shown in Fig. 5(a), with the goal of encrypting the sensitive information exchanged between the client and the server host. The second instance (Encryption for Req. 2) is also configured with the RSA algorithm, but uses two patterns (CommunicationEncryption and Response- Encryption) to apply encryption in both directions of the communications between the components EPaymentServer and BankTransaction of the same host (E-PaymentServer). Since all information exchanged between these two components is required to be encrypted, no information regarding the type of the data, nor the interface, methods, etc. is provided by the software architect. Finally, the third instance (Encryption for Req. 3) is configured with the AES algorithm, and uses the StorageEncryption pattern in order to storage the payment information in a secure way. In this case, the software architect has not instantiated any parameter of the pattern, as shown in Fig. 5(b). This could Fig. 4. Instance of the variability model for the encryption functionality and patterns. Fig. 5. Instances of the encryption patterns for (a) Req 1. and (b) Req. 3. occur when the requirements do not provide enough information, the software architect does not know how to interpret the requirements, or does not have the required knowledge to instantiate the pattern. In this case our approach identifies a larger set of join points and the software architect has to manually select the correct ones. At least it knows all the matching points that need to be considered. The encryption patterns show the parameters that can be customized according the application’s requirements. The patterns for applying encryption to the communications (Communication Encryption Pattern) and to the storage of information (Storage Encryption Pattern) are described in more details in Fig. 5(a) and (b), respectively. Providing a value in the feature tree means that this element in the pattern will be instantiated with the provided value. For instance, to satisfy Req. 1, the software architect has instantiated the Communication Encryption Pattern of Fig. 5(a) with the following parameters: the data type of the information to be encrypted (i.e., the PaymentMethod type), and the identifiers of the client and the server hosts (E-PaymentClient and E-PaymentServer). The following section explains how we correctly identify the join points from the previously customized patterns in our approach. 4 Supporting the Composition Process Once the variability model has been instantiated, now the security and the application models are composed. To achieve this, the composition patterns customized in the previous step are mapped on structures in the application architecture by using M2M transformations. The mapping process can be used in two complementary ways: (1) guiding the software architects in selecting the correct join points, and (2) supporting them in verifying their choices of join points. 4.1 Automatically Identifying the Join Points In order to identify the join points where the customized patterns have to be applied and guaranteeing that the final architecture satisfies the security requirements, the model transformations can be treated as a separate previous step to the composition process. Before the composition process, checking each instantiated pattern with our e-payment application architecture (Fig. 1) finds all possible matchings where the pattern can be applied (Fig. 6). The number of identified matchings directly depends on the number of parameters for which a specific value was provided during the instantiation of the variability model. For instance, the first instantiated pattern (Encryption for Req. 1) matches the application model in the join points Req. 1. Matching 1 and Req. 1. Matching 2 in Fig. 6. The software architect provided just the data type to be encrypted (PaymentMethod) and the hosts’ information, while the concrete components where the encrypt and decrypt methods will be composed has Fig. 6. Matchings for the encryption patterns in the e-payment architecture.