1 / 51

Application Controls - Intro

Application Controls - Intro. Ted Wallerstedt, CISA, CIA Principal Information Systems Auditor University of Minnesota. Application Controls - Agenda. Introduction 9:00 Input Controls 9:05 Interface Controls 9:35 Break 10:05 Access Controls 10:10

chaim
Download Presentation

Application Controls - Intro

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Application Controls - Intro Ted Wallerstedt, CISA, CIA Principal Information Systems Auditor University of Minnesota

  2. Application Controls - Agenda • Introduction 9:00 • Input Controls 9:05 • Interface Controls 9:35 • Break 10:05 • Access Controls 10:10 • Audit Trails 10:50

  3. Introduction • Why audit applications?

  4. Application Risks - STRIDE • Spoofing Identity • Tampering with data • Repudiation • Information Disclosure • Denial of Service • Elevation of Priveldges

  5. Application Security –Input & Interface Controls Quinn Gaalswyk, CISA Senior Information Systems Auditor University of Minnesota

  6. Application Input Controls • Controls imbedded in the application • Used to control functional/business transactions • Prevent or detect data integrity issues #1 REVIEW AND EVALUATE DATA INPUT CONTROLS

  7. Application Input Control Types - Edits • Prevent input from being entered that may cause data-integrity problems

  8. 10 Common Input Edits • Numeric - alphanumeric restrictions • Dates and hour fields set to convert input into the correct format

  9. 10 Common Input Edits • Transaction "reasonableness" checks on inputs

  10. 10 Common Input Edits • Limited input fields prevent invalid entries • E.g. Drop Down Lists • Duplicate entries not allowed for data that is to be unique • “Logic" checks • E.g. Parts Not Greater than Sum

  11. 10 Common Input Edits •  “Calculation" checks on inputs

  12. 10 Common Input Edits • Programmed cutoff dates • E.g. preventing wrong period inputs • Execution of a transaction not allowed until valid data entered into all required fields • Database operatives disallowed • E.g. * or =

  13. Application Input Control Types – Error/Exception Reports • Detects data inputted that may cause data-integrity problems • Push vs. Pull Reports • Input is not or cannot be prevented by edits #2 DETERMINE THE NEED FOR ERROR/EXCEPTION REPORTS RELATED TO DATA INTEGRITY, AND EVALUATE WHETHER THIS NEED HAS BEEN FULFILLED.

  14. Error/Exception Report Considerations • Who is reviewing the log? • Confirm review documentation • What activity/data is logged? • Log Size • Reviewing Time

  15. Application Input Control Auditing • Automated (application) controls: confirm operating effectively • Test data • Sample of one • Reports: confirm creation and review • Test generation as automated (application) control • Larger sample of report reviews – Email or written confirmation

  16. Group Activity –Identify Expected Edits and Report Controls

  17. Scenario: Edits & Reports Testing eChecks AR/AP Application What edits or reports would you expect to see?

  18. Scenario: Edits & Reports Testing eChecks AR/AP Application What are the top controls you want to test?

  19. Interface Controls Defined • Controls ensuring proper transfer of data between systems • Controls around both source and downstream systems #3 REVIEW AND EVALUATE THE CONTROLS IN PLACE OVER DATA FEEDS TO AND FROM INTERFACING SYSTEMS.

  20. Common Interface Types • Automated interface • Batch Processing (i.e. automated jobs) • Manual kickoff • Manual - Typing Interface

  21. Automated Interface - Batch Processing • Multiple places batches/jobs can be ran from: • Separate shared job scheduler • E.g. Autosys • Operating system • Cron jobs • Database • SQL Agent tool • Application directly

  22. Automated Batch Components • Batch/Job schedules • List of what jobs will run when • May include automated and manual • Job dependencies • Operator access (if applicable) • Job managing software (if separate)

  23. Auditing Automated Batches • Access to batch schedules • Batch schedule change procedures • Batch dependencies noted • Notifications if automated job abends • Confirm operator call list/operator monitoring • Confirm call is automated

  24. Common Interface Controls • Transfer Failure Notification/Reporting • Timely and to appropriate individuals • Control totals and accompanying reporting • Record Counts • Total Amounts • Hash Totals

  25. Common Interface Controls • Header Footer Checks • Interchange Control Envelope ISA - IEA • Reconciliation reports • Review of control totals and/or discrepancies

  26. Common Interface Controls • Transfers should be secured throughout process • Corruption and viewing • Source system security • File creation and storage • Network security

  27. Common Interface Controls • Input controls into the system where valid – interface edit • Example: duplicate transaction flag review or prevent for a credit card company

  28. Interface Synchronization • Data synchronization if multiple sets stored • Determine source of truth • Review synchronization process and test data #4 IN CASES WHERE THE SAME DATA ARE KEPT IN MULTIPLE DATABASES AND/OR SYSTEMS, PERIODIC 'SYNC' PROCESSES SHOULD BE EXECUTED TO DETECT ANY INCONSISTENCIES IN THE DATA.

  29. Interface Example

  30. Application Security –Audit Trails Quinn Gaalswyk, CISA Senior Information Systems Auditor University of Minnesota

  31. Application Audit Trails Value • Show detail of end user activity • Troubleshooting • Identify breaches • Prevent repudiation #5 REVIEW AND EVALUATE THE AUDIT TRAILS PRESENT IN THE SYSTEM AND THE CONTROLS OVER THOSE AUDIT TRAILS.

  32. Auditing Application Audit Trails • Obtain sample evidence of the audit trail and review • End users and developers cannot edit the audit trail • Users MAY view • Stored on DB or OS • Pragmatic and useful • Expensive

  33. Data Flow Traceability • Data should be traceable through the entire system • Confirm via audit trail and related controls #6 THE SYSTEM SHOULD PROVIDE A MEANS TO TRACE A TRANSACTION OR PIECE OF DATA FROM THE BEGINNING TO THE END OF THE PROCESS ENABLED BY THE SYSTEM.

  34. Application Audit Trail Example

  35. Application Controls – Access Controls Ted Wallerstedt, CISA, CIA Principal Information Systems Auditor University of Minnesota

  36. Authentication – Who are you? #7. DOES AN AUTHENTICATION METHOD EXIST? • What are some ways that users can be authenticated?

  37. Authentication – Who are you? • Passwords • Multifactor • Single Sign on • Log on to OS • Log on to CAH • Lon on to TFA server

  38. Passwords #12. ARE THERE STRONG PASSWORD CONTROLS IN PLACE? • What password controls do you expect to find?

  39. Password Controls • Length • Complexity • Change Interval • History

  40. UMN Password Standard • Password must be used for all devices • 8 or more characters long • Changed at least annually • Must be complex • A minimum of three types of characters • Account lockout required • Do not share passwords

  41. Activity - Passwords You have received evidence of the password settings for the application. Based on the evidence: • Does the Bookstore application meet UMN password standards? • What questions do you have of the admin?

  42. Application Administration • Add/Delete users/groups • Change users/groups • Audit trail • Reporting #9. IS THE ADMIN FUNCTION ADEQUATE?

  43. User Provisioning • Add/Delete users/groups • Change users/groups • Audit trail • Reporting #13. IS BUSINESS NEED VERIFIED BEFORE ACCESS IS GRANTED?

  44. User De-Provisioning • User quits or is fired • User changes jobs • User goes on leave #11. ARE RIGHTS REMOVED WHEN NO LONGER NEEDED?

  45. Authorization – What are you allowed to do? • Access Data (Read/Write) • Access Transactions (Execute) • Read (Display/Print/Copy) • Write (Create/Modify/Delete) #8. IS AUTHENTICATION AND AUTHORIZATION REQUIRED FOR ACCESS?

  46. Transaction Approval EXAMPLES - • Transactions limited by dollar amount • Access requests • Move to production • Record of review #10. IS THERE TRANSACTION APPROVAL IN THE APPLICATION?

  47. Session Timeout • Password protected screen savers • Required by UMN for HIPAA data • 30 minutes or less #14. ARE USERS LOGGED OUT WHEN INACTIVE?

  48. Data Encryption • HTTPS/SSL • PKI • Whole Disk • Record/field level #15. IS DATA PROTECTED IN TRANSIT AND AT REST?

  49. Developer Access • Segregation of Duties • Unauthorized changes • Disruption of service • Unauthorized transactions #16. CAN DEVELOPERS CHANGE PRODUCTION SYSTEMS?

More Related