SAP Cybersecurity: External Threats

Why SAP cybersecurity is a board level concern

SAP systems carry the financial books of record, the master data of the supplier and customer base, the production planning that runs the factory, and the HR records of the workforce. A successful external attack on SAP can move money, change vendor bank accounts, exfiltrate master data, or stop production. The board level concern is the combination of business critical data and growing external attack interest in ERP. The customer must address SAP cybersecurity as a discipline alongside the enterprise security operations center and not as a basis administration task on the side.

This article documents the attack surface taxonomy, the monitoring approach, the incident response framework, and the audit defensible cybersecurity posture. Reference the SAP security audit pillar, the basis security analysis, and the security hardening expertise.

Attack surface taxonomy

The SAP attack surface has four categories. The first is the network exposure of the message server, the application servers, the gateway, and the HANA database. The second is the authorization layer that an external attacker would seek to escalate after compromising a low privilege account. The third is the custom ABAP code that may contain unsafe dynamic SQL, command injection, or missing authorization checks. The fourth is the integration layer including RFC destinations, BTP services, and SOAP web services that an external attacker can probe from outside the perimeter. The customer position is to maintain a documented attack surface inventory for each of the four categories and to subject each category to quarterly review.

Reference the RFC security analysis, the ABAP security analysis, and the Fiori security analysis.

Monitoring approach

The monitoring approach connects the SAP audit log into the enterprise security information and event management platform. The audit log captures failed logon, successful logon by privileged user, authorization failure, RFC call to a critical destination, transport release, and table change for audit relevant tables. The customer position is to forward the SAP audit log in real time to the SIEM and to write detection rules that flag the high risk events. The first three detection rules cover failed logon from a non corporate IP, successful logon by SAP_ALL user from an off hours window, and a transport release outside the maintenance window. The discipline lifts SAP into the same security operations center workflow as the rest of the enterprise.

Reference the audit trail configuration, the table logging configuration, and the security notes and patches analysis.

Forwarding the SAP audit log to the enterprise SIEM in real time is the single most leveraged cybersecurity control. The discipline brings SAP into the same security operations workflow as the rest of the enterprise.

Incident response framework

The incident response framework has four phases. Detection through the SIEM rules. Triage by a named SAP responder who can interpret the SAP context of the alert. Containment by isolating the affected application server, disabling the compromised user, or rolling back the unauthorized transport. Recovery by validating that the audit log is intact, that the financial records are unchanged, and that the user authorization assignment matches the documented design. The customer position is to keep the SAP responder on the enterprise incident response rotation and to maintain a documented runbook for each of the high probability incident types. Reference the privileged access analysis, the firefighter id analysis, and the license audit pillar (cross cluster reference for the named user implication of an incident user lockout).

Audit defensible cybersecurity posture

The audit defensible cybersecurity posture has five components. First, the attack surface inventory updated quarterly. Second, the security notes patching cadence at no more than 30 days behind the SAP release. Third, the audit log forwarding into the SIEM with documented detection rules. Fourth, the incident response framework with named SAP responder on the rotation. Fifth, the annual tabletop exercise that walks the team through a simulated SAP incident. The five components together survive external auditor walkthrough and support the SoX testing program.

The implementation detail is in our GRC implementation analysis, the compliance framework pillar, the SoX ITGC analysis, and the security notes and patches analysis. The security hardening expertise documents the full senior advisor methodology.