It’s probably too early to sum up the state of SAP security in 2018. Then again, fall is the season for events such as the DSAG Annual Congress (German SAP User Group), which just ended in Leipzig. It is at conferences and trade fairs like this that you get a chance to find out exactly what is on the minds of SAP customers. As a result, it isn’t too soon to get a reading of the security issues that are considered important in the SAP environment.

Front and center, unsurprisingly is HANA. More specifically, the presentation of C/4 HANA has put this issue back on the agenda for many customers. However, on the back of SAP’s product initiative, the spotlight – surprisingly – is not solely on SAP security. Rather, an increasing number of customers are now preparing to actually implement HANA. Here, there are two main topics that are of interest to SAP customers approaching a HANA migration: roles and authorizations, and custom code.

Challenges of migrating to S/4 HANA

In both cases, technical requirements necessitate changes when migrating to or adopting HANA: Some custom development simply no longer works if HANA is implemented as a database or platform. Roles and authorizations are also affected. Many authorizations are compromised if S/4 HANA is used instead of a “normal” SAP ERP.

Security experts, however, are interested in another trend that is triggered by these two technical requirements. In short, the approach could be termed “YOLO” (you only live once). The customer’s thought process is as often follows: If I’m going to have to analyze my custom development, I can handle security at the same time. If I’m going to have to design roles for HANA, I can eliminate critical authorizations and SoD conflicts at the same time.

Good intentions aside, this highlights another problem concerning SAP security in 2018. Once again, customers are not looking at the issues holistically. Instead, different departments are each eyeing one issue. And this is understandable, as roles and development are often handled by different teams. Realistically, most customers do not have this holistic view of security, even though the overall picture is crucial in the SAP environment. Need an example?

Vulnerabilities in coding due to missing authorization checks

One of the most common security loopholes in custom code is the lack of authorization queries. If the missing authorization query refers to a transaction that is no longer in use, the security loophole isn’t really so bad. Sticklers might object to this characterization: Technically, the security loophole is still there and could still be misused. And that may well be true, but this is a symptom of the silo mentality, often the fatal flaw in SAP security.

We’ll use the above example as a simple exercise to demonstrate this: Let’s take the missing authorization check in the code that refers to an unused transaction. I can now take the following steps:

• We can assume that this piece of code is obsolete (because the code refers to an unused transaction). So we can get rid of it.
• If the transaction is hiding in some other roles, it can be removed from them, too.
• Before the transaction is removed from the code and the roles, we should log every access to the transaction and trigger a security warning if it is still used in order to prevent this security gap from being exploited.

To perform these steps, there are some additional prerequisites. Here, I’ll just provide some examples.

• To find out whether a transaction is in use, customers need usage statistics.
• To find out whether the transaction is in the code, customers need a code scanner.
• Finally, to find out whether the code is obsolete, customers need both of the above in combination. Now we’ve gone full circle: We must have the overall picture.

2018: SAP security is in vogue

So, what is the state of SAP security in 2018? The good news is that security is increasingly a topic for every customer. In the course of migration to HANA, the implementation of security projects has also become somewhat more realistic. The bad news is that this makes it even more dangerous to use this upswing for piecemeal fixes. What needs to happen is for customers to look at all aspects of SAP security. There are three main topics involved here:

Platform security: This is the technical security of SAP systems. It is important to widen the perspective to include the database and OS in addition to the SAP system. This is also when code security should be handled.

Identity and User Access Management: Often summarized as “Roles and Authorizations”, this is a core security issue for SAP systems. For example, this includes critical (security) authorizations, “super users” or “firefighters”, and everyday role management. The boundary between this and compliance, another core SAP issue, is often fluid. This makes it all the more important to set up roles and authorizations properly.

Security Intelligence: Security is one thing, but if something does happen, you do want to know what is going on. How secure is my system right now? Who is downloading or exporting data? Is my system being attacked from the outside? “Security intelligence” is where these questions are answered.

Now, just keep these three things in mind, and starting your adventure with HANA (migration) is not only a good idea, it is a safe bet.

Do you want to learn more about securing your SAP systems? Check out our SAST SOLUTIONS website or send us an e-mail us at sast@akquinet.de.

Patrick Boch, Product Manager, SAST SOLUTIONS