SAP HANA is SAP’s flagship database system and it is increasingly becoming important to focus on this innovative product as it is more than a database system. The fact that organizations are beginning to focus on the adoption of this in-memory database technology raises questions about whether auditors are equipped with even the baseline knowledge and expertise to perform a comprehensive and in-depth technical review of the SAP HANA system.

The multipurpose use of the SAP HANA system offers an additional layer of complexity to the general scope of a database audit when compared with conventional database systems, such as Oracle and Microsoft SQL Server. The scope of the audit is often a reflection of the amount of possible vulnerabilities that exist within the enterprise application. As organizations move toward acquisition, migration, adoption, and deployment of the SAP HANA database technology, the security requirements of the system need to be integrated into the wider infrastructure security framework of an enterprise and not treated as a silo application.

Other enterprise applications require auditing to ascertain the effectiveness of defined controls, and the SAP HANA database platform is not any different. However, it is important to identify the key areas to focus on to assign appropriate priority to possible vulnerabilities and subsequently define the basis for resource allocation in terms of auditing and remediation.

To perform a comprehensive technical review of the SAP HANA system landscape, it is important to first gain an understanding of the SAP HANA system landscape, including the implemented functionalities, the adopted options, and the dependent technologies. This knowledge gap is commonplace with internal auditors who might not be acquainted with the technicalities associated with the SAP HANA system. Unfortunately, they (internal auditors or process owners) represent the first point of call during the initiation of an audit by external auditors and they may be saddled with the responsibility of providing basic information about the SAP HANA landscape.

Therefore, I walk you through a number of questions that help you gain more information about the setup environment and configuration options adopted in an SAP HANA system landscape when planning a system audit. The intent of the article is to provide baseline information about the initial questions to expect during a system review of the SAP HANA infrastructure by external auditors, which will of course drive the audit scope. It provides uncanny insight to auditees as well as auditors alike.

Basically, an audit questionnaire helps highlight the main areas to focus on during the audit exercise. It can also be a tool to evaluate the amount of effort and time required to perform the audit work. In addition, it can help identify the required skill set needed to perform the review exercise.

As this is a relatively new database system and technology, auditors need to be equipped with the right elements to focus on when performing a technical review of the database system. An auditor does not want to be labeled as incompetent or ignorant because of an avoidable knowledge gap that can arise as a result of not identifying the associated dependencies of generic audit best practices in relation to the business requirements of a client. For example, an auditor should not have an audit item related to activation of the data volume encryption feature in the audit plan if the company has implemented the Dynamic Tiering SAP HANA option.

I not only focus on audit questionnaires that are related to just the core SAP HANA database functionalities but also discuss a number of concepts that are supposedly generic, of which SAP HANA has its own peculiarities. For example, during a typical audit of an SAP system, an auditor generally inquires about the operating system by asking questions about the vendor. You do not want to ask a user about a Windows operating system audit concern when auditing an SAP HANA database as it is not a supported operating system in the first place.

Furthermore, an appreciation of this questionnaire is vital in that SAP HANA brings a paradigm shift to a conventional SAP audit because one or two design options can influence the timing, effort, and focus area of the system audit. For example, one phenomenon that is commonplace with SAP HANA installations is cloud hosting, at least when compared with the traditional SAP installations running on conventional databases on premise. Therefore, the audit approach for an organization whose SAP HANA installation is cloud based is different than for an organization whose installation is on premise.

These are simple examples to justify why you need to get the audit questionnaire right. I explain possible options or feedback that is expected from the company. This is to guide the auditor administering the questionnaire in explaining the questions (where necessary) and validating the responses provided, especially as there are a couple of buzzwords peculiar with SAP HANA such as replication, tenancy, system type, and SAP HANA Extended Application Services (XS).

I detail neither what exactly needs to be checked nor how to perform audit checks on SAP HANA systems. Rather, I include checklists that should form the basis for identifying relevant areas of audit concerns for an SAP HANA technical review. This questionnaire is not exhaustive and is only designed to be used as a starting point to evaluate the audit requirement in a specific SAP HANA landscape.

I have put together 30 questions to facilitate the discussion on what technologies and functionalities have been implemented aimed at objectively identifying the applicable and possible audit concerns and required skills.

The focus here is to identify the revision level of the SAP HANA system, as a newer version fixes some security vulnerabilities and ironically introduces more vulnerabilities. Furthermore, newer releases offer additional functionalities that can raise new audit concerns.

You are interested in identifying the system identifier (SID) of the instances that will be reviewed during the audit. This might include non-production instances. The higher the number of instances, the higher the amount of effort that is required for the review work.

SAP HANA does not support too many operating systems. Different operating systems pose distinct security threats to the SAP HANA landscape and might require a specific skill set to review. The supported operating systems include:

• SUSE Linux Enterprise Server (SLES) 11
• Red Hat Enterprise Linux (RHEL) 6.5

Companies implement SAP HANA to achieve different objectives. The use case of SAP HANA can go a long way in affecting the scope and focus of the audit. Possible uses include:

• Reporting on replicated data
• A core database management system
• An application development tool

More often than not, SAP HANA typically acts as a data store for enterprise systems such as SAP ERP, SAP Human Capital Management (HCM), and SAP GRC solutions. You should be interested in identifying the enterprise applications running on the SAP HANA database to identify the corresponding audit concerns. For example, the audit concerns of an SAP HANA system housing SAP Business Warehouse (SAP BW) data are clearly different from that housing SAP HCM data.

This knowledge is invaluable in estimating an audit and review effort as it relates to migration, correctness, completeness and validation of legacy data in relation to the legacy database system.

SAP HANA options offer additional capabilities to the standard edition of the SAP HANA enterprise platform. There are generic and specific audit concerns when additional features are implemented with base offerings of SAP HANA platform. Therefore, it is important to get an idea of what capabilities are deployed, especially in the production landscape. The following SAP HANA options may be used in conjunction with the base edition of the SAP HANA platform:

• SAP HANA Accelerator for SAP Adaptive Server Enterprise (ASE)
• SAP HANA Advanced Data Processing
• SAP HANA Data Warehousing Foundation
• SAP HANA Dynamic Tiering
• SAP HANA Enterprise Information Management
• SAP HANA Predictive
• SAP HANA Real-Time Replication
• SAP HANA Smart Data Streaming
• SAP HANA Spatial

The ability to have multiple isolated databases in a single SAP HANA system raises specific audit concerns compared with when the SAP HANA system has a single database. For example, the risk associated with using the system user of the database system in a multi-tenant database container is spread across all the tenant databases.

The possible tenancy strategies that can be adopted are:

• Multi-tenant database container
• Single-tenant database container

As discussed in question eight, the number of tenant databases in the SAP HANA system can affect the audit scope and complexity. For example, data privacy can be an issue where a table is local to a tenant database, but can be queried by users in other tenant databases in the same system. Therefore, it is good to know the number of tenants in the SAP HANA system to further identify associated dependencies and relationships from an audit perspective.

Organizations typically choose a deployment option when planning an investment in SAP HANA technology. The audit concerns can vary depending on the deployment option adopted, especially in terms of information system security and service availability. 

The possible deployment options include:

• On premise: Hosting the SAP HANA appliance on the company’s existing IT landscape and infrastructure
• Cloud based: A service-provider-managed and subscription-based pricing approach to SAP HANA appliance acquisition

The audit concerns of the deployment model adopted can vary depending on who (the company or service provider) is taking responsibility for the provisioning of the SAP HANA appliance. Irrespective of the model adopted, the company still assumes ultimate responsibility for enforcing security in the SAP HANA system landscape. The possible deployment model options are:

• Appliance delivery model: The SAP HANA system was pre-installed by a certified SAP hardware partner
• Tailored data center integration model: The SAP HANA system was installed by a certified administrator

When reviewing the cloud-based option adopted in an organization, attention should be paid to specific audit concerns as they relate to the type of cloud-hosting technology adopted, as that forms the basis for other security considerations. Cloud-based hosting services can be provided via a public cloud or a private cloud.  

Another dynamic to the cloud-based hosting concept is the company offering the cloud-hosting service. In this regard, you want to differentiate between SAP and other cloud-hosting companies as that can affect the audit scope significantly. Owen Pettiford, in his article (https://scn.sap.com/community/business-suite/blog/2015/02/04/understanding-sap-private-cloud-public-cloud-and-on-premise--important-for-s4hana-roadmap) on SCN, offers insight into further distinctions between public cloud and private cloud in the context of SAP acting as the cloud-hosting company. The publicly available document HEC Security & Compliance (https://hcp.sap.com/content/dam/website/saphana/en_us/PDFs/HEC_IT_Security_and_Compliance_Customer%20Package_v2.pdf), for example, defines minimum security and data protection requirements. Cloud-hosted customer environments are expected to be operated in SAP tier levels III, III+, or IV classified data centers to meet the physical security and operational compliance requirements of the customer.

The SAP HANA system type is driven by the number of hosts that makes up the SAP HANA landscape. The host is basically a reflection of the operating system on which the SAP HANA system is installed and operated. The host provides the main resources that drive the operation and performance of the SAP HANA system, such as memory, CPU, network, and storage. The SAP HANA system type can significantly affect the audit scope and complexity as there are dependencies to evaluate objectively. For example, shared data storage is a priority concern in a multi-host system type environment and that can consequently raise audit concerns.

The possible system type options that can be adopted in an organization include:

• Multiple-host: Multiple SAP HANA instances distributed over multiple hosts, with one instance per host.
• Single-host: One instance of SAP HANA on a single host

Data replication or provisioning is an important concept in the SAP HANA world. The use of SAP HANA for in-memory reporting on business data requires data to be provisioned from a source system into a target system (typically, the SAP HANA database). Different approaches can be used for data replication, and which approach is used depends on the business requirements. The associated audit concerns vary from data quality to data security to security of the communication channels, depending on the adopted technology that can include:

• Landscape Transformation Replication Server (SAP Landscape Transformation [SLT])
• SAP HANA Extraction-Transformation-Loading (ETL) Data Services
• SAP HANA Direct Extractor Connection (DXC)
• SAP HANA Enterprise Information Management

Because SAP HANA drives different business requirements that require both internal and external communications, network security audit concerns, such as eavesdropping and data manipulation, are prevalent. Broadly, users, systems, and services connect with the SAP HANA system for different reasons. Some possible requirements for data communication include:

• Connections for system maintenance activities
• Connections for data replication purposes
• Connections from database clients that access the SQL/Multidimensional Expressions (MDX) interface
• Connections from HTTP/S clients
• External connections

The authorization concept in the SAP HANA system is based on privileges and roles. SAP HANA supports different types of privileges, including object privileges, system privileges, package privileges, and analytic privileges. It is important to establish how privileges are granted to users because how these privileges are granted can raise audit concerns. Possible approaches for granting privileges to users include directly to users or indirectly through roles. For more information go to:

https://help.sap.com/hana/sap_hana_security_guide_en.pdf

SAP HANA offers various tools to manage user and role creation and maintenance activities, depending on the implemented functionalities. Each of these tools has an area of audit concerns that needs to be evaluated appropriately.

Examples of possible tools for user and role maintenance include:

• The Developer Workbench of the SAP HANA studio
• The Editor tool of the SAP HANA web-based Development Workbench
• Security editor of SAP HANA studio
• Security tool of the SAP HANA web-based Development Workbench
• SAP HANA HDBSQL

The different authentication methods have associated audit concerns, and some options are not applicable to some SAP HANA front-end tools. Therefore, it is important for an auditor to know the limitations of the different single sign-on or authentication tools to identify the areas to focus on during the audit. For example, Security Assertion Markup Language (SAML) cannot be deployed on SAP HANA studio, so there is no point in concentrating audit time and effort on that. Generally, SAP HANA supports common single sign-on and authentication mechanisms or technologies, including:

• Kerberos version 5 based on Active Directory or Kerberos authentication servers
• SAML
• SAP log on/assertion tickets
• X.509 client certificates

There are a couple of approaches that can be adopted when designing and building SAP HANA roles. The possible options are:

• Run-time role design model
• Design-time role design model

Each of these approaches has its own pros and cons and it is best to validate the implemented approach in relation to the business requirement. This is because the validation guides the audit process and management reporting. For example, run-time roles, also referred to as repository roles, offer a couple of audit challenges pertaining to revocation of privileges and roles, but also have repository roles that can be a business requirement.

The transport of changes made to the system is important in SAP HANA just as in any other SAP system. Change management and controls are important concepts in security reviews. The first validation is to ascertain that there are processes and procedures in place for change control. More important, a review of the tool for enforcing the control is important as some approaches are best suited for specific business requirements when compared with others. Therefore, an evaluation of the security flaws of the deployed tool is important when analyzed within the context of the business requirement. The SAP HANA system supports a number of tools to manage the software logistics process that includes:

• SAP HANA Application Lifecycle Manager (ALM)
• SAP HANA Transport Container (HTC)
• The change and transport system (CTS+) of the SAP NetWeaver ABAP application server

There are a couple of tools (especially SAP products) that can be used to extend and simplify user and role administration in SAP HANA. Examples of such tools include:

• SAP Access Control
• SAP NetWeaver Identity Management
• Other third-party identity and access management (IAM) tools

Knowledge of the adopted tool is important in forming an opinion as to whether there are possible audit challenges with the integration of SAP HANA with the tool. For example, if SAP Access Control is integrated with SAP HANA for risk analysis and remediation, the validation of the SAP HANA ruleset can automatically form part of the scope of the audit work.

The user self-service functionality is designed to provide a web-enabled interface for requesting a new user account and resetting your own password. This functionality can trigger audit concerns, especially as they relate to the web-based interface and more importantly, associated configurations.

The approach used to store a user’s password on the client end can affect audit requirements. Therefore, it is a good practice to assess the implemented scenario and review associated audit concerns. A user’s password can be stored on the client side using a couple of strategies:

• SAP HANA user store (hdbuserstore)
• Eclipse secure store

When auditing is activated in the SAP HANA system, how the audit log is stored and the location of the audit log can be important audit concerns that may require further analysis to form an opinion on the auditing and logging processes. The analysis can use an empirical basis such as the criticality of the logged events and conformance to defined security policies. Another audit concern that is commonplace in the SAP HANA landscape in this respect is data access logging that can involve read and write access on tables and views, including execution of procedures. 

A firewall offers another layer of security to the SAP HANA system landscape. A couple of approaches can be employed in the deployment of firewall technology. Each has its own audit concerns and requirements.

The antivirus software used to prevent a virus attack while complying with the organization’s IT security policies forms an important area for audit review. Because SAP does not offer any guaranteed support for any third-party applications that it does not deliver, it is essential to assess if the product has been tested properly in an SAP HANA environment.

The knowledge of the backup software is important in identifying the viability of the product in meeting defined backup and restore policies or procedures. Additionally, audit concerns and flaws around the security of the backup data can be highlighted — for example, data encryption limitations.

Understanding of the tool and approach used for disaster recovery is pertinent to identifying any associated audit concerns and requirements. This is because disaster recovery is central to the ability of an organization to continue business operation following a disaster. SAP HANA supports the following disaster recovery strategies:

• Storage replication: Continuous mirroring of persistent data between primary storage and backup storage over a network
• System replication: Continuous update of secondary systems by the primary system, including in-memory table loading

The adoption of these technologies can raise audit concerns that require specific tools to perform a thorough and comprehensive system technical review. For example, storage replication strategy adoption may require an assessment of the network bandwidth as it needs a high bandwidth and low latency between the primary site and the secondary site. Furthermore, when disaster recovery using SAP HANA system replication is adopted, an auditor should be concerned about the security of the different connections throughout the data center.

29. Is the SAP HANA database integrated with any third-party applications?

Third-party applications offer potential windows for the exploitation of vulnerabilities and security weaknesses on the SAP HANA system. These applications normally involve the audit work to extend to an assessment of security vulnerabilities of the third-party products in addition to integration-centric audit concerns.

Detailed documentation is an important element in the audit process as it normally provides insights into the installation, operation, and administration of the SAP HANA system. Examples of relevant documentation to look out for include but are not limited to:

• User access management
• Transport management
• Security policies
• Replications procedures
• Blueprint
• Network diagram
• System operation guides

The feedback provided to the audit questionnaire by the responsible person in the organization is a good starting point to planning the audit, accessing the SAP HANA landscape, and gaining assurance on the effectiveness of defined controls. Responses received from the questionnaire may indicate red flags immediately even before the commencement of the audit work and can be a pointer to wider areas of audit concerns. Furthermore, it facilitates the recommendation of other areas of security settings improvement and control definition. Therefore, reviewing the questionnaire objectively offers a window of opportunity for the client to enforce the required security controls even before the proper audit.

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.