An excellent article from Andy and team at Spector Ops, as usual.
He mentions something about which there is still great misunderstanding: the concept of “Tier 0”. This terminology started with the Active Directory Tiered Administrative Model (though you could argue it was a concept in the access control models which preceded it, such as Biba and Bell-LaPadula).
In the original AD Tiered Admin Model, the scope of “Tier 0” was the accounts with Domain/Enterprise Admin privileges (or equivalent), plus anything which could be used to gain control over those accounts.
This last bit was where it got interesting—because it meant that any other user account, hardware, or software which had a control relationship with a DA/EA account was in-scope: upstream management tools with admin control over DCs, any devices the admins used, and so on. As orgs tried to implement the tiering model, this was where compromises were typically made—but in so doing, the isolation of Tier 0 was incomplete, and therefore ineffective.
Remember the principle enshrined in these access control models: if A can control B, and B can control C, then A can control C, whether you like that/intended that or not. This is why the Tiering Model required isolation of the full scope of Tier 0 to be effective; attackers would simply identify the Tier 1 or 2 assets which had a control relationship with a Tier 0 asset, compromise the lower tier device, and then use that control relationship to pivot to control over the Tier 0 asset.
The other issue was that the model was created for a world that no longer exists. With the advent of cloud, you can’t just wall off your identity infrastructure in some bastion forest; this is why Microsoft created the Enterprise Access Model a few years back, because it takes the concepts of Tier 0, translates them into Control Plane language, and shows how to implement those principles in modern access control scenarios.
Back to Andy’s point: All of these principles (such as the transitive nature of control) are still relevant, but they now extend far beyond traditional Active Directory. Entra ID, Application, and API permissions create toxic combinations which grant unintended access, because we fail to recognize the control relationships between the components, and either break (or tightly govern) those relationships before attackers discover them.
Fortunately there are tools which help to enumerate these relationships, but they cannot replace the principled approach to securing Control Plane/Tier 0 assets by first understanding control relationships. If you can work that into the culture of the way your organisation thinks about and architects access control, it will head off many issues before they begin.