Best Practices for Application Privileged Accounts in IBM Security Directory Server LDAP

By David Biondi, IBM Advanced Deployment Professional, IBM Master Instructor

 

If you’ve deployed IBM Security Directory Suite (SDS) or its predecessor IBM Tivoli Directory Server (TDS), you know have a centralized repository that contains some of the jewels of your organization – user account data. Ensuring that data remain both secure from compromise yet available for use is a balancing act that every security administrator must perform.

 

This paper will address eight practices that should be considered for any Application or System ID that connects to your LDAP server. For the purposes of this paper, we are considering only accounts that are used solely for machine-to-machine communications, not accounts that are used by a human to access your LDAP server. We will call these “Application Privileged Accounts”.

 

Because Application Privileged Accounts are used to perform system level tasks, they are often granted higher levels of access that standard human user accounts. They also may perform a large number of activities which can make auditing of account activity difficult. And because they underpin our organizations distributed computing systems, they often are exempted from the normal requirements we place upon our human users such as password rotation. This makes them an ideal target for malicious users.

 

Understanding the risk and what we can do to mitigate it is important to ensuring that our organization is secure. The following best practices can provide a road map to your success in limiting your potential expose from these vital Application Privileged Accounts.

Robots only, please

 

These Application Privileged Accounts are created for machine-to-machine use, so let's keep it that way. Instruct your staff that outside of specific activities, these ids should never be used outside of the automated process it is assigned to.

 

An admin might be tempted to co-opt the account to perform a quick query or minor update that their own account doesn't have access to perform. And there is always pressure to get the job done.

 

The best way to address this risk is to have a published policy with regards to acceptable use of these accounts. At the end of this paper, I'll provide a sample policy statement that addresses each of the eight best practices we discuss today.

 

Remember, that it will take time for admins to transition from using Application Privileged Accounts instead of their own personal accounts, so be sure to account for that transition. In many cases, your admins may not even have a personal account at all, much less one with adequate permissions to perform the necessary work. Creating those personal accounts is a necessary predecessor to finalizing the adoption of this best practice.

One per customer



This is probably the simplest of the eight best practices, but is one that is commonly ignored. It can be summed with this statement: Create a new, unique account for each different purpose.

It is human nature to select the path that seems easiest and when an administrator is configuring a new application, it seems easiest to just reuse an existing Application Privileged Account instead of obtaining a new one for the purpose.

While that may be the fastest solution in the short term, it is a short sighted way of adding to our organization's technical debt. Every touch point that reuses the same Application Privileged Account adds an exponential amount of work for the life-cycle of that account.

For example, when the password of the account needs to be rotated, if there is a single usage tied to that account, we can simply update the password and the one service during our next maintenance window. If there are two usages for that same account, we not have coordinate that maintenance window. And what happens when the SLAs for the applications do not align?

Luckily, when we implement the remainder of the best practices spelled out in this paper, single account use will almost automatically become the norm.

Branch out

 

Because Application Privileged Accounts are special, we want to make sure that we can always easily identify them.

 

One method to help identify these accounts is to take advantage of LDAP's tree structure. Within that tree, we can create branch containers where these accounts are stored.

 

How your LDAP tree is defined is generally based on organizational needs, however here are some guidelines that you should put into place.

 

  1. Human accounts will not be stored under the same parent node as Application Privileged Accounts

  2. The name of parent node for Application Privileged Accounts will clearly indicate that these are non-human accounts

  3. Access controls on the Application Privileged Accounts branch will be defined to restrict access to authorized users only

Your honor, I object to that class!

 

Every LDAP entry has an object type. Which means that each entry belongs to one or more object classes which identify that entry's type.

 

An object class specifies the mandatory and optional attributes associated with an entry of that class type. And object classes are hierarchical and inherit the attributes from their parents.

 

There are many object classes that are defined by default in LDAP. However, organizations tend to find that these object classes don't contain all of the attributes that they want to have available. Thus, it is common to create custom object classes that extend upon those default ones.

 

For example, we may look at the default inetOrgPerson object class, it contains a number of optional attributes to help define a user's profile. If we are using LDAP to contain our e-business users, there are likely additional pieces of data that we want to store about these users. For example, preferred shipping method, last order date, and if they are a member of our shopping club. So, in order to track that information within LDAP, we may create a new object class, eBusinessUser.

 

The same principle applies for our Application Privileged Accounts. The best practice is to create a unique object class that is used for every Application Privileged Account and is not used for any other type of account. This allows us to easily identify that this isn't a normal user account.

 

In addition, we can add new attributes that can help us manage these Application Privileged Accounts. For example,application name, hostname(s) that use this account, account owner, last access review date, and whether the account is read only or has read write access.

 

Wouldn't it be wonderful if you could look at the profile for an account and know what target systems and applications use it? Of course that data will generally need to be kept up to date manually, so that process should be part of your policy statement.

Is that really your password?



It should go without saying that Application Privileged Account should have very strong passwords. Since these accounts should never be used by a human, and generally the password is entered once and saved on the machine that will be using it, there is minimal effort required in having a highly complex password.

 

Since the password complexity for these accounts should be more strict than our standard user accounts, we generally do not want to use the same password policy within LDAP for these accounts.

 

IBM Security Directory Server supports two ways to implement custom password policies. The first one is the individual password policy. You can create a custom password policy and then attach that policy to each individual Application Privileged Account. This is an effective strategy, however, it does require additional steps when creating the account to ensure that the policy is attached.

 

An automated way to implement this is to create a group password policy. And, since we are now using a custom object class for our Application Privileged Accounts, we can build a dynamic group that automatically assigns membership into this policy.

Your Time Is Up

 

When an application team requests the creation of a new Application Privileged Account, they invariably request that the password be non-expiring. I understand why they would like the password to never expire. It takes work managing password changes for Application Privileged Accounts and it would just be easiest if they never need to change.

 

However, if those passwords aren't changed, we risk a data breach. There are a lot of reasons that we require our end users to change their passwords on a regular basis, and all of those and more apply to our Application Privileged Accounts.

 

Luckily, there are on the market several products that can help with password management in these scenarios to minimize the impact of password rotation while enabling a secure environment.

How may I encrypt for you?



When considering data security, there are two scenarios that need to be considered – when the data is at rest and when it is in transit.

With regards data at rest and our Application Privileged Accounts, we want to ensure that the passwords are stored within the LDAP database in an encrypted fashion. IBM Security Directory Server supports three different types of password encryption: none, unidirectional encryption and bi-directional encryption.

It is never a best practice to deploy LDAP without password encryption. In that configuration, passwords are stored within the database in clear text. This allows anyone that gets access to the underlying datastore to be able to read the clear test password for all of your users.

With bi-directional encryption, IBM Security Directory Server is able to decrypt the encoded password and retrieve the clear text again. Unidirectional encryption encrypts the password with a method that does not permit retrieval of the clear text password.

Which encryption algorithm that your organization chooses, will depend on your own security policies. However, unless there is a clear business case requiring that the ability to retrieve the clear text password, the recommended practice is to use a unidirectional encryption algorithm.

Quis custodiet ipsos custodes?

 

Once you've implemented a Application Privileged Account policy to address the best practices discussed in this paper, the final step is to implement monitoring to ensure that the policies are being followed.

 

As part of you periodic user access review policy, it is a best practice to validate that each Application Privileged Account has supporting documentation for it's creation and that it still remains in use to support the business function it was created to serve. At the same time, validation of password strength and rotation policies can be done as well as the proper placement with LDAP and objectclass selection.

 

Even more critical than the user access review process is ongoing monitoring of the use of these Application Privileged Accounts. Since each account should be tied to a single application purpose, the pattern of behavior of that account should remain relatively constant. An intelligent IBM QRadar SIEM, can help identify when that behavior deviates from the norm indicating a potential breach.

 

At a minimum, a SEIM tool should monitor the LDAP Bind activity for Application Privileged Accounts and ensure that the source addresses do not deviate from normal.

Rest Easy

 

In today's security landscape, it is a challenge to ensure that your organization is safe. Application Privileged Accounts represent a high profile target that can grant a high level of access to your systems. However, by implementing these best practices, you can mitigate the most significant threats that these accounts represent.

 

Policy verbiage

 

ESM Solutions IT Security Policy 4.1a, November 7, 2012

 

Application Privileged Accounts

 

This policy is directed to control the access of Application Privileged Accounts (APA) and mitigate the risk of their misuse. Applications Privileged Accounts are any account designated for machine-to-machine communication where the account credentials will be cached or otherwise stored on a system for reuse without human intervention.

 

  1. Requests for the creation of an APA will be made via a service request. The request will be approved by a manager or higher level staff member.

  2. All APAs will be identified by unique identifies within the account. The LDAP objectclass APAPerson will be associated with each account.

  3. APAs defined within LDAP will be contained within a branch with the ou “APAAccounts”. No other accounts will be created within that ou.

  4. All APAs will have an account owner which will be an staff member or team (identified by cost center)

  5. Each APA will be approved for a single purpose. The address of each server that will use the APA will be identified in the service request

  6. All APAs will receive a semi-annual access review. The account owner must validate the business need and level of access of the APA, or the account will be disabled.

  7. The password for all APA accounts will meet the following strength requirements:

    1. 16 characters in length

    2. A minimum of 1 each of lowercase, upper case, special and numeric characters

  8. The password for all APA accounts will be rotated every quarter; January, April, July, October

  9. Aside from initial configuration and troubleshooting, the use of APA accounts will be restricted to the machine-to-machine process for which the process is approved.

  10. After configuration of the APA process is complete, all records of the defined secure password will be deleted.

  11. The SEIM system will monitor the use of APAs and report on any abnormal behavior, including the use of the APA from non-approved addresses.