Towards Automated Attack Simulations of BPMN-based Processes

MAL is a language framework that combines probabilistic attack and defense graphs with object-oriented modeling. It can be used for creating Domain-Specific Languages (DSLs). Such a language defines what information is required and specifies the generic attack logic about the domain studied. We refer to the original paper [13] for a detailed overview of MAL.

To create a MAL-based language, the first thing is to identify all relevant assets and their associations within a particular domain. Each asset can contain multiple attack steps, representing real threats. One compromised attack step can lead to (represented by ”-$>$”) a next attack step, where each attack step is of the type OR (represented by ”$|$”) or AND (represented by ”&”). OR indicates that an attacker can work on this attack step as soon as one of its parent attack steps is compromised, while AND indicates that all its parent attack steps must be compromised for an attacker to reach this step. An asset may also feature defenses (represented by ”$\#$”). The sum of attack paths is the attack/defense graph used for the attack simulation. Also, assets can inherit from each other, which means that an inherited asset inherits all attack steps and defenses of its parent asset (unless explicitly stated otherwise).

In Listing 1, we present a short example of a MAL-based DSL. It contains four modeled assets, the attack step connections, and the connections between assets. In Line 7, the connect attack step is of type OR, while in Line 15 is an AND attack step. The -$>$ symbol denotes the connected next attack step. Thus, a phish on the User leads to obtain on the associated Password, and finally to authenticate on the associated Application. In Lines 28 to 32, the associations between the assets are defined.

As illustrated before, MAL provides the basics to create a threat modeling language from scratch. However, many languages created with MAL share a common set of concepts. To reduce unnecessary redundant work, coreLang [14] was developed. coreLang is comprised of predefined assets that appeared in different languages created with MAL. Thus, this coreLang can serve as starting point to model more domain specific languages or even act as a rudimentary language to model simple environments. Fig. 2 presents the overall structure of coreLang. For coreLang, we have identified six different main categories: system, vulnerability, user, IAM (Identity and Access Management), data resources, and networking. Following, we discuss the concepts of coreLang, that we will use later on for our mapping. For more details, we refer to the original publication [14].

Often, attackers gather initial access to a system by exploiting human factors, represented in our case by the concept of User. These User interact with Application through one or several Identity, which codifies the access rights that the user has. To secure the use of the Identity, Credentials can be applied, which are classically stored as Data and, thus, can be for example encrypted.

Usually, Data is managed by an Application, which represent the main concept used in the following. An Application can run another Application, which can be used to model for example an operation system executing a software. Moreover, Application can communicate with each other via a Connection where they exchange Data.

In an Application, common attack steps are codified. However, if the end-user of coreLang is aware of a certain Vulnerability, which is not included in the common attack steps, they can use the concept of Vulnerability and Exploit to add it to a certain Application.

Concepts like vulnerabilities and exploits as part of cyber security attacks captured by MAL and coreLang are crucial to be assessed in BPMN. While we assume the proper functioning and security checking of the process runtime, we subsequently assess elements of BPMN that can be facilitated as attack surface due to their inherited properties (cf. Tab. II). We consider configuration properties like conditions, expressions, scripts, service calls, and data flow as points of attack. We do not further consider control flow elements as these are managed by the process engine, which we consider as safe, and do not provide an attack surface by themselves.

The first property of BPMN we shed light on are conditions. A condition is some kind of threshold that — if it crossed — triggers a certain behavior in the process. As thresholds are usually defined by the user, these can be manipulated by the attacker. Alternatively, it is also possible that the attacker changes the input for the condition to (not) trigger it intently. E.g., Start Condition is such an event as a process starts if a certain condition is fulfilled, which could have been manipulated by an attacker. Another example is a Conditional Sequence Flow, as those include a condition check before continuing, which can be manipulated by an attacker to cause undesired behavior of the process.

Similar to conditions are expressions, which can be more elaborated and are interpreted. Thus, expressions provide a gateway for attackers to manipulate a process to their demands. e. g., a Business Rule Task is defined by a complex expression that evaluates a set of input parameters and takes a decision based on this input (e. g., by a business rule engine). An attacker can either make changes to the input parameters or — if they want to create more permanent changes — manipulate the expressions themselves, and thus exploiting the business rule engine. Further, there are Start Timer, which can contain an expression that regulates when a process is triggered. Here, an attacker could manipulate the starting time to initiate the process more often/seldom as expected.

One main task of Information Systems is to process data. Accordingly, this data is also of interest for attackers, who might want to get access to this data or even to manipulate it. The latter can cause severe issues for the process, as important decisions can be taken based on this data. Therefore, data related elements such as Data object or Message need special consideration in the security analysis.

Scripts are a powerful tool for developers to easily adopt requested functionality without the need for compiling new versions of programs. This made them very popular among process designers to alter processes to meet the customers’ desires. However, a Script Task can serve also as attack surface, as the script might be prone to manipulations or the interpreter behind the script has unsolved vulnerabilities.

It is essential for integration processes to provide collaboration mechanisms. As those mechanisms are responsible for organizing the entire process, they need to be in contact with all related elements of the process. Consequently, mechanisms of collaboration are of tremendous interest for an attacker, as the mechanisms can bring the attacker in the position to take over the entire process. Classically, these mechanisms are presented by a Participant or a Pool. Alternatively, a (Sub)Process can also be providing such a means. If an attacker receives access to the application behind the orchestration, they will be in a good position to attack other related activities.

Finally, there are service calls, in which activities are performed outside of the integration process. As the services elaborating on the call can even be outside of the organization or desire human interaction, they are prone to be exploited by an attacker. For example, a User Task could be exploited by tricking employees to perform not-safe actions. Considering a Service Task, the service can run a outdated server version that will easily allow the attacker to take it over and use it as a starting point to penetrate the process.

For the later, we do not consider those BPMN elements in Tab. II, that did not receive a \faCheck, as relevant for our mapping. Either they model a process related behavior that is not of relevance for a static threat model (e. g., Sequence Flow) or we consider them as already implicitly included in other elements. An example for the latter is the gateway. An attacker could exploit it by manipulating its input parameters. However, the behavior of gateways is managed by the collaboration mechanisms and, thus, represent no additional threat to be considered for our attack simulations.

Before, we have determined the relevant elements of BPMN to be mapped to coreLang. Our mapping relies mainly on three mapping rules, that can be summarized as follows:

1. 1.

   Data related BPMN elements will be mapped to Data.

2. 2.

   Elements that require user interaction are mapped to User, Identity (the digital representation of the user), and Credentials.

3. 3.

   Elements that can be configured or programmed by the process designer, are mapped to Application and Connection, where the latter illustrates the communication between several Application.

However, these rules have exceptions, which we will discuss in the following.

In Tab. III, we present our mapping for the collaboration aspects of BPMN to coreLang. Our general interpretation of Processes is that they orchestrate the overall happening. Therefore, a tool is needed taking over this task such as a process engine. Based on this observation, we map Process and Sub-Process to an Application.

As MAL-based languages do not have a focus on the process flow but on the static connection between the different assets, there is generally no counterpart for the different events of BPMN in coreLang. However, there are some exceptions: If the event is related to a message (i. e., Message Start or Message End), then there is obviously a communication possible. This communication relates to an exchange of information, which can be manipulated. Therefore, we map Message Start and Message End to Data. Further, there are Start Timer and Start Condition that are triggered by an Application that continuously evaluates the underlying conditions.

Next, we discuss the mapping from activities to coreLang. Firstly, BPMN defines User Task, where a human is expected to interact with the process. These interactions are a classic attack surface and, thus, we map User Task to User in coreLang. Secondly, there are automated activities, such as Script Task or Service Task. We map both to Application. This is founded in the fact that in a Script Task there is an engine (i. e., Application) executing a script, while a Service Task classically abstracts an interaction with e. g., a web-service, which are also executed by an Application.

Regarding the related Connection, we need to differentiate between synchronous and asynchronous calls. Basically, there is one Connection for synchronous calls, because the communication is initiated once. In contrast, there are two Connection for asynchronous calls, as communication gets initiated twice. Accordingly, Send Task and Receive Task have one Connection, while Service Task, Message Start, and Message End will have one Connection.

BPMN is a process-oriented language. Hence, it provides gateways that describe branching points of the process. In contrast, MAL-based languages codify the static connection between the different assets. Consequently, there is no equivalent in coreLang and just the general connections between the linked activities are transferred.

Often integration processes cope with data by transferring or transforming it. Moreover, to achieve access to data is often the ultimate goal of attackers. In BPMN this concept is modeled by Data object and Message. As there is no differentiation in coreLang, both are mapped to Data. If a Data object is stored outside of the process, then this is modeled by means of a Data Store, which can be for example a file system or a database. Obviously, this can be mapped to an Application (cf. Tab. III). For the threat modeling, flows are of no greater importance as indicated before. Nonetheless, there are exceptions in the connecting category of BPMN that require some logic and, thus, are mapped to Application (cf. Tab. III). In a Conditional Sequence Flow, the Application determines based on conditions if a communication takes place, while in a Message Flow expressions are evaluated.

To evaluate our approach, we implemented a prototype²²2Bpmn2Mal prototype, visited 6/2021: https://github.com/dritter-hd/bpmn2mal (cf. Fig. 3), which has a process model in BPMN as central input. To maintain objective (iii) –non-invasive–, we do not directly elaborate on the process model, but transform the model to a graph representation. This representation includes the overall structure of the process and the attributes that are necessary to perform the mapping from BPMN to coreLang.

To meet objective (iv) –simulation–, which arises from the challenge that we do not know the concrete software specification beyond every interface, we create different graphs that are enriched with respective specifications. Therefore, we provide a list of configurations for each included BPMN element that contains the possibly used libraries and the expected versions. This list is then used to crawl the NIST NVD³³3NVD NIST, visited 6/2021: https://nvd.nist.gov/ for known vulnerabilities of these possible solutions (e. g., Apache web server or nginx) and compute the time-to-compromise following McQueen et al. [17]. This information is added to the graph representation and additionally, the different solutions are combined. In other words, we prepare different graphs that to some degree contain e. g., Apache web server, while other graphs contain nginx or a combination of both.

These different graphs are then transformed into securiCAD models [5] that are instances of coreLang [14] following the mapping described in Sect. IV. This is extending previous work [7], which focused on automatically creating MAL languages, while here we are creating concrete instances of such languages. For each of the graphs, several simulations are performed giving the simulated attacker different attack surfaces (cf. Sect. IV-A). Then, the results of the different simulations get aggregated and are returned back to the graph representation to finally visualize the critical activities in the process model.

With Fig. 1, we introduced an example invoicing integration process. Facilitating the mapping presented in Sect. IV, we translate this integration process to the threat model presented in Fig. 4. To not clutter Fig. 1, it does not contain explicit data objects and related associations, which usually would be included. Accordingly, the respective coreLang representation does not contain explicit Data either.

For greater clarity, Fig. 4 contains only a subset of the possible vulnerabilities and exploits . More concretely, just those that are needed to enable the attacker to write the data transmitted to SdI-Production, which is symbolized by the star on Data . The top of the threat model describes the communication between the ERP-System and the Integration System. In the lower left part, the different Script Task and Service Task take place, which mainly process the document. The lower right part describes the communication with the SdI for the test and the productive system.

Next, we discuss a penetration, where an attacker can perform a Man-In-The-Middle (MITM) attack on the request (i. e., Data ) sent from ERP-System (i. e., Application ) to Integration System (i. e., Application ) via a Connection , e. g., because an older version of encryption is used. This enables the attacker to inject code into a component used by the process engine (CVE-2021-23337)⁴⁴4Lodash vulnerability used in Camunda, visited 6/2021: https://nvd.nist.gov/vuln/detail/CVE-2021-23337. As this vulnerability allows to execute arbitrary code, the attacker can alter the data sent to the Service Task communicating with SdI. If this Service Task is run by a miss-configured Apache Tomcat (CVE-2020-1938)⁵⁵5Apache Tomcat vulnerability, visited 6/2021: https://nvd.nist.gov/vuln/detail/CVE-2021-25329, the attacker is again able to execute their desired code. Hence, it is possible to write on the related data sent to SdI and the attacker reached their goal.

Now, we are able to perform the attack simulation in securiCAD [5] to analyze what path the attacker takes through the process and determine possible countermeasures (cf. Fig. 5). The analysis shows that the actual design of the process can be considered as secure, as the described attacker achieves a success rate of 8% after 100 days of penetrating the system.

Nonetheless, some room for improvement was identified. To stop the attacker early, one can require that data transmissions are just accepted if the sender is properly authenticated, thus MITM would not be possible anymore. Another option, which would stop the attacker later, would be to patch the vulnerable applications. Then, these would not be exploitable anymore (at least for exploits related to these specific vulnerabilities).

To reflect on our mapping decisions, we discussed them with an experienced threat modeler, who is also familiar with the concepts of coreLang. We explained the integration process in Fig. 1 and showcased the resulting threat model in Fig. 4. Overall, the expert agreed with our decisions. However, he raised some points that we will discuss further.

In our mapping, we opted to map every Script Task to a single Application, because we assumed that every script could contain a vulnerability that might not be present in other scripts. Alternatively, one could combine Script Task by the underlying technology, e. g., javascript, groovy, python, etc. Then, the focus would be more on the assumption that the vulnerability can be found in those technologies. Lastly, one could argue that there is no need for an explicit modeling of scripts since those are executed by the process engine. Discussing these three possibilities, we concluded that the first solution is the better one, as it contains information which scripts are corrupted, the data exchange between them is more obvious, and it is closer to the original process model.

Another point brought up was to split up the Process / Participant into several Applications that represent the different functionalities. In our case, this would result in splitting the Integration System into two endpoints to receive the request and to send the response, and a component managing the process execution. However, we neglect this additional differentiation, as we do not see any added value and more elements would be presented in the final model.

Taking a closer look at the attack simulations presented before, we recognize that for a successful penetration of the process, the Integration System is crucial. To reach the other parts of the process, the easiest and shortest way usually facilitates this central component. This observation can be generalized for all integration processes that make use of a process engine. Thus, we can conclude that the security engineers should put emphasis on that component.

Another observation is related to the positioning of the attacker. In our example above, the attacker can perform a MITM on the request. However, there are further attacks possible, like eavesdrop, that will result in different outcomes of what is accessible to the attacker and what is not. Moreover, the attacker could be (theoretically) placed on each and every element of the process. However, this is caused by the design of MAL itself. To overcome this, MAL could include an indicator, which assets and which attacks are the most likely attack surfaces.

This complexity is further increased by performing simulations for different configurations of the assets (i. e., a Service Task can either be executed by an Apache or an nginx http server). Each possible combination increases the number of needed simulations exponentially. Consequently, a solution is needed that reduces this number. One approach could be to restrict the possible configurations to realistic ones. For example, one can assume that within one organization (i. e., Participant / Pool), it is very likely that only one kind of a certain application for one purpose is deployed and only the versions might differ on a certain interval. Another possible assumption is to rely on usage statics of certain applications (e. g., http server) and to solely consider those that are used to a certain degree.

One aspect that can be improved in future is the fact that all our integration processes at hand only contain a subset of the possible BPMN elements. Especially, the integration processes are completely automatized and, hence, there is no interaction with humans expected. But the users of information systems are often used as attack surface to gain access to those systems. Moreover, human related security properties can differentiate significantly among organizations — and even in sub-entities of organizations. This cannot be codified in a static language such as coreLang. Therefore, an approach is needed that assess the security behavior in organizations (e. g., [6]) and includes this information into the performed attack simulations.