The need to protect the privacy of sensitive data—usually defined as data that is of a personal nature that can be used by hackers for malicious intent—has become a major challenge and therefore a major responsibility of any organization that handles data. Almost every company in the world, regardless of its size, handles some data of a personal nature. Today, in an increasingly online world, this data is vulnerable. This is aptly manifested in the serious breaches that have occurred in both the private and public sectors. These breaches have compromised the personal information of millions and resulted in significant monetary losses, not to mention intangibles such as loss of reputation.

SAP introduced Read Access Logging in NetWeaver 7.4 to track and audit activities within an SAP system and take rapid corrective action in case any changes to sensitive data are detected. The initial release (part of Support Pack 0) had limited functionality. With the release of Support Pack 4, Read Access Logging became a comprehensive user access and activity monitoring tool with monitoring capabilities on multiple channels. If your SAP system is on SAP NetWeaver 7.31 Support Pack 9, you can fully leverage Read Access Logging because this Support Pack is the equivalent of version 7.4 Support Pack 4.

From a security and audit standpoint, Read Access Logging helps answer the following questions:

• Who accessed a particular piece of data?
• What was this particular piece or segment of data that was accessed?
• When did this person access this particular piece of data?
• In what manner was this data accessed? In other words, through what channel was this data accessed?

A Business Scenario and Need

Consider a scenario in which ABCx is a large packaged foods company. In the last audit, an unusually high frequency of changes to accounting invoices (primarily in changes to payment terms) was detected for a couple of company codes and during a few fiscal periods. These frequent changes became a concern for ABCx because a change of payment terms directly affects either your payables or receivables. First, despite running an investigation, ABCx could not find the root cause for these changes. Second, ABCx was not monitoring these transactions in a way that such changes could be tracked and audited. Note, however, that ABCx does not use SAP’s GRC module, nor does it use any other non-SAP GRC application. Therefore, areas such as governance and segregation of duties are known areas of weakness.

To better meet audit requirements, to establish a systematic approach to tracking accounting invoices changes, and thus to be able take immediate follow-on action as needed, ABCx decided to use Read Access Logging.

Configuring Read Access Logging

To configure Read Access Logging, run transaction code SRALMANAGER. This action opens a new browser session (Figure 1). (Note that unlike conventional SAP applications, Read Access Logging was designed as a web-based application, and all the configuration activities need to be carried out in this web-based application.)

Figure 1

The initial (partial) login screen for Read Access Logging

After you successfully log in, the system displays the list of Read Access Logging configuration activities (Figure 2).

Figure 2

Administration and configuration activities in Read Access Logging

I now explain each of the administration and configuration activities.

Enabling Read Access Logging

Although this activity shows up as the last activity in Figure 2, I strongly recommend carrying it out at the very beginning. It is disabled by default. It is easy to understand why that is the case. Any kind of logging activity on an application or system adds overhead and comes with a performance trade-off. Read Access Logging is no different in this regard. You need to be cognizant of this fact, and therefore, be judicious in the breadth and depth of logging activities that you want to carry out in your SAP NetWeaver 7.4 system.

Click the Enabling in Client hyperlink to display the screen in which you either enable or disable read access (Figure 3). After you select the Enable Read Access Logging in Client check box, click the Save button to save the setting.

Figure 3

Enabling SAP client for Read Access Logging

Logging Purposes

It is good practice (although not mandatory) to put some meaningful information around what you are logging and why. This data serves as an identifier that helps you search for, assign, and report on logging-related activities. When you click the Logging Purposes hyperlink (Figure 2), the system displays the screen shown in Figure 4.

Figure 4

Creating a logging purpose

After you populate the fields shown in Figure 4, click the Apply button to create the logging purpose.

Log Domains

In this activity, you create categories of logs that you then assign to each field that you plan to monitor. After the logging is started, the logs help the reviewer or auditor understand the category of the error. They also help in searching and reporting. To create log domains in Read Access Logging, click the Log Domains hyperlink (Figure 2) and then in the next screen (not shown) click the Create button. This action displays a screen that shows the appropriate values that you entered for this scenario (Figure 5).

Figure 5

Create a log domain

Click the Create button to create the log domain.

Recordings

You need to click the Recordings hyperlink from the home page (Figure 2) to display the Create Recording screen (Figure 6) in which you identify what you are recording. There are three fields in this screen that you should fill. The Channel (with values of Dynpro and Web Dynpro), the Recording (in which you enter a meaningful identifier for your recording), and a suitable description in the Description field. The first two fields are mandatory. Figure 6 displays this activity along with the values to enter for my example.

Figure 6

Creating a recording

Click the Create button to create your recording. Upon creation, an entry is created in the recording table, and a recording is created by default (as shown by the Stop symbol). At this time, keep the recording on. This is shown in Figure 7.

Figure 7

Start tracking of changes to the payment term field

Activate Read Access Logging for Relevant Fields in the ERP System

You now have to turn on logging for the individual fields in your ERP system that you want to track and monitor. In this case you are tracking the payment term field in accounting invoice documents. Run transaction code FB03 or follow menu path SAP Menu > Accounting > Financial Accounting > General Ledger > Document Display. Figure 8 shows the display document screen with the appropriate values filled in.

Figure 8

Accounting document selection criteria

After pressing the Enter key on your keyboard, you see the document details in the screen shown in Figure 9.

Figure 9

Accounting document display

In this screen, you need to toggle from display to change by clicking the toggle_display_change icon (circled in Figure 9). Navigate to the customer line item details by double-clicking the first line item. (I have hidden the customer description). This action takes you to the customer line item screen. With your cursor on the Payt Terms (payment terms) field, press the Ctrl key and right-click simultaneously to bring up the content menu for this field (Figure 10). (In Figure 10, the Payt Terms field is hidden behind the context menu.)

Figure 10

Enabling Read Access Logging for the payment term field

Because you configured the Read Access Logging functionality for this transaction, you notice at the bottom of the context menu the option to turn on or off Read Access Logging tracking for each field. Click Record Field to start the tracking. A system message is then displayed confirming that the payment term field has been added to the Read Access Logging tracking. When you do this, the Read Access Logging application connects the main SAP program (SAPMF05L in this case) and the field you are recording/tracking (the payment term field in this case) to the recording (REC_FB03 in this case). Turn off the recording when you do not need to track the field. Now when you switch to the Read Access Logging recording screen in Figure 7 and click the display icon  next to the technical name of the recording, you see the details of this field (technical name: ZTERM) that have been added as well as other technical details.

Configuration

In this step, you identify what you are actually logging. The difference between this step and the previous one is that in this step you identify what fields within a particular transaction (that you have specified in the Recordings step) you want logged. I now walk you through the five activities you need to complete in this step.

Create the Configuration from the Channel

This activity binds the channel to the SAP program. You need to select channel type Dynpro, assign the SAP program name (from the previous step), and also provide meaningful attributes such as an appropriate software component name as well as a description. This is shown in Figure 11.

Figure 11

The configuration maintenance screen

Create the Log Context

The first sub-step is to create a log context. Click the create icon in the Log Context section of Figure 11. This action displays a pop-up window in which you provide an appropriate technical name and a description of the log context. Click the Create button to create the log context (Figure 12).

Figure 12

Log context creation

Bind the Tracked Field into the Log Context

After you create the log context, you need to drag and drop the payment terms field into the log context. You need to do some searching for this field. You find it under the Main Program node shown in Figure 13. Drag and drop Payt Terms (BSEG_ZTERM) to the Field column under Details of Log Context. The Field Direction field is defaulted to Output. I recommend changing this field to Both because you are interested in monitoring changes made to the payment term both internally and externally.

Figure 13

Assign the field to be tracked

Create Log Group

In this step, you need to create a log group. In the Log Groups section, click the create icon. This action opens a pop-up screen in which you provide a technical name, a purpose, and (optionally) a meaningful description for your log group (Figure 14). After you enter this information, click the Create button to create the group.

Figure 14

Create a log group

Bind the Tracked Field to the Log Group

After you create the log group, the system displays a details panel (Figure 15). Select the Without Condition check box because this field will be tracked without any conditions being attached. Deselect the Exclude if Initial check box. The audit trail for this field requires all changes to the payment terms be tracked even if it is initially blank. Now you need to drag and drop Payt Terms (BSEG_ZERM) from the Field list into the Field column of Details of Log Group. This action is shown in Figure 15.

Figure 15

Assign the payment term field to the log group

The final step is to save all your configurations as active by clicking the Save as Active button at the top of this screen (refer back to Figure 12).

Monitoring Changes to Payment Terms in the Financial Document

Finally, you are ready to monitor (and later audit) changes made to the payment term in the financial document that you created for this purpose. A quick recap: For my example, you created a customer invoice with a payment term of 0002. You now are going to change it to 0001 and save the changes. To monitor and audit this change, switch to the Monitor tab in the Read Access Logging home page (Figure 16).

Figure 16

Navigate to the Read Access Logging monitor

After you click the Read Access Log hyperlink and then the Monitor tab, the system displays the change log. In the search screen, after you enter one or more of the search terms, such as user, created at, channel, client, or logging purpose, the log of activities that took place relevant to changes to the payment term field for this document are displayed. Note that a smart way to do a targeted search is by using search criteria such as a log domain name or logging status because these are created by you primarily to aid in the search of access logs.

A partial view of this screen is shown in Figure 17. Note that I have erased certain sensitive field values, including IP addresses and user IDs.

Figure 17

Read Access Logging monitor with log information on payment term field changes

All the necessary information from an audit perspective is available to you in the extended mode, including a detailed time stamp with a very high degree of precision, user name, and the IP address from which this change was made. You are now prepared to provide your auditors with a detailed audit trail of this change in your payment terms. This trail also helps your organization take follow-on actions if there is a suspicion or evidence of questionable activities. So what did ABCx find out and how did it benefit from Read Access Logging? Here is a brief list of the benefits that ABCx reaped from using Read Access Logging:

• ABCx found that violations were limited to a handful of individuals. Significantly, all these individuals had privileges in the accounting document transactions that they should not have had.
• ABCx took the necessary disciplinary action against these individuals.
• Once ABCx started deploying this Read Access Logging in a widespread manner, the security and audit personnel were able to track deviations and violations in payment terms to customer invoices in real time and were also able to take prompt corrective action.
• Read Access Logging has started acting as a powerful deterrent to potential fraudsters within ABCx because with such an established audit trail it will be nearly impossible for them to be successful.
• With the increased compliance, ABCx expects to pass its upcoming audit in this particular area.

Read Access Logging provides a highly configurable interface for tracking user activity on transaction data at a most granular level. The information the Read Access Logging log provides not only helps you answer audit-related questions around user access but also helps your organization keep a close watch on such activities.

Anurag Barua

Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.

You may contact the author at Anurag.barua@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.