Analyzing the Poneman Study on Privileged Users

Thursday, December 29, 2011

Rafal Los


Analyzing the Poneman study on privileged users: 3 steps to build your process for employee access rights

You trust your employees and administrators with the most critical technical functions in your organization - but they're only human. 

Curiosity gets the best of everyone eventually, and when it does do you trust your technical controls to keep those that are manning the ship from peeking at its secrets? 

How much access do those employees and system administrators have to your critical intellectual property, company secrets and other secret information?  And how often do they take a peek behind the curtain... you know, just for curiosity?  This reminds me of the new study by the Ponemon institute, sponsored by HP Enterprise Security, which was released recently.

To ensure the study spoke to the people who have the level of access required to do significant damage to the organization, the respondents broke out like this:

"Sixty percent of respondents are at the supervisor level or higher and most report to the chief information officer. On average, respondents have been employed in their current position for slightly more than 7 years.  According to 77 percent of respondents, privileged access rights are required to complete their current job assignment. However, 23 percent say the access rights they have are not necessary for their role."

The study had some very interesting findings, mainly around why people have access beyond what they need, how it's monitored (or isn't), and some of the hints around the reasons for these access gaffes.

If we look into the detailed findings, one of the things that caught my attention was the 'privileged access' ... which generally means to data and functions.  Of the 23 percent of respondents that admit to having more privilege than they need, the one response that strikes me most as to why is "...for no apparent reason." 

Having worked in extremely large and complex organizations in my past life, I can honestly understand the situation where a person changes roles and their access is compounded rather than changed (old privileges not revoked) - but what I don't understand is the response "everyone at my level has privileged access even if it is not required to perform a job assignment." 

According to the study, this represents43 percent of respondents, and that absolutely blows my mind.  It's just a complete and utter lack of process and understanding.  The only logical (if you can call it that) reason why organizations would assign privilege across the board is if there is a complete breakdown in understanding at the role level. 

If the organization fundamentally does not understand what your role is, and how you need to accomplish it, everyone requires access to everything... and this is an extremely dangerous situation to be in.

What makes this situation compounded is that 64 percent of privileged users believe they are empowered to access all the information they can view.  Think through that for just one minute.  Let's combine the fact that organizations generally appear to misunderstand what role-based access users and administrators require with the sense of entitlement users feel to what they can access - and this situation gets bad, fast.  The second-most popular response to the question 'why' is "curiosity." 

Yes human beings are naturally curious and will access information they have privilege to - just because they can, and they're curious.  What happens next is a roll of the dice for most enterprises. While I don't want to go through the entire 33-page study titled "Insecurity of Privileged Users - Global Survey of IT Practitioners" ...which you can do on your own, there is some analysis here that I feel obligated to impart.

First, privilege is an often-misunderstood and dangerous thing.  When privilege is misunderstood the organization falls into chaos.  The situation where you can't define the difference between a dish washer and a master chef is dangerous because you don't know who's accessing your secret recipes, and making your signature dishes.  Privilege is also dangerous because it's so difficult to quantify especially once the organization is up and moving. 

Anyone who's tried to understand privilege within a fluid organization that's been around for a while will tell you just how difficult it is.  It is unlikely that your manager can identify all the access to processes, data, systems and applications you require to do your job - and it gets more difficult as workloads are shared and organizations expand/contract. 

There are many organizations out there that are in the 'everyone has access to everything' mode - some worse than others - as a matter of necessity.  Are you sure you're not one of those organizations?

There is a three-step process around privilege in any situation you're a part of.  The first critical step is understanding privilege, first and foremost.  Once you've understood it, you can implement and then ultimately govern and monitor privilege usage and distribution.  Let's look at this quickly.

Step 1: Understanding privilege

Step 1, or ground zero, for having a solid privilege model is understanding how your organization is built.  This is a complex idea in and of itself, but it breaks down to fundamentally "what are your critical processes, systems, applications and data, who should have access to these, and in what capacity? 

You'll need to answer the what, the who, and the how in order to be successful in understanding privilege.  This is one of the reasons many identity management system implementations linger in organizations much longer than projected, and eat up more budget than even dreamed... complexity. 

No one person is doing just one task on one system... ever.  This means that fictitious user John from accounting has access to 12 applications (wait, do we need to go into the difference between authentication and authorization?), three drive shares (with probably more data than he's supposed to see on those drive shares, a host of other things. 

When John becomes part of a new project he's given more access... probably on a user level rather than a group or role level which means John now has rights spread all over the place across your enterprise and there's no way to understand it comprehensively - unless of course you're using that spreadsheet still.

All joking aside, privilege is extremely difficult to manage in any size organization, and the higher your velocity of change, the more difficult privilege is and the more likely you will devolve into a situation where everyone eventually has much more access than they should.

I will put up a separate post on my tips & suggestions for managing a privilege process... shortly.

Step 2: Implementing privilege

Implementing privilege across the organization is done with a combination of manual processes and automated tools.  The more heavily you can emphasize the automation aspect, the better off you will be, at last for sanity's sake.  Implementing privilege across an organization - even a small one - is difficult to do manually. 

There are a lot of great technologies out there which can help you to script your way to managing privilege and even let you sleep too!  I won't get into those here, but identity management solutions exist everywhere, just be careful of the ones that promise too much.

Step 3: Govern and manage privilege

Once you've got your organization understood and implemented, it's going to be time to monitor and carefully govern to ensure you're not back to this mess you just fought your way out of in a year or less. 

Modern organizations are so fluid it's difficult not to fall back into privilege chaos, but you should absolutely think about keeping a watchful eye on your systems, applications and data to make sure that someone isn't trying to get into things they don't have rights to.

And the final analysis...

The Ponemon study is certainly interesting and hopefully applicable with all the talk of insider attackers lately, and the fact that I'm still in the middle of a big series on Data Loss Prevention (which this is right in the blast radius of!).  If you find something else interesting in the study that I may have missed or overlooked, do post your own analysis here or some place and I'll happily link to it! 

As with any commissioned study - your mileage may vary, some assembly required and batteries are not included.  Draw your own conclusions...

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Network Access Control
Information Security
Enterprise Security Security Strategies Access Control Poneman report Network Security Privilege Escalation
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.