I Know What You Read Last Summer: How SAP Read Access Logging Can Help Identify Data Theft
When people think about data theft, the occurrence of large data breaches and attackers extracting millions of sensitive records often comes to mind. What many don’t realize is, that regardless of the scope or size of data extraction, it often takes several months to realize that data has been compromised. In fact, many data breaches are not detected by the compromised company, but by third-party organizations reporting unusual activities, such as credit card processors.
Since it is difficult to detect large-scale data breaches with millions of records, it is even more challenging for organizations to detect the siphoning of their critical data on a smaller scale. Business-critical applications like SAP contain sensitive data that is responsible for the day-to-day operations of a business. Since it is used by more than 400,000 organizations, 77% of the world’s transactional revenue touches an SAP system. Considering the widespread use of SAP, and threat actors’ growing knowledge of these business-critical applications, organizations should prioritize protecting these applications with the utmost urgency. SAP systems are also interconnected with other internal and external application systems, and subsystems, via a large number of different interfaces and technologies. For this reason, all data channels and UI infrastructures must be considered in order to completely monitor access to all sensitive data.
SAP Read Access Logging (RAL)
Protecting critical data from this interconnected risk was SAP’s main motivation for introducing Read Access Logging (RAL). Its purpose was to enable customers to comply with legal regulations in banking or healthcare applications. Data privacy is mainly about protecting and restricting access to personal data. However, in some countries, data privacy regulations like GDPR require that access to certain personal data is reported. Companies and public institutions can use the capabilities of the RAL infrastructure to track access to any classified or sensitive data and thus identify the person(s) responsible for any public data leaks.
The RAL was initially released by SAP with SAP NetWeaver 7.40. Additional support packages for earlier NetWeaver versions, down to 7.01, were subsequently released to provide the same range of functionality as in version 7.40.
The support packages for versions prior to 7.40 did not introduce more functionality than what SAP provided with 7.40. Each of the SAP support packages for versions prior to 7.40 introduced parts of the 7.40 functionality into those earlier releases until they provided the same range of functionality as 7.40.
Starting with SAP NetWeaver 7.01 SP15, the following channels are supported:
- RFC Channel
- Web Service Channel
- Web Dynpro Channel
- Dynpro Channel
This list was successively extended in higher SAP NetWeaver versions with the following:
- SAP Gateway (OData v.2.0 and OData v. 4.0)
- ALE/IDoc Communication
Supported are the following default IDoc outbound protocols:- tRFC 3.0/3.1,4.x
- qRFC
- File, XML file
- http, SOAP
- SAP BW
Data accessed via- Query requests
- Query results or outputs
- Value help
- Master data maintenance data
- Data preview of InfoProviders
- KPro
- Logging can be activated based on PHIO classes
- Output Forms (DDIC Interface)
- Logging can be configured for the name of the Output Form as well as for its fields
- Electronic Documents
- Administrative eDocument data
- Administrative eDocument file data
- eDocument type-specific fields
- eDocument file content data:
- Geographical Enablement Framework(GEF)
How To Configure the Read Access Logging (RAL)
Manual Configuration
The configuration of RAL is done via transactions SRALMANAGER or SRALCONFIG and consists of multiple steps. The authorization for every individual step is checked against a separate authorization object.
Step 1: Create a Logging Purpose
Relevant authorization object: S_RAL_PURP
Logging Purposes group the logged events by use case and reason for recording, e.g.
- Financial Audit for logging various types of access to bank account details
- Data Privacy for logging access to personal data, such as religious affiliation
The Logging Purpose can be used as a filter criteria for archiving rules or reportings.
Step 2: Create a Log Domain
Relevant authorization object: S_RAL_LDOM
Log Domains define the semantic meaning of the data values that will be captured during the log recording, so an auditor can understand the recorded data when viewing the log results.
Example:
A financial account is often present in more than one user interface (UI), web service, or other interface and may be referenced by:
- An internal or external ID
- A text
- An integer
- Different formats
Step 3: Create and start a Recording (only for Dynpro and Web Dynpro Channel)
Relevant authorization object: S_RAL_REC
A recording is required to collect the Dynpro or Web Dynpro fields that are of interest for logging.
Step 4: Create a Configuration
Relevant authorization object: S_RAL_CFG
While the general architecture of RAL follows a generic approach, the configurations are generally channel specific. The main tasks to setup a configuration are as follows:
- Select the fields to log
- Specify if field values should be logged, too
- Assign log domains to the fields
- Assign conditions (optional)
Step 5: Maintain User Exclusion List (optional)
Relevant authorization object: S_RAL_BLKL
Specific users such as technical users who run expected, scheduled background jobs can be excluded.
Step 6: Enable Read Access Logging in Client
Relevant authorization object: S_RAL_CLIS
RAL must be enabled for each client separately.
Important: Configurations for the RFC channel require profile parameter
sec/ral_enabled_for_rfc
to be set to 1. Otherwise, there is no logging for the RFC channel.
SAP ships template roles for RAL. The roles SAP_BC_RAL_ADMIN_BIZ and SAP_BC_RAL_CONFIGURATOR contain all authorizations that are needed for the above configuration steps.
Applying Predefined Content
SAP provides more and more predefined content for each application. The collective SAP note #2347271 lists all notes containing preconfigured RAL content that is not shipped via support packages. In order to avoid conflicts with customer defined content in a customizing client, SAP content is always imported into client 000. Transaction SRALMANAGER provides export and import capabilities which are able to visualize existing conflicts before new entries are transferred into the customizing client. If automatic recording of customizing changes is enabled in the customizing client, all transferred entries are recorded in a transport request which can be used to ship the content to further systems. More details about the process can be found here.
Evaluation of the Read Access Log
The logged read access events can be analyzed with transactions SRALMANAGER or SRALMONITOR. Before applying any filter criteria for the log entries, a user has to select the database, he or she is interested in.
- Raw Database
- Contains the most recent data
- Is optimized for fast write access
- Only contains log entries of the current system and client
- Does not provide information about the logging purpose and about field values
- Expanded Database
- Contains data that was replicated from the Raw Database using program SRAL_REPLICATION => does usually not contain the most recent logged events
- Is optimized for queries
- Can contain log entries of multiple systems and clients
- Includes information about the logging purpose and about field values (assuming at least some configurations have been defined to log field values, too).
- Raw Archive
- Archive of the Raw Database
The Raw Database can be archived in transaction SARA via archiving object SRAL
- Archive of the Raw Database
- Expanded Archive
- Archive of the Expanded Database
The Expanded Database can be archived in transaction SARA via archiving object SRAL_EXP
- Archive of the Expanded Database
- Raw Archive with Index
- Indexed archive of the Raw database
SAP delivers the information structure SAP_SRAL for the RAL archive. This structure contains the following four fields according to which a RAL Admin can index log entries:- Created At
- Logging Purpose ID
- User Name
- Software Component
- Much faster searches possible
- Requires much more database space
- Indexed archive of the Raw database
How Can RAL Data Be Used to Identify Data Theft?
Let’s take a look at a couple of different situations where we can use RAL data to determine if data theft has actually occurred.
Example 1: A data theft was reported, and you already know which data is affected.
In this case, you can search for all access to this data in the past to get more details about who extracted the data and via which channel.
Example 2: Detection of a data theft in real time.
In this case, you have to constantly monitor and analyze the RAL events. In an ideal scenario, the RAL data is collected centrally in Security Information and Event Management (SIEM) software and subsequently checked for anomalies. Typical anomalies could be:
- A user accesses data that he/she usually doesn’t access
- Data is read via a different channel than usual
- Data is read outside of business hours
- The number of RAL events has increased noticeably in a certain time interval
Conclusion
With the Read Access Logging (RAL) infrastructure, SAP provides a powerful and reliable framework helping customers manage legal and other compliance regulations. It also helps to satisfy any audit requirement. Last but not least, it is an indispensable tool for detecting and analyzing fraud or data theft. The preconfigured RAL content, available in the SAP Help Portal, is a great starting point and minimizes your team’s configuration efforts.