Follow these best practices to install, administer, and operate the SAP HANA system securely. More importantly, learn about control objectives that auditors check to gain assurance about controls in the SAP HANA system environment.
Key Concept
A system audit is an exercise performed to gain assurance that defined controls work as intended, thereby eliminating the likelihood of fraudulent or malicious activities in the enterprise system. It involves the verification of conformance to policies and procedures through an acute review of objective and empirical evidences. An SAP system audit normally involves checking the controls defined in the system against what is defined in the security policies of an organization.
The SAP HANA system is SAP’s flagship in-memory database system with embedded intensive analytics capabilities. The network infrastructure, operating system (OS), hardware, and the SAP HANA database system itself all constitute important facets in the audit of an SAP HANA system landscape. The audit challenges come with different levels of complexities because of the diverse technological dependencies and associated dynamics that characterize a typical SAP HANA system landscape. Therefore, a comprehensive approach needs to be adopted when reviewing an SAP HANA system for vulnerabilities and security weaknesses.
- Maintenance of an SAP HANA system and OS
- OS settings
- Installed packages on the OS
- System monitoring
- Activation of tracing
- Password of SYSTEM user
- Status and use of SYSTEM user
- Status of the auditing functionality
- Definition of audit policies
- Target of the audit trail
- Assignment of standard SAP HANA roles
- Critical privileges in production
- Maintenance of blacklisted passwords
- Password expiry time
- Initial password change at first logon
- Reuse of passwords
- Password character set
- Minimum password length
- Maximum idle time of initial password
- Maximum idle time of productive password
- User lock after failed logon attempts
- Automatic unlock of locked users
- Activation of Secure Sockets Layer (SSL)
- Data volume encryption
- Transport management
- Disaster recovery
- Firewall configuration
- Maintenance of system configuration parameters
- Segregation of duties (SoD)
- Role build model
- License management
- Password protection on client side
- User self-service
- Permission administration of the OS users and files
Maintenance of an SAP HANA System and OS
Major risk: The SAP HANA system landscape might be vulnerable to known security weaknesses in earlier releases that SAP (and OS vendors) might have identified and fixed in the newest revision or patch. These known vulnerabilities can consequently be exploited with malicious intent, especially by users who know about the security weaknesses. New functionalities can introduce new vulnerabilities that can also be exploited.
Preventive measure: Upgrade the SAP HANA system to the current available revision to take advantage of improved and enhanced security-centric settings, fixes, and capabilities. Management should put in place policies that drive the appraisal and consequent implementation of a new revision of SAP HANA, especially from a security vulnerability perspective. This is important so that known vulnerabilities that have already been fixed in recent revisions are not exploited in older versions, which can be the situation if the focus of a system upgrade is not holistic, but only focused on taking advantage of new functionalities. Consider, for example, an SAP HANA database (version 74) that is susceptible to the following security vulnerabilities when compared with a more recent version (90):
- Unauthorized modification of displayed content in SAP HANA web-based Development Workbench – SAP Note 2069676
- Potential modification of persisted data in HANA Extended Application Services (XS) Administration – SAP Note 2067972
- Potential information disclosure relating to IMPORT FROM statement in SAP HANA - SAP Note 2109565
- Code injection vulnerability in SAP HANA XS – SAP Note 2098906
To review the current version of the SAP HANA database and the operating system via SAP HANA studio, click the system Overview tab (Figure 1).

Figure 1
Current version of the SAP HANA database and operating system
You can also check the upgrade history of the SAP HANA database in SAP HANA studio via the system properties (Version History option) as shown in Figure 2. To open Figure 2, right-click the system node (FRD for example, under Systems) and follow menu path Choose Properties > Version History.

Figure 2
Version history showing installation date and time
The OS is an integral part of the SAP HANA system landscape. It should be patched as soon as reported security vulnerabilities are fixed by the vendor and mitigation controls implemented as soon as vulnerabilities are identified.
OS Settings
Major risk: The performance of the SAP HANA system might be impaired if optimal OS settings are not adhered to, which can lead to system unavailability in some extreme circumstances.
Preventive measure: Adhere strictly to recommended OS settings. These OS settings can be as basic as the file system layout required to run an SAP HANA system efficiently. The OS settings to adopt depends on the OS (SUSE Linux Enterprise server or Red Hat Linux Enterprise server), but generally you should disable transparent hugespaces and configure c-states for lower latency. Swap space should be reviewed for appropriateness in order to improve the overall system performance and ensure system stability. SAP Notes 2013638 and 1944799 detail the recommended operating system settings for the Red Hat Linux Enterprise server and SUSE Linux Enterprise Server, respectively. These settings should be reviewed and validated for appropriateness as part of the technical system review of the SAP HANA system landscape.
Note
C-state reflects the capability of an idle processor (in a new cpuidle driver for recent Intel CPUs) to turn off unused components to conserve power. Transparent hugespaces allow the handling of multiple pages as hugepages to reduce the translation lookaside buffer footprint (TLB), in situations where it might be useful.
Installed Packages on the OS
Major risk: Installing irrelevant software packages on the Linux OS increases the chances of the exploitation of the security weaknesses associated with the different packages. This can also indirectly lead to more administrative costs arising from focusing resources on activities not central to the operation of the SAP HANA system. Furthermore, these unwanted packages can cause performance bottlenecks and system instability. For example, the package ulimit.rpm defines a global resource limit on the SUSE Linux OS, which can affect the available memory for the system identifier (SID) user in an SAP HANA landscape.
Preventive measure: Only install required packages and enforce strict controls around the deployment of packages on the OS running the SAP HANA database. Depending on the OS in use, review the installed packages against the required packages on a defined frequency. For a SUSE Linux OS, for example, SAP Note 1944799 details the required packages needed to run SAP HANA efficiently.
System Monitoring
Major risk: Not closely monitoring the overall system state is a recipe for performance bottlenecks and increased system downtime.
Preventive measure: Monitor system behavior, state, and status, especially around memory use. CPU consumption and disk use should be monitored closely. A set of routine system checks should be documented and reviewed by appropriate personnel at defined intervals. Examples of system checks to focus on include host physical memory use, record count of nonpartitioned column-store tables, record count of column-store table partitions, long-running uncommitted write transactions, long-running blocking situations, and memory use of main storage of column-store tables.
Activation of Tracing
Major risk: Uncontrolled activation of tracing can expose sensitive data and affect available disk space adversely.
Preventive measure: The system supports different types of tracing, including database trace, SQL trace, user-specific trace, performance trace, expensive statements trace, kernel profiler, and plan trace. Tracing should be activated only as necessary. The directory in which trace files are stored should be well protected against malicious attacks. Trace-level definition should be employed to control the kind and amount of data captured during tracing. As part of the system review, you should check the status of the different trace types via the Trace Configuration tab of the Administration perspective in SAP HANA studio as shown in Figure 3.

Figure 3
The Trace Configuration tab in the Administration perspective
The trace configuration can also be further reviewed by clicking the edit icon (the pencil), which displays the trace settings such as trace level, filters, and tables (Figure 4).

Figure 4
Trace configuration settings
Furthermore, Network Time Protocol (NTP) should be configured as part of the SAP HANA landscape to ensure that trace files from distributed hosts can be displayed in chronological sequence.
Password of SYSTEM User
Major risk: This risk is for preinstalled SAP HANA systems by a certified SAP hardware partner. Not changing the delivery installation password of the SYSTEM user exposes the SAP HANA systems to external threats and attacks from the hardware vendor employees (present and past) as they have the logon details of the most powerful users in the SAP HANA landscape.
Preventive measure: As the SYSTEM user account is a powerful database user, the password of the SYSTEM user account should be changed immediately after the SAP HANA appliance is delivered by the certified SAP hardware partner.
The SYSTEM user password can be changed via the SQL editor using the command: ALTER USER SYSTEM PASSWORD <new_password> (Figure 5).

Figure 5
SQL statement to change the SYSTEM user password
Status and Use of SYSTEM User
Major risk: Not deactivating the SYSTEM user makes it vulnerable to everyday use, thereby increasing the chances of its use for malicious activities.
Preventive measures: Deactivate the SYSTEM user account to restrict the ability to connect with the SYSTEM user to perform business as usual (BAU) administrative activities. Emergency procedures should be in place to address business requirements in which the SYSTEM user is required to perform specific administrative tasks.
The SYSTEM user can be deactivated via the SQL editor (Figure 6) using the SQL command ALTER USER SYSTEM DEACTIVATE USER NOW.

Figure 6
SQL command to deactivate the SYSTEM user
You can check the status of the SYSTEM user by querying the USERS system view using the command (Figure 7) SELECT USER_NAME, USER_DEACTIVATED, DEACTIVATION_TIME, LAST_SUCCESSFUL_CONNECT FROM USERS WHERE USER_NAME = 'SYSTEM'.

Figure 7
SQL command to confirm the status of the SYSTEM user
The value of the USER_DEACTIVATED column defines if the user queried is deactivated (TRUE) or not (FALSE). The LAST_SUCCESSFUL_CONNECT column helps confirm when the queried user (SYSTEM in my example) last connected to the system. This helps to form an opinion on whether the SYSTEM user is controlled in terms of when it was last used.
The SYSTEM user is critical, so the user needs to be activated at some point. You can activate the SYSTEM user using the command (Figure 8) ALTER USER SYSTEM ACTIVATE USER NOW.

Figure 8
SQL command to activate the SYSTEM user
Following the activation of the SYSTEM user, if you run the SQL statement to confirm the status of the SYSTEM user, a screen displays with the USER_DEACTIVATED column set to FALSE (Figure 9).

Figure 9
SQL command displayed when the SYSTEM user is deactivated
Status of the Auditing Functionality
Major risk: If auditing is not activated, it is impossible to keep track of what has changed and who is doing what in the SAP HANA database system. It leads to the inability to report attempts to contravene defined security policies. Furthermore, it is impossible to discover security weaknesses if excessive authorizations are granted to some users. The system owner is not protected against accusations of security violations and data misuse and it can therefore be difficult to effectively enforce security standards and policies.
Preventive measure: Activate the auditing feature in the SAP HANA system.
You can verify if auditing is activated or deactivated by reviewing the value (Disabled or Enabled) defined against the Auditing Status: field in the security editor (Figure 10). It should be noted that the Auditing Status: field definition is a global setting and can be overwritten at the different individual audit policy levels. However, this parameter must be set to Enabled for auditing to occur irrespective of the setting at audit policy levels.

Figure 10
Auditing status verification of the auditing status in the security editor
Definition of Audit Policies
Major risk: Inadequate audit policies can lead to lack of visibility and oversight as to what has changed or is changing in the system. Poor or incorrect classification of defined audit policies based on the audit level can lead to critical malicious activities missed via the review of audit logs as you are more likely to ignore audited items with the audit level INFO than for CRITICAL.
Preventive measure: Activate auditing for critical activities such as maintenance of user authorization, maintenance of database objects, authentication of users, maintenance of system configuration, and access to or changing of sensitive information. Assign the audit level appropriately to ensure the audited items reflect the correct risk classification and tolerance of the organization. The audit level defines how elements such as communication, escalation, and audit concerns highlighted via audit policies are handled.
Management should review these settings for adequacy and effectiveness at defined intervals that should be based on appropriate policies and procedures. For example, the audit level of ALTER USER statements to clear INVALID_CONNECT_ATTEMPTS system view should be CRITICAL and not INFO. Because there are other activities that are not audited as standard, effective procedures need to be in place to ensure that such activities are monitored. For example, changes made to the system via OS commands or a system restart cannot be captured via the SAP HANA audit functionality.
You can review the defined audit policies via the security editor in the Audit Policies section as shown in Figure 11.

Figure 11
Defined audit policies via the security editor
You can also query the AUDIT_POLICIES system view using the command SELECT AUDIT_POLICY_NAME, EVENT_STATUS, EVENT_LEVEL, EVENT_ACTION, USER_NAME, TRAIL_TYPE FROM AUDIT_POLICIES to get information about defined audit policies (Figure 12).

Figure 12
Defined audit policies via the SQL editor
Target of the Audit Trail
Major risk: Not securing the directory or location where audit policy reports are stored can lead to manipulation (or deletion) of audit log files. Storing the audit log in a conventional text file format may lead to easy disclosure of sensitive and critical information.
Preventive measures: Ensure the audit trail target is set to the database or the OS (syslog). Avoid defining the audit trail target as a Comma Separated Value (CSV) text file, especially for critical audit items. If noncritical audit information is stored as a CSV text file, the directory in which it is stored needs to be properly secured.
You can confirm the audit trail target value via the security editor. The audit trail directory can also be defined at the individual audit policy level, which overrides the global setting definition as shown in Figure 13.

Figure 13
Global settings level and audit policy level definition of audit level trail target via the security editor
You can also check the value definition via the global.ini file in the Configuration tab of the Administration Console as shown in Figure 14. The applicable global.ini parameter is default_audit_trail_type, which has the following possible values: SYSLOGPROTOCOL (OS log), CSTABLE (database table), and CSVTEXTFILE (CSV file).

Figure 14
Definition of an audit trail target via a system parameter configuration file
You can also confirm the value of the audit trail type using the SQL command SELECT KEY, VALUE FROM M_INIFILE_CONTENTS WHERE KEY = 'default_audit_trail_type' by querying the M_INIFILE_CONTENTS system view (Figure 15).

Figure 15
Audit trail target definition in the parameter configuration file
Assignment of Standard SAP HANA Roles
Major risk: Standard roles usually contain excessive and unrestricted authorizations that can be used for malicious intent, including reading all data in the system if assigned to users directly.
Preventive measure: Create custom copies of standard roles and do not assign the standard roles, such as MODELING and CONTENT_ADMIN, to end users. You can review the roles assigned to users by querying the system view GRANTED_ROLES using the command (Figure 16) SELECT GRANTEE, GRANTEE_TYPE, ROLE_NAME FROM GRANTED_ROLES WHERE ROLE_NAME = 'CONTENT_ADMIN'.

Figure 16
Assignment of CONTENT_ADMIN standard role to objects
Critical Privileges in Production
Major risk: The assignment of critical privileges such as DEBUG and ATTACH DEBUGGER privileges in production may subject the system to malicious attacks as security settings can be circumvented via program codes – for example, when DEBUG is granted in production.
Preventive measure: Do not assign critical privileges to users in the production system. You can review assigned privileges to a user by querying the system view EFFECTIVE_PRIVILEGES using the command (Figure 17) SELECT * FROM "SYS"."EFFECTIVE_PRIVILEGES" WHERE USER_NAME = 'KENNY'.

Figure 17
List of assigned privileges to users
Maintenance of Blacklisted Passwords
Major risk: The system can be compromised as a result of users being able to log in with trivial and easily guessable passwords.
Preventive measure: Set up a list of illegal or forbidden passwords that cannot be used as passwords to log on to the SAP HANA database. The list of words that are not allowed as passwords or parts of passwords is maintained via the security editor of the SAP HANA database in the Password Blacklist section (Figure 18).

Figure 18
Maintenance of forbidden passwords in the security editor
You can also access the blacklisted password entries by querying table _SYS_PASSWORD_BLACKLIST of the SYS_SECURITY schema using the command (Figure 19) SELECT * FROM "_SYS_SECURITY"."_SYS_PASSWORD_BLACKLIST".

Figure 19
Password blacklist table showing forbidden passwords
Password Expiry Time
Major risk: An inappropriate setting for the password policy parameter maximum_password_lifetime makes the system vulnerable to an attacker, especially if it takes too long for passwords to expire. The attacker will continue to be able to perpetrate malicious activities in the system, which might go unnoticed for a long period of time.
Preventive measure: Consider changing the value of the password policy parameter maximum_password_lifetime to a number of days fewer than 182 days, which is the default. You can review the setting for the password expiry time via the security editor (Figure 20). In the security editor, you can ascertain the value defined against the Maximum Password Lifetime: field.

Figure 20
Password policy settings in the security editor
The password policy settings can also be reviewed by querying the system view M_PASSWORD_POLICY using the command SELECT * FROM M_PASSWORD_POLICY (Figure 21) or SELECT KEY, VALUE FROM M_INIFILE_CONTENTS WHERE FILE_NAME = 'indexserver.ini' AND SECTION = 'password policy' - maximum_password_lifetime is the applicable property.

Figure 21
Password policy setting review via the SQL editor
The default and custom password policy parameter can also be reviewed via the indexserver.ini file in the Configuration tab of the SAP HANA studio (Figure 22): maximum_password_lifetime is the applicable property.

Figure 22
Password policy settings definition via the indexserver.ini
Initial Password Change at First Logon
Major risk: The user administrator can maliciously log on with the initial password if users do not change their initial password at the first logon attempt.
Preventive measure: Activate the password policy force_first_password_change that forces users to change their initial password at the first logon attempt. This password policy can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field (radio button) in the security editor is User must change password at first logon: (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) is force_first_password_change.
Reuse of Passwords
Major risk: If the password history logged against a user is low, then the system is more vulnerable as an attacker might be able to reuse a previously compromised password successfully in a short space of time.
Preventive measure: Adopt a value of at least 5 for the password policy parameter last_used_passwords. Do not use a value of 0, or the user will be able to reuse his or her old password at any time without any limitation. This password policy can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Last Used Password (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) is last_used_passwords.
Password Character Set
Major risk: A simple set of characters in a password will lead to the generation of weak password hashes, subjecting the password to easy compromise, especially via a brute-force attack.
Preventive measure: Implement the use of a complex character set in the definition of the password, especially the inclusion of special characters in the passwords.
The definition of character set is controlled by a number of characters type attributes such as case sensitive letters, numerical digits, and special characters whose combination can help enforce secure character sets in the password definition. For example, a password that adheres to secure character set requirements will be A2b!z*yB7. The default value is A1a, which implies that a special character is not mandatory as part of the character set of the password. This password policy can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Required Character Types (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and the Configuration tab of SAP HANA studio (Figure 22) is password_layout.
Minimum Password Length
Major risk: The use of short passwords can subject the system to vulnerabilities because short passwords are relatively weak and easily guessable. Therefore they can easily be compromised.
Preventive measure: Ensure that the definition of passwords with a lengthy number of characters is enforced by setting an appropriate value for the password policy parameter minimal_password_length. The default value of this parameter is eight, which is reasonably sufficient in ensuring that strong passwords are generated. This password policy can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Minimum Password Length (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) is minimal_password_length.
Maximum Idle Time of Initial Passwords
Major risk: Uncontrolled management use of the initial password can make the system vulnerable as an inactive user account might be used to perpetrate malicious activities in the system, especially when the user account is not logged on over a long period of time.
Preventive measure: Review the default value of the password policy parameter maximum_unused_initial_password_lifetime and set it appropriately so that when users don’t log on after a defined period, the password expires and needs to be reset. This password policy parameter can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Lifetime of Initial Password (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) is maximum_unused_initial_password_lifetime.
Maximum Idle Time of Productive Password
Major risk: The longer the time it takes to invalidate a user’s password after a period of inactivity, the more vulnerable the system is to threat and attack, especially from the users who have either changed jobs or left the company.
Preventive measure: Review the value defined for the password policy parameter maximum_password_lifetime to better enforce security in user administration as it relates to the period of user inactivity.
This password policy can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Lifetime of Initial Password (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and the Configuration tab of SAP HANA studio (Figure 22) is maximum_unused_initial_password_lifetime.
User Lock After Failed Log-on Attempts
Major risk: If it takes more attempts to lock out users after attempting to log on with invalid passwords, the system is vulnerable to a brute-force attack. The potential for a brute-force attack can be strengthened if the value of the password policy parameter password_lock_time is set to 0.
Preventive measures: Management should consider reducing the value defined for the password parameter maximum_invalid_connect_attempts to a relatively low value. When deciding on the optimal value for the password policy parameter setting maximum_invalid_connect_attempts, do consider the impact of setting the password parameter password_lock_time to 0.
Create an audit policy to log activity about data manipulation statements in the INVALID_CONNECT_ATTEMPTS system view with a higher severity level than WARNING, such as EMERGENCY or CRITICAL. This password policy parameter can be reviewed via the security editor, SQL editor, and Configuration tab of SAP HANA studio. The applicable field in the security editor is Number of Allowed Failed Logon Attempts (Figure 20). The applicable password policy parameter in the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) is maximum_invalid_connect_attempts.
Automatic Unlock of Locked Users
Major risk: If the password policy parameter password_lock_time is set to a low value, it is easier to perform a brute-force attack as the time to start logon attempts again after the user has been automatically unlocked is quicker.
Preventative measures: The password policy parameter password_lock_time should be set to a relatively high value. Avoid setting this password policy parameter to a value of 0 as this deactivates the auto logout after failed logon attempts functionality. In the security editor (Figure 20), the applicable radio button options are Lock For and Lock indefinitely. In the SQL editor (Figure 21) and Configuration tab of SAP HANA studio (Figure 22) the applicable parameter is password_lock_time.
Activation of Secure Sockets Layer (SSL)
Major risk: Data transmission over communication channels such as a web browser might be vulnerable to interception, misdirection, or manipulation.
Preventive measure: Activate SSL in the SAP HANA landscape. Following the configuration of SSL, client connections to SAP HANA database should be configured to refuse non-HTTPS connection requests. The SSL-centric system parameters shown in Figure 23 should be set appropriately. For example, the system properties parameter sslCreateSelfSignedCertificate should be set to false to prevent the use of self-signed certificates. Similarly, the system parameter enable_ssl should be turned on to facilitate secured communication during data provisioning.

Figure 23
SSL-related system parameters in the global.ini
Data Volume Encryption
Major risk: Unauthorized access to data saved on disk at the OS level.
Preventive measure: Activate data volume encryption functionality in the SAP HANA system, especially if Dynamic Tiering functionality is not used in the SAP HANA landscape. This is to ensure the privacy and security of data saved on disk.
When encryption is activated, change the page keys at defined intervals to reduce the potential implications of a key being compromised.
Management should consider supplementing data encryption with third-party solutions especially for files that data volume encryption functionality does not support as standard in the SAP HANA system, such as database redo log files, database backup, and database traces.
You can review the status of data volume encryption via the Data Volume Encryption tab of the security editor in SAP HANA studio as shown in Figure 24.

Figure 24
Configuration setting of data volume encryption
Transport Management
Major risk: Uncontrolled promotion of configuration changes to the production system might lead to data and customization settings inconsistency, thus making the system error prone or unavailable in extreme scenarios.
Preventive measure: Enforce control in the promotion of changed data or customization settings across the system landscape by avoiding performing customizing activities in the production system directly.
Use a proper change management tool for transport management in the SAP HANA landscape such as SAP HANA Application Lifecycle Manager (ALM), SAP HANA Transport Container (HTC), or the change and transport system (CTS+) of the SAP NetWeaver ABAP application server. Where third-party tools are used, ensure that the product offers complete traceability as to the logistics of configuration changes across the landscape using automated change request documentation rather than manual approach to change documentation.
Disaster Recovery
Major risk: Organizations might not be able to resume business operations after a system failure or natural disaster.
Preventive measure: Periodically back up and save database copies in a safe place. Adopt storage or system replication technologies to ensure data copy and synchronization between primary and secondary databases. Enforce control in the assignment of back-up system authorization (BACKUP ADMIN and BACKUP OPERATOR) to nonadministrative users.
Firewall Configuration
Major risk: Unauthorized access to the SAP HANA system landscape.
Preventive measure: Implement a firewall solution to create network zones for the different components of the SAP HANA landscape. Set up rules within the firewall to block access to internal ports in different network zones.
Maintenance of System Configuration Parameters
Major risk: Making parameter setting changes in the global.ini and indexserver.ini system properties file eradicates the capability to audit what has been changed, by whom, and when.
Preventive measure: Changes to system parameter settings such as password policies, data volume encryption, and auditing status should be made using the security editor in the SAP HANA studio option and not via parameter setting changes in the system properties file.
During the system review, if you can establish that changes have been made and not logged even though auditing is activated, then it is very likely that system administrators have been making changes directly via the indexserver.ini and global.ini system properties file.
Segregation of Duties (SoD)
Major risk: Lack of the enforcement of SoD makes the system vulnerable to malicious activities including fraudulent acts.
Preventive measure: Perform detailed analysis of SoD violations in the SAP HANA landscape. Enforce SoD principles within the SAP HANA system landscape. Leverage SoD analysis tools such as SAP Access Control to identify where violations exist and take appropriate steps to clean up inherent SoD conflicts. SAP Access Control 10.1 supports the user provisioning and access risk analysis for SAP HANA roles and privileges. The ruleset defined for the SAP HANA landscape must be validated for correctness and completeness.
Role Build Model
Major risk: Run-time roles cannot be transported across the landscape, which is a deficient control issue in that it can lead to data inconsistencies. Possible business disruption as a result of unavailability of roles can occur when the creator of the role is deleted as the associated run-time role is also deleted. Lack of versioning capability can lead to the inability to track change history to roles built using a run-time model.
Preventive measure: As much as possible, use a design-time role build model and avoid using run-time roles except when you have a pressing business justification to do so. Role build can be performed using the design-time approach and run-time approach. Generally, the design-time approach is more acceptable because of its transportability, versioning, ownership, and provisioning concepts when compared to a run-time role design model.
License Management
Major risk: Violating an SAP license agreement is illegal, can lead to legal disputes, and can negatively affect the reputation of an enterprise. Expired licenses can lead to the unavailability of the system for business transaction processing.
Preventive measure: Ensure that the SAP HANA enterprise platform and, in addition, the implemented SAP HANA options are licensed appropriately.
Like any other SAP product, the SAP HANA system needs to be licensed correctly. The peculiarity with the SAP HANA licensing model is that SAP HANA options are licensed separately from the enterprise database platform. Examples of SAP HANA options that can be deployed on top of the enterprise platform and that require licensing include SAP HANA Accelerator for SAP ASE, SAP HANA Advanced Data Processing, SAP HANA Data Warehousing Foundation, SAP HANA Dynamic Tiering, SAP HANA Enterprise Information Management, SAP HANA Predictive Analytics, SAP HANA Real-Time Replication, SAP HANA Smart Data Streaming, and SAP HANA Spatial. You can check the status of the license of the different products via the SAP HANA studio. Right-click the System node (figure not shown) and choose the properties. In the screen that displays choose the License option (Figure 25).

Figure 25
License status and validation screen
Password Protection on Client Side
Major risk: Access to unencrypted passwords makes the system vulnerable to malicious attacks. There is the possibility to decrypt encrypted passwords once the location where the password is stored is identified and accessible.
Preventive measure: Do not save passwords in the connection file when connecting to the SAP HANA database via the OLE database for OLAP (ODBO) driver. Disable the capability to store passwords in the Eclipse Secure Store where this capability is not required.
User Self-Service
Major risk: If appropriate controls are not in place, the self-service functionality can be abused as users are able to reset their passwords or create access requests when they are not supposed to be able to do that.
Preventive measure: Set up a whitelist and a blacklist to control access to the self-service functionality in the SAP HANA system. It is possible to define whitelist and blacklist entries for user requests, network domains, IP addresses, email addresses, and database users.
Permission Administration of the Operating System Users and Files
Major risk: The SAP HANA system might be accessed remotely with the intent of performing malicious activities capable of compromising the availability of the SAP HANA system. The integrity of the data in the SAP HANA database might be compromised if appropriate user authorizations and file permissions are not defined in the OS.
Preventive measures: Enforce control in the way users (root and normal) are authenticated (locally and remotely) and what they can do within the system once logged on. Define a restrictive file permission authorization concept to safeguard against uncontrolled changes to critical security-relevant system settings. Detailed information about how to secure the SAP HANA system at the OS level is available here for a SUSE Linux Enterprise Server (SLES) OS: https://www.novell.com/docrep/2014/06/os_security_hardening_guide_for_sap_hana.pdf.
Kehinde Eseyin
Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
You may contact the author at eseyinok@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.