It is widely accepted that the largest threat posed to many organisations comes from insiders, either through accidents or malicious behaviour. Identity and access management tools are used by organisations to protect their information, from both internal and external threats. IDAM isn’t the only thing an organisation needs to be secure, but it’s a good place to start. For a long time, Active Directory has been the de facto IDAM solution that organisations use to manage their internal resources, and with AD making it to the Gartner leader’s quadrant in 2017 it’s safe to say it will be around for a long time yet.

How can we leverage Active Directory to protect against the insider threat?

Active Directory allows security engineers and dev ops to apply controls to the user groups in a number of ways in order to limit threats to the organisation from both insiders and outsiders.

The most well-known set of policies which protect an organisation from its own people fall under Role Based Access Control (RBAC). RBAC largely does what it says on the tin: permissions are given to users based on the access they need to perform their jobs. If a certain tool doesn’t fall into the user’s particular remit, they won’t be given access to it.

RBAC is a useful baseline for organisations when it comes to limiting the amount of damage a particular user can do. Good RBAC policies, built on the principle of least privilege, could stop users from accidentally deleting the entire github repository for example. It won’t stop them from accidentally deleting their own work, but that particular risk can also be managed by backups.

RBAC can also be used to enforce Segregation of Duties. Segregation of Duties means having a work system where:

More than one person is responsible for completing tasks in each area.

One person is not responsible for multiple areas which intersect.

When Segregation of Duties is implemented, fraudulent behaviour in any individual area should be noticed by the other user working in that area. Additionally, a single user will not be able to make changes to cover up nefarious behaviour as they will not have access to other areas of work.

Under a system of Segregation of users cannot work in isolation, and others are informed of what they are working on. This idea underpins another set of IDAM policies: Intention Based Access Control (IBAC). IBAC is an evolution of RBAC and boils down to users requesting access to certain tools to do certain things. For example, if the financial officer only needs access to the financial reporting tool once a month for four hours, it would make sense for them to request access for this tool when they need it rather than having the permissions permanently tied to their credentials.

The one policy to rule them all: Eligible Admin Permissions

As of November 2018 it is possible to enforce a system of IBAC across administrators in Azure Active Directory when using Privileged Identity Management. The ‘Eligible Admin’ policy within Azure allows users to be eligible for admin permissions, rather than having them enabled on an account at all times.

Eligible Admins roles are replacements for Permanent Admin roles. A Permanent Admin is a user who has admin permissions assigned to their credentials and they have those permissions all the time. This is true whether they are working in the capacity as an admin 9-5 every day or need the permissions once a quarter to run a script. Permanent admin permissions also apply at the weekend and when the users are on holiday. This is essentially an unnecessary risk exposure, especially considering that the role of Global Admin within AAD is extremely powerful, including for example the ability to change any other users’ password – not something that should be put in the wrong hands.

Eligible admins have the ability to request admin permissions but do not have admin permissions constantly. In order to get admin permissions, the users must request them for a specified amount of time, and another user must review their reasoning and either grant or reject the request. If granted, the eligible admin will then have those permissions for that time frame. The fact that these permissions must be requested moves the organisation from RBAC to IBAC. It also means that if an admin account is compromised, it won’t be able to execute actions as an admin without requesting permission to do so.

All users who need admin (particularly global admin) privileges can and should be converted to eligible admins. However, a word of warning against removing all permanent admin accounts: instead of having no global admin accounts, set up break glass accounts.

Break glass accounts are accounts that should only be used in the case of emergency and have root user or global admin powers. Break Glass Accounts are not assigned to a particular user and again should only ever be used in the case of emergencies. The passwords for Break Glass Accounts are usually printed out, split into 3-5 different sections and those sections are then kept in separate locations. Break Glass Accounts are only used in the case of losing access to all other admin accounts on a system.

IBAC ensures that users only have access to what they need when they need it – protecting an organisation both from user error, malicious insiders and compromised accounts. A system of IBAC effectively reduces the risk posed by the largest threat that an organisation faces.

And External threats?

Finally, in addition to implementing systems to protect organisations from insider threats it would be remiss not to mention the easiest way to protect from external threats: introducing Multi-factor authentication on all user accounts. Since implementing MFA across all user accounts a year ago, roughly 80,000, Google hasn’t had a single reported or confirmed account take over. Ensuring MFA on organisations accounts ensures that external attackers will struggle to take over your user’s accounts as they’ll have to compromise two methods of authentication rather than one.