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

       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

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

      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

      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.

SUMMARY

      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.

      Those CIANA+PS attributes guide your work in creating and managing the process by which identities are created for people and processes and by which privileges are assigned that allow (or deny) these identities the capabilities to do things with the information assets you're charged with protecting. You've seen how this involves creating and maintaining trust relationships that allow different access control strategies and techniques to be put in place. These are the nuts and bolts of the systems that achieve the authentication, authorization, and accounting functions—the “big AAA”—that are the heart and soul of identity management and access control.

      Identities and access control, privileges and actions, subjects and objects—they're all different perspectives upon the same underlying and important needs.