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

start with account review. In the case of human users who have identities in your systems, this review should encompass two sets of data being reviewed by the right team of information risk managers from IT, human resources management, functional area supervisors or division managers, and possibly your legal team.

       Identity data review: Individual employees of almost any organization will go through any number of changes in their jobs as well as in their personal lives. Some of these changes are probably reflected in the organization's human resources (HR) or payroll functions; these systems do not, as a general rule, automatically notify IT security departments or the integrated IAM system that a change has occurred. Changes in marital status, significant changes in credit score or indebtedness, or legal actions (such as lawsuits, divorces, child custody actions, or criminal matters) might all be events in any person's life. The key question, though, is whether your security needs dictate such a high degree of personnel integrity and reliability that changes of these types are warning signs of greater risk levels regarding the affected employee.

       Privilege and access review: Regardless of changes in personal circumstances, all of your employees who have access to organizational IT systems and information assets should have a periodic review of those access privileges in the context of their current job or duties.

      Note that in both cases, employment law and regulations may establish constraints or conditions as to how these sorts of reviews are done, how frequently they can be done, or whether changes in conditions outside of job-related functional requirements provide reasonable grounds for such a review. Your organization's HR and legal teams, as well as your compliance officer (or department), should take the lead on ensuring this is done properly. In any event, your organization should create and use detailed, specific procedures for these reviews, that specify what data to gather and how it is evaluated in the context of such a review. Procedures should also provide for an employee appeal process—quite often bad data or poorly validated data has either granted or denied access and privileges in both incorrect and damaging ways.

      Other factors to balance when establishing such review processes should include:

       How frequently employees change jobs, in ways that may require changes in access privileges

       The pace of change, generally speaking, across your organization (or its individual but larger business units)

       The burden that such reviews place on administrative, IT, and other staff within the organization

       The direct and indirect costs of such reviews

      After all, these reviews are a safeguard—they are an administrative control that is attempting to mitigate the risk of privilege abuse leading to an information security incident and the loss or damage that results from it. In all things, seek a cost-effective balance.

      Account access review should consider two broad categories of accounts: users and systems. Let's take a closer look at each.

      User Access Review

All accounts associated with a human user of your systems should be subject to review on a periodic basis and special reviews when circumstances warrant it. For the most part, these will be user-level accounts and not systems accounts that are restricted to systems processes to use. (You'll learn about those next.) Whether you control access by enforcing rules or interpreting the various roles of the user, you must periodically review the access privileges accorded to each user (or system or software entity). The period of the review should be set by policy and strictly enforced by well-documented processes. Many organizations review the access of each user once per year.

      Your user access review process should include, at a minimum, the following:

       All of the accounts created for the user or the accounts to which the user has been granted access

       All of the computers this user can connect to, use, or log into

       All of the databases this user can read from or write to

       All of the applications this user can use

       All of the websites controlled by your enterprise that the user can visit and whether the user can log in, change things on the site, or merely read from it

       What sorts of data this user can see or change

       The times of day or days of the week all of these things may be done

       The geographical locations—and logical places on the enterprise network or in the cloud—from which all of these things may be done

      Many of the most serious computer breaches in history have been the result of access rights left in place after a user changed assignments 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