The 65th Edition of the Identity Jedi Newsletter

WHAT’S HAPPENING THIS WEEK

The Path To Identity Security

It’s the latest marketing term that has all the IAM vendors raving. But what is this shiny new term that all the cool kids use, and how does it apply to you?

Identity security is the realization of a decades-long vision of making identity the lynchpin of your security architecture. Putting the process and technology in place to securely create identities, manage the access to those identities, and react to when that access is something that it shouldn’t be. It’s the next logical step of identity governance and automation. Creating a standard of access and then enforcing that standard.

But do you need to purchase a shiny new tool to get there?

No. You don’t need to, but you may want to. And there is a BIG difference.

Let’s lay out some ground rules for what this “Identity Security” thing is.

First, you want to create a centralized view of your identity and the access granted to that identity. Visibility, visibility, visibility, you can’t secure what you can’t see. And this goes beyond Active Directory. As much as administrators want to make it so, Active Directory is NOT THE source of truth for identity, it IS A source of truth.

Your source of truth should show you not only user information, but access attributes for all connected applications to that user.

User A —> “connected to” Account B —> “has entitlements” Entitlement C —> “which is mapped to” Application D.

Put simply, your source of truth needs context. How, what, why does this identity have access?

Once you have that, now you can move to step two.

Securing the identity.

Using the context around your identities, you want to ensure that the right person has the right access at the right time. Ok so let’s break those down:

Right Person - Every identity in your organization should be classified and given identifiers. ( Employee, Contractor, Vendor, etc). If a digital identity exists, it’s organized and identified. This means you need controls and processes around the lifecycle of digital identities within your organization. ALL OF THEM ( human, non-human, service-accounts, etc)

Right Access - The identity should be given just the access needed to accomplish the required task. That access should approved and logged like any sensitive transaction. That approval can be direct or indirect. By that, I mean that another user can directly approve the access and provide that approval digitally. Or indirectly, the access can be assigned by policy or role that is approved by the organization.

Right Time - No identity needs all access all the time. They just need that ability to get granted access when they need it.

The final piece…

Enforcement

Identity can’t just be a one-way street in which it only sets polices, and access, but doesn’t reactively enforce them. IAM systems need to be able to respond when something goes wrong and also be able to tell when something goes wrong. For instance. Your organization’s SOD policy states that no administrator will have write access to Application A and Application B. As part of your lifecycle process, you ensure that no account is ever created with those two access privileges. Access requests for those privileges are denied as well. However, the last frontier is to ensure that if that access has been granted, it’s alerted, reported, and, most importantly, REMOVED.

Identity security isn’t something you buy; it’s something you do. It’s a culture, a way of thinking, an active day-to-day discussion of how identities move throughout your organization and how to protect them.

How I Started In Identity

My introduction to identity was by accident. I was hired to a project to be a J2EE developer and help build a “security application” that allows users to manage their access. I was super pumped ( just like the movie) to get started as it would be my first time as THE developer. Needless to say I was ready to crush it!

Oh those plans we make…

When I got to the project, I was given some basic requirements around what was needed. An interface for users to request access and also see what access they currently have. Easy enough I thought, so while I was waiting for my access to get approved and provisioned ( yeah, I know ironic right?) I started building some prototype screens and flows and just banging out code.

About a week later ( because it took that long to get access….) the architect on the project walked into my office and dropped three manuals on my desk.

“What’s this?”, I ask

“That”, he points to the manuals on my desk. “ Is what we need to deploy by the end of the year”. “ I want you to go through it and have something up and running for me when I get back,” he says.

“Wait, when you get back? Where are you —” I stammered.

“Vacation kid, see you in two weeks”. he said and walked out of my office.

I look down at the manuals..

“What the fuck is Waveset?”…

And almost 20 years later, here I am. Lol. The next 3 months of that project I spent every night reading the manuals, installing Waveset Identity Manager, learning XPRESS ( I still hate that language), and absorbing everything I could about how the product worked. But also, WHY the product worked. What was the point of managing identities? What was an LDAP, a policy? Why was role-based access important? I immersed myself in the world and learned all I could.

I spent the next 6 years implementing Identity and Access Management systems and technologies for a variety of companies. Oracle Access Manager, Vaau, Radiant Logic, etc. But I also spent time learning the business needs for these applications the value they offered.

And..well you know the rest.

The moral of the story is….

No one plans to be in identity, it just sorta happens..lol.

Become a paying subscriber of Identity Jedi Newsletter to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In