SAP HANA environments typically have far more users directly accessing back-end systems than conventional environments. Therefore, it is critical to configure effective audit policies to monitor actions that include SELECT, INSERT, UPDATE, DELETE, EXECUTE, and other SQL statements when combined with specific conditions.
– Aman Dhillon, managing director and SAP security architect, Layer Seven Security

To find out what security issues SAP HANA presents to IT organizations, I asked Aman Dhillon, SAP security architect at Layer Seven Security, a series of questions. See what he had to say about monitoring access to SAP HANA-based applications and determining if your SAP HANA-based environment has the optimal level of protection. Aman also comments on key areas on which to focus to ensure optimal protection against a new form of malware that targets SAP systems.

Aman, what are some key security points an organization should consider before implementing SAP HANA?

First, organizations should be aware that there are some trade-offs to adopting SAP HANA with respect to security. In-memory databases are a relatively new technology, and therefore, do not offer the same range of security measures as conventional persistent databases that have benefited from 30 years of evolution.

This includes label-based rules for more granular control over data access, data redaction to mask the display of sensitive data, and utilities to apply patches without interrupting the availability of database services. However, these drawbacks are a caveat for the use of SAP HANA and should not be used as an argument against the implementation of in-memory databases. The performance edge delivered by SAP HANA is extraordinary and, in most cases, outweighs any security disadvantages.

Companies can unlock the full potential of SAP HANA while protecting the confidentiality, integrity, and availability of information within such systems by placing database servers in secure network zones and limiting inbound and outbound connections. The SSL (Secure Socket Layer) protocol should be used to authenticate and encrypt all network communications. Furthermore, since data is replicated from in-memory to persistent volumes for recovery purposes, data should be encrypted at the volume level. Any data backups should also be encrypted.

Strong password policies should be configured through the SAP HANA Studio for users that authenticate directly with HANA. I recommend changing some of the default parameters for added security. Simple passwords should also be blacklisted, and password resets should be performed for standard users post-install.

Logging policies should be configured through the Security editor of HANA Studio. This is often required for compliance and forensics. It also supports security monitoring when combined with automatic alerting for critical events. Log data should not be transmitted in clear text over untrusted or lower trust network zones. This can lead to the disclosure of hostnames, systems ID, ports, IP addresses, clients, users, roles, and other sensitive data that can be abused to perform targeted attacks against SAP systems.

Since SAP HANA is delivered as an appliance, customers also need to secure the underlying operating system. The delivered security settings should be verified against the hardening guidelines issued by SUSE for the relevant version and release. It is important to disable vulnerable network services, control root-level access, and enable file integrity monitoring.

How is securing an SAP environment based on SAP HANA different from securing a standard SAP system, such as SAP ERP Central Component without SAP HANA?

Environments that leverage SAP HANA present some unique security challenges in comparison to those that use conventional databases. One of the most important challenges relates to the principle of server separation. Since persistent databases are usually installed on separate hosts, organizations are able to separate the different components in conventional three-tier SAP architectures into different physical or virtual machines and network zones. This enables organizations to apply unique security policies to each tier and build layered defense strategies to repel attacks. Server separation cannot be implemented in scenarios that involve the implementation of applications on the same technical infrastructure as SAP HANA. Server separation is a requirement of the Payment Card Industry Data Security Standard (PCI DSS). Therefore, this implementation scenario cannot be considered PCI compliant.

SAP HANA also stores large quantities of data in volatile memory such as RAM. This data is not encrypted. Although encryption is theoretically possible, it would place a massive strain on CPUs and impact latency and therefore would defeat the rationale for using in-memory databases. The reliance on non-persistent memory could make SAP HANA vulnerable to RAM-scrapping attacks that target unencrypted data in volatile memory. It is widely believed that such attacks were used successfully during the recent data breach at Target Corp.

Does an SAP HANA environment require more monitoring of who is accessing the SAP back end compared with a non-SAP HANA system?

Most definitely. SAP HANA environments typically have far more users directly accessing back-end systems than conventional environments. Therefore, it is critical to configure effective audit policies to monitor actions that include SELECT, INSERT, UPDATE, DELETE, EXECUTE, and other SQL statements when combined with specific conditions. Policies can be configured for particular users, tables, views and procedures. We recommend auditing all actions performed by privileged users, including the SYSTEM user and actions that impact sensitive database objects.

If an organization decides to migrate some of its data to SAP HANA on a cloud-based service such as Amazon Web Services, what are some key security points to consider?

At a technical level, companies opting for a cloud-based implementation scenario should ensure that virtual machines (VMs) are compartmentalized, isolated, and hardened. Furthermore, since network firewalls are incapable of inspecting communications between VMs on the same host, virtual firewalls should be deployed at the hypervisor level if hardware is not physically isolated.

Non-technical considerations include cross-border data flows. The cloud infrastructure of providers such as AWS can span a number of geographic zones. This could expose organizations to country- or region-specific regulations concerning data privacy and may even lead to international litigation in the event of a data breach.

According to a blog posted last November on the Layer Seven Security Web site, a new variant of the ibank Trojan showed signs of being adapted to target SAP systems. Could you comment on this threat and offer some advice on what security teams should do to ensure that their systems don’t fall victim to this malware?

The discovery of a new form of malware targeting SAP clients has understandably led to a great deal of anxiety and concern from SAP customers. The malware is a variant of a well-known Trojan program that previously targeted online banking systems. The reconnaissance performed by the malware is regarded by security experts as the preliminary phase of a planned attack against SAP systems.

The program seeks out SAP clients and is capable of logging keystrokes and capturing screenshots that could lead to the theft of user credentials and other sensitive information related to SAP systems. SAP responded to the malware by issuing numerous recommendations to customers in SAP Note 1946009. The recommendations include updating antivirus and IPS signatures, restricting the administrative privileges of end users on local machines, installing OS patches and updates, enabling Single Sign-On, network and host-level firewalls, disabling AutoRun features, and avoiding the use of non-complex passwords across multiple systems and accounts.

Since the malware targets front-end SAP clients, customers should also consider hardening security policies for the SAP GUI, including disabling user scripting and input history, limiting multiple logons, and enabling strong filtering rules in the SAP GUI security module.

Protecting SAP systems from cyber threats requires a broad response across the areas of network security, Remote Function Call (RFC) communications, user authorizations, logging, and system configuration management. Layer Seven Security has released a security framework to enable customers to secure SAP systems from such threats. The framework advocates 80 distinct actions across 20 specific controls grouped into five control objectives.

Gary Byrne

Gary is the managing editor of Financials Expert and SCM Expert. Before joining WIS in March 2011, Gary was an editor at Elsevier. In this role he managed the development of manuscripts for Elsevier’s imprint responsible for books on computer security. Gary also has held positions as a copy editor at Aberdeen Group, a Boston-based IT market research company, and as an editor at Internet.com, a publisher of content for the IT community. He also gleaned experience working as a copy editor for International Data Corp., a Framingham, MA-based IT market research company. He earned a bachelor of science degree in journalism from Suffolk University in Boston. He enjoys traveling, sailing as a passenger onboard schooners, and helping his wife, Valerie, with gardening during summer weekends. He’s a fan of all the Boston sports teams and once stood behind Robert Parish in a line at BayBank. He felt small and didn’t ask for an autograph. You can follow him on Twitter at @FI_SCM_Expert. His online footsteps can also be found in the SAP Experts group on LinkedIn.

You may contact the author at gary.byrne@wispubs.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.