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

Connect

Read

Write

Move

Delete

Verify the presence and state of health of the device on the system

Start or stop

Read or change access settings

Read or change any other configuration settings

Perform privileged actions, or act as a system administrator

Such checks are time-consuming and even in a modest-sized network must be automated in order for a comprehensive scan to be practical. As with so many security measures, you may find it necessary to prioritize which systems (and which system accounts) are reviewed.

It may seem strange to separate account reviews from account auditing . Reviews have as their focus the task of identifying any cases of privilege creep or the retention of privileges no longer required for that user ID to perform its currently assigned set of functions, tasks, or duties. Reviews may be periodic or based on known changes in circumstances, such as a change of jobs or changes in the software and systems themselves. Reviews are more often than not performed internally by the organization and its own people, using internally generated procedures and measurement or assessment standards. By contrast, audits are used to generate an evidence-grade record of behavior on the part of one or more user IDs, either as part of troubleshooting a problem, investigating an incident, or building a forensics case to support a legal or administrative corrective action. Audits are often required (by law or by insurance or financial services regulations) to be done by outside auditors who may have to meet various certification standards, producing audit findings and reports that are authoritative.

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.

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.

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 7for more details.

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: