Ansicht
Dokumentation
/VIRSA/ALERTGEN - Activity Monitoring
SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up General Data in Customer MasterThis documentation is copyright by SAP AG.
Title
Purpose
To monitor the transactions executed by users throughout the organization on a regular and incremental basis and identify and alert in the following 3 situations:
1) Conflicting transactions: Compliance Calibrator maintains a list of conflicting transaction combinations that should not be executed by the same user/role. These combinations of conflicting transactions are maintained to prevent users from executing transactions that lead to security and controls violations (Example).
2) Critical transactions: Compliance Calibrator also maintains a list of transactions (termed "critical transactions"), which when executed by any user raise alerts (Example).
3) Mitigation alerts: Compliance maintains a list of transactions that need to be executed by certain specified users, at specified time intervals. If such a transaction is not executed by the specified user at the specified time interval, an alert is raised. Such transactions are categorized under mitigation alerts (Example).
The functionalities in Alert Monitor build on the above framework provided in Compliance Calibrator.
Alert Monitor Objectives:
The Alert Monitor alerts unauthorized access to transactions and security breaches, by providing the following functionalities:
1. Log of executed transactions: Build a mechanism to retrieve an incremental log of all the transactions (included in the three alert types above) that are executed by users.
2. Filtering of transaction log: Provide an interface to filter transactions included in the log above.
3. Alert list generation: Create an incremental list of alerts for all situations that generate security breaches for the alert types mentioned above.
4. Filtering of alert generation: Provide an interface to allow the user to filter the generation of alerts by alert type.
5. Display a summary of generated alerts:
"Provide an interface to display alerts, categorized by alert type.
"Convey the alert level of the displayed alerts using color coding techniques.
"Provide a tree-view of the generated alerts within each alert type. Enable the user to expand each alert to view alert details.
6. Clear alerts: Provide authorized users the functionality to clear alerts from the alert list displayed - in #5 above.
7. Emails can be sent to personnel associated with certain alert types.
8. Email type: Email notifications can be configured to be sent via the internet or through the SAP mailbox.
Detailed explanations of terms above:
1. Regular intervals:
Transaction log generation and alert log generation are incremental processes. Increasing the frequency of log generation makes the process faster and more efficient. Moreover, this also leverages the value of the system by catching alerts in time, and thus prevents security breaches by getting to the violations faster. Nonetheless, the time interval for the generation of transactions and alerts depends on the business needs of the organization.
2. Incremental basis:
Transaction log generation and alert log generation are incremental processes, which means, that only the transactions that have been executed since the last run are included. This makes the log generation process faster and more efficient.
3. Example of a security breach (conflicting transaction):
There may be a transaction to create and maintain vendor accounts, and another to make vendor payments. The same user should not be allowed to access these two transactions, because the security risk lies in the possibility that a user may create a fake vendor account (with the first transaction) and make fraudulent payments to the non-existent vendor (with the second transaction). This is an example of conflicting transactions - such combinations are maintained in the /VIRSA/ZSODTC table.
4. Example of a critical transaction:
The organization maintains a list of transactions that should not be executed by any user, and if executed, should produce alerts. Such transactions are called critical transactions. The transaction used to manage HR data and employee compensation would be an example of a critical transaction that should not be authorized to all users, and hence marked as a critical transaction. Critical transactions are maintained in the /VIRSA/ZCRTRAN table.
5. Example of a mitigation alert:
For example, there may be a mitigation alert configured to force the user "BMOHANTY" to execute the transaction "MB01", every 3 days (as shown in the figure below). If this user does not execute the MB01 transaction after a 3-day time interval has elapsed, then an alert should be raised. Mitigation alerts are stored in the /VIRSA/MITREPORT table.
6. Master data:
The master data for the 3 types of alert situations are maintained in the following tables:
1. /VIRSA/ZSODTC table: Conflicting transactions
2. /VIRSA/ZCRTRAN table: Critical transactions
3. /VIRSA/MITREPORT table: Mitigation alerts
7. Transaction log data:
The transaction log is saved to the /VIRSA/ALTCDLOG table and the last run date of the transaction log is maintained in the /VIRSA/ALLASTRUN table.
8. Filter transaction log data:
Transactions written to the transaction log can be filtered using the following parameters: alert type, risk ID, and risk level and mitigation reference.
9. Filter alert generation:
Alerts can be generated for all the 3 alert types (Conflicting transactions, Critical transactions and Mitigation alerts), or the user can use the interface to limit the alerts by alert type.
10. Color coding:
Convey the alert level using the following color coding convention to highlight the alerts:
"Dark red: Critical
"Light red: High
"Yellow: Medium
"Green: Low
11. Alert details:
Alert details - depend on alert type - see: /VIRSA/ALERTVIEW in SE16.
12. User authorization to clear alerts:
Only certain users are authorized (based on the rule ID) to clear alerts from the alert log.
13. Note: background mode
Transaction log generation and alert log generation are processes that are scheduled to run in the background.
Integration
Prerequisites
Features
Selection
Standard Variants
Output
Activities
Example
General Data in Customer Master Fill RESBD Structure from EBP Component Structure
This documentation is copyright by SAP AG.
Length: 7029 Date: 20240425 Time: 151922 sap01-206 ( 137 ms )
