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

Almost every device on your organization's networks (and remember, a device can be both subject and object) has an operating system and other software (or firmware) installed on it. For example, Microsoft Windows operating systems provide policy objects, which are software and data constructs that the administrators use to enable, disable, or tune specific features and functions that the OS provides to users. Such policies can be set at the machine, system, application, user, or device level, or for groups of those types of subjects. Policy objects can enforce administrative policies such as password complexity, renewal frequency, allowable number of retries, and lockout upon repeated failed attempts. Many Linux distributions, and as well as Apple's operating systems, have similar functions built into the OS. All devices ship from the factory with most such policy objects set to “wide open,” you might say, allowing the new owner to be the fully authorized systems administrator they need to be when they first boot up the device. As administrator/owners, you're highly encouraged to use other built-in features, such as user account definitions and controls, to create “regular” or “normal” user accounts for routine, day-to-day work. You then have the option of tailoring other policy objects to achieve the mix of functionality and security you need.

Role-based access control (RBAC) grants specific privileges to subjects regarding specific objects or classes of objects based on the duties or tasks a person (or process) is required to fulfill. Several key factors should influence the ways that role-based privileges are assigned.

Separation of duties takes a business process that might logically be performed by one subject and breaks it down into subprocesses, each of which is allocated to a different, separate subject to perform. This provides a way of compartmentalizing the risk to information security. For example, retail sales activities will authorize a salesclerk to accept cash payments from customers, put the cash in their sales drawer, and issue change as required to the customer. The salesclerk cannot initially load the drawer with cash (for making change) from the vault or sign off the cash in the drawer as correct when turning the drawer in at the end of their shift. The cash manager on duty performs these functions, and the independent counts done by salesclerk and cash manager help identify who was responsible for any errors.

Need to know, and therefore need to access, should limit a subject's access to information objects strictly to those necessary to perform the tasks defined as part of their assigned duties, and no more.

Duration, scope, or extent of the role should consider the time period (or periods) the role is valid on and any restrictions as to devices, locations, or factors that limit the role. Most businesses, for example, do not routinely approve high-value payments to others after business hours or normally consider authorizing these when submitted (via their approved apps) from a device at an IP address in a country with which the company has no business involvement or interests. Note that these types of attributes can be associated with the subject (such as role-based), the object, or the conditions in the system and network at the time of the request.

Role-based access has one strategic administrative weakness: privilege creep . This unnecessary accumulation of privileges or the retention of privileges no longer strictly required for the performance of one's duties can put the organization and the individual employee at considerable risk. Quality people take on broader responsibilities to help the organization meet new challenges and new opportunities; and yet, as duties they previously performed are picked up by other team members or as they move to other departments or functions, they often retain the access privileges their former jobs required. To contain privilege creep, organizations should review each employee's access privileges in the light of their currently assigned duties, not only when those duties change (even temporarily!) but also on a routine, periodic basis.

Attribute-based access control (ABAC) systems combine multiple characteristics (or attributes) about a subject, an object, or the environment to authorize or restrict access. ABAC uses Boolean logic statements to build as complex a set of rules to cover each situation as the business logic and its information security needs dictate. A simple example might be the case of a web page designer who has limited privileges to upload new web pages into a beta test site in an extranet authorized for the company's community of beta testers but is denied (because of their role) access to update pages on the production site. Then, when the company prepares to move the new pages into production, they may need the designer's help in doing so and thus (temporarily) require the designer's ability to access the production environment. Although this could be done by a temporary change in the designer's subject-based RBAC access privileges, it may be clearer and easier to implement with a logical statement, as shown here:

IF (it's time for move to production) AND (designer-X) is a member of (production support team Y) THEN (grant access to a, b, c…)

Attribute-based access control can become quite complex, but its power to tailor access to exactly what a situation requires is often worth the effort. As a result, it is sometimes known as externalized , dynamic , fine-grained , or policy-based access control or authorization management.

Subject-based access control looks at characteristics of the subject that are not normally expected to change over time. For example, a print server (as a subject) should be expected to have access to the printers, to the queue of print jobs, and to other related information assets (such as the LAN segment or VLAN where the printers are attached); you would not normally expect a print server to access payroll databases directly! As to human subjects, these characteristics might be related to age, their information security clearance level, or their physical or administrative place in the organization. For example, a middle school student might very well need separate roles defined as a student, a library intern, or a software developer in a computer science class, but because of their age, in most jurisdictions they cannot sign contracts. The web pages or apps that the school district uses to hire people or contract with consultants or vendors, therefore, should be off-limits to such a student.

Object-based access control uses characteristics of each object or each class of objects to determine what types of access requests will be granted. The simplest example of this is found in many file systems, where objects such as individual files or folders can be declared as read-only. More powerful OS file structures allow a more granular approach, where a file folder can be declared to have a set of attributes based on classes of users attempting to read, write, extend, execute, or delete the object. Those attributes can be further defined to be inherited by each object inside that folder, or otherwise associated with it, and this inheritance should happen with every new instance of a file or object placed or created in that folder.

You might say that there are two kinds of organizations in this world: those with thoughtful, deliberate, and effective information security plans and processes already in effect when an information security event occurs and those that realize the need for those security processes after their first major security breach has disrupted their business. Ideally, your organization is more of the former and less of the latter. In either case, the information risk assessment leads to an information classification policy that dictates how types or groups of users need to use information assets to get vital business processes accomplished. That mapping of the confidentiality, integrity, availability, nonrepudiation, and authentication aspects of information security needs to groups of users (or types of roles and functions users can take on) is the starting point for identity management and access control, as you've seen throughout this chapter.