The SAP GRC Access Controls product is designed to support customers in their compliance objectives. To that end it comes with a number of “out of the box” capabilities to achieve this status for the connecting systems.
A common issue faced in the previous versions of GRC (5.1 to 5.3) was that the GRC system did not adhere to SAP best practice principles for system management and changes. Historically, it was easy to counter the application maintenance best practice by saying that GRC is different and not subject to the normal SAP application management conditions. Being a java environment, it did not have the transport management system available as standard to track changes in a controlled manner. Therefore, configuration changes had to be made in production directly and user authorisations were necessarily wider to be able to use the system.
Similarly, with it not being based in ABAP, the GRC system could not make use of the Firefighter application for elevated access management. The authorisations also relied upon standard java based actions rather than the object level security afforded to most SAP applications. Therefore, astute auditors raised questions over the compliance of the compliance tool. This often led to manual controls being documented and operated on the GRC system.
No more excuses
With GRC 10 being based on the SAP Netweaver ABAP there are no more excuses for managing GRC systems in a non-compliant manner, yet many implementations still do not have compliance at the heart of their implementation methodology. It is very easy to focus on the core functionality to support the SAP system processes (i.e. automated provisioning and emergency access management) but how many of the GRC implementations really take the time to understand the GRC operating processes as well?
GRC projects might then follow the pattern of what security professionals continually struggle against.
What are the symptoms?
There are tell-tale signs that not all is well with a GRC implementation. Some of these include:
- Authorisations are very close to, if not exactly like SAP standard proposed roles.
Authorisations are regularly relegated to the bottom of the priority list in favour of making the technology work. - The administrative functions of GRC may be left largely undefined.
The result of this is that administrators may retain pervasive access to the GRC system under the guise of post go-live support. - Configuration changes made directly in follow on systems.
When consultants do not have significant experience in working with ABAP systems, projects may take the easy way out when performing configuration by choosing to open the client for changes rather than think about the appropriate way to transport. This is especially true with configuring the connector landscape.
What does good look like?
1. Proper security and authorisations management
There is no reason why GRC should not be used to report on itself by installing the plug-in into the GRC system. From a GRC functionality perspective, this will then allow GRC authorisations to be included, reported on and assessed as part of integrated access management processes. I would therefore expect to see that additional risks are included in the ruleset which have a GRC flavor e.g. workflow administrative access. I would also expect to see some customisation of the standard roles to fit the individual business scenarios alongside a clear roles and authorisation design to evidence that this was actually considered.
2. GRC emergency access scenarios
Firefighter can also be used to support elevated access to the GRC system as well as to the other systems in the landscape. I would expect at least some Firefighter scenarios for standard Basis system maintenance access if not access to the workflow administrative access.
3. User provisioning and role management
Provisioning to the GRC system can also be included in the access request workflows and roles can be built and managed through Business Role Management. I would expect to be able to submit access requests for GRC system access in the same way as I would for other SAP applications.
4. Best-practice application maintenance processes
Perhaps more importantly, with GRC based on standard ABAP technology it should no longer be subject to a different set of rules around system and application management. Transports can and should be used wherever possible to align to good practice for IT general controls. Opening the client should be a last resort for changes which cannot be transported rather than an easy way out to correct poor development practices.
5. GRC system controls
In more complex operating environments, it is vital to consider the controls which should operate on the GRC systems. In the majority of cases, the GRC system should be able to rely upon the controls applied throughout the rest of the SAP estate. However, care should be taken that the specific functionality used in GRC should be taken into account and the control descriptions updated to reflect GRC processes.
It is important to also think about the impact that GRC has on the wider application as some very sensitive processes such as user provisioning and emergency access management may well be managed in the GRC system rather than directly in the SAP application as a result of the GRC implementation. This should definitely be reflected so that it is clear to all parties.
Impact on Implementations?
So what does this mean for implementation projects? Ultimately, I believe that this should make very little difference to the better examples of GRC implementation projects. These good examples of projects will always have security and controls at the heart of the project. Therefore, looking for control gaps and finding ways to plug them will ensure that it is not just the technology that is implemented; but that it is implemented with clear operational guidelines for how to maintain the compliance status.
It is the experience and diligence in getting these factors right which will differentiate specialist implementation partners with a proven track record in successful GRC projects. The alternative is a potential solution which may provide the superficial impression of control but still leave further findings or significant control gaps available for auditors to find and opportunists to exploit.
