Skip to Content

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.

  1. 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).
  2. 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’”.
  3. 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.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.