Essentially, SAP Security is a complex set of different areas with different responsibilities. There are several ways how to separate it into discrete parts to work with. SAP Security can be divided into application and business layers or platform and customization level. On the other hand, it can be grouped by approach such as detection and response or organizational and technical. SAP Security can constitute distinct areas in accordance with platform types (ABAP, JAVA, and so on).
In fact, SAP Security can be perfectly divided by responsibility into Segregation of Duties, Custom Code Security, and Application platform security. Each one is commonly a responsibility of different departments. However, I think a company should have one point of contact for all those areas and the aim of CISO is to be this person.
The first area is Segregation of Duties and access control. It consists in protection of the system against users who have meagre privileges or combination of these privileges. For instance, if some staff have access to essential functionality like browse any table, they will increase their privileges by merely watching a table with passwords. This space is that the most famous, however, it’s not as vital as others.
The second area is Code security. As you’ll remember, programs written in ABAP language (SAP’s proprietary language to develop extensions to SAP products) will have vulnerabilities and, additional significantly, they will be used as backdoors.
The third and main area is Application platform security. It covers all types of vulnerabilities, misconfigurations, encryption, logging, enabled unnecessary functionality, and alternative technical problems. Merely saying, here we deal with all problems which will result in unauthorized body access to SAP system and in most cases an attacker doesn’t need any SAP account to conduct an attack.
If we tend to compare these three areas, it’s clear that in terms of Cybersecurity the last one plays a significant role. Of course, it doesn’t mean that you simply shouldn’t listen to alternative areas in any respect. However, imagine the worst-case situation, you have got the weakest access management and SoD configuration ever, say, you have got SAP_ALL access for each user, this issue will solely be exploited by somebody who already has an access to the SAP system. However, if a flawless SoD management is in place, however a company’s portal is exposed to the internet and has an authentication bypass vulnerability, hackers will penetrate into the system and cause irreparable harm.
Segregation of Duties, or SoD
SoD, or Segregation of Duties, is a very important issue once dealing with completely different responsibilities and job profiles at intervals an enterprise. It implies that a set of roles and responsibilities ought to be appointed in such method that across an enterprise a person shouldn’t have end-to-end access rights over any business operate. Segregation of duties provides the reassurance that nobody encompasses a physical and system access to manage all phases of business method or transaction: from authorization to custody and record keeping. A personal shouldn’t have responsibility for over one in all these 3 transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the connected quality (custody). For instance, persons who will authorize purchase orders (Purchasing) shouldn’t be capable of process payments (Accounts Payable).
There are many SoD examples in several SAP merchandise and trade solutions. to investigate SAP system in keeping with those rules, some solutions were introduced together with SAP GRC which will facilitate to unravel SoD conflicts. Usually, Risk Management team or SAP Security team (if it exists within the company) are charged with SoD. Though, this resolution isn’t for CISOs because it needs an in-depth understanding of SAP authorization idea and elaborate integration with SAP Systems. However, taking into consideration that essential rights are often used for privilege step-up and cyber-attacks, CISOs ought to be ready to monitor SoD security additionally.
SAP Custom Code Security
Code security is a quite new area of SAP Cybersecurity comparing to SoD. The first information about ABAP Security was published in 2002. It was an article about SAP Virus. However, it is not the only problem of customization which SAP is giving for every customer in order to be able to customize their SAP Systems. In the beginning, it was possible to customize SAP only using ABAP. Later, SAP added new platforms; each of them can be customized. Currently, SAP provides a lot of languages and frameworks to extend functionality such as ABAP, JAVA, XSJX, and SAP UI5 (for HANA).
ABAP, as mentioned before, can have vulnerabilities left by developers unintentionally. But it can also be used to write backdoors which can provide malicious functionality such as sending details of every transaction to a 3rd party via email or even publishing it on Twitter. Unfortunately, development inside the company is almost uncontrolled. I mean, nobody knows what developers do in the system, so they can write insecure code, forget to add checks for access control in the programs, send money to their bank accounts and nobody will notice it unless looks at their source code. So, the developer is a kind of God but can act like a devil with this power.
Let me offer you one example of those problems. If a user desires to execute a selected transaction, he writes a transaction name in a very menu and therefore the system checks whether or not he or she has access to the current dealing in his profile. However if a user incorporate a dealing in an extension, the system doesn’t check whether or not the user who ran this program has the right to execute the transaction. So as to shield the system from illegitimate transactions by running such programs, programmers ought to implement special checks in code before every imply dealing or different dangerous action. Thus, nice responsibility lies with the developers. Of course, it’s not forever straightforward to stay a watch on the very fact that everyone the required checks are in place, especially once the quantity of programs is estimated at thousands, and the variety of systems and developers amounts to dozens or lots of.
SAP Application Platform security, or SAP Cyber Security
Finally, we can discuss the newest and most important area of SAP Security – Security of Application platform. As you probably remember, the first steps in this area were taken somewhere in 2006-2007. This area came from the underground in the 2010-2011, and the market began to actively form in late 2013.
What is SAP Cybersecurity, or SAP Application platform security? Well, in theory, it’s everything associated with secure configuration of SAP Applications and related systems. Simply saying, it’s about the security of SAP’s platform without taking into account any customization such as new access rights or new custom programs. However, sometimes access control checks for default BASIS functionality are also included into Application Platform security area as these misconfigurations may be used to perform cyber-attacks. Here is the list of the most critical areas that should be covered during any SAP Security Audit:
- Infrastructure security (Network, OS, Database)
- SAP Vulnerability check (blackbox, whitebox, greybox)
- Configuration analysis (authorization, encryption, logging)
- Access control checks (By Module, by Application, by Industry)
- Password complexity checks (for different types of stored passwords)
- Connections security (RFC, Trusted connections, PI interfaces)
- Compliance (SAP, EAS-SEC, ISACA, DSAG, PCI, SOX…)
Any vulnerability in Application platform can give an attacker full access to SAP system and its data. To perform the attack, a cybercriminal doesn’t need to be a legitimate user! They don’t even need an access to a company’s network, sometimes SAP Systems are available for remote connection from the Internet!
Who should be responsible for this area is a tough question. SAP BASIS team’s work is implementing and setting a whole system, they sometimes set up security as well as the administrators of any other systems, be it Windows or CISCO. However, if there are no team to control this segment and people who understand the nuances of how to safely configure an SAP system, it’s hard to expect that the SAP Basis team can provide an adequate level of safety since they are not an expert in the field of Cybersecurity and are not responsible for any possible consequences. As a result, responsibility for this area as well as for two others should lie with CISO.