ISO 27001:2022 A 5.16 Identity management

Audio version of the article

Advertisements

Identity management is the organizational process for ensuring individuals have the appropriate access to technology resources. This includes the identification, authentication and authorization of a person, or persons, to have access to applications, systems or networks. This is done by associating user rights and restrictions with established identities. Identities are used by computer networks to identify an entity’s (a user, group of users, device or IT asset) underlying ability to access a predetermined set of hardware and software resources. IT deals with the approval, registration and administration – defined as the ‘full life cycle’ – of human and non-human identities on any given network. The purpose is to  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. It maintains risk by maintains risk by acting as the main perimeter for all associated information security and cyber security operations, as well as the primary mode governance that dictates an organisation’s Identity and Access Management framework.Identity management includes authenticating users and determining whether they’re allowed access to particular systems.Identity management is focused on authentication, while access management is aimed at authorization.

Advertisements

Control

The full life cycle of identities should be managed.

Purpose

To allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights.

ISO 27001 Implementation Guidance

The processes used in the context of identity management should ensure that:

  1. for identities assigned to persons, a specific identity is only linked to a single person to be able to hold the person accountable for actions performed with this specific identity;
  2. identities assigned to multiple persons (e.g. shared identities) are only permitted where they are necessary for business or operational reasons and are subject to dedicated approval and documentation;
  3. identities assigned to non-human entities are subject to appropriately segregated approval and independent ongoing oversight;
  4. identities are disabled or removed in a timely fashion if they are no longer required (e.g. if their associated entities are deleted or no longer used, or if the person linked to an identity has left the organization or changed the role);
  5. in a specific domain, a single identity is mapped to a single entity, [i.e. mapping of multiple identities to the same entity within the same context (duplicate identities) is avoided];
  6. records of all significant events concerning the use and management of user identities and of authentication information are kept.

The organization should have a supporting process in place to handle changes to information related to user identities. These processes can include re-verification of trusted documents related to a person. When using identities provided or issued by third parties (e.g. social media credentials), the organization should ensure the third-party identities provide the required trust level and any associated risks are known and sufficiently treated. This can include controls related to the third parties as well as controls related to associated authentication information .

Other information

Providing or revoking access to information and other associated assets is usually a multi-step procedure:

  1. confirming the business requirements for an identity to be established;
  2. verifying the identity of an entity before allocating them a logical identity;
  3. establishing an identity;
  4. configuring and activating the identity. This also includes configuration and initial setup of related authentication services;
  5. providing or revoking specific access rights to the identity, based on appropriate authorization or entitlement decisions
Advertisements

Identities are the things that identify users, systems, services and are their virtual representation allowing access to data and resources. They can be managed, allocated and used to control, monitor and report on what people and systems do and are doing.The control 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. The 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 should rest with the individual who has ultimate responsibility for an organisation’s entire network, including all subdomains and Active Directory tenants.

  • 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. 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. 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. 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. 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 off boarding 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. 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. 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.

The main goal of identity management is to ensure only authenticated users are granted access to the specific applications, systems or IT environments for which they are authorized. This includes control over user provisioning and the process of on boarding new users such as employees, partners, clients and other stakeholders. Identity management also includes control over the process of authorizing system or network permissions for existing users and the off boarding of users who are no longer authorized to access organization systems. ID management determines whether a user has access to systems and sets the level of access and permissions a user has on a particular system. For instance, a user may be authorized to access a system but be restricted from some of its components. Identity governance, the policies and processes that guide how roles and user access should be administered across a business environment, is an important aspect of identity management. Identity governance is key to successfully managing role-based access management systems. Identity management is an important part of the Information security, as it is linked to both the security and productivity of the organization. In many organizations, users are granted more access privileges than they need to perform their functions. Attackers can take advantage of compromised user credentials to gain access to organizations’ network and data. Using identity management, organizations can safeguard their corporate assets against many threats including hacking, ransomware, phishing and other malware attacks. Identity management systems add an additional layer of protection by ensuring user access policies and rules are applied consistently across an organization.

Advertisements

The step involved in Identify Management is

  • Implement an approval process for creating or revoking identities. You will want a process that covers the approval for the creating, revoking and deletion of identities. Think in terms of user accounts and system accounts. Your process can be simple but the driving principle is the person making the request cannot be the person that approves it. This is part of segregation of duty . What ever the process is in terms of the technology that implements it, you should maintain and audit trail of the approvals. An example would be keeping copies of the email exchange, or the tickets that were raised in a ticketing system.Consider perhaps that your processes may vary slightly or be tightened up a little in certain circumstances. Examples of this would be where third parties require accounts or identities to be created. Also an example would be super user and administrative identities.
  • Confirm the business requirement for creating an identity. It is important to understand why you are creating an account or an identity. It will allow the person approving it to understand what and why they are approving as well as allow you to maintain some level of control . Particular attention should be given to admin accounts or accounts that have special powers.
  • Verify the identity of an entity before creating the virtual representation. The standard doesn’t give much guidance on this and clearly it is going to be hard if not impossible to do for non human identities. It is a hang over from when they only worried about user accounts so they kept it. It does make sense for users and people so as part of the approval process, or for the human that requires the identity, verifying who they are and that they are who they say they are makes senses. There is a lot of phishing attempts made to get people to do things they would not normally do, including creating accounts, that bad guys then use to do you harm. I am not saying check passports and photo id but I am saying be sensible and do some level of check to satisfy yourself the person is who they say they are. Use common sense. If you get a request and it doesn’t feel right no one minds if you pick up the phone to check or ask their boss / others for extra verification.
  • Create the identity. This really should be done by someone that knows what they are doing. The identity is going to be used to access ‘stuff’ so it is probably a good idea at this stage to create the record of the identity and who it was assigned to.
  • Configure the identity and activate it. Again, this should be done by someone that knows what they are doing. It is easy to create accounts and identities but you really should have experience to understand what you have created and how to configure in a way that meets the approved request and the needs of the business rather than what ever the default system identity. Defaults are defaults and not designed to meet your specific needs.
Advertisements

Considerations when implementing identity management

1.One person one id. Where an identity is assigned to a human then it should be unique to that human so we know what that human did if things go wrong and we can control what the human has access to and can do.

2. Many persons one ID The standard and common sense wants one human to one ID but it does allow for many people using one ID where they are required for business, operational needs and have appropriate documentation. Which makes one person one ID redundant as a rule really, as if you need it this way then you can have it. I guess that is why we are calling it guidance. Have one human to one ID where you can. Thanks.

3. Non Human IDs As in the implementation guide above you will want an approval process for system and non human identities. You will also want some level of oversight of them. There is no guidance in the standard on what this means so I recommend having a periodic ( monthly perhaps ) review of all service accounts to make sure they are needed still and perhaps alternating with a check on the configuration of the ID and what it can do.

4. Remove old IDs You have a starter, leaver, mover process hopefully where HR will inform your process that someone has left so you can remove the ID. If you haven’t then you should. You will also have regular access reviews where you are checking who and what has access to what so you can mop up where the HR process has failed.

5. You can only call something one name. The standard doesn’t want you calling entities by different names with different names mapped. If your entity / server / laptop or what ever is called Brian then it is called Brian. It isn’t called Brian by IT but Anna by HR.

Log Stuff
The standard wants records of significant events on the use and management of identities and for that to be kept. This is actually a powerful statement and was a clause in its own right but logging and monitoring of identities and administrative actions is a must. It is just up to you to decide what ‘significant’ means. I would not get carried away logging everything as you will never look at it but consult the norm for the systems you are using and think about things like

  • failed log on attempts
  • account creating
  • account deletion
Advertisements

Leave a Reply