deprovisioning should be something that can be done rapidly, across all systems, and in ways that can be readily confirmed or validated.
When it comes to the identities you manage for the people in your systems, nothing is forever; every such identity you create and provision will at some point need to be modified, suspended, and then ultimately removed. Whether this commonsense notion holds for the identities associated with devices remains to be seen.
It's vital that you keep these two concepts separate and distinct. Think of all of the information associated with a typical user, such as:
Their identity itself and the supporting information that was used to initially create it
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).
Identity and Access Maintenance
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.
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
