vs. Discretionary Access Control
The next major choice that needs to be made reflects whether the organization is delegating the fine-grained, file-by-file access control and security policy implementation details to individual users or local managers or is retaining (or enforcing) more global policy decisions with its access control implementation.
Mandatory access control (MAC) denies individual users (subjects) the capability to determine the security characteristics of files, applications, folders, or other objects within their IT workspaces. Users cannot make arbitrary decisions, for example, to share a folder tree if that sharing privilege has not been previously granted to them. This implements the mandatory security policies as defined previously and results in highly secure systems.
Discretionary access control (DAC) allows individual users to determine the security characteristics of objects, such as files, folders, or even entire systems, within their IT workspaces. This is perhaps the most common access control implementation methodology, as it comes built in to nearly every modern operating system available for servers and endpoint devices. Typically, these systems provide users with the ability to grant or deny the privileges to read, write (or create), modify, read and execute, list contents of a folder, share, extend, view other metadata associated with the object, and modify other such metadata.
The choices of centralized versus decentralized architectures, and whether to use mandatory, discretionary, or nondiscretionary access control as a global policy are important decisions that must be made before you can start implementing your IAM project. You've also got to make another set of decisions regarding the specific roles, tasks, or responsibilities that individual users or groups of users must fulfill, and correlate that with your organization's information classification guide. Combining those two sets of information informs your choice of access control models: Do your security needs dictate a role-based access control, for example, or can you safely operate with something simpler such as subject-based or object-based control? And with that decision in hand, you can then start putting AAA servers in place, configuring their services, and loading up their control information. Now, you can start provisioning user accounts.
Almost every device on your organization's networks (and remember, a device can be both subject and object) has an operating system and other software (or firmware) installed on it. For example, Microsoft Windows operating systems provide policy objects, which are software and data constructs that the administrators use to enable, disable, or tune specific features and functions that the OS provides to users. Such policies can be set at the machine, system, application, user, or device level, or for groups of those types of subjects. Policy objects can enforce administrative policies such as password complexity, renewal frequency, allowable number of retries, and lockout upon repeated failed attempts. Many Linux distributions, and as well as Apple's operating systems, have similar functions built into the OS. All devices ship from the factory with most such policy objects set to “wide open,” you might say, allowing the new owner to be the fully authorized systems administrator they need to be when they first boot up the device. As administrator/owners, you're highly encouraged to use other built-in features, such as user account definitions and controls, to create “regular” or “normal” user accounts for routine, day-to-day work. You then have the option of tailoring other policy objects to achieve the mix of functionality and security you need.
Role-Based
Role-based access control (RBAC) grants specific privileges to subjects regarding specific objects or classes of objects based on the duties or tasks a person (or process) is required to fulfill. Several key factors should influence the ways that role-based privileges are assigned.
Separation of duties takes a business process that might logically be performed by one subject and breaks it down into subprocesses, each of which is allocated to a different, separate subject to perform. This provides a way of compartmentalizing the risk to information security. For example, retail sales activities will authorize a salesclerk to accept cash payments from customers, put the cash in their sales drawer, and issue change as required to the customer. The salesclerk cannot initially load the drawer with cash (for making change) from the vault or sign off the cash in the drawer as correct when turning the drawer in at the end of their shift. The cash manager on duty performs these functions, and the independent counts done by salesclerk and cash manager help identify who was responsible for any errors.
Need to know, and therefore need to access, should limit a subject's access to information objects strictly to those necessary to perform the tasks defined as part of their assigned duties, and no more.
Duration, scope, or extent of the role should consider the time period (or periods) the role is valid on and any restrictions as to devices, locations, or factors that limit the role. Most businesses, for example, do not routinely approve high-value payments to others after business hours or normally consider authorizing these when submitted (via their approved apps) from a device at an IP address in a country with which the company has no business involvement or interests. Note that these types of attributes can be associated with the subject (such as role-based), the object, or the conditions in the system and network at the time of the request.
Role-based access has one strategic administrative weakness: privilege creep. This unnecessary accumulation of privileges or the retention of privileges no longer strictly required for the performance of one's duties can put the organization and the individual employee at considerable risk. Quality people take on broader responsibilities to help the organization meet new challenges and new opportunities; and yet, as duties they previously performed are picked up by other team members or as they move to other departments or functions, they often retain the access privileges their former jobs required. To contain privilege creep, organizations should review each employee's access privileges in the light of their currently assigned duties, not only when those duties change (even temporarily!) but also on a routine, periodic basis.
Attribute-Based
Attribute-based access control (ABAC) systems combine multiple characteristics (or attributes) about a subject, an object, or the environment to authorize or restrict access. ABAC uses Boolean logic statements to build as complex a set of rules to cover each situation as the business logic and its information security needs dictate. A simple example might be the case of a web page designer who has limited privileges to upload new web pages into a beta test site in an extranet authorized for the company's community of beta testers but is denied (because of their role) access to update pages on the production site. Then, when the company prepares to move the new pages into production, they may need the designer's help in doing so and thus (temporarily) require the designer's ability to access the production environment. Although this could be done by a temporary change in the designer's subject-based RBAC access privileges, it may be clearer and easier to implement with a logical statement, as shown here:
IF (it's time for move to production) AND (designer-X) is a member of (production support team Y) THEN (grant access to a, b, c…)
Attribute-based access control can become quite complex, but its power to tailor access to exactly what a situation requires is often worth the effort. As a result, it is sometimes known as externalized, dynamic, fine-grained, or policy-based access control or authorization management.
Subject-Based
Subject-based access control looks at characteristics of the subject that are not normally expected to change over time. For example, a print server (as a subject)
