Audit Trail Analysis in SAP R/3 System

AUDIT TRAIL ANALYSIS FOR FRAUD CONTROL WITH SAP R/3

-2 SAP AG 2006

Objectives Deductive fraud auditing vendor fraud Introduction to audit trail analysis Role-based access control in SAP R/3 Audit trails in SAP R/3 Fraud detection methodology
-3 SAP AG 2006

KPMG Fraud Survey 2004

-4 SAP AG 2006

KPMG Fraud Survey 2004

-5 SAP AG 2006

KPMG Fraud Survey 2004

-6 SAP AG 2006

Deductive Fraud Auditing Overview: Understanding the business or operations. Performing a risk analysis to identify the types of frauds that can occur. Deducing the symptoms that the most likely frauds would generate. Using computer software to search for these symptoms. Investigating suspect transactions.

SAP AG 2006

Deductive Fraud Auditing Fraud scenario vendor fraud:

Fraudster targets a vendor with frequent transactions. Changes banking details used for payment by bank transfer. Enters an invoice (e.g. possibly a duplicate -system may not be configured to reject duplicates). System pays the invoice. Restores banking details to original state.
SAP AG 2006

Extremely difficult to detect.

Audit Trail Analysis

Audit trails are daily records of significant events. These may be retained on-line for a period, before being archived. They incur significant overheads. Some reporting facilities may be provided. Audit trail analysis is ex-post analysis of user activity.

SAP AG 2006

Audit Trail Analysis

Purposes of audit trail analysis: Review of patterns of access.
Examine history of access by individual users or groups of users, showing actions performed or attempted. Audit trails also can report which users have performed specific functions, such as changes to vendor master records or the entry of vendor invoices. Analysis of audit trails may also reveal limitations in the organizations security model and its implementation.

Review of changes in security.

Changes made to the security of the system can be reviewed periodically by an independent person for authorisation and integrity.
SAP AG 2006

Audit Trail Analysis

Purposes of audit trail analysis (contin.): Review of attempts to by-pass security. Audit trails may be reviewed for attempts and repeated attempts by users and intruders to perform unauthorised functions. Deterrent against attempts to bypass security. Users should be aware of the existence of audit trail analysis and its use to detect attempts to bypass security. Fraud detection. Audit trails can be used to detect potential fraud by searching for red flags. The actions of users who are potential suspects can be reported and analysed to facilitate investigation for actual fraud.

SAP AG 2006

Audit Trails in SAP R/3: Security Audit Log Overview:

Security-related events are stored daily in an audit file on each application server. Filters once activated define which events are recorded (SM19). Filters may be distributed to all servers. A security alert is also sent to the Computing Center Management System (CCMS) alert monitor. Daily audit files are retained until deleted (once archived).

SAP AG 2006

SAP R/3: Security Audit Log Audit records have these fields:
Date Time Client. User-id. Transaction code. Terminal name. Message ID. Message text.
SAP AG 2006

SAP R/3: Security Audit Log

Displaying the audit analysis report: Tools > Administration > Monitor > Security Audit Log > Analysis (SM20). Specify restrictions from/to date/time, user, transaction, audit classes or events. Use Edit > Expert Mode. Message Filter to include/exclude specific messages. Modify the output settings, e.g. date column Security Audit Log > Reread audit log. Security Audit Log > Sort. Security Audit Log > Download.
SAP AG 2006

SAP R/3: Security Audit Log

SAP AG 2006

SAP R/3: Table Extraction

Extracting data using the Data Dictionary: Use transaction code SE16. Enter the table name and click Display. Utilities > Table Contents > Display. Restrict the extracted fields using Settings > List Format > Choose Fields. Deselect all fields and tick the required fields. Enter selection values e.g. BUKRS and GJAHR. Check Number of Entries Default limit is 500.Set the Max. No. Hits. Execute. Save your output as a spreadsheet or text file.
SAP AG 2006

Fraud Detection Methodology

1.Threat monitoring -high-level surveillance of security audit logs for red flags. Requires: Routine extraction of security audit logs. Maintenance of user profile database history of transaction code activity. Standard reports on users, including detection of critical combinations of transaction codes.

SAP AG 2006

Fraud Detection Methodology If the user HACKERW would be identified as a potential suspect. Identification of which vendors were involved and analysis of the financial impact of these transactions requires data extraction from appropriate audit trails. 2. Automated extraction and analysis of data from audit trails to provide documentation of user actions. Requires: Routine extraction of master record changes and accounting audit trails, as a foundation for further analyses of suspect behaviour for the set of chosen fraud schemes.

SAP AG 2006

Fraud Detection Methodology

Vendor account groups. Table T077K is extracted containing vendor account groups which are used to filter change document records,e.g. KRED see Figure 3). Change document headers. Records are extracted from table CDHDR for changes involving vendor account groups, the current fiscal year and critical transaction codes (e.g. FK02). Change document items. Records are extracted from table CDPOS for INSERT changes involving vendor account groups, table LFBK, and field KEY. Accounting document headers. Records are extracted from table BKPF for documents involving the target company code, current fiscal year, and critical transaction codes (e.g. FB60, F110 -payment). Accounting document line items. Records are extracted from table BSEG for line items involving the target company code, current fiscal year, and accounts payable general ledger accounts.

SAP AG 2006

Summary

Audit trails provide a rich source of data for proactive fraud detection. Must deduce likely symptoms in target system, and proactively search for them. Feasible to extend methodology to anomaly detection, highlighting changes in user behaviour which may also signal potential fraud.

SAP AG 2006