Abstract
This chapter outlines the overall access control policy engineering framework in general and discusses the subject of validation of access control mechanisms in particular. Requirements of an access control policy language are introduced and their underlying organizational philosophy is discussed. Next, a number of access control models are discussed and a brief outline of various policy verification approaches is presented. A methodology for validation of access control implementations is presented along with two approaches for test suite generation, that is, complete FSM based and heuristics based. This chapter is aimed at providing an overview of the access control policy engineering activity and in-depth view of one approach to device test cases for an access control implementation mechanism.
TopBackground
Security requirements of information systems include protection against unauthorized access to or modification of information, and against denial of service to authorized users. Access control is the key security service providing the foundation for information and system security. An access control implementation is responsible for granting or denying authorizations after the identity of a requesting user has been validated through an appropriate authentication mechanism. Operating systems, database systems, and other applications employ policies to constrain access to application functionality, file systems, and data. Often these policies are implemented in software that serve as front end guard to protected resources, or is interwoven within the application. Examples of application of such controls in securing system resources abound in commercial and research domains (Bhatti, 2005; Notargiacomo, 1996; Tripathi, 2003; XACML, 2005).
A number of reported common vulnerabilities and exposures are related to design and/or coding flaws in access control modules of an application. Testing remains indispensable despite advances in the formal verification of secure systems (Ahmed, 2003; Alpern, 1989; Clarke, 2000; Hansen, 2005; Landwehr, 1986; Lupu, 1999), and in static or dynamic program-analysis based techniques (Cowan, 2003; Livshits, 2005; Martin, 2005) because verification only guarantees correctness of the design under certain assumptions. Any faults in the implementation due to, for example, coding errors, incorrect configuration, and hidden or “backdoor” functionality could jeopardize the effectiveness of corresponding (access control) specification (Thompson, 2003).
Key Terms in this Chapter
Definition 2: Complete FSM based test suite generation technique. In this procedure tests are generated from the complete FSM, derived from the policy P, as per the steps outlined in (Chow, 1978). The complexity of this procedure not only depends on the size of M but also on the observability of states in the ACUT.
PR Assignment Faults: Like two previous kind of faults these faults can also be categorized into two types, PR1 and PR2 faults, where former are the faults in which a permission-role assignment allowed by P actually does not exist in the ACUT’ and later are the one in which the situation is otherwise, that is, such a permission-role assignment exists in the ACUT’ which is not permitted by the policy. In case of PR1 faults the authorized permission-role assignment, required to be valid in the ACUT’, can be either by virtue of direct permission assignment to the role or assignment through inheritance semantics.
UR Activation Faults: These faults can also be classified into two types: UA1—faults because of which an authorized user is restricted from activating a role or the activated role is improperly deactivated, UA2—faults by virtue of which an unauthorized user can activate a role. As noted previously, an authorized user can activate a role either by virtue of direct user assignment to that role or by being assigned to a role senior to the target role in A-hierarchy semantics. UA2 fault in an ACUT’ can result into serious compromise of confidentiality and integrity of the system resources because, in RBAC users are only able to access system resources through the mechanism of user-role activations.
Definition 1: RBAC Fault Model; The RBAC fault model consists of three types of faults: user-role assignment, user-role activation, and permission-role assignment.
Definition 3: Heuristics based test suite generation technique. In this procedure heuristics are used to reduce the size of the model and of the test set. These heuristics are similar to the concept of state abstractions as used in various verification techniques.
UR Assignment Faults: These faults are subsequently classified into two types: UR1—faults because of which an authorized user is restricted from assignment to a role or gets improperly de-assigned from the assigned role, UR2—faults by virtue of which an unauthorized user is assigned to a role. As already mentioned before, authorized user imply such a user who can be assigned to or can activate a role under R(P). UR1 fault in an ACUT’ constrain a user from accessing the authorized permissions, whereas UR2 fault allows access to unauthorized permissions.