The Official (ISC)2 SSCP CBK Reference. Mike Wills

Чтение книги онлайн.

СКАЧАТЬ 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 problem. Write-down also can happen if a storage device is not properly zeroized or randomized prior to its removal from the system for maintenance or disposal.

      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.

СКАЧАТЬ