Sarbanes-Oxley Best Practices in an Oracle Applications Environment

Presentation Agenda Overview: l. Segregation of Duties Best Practices l. Instance Management Best Practices l. Super. User Access Best Practices l. Application Security Best Practices l. IT Security Best Practices l. Key Setups Best Practices l. Tools and Automation Best Practices l. Change Management Best Practices l. Other SOX Issues © 2004 ERPS

Segregation of Duties Best Practices © 2004 ERPS

Segregation of Duties (So. D) Best Practices The common approach © 2004 ERPS

So. D Best Practices Problems with this approach: 1. Manual identification of conflicts for remediation. 2. Heavily reliant on Sys Admin group for changes going forward. 3. Not proactive. 4. Violations during future IT Audits will be costly as you try to prove that conflicts didn’t have material impact on financial statements (hint: make sure you have an audit trail!) 5. Very manual. © 2004 ERPS

So. D Best Practices Phases: 1. Conflict Identification 2. Testing and Remediation 3. Maintenance

So. D Best Practices A more thorough and automated approach: Conflict Identification • Identify conflicts at the business process level. Some audit firms may supply this as part of their Risk and Controls Library. • If not supplied by your external audit firm, have your external audit firm confirm the So. D conflicts list. • Translate those conflicts from business terms into your application’s terms. In Oracle terms these are ‘functions’ that are assigned to a menu. © 2004 ERPS

So. D Best Practices Testing and Remediation • Identify all users that have conflicting So. D in Oracle. • Remediate known conflicts by developing new menus and responsibilities or by limiting access within a form by making changes to the custom library (or purchasing software to help manage custom library changes). © 2004 ERPS

So. D Best Practices Maintenance • Document the process to maintain the conflict matrix as new modules and new business units are added to the system. • Develop Change Management Processes for changes to or new: • Users -Access to the apps should be granted by the Sys Admin group who should be the gatekeepers for So. D violations. They grant access in Dev/Patch, run incompatibilities query, then grant access in Prod (conflict matrix. © 2004 ERPS

So. D Best Practices Maintenance • Change Management Practices, cont’d: • Responsibilities – New or changes to Responsibilities should be reviewed the Application Security Steering Committee, approved by workflow process. • Request Groups – New or changes to Request Groups should be reviewed by the Application Security Steering Committee, approved by workflow process. • Menus - New or changes to Menus should be reviewed by the Application Security Steering Committee, approved by workflow process. © 2004 ERPS

So. D Best Practices Monitoring • Develop a process to audit changes to users, responsibilities, menus, and request groups, preferably a real-time automated solution (workflow or alert driven). • Enable audit tracking of all processes relating to So. D so that an audit trail can be maintained (reporting of audit trail information is not out of the box in Oracle even if you turn on audit tracking). • Develop a process to report the audit trail or alerts key users to So. D violations (monitoring of Sys Admin group) • Test controls to ascertain that they have been in effect all quarter. © 2004 ERPS

Instance Management Best Practices © 2004 ERPS

Instance Management Best Practices • Minimum of Four Instances: Dev – Initial development / playground Patch – Testing of patches and family packs Test – End-user testing instance for development/patches Prod – Production environment • Steering committee meets regularly to discuss priorities, includes functional and technical users. Management to play tie-breaker, when necessary • May require more than four instances, smaller databases © 2004 ERPS

Super. User Access Best Practices © 2004 ERPS

Super. User Access Best Practices • Give inquiry only or no access to Prod for IT Support • In non-Prod environments, restrict access to limited data • Develop “access to sensitive data” policy for IT Staff – download templates www. erpseminars. com/resources • Have strict policy on SQL updates in all instances. Make sure any updates are well-documented and include management approval (functional and technical management). Develop and maintain audit trail. • Have setups, new development, and SQL scripts migrated from non-Prod environments to Prod by DBA © 2004 ERPS

Super. User Access Best Practices • Beware of ability to update database through Help -> Examine functionality (Utilities: Diagnostics profile option). • When absolutely necessary to give SQL or form access in Prod, document why work cannot be migrated by DBA, grant very limited access, then revoke access when done. Ideally, only scripts from Oracle Support would be run. Make sure you have an adequate audit trail and functional and technical mgt approval • Use sparingly, document broadly, be prepare to justify • Full white paper on Super. User Access can be requested at www. erpseminars. com/whitepapers. html © 2004 ERPS

Other Application Security Best Practices © 2004 ERPS

Other Apps Security BP • All standard Oracle responsibilities should be end-dated since most have inherent So. D violations. • Develop and enforce naming conventions for menus, responsibilities, users, and request groups • Any changes to menus, request groups, or responsibilities should be done by creating custom ones: • For ABC Corp: • AP_NAVIGATE_GUI becomes ABC_AP_NAVIGATE_GUI, • Payables Manager becomes ABC Payables Manager © 2004 ERPS

Other Apps Security BP • Minimize or prohibit the use of function exclusion in Responsibilities (will add complexity to maintaining So. D documentation or monitoring queries) • Eliminate setup menus from all users in Production. Limit access to setup menus in non-Prod environment. • Identify and end-date all generic logins since they hide the identity of the person and eliminate an effective audit trail. © 2004 ERPS

Other Apps Security BP • Develop an Application Security Steering Committee made up of End Users from various areas, IT management and Sys Admin. Regularly review application security (pre-audit for Internal Audit) • Assign unique passwords to new users, no generic passwords © 2004 ERPS

Other Apps Security BP • Key Profiles Options in 11 i (11. 5. 8? ) • Signon Password Failure Limit – recommend 3, default 0 locks user account after failed logins • Signon Password Hard to Guess – recommend yes, default no - 1 letter, 1 number, not repeating char, d/n include username • Signon Password Length – default none, recommend 7 • Signon Password No Reuse – default 0, recommend 180 or more- # of days before password can be reused © 2004 ERPS

Other Apps Security BP • UMX (11. 5. 10) – allows for decentralized administration of user access (Metalink Note 258281. 1). • Could allow users to grant access which may be helpful • Could allow various locations to administer access • Increases need to proactively monitor due to lack of central control • Self-Registration • Many new workflows • Forgot Password Support • Remember, most theft happens from within, not from external sources… © 2004 ERPS

IT Security BP Here is a sampling of IT Security Best Practices: • Apply overall framework of Cobi. T. See www. erpseminars. com/links for more information. • Segregation of functions in IT for DBA, Sys Admin, and Developer roles. • Full System Administrator responsibility limited to Sys Admin group in all instances. © 2004 ERPS

IT Security BP Here is a sampling of IT Security Best Practices: • Lock down Help -> Examine functionality by: • Make applicable forms read only via QUERY_ONLY=“YES” in Form Functions screen • Eliminate altogether by setting following profile options: • • Utilities: Diagnostics to No Corporate policy for unattended sessions (w/ desktop support) • ICX: Session Timeout – default none, recommend 30 minutes – times out sessions (still can re-authenticate) • ICX: Limit Time © 2004 ERPS

IT Security BP IT Security Best Practices Sampling, cont’d: • Remediate ‘Apps/Apps’ access from custom development (reports, VB, Access databases, BI systems, etc) • Regularly change Apps password (no less than 90 days). Apps password limited to DBA group. • Change all Schema passwords upon initial installation. Have DBA maintain. • Mask or scramble sensitive data in non-production instances. Potential impact on testing plans and strategies when comparing to production results. © 2004 ERPS

IT Security BP IT Security Best Practices Sampling, cont’d: • Require user login when responding to e-mail workflow notifications (11. 5. 9? ) • Delegation of logins not looked upon favorably (Executives, Directors) - circumvention of controls/approval hierarchies • Trace usernames back to PCs to check for multiple logins (audit sharing of logins) and for delegation (big brother!) • Require user login when responding to e-mail workflow notifications (11. 5. 9? ) © 2004 ERPS

IT Security BP IT Security Best Practices Sampling, cont’d: • Desktop security – NOT personal computers, but work productivity tools • Access to Sensitive Data policy – see www. erpseminars. com/resources for policy examples. • Audit all Security Setup Forms (see Appendix A of Metalink Note 189367. 1) • Limit access to forms that allow entry of SQL statements or other codes to be executed at runtime (see Appendix B of Metalink Note 189367. 1) © 2004 ERPS

Key Setups BP Key Setups Best Practices Overview: • Foundational Setups Best Practices • Core Financials Best Practices • Using Request Sets to Disseminate Critical Business Information • Using Workflow Mailer and the Scheduling Function to Monitor Key Controls • Using ADI and the Analysis Wizard to Report and Analyze Financial Data © 2004 ERPS

Key Setups BP • Foundational Setups Best Practices: • Cross Validation Rules and Security Rules should be maintained by the same person or group that adds values to your Chart of Account’s segments and makes changes to your row sets for your FSGs. • Use Security Rules to prevent the update of control accounts such as AR, AP, PO Accrual, Prepayments, Unapplied Receipts, On Account Receipts, and Inventory Control Accounts. Also ‘secure’ Owners’ Equity Accounts so that only key GL personnel can update them. • Use Suspense Accounts to isolate data, where possible, to isolate the data for reconciling ERPS © 2004 purposes at month end.

Key Setups BP • Foundational Setups Best Practices: • Lockdown the Value Set update form to allow only update to AKFF value set via Custom Library extension • Remove setups menus from all users in Prod. • Enable audit trail on setup forms for all applications and key masters (customer, supplier, item, etc. ) to provide for proper audit trail © 2004 ERPS

Key Setups BP • Core Financials Best Practices – General Ledger: • Implement new Journal Approval functionality • Develop Spreadsheet Controls around spreadsheets that develop and upload Journal Entries • Attach supporting spreadsheets to JE to facilitate journal approval review and on-line audit trail. © 2004 ERPS

Key Setups BP • Core Financials Best Practices – Accounts Receivable: • Break apart Customer Form: Sales, Credit, Collections, Treasury based on update needs (custom library) • Control access to Credit Memo’s via approval workflow (coming in 11. 5. 10) • Implement lockbox to avoid handling cash and to automate cash receipts entry • Review Transaction Type Setups; allow access to high risk Transaction Types to only certain employees (custom library) © 2004 ERPS

Key Setups BP • Core Financials Best Practices – Accounts Receivable: • Mask at DB and hide fields at forms level for sensitive customer credit card information • Identify thresholds for major events and develop appropriate Alerts or Workflow process to monitor: • Ex. decrease in orders, bankruptcy or lateness of major customer, etc. © 2004 ERPS

Key Setups BP • Core Financials Best Practices – Accounts Payable: • Send Positive Pay file daily • Implement new Invoice Approval workflow process • Mask at DB and hide fields at forms level for sensitive supplier bank information © 2004 ERPS

Key Setups BP • Using ADI and the Analysis Wizard to Report and Analyze Financial Data: • Harness the power of ADI… • Publish a budget to actual P&L in ADI • Use themes and conditional formatting to highlight categories greater than budget by a certain amount or % • Double click on cells of actuals where they exceed budget figures to drill into the GL, then to Payables • Use 11 i’s new architecture in Payables to drill from the GL back into Payables detail information (supplier, invoice, purchase order, etc. ) © 2004 ERPS

Tools and Controls Automation Best Practices © 2004 ERPS

Tools and Controls Automation BP • Using Request Sets to Disseminate Critical Business Information: • What are Request Sets? • A grouping of concurrent requests that a user can submit all at once • Parameters can be shared or defaulted © 2004 ERPS

Tools and Controls Automation BP • Using Request Sets to Disseminate Critical Business Information: • Examples: • • • Dissemination of expense information via Account Analysis Report with Payables Detail (using shared parameter for period, but defaulting cost center for each request in the set) Dissemination of Aging by Salesperson – queue it to run nightly or weekly for various salespersons (default salesperson for each request in the set), combine with scheduling function and deliver via workflow mailer so salespeople don’t need access to the AR system Users of a Responsibility to Internal Audit for key responsibilities – System Administrator, Workflow Administrator, etc. © 2004 ERPS

Tools and Controls Automation BP • Using Workflow Mailer and the Scheduling Function to Monitor Key Controls: ’ • In the Options tab when submitting a concurrent request, choose Name in the Notify section. © 2004 ERPS

Tools and Controls Automation BP Forms before controls automation: © 2004 ERPS

Change Management Best Practices © 2004 ERPS

Change Management BP Elements of a change management document: • • • • • Document Control section Reviewers section Recap of issue Nature of the change Impact Analysis of Change (DBA/Developer) Development Plan Training Plan (SOX) Testing Plan (SOX Communication Plan Documentation Plan (SOX) Process Documentation (SOX) Controls Testing Strategy (SOX) Segregation of Duties Impact Analysis (SOX) System Security Plan Transition Plan Contingency Plan Reviewer Sign-Off Section © 2004 ERPS Organizational Impact, not just Systems Impact!!!

Audit Tracking Recap Here is a recap of the minimum audit tracking that needs to be enabled to support Internal and External Audits: • Users, Responsibilities, Menus, Request Groups • Key foundational setups in each module (example in Payables – Payables Options, Payment Terms, etc. ) • Key transactional setups in each module (examples include Supplier Master, Customer Master, Item Master, etc. ) These will be heavily audited for compliance with proper change management practices. Efficient reporting of such needs to be developed. © 2004 ERPS

Other Current SOX Issues • Spreadsheet controls • Interface cleanup • Q 4/Year End

Best Practices Caveat The Best Practices cited in this presentation have not been validated with your external auditors nor has there been any systematic study of industry practices to determine they are ‘in fact’ Best Practices for a representative sample of companies attempting to comply with the Sarbanes-Oxley Act of 2002. The Best Practice examples given here should not substitute for accounting or legal advice for your organization and provide no indemnification from fraud or material misstatements in your financial statements. © 2004 ERPS

ERP Seminars Info l l l l Cell for Jeff: 602 -769 -9049 E-mail: jhare@erpseminars. com Website: www. erpseminars. com (request various WPs) Fall seminar series: Dallas, Chicago, Minneapolis, Nor. Cal, So. Cal, Boston, Philadelphia Spring seminar series will probably include Atlanta #1 Action Point for you! Sign up for Oracle SOX e. Group at http: //groups. yahoo. com/group/Oracle. Sox/ Working on the following White Papers : BP for Super. User Access, BP for IT Security, BP for DBAs, BP for Developers, BP in an Upgrade/ Implementation Leave card if you want copies of slides © 2004 ERPS