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 identity management function provisions a newly created identity, it also creates or initializes the set of identity credentials, such as username and password, for that subject to use once the identity itself is provisioned across the systems that the subject has been granted use of.
Note that in common practice, the username is by definition the identity by which that subject is known within the system; the rest of the information created and provisioned by the identity management process, which is then used during access authentication and authorization, is known as the credentials. Some credentials, such as passwords, may also become factors and are presented as part of access authentication.
As with any process, authentication can be prone to errors. Type 1 errors, also called false negative errors, occur when an otherwise legitimate subject is denied access; this is an incorrect or false rejection of the subject. Type 2 errors, also called false positive errors, give the “green light” to a subject to proceed in their attempt to access the system or object in question. These false acceptances are the greater security worry, as they potentially are allowing an intruder into your systems. You'll look at these errors and how to manage their rate of occurrence several times in this chapter. Note that many IT professionals refer to these directly as false rejection or false acceptance errors and avoid the possible confusion of types, positive and negative.
Single-Factor/Multifactor Authentication
Authentication is the first step in controlling what subjects (people, processes, or hardware) can access any portion of your systems. As you think about authentication, keep in mind that there are three sometimes competing needs to address. Human subjects need to get work done; their identity, and the parameters and attributes associated with that identity, need to be kept safe and secure; and the information assets that are the very reasons for your system to exist in the first place need to be kept safe and secure. Each of those needs requires its own dose of CIANA+PS sauce; each will need a different mix of those security ingredients, tailored to your organization's needs and its approach
