Access Control for File Systems
When securing DAR, applying an access control policy to an organization’s file system is the first step. This is done by creating an access control list (ACL) to handle both rights management of the data and to audit data access. File system access controls deal directly with accessing data stored on a system or a group of systems sharing a common file system. You can manage ACLs in a Microsoft Windows environment using Active Directory, or in a Linux environment using built-in ACL capabilities.
Access Control List
An ACL is a list of security policies associated with an object. An ACL is commonly composed of a collection of access control entities (ACEs). These are security objects that define access for one distinct user, group, or system. An ACE has four properties:
- A security identifier (SID) that identifies what the ACE applies to—the specific user, group, or system
- An access mask that lists the specific rights granted or denied
- Flags to indicate the type of ACE and whether child objects can inherit the rights from the object to which the ACE is attached
There are three primary types of ACEs you can apply to any security entity: access-denied, access-allowed, and system-audit. Each ACE allows, denies, or audits a specific right, such as read or modify for the SID to which it is attached. TABLE 8-1 lists types of ACEs.
| TYPE | DESCRIPTION |
|---|---|
| Access-denied | Denies SID-specific access to an object |
| Access-allowed | Allows specific rights to a SID |
| System-audit | Causes the creation of an audit record when the SID performs a specific action |
An ACL is applied directly on the file system of one system and affects only users and data on that system. There are two types of ACLs: discretionary and system ACLs. Each list uses ACEs and handles a different aspect of access control.
Discretionary Access Control List
A discretionary access control list (DACL) controls access to an object. It handles what access is allowed or denied. When an object is accessed, all of the ACEs contained in the DACL are checked to see what access, if any, should be granted. Although the DACL can be directly accessed, it generally is not. The ACEs contained in it are the combined result of access controls set by an object’s owner on an object, by rights set by administrators on the object and its container, and by system rules.
When applying the rights from a DACL, the system begins by denying all rights and then processing the ACEs in the DACL until one granting access is reached. This means if a DACL is empty and contains no ACEs, access will not be granted to any user. This also means that it is important to create a DACL for every object that needs security. In the absence of a DACL, the permissions assigned to an object are inherited from objects at upper levels of the object hierarchy.
System Access Control List
A system access control list (SACL) is a system-created access control list that handles the information assurance aspect of access controls. Although a user can modify an SACL, this is generally not done. The SACL is a system-generated list based on the auditing rules set by the systems administrators. It contains the ACEs that handle what access needs to be audited and where to store the audit information. SACLs may be configured to record all attempts to access an object in the audit trail. Alternatively, administrators may decide to log only successful or unsuccessful access attempts. It is important to note that the SACL doesn’t actually allow or deny access; it only records the access attempt and the success or failure of that attempt.
The information gathered in audit logs by SACL rules can be invaluable to security investigators. When stored elsewhere, this information provides an unalterable log that contains crucial evidence for evaluating the scope and impact of a security breach and reconstructing the events that took place on a system.