Cybersecurity Architecture: Who Are You? Identity and Access Management

Welcome back to the Cybersecurity Architecture Series. In the previous three videos, I talked about some of the fundamental concepts of cybersecurity architecture. In the next seven videos, we're going to talk about the seven domains of cybersecurity architecture.

And today we're going to focus specifically on identity, or identity and access management. IAM is another way that it's thought. It said that identity is the new perimeter.

And the reason people say that is because we really can't rely on all of these other things alone to do the job. We need to start figuring out who the user is as soon as we possibly can. And what we do in identity and access management are the four As.

The first one is Administration. That's where we try to figure out what access rights you have and create those. Authentication, where we determine who you are.

Authorization, where we determine if you're allowed to do this or not. And then Audit where we go back and see if we did the previous three As correctly. We're going to talk about an architecture that you see here.

This is a high-level conceptual architecture where we're going to talk about the capabilities that will implement that. Starting with this base level. Think about if we were doing a building, this is the foundation, or this is the plumbing.

This is the stuff that we're going to build on top of. And the first two concepts we're going to talk about here are store and sync. Why?

Well, it turns out we've got users, of course, and those users will be of different types. When I'm doing an engagement with a client and I'm trying to figure out what their identity and access management architecture should look like, this is where I usually start the discussion. I say, "What kind of user groups do you have?

" Now we're going to have a very simplified example here, but what it would be looking for is-- so you've got a bunch of users up here, what are the large general groups and types? Well, they might say, "Well, we've got employees, we've got suppliers, we've got customers. " That's three major groupings of clients or of users.

And then among the employee group, we could break that down and say, we've got people that do administrative staff jobs, we've got people in manufacturing, we've got people in sales. So those are different groups of large groups of users as well. Suppliers, I'll leave that all just as one.

And then customers, well, we've got commercial and we've got retail. So again, very simple example here. But you can see with these types of user groups what we're going to do.

We're going to use this later in defining roles, so just bear that in mind. I take these users and users then have certain capabilities. What they have are IDs and access rights.

For instance, everyone who's an employee is probably going to be in the HR system--that's what we would assume. They're also going to probably need email access and some of those users might need access to our customer relationship management system. Some of them may need also access to the finance system.

So I could pick one of these particular users and say those are the access rights that they're going to need across all of these different systems. Now, that's what the user wants, but these all have to have identities. Wherever I store identity information--so that is names, that is accounts, that is the department you're in.

Any information about a user is essentially an identity. And wherever I store that, I'm going to tell you is what we call a directory. Now there are some people that have more narrow definitions of directories.

But I'm going to tell you a directory is wherever we store user information. And what I need to do is for each of these systems that are up here, I need to be able to store their information in a directory so that I can then look up and do the authentication authorization, so I can store their accounts in the administration step, and so forth. With this, what goes into a directory?

Well, typically what I need is some sort of database because I'm going to store those accounts in the directory itself. I also need a schema. That's how do I organize the information about that particular user.

And I could use a different schema in different cases. Different applications may have different ways that they're expecting the information to be represented. And then ultimately, I need a protocol, a way that I can talk to this directory.

A thing that will let me send messages in and get information back out. I can store information in it, I can pull information back out. The most common of these protocols is known as LDAP --a Lightweight Directory Aaccess Protocol.

So this is a way of talking to [it]. Although what you'll hear many times people. .

. they'll say "I put it in an LDAP directory. " What they really mean is it's a directory that has these elements.

And I'm using LDAP as the protocol to talk to it. But at the end of the day, it's some form of data store that I've got here. And you may also hear the term Active Directory.

So that's Microsoft's version of this kind of thing, but it will also speak through the LDAP protocol. That's the industry standard protocol for this. Okay, so in a perfect world, what I would do is take all of these user accounts, all of the information that all these users, put them in one directory, we would call that an enterprise directory and it would be job done for this foundation layer.

In the real world, what happens is this system right here, you know, maybe it requires its information in a very specific directory. And this information has to be stored in this particular [one], that is, the application has hooks into a very specific data store and so forth. You see what's happening here.

That is, these applications are requiring specific directories. In a perfect world, it would all use one. In the real world we have multiple directories.

Any organization of any substantial size will have multiple directories in their environment. They might not think about all of them all the time, but they are there. So what would be the next best thing if I can't get everything into one single directory?

The next best thing, if I can't store them all in one place, is to have an ability to synchronize them. And there are a couple of different ways that we can approach synchronization. One is a virtual directory.

That is, where this thing here, is basically an index. If someone sends a request into this directory and says, "Look up this user information," it knows where the information is and goes out and retrieves it for me. The information then might be cached here for performance reasons.

But in general, it's an index that points in to someplace else. Another approach is a meta directory. With this, I might actually take the information and pre fetch it and store it up into an enterprise directory.

I might not copy everything from all of these lower level directories into the enterprise directory, but I'm going to copy the relevant pieces so that way they are already in existence, already there, when I need to look them up. So the first thing we have to do in our IAM architecture--have a place to store users and a way to synchronize their information so that we have an ecosystem of integrated directories. Okay, now we've covered the base, the foundation, the plumbing of an identity and access management architecture.

Now let's get into the real capabilities. First of all, we're going to talk about administration. That's where we create accounts, we delete accounts, we update accounts, we change privilege levels, all of this kind of stuff.

It's an administrative task. And the term that's often used is identity management or identity governance has now become a more popular term for this. But these all kind of mean the same thing.

And what we're going to do is take an example here. We're going to add into our architecture this administrative application, which again, is the identity management or identity governance. And I'm going to include in that our role management capability.

In the previous section, I talked about the different types of users that we have. In a good architecture, in a good implementation, I would take those different user groups and map them into roles. These are IT roles that will have some mapping into their business role within the organization.

And I'm going to use those things to then tell me what are the IDs that a person should have. in a perfect world, everything would map into a role, and then I know exactly what they need. In the real world.

Maybe it's 80, 20, maybe that 80% of your access rates, I can determine based upon the role that you perform. And then the other 20% will handle as one-offs. And that would still be a massive improvement.

Let's take a look at how this works. Let's say we have a user here. This guy just hired into the company.

So what are we going to do? We're going to add him into the HR database. So this is HR database is going to identify all kinds of information about how this user is, who they work for, that sort of thing, and the job role that they perform--so the business role.

What I can do then is generate from that a request into our identity management/identity governance system. That then will go into a role management system which will take the information that we got passed to us from HR and convert this into an IT role or roles. Because there could be multiples that this person needs in order to do their job.

Within those role definitions. For instance, if it's a bank, i might say if you're a teller, then you need the following access rights, because all tellers need that. If you're a branch manager, you need the following access rights, and so on and so forth.

So that's an example of what those kind of role mappings would look like. I based this upon what role that the user is performing, and I say we have already determined in advance that if you're performing this role, you need this account and you need this account. Great, I don't have to go figure out on a one off basis what they need, I kind of already know.

Then for each of these accounts, I need to go through some sort of approval process. Some way that I'm going to go through and make sure that you should have these access rights. In some cases, it'll be very straightforward.

For instance, if you're an employee, then we map you into the role, and that account might be, say, an email account. Let's say all employees are entitled to an email account. So we're going to run that through the approval process, which is actually going to be very straightforward, it's just going to do maybe a look up to see if you are still in the database, if you're still an active employee, and if so, then you are considered to be approved.

And if you're approved, then I'm going to have a connector from my identity management system that goes out into the directory. Remember I talked about where we store in directories in the previous section? This is where we're going to do that.

We're going to store your information into that that directory, and that will then give you those access rights. And some cases there might be an API call that happens here, but this is one way that it happens. So this user now has gotten their email account.

Another thing that happens, let's say for this other account, maybe it's more sensitive information. So the approval process is more complex. We're going to start here and we're going to say you need to get an approval by this person simultaneously by this person.

Or we could make them so that it's one or the other. You could build this into the workflow approval process. And then once I've received all of those, then we're ready to go ahead and provision the account for you.

So this provisioning, this creation of the account flows all the way through the system. And you notice it's based upon the role, it's based upon the account, it's based upon the approval workflow process. And then we store it in the directory, and now the user has access.

Okay, so that's one use case. Let's go through a different use case, different scenario. Here's an existing employee who says, "I've already got access, but I need more access.

I need access to another system over here that I don't. ". So we're not going to get them through the HR system, but we're going to put a GUI, some type of web interface where this user can go and request new access rights.

And when they make their request, it's going to map into the same process we have here. That's the nice thing. We want to reuse the same infrastructure to do all of this.

So the request comes in. It may map to a role or not, since it's a single one-off request, probably it's going to skip the role part and it's going to map to a particular account. And that account still must be approved, still has to go through the regular approval process.

And once it's been approved, then we're going to give him the access rights that he's asked for. Or if not, then we're going to say why. So that's the second use case.

Now, the third use case, let's say we have an employee who now has left the organization. Could be on good terms, could be they retired, could be on bad terms, that they got terminated. But this person is no longer an employee.

Now, what I need--I've created a system that efficiently creates access rights. I need a system that is even more efficient at removing those access rights, because that's where the security exposure exists. So this provisioning process; now, I need a de-provisioning process to untangle, unwrap everything that I've done.

So that will indicate in the HR system this person is no longer employed here. And that will send a request into our identity governance system, which will know all of the accounts that this user has. It will know that we created an account for this guy here and here because this was the system that created it.

It's the one system of record that knows all of that. By the way, if I don't have this kind of infrastructure in place, if I've just gone and created each of these accounts separately, I don't have any one single source of truth. It means I have to go audit every single one of these systems out here to figure out where does this guy have access rights and how can I remove all of those.

With this type of system, I can efficiently provision, and now I'm going to send the de-provision request in to here. I don't need to approve a de-provisioning request in most cases, so it's just going to go and delete all of the access rights that this guy had. So there's three different use cases that you can see where the ability to provision and then from a security standpoint, even more importantly, the ability to de-provision has become very important.

Okay, now we've covered the identity management, the provisioning and de-provisioning part of the process. That's the administration, the first of the As. Now we're going to take a look at the next to the authentication and authorization portions of the four As.

So I've added to our architecture diagram an access management component. So identity management is kind of this first one. Access Management, if we're talking about identity and access.

This is the access part. All right, let's take a look. Authentication.

What we're trying to do with authentication is answer the question, "Who are you? ". So I'm going to determine who you are based upon something, you know, something you have, or something you are.

That's traditionally how we do this. Something you know, might be a password, for instance, or a PIN. This is going to be something that stays in your head.

And you don't tell anybody else. Because, by the way, if it leaks out of your brain into another brain, then it's no longer authenticating you. That's the problem with knowledge-based authentication, is that we don't necessarily know if information exists in only one brain because it can replicate.

The next possibility is something you have. And the most common version of this that we see today is using a mobile phone, because pretty much everyone has one all the time. And your mobile phone is unique.

So if part of our authentication is requiring that you have that device and prove that you have the device because I send a message to that device, either an SMS or a push notification--something along those lines that lets me know that you are in possession of the device, or whoever is in possession of that device, will pass for a proof of you. And then something you are. This is a biometric.

This is a reading of some physical characteristic of you, for instance, a facial recognition or a fingerprint scan. Sometimes we use voice prints, but those are becoming more and more unreliable now with deepfakes and things like that. But the idea is-- something you know, something you have, and something you are.

The best authentication systems don't rely on any single one of these factors. They do what we refer to as multi-factor authentication. Multi-factor authentication says, for instance, I'm going to use something you have and something you are.

I'm going to send a push notification to your phone. It's only going to go to your phone. So if you have your phone, you can answer this.

And by the way, if you lose your phone, you tend to notice that. If you lose your password, you tend not to necessarily be aware of that--if someone else has copied your password. So the fact that this is a physical device makes it a little more secure in that regard.

And then I'm going to measure the physical characteristic. You're going to unlock it with your face print, for instance. Then something you have and something you are--that's two factor authentication.

And notice the user didn't even have to remember a password. That's even better. Still, if you're really security conscious, maybe you do all three.

So something you know, something you have, and something you are. But the trend is moving more and more towards this idea of "passwordless authentication" where we don't require the user to have this knowledge. Because the thing is, is that knowledge, like I said, can move around from one person to the other.

Also, people tend to forget and then they have to call the helpdesk and that's expensive to get it reset. So passwordless is really the way of the future, I think. And using multi factors is a way to mitigate the risk of not having any password at all.

And then another thing that's big in this space is this notion of single sign on. Let's take an example of what that looks like. Here's a typical use case.

Here's a user, and they've got three different systems down here that they want to log into. So they have to have credentials on each one of those three systems. And the IT organization is telling them you need to have complex passwords and they need to be different on each one of these systems.

So this guy has a problem. He's got to remember all of these passwords in order to log in, but he's going to log in to each one of them with his unique credentials. Now, a better solution to this is to say, let's go ahead and, in fact, have different passwords on these systems, if that's all they support.

But I'm not going to require the user to keep up with all of that. Maybe I'm going to require the user to keep up with one password, or maybe I'm going to use multifactor and maybe the password is or is not one of those factors. They're going to log into a single sign on system, so prove who they are once.

Then the single sign on system, whenever they go to log into one of these things, it will provide the credentials for that user, the password or whatever is necessary, in that case. The user is much happier in this case--they only have one thing they have to keep up with. Therefore it's easier for them.

And we get this rare situation where we're actually able to make security better and the user is happier at the same time. And for those of you that are about to object and say, "Yeah, but now someone logs into this system and then they can get into all the others. " Yes, but my answer again, multifactor authentication.

It's not just stealing this guy's password. I've also got to steal his phone and his face, so that makes it harder still. And the other thing is, if by doing it this way--by the way, this user is probably setting all these passwords to the same thing anyway, if you give them half a chance, they will.

So the idea that one password gets you into everything as it does with a single sign on system again, multifactor mitigates that. If you don't do multifactor, the user has already done one password. They just did it in a very inefficient way.

So I don't think it's compromising security at all. In most cases it's improving security. So that's answering the question, "Who are you?

" That's the authentication question. The authorization question: This is answering the question, "What are you allowed to do? " Can you do what it is you're trying to do?

Are you permitted to do that? So the authorization system might use a technology we call risk-based authorization, adaptive access. These kinds of things are the newer kinds of technologies where it's not just a simple you're in or you're out.

You can do this, but maybe only under certain circumstances. So I'm going to look at other aspects, other characteristics, like the location that you're coming from. Maybe you can do this transaction, but not from an unknown location because it's too risky.

So that's the risk-based part of this. I look at the request type, certain types of requests. So yeah, it's low risk.

You're looking up your bank balance, not a big deal. You want to transfer funds, bigger deal. So I might put more restrictions in that case.

I might restrict on amount. You can transfer funds up to $1,000, but if you want to do more than that, then we're going to put extra kinds of controls in place. You also might look at frequency.

If you try to do 30 of these transactions in a day and normally you do one a month, then I might trigger with something like that. So the idea that authorization then is looking at now a complex algorithm that goes into all of this, and that's how we consider, based upon who you are, what you're allowed to do. Are you allowed to do this or not?

Okay, now we've talked about access management. There's a special case of access management, we call privileged access management, or privileged account management, or privileged user management or privilege identity management. PIM, PAM, POM.

. . it goes by a lot of different acronyms.

I'm going to stick with PAM. But what we're referring to in this particular case are these types of users. These types of users are the ones who have very highly privileged access, the root level access to a server, the system administrator, the database administrator, the network administrator.

These are the people that have the keys to the kingdom. They can control everything. They can steal all of the data or they can keep all the data safe.

They can make the network secure, or they could open it wide open. We're putting a lot of trust in these people. So we need, if we're going to trust them, have additional verification to prove that they're doing their jobs the appropriate way.

Now, I'm going to let you in on a dirty little secret of IT. That is, we tell all of our end users that they should all have separate unique passwords and change them all the time. What happens in a lot of organizations is that these super sensitive accounts?

We do the exact opposite, even though that's where the greater risk is. This is what we end up doing in so many of these cases. So let's say we have three of these super users, these privileged users, and they need to log in to these three different servers.

Well, if it was only three, you probably wouldn't do this. But imagine it's 300 or in some cases it could be 3000. So imagine multiplying this out.

And so what we do is say, you know, these three folks have to keep up with the account name and password for all of these different systems. Let's make it simple. We're going to set them all to the same thing.

All of the IDs are root and all the passwords are exactly the same thing. Well, that's going to present some problems for us. Because now what happens, it's easy for these guys, because they just have one password that each one of them have to remember.

And then he can log on to each one of these as he needs and on and on like this. So you can see how that works well for those folks. But then, let's say this guy leaves the organization.

Are we now going to change all of this stuff and retrain these guys and retrain the new guy that comes in? How often do we change that? The reality is, we tend not to change it at all.

We set it and forget it. These guys hang on to it and that's it. Also, there's another big problem here.

That is, if something goes wrong on one of these systems, how do we know which one of these three guys did it? We don't. It doesn't identify.

They all three knew what that password was. So they can all point to the other guy and say "He's the one that did it. ' Okay, this is not the way to do it.

It's a typical practice. It's not the best practice. Best practice would be to put in a PAM system.

A PAM system will require that these users not log directly into the system, they log into the PAM system. And we're going to require things that I talked about in the previous section like multifactor authentication. So I really have them locked down.

They again, only have to keep up with one password, if that, in order, each one of them have one password and it's unique to them, not a shared password. Here's shared accounts with shared passwords. Here we're going to have shared accounts without shared passwords.

Now, each one of these systems, you'll notice down here, I've put in different passwords for each one of them. So these users do not have to know what those passwords are, they just have to know how to log into the PAM system as themself. Once they do, this guy logs in and says, "Okay, I need access to this system.

" It says, fine, I'll grant you access because you're a privilege user and you've proven that you deserve that level of access. He logs in, he's given the credential to log into this system. Actually, it's probably put into special software so he doesn't even have to keep up with it.

But he's given a password to log in. He does his stuff, and then when he's done, he checks that account back in. So he's checked it out, now he checks it back in, says I'm done.

What does the PAM system do next? It goes and changes this password to something else. So he now no longer has access.

He could log in before, now he can't. If he wants to log in again, he goes back into the PAM system and again gets authorization and we're able to to give him that same thing for all of these guys. So now we have multiple passwords that are constantly changing on every use or every time someone checks out that particular account.

That way, I also know at any point in time who did what. So if something strange goes on here, I'll know who did it, who had that thing checked out at that point in time. And then I might add a capability like this--that is, session recording, so that I can literally see every keystroke that they type when they're on that system and I can replay it.

And there's no question these guys know that they are being monitored and the systems they're on are being monitored. And therefore that level of verification causes them to be less likely to do things they shouldn't, and also gives us an audit trail so we can prove if something does go wrong, who did it. Okay, now, we've covered the first three days: administration, authentication, authorization.

And the fourth A is audit. That's where we go back and make sure we did the previous three As correctly. Now, how do we do that?

What we're going to look at an example here. Here's a user doing normal stuff. Logged into the system, does something, and for everything they do, we're logging that access.

We're logging the activity so that we can go back and see later. So that's normal. Now, here comes along another user with mal[icious] intent.

They go and create a new account. Let's say they have stolen the privileged account user's password, they create a new account. Then they go dump a copy of the database instantly.

Then they instantly delete the account. Now, creating an account, deleting an account, even copying a database is not necessarily a bad thing in and of itself. But doing those three things in rapid succession could indicate a problem.

So we're going to have a system that audits that, that looks at all these log records and looks at different activities and has policies and uses things like machine learning to spot some of these patterns. And we call this UBA- user behavior analytics or user entity behavior analytics capability. This kind of tool will help spot those kind of anomalies.

So that's it for the four As. If we're talking about what is known as Enterprise Identity and Access Management, we now have a fairly complete architecture. All of these things working together.

There's one other thing that I might like to add, though, to this. What if this is my organization and my employees might need to log on to a cloud provider, a SaaS system somewhere, or some other business partner system? Well, I need to extend what is this into other identity domains.

So what I need is a federation capability. A federation capability would let me log in to my system as my identity provider and then be able to access other systems as service providers, as an example. And I want to be able to do all of that in an industry-standard way.

And in fact, we have protocols, industry standard protocols that will allow for that. So that becomes the thing that allows us to get outside of our own unique domain and integrate with other security domains that might be out there, other identity domains. And all of this is what we then refer to as enterprise identity and access management.

or enterprise identity management. Another term that's coming into play here is workforce identity management. So "workforce" meaning I'm looking at my particular employees within my organization and then maybe extending out.

Another aspect to consider these days is CIAM: Consumer Identity and Access Management. And CIAM is basically looking at some of these similar capabilities. But some areas we need more and some areas we need less.

For instance, for our customers, we need to make it as frictionless as possible. So we're not going to do a lot of of proofing and things like that, if the account is not particularly sensitive. We're not going to do a lot of approval processing, maybe none, because I want to drop those barriers to entry.

What I need to be able to do is preserve privacy and other things of that sort. So slightly different concerns in each one of these use cases, but underneath it all, is the same IAM architecture. Now we have a kind of high-level reference architecture that we can apply to all of these cases.

So in this series, we've taken a look at some fundamental principles in the first three videos. In this video, we took a look at the identity and access management domain, and in the next video we'll look at endpoint security. Thanks for watching.

Before you leave, don't forget to hit subscribe. That way you won't miss the next installment of the Cybersecurity Architecture Series.