Azure AD Security Best Practices: Access, Controls, & Roles

Randy:

Okay. So here is my big picture slide. We've got Azure Active Directory, and we've got Azure. We've got pieces of Office 365 shown. Of course, not going to show it all. And I purposefully drew the line through the et cetera block of Microsoft Cloud products through there because there's other stuff that is Office 365, and there's other stuff that's not specifically Office 365, but is part of the whole Microsoft Cloud offering.

And the key point here, of course, is as we would expect, and hopefully this isn't super new to anybody here, Azure Active Directory is the central place for identity, and at least the beginning of your access model for all of these products. Now, I want to make sure everybody gets what I mean when I talk about Azure and Azure Active Directory. So Azure AD is users and groups. It is the directory for the whole Microsoft Cloud. Azure is, we're talking about virtual machines and containers and storage accounts and all of the other things, I think they add about five new Azure products every week. Right, Tim?

Tim:

It seems like it. And certainly, the number of services behind it grows dramatically.

Randy:

Yeah. But that's Azure, and that's the difference between Azure AD and Azure. And even if probably a lot of small businesses think they're just Office 365 customers, but in reality, they have an Azure AD, right? So that's where all of the users and the groups are stored, in addition to a few other things. But if it has to do with authentication and access, it is either in AD or it begins there. So why do I say it begins there? Well, your groups are in AD, but your roles and your permissions assignments, of course, are going to be in each one of these individual offerings. Okay. By the way, you've got a fan out there. Chris says, Tim Sedlack like is so smart.

Tim:

I appreciate that! Thanks, Chris.

Randy:

Yeah, I thought it might beef up that self-esteem there a little bit, Tim. So now let's talk about privilege to access. This is the type of authority that administrators have. Right?

Randy:

Now, what you might have noticed is that I moved Azure Active Directory over here to where all of our other offerings are, because you've got admins for doing stuff in... well, let's put it this way, you have to administer Azure AD, just like you have to administer things in Azure, Exchange, Teams, and all the rest of the Cloud. And that's what we're going to drill down into, is how does this privileged access work? There's something else that's kind of interesting here. So, I'm just showing an admin here. I'm neutral as to what the technical security principle behind that admin is.

Now, yes, most of the time, that admin that's doing any kind of administration on any of these Cloud offerings, is going to be a user over an Azure AD. But it does doesn't have to be. It could also just be an external account, including some Microsoft account. You could literally make billy@outlook.com, your personal email address, and the account that is behind that personal Microsoft email address, that Microsoft account, an admin anywhere in here. Right? And I think that's a key thing to remember. It blows my mind, Tim, by the way, when I'm in there adding members to a group, and there are external users that I've already invited into the organization to see a file, right there beside my IT admins, like Barry. Like literally you, Tim. If I share a file to you, tim@beyondtrust.com, I'm going to see you in there.

Tim:

Right.

Randy:

And the next time I look at it, I need to see, is there a really nice visual cue to show me you're not an internal user, an internal employee.

Tim:

Right. And I don't think it does identify it for you. It's not as bad as like a GUID, or a GUID, depending on your pronunciation, but these external parties that participate in your Azure Active Directory, they're not segmented as you look at those users in their applications that they're using. Right?

Randy:

Yeah, exactly. Mike says, does it have to be a Microsoft account? If you set up... let's just call them trust relationships, because there's different ways you can do it, with other identity providers or other Azure AD tenants, other Azure tenants, then no, Mike. Okay.

Tim:

And Randy, correct me if I'm wrong. Didn't Microsoft extend their IDP or identity providers that you can create a Microsoft account with? I know originally it was like outlook.com, live.com, but I think they extended it. So, you can do things like, tim@gmail, and make that a Microsoft account.

Randy:

Yeah. Yeah. The name can be any email address.

Tim:

Right.

Randy:

But it's still a Microsoft account. And the password, there's not a trust relationship over it. So yeah, it's weird. I can have my randyfranklinsmith@gmail.com email address. I can get a Microsoft account called that, but there's no trust over there, to Gmail or to Google. The password is there.

Tim:

Yeah. And as a former AD guy, when I first saw that, I thought, wait, something's wrong here.

Randy:

Yeah. It's a complicated world nowadays, that's for sure.

Tim:

Yeah.

Randy:

Okay. So, here's the thing. Microsoft has implemented the basic tenants of role-based access control throughout all of their cloud offerings. And they do this through what I call trustee scoping, object scoping. and actual roles. So, we're going to drill down into what I mean by each one of those. The trustee is the person, is the administrator, in this case, because we're talking about privileged access. So, the trustee is the person you are entrusting with an entitlement, with authority over other objects, which could be other users and groups, since we're talking about Azure AD most specifically today.

Randy:

So, trustee scoping. That is primarily accomplished through groups and Active Directory. So, if Barry's on the help desk, we want him to have password reset authority over Tom, Dick and Harry. This is just like everything else you've ever learned, whether it's OnPrem AD, or if you go back before that, even other stuff. Don't give permissions and entitlements to individual users, do it through a group, for all kinds of reasons, which I'm not going to get into today. Hopefully I'm preaching to the converted on that. And that's what I call trustee scoping. It's accomplished primarily through groups and Azure Active Directory. You put users in groups, then you give those groups entitlements, here inside of Azure, inside of Exchange, Teams, and so on, or even, in the case of administrators, authority over other users and groups in Azure Active Directory. Let's see here.

Tim:

Randy, you used a word there that is very Cloud specific. And I know that I get the question occasionally, what's the difference between permissions and entitlements? You can think logically that they are effectively the same, but entitlements are the cloud method of being very atomic in what you can do in each one. So, if somebody hears that word, entitlement, you can think permissions, right?

Randy:

Yeah, yeah. I would say so. I mean, now we're playing semantics games, right? Because I think of entitlements back, even with entitlement management. Even in the OnPrem environment, we are reviewing somebody's entitlement. I view it as a less technology specific term that somebody has. It's at the business level. Whether that's through a group membership, or a permission assignment in AD, their role assignments, there's different nuts and bolt ways to do it. But anyway, that's what I meant by entitlement. But yeah, at the end of the day, permissions are probably the cleanest and most direct analogy. Absolutely.

Okay. Let's see here. Now, are there other ways to scope users or trustees in some of these applications? Yeah. For instance, like Dynamics 365, the CRM from Microsoft, there are. I don't remember if they're called roles or groups, but you can put users in them. And here's a great example, SharePoint. SharePoint has SharePoint groups, and you can put users directly in a SharePoint group, or you can put users in an Azure AD group and then put that Azure AD group in a SharePoint group.

So, there are other ways, or additional ways to accrete trustee scoping in these other applications. But I would say there's a lot of good reasons to try to pull all of this up into Azure AD. To me, Tim, this is a lot like local groups on Windows. Let's go to OnPrem, where we just have windows, active director domains. And we've got Windows Servers, and maybe we've got SharePoint or SQL Server. So, you can have local groups at the Windows Server level. You can have the equivalent of groups in SQL server, and you can have groups inside of SharePoint. And we've always said that it's smarter to pull all those groups up into Active Directory, right?

Tim:

Right.

Randy:

So that you can go to a user and say, show me everything this user has, and I don't have to leave Active Directory.

Tim:

Yeah. It's smarter to do it that way. I know there are use cases where you need to use the SharePoint groups or the SQL groups, but to simplify security, pulling those up into groups and doing your permission, your OnPrem permission management through groups and the application and permission to groups only, and then putting people in and out of groups, is really the way that it's been done because it's simple, it's easy to audit. It's what we do. And up in the cloud, you're getting into how we do that here too.

Randy:

And my basic tenant is, your rule of thumb, our basic instinct should be, do it with groups up in Azure AD. And again, but then if your Exchange admin says, yeah, but I don't have authority up in Azure AD, I'm not an Azure AD admin, it's the same solution that we said back in the OnPrem AD days, create an organizational unit that allow and delegate the authority for you to create and manage groups in that OU, which you then use in your application. And we're going to show you, you can do the same thing here in Azure AD. The words are just different.

Tim:

Yeah.

Randy:

Speaking of the words. So, folks, I mentioned organizational units. So, if you know, one of the primary ways... organizational units are multipurpose in OnPrem AD. But one of the key ways that you use OUs and OnPrem AD, is to bunch a bunch of users together, and then delegate authority over those users to some sub admin. In Azure AD, you have not organizational units, but you have administrative units. And over in Azure, you don't have either one of those, you have resource groups.

And let's zero in on something really quick, and that is that word group. I wish they had never used that, because don't think of a list of users. A resource group is more like a folder. Yeah, it's a folder. Just think on a file server, we arrange files into different folders, and then we assign permissions at the folder level. Okay. Well, in Azure, you've got virtual machines and storage accounts and all these other resources where you group the... oh, see, I just used the word. You collect them together into, not a folder, but a resource group. And basically, folks, at a sufficiently high level, an organizational unit in Active Directory is very similar to an administrative unit in Azure Active Directory and a resource group in Azure.

Tim:

I really like that file analogy, Randy. That's one I'm going to use.

Randy:

Yeah. And we could just add that to the list. It has very much the same purpose as a folder on a file server. Exactly.

Tim:

Right.

Randy:

And just think if we had named all these folders. And we know, okay, in Microsoft Cloud a folder is this, or an administrative unit, or something like that. But at any rate, that's the deal. Now, here's something that's interesting, by the way. They are extending the use of administrative units to other things outside of Azure AD. So, for instance, in Exchange Online, recently, they've now added support for delegating authority over Exchange, specific things about your mailbox, and the fact that you're a recipient and things like that, to administrative units. So administrative units are not... they do bleed over outside of Azure AD specifically. I don't know if that's going to be repeated in other things like Teams or Power BI, or other stuff in Microsoft or not. It may just be the fact that in Exchange, a lot of the stuff is stored on the user account in AD.

Tim:

Right. And you've probably seen those. If you look at AD and look at a user account, you see these Exchange properties. And you're thinking, wait a minute, I've got Exchange online. This should all be up in the cloud.

Randy:

Yeah, exactly. All right. So that's administrative units and resource groups. Those are ways of doing object scoping. Then we've got what are called roles. Now we have Azure AD roles, in Azure AD, of course. In Azure, we have Azure roles. So, terminology thing here, Azure AD roles are not Azure roles. Those are two different things. In Exchange, you have management roles, which can be further subdivided, I think, into administrative roles and user roles or something like that.

Tim:

That's right.

Randy:

And then you have other types of roles in other Microsoft Cloud offerings. Let's just put it that way.

Tim:

And Randy, right there is where people can get confused, because there's of course the Azure AD administrative groups, and all the permissions associated with that. And then you go down to Office 365, and there's a level of administrators there. And then you go down to a component of Microsoft 365 Teams, and you've got the administrative group there and all the administrative entitlements there that you need to think about. So, it really cascades down and becomes a bird's nest very quickly.

Randy:

Yes, it absolutely does. They've made some improvements. Thankfully, I was able to remove some stuff that I've had to talk about other times when I got into the subject with the classic administrative model, as they used to call it. But be that as it may, we've got roles in Azure AD, we have roles in Azure, in Exchange and in other things like CRM and so on. Now, there's a good bit of commonality in the overall concepts. Though oftentimes a role is limited... when we use the word role, oftentimes we're kind of just using it in terms of the set of permissions that that role gives you. So, here's a role, user management. So that doesn't allow you full admin authority over everything in Azure AD, but it does give you full control of users specifically. Or here's another one, password resetters. That one speaks for itself, right? So that is just the one permission that applies to the object type user, and the permission is reset password.

So sometimes when you talk about a role, it's just that. What are the permissions. A role does not necessarily specify the security principles that you are giving those permissions or the scope over which you have granted those permissions. So that is more a role assignment, or as Tim calls it, an entitlement. An entitlement would be that set of permissions, but also who has those permissions and what scope of objects they have those permissions over.

So let me give you some examples. Again, Barry is on the help desk for the US. So, a set of permissions would be very simple in this case, it's just password reset. And that would be the name of the role, password resetters. Then when we make that into a role assignment or a entitlement, now we're saying Barry is the trustee, the security principal. And the scope, if we want this limited to just end users in the US, then we are going to need an administrative unit with those users in it. But we can also assign roles at the directory level, or here I'm calling it global, because there are also roles in Azure, and in that case, you assign the role at the subscription level. In Azure AD, your global level would be at the directory level. With Exchange, it would be at the organization level. So, let's see here. What else did I want to bring out?

Tim:

And Randy, I'll just add here, that this is a really important concept here. You think of RBAC, role based access control, and you think we've been doing this a long time. But as Microsoft created Azure AD and this role structure, they really put a lot of effort into defining controls and allowing you as the administrator of your users and your data. How do we put those into constructs that we can use over and over and over, yet still allow people to make modifications, let's change the scope, let's add new objects. And I see you're going to get in and demonstrate this for us. So, I don't want to step on your toes here, but I do want to say, [crosstalk 00:29:06] is really important in Azure AD.

Randy:

Yeah, it is, for sure. I think this is a good time to actually get into the actual technology and show you what we're talking about. Here, we're in Azure AD, and we're looking at the roles. These are all the predefined roles that come with Azure out of the box. By predefined, Microsoft calls them built in. We could create a custom role, and you see, it is simply a matter of giving it a name and then choosing your permissions. And look how many permissions there are just an Azure AD. And notice that we're done. Have we assigned any members this role? No, nor have we assigned any scope for this role. And that's because it's just a definition, that's saying, okay, here are set of permissions that we could put a name on and reuse. That's a good point, that Tim had brought out, we can reuse this. But these roles already come out of the box. And I think we've got one called password. Yeah, password administrator. And let's look at the... I'm trying to simply see...

Tim:

You're looking for the definition, aren't you?

Randy:

Yeah. Oh, check that out. So, they don't just show you the specific assignment. I mean, not assignments. They don't show you...

Tim:

There you go.

Randy:

Yeah. There it is. Yeah, role permissions.

Tim:

Yeah. There you go.

Randy:

Awesome. Yeah. Funny, it takes a lot of role permissions to do that, because there's all these read things that you need. Okay. So yeah, there you go. Now again, no assignments until we actually do that. And we'll show you that in a second. Now, that's roles inside of Azure AD. I won't spend as much time on this, but let's just quickly show you roles over in Azure. So, this is where we have our virtual machines and stuff like that. And we will go to a resource group and pick that one, that resource group. And then we'll look at the role assignments on that resource group. And we could add, or we could look at... there we go. Yeah, here's all the roles over in Azure. Nothing to do with Azure AD roles. That's the key thing I wanted to show you. And then we have the same thing over in Exchange. We have administrative roles in Exchange, and I forget some of them, recipient, admins and...

Tim:

List administrators. Yeah.

Randy:

Yes, exactly.

Tim:

Yeah. And right here, what you're showing, Randy, as you go down these lists of permissions or entitlements, there we go. If you go down this list, you see things like Arc, Microsoft Arc. Fairly, relatively new service. And as Microsoft adds services, permissions are going to appear in here. And what's confusing, is what gets assigned by default. I don't know. So, I see why people are concerned and scratching their head and worry, especially if you are an IAM Active Directory guy, and you think, oh, I know Azure Active Directory. I know Active Directory, so I probably know Azure Active Directory. It's not the same beast.

Randy:

Exactly. And here's one you could relate to, virtual machine contributor. What a funny name, contributor.

Tim:

Yes.

Randy:

Of virtual machine. But it lets you manage virtual machines, but not things like getting into the VM itself, or even the virtual network that it's connected to. And that's another, that's a built in role. But this is all stuff inside of Azure itself. All right. So going back to our slides then, there, we just showed you really quick, roles inside of Azure AD and roles inside of Azure. And if we had time, we could go over to Exchange and Dynamic CRM, and you're going to see roles there over and over again. But basically, the role is the set of permissions. Then when you assign the role, you're choosing who and what scope that you're giving that authority over.

So, let's talk specifically Azure AD roles. These are going to be primarily permissions or things that you would do to users and groups, because those are the main objects in Azure AD. And then your security principle can either be a specific user that you give a role to directly, and that user can be internal or external. Or, and this is better practice, a group. So, you can create a group in Azure AD, mark it as security enabled, and then you can assign that group roles. And here's the two scopes in Azure AD, the entire directory, so analogy, OnPrem AD that would be the entire domain, or administrative unit, I.e., organizational unit, if you are coming from the AD world.

Tim:

So not a lot of choice there, right?

Randy:

What's that?

Tim:

I said, not a lot of choices. It's either top level, or you define an administrative unit.

Randy:

That's right. And administrative unit. What is the big difference? One of the big differences between AUs and OUs? OUs are like a folder hierarchy. You can have sub OUs and sub OUs, and it's sub OUs all the way down, whereas administrative units are flat. So, there's no nesting. There's no parent AU. That's right.

Tim:

That was really confusing for me, going from AD to Azure AD, is the relatively flat structure of Azure AD. And I'm thinking, wait a minute, I want to create parent child relations here. And that's done through administrative units.

Randy:

Yep. It's the way it is. We don't have that hierarchy. And you don't have it in Azure either. Right? You've just got resource groups, and they're flat also. All right. So, let's do this step by step. Let's demonstrate delegating a small chunk of administrative authority in Azure AD. Our goal, to state it again, is we want the US help desk to have the authority to reset passwords over the end users based in the US.

So, here's what we're going to do. We're doing all this in Azure AD. We're going to create a US help desk group. We're going to sign members to that group. We'll just put one in there. We'll put Barry in there. He works on the help desk. And then we are going to create an administrative unit to hold all the end users based in the US. So, we'll just call that thing US, and then we'll add some people to it. And then we're going to assign the password reset role that will then link that group, the US help desk group, to the US administrative unit, with the specific permissions afforded by whichever role we use. And then we can review the access from multiple vantage points. And I tell you what, Tim, this is one thing that is an advantage over...

Tim:

Yeah, OnPrem.

Randy:

Yeah, the vantage point thing. So, the visibility, starting it from different places. Okay. Ronald asked a great question. Can an object be in more than one administrative unit? So, could we put Billy in both the US administrative unit, could we also put Billy in, this very same user account, could we put him in an administrative unit maybe for his department? I think not, but I haven't tried it, Ronald. So maybe we'll have a chance to try that. If you can, then, man, all a lot of assumptions I've made are off. But I didn't even think. My assumption, immediately, my unstated assumptions was you can only put it in one place, but that should be proven, Ronald.

Okay, let's do this. So, first step, we're going to create the group. Go to Azure AD, going to create a group. This is a security group. We need to do this so that we can assign it to roles. And the name is US help desk. And, no, that's what I wanted to do, is make it enabled for Azure AD roles. I bet you, if we... see, look at that, so you could make that an Office Microsoft 365 group, but then make it... interesting. Anyway, we're going to leave it like that. And we're going to create that group. This is one thing I really hate.

Tim:

Yeah.

Randy:

Is the latency. All right. So, I created a group, right? It's named US help desk.

Tim:

But it's got to be propagated throughout the directory there. Oh, there it is.

Randy:

There we go. Okay. So now that group is there. There's nobody in it. Let's make Barry a member. Maybe I don't know how to use a computer.

Tim:

There we go.

Randy:

There. Oh, yeah. Now we've got to wait.

Tim:

Well, one of the things I wanted to point out, Randy, is as you click refresh here, is as you were creating that administrative unit, or the group, I'm sorry, you had an option there to go create the role in that, at the time you were defining the group. And you can certainly go that route of going and creating a role, but you can also use an existing role.

Randy:

Yes, you can. And we could have made the role assignment and all that at the same time.

Tim:

Right.

Randy:

But I'm wanting folks to really understand, as you're aware, the objects and the relationship to each other here.

Tim:

Yes.

Randy:

So now we have a group called US help desk, and we've got one person in there, Barry. Does he have authority to do anything yet? No. Now, let's see here. And by the way, you can do group nesting. I didn't mention that yet. You can do group nesting. Group nesting is the way I should stress that, in Azure AD. So that's like OnPrem AD, right? Groups can be members of groups and so on. And there can be some real benefits to doing that, but we don't have that capability with administrative units, no nesting there. Okay. Mark says, did Barry already have to be a user in Azure AD? Yeah. So, I already had the Barry account there, Mark. Absolutely. Okay, so now our next step is we need to create that administrative unit. And so, let's go to administrative units. Whoa, whoa, whoa. I've got mixed up here. Look at that. We need to...

Tim:

Take your pick.

Randy:

Yeah. What is an administrative unit under a group? It must be a set of permissions.

Tim:

Yeah.

Randy:

Oh, that would be the administrative unit that the group is a member of.

Tim:

Yes.

Randy:

Got it. Okay. Or is contained, I should say. Let me get rid of that. That is not part of what we're trying to accomplish. Okay. So back here to the directory, we're back up at the root of Azure AD, go to administrative units. This is where we create a new administrative unit. And this is US end users. Let's make it a little more specific. I don't want to assign roles and all that right now. All right, so now we've got end users of the US. This is where we would add all the folks that work in the US. And so, let's say Brendan works in the US. Let's say Randy works in the US, and we add those.

All right. So, you see, we're getting closer here. The last thing we need to do is link this group, US help desk, to the administrative unit, US end users. And we'll do that. Now, there's a bunch of ways we could do this. We could go to the administrative unit, to roles and administrators, and we could add the US help desk group with the password reset authority, or we could also go here to the group and look at assigned roles. So which way do you want to do it, Tim? It's going to accomplish the same thing. That's the important thing. And I've grown up in the Windows OnPrem world, and so I think in terms of going to the object and defining who has access to that object. I don't know about you.

Tim:

Yeah. I think that's pretty common for us older, Active Directory guys, right?

Randy:

Right. And I mean, even Unix too, right? Files have permission.

Tim:

Right.

Randy:

So, we'll go to US end users, and let's go to the roles and administrators, and we're going to go into password administrator. And now we're going to add US help desk. All right. So now US help desk has the password administrator role over US end users. And just with the UI that you have right here, it's not easy to see coming from this point of view. So, let's say, who has authority to US end users? All right, well, I go to roles and administrators, and password administrator.

Well, it doesn't tell me who it is. I must go into that and then see the assignments. So, US help desk has that, and US help desk is a group. And I can click on that, and I can go to US help desk and I can see the members. So, Barry's a member. And this is where we can go from the opposite direction. We can go to US help desk and say, well, what entitlements does US help desk have? Oh, it's got password reset authority. Well, what scope over the US end users, what is that? That is a administrative unit. So, you see, you can go at it from both directions, in terms of vantage points. So, reviewing access. So far, we've... go ahead.

Tim:

Before you move on, Jennifer asked a really interesting question. She said, looking at this from an Office 365 perspective, she's relying on federation and the Azure AD sync back to OnPrem AD. Can I set up AAD to close some of these abilities? Because she doesn't want people going in and creating groups or roles or things that are in Azure AD, and she doesn't see them in her OnPremise AD.

Randy:

Yeah. I totally understand that. And yeah, it's just a matter of controlling who has your global entitlements. So, I'll come out and show you that here in just a second, as I'm finishing up. There's one more thing I wanted to show you, is what happens if we go from the user, the trustee, the administrator point of view. So, if we go to Barry, what is Barry's assigned roles? Isn't this interesting. Now, this is something you could never do in OnPrem AD. It's just showed up, that he has password administrator authority, but I never gave Barry password admin authority direct, did I? No. I did it. It's got the concept of an assignment path. So, the fact that he's a member of the US help desk, shows that he has password reset authority over US end users. And that is something that you would never see without clicking down, down, down, down through it in classic on [crosstalk 00:50:35]

Tim:

On the OnPremise AD. Right. Right.

Randy:

So that's good. Okay. Now, just remember that we're only talking about Azure AD here. You've got other stuff in Azure, and remember that you have Azure objects, but then some of those Azure objects have a whole security world inside of them. So, an Azure SQL database is an object that can be in a resource group and all that. But then, don't forget, you can have user accounts at the Azure database level that have absolutely zippo, nothing to do whatsoever, with Azure AD. They are SQL user accounts, and virtual, and they might have admin authority to that database inside of Azure SQL. But you're on a different plane at that point.

Same with virtual machines, you've got a Windows or a Linux system. Let's just talk about Windows. There's three different possible ways to log on to a Windows virtual machine, depending on how it's set up. You could log on with a local account inside of Windows, Azure AD knows nothing about that. Or if that computer is Azure AD joined, or if you've deployed Azure AD directory services, then you can log on to that Windows account with your Azure AD account. Or remember, you can still set up domain controllers or link back to OnPrem domain controllers and log on with a classic AD account to a Window system, if you have joined it in the classic AD join way.

So, there's complexity there, and that's just Azure, not even Office 365. Also just remember that there are other possible routes of getting admin authority through subscriptions and enterprise enrollments and stuff like that, in the whole Microsoft world. And that's just talking about enterprise enrollments. It's a way to bring multiple Azure tenants together under one top level of control. Here's a couple good articles. But now that you've got an introduction to all the pieces at play here, how do you manage this? How do you report on it? Well, Tim, that's where you come in. And before we do that, I just want to ask the audience a couple other questions. Actually, this comes after you, doesn't it? So, I'm going to close that poll for a second. And let's go on to you, Tim. And after that, we will do our last poll.

Tim:

All right. Let me share my screen here. Brandon, help me out?

Randy:

Yeah. We're going to make you the presenter right now.

Tim:

All right. Thank you. And I'm going to have to make sure I pick the right screen. There we go. And I will get rid of that. All right. Y'all know who I am, so I will move on from here. So, I put this in. I just love the picture of the dog. This is typically the response when somebody moves to the Cloud. They think, oh, things are going to be easier. I can share more. I can do more. But as you were pointing out, Randy, there can be some unintended consequences. And the worst thing you can do is invite somebody you don't want to the table to participate in your Active Directory, your groups, your permissions, your entitlement, so that they have access to data that you don't want them to have access to.

So, hackers love the Cloud, because it's easy for them to get at data, because people misconfigure things all the time. Now, one of the things you pointed out was managing users, managing... if you're thinking from an OnPrem Active Directory basis, the Monterey group, Randy, your group, I bet your OnPrem Active Directory was fairly small. But one of the things that happens in the Cloud is, of course, automation. And a lot of those resources that you were talking about, Randy, will get their own identities under the covers.

So, the number of permissions goes up significantly, and you showed a good listing of permissions as they get added. And I made the point over and over, that Microsoft's adding services all the time. There's a set of permissions associated with those. So those number of permissions has grown dramatically, and the number of accounts that you're managing has also grown significantly. So, multiplying those, you see this explosion of management, of how do I manage all these people? How do I make sure they have the right permissions? So, I understand why you had so many people sign up for this, because it can be fraught and very confusing.

And there is, of course, the visibility challenge. One of the things you didn't talk about is, within a corporation, say a company, oftentimes there's multiple subscriptions. Sometimes, one group goes and does something with Azure AD off on their own, and you don't know that they've signed up for this service and therefore these permissions get added. And if you don't have visibility into everything, it can be a way of opening yourself up to hackers, or even coming in and just grabbing stuff and then holding you for ransom.

Now, we've been focused on Azure Active Directory. I know that's your sweet spot, Randy. But as we talk to customers, most customers have more than one Cloud. In fact, I saw a question from one of our attendees. He said, well, what if I have Google? And what if I have AWS? How do I do that? If you're managing Azure AD, AWS, and others, trying to do that from one central place, and trying to normalize between what they say in AWS or Google, versus what they say in Azure, you have to do a little mental translation, what I call swivel chair management, where you're going from your AWS console to your Azure console. And are the concepts of groups and roles the same? It can get very confusing, and I understand why people worry about this.

This is a statistic from Gartner that is a little concerning, but they've got proof that through 2023, the number of Cloud security failures that we have is almost exclusively the customer's fault. That's misconfiguration of your users, your groups, your roles, who gets to access what. And we get that it's confusing. And I always want to point out that it doesn't mean that magically, in 2023, this all goes away. They say with the current tool set, the current automation that we have, they expect at least through the end of 2023, that most customers will... most of the security failures we see will be caused by customer's misconfiguring or allowing something that they shouldn't allow.

So, we at BeyondTrust, you may be familiar with us, we used to have this wheel. Some people call it the buzzsaw. We kind of filter down to specific areas here. We're well known market leaders in the PAM space, and that kind of fits within the first three spokes. But we've been queried by customers, pushed by customers, if you will, to get into Cloud security management, to help them with exactly the problems that we've been talking about.

So, as I said, for those that are familiar with BeyondTrust, we're well known market leaders in the privileged access management space. But what I really want to talk about is Cloud security management. So that's the pillar that I run here at BeyondTrust. And one of the things we want to solve is kind of that multi-cloud visibility. And I'll tell you, Randy, the first time I put up this slide, somebody pointed at me and laughed and said, aha, you made a mistake, there's two Azures there. And that is absolutely on purpose for the reason that I talked about before, that there are often multiple subscriptions within an organization, and sometimes they're not aware of each other, and sometimes they don't have the visibility of working between different sections of Azure. It's not always harmonized and normalized up to a single management control plane.

Randy:

For sure. Multiple subscriptions are one thing, but then you end up with multiple Azure active directories. And so that's like multiple domains and domain sprawl, a whole problem that we're kind of seeing all over again.

Tim:

Yeah, absolutely. So, it's not uncommon. And I wouldn't be surprised if some of our attendees today have more than one Azure AD. So, what we have today is Cloud Privilege Broker. So, this is a new product for us. We just released this in January, just after the holidays. And the whole concept here is to kind of bring everything together and give you some guidance as to how to improve things.

Of course, it's a cloud-based product, SaaS-based product, that fully audits itself. Does this idea of continuous discovery. So just like you pressing that refresh button, Randy, we're constantly going out and looking, Hey, any new users? Any new groups? Any new roles that we should be aware of? So that we get a good understanding and can give you recommendations on how to get to the principle of lease privilege. One of the things we say is, let's get rid, let's get to zero standing privileges. So, a user is a user is a user, and when they need something special, you can assign them something special. So, what I'd like to do, is give you guys, if I'm sharing my screen... Randy, can you confirm you can see my beyond insight?

Randy:

Yep. You look good.

Tim:

Okay. So, I've logged into Cloud Privilege Broker here, and we've tried to make it purposefully very simple and high level. We go through and we parse. Let's stick to Azure. We'll go through and collect all those roles, collect all those users, collect all those groups, and understand, what's a human, what's a machine account, and pull those things down, build our own internal kind of graph of what's going on, and then assign risk scores based on what people have and what they've used. And that's critical for us, is if somebody's assigned a permission and not using it, that's a security hole, don't you think, Randy?

Randy:

Yep. There's a bunch of issues here. But for sure there, yeah.

Tim:

Yeah. So, we're assigning risk on an individual user level, and then boiling that up so that we keep track of what's going on in your environment. And you get kind of a quick view of how I am tracking over time. You'll see, as we process that graph of users and permissions, we're going to make some recommendations for you. And we call them recommendations, because today it's not the easy button. We have to be very cautious with Cloud, because as you push out new permissions, you want to make sure there's no unintended consequences. So, we make recommendations.

So, one of the simple ones is MFA. Here's an account where John Doe, he didn't have MFA assigned. And we'll tell you how to go enable that. This is an AWS recommendation, but we'll tell you how to go enable that, and then you can go mark as completed. One of the things I did earlier was, as part of the recommendations we do, we'll see users with a ton of permissions. Here's somebody in Azure. It's a Cloud monitoring service account. So let me go in and see what permissions they have. So, they've got permissions. And what I'm recommending here, what I'm showing you here, is these are unused permissions. So, we've combed through all the activity that's happened on this user account, and then seen what they've done. And if they're not using permissions, the idea is let's pull them. And so, here's the list of permissions assigned to this role that haven't been used in the last three months. So, we'll go through and give you steps.

Now here, under enable MFA, is a simple check box. But here, where we're saying you should go remove some permissions, we'll give you an actual custom role definition that you can copy to your clipboard. And you'll notice there are a couple of policies here, because this user acts in a couple of different groups and roles. So, we give you the recommendation. You can copy it out of here and paste it directly in. The idea is that as we get more and more confident over time, and we use more of our AI, that we'll be able to move ahead and allow you to use the easy button and say, I trust you, go ahead and make that change. But early in the product, I really want us to be more in an advisor role, because we don't want to be responsible for telling you, you didn't know about this exception, so therefore you did something wrong. So let me go back and close this panel here.

One of the things I do like to show people is, if we're focused on Azure, I can go and look by particular principle types. So, I can say, just show me service accounts in Azure. And if they've got too many permissions, I see this, the Cloud monitor piece that we looked at earlier is very high, and the mainland team, they have a set of permissions that I can go see again. It looks like a lot of IAM permissions that they got assigned, that they really aren't using, so it's probably safer if I go and resolve that and remove that. You also have the capability here to ignore that recommendation. So, I'll get rid of my filters here, and go back to my full list of recommendations. Let's go back up to the top.

The simplicity of what I've shown you here, kind of understate what's going on in the background. We've tried to make this purposefully simple and light. You can view all your recommendations. You can see what other people have done to fix recommendations. So, here's a user, Adam Smith, that the administrator went in and set the enablement or enabled his multifactor authentication to be on. I can show just the system that went in and completed those removed permissions. And for those that really want to drill down and know more about what it's going on, we can go into a system activity dashboard, and we can show you where people are logging in from and using Cloud Privilege Broker to understand their environment, look at who's over privileged or underprivileged. I can see who the users of Cloud Privilege Broker are.

So, it's a little bit more about care and feeding of Cloud Privilege Broker, but we want you to have the capability to know who's in here, and who's doing things through Cloud Privilege Broker. You can go in and create your own custom dashboards. We have a bunch of different tiles, and we'll be adding more over time. And so, this runs inside your... so this is a SaaS application, and again, back up at the top, the idea is to kind of build that graph. Know who's in your environment, know what they're capable of doing, but almost more importantly, know what they are using, so that you can get even more secure by removing unused permissions, and shrink that attack surface down.

Really simple to connect to your environment. You create a Cloud connector. And personally, I'm not going to go create one today. You can see some connectors here. Let me change my screen size here. I'll look at this connector. I know the one that failed a scan is on a user that is no longer permissioned to do this. So, you go in, you create the connector, you provide the client secret, you run a test and then you save your cloud connector. And it'll go out and it'll start to do that parsing. It's going to slurp down the thing that I talked about, users, groups, roles, understand who's doing what, where, what permissions are they using?

So, all in all, we want to help customers get a better handle around the permissions or entitlements that are out there in the Cloud. And that visibility of understanding who has access to what, can really give you some insights into how to reduce that attack surface. So that's kind of the end of my demo and brings it back to our poll. Randy, would you push out that poll?

Randy:

Yes, absolutely. So, there you go. If you'd like to contact BeyondTrust for a demo or anything else. I've got some good Q&A here to cover while we're at it. And this is what I was wondering too. Doug says, what is the logging that tells us who did what, and when, and with what privilege? Tim?

Tim:

Let me see that. Where is the logging that tells us who did what? So, in Azure, and I always get these confused. One is Cloud watch and the other is Cloud trail. So, both Microsoft and AWS do a very good job of auditing everything a user's doing. And what we are doing is pulling down those audit logs, teasing out the, this GUID, going to this object GUID, using this GUID permissions, doing all that translating to build that graph. So, we're pulling that down.

One of the recommendations we have is a review permission. So, I showed you the remove permissions, there's also a review permission. So, say I have a Randy Franklin Smith in my directory, and I've enabled you to go use the Cloud, and three months have gone by and you haven't done a single thing in the Cloud, we ask you to review that user, rather than go remove all of his permissions. Because it's probably not a great thing to go just delete Randy Franklin Smith, because he's not using the Cloud. We want to make sure that he understands how he can get up there, what he can do, and what applications he has access to. So, I hope that answered your question.

Randy:

And I've got one. You'd mentioned, hey, it's showing us these users aren't using their permissions. How do you determine if they're using them or not?

Tim:

Those audits. So, every time you use a permission, just like when you went in and saw the event that said group created, of course, there's an audit event that says, Randy Franklin Smith created a group with this name at this time, from this IP address, using this permission.

Randy:

Okay.

Tim:

So, we look at those audit events, and slurp those up, and build that graph.

Randy:

That's fantastic.

Tim:

Yeah.

Randy:

Bob asked, what type of permissions is required in your tenant for this to a run? So, what kind of access are they giving you, right?

Tim:

Right. It's mainly read. Then that's why, one of the things that we didn't want to do, and I said we're kind of in an advisement role, we don't have right capabilities. So, this is all read users, read roles, pull down the audit events, kind of permission. So, we've got a fairly detailed list of the exact entitlements that we require to run Cloud Privilege Broker, but I will say we intentionally made it very light and very read focused.

Randy:

Right. For good reason.

Tim:

Yeah.

Randy:

Mike asks, so is this hosted at BeyondTrust only? So, he must be asking like what Cloud, where does this run, right?

Tim:

Right. It is a SaaS application, so it's not something that runs within your tenant. It runs at BeyondTrust. It's all secure at BeyondTrust. We've got a full Cloud security team that's running our Cloud Privilege Broker, and you get your tenant at BeyondTrust, and that belongs to you, and that is how we allow companies to use the SaaS app. So, it's very similar to other SaaS apps like this.

Randy:

All right. Troy asks, commercial and government environments in Azure too? So, I think, I'm not sure, it looks like a follow on to another question, but I don't see his original question, so I don't know if... Troy, maybe throw that question at us again with a little more context? Go ahead.

Tim:

I think the short answer for Troy is, we are not in government Cloud today. So that is something that's on our roadmap longer term. The first one is more commercial Azure, commercial AWS.

Randy:

Tommy asks... this is a great question, Tommy. How can you determine if you have multiple Azure accounts? And so, Tommy, that's like asking other questions, like how many VPNs do we have?

Tim:

Yeah.

Randy:

Even how many forests do we have? There is no single place you can go to get a list of all your forests, because they're completely independent objects. So, this is very much a policy, and a matter of having accounts payable, be able to show you all of the Microsoft charges. If you think maybe, you've lost control and don't know about some Azure or Microsoft tenants out there, you've got to use things like... well, we know where money is going out, right? So, what are all the credit cards or other transactions being paid to Microsoft and whittle it down from there.

Tim:

Right.

Randy:

Microsoft can't even tell you how many Azure AD accounts you have unless you've already linked them together.

Tim:

Right. And not to put too fine a point on it, but as the example I was using earlier, of the marketing department that subscribes to some Azure based SaaS app, if they put in their credit card and it's coming to the marketing department, I guess that ultimately it would come through accounts payable. So, there's probably some reconciliation there. But it's not always the case that you can find out that you have multiple accounts. It does take a little footwork but putting all those accounts in here lets you manage all those accounts from Cloud Privilege Broker.

Randy:

Yep. Let's see here. Dooson asks, is BeyondTrust licensed by the number of security principles in AD, or what's the metric?

Tim:

So, what we license by is the number of subscriptions. So, if we're talking about Azure, it's subscriptions in Azure, it's accounts in AWS.

Randy:

All right. Roy asks... let me just close that. Roy asks, can BeyondTrust products audit authorized administrator actions, for instance detecting if an administrator deletes an important object, can we trace who did it and when?

Tim:

Absolutely. We don't separate out the administrator access, and we show you all the access. We're keeping track of every action that people take against the directory, the groups, the roles, and we can present all that to you, and you've got a full audit trail. And just like I was filtering and sorting there, you can go in and say, show me what Barry did... There we go.

Randy:

Cool.

Tim:

Get rid of that. Today, the way it's done is looking through the system activity and... shoot, now I'm drawing a blank because there's a way you can... oh, there we go. Add the tile for log activity, and you can go in and see.

Randy:

I see logs.

Tim:

Yeah. So, you get the log activity, and you can parse through that. And I'm having some issue here that the tile is not... there we go. View all, there it is. So, you get this viewer, and you can go through, for the last 24 hours. Let me see for the last 90 days, what's happened on a particular machine name, and then it'll filter down. So, if you know the machine name, if you know other things about the event or the particular exception that happened, you can filter down to what happened on this machine, and then you'll get the event that shows you where that came in and what's happened.

Randy:

All right. We've got some more for you. Matt asks, can BeyondTrust help untangle our mix of OnPrem and online RABC, role based access control models? We'll be tied to OnPrem for many years to come.

Tim:

Yeah. Let me tell you, the sales answer is always yes. But Cloud Privilege Broker is focused solely on Cloud, but we can also help with the OnPrem side using our other products as well.

Randy:

Yeah. Now Troy says, can BeyondTrust Cloud access be used with traditional PAM tools? I'm not sure where the integration would be there. Can you think of a scenario?

Tim:

Well, yeah, because that is something that's on our roadmap, is how do we look at things like session management? Let's look, what's a live session, and can we put constraints around those. And console access, Azure AD administrative access to that console, can we broker that through Cloud Privilege Broker? That's one of the things that's, again, in our more longer term roadmap, that we want to help people put constraints around, so that they get to that principle of lease privilege and they can remove those standing privileges so that not everybody has rights to log into the Azure AD console and create groups and roles and follow the Randy Franklin Smith method of going through and creating user groups and roles.

Randy:

Justin asked, do you have a UK tenant?

Tim:

Today, customers are in US East. We don't have a customer yet in the UK. It's fairly easy for us to spin this up in different areas of the world. So shouldn't be a problem. We don't have one today, but we have the capability to do it fairly quickly and easily.

Randy:

Jamal asks, does your CPB integrate with CASB?

Tim:

It does not. This is a new product for us. I'm going to make a note of that, because I think that's a question that I will get more and more often. And while I don't have a great answer for you today, it's something I would like to investigate more and find out what's the best way to integrate with CASB.

Randy:

So, Ronald asked me, quite a while back, can an object be in more than one administrative unit, and my gut reaction was no, but I've got to test it. And guess what? Yeah, you absolutely can put an object into multiple AUs. And it is pretty simple. It's not as big of a deal as what you might have thought, it's just the permissions are additive, right? So, if we put Bob in an administrative unit called US, and we give the US help desk password reset authority over that. And if we also put Bob in like a department called marketing and we give somebody else authority also to reset passwords, just over marketing people, if for whatever odd reason we wanted to, then both of those would apply. Brian says, that's the beauty of AUs, they're not so restricting like OnPrem use. Okay, I'll go along with that.

Tim:

Yep.

Randy:

Let's see here. William asks about FedRAMP certification. Is that on your radar?

Tim:

It is on our radar. Currently, my thinking is probably towards the end of this year, maybe early next. BeyondTrust as a company, we have products that are FedRAMP certified, and it's expected that this will also get that. But as you know, as probably most of the people that work in FedRAMP know, you submit your completed application. So as this application grows throughout this year, that's more likely what we want to do, a fuller featured, next version will be FedRAMP certified.

Randy:

All right. Dan, quite a while back, said let me complicate this. We're a higher ed organization. We use Azure, Gmail. He doesn't mention AWS, I'm surprised. And Microsoft Office 65 is their centralized security management solution. And so, I mean, that's what you guys are aiming to do, right?

Tim:

Yes. But I need to be fully transparent here. Today, we do Azure and AWS. We don't do GCP today.

Randy:

Well, the other four customers that use GCP will be disappointed about that. No, just kidding. Let's see here. I'm sure I'll get some flak for that. I know there's more than five people out there using GCP.

Tim:

I have seen the growth of Google Cloud for production. It used to be the realm of development. Let's play around in the cloud, and we'll use GCP. It's cheap. It's easy. But I have seen even some larger customers start to get into production uses of GCP as well. So, it's something we have on our radar as well.

Randy:

Hey, Tim, Michael has a question about a different BeyondTrust product. I'll just let you look at that once we send you the data and get back to Michael on that later. Scott asked, with privileged access for our Azure AD, do you have to have Azure premium? I think everything we showed you today... Oh wait, you answered that question, Tim.

Tim:

I did. But I think it's worthwhile to give your take on it. My response was anything we talked about today, you don't require anything higher than... I think he said he had like an E3. As you move up and pay Microsoft more, you get more tools and more Microsoft expertise and intelligence around how they can help you do that. So, you get things like PIM, right?

Randy:

Right. Yeah. So, I totally go along with that. I don't think we showed you anything that you have to have premium for today. And that brings us to the end of our questions and the end of our time. Thank you very much, everybody. Thank you, Tim, for making all this possible, and we'll be sending everybody a link to the recording. But thanks for your time today, and we hope it was valuable for you. Bye bye for now.

Tim:

Thanks, everybody. And thanks, Randy.