A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Cloud computing enables the provisioning of dynamically scalable resources as a service. Next to cloud computing, the paradigm of Service-oriented Architectures emerged to facilitate the provisioning of functionality as services. While both concepts are complementary, their combination enables the flexible provisioning and consumption of independently scalable services. These approaches come along with new security risks that require the usage of identity and access management solutions and information protection. The requirements concerning security mechanisms, protocols and options are stated in security policies that configure the interaction between services and clients in a system. In this paper, we present our cloud-based Service Security Lab that supports the on-demand creation and orchestration of composed applications and services. Our cloud platform enables the testing, monitoring and analysis of Web Services regarding different security configurations, concepts and infrastructure components. Since security policies are hard to understand and even harder to codify, we foster a model-driven approach to simplify the creation of security configurations. Our model-driven approach enables the definition of security requirements at the modelling layer and facilitates a transformation based on security configuration patterns. <s> BIB001 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Non-functional requirements (NFRs) are rarely taken in account in most software development processes. There are some reasons that can help us to understand why these requirements are not explicitly dealt with: their complexity, NFRs are usually stated only informally, their high abstraction level and the rare support of languages, methodologies and tools. In this paper, we concentrate on defining how to reason and how to refine NFRs during the software development. Our approach is based on software architecture principles that guide the definition of the proposed refinement rules. In order to illustrate our approach, we adopt it to an appointmernt system. <s> BIB002 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Business process modelling is very crucial for enterprises because it give an idea how the business would be operated in the real world and it is important for every stakeholder. SOA is one of the most popular architecture for building Web Information Systems. In current SOA system development practices, security is not defined at the early phases of software development and left on the developer. Properly configuring security requirements in SOA applications is quite difficult for developers because they are not security experts, furthermore SOA security is cross-domain and all required information are not available at downstream phases. The post-hoc, low-level integration of security has a negative impact on resulting SOA applications. Business process modelling is normally performed by the Business Process expert who is not a security expert. Furthermore current business process modelling languages like UML or BPMN do not support the specification of security requirements along the business process modelling. We have presented a DSL, to model the security requirements along the business process model. We are facilitating the Business Process expert to model the security in business process diagram. This security annotated business process model will facilitate the security expert in specifying concrete security implementation. As a proof of work the proposed DSL is applied to the modeling of a typical business process of “on-line student information system”. <s> BIB003 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Business process modelling and security engineering are two important concerns when developing information system. However current practices report that security is addressed at the later development stages (i.e. design and implementation). This raises a question whether the business processes are performed securely. In this paper, we propose a method to introduce security requirements to the business processes through the collaboration between business and security analysts. To support this collaboration we present a set of security risk-oriented patterns. We test our proposal in two industrial business models. The case findings characterise pattern performance when identifying business assets, risks, and countermeasures. <s> BIB004 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> The use of business process standards to model and execute business needs is growing rapidly. In addition, Service-oriented Computing has been adopted to realize business processes, which basically consists of executing the process activities using services available in the Internet. In this context, the importance of security is apparent, because sensitive data sent over the Internet may be accessed by unauthorized third-parties. To prevent security problems, users may associate security requirements that must be enforced in essential tasks of the business process. This fact leads to the need of automation, because both functional and security requirements should be modeled, at high-level, and enforced, at execution level. This work proposes a cloud-based solution named BPA-Sec4Cloud that supports all phases of the security-aware business process automation, from its modeling to its deployment. The use of a cloud-based solution facilitates the deployment process because all needed resources are available in the cloud and ready to be used. In addition, the cloud is also used as a platform in order to provide specific services, such as translators, to support the automation process. In order to evaluate the BPA-Sec4Cloud, the solution was compared against existing solutions through the use of metrics related to the quality of generated artifacts. <s> BIB005 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Making today’s systems secure is an extremely difficult and challenging problem. Socio and technical issues interplay and contribute in creating vulnerabilities that cannot be easily prevented without a comprehensive engineering method. This paper presents a novel approach to support process-aware secure systems modeling and automated generation of secure artifact-centric implementations. It combines social and technical perspectives in developing secure systems. This work is the result of an academic and industrial collaboration, where SecBPMN2, a research prototype, has been integrated with SAP River, an industrial artifact-centric language. <s> BIB006 </s> A survey on automation of security requirements in service-based business processes <s> Graphical extensions of BPMN <s> Every so often a paper is published presenting a new extension for modelling cyber security requirements in Business Process Model and Notation (BPMN). The frequent production of new extensions by experts belies the need for a richer and more usable representation of security requirements in BPMN processes. In this paper, we present our work considering an analysis of existing extensions and identify the notational issues present within each of them. We discuss how there is as yet no single extension which represents a comprehensive range of cyber security concepts. Consequently there is no adequate solution for accurately specifying cyber security requirements within BPMN. In order to address this, we investigate a new approach to modelling security and propose a solution which aims to overcome current issues whilst still providing functionality to include all concepts potentially modellable in BPMN related to cyber security. We explain how our solution takes a novel approach to current challenges that is both effective and with adequate coverage of the cyber security domain. <s> BIB007
In another related initiative, Rodriguez (2011) extended BPMN to allow the incorporation of security requirements into business process diagrams. For each security requirement, a dedicated BPMN graphical notation is introduced and can be associated with various BPMN standard elements. This association is done through a BPMN security extension, which relates the BPMN standard notation and the proposed security elements. Such as Turki et al.'s (2012 ) approach, Rodriguez (2011 introduces an intuitive graphical notation to represent security. In comparison to Turki's work, the graphical notations are very similar, but Rodriguez's (2011) approach proposes specific internal codes used to differentiate each security requirement. Some examples of internal codes are: CO relates to confidentiality, IN means integrity and AU refers to authentication. Figure 2 presents a business process enriched with 'confidentiality' and specified using the Rodriguez's proposal. The business expert expresses that confidentiality actions must be executed just before task credit card payment. Comparing Turki and Rodriguez approaches, it is possible to highlight that Rodriguez presents graphical elements that may be more expressive than Turki because the internal codes are easier to remember than different graphical notations. BIB001 present a domain-independent security model and security patterns. The primary objective of this initiative is to facilitate the generation of security configurations based on the modelled requirements. For this purpose, Menzel adopts a model-driven approach in such way that information at the modelling layer is gathered and translated into a domain-independent security model. Menzel's approach uses BPMN to express business processes. Meanwhile, the author also proposed an UML-based configuration to represent the relationships between security and business process elements. Regarding modelling, Menzel introduced the notion of 'profile'. A profile is directly connected to a security goal to identify the security level desired by the user. For example, the business expert may determine that a specific security goal should have a 'high' or 'low' profile. If the business expert selects the 'high' profile, a stronger encryption algorithm and key length should be chosen. Otherwise, if the 'low' profile is selected, a simpler encryption algorithm can be chosen. Based on that, users can model a set of security configurations that better fit what they need. This strategy is not exactly a new idea because some web browsers adopt similar strategies to configure the security parameters of the user. However, this is an interesting idea, because business experts can express the desired security level without having to be familiarised with specific security concepts and technologies. Similarly to Turki and Rodriguez, Menzel also proposed specific graphical notations to express security needs in BPMN business process diagrams. More specifically, Menzel proposed two artefacts named organisational trust and security group. The first artefact represents the 'trust relationship', which can be used to state the confidence between two or more participants better. Menzel considers that this is an important security information that should be represented in the BPMN diagram. An essential property in this context is the 'rating', which can vary from negligible (no need to take any security action or to be concerned with security issues) to extreme (security issues can cause several damages for people and enterprise). Another graphical element was proposed to represent the 'rating' property that represents each grade level. The second artefact proposed by Menzel, security group is used to group tasks, artefacts and pools that share similar security intentions. This artefact has a specific graphical notation, which is a dashed rectangle. Figure 3 presents an example of the utilisation of this proposed artefact. The security group artefact is grouping the BPMN tasks insert flight reservation parameters and credit card payment. The same 'rating' is valid for this artefact, the business expert can choose the desired level of each security property, which can range from negligible to extreme. BIB005 proposed another relevant work. In this work, the author introduces a strategy named BPA-Sec to represent security requirements and graphical notations to insert them in a BPMN business process model. According to the author, the first step towards the explicit treatment of security requirements in business processes definition is the ability to express them. BIB002 introduces a set of abstractions, namely NF-attribute, NF-statement and NF-action, to model and reason about non-functional requirements. To use the abstractions to precisely specify how the security requirements should be fulfilled, BPA-Sec extended the original semantics of these abstractions and added other ones, adopting some principles described in the following. Firstly, the notion of a NF-action 'affecting' a NF-attribute (as initially defined by Rosa) was extended, so that it may also 'implement' a NF-attribute. For example, when a NF-action like 'to encrypt data' is implemented, it does not merely affect the NF-attribute security. It implements it as well. Secondly, an additional abstraction named NF-group was introduced, that lets users group NF-actions in such a way that facilitates their reuse. Thirdly, the NF-property abstraction was proposed to enrich the definition of the NF-actions. For example, the security NF-action 'to encrypt data' has the NF-properties 'encryption algorithm' and 'key length', which serve to include more details about it. With this abstraction, more information about the enforcement of security mechanisms is provided, making this implementation closer to the business expert needs. Finally, graphical elements were proposed to be used at modelling level, enabling business experts to enrich their models with security requirements. Figure 4 shows a business process annotated with security requirements. The business process includes activities for a 'car reservation', which has four tasks and two of them were annotated with security requirements. It is possible to note that both NF-attributes confidentiality (represented by a cloud) and NF-actions UseAuthentication and UseCriptography (modelled by rectangles) appear in this figure and not only the security attribute. In comparison to the Menzel's approach, BPA-Sec proposes a shorter core set of generic abstractions and notations that could be used to express various security requirements rather than providing a fixed set of dedicated elements. Another relevant point to be highlighted is the presence of security actions in the BPMN graphical diagram. BPA-Sec proposed a graphical notation specifically for this purpose. By using graphical elements to represent security details may explicitly show the business expert some relevant information. However, some users may feel more comfortable in analysing a cleaner diagram and setting the specific actions or configurations in other location. Another relevant initiative in the security modelling context is BIB004 . In this initiative, the authors propose a method to introduce security requirements to business processes that considers collaboration between business and security analysts. This method includes the proposition and use of specific graphical notations to express security objectives in business processes. The modelling process is developed through the use of security risk-oriented patterns. The method itself is composed of activities such as security objectives identification, security risk analysis, the annotation of security requirements in the business process model and so on. It is possible to state that Ahmed and Matulevicius (2014) is another interesting initiative that proposes the insertion of graphical notations in business process models. However, one contribution that differs from other mentioned initiatives, such as BIB001 and BIB005 , is the presentation of a collaborative strategy to integrate business and security analysts in the modelling process. For example, both analysts perform security objectives identification. This collaborative strategy can provide a richer security configuration because all involved analysts contribute in the modelling process. In another interesting work,  proposes a structured approach that extended BPMN to express security risks and risks treatment in BPMN business models. This approach focuses on how BPMN activities could be annotated with security concerns. One of the main contributions is the development of a 'security risk-aware BPMN', which can be used to express security assets, security risks and countermeasures  . To model security requirements in BPMN business processes, Altuhhova initially defines that different colours can be used to represent different resources in the BPMN diagram. More specifically, black, red and blue colours are used to express asset-related constructs, risk-related constructs and risk treatment-related constructs, respectively. Altuhhova also proposed a lock to represent the security objective which is similar to other abstractions presented previously. This lock also has a specific code inside that determines the security purpose: confidentiality ('C'), integrity ('I') and availability ('A'). Also, BPMN traditional elements (especially tasks) are used to model not only functional activities but also security activities, such as to authenticate users, scan incoming messages and so on. By doing that, security and business experts can adequately model security activities using a BPMN-based process approach. This strategy substantially differs this approach from others and has some implications. To better illustrate it, a simple example is presented in Figure 5 . In functional terms, this example has only two events (user request and user request was processed) and one task (process user request). Regarding security, the business expert wants to express that the user must be authenticated before processing the request. To accomplish this, the modeller added the tasks authenticate user and deny request, the gateway user was authenticated? and the event user request was denied. It is possible to observe that the security modelling of this figure has a different colour, i.e., the functional elements are in black, while security-related elements are in blue. It is worth observing that the expressiveness of Altuhhova's approach is evident. By marking the security modelling in different colours, the diagram highlights the security elements in the diagram. Also, modelling security requirements using a process-oriented strategy may facilitate the understanding of the security process by the business expert. The business expert is familiarised with process-oriented modelling, especially because this expert uses a process-oriented standard to model the business model. However, someone can argue that this approach overloads the BPMN model not only with additional notations but also in the process flow, by merging the functional and security flows in the same diagram. Depending on the number of security requirements to be modelled, the resulting security flow can be significantly higher in comparison to the functional flow. BIB003 proposed another interesting initiative in the area of security requirements modelling. The author introduces a domain specific language (DSL) to support the specification of security requirements in business processes. According to BIB003 , DSLs can be used to formalise a modelling language capable of representing both different business domains and system aspects like security. Saleem's approach deals with confidentiality, integrity, availability and traceability/auditing. Each of them was associated with a security symbol, which is a graphical element that expresses the security requirement in a BPMN diagram. To illustrate Saleem's approach, Figure 6 presents a simple example in which the business expert wants to model that the data used in the process credit card payment must support confidentiality-related mechanisms. It is possible to observe that this graphical notation differs somehow from ones presented previously. It is not only a lock with code inside but a symbol that intuitively represents what has to be done. For example, in Figure 6 , the idea is to secure the data that should be transmitted. It is possible to note that these symbols differ, in conceptual terms, from other security graphical notations and this fact can impose barriers to the adoption of this approach. However, the proposed symbols are more intuitive, as they better represent, in a visual way, what the business expert is trying to express. Finally, BIB007 proposes an innovative approach for representing security in BPMN diagrams. The authors advocate the use of three dimensions (3D) for modelling and representing BPMN elements and security requirements. The author evaluates some existing approaches, such as Rodriguez et al. (2011), BIB003 and BIB006 and then concludes that the use of 3D can mitigate existing issues such as complexity management and cognitive overload. With the 3D usage, it is possible to model and control a large number of symbols, without incurring in cognitive overload. However, not many tools exist to enable the 3D usage, both for functional or security modelling.  proposes a security language embedded into BPMN to represent security requirements and constraints. This is carried out by using BPMN artefacts with the desired requirements. According to the authors, the reasons for that are because this approach both conforms to the BPMN 2.0 at a syntax level and reduce the implementation efforts as BPMN artefacts are available in most available BPMN modelling tools  . In Mulle's approach, security constraints are inserted in BPMN as structured text annotations, in a declarative form. In this approach, annotations have a generic structure, which is presented as follows: