Having defined subjects and objects, let's put those read-up and write-down problems into a more manageable context by looking at privileges or capabilities. Depending on whom you talk with, a subject is granted or defined to have permission to perform certain functions on certain objects. The backup task (as subject) can read and copy a file and update its metadata to show the date and time of the most recent backup, but it does not (or should not) have permission to modify the contents of the file in question, for example. Systems administrators and security specialists determine broad categories of these permissions and the rules by which new identities are allocated some permissions and denied others.
Access Control via Formal Security Models
Let's take a closer look at CIANA+PS, in particular the two key components of confidentiality and integrity. Figure 2.3 illustrates a database server containing proprietary information and an instance of a software process that is running at a level not approved for proprietary information. (This might be because of the person using the process, the physical location or the system that the process is running on, or any number of other reasons.) Both the server and the process act as subjects and objects in their different attempts to request or perform read and write operations to the other. As an SSCP, you'll need to be well acquainted with how these two different models approach confidentiality and integrity.
Protecting confidentiality requires that you prevent attempts by the process to read the data from the server, but you also must prevent the server from attempting to write data to the process. You can, however, allow the server to read data inside the process associated with it. You can also allow the process to write its data, at a lower classification level, up into the server. This keeps the proprietary information safe from disclosure, while it assumes that the process running at a lower security level can be trusted to write valid data up to the server.
Protecting integrity by contrast requires just the opposite: You must prevent attempts by a process running at a lower security level from writing into the data of a server running at a higher security level.
FIGURE 2.3 Bell–LaPadula (a) versus Biba access control models (b)
The first model is the Bell–LaPadula model, which was developed by David Bell and Leonard LaPadula for the Department of Defense in the 1970s as a fundamental element of providing secure systems capable of handling multiple levels of security classification. Bell–LaPadula emphasized protecting the confidentiality of information—that information in a system running at a higher security classification level must be prevented from leaking out into systems running at lower classification levels. Shown in Figure 2.3(a), Bell–LaPadula defines these controls as follows:
The simple security property (SS) requires that a subject may not read information at a higher sensitivity (i.e., no “read up”).
The * (star) security property requires that a subject may not write information into an object that is at a lower sensitivity level (no “write-down”).
Another property is the discretionary security property, which requires that systems implementing Bell–LaPadula protections must use an access matrix to enforce discretionary access control.
Remember that in the examples in Figure 2.3, the process is both subject and object and so is the server! This makes it easier to see that the higher-level subject can freely read from (or be written into) a lower-level process; this does not expose the sensitive information to something (or someone) with no legitimate need to know. Secrets stay in the server.
Data integrity, on the other hand, isn't preserved by Bell–LaPadula; clearly, the lower-security-level process could disrupt operations at the proprietary level by altering data that it cannot read. The other important model, developed some years after Bell–LaPadula, was expressly designed to prevent this. Its developer, Kenneth Biba, emphasized data integrity over confidentiality; quite often the nonmilitary business world is more concerned about preventing unauthorized modification of data by untrusted processes than it is about protecting the confidentiality of information. Figure 2.3(b) illustrates Biba's approach.
The simple integrity property requires that a subject cannot read from an object that is at a lower level of security sensitivity (no “read-down”).
The * (star) integrity property requires that a subject cannot write to an object at a higher security level (no “write-up”).
Quarantine of files or messages suspected of containing malware payloads offers a clear example of the need for the “no-read-down” policy for integrity protection. Working your way down the levels of security, you might see that “business vital proprietary,” privacy-related, and other information would be much more sensitive (and need greater integrity protection) than newly arrived but unfiltered and unprocessed email traffic. Blocking a process that uses privacy-related data from reading from the quarantined traffic could be hazardous! Once the email has been scanned and found to be free from malware, other processes can determine whether its content is to be elevated (written up) by some trusted process to the higher level of privacy-related information.
As you might imagine, a number of other access models have been created to cope with the apparent and real conflicts between protecting confidentiality and assuring the integrity of data. Biba and Bell–LaPadula show up quite frequently in many situations. Other formal models you may not encounter as often include the following:
The Clark–Wilson model considers three things together as a set: the subject, the object, and the kind of transaction the subject is requesting to perform upon the object. Clark–Wilson requires a matrix that allows only transaction types against objects to be performed by a limited set of trusted subjects.
The Brewer and Nash model, sometimes called the Chinese Wall model, considers the subject's recent history, as well as the role(s) the subject is fulfilling, as part of how it allows or denies access to objects.
Noninterference models, such as Gogun–Meseguer, use security domains (sets of subjects) such that members in one domain cannot interfere with (interact with) members in “another domain.”
The Graham–Denning model also uses a matrix to define allowable boundaries or sets of actions involved with the secure creation, deletion, and control of subjects, and the ability to control assignment of access rights.
All of these models provide the foundational theories or concepts behind which access control systems and technologies are designed and operate. Let's now take a look at other aspects of how you need to think about implementing and managing access control.
Biba and Bell–LaPadula define properties (sometimes called axioms, principles, or rules) that can easily be confused with each other if you don't look at the next word in the property name. Always ask “What are we protecting?” and let that need for confidentiality or integrity tell you which directions you can read or write in!
IMPLEMENT AND MAINTAIN AUTHENTICATION METHODS
Authentication is the process of verifying that the factors or identity credentials presented by a subject actually match with what the identity management system has already established and approved. (Later sections in this chapter will address how these different functions—identity management, authentication, authorization, and accounting—can be hosted in different server architectures to meet the organization's needs in a cost-effective way.) When the