Implementing the ACSC Essential 8 Maturity Model. Mitigation Strategy 5: Restrict Admin Privileges

The Essential 8 Maturity Model is a set of baseline cyber security measures for Australian organisations developed by the Australian Cyber Security Centre (ACSC). This article forms part of our Essential 8 series and goes into detail on Mitigation Strategy 5: Restrict Admin Privileges. Read on to learn about how you can implement Mitigation Strategy 5: Restrict Admin Privileges for all Essential 8 Maturity Levels within your organisation.

What is Restrict Admin Privileges? Why is Restricting Admin Privileges important? Maturity Level 1: Restrict Admin Privileges Maturity Level 2: Restrict Admin Privileges Maturity Level 3: Restrict Admin Privileges Summarising Restrict Admin Privileges Where to Next?

What is Restrict Admin Privileges?

What did spiderman say? “with great power comes great responsibility”. Admin users have power over IT assets, and almost no businesses today do not utilise IT assets. You can think of privileged accounts as the keys to the kingdom, the keys being your credentials and the kingdom being your organisation. Of course, if you are anything like the Japanese cyber security minister who has never used a computer, you probably won’t need Essential 8.

Power can be used for good or bad. If you are a standard IT admin, then it is fine. But the damage you can do is significant if you are an insider or a threat actor who managed to get their hands on the credentials of a privileged account. For example, you need to look at the Medibank hack to see how much damage. They lost all their data, including personal information and health records, their financials dropped, and worse yet, their reputation has been scarred. More alarming, as data is sold on the dark web and threat actors begin social engineering activities, everyday people can really get hurt.

Restricting admin privileges apply least privileges to admin users and is another mitigation strategy to limit the impact in case of a breach.

Why is Restricting Admin Privileges important?

To understand why we need to Restrict Administrative Privileges, we must first understand our users.

👩‍💼Business users
- What are privileged accounts?
- I have access to some privileged accounts
- I have access to some things I don’t use
- I would rather have access to more than I need so I don’t have to keep requesting it
✅Risk managers
- Why are we able to access things we don’t need which could be malicious?
- In the event of a breach, I want to limit the impact on the organisation
👩‍💻IT users
- I don’t want to lose my power
- I keep my credentials safe already
- Some admin credentials are stored in a spreadsheet
- I don’t want to be monitored
😈Threat actors
- I want to gain access to the most privileged accounts to do the most damage and make the most money possible
- I know who is on the technology team and in key positions that may have system privileges

Maturity Level 1: Restrict Admin Privileges

Requests for privileged access to systems and applications are validated when first requested.

Only some people should have access. Access should constantly be reviewed and approved especially privileged access. You are giving up the ‘keys to the kingdom’, so you have to be careful whom you give it to and whether they have a business reason to have it and all the access it comes with.

You need to put in a process if you don’t already have one. It’s also good to record who approved access in the first place for record keeping. But, again, applying least privileges we should only be granted what they need to get the job done.

Assessors will ask for forms or tickets to see proof of admin access requests.

Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services.

The internet, emails and web services are great places for potential attacks, and the last thing you want is for your privileged accounts to be attacked. You don’t even want them to be known. So, it is best to keep them away from predators.

Block internet, email and web services for your privileged accounts.

To implement this, deploy a privileged access solution with privileged access workstation capability.

Privileged users use separate privileged and unprivileged operating environments.

Ring fence your privileges. If you have the same operating environments, attackers can see everything if they get in. Ring-fencing them limits what they can do.

If you are separating your environments and planning to achieve Maturity Level 2, ensure your privileged environment is not virtualised in your unprivileged operating environment.

Unprivileged accounts cannot logon to privileged operating environments.

Why would an unprivileged account need access to privileged environments in the first place? If you have followed least privileges and access request requirements, unprivileged accounts should not have access to privileged operating environments.

Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.

Same as the above but in reverse. Keep those privileged accounts safe!

Maturity Level 2: Restrict Admin Privileges

Privileged access to systems and applications is automatically disabled after 12 months unless revalidated.

It feels nice to have power. It’s even better if you can keep it. But do you need still need it? You may have previously required access, but do you still need it now? So why keep it around? Is that person even still with the company?

Automatically disabling accounts is a great way to keep your stock of privileged accounts clean. In addition, less privileged accounts are easier to manage and reduce your attack surface.

Use your PAM/PIM solution to clean them up. Too often, we’ve seen accounts just sitting there. Nobody knows what they do, and they are too afraid to disable them in case things break. We typically see these with service accounts. Yes, you know what I’m talking about.

Privileged access to systems and applications is automatically disabled after 45 days of inactivity.

Again, we want to reduce the attack surface. If accounts are not used within 45 days, they probably do not need it, so let’s be safe and away from adversaries. Disable them. Set a policy to have privilege access disabled if inactive for 45 days.

Privileged operating environments are not virtualised within unprivileged operating environments.

At Maturity Level 1, you have already split the privileged and unprivileged operating environments. You need to check that none of those unprivileged operating environments is virtualised within privileged operating environments. Why you would create a privileged operating environment in the first place seems like a mistake. Either way, separate your privileged and unprivileged operating environments.

Administrative activities are conducted through jump servers.

Before modern PAM solutions such as Delinea’s secret server or CyberArk’s PAM, IT departments used jump servers and still do today. As the name suggests, log into one server to jump to another server. The initial server is protected, and the subsequent server can only be accessed from the origin server.

You would do this to limit who can access your server, decreasing the attack surface and reducing the risk.

Credentials for local administrator accounts and service accounts are long, unique, unpredictable and managed.

Access to local admin or services means you can run anything on that device, endpoint, or service. If these accounts are compromised, well threat actors also do whatever they like on the local device. Therefore, credentials for these accounts must be complex and challenging for threat actors to crack.

Privileged access events are logged.

Nobody likes to be tracked from those pesky internet cookies that follow you to full-on surveillance systems as they have in China that can track anyone in the country down in seconds.

However, tracking privileged access logs are essential. Logging normal access activities are fine. It is crucial, though, to log abnormal activities. But how do you know? Is it normal or not? Well, you must log them all, so your forensics team have something to look at when they are trying to identify what happened.

Like other Mitigation Strategies at Maturity Level 2, events simply need to be logged and not centralised.

Privileged account and group management events are logged.

It is not enough to log access. We need to know what admins are doing. Event logs will help capture changes in privileged accounts and groups.

As mentioned above, this is vital for forensics should you have an incident involving privileged accounts.

Capture your event logs for a later date.

Maturity Level 3: Restrict Admin Privileges

Privileged access to systems and applications is limited to only what is required for users and services to undertake their duties.

Maturity Level 3 takes least privileges for privileged users to the next level. Users requiring privileged access must only have access to what they need. Too often, we have seen global admin accounts being granted where they only need access to certain privileges for ease of use. Worse, sometimes these accounts are shared or have not changed passwords for decades, making them difficult to track and increasing the risk.

Privileged accounts are prevented from accessing the internet, email and web services.

In Maturity Level 2, we had the same requirement. However, it excluded service accounts. To achieve Maturity Level 3, we expand the restriction to include all privileged accounts from accessing the internet, email and web services.

Just-in-time administration is used for administering systems and applications.

Ok, if you’ve managed to avoid PIM/PAM solutions, you will need them now. Just-in-time admin controls access to allow privileged access only when required, no more and no less. Access will be granted when requests have been approved and only for a set period. Additional access can be requested either through extensions or a new request.

Most PAM and PIM solutions have Just-in-time administration built-in.

Windows Defender Credential Guard and Windows Defender Remote Credential Guard are enabled.

Credentials could be cached within the Local Security Authority System Service process to access network resources without asking users to keep entering their credentials. Windows Defender Credential Guard and Windows Defender Remote Credential Guard are Microsoft’s solutions to protect cached credentials for users and remote logins.

Privileged access events are centrally logged.

Again, logs at Maturity Level 3 need to be centralised into a SIEM. If you have saved your privilege access logs but have yet to ingest them, now is the time.

Privileged account and group management events are centrally logged.

As above but instead of privilege access events, log your privilege account and group management events into your SIEM solution.

Event logs are protected from unauthorised modification and deletion.

As mentioned, protect your logs across Essential 8 Mitigation Strategies. In addition, if you are working with a managed service such as our managed CyberOxide SOC, we can help you to secure your logs.

Event logs are monitored for signs of compromise and actioned when any signs of compromise are detected.

Again, make sure your logs are safe from compromise. If you need help or do not have the capability inhouse, our managed CyberOxide's SOC has SOC analysts available to monitor your logs for any signs of compromise. Contact our team to find out how we can partner with your organisation.

Concluding Restrict Admin Privileges

Privileged admins have power, sometimes too much power. Threat actors know this, so privileged accounts are key targets. Essential 8 requires you to apply least privileges to privileged accounts to limit the ability of damage should a privileged account be targeted.

Most admins won’t want to lose their privileges. However, like any Identity and Access Management (IAM) solution, the difficulty is in educating users and increasing awareness to adopt best practices. It is not like you want to see what admins are doing wrong. It is more that these are the most critical accounts within an organisation, and they need to be protected to the nth degree.

If you are an admin, you must understand that threat actors are after you. While losing power may not feel good, you need to consider it from a business perspective. The benefit outweighs the cost of relinquishing your excessive admin rights.

Where to Next?

Restrict your organisation’s Admin Privileges! Accelerate your Essential 8 program and reach out to a CyberOxide Specialist to help uplift and assess your Essential 8 Mitigation Strategy 5: Restrict Administrative Privileges.

Continue learning about Essential 8 with our next article on Essential 8 Mitigation Strategy 6: Patch Operating Systems.