Access Control Techniques and Technologies
Once an organization determines what type of access control model it is going to use, it needs to identify and refine its technologies and techniques to support that model. The following sections describe the different access controls and technologies available to support different access control models.
Rule-Based Access Control
Everyone will adhere to my rules.
Response: Who are you again?
Access Control ModelsThe main characteristics of the three different access control models are important to understand.
|
Rule-based access control uses specific rules that indicate what can and cannot happen between a subject and an object. It is based on the simple concept of “if X then Y” programming rules, which can be used to provide finer-grained access control to resources. Before a subject can access an object in a certain circumstance, it must meet a set of predefined rules. This can be simple and straightforward, as in “if the user’s ID matches the unique user ID value in the provided digital certificate, then the user can gain access.” Or there could be a set of complex rules that must be met before a subject can access an object. For example, “If the user is accessing the system between Monday and Friday and between 8 A.M. and 5 P.M., and if the user’s security clearance equals or dominates the object’s classification, and if the user has the necessary need to know, then the user can access the object.”
Rule-based access control is not necessarily identity-based. The DAC model is identity-based. For example, an identity-based control would stipulate that Tom Jones can read File1 and modify File2. So when Tom attempts to access one of these files, the operating system will check his identity and compare it to the values within an ACL to see if Tom can carry out the operations he is attempting. In contrast, here is a rule-based example: a company may have a policy that dictates that e-mail attachments can only be 5MB or smaller. This rule affects all users. If rule-based was identity-based, it would mean that Sue can accept attachments of 10MB and smaller, Bob can accept attachments 2MB and smaller, and Don can only accept attachments 1MB and smaller. This would be a mess and too confusing. Rule-based access controls simplify this by setting a rule that will affect all users across the board—no matter what their identity is.
Rule-based access allows a developer to define specific and detailed situations in which a subject can or cannot access an object, and what that subject can do once access is granted. Traditionally, rule-based access control has been used in MAC systems as an enforcement mechanism of the complex rules of access that MAC systems provide. Today, rule-based access is used in other types of systems and applications as well. Content filtering uses If-Then programming languages, which is a way to compare data or an activity to a long list of rules. For example, “If an e-mail message contains the word ‘Viagra’, then disregard. If an e-mail message contains the words ‘sex’ and ‘free,’ then disregard,” and so on.
Many routers and firewalls use rules to determine which types of packets are allowed into a network and which are rejected. Rule-based access control is a type of compulsory control, because the administrator sets the rules and the users cannot modify these controls.
References
“Creating a Policy-Aware Web: Discretionary, Rule-based Access for the World Wide Web,” Tim Berners-Lee, et al. www.w3.org/2004/09/Policy-Aware-Web-acl.pdf
Rule-Based Access Control for Web Services www-128.ibm.com/developerworks/webservices/library/ws-soa-access.html
Access Control http://foundation.bricksfactory.org/deliverables/d353/ar01s06.html
Constrained User Interfaces
Constrained user interfaces restrict users’ access abilities by not allowing them to request certain functions or information, or to have access to specific system resources. Three major types of restricted interfaces exist: menus and shells, database views, and physically constrained interfaces.
When menu and shell restrictions are used, the options users are given are the commands they can execute. For example, if an administrator wants users to be able to execute only one program, that program would be the only choice available on the menu. This limits the users’ functionality. A shell is a type of virtual environment within a system. It is the user’s interface to the operating system and works as a command interpreter. If restricted shells were used, the shell would contain only the commands the administrator wants the users to be able to execute.
Many times, a database administrator will configure a database so users cannot see fields that require a level of confidentiality. Database views are mechanisms used to restrict user access to data contained in databases. If the database administrator wants managers to be able to view their employees’ work records but not their salary information, then the salary fields would not be available to these types of users. Similarly, when payroll employees look at the same database, they will be able to view the salary information but not the work history information. This example is illustrated in Figure 4-15.
Physically constraining a user interface can be implemented by providing only certain keys on a keypad or certain touch buttons on a screen. You see this when you get money from an ATM machine. This device has a type of operating system that can accept all kinds of commands and configuration changes, but you are physically constrained from being able to carry out these functions. You are presented with buttons that only enable you to withdrawal, view your balance, or deposit funds. Period.
Access Control Matrix
The matrix—let’s see, should I take the red pill or the blue pill?
An access control matrix is a table of subjects and objects indicating what actions individual subjects can take upon individual objects. Matrices are data structures that programmers implement as table lookups that will be used and enforced by the operating system. Table 4-1 provides an example of an access control matrix.
| User | File1 | File2 | File3 |
|---|---|---|---|
| Diane | Read and execute | Read, write, and execute | No access |
| Katie | Read and execute | Read | No access |
| Chrissy | Read, write, and execute | Read and execute | Read |
| John | Read and execute | No access | Read and write |
This type of access control is usually an attribute of DAC models. The access rights can be assigned directly to the subjects (capabilities) or to the objects (ACLs).
Capability Tables
A capability table specifies the access rights a certain subject possesses pertaining to specific objects. A capability table is different from an ACL because the subject is bound to the capability table, whereas the object is bound to the ACL.
The capability corresponds to the subject’s row in the access control matrix. In Table 4-1, Diane’s capabilities are File1: read and execute; File2: read, write, and execute; File3: no access. This outlines what Diane is capable of doing to each resource. An example of a capability-based system is Kerberos. In this environment, the user is given a ticket, which is his capability table. This ticket is bound to the user and dictates what objects that user can access and to what extent. The access control is based on this ticket, or capability table. Figure 4-16 shows the difference between a capability table and an ACL.
Figure 4-16. A capability table is bound to a subject, whereas an ACL is bound to an object.
A capability can be in the form of a token, ticket, or key. When a subject presents a capability component, the operating system (or application) will review the access rights and operations outlined in the capability component and allows the subject to carry out just those functions. A capability component is a data structure that contains a unique object identifier and the access rights the subject has to that object. The object may be a file, array, memory segment, or port. Each user, process, and application in a capability system has a list of capabilities.
Access Control Lists
Access control lists (ACLs) are used in several operating systems, applications, and router configurations. They are lists of subjects that are authorized to access a specific object, and they define what level of authorization is granted. Authorization can be specified to an individual or group.
ACLs map values from the access control matrix to the object. Whereas a capability corresponds to a row in the access control matrix, the ACL corresponds to a column of the matrix. The ACL for File1 in Table 4-1 is shown in Table 4-2.
| User | File1 |
|---|---|
| Diane | Read and execute |
| Katie | Read and execute |
| Chrissy | Read, write, and execute |
| John | Read and execute |
Content-Dependent Access Control
This is sensitive information, so only Bob and I can look at it.
Response: Well, since Bob is your imaginary friend, I think I can live by that rule.
As the name suggests, with content-dependent access control, access to objects is determined by the content within the object. The earlier example pertaining to database views showed how content-dependent access control can work. The content of the database fields dictates which users can see specific information within the database tables.
Content-dependent filtering is used when corporations employ e-mail filters that look for specific strings, such as “confidential,” “social security number,” “top secret,” and any other types of words the company deems suspicious. Corporations also have this in place to control web surfing—where filtering is done to look for specific words—to try to figure out whether employees are gambling or looking at pornography.
Context-Dependent Access Control
First you kissed a parrot, then you threw your shoe, and then you did a jig. That’s the right sequence, you are allowed access.
Context-dependent access control differs from content-dependent access control in that it makes access decisions based on the context of a collection of information rather than on the sensitivity of the data. A system that is using context-dependent access control “reviews the situation” and then makes a decision. For example, firewalls make context-based access decisions when they collect state information on a packet before allowing it into the network. A stateful firewall understands the necessary steps of communication for specific protocols. For example, in a TCP connection, the sender sends an SYN packet, the receiver sends an SYN/ACK, and then the sender acknowledges that packet with an ACK packet. A stateful firewall understands these different steps and will not allow packets to go through that do not follow this sequence. So, if a stateful firewall receives a SYN/ACK and there was not a previous SYN packet that correlates with this connection, the firewall understands this is not right and disregards the packet. This is what stateful means—something that understands the necessary steps of a dialog session. And this is an example of context-dependent access control, where the firewall understands the context of what is going on and includes that as part of its access decision.