Technical points to consider
Introduction
The SAP HANA platform has a crucial role in both cloud and on-premise SAP offerings. As a database solution, it is the primary foundation with S/4 HANA as the prime example. With end-of-maintenance of SAP Business Suite and NetWeaver on the horizon, it is no surprise to see organizations that run SAP, migrate to SAP HANA as the primary database. Which is already happening for several years. All the more reason for organizations and security specialists to look closely at the security aspects of the SAP HANA database. One of these is audit logging and in this blog we would like to share some technical key points to consider for audit settings on the HANA database.
- Activate HANA auditing
It may come as a surprise to some, but auditing is disabled by default on SAP HANA. Just like the
ABAP Security Audit Log, it is left to the customer to activate it when it is considered ‘required for the security concept’ of the organization. That’s at least how it is put by the ‘SAP HANA Security Checklists and Recommendations’. See the link here.
We believe that statement is far too open-ended though and that any productive HANA database should have auditing activated for a minimum set of actions. Regardless of the database being used as a stand-alone solution or as a database for a SAP solution. It is essential to safeguard data, track risks, identify suspicious activities etc. Without audit logging there is no serious investigation possible. Which is why activating audit logging is also recommended by the ‘SAP Security baseline’. See the link to the baseline here.
Consideration: activate auditing with parameter ‘global_auditing_state’ set to ‘true’. For a HANA SYSTEM database this is done in the ‘nameserver.ini’ and for a HANA TENANT database this is done in the ‘global.ini’ configuration.
“Any productive HANA database should have auditing activated for a minimum set of actions”
- What to audit?
With the activation of auditing, comes the question of what to audit for? In SAP HANA, auditing is done by defining so-called audit policies. First, it is important to note that there is always a default policy active when auditing is activated. This policy named ‘MandatoryAuditPolicy’, logs the most important actions that are related to the audit function itself. Like parameter changes for auditing and creation and changing of audit policies. Also, some other critical actions are logged.
Second, additional policies need to be created to log additional activities. These may be hard to define and can be quite specific as well, depending on compliancy rules that may apply. A good starting point though, is the ‘Best Practices and Recommendations for Creating Audit Policies’ from SAP. These can be created directly as suggested or adjusted to suit different requirements. See the following link here.
Consideration: create additional policies and use best-practices where applicable.
- Where to store audit data?
This may seem a straightforward topic, but it can be more complicated than expected. SAP HANA implements different priority levels that can be used for audit logging and also the possibility to log the data in different locations. This allows for a fine-grained auditing configuration but can be complex at the same time.
First, there are 5 priority levels: EMERGENCY, ALERT, CRITICAL, WARNING and INFO. The level is defined with the audit policy.
Next there are 4 different possible audit locations (called ‘audit targets’): SYSLOGPROTOCOL, CSTABLE, CSVTEXTFILE and KERNELTRACE. The last two options are not to be used in production systems for various restrictions and can in general be ignored for serious audit configurations. Which is why the ‘SAP Security Baseline’ also only considers SYSLOGPROTOCOL and CSTABLE as viable options. These two options mean the following:
SYSLOGPROTOCOL: logging of data in the Linux operating system log (like /var/log/messages).
CSTABLE: logging of data in an internal table on the HANA database.
The default audit trail that is used by the system, is set with parameter ‘default_audit_trail_type’. But for audit levels EMERGENCY, ALERT and CRITICAL, a separate trail type parameter can be set that has priority over the default. In turn, an audit trail can also be set on audit policy level which again has priority over the separate parameter. Still follow? Let’s clarify with an example:
Let’s assume there is an audit policy called ‘Protect4S’ on a TENANT database that logs any ‘DROP USER’ action with audit level ALERT. To make sure the data for this audit policy is written in the internal database (CSTABLE), there are 3 options to achieve this:
- Create the audit policy ‘Protect4S’ with specification TRAIL TYPE TABLE.
This will write any audit data for this policy (DROP USER) in the internal database table, regardless of any other parameters.
- Create the audit policy ‘Protect4S’ without TRAIL TYPE specification. But with parameter ‘alert_audit_trail_type’ set to ‘CSTABLE’.
This will write any audit data with ALERT level to the internal database table, including the ‘Protect4S’ policy (DROP USER).
- Same as 2, but with parameter ‘default_audit_trail_type’ set to ‘CSTABLE’, while making sure ‘alert_audit_trail_type’ is not set.
This will write any audit data to the internal database table unless otherwise overruled. Because the parameter ‘alert_audit_trail_type’ is not set, this includes the ‘Protect4S’ policy.
Consideration: keep the audit levels and trail types clear and easy to understand. Especially try to avoid different audit trail types for different audit levels to avoid confusion unless there is a clear business case for doing otherwise. From a SAP / database administrator perspective, it is likely preferable to use the internal database table for audit trails.
- How long to store audit data?
This mainly depends on organization requirements. When using the internal database table, the default retention is set with parameter ‘minimal_retention_period’. This can also be set explicitly on audit policy level, as shown in the example (180 days), allowing more precise retention control. The internal database table can be cleaned up with the ‘ALTER SYSTEM CLEAR AUDIT LOG’ statement or externally be exported if necessary. See SAP note 3252238 and 2684434 for more information. Note that a retention period can only be set for audit policies that use the internal database as trail type.
Useful references
See below for some additional references regarding HANA auditing
SAP Help – Auditing Activity in SAP HANA – link
SAP Note 3027477 – General information about auditing activity in SAP HANA – link
Conclusion
SAP HANA auditing is not merely a compliance checkbox but a vital security tool when configured sufficiently. A sound technical setup is a prerequisite for which we have given some key points to consider. The audit log functionalities of SAP HANA are also incorporated in our solutions SAP Vulnerability Management and SAP Threat Detection.
Like to know more about how Protect4S can help to increase security of your SAP landscape? We are happy to tell you more. For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
