Access Control Models

An access control model is a framework that dictates how subjects access objects. It uses access control technologies and security mechanisms to enforce the rules and objectives of the model. There are three main types of access control models: discretionary, mandatory, and nondiscretionary (also called role-based). Each model type uses different methods to control how subjects access objects, and each has its own merits and limitations. The business and security goals of an organization will help prescribe what access control model it should use, along with the culture of the company and the habits of conducting business. Some companies use one model exclusively, whereas others combine them to be able to provide the necessary level of protection.

These models are built into the core or the kernel of the different operating systems and possibly their supporting applications. Every operating system has a security kernel that enforces a reference monitor concept, which differs depending upon the type of access control model embedded into the system. For every access attempt, before a subject can communicate with an object, the security kernel reviews the rules of the access control model to determine whether the request is allowed.

The following sections explain these different models, their supporting technologies, and where they should be implemented.

Discretionary Access Control

Only I can let you access my files.

Response: Mother, may I?

If a user creates a file, he is the owner of that file. An identifier for this user is placed in the file header. Ownership might also be granted to a specific individual. For example, a manager for a certain department might be made the owner of the files and resources within her department. A system that uses discretionary access control (DAC) enables the owner of the resource to specify which subjects can access specific resources. This model is called discretionary because the control of access is based on the discretion of the owner. Many times department managers, or business unit managers, are the owners of the data within their specific department. Being the owner, they can specify who should have access and who should not.

In a DAC model, access is restricted based on the authorization granted to the users. This means users are allowed to specify what type of access can occur to the objects they own. If an organization is using a DAC model, the network administrator can allow resource owners to control who has access to their files. The most common implementation of DAC is through ACLs, which are dictated and set by the owners and enforced by the operating system. This can make a user’s ability to access information dynamic versus the more static role of mandatory access control (MAC).

Most of the operating systems you may be used to dealing with are based on DAC models, such as all Windows, Linux, and Macintosh systems, and most flavors of Unix. When you look at the properties of a file or directory and see the choices that allow you to control which users can have access to this resource and to what degree, you are witnessing an instance of ACLs enforcing a DAC model.

DACs can be applied to both the directory tree structure and the files it contains. The PC world has access permissions of No Access, Read (r), Write (w), Execute (x), Delete (d), Change (c), and Full Control. The Read attribute lets you read the file but not make changes. The Change attribute allows you to read, write, execute, and delete the file but does not let you change the ACLs or the owner of the files. Obviously, the attribute of Full Control lets you make any changes to the file and its permissions and ownership.

It is through the discretionary model that Sam can share his D: drive with David so David can copy all of Sam’s MP3s. Sam can also block access to his D: drive from his manager so his manager does not know Sam is wasting valuable time and resources by downloading MP3s and sharing them with friends.

References

Identity-Based Access Control

DAC systems grant or deny access based on the identity of the subject. The identity can be a user identity or a group membership. So, for example, a data owner can choose to allow Bob (user identity) and the Accounting group (group membership identity) to access his file.


Mandatory Access Control

In a mandatory access control (MAC) model, users and data owners do not have as much freedom to determine who can access files. The operating system makes the final decision and can override the users’ wishes. This model is much more structured and strict and is based on a security label system. Users are given a security clearance (secret, top secret, confidential, and so on), and data is classified in the same way. The clearance and classification data are stored in the security labels, which are bound to the specific subjects and objects. When the system makes a decision about fulfilling a request to access an object, it is based on the clearance of the subject, the classification of the object, and the security policy of the system. The rules for how subjects access objects are made by the security officer, configured by the administrator, enforced by the operating system, and supported by security technologies.

Security labels are attached to all objects; thus, every file, directory, and device has its own security label with its classification information. A user may have a security clearance of secret, and the data he requests may have a security label with the classification of top secret. In this case, the user will be denied because his clearance is not equivalent or does not dominate (equal or higher than) the classification of the object.

Note

The terms “security labels” and “sensitivity labels” can be used interchangeably.


Each subject and object must have an associated label with attributes at all times, because this is part of the operating system’s access-decision criteria. Each subject and object does not require a physically unique label, but can be logically associated. For example, all subjects and objects on Server 1 can share the same label of secret clearance and classification.

This type of model is used in environments where information classification and confidentiality is of utmost importance, such as a military institution. Special types of Unix systems are developed based on the MAC model. A company cannot simply choose to turn on either DAC or MAC. It has to purchase an operating system that has been specifically designed to enforce MAC rules. DAC systems do not understand security labels, classifications, or clearances, and thus cannot be used in institutions that require this type of structure for access control. The most recently released MAC system is SE Linux, developed by the NSA and Secure Computing. Trusted Solaris is a product based on the MAC model that most people are familiar with (relative to other MAC products).

References
Sensitivity Labels

I am very sensitive. Can I have a label?

Response: Nope.

When the MAC model is being used, every subject and object must have a sensitivity label, also called a security label. It contains a classification and different categories. The classification indicates the sensitivity level, and the categories enforce need-to-know rules. Figure 4-14 illustrates a sensitivity label.

Figure 4-14. A sensitivity label is made up of a classification and categories.


The classifications follow a hierarchical structure, one level being more trusted than another. However, the categories do not follow a hierarchical scheme, because they represent compartments of information within a system. The categories can correspond to departments (UN, Information Warfare, Treasury), projects (CRM, AirportSecurity, 2003Budget), or management levels. In a military environment, the classifications could be top secret, secret, confidential, and unclassified. Each classification is more trusted than the one below it. A commercial organization might use confidential, proprietary, corporate, and sensitive. The definition of the classification is up to the organization and should make sense for the environment in which it is used.

The categories portion of the label enforces need-to-know rules. Just because someone has a top-secret clearance does not mean she now has access to all top-secret information. She must also have a need to know. As shown in Figure 4-14, if Cheryl has a top-secret clearance but does not have a need to know that is sufficient to access any of the listed categories (Dallas, Max, Cricket), she cannot look at this object.

Note

In MAC implementations, the system makes access decisions by comparing the subject’s clearance and need-to-know level to that of the security label. In DAC, the system compares the subject’s identity to the ACL on the resource.


Software and hardware guards allow the exchange of data between trusted (high assurance) and less trusted (low assurance) systems and environments. For instance, if you were working on a MAC system (working in dedicated security mode of secret) and you needed it to communicate to a MAC database (working in multilevel security mode, which goes up to top secret), the two systems would provide different levels of protection. If a system with lower assurance can directly communicate with a system of high assurance, then security vulnerabilities and compromises could be introduced. A software guard is really just a front-end product that allows interconnectivity between systems working at different security levels. Different types of guards can be used to carry out filtering, processing requests, data blocking, and data sanitization. A hardware guard can be implemented, which is a system with two NICs connecting the two systems that need to communicate with one another. Guards can be used to connect different MAC systems working in different security modes and they can be used to connect different networks working at different security levels. In many cases, the less trusted system can send messages to the more trusted system and can only receive acknowledgments back. This is common when e-mail messages need to go from less trusted systems to more trusted classified systems.

Role-Based Access Control

I am in charge of chalk, thus I need full control of all servers!

Response: Good try.

A role-based access control (RBAC) model, also called nondiscretionary access control, uses a centrally administrated set of controls to determine how subjects and objects interact. This type of model lets access to resources be based on the role the user holds within the company. It is referred to as nondiscretionary because assigning a user to a role is unavoidably imposed. This means that if you are assigned only to the Contractor role in a company, there is nothing you can do about it. You don’t have the discretion to determine what role you will be assigned.

The more traditional access control administration is based on just the DAC model, where access control is specified at the object level with ACLs. This approach is more complex because the administrator must translate an organizational authorization policy into permission when configuring ACLs. As the number of objects and users grows within an environment, users are bound to be granted unnecessary access to some objects, thus violating the least-privilege rule and increasing the risk to the company. The RBAC approach simplifies access control administration by allowing permissions to be managed in terms of user job roles.

In an RBAC model, a role is defined in terms of the operations and tasks the role will carry out, whereas a DAC model outlines which subjects can access what objects.

Let’s say we need a research and development analyst role. We develop this role not only to allow an individual to have access to all product and testing data, but also, and more importantly, to outline the tasks and operations that the role can carry out on this data. When the analyst role makes a request to access the new testing results on the file server, in the background the operating system reviews the role’s access levels before allowing this operation to take place.

Note

Introducing roles also introduces the difference between rights being assigned explicitly and implicitly. If rights and permissions are assigned explicitly, it indicates they are assigned directly to a specific individual. If they are assigned implicitly, it indicates they are assigned to a role or group and the user inherits those attributes.


An RBAC model is the best system for a company that has high employee turnover. If John, who is mapped to the contractor role, leaves the company, then Chrissy, his replacement, can be easily mapped to this role. That way, the administrator does not need to continually change the ACLs on the individual objects. He only needs to create a role (contractor), assign permissions to this role, and map the new user to this role.

As discussed in the Identity Management section, organizations are moving more towards role-based access models to properly control identity and provisioning activities. The formal RBAC model has several approaches to security that can be used in software and organizations.

Core RBAC

This component will be integrated in every RBAC implementation, because it is the foundation of the model. Users, roles, permissions, operations, and sessions are defined and mapped according to the security policy.

  • Has a many-to-many relationship among individual users and privileges

  • Session is a mapping between a user and a subset of assigned roles

  • Accommodates traditional but robust group-based access control

Many users can belong to many groups with various privileges outlined for each group. When the user logs in (this is a session), the various roles and groups this user has been assigned will be available to the user at one time. If I am a member of the Accounting role, RD group, and Administrative role, when I log on, all of the permissions assigned to these various groups are available to me.

This model provides robust options because it can include other components when making access decisions, instead of just basing the decision on a credential set. The RBAC system can be configured to also include time of day, location of role, day of the week, and so on. This means other information, not just the user ID and credential, is used for access decisions.

Hierarchical RBAC

This component allows the administrator to set up an organizational RBAC model that maps to the organizational structures and functional delineations required in a specific environment. This is very useful since businesses are already set up in a personnel hierarchical structure. In most cases, the higher you are in the chain of command, the more access you will most likely have.

  1. Role relation defining user membership and privilege inheritance. For example, the nurse role can access a certain amount of files and the lab technician role can access another set of files. The doctor role inherits the permissions and access rights of these two roles and has more elevated rights already assigned to the doctor role. So hierarchical is an accumulation of rights and permissions of other roles.

  2. Reflects organizational structures and functional delineations

  3. Two types of hierarchies:

    1. Limited hierarchies—Only one level of hierarchy is allowed (Role 1 inherits from Role 2 and no other role)

    2. General hierarchies—Allows for many levels of hierarchies (Role 1 inherits Role 2 and Role 3’s permissions)

Hierarchies are a natural means of structuring roles to reflect an organization’s lines of authority and responsibility. Role hierarchies define an inheritance relation among roles. Different separations of duties are provided under this model.

  • Static Separation of Duty (SSD) Relations through RBAC This would be used to deter fraud by constraining the combination of privileges (such as, the user cannot be a member of both the Cashier and Accounts Receivable groups).

  • Dynamic Separation of Duties (DSD) Relations through RBAC This would be used to deter fraud by constraining the combination of privileges that can be activated in any session (for instance, the user cannot be in both the Cashier and Cashier Supervisor roles at the same time, but the user can be a member of both). This one is a little more confusing. It means Joe is a member of both the Cashier and Cashier Supervisor. If he logs in as a Cashier, the Supervisor role is unavailable to him during that session. If he logs in as Cashier Supervisor, the Cashier role is unavailable to him during that session.

Role-based access control can be managed in the following ways:

  • Non-RBAC Users are mapped directly to applications and no roles are used.

  • Limited RBAC Users are mapped to multiple roles and mapped directly to other types of applications that do not have role-based access functionality.

  • Hybrid RBAC Users are mapped to multi-application roles with only selected rights assigned to those roles.

  • Full RBAC Users are mapped to enterprise roles.

References

RBAC, MAC, DAC

A lot of confusion exists regarding whether RBAC is a type of DAC model or a type of MAC model. Different sources claim different things, but in fact it is a model in its own right. In the 1960s and 1970s, the U.S. military and NSA did a lot of research on the MAC model. DAC, which also sprang to life in the ‘60s and ‘70s, has its roots in the academic and commercial research laboratories. The RBAC model, which started gaining popularity in the 1990s, can be used in combination with MAC and DAC systems. For the most up-to-date information on the RBAC model, go to http://csrc.nist.gov/rbac, which has documents that describe an RBAC standard and independent model, with the goal of clearing up this continual confusion.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset