In recent years, the business process modelling is matured towards expressing enterprise's organisational behaviour (i.e., business values and stakeholder interests). This shows potential to perform early security analysis to capture enterprise security needs. Traditionally, security in business processes is addressed either by representing security concepts graphically or by enforcing these security constraints. However, these approaches miss the elicitation of security needs and their translation to security requirements for system-to-be. This paper proposes a method to elicit security objectives from business process models and translate them to security requirements. The method enables early security analysis and allows developers not only to understand how to protect secure business assets, but it also contributes to alignment of the business processes with the technology that supports the execution of the business processes.
Although the importance of introducing security engineering practices early in
the development cycle has been acknowledged, it has been overssighted in
business processes and targets the improvement of business function. The reason
behind is that the business analysts are expert in their domain but having no
clue about the security domain [
Here we analyse the research question, how to elicit security objectives from the business processes and to translate them to security requirements ? We propose a method consisting of two major stages. Firstly, it describes how to identify business assets and to determine their security objectives. Secondly, it supports eliciting security requirements from the operational business processes.
The rest of the paper is structured as follows. In Section 2 we introduce the illustrative example. Section 3 presents our method for eliciting security requirements from the business processes. Section 4 concludes the paper and presents some future work. 2
To perform the security requirements elicitation one needs to collect the knowledge of enterprise value system, including the value chain and the business functions. Fig. 1 illustrates a value chain for the LMS example. It organises the enterprise business functions and relates them to each other (as enterprise cooperates to achieve the business goals). In Fig. 2 we present a detailed work ow of Prepare Plan process. The process has two business partners (Lodging Party and Planning Portal) expressed as swimlanes, while Registry is identi ed as an information system.
Similarly to Prepare Plan, other sub-processes (e.g., Lodge Plan, Examine Plan, Approve Plan and Update Plan) are also expanded to the operational and conversation models. But in Section 3, we will present our proposal using the Prepare Plan process (as illustrated in Fig. 1 and 2). 3
In [
The rst stage starts with the analysis of the value chain, which (i ) gives an understanding of organisational processes and, thus, (ii ) helps determine the assets that must be protected against security risks. In the LMS case the protected asset is Plan since it is the central artefact used in all the business activities (see Fig. 1). In terms of the security objective: i ) Plan should be con dential, i.e., no unauthorised individual should read it and its relevant data; ii ) Plan should be integral, i.e., the Plan and its relevant data should not be tempered; and iii ) Plan and its relevant data should be available to the business partners at anytime. 3.2
At the second stage, the security requirements elicitation is performed at ve contextual areas: access control, communication channel, input interfaces, business services, and data store. It is important to note that each artefact {data or process{ separately considered and protected at each contextual area, contributes to the security of business asset (i.e., Plan) identi ed at the rst stage. Access Control speci es how the business assets could be manipulated by individuals, applications or their groups. The major concern is to protect the con dentiality of identi ed business asset, in our example the Plan, when it is being manipulated by the IS asset, (i.e., the Registry). The security threat arises if the access to the Plan and its properties, like (Plan Number, Digital Data, and Plan Validation) is allowed to users without checking their access permissions. The risk event would: i ) negate con dentiality of Plan, ii ) lead to the Plan unintended use, and iii ) harm the Registry's reliability.
A way to mitigate the security risk is the introduction of access control mechanism, for example the Role-Based Access Control (RBAC) model. A r ole (e.g., Lodging Party and Planning Portal modelled using role stereotype) is a job function within the context of organisation. P ermissions characterise role privileges to perform operations on the protected object. An object is a protected resource (i.e., Plan). An operation is an executable set of actions that can change the state of the protected resource. For instance, Pre allocate Plan Numbers, Send Digital Data, etc are operations which manipulate properties Plan Number, Digital Data and Plan Validation (Fig. 4). Permissions specify the security actions {namely, Create, Read and Update{ that the role can perform over the state of the protected resource. The following security requirements are de ned: RQ1. Lodging Party should be able to: 1. create or initialize the Plan Number, Digital Data and Plan Validation. 2. read the Plan Number, Digital Data and Plan Validation. 3. update the Digital Data.
RQ2. Planning Portal should be able to: 1. update the Plan Number and Plan Validation. 2. read the Plan Number.
The security model (i.e., Fig. 4) de nes how authorised parties should access
the protected resources. However, it does not support capturing the concerns
related to the separation of duties, binding of duties, and usage control [
RQ4. A sequence of secured operations (e.g., Pre allocate Plan Numbers and Send Plan Number) should be performed by the same user assigned to the role (e.g., Planning Portal).
RQ5. The system (i.e., Registry) should place constraints on how con dential data should be used by the roles (i.e., Lodging Party and Planning Portal).
RQ3 de nes that there should exist at least two users in the Registry with the same role, to nish executing the task Fee Calculation Service: the rst user issues the Invoice and the second user approves the Payment Consent. Requirement RQ4 highlights the concept binding of duties. Requirement RQ5 de nes the security constraints for usage control; e.g., the Registry could potentially dene constraints for Digital Data and Validation Report saying, that they remain valid for seven days. Elicitation of requirements RQ3-5 much depends on the concrete problem. They can't be captured from the business model and require involvement of business and/or security analysts.
Communication Channel is used to exchange data between business partners (e.g., Lodging Party and Planning Portal) and system (e.g., Registry). Here, data, like Selected Business Process(es), Payment Consent and etc, need to be protected when they are transmitted over the (untrusted) communication channel, i.e., Internet. The communication channel could be intercepted by the threat agent and the captured data could be misused (i.e., read and kept for the later use or modi ed and passed over) by the threat agent. This could lead to the loss of the channel reliability, and could negate the con dentiality and integrity of the Plan. To mitigate the risk, the requirements should be implemented for the Lodging Party and Registry and correspondingly for the Planning Portal and Registry: RQ6. The server (e.g., Registry) should have the unique identity in the form of key pairs (public key, private key) certi ed by a certi cation authority. RQ7. The client (e.g., Lodging Party and Planning Portal) should encrypt and sign the data (e.g., Selected Process(es), Plan Number, and other) using keys before sending it to the server (e.g., Registry).
A security requirements implementation could be ful lled by the standard
transport layer security (a.k.a., TLS) protocol [
RQ9. The input interface (e.g., Fee Calculation Service) should sanitize the input data (e.g., Payment Consent) to transform it to the required format. RQ10. The input interface (e.g., Fee Calculation Service) should canonicalize the input data (e.g., Payment Consent) to verify against its canonical representation.
Input ltration [
Business Service is a task or activity executed within an enterprise on behalf
of the business partner [
RQ12. Packet Filter Firewall should lter the business party's (e.g., Planning Portal's) address to determine if it is not a host used by the threat agent. RQ13. Proxy Based Firewall should communicate to the proxy which represents the business service (e.g., Pre allocate Plan Number) to determine the validity of the request received from the business party (e.g., Planning Portal). RQ14. State Firewall should maintain the state table to check the party's (e.g., Planning Portal's) request for additional conditions of established communication.
It is important to notice that the communication between the Planning Portal (and also Lodging Party) and the Registry is bidirectional. The similar requirements must be taken into account when Registry sends messages (e.g., Fee Calculation Service sends Invoice) back to the business party.
Data Store is used to de ne how data are stored and retrieved to/from the associated databases (e.g., Data store in Fig 2). If the threat agent is capable of accessing and retrieving the data, their con dentiality and integrity would potentially be negated, thus, resulting in the harm of the business asset (i.e., the Plan) and its supporting IS assets (i.e., the Registry).
RQ15. The server (e.g., Registry) should audit the operations after the retrieval, storage or any other manipulation of data in the data store (e.g., Data store).
Auditing is the process of monitoring and recording selected events and
activities [
RQ16. The server (e.g., Registry) should perform operations to hide/unhide data when they are stored/retrieved to/from the data store (e.g., Data store).
A possible RQ16 implementation is cryptographic algorithms. The encryption o ers two-fold bene ts: (i ) the data would not be seen by the Data store users (e.g., database administrator) where the circumstances do not allow one to revoke their permissions; (ii ) due to any reasons if someone gets physical access to the Data store (s)he would not be able to see the con dential data stored. 4
In this paper, we presented a method to elicit security requirements from the business process models. Its strength lies in its general description of security goals and the systematic analysis of the contextual areas. In comparison to the related work where the focus is placed on representing security requirements (graphically) on the process models, our proposal suggests a novel approach to elicit these requirements and de ne them as the business rules.
The method should be improved with new security risk-oriented patterns. We also plan to extent the method with the requirements prioritisation to support the trade-o analysis. Finally, we continue validating the method empirically.