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

As an example, consider the access control system itself as an object . It is a lucrative target for attackers who want to get past its protections and into the soft underbellies of the information assets, networks, and people behind its protective moat. In that light, hearing these functions referred to as data center gatekeepers makes a lot of sense. Yet the access control system is a subject that makes use of its own access control tables and of the information provided to it by requesting subjects. (You, at sign-on, are a subject providing a bundle of credential information as an object to that access control process.)

The first notion you have to come to grips with is just how many millions of objects can exist within even a small office/home office (SOHO) local area network (LAN) environment; scale this up to a large cloud-hosted data center operation and you could be dealing with billions and billions of objects. Even at the small end of this scale, the sheer number of objects involved dictates the need for efficient processes and effective, automated solutions to carry out most of the work that an access control system has to perform. For example, a typical SOHO LAN environment with an ISP-provided modem, a Wi-Fi router, and peer-to-peer file and resource sharing across a half-dozen devices on that LAN might have the following types of objects as part of that LAN system:

Each hardware device; its onboard firmware, configuration parameters, or device settings; and its external physical connections to other devices

Power conditioning and distribution equipment and cabling, such as a UPS

The file systems on each storage device, on each computer, and on each subtree and each file within each subtree

All of the removable storage devices and media, such as USB drives, DVDs, or CDs used for backup or working storage

Each installed application on each device

Each defined user identity on each device and the authentication information that goes with that user identity, such as username and password

Each person who is a user or is attempting to be a user (whether as guest or otherwise)

Accounts at all online resources used by people in this organization and the access information associated with those accounts

The random access memory (RAM) in each computer, as free memory

The RAM in each computer allocated to each running application, process, process thread, or other software element

The communications interfaces to the ISP, plain old telephone service, or other media

Wi-Fi is a registered trademark of the Wi-Fi Alliance, the nonprofit organization that promotes wireless connectivity, certifies products as conforming to their standards for interoperability. The name does not stand for anything; in particular, it does not mean “wireless fidelity,” even though a number of websites say that it does.

Note that third item: on a typical Windows 10 laptop with 330GB of files and installed software on a 500GB drive, that's only half a million files—and each of those, as well as each of the 100,000 or so folders in that directory space, is an object . Those USB drives, and any cloud-based file storage, could add similar amounts of objects for each computer; mobile phones using the Wi-Fi might not have quite so many objects on them to worry about. A conservative upper bound might be 10 million objects.

What might the population of subjects be, in this same SOHO office?

Each human, including visitors, clients, family, or even the janitorial crew

Each user ID for each human

Each hardware device, including each removable disk

Each mobile device each human might bring into the SOHO physical location with them

Each executing application, process, process thread, or other software element that the operating system (of the device it's on) can grant CPU time to

Any software processes running elsewhere on the Internet, which establish or can establish connections to objects on any of the SOHO LAN systems

That same Windows 10 laptop, by the way, shows 8 apps, 107 background processes, 101 Windows processes, and 305 services currently able to run—loaded in memory, available to Windows to dispatch to execute, and almost every one of them connected by Windows to events so that hardware actions (such as moving a mouse) or software actions (such as an Internet Control Message Protocol packet) hitting a system's network interface card will wake them up and let them run. That's 521 pieces of executing code. And as if to add insult to injury, the one live human who is using that laptop has caused 90 user identities to be currently active. Many of these are associated with installed services, but each is yet another subject in its own right.

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.

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.