Security analysis is growing in complexity with the increase in functionality, connectivity, and dynamics of current electronic business processes. To tackle this complexity, the application of models in pre-operational phases is becoming standard practice. Runtime models are also increasingly applied to analyze and validate the actual security status of business process instances. In this paper we present an approach to support not only model-based evaluation of the current security status of business process instances, but also to allow for decision support by analyzing close-future process states. Our approach is based on operational formal models derived from development-time process and security models. This paper exempli es our approach utilizing real world processes from the logistics domain and demonstrates the systematic development and application of runtime models for situational security analysis.
Electronic business processes connect many systems and applications. This leads
to an increasing complexity when analyzing distinctive properties of those
business processes. Additionally, frequent changes to business process models are
applied to address changing business needs. Current approaches apply changes
to those models at runtime [
Traditionally, approaches to security analysis of electronic business processes
are executed at development-time. In this perspective, the analysis of possible
violations of security policies is part of the requirements engineering process
[
Contributions. To support security analysis at runtime we utilize formal
models based on development-time process and security models. On the basis of
sound methods for the elicitation and modeling of security requirements provided
in [
security events present time
Feasible security violations future time
In section 2 we provide an application scenario from the logistics domain and elicit security requirements. The formalization of the scenario is given in section 3. Section 4 analyzes the runtime operation and exempli es generated security alerts. Section 5 reviews shortly related work to our approach. Concluding remarks and further research directions are given in section 6. 2
In order to demonstrate what kind of security requirements we are able to consider and how our model-based runtime analysis is applied, we have chosen a small part of a \Pickup" target process which is analysed in the project Alliance Digital Product Flow (http://www.adiwa.net/). 2.1
Process and Event Model The \Pickup" process is initiated when the truck driver is noti ed about new pickup orders. He accepts the received list of orders and the system calculates a route plan based on the addresses. When the driver arrives at a pickup address, he checks visually the packages for deviations with regard to the description in the order. In case of deviations he consults with the sender whether this package is to be transported. If the truck driver accepts the new package, the package description in the list of orders is updated accordingly. For each accepted package the system receives a con rmation that it has been loaded. The system links each loaded package and its transporting truck using the corresponding radiofrequency identi cation (RFID) tag identi ers. An Event-driven Process Chain (EPC) owchart of the considered subprocess is depicted in Figure 2. Rectangles with rounded corners denote actions and chamfered rectangles denote events.
As an example of a security threatening misuse case, we consider a situation where the system performs a rescheduling because of a delay of one or more trucks on the basis of not con rmed Global Positioning System (GPS) locations. In this case there is a possibility for an attacker to send false GPS data to the system, which may result in ine ective rescheduling and possible time loss in completing the orders. 2.2
Security Requirements Elicitation
In order to derive the security requirements in the given scenario, we follow the
scheme described in [
send(route) recv(pos)
replan(routing) recv(schedule) prio(payload) gpsx(pos) recvx(route)
recv(flight) send(schedule)
We apply a general security goal: Whenever a certain output action happens,
the input actions that presumably led to it must actually have happened. As an
example for a speci c security goal, in the following we will use the authenticity
requirement: Whenever a rescheduling action is performed, the GPS coordinates
of each truck should be authentic for the dispatcher in terms of origin, content
and time. The formal syntax to describe these requirements in parameterized
form is de ned as (see [
Therefore, our selected authenticity requirement can be written as: auth(gpsx(pos); replan(routing); dispatcher): (Auth 1)
We will use the authenticity requirement (Auth 1) to describe the reasoning process with the help of an appropriate operational model.
There are of course many other security requirements necessary in this scenario. For example, while loading a package on the truck the RFID data and the truck driver should be authentic in terms of content and identi cation number. Analysis and application in our situational security analysis follow the same procedure as for (Auth 1). Therefore, we will exemplify only (Auth 1) in the following. 3
In order to analyze the system behavior with tool support, an appropriate
formal representation has to be chosen. In our approach, we use an operational
nite state model of the behavior of the given process which is based on
Asynchronous Product Automata (APA), a exible operational speci cation concept
for cooperating systems [
De nition 2 (Asynchronous Product Automaton (APA)). An Asynfcahmroinlyouosf PstraotdeuscettsAZutso;msa2toSn, aAfa=mi(l(yZosf)s2elSe;m( ent tary automata ( t; t), with ; t)t2T; N; q0) consists of a t 2 T, a neighborhood relation N : T ! P(S) and an initial state q0 = ponents and osf2eSle(mZse)n.taSryanadutoTmaartea iannddexPs(eSt)s iswitthhe tphoewneramseets ooffSs.taFtoer ceoamch(q0s)s2S 2 elementary automaton ( t; t) with Alphabet t, its state transition relation is t s2N(t)(Zs) t s2N(t)(Zs). For each element of t the state transition relation t de nes state transitions that change only the state compathological cases it is generally assumed that N (t) 6= ; for as2llSt(Z2s)T..TAonaveoliedponents in N (t). An APA's (global) states are elements of mentary automaton ( t; t) is activated in a state p = (ps)s2S 2 s2S(Zs) as to an interpretation i 2 t, if there are (qs)s2N(t) 2 s2N(t)(Zs) with ((ps)s2N(t); i; (qs)s2N(t)) 2 t. An activated elementary automaton ( t; t) can execute a state transition and produce a successor state q = (qr)r2S 2 s2S(Zs), if qr = pr for r 2 S n N (t) and ((ps)s2N(t); i; (qs)s2N(t)) 2 t. The corresponding state transition is (p; (t; i); q).
A simpli ed model of the part of the \Freight Forwarder" business process shown in Fig 2 contains the APA state components pstate and event representing the current process state and event. Formally, S = fpstate; eventg, with Zevent = fimminent truck delay; : : : ; replan; :replang, Zpstate = : : :.
The elementary automata T = fidentif y critical payload; : : : ; select plang represent the possible actions that the systems can take. The neighborhood relation between elementary automata and state components of the APA model is depicted by the edges in Fig. 4.
identify critical payload compute replan proposals Formally, the behavior of our operational APA model of the business process is described by a reachability graph. In the literature this is sometimes also referred to as labeled transition system (LTS).
De nition 3 (Reachability graph). The behavior of an APA is represented by all possible coherent sequences of state transitions starting with initial state q0. The sequence (q0; (t1; i1); q1)(q1; (t2; i2); q2) : : : (qn 1; (tn; in); qn) with ik 2 tk represents one possible sequence of actions of an APA. State transitions (p; (t; i); q) may be interpreted as labeled edges of a directed graph whose nodes are the states of an APA: (p; (t; i); q) is the edge leading from p to q and labeled by (t; i). The subgraph reachable from q0 is called reachability graph of an APA.
We use the SH veri cation tool [
q4
During runtime, the events from the business process are used to synchronize
the state of the model with the real process. In our exemplary setup, the events
are produced by a Complex Event Processing (CEP) engine which is provided
by one of the project partners. The events are described by an XML schema and
communicated by the Java Message Service (JMS). The events from the event
bus are used to provide the information about the state and input to the business
process. In our nite state model, this information is represented in the state
components pstate and event (cf. Fig. 4). This constitutes the initial state of
the model from which a simulation is then started. In addition to the predicted
system behavior, we also need the information on the security requirements in
order to identify critical situations. In [
Security Reasoning { No Authenticity Approval of GPS Event In order to demonstrate the use of process models at runtime, let us assume the following situation. We are currently at logical time 0 as depicted on the timeline in Figures, 7, 8, 9, 10. We further assume that the trusted agent inspects the events generated by GPS units of the trucks and sends additional events which attest to the authenticity of each GPS event within a timeframe of 2 logical time units. Please note that it is also a possibility that the trusted agent would lter the events and only let authentic events pass the lter. We furthermore assume that we know from the analysis of dependencies of actions and speci cally from the requirement (Auth 1) that whenever a rescheduling action is performed, the GPS coordinates of each truck should be authentic for the process planner in terms of origin, content and time.
We now describe the reasoning process where the authenticity of the GPS event is not approved by the trusted agent. In the diagrams we use pentagon symbols to depict events on the event bus such as GPS information and we use triangles to depict Security Warnings (SW), Predictive Security Alerts (PSA) and Security Alerts (SA) generated by the reasoning process.
GPS 0 1
Auth 2 3 4
5 Timeline 6 7 8 9 Figure 6 shows the situation when a GPS event is received. This event is matching a precondition in the requirement pattern: GPS needs con rmation in 2 steps. This requirement (warn-level) is triggered by the GPS event. The reachability analysis reveals no critical actions within the scope (3 steps) of the analysis. We conclude from Fig. 6 that everything is OK at this point. A future event might con rm authenticity of the GPS location received.
GPS -2
-1 GPS Figure 7 shows the situation when an expected event from the trusted agent, namely the authenticity approval of this GPS event is recognized as missing. The missing event indicates a broken security requirement: GPS needs con rmation in 2 steps. The reachability analysis in this situation shows that no other security requirement will be triggered within the scope of the analysis. However, some forthcoming security relevant action might require authenticity of this GPS event. Therefore, an alert action associated with a broken warn-level requirement, such as issuing a security warning (SW), is now triggered.
PSA 1 2 replan 3 In Fig. 8, an arbitrary event is received from which, in one possible execution sequence of the business process, a replan event is reachable within the scope of the analysis. In our scenario imminent truck delay is such an event. The reachability graph is similar to the one depicted in Fig. 5. It shows that the select plan action may happen in the future if replan is chosen. But there GPS GPS is another possible path in the graph where replan is not chosen. The replan event in the prediction scope is matching a precondition in a requirement pattern: auth(GP S; replan; dispatcher), but the GPS event is not approved to be authentic. Therefore, a replan event with broken security requirement is possible. An action associated with this (possibly) broken alert-level requirement, such as issuing a predictive security alert (PSA), is now executed.
Figure 10 shows the situation when a replan event is not received as expected (cf. Fig. 5 transition q2 ! q5). In this case, we know that the issued predictive security alert (PSA) was a \False Positive", so a corrective action may be necessary. Corrective actions might be the reduction of a general security warning level or lifting of restrictions on the business process depending on the operating environment. However, the security warning issued in step 2 is still valid because some future event might require authenticity of the GPS event. Figure 9 shows the situation when a replan event is received as predicted (cf. Fig. 5 transition q2 ! q4). At this time we know that the security requirement (Auth 1) is broken. Therefore, an action associated with a broken alert-level requirement, such as issuing a security alert (SA), is now executed. Step 4b: Predicted replan event not received after step 3
PSA
PSA replan
The work presented here combines speci c aspects of security analysis with
generic aspects of process monitoring, simulation, and analysis. The background
of those aspects is given by the utilization of models at runtime [
Security analysis at development-time to identify violations of security
policies is usually integrated in the security requirements engineering process. An
overview of current security requirements engineering processes is given in [
Process monitoring has gained some popularity recently in the industrial
context prominently accompanied with the term Business Activity Monitoring
(BAM). The goal of BAM applications, as de ned by Gartner Inc., is to process
events, which are generated from multiple application systems, enterprise service
buses or other inter-enterprise sources in real-time in order to identify critical
business key performance indicators and get a better insight into the business
activities and thereby improve the e ectiveness of business operations [
Di erent categories of tools applicable for simulation of business processes
including process modeling tools are based on di erent semi-formal or formal
methods such as Petri Nets [
In this paper we demonstrated the application of runtime models to analyze the security status of business processes and to identify possible violations of the security policy in the near future. Therefore, we started with a business process model from the logistics domain and analyzed corresponding security requirements. Utilizing both development-time models we derived a runtime model. The runtime model consumes events from the runtime environment, evaluates current violations of the security policy, and identi es close-future violations of the security policy. Within the logistics domain we applied our approach to identify situations in which an attacker might try to disrupt or degrade the process performance. By issuing predictive security alerts, users or operators (in this case: the dispatcher in the logistic process) are able to act securely without the need to understand the security policy or infrastructure in detail.
Other novel uses of such models at runtime can enable anticipatory impact
analysis, decision support and impact mitigation by adaptive con guration of
countermeasures. The project MASSIF (http://www.massif-project.eu/), a
large-scale integrating project co-funded by the European Commission, addresses
these challenges within the management of security information and events in
service infrastructures. In MASSIF [
Acknowledgments. The work presented here was developed in the context of the project MASSIF (ID 257475) being co-funded by the European Commission within the Seventh Framework Programme and the project Alliance Digital Product Flow (ADiWa) (ID 01IA08006F) which is funded by the German Federal Ministry of Education and Research.