Building an SAP Incident Response Playbook

Why SAP Needs a Dedicated IR Playbook

Standard IT incident response playbooks assume common attack surfaces: endpoints, network devices, identity providers, and cloud workloads. SAP introduces several layers of complexity that generic IR processes fail to address:

• Proprietary protocol stacks: SAP uses DIAG protocol for GUI connections, RFC for system-to-system communication, and HTTP/HTTPS for Web GUI and BTP services. Attackers exploit these protocols differently than standard web traffic.
• ABAP runtime vulnerabilities: The ABAP application server is its own attack surface. Unsecured function modules, vulnerable BSP applications, and improperly coded authorization checks can allow attackers to execute arbitrary code or extract data without triggering typical SIEM alerts.
• Segregation of duties (SoD): SAP authorization models are complex. An insider threat or compromised credential may perform seemingly legitimate transactions that violate SoD, bypassing audit controls if not monitored in real time.
• Critical compliance exposure: A breach in SAP can violate SOX controls around financial reporting, PCI DSS requirements for cardholder data, and GDPR mandates for personal data. The incident response itself must preserve forensic evidence for regulators.

A dedicated playbook ensures your team does not waste time mapping generic IT procedures to SAP-specific artifacts. When an SAP security alert fires, you need a playbook that starts with the correct SAP transaction codes, log tables, and forensic data sources.

SAP-Specific Threat Vectors to Cover in Your Playbook

Your playbook must address the threats most relevant to SAP landscapes. Based on industry threat models and the CyberSilo SAP Guardian detection framework, these are the critical scenarios to include:

Each of these vectors requires distinct containment steps, forensic data sources, and recovery processes. Do not treat them as a single "SAP incident" category in your playbook.

Phase 1: Preparation — Instrument Your SAP Landscape Before a Breach

The preparation phase determines whether your playbook succeeds or fails. Without proper instrumentation, your SOC team is blind to SAP activity. Preparation includes three critical workstreams:

Enable and Harden SAP Audit Logging

The SAP security audit log (SM19, SM20) must be active on all production systems. Configure audit classes for critical events: RFC calls, authorization failures, transaction starts (especially for sensitive T-codes like SE01, SE38, SU01, and SM30). Set the audit log to alert on overflow conditions — attackers may attempt to flood the log to hide activity. Store logs off-system via SM20 archive or SIEM integration to prevent tampering.

Configure Real-Time Monitoring for SAP Events

Your SIEM or dedicated SAP security monitoring solution must ingest key SAP data sources: security audit log (SM19), change document log (SCU3, CDHDR), ABAP runtime data (STAD, SE30), and system log (SM21). This is where CyberSilo SAP Guardian provides built-in connectors for these data sources, reducing the engineering effort. Map each detection rule to a specific playbook step so that when an alert fires, the responder knows exactly which transaction to check and which log to query.

Build an SAP IR Toolkit

Pre-authorize a set of emergency user IDs with restricted but powerful diagnostic access. These IDs should have roles like SAP_ALL with specific IR only parameters (S_DEVELOP: 02 activity for emergency debugging). Store the authorization documents in your incident management system. Include scripts or ABAP reports for common investigation tasks: listing active users per client, checking locked users, exporting current authorizations, and locating recently changed roles.

Phase 2: Identification — Recognize SAP Incidents Quickly

Identification in SAP environments relies on knowing what "normal" looks like. False positives are high in SAP because of batch jobs, scheduled background processes, and legitimate admin activity. Your identification workflows should distinguish between these and genuine threats.

Trigger Events and Initial Triage

Define specific alert conditions for each threat vector. For example:

• SAP_USER_ADMIN_CHANGE: A change to SU01 during non-business hours by a user ID that typically does not perform admin activity.
• SAP_RFC_LOGON_ANOMALY: An RFC logon from an unexpected source system or IP range outside the trusted RFC network.
• SAP_CODE_UPLOAD: Any SE24 class upload or SE38 program creation by an account that does not belong to the development team.
• SAP_CRITICAL_TC: Execution of SE01, SU01, or SM30 by a user whose normal role profile excludes these transactions.

Upon alert, the initial triage step is to verify the legitimacy of the event. Check the SAP system log (SM21) for related error messages. Run SM20 to review the security audit log for the specific user ID and timeframe. If the event appears anomalous, escalate to the full playbook.

Forensic Investigation Workflow

Once an incident is confirmed, move to the investigation phase. Document every step with timestamps. Use these ABAP transactions and tables as your primary forensic sources:

Phase 3: Containment — Stop the Bleeding in SAP

Containment in SAP requires careful balance. You cannot simply pull the power cord on a production ERP system. Instead, use targeted containment actions that isolate the threat without disrupting business operations.

User-Level Containment

For incidents involving compromised credentials or insider threats, immediately lock the user account via SU01 (set "locked" flag). Do not delete the user — forensic evidence may still be needed. Revoke all critical authorization profiles by marking them as expired. Block the user at the SAProuter or firewall level by adding their source IP to a block list. If the incident involves an RFC user, remove or disable the RFC destination in SM59 and clear the logon data.

System-Level Containment

For code injection or transport-based attacks, the containment approach changes. Disable the relevant RFC destinations (SM59) if the attack uses external RFC calls. For ABAP code threats, use SM01 to deactivate the suspicious function module or program. If a BSP application is compromised, use SICF to deactivate the service. In extreme cases, put the system in "restricted mode" via login/system_client and limit access to only the emergency IR team.

Data Preservation Actions

Before any containment actions that modify system state, take preservation steps. Export the relevant audit log entries from SM20 to a secure archive. Take a direct screen capture or export of the ABAP code, role assignment, or transport object. For RFC-based incidents, document the source system ID, destination target, and the specific function module calls. Store all evidence in a chain-of-custody-accessible location, ideally integrated with your broader SIEM tool evidence repository.

Phase 4: Eradication — Remove the Threat From SAP

Eradication in SAP means cleaning up the artifact left by the attacker. This is significantly more complex than deleting a file from a Windows server because SAP objects have interdependencies.

Code and Role Remediation

For ABAP code injection threats, reverse the upload by restoring the previous version from the transport system or from a known-good backup. Use SE95 to delete the compromised program or class. For custom code that was suspiciously modified, run ABAP Test Cockpit (ATC) checks to ensure no backdoor function remains. For authorization issues, use PFCG to remove the compromised role assignments and run the role comparison report to propagate changes. Use SUPC to check for conflicting profiles across the user base.

User Credential Remediation

For credential-related incidents, force a password reset for the affected user. For all "dialog" users (type A) that were impacted, ensure they log in again with new credentials. For service users and RFC users (type B and type C), generate new logon tickets or configure new SNC certificates. If the incident involved SAP BTP or cloud platforms, rotate the service keys and OAuth client secrets in the SAP BTP cockpit.

Deeper System Review

After containing and eradicating the obvious threat, conduct a deeper scan of the system for persistent access. Run SAP Security Optimization Service (SOS) or a dedicated SAP vulnerability scanner. Check for unexpected SAP security baseline deviations. Review all system profiles (RZ10) for unauthorized parameter changes. Look at table T000 for changes to client settings (client role, changes allowed flag). Scan for any open SQL injections in custom ABAP code using the Code Vulnerability Analyzer (CVA).

Phase 5: Recovery — Return to Normal Operations

Recovery in SAP is not a single action — it is a phased return to operational status with heightened monitoring. Each system (DEV, QAS, PRD) may recover at a different pace.

System Reunlock Process

If you restricted system access during containment, begin lifting restrictions. First, lift the system-wide lock for the emergency teams and key business users. Then gradually restore access for the affected user base, verifying each user's authorization profile is clean. Reactivate any deactivated function modules or services (SM01, SICF). Re-enable any blocked RFC destinations after verifying the remote system's security posture.

Post-Incident Monitoring

After recovery, tighten monitoring for at least 30 days. Increase the audit log verbosity in SM19. Set up additional alert rules for the same attack vector targeting other systems in the landscape. Verify that your compliance automation tools reflect the post-incident state. Run a delta comparison of authorizations against the baseline to ensure no residual unauthorized access remains.

SAP IR Playbook Template and Workflow

To accelerate your development, here is a structured template for each playbook scenario. You can adapt this for each of the five high-priority threat vectors identified earlier.

Playbook Section: [Scenario Name]

Example: Privileged Role Escalation (SAP_ALL abuse)

Trigger: Alert from SAP Guardian — user ID "SUPPORT01" executed SU01 on two user IDs outside normal business hours, or a user was added to profile SAP_ALL.

Initial Triage (5 minutes):

• Check SM21 for system messages associated with the user during the timeframe.
• Run SM20 audit log for the specific user and transaction codes SU01, PFCG, SUIM.
• Query table AGR_USERS to confirm the profile assignment.
• Query USH02 for changes to authorization values.

Containment (10 minutes):

• Lock the user in SU01.
• Remove the suspicious profile via PFCG or direct table update (AGR_USERS).
• If RFC user, disable the RFC destination in SM59.

Forensic Investigation (45 minutes):

• Export full user activity log (SM04, AL08).
• Check table CDHDR for change documents on SU01 and PFCG.
• Review any transport requests created by the user (E070).
• Run RSUSR003 for authorization value changes.

Eradication (30 minutes):

• Revoke all critical authorizations.
• Reset user password and force new password at next logon.
• Run ATC checks on any custom code the user may have created.

Recovery (1 hour):

• Confirm user's legitimate role profile is restored (with business owner approval).
• Unlock user.
• Escalate monitoring for this user for 30 days.
• Document incident in GRC system for compliance audit.

Integrating the Playbook With Your SOC

An SAP IR playbook does not exist in isolation. It must integrate with your Security Operations Center (SOC) workflows, tooling, and escalation paths.

SOC Level 1 vs. Level 2 Handoff

Define which playbook steps a Level 1 analyst can perform and which require Level 2 SAP SMEs. Typically, Level 1 can handle: initial triage (check user ID, transaction code, time of alert), basic lockout of users, and escalation to Level 2. Level 2 (which should include a Basis admin or SAP security specialist) handles: forensic investigation, advanced containment (e.g., transport reversal, deactivation of function modules), eradication, and recovery validation.

Tool Integration Requirements

Your SIEM or SAP security monitoring solution must support these integration points for the playbook to function smoothly:

• Automated alert enrichment: When an SAP alert fires, automatically pull the user's last 24-hour activity, authorization profile, and recent logon IPs.
• Pre-built dashboards: A SAP incident investigation dashboard showing live user sessions, transaction execution, and RFC connections.
• Playbook automation: The ability to trigger containment actions (lock user, disable RFC, deactivate function module) directly from the incident ticket.
• Audit trail capture: All playbook actions must be logged with user ID, timestamp, and system action for compliance audit.

CyberSilo SAP Guardian is designed for this level of integration, providing API-driven automation for common containment actions and real-time enrichment of SAP alerts in your SIEM.

Testing and Updating the Playbook

A playbook is only as good as its last test. Run tabletop exercises at least quarterly. Use the Purple Team model: have a red team simulate an SAP attack (e.g., RFC privilege escalation, ABAP code upload) while the blue team runs the playbook. Measure time to detect, time to contain, and any gaps in the procedural steps. Update the playbook quarterly based on lessons learned and new threat intelligence.

Common Pitfalls to Avoid

Organizations that implement SAP IR playbooks often encounter these specific failure modes:

SAP BTP Incident Response Considerations

If your landscape includes SAP Business Technology Platform (BTP), extend your playbook to cover cloud-specific vectors. BTP incidents involve different data sources: subaccount audit logs, Cloud Foundry logs, Kyma runtime logs, and OAuth token exchange logs. Your playbook should include:

• Subaccount isolation: Move affected BTP subaccounts to a restricted space with blocked external routes.
• Service key revocation: Rotate all service keys for XSUAA and destination services in the affected subaccounts.
• Cloud connector review: Validate the Cloud Connector's access controls to on-premise SAP systems.
• BTP audit log retrieval: Pull logs from the BTP cockpit or the audit log service for forensic analysis.

BTP incidents often have a faster blast radius because cloud resources are API-controlled. Your playbook should automate containment using BTP CLI or REST APIs.