Annotated Bib.: Modeling of task-based authorization constraints in bpmn

[1] C. Wolter and A. Schaad. Modeling of task-based authorization constraints in bpmn. In G. Alonso, P. Dadam, and M. Rosemann, editors, BPM, volume 4714 of Lecture Notes in Computer Science, pages 64–79. Springer, 2007.

 

 

This paper proposes an extension for the Business Process Modeling Notation (BPMN) to express “authorization constraints for task allocation in workflows” within the workflow model, such as Separation of Duty, Role-Based Allocation, Case Handling, or History-Based Allocation in BPMN.

The paper defines Task-based authorization constraints that it “expresses who is allowed or must perform a certain task under specific circumstances in the context of a workflow”, and it state that most resource allocation pattern are not supported in the domain of business process modeling.

This paper provides:

–       Formal definition of authorization constraints in the context of workflow models.

–       Example workflow constraints derived from the banking domain and their formal representation.

–       Evaluation of BPMN’s capabilities to express task-based authorization constraints in the context of resource allocation and defines a BPMN extension for the specification of appropriate authorization constraints.

–       Applies the proposed BPMN extension to a real world, banking scenario, to evaluate its applicability.

Then the paper gave an example about a real-life process (Banking workflow) that can make use of these constraints, and explained the 6 constraints that need to be applied in this process: Clerk must interact with the customer, bank manager must sign the form, user must not check the credit worthiness, bank manager may act as a clerk, user acquiring the customer data must identify the customer’s account, For a single customer an user must not perform more than five tasks. Then provided deep technical and mathematical definition of all these constrains.

Finally, the paper explained how to solve these requirement and how to have them as an extension to BPMN, then showed how to represent each in a model (such as manual tasks and roles, task grouping and looping, Allocation Constraint Artifact), and finally reproduced the process model with all the six requirements expressed in the model, as shown below:

 

Relation to research in hand, this paper presented a novel approach to describe authorization constraints for manual tasks within the Business Process Modeling Notation. It covered one security requirement (authorization) in one modeling language (BPMN), but covered it in details, and showed six different requirements and constrains all related to authorization. The idea of this paper could be extended to other modeling languages and to make it generic to cover the authorization aspect in process modeling.

Annotated Bib.: Risk management in the bpm lifecycle

 

[1] M. zur Muehlen and D. T.-Y. Ho. Risk management in the bpm lifecycle. In C. Bussler and A. Haller, editors, Business Process Management Workshops, volume 3812, pages 454–466, 2005.

 

This paper provided an overview of risks associated with BPM projects during all the phases of the BPM lifecycle. The paper started by trying to define BPM, providing different definitions by different researchers, and finally defining BPM as creating “alignment among the individual process components input, output, resources, process structure, and process goals”.

Then it went in to defining risk and risk management; it explains that risk management composed of 3 main phases: identification, analysis, and control of risk. Also explained 4 of the management strategies toward a risk; mitigation, avoidance, transfer, and acceptance, by giving a definition and example for each of these strategies.

 

Then in section 4 went into “risks specific to BPM projects”, and listed common risks encountered in and between BPM lifecycle phases; it listed six phases of BPM life cycle, and four transition phases, in each of these ten phases listed a number of a BPM-specific risks to this phase.

 

This paper focused more on risks that can occur during BPM lifecycle and not on integrating risk to BPM or producing a risk-aware BPM. It showed and pointed out risks that might occur during the BPM life cycle.

Relation to research in hand, this paper might not be directly related to the research in hand, as it is not concerned with integrating risks, it was set only to point out risks associated with each phase of BPM life cycle. But it could be useful in showing the importance of considering risks, and other security aspects from the beginning, as these risks pointed out in this paper can be used as example and show case to prove that risk could happen and we should be prepared for it by considering it from the beginning and considering what kind of reaction to take.

Annotated Bib.: Security for workflow systems

[1] V. Atluri. Security for workflow systems. In Information Security Technical Report, volume 6, pages 59–68, 2001.

The paper started by defining what is Workflow, and what are the workflow systems. Then went in to explaining the security requirements for a workflow and define them in a BPM terminology.

Then the paper explained in details what the other thought are the most important security requirements in regards to the BPM. The paper explained Authorization and Access Control. Then talked about Separation of Duties. Authentication and Anonymity were the last 2 security requirements that where explained in how to integrate in the BPM.

The paper described that most commercial workflow systems provide minimal security features such as user authentication, and most of them have to implement an ad-hoc manner through a script type language. where such ad-hoc implementation makes specification, analysis and maintenance of security policies more difficult.

There treatment of authorization emphasizes the need for synchronization of authorization flow with the workflow, and it is missing some features such as assigning different roles to tasks based on the outcome of the prior task, granting different permissions to roles based on the outcome of the task, capability to specify different authorizations for different instances of the same workflow, ability to specify authorizations based on the context and based on the responsibilities to be performed by individuals, and delegating the responsibility to other users and roles.

Relation to research in hand, the paper highlights the security requirements of workflow systems and also discussed authorization, separation of duties, authentication and anonymity at length. In terms of discussing the security requirements, the paper might be old (2001), and other papers provided a better discussion and more relevant. But the paper provided a concise and specific definition to eight security requirements in terms of BPM, and what would these security requirements means to the workflow, this paper is the best yet in doing such work.

Annotated Bib.: Secure business process management: A roadmap

[1] T. Neubauer, M. D. Klemen, and S. Biffl. Secure business process management: A roadmap. In ARES, pages 457–464. IEEE Computer Society, 2006.

The paper starts by defining what is ”Secure Business Process Management” (SBPM), the paper says that if the BPM life cycle consist of analyzing, optimizing and designing the business process in accordance with the business strategy, allocating applications and employees, implementing and executing the processes to support information exchange, monitoring and aggregating operational data for the purpose of decision making and continuous improvement. Then so SBPM should take the same life cycle and Security aspects should be present during the whole cycle.

The paper presents an idea that Security should be a concern since the strategy definition, and Security should be developed in parallel with the business process. Then it says that Security measures should be modeled in the same BPM diagram. After that the authors presented the idea that security should be valued based on the business process. Finally the idea of the business cockpit was presented, where the monitoring should occur, as security needs to be monitored along with the business process.

This paper defined Secure Business Process Management and presented a research roadmap for this field. Compared to existing approaches the idea presented in this paper allows the alignment and integrated design of business processes and security objectives over the whole life cycle of a business process. The extension of existing BPM methodologies allows reducing the gap between IT- security and business activities using a combined business driven top down approach.

Relation to research on hand, The paper is a first step to considering security aspects in BPM, although it id not offer a complete solution, but it gave a roadmap, and a first step in a theoretical idea on how to integrate security aspects in BPM. The main contribution could be the idea of early consideration of security aspects with the strategic planning, and the paper showed how important is that.

Annotated Bib.: A reference model for process-oriented it risk management

[1] S. Sackmann. A reference model for process-oriented it risk management. In the 16th European Conference on Information Systems (ECIS’08), Galway, Irland, 2008.

This paper focuses on threats generated from IT and their influence on BPM, and relevance of IT risks resulting from flexible business processes and the integration of cause-effect relations into the typical risk management process and necessary extensions.

The paper defines “IT Risks” and that it should be seen as a section of “operational risks”, measuring the unanticipated losses, that are determined by “the frequency” and “amount of losses”. Then it shows the importance on IT in today’s organizations, and explains how that the increasing flexibility of business processes and their IT support challenges Traditional methods for risk management.

The paper proposes a “layer-based IT Risk Reference Model” that provides an approach for modeling IT risks. In Section 3 it went in to establishing the “IT Risk Reference Model”; Modeling the relations between the causes of IT risks and their effects on business processes, and explaining the four different layers:

Layer 4: Business Process (BP): On this layer, parts of the business process should be regarded as independent components that are defined as enclosed activities using at least one IT application for their realization.

Layer 3: IT Application / IT Infrastructure (AP): The assignment of protection goals to IT applications allows the bringing together of the economic handling of IT risks with the more technological.

Layer 2: Vulnerabilities (VN): the vulnerabilities identified are interpreted as independent “components” that can be associated to at least one IT application.

Layer 1: Threats (TH): This layer includes all known threats that are seen as causes of IT risks and, ideally, can be described with a probability of their occurrence.

Within these four layers, the relations between the causes and effects can be modeled addressing the needs of process-oriented IT risk management. Witch is done in the 4th section; “MODELING CAUSE & EFFECT RELATIONS FOR IT RISKS”.  Then in the 5th section the paper discussed some extensions, such as risk identification, risk quantification, risk treatment, and risk control.

This paper showed that the relations between the threats to IT (causes) and their implications on the business process activities (effects) have to be modeled in a standardized and formal way. The IT Risk Reference Model proposed in this contribution reduces the complexity of the modeling challenge by defining four layers. It also established the IT Risk Reference Model, which serves as a framework modeling the interdependent layers in the form of matrixes and allows a formal description of the interdependencies between the separated layers according to a company’s requirements.

Relation to research on hand, as our research is concerned with security-aware BPM, and risk is one of the security aspects. This paper focused more on the IT risks, and showed in details, how model both the risk causes, and effects. The reference model proposed in this paper is structured and well defined, and look at the problem from a different angle; considering the IT threats to be causes and that the effect will be on processes.

Annotated Bib.: Integrating Risks in Business Process Models with Value focused Process Engineering

[1] L. Churliov, D. Neiger, M. Rosemann, and M. Zur Muehlen. Integrating risks in business process models with value focused process engineering. 2006.

The paper proposes a new framework that link between the risk management and process management disciplines. The paper starts by defining what is a business process, and showing that any system including a business process consists of Hardware, software, and human, and that any error from these components may cause a system break down. So they all considered a risk. The framework was built on the concept of “risk-oriented process management”. The framework theoretical basis is the idea of “value-focused process engineering”, which explained thoroughly in section two that shows that “value-focused process engineering” is used to link between business processes and business objectives.

Section three is a step by step to integrate risk management and process management modeling techniques. The integration can be achieved by following these steps:

-        Identifying relevant process risks by decomposing business values and fundamental objectives.

-        Construction of a objectives structure link to the process flow by identifying specific risks, and finding what processes and what specific task of the process contribute to the risks.

-        Finding an alternative process configuration to reduce the effect of the risk, and developing an objective function to compare alternative configurations, to assess risks in the context of other business objectives.

-        Chose the best process configuration minimize risk in the context of business requirements, using the outputs of the previous step.

Section 4 gave a real life example and applied the previous framework on it, to illustrate the benefits of the new framework, and shows the how it could be used to recognize risks and reduce them before the execution of the process.

The paper concludes that the new framework brings the two domains of risk management and process management closer together, and it provides a first step toward risk-aware process management.

Relation to research in hand, this is another paper that focuses on risk-aware processes. It shows that the need to such thing is in high demand and that there is no such a perfect solution to this problem. It provided a conceptual idea to solve this problem, which is under the domain of security-aware processes (as risk is part of the security aspects). The conceptual idea provided in this paper is a good idea, but as indicated it is only a first step and need to be developed more. This idea might be used in combination with other ideas, to get the perfect risk-aware process solution. Also could be extended to cover other security aspects.

Annotated Bib.: Integration of an Ontological Information Security Concept in Risk Aware Business Process Management

[1] G. Goluch, A. Ekelhart, S. Fenz, S. Jakoubi, S. Tjoa, and T. Mu ̈ck. Integration of an ontological information security concept in risk aware business process management. In HICSS, page 377. IEEE Computer Society, 2008.

This paper describes the ROPE (Risk-Oriented Process Evaluation) methodology and the Security Ontology concept; which companies the domains of BPM and Risk Management, and enables risk-aware business process management.

The paper started by showing how important are the two domains (BPM, and Risk management), and how the are grown separately. Then Briefly explained the Risk management stages, and the BPM life cycle; showing the strengths and benefits of each world. Finally it shows how ROPE combine the strengths and benefits of both worlds, as ROPE focuses on risk-aware business process modelling and simulation, and to get to the full potential, ROPE is combined with the Security Ontology that covers major aspects of the risk management domain.

In the second section, the Authors went in to explaining the need for a "conceptual schema" about security. Where section 3 was about explaining ROPE methodology. The methodology consists of four processes: "re-engineering process", "resource allocation process", "workflow execution process", and "performance evaluation process". 

This paper focuses on the modelling and simulation of risk-aware business process, which occurs in the first process (re-engineering process)_. This process consists of five stages to result in the targeted model: "criteria selection stage", "acquisition stage", "analysis stage", "evaluation stage". The methodology make use of two diagram techniques; first "CARE (Conditions, Actions, Resources and Environments)", which is used to refine business process activity in to those four essential element types; as the relation between Actions, Resources and Environments is articulated by Conditions. The other model "TIP (Threat Impact Process)" is used to model the information related to "behaviour of threats, countermeasures and recovery measures".

The final section is about a proof of concept prototype; where a proof of concept prototype was developed to demonstrate how ROPE concept could be realized by a toolset. It also shows the feasibility of ROPE and the added value when it is combined with the Security Ontology. The prototype was built using: "Security Ontology Web Service", "Business Process Modelling Tool ADONIS", "Risk-Aware Business Process Simulation Engine", and used XML-based exchange format.

The paper concludes that ROPE combines the benefits of both domains Risk management, and BPM, it listed some of the benefits of using ROPE to get to a risk-Aware BPM, the paper also stated that ROPE is a generic concept, and can be used for every type of BPM and security threat ("as long as it can be represented in a process-oriented way").

Relation to research in hand, this paper presented a generic methodology that can be used to model and simulate Risk in BPM. While our research is concerned with all security concepts, Risk could be out of our scope, as it seems to be solved using the ROPE methodology. The methodology might also further investigated, as it might be suitable to represent other security aspects in BPM models.