Author: Layer Seven

Security Information and Event Management (SIEM) platforms combine the ability to collect log data from applications, hosts, routers, switches, firewalls and other endpoints with the ability to analyze events in real time. They support threat detection, event correlation and incident response with alerting and reporting capabilities.

SIEM platforms require complete coverage for maximum yield. In other words, organizations reap the full benefits of SIEM platforms when monitoring logs throughout the technological infrastructure. This includes SAP application logs for organizations with SAP systems.

However, there are several challenges with integrating SAP application logs with SIEM systems. The first is complexity. SAP systems typically contain multiple logs that capture security-relevant events. The SAP NetWeaver Application Server ABAP (AS ABAP) alone has at least seven such logs including the Security Audit Log, Gateway Server Log, HTTP Log, System Log, Transaction Log, Change Document Log, and the Read Access Log. The logs do not have a standardized format or structure. Some are captured at the file level and others are stored in SAP tables. The complexities involved in integrating multiple and distinct logs from each SAP system should not be underestimated, especially for large SAP landscapes.

The second is log volume. Raw event logs can grow to gigabytes and even terabytes within a relatively short period of time in SAP systems that often support thousands of end users and hundreds of cross-system connections. Transmitting large volumes of log data from SAP systems to SIEM platforms could consume high levels of network bandwidth. The need to store such data for analysis could also increase resource requirements and licensing costs for SIEM systems.

The third challenge with directly integrating SAP logs is maintenance. Monitoring and supporting the numerous integration points between SAP systems and SIEM platforms, as well as regular archiving to deal with the accumulation of log data, could lead to high maintenance costs.  

Finally, many SAP logs do not natively include information to support cross-platform correlation using SIEM tools. This includes source and destination IPs for security events. Values for sources and destinations in SAP logs are often terminal names and SAP Systems IDs (SIDs) rather than IP addresses. Therefore, Security Operation Centers (SOCs) are not able to easily correlate SAP events with non-SAP events in SIEM platforms.

The Cybersecurity Extension for SAP Solution Manager overcomes such obstacles by filtering, normalizing and enriching security event data from SAP logs. The Monitoring and Alerting Infrastructure (MAI) in Solution Manager can be used to monitor logs at source without extracting and replicating event logs to external repositories. This reduces both bandwidth and storage requirements. MAI data providers support monitoring for all SAP logs including file and table logs in ABAP, HANA, and Java systems, and standalone components such as the SAProuter. MAI periodically parses event logs using attack detection patterns configured in metrics. The frequency of metric checks is customizable and can range from every 60 seconds to several minutes apart. Intervals can be adjusted at the metric level which means metrics can have different monitoring intervals.

A pattern match triggers the MAI to generate alerts and email or SMS notifications for security events. Security alerts generated by Solution Manager are managed using applications such as Monitor Systems, System Monitoring and the Alert Inbox. Alerts can also be written to an external file by Solution Manager. Solution Manager enriches event data by including source and IP addresses for each alert written to the file. This is intended to support correlation once the data is ingested by SIEM platforms. Event data is also normalized using a standardized structure for all log sources. The fields and separators for event details within each file are customizable and include values for alert name, description, date, time, system, system type, and event details. The event details can include information such as the event ID, username, source and destination IP addresses, and objects accessed by the user such as transactions, reports, function modules or URLs.  The example below includes <DATE>::<TIME>::<SYSTEM>::<MANAGED OBJECT TYPE>::<ALERT TYPE>::<PRIORITY>::<ALERT NAME>::<ALERT DESCRIPTION>::<ALERT DETAILS>. Each value is separated by ::

Since event details are written to and stored within alerts in Solution Manager, attackers will not be able to remove all traces of their malicious actions by modifying event logs alone.  They will also need to delete alerts and stop the triggering of email/ SMS notifications of alerts in Solution Manager. This would be challenging since alerts cannot be deleted in Solution Manager. They can only be confirmed. All alerts are retained and only removed by periodic housekeeping jobs designed to delete aged alerts.

Event files can be stored on the Solution Manager host or an external host or file server. A new event file is created by Solution Manager for each day. The contents of the newest file can be periodically pushed to SIEM platforms or pulled by SIEM systems directly from relevant directories. Since there is a single point of integration for event data between SAP and SIEM systems, maintenance efforts are relatively low.

This article outlines the benefits of integrating security event data from SAP applications with SIEM platforms using the Cybersecurity Extension for Solution Manager. The benefits include lower costs, rapid deployment, ease of maintenance, and the enrichment of event data to support cross-platform correlation. The example below is for SIEM integration with Solution Manager for Splunk Enterprise. However, the approach can also be used to integrate security event data with other SIEM systems including QRadar, ArcSight and Log Rhythm.