\thesection Approach Description
Figure Document gives a visual overview of the threat management life-cycle, outlining both activities in the process as well as data flow. Key to understanding the advantages of this holistic view are the threat repository and notification services in the centre, which together connect the dots between the remaining components and stages. In the requirements engineering process we utilise goal-oriented modelling (Socio-Technical Security modelling language, STS-ml [ststool]) to elicit and define security requirements. Here we also instantiate some of the main threats to our system on an organisational/business level of abstraction. Further, we use Business Process Model and Notation (BPMN) [OMG] for designing the service process of a composite web service. At this stage we do not depend upon how the requirements engineering has been done, but if STS-ml has been used, we can transform the goal models into process models with some help from a software tool. The BPMN model defines a service process which can be deployed and executed as a web service, and here should the threats be refined on a more technically detailed level. Based on this, we can ask for accordingly technical countermeasures from the threat repository. We can also define rules for responding to particular events, if we are able to monitor the service components at runtime. Whenever an alert is received from the monitors, these rules will be evaluated by a service runtime environment (SRE) tailored for this purpose. If is a match is found, a re-composition can for example be triggered, replacing a service component instance with another one providing similar functionality. Alternatively, one can move along in the life-cycle to re-design of the system and/or the particular service.
\thesubsection Case Study: Air Traffic Management
For demonstrating our proof-of-concept, we have chosen a case study based on Air Traffic Management (ATM). The European air navigation services and their supporting systems are currently undergoing a paradigm shift, most notably through the System Wide Information Management (SWIM) [swim]. Going from numerous incompatible stand-alone systems, SWIM enables cross-border collaboration and data exchange between many systems and organisations with its service oriented architecture (SOA) approach. This raises prospects for an expansive registry of composite services, which hopefully will contribute to maximizing efficiency of the airspace with time. The service we demonstrate is one that gathers various information about an airport to be used e.g. in the cases when a pilot wants a fresh report on the flight’s destination. As seen from the perspective of this service provider, further details on this composite service sample is provided along with the description of each step in our approach below. Security-experts from three ATM organisations were involved in the modelling, using already defined security requirements and system specifications from the SESAR project [sesar] through which SWIM is developed. However, the models provided in this paper only represent a limited excerpt of the SWIM system model, and the demonstrator we have implemented is not based on service components actually provided through SWIM. Work on collecting and analysing feedback from the actual case study users is yet to be completed, and results as such are hence not considered in this paper.
\thesubsection Knowledge Management Through a Threat Repository
Every part of our approach is tied together by the concept of having a centralised repository of threats . While threats can always be created and modelled independently in the different diagram types that we use, a persistent threat repository provides better conditions for import and re-use of threats [Oladimeji06securitythreat]. It is of essence here that each threat in the threat repository is associated with a unique threat identifier (ID), and that this threat ID is stored along with the threats in the various diagrams we create. This allows the tools to always access (meta-) information on threats stored in the repository, and for the threats to be passed between the models and pushed further through deployment into the runtime phase. In our proof-of-concept, we have utilised an existing online threat repository service [svrs], providing an application programming interface (API) for accessing its large collection threats externally. The API offers functionality for searching for threats in terms of their name, class (business-level or operational level), or business domain tags. Some additional meta-data may also be available, such as a textual description and links to further information resources. For the two graphical modelling tools we present below, we have implemented a plug-in that takes advantage of this API, as shown in Figure Document. In addition to the API, we have access to a web-based user interface which allows more info to be looked up on each threat, including suggestions for countermeasures and relationships with other threats. A threat uploader tool has also been developed for adding new threats to the threat repository, using existing diagrams.
Threats related specifically to ATM are found in the threat repository under the business domain selector Air Traffic Management. These threats can both be general ones that are known to also apply in that particular domain, such as Gain access to server, as well as threats more specific to ATM only – e.g. A/G SWIM Access Point Denial of Service. Generic high-level threats, like Tampering, can for instance be specialised into a domain specific threat such as False airport coordinates.
\thesubsection Requirements Engineering
While requirements engineering can take many shapes and forms, graphical goal-oriented modelling is an approach well suited for complex and distributed socio-technical systems (of systems) [sts2, PajaDPRG2013]. Where goals justify why the system and its functions are needed, threats justify why security for the system is needed.
In the STS model from our case study, depicted in Figure Document, we see that the pilot’s request for a destination report is transmitted to SWIM rather than directly to a specific service provider. Since the requesting aircraft’s destination is information already known inside SWIM, the request is complemented with this information here. Through its service registry, SWIM can select and invoke an actual service provider on behalf of the pilot/aircraft, possibly depending on the particular destination’s location. The airport report contains various local information on the airport, along with weather conditions and a map onto which various local observations (e.g. wind meter readings, contaminations) are plotted. Threats from the perspective of the airport report provider, would in this case be any kind of tampering with externally acquired data or unavailability of any of the service components, which might hold them accountable for impacting flight safety. A threat worth including could also be denial of service within the SWIM area of responsibility, since that could block an airport report to arrive timely on the provider’s behalf – although not being the airport report service provider’s actual responsibility in the end. Supported by the STS-Tool [ststool], we are able to both perform both graphical modelling as well as advanced formal analyses of the models. This includes checking consistency and detecting conflicts between goals and requirements, as well as analysing (visually in the model) how threats can propagate throughout the modelled system [goals-threats]. The STS-Tool also supports generating a security requirements document which contains the information we have added on threats. In addition, the document generator performs the aforementioned threat propagation analysis so that the results can be output in textual form, as shown in Figure Document. In our case specifically, the A/G SWIM Access Point Denial of Service threat does not have a propagated impact, and is hence not mentioned in the document, as it is directed at an actor external to the modelled system owner. Although not implemented, the document generator could potentially use the threat IDs provided in the model to look up information on countermeasures, and hence include that in the document for further reference.
\thesubsection Service Design
In the BPMN model, we specify the process flow which our composite service shall follow. Herein lies the advantage of standardised BPMN as the service process language, that the graphical models translate into well-defined execution semantics, which in turn can be executed in business process model engines as a web service. Although BPMN has no explicit language construct for threats, we have in previous work concluded that e.g. the standard ErrorBoundaryEvent element can be used for representing threats [conf/IEEEares/MelandG12]. While our BPMN model in Figure Document may appear similar to the STS model, the service tasks (yellow boxes) now represent atomic components of a process, unambiguously ordered as an executable process flow. Moreover, each service task implies a single invocation of a particular web service, taking process variables as (optional) input to operations defined by each service components’ web service definition file (Web Service Definition Language, WSDL [w3cWSDL]). Although not visible in the model, the first service task, Airport geocoding, takes as input the IATA code of an airport (e.g. FCO for Rome, Fiumicino) and queries a public airport information service. The returned value, which is also defined by the component’s WSDL file, should be a pair of coordinates which pinpoint the airport’s geographical location. These coordinates are in turn used as input for the following two tasks, which can be done in parallel, namely to obtain the weather and any local observations from/surrounding the location in question. A fourth service takes care of plotting the gathered information on a map, whereas the final (internally maintained) service wraps up and creates the report data to be returned to the pilot’s application.
We have extended the Activiti Designer tool [activiti], built as a plug-in for the Eclipse IDE [eclipse], in order to support our BPMN modelling. We have chosen to store the threat ID in the BPMN 2.0 XML file, as shown in Figure Document, which is in line with the standard. This results in compatibility between different modelling tools, at least when it comes to portability of the graphical model. What is not part of BPMN is functionality for producing several alternative composition plans, i.e. alternative combinations of service components, that each provide the very same functionality . This is possible when you have more than one possible candidate services for a service task, while still maintaining the required level of functionality. In our proof-of-concept, we have two candidates for the map service. The total number of composition plans equals the Cartesian product of all service component candidates for all service tasks, i.e. all possible combinations of service implementations. These different composition plans can in turn be ranked against one or several criteria, such as level of trustworthiness, quality-of-service, etc., if this information is maintained on behalf of the components [achim, brucker.ea:framework:2013].
\thesubsubsection Model Transformation
In order to support security information from the requirements engineering phase to be maintained at development time, essential parts from the goal models are possible to transform into a simple process model skeleton. The STS-Tool is not only, as previously described, able to output a textual description of the security requirements and threats. The STS-models can also be output to a machine-readable security requirements specification (SRS) format for use in the transformation. Although there is no way to completely automate the transformation from STS to BPMN, a transformation tool can provide a structured way to manually support selection of threats that are relevant for the service process model [aniketosD52], as shown in Figure Document.
Transformation of STS-ml threats into BPMN threats is preferable in cases where we have input from monitors that can give the modelled threats a meaningful role at runtime. An advantage of the tool-supported model transformation is that the threat ID, which enables linking a modelled threat to the threat repository, can be conveniently transferred between the models. In that way, any further transformation and use of the threat can be done with support from the threat repository, and the information always to be found here. In our case study, we have Unavailable component as a threat in the goal model, which can be specialised into e.g. a DDoS attack on service component threat in the service process. This threat can be fairly easy to monitor, and we hence are potentially able adapt our service in case this threat escalates.
\thesubsubsection Threat Response Recommendations
A separate component, also integrated with the online threat repository, implements logic and knowledge to find and recommend possible mitigations for threats [aniketosD43]. These countermeasures can potentially be provided in various formats, ranging from textual descriptions to actual code or services.
In order to obtain the threat response recommendations, the threat IDs are gathered from the BPMN diagram and the relevant ErrorBoundaryEvent elements. Again, the threat ID is input to the threat repository, and returned are the countermeasures. As there may be several countermeasures available for each threat, the various options are ranked before being presented to the service designer.
\thesubsubsection Rules Definition
Not only finding appropriate countermeasures, but actually implementing those that are appropriate, is essential to improve security of the service. Based on threats defined in the diagram and any other events that are monitored and one can be notified about, rules can be defined to address the scenarios we are able to foresee. Rules assume some kind of monitoring in place to provide actual value, but as long as the format can match what the SRE is able to interpret from the individual monitors, the rules are in practice agnostic to monitoring implementations.
The service tasks form the basis for defining such rules, as shown in Figure Document. The tasks are both accurate in targeting the rule’s scope, yet independent of the actual service implementation we choose. Therefore, we do not need to define individual rule-sets for each potential composition plan. In our case study service process we have already modelled a DDoS-attack occurs on service component threat, and this can be addressed by choosing Threat level change as the event type, and then selecting the service task it applies to. For values in the rule, we choose a decimal number between 0 and 1 (inclusive). This matches our threat monitoring module, which can send alerts with probability value for the escalation of threats [aniketosD43]. Further, in the scope section of the rule editor, it is possible to define where in the process the rule shall apply. If a particular threat escalates for a component, we might not need to perform reactive measures unless it happens before, after or during the execution of a particular task in our process. Anyhow, we have several options for also defining the action to perform when the rule is matched, such as simply stopping the service execution (and further provision), or trying to recompose or reconfigure the service. We also have an option to launch an additional service process, e.g. one that might initiate hardening of other parts of the system, and/or send notification messages to clients and/or service technicians. In the end, we might end up with a list of several rules for several service tasks, or simply one for the one we have defined in our case study, as shown in Figure Document.
\thesubsection Runtime Management
In order to operate a self-adapting service infrastructure at runtime, a commonly supported system for machine-to-machine (M2M) messaging is needed. Since there may be an endless number of services and SREs utilising this infrastructure, we cannot provide all messages to everyone. A publish-subscribe pattern is rather suitable, since we already define rules for what we need to respond to. Hence, appropriate subscriptions can be derived automatically from these rules and registered by the SRE. The SRE will then receive notifications only as specified, although the granularity of the rules will determine the relevance of e.g. slight variations in threat level probabilities (not all changes will actually trigger an action). The SRE in our proof-of-concept creates subscriptions based on the rules which are attached to service deployment. It receives notifications according to the subscriptions, and whenever such notifications arrive, all rules are being checked for a match. The messaging system is based on Apache ActiveMQ [activemq], which utilises the Java Messaging Standard (JMS) to provide compatibility for many platforms and alternative protocols. ActiveMQ subscriptions are registered with a centralised broker, or network of brokers for horizontal scalability, since it is the broker(s) that deal with receiving and dispatching the notifications to all subscribers. Our broker is in addition deployed on a cloud-based infrastructure, for further increased scalability. In addition to threat level changes, we have implemented support for notifications about changes in trustworthiness, service contract violations, security properties of service components, service runtime context, and service component changes. The notifications are delivered on a best-effort basis, and may of course arrive too late in some cases (depending on how quickly a problem is discovered and duration of the attack).
\thesubsubsection Dynamic Adaptation
Since a threat monitor has now purportedly detected that the original map service used in our case study is hit by a DDoS-attack, the SRE becomes notified about this through the notification service. In order to trigger events in the self-configuring service process, the SRE must naturally be able to receive such notifications and align these with the previously defined and deployed rules. As it finds a match with the rule we defined earlier on DDoS-attacks, the SRE initiates the specified action according to that rule, which is here to try a recomposition. Since we had support for two different map services providing the same functionality, we have prepared an additional composition plan for the airport report service. When the notification concerning a DDoS-attack on the map service is triggered and received by the SRE, the first plan no longer satisfy our security requirements through verification [zhou2012secure]. Since the rule in Figure Document provides the match, a recomposition is initiated accordingly. The original composition plan with the DDoS-ed map service will be ignored, and the second plan becomes the top-ranked one based on a chosen ranking criteria. The recomposition proceeds with deploying the second composition plan, containing the alternative map service instead of the original one. Nevertheless, the same level functionality is provided, as illustrated with Figure Document where the airport reports, before and after recomposition, are lined up next to each other. Before the new composition is deployed, the SRE invokes a runtime verification, and the time this takes depends on the complexity of the composition. This is a well-known scalability issue associated with any kind of runtime adaptation.