This article can also be found in the Premium Editorial Download "Information Security magazine: Why privileged account management is critical to today's data security."
Download it now to read this article plus other related content.
In the wrong hands, privileged accounts represent the biggest threat to enterprises because these accounts can breach personal data, complete unauthorized transactions, cause denial-of-service attacks, and hide activity by deleting audit data. Privileged accounts, such as the UNIX root, Windows Administrator accounts or accounts associated with database ownership and router access, are required for platforms to function. Moreover, they are required for "break the glass" emergency access scenarios as well as more mundane day-to-day tasks.
While important, they are notoriously difficult to secure because they don't belong to real users and are usually shared by many administrators Yet a down economy increases the risk of disgruntled workers, making it more important than ever to have a system in place to control privileged access.
What's more, control of privileged accounts is at the top of the auditor's findings list, and is an essential component of compliance mandates associated with Sarbanes-Oxley, the Payment Card Industry Data Security Standard (PCI DSS), the Federal Energy Regulatory Commission (FERC), and HIPAA. If those mandates aren't enough, many business partners are asking for a review of controls associated with privileged accounts as part of their Statement on Auditing Standards (SAS) 70 reviews.
Let's take a look at the technology and strategies that are available to help organizations can get better control over their privileged accounts.
PRIVILEGED ACCOUNT MANAGEMENT TOOLS
Privileged account management products can help mitigate the risks associated with elevated access. These products can help close out audit findings, assist in meeting compliance mandates, and increasingly enable an organization to pass its SAS 70 reviews.
Clearly, privileged account management products have met a need in the enterprise: the product class has experienced explosive growth in the past three years, with the number of customers doubling every year. The number of organizations that have deployed a privileged account management product now exceeds 2,000
Privileged account management products control access to accounts via two mechanisms. The first mechanism forces the administrator or program to check out the account password and the second mechanism changes the account's password frequently on the target platform. These products also provide some workflow capabilities for approval and follow-up after giving emergency access to a privileged account.
Traditional identity management provisioning systems are not up to the task of managing privileged accounts because they lack checkout methods. But privileged account management tools provide two password-checkout methods: interactive and programmatic.
In an interactive checkout, system administrators use the privileged account to access target platforms. Typically, the system administrator authenticates to the privileged account management product via a Web browser session. Once authenticated, the system administrator retrieves the specific account password, then uses the password in an interactive session such as Windows Terminal Services, Secure Shell, telnet, or a SQL client.
Programs also need access to privileged account credentials. Examples of programmatic access include: shell and Perl scripts for the startup, shutdown, and maintenance of target platforms including databases and application servers; services controlled by Windows Control Manager; and configuration files for database and LDAP account connection information. These access methods have traditionally required the embedding of the privileged account management password. The embedding of this password is a significant security risk, because anyone with access to the script or configuration file can steal the password and use it maliciously.
Privileged account management products have tools to help remove the embedded password, and programmatically retrieve it as needed. Programmatic retrieval requires the installation of privileged account management middleware on the target platform. This software enables the program to retrieve the account password in real-time. In some cases, a Secure Shell client residing on the target platform can be used in lieu of middleware.
The interactive access method is by far the easiest to secure, and most organizations tackle it first. The protection of accounts via the programmatic access method requires an inventory of all the places where the account password is stored, then replacing it with execution code that retrieves the password on the fly. Shell scripts and Perl files are relatively easy, but other programmatic access methods can require considerable work.
In particular, account passwords embedded in configuration files -- for example those associated with application servers -- are more difficult because the privilege account management product cannot control when the configuration file is read. Some of the vendors are addressing difficult programmatic access methods like application servers with modules specific to the application server. While tackling programmatic access requires elbow grease, companies that ignore the embedded privileged account passwords do so at their peril; in most cases these accounts can be used for interactive sessions by intruders.
Password change frequency
When controlling access by routinely changing an account's password on a target platform, privileged account management products provide organizations with several options, including:
- Never (not recommended but may be required for antiquated target platforms)
- Frequently (configurable, but the range is generally between one to 30 days)
- Per session (otherwise known as the exclusivity option)
- On demand
Most companies opt to frequently change most of the account passwords. Deployments in early stages typically change the password less frequently, for example every two weeks. As deployments mature and an organization gets more comfortable with the privileged account management product, passwords are changed more frequently; daily changes are common.
For very sensitive systems, some businesses implement the exclusivity option. With this option, the system administrator must "check in" the password when done with the session. The benefit of the exclusivity option is that it provides tighter accountability because the checkout can be closely associated with subsequent actions executed by the privileged account. After the system administrator checks the account in, the product randomizes the password. The password randomization effectively means that no system administrator knows the password until it is checked out again. When the next system administrator checks out the account password, she has "exclusive" access to the account. All subsequent activity can now be correlated to this system administrator. Most organizations reserve the exclusivity option for very few high security systems because of its operational limitations: only one user can access target platform via the account at any given time.
The on-demand password change mechanism is becoming increasingly important in these economically turbulent times. When a system administrator's employment is terminated, timely revocation of access to privileged accounts is essential. The on-demand password change effectively locks the terminated administrator out of sensitive systems, because she no longer has knowledge of the account passwords.
Privileged single sign-on (SSO)
Single sign-on is a recent feature added to privileged account management products. The system administrator accesses the target platform via the privileged account management product's workstation client software or proxy server. Both mechanisms provide single sign-on because the system administrator is transparently logged into the target platform. Behind the scenes, the privileged account management software retrieves the password and logs the user onto the system via the session protocol (for example, telnet, Secure Shell, and Windows Terminal Services). Enhanced security is an additional benefit because the system administrator does not have knowledge of the account password.
Programmatic password caching
Highly-distributed production environments such as large retail corporations are at a disadvantage if the account management password cannot be retrieved due to network issues. Additionally, some target platforms use the account password frequently during processing, and the constant retrieval of the privileged account password would bring processing to a grinding halt. Some of the privileged account management vendors have responded by providing the ability to cache the account password on the target platform. Caching introduces additional security risks, relative to retrieving the privileged account password dynamically. However, caching is a much better alternative than leaving the password embedded in files. The account password will be more difficult to steal because it will not be resident in the file, and the password will be changed more frequently.
|Don't Forget Real Users|
Enterprises need to secure accounts belonging to actual users by reviewing and monitoring their privileged access .
THE PROCESS OF SECURING ACCOUNTS belonging to real live users includes reviewing access to target platforms to ensure that users have the minimum necessary access to perform their job function. In addition, their job function and related access should be reviewed to ensure that no separation of duties issues exist. Case in point: a person who can create a vendor account and also approve payment to that vendor.
The access review process includes workflow; a baseline of access policies must be reviewed and approved. Additionally, subsequent changes to access rights should be reviewed and approved. Access certification tools, including those embedded in identity management provisioning systems from vendors such as Aveksa, Courion, CA, IBM, Novell, Oracle, SailPoint, and Sun Microsystems can assist with the review process.
In some cases, a third-party security tool like CA Access Control or Symark PowerBroker is required to limit privilege user access. For example, rather than giving the UNIX database administrator root access to restart the server, the security tool can delegate the privilege of system restart to a real user.
Assuming that you have locked down privileged user access, you should be all set, right? Not quite; you need to ensure that privileged users do not abuse their access rights. One common use case is the customer support supervisor, who appropriately has access to confidential customer data. If the supervisor accesses an excessive number of customer records on a given day, it may be an indication of a problem. A security information management (SIM) system would not likely detect this anamoly. Increasingly, enterprises are looking to deploy risk-based consumer authentication techniques to detect this level of access, but for the most part these risk-based tools aren't ready for enterprise usage. Consumer authentication vendors with risk-based authentication include AdmitOne, Arcot, Entrust, Oracle, RSA/EMC, and VeriSign.
Another strategy that some organizations use to control privileged access is to maintain two accounts for privileged users. The first one is the "everyday" account for the use in routine activities such as logging onto Windows workstations and checking email. The second account is the one that's used only for those administrative tasks that require high privilege including administrative tasks, including working with high-risk production systems. The high privilege account is not used during everyday tasks, which limits exposure to malware.--Mark Diodati
While privileged account management tools can help organizations deal with a tricky security problem, they should be integrated with SIM and identity management systems to be truly effective. In addition, enterprises should leverage any platform privilege delegation capabilities, which reduce the need to give access to privileged accounts in the first place. Important systems also should be physically secured to help reduce the risk of intruders bypassing logical security controls.
Security Information Management
The auditing of privileged account passwords is an essential component of successful compliance initiatives. Most organizations want the ability to determine who checked out the account and when the account was checked out. All of the privileged account management products possess this capability. Additionally, most of the products can forward audit events to the Windows Event Log or a syslog collector.
To obtain full auditing benefits, a privileged account management product usually needs to be integrated with a security information management (SIM) tool. While
privileged account management products will happily log all account checkout events, that's only part of the picture. Checkout events need to be correlated with the subsequent actions taken with the privileged account. Some correlation may be possible via Windows Event Log or syslog, but organizations will benefit by spending the extra time integrating the privileged account management tool with an existing SIM tool. In some cases, the product will integrate directly with the SIM tool; in other cases the integration is achieved via syslog or the Windows event log.
The integration of a privileged account management product with a provisioning system provides two benefits. The first is timeliness; the provisioning system can make real-time updates to who can access the accounts. The best example is the timely removal of access to all sensitive systems when an administrator's employment is terminated. Another example is removing access to sensitive production resources when the administrator changes job function or location. The other benefit is better security; the provisioning system's role management capabilities can restrict access to privileged accounts to authorized system administrators. For example, only system administrators in Chicago can access the accounts associated with the systems in Chicago.
Most of the privileged account management products have integration with the large identity management vendor provisioning systems. In some cases, an LDAP-based directory server can be used as a conduit between the provisioning and privileged account management systems when formal interoperability does not exist.
Target platforms that can delegate privilege to real users can diminish but not eliminate the need for a privileged account management product. For example, the Microsoft Windows platform has good capabilities in assigning privilege rights to users, without giving access to the Administrator account. In general, UNIX platforms have delegation capabilities, but this varies by platform. Many organizations use UNIX security products to delegate privilege and therefore reduce the need for accessing the root account.
Some platforms, such as network routers, don't possess the necessary delegation capabilities. For these platforms, the best option is the use of a privileged account management tool coupled with a SIM product.
Of course, in controlling privileged access, don't forget about physical security. Physical security almost always trumps all logical controls. Ensure that only authorized personnel can access the "raised floor" (that is, the data center) where the target systems physically reside. In some cases, people have general access to the data center, but should not have access to specific systems. In this case, consider a locked cabinet inside the data center.
To be sure, controlling privileged access is an issue that organizations cannot afford to ignore. Failing to secure privileged accounts could mean failed audits and worse, a data security breach with devastating consequences to the business.
Mark Diodati, CPA, CISA, CISM, has more than 19 years of experience in the development and deployment of information security technologies. He is a senior analyst for identity management and information security at Burton Group. Send comments on this article to firstname.lastname@example.org.
This was first published in July 2009