[adrotate banner=”21″]This post was authored by Doug White, Cybersecurity professor and President of Secure Technology at Roger Williams University, and host of the Security Weekly show Secure Digital Life. This post is sponsored by STEALTHBits. For more information on STEALTHbits products, and to download free trials of their products, please visit https://stealthbits.com/security-weekly.
Let’s talk about 3 key areas on which you need to focus your Active Directory (AD) Security: physical, logical and audit. All three of these things comprise are, by nature, complex and you will find as you delve into the labyrinth of AD Security that you will need to find a dynamic method. Dynamic methods allow for continuous improvement and oversight as AD Security is not a static monument but rather a churning swamp which is always changing and squishy. It is critical that you communicate to upper management that AD Security is not just a one-shot fix, but an ongoing process. If AD has been ignored for a long time without supervision, this means, you need people, planning, and tools, not to mention budget to provide security.
1. Physical
I would say, “I don’t need to tell you…” but my observation in practice is that “I do need to tell you…” about physical security issues in AD Security. Three primary areas come to mind that threaten your AD security with physical attacks: lack of knowledge, passwords (admin and service) and controls, and general security threats.
In the case of lack of knowledge, one of the great weaknesses I have seen in an enterprise, big and small, is the lack of knowledge of the objects which exist in the environment. You must have a full understanding of your network (and I don’t mean that old network diagram from 2001) and all of the schemas that exist in that domain. This must be done before you can begin to improve AD security. You must sit down and audit your existing schema diagrams that show all items (again, not just a big bubble that says “users”). My common finding is that most organizations struggle to define below the level of critical servers. So, before you even start, this audit is a must. Until this process has been completed, you can’t define user roles and permissions (,e.g. Anne needs access to the shared finance directory and Kelli does not).
In the passwords and controls area, you need to do several things, such as create policies and impose the policies with a great vengeance. I like to tier policy for passwords by threat level, which means you may have varying policies across the domain that require different password policies. My approach is to use at least three tiers, untrusted, trusted, and doomsday (which I sometimes call red cards). Untrusted passwords are in the bands of general users and should follow the typical rules of at least 8, numbers, letters, case, and symbols. The assumption here is that passwords will be compromised and subsequently require change on a quarterly basis. Only allow these passwords to be used for individual-level resources (e,g, a user’s non-threatening files). In the trusted level, define accounts that access multiple resources or mission-critical resources, require two-factor authentication, and enforce strong password policies. In the case of doomsday passwords, passwords that can change other passwords, allow access to any resource which can be used to cause extraction of information resources from the domain, or control access to the objects (servers, etc.), use two-factor authentication and passphrases such as, single-use strings which are long (up to 256 characters or the max length that is allowed by AD or other applications). It is also recommended to use “red carding”, a process that physically stores the password out of band (such as in a safe). The red card should only be accessible in situations of extreme duress by the designated warden (out of band people such as the CFO or CEO). All “red card” access must be logged. Use your security groups to design and enforce these policies, audit them quarterly, and tie it back to your schema.
In the general security threats category, you can’t just trust devices because they are sitting in the marketing department or because they connected via a VPN. Security groups need to be used on devices and privilege controlled. However, there is also the question of what user is in control of the device. AD security inherently requires a layered approach (since security groups apply across devices as well as users and objects) but I often see organizations enforcing policy on one of these things but not all of them. This, of course, traces back to schema definition and understanding the environment. However, if a device can access the launch code folders and a stray user sits down at a trusted, open machine, there is a triple threat to the folder. The threat is based on which security groups are being used to control all three parts of the equation.
Physical security is the starting point for the development of good AD Security policies. You must understand, at a very granular level, what resources exist, who can access those resources, and which devices have trusted access. In all three cases, security policies must be applied to develop restrictions based on threats to those resources. For example, if the permissions on a folder called “launch codes” restricts the marketing department’s access and there is a shared administrator password used by ten other people. Those ten people can get to the launch codes and there is no way to determine which one. Likewise, if we trust the device where the folder resides, and that machine is left logged in, a member of the marketing department could just sit down and access it. So, the penultimate understanding here is that you must use a granular schema, two-factor authentication, per object policies, object grouping by privilege, and know which privileges are assigned to the object. Finally, you must understand the trust relationships between (and among) the objects themselves within the domain and externally.
2. Logical
Logical involves the assessment of threats which emerge not from a specific physical threat but from other machines, privileges, and individuals in the domain or forest. Inter-domain and intra-domain issues must be considered in this AD realm (viz. the forest or even multiple forests). Administrators are often escalated or shared within the organization (and sometimes even outside the organization!) since there is a base administrator account and many other built-in accounts (like domain administrator, etc.) and these privileges can easily be shared across the logical schema of the device, domain, forest, world as well. I frequently encounter organizations that do not rename the Administrator account nor assign limited administrator privileges to those requiring them. Worse is the assignment of administrator roles to user accounts. This happens due to it being easier to allow an administrator to do some action. For instance, I observed a situation where a user had been granted the “Administrator” login, so they could install an application. In the same situation, each “IT” person also had the Administrator password and could use it when needed. This creates a situation where a rogue user caused a great deal of damage when they heard about a pending layoff and logged in as Administrator. The user then deleted the entire finance drive. I recommend the administrator account be renamed and treated as a “red card” with group policy restrictions applied.
“Administrators” should be tiered and defined carefully in the schema. Since escalation of privilege is the quintessential basis of most compromises and sloppy policies cause both intentional and unintentional harm. Under no circumstances, should passwords for administrative (or any other) accounts be shared among devices or users as this creates the problem of non-repudiation in the logs as well as allows for sidestepping of the security group by using a different account/device. rust among objects has this same set of issues. If we globally trust an object and that object is subsequently compromised, the bad actor can escalate into other objects.
The second area of concern is the proliferation of built-in accounts in AD. Active Directory includes accounts which are used for maintenance (and should not be deleted), like the Directory Service Restore account, used when domain controllers must be put into maintenance mode. Accounts like Directory Service Restore are problematic but can’t be easily eliminated from the domain. I typically treat them as single-use passwords, again “red cards”. These passwords must be changed with each use and the card updated in the vault. If the red card is logged properly, the last user of this password is then documented until the next use. his may be done with virtual vaulting, but I still prefer the old-fashioned approach of isolating it out of band and making the action a series of policy steps required to access these shared passwords.
Object hardening is another complex and difficult task included in this security process. here is likely some unimaginable number of objects in a domain or forest. This means the physical schema must be understood completely. Object hardening requires evaluating the permissions of each object and ensuring those permissions extend only to the limit which is necessary for reasonable operations. Read-only is a way to this but even that comprises a threat since access to stored information is also valuable. Subsequently, one of the common challenges in security audit is always the daunting analysis of object permissions. Not only do many objects exist, but each object in AD has many different options and permissions which may grant the object rights to affect other objects (essentially, trust).
These permissions take on a variety of forms including: user permissions, group permissions, organizational unit permissions, and even hardware (device) permissions. In each of these categories, read, write, and execute permissions may have far-ranging impacts across the domain. In fact, the truly onerous threat is not a given permission (although that is a threat as well) but rather the chain of threats that results when object permissions create trust chains between objects. If a printer object has write permissions to a server object and a user has write permissions to the printer object, these type of transactions may allow pushing a transaction through the whole chain. As an example, Anna is a marketing trainee who then moves to the IT help desk group as part of training and is given a different level of access. When Anna accepts a permanent position in the Human Resources group, what is the process, by which these permissions are changed, deleted, etc? It is common to see long-time users with many different sets of “credentials” associated with their account as new permissions are added, but old permissions are not removed during the transitions. Even separated employees may be found in these permission groups still with high-level access. All of this trust is compounded by the built-in accounts, difficulty in understanding what permissions should be applied and restricted, and how all those things interrelate with each other across the domain/forest
3. Audit
Active Directory Security and AD, in general, are very difficult to audit. The physical schema must be understood in detail. The schema development alone is a time consuming and difficult task. When auditing AND, I usually tried to physically investigate about 5% of the objects and determine if they existed. The audits were conducted forwards from the domain controllers’ listings and then backward from devices and objects we could find in the domain. It was not unusual to find new, different, and modified objects even in bi-annual audits. r. Rarely, was there a client who had a good method for the creation, deletion, and modification of objects in the domain, let alone the forest. An auditor needs effective tools for tracking changes in each domain in order for events to trigger notification of changes. New objects should update in the policy list which allows them to be evaluated. So, if a new folder is created on a server by an administrator, this should result in a notification. When the notification occurs, the permissions can be assessed for correctness, the proper security policy is in place, and all of the policies are applied to the object.
Thus, a granular, accurate schema is important if an audit is to be effective. If the organization doesn’t know what is there, the auditor cannot effectively audit since an unknown object may be in the domain with inappropriate privilege levels and that single object can violate the trust of other objects in the chain.
During your regular audits, the auditor must look at both the physical and logical areas of AD Security if the audit is to be effective.. Likewise, looking backward and forward on the objects is mandatory. As an example, when auditing permissions on a share called “finance”, the auditor should start with “who” should have “what” permission to that resource (this is the forward). Then a sample of those objects is taken to determine if the permissions are set correctly per the policy. The more frequently you audit, the smaller the sample may be. When the folder itself is audited: 1) Where is it physically; 2) What can access it, and 3) What permissions do those things have (backward)? Does all this match the forward audit findings?
Final Word
The initial audits of AD will require time, commitment, and persistence in order to be effective. It is well established that there must also be an overall commitment to this process by upper management if the process is to have any level of success. I am certain that the initial advent of financial audits was met with skepticism and resistance but as the value of conducting these efforts was realized, it became apparent that an apparent expense improved the overall health of the organization, the worth became more obvious. The same is true of security audit of AD. As organizations realize the consequences of failed trust and the loss of goodwill, the inherent value in a comprehensive audit of AD objects will also be realized.
