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

Files created, modified, or maintained by them on company systems, whether for personal use, business use, or both

Records containing information about that identity or user, which were created in other files in the company's systems; these might be payroll, training, personnel management, or workflow control settings

Metadata, systems event logs, and other information that attests to what information the user has accessed, used, modified, or attempted to access

Emails sent or received by the user or with message text pertaining to that user

Archive or backup copies of those files, records, metadata, or systems that contain it

Revoking the identity blocks it from further access but changes no other data pertaining to that identity, no matter where it might be stored in your systems. Deleting that identity could mean a catastrophic loss of information, if the company ever has to answer a digital discovery request (about a wrongful termination, for example).

Three major activities—account access review, auditing, and enforcement—should be part of the ongoing monitoring and assessment of the health, status, and effective operation of any identity management and access control system. As you might expect, the particular CIANA+PS needs of your organization should drive how rigorous and extensive these efforts are—and what you do when you discover indications that something about a particular identity, its privileges, and the actions taken in its name reveals.

Let's 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.

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.

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: