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

Just (and justifiable): Authorization decisions need to be justifiable in the eyes of those who are denied as well as those who are granted permission. Arbitrary decisions, or decisions that can reasonably be criticized as discriminatory or frivolous, will at the least drain energy away from security as they are defended.

Comprehensible: Do not underrate the advantage of being able to explain the reasoning behind the identity and access management scheme you have selected. Management, vendors, board members or advisors, and many curious and sometimes frustrated employees will want to know how names and access roles are determined and what policy and infrastructure is carrying out access decisions.

Provisioning starts with the initial claim of identity and a request to create a set of credentials for that identity; typically, a responsible manager in the organization must approve requests to provision new identities. (This demonstrates separation of duties by preventing the same IT provisioning clerk from creating new identities surreptitiously.) Key to this step is identity proofing, which separately validates that the evidence of identity as submitted by the applicant is truthful, authoritative, and current. Such evidence might include the following:

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.

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