This chapter contains these topics:
Section 19.2, "Configuring and Using User Activity Reporting,"
Section 19.3, "Configuring and Using Database Audit Manager,"
Section 19.4, "Configuring and Using Segregation of Duties Reports,"
Several reports and inquiries are available to help security administrators understand whether the authorizations and access controls in place are effectively protecting the JD Edwards World environment. Use the following general guidelines when devising a self- auditing strategy:
Keep Audited Information Manageable
Although self-auditing is relatively inexpensive, you should limit the number of audited events as much as possible. Two log files are available for capturing user activity: the Menu Selection History file (F0082H) and the User Job Activity Log (F009250). Both of these files grow rapidly when logging is turned on. In addition, the Database Audit Manager (DBAM) facility is available to track additions, changes, and deletions on selected files. Limiting the periods in which logging is turned on minimizes the performance effect on the processing of audited statements and the size of the audit trail, making it easier to analyze and understand.
Evaluate the Purpose for Auditing
After you have a clear understanding of the reasons for auditing, you can devise an appropriate auditing strategy and avoid unnecessary auditing. For example, suppose you are auditing to investigate suspicious database activity. This information by itself is not specific enough. What types of suspicious database activity do you suspect or have you noticed? Perhaps you could use DBAM to track one or two files. Another focused auditing purpose might be to audit unauthorized deletions from arbitrary tables in the database. This purpose narrows the type of action being audited and the type of object being affected by the suspicious activity.
Audit the minimum number of statements, users, or objects required to get the targeted information. This prevents unnecessary audit information from cluttering the meaningful information and consuming valuable space in your system. Balance your need to gather sufficient security information with your ability to store and process it.
For example, if you are auditing to gather information about database activity, then determine exactly what types of activities you want to track. Audit only the activities of interest and audit only for the amount of time necessary to gather the information that you need.
Beginning with JD Edwards World release A9.2, a facility called user activity reporting is available to support self-auditing. Three types of information may be monitored: user activity, menu selection history, and file update activity. All three reports display totals by user license type as defined for users in the User License Type file (F00925). You set the user license type file to categorize users in a way that helps you self-determine compliance with your software license. These reports cannot determine compliance; that determination must be done by analyzing your actual software license document.
The primary purpose of the User Activity Summary Report (R009253P) is to capture and report the level of user activity in a given period, called a collection period. The average and peak volumes for user session and users signed on can be monitored. To run this report, you first set up definitions for the collection periods and run them using Unattended Night operations (Sleeper). After the collection periods have run and the information is collected, you may run the report.
Monitor Menu Selection History
The Menu History Summary Report (R009254P) reports the menu selections taken by users during the defined collection periods. The report displays the number of times each menu selection is processed, as well as the system code the menu selection belongs to and the user license type.
The File Update Activity Summary Report (R009255P) reports the number of instances in which a user appears in the audit information for selected files. This information is meant as a quick way to monitor file update activity, but it does not provide a complete audit trail of file update activity because the file audit information only tracks the user ID of the user who last updated the record, not all users who have updated a record. Use the DBAM facility if you want a complete audit trail. The report displays the number of times the user's ID appears in the selected files, as well as the system code the file belongs to and the user license type.
As described in the previous section, User Activity Reporting has a quick method of checking for appropriate file update activity, but it does not provide a complete audit trail. Database Audit Manager (DBAM) is a user-configured audit tool that can track all database transactions you are interested in. Additionally, DBAM provides the ability to require an electronic signature (password) authentication for sensitive transactions.
Set up Audit Configuration Defaults
To configure DBAM, you first set up the system-level defaults for monitoring activity. These are the system locations for the audited files and their source. You should locate the activity logs here.
Set up Files and Fields to Track
You use the Audit Manager Workbench video (V98200) to configure individual database audit configuration records and activate monitoring activity. Each audit configuration record is then configured with a list of files and fields to track. You can also set up audit definition parameters, such as whether electronic signature and change reason codes will be required. Depending on the application, you can set up electronic signature at the record level or transaction (multiple records) level.
DBAM uses database file triggers. When defining a new DBAM audit configuration, you should review what other file triggers may be in place.
After you set up DBAM auditing for a file, you build your own queries over the DBAM audit log files to analyze the file update activity. You can use World Writer to build these queries.
The Sarbanes-Oxley Act raised the level of awareness for many types of security issues, among them problems with conflicts of interest in user's assigned responsibilities. The control principle used to resolve the conflicts of interest is called segregation of duties. When segregation of duties is not properly enforced, segregation of duties conflicts result. These are monitored using the segregation of duties reports.
The first step in determining segregation of duties conflicts is to define the system tasks that make up a particular business activity, called a process. Process definitions may be a single program, function key exit, or selection exit or may include multiple programs. Processes may be embedded within one another, allowing you to modularize the definitions into reusable elements.
The second step in determining segregation of duties conflicts is to define the business processes that together raise a conflict of interest. For example, the user responsible for printing accounts payable checks should not also be the person who sets up new vendors and approves payables invoices. Conflict definitions may be set up at the function key/selection option level, the program level, or the business process level.
Report Segregation of Duties Conflicts
After process definitions and conflicts definitions are in place, the system may then look at user authority and report on users who have authority to system resources that represent a segregation of duties conflict. The report is the Segregation of Duties Conflicts report (R00713). When you determine that a segregation of duties conflict exists, you may then make the appropriate changes in your security setup (and user's responsibilities, as appropriate) to remove the conflict.