Identity cards or papers, such as government-issued ID cards, passports, or birth certificates. You validate against third-party identity systems (which should draw directly from databases supporting those government ID processes).
Citizenship, permanent resident, or right to reside and work status, as pertains to the country in which the applicant will perform work-related functions for you. You'll validate this via official channels or third parties who can access that data for you.
Personal employment history data, which you validate via credit histories or direct contact with those employers.
Residential address information, supported by applicant-provided utility bills, leases, or deeds, which you validate via issuing parties or agencies.
Personal and professional references, which you validate via contact.
Legal, criminal, or other court system records. (Your human resources management screening functions often have a “block-crimes” list, which they use to preclude hiring someone with such convictions as a way of limiting the company's exposure to risks. Note that the old-fashioned concept of a “crime of moral turpitude” can include such acts as making false statements to government officials, which might be a valid indicator of a personal integrity risk.)
Open source information via social media websites, web searches, news media, and so on.
Whether your organization uses a few of these proofing techniques or all of them or adds even more to the proofing process should be driven by two things: the overall risk management process and how that drives the requirements for personnel integrity and reliability.
All of that results in the first decision to hire the individual in question and for what duties; this leads to the decisions as to what information assets they'll need to use and what information or business processes they'll need to execute to perform those duties. This should lead in fairly straightforward ways to which systems, platforms, and server-provided services the individual will need access to and what mix of privileges they'll need on each of those systems or platforms.
Provisioning/Deprovisioning
Having made the decision to create a new identity and having decided what privileges it will have associated with it, it's time to actually provision it. Provisioning is the process of implementing the management decisions about a subject's identity and the privileges associated with it into the logical, physical, and administrative aspects of the access control functions throughout all of the systems this identity will require (and be allowed) access to and use of. (Note that I separate proofing from provisioning here for clarity.) Depending upon your overall systems architecture, this “push” of a new identity, and all subsequent updates to it, might be simple and straightforward or complex and time-consuming.
Typical SOHO-style architectures that do not use an integrated identity management and access control set of technologies will require creating the new identity and provision its access privileges on each system, endpoint, or platform the user needs access to. This might include creating the username and credentials on each Windows, Mac, or Linux workstation and endpoint device and then creating similar credentials on each network-attached storage system, website, or cloud-hosted storage, database, or applications platform that the employee will use. Every one of these systems, sites, and platforms will need to be “touched” or updated every time this user's privileges are modified, revoked, or suspended.
Integrated identity and access management (IAM) systems can reduce this to a single creation/update task and then push this information to all connected systems. Systems, platforms, and apps that support the organization's single sign-on access process are also updated with a single push, whether for the initial provisioning or for updates.
Note that the IAM/SSO “single push” process is not instantaneous. Depending upon the scale and complexity of your information architecture, it can take minutes or hours for every server, every platform, every applications suite, and every affected endpoint to process the update. (Globe-spanning organizations, even ones of 500 people or fewer, can often see this take half a day or more.) Creation and update of identities can and should be a deliberate process, and “next business day” availability is quite often acceptable. However, systems administrators need to be able to support rapid updates to meet urgent and compelling needs, either to grant new identities new privileges or to revoke or suspend them.
Deprovisioning is the process of temporarily or permanently revoking both the privileges associated with an identity and the identity itself. Typically, deprovisioning is done in a series of steps that disable (but do not remove) privileges and accounts and then remove them completely. As with provisioning, this is either a straightforward, single “unpush” kind of action supported by your integrated identity and access management system or a laborious system-by-system, app-by-app, site-by-site effort. Since many deprovisioning actions are related to situations involving an employee being disciplined or terminated from employment, two special considerations should apply.
The employee's work unit managers or directors, the human resources management team, and the information systems security specialists should coordinate informing the employee of their change of status and the deprovisioning itself. This is necessary to prevent a disgruntled employee from inflicting damage to systems or exfiltrating data from them.
The 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.