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.

 

Security Policies ..

Source: Maria Leitner,Stefanie Rinderle-Ma, and Juergen Mangler. Responsibility-driven Design and Development of Process-aware Security Policies. in Sixth International Conference on Availability, Reliability and Security. 2011.

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

Security policies are a set of principles that control which subject is allowed to access which object within an information systems. In PAIS, however, security policies require a more detailed definition due to the multi-faceted characteristics of such systems. Specifically, security policies in PAIS might relate to access control, control flow, information flow, data integrity, and availability.

Security aspects in security polices:
Structural Aspect: denotes a set of data objects and tasks, and how they occur in a process model.
- Responsibilities: We define a responsibility r to be a piece of data or interrelated tasks from the point of a certain role.
Operational Aspect: denotes constraints on this data objects and tasks, for example during process execution. I.e. under which circumstances something is allowed.
- Permissions: define which operations (execute, monitor) are allowed for which security objects (process execution, process model change, service selection).

 

What is a secure Workflow

Source: P. C. K. Hung and K. Karlapalem, “A secure workflow model,” in Proc. of AISC on ACSW frontiers 2003 - Volume 21.    Australian Computer Society, Inc., 2003, pp. 33–41.

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

Definition 1:    A secure workflow is a computer supported business process that is capable to against security threats and further satisfies the security requirements defined by the workflow modeler.

Definition 2: A secure Workflow Management System (WFMS) is a workflow management system that can specify, manage and execute a secure workflow.

==========

In a secure workflow model, there are three layers for a secure state: Workflow, Data and Control:

Workflow:
Availability in the workflow layer is: “For every task there must be at least one agent who is able to execute the task.”

Integrity and Authorization in the work- flow layer is: “An agent can only execute the assigned task if and only if the privilege “execute” is granted. The secure workflow has to revoke the privilege from an agent if the task has completed execution.”

Data:
Integrity and Authorization in the data layer is: “An agent can only access a document with a specific privilege if and only if the document access privilege is granted to the agent and also it is needed to access the document with the privilege during the task execution. The secure workflow has to revoke the document access privilege from an agent if the document access privilege is no longer needed.”

==========

To ensure the property of authorization:
The secure workflow model assigns the task to an agent if and only if the agent can execute the task.

To ensure the properties of integrity and authorization, the secure workflow model:
- Grants the task to the assigned agent for execution if and only if the set of input events is generated, the task is not started and all the dependent tasks are completed in the relevant session.
- Revokes the task from the assigned agent if and only if the set of output events is generated and all the granted privileges for documents are revoked in the session.
- Grants the document access privilege to the agent for execution if and only if it is authorized by the task’s TAC in the session.
- Revokes the document access privilege from the agent if and only if the document access privilege or task is completed in the session.
- (an agent can) generate the event for a task if and only if it is authorized in the session.

Dimensions of trust

Trust is both and emotional and logical act. Emotionally, it is where you expose your vulnerabilities to people, but believing they will not take advantage of your openness. Logically, it is where you have assessed the probabilities of gain and loss, calculating expected utility based on hard performance data, and concluded that the person in question will behave in a predictable manner. In practice, trust is a bit of both. I trust you because I have experienced your trustworthiness and because I have faith in human nature.
We feel trust. Emotions associated with trust include companionship, friendship, love, agreement, relaxation, comfort.
There are a number of different ways we can define trust. Here are the dimensions of trust and consequent definitions.

Predictability

It is a normal part of the human condition to be constantly forecasting ahead. We build internal models of the world based both on our experiences and what others tell us, and then use these to guess what will happen next. This allows us to spot and prepare for threats and also make plans to achieve our longer-term goals.
The greatest unpredictability is at 50%; a reliable enemy can be preferable to an unpredictable friend, as at least we know where we are with them.

Definition 1: Trust means being able to predict what other people will do and what situations will occur. If we can surround ourselves with people we trust, then we can create a safe present and an even better future.

Value exchange

Most of what we do with other people is based around exchange, which is the basis for all businesses as well as simple relationships. At its simplest, it is exchange of goods. I will swap you two sheep for one cow. It is easy to calculate the value in such material bargaining. Things get more complex when less tangible forces come into play. A parent exchanges attention for love. A company exchanges not only pay but good working conditions for the intellectual and manual efforts of its workforce.
Value exchange works because we each value things differently. If I have a whole flock of sheep but no milk, then I can do business with a person who has a herd of cows but no clothes. This principle of reciprocity is what binds societies together.
Trust in value exchange occurs when we do not know fully whether what we are receiving is what we expect. When we buy a car, don’t want to be sold a ringer which the seller knows is faulty. When I get advice in business, I want it to be based on facts, not wild opinions.

Definition 2: Trust means making an exchange with someone when you do not have full knowledge about them, their intent and the things they are offering to you.

Delayed reciprocity

Exchange is not just about an immediate swapping of cows and sheep or hugs and kisses. What makes companies and societies really work is that something is given now, but the return is paid back some time in the future. The advantage of this is that we can create a more flexible environment, where you can get what you need when you need it, rather than having to save up for it.
Trust now becomes particularly important, because otherwise we are giving something for nothing. The delay we have placed in the reciprocal arrangement adds a high level of uncertainty which we need to mitigate through trust.
What is often called the ‘golden rule’ is a simple formula for creating trust. ‘Do unto others as you would have them do unto you.’ It sets up the dynamic for my giving you something now with the hope of getting back some unspecified thing in the indeterminate future.

Definition 3: Trust means giving something now with an expectation that it will be repaid, possibly in some unspecified way at some unspecified time in the future.

Exposed vulnerabilities

When we trust other people, we may not only be giving them something in hope of getting something else back in the future, we may also be exposing ourselves in a way that they can take advantage of our vulnerabilities. If I buy a car from you and I do not know a good price, you can lie to me so you get a better bargain. If I tell you in confidence about the problems I am having with work, you could use this to further your own career at my expense.
Although the threat of retribution or projected feelings of guilt can counteract your temptation to abuse my exposed vulnerabilities, if you succumb I still get hurt and may still end up with the shorter stick. For our transaction to complete successfully, I must be able to trust that such agonies will not come to pass.

Definition 4: Trust means enabling other people to take advantage of your vulnerabilities—but expecting that they will not do this.

Trust if you do it well, other people will give you the earth. If you betray them, they will hunt you to the ends of the earth.

The Challenge of Conceptualizing Trust and Distrust ..

Resource: D. H. McKnight and N. L. Chervany. Trust and distrust definitions: One bite at a time. In R. Falcone, M. P. Singh, and Y.-H. Tan, editors, Trust in Cyber-societies, volume 2246 of Lecture Notes in Computer Science, pages 27–54. Springer, 2000.

An analysis of the word trust in three unabridged dictionaries (Websters, Random House, and Oxford) showed that trust had far more definitions (9, 24, and 18, respectively) than did the terms cooperation (3, 2, 6), confidence (6, 8, 13), and predictable (1, 2, 1). On average, trust had 17.0 definitions, while the others had an average of 4.7. Trust had close to as many definitions as did the very vague terms ‘love’ and ‘like.’ Hence, trust is by nature hard to narrow down to one specific definition because of the richness of meanings the term conveys in everyday usage.

It is hard to follow and difficult to compare with each other because the term trust is defined in a multitude of different ways. Trust has not only been described as an “elusive” concept [103: 130], but the state of trust definitions has been called a “conceptual confusion” [50: 975], a “confusing potpourri” [86: 625], and even a “conceptual morass” [3: 1, 10: 473].

“ ... trust is a term with many meanings.” – Oliver Williamson
“ Trust is itself a term for a clustering of meanings.” – Harrison White

92% of the definitions that involved trustee characteristics fell within these four categories:

• Benevolence means caring and being motivated to act in one’s interest rather than acting opportunistically [34].
• Integrity means making good faith agreements, telling the truth, and fulfilling promises [9].
• Competence means having the ability or power to do for one what one needs done [3].
• Predictability means trustee actions (good or bad) that are consistent enough to be forecasted in a given situation.