Summary: Framework for Business Process and Rule Integration: A Case of BPMN and SBVR

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

“Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature. Business rules, however, tend to be text-oriented. Second, they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge”. This paper is about a framework that integrates BPMN (Business Process Modeling Notation 2.0), process modeling language, and SBVR (Semantics of Business Vocabulary and Business Rules), rules modeling language.

Most available frameworks follow a top-down approach, and that integration should happen in the design stage, which is correct but not realistic. As in reality most organisations already have existing processes’ models and rules’ models that are separate, and the real problem facing organisations is integrating these existing models. That’s why a bottom-up approach is required, where integration happens in analysis stage. “The bottom-up integration framework is built around a collection of mapping methods that provide distinct ways in which overlap and consistency (or lack of) between processes and rules can be studied”.

Integration framework have two main aspects; semantic and structural aspects. Semantics aspects are about providing a reference that can provide a mapping between the two languages terms. Structural aspects are dealing with how the two languages have different structures. This paper only looked into structural aspects.

XML Process Definition Language (XPDL) was used as a canonical intermediate language to bridge the gap between BPMN, a visual process modeling approach, and SBVR, a text based business rule’s modeling language. Because, it is standardized and well supported, also it has the ability to transfer BPMN graphical notations into text representation.

To provide a mapping, both languages have to be broken down to the main components. SBVR was brought down to Name, Term, Verb, and four types of keywords. While BPMN consist of: activities, events, gateways, and participants. XPDL is used to translate each one of these BPMN components into XPDL tags and then mapped into SBVR component (a table is provided in the paper). The proposed approach do not have a way to present the model operation in BPMN except using ‘must’ or ‘it is obligatory’, which is considered a limitation of the solution. The paper also provided a car sale process and its business rules to demonstrate the proposed solution and prove its effectiveness.

in L.R.:

Cheng et al. in provided a bottom-up approach to integrate process models and business rules models in an analysis stage. There approach was specific to integrating BPMN process models with SBVR rules models. It used XPDL to translate the BPMN diagrams to text representation and then used these tags to map the business rules models, and finally producing a new model that include both the process and the rules. Even thought the approach was applied to BPMN and SBVR, but the idea can be generalized to other languages. A limitation to the approach, that it was only able to represent BPMN operations using either ‘must’ or ‘it is obligatory’. The approach did not invent a new language. It made use of XPDL and its ability to translate BPMN diagrams into XML tags. The main contribution was providing a list of the main components of the process language (BPMN) and the rules language (SBVR), and using XPDL to map these components to each other.

Challenges in integrating BP models and regulations

 

R. Cheng, S. W. Sadiq, and M. Indulska. Framework for business process and rule integration: A case of bpmn and sbvr. In W. Abramowicz, editor, BIS, volume 87 of Lecture Notes in Business Information Processing, pages 13–24. Springer, 2011.

"Integrating the outputs of the two modeling approaches is a challenging task. First, business process models tend to be visual in nature, with most of the relevant information represented graphically. Business rules, however, tend to be text-oriented. Thus, integration of the outputs of the two approaches requires an information exchange format with minimal information loss. Second, process models differ from business rules fundamentally as they have different composing elements. Third, they are designed for different purposes - process models describe how things should happen, whereas business rules describe what should happen. Finally, the overlap and inconsistencies between business process models and business rules also presents a significant challenge. In particular, a set of criteria is required that helps a business analyst to resolve identified overlaps and inconsistencies in a satisfactory manner."

Why do we need formal representation of Security policies

Resource: Wissam Mallouli, Fayc ̧al Bessayah, Ana R. Cavalli, and Azzedine Benameur. Security rules specification and analysis based on passive testing. In Proc. of the Global Communications Conference on Exhibition and Industry Forum Co-located with WTC (GLOBECOM’08), New Orleans, LA, USA, pages 2078–2083. IEEE, November-December 2008.

"A security policy is a set of rules that defines the desired behavior of users within an information system. Its main goal is to describe how data and other critical system resources are protected. If a security policy is written in a natural language specifying for example: ‘file F is only accessible from terminal T in the context C’, it will be very difficult to verify its correct implementation using an automatic testing approach because it is a completely informal specification. Consequently, if such verification is not performed, there is no guarantee that the security rules of the system are properly implemented".

"To guarantee that the system respects its security policy, we can rely on formal testing based methods. The main ones are (i) the active testing which validates a system implementation by applying a set of security test cases and analyzing its reaction and (ii) the monitoring (or passive testing) that consists in observing, during the execution, whether the system behavior is conform according to its functional and security formal specification".

"To perform this analysis, we rely on a dedicated formal language to describe the security requirements of the system. Then, we check using well adapted algorithms whether these security rules are verified on the collected traces to deduce the appropriate verdict about the system security conformance".

W. Mallouli, J.-M. Orset, A. R. Cavalli, N. Cuppens-Boulahia, and F. Cuppens. A formal approach for testing security rules. In V. Lotz and B. M. Thuraisingham, editors, SACMAT, pages 127–132. ACM, 2007. 

To ensure that a certain level of security is always maintained, the system behavior must be restrained by a security policy. A security policy is a set of rules that regulates the nature and the context of actions that can be performed within a system, according to specific roles. As an exam- ple, such policy can tackle the interactions between a network infrastructure and Internet or manage accounts and rights toward an operating system or a database. Generally, a security policy is written by the mean of a natural lan- guage specification, containing statements such as “this file must be accessible only to authorized users” or “all ports are closed except for 21 (ftp), 22 (ssh) and 80 (www)”.

The main problem is that it is quite difficult to verify whether a system implementation conforms to its policy. However, if one can not ensure this conformance, the global security can not be guaranteed anymore. Most current work only concentrate to define meta-languages in order to ex- press security policies and provide unambiguous rules. Once the security policy is formally specified, it is essential to prove that the target system imple- ments this policy by (1) injecting this policy in the system considered or (2) specifying formally the target system and generating proofs that this system implements the security policy or (3) by considering several strategies of formal tests.

Completeness of policy refinement

Source: N. Damianou, A. Bandara, M. Sloman, and E. Lupu. A Survey of Policy Specification Approaches. Technical re- port, Department of Computing, Imperial College of Science Technology and Medicine, London, 2002.

The objective of policy refinement is to transform high-level policy specifications into more specific policies that would be better suited for use in different execution environments.

Definition: (Policy Refinement) If there exists a set of policies Prs:p1, p2, .. pn, such that the enforcement of a combination of these policies results in a system behaving in an identical manner to a system that is enforcing some base policy Pb, it can be said that Prs is a refinement of Pb. The set of policies Prs:p1, p2, .. pn is referred to as the refined policy set.

A policy refinement can be said to complete iff all the following properties hold:
1.    Correctness: a refinement is said to be correct if there exists a subset of the refined policy set such that the conjunction of all the members of that subset is also a refinement of the base policy.
2.    Consistency: refinement is said to be consistent if there are no conflicts between any of the policies in the refined policy set.
3.    Minimality: a refinement is said to be minimal if it is correct and if removing any policy from the refined policy set causes the refinement to be incorrect.

Handling Conflicts between policies

Source: N. Damianou, A. Bandara, M. Sloman, and E. Lupu. A Survey of Policy Specification Approaches. Technical re- port, Department of Computing, Imperial College of Sci-
ence Technology and Medicine, London, 2002.


Jajodia et al. 1997, proposes that a conflict, once detected could be handled in one of three ways. The most obvious and simplest one is for the system to declare an error condition whenever a conflict arises. However, this solution is not particularly interesting since it does not allow for the system to automatically recover from the conflicting scenario. Other solutions are to allow the positive policy to override; or to let the negative policy override. The latter strategy is adopting an approach of ‘‘do no harm’’, based on the assumption that the negative policy (i.e. the one that prevents an action being performed) has a more benign effect on the system than its conflicting counterpart. As would be expected, the positive policy override strategy is the exact converse of the negative override approach described.

In addition to the negative and positive override strategies mentioned above, [Lupu and Sloman 1999] also identifies some alternatives. One approach suggested is to assign explicit priorities to every policy. This way when a conflict arises the agent enforcing the policy could simply compare the priority values and enforce the policy that has the highest priority. However, this approach could easily lead to inconsistent behaviour of the system if, as is common in distributed systems, multiple people are responsible for defining policies and assigning their priorities. Other strategies suggested include giving priority to the policy that is ‘closest’ to the managed object; or using the specificity of the policy definition to determine the priority.

[Moffet and Sloman 1993] introduces the idea of policy hierarchies and the application of policy refinement to derive lower-level, more specific policies from high-level ones.
policy refinement is to transform high-level policy specifications into more specific policies that would be better suited for use in different execution environments.

Challenges facing security policies in PAIS

Source: M. Leitner. Security policies in adaptive process-aware information systems: Existing approaches and challenges. In ARES 2011, 6th International Conference on Availability, Reliability and Security, New York City, 2011. Institute of Electrical and Electronics Engineers (IEEE).

The paper provided 6 challenges that are facing security policies in PAIS, and also provided a requirement that if fulfilled then the challenge will be solved. the following are summary of the challenges and the requirements to solve the challenges.

** all information below is quoted directly from the source paper, non of this is in my own words **

Challenge 1: Modeling Security Policies

1) Policy Modeling:

Problems: While an imperative approach is very strict and definite, it may not be reasonable for certain domains where ad hoc decisions based on circumstances have to be made. In terms of security, a security expert has to examine all possibilities and specify all policies in advance in the declarative model. Especially in large systems, it is difficult to oversee all regulations, possible vulnerabilities, or risks for all processes. This might be demanding in a declarative model because all potential occurrences have to be examined.

Requirements: It is important to consider the policy modeling approach depending on the domain of the PAIS. A declarative approach presents a more flexible way for integrating ad hoc changes. However, enforcing security can be difficult because potential process paths have to be analyzed and the risks of threats minimized. An imperative modeling type enables a stringent security policy definition (e.g. authorization) and is therefore more solid because not all potential pathways have to be foreseen.

2) Process Modeling:

Problems: Current commercial systems mostly use attached and inherent process modeling but research proto- types tend to focus on a separate policy implementation. This distinction leads to various research scenarios.

Requirements: In general, it should be possible to separate the process model and the security policies from each other. Then, the checks for inconsistencies are more efficient in a repository (than e.g. going through each activity in a process). A repository supports also the administration of policies such as adding, updating or deleting which is essential due to continuously changing business requirements. Furthermore, separating process models from policies facilitates the evolution of processes. If the policies are not included in the data and control flow of the model, the process models can be significantly reduced to a minimal set of tasks.

3) Modeling Extensions:

Problems: Current approaches provide only some security function modeling and are at a very early stage. They neither provide patterns for all security policies nor specify a standardized vocabulary for enforcing security in PAIS. Current proposals use different symbols or text to display security. Modeling security policies in PAIS might include further challenges such as visualization. Imagine a large process model: Is it possible to present security-critical information in large models?

Requirements: It is necessary to identify the require- ments to enable security modeling extensions for standard notations. We require to investigate how to display semantical or technical security features. In large process models, the model should be kept simple and complexity should not increase due to security extensions.

Challenge 2: Separating Security Policies from other Constraints:

Problems: Imagine a PAIS within the health care domain. There are a lot of guidelines that have to be included in the processes such as medical guidelines, public health guidelines, law, and budget restrictions. However, all guidelines have to be integrated in the processes. But which guidelines can be specified as security policies?

Requirements: Security guidelines originate from various sources and have to be incorporated in PAIS. Security policies in PAIS should be related to the security objectives confidentiality, integrity, and availability. For example, the guideline “A surgery can only be performed with two doctors” is user- centric and relates to availability. Therefore, the rule can be categorized as a security policy in PAIS. This approach can be extended to other security principles (e.g. privacy).

Challenge 3: Mapping Policies to Process Activities:

Problems: Policies can be administered at build and run time. The inherent approach does not support all constraints such as inter-process constraints. Imagine, a large system with about 500 roles, 1500 activities, and 500 security policies. Associating each policy to many activities is troublesome and inefficient. At this point it gets difficult: How can policies be associated with activities? Which criteria should be considered?

Requirements: Ideally, there should be a mechanism that maps the security policies to process activities. However, to be able to handle the mapping, we need to know which rules should be associated with which activity. We demand an easy and manageable association of activities and policies at a fair level of complexity. Furthermore, we also require that scalability should be supported.

Challenge 4: Process Evolution:

Problems: When a process changes such as add, delete, or move an activity all associated constraints have to be checked for correctness.

Requirements: When a process changes, the corresponding policies (e.g. authorization constraints) should be validated. Because workflows can change at build and run time it is important to develop mechanisms to manage both scenarios. It should be possible to change an activity and to further maintain the security of the activity at the same level regardless of e.g. the changed control flow or data flow.

Challenge 5: Policy Evolution:

Problems: Approaches focus mostly on build time strategies where policies are set and checked for conflicts. However, policies such as authorization con- straints or legal regulations evolve over time.

Requirements: There is a need for administration of security policies such as adding, deleting, or updating rules. We require to enable an easy handling and maintenance of security policies at build, run, and change time. Therefore, security policies and process models should be administered separately.

Challenge 6: Inter-process Security Policies:

Problems: Current systems neither provide inter- process security policies nor enable a semantical support. However, the interaction between process instances becomes more importan.

Requirements: In PAIS, there is a growing need of more interaction between process instances. In particular, security policies should be enforced over multiple instances. When enabling interaction between instances, designers and practitioners have to tackle another challenge: How to model, implement, and enforce inter-instance constraints at a fair level of complexity.

Security policies in PAIS

Source: M. Leitner. Security policies in adaptive process-aware information systems: Existing approaches and challenges. In ARES 2011, 6th International Conference on Availability, Reliability and Security, New York City, 2011. Institute of Electrical and Electronics Engineers (IEEE).

** all information below is quoted directly from the source paper, non of this is in my own words **

In PAIS, security policies are often related to role-based access control restrictions or constraints (e.g. separation of duties). But to be more specific, security policies in PAIS might relate to access control, control flow, information flow, data integrity, and availability. Therefore, policies can be specified for users, information (data), control flow, activities, and process instances. Can be enforced at build time (static constraints) and run time (dynamic).

security policies in PAIS categorized by the main key concepts of information security: confidentiality, integrity, and availability:

• Confidentiality: In PAIS, confidentiality is usually ensured by an access control model and constraints associated with activities. Information should only be accessible to authorized users.

• Integrity: A security policy for the integrity of a control flow signifies that, for example, a certain activity has to be finished before another activity starts (e.g. activity PayQuotation has to be completed before SendShipment). Integrity of data means that no user who is unauthorized to access the data can modify it. Therefore, only authorized actions are carried out on data.

• Availability: In PAIS, availability may refer to the system, resources (e.g. data, users), or the control flow which can be verified with the workflow liveliness and soundness.