The Future of Identity

Twenty years ago, Identity was just getting started, and IT pros were beginning to question people, “What are you doing to create accounts?” Everyone was starting to talk about Identity.

Five years later businesses had moved to understanding what Identity was but still wondering why they should implement it.

Five more years later and they understood why, but needed help.

“There’s no magic to it. In Identity we don’t move at the speed of light. We don’t make rapid shifts. Some of that is going to change.”

Jim Gerken, Innovate Cybersecurity Summit

Where Are We Now: Static

Thinking five years ahead means doing what the bleeding edge folks are doing today. This is about how most organizations today approach their planning for Identity technology. It’s a bell curve with nearly everybody sitting in the middle. A few people are ahead of the curve doing what we will be doing five years from now.

There’s no magic to it. In Identity, we don’t move at the speed of light, we don’t make rapid shifts, and some of that will change. A lot of what we’ve been doing has been very static. In Identity, we have five core functions:

The first is an identity repository where we stuff all our identity data. It was a directory back in the day, but now it’s a little more complicated.

The next is provisioning. This is where you move the data from the repository to where it needs to be. Only a few applications exist that consume data directly from the repository, so we move the data into the application where it’s needed. Some applications can consume the data directly from the repository.

Identifying and validating the users is also a core function that hasn’t changed—it’s what we still do. We call it authentication, where you’re saying I am who I am pretending to be.

The function that answers the fundamental question of “can I do that?” is called authorization. It has stayed the same too, so can I do that is an interesting question that we will discuss from a visibility perspective. Visibility is the latest thing we’ve been talking about in Identity.

Governance and Visibility

Identity used to be a magical thing that nobody cared about so long as people could log in and do their jobs. As long as we were the invisible thing, it made it so the rest of the business could function. Now due to regulatory compliance, etc., we’ve got governance.

This means we must demonstrate that we’re doing our jobs; we need to give people visibility into why they can’t do their jobs even though we set up access the way they asked us to do it. So, visibility and those functions are still the five core pieces of what we do. Nothing new.

The Future of Repositories

Identity repositories are changing—we are adding a lot more identity data into that repository, not just more identities. An identity is a person or a thing with attributes about that person or thing, and I’ve stored that in my identity repository.

Identities are kind of fragmented. Example: we’ve got personas where I am one biological entity that may log in as a student where I have limitations on what I can do, but then later I log in as a staff member for my campus job.

It’s possible that I’m also a TA (teacher’s assistant), so I may also be faculty. So, where there used to be three different identities—teacher, student, and staff—now all three can be one person, and we need to be able to split the things we do.

Some students in staff roles can look at other people’s information, which is very bad, but that’s part of their job. How do you control that? That’s where personas are useful.

But now I have segmentation in the data, and I have to be able to satisfy regulation like GDPR, CCPA, et al.

Now I’ve got attributes about attributes:

• Phone number
• Who can I share the phone number with?
• I need to record that status.

Also, it’s okay to use this attribute data for required business purposes like SMS notifications for MFA, but it’s not okay to use it for marketing purposes. This is an example of an attributes about attributes.

It’s a never-ending cycle and a common joke in this space. You see that this data and the controls about all of the data become more data in your data repository for provisioning.

The Future of Provisioning

How many people have succeeded in simplifying their environment? And reducing their footprint with the number of applications they have?

Nobody should raise their hand here.

Provisioning is now more complicated; I’ve got more destinations that need this data, I need to move the data into more places, and when I move it, that data needs to be monitored, managed, and controlled.

Example: An online retailer that needs to have custom things made by a supplier, that means sending off some data to the supplier but also maintaining control of it. This is a very common business scenario. So, provisioning and moving this identity data into various places becomes something that is not getting any simpler.

The Future of Authentication

I’m tired of putting authentication apps on my smartphone. I currently have 12 authentication apps. Sometimes they’re beeping over each other, and I can’t press the “yes, it’s me” button fast enough or have to think, “which one did I register this application into?” It’s become much more complicated.

At the same time, all of us are facing requests from our users to streamline this:

• We’re talking about frictionless authentication
• We’re talking about “remembering me”
• We’re talking about basically going back to the days of cookies

We want to make it easier on our users, but if I’m streamlining it and it’s becoming more complicated, how to resolve that? Probably more attributes! Authentication is now becoming more of a task that I may use.

One way to streamline is to consider your context, for example:

• I recognize your environment.
• You are coming in from your work machine, and you badged into the building, which is where you usually come in from.
• You typically log in at this terminal.
• It’s got the Bluetooth associated with your smartphone, and so it’s you sitting at the desk.

Maybe I don’t need to force re-authentication this time. But when you try to do something a little riskier, like log into the payroll app, well, maybe now I need to ask you to re-authenticate. Issue a check for $2 million? I need you to authenticate with two-factor.

We are starting to do things that are more task driven, which can no longer rely on session-based auth. It’s something that happens throughout the day, prompted by the nature of tasks and is driven by that data.

The Future of Authorization

Similarly, authorization—my ability to do things—is changing and becoming dynamic as well. I’m starting to make more real-time decisions about what I’m allowed to do, or the system is at least.

I’ve got a job and a particular role that I fill, and I’ve got attributes that drive my attribute-based system and I’ve got the ability to make those decisions.

But the need to make those decisions is more frequent throughout the day. I’m at my workstation, which lets me log in automatically because of my Bluetooth devices. Now, I’ve picked up my laptop and walked down to the Starbucks on the first floor. My context is now changed. The attributes about what I’m trying to do have changed, my environment has changed, the network I’m on has changed—all of that is again the balance of security and ease of use.

Do I need to have this user re-authenticate to make sure it’s still them? To ensure that it isn’t a piggyback communication and they’re in two places at once? These choices and authorizations become real-time decisions now. And then there’s visibility.

The Future of Visibility

Today we do certifications, we do audits, we do reports, and they’re very static. Show me who has access. It’s not changing.

Back when I was an IT administrator, they usually asked, “show me who has access,” and we’d run that report before 9 or after 5 because it was about “who’s in this group” or “who’s in this role.” But throughout the working day there would be access changes to get tasks done, then we’d reset it before 5.

Nobody has access, see? That example is to show that audit reports and certifications are still in static mode.

When I run a certification, it takes a day or two to calculate and compile this extensive report or application showing this data. How am I going to change that? How am I going to get the auditors to change their mindset to ask better questions like:

• Who might have access?
• Who could have access?

Not who does have access? Show me who used it, show me who might have used it, and reconcile that.

Visibility is definitely changing and becoming more dynamic.

Signals

A lot of what’s driving this is what everybody likes to call signals, which is just more attributes and more data. So, in an attribute-driven world, I’ve got data, and programmatically I’ve got more data. Help me make better choices—feed me more data.

I’ve got many more attributes that I’m feeding into the system that comprise these signals. Profiling data, for example, to determine what is normal and what is abnormal as a criteria for risk.

• Is this normal? It’s a lower risk.
• Is this abnormal? It’s a higher risk.

So, as we start gathering all of this data, we get more information to feed us to make more informed decisions, more on-the-spot decisions.

More attributes, attributes about attributes, and so on.

Moving away from RBA

It used to be all about role-based access. I put you in a role, and you’ve got a job. You work for this department; I can define those as little boxes and put people in them. You may be in a combination of boxes, or you may be in one box. It doesn’t matter. It’s a role-based system.

Then things started changing to be more dynamic. What about the attributes I can modify? Your role based upon your attributes?

• You are in a role
• You are in accounting
• You are in accounts payable.
• You can write checks, but you’re not allowed to write checks outside the building.
• You’re not allowed to write checks outside of normal business hours.
• You’re not allowed to write checks over a specific dollar amount or to particular vendors.

In a healthcare scenario, you might be a nurse. If you are a nurse, you can see and work with the patient records of the patients you treat. Each scenario will have its own definitions.

Healthcare data breaches in the news? Somebody was looking at patient records they shouldn’t see because they were not providing care for that patient.

If you work for UCLA Medical Center, and look for famous stars that get checked into the hospital, you can sell that information to TMZ. It could be nefarious, or it may not be. It’s all about that kind of access.

Purpose-Based Access

Now we’re going from a policy-based system, which was the evolution of what you’re allowed to do or not allowed to do, to a purpose-based system.

Example: you’re in tech support. What do you need to do to service the customers? It may be three or four tasks you need to do on the spot or regularly, but your job is to service the customers.

Another user is in accounts receivable and needs to do accounts receivable-type things. These are different purposes which will determine different access..

If I need to look up phone numbers and track people down to collect money, now I’m getting into not just who’s recorded as the person who sends the check. But how to call that person and remind them?

We’re getting to purpose-based access controls. In the same conversation you might hear “Zero Trust,” etc., which is based on just-in-time access. My philosophy on Zero Trust is unlike the Zero Trust network architecture, where server A doesn’t trust server B or only trusts server C for this particular function, it’s more that I don’t trust any of my users.

For this reason, they are all base-level users until they need to do something, and I elevate them to do the task at hand, and then I revoke that elevation once finished.

The result is: if you are hacking that person’s account, chances are that unless you time it really, really well, they’re just a plain user.

You might get access to their e-mail, and you may even see some of their benefits because you cracked their password, but you can’t do any other task because they’re not allowed to do any other tasks.

Just-in-time provisioning, just-in-time de-provisioning.

Context-Based Access Enforcement

Everybody’s using a VPN—it’s trivial to change your source IP location these days.

Things like that are not criteria I use anymore. There are many other attributes that I can use to determine normalcy, which means that we’re going to have a lot of attribute aggregator services—a way to collect all of this information.

If I’m doing queries to 20 different systems, the decision to allow or prevent you from writing this check, granting extra access, rebooting that server, or whatever task you’re trying to do will now take measurable time.

It’s cumbersome to query 20 different systems to determine and collect all these attributes to determine if it’s an appropriate purpose. So it’s best to aggregate services to pull all of these attributes into one place, so I can do a single query and be speedy and fast about it.

Visibility for Auditors

How do I track this for the auditors?

If you manage the SIEM, I’m sorry about this; we’re going to be dumping a lot more information into the SIEM so that we can recreate why something happened. It’s an appropriate place to store it.

To accomplish this, I need to take all of my decisions, the policy that I called into effect, and the decision that I made, whether I authorized or did not authorize this, and send that out to the SIEM, so it’s recorded.

Suppose nobody has any access because you’re performing maintenance, or nobody has any access except when I make a desperate hack to get it working. In that case, you need to be able to explain why somebody did something. And if you don’t have the data to back that up because it’s fleeting—just moments in time—you won’t be able to show that to the auditors. You won’t be to show that in defense of your needing to make more policies or implement more systems.

We talked about personas already. These services are becoming more in demand. I need to be able to grant and revoke access, and I need to be able to employ more automation to set this up. And I’ve got more platforms, SaaS or not SaaS.

I’ve got many more systems out there utilizing all of this, but our users want it to be simpler. Our users want it to be less of a burden on them, so we use more automation to be able to detect this. Again, profiling or determining what’s normal, calling it out when it’s abnormal, and then handling those exception cases.

Trust is the New Normal

We’re building stuff on trust. So, you need to trust the data that goes into the system, and you need to trust the data in your identity source, and you need to be pulling it from something that is a trusted source.

In identity management, we don’t have standards, so everything’s bespoke.

Jim Gerken

HR usually requires that you provide an ID, and they make sure it’s you or that you are who you say you are. We don’t usually do that for a lot of other things, and third-party downstream problems typically occur for this reason—it’s outside our control to validate a contractor.

We have an arrangement with a staffing agency, we trust that they are doing the right thing to verify a resource. If they’re not, that becomes a problem.

Similarly, when you’re doing authentication, take a look at the authentication that you’re doing and ask yourself do I trust it?

Biometrics sound great, but if you’re comparing it against a reference element of a fingerprint or face print provided by the person you’re going to compare it against, how much do you trust that data?

We’re going to see it become necessary to take trusted sources and utilize them for your authentication data. Sure, it’s great that a smartphone with an authenticator app was registered with my system, but what does that tell me about who is using my application?

Do I cross-reference that phone number with the phone company records to make sure that it’s you? That is the phone number I assigned you out of the corporate office. I mailed the phone to you, and I know it’s yours. I made you come in and show an ID, and you needed a building badge to get in the first place…

Or do you implicitly trust it simply because it’s MFA?

We’re building more and more automated rules. How many trust the automated systems to specifically do what we want them to do?

We’re going to build more and more black boxes. Our policies, our purposes, all this data that’s getting fed in there is becoming a black box. It’s just a question of setting the computer up to do its thing. I don’t want to monkey with it; I’ll handle the just exception cases.

So, we’re going to have to trust those automated rules. And we’re going to delegate some of this responsibility to other people. We see that already with federation resources, and we want other companies with whom we have a federated relationship to put people in the groups.

We can say: “Here’s what you need to do technically to be able to use this service, or to be this person, or have this role within the application. You just put them in the right group.” We want to unload that responsibility so we’re establishing more trust.

How do you verify and validate that trust? How do you set up and earn that trust? These are things that we really have to figure out.

Along those lines, we’re now going to focus on more of a macro picture. We need to start leveraging more of the big details and focus less on the details.

In identity management, we don’t have standards, so everything’s bespoke. In essence, I work on the plumbing connecting two applications or an application to an identity source, or an application to an authorization service or an authentication service. I work on that plumbing. I work on the details.

What attributes am I exchanging? That takes up all my time, and I don’t get to focus on business policies or how I like grouping things together for business processes or purposes, which means that we’re going to have an overload. We’re going to have more data and more systems, and we’re getting more commitment to this automation. So, we need more management of the automation.

We’ll need more people, and we’ll have to learn to trust these systems and then test the systems.

How many of you have actual rigorous testing of your identity management?

• If somebody makes a change to a policy, do you feed it a spreadsheet of known inputs?
• Do you make sure you have a spreadsheet of expected outputs to compare against it?
• Or do you make a policy and use the good old user notification system for when something is broken because you didn’t properly test it?

The systems will get so much more complicated that we will have to do much more testing.

New Transitions

As always in identity, we don’t make any fast changes. It takes two or three years for us to make a major change to our systems like: replace an application, change the way that we go from role-based to attribute-based, or go from attribute-based to policy-based to change from single sign-on using a proxy model to single sign-on using an IDP out in the world using SAML. We don’t move fast, and it makes it easier to forecast things, but we are going to have to evolve our tools to gather all this data and use all of this automation.

We can make some changes toward getting some standardization, but we’ll also have to change our approach.

We’re going to be provisioning, and our access management systems are going to be real-time. We need to scale; all of these systems will be bigger or more fragmented to provide a more services-oriented architecture. Are you staffed to support this?

We talk about identity and security— identity is as big as security. There’s no chief identity officer (CIDO) for most organizations, but there is for those on the bleeding edge, and their spend for identity is nowhere as big. But without much warning, identities will have become the new perimeter and we will need more staff to support this new perimeter. You’ll need staff that specializes in the voodoo behind the scenes in the black box and people who can support the front end.

And then most importantly, your model of specifying requirements has to change and ask “why?” Today, we gather information about what the data is and where it is allowed to go. The why drives the purpose. Purpose-based access systems are all about why you need this access. If I can document why I made a change to a system or why I made a policy that grants a particular group a bundle of access, then the “why?” makes it easy for me to track the changes.

In your own shift to refine your identity management, before you make any changes, ask yourself why you are doing something so that you can reconcile with policy. And with that, we start on this journey to the future.