In recent years, organisations have undertaken major projects to secure their Active Directory (AD). These projects have been launched to counter the threat of a massive compromise of the AD system in order to deploy ransomware, of which there are unfortunately many examples in the news. The key measure in securing the AD is the implementation of tiering, a layered security model recommended by Microsoft and the ANSSI, to prevent the compromise of high-privilege accounts in the AD. Such projects often come up against an existing project that is either ongoing or recently completed in the organisation: the PAM project. Most organisations embarking on this vast project have already put in place protective measures around these accounts, which do not take into account the three-tiered view that the security model brings. Privileged Access Management (PAM) and its implementation, mainly exists through bastions, and is often not perfectly aligned with the precepts of tiering. Indeed, the PAM project often structures its approach around business sensitivities or operational responsibility perimeters, whereas the tiered model proposes an approach by component type. So let us explore this relationship more clearly…

 

Reminders on tiering

 

Tiering is a security model that is applicable to Active Directory. The main idea is to separate privileged accounts into different layers (tiers) and functional scopes, in order to restrict possible use to their originating tier only, so that if one tier is compromised, it does not lead to the compromise of other tiers. This allows, for example, to contain a ransomware attack in the original tier of the attack only, or to prevent the classic scenario of discovery and replay of a domain administrator credentials on a workstation. Typically, the model breaks down as follows:

 

• Tier 0 is the most critical. It consists of the AD itself, i.e., the domain controllers that carry it, as well as the components that interact directly with it, or that can compromise it by rebound. These are typically the ADLDS, ADCS, PKI, but also the IT components necessary for its operation: hypervisors, SCCM, SCOM, backup, and dedicated administration stations (PAW, for Privileged Access Workstation). The administration accounts for these components are those with the highest privileges, as they are necessarily the domain administrator accounts (the accounts with rights over the entire Windows estate of the organisation), but also the accounts of the other components that can indirectly assign themselves domain administrator rights, through interaction with the domain controllers.
• Tier 1 typically consists of the company’s applications and the servers that host them. The privileged accounts are therefore those of the functional administrators of the applications as well as those of the technical administrators of the servers.
• Finally, tier 2 includes everything that revolves around the user environment. In addition to the accounts and office workstations, we can find printers, telephony, as well as all the accounts for the different levels of user support.

To make it possible to seal off the tiers, and therefore limit the scope of compromise, “deny logon GPOs” (simpler to set up) or Authentication Policy Silos (more secure) are set up, to prohibit an account from a higher tier connecting to a component belonging to a lower tier. Also, another objective of the tiering implementation project, which may have an impact on PAM, is to restrict the number of tier 0 administrators to a minimum, again with a view to reducing the attack surface and the scope of a potential compromise. Having established this new concept, let us look at what already exists.

 

Bastion? Did you say bastion?

 

The security bastion is a very common tool used by organisations to implement PAM. The principle is to host privileged accounts in secure vaults, and to enforce administrator logins (with a non-privileged account) to a central bounce machine, which will play these privileged accounts for the administrator, without revealing their password. Another advantage of the bastion for organisations is the ease with which they can set up multi-factor authentication, the recording and traceability of administration actions, the automated management of password rotation, etc.

So far, there is nothing incompatible with the tiering model. And yet there are similarities. The structure of privileged accounts that was created in the bastion (by perimeter and/or by functional team and/or type of component, etc.), was created without consideration of the concept brought about by the AD security project: the notion of tiering.

In order to identify the potential impacts, let us place ourselves in the perspective of tiering and ask the questions simply in relation to the bastion.

How to adapt the bastion to the tiering model?

 

If one were to synthesise the problem to be solved, this would give the above diagram. To adapt it successfully, choices must be made.

 

Should the bastion be placed in a specific tier? Should it be duplicated in each tier?

As described in the diagram from a purely theoretical point of view of tiering, there should be an instance of a bastion in each tier, and perhaps even an instance from different publishers in order to protect against a 0-day flaw in the technology used. But the measure comes up against a financial reality, as the possession of several bastions has a certain cost, coupled with an operational reality that does not support the multiplication of tools for the same need. Fortunately, adaptations are possible. In reality, no company puts a bastion on tier 2. As this tier is relatively homogeneous and monolithic in terms of responsibility, it is allowed to connect directly to it, obviously through a tier 2 privilege account, or with the local administrator account (protected by LAPS) which has the advantage of being robust with respect to a total compromise of tier 2 in the event of the compromise of a single tier 2 privilege account.

For tiers 0 and 1, their fate is linked and depends on both the context of the organisation and the existing situation. The first option, as mentioned, is to deploy a dedicated bastion in each tier. Being a bit more realistic , if only one bastion instance is possible, then this should necessarily be positioned in tier 1. The reason for this choice is very simple: the bastion meets a functional need for administration, and the largest number of machines and accounts are in tier 1, as opposed to tier 0, where you want to restrict exposure (i.e., the number of administrators who have access).

Tier 0 can be more simply managed by PAWs, dedicated and hardened administration workstations with the specific purpose of accessing privileged accounts and resources. Access to the network area which hosts tier 0 is subject to a VPN connection, authorised only from these PAWs. There are organisations that have done a combination of both: bastion and PAW. This implementation remains perfectly valid from a security point of view, but its feasibility depends on the company’s ability to deploy PAWs for all its tier 1 administrators, which represents a much larger target population and cost. One last point to conclude this topic: the use of bastion and PAW are compatible, and the security benefits are complementary for the protection of privileged accounts.

 

In the case of a single bastion, can the other tiers be administered via the bastion?

This would simplify things, but unfortunately it is not desirable. Administering tier 0 from tier 1 would break the whole segmentation we are trying to implement, especially because privileged tier 0 accounts would be hosted in tier 1 and accessible by the tier 1 administrators of the bastion. That said, a tiny possibility of this implementation exists, but it is very technology-dependent, as very few bastions offer the appropriate functionality. In principle, by placing the bastion in tier 0, administered by tier 0, it would be possible to create groups of rebound machines, as well as dedicated (logical) vaults, active or passive, in each tier. However, it should be noted that the few organisations that have tried this are now retreating from the technical management of the vaults and the administrative burden involved.

 

 

Should the allocation and distribution of accounts in the bastion be reviewed?

Not necessarily, but again, it depends on the context and the existing situation. Firstly, the accounts from each tier must be hosted in different safes, in order to respect the segmentation and watertightness of each tier. If necessary, there is nothing to prevent the vaults from being broken down into sub-areas within each tier to suit the existing technical or functional organisation (e.g., teams responsible for the MCO/MCS of components hosting databases are different from those responsible for the MCO/MCS of business applications). Finally, it is recommended that as many named accounts as possible be used, rather than generic or shared accounts. While there is nothing to prevent the use of a single administrator account for all tier 1 servers used by all administrators within the perimeter, and this method of operation does not contravene the principles of tiering , it is still preferable to be able to immediately identify the owner of the account that performed the action, in order to better control the accesses and authorisations of each person, even if the stronghold would still allow the identity to be traced indirectly by cross-checking the logs.

 

Providing a good framework for the implementation of tiering

 

Tiering is currently the project that most reduces the risk of compromise of high-privilege accounts and the AD in general. However, it is also a complex subject, which has a lot of impact on all infrastructures, and which requires many adaptations to the existing system for its implementation to be considered successful. As PAM is an essential building block for the management of these administrative accounts and accesses, it is necessary to ensure that its implementation does not interfere with the principles of tiering, or even break down the segmentation and isolation into layers. If there is only one thing which must be remembered to succeed in this transformation, it would be that the implementation of tiering, contrary to popular belief, is far from being a simple AD subject,  but rather that it must lead to a rethinking of all administration practices in their entirety.