ISO 27002:2022- Control 5.16 – Identity Management

What Is the Purpose of Control 5.16?

5.16 deals with an organisation’s ability to identify who (users, groups of users) or what (applications, systems and devices) is accessing data or IT assets at any given time, and how those identities are granted access rights across the network.

5.16 is a preventative control that maintains risk by acting as the main perimeter for all associated information security and cybersecurity operations, as well as the primary mode governance that dictates an organisation’s Identity and Access Management framework.

Attributes of Control 5.16

Ownership

Given that 5.16 serves what is primarily a maintenance function, ownership should be directed towards IT staff who have been assigned Global Administrator rights (or equivalent for non-Windows based infrastructure).

Whilst there are other built-in roles that allow users to administer identities (e.g. Domain Administrator), ownership of 5.16 should rest with the individual who has ultimate responsibility for an organisation’s entire network, including all subdomains and Active Directory tenants.

General Guidance

Compliance with control 5.16 is achieved through a combination of ensuring that identity-based procedures are clearly articulated in policy documents, and monitoring day-to-day adherence among staff.

5.16 lists six main procedures that an organisation needs to follow, in order to meet the requisite standards of infosec and cybersecurity governance:

• Where identities are assigned to a person, only that specific person is allowed to authenticate with and/or use that identity, when accessing network resources.

Compliance – IT policies need to clearly stipulate that users are not to share login information, or allow other users to roam the network using any identity other than the one they’ve been assigned.

• Sometimes it may be necessary to assign an identity to multiple people – also known as a ‘shared identity’. This approach should be used sparingly, and only to satisfy an explicit set of operational requirements.

Compliance – Organisations should treat the registration of shared identities as a separate procedure to single user identities, with a dedicated approval workflow.

• So-called ‘non-human’ entities (as the name suggests, any identity that isn’t attached to an actual user) should be considered differently to user-based identities at the point of registration.

Compliance – As with shared identities, non-human identities should in turn have their own approval and registration process that acknowledges the underlying difference between assigning an identity to a person, and granting one to an asset, application or device.

• Identities that are no longer required (leavers, redundant assets etc.) should be disabled by a network administrator, or removed entirely, as is required.

Compliance – IT staff should carry out regular audits that list identities in order of use, and identify which entities (human or non-human) are able to be suspended or deleted. HR staff should include identity management in their offboarding procedures, and inform IT staff of leavers in a timely manner.

• Duplicate identities should be avoided at all costs. Firms should adhere to a ‘one entity, one identity’ rule across the board.

Compliance – IT staff should remain vigilant when assigning roles across a network, and ensure that entities aren’t granted access rights based on multiple identities.

• Adequate records should be kept of all ‘significant events’ regarding identity management and authentication information.

Compliance – The term ‘significant event’ can be interpreted in various ways, but on a basic level organisations need to ensure that their governance procedures include identity registration documentation, robust change request protocols with an appropriate approvals procedure, and the ability to produce a comprehensive list of assigned identities at any given time.

Supplementary Guidance

As well as the six main operational considerations, 5.16 also lists four steps that organisations need to follow when creating an identity, and granting it access to network resources (amending or removing access rights is dealt with in control 5.18):

• Establish a business case prior to an identity being created

Compliance – It’s important to acknowledge that identity management becomes exponentially more difficult with every new identity that’s created. Organisations should create new identities only when there is a clear need to do so.

• Ensure that the entity that’s being assigned the identity (human or non-human) has been independently verified.

Compliance – Once a business case has been approved, Identity and Access Management procedures should contain steps to ensure that the person or asset who is receiving a new identity has the requisite authority to do so, prior to an identity being created.

• Establishing an identity

Once the entity has been verified, IT staff should create an identity that’s in-line with the business case requirements, and is limited to what is stipulated in any change request documentations.

• Final configuration and activation

The final step in the process involves assigning an identity to its various access-based permissions and roles (RBAC), and any associated authentication services that are required.

Changes from ISO 27002:2013

General

27002:2022 / 5.16 replaces 27002:2013/9.2.1 (User Registration and De-registration) – which itself formed part of 27002:2013’s User Access Management control set. Whilst there are some similarities between the two controls – mostly in maintenance protocols, and deactivating redundant IDs – 5.16 contains a far more comprehensive set of guidelines that seek to address Identity and Access Management as an end-to-end concept.

Human vs. Non-human Identities

The main difference between the 2022 control and its 2013 predecessor is the acknowledgement that whilst there are differences in the registration process, human and non-human identities are no longer treated as distinct from one another, for general network administration purposes.

With the onset of modern Identity and Access Management and Windows-based RBAC protocols, IT governance and best practice guidelines speak of human and non-human identities more or less interchangeably. 27002:2013/9.2.1 contains no guidance on how to administer non-human identities, and concerns itself solely with the management of what it refers to as ‘User IDs’ (i.e. login information that’s used to access a network, along with a password).

Documentation

As we’ve seen, 27002:2013/5.16 contains explicit guidance on not only the general security implications of identity governance, but also how organisations should record and process information prior to an identity being assigned, and throughout its lifecycle. In comparison, 27002:2013/9.2.1 only briefly mentions the accompanying role that IT governance plays, and limits itself to the physical practice of identity administration, as carried out by IT staff.

New ISO 27002 Controls