Access and Resource Control

Access controls can be separated into several categories, beginning with physical, technical, and administrative controls. Their names imply how they work: physical controls regulate access to the physical components or interfaces to a system; technical controls govern access and authentication to the systems; and administrative controls apply policies to actions taken by system operators and users. We ll be covering physical access controls in depth in Chapter 5, Physical and Operational Security ; administrative controls are mostly outside the scope of this book. That leaves us with technical access controls, which can be implemented in a variety of ways.

Technical access controls depend on authentication systems. Once a user has been authenticated, the system can then determine what the user should be permitted to do. Windows, UNIX variants, and most other modern operating systems store access control lists (ACLs) for objects like files, folders, or system devices. The ACL for an object defines which users can and cannot take a particular action on the object. These individual definitions, known as access control entries (ACEs), can be explicit permission to do something ( User Joe can write to this directory. ) or an explicit denial ( Users in the Engineering group cannot log on after 5 P.M. ).

In systems that support access controls, some trusted component is responsible for comparing the ACL of an object with the identity of the user who is requesting access. If the ACL has an ACE that explicitly grants the user access, he or she gets access; if an explicit deny ACE is present, he or she doesn t. When the ACL is evaluated, explicit deny ACEs always take precedence. (Windows adds some additional rules to this basic process, as you ll see in Chapter 3, Windows and Exchange Security Architecture. ) By design, most access control systems are prohibitive, so anything not specifically allowed is forbidden. Some systems are permissive, meaning that anything not specifically forbidden is allowed. Obviously, prohibitive systems provide better security, because they never default to allowing access to a resource.

Note  

There are other access control models in addition to the ACL-based one just described. However, because Windows (and thus Exchange) access control is based on ACLs, that s all I cover here.

There s another important access control concept, too. Mandatory access controls can be set or changed only by administrators, not by the owners of resources. Systems that are approved for processing classified government information must implement mandatory controls so that individual users can t make access control decisions that contravene security requirements. Discretionary access controls are a bit different. The U.S. Department of Defense s Trusted Computer System Evaluation Criteria (TCSEC; available from http://www.radium.ncsc.mil/tpep/library/rainbow/ ) defines discretionary access controls as:

A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject.

Discretionary controls provide a finer degree of control within the overall restrictions imposed by mandatory access controls. Discretionary controls can be changed by users; for example, a mandatory access control might specify that no users can read a file classified top secret unless they have appropriate clearance. The system enforces that access control under all circumstances. If I own a file with that classification, I can further decide that top secret users Alice and Bob can read it, but that Charlie and Donna cannot. The system enforces the mandatory controls first, then applies additional, more restrictive permissions according to the discretionary ACLs (DACLs) that I ve placed on the file. In Windows, the owner of a resource can apply discretionary access controls, including permissions that allow other users to change the ACL for an object, but there s no built-in mechanism for applying mandatory access controls.

Besides directly enabling go/no-go resource access decisions, access controls can impose additional requirements. As one example, remote access policies in Microsoft Windows 2000 and Windows Server 2003 allow you to control who can remotely log on over a dial-up or virtual private network (VPN) connection, but they also allow you to restrict when otherwise -authorized users can do so. Exchange permissions are implemented as separate ACEs on existing objects (see Chapter 3), so that access to messaging resources is controlled through the same system used for other types of system objects.

Auditing

Access controls are most useful when they re combined with auditing functions. The audit log can provide a record of several interesting types of events, including both successful and failed attempts to access particular resources. For example, Exchange logs an event when user A logs on to user B s mailbox. When you see this event, it might mean that user A is opening user B s calendar, or it might mean that an administrator is reading someone s mailbox without permission. Monitoring system audit logs for security- related events and exceptions (for example, an administrator taking ownership of a sensitive file or object) is a key part of good security management.