K. Irwin, T. Yu, W. Winsborough. 2008. "Enforcing Security Properties in Task-based Systems"

In this paper, we introduce the concept of tasks into access control, and use tasks as a central and explicit means to constraining privileges of users.


Advantages

1. Tasks are a natural way to think about user actions and their contexts.
2. Many privacy policies require identifying the purposes of actions. It is much easier to categorize the purpose of a task than that of an individual action.

Given an assignment of privileges to tasks and tasks to users, and a high level security property, there are two questions which should be examined.

1. Whether it is possible for a user to abuse the granted privileges and violate a high-level security property. If the answer is no, the system simply needs to check a user’s privileges when she attempts an action. Otherwise, the system has to keep track of the operations that a principal has conducted thus far, and dynamically enforce the high-level security properties.
2. How to reduce the complexity of the dynamic enforcement of a security property.

Two types of security properties

• Intra-task properties proscribe action sequences that must not be performed by using the privileges granted for a single task.
• Inter-task properties must not be violated by using privileges obtained from any assigned tasks.

Access control policy level

• access control policies concern when and under what circumstances privileges may be granted to or revoked from principals
• distinguished from the current access control state which indicates what privileges each user holds at present
  • access control state may change as part of the normal operation of a system, as long as the change is allowed by the system’s access control policy

Ways to enforce security property

1. design an access control policy that ensures no user will ever obtain privileges that enable her to violate that security property.
   • For example, consider a security property that states Alice should never be allowed to perform action a. To enforce it at the access control-policy level, we need to show that, from an initial state, no matter how the access control state changes, as long as each change conforms to the policy, Alice will never get the privilege to perform a.
   • advantage of this approach is that the runtime execution of the system is quite simple.
   • however, the problem to determine whether an access control policy enforces a security property can be challenging
2. design policies conservatively so they are clearly sufficient to enforce security properties
   • this approach often force policies to be too conservative to be useful

Access control state level

• a system’s access control state describes the privileges each user has at a given time

Ways to enforce security property

1. when an action is performed that would change the privileges of a user (especially when new privileges are about to be granted), the reference monitor could first determine whether the new access control state would enable the user to perform actions that violate security properties. If so, the attempt to change the privileges can be denied even if it would have otherwise been allowed by the access control policy.

Action-execution level
Ways to enforce security property

1. monitor what actions are actually performed. A user’s action request will be denied if the action, taken in the context of the user’s previous actions, would violate a security property.
• When the manager attempts to submit a reimbursement request, the system allows it to be executed, but also records the action. If the manager later attempts to approve the same reimbursement, because the system records the prior action, it would determine that the approval would violate the security property, and rejects it.
• offers the maximum flexibility in terms of how users may fulfill their tasks
• the history information for each user might be quite large
• execution-level enforcement has to perform analysis every time a user attempts to take an action

In practice, it would be desirable to combine the above three types of enforcement mechanisms to secure an information system.



Task-based system

• U: a set of users.
• K: a set of tasks which users may carry on.
• A: a set of actions that can be taken by users.
• t: a clock t, which we represent as a real number.
  • At any time an action is attempted, the clock will have some value in the domain T = R+, with 0 indicating the system start time.
  • We assume that any two action attempts can be ordered. This can either be accomplished by assuming that no two action attempts happen at precisely the same time or by assuming that there is an ordering on the actions such that if two are attempted at precisely the same time, then they are still processed sequentially.
    
  • Although the set of reals is uncountable, we will only be dealing with a finite subset in practice since only time points at which actions occur or permissions change are relevant.
• P = A×T ×T : a set of privileges.
  • Each privilege (a, s, e) element_of P identifies a time window during which the permission for action a is available. That is to say, if s <>
  • We require s < style="font-style: italic;">element_of P.
• F: a privilege-granting function which takes as input a task k and a time point t, and returns a set of privileges.
  • A privilege granting function abstracts the access control policy of a system. It is intended to be flexible in several respects so that it can represent various policies for granting privileges to users.
  • First, the returned privileges of a privilege granting function are not restricted to a single user. This enables the modeling of privilege assignments for collaborative tasks.
  • Second, the returned privileges are not required to have the same time period. In other words, it is possible for a system to require that one privilege is used before another one.
  • Third, we allow different privileges to be returned if the same task is assigned at different times. This gives a system the flexibility to decide the necessary privileges for a task by considering the current state of a system.
  • Observe that if two privileges are about the same permission and their time periods overlap, we can always merge them into a single privilege by merging their time periods. Clearly, this will neither increase nor decrease what the user can do.

The access control state of a system is a subset of U × K × P. It contains one entry for each permission granted to each user and for each task assigned to the user that requires the permission. In other words, if a given user has a given permission that she needs for each of two tasks, there will be two entries in the access control state, one for each task.



Security properties
Most practical security properties should be amenable to modeling as a finite state automaton to be effectively enforced in an information system.

In our model, undesirable sequences of user actions and times are those that are accepted by the automaton, which are said to violate the modeled security property.

If an action sequence q violates a security property, all the sequences that have q as a prefix also violate that property.

NFA examples
It is a security violation if a summer intern modifies the database of a company.


The clerk initiating a legal draft should not be the principal who decides whether reviews
by stakeholders are required.



In order to use a company fax machine, an employee is required to log his usage first, e.g., where the fax is sent to and with how many pages. In other words, it is a violation of the company’s policy to send a fax unless it is logged, which is a compensatory action.

A computer system has a temporary directory used as a scratch space. To prevent information leakage, if a user queries a sensitive database and then writes to the temporary directory, then she must not copy anything from the temporary directory to a public ftp server, unless the system first empties the temporary directory.



We focus on enforcing a security property of the behavior of a single user. (when considering collusion among multiple users, the problem becomes intractable)



Enforcing intra-task property
Access state level enforcement
Given a user’s access state, whether it is possible for her to violate a security property.

• If the answer is that she cannot violate the property, then we only need enforce access control according to the user’s access state (i.e., whether she has a permission at the current time), and need not maintain any further information to check for violation of intra-task properties.

Let P be a user’s privileges obtained from a task k, and H be a intra-task property. If no action sequences compatible with P violates H, we say P enforces H.

• Basically, we convert P to a finite state machine M which accepts exactly those sequences compatible with P. P enforces H if and only if the intersection ofM andH is empty, which can be efficiently checked.

With system compensatory actions





Given a set of users along with their privileges and a security property H, do there exist fewer than k users whose privileges put together enable those users to violate H? NP complete in general


Reduce privileges to enforce property
Reducing a user’s privilege risks the possibility that we could prevent the user from carrying out legitimate actions which are needed to complete the task.
As such, if we are to change the access state, we must logically do it in a minimal way to reduce its impact on task fulfillment.

The problem to minimize the reduction of a user’s privileges to enforce a security property is intractable.


Action execution level enforcement
Conceptually, given an NFA H that defines a security property, the system maintains the set of states that a user is in.

• Whenever a user submits a request to take an action at time t, the system would first check whether the user has the right permission at t.
• If she does, the system would further consult H and determine, if the action is taken, what states the user would be in, and whether those states include a final state.

It would be expensive to consult the NFA, especially when we have to do so to handle every action request.

For a user with a particular set of privileges, however, very often only a small portion of the NFA is relevant. Not only some of the states in the NFA cannot be reached by the user, even for those that can be reached, they may not lead to the final state as the user may not possess necessary privileges anyway. By not keeping track of these irrelevant states, a system would be able to reduce the cost of dynamic enforcement.

(authors develop an algorithm to develop "personalised" NFAs)



Enforcing inter-task property
Action execution level enforcement
Enforcing inter-task properties requires recording a user’s actions.

• However, keeping record of their actions does not necessarily imply dynamically monitoring those actions at all times. If it is known that a user cannot violate a security property using their current privileges, then we do not need to actively monitor for security property violations, but instead we can simply keep a log of actions.

Use an intersection of finite state machines as in enforcing intra-task property.

• However, the NFA modeling the possible actions that a user can take should begin with a string of transitions that represent the actions that the user has already taken so far.
• That is, rather than have a set of states representing different time segments where the transitions model what actions the user is allowed to take, for time segments prior to the current time, only the transitions representing the actions which the user actually took should remain.

Task assignment
In many systems, tasks will arise in response to dynamic events.

• either users may observe events and initiate tasks in response to them
• or the system may observe events and have a means of assigning tasks to users

We can solve this question for inter-task properties by applying the same technique we just used.

• We simply add the permissions of the new task starting at the current time to the set of permissions that we are modeling before we take the intersection.
• If the intersection is empty, then the new task can safely be given to the user.
• If we cannot guarantee that a task can safely be given to a user, we can either give it to another user or dynamically monitor this user’s actions to ensure the high-level security properties are not violated.