Today we will discuss how SAP Security differs from traditional IT security. While in most cases security is security, no matter what we discuss, in SAP area there are some unique features.

First of all, it is the question of responsibility. It's not a secret that SAP is owned and managed by business, which, to be honest, rarely cares about security. However, people who are responsible for security, I mean CISOs or other similar positions, sometimes don't even know that SAP exists in their network and since have no idea how to ensure its security. Traditional security team mostly thinks about infrastructure security (such as network and server security) and malware prevention. Only a few years ago application security was added as a part of their daily job, but usually, a security team only deals with custom external facing web applications and portals, which are not related to SAP or any other Enterprise application.

The reason probably lies in the fact that SAP used to be a kind of a black box that companies install and trust implicitly. But when this application became more connected to other systems, new technologies including mobile and cloud were introduced, SAP became a part of existing infrastructure, but the part which nobody knows how to configure properly regarding security.

It doesn't matter who is in charge of SAP security when everything is fine and when there are no attacks on SAP Systems internally or externally, but if something happens with the organization's SAP System, the question of responsibility is raised. As SAP like any other system, be it either Windows domain controller or CISCO Router, is included in IT infrastructure, any issue within this system is a CISO's responsibility.

Unfortunately, most of them still don't have a clear understanding what SAP is and how to deal with the Enterprise Business Applications (for example, SAP ERP or Oracle PeopleSoft), we want to help them to close this gap. Our global aim is to provide non-SAP people with in-depth knowledge of SAP and teach SAP people what Cyber Security risks are.

4 Cs of SAP Security

Simply saying, SAP is a combination of some services with its own configurations such as FTP and custom-developed applications like Web Portal. Add on top of this a mix of thousands of users with a very complex role model like one you have in Domain controller. As a result, you will get an environment where different security approaches should be implemented in one place.

Four differences between SAP (or any other enterprise business application) and traditional applications are Complexity, Customization, Criticality, and Closeness.

Complexity

SAP Systems are very complex. I mean VERY complex. SAP is a company which is even older than Microsoft and its main software – SAP ERP system is at least as complex as operation system or even more. Just to give you an idea, demo installation of SAP System requires 60 gigabytes on a hard drive. The latest version of SAP NetWeaver J2EE engine is shipped with 1200 preconfigured web services, and each has a functionality of a small website. It's much more complex than any other application that you may meet. SAP has about 1000 parameters, and most of them can affect security. When you install an SAP System, it goes with 20+ different services, each of them uses its own proprietary protocol and a set of configurations. Just imagine how many vulnerabilities can be found in a multipart system. And it's only for NetWeaver ABAP Application Server, besides SAP provides at least five other platforms with a completely different set of functions, services, protocols, and even access control systems. By the way, a few words about access control system. If you are aware of it, I can see it by your reaction even without starting, but anyway.

Just to tell you briefly, authorizations in SAP are like a small portion of functionality you can execute. There are thousands of them; each authorization has an activity, field, and value. For example, there is an authorization to get access to tables, and this authorization can be associated with different types of activities such as read or write. Also, there are different types of access such as access to a particular number of tables, say, system tables or material tables. When you configure this one small part of access, it will be called authorization, then a set of authorizations is combined into a role, and a role is combined with a composite role and then the role is assigned to a user. But it is not the end; roles can be assigned to a profile and profile can be assigned to a user, as well. And above that system, we also have different types of users. For instance, reference users take access rights from real users but don't store the information about access rights in their profile. Once again, it's only about ABAP system. For other systems or even modules, you have other role models. And another fact to prove the idea of SAP complexity. Traditional scanners provide about 40k security checks for all IT systems; we have more than 10k checks for SAP alone. So, you can imagine how complex SAP is (complexity certainly kills security) and how large the share of SAP Security is in comparison with traditional systems.

Customization.

To be honest, SAP is not just a typical software. It's more like a framework and on top of this framework, customers develop their own applications using ABAP, JAVA, and XSJS languages or some frameworks such as UI5 for HANA. According to our review, up to 50% customization are usually implemented in large organizations. And it's not something unusual; customizations are a part of SAP. You can hardly find any SAP Implementation without customizations and new programs developed to automate one or another part of business. Those customizations may have vulnerabilities as any others. Those customizations are usually made by the internal development team, but now more and more companies outsource this process to 3rd parties. The typical SAP Installation may have ten to thirty thousand of programs which may have vulnerabilities. According to our Security Research, we usually find thousands of vulnerabilities per system during the initial assessment. Although not all of them are highly critical, it is a sight that this area is a part of SAP Security that shouldn't be ignored.

Criticality

All SAP systems are mission-critical, and if something happens to them, companies are likely to lose millions of dollars per minute. We speak not only about attacks but also about mistakes which can occur because of improper configuration or patching of SAP System. SAP Systems have many configuration parameters for backward compatibility with old and legacy systems, some or those parameters are insecure, but it's not always easy to configure them properly without breaking some connection with a legacy system. Unfortunately, some administrators leave their systems unpatched, because they are simply scared that something will go wrong after modifications.

Closeness.

Now we can say that this subject is less relevant than it was five years ago, but it remains important. SAP Security is a closed world, only a few people conduct in-depth research in this area and identify new vulnerabilities in SAP software on the regular basis. For years SAP Security seemed a synonym of Segregation of duties and SAP was like an unbreakable, solid and secure application developed by Germans. In reality, it turned out that the security was based on the fact that no one had access to these applications and hackers were not interested in examining them for the time. But gradually SAP applications have become more and more integrated into the infrastructure. At the same time, more researchers began to pay attention to these applications and their security.

Nevertheless, any other system (for example, Windows) was on the hackers' radar for dozens of years. Like the human immune system, they became less prone to attacks, as all the simple vulnerabilities were identified and closed years ago. As for SAP, these applications have relatively recently become publicly available, so they are plagued with vulnerabilities which were closed in other applications years ago. Figuratively speaking, regarding security SAP is like a child who is standing in the heart of Moroccan market crowded with pickpockets, tricksters, and other criminals. Luckily, the situation is changing, and the level of security awareness has increased significantly. However, security specialists now face another problem. Many guides, books, and documents from SAP related to security are being published, so, it's hard to choose the most relevant ones and especially information applicable for your business case.

SAP Security Myths

There are also some myths about SAP Security. Fortunately, some of them are dispelled by now, and for those who are into SAP Security, it may be strange to hear them. I will debunk them once again as I did more than six years ago at the SourceBarcelona security conference in 2010 where I delivered my presentation "ERP Security Myths Problems Solutions". I'm talking about such myths as SAP Systems are only available internally, SAP security is a vendor's responsibility, SAP is very specific and not known for hackers, and SAP security is only about SoD.

Let's talk about the Myth number one - SAP Systems are only available internally. This belief is widespread for all internal or legacy corporate systems. These systems are considered to be available only internally. Maybe, in the mainframe era you were able to use SAP only inside the company but not now we are living in the age of global communications. You need multiple connections with other offices' customers, suppliers, SAP technical support, mobile users, OT network, ICS systems, and so on. I'm not taking into account all new HANA and Cloud features, where all your data are potentially available to everybody from the Internet. And even if you don't have any external connections with SAP, there is still one potential door into your system. Users' workstations have both access to SAP and connection to the Internet, so it makes possible to attack users using malware and then connect to SAP Servers. To make matters worse, it's much easier than you think, just type in Google search some special strings such as /irj/portal which identify the SAP login page and you will see hundreds of SAP Portal systems accessible online. Some of them may be vulnerable

The second myth states that SAP Security is a vendor's responsibility. Well, if you check a license that you signed, you can find out that a vendor is not responsible at all for any damage within vulnerabilities in their products. In reality, the situation is rather better. Although they are not formally responsible, they care about some things. Nevertheless, it's mostly your responsibility. If we divide all potential security issues into two categories, we will see that vendors can solve program or architecture errors identified in their products, and they usually release updates sooner or later after an issue has been presented to vendor publicly or privately. Of course, the vendors try to release patches as soon as possible, but if you stay without a patch at least for one day after vulnerability disclosure, somebody is likely to exploit it and get access to your data. So, even if the vendor releases patches, you are still at risk for this period. While the vendors are responsible only for two things: releasing software updates and guidelines, an administrator is responsible for most of other things including implementation, secure configuration, human factor, patch management policies and procedures, access control implementation and security of custom developed programs.

The third myth is that business application internals are very specific and not known for hackers plus there were no public attacks on SAP. In short, here we are talking about security through obscurity. It is a very interesting topic. Traditional popular products such as browsers are "reviewed" by hackers, and thus becoming more secure. As you may remember, for many years SAP Systems were not in the scope of researchers and not reviewed by the community. Now business applications such as SAP are becoming more and more widespread on the Internet and in the cloud, so it raises the interest of hackers and researchers. According to our post on SAP Security History, there were 100+ research articles about SAP Security in the last five years, and this number is increasing.

And the last but not least myth is that many people, especially ERP-focused people, think that security is all about SoD and nothing else. For the beginning just think about it: configuring secure access control for Active Directory won't help you to secure infrastructure and network. But it's not just insecure approach, it's also irrational approach, it's like buying a new engine for your car every year when a tire is punctured. This is how you look like when you spend all resources on configuring Segregation of Duties and implementing GRC products, but leave your system unpatched. Just recall that Sachar Paulus (former SAP CSO) says: "another threat comes from people connecting their ERP systems to the Internet." That's what is happening right now.

Think again, having an ERP system with configured SoD and nothing else is like spending all money on video systems, biometric access control with the back door opened for housekeepers.

SAP Security in a nutshell

To sum up, let's answer the main question – what is SAP Security? SAP Security is a complex set of different areas. In fact, it can be divided into three distinct areas, namely Segregation of Duties, Custom Code Security, and Application platform security. Each one is usually a responsibility of different departments. However, I think there should be 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 is intended to prevent situations when users have elevated privileges or combination of these privileges. For instance, if some members have access to critical functionality such as read any table, they can escalate their privileges by reading a table with passwords. Despite this area is the most known, it's not as critical as others.

The second area is Code security. Programs written in ABAP (SAP's proprietary language for programming extensions to SAP Products) may have vulnerabilities and, what's more important, they can be used as backdoors. There are some solutions on the market that are intended to identify vulnerabilities in source code, transactions, and other extensions made by internal developer team or 3rd party developers.

The last and most important area is Application platform security. It covers all kinds of vulnerabilities, misconfigurations, encryption, logging, unnecessary enabled functionality, and other technical issues. In other words, it deals with all the issues that can lead to unauthorized administrative access to SAP system. In most cases, a hacker doesn't even need access to SAP to conduct an attack.

Why is the third part the most important regarding security? Imagine, you have the worst access control and SoD configuration ever, say, the SAP_ALL access is assigned to every user, this issue can only be exploited by somebody who already has access to SAP. On the other hand, if one has perfect SoD controls but a portal is exposed to the Internet and has an authentication bypass vulnerability, attackers can penetrate into the system and cause irreparable damage. It doesn't mean that we shouldn't pay attention to other segments, but application platform security is more important regarding cyber-attacks than others, and we will start with this area in our next article. Stay tuned!

Links

1. https://erpscan.com/wp-content/uploads/presentations/ERP-Security-Myths-Problems-Solutions-2010-SourceBarcelona.pdf
2. https://erpscan.com/tag/sap-netweaver-abap-security/
3. http://eas-sec.org