Audit logging and compliance

 Audit logging and compliance are fundamental pillars of information security in any enterprise system, and SAP landscapes (both ABAP-based systems and SAP HANA) are no exception. They ensure accountability, detect unauthorized activities, facilitate forensic analysis, and, crucially, meet regulatory and internal compliance requirements.

I. Audit Logging and Compliance in SAP ABAP (SAP Basis)

In SAP ABAP systems, the primary tool for security auditing is the Security Audit Log (SAL), also known as SM19/SM20.

A. Purpose and Importance:

• Accountability: Provides a verifiable record of who did what, when, and where in the system.
• Security Monitoring: Helps detect suspicious activities (e.g., repeated failed logons, critical transaction attempts by unauthorized users, changes to security settings).
• Forensic Analysis: In the event of a security incident, the SAL is crucial for reconstructing events, identifying the attack vector, and determining the impact.
• Compliance: Essential for meeting various regulatory requirements (e.g., SOX, GDPR, HIPAA, PCI DSS) that mandate logging of access to sensitive data, changes to system configurations, and user activities.

B. Key Features and Configuration (SM19):

1. Activation:

   • The Security Audit Log must be activated at the instance level using the profile parameter rsau/enable = 1. This is typically done via RZ10.
   • Restart of the application server is required after changing this parameter.

2. Filters (SM19 - Security Audit Log Configuration):

   • Filters define what events are recorded. You create "audit profiles" with one or more filters.
   • Each filter can be configured based on:
     • Client: Specific client or * for all clients.
     • User: Specific user or * for all users.
     • Audit Class: Categories of events to log:
       • Dialog Logon: Successful/unsuccessful dialog logons.
       • RFC Logon: Successful/unsuccessful RFC logons.
       • RFC Call: Execution of RFC-enabled function modules.
       • Transaction Start: Successful/unsuccessful transaction executions.
       • Report Start: Execution of ABAP reports.
       • User Master Record Change: Changes to users, roles, profiles, authorizations. This is highly critical.
       • System Start/Stop: When the SAP instance starts or stops.
       • System Environment: Changes to profile parameters, system status.
       • Audit Log Configuration: Changes made to SM19 settings itself (critical for detecting tampering).
       • OS Command: Execution of operating system commands.
       • File Access: Access to files via specific logical file paths.
       • HTTP/HTTPS Connection: HTTP/HTTPS security session management activities.
       • SQL Statement: (Less common, often relies on DB-level audit for this).
     • Weight of Event:
       • Critical: High-impact events (e.g., changes to critical users, SAP_ALL assignment, failed logons).
       • Important: Significant events (e.g., successful critical transaction execution).
       • All: All events in the selected class.
   • Filter Types:
     • Static Profile: Configured once and applies globally to all application servers (recommended for consistency).
     • Dynamic Filters: Can be activated/deactivated on specific application servers without restarting. Used for temporary, targeted tracing.

3. Profile Parameters for File Management:

   • rsau/local/file: Specifies the path and file name for the audit log on each application server.
   • rsau/max_diskspace_local: Maximum size of the audit file (in bytes). When exceeded, the current file is closed, renamed (.old), and a new one is started.
   • rsau/selection_slots: Number of filters that can be active simultaneously.

C. Reading and Analyzing Audit Logs (SM20):

• SM20 (Audit Analysis Report): Used to display and analyze the collected audit data.
• Selection Criteria: You can filter by date/time, user, client, audit class, event ID, application server.
• Interpretation: The report shows detailed information for each logged event, including:
  • Date and Time
  • Client
  • User Name
  • Transaction Code (if applicable)
  • Report Name (if applicable)
  • Event ID and Description
  • Return Code (success/failure)
  • Terminal/IP address
  • Additional details (e.g., new/old value for master data changes).
• Long-Term Storage: Audit files are stored on the application servers. For long-term retention and centralized analysis, they are often extracted and forwarded to a SIEM (Security Information and Event Management) system (e.g., SAP Enterprise Threat Detection, Splunk, QRadar).

D. Deleting Old Audit Files (SM18):

• SM18 is used to manage and delete obsolete audit files. It's crucial to have a retention policy and automate deletion to prevent disk space issues.

E. Other Relevant Logging in SAP ABAP:

• System Log (SM21): Records system-level events (database errors, program errors, security-related messages, changes to critical parameters). More for operational monitoring than detailed security auditing.
• Change Documents (Tables CDHDR, CDPOS via SCU3, SUIM): Records changes to specific application data (e.g., material master, vendor master, financial documents). This is different from the Security Audit Log, as it tracks business data changes rather than user actions or system events.
• Table Logging (SE13 for DDIC setting, SCU3 for evaluation): Records changes to table contents if logging is enabled for the table. Used for highly sensitive master data or configuration tables.
• Transport Logs (STMS): Records all changes transported between systems, providing an audit trail for configuration and code changes.

II. Audit Logging and Compliance in SAP HANA

SAP HANA, being a database platform, has its own robust auditing capabilities that are distinct from the ABAP application layer.

A. Purpose and Importance:

• Database-level Security: Tracks actions directly performed on the HANA database, bypassing the application layer (e.g., direct SQL queries, privilege grants, user management at DB level).
• Data Access and Integrity: Logs data access, modifications, and deletions, crucial for data privacy and integrity compliance.
• Compliance: Meets specific database auditing requirements for regulations like GDPR, HIPAA, SOX, and internal policies.

B. Key Features and Configuration:

1. Activation:

   • Auditing must be explicitly enabled for the SAP HANA database. This can be done via SQL (ALTER SYSTEM ALTER CONFIGURATION ... GLOBAL_AUDITING_STATE = 'true') or through the SAP HANA Cockpit.
   • For multi-tenant database containers (MDC), auditing is configured independently for the system database and each tenant database.

2. Audit Policies:

   • Unlike ABAP's filters, HANA uses "audit policies" to define what actions are audited.
   • Policies define:
     • Audited Actions: Granular SQL actions (e.g., CREATE USER, DROP USER, GRANT PRIVILEGE, REVOKE PRIVILEGE, SELECT, INSERT, UPDATE, DELETE).
     • Target Objects: Specific schemas, tables, views, procedures to monitor.
     • Affected Users: All users or specific users/roles.
     • Audit Levels: EMERGENCY, ALERT, CRITICAL, WARNING, INFO (for severity/importance).
     • Success/Unsuccessful: Log successful actions, unsuccessful, or both.
   • Always Audited Actions: Certain actions are always audited when auditing is active, regardless of user-defined policies, such as changes to audit policies themselves, deletion of audit entries, and changes to audit configuration. This prevents tampering with the audit trail.
   • Creation: Audit policies are created using SQL (CREATE AUDIT POLICY) or via the SAP HANA Cockpit.

3. Audit Trail Targets:

   • Where the audit logs are stored. HANA offers several options:
     • Internal Database Table (default for Tenant DBs): _SYS_AUDIT.AUDIT_LOG. This is secure as it's within the database and protected by database privileges.
     • Linux Syslog (default for System DB): Logs are written to the operating system's syslog.
     • CSV File: Primarily for testing, not recommended for production due to security and manageability concerns.
   • Best Practice: Internal database tables are generally preferred for security and ease of management within HANA. Logs from here can then be forwarded to a SIEM.

4. Managing Audit Trail Size:

   • HANA provides mechanisms to manage the size of the audit trail to prevent it from growing indefinitely.
   • Retention periods can be configured for database table targets.
   • Alerts can be set up to notify administrators when the audit log size approaches limits.

C. Viewing and Analyzing the Audit Trail:

• SAP HANA Cockpit: Provides a graphical interface for reviewing audit logs.
• SQL Queries: Directly query the _SYS_AUDIT.AUDIT_LOG view (or similar views depending on HANA version) for detailed analysis.
  • Example: SELECT * FROM "_SYS_AUDIT"."AUDIT_LOG" WHERE USER_NAME = 'HANAUSER' AND ACTION_NAME = 'SELECT';
• Security Audit Log (SM20) in ABAP: While HANA has its own logs, if the ABAP system is running on HANA, some specific events (e.g., changes to ABAP profiles) might still be visible in SM20 on the ABAP layer, as the ABAP system acts as a client to the HANA DB. However, direct DB operations are only in HANA's native audit logs.

D. Key HANA Privileges for Auditing:

• AUDIT ADMIN: Required to enable/disable auditing, create/modify/drop audit policies.
• AUDIT OPERATOR: Required to view and delete audit entries.
• INIFILE ADMIN: May be needed to modify certain auditing-related system parameters in global.ini or nameserver.ini.

III. Compliance Requirements and Best Practices for SAP Audit Logs

A. Key Compliance Requirements (General):

• SOX (Sarbanes-Oxley Act): Mandates strong internal controls over financial reporting. Requires logging of all financial transactions, changes to master data, and user access to sensitive systems.
• GDPR (General Data Protection Regulation): Focuses on protecting personal data. Requires logging of access to, modification of, and deletion of personal data, especially sensitive personal data.
• HIPAA (Health Insurance Portability and Accountability Act): For healthcare, requires logging of access to Electronic Protected Health Information (ePHI).
• PCI DSS (Payment Card Industry Data Security Standard): For organizations handling credit card data, requires logging of all access to cardholder data environments.
• Internal Audit Policies: Organizations often have their own specific internal policies that are more stringent than external regulations.

B. Best Practices for Audit Logging in SAP:

1. Define Clear Audit Policies:

   • What needs to be logged? (Critical transactions, sensitive data access, configuration changes, user master changes).
   • Who needs to be logged? (All users, or specific high-privileged users like SAP* / DDIC / security administrators / emergency users).
   • Prioritize logging for high-risk activities and data.

2. Activate and Configure Extensively:

   • SAP ABAP: Activate SM19 filters for all critical audit classes (Dialog/RFC Logon, User Master Record Changes, Transaction Starts for critical T-codes, Audit Log Configuration Changes). Consider "Critical" and "Important" events.
   • SAP HANA: Enable auditing and define policies for user management, privilege grants, and access/modifications to sensitive data tables/schemas.

3. Secure the Audit Logs:

   • Access Control: Restrict access to SM19, SM20, SM18, SUIM, and underlying audit log files/tables to a very limited number of security/Basis administrators and auditors.
   • Tamper Protection: Ensure logs cannot be easily modified or deleted by unauthorized individuals. (HANA's "always audited actions" for audit config changes is key here).
   • Off-System Storage: Export audit logs to an external, secure, centralized SIEM solution. This provides an independent copy for forensic analysis even if the SAP system is compromised.

4. Regular Monitoring and Review:

   • Automate alerts for critical events (e.g., multiple failed logons, SAP_ALL assignment, changes to SM19 filters) via SIEM or SAP's internal alerting mechanisms.
   • Perform periodic (daily, weekly, monthly, quarterly) reviews of audit logs by a dedicated security or audit team.
   • Investigate anomalies promptly.

5. Retention Policy:

   • Define and adhere to clear retention periods for audit logs based on legal, regulatory, and internal requirements (often 1 year, 7 years, or even longer).
   • Implement archiving procedures to move old logs to secure, long-term storage.

6. Segregation of Duties (SoD):

   • Ensure that the individuals responsible for configuring and reviewing audit logs are separate from those performing operational activities in the system. The "auditor" role should be distinct from the "administrator" role.

7. Documentation:

   • Maintain detailed documentation of audit policies, configurations, retention periods, and review procedures. This is essential for internal and external audits.

8. Performance Considerations:

   • While comprehensive logging is important, over-logging can impact system performance. Balance compliance needs with performance by carefully selecting what to log, especially for high-volume activities (e.g., avoid logging every SELECT statement in a highly transactional table unless specifically required for extreme sensitivity).

By implementing a robust audit logging strategy across both the ABAP application layer and the HANA database layer, organizations can significantly enhance their SAP security posture and ensure compliance with critical regulatory mandates.