The role of 'superusers' and project teams and the risks and controls that must be considered when assigning them access.
In a post Enron and Bearing world, the way we work has changed significantly, and nowhere is this more apparent than in the audit and control arena. Security and controls used to be far too low on a project manager’s priority bring much more focus to this area.
Whilst the security landscape may have altered, necessity dictates that it is still essential to have system 'superusers'. These users have almost unlimited access to company data in order to successfully implement and launch a project, as well as ensure it runs smoothly in the critical early days. But superusers are not CEOs and CFOs, responsible for the overall success of the company. Ironically, although their status justifies them easy access to any organisational detail they require, the reality is that this is more than they need on a day to day basis. System responsibility is therefore handed over to IT managers. These are often third parties, with no vested interest other than a monthly salary and the motivation to do a good job – and yet their level of system access makes them supremely powerful.
So how can superuser access be developed and deployed in a controlled and auditable manner? There are two main factors that must be considered when defining security for power users. Firstly environmental aspects must be appreciated: At what stage is the project lifecycle and what systems are being worked on? Security within a sandbox will obviously be very different than in a productive system for the same user. Security during a go-live where quick fixes are essential will be differe
nt from ongoing access where the system is far more stable. Secondly 'everyday' superuser access vs. exceptional or 'firefighting' rights must be considered. Some support users will require wide access on a day-to-day basis but when something goes seriously wrong, their security will need to be temporarily expanded to provide a fix before the business grinds to a halt.
Protecting the environment
When defining access rights for the superuser community, it is important that timing and platform requirements, as well as cross platform factors, are taken into consideration.
Timing is less of a factor in pre-productive environments where security is likely to be the same during the implementation, go-live, and subsequent maintenance but will greatly affect superuser access in a productive environment. The initial days of a live system are the most critical and power users will have a greater responsibility to keep the business running, especially as the end user community will be accessing the system for the first time. Although the requirement for wider access is obvious during this 'hyper care' stage, the need for control must not be ignored. It is highly recommended that principles laid out in the firefighting concept (below) are adhered to and that the superuser community has extremely limited access to create and maintain business data.
Where an end user has to be walked through a business process, a training system should always be used so that live data will not be affected. Where a user has incorrectly entered live data (and does not have the permission to reverse or cancel the posting) two courses of action can be taken. Either another end user should be identified who can make the necessary amendment, or a firefighting role should be used with all actions documented and signed off. This approach is the only way
to ensure that superusers cannot ‘play God' in an uncontrolled manner.
Platform specific access to the poweruser community is also an important consideration when defining specialist access. While careful consideration should be given to segregation of incompatible duties (SoDs) granted to these users in every system, cross system SoDs must also not be forgotten. In all likelihood, IT users will probably have extremely wide access in a development system – somewhere near SAP_ALL. They can probably modify configuration and also have the ability to migrate changes to other systems further down the 'promotion path'. But if these users also have the ability to move configuration through the different environments to production, what is the point of restricting their access in the live system? Cross system SoDs must be defined and monitored. So often companies carefully segregate sensitive functions within a given environment and completely ignore the consequences of power users having the ability to migrate changes at will through the systems.
Problem solved, job well done?
It is sometimes essential to grant a superuser excessive power to overcome an issue that would otherwise prevent a project going live successfully. But in the heat of the go-live moment, this additional access must not be forgotten. If it is not removed, there is the risk that even the most loyal employee or conscientious contractor, will have temptation put too firmly in their path to be able to resist it. (In a recent survey by Leicester University, 70 percent of the 2,000 people questioned admitted they would commit fraud, if they knew they would get away with it. Recession exacerbates this risk – in August this year, fraud prevention service CIFAS reveale
d that the rate of dishonest employee actions had increased by more than two thirds (69.5 percent) between the latter half of 2008 and the first half of 2009).
The bottom line is that there will always be a need to grant excessive 'superpower' access to people but that control of this is paramount. Where such security has to be assigned to ensure the business continues, procedures must be in place to approve the access, monitor activities performed during the time it is allocated, and then immediately remove it once the problem is fixed and resolved.
Whether the system is live, or still being developed, the need for control over superpower access must be high on the priority list. Some individuals will always need the ability to have wider access than others but this does not have to put the business at risk. The following should form a key checklist for any organisation with a superuser community:
- Before building any superuser access ensure that SoDs are defined. Although segregating certain activities may add time to the process (e.g. creating, approving, and moving changes from one system to another as segregated activities) the increased control is a necessary evil.
- Ensure that all SoDs are defined with a cross-system mindset. Most pre-productive systems will be connected with some sort of migration path. While individuals may have their security segregated within a system, that access in other systems must not violate the SoD rules you have defined.
- Define security appropriate to the type of system the users are working on. Most companies do not care if users have full access in a sandbox environment which has no migration path to production. But this access is not appropriate in a development or test system, and
certainly not in the live system.
- Define 'firefighting roles' where temporary wide access is required to fix a bug or a problem. Ensure that procedures are in place on the approval of these rights, the subsequent removal of the access in a timely manner, and the monitoring of activities performed when the security is being used. At a minimum this should be a full set of documentation and review of the work performed. Ideally third party products can be used which automate this control and provide a complete audit trail of changes made. There are a number of tools out there, including SAP’s own GRC application. Utilising superuser privileges in the controlled manner that these products enforce will ensure that wide access is not abused and thoroughly controlled.
- Work with the audit function to make sure that the controls defined are adequate for the business.
In today's business environment, it is not enough to believe 'it won't happen to us' when it comes to superuser systems access. The technology is available to prevent security breaches of any kind, and organisations have a responsibility to use it.