Endpoint // Authentication
12/12/2011
04:30 PM
Connect Directly
RSS
E-Mail
50%
50%

Unraveling The Riddle Of Privileged Identity

Some argue for monitoring to take a greater role in refining privileged identity policies, but root accounts pose problems

Whether they're network administrators, DBAs, or just people who know the username and password of certain shared root accounts, privileged users have long been a difficult nut to crack for security and compliance professionals seeking to keep information on a need-to-know basis. Most experts will agree that it is time for enterprises to make a change in how they deal with privileged accounts and users -- they just might not necessarily see eye-to-eye on how it needs to be done.

Some experts think that the current failings of today's identity and access management tools point to a need for organizations to better use their logging and monitoring solutions already in place to help refine privileged user access. But others warn it isn't as simple as that.

Regardless of the stance, it is clear that as things stand, many organizations are not keeping a tight enough rein on privileges. New data out today validates what grizzled security vets have been saying for what seems like forever: People have way too much access to sensitive data that they don't really need to do their jobs. The numbers come by way of a survey conducted by Ponemon Institute on behalf of HP, which queried more than 5,500 security and operations managers around the world about privileged identity issues.

The survey shows that 64 percent of organizations say it is likely that privileged users think it is OK to access all of the information they can view, and 61 percent report that privileged users access sensitive information for the sake of curiosity rather than job function.

Many organizations are winging it when it comes to assigning and keeping track of who can access what sensitive resources. A little more than 40 percent of organizations say the way they assign such privileged user access is ad-hoc, with just 27 percent of organizations reporting that they use some kind of technology-based identity and access management controls to detect sharing of system administration rights sharing or root level access

[ How can enterprises quickly provision new users with secure access and "off-board" users who should no longer be on the system? See "Tech Insight: Securely Adding New Users -- And Subtracting Old Ones." ]

"It's almost impossible in an organization of almost any size whatsoever to understand exactly what rights everybody needs to every single application and service that they need to get their job done," says Ryan Kalember, senior director of solutions marketing for HP Enterprise Security. "Even worse than that, if you ask them the question of what rights they need, they'll probably ask for the maximum access that is possible because they never want to talk to a security admin again."

According to Kalember, one of the problems with managing privileged users today is that current identity management deployments don't scale well across the entire enterprise; organizations just can't keep track of every possible privileged account using a federated approach.

"There are billions of dollars essentially flushed down the toilet in failed IDM deployments because it's just too complicated, depending on the organization's culture and their IT architecture, the breadth of applications they're using, and lots of other variables," he says. "So then it becomes a matter of looking at it differently."

What he and HP advocate is utilizing logging and monitoring infrastructure to take a snapshot of user activity, develop a baseline of what is normal, create policies around that, and begin enforcing privileged access from there.

"If you're monitoring, you can build up a picture of what is normal, and you can use that to properly configure an IDM. You have a very good idea of which permissions are being used on what systems, how and when they are being used, and by whom if you chose to correlate that with your identity management system. And that means you can take a picture of user activity and figure out what is happening, living in the messy real world and acknowledging that nothing is going to be perfectly corresponding to your vision of what roles should be defined as or what access rights," Kalember says. "You actually just look at what's happening and then build up the picture of roles based on that. That becomes a positive feedback loop. That becomes self-sustaining."

But Phil Lieberman of privileged identity management vendor Lieberman Software says there is a big Achilles heel in that method.

"So essentially you understand where to put the locks after you put the cameras up after they've broken in? The assumptions they're making are just wrong," he says. "In privileged identity, there are two classes of identity: There are those that are named and then those that are generic accounts. There is some validity to their statement that if you use the named accounts, a logger is a great idea. But most privileged accounts are those like 'root' or administrator, and you don't know who is using those accounts. They're essentially using the camera to take pictures of who you can get a picture of, but in other cases it is people with ski masks on who all look exactly the same."

Kalember agrees that "shared accounts aren't always easy to root out." But he says there are methods for monitoring tools to tie specific users to these accounts.

"One of the big use cases in ArcSight for our customers has been using IP address attribution, which doesn't sound like a very entertaining thing. But you can basically say, I know Joe is on 192.168.1.2, so even though he logged into an account that is hard-coded into an application that got written in 1998, and that account is called 'root' or 'admin,' I know it's Joe because he's on that IP address," Kalember says. "So then all that activity I can attribute back to him. I can pass an audit. That stuff comes up very frequently, so you're sort of extending the useful lifetime of legacy applications where rewriting them may not even be an option."

However it is done, tying identity of the user to privileges rather than tying accounts to those access rights is the key to getting a better handle on who sees what within the organization.

"The discussion should morph from being about controlling the credential to controlling the user's access," says Patrick McBride, vice president of marketing for privileged access management firm Xceedium. "That's what they're really trying to control: Who has access to what. You have to have the identity established to do that. So tying an individual -- not an IP address or not something called 'root' -- tying the person who's actually doing something to what they're doing, that's what the auditors want."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.