SOX Compliance a Practical Approach to App Auditor[1]

7/29/2019 SOX Compliance a Practical Approach to App Auditor[1]

1/47

SOX Compliance with

Application Auditor

Presented BySunita Sarathy

Product ManagerAbsolute Technologies, Inc.At SROAUG, Los Angeles, March 24, 2006 v2


2/47

Highlights

Sarbanes Oxley

Common knowledge?

Your situation? Internal Controls

IT Best Practices for SOX Compliance

Auditing Options in Oracle Application Auditor


3/47

Sarbanes Oxley Act

SOX Signed into law on July 30, 2002 as a resultof various accounting scandals

Section 404 requires public companies to attest tothe effectiveness of their internal controls over

financial reporting

Section 302 requires that CEOs and CFOs vouchfor the integrity of their financial statements


4/47

Section 404 Compliance

Compliance with SOX 404 has 4 steps

1. Identify Key Internal Controls2. Document the identified Internal Controls

3. Management - Test Internal Controls

4. Auditor - Test Internal Controls


5/47

What are Internal

Controls? Measures adopted by an Organization to:

Ensure integrity and reliability of information

Ensure Compliance with policies, laws and regulations

Safeguard assets Promote economic and efficient use of resources

Accomplish established objectives and goals

Mature controls are recognized by:

Real-time monitoring

Continuous improvement, enterprise risk management

Automation support, ability to make rapid changes to controls


6/47

When Internal Controls

are missing or inadequate1. Control Deficiency

Remote likelihood of undetected material misstatement infinancials

No requirement to report it Significant Deficiency

Adversely affects processes, more than remote likelihood ofconsequential misstatement

Must be reported to the audit committee, but not to the public

1. Material Weakness Significant deficiency, possible material misstatement

Needs to be disclosed publicly, in company financialstatements


7/47

How is IT Affected?

SOX Section 404 -Management has to ensureappropriate internal controls of financial reporting

Most companies have software applications thatimpact Financial Reporting, like Oracle, SAP etc

Therefore, most IT Applications would need to beregulated as per SOX requirements!


8/47

Internal Controls in IT

Best Practices in the development cycle:

DocumentationApprovals

Segregation of Duties (SOD)

Testing

AUDITING


9/47

Why Audit?

If you dont properly audit transactions thatimpact

(a) financial data, and

(b) application setups

there is exposure that mistakes orfraudulent activity may be undetected

resulting in incorrect financial statements Auditors may identify inconsistencies as

significant deficiency or material weakness


10/47

How data is changed in

Oracle eBusiness Suite In Oracle, data can be modified through two

mechanisms:

eBusiness Suite of Applications

Directly at the database level, through tools such asSQL*Plus, TOAD, SQL*Navigator, etc

Most conventional Auditing options audit one or the

other method


11/47

Auditing in Oracle

There are several auditing options* in Oracle:

Oracle Database Audit Feature eBusiness Suite Row Who Columns

eBusiness Suite End User Access

eBusiness Suite Oracle Alerts

eBusiness Suite Audit Trail

* Part of Oracles products prior to SOX legislation,

oriented toward instrumentation and debugging.


12/47

1. Database Audit Feature

Set audit_trailparameter = TRUE in init.ora file

Execute SQL audit commands from SYSTEM user inSQL*Plus. Transactions are captured in SYS.AUD$

table

Limitations

No Before and After values for changes. No

standard reporting, or form level access to data User Notification not possible, as table is owned by

SYS


13/47

2. EBS Row Who

Creation_Date, Created_By, Last_Updated_By,Last_Update_Date, Last_Update_Login

Navigate to Help > Record History, in the Oracle

Applications Menu, or select from within SQL

Limitations

Only records identities of Initial and Last User

Does not store Old and New Values Cannot handle changes made by processes external

to the security of Oracle Applications


14/47

3. EBS End User Access

System profile option Sign-On: Audit Levelcontrols the level of end user access auditing

Audit using standard reports like SignOn AuditUsers, SignOn Audit Responsibilities, SignOn AuditForms, etc

Limitations

Only audits user access, or end user usage ofspecified forms

Does not audit changes at the database level


15/47

4. EBS Oracle Alerts

Oracles Exception Reporting Tool

Use SQL statements to define exception conditions

Can be Periodic (schedule based) or Event (createsa database trigger)

Limitations

Event Alerts fire on any change to a record within adefined table, generating unwanted transactions

May cause Concurrent Request bottlenecks


16/47

5. EBS Audit Trail

Set System Profile OptionAuditTrail: Activate =Yes

As System Administrator, select Security >AuditTrail > Install

Define applications, tables and columns to audit RunAudit Trail Update Tablesprogram to activate

Limitations

Cant toggle audits On/Off for selected tables Cant capture data outside the scope of the audited

table


17/47

Keys to SOX Compliance

The Audit triggering process should be automated

Audit trail (record of transaction, the activity &data) should be meaningful and comprehensive

Audit Reporting should be convenient

The Auditing Application should be secure


18/47

Enter Application Auditor

(Aa) Comprehensive auditing solution

Can be installed and configured in less than an hour

Create Audit Configurations, for tables and columns

to be audited User Interface

Defines the work flow of defining, creating, configuring,installing, using, and reporting audits

Based on Oracle Developer tools, familiar look & feel

Simplifies audit reporting all audit trail records goto one table

All audits are created in custom Aa schema


19/47

Application Auditor

Source Table(FND_USER)

Source Table(AP_CHECKS)

Source Table(ORDER_HOLDS)

App

Auditor

TransactionDetails

(Destination)

Table


20/47

Create Audit Config

Select a Source Table - the table to be audited

Register standard Aa Destination table

Identify Source Columns - Columns to be tracked Aa automatically collects standard Reference

information for each record

Create Conditions, if any, to limit auditing

Aa maps the Source and Reference Column valuesto columns in the standard Destination Audit Table.

Compile the configuration - It is now ready to audit!


21/47

Audit Mapping

(Source Columns) (Mapped Columns)START_DATE* OLD_COLUMN_VALUESTART_DATE* NEW_COLUMN_VALUE

LAST_UPDATED_BY LAST_UPDATED_BYTRANSACTED_DATE TRANSACTED_DATED_EMAIL EMAILD_TERMINAL TERMINAL

Source Table

(FND_USER)

Destination Table

(ai_ce_change_trx)


22/47

Audit Design

App Auditor dynamically creates trigger-procedurecombination

Database Objects are created in the Aa schema

Trigger is defined on Source Table, to be fired uponchange to Source Columns

Procedure collects

Before and After Values of Source Columns

Reference Columns and other identifying Elements

and inserts them into the Transactions table


23/47

Source Table is Changed

Audit Flow

Table based Trigger fires, calls Procedure

Procedure collects Old and New Values ofChanged Column, and other Reference Columns

Inserts audit data into Destination Table


24/47

Audit Features

Single audit table stores

Before and After values of Source Column

Source Table and Column name

Trigger Action (Insert, Update or Delete)

Primary Key of Source Table

Who changed Column and When

Reference additional column values from Source table

Embedded SQL to select additional data from othertables

Audit Notification can be set up via email


25/47

Revision Architecture

Aa uses Revisions to create separate audit bins

Audits may be migrated across revisions, acrossschemas, or even across database instances.

Migrate Audit from Revision 1 to Revision 2

Migrate entire Revision from Dev to Prod instance

Only one compiled revision can exist at a point intime


26/47

Revision Architecture

Allows the separation of audits based on usercriteria

Allows one-step compilation of all audits in arevision

Compiled AuditsRevision

(example)

DevelopmentRevision

(example)


27/47

Audit Reporting

Audit Transactions Report Displays the old and new values of the column, the

database user who updated the record, and the identity ofthe terminal used to make the change

Audit Configurations Report Facilitates review discussion with external auditor

Documents all audit configurations defined in ApplicationAuditor

View Transactions Form Displays the various audited transactions created as a

result of triggered audits


28/47

SOX Audit Package

Pre-defined set of 80+ table level audits, based onkey setup and transaction tables that can impactFinancial reporting and controls in Oracle eBusiness

Suite

Package can be loaded and compiled withinminutes


29/47

Aa Administrator

Audit the Auditor!

Create and maintain Aa Audit users

Track changes to database objects in any schema

Maintain Admin email accounts, which receive a

copy of all email notifications sent from Aa

Define content for Aa email alerts


30/47

Audit the Auditor


31/47

Aa Customer

Silicon Image

Requirement Differentiate updates made from

SQL*Plus

Oracle AppsSolution Aas Check Terminal feature allows the

user to identify how the transactionwas performed.


32/47

Aa Customer

Harmonic

Requirement Monitor selected users transactions

Solution Aa provides notification whenunauthorized transactions occur

Condition feature allows tracking to

be limited based on user criteria Changes made via external processes

Changes made by a specific user


33/47

Aa Customer

Tektronix

Requirement Track Sales Order changes forseparate business and financial review

Solution Aas custom table option allows foraudit records to be mapped toseparate audit trail table


34/47

Finally

Highlights Can audit database and Oracle E-Business Suite

transactions

Email Notification when audit is triggered Auditing can be limited to user defined criteria

Custom Schema to ensure audit integrity and security

Application Auditor is highly performanceoptimizedno performance issues

User-friendly Forms Interface Audit security maximized by dual role auditing

(Auditor and Audit Administrator)


35/47

Thank You!

www.absolute-tech.com


36/47

Source Destination

Tables


37/47

Source Columns


38/47

Reference Elements


39/47

Conditions


40/47

Column Mapping


41/47

Audit Transactions Report


42/47

Audit Configuration

Report


43/47

View Transactions


44/47

AUD$ Table


45/47

EBS Row Who


46/47

EBS End User Access


47/47

Audit Trail > Install