Cybercriminals are increasingly targeting system landscapes containing SAP solutions. Not because SAP systems are particularly vulnerable — on the contrary, an up-to-date, well-configured SAP system is highly secure — but because SAP systems tend to contain valuable data that is a prime target for exploitation or corruption.
A security breach that exposes critical data has the potential to damage an organization’s business goals, personnel, assets, and reputation. This makes it extremely important to find a way to monitor all of your systems for unexpected and suspicious activities. This article introduces a solution — SAP Enterprise Threat Detection — that enables organizations to analyze threats and identify critical attacks as they are happening, so that appropriate countermeasures can be applied in time to prevent serious harm to the business.
The Changing Face of Security
Today’s business landscapes tend to be heterogeneous, with interconnected systems and increasing numbers of mobile and cloud-based applications. This diversity makes it difficult to use traditional approaches, such as perimeter security, to seal vulnerabilities in landscapes. While such measures are still essential to protecting assets from threats originating outside the organization, they are no longer sufficient on their own, and are even less so when you add internal threats such as disaffected employees, tactics such as social engineering, and an array of other potential methods of attack.
It’s easy to conclude that total protection of your landscape is impossible, and that the only realistic approach is to focus on protecting your key assets. However, an attacker need only discover and exploit one path of weakness to inflict significant damage. For example, an attacker who manages to temporarily grant himself or herself SAP_ALL authorization can perform any task across an organization’s SAP system, and potentially cause serious problems. To minimize this risk, organizations need visibility into suspect activities across the entire system landscape.
Most large organizations have measures — from firewalls to intrusion detection systems and encryption technology — in place to protect and monitor their assets. In particular, security information and event management (SIEM) solutions, which gather and analyze log information, can be a powerful tool for identifying threats. If properly combined and interpreted, system and application logs are a treasure trove of information about what has happened and is happening throughout a landscape. However, traditional SIEM solutions tend to run up against what is fundamentally a big data challenge: The amount of security-relevant data generated by systems and applications in today’s landscapes is huge and is spread across a vast number of logs. And for organizations running SAP systems, a further challenge is gaining insight into SAP business systems and, in particular, the application layer. SAP’s real-time data platform is equipped to handle these challenges.
Introducing SAP Enterprise Threat Detection
Scheduled for release in Q4 2014, SAP Enterprise Threat Detection combines the high-performance complex event processing functionality of SAP Event Stream Processor (SAP ESP) with the real-time capabilities of SAP HANA to create a powerful solution for processing and analyzing security-relevant data. It helps security administrators detect, monitor, and analyze security events to provide insight into what is happening throughout heterogeneous landscapes — including both SAP and non-SAP systems and components — by scanning log files and identifying suspicious patterns. Figure 1 provides an overview of how the solution works.
Log data is extracted and transferred from monitored systems and components to SAP Enterprise Threat Detection through a REST-based API that is exposed by SAP ESP. This API enables the integration of non-SAP systems and components. A log data extractor (shown in Figure 1) makes it particularly simple to extract log data from ABAP (7.00 or higher) systems.
The SAP ESP engine pre-processes the incoming log data to format it for SAP HANA, and then sends it to the SAP HANA database, where it is stored. Then SAP Enterprise Threat Detection runs attack detection patterns that generate alerts. An alert API enables these alerts to be consumed by external tools, such as an incident management system, to enable the tracking of problem resolution, for example.
The user interface of SAP Enterprise Threat Detection provides the tools necessary to support real-time security monitoring and ad hoc analysis, including a dashboard for viewing alerts; tools for browsing and analysis as well as creating attack detection patterns; and tools for configuring, scheduling, and monitoring attack detection patterns.
A Closer Look Inside
Let’s take a closer look at the inner workings of SAP Enterprise Threat Detection, including:
- Connecting monitored systems to SAP ESP
- Pushing log data to SAP Enterprise Threat Detection
- Ensuring a standard data format in SAP HANA
Connecting Monitored Systems to SAP ESP
To transfer log data, monitored systems must be connected to SAP ESP, which facilitates communication with SAP Enterprise Threat Detection.
Non-ABAP systems currently require some extra effort to connect to SAP ESP via the log data API. Only a few steps are required to connect ABAP systems, however:
- First, ensure that the ABAP system has the relevant package installed. This is described in SAP Note 1998675: Unified ABAP Interface for SAP Enterprise Threat Detection.
- With SAP Note 1998675 implemented, you can now specify which logs will be read in the ABAP system. The logs are listed in the table SECM_LOGS, and you can use transaction SM30 (Maintain Table Views) to set the values for SECM Log Active to “true” for the data to be sent to SAP Enterprise Threat Detection (see Figure 2). Other values, such as those relating to time span and package size, have default values, but you have the option of changing them.
- Next, you need to run two reports: one (report SECM_CONFIGURATION) to configure the connection of the ABAP system to SAP ESP, and a second (report SECM_LOG_2_ESP) to test the connection. (Later, you will schedule the second report to run as a batch job to push the log data to SAP Enterprise Threat Detection.) The inputs required to run the reports are described in the report documentation.
Pushing Log Data to SAP Enterprise Threat Detection
To push log data from monitored systems to SAP Enterprise Threat Detection, SAP ESP exposes a REST service with which any monitored system, also known as a log provider, can communicate. A monitored system sends a JSON request via the exposed REST service to push its log data.
Typically, the data push is scheduled to run in the log provider systems at frequent intervals — every minute or so, for instance — to ensure the data is up to date. In an ABAP system, the data is pushed by scheduling report SECM_LOG_2_ESP to run as a batch job; in non-ABAP systems, the functionality currently must be implemented manually.
To ease the load on both ends of the connection, SAP Enterprise Threat Detection provides a delta mechanism that automatically minimizes the amount of data that is transferred, so that only changed data is transferred with each push rather than the entire data set.
In the initial release of SAP Enterprise Threat Detection, there is no pull of data by SAP ESP. Any systems sending log data to SAP Enterprise Threat Detection must use the REST service to do so. SAP ESP then pushes the data in the correct format to the SAP HANA database.
Ensuring a Standard Data Format in SAP HANA
To allow the various types of logs to be correlated for analysis, the log entries must conform to a standard, uniform format in the SAP HANA database — a process called normalization. SAP ESP performs the normalization of the log data obtained from the log providers and then stores the normalized data in SAP HANA.
The unified database schema that holds all log events in SAP HANA is based on a data model that is generic enough to support most envisioned uses, whether from SAP or non-SAP sources. It consists of a header table and a corresponding details table (see Figure 3). The header table contains around 20 fields, and includes the most-used fields for ABAP, network, and system logs. While contributing logs will not always fill all the fields in a standard header table, each log will contain at least HeaderId (which is a binary GUID) and Timestamp values, and usually also SystemId, User, LogType, and TerminalId values.
All additional information is stored in a corresponding details table. The most interesting data in this table is usually defined in the Name fields and in the corresponding Value fields. These fields contain everything that does not fit into the other fields. Some of the other fields in the details table are the same as those in the header table — for technical reasons (such as the HeaderId, which references the corresponding field in the header table) and for convenience (such as the LogType, which helps to distinguish between multiple entries that have the same name but come from different logs). The Timestamp field is used for data analysis as well as for data partitioning and for the automatic deletion of records after a specified interval.
Once a log has been normalized, it is stored in the SAP HANA database and used by SAP Enterprise Threat Detection to deliver rapid automatic attack pattern analysis and fluid ad hoc analysis.
SAP Enterprise Threat Detection in Action
Tools based on SAP HANA allow experts to follow their intuition because of the speed at which results are returned. Let’s look at a simple example of how browsing data in SAP Enterprise Threat Detection, combined with the rapid analytics power of SAP’s real-time data platform, can lead to a clear indication of a threat.
Let’s say that a security analyst has decided to look for evidence of suspicious internal activity in a monitored landscape. If someone is trying to guess passwords, an increase in the frequency of failed logons would be expected. A standard-provided attack detection pattern exists for failed logon attempts in SAP Enterprise Threat Detection, so the analyst applies this pattern to compare the number of failed logons to the monitored systems. The analyst notices that one particular system and user is dominating the results. After quickly determining that this combination is innocuous, the analyst excludes it from the results. Now the analyst adds the terminal ID to the dimensions to be considered. Reordering the dimensions reveals that one particular terminal is responsible for many logon attempts by multiple users in a short period of time (see Figure 4). A threat has been identified and the analyst now has plenty of information to refine the investigation.
Balancing Privacy and Security
Protecting personal data is one of the most critical tasks facing organizations in the age of big data. Two tools that are commonly used for protecting personal information are pseudonymization, which allows data to be linked to a person without revealing that person’s identity, and anonymization, which erases any connection between data and a person’s identity.
Log data in productive SAP systems generally is not pseudonymized or anonymized, and this is probably true of most non-SAP components as well. With the correct authorizations in the individual systems, a system administrator can see all the personal data that is stored in those systems. However, once data is consolidated in a central management system, such as SAP Enterprise Threat Detection, where it can be easily searched and correlated, data protection considerations kick in more strongly and, in some countries such as Germany, the data must be pseudonymized so that real user IDs are not shown. Data is not anonymized by SAP Enterprise Threat Detection, because it would make the collected data useless for active threat detection or forensic analysis.
SAP Enterprise Threat Detection pseudonymizes personal data by default, so you can impose a division of responsibility between those who can access individuals’ identities and those who cannot. For example, you can specify that operators can work with the data but cannot directly deduce the identity of individuals from that data. You can allow overseers to, when required — when security guards need to intervene promptly or when legal follow-ups are required for a forensic investigation, for instance — decipher the data to discover the identity of individuals.
While solutions such as SAP Enterprise Threat Detection are powerful tools for ensuring the safety of an organization’s landscape, the solutions alone cannot prevent the abuse of their power. Privacy and trust considerations must be carefully factored into the overall processes involved in monitoring networks and systems by central IT organizations.
By combining the high-performance power of SAP Event Stream Processor with the real-time capabilities of SAP HANA, SAP Enterprise Threat Detection enables you to monitor both SAP and non-SAP systems across your landscape to identify and analyze security breaches as they are occurring, so that you can neutralize attacks before you sustain critical damage to your business.
In the future, SAP intends to add modules to SAP Enterprise Threat Detection that further facilitate the integration of SAP platforms such as SAP HANA as well as Java and cloud-based SAP systems, and to widen its support for non-SAP log providers by, for example, including support for syslog. SAP also plans to incorporate support for log archiving to enable analysis of data that extends beyond the time interval specified for deleting partitions. In addition, there is considerable potential for leveraging more of the existing capabilities of SAP HANA and SAP’s real-time data platform for security monitoring purposes.
Defending against security breaches in large landscapes is a big data problem that SAP Enterprise Threat Detection is designed to solve as security threats continue to evolve. For more information, visit www.sap.com/pc/tech/application-foundation-security/software/security-solutions-overview.html.