SAP SE reveals security shortcomings within cloud portfolio
Chapters
Share Article
The inevitable has just happened. SAP has disclosed that some of its’ cloud products did not meet the security standards that customers were expecting, or were even legally entitled to. In defense of the German software giant, it should be noted that no security breach actually happened, it did however, expose some of the security challenges that not only SAP, but every major application provider faces. SAP states that 9% of their customers were affected by the “glitch”, which is an indication that most SAP clients still run on-premise rather than in the cloud. The gravitas for both SAP and their customers in securing their cloud applications is hugely significant: SAP, has a codebase that is 5-6 times higher than that of a common operating system, so how is that going to be protected.
Of course, there is vulnerability management, but given the complexity of SAP systems and the dynamic nature of configurations, this can only be one building block in a robust SAP security strategy.
To put it into perspective:
CISOs sweat the importance of zero-trust policies, especially for hybrid SAP environments. Zero-trust represents the necessity of “never trust, always verify”. In theory, SAP systems include most of the prerequisites for implementing a zero-trust concept. To take just a few examples: Access to an application or to be more specific an ABAP program should be verified by an authorization check existing in the code. Or, to take a more holistic example which includes network security: The SAP system always logs which terminal, i.e. which IP-address, was used for the logon – this information also needs to be verified.
However, these examples showcase the difficulty in applying a zero-trust model to SAP. For an authorization check to work, it must be implemented or, to look at this from a different perspective – a scan of the code has to be performed that detected non-existing authorization checks. Failing that, information has to be passed to the Security Operations Center which indicates that this particular user doesn’t usually execute that particular report. For the IP-address to be verified, a SIEM system needs to have the information from the SAP system as to which IP-address was used at the login event.
Looking at these examples, it’s evident that the one thing that is an absolute necessity when applying a zero-trust model to SAP systems, regardless whether those are in the cloud or on premise, is this: Monitoring. This monitoring should, of course, be able to identify obvious security breaches but also incompliant behavior. However, it also needs to correlate “normal” user behavior with suspicious actions in an SAP system. As tomorrow is world password day, let’s take a related example: A good monitoring system needs to be able to distinguish between a user mistyping his/her password multiple times out of simple forgetfulness and a brute force attack. In addition, this monitoring system should be able to feed SAP events to a SIEM system for a holistic view of security which includes SAP applications.
So, in summary, for a solution capable of providing such a 360-degree view, you as an SAP customer should look beyond what SAP themselves are offering, to ensure that you get a neutral, independent perspective. After all, you wouldn’t allow a fox to guard the chickens, would you?
Source: