Your GRC: Is it truly cyber resilient?

This article is a collaboration between Jonathon Pasquale, Director at Altum Strategy Group, and Barry Snow, Technical Account Manager at SecurityBridge. 

Introduction

There is much focus on S/4HANA projects these days. So, I want to call your attention to another one of those non-S/4HANA systems that are facing an SAP 2027 deadline. As you might know by now, the 2027 deadline is not only for ECC, but ALSO for anything running on SAP NetWeaver 7.5 platform or lower. Many of these systems are expected to have cloud-native replacements in the future.  Although S/4HANA remains at the center of the ERP constellation, we will highlight another equally important “supporting actor”.  SAP Governance, Risk, and Compliance is best known simply by its acronym: GRC.  SAP GRC is a solution that many architects are hesitant to see as cloud only. Let’s take a few minutes to discuss what it means for your SAP GRC system to be truly cyber-resilient. 

Why Protect SAP GRC now?  

💡 GRC is closely linked with SAP CyberSecurity, managing security objects in the connected SAP systems.  But this also makes it an ideal target for a threat actor!   

In my June article on BW/4HANA Cyber-Resilience,  we discussed that the most important system to protect is your S/4HANA, since it is the “system of record” for so much data… from there, we followed the data downstream to BW/4HANA.   

Then, I contributed an article on Cyber-Resilience for SAP Solution Manager.  We discussed that “Solman” is a “well-connected” system, and that by protecting your Solman system, you effectively give better defense to all your SAP systems..  We discussed that “Solman” is a “well-connected” system, and that by protecting your Solman system, you effectively give better defense to all your SAP systems. 

This month’s article is the third in a series and the first in collaboration with Altum Strategy Group.  Altum is a management consulting firm, founded in 2019 and provides unprecedented access to senior leadership representing decades of collective experience in management consulting and industry. Altum has deep experience in GRC software solutions and processes with crew members leading the design, implementation, and operationalization of GRC tools over 150 times in addition to dozens of security role design and remediation projects for organizations across numerous industries. 

What exactly is SAP GRC?  

💡 “SAP GRC” is both a product and now also, an evolving “brand family” of products.  As a single product, SAP GRC 12 is implemented on a single SAP system performing as a Management System for the Governance, Risk, and Compliance of other SAP systems.  But also, SAP is evolving the GRC brand to include new applications and merge into the SAP cybersecurity market segment.   

For this article, let’s focus on SAP GRC 12.  There are several “modules” that comprise the SAP GRC 12 suite of capabilities.   

Access Control is a module designed to help organizations manage and monitor user access to sensitive data and systems, ensuring that employees have the correct level of access based on their roles while minimizing the risk of fraud, errors, and regulatory non-compliance. The module automates the management of user permissions and access rights within SAP systems, helping organizations adhere to data protection laws, internal security policies, and audit requirements. 

• Access Risk Analysis (ARA): it is the core feature that identifies potential risks in user permissions by evaluating whether employees have access to incompatible transactions or conflicting permissions that could lead to fraud or data breaches. The ARA tool allows for continuous risk analysis to prevent or remediate potential access issues. 

• Emergency Access Management (EAM), also known as “firefighter” access, allows authorized users to temporarily gain elevated permissions to resolve critical system issues. The feature includes audit trails and logs to monitor activities performed under this special access, ensuring accountability and compliance. 

• Business Role Management (BRM) centralizes the design, testing, and maintenance of user roles, simplifying the assignment of access rights according to job functions. It helps standardize role assignments across the organization and reduces the administrative burden associated with manual role provisioning. 

• Access Request Management (ARM) streamlines the process of requesting and approving access changes. It automates workflows for creating, modifying, or deleting user access, ensuring that access requests go through appropriate approval channels. This module includes self-service capabilities, allowing users to request access directly, which is then routed for automated or manager approvals. 

• User Access Review (UAR) facilitates periodic reviews of user access rights to ensure compliance with internal controls and regulatory requirements. By conducting regular access reviews, organizations can validate that users have the correct access based on their current roles and responsibilities, maintaining a secure access environment.

SAP Process Control – Process Control is a module designed to help organizations manage and automate internal controls, risk assessments, and compliance processes. Its core functionality is to ensure that business operations align with regulatory and organizational standards, making it easier to detect, correct, and prevent process control deficiencies across complex business environments. 

SAP Risk Management – helps businesses identify, assess, and mitigate various operational, financial, and compliance risks. It provides tools for real-time monitoring, analysis, and reporting of risks across different business units, supporting a unified view of risk management alongside other GRC modules like Process Control, Access Control, and Audit Management. This integration allows businesses to align their risk mitigation strategies with broader compliance and business objectives. 

Think about the capabilities of GRC Access Control – Emergency Access Management (GRC AC EAM).  Are you familiar with the process for enabling “Firefighter Access” in your S/4HANA production system?  Here we have a unique choreography between 2 SAP systems.  The S/4HANA system and GRC interact in a way where one system totally trusts the other system to “come to its rescue”.  One system sends in a firefighter. . .or multiple firefighters.  These are individuals who are given temporary access to perform a specific emergency function or business process.  They perform these functions while being granted “elevated permissions” via specially designated “firefighter” user IDs. 

Can this arrangement be abused?  It most certainly can!  Companies can become relaxed and begin to perform “normal” business processes through a firefighter arrangement because they do not take the time to properly configure the needed Role/Authorization/User architecture that SHOULD be in place to support the business processes. 

A properly designed EAM/FireFighter process is critical to enabling proper governance and implementing and enforcing guardrails around the need for elevated access. Fundamental tenets of a well governed process for elevated access include a presumption of limited use. Elevated access should only be granted under specific criteria and in limited circumstances, moreover the elevated access roles/ID’s should be designed with least privilege access in mind and be purpose built for the intended use. Many organizations tend to take the easy route and build or assign roles with widespread access to a FireFighter ID. This adds additional risk as users may have access to extremely powerful transactions or access that they may not understand. A user may execute far more transactions than intended during the session resulting in much larger logs which makes it harder for reviewers to appropriately monitor the activities performed during a FireFighter session. In other words, a support user for a procurement process should not need access to maintain security roles.  

To distinguish between the legacy SAP GRC product and the GRC branded family of products.  We can illustrate this best with 2 screenshots from SAP sources.  One screenshot will show the “core components” of the legacy/current product: SAP GRC 12.