Avoiding privilege abuse in Active Directory

It’s inevitable. You’ve given a number of individuals in your organization rights to run around in AD making changes as they see fit, with little oversight. It’s a situation that’s ripe for abuse.

A user with admin rights can grant another permissions with little more than a group membership change, giving an unauthorized user access to commit data theft, or fraud. Too many users, with too many privileges… and no one watching to prevent abuse.

Think it doesn’t happen? Nearly two-thirds of organizations today believe threats stemming from insiders are more difficult to detect, citing their already credentialed access as the number one reason1.

With 59% of organizations concerned about privileged users posing an insider threat to the organization[1], it’s time to do something about the potential abuse that exists within your Active Directory.

 If you do nothing, abuse will eventually occur… and you’ll likely never know.

So, what are you supposed to do about abuse? No organization wants it to occur, but can it be stopped? Avoided? You’ve already given the keys to your AD to a number of individuals for quite some time. 

Don’t worry, all is not lost.  There are tangible steps you can take to address the potential abuse that exists within your organization.

Can you Prevent Abuse?

Some of you may be wondering if it’s possible to actually stop someone from abusing privileges. If you’ve asked this question, at least you’re not willing to settle for any abuse. But once you’ve given someone permissions, it’s nearly impossible.  Solutions that monitor changes of critical objects and resources, at best, can revert changes – but that’s still reactively done. Without workflow in front of all requests to modify Active Directory – as well as any systems, applications, or data AD gives users access to – you won’t be able to truly prevent. Because of this, for most organizations, the focus needs to be squarely on avoidance.

So, what are the steps necessary to avoid privilege abuse?

Embracing Avoidance

Avoidance begins with an understanding of your current security lifecycle, taking advantage of that process to identify proactive steps that can be taken to steer clear of scenarios where privilege abuse could otherwise run rampant.

Since not every company follows the same security protocols or processes, we’ll use a basic three-phase lifecycle that aligns to any security model. This security lifecycle will serve as the basis for the remainder of the whitepaper, demonstrating steps you can take to avoid privilege abuse throughout.  The security lifecycle can be though of as existing in three phases: 

• Assessment – Before you make any changes to security, you should first assess the current state. This is to check the current settings to ensure they are correct.
• Assignment – The most common (and sometimes the only) step in security organizations take. Here you’re making changes in the form of additions, deletions, or modifications to security.
• Auditing – Monitoring usage of the environment to which users have been granted privileges is equally important. Because we’re talking about both AD and the applications and data AD provides access to, usage should be thought of as both the work performed during the assignment phase, as well as the access and use of the resources granted privileges to.

Avoidance can be achieved by improving your organization’s security stance in each of these three phases. In the remainder of this paper, we’ll cover avoidance from the perspective of each of these three phases.

Avoidance through Assessment

Assessment is one of those phases in the security lifecycle that falls squarely in the “set it and forget it” column. That is, unless you’re in the middle of a security audit, privileges are often simply assigned and no further scrutiny is placed on them. But it’s critical – perhaps more critical than you realize – that you perform continual assessments of your assigned privileges. Why? If you’re like most organizations, you’re one of the 71% of companies whose users say that they have access to company data they should not be able to see[2].

In other words, they have too many privileges, demonstrating that no one in IT is looking to see who has privileges to sensitive data and critical applications. As users change roles within an organization and are re-assigned permissions to relevant systems, applications, and data, the privileges relative to their old role are not being removed. Why? Because an assessment wasn’t done first.

And with too many permissions, the risk of abuse is elevated, as users believe they have slipped under the radar and won’t get caught.

 So, how do you prevent abuse of AD through assessment?

 In this phase of the lifecycle, avoidance is accomplished by verifying what privileges have been granted and determining whether the appropriate people were assigned those privileges. The following tasks should be focused on to achieve avoidance through assessment.                                                                                                      

• Manage your Groups – This is a very overlooked part of AD management that has a material impact on our security. All it takes is the reuse of a security group with sensitive access as a distribution list, matched with the addition of a user for the purpose of email, and you have yourself a user with inappropriate access. Groups needs to have their members and nested memberships certified periodically, as well as have their very existence attested to. Assigning an actual owner of the group – and not just someone’s user account populated in the Managed By field – who will be responsible is important if you want to keep your groups, and the access they provide, secure.
• Check Your Privileges – Since no permissions, other than assignments to other objects within AD, are documented within a user or group object, you’re going to need to work through privilege assignments in each of your important systems to identify, document, and report on the current state of privileges. This needs to be done both for groups, as well as users (despite users being less likely to have directly assigned permissions). In reality, this may prove to be too great an undertaking without the use of third party solutions to pull permissions from various resources and applications (e.g. file servers, SharePoint, databases, etc.)

Both of these tasks are not for the faint of heart; they require some significant investment of time up front to get a handle on the current state of privileges, as well as additional time on an on-going basis to ensure that, as you clean up privileges and groups (more on this in the Assignment section of the paper), you can maintain this more secure version of the directory. Despite the amount of work necessary, keep in mind that this is one of those rare opportunities where, should you properly and continually perform assessments, you keep users from retaining inappropriate privileges, lowering the risk of abuse.

But, just how often are you supposed to assess the state of your privileges?

Remember, AD security is fluid. It’s rarely static, unless you have only one admin managing AD - you. So, if you perform assessments on, say, an annual basis, you’re missing the constant changes occurring and only see the sum total after a year’s time. The answer isn’t to assess constantly, as that’s not realistic. But the answer does lie in partnering frequent periodic assessments with keeping track of any work done within the assignment portion of the lifecycle to ensure you know when the state of security as you know it has changed.

Avoidance through Assignment

The problem of excessive permissions has already been outlined, and it’s this phase of the lifecycle that is equally to blame. Remember, assignment includes adding, modifying, and deleting privileges. You should think about assignments of privileges from two perspectives – in response to an assessment, and in response to a request. When in response to an assessment, you are working to fix a very specific problem that IT is already aware of, so this is not a case where you need to be concerned IT is aiding privilege abuse.

It’s when IT is responding to an everyday request that it tends to not pay attention. Take a user that has moved departments from accounts payable to accounts receivable. IT would generally focus on adding the user to the “AcctRec” group, and perhaps forget to remove the same user from the “AcctPay” group.  This leaves the user able to potentially commit fraud by being able to add a fake payee, and cutting an unapproved check.

So, what steps should you take to to avoid abuse through assignment?

Implement Least Privilege

The principle of least privilege means only giving a user the permissions they need to do their job.  It’s more a mindset that drives policy and process than a specific process itself. Take the previous group membership example – if an organization was focused on implementing least privileges for all its’ users, a process would exist that says when a user changes roles within the organization, they should identify and validate the user’s membership in all groups.

 If you’re serious about implementing least privilege, you should start by defining levels of access within the organization. This will likely be a more organization-wide undertaking, involving stakeholders and line of business owners within the organization to help define levels of access. Consider use of a role-based approach as often as is possible to avoid granting one-off assignments to users. Defining process and policy should follow to ensure assignment activity will align with the intent of the principle.

Lastly, you’ll need to implement a periodic review to have the defined roles, policies, and processes reflect the current state of the organization.

Make use of Native Tools

There are a few tricks Microsoft has out of the box that can help with assigning permissions and ensuring users only have the privileges they need. Since most assignments in AD come from membership within a group, consider using Restricted Groups within Group Policy.  With this setting you can ensure only specific user accounts can be made a member of groups granting privileges to sensitive or critical resources.

For those users needing temporary access to resources, take advantage of AD’s dynamic object functionality, adding the temporary user to a temp group with the Entry-TTL value specified, and add that temp group as a member of the group granting privileges. Once the TTL times out, the group no longer exists – and neither does the user’s privileges.

Even once you establish avoidance within the assignment phase, you’re still relying on everyone adhering to the policies and procedures as part of least privilege. But someone can still malicious ignore those, or simply forget in the midst of trying to put a fire out.  So it’s important to have a way of ensuring you have complete visibility into the use of AD and the assignment of privileges through auditing.

Avoidance through Auditing

As previously mentioned, auditing is about monitoring the provision of privileges to systems, applications, and data, as well as the use those resources. It’s a critical piece to the “avoiding abuse” puzzle. Auditing provides IT with context around when and how the environment is accessed. Details around the who, when, and what of usage (whether in AD or resources) all give IT clues as to whether abuse is occurring or not.

Auditing findings serve as the basis for the next assessment (that is, you see someone accessing something they shouldn’t, which should cause an assessment to take place). And they provide accountability around the assignment phase. To truly avoid privilege abuse during the assignment phase, you must be certain that either privilege changes aren’t being made at all or, when they are, that you are notified of the specific changes being made – which is where auditing comes into play.

There are two use cases of how you should use auditing to identify potential abuse. 

• Auditing the Assignment and Modification of Privileges – This envelopes changes to AD group memberships, as well as assignments of permissions within applications and services across your network. Auditing AD changes is available natively, albeit somewhat cryptically, within event logs. And if you’re wanting to see every change made in AD, you’re, in essence, asking to also see every entry in the event logs. When you go beyond AD and start trying to audit changes to privileges within applications, such as SQL Server, or a SharePoint site, because those assignments are made within the application itself, in many cases, it’s either a case of the log data isn’t centralized, or even worse, just doesn’t exist.
• Auditing the Use of Applications and Resources – Think accessing files, non-owner mailbox access on Exchange, or checking out a file from SharePoint. Like privilege assignments, it’s really up to the application as to whether an audit trail is possible or not.

The challenge here is to properly avoid abuse, you want the ability to have an audit trail for every change in AD, every permission assignment (regardless of what application makes it), and every use of those permissions to access resources.

 Third-party solutions do exist that watch changes made to AD and other critical applications and resources, not just creating the audit trail missing natively, but also providing intelligence to present IT with a single change (instead of, say, 6 event log entries to sort through). These solutions provide alerting, which is critical to proactively manage assignments as they occur, as well as to provide real-time feedback as resources are accessed. Additionally, they provide turnkey and, often, custom reporting, so generating proof of a lack of abuse, or adherence to compliance mandates, or to simply review the state of your AD security is (and the vents leading up to the current state) all are simple tasks to accomplish.

Avoiding Abuse

The very real potential exists for individuals with privileges to take advantage of their given rights, shifting their loyalty from the organization’s to themselves. Avoidance of this abuse is possible by putting in place proper controls at each phase of the security lifecycle that create accountability for IT and users with privileges. 

Native tools can provide the basic means of assessing, assigning, and auditing security, but if you want to be serious about your avoidance efforts, you’ll need to look to third-party solutions that extend your lifecycle reach beyond that of a basic view of just AD, to a comprehensive view of the state of your AD security, the management of it, and the use of privileges it provides.

[1] LinkedIn Information Security Group, Insider Threat Spotlight Report (2015)

[2] Ponemon, Corporate Data: A Protected Asset or a Ticking Time Bomb? (2014)