Security for SAP HANA ®

SAP HANA ® is one of the newest and most exciting products to emerge from Walldorf in recent years. In memory database processing as a concept is not especially new, but until recently the costs of memory required to enable it have been prohibitive. This is no longer the case, and when harnessed with multi-core processors the results can be spectacular. Primary memory can be read up to 10,000 times quicker than secondary memory, and this also involves negligible latency (minutes instead of days). The SAP HANA ® platform processes both OLAP and OLTP transactions, extracting data from ECC, CRM, BI and other external feeds, and delivering output to a wide assortment of SAP ® enabled applications including mobile devices, and with SAP HANA One ®, to the cloud using AWS ® (Amazon Web Services).

For all the many advantages, in-memory databases are in their infancy and have not yet developed the mature security countermeasures that are present in conventional persistent databases.

Policy management tools looking for vulnerabilities and misconfigurations are not available for SAP HANA ®.
The absence of data redaction facilities at the application level means that sensitive data may not be concealed adequately.
Unlike conventional databases, SAP HANA ® user accounts are typically the same database user accounts, and this lack of abstraction introduces its own security risks.
The volumes of data involved and the speed at which they can be queried means that huge quantities of data can be spirited away before remedial action can be taken.
This architecture also amplifies the consequences of RAM based attacks.
The very implementation of a SAP HANA ® solution conflicts with the safety principles of server separation. SAP HANA ® involves using application and web servers built directly onto SAP HANA XS ® (Extended Application Services), because sharing of hardware resources gives the optimum performance and high performance processing that give SAP HANA ® its edge.
SAP HANA ® database backups are not encrypted and neither are Db traces, so Soteria make recommendations concerning encrypting OS files and Db backups.
We can advise on how to make safe connections between SAP (SMD) Solution Manager Diagnostics Agent ® and SAP Solution Manager ®.
We can advise best practice for connection between SAP HANA ® and R ® environments.

Soteria is a big fan of the SAP HANA ® suite of products. (We are for example particularly impressed with some of the new password parameters that are maintained e.g: maximum_unused_initial_password_lifetime
and
maximum_unused_productive_password_lifetime)

Unlike more mature SAP ® products in which cyber security has been retro-fitted, SAP HANA ® boasts an impressive array of security measures:
SAP HANA XS ® authenticates SAP ® logon tickets issued by either SAP Netweaver Application Server ® or portal, and recommends that SSL (Secure Sockets Layer) protocol is used to ensure both authentication and confidentiality through data encryption. Soteria is keen that this functionality is deployed with the caveat that the sslCreate-SelfSignedCertificate parameter is set to false to stop the use of self-signed certificates.
Where SSL is implemented for internal communications between hosts, a reputable CA (Certification Authority) should be used to sign certificates.
For access authentication SAML (Security Assertion Markup Language), and Kerberos are supported and all of these methods can be used to support SSO (Single Sign on).

Soteria are familiar with the various architectures which can be deployed within SAP HANA® together with the accompanying configuration and parameters to secure both data, and processes. We can steer customers around the architectural vulnerabilities and recommend mitigations where there are gaps in the defence in depth.