The work by Huang and Shan [8] describes a SQL-like policy definition language. The policy enforcement process allows refining of the initial authorization request (request enhancement) and suggesting alternatives (request rewriting) if the requested resource is unavailable. These actions are performed by the policy enforcement mechanism before submitting the actual resource retrieval request to the resource manager. This approach is different from ours in that:
In Policy Maker's terminology, "proof of compliance question" asks if the request 37#37, supported by a set of credentials complies with a policy 2#2. This is equivalent to the authorization question that we consider in our work: "is request 37#37 authorized by the policy 2#2 (in our model the credentials are contained in the request)". Their approach, however, is different from ours.
In our approach, the information passed to the authorization engine with the authorization request is used to evaluate conditions in the relevant policy statements. The order of condition evaluation is important.
The Policy Maker system is based on the logic programming approach. The goal is to infer the desired conclusion from given assumptions in a computationally viable manner. In Policy Maker, the credentials and policy (called assertions) are used collectively to compute a proof of compliance. The assertions can be run in an arbitrary order and produce intermediate results that then can be fed into other assertions.
Hayton and colleagues [7] proposed a role-based access control system called OASIS. OASIS services specify policy for role activation using Role Definition Language (RDL) that is defined in terms of axioms in proof system. These axioms are used to prove user's eligibility to enter a set of roles.
The policy for each set of services is specified at administrative domain level, with service level agreements between domains. The role names are local to each service. A role can be specified as being permitted only for those who can prove membership of other roles issued by this and other services. The services are responsible for issuing certificates, verifying their validity and notifying other services about the certificate state changes. A policy defines a set of conditions under which a user can activate a role. Condition evaluation is achieved by presenting a corresponding certificate. The role revocation is accomplished through membership conditions. Some of the membership conditions must continue to hold while the role remains active. If any of the membership conditions associated with the activated role fails, the role is deactivated. In some sense, the OASIS membership conditions are similar to our mid-conditions that must hold during operation execution.
RDL is not as generic and expressive as our approach and not as well suited to representing complex access control policies and those that include mandatory access control.
Policies, representable in Policy Maker and RDL, are restricted to the set of policies which do not produce side effects, resulting in change of the system state.
Ponder [4] is an object-oriented policy specification language that is suted for role-based access control policies, as well as general-purpose management policies. Ponder is targeted for different types of policies, including obligations, authorizations, delegation and filtering policies, and grouping these policies into aggregate structures. The obligation policies, for example, specify what actions (e.g., notification or logging) are carried out when specific events occur within the system. To some extent, the request-result and post-conditions in our framework serve a similar purpose. However, there are several significant differences between Ponder's and our approaches. First, in our framework all security requirements are expressed in a single policy structure, whereas in the Ponder approach authorization and obligation policies can be specified independently. These can lead to conflicts between the two policy types. Second, the policy in our framework is enforced by the same access control mechanism. The three-phase policy enforcement model allows for parts of policy (particular conditions) to be enforced at different times. In contrast, the Ponder uses a separate enforcement mechanism for each policy type.
Finally, the Ponder obligation policies are triggered by system events whereas in our framework the actions are triggered by other conditions in the same policy, such as threshold or system threat level.
Minsky and Ungureanu [11], [12] define the policy in terms of messages that only a restricted set of agents is permitted to exchange. Furthermore, the message exchange is controlled by a set of rules that is included in the policy. The policy enforcement mechanism is based on a set of trusted agents that interpret the rules and enforce them by regulating the message exchanges and the effect that the messages have on the control state (attributes and permissions) of the participating agents.
The ability to communicate and change the state resembles our concept of the read and write conditions. Our approach is different in that the ``state'' has a wider meaning. It includes all security-relevant information about real world which is representable in a computer system, e.g., bank account balance, temperature and user identity. Another difference is that the reading and writing of the state is based on the ordered synchronous evaluation of the conditions, rather than controlled message exchange.
Jajodia et al. [9] have proposed a logical language for the specification of authorizations. The concerns addressed in this work are orthogonal to the ones in this paper. In particular, they focus on modeling conflict resolution, integrity constraint checking and derivation rules (that derive implicit authorizations from explicit ones), while our work focuses on the representation and enforcement of authorization policies enhanced with detection and management of security violations.
Summary of the research of audit-based intrusion and misuse detection is given by Lunt [10]. Sandhu and Samarati [17] discuss authentication, access control and intrusion detection technologies and suggest that combination of the techniques is necessary in order to build a secure system.