|back to blog series|
There are various problematic attack vectors for SAP backends, but one is more prominent than others: SAP Audit Log deactivation . Maybe because SAP forensics people are practically blind or because it demos well at security conferences
A recent conversation with a customer from the oil industry confirmed the need to release yet another playbook. This time specifically for the out-of-the-box analytic rule “Deactivation of Security Audit Log”.
Note the skipped approval step in Teams compared to part 1 of the blog series. The playbook was designed with the assumption in mind that such a critical event should be acted upon immediately without human intervention.
Fig.1 Overview of automatic SAP audit log re-activation workflow
See the Sentinel content hub to activate that audit log rule and learn about further scenarios.
Fig.2 Screenshot of Sentinel Content Hub listing available analytic rules for SAP
The playbook configuration is identical to part 2. It differs slightly in the SOAP API handling. The SAP function module RSAU_API_SET_PARAM requires a set of parameters in addition to the activation flag ID_ACTIV. See transaction SE37 or the SOAP WSDL for reference.
Fig.3 Screenshot of successful audit log reactivate run
Those additional parameters are dependent on the profile. Verify from transaction RSAU_CONFIG.
🛈Note: Consider enabling dynamic parameter auth/auth_user_trace in transaction RZ11 to allow audit log active state switching. Some might argue it is a security risk to even enable such an interface to deactivate the audit log. But hey, the playbook will just activate it again once the incident hits If you want to reduce the interface capability to “enable only”, you will need to provide a custom ABAP function module. The SAP standard doesn’t offer that option.
Curious about your thoughts on the enablement of this SOAP service @community. Let me know in the comments.
Fig.4 Screenshot of SAP audit log configuration and state
Given there is an existing setup of parameters that is desirable to be retained, the playbook first needs to read the setup and pass on alongside the re-activation property (see message body in fig.3) before making the final SOAP request.
The function module RSAU_API_GET_PARAM offers the capability to retrieve the existing configuration.
Fig.5 Screenshot of retrieved SAP Audit Log configuration
Ready to roll with an integration test
Uncheck the top checkbox as shown in fig.4. and wait for the incident to hit. At least if you dare
Fig.6 Screenshot from Teams message informing about re-activated audit log
If you are brave enough, you are greeted with above message telling you about the automatic re-activate action taken. Start your investigation from the “View Incident” button at the top.
Additional automation scenarios
Anyone curious about malicious Sentinel collector agent tempering detection and avoiding false positives? You don’t want to get mad during SAP maintenance windows, do you. That is next
Looking to you to request additional scenarios and share your own as Pull Requests on GitHub.
That’s a wrap today you saw another SAP security automation scenario in action. This time without human intervention. Since SAP security audit log deactivation is a critical event with high certainty of malicious intent it gets updated right away. Better be safe than sorry
To make that happen we configured the SOAP services for two more function modules. The remaining steps were identical to part 2 of the series. A side effect of this uniformity in approach, is sheer speed of adding additional scenarios to your security estate in no time.
This integration pattern overall is applicable to any SAP API. Got another SAP threat at your hands that needs automatic remediation? Let me know in the comments or reach out directly.