Summary: The Ponder Policy Specification Language

N. Damianou, N. Dulay, E. Lupu, and M. Sloman. The ponder specification language. In Workshop on Policies for Distributed Systems and Networks (Policy2001), pages 29–31, Bristol, UK, Jan 2001. HP Labs.

N. Damianou, N. Dulay, E. Lupu, M. Sloman, and N. D. N. Dulay. Ponder: An object-oriented language for specifying security and management policies, 2000.

N. Damianou, N. Dulay, E. Lupu, and M. Sloman. Ponder: A language for specifying security and management policies for distributed systems. Research Report. London, UK, Imperial College, Octuber 2000.

These papers introduced Ponder an object-orientate security policy language that has the ability to represent authorization, obligations, refrain, and delegation policies. It can also represent time and state constrains. Ponder is a flexible language that allows reuse of policy specifications, and it provides scalability by allowing composite policy types.

Ponder right rules in the form of: first stating the type of the policy (auth+, auth-, delg+, …) then stating the name of the policy (so it might be reused later). Then stating the subject (user), the target (object e.g. resource), and action, finally a when (for time constrains) is optional.  Ponder pre-defined type of policies; it has auth+ (for granting authority), auth- (for revoking authority), deleg+ (to grant delegation), deleg- (to revoke delegation), refrain (to apply prohibition), and oblig (to present obligations). Ponder also provides ‘filter’ to be able to apply specific constrain (e.g. location, time, specific target, etc.) on a policy. Ponder also make use of roles (group of people with the same role e.g. system administrator) and groups (group of people with anything in common e.g. same floor, same branch, etc.) to make it easier to manage large complex organizations. Finally, Ponder uses meta-policies, which are policies about policies, to avoid conflicts and to control the sequence of the policies.

Ponder has pre-defined the policy types, and each of these types has its own structure, for example if you are using delegation policy you need to add the ‘grantee’ filed, which specify the element receiving the delegation. For obligation policies you need to add ‘do’ filed.  

Damianou et al. in these papers introduced Ponder; a security policy language that has the ability to represent authorizations, obligations, delegations, and prohibitions. Ponder is different that it pre-defined the type of policies to be used, and provided a structure for each of these policies. Although Ponder covered a wide range of policies, but this pre-definition method made it hard to add to Ponder and to widen the language capabilities. Ponder provides conflict resolution using meta-policies, it also makes use of groups and roles to provide scalability to large organization. Ponder also provide flexibility by reusing the policies. Ponder focuses on access control and obligations. It also has the ability to represent time and state constrains. The use of filters in Ponder made it easy to apply any type of constrains such as sequence constrains. As a drawback, Ponder is not an easy language to understand or to map to runtime object-model. 

Summary: A POLICY DESCRIPTION LANGUAGE

J. Lobo, R. Bhatia, and S. A. Naqvi. A policy description language. In AAAI/IAAI, pages 291–298, 1999.

This paper introduced Policy Description Language (PDL), which is a real-time specialized production rule language to define policies. It is a declarative language. PDL has three categories: 1- set of events (e.g. router is down). 2- set of actions (send alert email). 3- set of functions to evaluate the environment (disk is 95% full). Each of these categories has its own class of symbols. PDL take in consideration sequence constrains.

In PDL policies are described by a collection of propositions of two types; policy rule propositions and policy defined event propositions. Policy rule propositions are expressions of the form:

event causes action if condition.

Which mean if the event occurs in a situation where the condition is true then the action will be executed.

A policy defined event proposition is an expression of the form:

event triggers pde(Ml = T1,...,Mk = Tk) if condition

Which mean if the event occurs in a situation where the condition is true, an instance of the primitive event pde will occur in the immediately following epoch with the valuation of each Ti as the value assigned to each attribute Mi of pde.

The language is a generic language that can be used to describe any type of policies and not only security policies. but as the authors claim it is a first proposal that is expected to grow. PDL do not have the ability to solve conflict or even detect them. The language can not distinguish between rights and obligations.

Lobo et al. in this paper introduce a new language: Policy Description Language (PDL). The authors admit it is a first proposal and that it is expected to grow. PDL is a language that can be used to describe any type of policies and not only security policies. it describes policy as an actions that take place at a specific event if the condition was true. This type of formalization will allow representing obligations, and prohibitions, but it do not have the ability to solve conflict or even detect them. The language cannot distinguish between rights and obligations. If delegation looked at as an action then it would be passable to represent delegations using PDL.

Summary: A Policy Language for a Pervasive Computing Environment

L. Kagal, T. W. Finin, and A. Joshi. A policy language for a pervasive computing environment. In POLICY, pages 63–. IEEE Computer Society, 2003.

This paper introduced a new language called Rei, which is based on deontic logic, and able to represent rights, prohibitions, obligations and dispensations. It is also able to solve conflicts, and represent delegations by using action operators. It is also able to reprsent sequance obligations. Rei express policies as what an entity (user, agent, service, etc.) ‘can’/‘can not’ and ‘should’/‘should not’ do in terms of actions, services, and conversations.

Rei includes three types of constructs: (i) policy objects, which represent rights, obligations, prohibitions and dispensations, (ii) meta policies, which is used for conflict resolution, and (iii)speech acts, which is used to dynamically modify the system; delegate, revoke, cancel and request. In Rei policies can be individual, role, or group – based policy. Also can be any combination of the three. This mechanism is different from other policy languages, which include special constructs for role/group based rights/obligations.

“Rights are permissions that an entity has. The possession of a right allows the entity to perform the associated action”. “Prohibitions are negative authorizations implying that an entity cannot perform the action”. “Obligations are actions that an entity must perform and are usually triggered when a certain set of conditions are true”. “Dispensations are actions that an entity is no longer required to perform. They act as waivers for existing obligations”.

Rei represent any rule as followe: PolicyObject(Action, Conditions), and to associate a policy object with an entity, the has construct is used: has(Subject, PolicyObject). Actions can be represented as a tuple with the following parameters: action(ActionName, TargetObjects, Pre-Conditions, Effects).

Rei includes four action operators that allow various kinds of complex actions to be specified; sequence: seq(A,B) denotes that action B must only be performed after action A. non-deterministic: nond(A,B) denotes either A or B can be performed, but not both. Once: once(A) denotes that A can only be performed once. Repetition: repetition(A) denotes that A can be executed several times.

Rei includes specifications for four speech acts that affect the policy objects of the communicating entities: (i) delegation, (ii) request, (iii) cancel, and (iv) revocation. Delegation allows an entity to give a right to another entity or group of entities, which can be represented as delegateSpeechAct(Sender, Receiver, right(Action, Condition)), where ‘Sender’ is the person delegating the right, ‘Reciver’ is the person receiving the delegated right, and ‘action’ represent the action that is delegated. Request: there are two kinds of requests; a request for an action and a request for a right. It is represented as requestSpeechAct(Sender,Receiver,Action) à disagree. Revocation is the removal of a right and acts as a prohibition, and it is represented as: revokeSpeechAct(Sender, Receiver, right(Action, Condition)).  Cancel: An entity can cancel any request it has sent. It can be represented as: cancelSpeechAct(Sender, Receiver, right(Action, X)).

Rei permits complex conditions, and supports the following operators: AND, OR, and NOT. A complex condition made of two conditions associated with an AND, will be true only when both conditions are true. A complex condition made of two conditions associated with an OR, will be true only when one of the conditions is true. A complex condition consisting of not(ComplexCondition) is true when Complex- Condition is cannot be proved.

In Rei if the conflict between ‘Right’ and ‘prohibition’ was solved, it will solve every other conflict. Rei uses Meta policies, which are “policies about how policies themselves are interpreted and how conflicts are resolved at run-time”. Meta policies regulate conflicting policies in two ways; (i) priorities (overrides(A1, B1) means A1 is given priority over B1), and (ii) precedence relations, which can be either positive or negative (negative means prohibitions hold over rights and dispensations are stronger than obligations). It can be general over the whole policy (metaRule(Policy, positive/negative)), over a set of actions (metaRuleAction(ActionConditions, positive/negative)), or over a set of entities (metaRuleAgent(ConditionOnAgent, positive/negative)).

Delegation is an important aspect in security policies. Rei identifies two types of delegation, while-delegations and when-delegations. “A while-delegation forces all following delegators to satisfy its conditions in order to be true. Whereas a when-delegation requires the immediate delegator to satisfy its conditions only at the time of the delegation and not after”. The default delegation type is the while delegation.

The paper then presented an application example showing the usefulness of using Rei. After that it compared Rei with other available languages such as Ponder, Woo and Lam work, and Jajodia et al.’s work. It also showed how Rei made use of the work by Sloman and the work by Lupu.

Kagal et al in this paper introduced Rei; as security policy language, that is based on deontic logic. It has the ability to represent obligations, rights, prohibitions and dispensations. It introduces two methods that can be used to solve conflicts, but both of these methods solve conflicts at run time when detected. Rei do not offer a design time conflict resolution method, which is more practical. Rei has the ability to represent sequence requirements, and if an action is required once or more. It is also able to represent complex rules using AND, OR, and NOT parameters. An important aspect of Rei that it has the ability to represent delegations, and distinguish between two types of delegation, also it distinguish between the right to execute and the right to delegate. Finally it has the ability to represent revocation, requests, and cancelation. Rei has strong representation capabilities; it is able to cover most of the security requirements, but it is a complex language. It is very strong on delegation, but might need some enhancement in conflict resolution.

summary: A FORMAL ANALYSIS OF A BUSINESS CONTRACT LANGUAGE

G. Governatori and Z. Milosevic. A formal analysis of a business contract language. Int. J. Cooperative Inf. Syst., 15(4):659–685, 2006.

This paper presents a formal system for describing contracts in terms of deontic concepts such as obligations, permissions and prohibitions, and the logic supports reasoning about violations of obligations in contracts. Using a formal representation for contracts. The paper first provided a sample contract to be used as an example. The showed the importance of using formal languages to represent contracts. After that stated that a formal language intended to represent contracts should provide notions related to the concepts of obligations, permissions, and entitlements.

The paper explained the FCL rules anatomy (r : ¬p,¬α |- OSupplierβ) showing that every rule should start with a unique name/id (r), then a list of conditions (¬p,¬α ), that when true, a consequence (OSupplierβ) to be applied. It also showed that FCL could represent permission, obligation, prohibition, and negation. Another useful tool used by FCL is the ‘⊗-expression’ that can be used to repair violations. FCL can be used to analyse contracts and to reason about them so that ambiguities in a contract can be identified.

The paper then introduced a procedure that uses FCL to generate a formal (logical) form of the contract. First step to do so is to combine contract closes of obligations with the obligations that triggered in response to violations of these obligations. Second step is identifying and removing redundancies from the formal specifications, redundancy occur when the normative content of one rule (r2) are all included in another rule (r1), then we can easily say that r2 does not add anything and can be discarded. Final step is finding and solving the issue of conflicts by either creating a superiority relation over the rules (≺) and to use it do “defeat” the weaker rule, or by supplementing the antecedent of one rule with an additional guard.

The paper then gave an explanation about BCL (Business Contract Language). BCL is to enable monitoring of contract execution in an event-based manner. The main use of event patterns in BCL is to enable checking of policies related to a contract. Policies define behavioural constraints for the roles that carry out activities in a contract and these constraints are described in terms of event patterns. Policy checking consists of identifying event patterns in activities of parties filling a role and establishing whether they satisfy the policies. The policies take a form of modal constraints such as obligations, permissions and prohibitions. A policy violation can be linked to another policy that can take effect in response to this violation.

BCL uses the following attributes:

·      Role: to label a party whose behavior is constrained by the policy. 

·      Event patterns: where events can be matched with event patterns using event type. Checking policies consists of identifying event patterns in activates. Events in BCL can have event roles, which can be linked to contract roles.

·      State: used to define data value shared by participants. It is used to maintain running totals, counters, and other states.

·      Policy: it is associated with a role and indicate wither it is an obligation, permission, or prohibition. Policy consist of a name, the role that this policy applies to, what type of modality applies, what triggers this policy, and what is the expected behavior based on this policy. It might also include a Guard that specify a specific timing when will this policy should be applied. A guard can be used to specify that a policy only will occur in case of violation of another policy.

The authors stated that even thought there are other contract languages such as Contract Expression Language, Web Services Level Agreements and ecXML. BCL “covers broader aspects, including the organisational context for the definition of policies, behaviour and structure and relationships between these concepts”.

Finally the paper introduced a mapping from FCL to BCL, and then from BCL to FCL. To map FCL to BCL, the name/id of the rule in FCL can map to the policy name in BCL. The model literal in FCL rule gives the role, modality, and expected behavior of BCL policy. Finally the condition literals in FCL rule will map to trigger in BCL policy.  The same concept can be reversed to map from BCL to FCL.

The paper then stated that BCL need a better separation between subject and target roles, also a better separation between trigger event and the action event. Another shortcoming of BCL is the lack of priorities support between rules to avoid conflicts. BCL need to be tested against the notions of delegation and authorization.

Summary: An Algorithm for Business Process Compliance

G. Governatori and A. Rotolo. An algorithm for business process compliance. In E. Francesconi, G. Sartor, and D. Tiscornia, editors, JURIX, volume 189 of Frontiers in Artificial Intelligence and Applications, pages 186–191. IOS Press, 2008.

Business process compliance means the adherence or consistence of a set of specifications modelling a business process and a set of specifications modelling the norms for a particular business. Business process specifications describe how a process is executed, while norms state what can be done and what cannot be done by a process. Compliance checking is to figure out (a) which obligations will definitely appear when executing the process, and (b) which of those obligations may not be fulfilled. This paper introduces an algorithm that provides a compliance checking.

The paper first chooses FCL as the formal rules language, FCL (Formal Contract Language) is a logical language that represents rules as expressions. FCL uses the following operators ¬(negation), O (obligation), P (permission), and ⊗ (violation/reparation), ∼p denote the complement of p. (≺) determines the priorities between two rules to avoid conflicts. FCL expressions such as:

r1 : account(y) ⇒ OpositiveBalance(y) ⊗ OapproveManager(y)

Which means for account y it is an obligation to have a positive balance, if this obligation was violated then it is an obligation to get manager approval. After writing all rules in FCL, one can enrich the process model by these rules expressions.

Then the paper explains process models showing how to annotate them with these rules expressions. Finally, it presents the compliance-checking algorithm. To do compliance checking there are three steps to go through. Step one ‘building procedure’, consists of the following: 1- identifying sets of effects for each task from the process model. 2- determine the normative position (obligation, permission, prohibition) for each set of effects of these tasks. 3- for each task check if obligation is fulfilled or a violation has occurred. Step two ‘from tasks to obligations’, which determine the obligations derived by the tasks. Step three ‘checking compliance’, is applying the checkCompliance algorithm.

Governatori and Rotolo in this paper proposed a compliance algorithm, using FCL as the rule modeling language. FCL has the ability to represent obligation, permission, and negation. It also has the ability to show what to do incase of violation. And also uses a priority operator to avoid conflicts. FCL do not differentiate between different types of obligations (e.g. if an obligation is continues or occur once). Also it does not have the ability to represent time constrains regulations, or if an obligation need to happen after another obligation already happened and never before.

summary: Designing Compliant Business Processes with Obligations and Permissions

S. Goedertier and J. Vanthienen. Designing compliant business processes with obligations and permissions. In J. Eder and S. Dustdar, editors, Business Process Management Workshops, volume 4103 of Lecture Notes in Computer Science, pages 5–14. Springer, 2006.

This paper introduces a new language called PENELOPE (Process ENtailment from the ELicitation of Obligations and PErmissions), a language to express temporal rules about the obligations and permissions in a business interaction. It does not consider the execution time monitoring of business contracts, but rather considers the impact of sequence and timing constraints on business process design.

PENELOPE uses deontic properties to express rules and regulations. It distinguishes between necessity and possibility in business policy and regulations, by considering the deontic modalities of obligation, conditional commitment and permission. It does not consider prohibition, as it is assumed if neither permission nor obligation can be derived. It allows to explicitly define deadlines. The following are some PENELOPE’s properties:

Termination of a process means that no obligations or permissions exist. If there exist obligations or permissions and no permissible performance exist to carry the business interaction forward it is called a deadlocks situation. Where In a livelock situation, the protocol state is trapped in an infinite loop. Deontic conflicts arise when there are protocols state a business partner has both the permission and the prohibition to an activity. This type of conflict is not possible in PENELOPE, as it does not make use of prohibition. Temporal conflicts occur when two deontic assignments at the same time initiate and terminate a permission, obligation or conditional commitment. Trust conflict occur when a business interaction puts the business in a position were it has direct obligations towards non-trusted business partners that involve sensitive activities. The paper provided an algorithm if followed one could avoid all these conflicts and locks.

Goedertier and Vanthienen in this paper presented a new language called PENELOPE, which is based on deontic logic. It has the ability to represent obligation, conditional commitment and permission. It does not represent prohibition, as it is assumed in case no permission nor obligation was presented. The assumption of prohibition gave the ability to avoid conflicts. It does not provide what to do in case of violation, as the language is more concerned with design time than execution time.

Summary: A Methodological Framework for Aligning Business Processes and Regulatory Compliance

S. Sadiq and G. Governatori. A methodological framework for aligning business processes and regulatory compliance. In J. Brocke and M. Rosemann, editors, Handbook of business process management: 2 Strategic alignment, governance, people and culture, International Handbooks on Information Systems, pages 159–176, Berlin and Heidelberg, 2010. Springer-Verlag Berlin Heidelberg.

This chapter focuses on compliance by design. It starts different types of compliance (detective, corrective, and preventive), and show that the best way to have a preventive method is to integrate compliance from the design stage. It also shows that to be able to have compliance first it is important to have a formal representation of the rules and regulations, then need to find an alignment between the two ontology (business rules languages and process model language), then need to have a compliance enforcement framework, and finally, compliance monitoring.

The chapter then reviewed the literature on business rules modeling languages. It stated that (Governatori, 2005), and (Governatori & Milosevic, 2006) have proposed FCL (Formal Contract Language) as a candidate for control modelling, which has proved effective due to its ability to reason with violations. While (Goedertier & Vanthienen, 2006) presents a logical language PENELOPE that provides the ability to verify temporal constraints arising from compliance requirements on affected business processes. (Kuster, Ryndina & Gall, 2007) provide a method to check compliance between object lifecycles that provide reference models for data artifacts e.g. insurance claims and business process models. (Giblin, Muller & Pfitzmann, 2006) who provide temporal rule patterns for regulatory policies, although the objective of this work is to facilitate event monitoring rather than the usage of the patterns for support of design time activities. Furthermore, (Agrawal, Johnson, Kiernan & Leymann, 2006) has presented a workflow architecture for supporting Sarbanes-Oxley Internal Controls, which include functions such as workflow modeling, active enforcement, workflow auditing, as well as anomaly detection. Although several proposals provide a powerful and conceptually faithful means of capturing controls, it still remains to be studied, how these formal models can be deployed in practice.

As shown earlier in the chapter modeling rules is only one step toward compliance, for this reason the chapter then reviewed the literature on enforcing the rules model into the process model (enriching business process models). It stated that the work by (zur Muehlen & Rosemann, 2005) and (Neiger, Churilov, zur Muehlen & Rosemann, 2006) provides an appealing method for integrating risks in business processes. The proposed technique for “risk-aware” business process models is developed for EPCs (Event Process Chains) using an ex- tended notation. (Sadiq, Governatori & Namiri, 2007) propose an approach based on control tags to visualize internal controls on process models. (Liu, Muller & Xu, 2007) takes a similar approach of annotating and checking process models against compliance rules, although the visual rule language, namely BPSL is general purpose and does not directly address the notions representing compliance requirements.

The chapter then concluded by showing that a theoretically rigorous and practically feasible means of control modelling supported by a powerful analysis machinery that provides diagnostic support for comparing business and control objectives has the potential to create a holistic approach to compliance management, by not only providing preventative and detective techniques, but also corrective recommendations. Then indicated that future research in this area should strive towards compliance management frameworks that provide a close integration of the three perspectives namely preventative, detective and corrective. Such a framework can allow organizations to better respond to the changing regulatory demands and also reap the benefits of process improvement.

Sadiq and Governatori in this chapter provided a holistic overview over the ‘business process compliance’ topic. The chapter showed different types of compliance (detective, corrective, and preventive), and showed that compliance by design is the best way to have a preventive compliance method. The authors emphasized at the importance of having formal representations of business rules and then enriching the business process models with compliance requirements. The chapter then provided a literature review for both aspects. The chapter concluded with a discussion showing that a rigorous and feasible formal representation of the business rules that can be used to enrich a business process model and provides a diagnostic support, can potentially provide a holistic approach to compliance management.