Please take some time to read all of the previous articles on the updated Essential Eight Maturity Model; the links are at the bottom of this article.
With cyber crime costing the Australian economy an estimated $42 billion per year1 , it stands to reason that organisations must do whatever possible to lock out intruders. As with any highly secure physical environment, there is the need to manage, maintain, and provide services, and special administrative privileges are granted for this purpose.
Just like in a secure environment such as a jail, virtual keys to the IT environment are given to trusted individuals so that they can perform essential tasks. Like that jail, handing out too many keys would compromise security. No matter how good the intentions, poorly managed admin rights increase the frequency and severity of breaches to cyber defences. Fortunately, many of the measures in the Essential Eight can be introduced quickly and effectively.
Where should you start?
As with most Essential Eight controls, there’s a lot to take in to get your Admin Privileges secured to the max. Take inventory before reviewing the roles that have administrator privileges. Review your policies, make a plan and run it through proper change management. With a plan in place, you can start on the clean-up. Remember to take your time, restricting administrative privileges won’t happen overnight. However, let’s get you started with a look at Maturity Level 1, 2 and 3.
Every organisation should strive for a minimum of maturity level one in order to demonstrate a responsible approach to securing their systems and data. In some industry sectors, this may be mandated.
“Requests for privileged access to systems and applications are validated when first requested.”
Keeping on with our jail analogy from earlier, you wouldn’t hand those jail keys to just anyone who asked for them, and the same goes for handing out admin privileges. The fewer people who can inadvertently open a door to cyber criminals, the better, so limit numbers to only those with a valid reason.
I’d recommend defining which specific environments each admin needs to access and restrict the rest. In the jail, a guard may only need to access certain cell blocks, and only after his credentials are checked, whereas the governor can access all areas. Similarly, the someone who needs admin rights for a group of SQL servers may not need the same privileges for a firewall.
“Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services.”
Internet, email and web services are common attack vectors, so using a privileged login to check Facebook or catch up on emails gives malicious actors a fast track to critical systems. In a busy environment, it is all too easy for an admin to momentarily forget which login they are using and click on an incoming email, so this is best not left to chance.
“Privileged users use separate privileged and unprivileged operating environments.”
For this control, imagine someone wanted to break a friend out of that jail. Even if he somehow acquires a key to the front gate, it won’t get him into the cell blocks, control room, or admin offices, so he won’t get far. If, though, someone with an entire set of master keys sits just inside the front gate, we have the entire prison population on the run. Keeping the privileged and unprivileged environments separate makes it harder for admin activities and privileged accounts to be compromised.
“Unprivileged accounts cannot logon to privileged operating environments.”
Some parts of your IT environment are undoubtedly more sensitive than others. Areas requiring a higher level of security, such as database servers, for example, should be classified as privileged operating environments, and accordingly, they should be limited only to admin users with a higher level of trust. It is important to remember that just as the guards will not need to access all areas of the jail, so all admins do not need to access every privileged operating environment.
“Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.”
A similar scenario applies in reverse – those high trust accounts are at far greater risk of compromise if they log on to unprivileged operating environments, just as the guards wouldn’t take the cell block keys in their jacket pocket when they stop for an after-work drink after a long day.
All level one measures must be in place, along with a number of more stringent additional actions, in order to achieve the more challenging level 2 status.
“Requests for privileged access to systems and applications are validated when first requested.”
(As above, ML1) Keeping on with our jail analogy from earlier, you wouldn’t hand those jail keys to just anyone who asked for them, and the same goes for handing out admin privileges. The fewer people who can inadvertently open a door to cyber criminals, the better, so limit numbers to only those with a valid reason.
I’d recommend defining which specific environments each admin needs to access and restrict the rest. In the jail, a guard may only need to access certain cell blocks, and only after his credentials are checked, whereas the governor can access all areas. Similarly, the someone who needs admin rights for a group of SQL servers may not need the same privileges for a firewall.
“Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services.”
(As above, ML1) Internet, email and web services are common attack vectors, so using a privileged login to check Facebook or catch up on emails gives malicious actors a fast track to critical systems. In a busy environment, it is all too easy for an admin to momentarily forget which login they are using and click on an incoming email, so this is best not left to chance.
“Privileged users use separate privileged and unprivileged operating environments.”
(As above, ML1) For this control, imagine someone wanted to break a friend out of that jail. Even if he somehow acquires a key to the front gate, it won’t get him into the cell blocks, control room, or admin offices, so he won’t get far. If, though, someone with an entire set of master keys sits just inside the front gate, we have the entire prison population on the run. Keeping the privileged and unprivileged environments separate makes it harder for admin activities and privileged accounts to be compromised.
“Unprivileged accounts cannot logon to privileged operating environments.”
(As above, ML1) Some parts of your IT environment are undoubtedly more sensitive than others. Areas requiring a higher level of security, such as database servers, for example, should be classified as privileged operating environments, and accordingly, they should be limited only to admin users with a higher level of trust. It is important to remember that just as the guards will not need to access all areas of the jail, so all admins do not need to access every privileged operating environment.
“Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.”
(As above, ML1) A similar scenario applies in reverse – those high trust accounts are at far greater risk of compromise if they log on to unprivileged operating environments, just as the guards wouldn’t take the cell block keys in their jacket pocket when they stop for an after-work drink after a long day.
“Privileged access to systems and applications is automatically disabled after 12 months unless revalidated.”
This one is straight-forward. Roles change, environments are not static, so it makes sense to review all privileged access at least annually and require all privileged access to be validated again.
Third party tools are the best and most reliable way to achieve this requirement with regular cadence.
“Privileged access to systems and applications is automatically disabled after 45 days of inactivity.”
If privileged access is to be granted only as needed, it stands to reason that if it is unused for 45 days, it is likely that the privilege is no longer needed. This control is intended to catch any unnecessary access that has been otherwise overlooked.
“Privileged operating environments are not virtualised within unprivileged operating environments.”
A virtualised environment may not sufficiently separate privileged and unprivileged operating environments for administrators, so this should be avoided.
“Administrative activities are conducted through jump servers.”
If you’re thinking “what’s a jump server?” let me explain that first. A jump server, pivot server, jump host or jump box is a hardened device on a network that spans two or more alternate security areas, providing a secure means of access between environments. Administrators use the segregated server to “jump” safely between environments.
Using a jump server prevents direct access to sensitive servers – it is the equivalent of the multiple physical layers that a jail would use before reaching the inner sanctum.
“Credentials for local administrator accounts and service accounts are unique, unpredictable and managed.”
You wouldn’t allow multiple prison guards to share an access card, and nor should admin accounts be shared. Every admin account must be unique, so that actions are trackable, and access tailored to the admin’s specific role.
“Use of privileged access is logged.”
No need to explain this one in great detail. When use is logged, it gives a greater ability to review the actions that contributed to a breach and address them. In the event of a breach where an admin logon is compromised, organisations can more quickly and easily detect malicious actions and better manage the response.
“Changes to privileged accounts and groups are logged.”
Given the power that comes with privileged accounts, it is necessary to keep tight controls over them, and to understand the who, when, and why of any changes. Aside from creating a trail that can be evaluated in the event of a security incident, it also ensures a higher level of responsibility – much like a record should be kept of who gave a guard the key to a new work area in the jail.
To achieve the more stringent maturity level 3, organisations must meet all requirements for levels 1 and 2, plus additional measures that add further strength to their security posture.
“Requests for privileged access to systems and applications are validated when first requested.”
(As above, ML1) Keeping on with our jail analogy from earlier, you wouldn’t hand those jail keys to just anyone who asked for them, and the same goes for handing out admin privileges. The fewer people who can inadvertently open a door to cyber criminals, the better, so limit numbers to only those with a valid reason.
I’d recommend defining which specific environments each admin needs to access and restrict the rest. In the jail, a guard may only need to access certain cell blocks, and only after his credentials are checked, whereas the governor can access all areas. Similarly, the someone who needs admin rights for a group of SQL servers may not need the same privileges for a firewall.
“Privileged accounts (excluding privileged service accounts) are prevented from accessing the internet, email and web services.”
(As above, ML1) Internet, email and web services are common attack vectors, so using a privileged login to check Facebook or catch up on emails gives malicious actors a fast track to critical systems. In a busy environment, it is all too easy for an admin to momentarily forget which login they are using and click on an incoming email, so this is best not left to chance.
“Privileged users use separate privileged and unprivileged operating environments.”
(As above, ML1) For this control, imagine someone wanted to break a friend out of that jail. Even if he somehow acquires a key to the front gate, it won’t get him into the cell blocks, control room, or admin offices, so he won’t get far. If, though, someone with an entire set of master keys sits just inside the front gate, we have the entire prison population on the run. Keeping the privileged and unprivileged environments separate makes it harder for admin activities and privileged accounts to be compromised.
“Unprivileged accounts cannot logon to privileged operating environments.”
(As above, ML1) Some parts of your IT environment are undoubtedly more sensitive than others. Areas requiring a higher level of security, such as database servers, for example, should be classified as privileged operating environments, and accordingly, they should be limited only to admin users with a higher level of trust. It is important to remember that just as the guards will not need to access all areas of the jail, so all admins do not need to access every privileged operating environment.
“Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.”
(As above, ML1) A similar scenario applies in reverse – those high trust accounts are at far greater risk of compromise if they log on to unprivileged operating environments, just as the guards wouldn’t take the cell block keys in their jacket pocket when they stop for an after-work drink after a long day.
“Privileged access to systems and applications is automatically disabled after 12 months unless revalidated.”
(As above, ML2) This one is straight-forward. Roles change, environments are not static, so it makes sense to review all privileged access at least annually and require all privileged access to be validated again. Third party tools are the best and most reliable way to achieve this requirement with regular cadence.
“Privileged access to systems and applications is automatically disabled after 45 days of inactivity.”
(As above, ML2) If privileged access is to be granted only as needed, it stands to reason that if it is unused for 45 days, it is likely that the privilege is no longer needed. This control is intended to catch any unnecessary access that has been otherwise overlooked.
“Privileged operating environments are not virtualised within unprivileged operating environments.”
(As above, ML2) A virtualised environment may not sufficiently separate privileged and unprivileged operating environments for administrators, so this should be avoided.
“Administrative activities are conducted through jump servers.”
(As above, ML2) If you’re thinking “what’s a jump server?” let me explain that first. A jump server, pivot server, jump host or jump box is a hardened device on a network that spans two or more alternate security areas, providing a secure means of access between environments. Administrators use the segregated server to “jump” safely between environments.
Using a jump server prevents direct access to sensitive servers – it is the equivalent of the multiple physical layers that a jail would use before reaching the inner sanctum.
“Credentials for local administrator accounts and service accounts are unique, unpredictable and managed.”
(As above, ML2) You wouldn’t allow multiple prison guards to share an access card, and nor should admin accounts be shared. Every admin account must be unique, so that actions are trackable, and access tailored to the admin’s specific role.
“Use of privileged access is logged.”
(As above, ML2) No need to explain this one in great detail. When use is logged, it gives a greater ability to review the actions that contributed to a breach and address them. In the event of a breach where an admin logon is compromised, organisations can more quickly and easily detect malicious actions and better manage the response.
“Changes to privileged accounts and groups are logged.”
(As above, ML2) Given the power that comes with privileged accounts, it is necessary to keep tight controls over them, and to understand the who, when, and why of any changes. Aside from creating a trail that can be evaluated in the event of a security incident, it also ensures a higher level of responsibility – much like a record should be kept of who gave a guard the key to a new work area in the jail.
“Privileged access to systems and applications is limited to only what is required for users and services to undertake their duties.”
It stands to reason that different admins perform different tasks. One may need to add users, another may need to make changes to key systems. By allowing least privileged access, even if an admin’s account is compromised, the potential damage is restricted.
“Privileged accounts are prevented from accessing the internet, email and web services.”
Where on maturity level 1, there was a requirement for admins to use two separate accounts, here the level of control is strengthened even further. We can all make mistakes when we are busy, and admins are no exception – so this measure means that if someone forgets they are using their admin credentials, they can’t accidentally watch that cat video on YouTube that their co-worker just sent.
“Just-in-time administration is used for administering systems and applications.”
There’s seldom a need to stay logged on with an admin account all day, so maturity level 3 requires admin logon time to be restricted. For example, if a logon is used to patch a system, a more advanced third-party toolset can allocate an appropriate amount of time to complete the task and then terminate the logon.
If we continue the analogy of the jail, a guard may need a key to open a door into a high security wing, but we don’t want him to leave the door unlocked or run the risk of an unattended key being used for unapproved actions – better instead that it locks automatically behind him.
“Windows Defender Credential Guard and Windows Defender Remote Credential Guard are enabled.”
Cyber criminals don’t just turn up at your virtual front door and tell you the truth about who they are. Windows Defender Credential Guard is designed to do just what the title says – it makes sure users match their credentials, by isolating user login information from the rest of the operating system to prevent theft or wrongdoing.
As you might expect, this particular control is unique to Windows environments. Don’t forget you’re highly likely to have other operating systems installed. I recommend you investigate what credential controls are available in all relevant operating systems, to that they are all protected.
“Use of privileged access is centrally logged and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.”
When using just in time admin, it is then possible – and recommended – to maintain a log of what is requested, when, who authorised it, and what action occurred in the form of keystroke logging and screenshots. This can be used to try to pick up any unauthorised issues.
“Changes to privileged accounts and groups are centrally logged and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.”
Records of actions and changes are enormously valuable when investigating cyber events, so it stands to reason that businesses don’t want anyone to intentionally or inadvertently cover the traces of any issue. There are several Microsoft and partner tools that can perform this function in the Microsoft environment, and in non-Windows environment, Delinea Thycotic and Centrify are worth a look. The more accurate the data, the clearer the picture of the situation and the more effectively it can be resolved with the least amount of damage.
It is important that organisations avoid taking a piecemeal approach. We often see the more commonly used Microsoft servers or network files being protected but platforms that are seldom touched can be easily forgotten, and people may be more tempted to use simple passwords. A good plan should cover your entire environment, network, server farms, hypervisors, physical machines – even connected AV devices, printers and sensors. Absolutely everything that is connected should be subject to the same security approach. The kitchen window at the jail should be secured just as the front gate is protected.
Want to know more about the Essential Eight maturity levels? Check out our other blogs, or chat with the Data#3 security practice.
Using the ACSC recommendations as a framework, Data#3 has built an Essential Eight Assessment to help organisations understand and improve their security posture.
The Essential Eight Assessment is a 5-day engagement, conducted by a Data#3 Information Assurance Specialist, including up to 2 days spent onsite with the customer.
This is blog 6 of a 9-part series. See earlier posts on:
1. Your guide to the ACSC’s Essential Eight Maturity Model
2. Essential Eight Maturity Model: Application Control
3. Essential Eight Maturity Model: Patch Applications
4. Essential Eight Maturity Model: Configure Microsoft Office Macro Settings
5. Essential Eight Maturity Model: User Application Hardening
6. You are here.
7. Essential Eight Maturity Model: Patch Operating Systems
8. Essential Eight Maturity Model: Multi-Factor Authentication
9. Essential Eight Maturity Model: Regular Backups