Last Update: Sep 04, 2024 | Published: Jan 11, 2018
In this Ask the Admin, I’ll explain how to integrate the clean source principle into your Active Directory design and management practices to keep your systems secure.
The clean source principle (CSP) is important in information system security and states that a system can be dependent on a higher trust system but not on a lower trust system. In practice, this means that you should identify all of an object’s security dependencies and make sure that they are as trusted as the object you are trying to secure.
Any subject that controls an object is a security dependency of the object. Let’s take the example of a domain controller (DC). A DC’s security dependencies (subjects) are other objects that have direct or indirect control of the DC. Domain administrator accounts and workstations, where domain administrators log in, are both subjects. If a hacker can compromise a domain administrator account or a workstation that a domain administrator uses, they can get effective control of the domain controller.
Understanding the security dependencies in your environment might not be as simple as it first seems. The best way to analyze security dependencies is to look at control relationships. I can determine that domain administrators are in control of domain controllers but the workstations they log in to are also subjects because control is transitive.
Domain administrator accounts and the workstations they log into must be secured to the same level as my domain controllers. You can recursively repeat this process to establish all an object’s security dependencies. If the workstations used by domain administrators are subjects, by this logic I can also establish that the workstation hardware and OS installation media are also subjects. To secure the DCs, I need to trust the workstation hardware used by domain admins to the same level as I would trust hardware deployed for domain controllers and secure the OS installation media source appropriately.
Once you’ve got your head around CSP, you can see that it is mainly common sense. But that doesn’t stop us ignoring CSP in our environments. Domain administrator privileges are often handed out to IT staff on a permanent basis with little consideration. And those same users log in on workstations that aren’t hardened to protect highly-privileged credentials.
Microsoft recommends using specially hardened workstations (Privileged Access Workstations) for administering sensitive systems like domain controllers. Jump servers, admin virtual machines (VMs), and Privileged Access Management (PAM) solutions can help mitigate some attacks but don’t meet the requirements of CSP.
Servers designated exclusively for administration tasks (jump servers) rely on the security of the remote PC from which they are accessed. So, jump servers should only be used if they are accessed from Privileged Access Workstations.
Admin VMs that are hosted on standard user workstations are dependent on the workstations for their security, which violates CSP. If you want users that have domain admin privileges to use a single device, deploy standard user VMs on Privileged Access Workstations, not the other way around.
PAM solutions that give users elevated privileges on demand, or according to predefined rules, must be used carefully to make sure that CSP isn’t violated. Using PAM to grant domain administrator privileges to a user that’s logged into a standard workstation is a security risk because it doesn’t adhere to the clean source principle.
CSP can be applied in cases where you need to secure sensitive objects, for instance, database servers, network infrastructure, and domain controllers. Security is rarely convenient but the payoff will be a hardened infrastructure that is harder to penetrate. In a future Petri article, I’ll show you how to configure Privileged Access Workstations.
Follow Russell on Twitter @smithrussell.