Note that in many organizations it's common to refer to a special, circumstances-driven review of a particular user account or set of accounts as an informal audit. This often happens when there is sufficient grounds to worry that an employee or a group of employees may be acting in ways that violate inappropriate systems use policies or that their accounts (rather than they themselves) have been hijacked by others.
Whether it's a review or an audit, formal or informal, it's good practice to get the requesting management or leadership team's clear statement of the purpose and expectations regarding this examination of the data from the third A in AAA.
Enforcement
At some point, the review or audit findings (or other decisions made by management) will direct that a particular user ID needs to be brought back under control, by either a reduction in privileges, a temporary suspension, or a revocation. All of these actions are part of deprovisioning, as discussed in the previous “Provisioning/Deprovisioning” section.
Entitlement
The word entitlement has two meanings within an information systems security concept: a personal one and a systems one. Both are important and relevant to you as the access control and identity management systems administrator; you're the one who has to broker the first set of ideas into the second set of physical, logical, and administrative controls and their use.
On the personal front, some employees will believe that because of who and what they are, they have some kind of overarching right to have access to systems and privileges on those systems. In many cases, this is a legitimate and logical conclusion they've reached: If I am hired to lead a software development team, I have a reasonable expectation that I can see into all of the software units, support files, log files, and such, that are the work of all the people assigned to my team and to the projects I'm responsible for. In other cases, a newly appointed senior manager might believe (perhaps based on perceptions and emotions rather than logic) that their position somehow grants them this uber-authority. In either case, the strong principle of separation of duties should be able to sort through, function by function, what privileges the person actually requires on which systems, platforms, or applications to do their assigned duties. This is the basis of principle of least privilege.
On the technical front, entitlement refers to the ways in which user IDs are constructed, assigned privileges, and managed.
As an illustration, consider the seemingly simple task of installing a new application on a Windows-based desktop or laptop computer. As part of its own self-defense mechanisms, Windows uses a specific identity called the trusted installer to perform this task; no other identity can actually perform the set of steps associated with installing and registering an application. As an out-of-the-shrink-wrap user of my new Windows 10 laptop, each attempt I make to install an app causes the User Account Control functions to intercede, seeking my conscious affirmation and permission to continue. On my company-provided system, Group Policy Objects (GPOs) have been configured in the system by the sysadmins to require that a software allowed and blocked list management to restrict execution system intercepts any such attempt. This happens on both machines even though my user account is an Administrator account. Thus, my Windows machines have internally applied a separation of duties concept in the way that user IDs are constructed and the ways in which systems policies (via GPOs) are set to restrict each ID to just what it should be authorized to do, and no more. Note how the use of allowed and blocked lists is implementing both positive and negative security control measures. Each attempt by one ID to ask another to do a restricted task on its behalf is defined as a security event and is logged for later troubleshooting; security events can also be treated as real-time alarm conditions, and in many cases, they should be.
Using allowed list management for controlling software execution is a powerful defense against most of the malware infection vectors by prohibiting any software to execute if it is not on a controlled list of previously-approved tasks. If your organization is not using it, it's only a matter of time before you'll wish you had been. See Chapter 7 for more details.
Manage by Groups, Not by Individual Accounts
Modern operating systems such as Windows 10 or Apple's macOS Mojave provide many built-in features that encourage systems administrators (and sole proprietor end users of SOHO systems) to structure their user IDs into groups and arrange those groups in hierarchies. This again implements separation of duties by means of separately entitling a group of like user IDs with the same set of privileges.
The hierarchy starts with separating IDs into major systems groups: root or superuser, trusted installer, security administrator, user account manager, device manager, and so on. Servers and platforms should form another group, which might also include things like print servers, archival storage systems, or backup/restore platforms.
Your systems administrators (you included!) should recognize and support the need for this. Separate the different job functions and duties that your network administrators, database administrators, and security operations specialists must perform into different user account ID groups; set privileges derived from those official duties for each group; and then create each new user ID within a group for each systems administrator so that this unique user ID inherits the privileges from the group it belongs to.
Now the hard part: your ordinary, everyday users. Systems vendors recognize that the retail buyer of a laptop, desktop, or other endpoint device is a “company of one” and needs to have administrative privileges upon the first power-on boot of their new investment. This is also true of organizational purchases, of course. The “company of one,” however, often ends up with that default user account, created with administrative privileges by the original equipment manufacturer (OEM), being used for day-to-day routine operations. Larger organizations, or just ones with a more astute sense of information security, may need to manage subsets of users with separate but overlapping privileges. Retail stores, restaurants, or even banks, for example, might need to create and manage user subgroups such as:
A severely restricted user group for their customer-facing retail sales and service people
Another group for customer service managers, who might have authorities to override transaction limits or errors or perform lookup operations across a customer's transaction history as part of their duties
A different set of privileges for accounting systems operators that would allow them to process transactions but not initiate or modify them; their managers might be in another user group, which has those specific privileges associated with it
And so on
Note that depending upon the business systems, platforms, and technologies involved, this might require user account provisioning at the operating system level, on specific servers or websites, or within specific applications platforms.
Consider a whaling attack, in which a company's chief financial officer receives an email purportedly from his chief executive officer; he knows that she is traveling and working on trying to put together a new, significant deal for the company. The email says, “It's urgent that you wire transfer $15,000 to our new partners' account to bring this deal home. Do that now, please! The account details are….” Separation of duties by means of user IDs should require that although the CFO might be an approval authority on such a transfer of funds that it's actually