The objective of this post is to explain the concept of Identity and Access Management and provide you with some starting points to implement it in your organization and make sure that this crucial topic is under control.
Let’s start by a Wikipedia definition: identity and access management (IAM or IdAM), is a framework of policies and technologies for ensuring that the proper people in an enterprise have the appropriate access to technology resources.
In other words, organizations must ensure that employees, customers and partners have appropriate, secure access to information and technology resources. IAM is about defining and managing the roles and access privileges of individual users and the circumstances in which users are granted (or denied) those privileges.
Before jumping into security controls, let’s define some major concepts:
Identity
An identity is something that can be used to recognized a person as human being, first thing could be the first name, but we quickly understand that this is not enough to differentiate two persons, therefore the following characteristics are also part of the identity (list not exhaustive):
- Last name
- Phone number
- Company
- National number
- Address
For security purposes we need to uniquely identify a person and for that we use an account.
Authentication (account)
Authentication is the process of uniquely identifying a person or a device. When a user attempts to access a system or data, first he/she should claim his/her identity (often by entering a user name and password, also known as account).
Account is therefore a unique identifier mapped to an individual or a service. Often we tends to use IDs for accounts, this is totally non personal as nothing map the identity of a person to his/her account, and that’s the purpose of it.
Moreover, a user identity can have multiple accounts, for example imagine that you want your users to have a regular account for “normal” work and that you want some IT people to have an admin account with elevated privileges, in this particular case an identity will have 2 accounts.
The following factors can be used for the authentication process:
- Something you know (e.g. password, pin code)
- Something you have (e.g. ID card, smart card)
- Something you are (e.g. fingerprint)
Authorization
Once you are authenticated by a system you need to have the permissions required for doing what you are expected to do on the systems (i.e. need to know). Authorization is the process of giving permission to do or to have access to something.
A system administrator defines for the systems which users (or group of users) are allowed access to the resources and what privileges of use (e.g. read only, write access, access during certain hours only)
So why we need IAM?
Basically, every system in an organization manages its own identities and access privileges (i.e. local accounts). So imagine that an employee must have access to 2 systems, his/her needs to be managed on the 2 systems, and what often happens… the user uses the same password for obvious reasons.
In this small example, we quickly understand that it’s both an administrative burden to manage user accounts at the system/application level and a security threat. That’s where identity and access management solutions become critical to organizations. Hereby are the main concepts of such solutions:
- Centralized Access Management
- User provisioning: manage user accounts/identity and permissions
- Single Sign-On (SSO) authenticate users only once independently of the system accessed (permissions/authorization can obviously be different between the different systems/applications)
- Multi-factor authentication (MFA): on top of asking the users to provide something he/she knows, requires the user to introduce something he/she has or something he/she is (cf. definition of authentication)
Major IAM security concepts
Personal accounts only
Non-personal accounts should be prohibited. Accounts such as administrator and root (which are most of the time the keys to the kingdom) must not be used under normal circumstances but only in case of urgency (i.e. break the glass procedures).
Using generic accounts prevents, in case of an incident, the organization to understand who did what on the system (search for non-repudiation for example if you want to know more on this topic: https://en.wikipedia.org/wiki/Non-repudiation)
Groups to assign permissions
Don’t assign permissions at user level, it’s unmanageable, all the permissions must be managed at groups level and users must be added to the correct.
As you can imagine some groups will provide with elevated privileges the users belonging to it. For theses sensitive groups it’s crucial to monitor them (i.e. when a permission is changed, when a user is added/removed from the group).
Least privileges
When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.
Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.
Enable MFA
For extra security, you must require multi-factor authentication (MFA) for all users. Whether it’s a one time password (OTP), a fingerprint, a smart card or whatever this extra layer for authentication improves drastically the security posture of your organization.
Strong password policy
I will not detail here what is a strong password policy for users, but if you are interested in this topic you can start by search for NIST SP 800-63b. Note also that nowadays people are talking about passwordless authentication, but since I’ve never met a company with that concept in place I will not make any comment but it worth taking a look at it if you are interested in what might be the future …?
Revoking accesses & review
For me the key point when we talk about IAM, often the companies are very good at granting rights to users, simply because else the employees would not be able to perform what they are hired for… But what about revoking accesses, often this process of revoking access is simply not present or not applied at all. This process must be defined ideally even before defining the process of granting accesses.
When this process should be trigger? For example when a user change function, when a user leaves the company.
Good practices in this domain is to ensure that the owner of a systems perform the following reviews on a regular basis (at least once a year and more frequently for critical systems):
- Review the different roles defined for his/her application/system (e.g. the role ABC provides the users having this role with the ability to read all the invoices in the SAP system), to ensure that there is not a role providing incorrect authorization.
- Review all the users for each role to ensure that the revoking process worked as expected and that there is no user with authorization he/she should not have.
