Subjects and objects have identities by which they are known to the systems that they participate in. For identity management and access control to work effectively, these identities need to be unique—that there is a one-to-one correspondence between a subject and its identity (or identifying information). Human names fail this uniqueness need more often than not; thus, we have to end up assigning some kind of identification key or value to each new human entity that comes into our identity management system's purview. Hardware identities, such as the media access control (MAC) addresses, are reasonably unique, but they can be locally altered and spoofed. You'll look at this identity proofing problem in more detail later in the “Proofing” section.
Privileges: What Subjects Can Do with Objects
The next key ingredient to access control is to define the privileges that subjects can have with respect to objects. A privilege is a type of action that the subject can perform upon the subject, such as:
Read data from the object.
Write data into the object.
Delete the object.
Read or inspect metadata associated with the object.
Modify the metadata associated with the object.
Load the object into memory and execute it as a program.
Extend or alter the system resources (such as storage space) allocated to the object.
Copy the object from one location to another.
Move the object from one location to another.
Read or inspect the security data associated with the object.
Modify the security data associated with the object.
Verify the existence of the object.
It is true that some of those privileges can be thought of as aggregates of others: Copying a file requires one to be able to read it, as well as create another instance of it someplace else; moving a file further requires the privilege of deleting the file after it has been copied. Verifying that a file is in fact on a given storage device requires read access to another object (the device's directory structure), as well as interpretation of metadata about the object. It is also true that not all commercial operating systems or access control systems provide this level of granularity. Organizations need to look at their information security classification needs as part of deciding how to establish privileges and relate them to subjects and to objects to make effective use of access control as part of their information security posture.
The privilege of being able to confirm or deny the existence of an object within a given system is frequently used for user logon systems, in which a failure of a subject to provide a valid user ID and password should not result in confirmation that the user ID is legitimate. Some operating systems, such as Windows, also implement features that can hide certain classes of files (by file type or location) from certain classes of users, both to declutter a user's view of folder trees and to protect systems resources from prying eyes. Organizations with more stringent (higher) security needs often make extensive use of this privilege to deny reconnaissance attempts to discover the presence of lucrative information assets, to infer knowledge about processes within the system, or to gain insight into a possible pathway to other objects.
This brings me to define identity management as the set of processes that are used to create identities within a system, provision those identities across all elements of the system as required, assign and manage privileges to those identities, revoke privileges, and finally retire or delete an identity once it is no longer needed. Access control uses this information about identities and privileges as its standards by which to adjudicate each access request or attempt.
However, before you can learn about identity management, you need to look at how the security classification of the various information assets should drive the way you use access control to deliver those various levels of protection.
Data Classification, Categorization, and Access Control
Next, let's talk layers. No, not layers in the TCP/IP or OSI 7-layer reference model sense! Instead, you need to look at how permissions layer onto each other, level by level, much as those protocols grow in capability layer by layer.
Information risk management should start by classifying the many different kinds of information your organization uses, in terms of the degree of impacts resulting from any security compromise. In short, the greater the threat to the existence of the company, the higher the security classification level of that information. The lowest level of such protection is often called unclassified, or suitable for public release. It's the information in press releases or in content on public-facing web pages. Employees are not restricted from disclosing this information to almost anyone who asks. Privacy-related data, company proprietary, pre-procurement sensitive, and even client-specific proprietary data are often treated as separate classification levels today.
Categorization then groups information assets (the information, not the systems that process them) of similar security classifications together. This facilitates common control strategies for assets in the same category.
A good demonstration of classification and categorization at work can be seen in the Computer Emergency Readiness Team (US-CERT)'s Traffic Light Protocol (TLP), shown in Figure 2.2. The TLP is a schema for identifying how information can or cannot be shared among the members of the US-CERT community. It can be seen at www.us-cert.gov/tlp and appears in Figure 2.1. It exists to make sharing sensitive or private information easier to manage so that this community can balance the risks of damage to the reputation, business, or privacy of the source against the needs for better, more effective national response to computer emergency events.
FIGURE 2.2 US-CERT Traffic Light Protocol for information classification and handling
Note how TLP defines both the conditions for use of information classified at the different TLP levels as well as any restrictions on how a recipient of TLP-classified information can then share that information with others.
Each company or organization has to determine its own information security classification needs and devise a structure of categories that support and achieve those needs. They all have two properties in common, however, which are called the read-up and write-down problems.
Reading up refers to a subject granted access at one level of the data classification stack, which then attempts to read information contained in objects classified at higher levels.
Writing down refers to a subject granted access at one level that attempts to write or pass data classified at that level to a subject or object classified at a lower level.
Shoulder-surfing is a simple illustration of the read-up problem, because it can allow an unauthorized person to masquerade as an otherwise legitimate user. A more interesting example of the read-up problem was seen in many login or sign-on systems, which would first check the login ID and, if that was correctly defined or known to the system, then solicit and check the password. This design inadvertently confirms the login ID is legitimate; compare this to designs that take both pieces of login information and return “username or password unknown or in error” if the input fails to be authenticated.
Writing classified or proprietary information to a thumb drive and then giving that thumb drive to an outsider illustrates the write-down