MODULE 12
Understanding Authorization
We discussed authorization in Modules 3 and 11, but in this module, we’ll go more in depth, detailing the concepts of authorization and how they relate to supporting the authorization processes. We will also look at access control models, which define how organizations frame and implement authorization.
Authorization Concepts
In Module 3, you learned that authorization is a distinct part of the process of identification, authentication, authorization, and accountability. To recap, identification involves presenting credentials to a system. Authentication is the process of validating those credentials against a centralized database, to ensure that the user is who they say they are. Authorization takes it a step further. Simply because someone is authenticated to a system, meaning their identity has been positively verified, doesn’t necessarily mean that they have rights, privileges, and permissions to access the system. That’s where authorization comes in. Authorization is the process of making decisions on what users can and cannot do with respect to the system and resources. There are different ways to implement authorization, which we’ll discuss in this module. First, however, let’s discuss some supporting elements of authorization.
Supporting Authorization
Authorization is the process of determining who gets what type of access to systems and data, but there’s more to authorization than that. Authorization is part of an access control policy, which, if you remember from Module 3, relates to how the organization determines who gets access to what systems and data based upon the sensitivity of those systems and data. Data sensitivity determines how much protection an asset gets, and part of that protection is to allow only people with a verified need-to-know (based on job requirements) and clearance level to access systems and data. Access control policy should be based upon several things, but data sensitivity is definitely one of them. Other elements that support access control policy include the organization’s stance on the principle of least privilege, how duties are separated and divided among key personnel, and the access control model used in the organization. We’ll discuss all of these over the next few sections.
An access control policy often dictates how an organization handles its authorization processes. Data sensitivity policies also dictate authorization.
Least Privilege
Remember that the principle of least privilege involves granting only the level of access someone needs to do her job, and no more than that. In other words, the general rule is that a person should get the minimum access to systems and data required to complete her daily duties. Any more than that and the risk to the organization increases because of the possibility of data disclosure, modification, or destruction. The principal of least privilege applies not only to being able to view and interact with data; it also applies to actions users can take with respect to the system and the network. For instance, all users don’t necessarily need administrative-level access to their workstations. Organizations should follow the principle of least privilege whenever possible, and the access control policies developed to support authorization should also follow this principle.
The principle of least privilege dictates that a user should only get the minimum level of access needed to do her job, and no more.
Separation of Duties
In Module 3 you also learned about separation of duties, which also supports authorization processes. Separation of duties involves dividing up critical or security-related tasks and responsibilities among two or more individuals, rather than allowing one individual to perform an excessive number of powerful tasks. When one individual has a great deal of power in an organization, especially over systems and data, it’s difficult to ensure that he will not misuse this power, which might result in unauthorized data access or system modification. Additionally, users who have this power may be able to erase any audit trails that exist, reducing accountability for their actions. When separation of duties is implemented, critical or security-related tasks can’t all be performed by one individual without checks and balances from other individuals. Some tasks may require that more than one individual perform them so that one person doesn’t have all the control. Other tasks may require that someone other than the person performing the task approves or audits the process. This reduces the likelihood of malicious behavior on the part of any single individual. It also ensures that no one individual can cause catastrophic damage to systems and data within the organization.
Rights, Permissions, and Privileges
We’ve mentioned the concepts of permissions, rights, and privileges several times throughout this book. Although a great many people, security personnel included, use these terms interchangeably, they are actually different things, and you should be aware of the differences. Permissions normally apply to resources, such as a shared folder or file. Permissions involve the actions people can take with respect to these resources. For example someone may be given both read and write access to a particular file, or only read access. Often permissions include the ability to create, delete, or modify files and shared folders. Permissions are normally inherent to resources, and different users are assigned to those permissions for that resource. Figures 12-1 and 12-2 show Windows permissions on a folder and Linux permissions on a directory, respectively.
Figure 12-1 Windows permissions on a folder
Figure 12-2 Linux permissions in a directory
Rights typically define the capabilities a user has on a system, such as the ability to log on via the console or over the network remotely. Rights and privileges are often the same, depending upon the particular system you are discussing, as different vendors also refer to these terms interchangeably. Figure 12-3 shows how user rights can be assigned through the Local Security Policy in Windows.
Figure 12-3 User rights in Windows’ Local Security Policy
Privileges involve the user’s ability to take certain actions on a system; they can be granted or taken away from an individual. An example of a privilege would be the ability to change the system time, back up data (even data the person normally would not have permissions to interact with), or perform other system-level modification. Privileges are granted to users, whereas permissions are part of a resource. A user may not necessarily have permissions for a resource, but she may have the privileges necessary to grant herself permissions to the resource. In other words, privileges are things a user can or cannot do, and permissions are what can and cannot be done to a resource.
Although these terms are often used interchangeably, remember that they don’t mean the same thing. Rights and privileges involve what a user can or cannot do on a system; permissions apply to what can or cannot be done to a resource.
Access Control Lists
An access control list (ACL) is a physical or logical list that details the specific access levels an individual may have to an object such as a shared file or folder. In some cases, an ACL may also tell what type of actions a user may take on a system or network. ACLs are used in many different contexts in security. For example, ACLs exist on network devices, such as routers, and serve to dictate how inbound and outbound network traffic can access certain parts of the network or hosts. A specific type of network traffic may be denied for a particular part of the network, or it may be allowed for a certain host, based upon different characteristics of the traffic. We’ll discuss that aspect of an ACL later on the book when we discuss network security. Another example of an ACL is the type that might exist logically as part of a resource. For instance, a shared folder may have an ACL as part of its descriptive metadata that details what permissions different users and groups have on the folder. It might detail that certain users can create files in the folder, or it may state that certain users cannot view the contents of the folder at all. In any event, an ACL typically has entries for particular users and groups that details what permissions or actions they may or may not take on an object or system.
Access Control Models
Authorization within a network or system is based upon an organization’s access control model, a logical model that details exactly how users can interact with systems and data of various sensitivities. Although we will not necessarily go into detail on the particular models that exist, we will describe basic characteristics of some of the more common models, including the mandatory access control, discretionary access control, rule-based access control, and role-based access control models.
Mandatory Access Control
Mandatory access control (MAC) is a model often found in highly secure environments, such as defense or financial systems. With mandatory access control, a user is granted access to a particular system or data based upon his security clearance level. Data is assigned different labels that designate its sensitivity and the security clearance required to access it. Administrators grant users, who also have security clearances assigned to their accounts, access to particular systems or data, based upon their need-to-know requirements. Even on the same system, users who have the requisite security clearances don’t always get access to all of the data at the same clearance level; each user’s job requirements must also indicate a valid need to access the data. MAC models are typically either confidentiality or integrity models. A confidentiality model emphasizes protection against unauthorized access, and an integrity model emphasizes the need to protect all data from unauthorized modification.
Discretionary Access Control
Discretionary access control (DAC) is what most users encounter on a normal basis. Microsoft Windows, as well as Mac OS and Linux systems, typically use DAC in both standalone and network environments. With DAC, the user who has created or owns an object, such as a file or folder, has the discretion to assign permissions to that object as she sees fit. Administrator-level access isn’t required to assign permissions; any user who is the creator or owner of the resource can do so. Discretionary access control is a very flexible model, and users can assign rights, permissions, and privileges both to individuals and groups of users, which can be logically created in the system based upon different functional or security needs.
The discretionary access control model is the only model that allows normal users to dictate who has permissions to objects such as files, folders, or other resources.
Rule-Based Access Control
Rule-based access control is a model that is rarely seen as a standalone type of access control model. It’s typically integrated with other access control models, such as discretionary or mandatory access control. In rule-based access control, all accesses granted in the system are based upon predefined rules, which might include restrictions on when, how, where, and under what circumstances a user may access a particular system or resource. A rule, for example, may state that between the business hours of 8 A.M. and 11 A.M., only the accounting department may have write access to a particular database, but between 1 P.M. and 4 P.M., users in accounting, marketing, and production may have read and write access to the database. Rules may apply to users or groups of users, and they may even specify the workstations that must be used, the type of permissions that apply to the resource, and so on. An example of rule-based access control is that used in more advanced firewalls, which lists a series of rules that users, network devices, hosts, and network traffic must meet in order to access other hosts and resources on the network.
Role-Based Access Control
Role-based access control (RBAC), on the surface, sounds like access control using groups, but this isn’t necessarily the case. Although DAC models can be used to assign permissions, rights, and privileges to traditional groups, RBAC almost exclusively uses predefined roles, versus groups or users. These predefined roles must already exist in the system, and users must be assigned to these roles to have the access levels granted to the roles. This type of access control model is not discretionary in that the creator or owner resource cannot necessarily assign a user to a particular role simply to give him access. Normally an administrative-level user must assign a user to a role. Roles might include supervisory roles, administrative roles, management roles, or data change roles that have an increased level of access to systems, data, or other objects.
There is no specific convention for the use of the term RBAC; most security texts by convention refer to RBAC as role-based access control, but you will see RBAC used also to describe rule-based access control. If you see the acronym RBAC, look at its context to determine which model is being referred to.
Other Authorization Restrictions
In addition to these access control models are other restrictions that can be imposed on authorization processes. For example, administrators can impose time-of-day or location restrictions on users when authorizing access to a particular resource. The administrator can stipulate that users can access a shared folder, for example, only during business hours. The administrator could also stipulate that users can access a shared folder only from a particular workstation, not simply any computer. In addition to time-of-day and location restrictions, administrators can also impose restrictions on whether or not a resource can be accessed locally or remotely—in other words, the user might have to sit down physically at a workstation and log in to use the resource, and he might not be able to access it remotely across the network. Other authorization restrictions are possible, of course; they get into granular details such as type of network port or protocol, source and destination Internet protocol addresses, and so on. Many of these will be discussed later on when we discuss network security.
Module 12 Questions and Answers
Questions
1. Which of the following terms describes the process of allowing access to different resources?
A. Authorization
B. Authentication
C. Accountability
D. Identification
2. Which of the following states that users should be given only the level of access needed to perform their duties?
A. Separation of duties
B. Accountability
C. Principle of least privilege
D. Authorization
3. Not allowing system administrators to have access to security audit logs is an example of __________.
A. principle of least privilege
B. separation of duties
C. job rotation
D. authorization
4. The ability to write to a particular file is an example of a __________.
A. right
B. privilege
C. discretionary access control model
D. permission
5. Which of the following would detail the particular access levels of an individual for a given object?
A. Access control list
B. Rule-based access control model
C. Role-based access control model
D. Privileges
6. Which of the access control models is based upon labels assigned to data and matching security clearances?
A. Discretionary access control
B. Rule-based access control
C. Role-based access control
D. Mandatory access control
7. Which of the following access control models allows object creators and owners to assign permissions to users?
A. Rule-based access control
B. Discretionary access control
C. Mandatory access control
D. Role-based access control
8. Restricting access to a particular system, based upon a stringent set of requirements including time of day, workstation, type of access, and resource is an example of which access control model?
A. Rule-based access control
B. Role-based access control
C. Discretionary access control
D. Mandatory access control
9. Which of the following are used as a basis for access in role-based access control models?
A. Discretionary access control groups
B. Individual users
C. Predefined roles
D. Set of predefined rules
10. An administrator wants to restrict access to a particular database based upon a stringent set of requirements. The organization is using a discretionary access control model. The database cannot be written to during a specified period when transactions are being reconciled. What type of restriction might the administrator impose on access to the database?
A. Access restricted by the database owner
B. Access based upon membership in a logical group
C. Access from a particular workstation
D. Time-of-day and object permission restrictions
Answers
1. A. Authorization describes the process of allowing access to different resources.
2. C. The principle of least privilege states that users should be given only the level of access needed to perform their duties.
3. B. This is an example of separation of duties, since allowing system administrators to have access to security logs might allow them to take unauthorized actions and then delete any trace of those actions.
4. D. The ability to write to a file is the example of a permission.
5. A. An access control list would detail the particular access levels of an individual for a given object.
6. D. The mandatory access control model is based upon labels assigned to data and matching security clearances.
7. B. The discretionary access control model allows object creators and owners to assign permissions to users.
8. A. This is an example of rule-based access control, since access is based upon a series of restrictions or rules.
9. C. Predefined roles are used as a basis for access in role-based access control.
10. D. The administrator would want to impose both a time-of-day and object permission restriction on users to prevent them from writing to the database during a specified time period.