This is a copy of a Microsoft Post that I think my readers would be interested in.
This post starts a series explaining why we at Microsoft Security Services for Incident Response recommend some of our favorite protections. Our first post in the series talks about identity hygiene.
If you’re new to our services, we’re a team of cyber-security experts at Microsoft who help companies get global response with investigation and recovery by applying proven practices against various types of attacks before, during and after a security incident. You’ll learn more about us and what to do in our page here: https://aka.ms/MicrosoftIR
Our goal with this post is to highlight the importance of getting the right privileges as a protection mechanism to prevent a cyber-attack. The post will cover some definitions and some calls to action so your company can be better protected though identity hygiene.
When we mention identity hygiene you might think of shiny-bright and clean identities. And yes, at some point, they look like this because it takes some brush-up and polishing of your current, and maybe new identities. Identity hygiene process is a series of steps that we follow when we’re helping customers recover from attacks, it starts with a discovery of the environment and its configurations and of course, some of these configurations include identities and these are subject to be cleaned up.
Why is this technique needed at all? Imagine Magda, the administrator of your company’s file server. When she’s about to enter a meeting, she gets an urgent call from her manager, saying that he is not able to access some important files he needs. She’s in a hurry, but can’t leave her manager unable to work, so she quickly gives him full control permission over the files so he can’t complain.
In an ideal world this shouldn’t have happened at all, but, if for any strange reason her manager had gotten these excessive permissions, she should analyze what just happened and would correct this by putting the least permissions required for the manager to access the files. Yeah, but that’s the ideal world… Unfortunately, many times this happens in a less-than-ideal way. When we look at customers’ environments after a compromise, we find all kinds of excessive permissions being applied to files, folders, identities, directory structures, resources, organizational units, storage accounts, group policies and all kinds of assets in a company’s environment. This sort of situation happens every day, in most companies, and keeps happening over the years! Imagine cleaning up all this mess after years of hurries!
When we talk about de-privileging in cybersecurity, and especially in Microsoft Security Services for Incident Response, we’re talking about taking away from an entity those permissions and features that make it relevant for a security investigation, or for an attacker to own control of it. If an account has many permissions applied (and that’s noticeable!) An attacker will likely try to get a hold of that account to perform their activities, as they would expect that the account has some sort of special value and, because of that, it has been given those extensive permissions.
De-privileging is key in our compromise recoveries, but, unfortunately, you cannot just strip privileges to ALL your identities… there must ALWAYS be at least some privileged identities in the system… otherwise how would you delegate permissions to others to help you in your job if they don’t have at least some privileges?
Removing privileges is not only about cleaning up existing accounts, but sometimes also we find accounts that are no longer used (never logged on in months!) or have not changed their passwords in a long time (meaning that an old attack might be replayed), or accounts might have been disabled without removing their permissions first, allowing for a potential escalation should that account gets re-enabled. These situations should also be avoided, and their prevention should be part of the credential hygiene process.
What are we doing here?
Privileges can be permanent, or they can be temporary, the most common way nowadays to have temporary permissions is to use solutions like Azure Privileged Identity Management (described here: https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure) or solutions from some of our partners in the industry. Any of these are good if they cover your business’ specific needs and preferences. It’s always a good idea to evaluate several of them and ideally choose the one, or ones, that best suit your case. The ability to grant privileges temporarily is a great idea as it allows you to build a process to audit, revoke and integrate the identity lifecycle in a way that makes sense for your company.
Another important discipline you can (and should) use is performing Access Reviews. An access review is an activity where you ask the user, or the person responsible for their access, if the outstanding privileges are still needed by that user. You cannot ask for access reviews every day to every user, (it would make users hate (even more!) their security departments!), you need to learn the art of balancing the opportunity, the value of the assets being protected and the process that it takes to perform the access review, which is also key in its success. You can visit this page to see an example of how access reviews work in our Azure AD platform: https://docs.microsoft.com/en-us/azure/active-directory/governance/access-reviews-overview
When we have this feature, revoking privileges and making things clean is easily done. However, many systems still allow you to provide users with permanent privileges. This is, by the way, the default way in most running operating systems and applications which have been designed with this concept in mind, so we can say it is present in most of the customers we work with. The problem with permanent privileges is that they are easy to forget, so it is easy to end up having users who have more power than desired… sadly, attackers are very good at finding these and will go after those credentials to perform their attack (most of the times through lateral movement (http://en.wikipedia.org/wiki/Network_Lateral_Movement)
Unused privileges is another problem, people might have been granted temporary access to assets but then they’re not needed anymore. With the help of tools such as Microsoft Entra Permissions Management we can discover, remediate and monitor the permission “creep” that can be created, and we can even fix it across multi-cloud environments. There’s a nice article here: https://learn.microsoft.com/en-us/azure/active-directory/cloud-infrastructure-entitlement-management/overview, that introduces the concepts behind Entra Permissions Management
One of the techniques we use in Microsoft Security Services for Incident Response during our interactions with customers is to de-privilege those accounts that we found with excessive power over the systems which are more critical for managing the environment. We will discuss which kind of systems those are in a future post. By de-privileging we attempt to leave identities with the minimum required access to perform the tasks they are supposed to do, and we encourage the use of the delegation tools available in the system to manage the permissions according to the best practices.
The value of de-privileging
Let’s suppose that every account that has excessive permissions was worth $1000 (It can actually give an attacker way more value than that!). Often, when we analyze a customer’s environment, we find hundreds of accounts that have more privileges than required. For the attacker it is just a matter of finding the right account to have success in their attack.
If we analyze recent environments where we have worked, we’ve managed to find that over 4/5ths of the accounts they had configured to have excessive permissions could be de-privileged to leave them either as standard users or properly delegated administrators. In some cases, we prefer to remove those accounts and create new accounts which have passed through the right delegation process.
Another way of looking at the value of de-privileging is looking at the exposure surface you have in your system. Imagine that you have 100 accounts, if 80 of those accounts have more privileges than required, you have an exposure of 80%. This means that a potential attacker has an 80% success rate to get a hold of a privileged account, making it possible for them to cause a lot of harm in your environment or your data.
The process of de-privileging takes time. You need to understand why each user has the current privileges, and you need to assess how harmful it is to remove those privileges in terms of the ability for the user to perform the task they have in assigned to. If you don’t have an access review process in place, the understanding of the status of your user accounts is going to take a big effort to get.
How to avoid de-privileging?
For a new system, it is easy to build some sort of privilege-granting rule. You need to make sure that everybody who can grant a privilege is conscious of the implications of granting that permission. This is one point to consider. Education, in this case it’s not for the end user, but for the team administering your systems, so they keep conscious about this fact. Education for your end users to reject and report when they see they have too many rights would be ideal, but that’s very hard to achieve and then unlikely to happen.
For existing systems, you really want to make sure what permissions are outstanding. To do that, you will need some sort of tool that will collect information about your current permissions. These tools are not easy to find in the market and sometimes they are expensive. If you happen to be working with our Microsoft Support services or with our Microsoft Security Services for Incident Response, you will have several tools included in your engagement. And you can keep using it for some time after we leave.
Apart from the education and the tools, you need a team. When we’re engaged with you, teamwork is essential in getting to a successful eviction or recovery, we have learned with our engagements, that building a team of people creates powerful responses to attacks. Communication, clarity, and agility make great skills to a team that helps protect your environment. A well-formed team is, indeed, one of the best ways to avoid having to de-privilege identities in your systems.
TL;DR (well, you read already!)
Cleaning up your permissions will help you be more resilient to attacks. Of course there are more techniques and we will be covering those soon but, for now, make sure your important permissions are given ONLY to the right identities you’re expecting to use it. Uncontrolled permissions might be a source for someone to get control of your environment.
To read the full Article and learn more,
