These users often have virtually 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. Yet super users are not CEOs and CFOs, responsible for the overall success of the company.
Instead, system responsibility is handed over to IT managers, who are often third parties, with no vested interest other than a monthly salary and the motivation to do a good job. The level of system access required by super users makes them supremely powerful, and must therefore be developed and deployed in a controlled and auditable manner.
Defining access rights
When defining security for power users, environmental aspects must be taken into account: 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 different from ongoing access where the system is far more stable. 'Everyday' super user access versus exceptional or 'fire-fighting' rights must be considered. Some support users will require wide access on a day-to-day basis, but if something goes seriously wrong, their security will need to be temporarily - and immediately - expanded to rectify the issue before it has a detrimental effect on the business.
When defining access rights for the super user community, it is important that timing and platform requirements as well as cross-platform factors are taken into consideration.
Productive and pre-productive environments
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. However, super user access is critical during a productive environment.
For example, 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.
Cross-platform segregation of incompatible duties
Platform-specific access to the power user community is also important. 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. IT users will probably have extremely wide access in a development system. They will be able to modify configuration and also have the ability to migrate changes to other systems further down the 'promotion path'.
However, 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. Companies often segregate sensitive functions within a given environment, but don’t take into account the consequences of power users having the ability to migrate changes through the systems.
Temporary excessive access
It is sometimes essential to grant a super user excessive power to overcome an issue that would otherwise prevent a project going live successfully. However, if this additional access is not removed after the event, 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.
(More than 50 per cent of businesses consider their own employees to be the greatest IT security threat, according to a survey undertaken by IT governance in 2013).
There will always be a need to grant excessive 'superpower' access to people, but 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.
Five point checklist
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 to have wider access than others, but this does not have to put the business at risk. The following is a key checklist for any organisation with a super user community:
- Before building any super user access ensure that SoDs are defined. Although segregating certain activities may add time to the process (for example, creating, approving, and moving changes from one system to another as segregated activities) the increased control it enables is essential.
- Ensure that all SoDs are defined with a cross-system mindset. Most pre-productive systems will be connected with a migration path. While individuals may have their security segregated within a system, that access in other systems must not violate the SoD rules already defined.
- Define security appropriate to the system on which users are working. Full access in a sandbox environment that has no migration path to production is not an issue for most organisations. However, this is not appropriate in a development, test or live system.
- Define 'fire-fighting roles' where temporary wide access is required to fix a bug or a problem. Ensure that procedures are in place for the approval of these rights, the subsequent removal of the access in a timely manner and the monitoring of activities performed when the access is being used. Ideally third-party products, such as SAP’s own GRC application, can be used, which automate this control and provide a complete audit trail of changes made. Utilising super-user privileges in the controlled manner enforced by these products ensures that wide access is thoroughly controlled.
- Work with the audit function to make sure that the controls defined are adequate for the business.
It is tempting to believe 'it won't happen to us' when it comes to super user systems access. However, with technology available to prevent security breaches of any kind, organisations should make using it a business priority.
