Whatever the reference monitor’s structure, it must collect, store, and use administrators’ specifications of what access is to be granted. The information is essentially a simple function involving types of access permitted as defined on two fields of variables (i.e., subjects or people and objects or resources), efficient storage of the data, and the function’s values. However, this function poses a complex problem.

Much of what administrators specify should be stated tersely, using an abbreviated version of many values of the function. Efficient storage of the information can mirror its statement. Indeed, this is true in the implementation of every general access control product. Simply mirroring the administrator-supplied rules is not enough, however. The stored version must be susceptible to efficient processing so that access control decisions can be made efficiently. This virtually requires that the rules be stored in a form that permits the subject’s and object’s names to be used as direct indexes to the rules that specify what access is permitted. Each product provides an instructive example of how this may be done.

Because rules take advantage of generalizations, however, they are inevitably less than optimum when generalizations are few. A rule that treats but one subject and one object would be an inefficient repository for a very small amount of information — the type of access permitted in this one case.

Access control information can be viewed as a matrix with rows representing the subjects, and columns representing the objects. The access that the subject is permitted to the object is shown in the body of the matrix. For example, in the matrix in Exhibit 1, the letter at an intersection of a row and a column indicates what type of access the subject may make to the object. Because least privilege is a primary goal of access control, most cells of the matrix will be empty, meaning that no access is allowed. When most of the cells are empty, the matrix is said to be sparse.

Exhibit 1.  Access Control Matrix

Storage of every cell’s contents is not efficient if the matrix is sparse. Therefore, access control products store either the columns or the rows, as represented in Exhibits 2 and 3, which show storage of the matrix in Exhibit 1.

In Exhibit 2, a user called UACC, RACF’s term for universal access, represents all users whose names do not explicitly appear in the access control lists represented in the matrix in Exhibit 1. The type of access associated with UACC is usually none, indicated by an N. In addition, groups are used to represent sets of users with the same access rights for the object in question. For example, for objects B and C, GP1 (i.e., group 1) represents Alex, Brook, Chris, and Denny. Descriptions of the groups are stored separately. The grouping mechanisms reduce the amount of information that must be stored in the access control lists and the amount of keying a security administrator must do to specify all the permissions.

Exhibit 2.  List-Based Storage of Access Controls

Exhibit 2 shows access control storage based on the columns (i.e., the lists of users whose authorized type of access to each object is recorded), called list-based storage. Unlisted users need not be denied all access. In many cases, most users are authorized some access — for example, execute or read access to the system’s language processors — and only a few will be granted more or less authority — for example, either write or no access. An indicator in or with the list (e.g., UACC in RACF) may indicate the default type of access for the resource. List-based control is efficient because it contains only the exceptions.

Exhibit 3 shows access control storage based on the rows (i.e., the lists of objects to which the user is authorized to gain specified types of access), called ticket-based or capability-based storage. The latter term refers to rigorously defined constructs, called capabilities, that define both an object and one or more types of some access permitted to it. Capabilities may be defined by hardware or by software. The many implications of capabilities are beyond the scope of this chapter. Any pure ticket-based scheme has the disadvantage that it lacks the efficiency of a default access type per object. This problem can be alleviated, however, by grouping capabilities in shared catalogs and by grafting some list-based control onto a ticket-based scheme.

Exhibit 3.  Ticket-Based Storage of Access Controls

SUMMARY

Effective application security controls spring from such standards as least privilege and separation of duties. These controls must be precise and effective, but no more precise or granular than considerations of cost and value dictate. At the same time, they must place minimal burdens on administrators, auditors, and legitimate users of the system.

Controls must be built on a firm foundation of organizational policies. Although all organizations probably need the type of policy that predominates in the commercial environment, some require the more stringent type of policy that the U.S. government uses, which places additional controls on use of systems.