What is SAP Security?
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, we 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 insufficient privileges or combination of those privileges. For example, if some employees have access to critical functionality such as read any table, they can escalate their privileges by simply looking at a table with passwords. This area is the most known, however, it’s not as important as others.
The second area is Code security. As you may be aware, programs written in ABAP language (SAP’s proprietary language to develop extensions to SAP products) can have vulnerabilities and, more importantly, they can be used as backdoors.
The third and main area is Application platform security. It covers all kinds of vulnerabilities, misconfigurations, encryption, logging, enabled unnecessary functionality, and other technical issues. Simply saying, here we deal with all issues that can lead to unauthorized administrative access to SAP system and in most cases an attacker doesn’t need any SAP account to conduct an attack.
If we compare these 3 areas, it’s clear that in terms of Cybersecurity the last one plays a vital role. Of course, it doesn’t mean that you shouldn’t pay attention to other areas at all. However, imagine the worst-case scenario, you have the weakest access control and SoD configuration ever, say, you have SAP_ALL access for every user, this issue can only be exploited by someone who already has an access to the SAP system. However, if a flawless SoD control is in place, but a company’s portal is exposed to the Internet and has an authentication bypass vulnerability, hackers can penetrate into the system and cause irreparable damage.
Segregation of Duties, or SoD
SoD, or Segregation of Duties, is an important factor when dealing with different responsibilities and job profiles within an enterprise. It means that a set of roles and responsibilities should be assigned in such way that across an enterprise any individual should not have end-to-end access rights over any business function. Segregation of duties provides the assurance that no one has a physical and system access to control all phases of business process or transaction: from authorization to custody and record keeping. An individual should not have responsibility for more than one of these three transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the related asset (custody). For example, persons who can authorize purchase orders (Purchasing) should not be capable of processing payments (Accounts Payable).
There are hundreds of SoD examples in different SAP products and Industry solutions. To analyze SAP system according to those rules, some solutions were introduced including SAP GRC that can help to solve SoD conflicts. Usually, Risk Management team or SAP Security team (if it exists in the company) are charged with SoD. Though, this solution is not for CISOs as it requires an in-depth understanding of SAP authorization concept and detailed integration with SAP Systems. However, taking into account that critical rights can be used for privilege escalation and cyber-attacks, CISOs should be able to monitor SoD security as well.
SAP Custom Code Security
Code security is a quite new area of SAP Cybersecurity comparing to SoD. 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. 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 give you one example of these issues. If a user wants to execute a particular transaction, he writes a transaction name in a menu and the system checks whether he or she has access to this transaction in his profile. But if a user calls for a transaction in an extension, the system does not check whether the user who ran this program has the right to execute the transaction. In order to protect the system from illegitimate transactions by running such programs, programmers need to implement special checks in code before each call for transaction or other dangerous action. Thus, great responsibility lies with the developers. Of course, it is not always easy to keep an eye on the fact that all the necessary checks are in place, especially when the number of programs is estimated at thousands, and the number of systems and developers amounts to dozens or hundreds.
It’s clear that there should be some frameworks or tools to check if developers write their code properly. But how can one check it? What should they look for? When we deal with web application security the common way is to follow OWASP methodology and to be sure that top10 most critical issues do not affect your application at least. As for enterprise applications, it is not a trivial task to understand what issues we need to check. Fortunately, there is EAS-SEC – a nonprofit organization developed to increase awareness in enterprise application security. EAS-SEC consists of separate projects, one of which covers code security. It’s called Enterprise Application Systems Application development guide or simply EASAD – this guide describes 9 general categories of source code issues for business languages. Those categories are universal and the same for most of business, applications such as SAP, Oracle, Microsoft Dynamics, Infor and their custom languages.
Who is responsible for this area? Usually, Custom Code security is under the responsibility of SAP Developers, which means that they need to test their work themselves. This approach doesn’t actually work, as we all know. In my opinion, the responsibility of security of custom developments, be it either SAP’s ABAP or anything else, should be a CISO’s duty.
SAP Application Platform security, or SAP Cyber Security
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:
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 the CISO.
Conclusion
Well, so what is SAP Security finally? The cybersecurity of the entire SAP landscape depends on all three areas. However, the market is developing, so customers’ desires are changing. Here come new fields. First of all, it’s a correlation. Currently, clients don’t want to implement numerous solutions that provide multiple reports and require a lot of time to learn. But, most importantly, they want to see the whole picture, not just a list of users with critical rights and another list of vulnerable programs. As we learned from this article, CISOs should be responsible for all the listed areas and they want to see the whole picture and collect security-relevant data about different angles of SAP Security in one solution. The second important thing is not how the system itself is vulnerable but if it’s possible to hack other systems connected with this system, and, if so, how many systems it’s possible to hack, how easy it is and how critical those systems are.
And the last but not least, companies from different industries want to be able to analyze the security of their industry-specific applications, exact risks associated with their industry and follow guidelines applicable to their organization. All those needs are relatively new, but we already heard about those requirements from different analysts, CISOs, risk officers, SAP security engineers, and others involved in SAP Security.
I hope this post helped you to get to know what SAP Security is and how you can be involved in this growing world of opportunities.
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, we 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 insufficient privileges or combination of those privileges. For example, if some employees have access to critical functionality such as read any table, they can escalate their privileges by simply looking at a table with passwords. This area is the most known, however, it’s not as important as others.
The second area is Code security. As you may be aware, programs written in ABAP language (SAP’s proprietary language to develop extensions to SAP products) can have vulnerabilities and, more importantly, they can be used as backdoors.
The third and main area is Application platform security. It covers all kinds of vulnerabilities, misconfigurations, encryption, logging, enabled unnecessary functionality, and other technical issues. Simply saying, here we deal with all issues that can lead to unauthorized administrative access to SAP system and in most cases an attacker doesn’t need any SAP account to conduct an attack.
If we compare these 3 areas, it’s clear that in terms of Cybersecurity the last one plays a vital role. Of course, it doesn’t mean that you shouldn’t pay attention to other areas at all. However, imagine the worst-case scenario, you have the weakest access control and SoD configuration ever, say, you have SAP_ALL access for every user, this issue can only be exploited by someone who already has an access to the SAP system. However, if a flawless SoD control is in place, but a company’s portal is exposed to the Internet and has an authentication bypass vulnerability, hackers can penetrate into the system and cause irreparable damage.
Segregation of Duties, or SoD
SoD, or Segregation of Duties, is an important factor when dealing with different responsibilities and job profiles within an enterprise. It means that a set of roles and responsibilities should be assigned in such way that across an enterprise any individual should not have end-to-end access rights over any business function. Segregation of duties provides the assurance that no one has a physical and system access to control all phases of business process or transaction: from authorization to custody and record keeping. An individual should not have responsibility for more than one of these three transactions components: authorizing transactions (approval), recording transactions (accounting), and handling the related asset (custody). For example, persons who can authorize purchase orders (Purchasing) should not be capable of processing payments (Accounts Payable).
There are hundreds of SoD examples in different SAP products and Industry solutions. To analyze SAP system according to those rules, some solutions were introduced including SAP GRC that can help to solve SoD conflicts. Usually, Risk Management team or SAP Security team (if it exists in the company) are charged with SoD. Though, this solution is not for CISOs as it requires an in-depth understanding of SAP authorization concept and detailed integration with SAP Systems. However, taking into account that critical rights can be used for privilege escalation and cyber-attacks, CISOs should be able to monitor SoD security as well.
SAP Custom Code Security
Code security is a quite new area of SAP Cybersecurity comparing to SoD. 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. 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 give you one example of these issues. If a user wants to execute a particular transaction, he writes a transaction name in a menu and the system checks whether he or she has access to this transaction in his profile. But if a user calls for a transaction in an extension, the system does not check whether the user who ran this program has the right to execute the transaction. In order to protect the system from illegitimate transactions by running such programs, programmers need to implement special checks in code before each call for transaction or other dangerous action. Thus, great responsibility lies with the developers. Of course, it is not always easy to keep an eye on the fact that all the necessary checks are in place, especially when the number of programs is estimated at thousands, and the number of systems and developers amounts to dozens or hundreds.
It’s clear that there should be some frameworks or tools to check if developers write their code properly. But how can one check it? What should they look for? When we deal with web application security the common way is to follow OWASP methodology and to be sure that top10 most critical issues do not affect your application at least. As for enterprise applications, it is not a trivial task to understand what issues we need to check. Fortunately, there is EAS-SEC – a nonprofit organization developed to increase awareness in enterprise application security. EAS-SEC consists of separate projects, one of which covers code security. It’s called Enterprise Application Systems Application development guide or simply EASAD – this guide describes 9 general categories of source code issues for business languages. Those categories are universal and the same for most of business, applications such as SAP, Oracle, Microsoft Dynamics, Infor and their custom languages.
Who is responsible for this area? Usually, Custom Code security is under the responsibility of SAP Developers, which means that they need to test their work themselves. This approach doesn’t actually work, as we all know. In my opinion, the responsibility of security of custom developments, be it either SAP’s ABAP or anything else, should be a CISO’s duty.
SAP Application Platform security, or SAP Cyber Security
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 the CISO.
Conclusion
Well, so what is SAP Security finally? The cybersecurity of the entire SAP landscape depends on all three areas. However, the market is developing, so customers’ desires are changing. Here come new fields. First of all, it’s a correlation. Currently, clients don’t want to implement numerous solutions that provide multiple reports and require a lot of time to learn. But, most importantly, they want to see the whole picture, not just a list of users with critical rights and another list of vulnerable programs. As we learned from this article, CISOs should be responsible for all the listed areas and they want to see the whole picture and collect security-relevant data about different angles of SAP Security in one solution. The second important thing is not how the system itself is vulnerable but if it’s possible to hack other systems connected with this system, and, if so, how many systems it’s possible to hack, how easy it is and how critical those systems are.
And the last but not least, companies from different industries want to be able to analyze the security of their industry-specific applications, exact risks associated with their industry and follow guidelines applicable to their organization. All those needs are relatively new, but we already heard about those requirements from different analysts, CISOs, risk officers, SAP security engineers, and others involved in SAP Security.
I hope this post helped you to get to know what SAP Security is and how you can be involved in this growing world of opportunities.