Caution: silos ahead. The risks of diversifying your IAM strategy

It’s been an interesting news cycle for identity solutions. Depending on whom you ask—and whom you believe—a popular identity management provider may have been breached across the entire standard attack kill-chain (ingress, C&C, lateral movement, exfil) a couple months ago. I have a lot of questions about the specifics of the attack itself, but what the attackers revealed is that identity is a lot more than just authentication. 

Let’s address one thing right off the bat: zero-trust and modern security postures assume breach, so the idea that they were (or weren’t) breached isn’t really an issue. Breaches happen. Learn from them, minimize the blast radius, lick your wounds, and move on. 

But the fact that it took 2 months to report it is absolutely an issue, and depending on who ends up being affected, it may come back to bite them hard. GDPR only allows 72 hours for self-reporting, and I’m more than a little confident this org has customers that can pull that lever. 

Now on to the meat of what I find personally fascinating about this whole thing… 

The solution that was attacked principally focuses on identity and authentication. It does not directly handle access management, though it is on their roadmap. I’ve been working in IAM & IGA for YEARS and never realized how good I have it getting all of my signal data, my attributes, my logging and analytics, and my conditional access processing from a single product. I came to Microsoft identity solutions—namely NT domains—back in 1999 after several years of trying to manage access on Mac networks. I’ve seen the literal worst identity management and the culmination of decades of development in what I believe to be the best. 

And I can tell you, with absolute certainty, that your IAM solution MUST do more than simple authentication. Let’s talk about what your IAM/IGA should do, and why it matters. 

First and foremost, it must provide secure mechanisms for authentication. That’s a given, and we need to be squarely focused on MFA & passwordless authentication. Device authentication should also be a consideration in this first layer. There are a bunch of players in the top right square of Gartner’s Magic Quadrant for this, and rightly so: authentication is the baseline. 

Second, it should manage access. That seems kinda silly to have to call out since we’re literally talking about “Identity and Access Management”, but it’s a hurdle many systems do not clear. So let’s manage access. Let’s go beyond checking tickets at the gate and make sure once you’re in the castle, you only get to the spaces you need to do your job. That means groups and rights. That also means separating users from service principals. It also means hygiene for account attributes, since we can build access on dynamic properties. 

We now have enough data to begin to reason over access with Conditional Access policies. We can see that an authenticated user, coming from an authenticated device, is trying to access a resource to which access would normally be granted, but before we grant that access wholesale, let’s look at some of the other metadata of the access request. Is this request coming from a location I trust? Is the device compliant with our security requirements? Is the user also trying to access other resources at the same time from multiple geographies? Is the user’s credential-pair exposed on the Internet? Are they using modern authentication? MFA? And then what do we do about it if they don’t clear those hurdles? And should we periodically re-assess the session to ensure it still passes our tests? 

Next we need to layer in access governance. Auditing, access reviews, management of elevation. This is also the area where we can begin to identify access requirements of a given job role, bundle them, and deliver them as a single access package. That, in turn, means approval processes with failbacks, making decisions about if and how much access to grant to internal vs external users, whence to source identity and what to do when access requirements expire. This is also where we make decisions about package compatibility. If, for instance, we define a package for Help Desk technicians, it would likely be inappropriate for anyone holding that role to also have the Compliance Officer package. An IAM solution should be able to handle that. 

Finally we need to continuously evaluate user behaviors to identify shifts and risk post-auth, post-access, post everything. This may be a component of assessing insider risk or just additional evaluation for compromised accounts, but our IAM must be capable of assessing behavior patterns to determine when users change habits, like significant changes in work hours, multiple new devices, abnormal access and file activities. 

An IAM solution should be able to authenticate identities, whether they be users, devices, service principals, or “other”. It should be able to manage access, reason over that access, govern that access, and report on that access. If it cannot do those things without external help, I would argue it’s not a full IAM solution. It may be an authentication broker or a governance engine, but it’s not an integrated solution. As such it will absolutely require exposing your identities, apps, and infrastructure to additional complexity and ingress points that may weaken, rather than strengthen, your security posture. At a minimum it will demand investment in some sort of intelligent auditing like a SIEM, and the silo-ing of responsibilities will increase the time-to-detect and time-to-respond for any attack. In an assume-breach world, that is unacceptable.