This document elaborates the usage of Emergency Access Management (EAM) and its dangers of inappropriate usage. To get more information about EAM in general please refer to the excellent collection document from leos: EAM - For the new kid on the block.
Before you start using EAM you have to think why you are using it and what you are going to analyze in log review. SAP's official GRC300 course (GRC300 - SAP Access Control 10.0 - Implementation | SAP Training and Certification Shop) says that EAM is used as a form of remediation/mitigation for SOD (Segregation of Duties). This document focuses more on firefighting in emergency situations rather than on mitigating critical access.
In the section "Inapproriate Usage" I have mentioned that daily business tasks should not be performed with a firefighter. In case you define EAM as mitigation/remediation of critical access, as mention in GRC300 course, then this isn't an inappropriate action as it covers an end user's business function for supporting user. Also you might have support users have daily activities that they use Firefighter for (from security point of view it's recommended as a way to capture service call numbers for audit trail).
Short Overview
EAM in general offers a number of advantages for the management of emergency access, including
- Mitigates the most common open audit issue faced by virtually every company (e.g. with profile SAP_ALL and SAP_NEW)
- Eliminates emergency phone calls to approve access outside the business hours
- Tracks and logs transaction code usage and changes made within the firefighting session
- Allows to provide defined authorizations and validity dates
- Sends email notification of emergency access logon immediately to defined controllers
- Generates auditable reporting logs
Appropriate Usage
Appropriate usage of emergency management includes:
- Emergency changes required in productive environment
- Sensitive transactions not available via end user security roles
- SOX sensitive and restricted transactions
- Infrequent and sensitive tasks (e.g. opening and closing of posting periods)
- Cutover activites
Inappropriate Usage
Inappropriate usage of emergency management includes:
- Daily business tasks by support users (e.g. creating purchase orders, etc.)
- Non-sensitive tasks available via security roles (e.g. display access)
- Displaying sensitive reports
- Using EAM as a crutch to support a bad security design
Dangers of Inappropriate Usage
Excessive usage represents one of the largest EAM issues.
- Frequently, EAM is used as a crutch for a poor security role concept. End users tend to rely on their Firefighter ID instead of using their regular access given to their personal user ID. Simple table display (e.g. SE16) or daily activities for supporting business tasks are both examples of inappropriate usage seen in several companies.
- The high volume of use generates longer logs, requiring more system resources, and more time to review.
- As a result logs are not reviewed in detail and EAM cannot be relied on as a security control.
It is important that the concept of firefighting is defined properly as excessive usage might cause real danger to your organization as fraudulent actions might remain undetected due to the high volume of logs. Inappropriate usage could be eliminated with a proper provisioning strategy (see also EAM - Provisioning Strategies), the proper type of firefighting (see also ID-Based Firefighting vs. Role-Based Firefighting), as well as a proper authorization concept defined by your basis/security team.
Furthermore it is required to correctly assess the role design of the FF roles as role design has an impact on the size of the logs. Firefighter Logs (see also Emergency Access Management Reporting) do not differentiate between display and change and hence EAM collects all information that is logged. This means the file can become overwhelming for the Controller to review.
Instead of using Firefighter, if you are on 7.40 release, you could configure RAL (Read Access Logging (RAL)) that allows you to monitor and log read access to sensitive data.
Hope this document helps for the general understanding of how EAM should and shouldn't be used. Your feedback is always highly appreciated to improve the quality.
Best regards,
alessandr0 & m.lee
