ASD Essential Eight Explained – Part 3: Restricting Administrative Privileges

The Essential Eight

The Australian Signals Directorate (ASD) Essential Eight has received considerable attention since it included an additional four strategies to the previously defined ‘Top 4 Strategies to Mitigate Cybersecurity Incidents’. Logan Daley continues the ASD Essential Eight Explained series below.

Restricting Administrative Privileges

What is it?

In nearly every environment, there are accounts that have elevated privileges beyond the everyday users in order to add, remove, and change elements of the information systems. These accounts, including dedicated service accounts for automatic execution, yield considerable power and the ability to cause untold sorrows if used inappropriately. Some may consider only the administrator accounts used directly on servers or in Active Directory, but administrative privileges can be local, domain, or enterprise level, and have varying degrees of control (such as power users, domain administrators, and enterprise administrators to say nothing of delegated privileges). Beyond that, they exist on workstations, network appliances, and just about every piece of Internet of Things (IoT) technology.

Where do I start?

As you would have with Application Whitelisting, an inventory. A current inventory of administrator accounts is a great place to begin. It will take a while to get a thorough a list of all of your administrator accounts, but it needs to be done. Include accounts with elevated privileges and not just Local, Domain, and Enterprise administrator groups – consider power users and any users with delegated authority. While you’re at it, inventory your service accounts as well, include the local administrator accounts on your workstations and whether or not users have this access. Finally, consider your network capable devices such as routers, switches, firewalls, IoT, and so on. Any of these can have a number of local administrator accounts. It may be a good time to look at these local accounts and evaluate your password strategy. If it has administrator rights, it has power, and that power must be used wisely.

Any pitfalls?

There are plenty of things that can go sideways when it comes to restricting administrative privileges. Service accounts can break, so be sure you maintain the level of access required by the services and vendors. Maintain a secure local account on your network equipment in the event it cannot reach the domain for authentication or else you may find yourself unable to fix a router or switch quickly. Failing to deactivate administrator access for employees that change roles or leave the company can cause hours and hours of “fun”. There may be accounts with administrative access to the most obscure things, by restricting the ability of a hacker to run riot on your systems and having a degree of accountability when changes are made. This is a solid strategy that gives people a pause-for-thought before clicking OK. There are tools available to help, and bringing in the pros to untangle the mess can be worth its weight in gold. A good password management application is a big plus, too.

The ghost in the machine?

Politics, plain and simple. Administrative access is a powerful element of a user’s psyche and taking it away can open Pandora’s Box. At the same time, it can also be the key to locking that very same box. Be ready for the battles that come with taking away admin rights, especially at the workstation level. Admittedly, Application Whitelisting can only help at an endpoint level so far by controlling installation and execution of programs. You can consider separate privileged accounts for those times when the user “must” have it and the service desk is swamped. Managers and Executives often demand administrator rights, so tread lightly and fully understand why before arbitrarily granting the power to the powers that be. Auditing and logging systems for privileged account activities should be thought of as well so when (not if) things get a little scary, you can follow the audit trail and make the resolution a bit easier.

How do I make it work?

Technically, it’s easy, but I’ve yet to find someone willing to blindly start revoking administrator rights (or granting them for that matter) arbitrarily. You need a rock-solid policy to underpin this strategy and it has to be supported and enforced by management. The roles of staff should dictate what they can and cannot have access to. Where possible, use security groups rather than assigning admin rights to individual accounts, it’s easier to move users in and out of groups than worry about individual accounts. Always remember to ask “why” the administrator privileges are required in the first place as it should be backed up with a solid business case.

Am I missing anything?

If there is one thing you shouldn’t miss, it’s the presence of generic accounts that have administrator privileges – watch out for these! I advocate against generic accounts by all means but if you must have them, restrict them as tightly as possible and log everything they can do. Also, wherever possible, try to leverage your directory services as the “source of truth” when logging onto network appliances. Changing the name of default administrator accounts doesn’t hurt either. Oh yes, remember good password practices lest you’ll end up with a hacker on the core switch using “admin” “admin”.

How do I start?

Take inventory and then review the roles that have administrator privileges. Review your policies, make a plan, run it through proper change management, and then just get moving with the clean-up. Remember, take your time, this won’t happen instantly or overnight.

Read more from the ASD Essential Eight Explained series.

Go to: Part 1: Application Whitelisting | Part 2: Patching Applications