A wave is sweeping through IT organizations right now. Entrenched processes are being examined for effectiveness and efficiency and scrutinized from the economical perspective. It is common for cyber-attacks on the corporate infrastructure and, if worse, the enterprise applications to trigger this. Successful exploits prove the inefficiency of established security measures in the event of an attack. Upon closer inspection, it becomes apparent that the established processes and measures do not create resilience. So, what do you need to achieve SAP cyber resilience?
In particular, the threat landscape is constantly changing. Attackers develop new methods of exploitation or discover previously unknown vulnerabilities. You must acknowledge that the SAP system settings are constantly changing – even when these changes are part of the change management process. To establish SAP Cyber Resilience, you must develop procedures that capture any change, analyze the security impact, and enable prompt upgrades. You must ensure a reaction to changes in the threat situation and the security posture.
When it comes to SAP, an occasional check, as part of an IT security audit, is taken as an opportunity to adjust the hardening of the SAP systems and to question the basic security architecture. A one-time assessment of SAP security affairs cannot be reliable for resolving the identified problems. During the next test, at the latest, you will notice that new vulnerabilities or problems that were solved reappear.
You must establish active management of security postures for SAP applications to achieve resilience against cyber-attacks. For that purpose, you must frequently validate your IT landscape, SAP systems’ configuration, and evaluate the user management and authorization assignments. Detecting deviations from the designated security baseline can lead to a timely reaction. With constant compliance to security requirements, the first step toward SAP Cyber resilience is done. The SecurityBridge Security & Compliance Management helps you define a security policy for all relevant SAP system parameters, critical authorizations, and access control lists (ACL) and constantly verify that the present configuration complies with your standard. However, an essential building block is still missing.
If you intend to implement an effective security monitoring program to detect cyber-attacks, you will need to track all transactions performed in the SAP application. To illustrate the challenge: Depending on the number of users, processes, and interfaces, SAP systems process between 1,000 and several million transactions per minute. It is helpful to work with detection patterns to capture the relevant transactions. SecurityBridge Threat Detection refines this with intelligent anomaly detection.
A real-life example illustrates why periodic checks and real-time monitoring are so important. Because we do not want to publish instructions here, we only described the process briefly. The attacker uses a vulnerability residing unpatched within the SAP transport management system (STMS) to elevate an account to which the threat actor has access to God-Mode (e.g., SAP_ALL). Later, once the malicious transport gets imported and the credentials are active, the attacker gains access and opens the system changeability. In parallel, the attacker also disables the security audit logging. Now the attacker creates persistence by changing some system parameters that can be set dynamically. This is done without leaving relevant log entries.
Had the attacked systems been immune to SAP cyber-attacks, the attack would not have been possible. Because then, the vulnerability in SAP STMS, which was fixed in October 2021, would have been patched already. Read also: SecurityBridge identified software supply chain vulnerability in SAP Transport System. Even if the attacker could have exploited the vulnerability, the unauthorized allocation of administration rights would trigger detection as an anomaly in real-time monitoring and, if activated, would have been removed via automatic rule. This would have stopped the attack or, at least, allowed for a short response. However, if the attacker managed to modify the system and disable relevant logs, things could get tricky. The hacker could have installed a backdoor, allowing them to return later. This is when the periodic vulnerability analysis comes into the picture. Because, even if the hacker had achieved persistence, the likelihood of detecting and eliminating the vulnerable configuration or code adjustment increases with testing the security settings and the custom code base.
Posted by
Find recent Security Advisories for SAP©
Looking into securing your SAP landscape? This white-paper tells you the “Top Mistakes to Avoid in SAP Security“. Download it now.
