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

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
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

Best of the Web