15 Feb (E)SAE DEEP DIVE SERIE PART 7 – Tiering Model
After we wrote about the new Microsoft Securing Privilege Access Model in our last blog article, we would like to discuss the classic ESAE tiering this time. First, we would like to point out that the new Microsoft model no longer refers to tiering, but to levels of security (Privileged Access, Specialized Security and Enterprise Security). More on this in a moment, just keep in mind that we will come back to the Levels of Security in a moment. But now, as an introduction to this blog, to our infographic on the Tiering Model:
Why divide the infrastructure into different tiers or levels? Microsoft wrote about this in the original ESAE documentation:
„The purpose of this tier model is to protect identity systems using a set of buffer zones between full control of the Environment (Tier 0) and the high risk workstation assets that attackers frequently compromise.“
So, the goal is to create one or more buffers between systems that manage identities and the systems with high risk of attacks. Whether only systems that manage identities need/should be protected and which are the high-risk systems will be discussed in the next section.
How to do tiering?
Again, first take a look at the Microsoft documentation. To protect the systems, the accounts must be protected with administrative access. The tier model therefore revolves around the protection of these accounts and provides for 3 tiers in the standard:
Tier 0: Administrative accounts that have direct or indirect control over enterprise identities (as opposed to local identities e.g. local SQL accounts)
Tier 1: Administrative accounts that have control over enterprise servers and applications
Tier 2: Administrative accounts that have control over end users, workstations, and devices
At this point again a short comparison to the Levels of Security from the new Microsoft Model (Privileged Access, Specialized Security and Enterprise Security). So there are still 3 levels, or should we say tiers? 😉
In the new model, Privileged Access is the most secure layer, i.e. Tier 0, followed by Specialized Security (could be compared to Tier 1) and finally Enterprise Security, which, similar to Tier 2, comprises all enterprise-wide security controls. Even though Microsoft has renamed the levels, the idea is still to define different layers according to protection needs and to seal them off from each other. But now back to tiering….
How should administrative access be protected in concrete terms? Microsoft sees the restriction of access as the primary protection mechanism here:
These screens are described by Microsoft as follows:
- Tier 0 accounts administer Tier 0 systems and can interactively log on to Tier 0 systems only
- Tier 0 accounts can control assets in each tier
- Tier 1 accounts administer the Tier 1 systems and can interactively log on to Tier 1 systems only
- Tier 1 accounts can read access assets on Tier 0 (“via network logon type”)
- Tier 1 accounts can control assets in Tier 1 and 2
- Tier 2 accounts administer Tier 2 systems and can only log on to Tier 2 systems
- Tier 2 accounts can access assets in all tiers (“via network logon type”)
- Tier 2 accounts can control assets in Tier 2
In addition to restricting access, Microsoft lists numerous other protective measures in the documentation. However, the description would go beyond the scope of this article. We therefore refer again to the documentation as well as our first (E)SAE blog series.
So much for the documentation. Now some answers to questions we have encountered in projects.
Do there have to be exactly three tiers?
No, we have already seen that the server tier (1) is subdivided into infrastructure and business servers or into servers that are worth protecting and servers that are less worth protecting. You should analyze the protection requirements in the specific situation and compare them with other aspects such as usability, and then decide how many tiers are best for the current context.
Are only “identity systems” allowed in Tier 0?
Again, no. If the risk analysis shows that another system has the same protection needs as the “Identity Systems” and can be operated with the same processes, another system can also be assigned to Tier 0. However, the principle of keeping the number of administrators in Tier 0 as low as possible should be observed. In practice, therefore, it is usually left with the “identity systems” in Tier 0 and the server tier is subdivided as described above.
However, systems that can control a Tier 0 system (“indirect control of enterprise identities”) should not be forgotten. Think, for example, of a monitoring or backup agent that is operated in the system context. These systems must either be regarded as Tier 0 or separate Tier 0 instances must be set up.
At least the following systems are to be treated as Tier 0:
- Active Directory Domain Controller
- Azure AD connect
- Federation services
- PKI systems
- Privilege Administrative Workstations
- IAM Systems
- PAM systems
- Systems managing other Tier 0 systems
How can this separation be implemented in practice?
The separation is done with a combination of OUs, groups and group policies. In simplified terms, it might look like this:
There is one OU per tier with further sub-OUs for logical separation of servers, users and groups, etc. In each tier there is a group in which all admin accounts are members.
For Tier 1 and Tier 2, there is one GPO each in which the logon restrictions are configured.
In Tier 1 policy, Tier 0 admins are denied logon.
In the Tier 2 policy, both Tier 0 and Tier 1 admins are banned from logon.
Implementing tiering is a task that should not be underestimated, especially in evolved environments. However, it is an important cornerstone for many further measures and a massive security gain, as it makes lateral movement by attackers very difficult. If in doubt, it is best to isolate only Tier 0 systems first. Only then are Tier 1 and Tier 2 systems protected. This has the advantage of sealing off the most important systems and at the same time allowing experience to be gained with the tiering model. This makes it easier to expand to Tier 1 and 2 at a later stage.
In our January blog, we started an SAE deep dive series and explained how to use Hyper-V as a secure hypervisor in an (E)SAE scenario. Since by far not all our customers use Hyper-V, but many also use VMWare...15 June, 2020
(E) SAE Deep Dive Series Part 1: Hyper-V Host Guardian Service (HGS) and Shielded VMs in an EASE Environment
After the success of the first ESAE series, we decided to launch a deep dive series in which we go into a little more detail on various measures....16 January, 2020
After Hyper-V HGS and VM protection with VMWare, now the third part of our (E) SAE Deep Dive Series follows. Maybe you follow us on LinkedIn, Xing, Facebook, Instagram or Twitter and ...15 July, 2020