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

Чтение книги онлайн.

СКАЧАТЬ or left the company. Leftover accounts and no-longer-needed access are like land mines in your network. Defuse them with periodic substantive access review.

      System Account Access Review

More often than not, software and devices are acting in their own name (so to speak) as subjects in your systems and have user IDs created for them. Database systems, systems belonging to partners in your federated access environment, storage subsystems, and even individual endpoint devices are just some examples of devices and their installed software and firmware that might have user IDs; if they do, then their accounts should be subject to review. Underneath all of that “user-level” devices-as-users activity, though, you'll find an ever-increasing number of operating systems and support functions, each with its own user ID and privileged account, which are automatically invoked as part of routine systems operation and use. In effect, invoking such a function causes a login-like event to happen for that function's user ID; or, if it's a continuously logged-in user ID, the function “wakes up” the process thread related to that user ID, and it starts requesting other systems functions to take action as needed to get its job done. Often used for housekeeping purposes such as backups, disk management, or the general gathering and analysis of monitoring and log data, these accounts usually have elevated privileges that grant access to special devices or system files.

      It's therefore a very good practice to check the access accounting information for these system-level user IDs as well. Ideally, you would check system by system for every computer, every security device on your network, and every database—in fact, every technical entity—to see which software and systems can do any of these things:

       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.

      Auditing

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.

      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.

       Are You Positive?

      Using СКАЧАТЬ