[MUSIC PLAYING] Welcome. My name is Ian Stimpson. I'm a solutions architect based out of the UK. In this session, we are going to think like a security officer and delve into some of the strategies to protect against AD breaches and secure a hybrid environment. In the world of info security, there isn't, unfortunately, a magic bullet, but I'm going to reference some industry information, look at some areas, some challenges, and really provide you over the course of this session an insight in some of these areas with a few suggested remedies to help improve your security posture.
Now, I've broken this down into four key areas. We're looking at the cybersecurity landscape. We're going to then look at some of the challenges around Active Directory and Azure Active Directory, and then I'm going to introduce some protection strategies to help mitigate or alleviate those challenges. And then we're going to summarize with a few key points and a few key call to actions, and also some links to some industry information that I'll draw reference to as we go through this presentation.
Now, let's first start at the cybersecurity landscape. Now, this is ever changing, constantly evolving, and it really-- to keep up to date with what is going on is very difficult, and that makes it hard for a CISO, for a security practitioner, to really have the clear view of what is actually going on to make those well-informed decisions. Now, if you look back, we have from the early noughties, we had the worms, going into around 2011, 2012, there was Stuxnet, and then more recently, with the rapid evolving threats around ransomware and ransomware as a service.
So, I don't think a day goes by where we don't see organizations in the news that have suffered a breach. Now, I'm not going to call out any of those. I've not got a slide here that calls out all of the organizations that have suffered a breach, because I think we're all too aware of that. However, what I am going to call out is assume a breach. Now, this is quite a bold statement, but it's meant to be, because if you assume that you're going to get breached, that is a great point to start from. Now, you can say there are only two organizations in this world, those that have been breached, and those that don't know it yet.
Now, the assume breach mandate is not something that's new to very well known organizations, the National Security Agency in the US and the National Cyber Security Center here in the UK, where I'm from. Now, looking at the NSA first, they made a statement by-- well, a lady by the name of Deborah Plunkett made a statement that there's no such thing as secure anymore. They build their networks on the assumption that bad adversaries will get in. Now, that's quite a powerful statement.
But the advice from the UK, NCSC is very similar. Assume breach is one of the cybersecurity mandates that your organization should heed. So, here we go. There's a couple of statements here. The agency, the NSA, works as if it's been compromised, and the NCSC says assume breach.
Now, what I find interesting about this statement or these statements is there's actually 10 years between them. The NCSC statement is actually current on their website at this moment in time with a wealth of information to help you as an organization and look at preventing breaches from a security perspective. The statement from the NSA is actually linked back to an article on the Reuters website in 2010. So, this isn't something new. 10 or 11, 12 years have passed between these two statements, and they're still very relevant today.
So, this brings me onto the topic of the presentation here around securing Active Directory in Azure Active Directory. And securing hybrid AD is absolutely full of uncertainty and risk. Now, we can look at a few areas here around these challenges. Let's start with the administrative access.
One of the weaknesses that you could introduce into your organization is by giving too many privileges to your users than they need or for your privileged users or the administrators of Active Directory. You need to ensure that the privileges are right for the role that they belong to. And that is a really powerful way of ensuring that you limit that privilege to the role and to the individual and don't give out too much privileged access.
Following on from that is having consistency around your policies. Now, that could be policies for onboarding, your naming standards, what actually happens within the organization, within the directory service. Have the consistency to move away from any human error. And then one of the big call outs here is around the visibility. Absolutely need to know what's going on inside your directory service.
On the Microsoft side, they talk around the best practice around securing Active Directory. One of the key areas there is on the visibility. Know what's actually going on. And that then leads and feeds itself into the audit demands, be that SOX, PCI, GDPR. Again, you need to have the information to satisfy those audit requirements, which will ultimately help improve your security posture and secure Active Directory and Azure Active Directory.
And then when we move around into the disjointed practices, you don't want to be using more than once tool or more than one interface, let alone 3, 4, or 5 to administer your directory services, because that will lead to human error, lead to mistakes, and lead to potential holes in security of your directory service.
And then from an entitlement perspective, how often do you see an individual or groups of individuals that have been with an organization a long time, or even a short time, but their rights, their permissions are incorrect for what they do? This could be a user changing jobs, changing departments, moving around the organization, and gaining these additional entitlements as their job role changes. But who's actually then removing those entitlements? And these are all some of the risks that are introduced in the administration of Active Directory.
So, let's have a look at introducing some different protection strategies around this. So, the first one we're going to look at is around the policies and practices, ensuring that we can put down some consistency for our JML, our joiners, movers, leavers, to say when a user comes on board they have access to what is right for their role, and it's controlled by the organization to remove that human error and introduce the automation.
And then introduce and prevent scope creep. So, when a user does change, when their role changes and they move around the organization, they're not amassing additional rights and privileges and capabilities and roles and resources that are not right for what their role actually is. And what better way to do that than to have the approval process being driven by the business owner, by the asset owner?
So, let's have a look at this in practice, and we'll go through the different details here. So, I'm logged in here as a user on a help desk called Jen, Jen Barber. Now, she's what I would refer to as a Level 2 operative in our system. Now, she's had a mandate to create a new user, a new account, a new Identity. She can do this in the areas she's got the permissions to, which is the UK. And we're going to create a new user. Now, this new user could be fed automatically from an HR system or from a CSV file. We're doing it manually in this example.
So, here's my new user, Alex Rose, a very British name, from where I'm from. So, here we go. We've created Alex, and we can see that it's automatically gone first name dot last name as part of our policy standard. Now, it's allowed Jen to select the department that Alex is part of. Now, Jen is selecting the sales department. And similar with the office location, we can then select from a list of where this user is coming on board. In this example, we're selecting Bracknell. We're then going to set the password for our user. This could be randomly generated, but I'm going to log in as this user as we go through these demonstrations.
Additionally, it might be that this isn't a user account. It could be a service account that we're flagging up here, as well, or from a user perspective, a start date in the future. So, this is all details that we can put into the onboarding process, including in my example here, adding the user to Azure Active Directory and also assigning them one of my developer licenses for Office 365. Now, that could be if you've got an E3 or an E5. Imagine that from a single interface. So, no roles are required for our user Alex, and we're adding them into the system.
Now, in the background what is key to what's actually occurred here is the process and the workflow and the automation that has happened. So, one of these automations is the user was or is in the Bracknell office. So we've automatically filled out the fields and the data that is relevant for that user being in Bracknell, be it the address, the office phone number, and all of the details. But that's an example of the automation of keeping that data correct.
The second part of this is for the role that Alex is part of, we're adding them to certain groups and giving them membership. So, within here, we can see we've automatically added Alex to the Bracknell office, and also to the sales group here as well. Also, he's our radius defender for doing self-service for 2FA registration there, as well. But that goes to all of our users. But in this example, let's say that our user Alex needs to be added to an additional group that has certain protections in place, and this is our finance group. It's for critical access to financial applications.
Now, for the user Alex, they only need access for the next seven days. So, ensure that you can give them temporal access. This means in seven days' time, the access is removed to keep the security in place without allowing that scope creep. Now, Jen needs to give a reason behind this, because it's going to initiate a workflow, because Jen doesn't have the rights to add the user. This can only be added by the asset owner.
So, in this example, it's myself. So, I flicked screens. I'm into the tool as myself. And I can see the approval has come in. I'm going to see the approval. It's initiated from Jen, to add Alex to our finance group. Now, I'm going to approve that. I can then give my reasons, so I'll put in agreed here. Click on OK, And then we're going to flip back over to Jen's screen. Refresh the screen, and we will see that our user Alex has now been added to that group, finance. And if you look there closely, there's a little clock on the object that indicates it's a temporal membership that will expire in seven days.
But let's take this a bit further, and let's say now that Alex is going through his move. So, he's moving from a sunny Bracknell office into the London office. So, we're going to select that form from the system here. But also, Alex is going to change roles. He is going to move from sales to engineering. Interesting move, I know, but for the example here, moving from sales to engineering. Now, what's going to happen in the background is absolutely this user needs to be removed from any associations or privileges that were associated with sales and added to the engineering group. So we can see here, it's automated. That removed the existing rights and memberships, added in engineering, removed the Bracknell office, added to the London office. And additionally, you'll see that the group Safeguard is associated and provided to our engineers. They can get access to some of our privileged credentials in the vault.
So again, it's driving all of this automation to ensure that the correct memberships are related to the groups of the user is part of. Overall, this keeps the security of Active Directory and Azure Active Directory.
So, that was the first demonstration, the first example there. So, let's flip this around slightly and we're going to now talk about the actual day to day administration of Active Directory in Azure Active Directory. Now, I've actually been doing that in the previous example. So, what's behind the scenes here is saying, ensure that your users, like Jen, has only got the right permissions for her role.
Similarly, provide the granular delegation to ensure that these roles are delegated to the parts of the organization that they're relevant to. So, let me show you this in action.
So, here we are back in the screen as Jen Barber. So, for Jen's perspective, she's a Level 2 help desk, but her role doesn't require her to have the ability to browse the directory tree. She doesn't need to look at what's in the US side or down in Asia-Pac, only for the areas that she manages. And we've given that to Jen via what we call managed units. So, this is a representation of where Jen can actually administer and carry out her functions.
So we can see here we've got our Europe users, enterprise users and groups, and we're setting the permissions over where this can be applied to so we've got all of our users here that this role allows Jen to do the administration for. Now, similarly, if I flip to myself, I'm a Level 3 Administrator. If I go into the directory management, we'll see here that I do for part of my role have a requirement to browse the directory tree. And also, for the day to day administration, we've provided managed units for my role that is more encompassing than Jen's role.
So, I can go into here. I can manage service accounts, the Windows servers, and again, more capability relating to my role. Now, we also have a role here for HR. So, for our HR users, they just need basic user capability, no need to browse the tree. And for our user hour in , Europe we're just going to provide a virtual overview for all of our European users. so we can carry out basic tasks. Now, that could be disable the account, reset their password, or some basic user management that you might delegate out to HR or to Level 1 on the help desk, but it's providing that delegation.
And we do that using templates. So, I have a permissioning model that says who this is applied to, where this is applied to, and the rights that that role can do. So, let's go into the example here for my Level 2 help desk, which Jen is a part of.
So, this is associated to information services. It says these are the rights that this role can carry out, so some general user and group administration. And then it's the part of the organization we can see in the right hand side of the screen here, where it's applied to. So, this is where that role, Level 2 on the help desk, can carry out these tasks. So, it provides that delegated administration. It ensures you're not giving too many rights to users to do their job that they were required to do. Really important to ensure that security of Active Directory and Azure Active Directory.
Now, there's going to be times when your users, your engineers, your administrators do require additional privileges. They might require access to a DA account or an enterprise admin account. But from a security perspective, looking at ways to provide this using just in time, providing the ability to elevate privilege only when it's required, is really key to successful security around Active Directory and Azure Active Directory. So, let's look at how we can actually do this in action.
So, we're going to take our user, Alex. And in this example, we added him previously to our engineering group, which gave Alex access to our password vault. So, Alex is going to log into our vault. You'll see me move the screen across here slightly, as I'm just moving my iPhone, because we've prompted Alex to verify who he is. So, we're sending a push notification down. We'll allow Alex-- as I've mirrored my iPhone to my desktop here-- we'll see this come in. I can then accept the notification, approve, and then it provides me with access into the vault. So, I'll just maximize the screen backup here.
Now, part of the role that Alex is a member of within Active Directory allows him access to certain resources, one of which is our Active Directory and four accounts that we're allowing him to check out the credentials for that give different levels of access. So, we are requesting a domain admin account in this example. I'm going to click on OK.
And before I do this, let's just explain what happens in the background. So, we'll see here that I've got some accounts that are actually managed via our privileged solution. And these are the four user objects. At the moment, they're disabled. And not only are they disabled, they are only a member of domain users, so they have no additional privileges.
Now, what's going to happen when Alex clicks Next and goes through the process here of making that request? We're going to request it immediately. In the background, as this is submitted, the system is now going to provide Alex with a credential. It's valid for that two hour period, or until it's checked in, and then that credential is rotated. But importantly, we can see that account has now been activated and we've actually added that account to a temporary group, which is in turn a member of our domain admins. So, this provides that account with elevated permissions to carry out the tasks that are required.
Now, I'm just going to take this a little step further. So, I'm going to-- first of all, we're going to just check that back in and we'll see that it's removed all of those permissions. So, you can see there's no standing rights. The permissions have been removed. So, let me just minimize that. And as I said, I'm going to take this a little step further, because it's all about the visibility.
So, let's say that for Alex, he actually needs to access one of our member servers. So, the objective is to do an RDP to this target device, to this target server. He's going to check out one of these temporary domain credentials. Again, the account is going to be reactivated. We're going to apply the permissions that are relevant for that account, and then allow Alex to launch a session to that target member server. And importantly, everything that's going on, we're actually going to have the ability to monitor and audit.
Now, to simulate some activity here, Alex is going to access this member server. We're going to then just carry out some basic administration. And in the example here, we're going to bring up Active Directory users and computers.
Now, remembering that the account that Alex is using is a domain admin, it's got domain admin privileges. So, we're going to go into the finance group. And as this domain admin, I'm going to now add someone directly to this finance group. In my example, I'm going to have my colleague Alan, click on OK, Apply. And we actually get a warning, because even though we're using a domain admin account, this is a protected group. We're ensuring that unless you go via the correct mechanism, you can't make a change to that group. So, it's applying the protection over there.
Now, just to show the example here, if I was to go to domain admins and add Alan to this group, it's allowing me to do that because I am a domain administrator, but I haven't set the protection on the enterprise admin group. Now, that is a way of providing control and security over critical objects or critical groups in your Active Directory.
So, let's just close down the session, check back in the credentials. And as Alex, we think we've covered our tracks, we've finished doing what we're needing to do. So, we've seen the user check out those credentials, using them just in time, and then the permissions have been removed. But what's really important the organization is the visibility.
Now, visibility absolutely key. Look at the Microsoft best practice for AD and Azure Active Directory, and it will call out many times, you need to know what's going on. And to give an example of why, if you look back to the turn of this year, 2021, January, February time, there was a threat actor called Hafnium. Now, they used a number of post-exploitation tools based on a zero day to access Exchange servers and create accounts and then log back in as those accounts. Now, this exploit has since been fixed, so there's no longer an exploit there, but it just goes to show the importance of monitoring what's going on.
Now, I've picked two examples, monitoring users and also monitoring protected resources, like SAP admins, domain admins, or in my example, my finance group. So, let's see this in action.
So, firstly, I want to know if anyone's been making changes or doing anything to that finance group, because I'm the asset owner. I want notification. But this could just as easily go to the SOC.
So, any changes, any access to this group, I get notification. So, we can see this alert's been triggered. Now, we can see that Jen Barber has added an object to this, but it was successful, because it was approved and via the correct mechanism. However, when Alex went in with those domain credentials, we get another alert that this has actually failed, because it's protected. We've set this as a medium severity. But the important thing here is it's triggered an alert. I know he's done something or someone's trying to access this group. So, it allows me to then look at this in more detail.
But what's going on behind the scenes here? Let's just have a quick look. So, we're monitoring everything that's going on in the directory service. And we can see there that in this last month, 34,000 events have been recorded. So, that's a lot to go through and it's really important to able to drill into what's important to you. So, I've got a search here that looks at finance and it also looks at group changes and user added. So, these are four searches that I've set that I want my notifications, I want to be able to drill into the details of.
And if we look at my finance group, this has been defined as a protected object that we control the access to. And in our example, we're saying that the only way changes to this group can be made is via our directory administration tool, Active Roles, and that was how Jen added the user. But importantly, we need visibility of the directory service critical activity, and then we can also drill into this by sharing certain searches.
So, I've got my four private searches here. This is my finance group over the past 24 hours, users that have been created, but importantly, I can see that the one that's successful-- I'm just changing the window sizes here-- we can see that this has come from the initiator, Jen Barber, the Active Roles service, and this was successful. However, the one here that's failed is this temporary domain admin account. Now, I know that that's managed via our Pam tool, so it allows me to drill into this in more detail for investigatory purposes.
So, in this example, I'm then going to bring up our sessions analysis and we can see here on the second one down that Alex has come in. He has used this temporary domain admins account to access this member server on this address. We can see the date and time. And having that ability to look at the details, look at the timeline, look at the analytics and how they've been behaving and then rebuild and replay this in a movie-like format is absolutely key for that visibility, knowing what's going on in your directory service, knowing what's going on in your servers.
So, I'm replaying this session. It allows me to look at what has Alex done, the keyboard, the mouse movement. And we can see that he's tried to add that user to this group. So, absolutely pertinent to have this visibility. You know who's being created and what's going on, and you can alert on it.
So, in summary, limit human error with a JML process that's defined, policies that are backing all of this up so it's controlled, you're not having that human error and you're actually controlling-- and also the efficiency that it adds to not only the security. Then, very important is to delegate the administration by the role. Only give out the rights that are relevant for that role, and for where that role should be applied. Don't go around giving out additional permissions when they're not needed. If someone does need those elevated permissions, have a methodology for providing it just in time. Elevate the privileges at that moment in time.
And then, importantly, gain your visibility. You need to know what's going on so you can spot things that are going wrong so it helps you to mitigate a breach. Or if there was a zero day, you can have that notification that something untoward is actually going on.
And finally, assume you will be breached. Think that you'll be breached and build your environment in that way.
Now, taking the opportunity if you have any questions from the content that's been discussed and presented during this session, we are on hand to answer those questions. Please submit them into the chat window. Thank you very much.
[MUSIC PLAYING]