After we embraced the security of SAP ABAP and Java platforms, now it's SAP HANA Platform's turn. You will learn the most important notes about its security, vulnerabilities, and trends.

What is SAP HANA?

HANA stands for High-Performance Analytic Appliance. It's an in-memory relational database management system. Later, SAP introduced an application server dubbed HANA XS, and business applications based on top of this database (i.e. HANA S/4).

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Currently, SAP HANA looks more like a platform rather than a database. The platform seems to be the default for all business applications that SAP will release in the future, SAP reports outnumbering 7200 SAP HANA instances implemented worldwide. That's why it's vital to mind its security now before it becomes widespread.

SAP HANA platforms

Before we dive deeper into SAP HANA security, let's try to figure out all the existing types of SAP HANA since it might be a challenging task.

First, SAP HANA is a database and has different versions with different Service Packs. The latest SAP HANA versions are SAP HANA 1 SP12 and SAP HANA version 2 SP0. Nevertheless, the versions are easy to understand; the main difference is how exactly SAP HANA can be shipped.

There are several options:

• On-Premises. This is the most evident way. You install the SAP HANA platform in your environment. You can use SAP HANA database for any non-SAP application or for your SAP ECC system (SAP ECC on HANA), which will optimize performance. Users will employ the old SAP GUI client to work with the system (although it is vulnerable to attacks, the most notorious one is ransomware). You can also have SAP HANA S/4 that is SAP ECC on HANA but optimized to work with HANA and a new user interface, so-called SAP Fiori. As an example, SAP S/4HANA Finance app can shrink data more than ten times after optimization. Therefore, SAP HANA S/4 will be the prevalent option eventually [1]. From a security perspective, a user is in charge of all layers of HANA Security including network, application (vulnerabilities and misconfigurations), business logic (access control and SoD), and customization (Code Security).
• Infrastructure as a service. Both SAP HANA and SAP HANA S4 can be provided as IaaS. From a security view, it's almost the same as on-premises, but with a different datacenter. As a rule, application management and application security tasks are similar with those On-Premises versions, probably excluding some network security areas by the network configurations.
• Platform as a service. This option used to be called
  SAP HANA Cloud Platform, now SAP Cloud platform. If you don't want to have HANA onsite but to use the benefit of SAP HANA, SAP Cloud Platform can be implemented as an option. You can have your ECC system hosted on-premises but backend hosted in SAP Cloud, for that reason you deal with SAP HANA Cloud Connector to link ECC with SAP HANA Platform. From the security perspective, you stay responsible for the business logic security (i.e. access control and SoD), for customization protection of your ERP system, and application security (i.e. secure configuration of SAP HANA Cloud Connector). However, most of SAP HANA security issues won't be relevant for you as you won't be able to access critical services, except those that you manually redirected to your local network. Hackers who broke into your network won't be able to do it as well. Nevertheless, there is a risk of perpetrators attacking your PaaS provider.
• Software as a service.  Business applications based on HANA Platform (i.e. SAP HANA S4, SAP S/4 Finance or any other business application) are provided to you as a service. It reminds Salesforce's delivery model. Everything is in the cloud, and you have access to the application. In this case, your responsibility is mostly access control and SoD plus the security of custom applications you have developed.

SAP HANA architecture

SAP HANA Platform consists of the following services:

• Index Server is the main part, the database that holds all the data. There are engines for requests and data processing in Index Server
• Statistics Server gathers the statistics about the system, its work, mistakes, etc.
• Preprocessor Server operates Index Server for the text search and work with text data
• Name server stores the information about the system topology regarding the data and database location (for multi-host or Tenant systems)
• XS Engine is the web server that contains user applications and Cockpit necessary for web communication.

While the architecture seems to be quite simple in the beginning, it isn't the case. SAP HANA implementation might be complicated consisting of multiple HANA instances and being connected with other systems from ERP to IoT devices, smart meters, and other components of critical infrastructure [2].

Aside from the fact that all the information is stored in the main memory, SAP HANA (unlike a typical database) has its own XS web server, which holds various customer or SAP applications. For user applications, there is studio functionality to create and deploy them in the system. Also, built-in Cockpit allows a user to interact with the system via the web interface. It makes it possible to interact with the database and change the system settings at the Security tab. The in-files setup is carried out when the adjustment of a certain service is performed via Cockpit. That can replace the studio while working with the system.

SAP HANA Role model

SAP HANA Platform has its own role model, which is more complex than SAP NetWeaver ABAP authorization model.

• Analytic Privileges for access to certain table rows;
• System Privileges for administrative tasks;
• Object Privileges for managing database objects (if required, different SQL queries are possible);
• Package Privileges for managing (reading and changing) repositories are intended for developers
• Application Privileges for managing HANA applications, mostly XS. It resembles roles
• User Privileges is used only for the SYSTEM user; it's possible to assign it the privilege (e.g. ATTACH DEBUGGER)
• Granted Roles – other roles.

SAP HANA Security

SAP HANA vulnerabilities

Let's look at vulnerabilities affecting SAP HANA. 60+ patches were released in total by March 2017, and the actual number of vulnerabilities closed by those patches is at least over 100 (a single patch can fix one or more security issues).

It's less than in any other SAP system. First, the history of SAP HANA is just a few years comparing to the ABAP engine which is ten times older. Although there are not so many vulnerabilities in SAP HANA, their number increased five times since 2013 to 2014.

Secondly, we should give attention not only to the number of issues but also to their criticality, since most of the identified vulnerabilities are extremely dangerous. Information disclosures, SQL Injections, and Buffer overflows are the most common ones and can be exploited to get full access to the system without authorization.

Attack vectors

There are four common areas constituting SAP HANA attack surface:

1. The database itself and related services
2. All the additional services enabled for high-availability
3. The SAP HANA XS application server itself with its default applications and cockpit
4. All the custom developed web applications.

Attacks on SAP HANA Database

Let's take a quick look at the most significant areas of HANA Database Security. HANA stores crucial information such as user data (administrative login and encrypted password), encrypted root key and other keys in hdbuserstore, which is a kind of ABAP Security storage. The most dangerous security issue is that the default key for encrypting HANA Security Storage is the same for every installation, and administrators seldom change it.

As we can learn from different guides, the SAP HANA database holds the bulk of its data in memory for maximum performance, but it still uses persistent disk storage to provide a fallback in case of failure. Data is automatically saved to disk at regular savepoints. SAP HANA uses SAP NetWeaver SSFS to protect the root encryption keys that secure all encryption keys used in the SAP HANA system such as keys to encrypt savepoints data. So, savepoint keys are encrypted with the same for every SAP installation master key until a user changes it manually.

Attacks on SAP HANA XS Engine

SAP HANA Platform includes HANA XS Engine – a built-in application server, which can process HTTP requests from a web browser to the database. HANA XS is yet another application server like Apache Tomcat. All functionality of SAP's new products is based on web applications, which work on XS engine, obtain data from the SAP HANA database, process this data on XS Engine, and present users the results on web pages. XS Engine uses its own server-side JavaScript engine to process server-side requests.

The fact that SAP HANA is an in-memory database doesn't mean that it's more secure. SAP HANA XS web application server, as well as applications based on it, is susceptible to the same vulnerabilities as any other web application server. A number of critical vulnerabilities in SAP HANA XS application server itself was identified by security researchers such as buffer overflow vulnerability discovered by Matheu Geli from ERPScan.

Attacks on SAP HANA XS Applications

Every user can develop their own applications on top of SAP HANA as it was in SAP ECC with transactions written in ABAP. XSJS and SAP UI5 framework can be used to develop such applications. Different types of injections such as JavaScript code injections, SQL injections, and R-script code injections can affect SAP HANA applications. We have discovered some examples of them in SAP applications as well as in custom applications.

Attacks on SAP HANA additional services

Single instance SAP HANA differs from multiple instance SAP HANA installation, as the first one contains fewer services and thus less potential attack vectors. In fact, multi-tenancy multi-host implementations are the prevalent type of implementation.

When you have multiple SAP HANA systems that need to communicate with each other, you have multiple entry points. One of them is a TrexNet service, which is used by SAP HANA instances to send commands. It is susceptible to a vulnerability allowing anonymous execution of critical commands on the SAP HANA operation system (closed by SAP). Taking into account previously disclosed a vulnerability in security storage, this vector might lead to full compromise of HANA system and data it stores.

Conclusion

It's safe to say that SAP HANA is the future of all SAP systems and it will replace SAP ECC. However, it will take years for the largest enterprises to move their infrastructure to HANA. Currently, some large companies still use SAP R/3 system released in 90th, thus you should not underestimate the reality and protect your SAP ABAP and SAP JAVA systems.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

As for the defensive measures, we strongly recommend that you, at least, follow the SAP HANA Security Guides, regularly update system, and change default keys.

References

1. http://symmetrycorp.com/blog/sap-business-suite-on-hana-vs-s4hana/
2. http://help-legacy.sap.com/saphelp_hanaplatform/helpdata/en/37/d2573cb24e4d75a23e8577fb4f73b7/content.htm