What is IAM? (AKA: Back to the basics)

In previous articles, we directly dived into some quite-specific concepts of Identity and Access Management (IAM). I'm aware, however, that we are yet to set a basic scenery with the main components of the IAM domain. Kind of a chapter 0 defining the building blocks. Let's take the time to do that, without going into excruciating details for now (although we will cover them in later articles).

So: What is IAM? 

We know that in the domain of Information Security, Identity and Access Management is the field that aims to ensure that the right users have appropriate access to different resources (data, applications, etc.). In other words, it guarantees that these users can only access what they have been authorized for, in line with risk-based decisions made by the owners of those resources.

But what does it all mean? How do we achieve this, and what are the different components of such an enterprise?

Although very often we find them muddled and mixed up (especially in real-world situations), IAM has five clearly distinguishable pillars:

1. Identity Management (IdM) is the way in which the organization (or system) knows about who might access resources. It's the processes around identifying these individuals (which might be users, services, or any other possible type of actor), sufficiently validating their identity, gathering and handling information about them, and running them through the identity lifecycle, including onboarding, change and offboarding (AKA: the Joiner-Mover-Leaver processes). This pillar is probably the most critical one, since it's a dependency for all the others. It has a lot of implications in terms of regulations (what information you can manage, why you do it, how you do it...) and it needs to be well thought-out so that the information is relevant for your long-term vision (Example: if you already manage 50,000 employee identities and you then decide that you need to introduce a new attribute to identify their Job Profile, this change will be much harder than identifying this need at the beginning).
2. Authentication (AuthN) is the process of validating, at one point in time, the identity of the user accessing a resource. In other words, it's verifying that the user is who they say they are. There are many ways to do this, ranging from the user providing a username and password that we store, to requiring the user to confirm a push notification on their phone. There is also non-interactive authentication, mainly for services to prove their identity, even though there will be no human user actively providing that proof-of-identity in real time.
3. Authorization (AuthZ), also known as Access Management (AM), is the process of defining which users are entitled to access which resources. In other words, defining "who can do what" according to our risk appetite. There are also multiple methods to do this, from simple lists of users who can do X, to automatic rules that get evaluated in real-time to decide whether the user should have access or not. It will be very important to choose the right one, depending on the complexity, size and dynamism of our organization, or we will find ourselves paying the price in the form of an unmanageable and less-than-secure authorization setup.
4. Access Provisioning, is the often-disregarded area of IAM. It is the piece that makes it all useful and valuable, by making those decisions of "who can do what" available to the applications. Let's say you have defined that "John can access our monthly financial statements". But... how do the different systems which allow accessing financial statements know that John is authorized to do so? Access Provisioning is about putting this information in the right places, or communicating it to these systems so the appropriate access can be enforced. The different ramifications and possibilities for this capability are as many as organizations exist, but in future articles we will cover the different approaches and what they mean.
5. Governance, also known as Access Control (AC), is the set of practices for controlling that all the aforementioned pillars work as expected towards reducing the risk that the organization is exposed to. It has not purpose by itself, but as measurement devices to ensure that all the other components work reasonably well. IAM Governance ensures that we are adhering to the principle of Least Privilege (that is, that we are granting authorization on a need-to-access basis). For example: How are we making sure that employees leaving the organization are properly removed from all systems? (maybe it's an automated process, maybe a manual review every Monday). And how are we making sure that those controls themselves don't fail? It might lead to controls on top of controls on top of controls... Up to which point? How much risk-reduction and how effective and exhaustive do we need these to be? Well, that will depend on the risk appetite of our organization and the applicable regulatory and legal obligations. Remember that absolute assurance, is never possible; we're always going for reasonable assurance (more on that in later articles).

Every organization needs to think carefully about all five of these capabilities. If you overlook just one of them, the whole thing collapses. If you have very strong and restrictive authorization policies, but your authentication is a joke and anyone can impersonate anyone, you basically have nothing. If you have extremely strong authentication but their is no identity verification when signing up to your environment, you basically have nothing.

These pillars form the chain securing your IAM function and, like any chain, it will only be as weak as the weakest of its links. It's up to us to make sure we're confident and comfortable with the strength that we have imprinted in them, so that when the situation will tighten the chain (and it will), it can take the tension without breaking.