Everything IAM: Identity and Access Management made simple

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 i n 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-worl

I often see that the concepts of Entity , Identity and Form of Identity are assumed as understood by all parties, and yet rarely with the same definition for all. These are not specific to the realm of IAM, with the first two being universal and the latter being simply derived from their physical-world counterparts. The problem is, as we will see, that not having a clear understanding of what they mean and their importance, will lead us to make design mistakes which will have an impact in our security and governance. Let's go step by step and try to understand each of these terms, in the physical world, to map them later to the digital one. Entity An Entity is defined as "something that exists independently, not as part of a whole". This is the foremost node in the identity chain. John Smith  is an entity (a car is also an entity, as is a service or an application , in the digital world, but let's stay with John as a simpler example, for now). John can't be mor

The following scenario should sound familiar for most of the readers who had to work from home during the recent pandemic. Your day starts and you sit down in front of your workstation. You turn it on and you are prompted for your credentials. Some form of more-or-less sophisticated multi-factor authentication (MFA) helps ensure that you indeed are who you're claiming to be. That way, your organization makes sure that only the right people can access its resources. Putting aside the many challenges that this scenario presents under the hood, the truth is that we know quite well how to solve them. We know what methods, technologies and practices can be employed, and which can't or shouldn't. However, the recent pandemic has uncovered a fundamental weakness, common to most organizations. Before 2020, the typical process would go as follows. I want to work from home, so I'll need to have access to the company network or systems from my home office. But wait! In order to do

As of 2021, there isn't one single day where this buzzword is not mentioned in some discussion or reading materials I come across. But what is passwordless ? What is the big deal? First of all, let's dive a little into the reasons for this sudden hype of a concept that has actually been around for more than 15 years. What's wrong with passwords? Passwords. They are the most primitive means of authentication out there, right? Wrong! In fact, passwords are (originally) not a method of authentication at all.  The first method of authentication ever used was actually  biometrics . Face recognition, specifically. Humans have been using it for as long as we exist. Hello, Bob! I know it's you, because I know your face! That's what we did, for thousands of years. We recognize that a person is Bob because we recognize his facial (or other) traits and associate them to his identity. At some point, however, identifying anyone based on their face alone becomes impractical, beca

There are two seemingly irrelevant decisions that we tend to take very lightly when creating permissions, and which will mess up our Authorization model in the long-term and make it totally unmanageable. The first one is a bit better known: " Avoid overly broad permissions " or " Make your permissions as granular as you can ". We will address it in detail in later articles. The scope of this article, however, is the second principle, which sounds a little more arbitrary and typically triggers a deal of unrest with the application owners when pointed out. It's about "D efining your permissions as verbs " or " Properly naming your permissions ". Application owners typically find this concern to be an exaggeration. Who cares about the name of permissions, right? Let's use a simple example to illustrate how much of a problem this will become if we don't pay proper attention to it. Let's say we have a CRM (Customer Relationship Managem

In every organization, users will need access to different resources in order to be able to do their jobs. These might be data, applications, system-administration rights, approval capabilities for different processes, etc. Most users will (or at least should) end up with a set of permissions which present a low risk to the company. In other words, if those users decided to harm the organization, or if their accounts were compromised or stolen by external attackers, the level of damage they could infringe is fairly under control. However, it is inevitable that some other users will end up holding certain permissions that do pose a much larger risk. System administrators could disable all corporate accounts, preventing all employees from carrying out their functions. Data owners could disclose confidential information to the general public, causing a huge damage from a reputational, financial and legal perspective. The Chief Financial Officer could approve inappropriate payments res