Other than their name suggests, audit policies are not only relevant for auditors. Just as the various regulations require policies to be set often incorporate security measures. Audit policies can by themselves be a powerful tool to increase the security baseline of IT systems.
Unfortunately, audit policies are usually not the first thing you think of when implementing the security settings of any given system. Therefore, it would be nice when those settings were carrying a secure value by default, wouldn’t it? At SAP, we’re fully committed to a “security by default” approach, and the SAP S/4HANA team has been one of the first teams to make this a standard.
Returning to the issue of audit policies, with the upcoming
note 3016478 we provide our SAP S/4HANA customers with a set of audit policies for the underlying HANA database which includes recommended general values for the SAP HANA database used, but also specific policies for the HANA database used in the SAP S/4HANA system. And even if you’re looking for some extended monitoring and logging, we got you covered with some optional values for added security.
But why is this important? First of all, let’s cover the basics. When you define an audit concept for an application, it should cover all aspects of said application. In this case, the SAP HANA database as an integral part of an SAP S/4HANA system, needs to be part of this audit concept.
Secondly, there are different purposes for which an audit concept can be devised (besides the naming purpose, of course). As mentioned above, these might be security purposes, such as intrusion detection or, more generally, security monitoring. It could also be closely related topics, such as data protection and privacy. Or it might just be part of an overall monitoring for system change logs. Whatever your purpose is, besides implementing the policies from
note 3016478, there are a few principles you should follow for audit policies in general.
- Avoid non-meaningful entries in the audit log
A meaningful audit log will only contain relevant entries. Logs are written for almost any event you can think of but making all of them part of your audit policy will significantly increase the size of the log files. And even in today’s world where storage costs are measured by a fraction of a cent, this can become an issue.
- Catch events related to security configuration and log actions related to security
All changes related to security settings should be logged. This is especially important if you plan to include security events and action into your security monitoring strategy. Solutions which analyze security events and information (so called SIEM solutions) usually try to identify suspicious activity by correlating events which seem out of the ordinary. And this can best be achieved when security-related events are actually caught in the log files.
- Log changes for users and authorizations
Attackers – both from the inside as well as from the outside – often use privilege escalation to gain additional authorizations. Those attempts need to be documented as well, not only for forensic purposes, documenting changes in authorizations might also be helpful or required in audit circumstances or other situations.
- Log unusual events
As mentioned above, unexpected events often give the most information. And since expected events don’t add any real value, the principle is to define auditing for everything and exclude the expected.
- No unnecessary redundancies
Some changes, notably those which are made by the technical user who “owns” the database, are also tracked in the application change log. Hence, this user should be excluded from the SAP HANA audit policies. The same is true for other technical users expected to act on the database. On the other hand, changes made by non-technical users should be included in the logging, specifically to avoid gaps in logging for Data Protection and Privacy (DPP).
Keeping these principles in mind will help you devise a strong audit strategy for the underlying database of your SAP S/4HANA system – and with the addition of the audit policies defined in
note 3016478, you’re on a good way to have a secure SAP S/4HANA system. By default.
As we're introducing those audit policies, we are also counting on your feedback - are the recommended and preset audit policies helpful? How are your experiences with securing both the SAP HANA database and the settings in the database for the SAP S/4HANA system? Let us know in the comments!
