Keywords

1 Introduction

Future Internet (FI) systems encompass a set of pervasive computing devices (e.g., smartphones, vehicles, wearables) always connected to the Internet and continuously exchanging information with remote entities [1]. In order to ensure that the exchange of information is performed securely, the development of such systems requires the creation of a set of security mechanisms that are able to protect the system against different threats that may arise. For instance, let us consider the following case study: an Intelligent Transportation System (ITS) application that dynamically recommends the speed limits for a road according to climate conditions and to unexpected events like accidents or traffic jams, collects the information sent by both the vehicle’s sensors (e.g., geolocation, current speed) and the road side sensors (e.g., weather conditions, traffic status). Then, using this information the new recommended speed limit is calculated and notified to the driver on his On Board Unit (OBU). Some of the security requirements that could be taken into account in the development of this application are: (1) the user anonymity must be assured, otherwise, some users will not agree to send their current speed and location; (2) only authorized users subscribed to the service can send information to the ITS server and receive recommendations, and (3) in some contexts (e.g., when a police car is pursuing an offender) all the information sent by the police car should be cyphered in order to hide the information from the infractors.

The main problematic of enabling security in FI systems is the heterogeneity and dynamicity of the security policies that determine how the different parties need to interact with each other. On the one hand, the security policies can be heterogeneous because each user can customize his own security policies that answer their security constraints and they can also be different from the security policies expected by the applications. On the other hand, the security policies can be dynamic and can change over time to adapt to new requirements, new regulatory rules or new application contexts, for instance moving from one country to another. In this context, there is a lack of sufficiently rich techniques to tackle the problem of security policy modeling, interoperability, deployment, enforcement and supervision. Moreover, focusing on dynamic security enforcement, there is also a lack of solutions that allow the dynamic adaptation of security to new application requirements and changes in the environment.

In order to solve these issues, the Inter-operable Trust Assurance Infrastructure (INTER-TRUST) framework [2] aims to deal with the problematic of enabling security in heterogeneous and pervasive systems, modeling secure interoperability policies with different constraints, and enabling the dynamic and secure establishment of trusted relationships between systems [3]. The main contributions of the INTER-TRUST framework are the dynamic specification of security policies, the dynamic deployment of security policies, the dynamic monitoring of security policies and the fuzz and active testing of security policies. In this paper we focus on the second and third contributions. The dynamic deployment of security policies is performed by using one of the most used enhanced deployment mechanisms to inject dynamic behavior: Aspect Oriented Programming (AOP) [4]. AOP is used to add/implement security aspects (i.e., anonymity, authentication, integrity, encryption, etc.) to application components at runtime so that applications can dynamically adapt their behavior for required/negotiated security policies. However, the dynamic deployment mechanism can introduce new vulnerabilities and security risks, and thus INTER-TRUST incorporates dynamic monitoring and testing techniques to obtain enriched information of the system’s execution, which is used to verify the conformity with the implementations, ensuring a secure interoperability between systems. In this paper, we present an approach to detect changes in the environment and checking that the communicating parties respect the negotiated security policies by maintaining the correlation between the security policies, the security aspects, and the security properties of the monitoring tool. The dynamic monitoring of the security policies allows FI applications to have a global understanding of the changes performed at runtime and can automatically react to new risk or threats that may arise. This approach represents a generic solution that can be applied to many types of pervasive applications.

The rest of the paper is organized as follows. Section 2 explains the correlation between the security policies, the aspects, and the security properties; and briefly overviews the INTER-TRUST framework. In Sect. 3 we present our approach to deploy the security policies and monitor that correlation. Section 4 evaluates the overhead performance of our approach and Sect. 5 discusses related work. Finally, Sect. 6 concludes the paper and presents our future work.

2 Correlation Between Security Policies, Aspects and Security Properties

The correct enforcement and dynamic adaptation of the security policies is based on two cornerstones (see Fig. 1). The first is the correlation defined between the security policies that need to be enforced, the security aspects that are deployed/undeployed in order to enforce those security policies and the security properties that are activated/deactivated in order to check whether or not the system is behaving according to the specified security policies. The second is the monitoring at runtime of this correlation in order to detect any attack that breaks it. These attacks could occur due to different kinds of security vulnerabilities (e.g., an attacker could send a huge number of legitimate requests to a server to monopolize its resources), or due to those vulnerabilities that are introduced by the dynamic deployment mechanism itself (e.g., a malicious aspect). For instance, in order to monitor the correct deployment of the security policy shown in Fig. 1, with three rules that indicate that the system is required to cypher the messages, to ensure the user’s anonymity and to allow only the interaction of authorized users, a set of security properties associated with these rules needs to be activated in the monitoring tool. In Fig. 1 we have shown an example of the security property that needs to be verified to ensure that the messages are correctly cyphered. Also, for each rule in the security policy, a set of aspects that fulfill the required functionality are deployed inside the application. For instance, the encryption and decryption aspects are deployed to cypher the messages, the authentication, privacy and pseudonymous certificate aspects are deployed to ensure the user anonymity, and the authorization aspect are deployed to provide user authorization. Finally, the application with the aspects is monitored and the captured traces are sent to the monitoring tool that correlates the deployment of the aspects with the security properties. Note that this correlation must be maintained, both when the user joins the application for the first time (i.e., after the deployment of the initial security policies) and also at runtime, when the security policies are dynamically negotiated and adapted.

Fig. 1.
figure 1

Correlation of the security policies, the aspects, and the security properties.

Full size image
Fig. 2.
figure 2

Architecture of the INTER-TRUST framework.

Full size image

The modular architecture of the INTER-TRUST framework that implements the correlation described is shown in Fig. 2. In INTER-TRUST, security policies rely on the OrBAC model [5], and are first specified using a Security Editor (e.g. MotOrBac [6]) and then negotiated between the different parties (e.g. a vehicle and an ITS server in the context of a Vehicle-to-Infrastructure communication) using a Negotiation module (see the Dynamic Specification of Security Policies block in Fig. 2). The negotiated security policies are analyzed and interpreted by the Policy Engine and the Policy Interpreter modules. These modules are responsible for identifying changes in the security policies that require the security concerns deployed inside the application to be adapted. Security policies are dynamically deployed, and/or adapted at runtime using the Aspect Generation and the Aspect Weaver modules, which are in charge of receiving the information generated by the Policy Interpreter module and of incorporating or eliminating the corresponding security aspects in the application (see the Dynamic Deployment of Security Policies block in Fig. 2). Security aspects can be developed in any Java-based AOP language such as AspectJ, Spring AOP, CaesarJ, or JBoss. The aspectual knowledge depicted in Fig. 1 contains the functionality provided by the aspects for each security policy and the join points where the aspects can be deployed.

Negotiated security policies are also sent to the Monitoring Tool in order to activate/deactivate the associated security properties that control the fulfillment of the security policies by the deployed aspects. Security properties are formally described as conditions in sequences of events [7] based on Linear Temporal Logic (LTL) to define security rules (i.e., rules that should be respected) or attacks and misbehaviors [8]. The Monitoring Tool relies on an adaptation of the Montimage Monitoring Tool (MMT) [9] which is an online monitoring solution that allows a real-time network traffic, application, flow and user level visibility to be provided. The Notification and Context Awareness modules notify the Monitoring Tool about application’s internal events and changes in the application context — e.g. network packets, battery of the device, CPU consumption, etc. (see the Monitoring (Test and Operation phases) block in Fig. 2). Finally, different fuzz [10] and active [11] testing techniques are also provided as part of the framework (Fuzz Testing Tool and Active Testing Tool modules) in order to test the application’s security and robustness. During the testing phase the MMT tool monitors the traces automatically generated by the fuzz testing and active testing tools in order to simulate the application behavior (see the Testing for Vulnerabilities Detection block in Fig. 2).

In this paper, we focus on the dynamic deployment of the security policies and on the monitoring phase, while the details of the dynamic specification of security policies and the testing phases are beyond the scope of this paper.

3 Deployment and Monitoring Approach

Figure 3 provides a more detailed description of the dynamic deployment of security policies (activities labeled 1, 2, and 3) and the monitoring mechanism to maintain the correlation between the security policies, the security aspects, and the security properties (activities labeled 4, 5, and 6).

Fig. 3.
figure 3

Our approach for deploying and monitoring security policies.

Full size image

3.1 Dynamic Deployment of Security Policies

When a security policy needs to be deployed inside the application at runtime (activity labeled 1 in Fig. 3) — e.g., due either to the initial deployment or to a (re)negotiation of the security policy, the new security policy is sent to the modules of the framework in charge of: (i) the Dynamic Deployment of Security Policies, which will deploy/undeploy/reconfigure the aspects, and (ii) the Dynamic Monitoring of Vulnerabilities, which will activate/deactivate the corresponding security properties. In order to deploy the security policy, the Aspect Generation module receives a security deployment specification (activity labeled 2) that is the result of interpreting the security policy and contains the list of security aspects that must be deployed (woven), undeployed (unwoven), and reconfigured (i.e., changing the configuration parameters such as the digital certificate in an authentication aspect) within the application to enforce the new security policy. The Aspect Generation module also receives the required aspectual knowledge that contains the list of aspects available in the aspect repository of the framework.

The Aspect Generation module performs a mapping between the required security functionalities and the aspects that provide these functionalities. The output of this mapping is a new configuration that is analyzed to: (1) obtain the differences between the new and the current configurations of the aspects deployed within the application, and (2) generate a security adaptation plan with the list of actions that must be performed over the aspects: weave, unweave, or reconfigure. The security adaptation plan generated by the Aspect Generation module is sent to the Aspect Weaver module that is in charge of executing the actions by interacting directly with the aspects (activity labeled 3). The Aspect Weaver module is a wrapper that translates the list of actions received as input (which is specified independently of a particular AOP language/framework) to the particular syntax of the AOP weaver being used. This means that we provide different instantiations of the Aspect Weaver module for using different AOP weavers, since the use of a unique AOP solution does not cover all the dynamicity, expressiveness, and performance requirements that the applications may need (e.g., AspectJ does not support runtime weaving).

Listing 1.1 shows an example of an encryption aspect using the AspectJ language. The aspect defines two main pointcuts: encrypt (line 5) and decrypt (line 6). Each pointcut defines the points where the messages will be encrypted (line 2) or decrypted (line 3). To control the activation of the pointcuts we use the if() pointcut constructor that AspectJ provides to define a conditional pointcut expression which will be evaluated at runtime for each candidate join pointFootnote 1. This mechanism increases the degree of dynamicity by coding patterns that can dynamically support enabling and disabling advice in aspects [12]. In our example, the AspectsStatus class contains the configurations and status (enabled/disabled) of the aspects that are changed at runtime by the Aspect Weaver module. The aspect defines two advice associated with the encrypt and decrypt pointcuts: one for encrypting (line 8) and one for decrypting (line 14) CAM messages. The advice use a CypheringModule object that provides the functionality for encryption and decryption and is configured with the algorithm and parameters indicated in the AspectsStatus class (lines 9 and 15).

figure a

Once the aspects have been adapted, the Aspect Weaver module notifies the Monitoring Tool in order to inform about the status of the deployment (activity labeled 5). That is, to notify whether or not the deployment was successfully carried out and which aspects were deployed/deployed/reconfigured.

3.2 Dynamic Monitoring of Security Policies

In order to maintain the correlation between the security policies, the aspects, and the security properties, the application and the aspects are monitored at runtime by the Notification module. The Notification module reports the application’s internal events (e.g., traces with state changes, error conditions, timestamps, method status, etc.) to a monitoring server (the Monitoring Tool) (activity labeled 7 in Fig. 3). To operate at runtime, the Notification module is introduced into the target application as an aspect in the instantiation phase. The target source code is annotated, using standard Java annotations, to specify the measurement points (or meters) that generate the monitored data. These annotations are also incorporated using AOP without manually modifying the source code of the application. While the target application is operating, the Notification module produces a stream of log messages. Measurement points can be attached to classes, methods and attributes, and work on two different levels of scope: local and recursive. Meters operating at the local scope level are always marked by an annotation. Only annotated elements are effected by local scope meters (e.g., calls to nested methods are not tracked). In the next scope level, recursive monitoring, beside the annotated code, all code reachable through control flow is monitored, up to the available call depth. Recursive monitoring may cause a significant performance overhead, so this kind of monitoring should be used by annotating only relevant data for security analysis. Call depth is limited by the available source code, because static aspects operate by modifying accessible source code. The instrumentation therefore does not penetrate pre-compiled classes, such as .class files or system libraries.

Furthermore, the Context Awareness module notifies the Monitoring Tool but, in contrast to the Notification module, the Context Awareness monitors changes in the environment (activity labeled 8) — i.e., contextual changes that are external to the application such as packets over the communication network, battery status of the device, CPU consumption, etc. Both traces and context changes are sent to the Monitoring Tool that interprets them (activity labeled 8 in Fig. 3) so it can react to changes or adapt the security rules with the negotiation of a new security policy.

The right-hand side of Fig. 3 shows an excerpt of a sample trace received by the Monitoring Tool with three events generated from the Notification module. For instance, the first event (event with name Pursuing_DCL) provides the values of the attributes captured by the monitoring annotation. When the first event arrives, the Monitoring Tool checks whether it fits one or more of the events defined in the security property (Fig. 1). In the example, the first event received fits the event of the property event_id="1" that corresponds with a change in the context. The second event received with the name DSA_Encrypt fits the event event_id="2" of the property by checking the values of the attributes received in the event with the boolean expression defined in the property. The class object captured is an instance of the DSAEncryption aspect that is deployed inside the application of the police vehicle and is using the DSA algorithm to encrypt the messages. Other attributes such as the key and the type of the key are also checked against the rule defined in the security property. As the two events received have a delay of less than one second as defined by the security property, the two events consecutively match the rules of the security property. So, in this example the Monitoring Tool checks that the CAM messages sent by the police vehicle are being encrypted in the context of a pursuit, and verifies the correct deploying of the encryption aspect required by the security policy, maintainig the correlation between the three parts. A non-match condition in the boolean expression of the rules in the security property, for instance, if the event with the name DSA_Encrypt does not occurr, or if the algorithm attribute is different to DSA. This means the non-match of the entire security property, and thus the detection of a gap in the correlation between the security policy, the aspects and the security property.

4 Evaluation

We quantitatively evaluate the performance overhead of the dynamic deployment of security policies and the dynamic monitoring of the application. Also, as part of our participation in the INTER-TRUST project, the deployment modules (the Aspect Generation and the Aspect Weaver)Footnote 2, the monitoring modules (the Notification and the Context Awareness)Footnote 3 as well as the Monitoring ToolFootnote 4 have been used to implement a demonstrator of the project that provides dynamic adaptation of security policies for two real case studies: the ITS case study presented in this paper and an online electronic voting case study.

4.1 Performance of Deployment

The performance overhead of the deployment process considers the time from the reception of a security deployment specification in the Aspect Generation module to the execution of the adaptation plan by the Aspect Weaver. We consider the number of aspects that need to be dynamically adapted (i.e., woven, unwoven, or reconfigured) in order to fulfill the required functionality specified in the security policy. The experiments were done on a laptop Intel Core i3 M350, 2.27 GHz, 4 GB of memory, and with 1.7 JVM. Aspects were implemented in AspectJ and Spring AOP. The results are summarized in Fig. 4 where the performance presents a linear increment of the overhead over the number of aspects. For instance, the adaptation process takes 320 ms for deploying 20 aspects specified in the security policy. Reconfiguring aspects takes 20 ms more on average than deploying them, while undeploying aspects takes 15 ms more than deploying them. The results indicate that adapting security policies with AOP at runtime does not suppose a high overhead.

Fig. 4.
figure 4

Performance of deployment security policies.

Full size image

4.2 Performance of Monitoring

The performance overhead of the dynamic monitoring considers the time overhead introduced at runtime when the Notification and Context Awareness modules are integrated as aspects inside the application. We evaluated the time overhead for generating the traces for the most expensive monitor annotation — i.e., the recursive annotation that tracks all methods encountered by the control flow from the annotated method. Figure 5 shows the time overhead based on the number of join points captured. We can observe that the performance presents a linear increment of the overhead over the number of join points while this number is lower than 100. Then, from 100 join points, the increment is higher but still linear. In all cases, the results obtained do not suppose a significative overhead. For instance, monitoring 10,000 join points in the control flow of a method takes 250 ms on average. The analysis of the generated traces is carried out by the Monitoring Tool which is independent of the application and can reside in a different computer, and thus, the analysis of the traces does not affect the application’s performance.

Fig. 5.
figure 5

Performance of monitoring join points at runtime.

Full size image

5 Related Work

The analysis of existing research work and standards in the domain of FI and pervasive systems reveals a common problem: the inexistence of a proper security framework to secure the communications flexibly and efficiently ([13, 14]). In [13], the authors propose a framework for specifying, deploying and testing access control policies independently of the security model. The main drawback to this approach is that the generic meta-model only supports access control policies, and thus, it is not possible to specify and deploy other security concerns such as integrity, encryption, or non-repudiation, as the INTER-TRUST framework can. In [14], an Aspect Oriented Permission System (AOPS) for runtime policy enforcement is presented. The policy decisions are based on the execution history-based access control model (HBAC) [15] and implemented in AspectJ following the Java permissions model but applied to AOP. Only security vulnerabilities related to access control permissions are considered (e.g., restricted rights to read and modify attributes of the base system by the aspects). Also, the approach assumes that the weaver as well as the execution environment are trusted, and that the weaver protects against scenarios in which untrusted aspects are incorrectly woven into the application code.

AOP vulnerabilities are well-known and have been identified during the development activity [16–19]. In [16], the authors present bug patterns in AspectJ and illustrate the symptoms of the patterns through examples. The security risks in using AOP to develop secure software are analyzed in [17] from a programming level point of view. An aspect permission system is also proposed to address some of the issues identified (e.g., parameter alteration, invocation hijacking, use of privileged aspects, etc.). In [18], the authors use a combination of static code analysis and protection code generation during the development phase. They focus on security vulnerabilities caused by missing input validation — i.e., the process of validating all the inputs for an application before using it. They analyze the source code and/or binary code without executing it and identify anti-patterns that lead to security bugs. The unexpected vulnerabilities that the dynamic weaving may introduce when the aspects are woven at runtime cannot be covered with the static analysis. In [19], aspect orientation is used to monitor the information flows between objects in a system for the purpose of detecting misuse. That is, identifying behavior that is close to some previously defined pattern signature of a known intrusion. The problem with misuse-based detections is that the anomalies must be known in advance and cannot detect new vulnerabilities at runtime.

Apart from monitoring, there are several techniques to perform dynamic detection of failures in the deployment of security policies such as active testing [11] (to validate the implementation by applying a set of test cases and analyzing its reaction) or fuzz testing [10] (to detect unwanted behaviors or security violation by using random or mutated inputs). However, although these testing techniques are incorporated in the INTER-TRUST framework, these are not suitable to use at runtime as monitoring can be, but are applied at the testing phase.

Finally, the modular architecture of the INTER-TRUST framework allows its integration with different middlewares such as FamiWare [20] in order to provide security and privacy to wireless sensor networks; and with security adaptation services such as a MAPE-K loop approach [21].

6 Conclusions and Future Work

We have defined an approach to maintain the correlation between the security policies that need to be enforced, the security aspects that are deployed/undeployed in order to enforce those security policies and the security properties that are activated/deactivated in order to check whether or not the system is behaving according to the specified security policies. Our approach has been integrated as part of the INTER-TRUST framework, however, it can also be applied to many other types of pervasive systems in other contexts independently of the INTER-TRUST framework, and can also be used to adapt other functionalities implemented as aspects (not only security).

As for future work, we plan to complete our approach by dynamically generating the structure of the aspects and the security properties from the security policies minimizing the aspectual knowledge needed to maintain the correlation.