Security Logging 

Description

SAP systems keep a variety of logs for system administration, monitoring, problem solving, and auditing purposes. Audits and logs are important for monitoring the security of your system and to track events if problems occur.

What Do I Get from the SAP NetWeaver Platform?

Depending on the data type, SAP systems offer different frameworks for logging data changes. In addition, several frameworks exist for logging events. For an overview of the different frameworks provided, see the following table:

Data Type / Events	Framework
Events	Security Audit Log, System Log, Application Log
Repository Data	Version Management
Customizing Data	Table Logging
Master Data	Standard Change Documents
Transaction Data	-   No framework is provided. It is not useful to log transaction data.

What Do I Need to Do?

Every time a log is required to trace data changes or system events, determine whether a logging mechanism that fulfills your needs is already provided by the SAP system. Where possible, use standard functionality. In this case, you automatically inherit all functions from the framework (for example, archive routines for change documents).

Security Audit Log

The Security Audit Log is available on the SAP Web Application Server. The tool is designed for auditors who need to take a detailed look at what security-related events have occurred in the SAP System. You can activate or deactivate the Security Audit Log. When you activate the audit log, the system keeps a record of those activities the customer considers relevant for auditing. The information may be evaluated by an audit analysis report.

The Security Audit Log allows insight into the daily work processes and system events, such as failed logon attempts or transaction starts. The audit log's main objective is to record:

●      Security-related changes to the SAP system environment

For example:

○       Changes to user master records

○       Changes to the audit configuration

●      Information that provides more transparency

For example:

○       Successful and unsuccessful dialog logon attempts

○       Successful and unsuccessful RFC logon attempts

○       Application server start and stop

○       Download of files

●      Information that enables tracing of a series of events

For example:

○       Successful and unsuccessful transaction starts

○       Successful and unsuccessful report starts

○       RFC calls to function modules

For more information, see Security Audit Log.

System Log

In addition to the Security Audit Log, the ‘normal’ System Log is also written in the SAP system. The System Log provides a more technical view of the events in a system, such as rollbacks, database read errors, dumps, and so on. The System Log is written on a continuous basis and may not be deactivated. Each event is recorded as a system log message under the system log numbers AU (or BU or CU since release 6.10).

For more information, see System Log.

Application Log

The Application Log is a tool that collects messages, exceptions, and errors. This information is organized and displayed in a log. Application logs are useful for brining situations that occur at runtime of an application program to the user’s attention. In standard SAP systems you will find application logs in QM, for example.

If you provide the Application Log (events) as an infrastructure in your own programs, take into account, that it is used to temporarily store messages. Data that, for reasons of revision security, has to be available for a long period of time, should not be stored with the application log but with Change Documents (changed data).

Developers who want to integrate the Application Log in their applications will find detailed documentation for all function modules and archiving techniques using archiving object BC_SBAL, and an overview of callback routines by executing the report SBAL_DOCUMENTATION in transaction SA38.

For more information, see Application Log – Guidelines for Developers (BC-SRV-BAL).

Audit Info System (AIS)

The Security Audit is not to be confused with the Audit Info System (AIS). The Audit Info System (AIS) is designed to facilitate and improve the audits performed by external auditors as well as internal auditors. The system is designed for Business Auditors, System Auditors and Security Administrators; many System Administrators also find it a useful tool.

Version Management

Use the version management function for Repository objects when making modification adjustments. The aim of version management is to keep track of all changes made to a Repository object. Therefore, the system automatically creates versions. More detailed information is provided in Version Management.

Table Logs

The analysis of logged customizing objects allows the customer to answer the following questions:

●      Who has changed customizing settings?

●      When and what has been changed?

For more information, see Logging Customizing Objects.

Log files are written if the following prerequisites are met:       

●      The rec/client parameter in the system profile is set to allow data logging.

●      Logging is active for the table.

For technical settings see Activate/Deactivate Table Change Logging.

When developing your application, you have to decide for which tables you want to activate logging. You can activate table change logging in the technical settings of the table using transaction SE11.

Standard Change Documents

Many business objects are changed frequently. It is therefore often useful and even necessary to be able to trace the changes made. This logging is carried out with change documents.

For detailed information, see Change Documents and Creation of Events When Change Documents are Written.

How to Use a Logging Framework?

When using a logging framework, the following advice may help:

...

       1.      Keep in mind that the aim of a log should always be the traceability of events on the business object of interest.

       2.      All data and documents must be assigned to the relevant transactions.

       3.      Never log passwords in plaintext.

       4.      Logs should not contain potentially confidential data such as credit card numbers or social security numbers. Instead, log sensitive data of this type in specially protected logs with authorization checks.

How Not to Do It?

As mentioned above, do not create your own logging framework. Instead, use a logging mechanism already provided by the SAP system. If no standard functionality is provided that fulfills your needs, try to get your required features included into the existing standard frameworks. All existing standard logging frameworks provided by the SAP system offer the following features that are required by a good logging framework:

...

       1.      Logging and archiving should be customizable, because every customer has different requirements. Even writing of log entries may be activated and deactivated in the system.

       2.      Logs should only be readable and never be changeable, due to traceability. Make sure that there is a check implemented to deny unauthorized access to logs.

       3.      Logs should contain information about:

○       The reason for logging.

○       The user who has created the log entry.

○       Date and time when the log entry was written.

○       System and client where the log entry occurred.

       4.      Consider how logs should be handled, that is, whether they can be deleted or be archived.

       5.      Take into account that log file creation affects performance. Secondly, many users access this log table in parallel. This could cause lock situations even though the users are working with different application tables.

Further Information

●      Auditing and Logging in the SAP NetWeaver Security Guide

●      SAP documentation about BAL_* Application Log Function modules

Execute program SBAL_DOCUMENTATION in transaction SE38 within the mySAP ERP 2005