This article discusses common challenges in SAP authorizations and the implementation of solutions through SAP GRC. It explores issues such as excessive access and misuse of Firefighter IDs, emphasizing the importance of controlled and auditable access to sensitive SAP systems.
1. Emergency Access Management with SAP GRC
Excessive access granted to users within an SAP system might compromise security and violate regulations. This could be from unauthorized use, inadvertent misuse of sensitive T codes, or mysterious process conflicts. When this happens, a security consultant with emergency access to the production system can investigate the breakdown.
Process management is becoming increasingly challenging for SAP teams, even with Firefighter’s capabilities (managing privileged access, expedited emergency access management, enhanced audit compliance, etc.). Organizations experiencing a significant increase in their FF log volume due to the increased use of the FF capability are seeing an accumulation of unchecked entries spanning weeks or even months.
FF access is granted by a standard procedure known as SAP Emergency Access Management (SAP EAM). Automated tools for managing an internal security model (Specified Business Ruleset), keeping an eye out for threats, and resolving compliance concerns are SAP GRC access control and process control.
However, providing sensitive and important authorization/access to the production system compromises the security and compliance of the system.
2. Challenges
SAP users in business and IT departments have unrestricted access to sensitive SAP tables and transactions. However, this access was not necessary to support the users’ day-to-day tasks. These users were given sensitive access so they could assist the company in an emergency or incident, but this led to the uncontrolled use of sensitive SAP access.
Overuse of Firefighter for non-critical transactions: Using Firefighter for low-risk transactions excessively during emergency access sessions is one of the key reasons why FF logs are growing. The FF Controller, who reviews every used transaction, will have less work to do if these low-risk transactions are excluded from FFIDs.
Research reveals that there is more to this misuse of FFID. Security teams are likely to create a zero-risk environment by developing business roles in accordance with their business processes and sub-processes (day-to-day operations for the organization such as processing payrolls, inventory management, finance, etc.). To do simple operations, more FF identities are needed because any transaction that poses a risk is eliminated and assigned to an FF role.
The SAP team must set up practical risk management to address this. While it is impossible to eliminate risk, there are controls that can help. For example, segregation of duties, process controls, and access controls within ARA (Access Risk Analysis) can help ensure that only sensitive and critical transactions are included in the emergency access process while still enabling users to accomplish their daily tasks. These new goals might be reflected in the redesign of roles.
3. SAP GRC EAM
Having an overview of SAP EAM’s operation is crucial to understanding any potential hazards in the context of GRC. The primary functions of SAP Emergency Access Management (EAM) are SAP process and access controls, which let end users use Firefighter ID to handle emergencies. SAP EAM is made to offer emergency access via a regulated and auditable procedure. For example, SAP EAM records everything the user does while using the temporary FFID. Many risk functions and procedures will be developed for the tracking process after roles are assigned to IDs.
Key Functionality:
- Giving approved users advance notice about emergency access
- Tracking all emergency users’ activities
- Allowing SAP emergency access with a compliance focus
Key Benefits:
- Prevent company disruptions by responding to emergencies quickly
- Reduce audit time
- Shorten performance time
- Workflow-based log review
- Adherent emergency access management procedure
The EAM Module supports the following approaches:
| Firefighting Type | Description |
|---|---|
| Centralized | Where users access EAM through SAP Access Control |
| Decentralized | In case if GRC system is not available allows to use EAM Launchpad directly through backend systems |
4. SAP GRC FFID Types
4.1 ID-Based Firefighter: Each Firefighter ID in ID-Based Firefighter has a unique user master record, and roles are allocated to the Firefighter ID directly. The end user (Firefighter) verifies an ID and executes a transaction code. A Firefighter ID can only be checked out by one person at a time. Access for firefighters can only be granted after a reason code and the anticipated activity has been recorded. The change history under the Firefighter ID contains pertinent SAP updates.
4.2 Role-Based Firefighter: Each role, which is defined as a Firefighter Role, can be assigned directly to users. This can be done through Access Request Management (ARM). A user does not need to check out a separate ID to use Firefighter. Transactions and change history are logged with the user’s own ID which is an advantage in relation to an ID-based Firefighter. Since the end user uses their own ID instead of having to check out an ID, they are unaware when they are using emergency or firefighter access. Emphasizing that everything is recorded using the Firefighter ID is crucial.
5. SAP GRC Firefighter Workflow
To assign Firefighter credentials to end users, an EAM (Emergency Access Management) workflow must be established. Within the company, there needs to be an EAM owner. EAM requests are handled by this individual, who ought to be a reliable person. The EAM owner is usually the first of two people to authorize an EAM request in a workflow. The workflow stops if they reject the EAM request. If the request is approved by the EAM owner, it should proceed to a security approver who has the authority to accept or deny it.
As may be seen in the table below, the Firefighter is not an isolated idea. You would think that someone would review your logs if you were writing them. You should not provide each employee in your business access to a Firefighter ID. But since battling fires requires higher authorizations, you make sure that only qualified people with the right business rationale are granted access.
The business process owner oversees the impacted business domains and is the rightful owner of the roles or Firefighter IDs. For instance, a Firefighter has a temporary window of time to seek a Firefighter ID (using ARM). The Firefighter must submit a request for access along with appropriate business reasons and the T-codes they plan to use. The request is submitted to the Firefighter owner in accordance with procedure, who reviews and approves it. The Firefighter owner then receives a notice, allowing them to begin utilizing the Firefighter. From the minute the Firefighter logs on with FFID, all their actions are recorded. The workflow item and notification, along with a log file containing all completed change operations for approval, are sent to the Firefighter controller.
6. SAP GRC – Firefighter Log file Reports
With an existing rule set inside SAP Access Controls, SAP EAM would create the SAP GRC Firefighter Controller log files (Rule set). The log file contains information on EAM requests, approvals, and usage. It consists of separate logs for transaction log (STAD), change log, audit log (SM20), system log (SM21), debug & replace activities, OS commands, and a security audit log.
A lead auditor is in charge of reviewing the process (request, justification, and approval) and usage records as part of regular internal and external audits to make sure that usage and reasoning are consistent.
7. Insufficient documentation & evidence
In any aspect, failure to document evidence and FF process-related information creates unforeseen workloads, resulting in controllers not being provided with enough context to approve FF usage logs. This results in more work being created as the end-user is contacted to investigate FF issues and determine why specific transactions were necessary.
As a result, when organizations submit FF access requests, they must adhere to strict procedures. Applications must be challenged, and the requestor must provide a clear justification for why privileged access is required. FF owners oversee accepting or rejecting these FFID requests via EAM. Together, the controller and owner should be closely monitoring activity.
In addition, certain minor adjustments—like adding multiple cause codes—would help controllers by making activity logs more classified. More context is provided by reason codes that are more specific, which leads to a thorough comprehension of the controller’s requirements without the need for additional research.
8. Challenges with SAP’s built-in EAM Functions
There are many challenges to using native SAP EAM, including:
- The manual workflow, which may be inefficient, is used to allocate firefighters.
- Log analysis takes a lot of time to find security flaws.
- Security concerns may evade active monitoring of usage records.
- The procedure could unintentionally result in violations of the Segregation of Duties (SOD) rules needed to abide by laws like Sarbanes-Oxley (SOX).
Organizations typically adhere to SOX and SOD regulations by restricting sensitive or vital access or authorizations in production systems, which can be against emergency access regulations. The person with the Firefighter position must contact security while using the manual SAP EAM process to have their role eliminated after fulfilling the prerequisites. This puts a strain on security staff and increases the possibility that it will not happen at all, leaving temporary access open-ended and vulnerable to abuse.
9. SAP GRC EAM – Value of Automation
SAP GRC EAM automation offers the following values to an organization’s system:
Automation can be beneficial for many high-volume IT security operations, including emergency access procedures. However, this is only true, as this activity should only be carried out for low-risk transactions. Automation will lessen the quantity of low-risk logs that an FF controller needs to review, but it does not intend to eliminate the need for a qualified person to review logs. Security teams can identify which low-risk transactions are frequently carried out during sessions by using past data.
FF log data can be summarized in a user-friendly manner using business analytics reporting tools that present data in clear infographics; this summary is then authorized by the controller.
- Balances security and compliance regulations with the necessity for emergency access.
- The automation process eliminates manual efforts in security workflows for issuing emergency access and credentials.
- Releases security personnel from a time-consuming obligation.
- Permits access that adheres to SoD regulations.
- Produces audit logs after an emergency session readily available for audit trials and comprehensive documentation.
To make sure that this tooling functions as intended and that high-risk transactions are excluded from the automation process, any automation must be paired with frequent spot checks. Regarding acceptable usage and access risks, the FF controller will still be in charge.
In conclusion, Firefighters are vital tools, but they also carry a risk of being overused for a variety of reasons, which can result in heavy workloads and internal pressures.
