Active Directory security threats are increasing per part 1 of this post, and organizations must deploy an array of preventative, procedural, and detection controls to avoid becoming one of the next victims.
The AD protection matrix above depicts a number of security issues that contribute either to domain-wide risk, or put resources in the domain at risk should they be targeted by attackers. For each issue, the matrix identifies good practices and controls for the remediation.
Preventative Controls
For the most part, physical security, network security, vulnerability/configuration management, and logical access management controls are assumed as pre-requisites that help prevent the AD content and/or domain controller (DC) servers from being compromised by internal or external threats. For additional detail, see the ISACA Windows Active Directory Audit/Assurance Program (login required) and the CIS Microsoft Windows Server 2012 R2 Benchmark with its 437 references to the protection mechanisms (not all preventative) specifically for servers filling the DC role.
Procedural Controls / Organization
Maintaining just the preventative controls for any non-trivial AD deployment can be a major undertaking that – in a large enterprise environment – requires the full backing of the responsible IT / security organizations, an architecture for the AD forest(s), and security policies, processes, and procedures. The ISACA assurance manual mentioned earlier is a good one-stop shop for identifying and assessing whether there is adequate rigor in the way an AD forest is deployed, operated, and supported. Reasonable proficiency in all these areas is foundational to AD security.
Procedural Controls / Operation
Now, finally, we can get back to the protection matrix. You can see that although a few of the good practices do specifically identify some preventative controls (i.e., strong authentication) many other controls are procedural (“processes and workflows”), organizational (“strict policies”, “disallow or strictly control”), and architectural (“consolidate domains,” “least privilege”).
Procedural controls must support good practices in operation because AD itself cannot prevent a DA, a privileged user, or a hacker who has obtained the right domain credentials from violating policies and procedures. Not many other preventative controls help in these cases either. Procedural controls need to be backed up with detective controls, such as change monitoring. Some examples follow.
Maintain a Small Number of DAs (and Tight control over Adding New Ones)
As a basic approach, establish organizational policies designating a top security operations (SecOps) group with formal and technical ownership of the AD Enterprise Admins and AD Domain Admins groups. Establish a procedure for assigning a SecOps person(s) as the group(s) owner. Monitor AD for all changes to the groups and ring the fire alarm if anyone other than the designated SecOps person makes the change.
Building on the basic approach, use workflows to ensure the SecOps person never proceeds with creating a new DA (by adding someone to the EA or DA groups) without full, formal organizational approval in advance. Privileged access management (PAM) systems can be used to control the credentials for critical SecOps and DA accounts. Finally, the PAM/procedural controls, SecOps, and/or DA accounts can be implemented in a Microsoft Bastion Forest for further protection.
Maintain Tight Control Over Build-In AD Infrastructure Security Objects
Sensitive objects in AD include GPOs, which control collections of security configuration settings for dependent systems. Also, an AdminSDHolder object resides in each AD domain with a unique ACL that is propagated hourly to control permissions of privileged users in AD. Although these built-in AD infrastructure objects were designed to increase centralized control and security of domains, they can be abused to propagate malicious changes as well. Ownership and use of built-in AD infrastructure objects should be controlled using similar basic procedures described above for the Domain Admin group. However, implementing advanced procedural controls such as workflows requires use case-specific, or object-specific procedure definition and tool work for each scenario.
Adding or Modifying Inter-Domain Trust Objects
Finally, changes that affect multiple domains, such as creating or modifying domain trusts, deserve special mention if only because the DAs from each domain should be involved in workflow approvals, along with SecOps.
Detection Controls
The common theme of many good practices requiring procedural controls is that AD must be monitored for policy-violating changes by privileged users. Monitoring can also help administrators clean up inactive accounts, another contributor to domain risk. For a general approach, see Best Practices for Auditing Active Directory.
Unfortunately, not all the information needed for AD monitoring is in one place. To monitor all parts of AD properly – including AD-integrated DNS and Group Policy Objects (GPOs) – it is necessary to turn on a number of advanced audit settings. Then, AD change records must be enriched with data collected from the Windows Event Viewer from logs on each domain controller.
Tailor Made for a Tool
Monitoring AD using AD-native tools alone is painful, involving many configuration settings and screens throughout the cluttered AD admin environment. Tools should be considered to handle a lot of the grunt work involved in configuring, collecting, enriching, and alerting on AD events. Some AD audit tools are configurable to generate alerts based on the occurrence of specific change events. For example, customers could request alerts be generated in the event of a change to AD infrastructure objects – such as the OU=Domain Controllers, GPOs, or the AdminSDHolder objects – to get an early, automated warning of unauthorized changes. No longer would the enterprise depend entirely on careful dashboard monitoring, or on manual log review by an operator, to flag policy violations. Other tools – such as Semperis’ DS-Protector – provide the ability to rollback policy-violating or directory-corrupting changes.
BeyondTrust, Lepeide, ManageEngine, NetTrix, Quest, SolarWinds, StealthBits, and a large number of other vendors provide tools in this space.
Bottom Line
To reduce AD security risk through the protection matrix’s good practices, Security Architects Partners recommends working on AD architecture, procedures, and detection controls in a coordinated way to simplify the control set and save time. Directory services and identity management are some Security Architects Partners’ core subject matter areas, and we’ve helped many customers with assessments and architecture improvement programs in these areas. Please contact us with any questions and/or to explore opportunities.
The post Active Directory Security Risk Factors and What to Do About Them (Part 2) appeared first on Security Architects Partners.