Tom Kemp's Centrify Blog

Superuser Privilege Management

Friday, December 5, 2008

Clearly, a key value proposition of Centrify DirectControl is the ability to leverage Active Directory as the central identity hub/store to administer users and their access, as well as centrally control authentication. This centralization then enables single sign-on for users to non-Microsoft systems and applications. Other value propositions of Centrify DirectControl being an "AD Bridge" solution include cross-platform group policy management and having user authentication login attempts centrally logged. But the Centrify approach of leveraging Active Directory for not only authentication but also extending our capabilities via the Centrify Suite (of which DirectControl is the underlying platform) into authorization and auditing also facilitates customers addressing an equally important set of needs beyond single sign-on and centralized administration that reduce costs. One such critical need is "superuser privilege management" which is the topic of today's blog post.

Most operating systems, applications and databases have an administrative account to enable installation, configuration, administration and management of those platforms. And most large organizations have multiple personnel that need to administer Windows or UNIX systems ("the sys admins"), multiple personnel that administer their Oracle or DB2 databases ("the DBAs"), and multiple personnel who either develop applications ("the developers") and/or administer applications ("the app admins"). This means that in effect there are multiple people that have "keys" (i.e. administrative access) to these "doors" (i.e. systems and applications) and the valuable information that reside behind those doors.

As Gartner Group notes on page 2 of this presentation, organizations need to worry about important things such as (and the bullets below are direct quotes from the slide):
  • How many users have the keys for every door?
  • Do users get their own keys or share keys?
  • Do you know who is using which key when?
  • Do you even know how many keys you have?

As I discussed in this blog post, unfortunately many basic administrative commands on UNIX and Linux systems require superuser (i.e. root) permissions. In addition, per Gartner (Research Report ID# G00130427), UNIX and Linux systems inherently lack a scalable and simple model for administrative delegation as compared to Windows. This means that UNIX personnel — such as system administrators, DBAs, backup operators and help desk staff — must be given increased privileges to accomplish even narrowly focused administrative tasks such as performing backups or managing a web site.

What Centrify has found that when we initially engage many organizations that we do in fact find that they have IT staff sharing privilege accounts such as "root" and "oracle." So what is the problem with that? The above mentioned presentation from Gartner, page 4, does a nice job of summarizing the issues (and the bullets below are direct quotes from the slide):

  • Egregious violation of the principle of least privilege
  • Huge opportunity for security breaches through ignorance, accident or malice
  • High privacy risk through access to sensitive personal data (medical...)
  • High compliance risk through access to financial systems and cardholder data, for example

Recently the press has caught onto this problem and how a burgeoning market is forming to address this problem. In this week's eWeek there is an article on this very topic, entitled "Enterprise Security Requires Shared and Privileged Account Password Management," with the lead being:

"Shared and privileged accounts can pose a security risk to enterprises if the proper controls and procedures are not in place. ... Super users may use their powers for good most of the time, but every now and again, an insider breach will remind us how important keeping track of super users and shared accounts truly is."

And the article later quotes Mark Diodati at Burton Group who nicely sums up the problem:

"Keeping track of super users and shared accounts is important for accountability," Burton Group analyst Mark Diodati said. "Unfortunately, however, many organizations simply don't know for sure who has access to shared passwords."

"They might have 15 system administrators, for example, who have access to the root password, but that doesn't mean those are the only 15 people that know it," Diodati explained."

Why Do We Need Privlege Management?

So what to do with this shared account and privileged account password management problem?

The first step is to avoid shared accounts and use personal accounts, i.e. have users login as themselves. According to Gartner: "The best practice is to avoid shared accounts: Most situations that appear to demand this approach [of using shared accounts] can be more elegantly and securely addressed by using personal accounts." (Gartner Report ID G00152051).

We heartily agree. That's one of the benefits of DirectControl in that it provides the ability for users to login as themselves (i.e. their AD account) vs. sharing a root/super-user account. In other words, there is significant value in having the IT staff who login to a UNIX box (e.g. sys admins, DBAs, web developers, etc.) to administer the system to login as themselves using their AD credentials. Otherwise they will share the root account, the oracledba account, etc. And in order to ensure that they don't continue to use privileged local accounts, customers need to create new passwords for these accounts and make sure we have a process to manage the passwords over time. DirectControl does this by mapping these local accounts to an AD account so that the AD password, which is under AD password policy controls, must be used for any access to these accounts.

The net net is that organizations don't want to share these privileged accounts passwords, so having people do stuff as themselves (i.e. their AD username) delivers more accountability and reduces sharing of root / superuser accounts and their passwords. And of course by having users login onto their apps and UNIX boxes with their AD credentials (vs. using a different identity store other than AD) you get the benefits of single sign-on, single place to administer the user account (e.g. disable them), etc.

So what's the next step in addressing this problem?

The reality is that the UNIX OS requires root privileges to perform basic UNIX administration, e.g. to do a backup you need to run these commands using the root account. Now that you have users logging in as themselves vs. root or any other superuser account, the next step is to put into place the ability to limit what they can access (i.e. reduce the # of keys) and once they been securely given a key (i.e. access to a system), grant in a granular manner the privileges required for them to perform their duties. This is known as the principle of least privilege which, per the Wikipedia definition, when applied to users is the "concept that users at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible." Analysts in the identity and access management market refer to this as privilege management or authorization management.

Centrify believes authentication and access control (i.e. controlling who can log into which systems and applications) and authorization (i.e. controlling how and when users can access a system and controlling exactly what commands they can run on those systems) go seamlessly together. Our DirectControl solution does the authentication and access control piece while DirectAuthorize does the authorization piece. And when we make comments that these solutions go "hand-in-hand" that means we offer DirectAuthorize as a standard component along with DirectControl as part of the Centrify Suite Standard Edition, and being based on the same underlying Active Directory-centric architecture. This is in stark contrast to what other vendors to in this market, charging $1000s per server extra for their privilege management solution and offering products that integrate mainly at the brochure level. And most importantly, the integration with DirectControl and Active Directory means that these access rights and privileges are granted to AD accounts and groups vs. some local account, which provides auditors the assurance that we can prove accountability for any actions taken on these systems.

Grant Privleges Based on Roles

Finally, what is the final step in addressing this superuser privilege management problem?

As Gartner states in page 8 of the aforementioned presentation, the final step is that you need to "monitor all activity by privileged users."

That's where Centrify DirectAudit comes in. DirectAudit builds on top of DirectControl and DirectAuthorize by auditing all actions taken by any individual including those with root or administrative privileges. This associates user activities to a specific person through the person's Active Directory account used at login with DirectControl, establishing the accountability required by the auditors. DirectAudit addresses the issue of accountability by auditing and showing exactly what the users were doing on your systems. Think of DirectAudit as a Tivo or VCR for your UNIX/Linux system, with ability for auditors to quickly see and search on who has been doing what on your mission-critical systems. As an example of meeting compliance requirements, DirectAudit clearly addresses Section 10 of PCI DSS ("Track and monitor all access to network resources and cardholder data"). We offer DirectAudit as part of our Centrify Suite Enterprise Edition.

Monitor and Record Activity

So there you have it: have users login in as themselves, provide centralized authorization management to control what privileged users can do, and audit their activity. Doing those three things should go a long way in addressing the risks associated with shared and privileged accounts, and that's what the Centrify Suite Enterprise Edition aims to do.

< Previous Article: We've Moved!
> Next Article: Centrify Suite 2008 Released