This article originally appeared on Quest Software’s official blog, HERE.
It may come as a surprise that for many years the concept of least privilege was foreign in a Windows network. It would not have been uncommon in the past for vendors to demand administrator rights, or worse yet, require that you be a domain administrator to install and run certain software. But now the cyber industry is catching up and mandating implementation of least privilege.
What is the principal of least privilege?
The principal of least privilege (POLP) is a computer security concept that limits the number of permissions or access rights a user has to IT systems. Just like its name, least privilege means having the least number of permissions or rights necessary to perform one’s job. Whether you are a domain administrator or a mere user in the network, it ensures that you only have access to what you absolutely need to perform the tasks required for your role.
Nowadays, even cyber insurance carriers are jumping into the enforcement of least privilege. Recently, my own cyber insurance carrier mandated that I ensure that I have “multi-factor authentication protection on all network administrator accounts and any other user accounts with elevated permissions within my network.”
Why is the principle of least privilege so important?
Attackers are consistently looking for ways to elevate privileges to go from mere user to domain administrator. You should review your network for two major concepts:
First, you should design your network such that users only have the rights and access they need to do their job. Don’t make it easy for attackers to perform lateral movement throughout the network in the blink of an eye. Networks should be segmented so that damage can be isolated and contained.
Second, the principle strikes a balance between usability and security protections. We once built our networks with a hard outer shell thinking that attackers have to break in to do damage. Now you need to build your network with the view that they may already be in your network and thus limit the scope of attack. Simplifying auditing and compliance will assist you in the breach investigation stage.
A new approach to admin access
Now is the time to rethink administrator access throughout your entire organization. From domain servers, to cloud services, to workstations, the use of administrator access should only be provided on an as-needed basis. We must make it harder for attackers to laterally move throughout our networks.
In my own network, I have progressed from having a common local administrator password, as I deployed my workstations, to where I ensure I use the Local Administrator Password Solution to generate random passwords that are then saved in Active Directory. If you still have a common shared administrative password, all an attacker has to do is phish or trick a user into handing over the credentials and then the attacker can perform lateral movement in the network.
I often seen situations where application vendors do not properly code their applications and to get the software to function as intended, a temporary workaround of increasing the rights of the user is permitted in order to have the business function. Too often, after these adjustments are made, users keep their elevated rights and they are never removed. Often attackers will “audit” the organization’s rights and accesses during stealthy reviews of the network and specifically target those users that perform high-level functions or have rights to highly targetable assets.
Then there are those situations where you may have limited the user rights, but the attacker is still able gain more access in a system. Too often attackers use phishing lures to gain access to a system and then use blended vulnerabilities to elevate their rights to the system. Often older unpatched Office installations are a source and means for attackers to gain access to systems. Unpatched software that can lead to privilege escalations is often just as dangerous as having the elevated rights from the get-go. That’s why patch management best practices are so critical to implement.
Staying a step ahead
Microsoft is continuing to improve and advance solutions to ensure that we stay one step ahead of the attackers. There are already known tools designed to go after the LAPS solution on your network.
In a recent blog post, Microsoft has indicated that they too reviewed their practices and thoughts regarding administrative access. They begin first with a secure admin workstation— a computer whose only view is that it will be used for administrative access and no other purposes. During the pandemic, especially during the early months of “work from home” and isolation, we struggled in offices to obtain enough hardware to allow all users to have a specialized workstation. We were using and reusing any laptop we could get our hands on, as well as allowing workers to use their home machines for remote access to the organization. But this “personal use is okay” philosophy meant that we introduced situations where attackers could target our developers and administrators who did not keep their workstations secured.
Just recently in fact, a major password management solution suffered a security breach that was triggered by the use of a personal workstation that was not secured or fully patched. The use of a personal device and lack of isolation meant that the entire organization was now at risk.
Recommendations on how to increase least privilege security measures
Microsoft recommends four areas that you can get started on to increase security.
- First, ensure that you implement technology and compliance structures to encourage and enforce least privilege. Start by reviewing what roles and rights users have in your environment and why they have the roles or access they do. More often than not, the old-fashioned permission level of “everyone, full access” wasn’t appropriate back then, and isn’t appropriate now. Users and even administrators need rights to do their jobs, but not to allow attackers to take full control of the network.
- Next, ensure that role-based access control is in place to ensure that users and administrators are segregated. The sales team has no need for the same information that the legal division needs access to and vice versa. Justification for access beyond what is normal for the position needs to be formally justified.
- Investigate rolling out just-in-time elevation. Often a user needs access just for a specific task or need but not for the entire time. Often this means that a user has to request access which is then approved by an administrative process. Once the task is complete, the access is removed. Often users don’t need permanent access to a database or rights for a location. The access typically can have a time limit based on the time of the project.
- Ensure that administrator accounts are not used for day-to-day use. The higher and more sensitive the administrator, the more they should not have an email address that corresponds to the administrator account. Attackers review LinkedIn and other social media locations to find and specifically target high-value administrators. Ensure that the users that inhabit these roles are isolated as much as possible.
Don’t assume new means better
Too often when starting a new cloud deployment model, we build out our infrastructure in a manner similar to our on-premises deployments. Thus, we pivot to the cloud and think the user or administrator needs exactly the same rights and permissions. While it may have made sense years ago to provide the SharePoint administrator rights in the Exchange organization, it may not make the same sense now.
Furthermore, we typically did not build our user rights model with the idea of just-in-time management years ago. Now, when we pivot to any cloud application from any cloud vendor ranging from Azure to Google cloud to AWS, we need to build our access using this just-in-time model. Azure AD Privileged Identity Management (PIM) allows you to set users to have specific Azure AD roles for a limited time. You can set up the network such that users have to ask permission and you receive notifications in order to gain these higher privilege roles.
Ensure vendor participation
You should review and ensure that your vendors and consultants are also doing everything they can to keep your network and systems protected and limited from attacks. Specifically, consultants and managed service providers (MSPs) that have access to your systems and networks should ensure that they practice the concept of least privilege amongst their client base.
Each customer’s domain administrator rights should be segregated. Ensure they are protected with multi-factor authentication. And make sure passwords should not be shared across networks. Connections between the consultant and the customer network should be limited for trust. Review your contracts with your MSP along with guidance from your cyber insurance policy carrier to ensure that the MSP identifies high-risk devices, services, and user roles and limits their use and access.
The CISA guidance for the use of managed service providers specifically calls out that when anyone, from the local information technology staff to the external consultant, changes hands, privileges should be updated upon changes in administrative roles.
Administrator duties should be limited, and administrators should be given only those rights they need to perform the specific duty required of their jobs. From on-premises networks to cloud resources, no one should be logging in as the global administrator unless there is a specific and potential emergency need to do so. Ideally a documented playbook should exist for any breach or security incidents so that administrators do not inadvertently log in to a resource with higher rights than is needed to repair or limit the attack.
In the heat of the moment and under stress, IT personnel may inadvertently violate least privilege and expose credentials to the attacker, making the situation worse, not better. Even for Azure Active Directory, all administrators should use multi-factor authentication at all times and there should a limit to those accounts that are set up without multi-factor. These should be set up in such a manner that they are not logged into and if they are – as in the case of an emergency – an alert is set up to the other administrators that the accounts have been accessed.
These “break glass emergency accounts” that are set up without multi-factor authentication should only be used just for that – an emergency. No administrator account should be used for a lengthy period of time. Everyone logging in should log in to do their job and then log out.
To learn how Quest Public Sector can assist your federal agency in implementing least-privilege and zero trust security models across its networks, click HERE.
