It's time to look at another strategy in the ASD Essential 8. The concept of minimising administrative privileges was in the original ASD top 4, but unfortunately this important and very effective strategy is often overlooked. Administrative privileges are powerful, and once granted allow almost any change to be made to a system. If a user has administrative privileges to a system they can make intentional or unintentional changes that could have major consequences. Consider the difference between an employee executing malware as a domain administrator versus a standard user. The malware is much less likely to do damage and have access to sensitive information if it’s running in the context of a standard user account. IT systems are also much more likely to be stable if administrative privileges are restricted to only trained personnel.
In a Windows environment we often think of this strategy in terms of restricting access to domain administrator privileges. Certainly this is critical, but we also need to consider administrative rights that exist on workstations, servers, applications and other network devices.
So how do you go about restricting administrative privileges, what’s a good approach? Unfortunately we have to do a bit of investigation and planning work before jumping into the doing. That's no fun, right? A good place to start is:
Determine what administrative privileges exist and who has access to these accounts. In a Windows environment this means looking at elevated domain groups like Domain Admins and Enterprise Admins, local administrators of workstations and servers, application administrators and also administrators of network devices.
Determine who actually needs administrative privileges based on their job function and ensure that policies and procedures are in place regarding granting, reviewing and revoking privileges. You should also ensure staff with elevated privileges are trained to carry out their duties.
Once we know the current state of play and requirements, then we can start implementing some of the best practices:
In many businesses staff have full admin rights to their workstations. This is certainly bad practice and staff should only be logged onto workstations with standard user rights. If malware is executed we want to limit the impact and also the potential for the user to install unauthorised software and break functioning business software. This might be a good opportunity to roll out a standard operating environment, a build that is locked down from an end user perspective and where software is remotely managed and maintained.
For staff with administrative privileges to the domain and applications, separate admin accounts should be created. This account should have appropriate (least privilege) permissions for the task, and should be linked to the user and not be generic. It’s important that this account is separate to the users day to day account. Think admin_johnsmith.
Admin level accounts as mentioned above should not have internet access or access to email. This way they are much less likely to come in contact with malware.
The principle of least privilege should be adhered to. In an Active Directory environment this means limiting administrative permissions based on group or delegation. For instance does a database or backup administrator also need to be a domain administrator? Does a service account need to have domain administrative privileges? Certainly in many cases, accounts are made a domain or enterprise administrator for convenience, but this is often not necessary.
Generic privileged accounts should be avoided where possible. If this is not possible then privileges should be restricted to the lowest level possible. This includes admin accounts on network devices like firewalls and switches. These should be named accounts linked to a staff member.
Privileged administrative tasks should be logged and audited. It’s important to be able to detect malicious or inappropriate use of credentials.
These ideas will help you get started, good luck.
Colin has over 20 years consulting experience working with organisations ranging from small business to large enterprises. He has consulted in the United Kingdom, Canada and Australia. He specialises in Microsoft based technology solutions, disaster recovery implementations and information security.