Organizations exist either to generate revenue or to perform a service.  The mere thought of securing an environment doesn’t exist until there is something of value to secure.  Once you have gotten to that stage of an organizational lifecycle, people already have more access than is really required to do their job (someone previously doing multiple functions may now have additional people in the organization to perform some of those functions).  Knowing where to get started is the first step in your aspiration for least privileged access.

Who do we have?

Identifying who should be able to do what is the first thing that needs to be done.  If you are new to an organization, it will be important to learn the different departments and what their needs are.  It may be good to setup a meeting with someone in human resources to parse through what job functions exist in your organization.  Once you have identified WHO you have, the next step will be to identify WHAT they should be able to do. ...

What should we be able to do?

This is a challenging task as you do not want to impede your organizations productivity.  If you slow down productivity then you can consider yourself an organizational risk.  To be part of the solution and not the problem it is beneficial to have data to help you make a decision.  It is a good idea to audit what people are currently doing with the access they have been before removing their ability to perform a task.  One thing to consider is the length of time in which you should audit activity prior to taking away their rights.  Some tasks may only be performed on a yearly basis, others may work with a shorter base line.

Figure 1- Using Quest Change Auditor I am able to audit what the members of a group have done over the last six months.   This data can be used to create policies as you now know what functions these users normally perform.

Figure 2- Using Privilege Manager for Windows I am able to view what applications users need administrative rights for.  This will help me create the exceptions so that I can remove the local administrative rights.

Figure 3- There are many variations of UNIX and Linux.  As an example, on Ubuntu you can look in the /var/log/auth.log and see what actions have been performed across a box.

Creating Policy     

Without support from the top of your organization, you are destined to fail with least privilege access.  By understanding who is currently doing what in your environment allows you to create policy for an organization to establish WHAT they should be doing.  The audit data that has been collected should be used and questioned to identify what SHOULD these users be doing.  Authorization creep has probably already happened so a clear line of communication with policy creators should be used to determine who should be able to do what.  Another thing you may want to consider when creating policies is to which scenarios may occur when someone may need additional rights (Quest has a business enablement solution for your privileged accounts so you can have an approval process prior to someone getting elevated permissions for a specific amount of time).

Figure 4- By documenting who should be able to do at what location will help you in getting the policy created as well as implementing your new model.

Implementing Policy

Now that we have identified who should be able to do what, we can implement our new model.  Some may choose to do native delegation, many others will consider products from Quest Software that enhance what you can natively do.  Quest Software provides products that can do more granular delegation across your workstations, UNIX/Linux environments, GPO’s and Active Directory environments. 

Figure 5- By default you have read access to all objects in Active Directory.

Figure 6- If granted access, you can fill in an attribute with whatever text you’d like.

Figure 7- With Active Roles you only see the objects and actions you are allowed to perform.

Figure 8- Policies can be implemented so you can be more granular and determine WHAT can be placed in an attribute.

Figure 9- Using GPOADmin you can setup least privilege access for GPO’s and also setup workflow approval prior to changes happening on a GPO.

Removing excess privileges

Once your policy has been implemented, the next step is to remove any excessive permissions.  If a human is given the ability to do things the way they have always done something, you shouldn’t be surprised when policy is broken and people revert back to their more familiar ways.  There are many different systems so this is another effort to ensure there are no back doors.

Figure 10- This is a report with Quest Enterprise Reporter that I customized to exclude built in account so show me native delegation points in Active Directory.

Figure 11- Privilege Manager for Windows allows you to remove members from the local administrator group.

Auditing Policy

If your policy is not being adhered to then it is worthless.  Not only that, but as your organization changes, your least privilege access model should be able to change with it.  By continuously auditing who is doing what will allow you to determine if the grouping of people should maintain their existing access.  Having access when it is not needed goes against the principle of least privilege access.

Figure 12- An organization can use Change Auditor to show changes that happened outside of their service accounts.  This will reduce a lot of noise so you can easily see who is going outside of your organization policy to make changes in Active Directory.  You could setup multiple alerts as your Identity Management and AD management service accounts should only be used from specific machines acting as a proxy into your environment.  If these accounts are ever used on another machine, an alert would be beneficial.

Figure 13- An organization that has *NIX still needs to audit what people are doing with the access provided.  People’s roles change and it is important to validate if people are using the access that has been granted or if they are abusing any access they may have.

Attesting your policy

Organizations are always changing.  People tend to change roles over time and as their roles change, there rights should change as well.  With that said, it is vital that you identify someone who knows a job function and who should be performing that job function on an ongoing basis.  By scheduling attestations for these functions you can ensure that people can remove other people from having access they no longer need. 

Figure 14- Here is an example of an attestation on a group in Active Directory that is granting access to data for Account Payables.  When the business owner clicks deny for an individual, that individual will automatically have their permissions revoked from that entitlement.

Achieving least privilege access isn’t a project, but a change in the culture of an organization.  By changing the culture and getting all people from your business involved the security posture of your organization will begin to strengthen.