Home > Risk > If you weren’t already worried about privileged users, you should be

If you weren’t already worried about privileged users, you should be

The issue of privileged users, and the risk that their access presents, is one many of us have been concerned with for a long time. At the end of this post, I will share stories from my (long-ago) past as an IT auditor and IT executive.

A new study by the Ponemon Institute (sponsored by HP Enterprise Security) brings the issue to life. Insecurity of Privileged Users is not a theoretical study. The authors surveyed the people with privileged access themselves. Who are they?

“For purposes of this research, privileged users include database administrators, network engineers, IT security practitioners and cloud custodians……. We believe respondents have a deep understanding of the potential risks to sensitive data because they have privileged access in their organizations.”

Why is privileged access a risk? Because it can be used to bypass controls and make changes, delete, or add data – or make changes to application code. If the capability and its use is not controlled, inadvertent, inappropriate changes can lead to major systems disruption – let alone deliberate actions to damage the organization or enable fraud.

I admit to being surprised – and not in a good way – by the results. How about this quote from the report?

“According to the findings of this study, these individuals often use their rights inappropriately putting their organizations’ sensitive information at risk. For example, the majority of respondents say privileged users feel empowered to access all the information they can view and although not necessary will look at an organization’s most confidential information out of curiosity.”

Now for some of the details:

  • “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.” I will tell you from personal experience that while many of these people may believe they need privileged access, they don’t need it as often as they assert. They have ways to get most of their job done with special access, and when they need it the access (such as SAP_ALL in an SAP environment) can be assigned for a limited period and its use monitored by management.
  • 43 percent said “Everyone at my level has privileged access even if it is not required to perform a job assignment” and 12 per cent said “The organization assigned privileged access rights for no apparent reason.” 11 per cent had no idea why they had privileged access.
  • “According to 64 percent of respondents, it is very likely or likely that privileged users believe they are empowered to access all they information they can view and a similar percentage (61 percent) say privileged users access sensitive or confidential data because of their curiosity.”
  • “The countries where privileged users are most likely to access sensitive or confidential data because of their curiosity are France, Australia and Italy.”
  • “52 percent of respondents say it is likely or very likely that the organization will assign privileged access rights that go beyond the individual’s role and responsibilities.”
  • “Forty-two percent of respondents say the risk to organizations caused by the insecurity of privilege access users will increase over the next 12 to 24 months and 42 percent say it will stay the same. Cloud-based applications,   virtualization and regulations or industry mandates are the primary reasons for this belief.”
  • “41 percent say the best way to describe the assigning of privileged user access to IT resources is ad hoc.”
  • “Almost one-third (32 percent) of respondents are not confident and six percent are unsure that their organization has enterprise-wide visibility for privilege user access and can determine if these users are compliant with polices. The primary reason for this lack of confidence is the inability to create a unified view of privileged user access across the enterprise.”
  • “Only 27 percent of respondents say their organizations enforce access policies in a consistent fashion. Further, only 29 percent say their organizations have an excellent or good understanding of privileged users’ entitlements that violate policy.”
  • Just 51% said that segregation of duties was adequately enforced.
  • Many privileged users believe they have permission to “circumvent IT security requirements” in order to deliver services: 67% in the US and UK, 72% in Italy, 70% in Brazil, and 65% in France. Germany and Singapore had the ‘best’ results, with only 12% and 13% asserting such permission.

The report includes several excellent recommendations. When you consider that the top barriers to effective control of privileged access are identified as budget, lack of technology, and ineffective provisioning systems, I would advise organizations to do the following:

  1. Understand and assess the current situation, the level of risk to the organization, and the barriers to effective management of privileged access
  2. Accept the philosophy that access to information assets should only be given to people that have a valid business need. Not knowing why people have access rights is unacceptable
  3. Also accept the philosophy that privileged access should not be granted to anybody on a permanent basis. It should be granted only when needed, for a limited time, and then monitored to ensure it is used as approved
  4. Give strong consideration to the use of technology that will streamline both user and IT access provisioning, routing requests for approval to the right people – not just the employee’s manager, but the owners of the resources in question
  5. The technology should enable privileged access to be granted only when needed to address a business problem that cannot be resolved without it, and then provide monitoring of its use
  6. The technology should also include the capability to identify potential segregation of duties (SOD) issues before an access request (whether from a business or IT user) is approved. If it is necessary to grant access that will create an SOD issue, then the technology should enable the identification of a compensating control and/or monitor inappropriate use of the access
  7. Ensure you have the ability to monitor both inappropriate access rights, and inappropriate violations of policy
  8. Upgrade your processes and implement the technology. In my experience, the ROI is very clear: not only a reduction in risk and actual disruption, but a major reduction in the administrative cost of provisioning, detecting and correcting excess access situations
  9. Provide periodic reports to management showing progress, and
  10. Continually monitor and improve the access rights management processes – especially as new technology, such as mobile enterprise applications, is adopted

What is your opinion? What is your experience?


As I said, I have some personal experiences concerning access rights that you might find interesting.

  • As an IT auditor in the UK with Coopers & Lybrand, I was one of the first in the office to get involved in addressing risks involving systems programmers and their access. One of my concerns was their use of utilities such as Superzap (in an IBM MVS environment). What the programmer does is specify an area on a disk or in memory, have the utility confirm its current content (an option), and then insert or change the content to new values. The systems programmer can therefore not only change data in a file, he can change data in memory while a program is running. When I met with the CIO, he agreed to take action to limit its use. The manager of systems programming told the CIO and me that he had changed the name of the utility in the system, so that anybody trying to run it (its correct name is AMASPZAP) would not be able to locate it. They would have to come to him for permission and to find out where he had hidden it. For whatever reason, I didn’t 100% trust the answer and went digging. I was able to determine that the name AMASPZAP no longer worked; but the systems programmers all knew the “new” name, because it wasn’t really a new name. The “new” name was simply the alias (IMASPZAP) for the utility. The lesson I learned? These guys wanted their access, thought that going through the approved process was too bureaucratic, and didn’t think anybody would be able to catch them out – not the CIO, and certainly not an accountant turned IT auditor (me).
  • After I moved to the US, I remember talking to systems programmers who told me that Superzap was tame. They had this utility called DEBE. Innocently, I asked what it did: “anything and everything you want. DEBE stands for ‘does everything but eat’”.
  • Some few years later, I was in IT as a vice president, leading a number of groups including a new information security function. The team was implementing the ACF2 product and was having occasional run-ins with the systems programmers. It’s not that they were anything but ethical – they just had a healthy level of ego and thought information security was not only for everybody else, but they could hack their way around it. Well, to make a long story short, my more technical information security analyst found that they were accessing sensitive data and changing the log file that recorded the change. But, she found the log entry that recorded their deleting the record of their access. Red faces on the systems programmers, and big smiles on my team’s faces.

Rather than repeating my last story, about excess user access and SOD issues while I was at Maxtor, please read this post from last year. It is a great example of how IT can rack up cost and fail to control user access – and why building the business case for technology is not hard.

  1. April 5, 2012 at 5:36 PM


    Interesting post and I would like to add one more angle to it. In ITES sector, the employees are working in India, however, the systems and databases are in the host country normally where the head office is located. Hence, access is granted and controlled by the host countries system administrators and local offices have no information whatsoever.

    In this case, the backend logs can be modified by the host country system administrators and the blame can be conveniently put on the Indian employee. For example, in case of identity theft of customer information, an Indian employee can be blamed for unauthorized access, when actual theft was done at host country.

    In your view, what controls should be put in place to control this activity?


  2. Norman Marks
    April 5, 2012 at 5:41 PM

    Sonia, that’s an interesting situation. I will leave it to the experts but I would think the main thing is to limit access in all areas. In the case you describe there should still be some record of the change to the log. Even turning off the log should be logged!

  3. April 5, 2012 at 6:02 PM


    You are talking about an ideal scenario, and I agree with you on the best practice. But in reality, specially in the fraud scene, the situation is different. I remember I was once cracking a big case and asked for the backend logs of customer accounts to detect fraudulent activities. I got a response, you will find it hard to believe – we don’t maintain backend logs (of sensitive customer information mind you) as it is not cost effective. Who is taking these decisions? And in fraudulent transactions, most of the transactions can be passed through by system administrators even when a business user has stopped the transaction.

    In such cases, though the information is available nothing will be provided and if provided may not be reliable. Though if you do a google search you will find a lot of talk about how good the systems are.


  4. April 5, 2012 at 6:33 PM

    To add, in fraud cases, it is best to tie up information available from internal fraud systems with information available with external sources. Then the discrepancies can be explored and a more informed decision can be made.


  5. Frans
    April 6, 2012 at 12:43 AM

    I do miss the basic or first ‘priviliged user’, the system administrator, like the windows administrator of Unix/Linux root accounts. They can have unlimitied accesse and are able to change the loggings about their whereabouts. In large companies, you can take mitigating controls. In small companies without SOD you must hope you hired an integer person.

    But many can be added to the list: SAPALL, etc..

  6. October 17, 2012 at 12:53 PM

    Thank you for this article. I feel like this is the #1 most useful practice for using any computer or resource more securely. Most of the time Administrative, or Privileged access is not required. Running in the administrative context is akin to walking around with a loaded gun in your pocket.

    I wrote an article targeted for your average user that features the concept you’re advocating for in this artcle, which is not to run as a privileged user for day to day use. I have also linked this very article as a reference. See my article here: http://itwurx.net/blog/simple-windows-tips-to-avoid-viruses-and-increase-security/

  7. October 18, 2012 at 6:47 PM

    The information you’ve provided here is extremely useful and relevant. It helps bring to light a serious issue facing businesses and the server administrators and information security professionals they employ. Not to mention their customers or end users.

    Too often, at least with servers, a user is put in the local administrator group because it’s easier than taking the time to delegate specific rights based on that user’s job function or actual need. And once an end user has that level of access, it’s hard to take it away – even with the proper justification.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: