Aug 19
GRC

This document describes the provisioning strategies of Emergency Access Management. Basically SAP GRC Access Control offers two different strategies how EAM can be utilized.

Pre-Approval

Some users are pre-approved for specific Firefighter IDs and have pre-assigned access in GRC. When a Firefighter ID is checked out, the application sends notification to the controller whenever the firefighter logs onto a system (Parameter 4008). Additionally the controller gets informed when the log report is available (Parameter 4007) and it is his responsibility to confirm that the actions taken were appropriate. The application sends the notification either as email or workflow item to the controller (Notification settings in the Firefighter ID Assignment).

Approval Required

On the contrary, a user must request access to EAM before the Firefighter ID can be used. Access can be requested in Access Request Management. Super User Access Request Type is available to automate provisioning access to Firefighter IDs via workflow in ARM.

Both strategies have as well advantages as also disadvantages. Having pre-approved firefighters have the advantage that the IDs are available at any time and emergency activities can be provided immediately (e.g. during weekends), whereas it might be critical that fraudulent activities can be executed and are reviewed afterwards. If a user must request access to EAM, emergency access is delayed due to the fact that the approval from the controller is required before usage. In case of an emergency e.g. during weekends the controller might not be available and the work can't be done.

I would like to know which strategy you prefer and do you have other concerns than mine?

Looking forward to your feedback and contribution.

Refer also to SAP SCN GRC Community: http://scn.sap.com/docs/DOC-57322

Posted by Alessandro Banzer

Twitter Facebook
Mar 3
GRC

A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

In this post I would like to clarify the lifecycle of Firefighter IDs. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

On request I have additionally added the RACI matrix to see who is Responsible, Accountable, Consulted and Informed for each step. Please be aware that this is very much depending on the point of view and can be different in your organization. My considerations are commonsense and pretty much of thinking in smooth processes throughout a global enterprise.

Creation of Firefighter ID

Tasks

  • Define the necessary access rights of the FFID
  • Define the responsibilities (Ownership, Controller)
  • Create Firefighter ID

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

Changing of Firefighter ID

Tasks

  • Define the necessary changes in access rights
  • Define changes in resonsibilities (Ownership, Controller)
  • Define changes of Firefighter ID (e.g. validity)

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner


Deletion of Firefighter ID

Tasks

  • Delete the Firefighter ID
  • Document the decision of the deletion
  • Archive belonging firefighter logfiles

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible


Reviewing of Firefighter ID 

Tasks

  • Review validity
  • Review rirefighter ownership and controller
  • Check proper access rights

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

Please also see my blog post on SAP SCN: http://scn.sap.com/community/grc/blog/2014/03/03/firefighter-id-lifecycle

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

Posted by Alessandro Banzer

Twitter Facebook
Jan 28
GRC

ID-Based Firefighting

With ID-Based Firefighter each Firefighter ID has its own user master record with roles assigned directly to the Firefighter ID. The End-user (Firefighter) executes a transaction code and checks out an ID. It is possible for multiple users to check-out each Firefighter ID (which is authorized to the end-user) but only one user can have a Firefighter ID checked out at any time. A reason code and the expected activity must be documented prior to gaining Firefighter access. Relevant changes in SAP are captured in the change history under the Firefighter ID. It is important to highlight that everything is documented with the Firefighter ID and not the user’s normal user ID. 

Role-Based Firefighting

Each role which is defined as Firefighter Role can be assigned directly to a user. This can be done through Access Request Management (ARM) if in place or directly in SU01. To use the Firefighter a user doesn’t have to check out a separate ID. Transactions and change histories are logged with the user’s own ID, which is an advantage in relation with the ID-based Firefighter. The end-user is not aware when he is utilizing emergency / firefighter access as he does not have to check out an ID and uses his own ID all the time.

Concept of ID-Based Firefighter


Concept of Role-Based Firefighter


Steps to set up ID-Based Firefighting

  1. Create Firefighter ID
    • Create a user account in transaction SU01 with user type “System” to be used as a firefighter. This can also be done in Access Request Management if in place.
    • Assign the Firefighter ID role which is defined in configuration parameter 4010 (Firefighter ID role name) to recognize the system user as a Firefighter ID.
    • Assign necessary roles for firefighter access.
  2. Define Firefighter Owner
    • Assign an Owner to the Firefighter ID
  3. Assign Firefighter Controller
    • Assign a Controller to the Firefighter ID. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter ID Controllers can also be Firefighter ID Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter ID.
    • The user can access the Firefighter IDs (can be more than one) within the validity dates.

Steps to set up Role-Based Firefighting

  1. Define Firefighter Role
    • Enable a specific role for Firefighting directly in the Business Role Management.
  2. Define Firefighter Role Owner
    • Assign an Owner to the Firefighter Role.
  3. Create Firefighter Role Controller
    • Assign a Controller to the Firefighter Role. Controllers are responsible for reviewing the log report and can receive email notifications or workflows of Firefighter ID use.
    • Firefighter Role Controllers can also be Firefighter Role Owners.
  4. Assign Firefighter
    • Assign a user (must have an existing user ID) to the Firefighter Role.
    • The user can access the Firefighter Roles (can be more than one) within the validity dates.
If you need more information about the possibilities of firefighting with SAP GRC do not hesitate to contact me directly by leaving a comment or sending an email. 

Posted by Alessandro Banzer

Twitter Facebook
Jan 24
GRC

In this article, I will provide an overview of the Emergency Access Management reports and which information can be seen. GRC provides six reports specifically for EAM, e.g. the consolidate log report shows firefighting activities which have been executed while using firefighter. The consolidate log report is far the best and used for management review from the firefighter controller (if workflow is in place).  The consolidated log report has all the captured information from the backend system in a consolidated view. Following a short overview of the captured information and where it comes from.

Transaction Log
Captures transaction executions from transaction STAD. System, Firefighter, Firefighter ID, Reason Code, Transaction, Date and Owner are read.

System Log
Captures debug and replace information from transaction SM21.

Change Log
Captures change log from change document objects which are stored in table CDPOS and CDHDR.

Security Audit Log
Captures security audit log from transaction SM20.

OS Command Log
Captures changes to OS commands from transaction SM49.

For further investigation or to get more information about the activities performed in the backend system these transactions might be helpful. 

Other reports are:

Invalid Superuser Report - shows expired, locked and deleted firefighter IDs.

Firefighter Log Summary - shows firefighter ID session details (only available for ID-Based firefighter, see also Types of Firefighting).

Reason Code and Activity Report - shows reason and activity details.

SOD Conflict Report for Firefighter IDs - shows SoD conflicts (risk analysis) for firefighting sessions.

If you need more information about the EAM reports do not hesitate to contact me directly by leaving a comment or sending an email.

Posted by Alessandro Banzer

Twitter Facebook
Jan 24
GRC

The purpose of Emergency Access Management is to allow users to take responsibility for tasks outside their normal job function. This component allows temporary access for users when assigned with solving a problem, giving them provisionally broad, but regulated access which is monitored and recorded in the application.

SAP GRC 10.0 provides two different types of firefighting which can be used either centralized or decentralized. Following a short description of both types which can be configured in IMG using parameter 4000 (Application Type). Only one type can be configured at a given time.

ID-Based Firefighter 

The firefighter ID created in the remote system will be assigned to the user in the GRC system, either manually or via an access request. The firefighter accesses their assigned firefighter ID either in the GRC system (centralized firefighter) or in the remote system (decentralized firefighter) using the SAP GUI and transaction GRAC_SPM. The firefighter ID for all remote systems assigned to the firefighter will be accessed from this transaction.

Role-Based Firefighter

The firefighter roles created in the remote system will be assigned to the user in the GRC system. The firefighter directly logs into the remote system using their user ID and performs activities which are provided in the user's role and firefighter role assigned to the user.

If you need more information about the possibilities of firefighting with SAP GRC do not hesitate to contact me directly by leaving a comment or sending an email. 

Posted by Alessandro Banzer

Twitter Facebook
Jul 31
GRC

Emergency Access Management, better known as firefighting, is a tool which gives the user emergency access for a limited amount of time. One of the advantages of this tool is that the access can be tracked and monitored by a defined controlling level. Since GRC 5.3 our internal SAP CC is using firefighting for business transactions which are not assigned to the user directly. Firefighters can also be used in business, for example for deputizations or critical business transactions which are used rarely. Another example is transactions which are used for month or year-end closing.

The firefighting process itself is very simple and can be understood very easily. A Firefighter ID, which can be used by a user, does have independent authorizations and is mostly just authorized for a few transactions (e.g. only payment run).

Once a user has requested the Firefighter ID he has to select the reason of firefighting and enter the expected activities. After the emergency access has been done a regular log-out from the firefighter ID will trigger the approval workflow. As each firefighter ID does have a defined controlling level (a so called controller), this workflow is automatically sent and waiting for review and the approval by its defined controlling level. As long as no inappropriate actions were performed, the defined controlling level can approve the workflow and end the process. If there were inappropriate actions performed, the defined controlling level has to collect information to make sure why and what has been done and how this issue be fixed. It also needs to be properly documented for audit purposes.

Posted by Alessandro Banzer

Twitter Facebook