Monday, 13 August 2012
Posted by Simon Persin
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 flavour 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.
Thursday, 2 August 2012
Posted by Richard Hunt
Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. In this two part blog entry we explore how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can improve the effectiveness of internal controls in the long-run.
A conversation with one of our customers recently got me thinking about the way that most GRC projects are commissioned, and about how things could be different if a slightly more forward thinking approach was taken. This blog will explore, in two parts, how the deployment of the SAP GRC toolset at the outset of a Greenfield implementation can offer a significantly more effective implementation in the long-run. We start with SAP GRC Access Controls.
A GRC Access Controls project will typically be initiated for one of two reasons:
- In response to an audit report recommending improved controls.
- As a result of a process improvement initiative.
Unfortunately we still rarely see GRC as part of a Greenfield SAP deployment. GRC will often either be overlooked in scoping or become a casualty of tightening budgets at some stage of the project. This is a shame as there are a number of reasons why implementing GRC Access Controls at the outset of a project can be hugely beneficial.
A Compliant Role Design
Any implementation of SAP will require the implementation of SAP roles to support access control requirements and facilitate segregation of duties (SoD). Whilst SAP roles are often designed and built without a segregation of duties tool this approach will inevitably lead to some form of role remediation to align the SAP roles with an SoD ruleset. Even if SoD rules are not defined during the initial implementation a subsequent audit will almost always necessitate some form of remediation activity to achieve this.
By implementing the SoD monitoring tool (Access Risk Analysis) at the same time as the SAP roles it is possible to develop a role design that aligns with the SoD ruleset from the outset, avoiding this subsequent re-work and the associated costs and disruption to the business. This approach is also likely to result in a role design that is easier to maintain as, in the absence of a complete re-design, most post go-live role remediation projects will necessitate some compromise in role design.
A Complete Audit Trail from Day One
Although not widely used in pre-production systems the Emergency Access Management (EAM) module comes into it’s own in a project environment. There are a number of scenarios during a project where elevated access needs to be allocated in a controlled way and EAM is the ideal tool to achieve this. For example, during cutover it will often be necessary for project team members to execute business transactions as part of a data load. Similarly, fire fighting during the hypercare period immediately after go-live will often necessitate higher access privileges than a ‘normal’ business as usual support environment. Making the EAM module available to the project team is an excellent way to provision this elevated access in a controlled way and it will also ensure that an audit trail of high privileged access is available from day one.
Modern Access Control Processes
A Greenfield SAP implementation will most likely require some changes to the IT support model in order to provide an adequate run and maintain environment post go-live. User Access Management processes will vary significantly if an SoD tool is in scope as these processes will need to incorporate SoD analysis. Today’s GRC applications also enable automated provisioning which will further change the UAM process. By deploying these tools into the Greenfield implementation it is possible to design UAM processes that incorporate the most effective use of the GRC tools available from the outset. This will not only save money but will also avoid some of the challenges that many GRC implementations face in failing to secure sufficient business engagement to make best use of the GRC tools.
Many Greenfield SAP implementations will exclude SAP GRC from scope, treating it as an optional module that can easily be implemented post go-live. Clearly this over simplifies things. My hope is that readers of this blog entry will challenge the assertion that the deployment is of GRC is not part of the initial project scope and will argue that GRC should be treated as part of the core solution infrastructure in a similar way to solution manager. After all, why wait until your first audit to be told that you should have included it?