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.

Annotated Bib.: Enhancing Business Impact Analysis and Risk Assessment Applying a Risk-Aware Business Process Modeling and Simulation Methodology

[1] S. Tjoa, S. Jakoubi, and G. Quirchmayr. Enhancing business impact analysis and risk assessment applying a risk-aware business process modeling and simulation methodology. In ARES, pages 179–186. IEEE Computer Society, 2008.

The paper starts by giving some statistics and numbers to show how risks and incidents can affect business process, and explain how that the two domains of BPM and Risks does not have an integration, which made the authors to introduce ROPE (Risk-Oriented Process Evaluation) methodology, which was introduced in a previous paper. This paper is only to show the application of the ROPE methodology and the benefits of using it.

In the next section it briefly explained the ROPE methodology and its five iterative processes: Strategic Decision Process, Re-Engineering Process, Resource Allocation Process, Workflow Management Process, and Performance Evaluation Process. It also explained its three layers: TIP (Threat Impact Process) layer, CARE (Condition, Action, Resource and Environment) layer, and BP layer.

The paper then used business impact analysis (BIA) to compare between the ROPE methodology and other standards and widely accepted good practice guidelines. Then used risk assessment to also compare ROPE to other standards and guidelines. Then section 5 was dedicated to show how applying the ROPE methodology would enhance BIA and Risk assessment; the paper presented two case studies for each aspect to prove the strength of the ROPE methodology.

The paper conclude that based on the case studies the ROPE methodology supporting a business impact analysis leads to succeeding benefits, as well as using the ROPE methodology supporting a risk assessment.

Relation to research on hand, the paper proves the usefulness of the ROPE methodology, which can be used to integrate risk in modelling, along with providing a methodology to integrate Risk; the paper also provides a technique that can be used to prove our methodology. On the other hand we can make use of the ROPE methodology to integrate other security aspects.

Annotated Bib.: Integrating risks in business process models

[1] M. Z. Muehlen and M. Rosemann. Integrating risks in business process models. In B. Campbell, H. Under- wood, and D. Bunker, editors, Australasian Conference on Information Systems, Australasian Chapter of the Association for Information Systems, pages 1–10. ACIS, Dec. 2005.

The paper started by giving a story happened in 2005 to show how important is the consideration of risk in BPM and how they are related. The paper continues to show how that risk-oriented process management is important to ensure the continuity of business operations. The paper reports the outcomes of the first step of a comprehensive research project, in which we aim for the development of a risk-aware process management methodology. The paper then gave a brief background on what have been done in the field of "Risk and BPM".

The paper then went in to explaining in simple words what is business process, showed the taxonomy of it, and how that risk is related to the five clusters: goals, structure, information technology, data and organisation, and the links between these clusters as well. it also showed that clusters goal and structure are of concern during build-time, while the clusters organisation, information technology and data are of concern during run-time.

in the other section, it gave the Risk taxonomy; showed the reasons that could cause risk, and also explained the differences between build-time risks and run-time risks. Also explained the four risk-handling strategies: mitigation, avoidance, transfer and acceptance.

The paper then showed that current modelling techniques does not consider risk and proposed a solution. The proposed solution consist of four model types:

•   Risk Structure model: provides insights into the hierarchical relationships between risks which is helpful to understand what risks have to occur together so that one risk can occur.

•   Risk Goal model: a matrix with risks forming the rows and goals placed in the columns which shows how different risks have impact on different goals.

•   Risk State model: capture the dynamic aspects of risks; it consisting of the object types risk, consequence and the control flow connectors, which depict non-hierarchical interrelationships between risks and the causal relationships between risks and consequences.

•   EPCs extended with risks: is used to assign risks to the individual steps of a business process.

The paper concludes that although this approach has some limitations, it is a first step toward the Risk-Aware processes, and some future work is needed.

Relation to research in hand; the paper focuses only on one security aspect "Risk", and its integration to BPM, it might have some limitations and focused only on one modelling language, but as explained in the paper can be extended to other modelling languages. The paper also provided a nice literature review about the history of integrating Risk and BPM, along with the detailed explanation of Risk and how it is related to the processes steps.

Annotated Bib.: Designing security requirements models through planning

[1] V. Bryl, F. Massacci, J. Mylopoulos, and N. Zannone. Designing security requirements models through planning. In E. Dubois and K. Pohl, editors, CAiSE, volume 4001 of Lecture Notes in Computer Science, pages 33–47. Springer, 2006.

This paper is about having a requirements engineering methodology that addresses security, it uses Secure Tropos to extend it and build on it to get to the required result.

The paper started by stating how important is security and trust in the design of the system and the software, and then showed that the proposed solutions are largely domain-specific. the paper also detailed the process that security might be needed in during the design.

in the second part the paper explained the Secure tropos framework, and showed how it is the best choice to bullied on top of it; as it is able to describe both the system-to-be and its organizational environment starting with early phases of the system development process. The section also described the requirements verification process.

The third section talked about the design in the planning phase. section four was about the Domain, and section 5 was about delegation and contract. All these three section contributed toward the extended framework. It used a running example of a health insurance case, to describe the new framework.

Section 6 compared between several off-the-shelf planer to use one of them on association with the new extension. Analysing and comprising was based on 4 requirements. At the end and after a thrall comparison the "LPG-td" was chosen to be the planer to be used in the framework. After that the paper discussed related work.

The paper conclude that within the new extended Secure Tropos framework it is possible to automatically support the designer of secure and trusted systems also in the automatic selection of design alternatives, and it is possible with the use of an off-the-shelf planner to generate possible designs for not trivial security requirements.

Relation to research on hand, This paper might be focused more on Software engineering, and building secure softwares, but it is related on the methodology, where the same idea and approach can be used in BPM, and the secure tropos framework can be used to build business process models, so the new framework can be used to build models that includes security aspects in it.