The ultimate goal of an information security program is to reduce risk. Often, hidden risks run amok in organizations that just aren’t thinking about risk in the right way. Control 5 of the CIS Critical Security Controls can be contentious, can cause bad feelings, and is sometimes hated by system administrators and users alike. It is, however, one of the controls that can have the largest impact on risk. Therefore it is an important control, and the conversation around why it is important is also important. We’ll talk about both.
Misuse of privilege is a primary method for attackers to land and expand inside networks. Two very common attacks rely on privilege to execute. The first is when a user running with privilege is tricked into opening a malicious attachment, or gets malware from a drive-by website, such as malware which loads silently in the background. Privileged accounts just make these attacks succeed quickly, and user machines can be controlled, or keylogging can be installed, or running malicious processes can be hidden from view.
The second common technique is the elevation of privilege when guessing or cracking a password for an administrative user and gaining access on a target machine. Especially if the password policy is weak (8 characters is not sufficient!) or not enforced, the risk increases.
What it is
Reducing administrative privilege specifically means running services or accounts without admin level access all the time. This does not mean that no one should have admin, it means admin privilege should be heavily restricted to only those users whose jobs, and more specifically tasks, require admin privilege.
Regular, normal users of a system should never require admin privilege to do daily tasks. Superusers of a system might require admin access for certain tasks, but don’t necessarily need it all the time. Even system administrators do not require admin level access 100% of the time to do their jobs. Do you need admin access to read & send emails? Or search the web?
How to implement it
There’s a lot of different ways to implement restrictions on admin privilege. You are first going to have to deal with the political issues of why to do this. Trust me, addressing this up front saves you a lot of heartache later on.
The political stuff
Case #1: All users have admin, either local admin and/or admin account privileges
My first question, when I see this happening in any organization, is “why do they need this?”
Typical answers are:
- They need to install software [HINT: no they don’t.]
- Applications might fail to work [Possible but unlikely, the app just might be installed improperly.]
- They need it to print !!! [No.]
- My executives demand it [They demand a lot in IT without understanding. Help them understand. See below.]
- Why not? [Seriously?]
All of these Some of these are valid responses. The problem is we don’t understand the root issue that’s driving the reason that everyone needs admin level access to do their daily duties. And this is probably true of many organizations. It’s simpler just to give admin access because things will then work, but you create loads of risk when you do this. You have to take the time to determine what functions actually need the access, and remove this access from those functions that don’t require it, to lower the risk and the attack surface.
All of these responses speak to worries about not being able to do a business function when they need to. They also imply that the people in charge of approving these permissions really don’t understand the risks associated with imparting them. We need to get them to understand the lowered risks of possibly needing admin once or twice, and much higher risks of having it when attackers strike.
Case #2: Your admins say they have to have it “to do their jobs”
I don’t disagree with this statement. Admins do need admin rights to do some tasks. But not every task calls for it. Do this exercise: list all the daily tasks an admin does on an average day. Then, mark each task which does not require admin privilege to accomplish. Show that list to the person responsible for managing risk in your organization. Then simply create a separate, normal user account for your admins, and require them to use it for all those tasks that are marked. For all other tasks, they escalate into their admin account and then de-escalate when done. It's an extra step, and it is a secure one.
Now have the conversation. It may be painful. I have actually been in meetings where people got so mad they threw things, and would be in tears when we told them we were “taking away” their privilege. This is why we say “reducing” or "controlling.” These are important words. The phrase is “we’re reducing/controlling risk by allowing you to use your privilege only for tasks that require it.” For executives that demand it, point out they are the highest risk to the organization due to their status and are frequently a high value target sought by attackers.
Then you support your conversation with information from around the web, whitepapers, studies, anything that helps drive your point.
For example this article from Avecto illustrates 97% of critical Windows vulnerabilities are mitigated when reducing admin privilege. Allowing you to focus on the remaining 3%, and be more effective. Search around, there’s lots more good supporting material.
This does not need to be an expensive exercise. Using techniques like Windows delegation of authority, you can give administrative privilege to users for specific tasks, like delegating to your help desk the ability to disable accounts or move them to different OUs. They don’t need full admin to do this. On linux systems, using sudo instead of root interactively is much less risky.
If you are a compliance-driven organization, most compliance requirements state reduction of admin is required as part of access controls. Here’s a brief glimpse of some compliance requirements that are addressed by Control 5:
- PCI Compliance Objective “Implement strong access control measures”
- Sections 7.1, 7.2, 7.3, 8.1, 8.2, 8.3, 8.7
- HIPAA Compliance 164.308(a)(4)(ii)(B)
- Rights and/or privileges should be granted to authorized users based on a set of access rules that the covered entity is required to implement as part of § 164.308(a)(4), the Information Access Management standard under the Administrative Safeguards section of the Rule.
- FFIEC (Federal Financial Institutions Examination Council)
- Authentication and Access Controls
The technical stuff
Reducing admin privilege supports the Pareto principle, or the 80/20 rule. Effectively, reducing admin privilege, combined with the first four CIS critical security controls, can reduce the risks in your organization by 80% or more. This allows you to focus on the remaining 20%. It’s very likely the risk factor reduction is even higher! The Australian Signals Defence Directorate lists reducing admin in its Top 4 Mitigation Strategies, along with elements from Control 2 by using application whitelisting, and Control 4 by having an ongoing patching program.
Here is Microsoft’s guidance on implementing Least-Privilege Administrative Models. If you use Active Directory and are on a Windows domain this is very helpful in making meaningful changes to your admin models.
For Linux environments, each sysadmin should have a separate account. Enforce them using the ‘su’ command to gain root. Better yet is disabling su and enforcing the use of the ‘sudo’ command.
There are also 3rd parties who sell software which can help with this, such as CyberArk Viewfinity, Avecto PrivilegeGuard, BeyondTrust Powerbroker or Thycotic Privilege Manager. Note Rapid7 does not partner with these companies, but we recommend them based on what we see other organizations deploying.
All the other things
As with most of the controls, the sub-controls also list other precautions.
- Change all default passwords on all deployed devices
- Use multi-factor authentication for all administrative access
- Use long passwords (14 characters or more)
- Require system admins to have a normal account and a privileged account, and access the privileged account through an escalation mechanism, such as sudo for Linux or RunAs for Windows.
- Configure systems to issue alerts on unsuccessful logins to admin accounts. Rapid7 offers products such as InsightIDR which can detect and alert on these events. A use case might be if an admin leaves for vacation, you monitor their account and if you see any login attempts, it triggers an investigation.
- As an advanced control, admin tasks can only be performed on machines which are air-gapped from the rest of the network, and only connect to systems they need to administer.
Reducing or controlling admin is not hard to implement. However, it is a change to the way things are being done, and fear of change is very powerful. Do your best to have conversations to ease the fear. You are not taking anything away. You are simply making it harder for errors to occur which have large impact, and you are reducing the risk that an attacker can easily comprise an account, a system, fileshares, sensitive data, and more.