Discussion of the Existing Extensions

This section contains the detailed discussion of 15 closely related proposals chosen for the analysis.

The analysis is summarised in four tables which are discussed in Section 5.4.3.

In addition to this, Appendix A.14 discusses (1) the outcomes of academic reviews of research related to various aspects of the integration of IAS into BPM and (2) mentions other proposals suggesting to integrate security in business process models apart from those selected for a detailed analysis in this chapter.

5.4.2.1 Rodríguez et al., 2007 [24]

Rodríguez et al. [24] propose a BPMN extension which incorporates security into business process models from the business analyst’s viewpoint. The need for considering the business analyst’s and security expert’s viewpoints on security requirements in business processes is acknowledged.

The BPMN 1.0 metamodel, which represents the core element of a business process diagram, is extended with five security requirements: Non-Repudiation (NR), Attack harm Detection (AD), Integrity (I), Privacy (P), and Access Control (AC). These security requirements are adopted from [67].

A security requirement is depicted as a padlock symbol with a corresponding capital letter in the center. The criticality of a security requirement on the scale of low-medium-high is discussed in

the paper. However, its visual representation is not mentioned.

Rodríguez et al. [253, 14, 152] also suggest an extension for the UML 2.0 Activity Diagram based on a similar logic. In [14], the choice of a padlock symbol for the visualisation of security-related concepts is explained by the strong association between this symbol and the notion of security.

5.4.2.2 Wolter and Schaad, 2007 [164]

Wolter and Schaad [164] suggest an extension for BPMN for capturing authorisation constraints.

Authorisation constructs are depicted using the BPMN Text Annotation element enriched with a human figure. An annotation contains a reference (shown in the brackets) to formal constraints on the involvement of users in tasks. For example, the reference (2,1) means that the tasks must be performed by different users, while (1,2) means that the tasks must be performed by the same user. The extension is evaluated by demonstrating how it may be applied in a BPMN model of a banking workflow.

5.4.2.3 Wolter et al., 2008 [60]

Wolter et al. [60] discuss the importance of security goals in the context of PAIS. According to [60], security goals should be defined by business experts at the business process level while se-curity countermeasures should be identified at the service and resource levels. This thesis, on the contrary, suggests that within a business process model both security goals and security counter-measures (along with other security information) must be depicted to provide an holistic view of security in the process.

Wolter et al. [60] discuss a set of security goals including confidentiality, integrity, authentication, authorisation, traceability and auditing, and availability without making any reference to how or from where this set of goals is derived. The syntax of the proposed extension is not discussed.

However, in order to evaluate the proposal, one sample BPMN diagram annotated with security information is presented. The example depicts only security countermeasures such as binding of duty, separation of duty, encryption and the signing of a contract. A security countermeasure is depicted using the Text Annotation element, which shows the name of a countermeasure and is enriched with an icon presumably indicating the nature of the countermeasure. None of the security goals discussed in the paper are represented.

5.4.2.4 Souza et al., 2009 [186]

Souza et al. [186] present Sec-MoSC (Security for Model-oriented Service Composition), a methodology for the annotation of BPMN models with security abstractions and for the trans-lation of annotated models into BPEL process specifications enforced at runtime. A range of security goals and countermeasures is identified (see Table 5.5) for service composition in the context of a Virtual Travel Agency.

BPMN is extended with three elements: NF-Attribute (security goal), NF-Statement (the criticality of an activity), and NF-Action (security countermeasure), where NF stands for non-functional. A security goal is depicted as a cloud shape with the name of the goal inside. A security goal is attached to an Activity element. The criticality of an activity is depicted as a padlock at the corner of the Activity element.

Only technical countermeasures, executable at runtime, are considered. They are depicted as the names of NF-Action functions inside the Pool BPMN elements. In this proposal, symbol overload occurs because of the reuse of a Pool element to represent a security countermeasure.

An Eclipse plug-in and a translator converting annotations into executable XML configurations are presented [186].

5.4.2.5 Menzel et al., 2009 [181]

Menzel et al. [181] suggest an extension for BPMN for the specification of security requirements in business processes with the purpose of their automatic translation into a concrete security con-figuration in the context of SOA. The paper discusses the following security goals: authentication, authorisation, trust, data confidentiality and integrity, system integrity and availability. No refer-ence is found in the paper describing from where or how these security goals are derived.

An example of an annotated model of an ordering process is provided. The syntax of the proposed extension to BPMN includes the following graphical elements: asset value, trust and security goal.

Asset value is depicted as a padlock symbol inside a Data Object or an Activity element. The level of the filling of a padlock symbol indicates the rating of the asset value on the scale from negligible to extreme. In an annotated example, it is hard to distinguish the value of an asset because the icons are too small. The trust between the participant of a process is depicted as a Data Object with a handshake icon. Hence, a symbol overload occurs because an existing BPMN element is reused

to represent the concept of trust. Another reuse of a BPMN element is encountered when a Group element depicts a security goal as applied to a group of activities. The type of security goal in this instance is not visually indicted. The paper also shows the sample XML configuration for message encryption.

5.4.2.6 Wolter et al., 2009 [182]

Wolter et al. [182] introduce a model-driven transformation framework for generating security configurations from security-annotated business process models. For this thesis, the tool which in the proposed transformation framework supports the graphical annotation of business process models is of interest.

The paper addresses four security goals, namely authorisation, authentication, confidentiality and integrity. The goals are chosen at the authors’ discretion stating that these goals "have the most significant effect on the modelling of business processes and people involved."

The paper presents one annotated sample diagram expressed, presumably, in BPMN 1.0 (the paper itself does not mention which modelling notation is used). The business process modelling notation is enriched with several graphical security elements of which only one foureye principle -is d-iscussed in the paper. The four-eye principle -is depicted as an icon with two human figures placed within a BPMN Text Annotation element. For evaluation purpose it is demonstrated how an XACML policy is generated from an annotated model.

5.4.2.7 Mülle et al., 2011 [21]

Mülle et al. [21] propose a language for the formulation of security constraints embedded in BPMN. The authors attempt to address two gaps in the research: (1) the incompleteness of the security modelling vocabulary and (2) insufficient user involvement. The proposed language uses the standard BPMN Text Annotation element as a container for security constraints.

The basis of the language is formed by the following requirements: authorisation, authentica-tion, auditing, confidentiality, data integrity, security-specific user involvement and trust-specific aspects. The authors also propose a new approach to the transformation of security annotations into the representation, supported at process execution. The paper significantly extends the set of

security requirements being addressed. Nevertheless, the limitations of the work is in deriving se-curity requirements from only two specific scenarios originating from the employability domain.

Although the scenarios are complex, it is not sufficient evidence to support the statement about the completeness and general suitability of the identified security requirements. For example, essential security goals such as availability and accountability are omitted.

The main aim of the proposed language is to translate security requirements (annotations) specified in a BPMN model into an executable specification. Hence, the language is text-based and oriented on technical experts. Business experts would find the annotations hard to comprehend. This would deter business experts from the security-annotation of business process models and complicate se-curity requirements gathering. The similar text-based BPMN extension for privacy-aware business processes is presented by the same group of authors [187].

5.4.2.8 Varela-Veca et al., 2011 [183]

Varela-Veca et al. [183] develop a framework for weaving risk into BPM. They extend BPMN with the risk information expressed in the textual form using a Text Annotation BPMN element. Varela-Veca et al. [183] focus on the diagnoses of non-conformance of security objectives in annotated models. The constructs introduced into the BPMN metamodel are extracted from the UML profile for modelling quality of service and fault tolerance characteristics and mechanisms [254].

5.4.2.9 Brucker et. al., 2012 [38]

Brucker et. al. [38] suggest the SecureBPMN methodology, which allows the modelling of se-curity requirements at the system design stage along with the functional requirements and the enforcement of the requirements at run-time. The security requirements considered in [38] are limited to access control, separation of duty, binding of duty and need-to-know. The requirements are derived from a travel-approval process and from other unnamed case-studies. The main crit-icism of this proposal is associated with the fact that it focuses on Role Based Access Control (RBAC) and overlooks other security concerns. The proposal does not outline an extended BPMN metamodel. Brucker et. al. [38] extend the Activity Designer with security modelling capabilities and enable the generation of XACML policies from annotated BPMN models.

The importance of a clear visual representation of security requirements within BPMN model is acknowledged. It is said that security aspects should be embedded into BPMN in a well-arranged

manner. However, there is no discussion or justification provided regarding why the symbols suggested in the paper are clear and well-arranged, and why the representation suggested is better than others previously proposed.

An analysis of the syntax proposed in [38], shows that it introduces symbol overload: (1) it uses a rectangle with rounded corners to represent a security requirement, while it already represents an Activity and (2) it uses a solid line arrow to represent the applicability of a security requirement to an Activity, while it is a Sequence Flow BPMN element.

5.4.2.10 Saleem et al., 2012 [184]

Saleem et al. [184] develop a BPMN security extension for SOA applications. In comparison with [24], only a limited set of security requirements is considered: confidentiality, integrity and avail-ability (associated with non-repudiation). The main criticism of this proposal is associated with the use of an outdated metamodel of BPMN for extension. This proposal extends the metamodel of BPMN 1.0 with security constructs. However, the metamodel of BPMN 2.0, which emerged in 2011, is different.

A set of graphical notations for confidentiality, integrity and availability is also introduced. The proposed symbols do not comply with the BPMN extensibility rules as they do not maintain the

"feel-and-look" of BPMN. Despite its limitations, this work is one of a few which discusses, although very briefly, a rationale for its syntax.

5.4.2.11 Monakova et al., 2012 [166]

Monakova et al. [166] describe a tool-supported framework for modelling and monitoring security and safety requirements in supply chains. Monakova et al. [166] consider the following security controls: signature, encryption, audit-control, privacy-policies and separation of duties.

The syntax of the proposed extension includes tags for (1) logical and physical assets (an icon inside a rhombus shape attached to a Data Object) and (2) security controls (as icon placed inside a hexagon attached to Data Object and Activity BPMN elements).

A software prototype is presented. Although the paper states that it aims to improve comprehen-sion through the visualisation of security concepts, the syntax of the notation is not justified or

analysed in any way. The proposal does not concentrate on IAS as such, but considers it as one of the aspects among other security and safety requirements.

The proposal is developed to suit the needs of food supply chains and is not broadly applicable.

According to the paper, the software tool was presented to and discussed with supply chain stake-holders and received positive feedback. However, the description of the evaluation process and of the results is limited to the statement above and no further details are provided.

5.4.2.12 Rekik et al., 2012 [189]

Rekik et al. [189] extend BPMN for security modelling in a cloud environment. The following se-curity requirements are addressed: integrity, privacy, access control, non-repudiation, availability and audit. The requirements are derived from Rodríguez et al. [24] as they are said to be perti-nent to a cloud environment. The concept of inter-sides communications is also introduced in the extended BPMN metamodel. The syntax of the proposed extension is not discussed. All security annotations in the example diagram are depicted using the Text Annotation BPMN element.

5.4.2.13 Marcinkowski and Kuciapski, 2012 [173]

Marcinkowski and Kuciapski [173] introduce an extension for risk handling in BPMN 2.0. The semantics are derived from risk management standards. The following risk modelling elements are incorporated into BPMN: risk factors, risk types, risk handlers and risk mitigation methods. One example diagram is presented illustrating the application of the proposed method to the process of managing an architectural contest. Risk in the diagram is depicted as a triangle with an exclamation mark inside. No discussion of the syntax is provided.

5.4.2.14 Altuhhova et al., 2013 [185]

Altuhhova et al. [185] propose a security risk-aware BPMN extension based on the Information Systems Security Risk Management (ISSRM) domain model [59]. The following security ele-ments are introduced into BPMN to enable security/risk annotation:

• The characteristic of an asset - a circle with a corresponding letter inside (B for a business asset and IS for an IS asset) which is applied to the top right corner of the Event, Gateway and Task BPMN elements;