Beginning with Compliance Calibrator 5.1 through Risk Analysis and Remediation version 5.3, there is functionality available called Alert Monitor. This tool assists users during the remediation phase of their projects. I’ll provide a technical explanation of exactly what alerts do, discuss the appropriate use of alerts, offer preferred practices around alerts, and show you step-by-step instruction on how to configure alerts in the system.

Technical Explanation of Alerts

The alert job extracts all transactional data from SAP Workload Business Transaction Analysis (the transaction STAD database) in the SAP system. This can be a huge amount of data depending on the transaction volume your company carries out. Every company configures how long its systems retain STAD records. After the STAD data is purged from the SAP system, there is no way for RAR alerts to retrieve the data.

Alerts are at transaction code only level. Even though rules are created at permission level (authorization object), alerts are only reported at the action level. If a user executes the transaction without actually editing anything, it still reports on the alert.

Alerts do not provide information if any changes were made in the transaction; SuperUser Privilege Management does this. Any investigation of what was done while the user was in the transaction is entirely manual.

Use of Alerts

RAR generates three types of alerts:

Conflicting actions. The system generates this type of alert when someone executes two transactions that conflict based on the action segregation of duties rules defined in RAR. For example, the rule shown in Figure 1 was built in RAR Rule Architect to say that there was a conflict between transactions ME21N (create purchase order) and MIGO (goods movement). If alerts are configured, the system generates an alert any time someone executes both transactions.

Figure 1

RAR Rule Architect conflict

Critical actions. The system generates this alert when someone executes a transaction classified as a critical action in RAR Rule Architect. Figure 2 shows an example of transaction code SA39 (SA38 for Parameter Transaction) classified as critical. A critical transaction is one that poses a risk to the corporation regardless of when it’s executed. Another example is transaction code SCC4 (client configuration). With this transaction, a user can open up a client for configuration, thereby bypassing certain controls inherent in the system.

Figure 2

Critical action conflict

Control monitoring. This type of alert is based on the controls configured in the mitigation. Within the mitigation, you can set up a specific report transaction that mitigates the risk (Figure 3). This alert generates if the report is not executed by the person identified as the monitor as required in the mitigation.

Figure 3

Mitigating control definition

SAP created conflicting action and critical action alerts to assist users in prioritization during remediation. Alerts can highlight which conflicts are exploited most often so you can remediate or mitigate these conflicts first. Alerts are not meant to be a replacement for remediation and mitigation — they are meant to be a short-term solution while remediation continues. To compliantly use alerts, every single one must be investigated.

Preferred Practices Related to Alerts

The amount of data that you extract ultimately determines how often the job must run. You should only consider configuring alerts after role remediation is complete and single and composite roles are clean. Alerts help in prioritizing for user remediation, but if role remediation is not performed, the amount of data will be overwhelming.

A best practice is to run the job periodically every hour so it only extracts one hour of data. Data extraction at intervals greater than four hours might not finish, or you might experience excessive runtimes. The exact timing of the extract is specific to each company based on its STAD configuration.

Depending on the amount of transactional data in the back end, the table that holds this information might become huge. The size of this alert table affects the runtimes of the ad hoc alert reporting, which uses variables to query the tables. The larger the table, the more time it takes to run. Deleting alerts directly from the table is the only way to reduce the size of this table. See SAP Notes 1050750 and 1178370 for additional help in managing table sizes.

Ultimately, you should not use conflicting action or critical action alerts on an ongoing basis — they are meant to assist in prioritization during remediation. If the company’s use case is to be notified when a critical transaction is used, you should use SuperUser Privilege Management. This provides immediate notification of the use of the transaction and shows the details of what happened in the transaction (as long as it’s recorded in the CDHDR table).

Configure Alerts

First, you should bring GRC Access Control to the highest Support Package level prior to using alerts. The Support Package fixes are documented in SAP Notes 1017964, 1022187, and 1168120.

The user guides contain detailed information on how to configure. You can find links to user guide documentation in SAP Note 1243085. You can see more helpful SAP Notes in Table 1.

To configure alerts, create a file named Alert_Log.txt on the application server on which RAR is running. Within RAR, follow menu path Configuration>Miscellaneous. Enter the full path and file name of where this text file is stored (Figure 4).

Figure 4

Enter the path where you store the file

Prior to the first running of the alert job, the database administrator should manually adjust the Alert Last Run date in the table. If this date is not adjusted, the job attempts to extract from the beginning of time and will probably error out. The database administrator can use the scripts shown in Figure 5 to make these updates.

Figure 5

Scripts for the database administrator

In these scripts, replace VSYSKEY with the system in place of 'DEV', LASTRDATE with the current date, and LASTRTIME with the current time. If this insert statement fails in the database, you might have to use the right schema and modify the script to specify ..

After the script is updated, restart the J2EE server on which RAR runs. Then schedule the job that extracts the data from STAD and populates the RAR tables. You should tailor this job as much as possible to restrict the amount of data needed.

It’s important that you select a specific system, especially if multiple connectors exist. If you want alerts for multiple systems, you should run multiple alert generation jobs. You should also limit which risk IDs you care about. If you run with *, the job takes much longer to generate the alerts. In the example in Figure 6, the job is tailored to only generate alerts. The options in the Alert Notification section are not checked. If you check any of the Alert Notification fields, the system sends out emails for the type of alert notification selected based on the configuration of the risk owners and mitigation control monitors. These emails could be overwhelming, so investigate whether you want the emails to go out. With the job scheduled as is, you can run ad hoc reports on the alert data via the Alert Monitor tab, but the system does not send out any emails.

Figure 6

The system only generates alerts

It is key that you have a set process in place prior to setting up alerts, especially if you’re going to use emails. This process depends on the company’s control environment, but it’s vital that people receiving an alert notification know what is expected of them.

Figure 7 shows an example of an ad hoc conflicting action alert report. The various icons are explained in detail in the user guide. In addition, the user guide provides instructions on how you should clear the alerts to document the use.

Figure 7

Ad hoc confliction action alert report

Jayne Gibbon

Jayne Gibbon, CPA, has been implementing SAP applications since 1996 and is currently a director in the Chief Customer Office at SAP. Jayne’s focus is making customers successful with their SAP HANA deployments. She has helped more than 100 customers drive business value with SAP HANA. Prior to joining SAP in 2007, Jayne worked for two multinational manufacturing companies based in Wisconsin. While an SAP customer, Jayne led the very first implementation of Virsa’s Compliance Calibrator, which is now part of SAP Access Control. Jayne’s experience includes internal audit; computer security; governance, risk, and compliance; SAP HANA; and SAP analytics.

You may contact the author at jayne.gibbon@sap.com.

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