Download the new whitepaper for SAP-SIEM integration from Layer Seven Security. The whitepaper outlines recommended settings for the Security Audit Log, HANA audit log, and other logs to support advanced threat detection. It discusses the challenges of direct integration of SAP logs with SIEM systems in terms of complexity, log volume, maintenance, and event correlation.
The whitepaper advocates SIEM integration using SAP Solution Manager based on benefits such as lower complexity, rapid deployment, reduced costs, ease of maintenance, and the enrichment of event data to support cross-platform correlation.
The SIEM Integrator for SAP is a software add-on for SAP Solution Manager that delivers automated threat detection for SAP systems. The add-on supports integration with SIEM platforms including Splunk, QRadar, ArcSight, LogRhythm and SolarWinds. The Integrator includes 300+ attack detection patterns for SAP platforms and logs.
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.
According to the findings of a recent independent survey of 430 IT decision makers, 64 percent of ERP deployments have experienced security breaches in the past 24 months. The findings are published in the report ERP Security: The Reality of Business Application Protection. In the words of the IDC, “ERP applications such as SAP can be foundational for businesses. A breach of such critical ERP applications can lead to unexpected downtime, increased compliance risk, diminished brand confidence and project delays…..Cyber miscreants seem to be indiscriminate when it comes to ERP systems, having an appetite for all types of data, which, if in the wrong hands, could be detrimental to the business in terms of revenue and reputation.”
The survey revealed that of the 64% of organizations that reported security breaches in ERP systems, the majority included the compromise of sensitive data including sales data in 50% of cases, as well as HR data (45%), customer data (41%), financial data (34%) and intellectual property (36%).
The survey also revealed the following:
The estimated cost of downtimes in ERP
applications is $50,000 or more per hour at almost two thirds of organizations
62% of ERP systems may have critical vulnerabilities
74% of ERP applications are accessible from the Internet
56% of executives are concerned or very concerned about moving ERP applications to the cloud
According to the former Chairman of the Global Board of the Institute of Internal Auditors (IIA), “The findings of this independent survey should raise questions at the Board level about the adequacy of internal controls to prevent cyber attacks and the level of auditing taking place. The lack of these controls is one way for cyber insurance companies to deny claims….The information compromised most often according to this research is the highest regulated in today’s business ecosystem. Most concerning is the popularity of sales, financial data and PII, all of which should raise flags about the possibility of insider trading, collusion and fraud.”
SAP ERP installations can be protected against cyber attack using the Cybersecurity Extension for SAP Solution Manager. The extension implements automated vulnerability and patch management, and security incident detection and response for SAP systems, without requiring additional hardware or agents.
Vulnerability assessment and penetration testing both serve important functions for protecting business applications against security threats. The approaches are complementary but should be deployed sequentially. Penetration testing against systems and applications that have not been hardened based on the results of vulnerability assessments is inadvisable since the results are predictable. The objective of penetration testing is to assess the strength of security defenses, not to exploit ill-equipped and unprepared systems and processes to prove a point.
Therefore, vulnerability assessments should be performed ahead
of penetration tests. The results of comprehensive vulnerability scans inform organizations
of configuration, program, user and other weaknesses that could be exploited to
compromise systems during real or simulated attacks. The recommendations resulting
from the assessments enable organizations to remediate security weaknesses
using a prioritized approach. It also supports the implementation of counter
measures to detect and respond to potential attacks.
Once systems are hardened and defenses are prepared, performing
a penetration test is a valuable exercise to test the adequacy of security mechanisms.
The lessons learned from the discovery and exploitation of vulnerabilities during
penetration tests can be applied to address areas that may have been overlooked
or inadequately secured after vulnerability assessments. Penetration testing
against hardened systems that are actively monitored for attacks forces pen
testers to exercise more complex and difficult attack vectors. It also compels
pen testers to deploy evasive techniques to avoid detection. This improves the
quality of penetration tests and the reliability of the results, providing a stronger
litmus test for system security, threat detection and incident response.
There are several apps available in SAP Solution Manager for monitoring security alerts for SAP systems. The most longstanding is the Alert Inbox which provides an overview of alerts by process area. Guided procedures for investigating security alerts are executed from the Alert Inbox. Another option is System Monitoring which provides a more user-friendly interface for navigating incidents than the Alert Inbox. System Monitoring includes the Alert Ticker displayed in the right pane of the app for monitoring incidents in real-time.
SAP Solution Manager 7.2 SP07 introduced a third option for monitoring
alerts called Monitor Systems. The app is delivered in the new work center
Application Operations.
System Monitoring and the Alert Inbox are Web Dynpro applications. Monitor Systems, however, is a SAPUI5 application based on the Fiori framework. Therefore, Monitor Systems delivers exceptional performance with alerts loading and refreshing at much faster rates than both the Alert Inbox and System Monitoring. The performance gains are considerable even for SAP Solution Manager installations running on conventional databases rather than SAP HANA.
You can access Monitor Systems from the SAP Fiori Launchpad using the roles SAP_STUI_APPOPS_AUTH and SAP_STUI_APPOPS_TCR.
The initial screen summarizes alerts open alerts by systems and components.
Results can be filtered or sorted by clicking by system and category.
Systems can also be labeled as favorites for fast selection.
You can view details of open alerts for each system by clicking on the system. Below are alerts for security configuration issues impacting system AS2.
Below are security exceptions detected through real-time monitoring of event logs in the system.
We can drill down into the details of each alert by clicking on Critical Metrics. For example, we can investigate the alert below for the Actions by the Standard SAP* User Alert by reviewing the relevant metric.
The Metric Details reveals that there was an attempted logon with the SAP* user from IP address 10.8.91.2 at 12:51 on 2019-08-14. We can execute a guided procedure that will investigate other actions from the source IP directly in the Security Audit Log.
The results can be shared with security operations teams through email by clicking on the Notify option in the Metric Details.
In another example, we can drill down into the alert for active users logged into the system with SAP_ALL in their user buffer to investigate potential privilege escalation. The profile should not be used in productive systems.
The Cybersecurity Extension for SAP Solution Manager monitors SAP event logs to automatically detect and alert for indicators of compromise. The monitoring interval can be customized for each security metric based on risk and sizing. An interval of 60 seconds, for example, can support real-time threat detection. However, real-time detection is only useful when supported by real-time incident response. Organizations that lack rapid response capabilities should opt for collection intervals of 10-15 minutes to balance the need to minimize the mean to detect (MTTD) with the system impact of continuous monitoring.
Log settings also need to be carefully maintained to capture
security-relevant events while preventing the accumulation of log data and the consumption
of excessive disk or table space. The recommended settings and archiving
procedures below for each log area will enable you to maintain comprehensive
forensic logs with minimal system impact.
Security Audit Log Maintain static filters to log all actions by the standard SAP* user, logons and transaction starts by the DDIC user, and Severe and Critical events for all audit classes and users. Also create a static filter to log the non-critical event IDs BU4, CUY, DU9, DUI, and FU1. The filters should be applied to all clients. If you have yet to remove the EarlyWatch client, also create a filter to monitor events for all audit classes and users in client 066.
Periodically export events older than 30 days using
transaction SM20. Once the events are successfully exported and backed-up to a
file server, trigger the background job RSAUPURG to delete events older than 30
days using transaction SM18.
Read Access Log Configure or import logging purposes to log access to sensitive fields and tables including user tables. Archive SRAL objects using transaction SARA. RAL archives can exported and stored offline.
Change Documents Change documents for user changes are triggered automatically. Similar to the Read Access Log, change documents are archived using transaction SARA.
Business Transaction Log There are no specific settings required for STAD. Since data is retained for only 48 hours, STAD archiving is also not required.
System Log Similarly, the system log does not require any specific settings or archiving. The system log is a ring buffer. When the log file reaches its maximum size, the system overwrites the oldest data.
HTTP Log The LOGFORMAT option for HTTP logging should specify a format that includes the URL in log entries. An example is the CLF format. HTTP log files in the /usr/sap/SID/instance/work directory can be exported and archived offline.
Gateway Server The ACTION option for gateway logging should include the actions SsZMP to capture security events, configuration changes, and monitor commands. Gateway log files are can also be found in the work directory of each instance and archived to an external location.
Java Security Log The value of the following properties should be set to TRUE to include the client host address, object name and actor in logged events: ume.logon.security_policy.log_client_hostaddress, ume.secaudit.get_object_name, and ume.secaudit.log_actor. Automatic archiving should be activated using the Log Manager. Once activated, the compressed archives can be found in usr\sap\<SID>\JC<Instance number>\j2ee\cluster\<Dispatcher or server>\log\archive.
HANA Audit Log The target audit trails should be set to CSTABLE and SYSLOGPROTOCOL to log events simultaneously to internal tables and the OS-level system log. Audit policies should be configured to log critical actions including all actions performed by the SYSTEM user, system changes, user changes, role changes, repository changes, and unsuccessful logons.
The contents of the AUDIT_LOG table can be exported using the AUDIT OPERATOR privilege in the HANA Studio. Once exported, navigate to the Auditing tab in the Security section and select the option to truncate the audit trail.
For detailed step-by-step instructions, refer to the section on Log Settings and Maintenance in the user manual for the Cybersecurity Extension for SAP Solution Manager.
Watch the playback of this month’s webinar to learn how you can implement holistic cybersecurity for your SAP systems with Code Vulnerability Analyzer and Solution Manager.
CVA performs static code analysis to detect vulnerabilities in custom code. SAP Solution Manager detects vulnerabilities and threats in SAP systems including components such as the gateway server, message server and SAProuter, targeted by the recent 10KBLAZE exploits.
Together, CVA and Solution Manager provide an integrated platform to secure custom code and SAP systems against cyber threats.
On May 2, the Department of Homeland Security issued an alert for SAP customers in response to the disclosure of new exploits targeting vulnerable SAP components. According to some reports, the so-called 10KBLAZE exploits could impact 90% of SAP installations worldwide. The exploits target misconfigurations in the gateway server and message server installed in most SAP systems including S/4HANA, ERP and CRM. The successful execution of the exploits could enable attackers to exfiltrate or modify data and provoke a denial of service without authentication. In other words, attackers can completely compromise target SAP systems without any user credentials.
The new exploits target known vulnerabilities addressed by notes and advisories released by SAP since 2005. Note 821875 details measures to secure the message server, including restricting external access, separating internal and external communications, and maintaining secure access control lists. The profile parameter ms/monitor should be set to 0 to prevent external programs such as msmon from administering the message server at the operating system level. Access to transaction SMMS should also be restricted since the setting can be changed dynamically using the Message Server Monitor within the application server. A separate port for internal communication between application servers should be defined using parameter rdisp/msserv_internal. This will prevent external clients from intercepting or rerouting internal message server communications. The port should not be exposed to clients or intranets. Finally, the parameter ms/acl_info should specify the file containing a restrictive access control list of hosts, domains, IP addresses or subnets for application servers permitted to log on with the message server.
ACLs should also be defined for the gateway server to control access to starting external programs. This can be performed using the gateway security file sec_info. The correct syntax for the file depends on the kernel level. For kernel 7.20 and higher, the setting USER-HOST=LOCAL is recommended to protect against 10KBLAZE exploits. This will allow connections from the same server instance. The setting USER-HOST=INTERNAL could be vulnerable but is required for SID clusters. For detailed guidance, refer to Note 1408081. The ACLs should be supported by the setting gw/acl_mode to 1. This parameter defines the behavior of the gateway server if sec_info does not exist.
Since some 10KBLAZE exploits are targeted at modifying or redirecting data packets, enabling SNC to authenticate and encrypt client-server communications is recommended.
SAP systems vulnerable to 10KBLAZE exploits can be discovered using SAP Solution Manager. The Cybersecurity Extension for SAP Solution Manager automatically monitors security settings for the message server and gateway server including profile parameter settings, access control lists and users with critical transactions such as SMMS. The extension also monitors message and gateway logs for external monitor commands, successful and unsuccessful program starts, and other events. Alerts are triggered by the extension for suspected exploits.
The example below illustrates how you can discover insecure sec_info entries that could expose systems to 10KBLAZE exploits.
Click on Vulnerability Report in the Fiori Launchpad.
Filter by ABAP systems, select the check-box for the target system and click on Display.
Filter for vulnerabilities in open status within the area of RFC Security. Click on the check for starting of external programs.
Review the details and recommendation. Click on the linked SAP Notes and SAP Help.
Click on Additional Information to review the insecure entries in the sec_info ACL.
Focus on entries with the setting USER-HOST=internal.
Click on the download icon to export the current settings.
If required, add comments in the Comment section.
The finding for the system will be automatically removed from the report once the sec_info entries are updated. However, you can manually change the status using the Change Status option. Note that status changes are tracked in the extension.
You can also assign responsibility for remediating the finding to specific groups using the Change Owner option.
According to a recent report, thousands of SAP installations may be vulnerable to 10KBLAZE exploits targeting SAP applications.
Join SAP and Layer Seven Security to learn how to secure your SAP systems against the exploits with SAP Code Vulnerability Analyzer (CVA) and SAP Solution Manager. CVA performs static code analysis to detect vulnerabilities in custom code. SAP Solution Manager detects vulnerabilities and threats in SAP systems including components such as the gateway server, message server and SAProuter, targeted by 10KBLAZE.
Together, CVA and Solution Manager provide an integrated platform to secure your business-critical SAP systems against 10KBLAZE and other exploits.
The misuse of administrative privileges is a common method used by attackers to compromise applications and propagate attacks to connected systems. The elevated privileges granted to administrative accounts are a prized target for attackers and provide a fast path to accessing or modifying sensitive data, programs and system settings.
User privileges for Java applications are administered through the User Management Engine (UME) in the SAP NetWeaver Application Server for Java (AS Java). The UME is the default user store for AS Java and can be configured to use LDAP directories, AS ABAP, or the system database of AS Java as the data source for user-related data.
UME permissions granted to users can include administrative actions such as Manage_All, Manage_Roles, Manage_Users, Manage_User_Passwords, and other privileged functions. Administrative actions are bundled into roles and granted to users organized into user groups. Standard user groups include the Administrator group, as well as groups such as SAP_J2EE_ADMIN and SAP_SLD_ADMINISTRATOR. The latter includes users with administrative access to the System Landscape Directory. Standard roles include Super Admin and, for Enterprise Portals running on AS Java, Portal System Admin, Portal User Admin and Portal Content Admin.
Access to administrative roles and rights in AS Java should be granted to required users only, based on the principle of least privilege. Users with administrative privileges in AS Java systems can be detected using the Cybersecurity Extension for SAP Solution Manager. The results are displayed in security reports and dashboards. Alerts are also triggered by the extension for new users granted privileged roles and actions for possible privilege escalations. The extension also detects users with administrative rights in ABAP and HANA platforms, as well as SAP-compatible databases including IBM, Microsoft, Oracle and Sybase.