0% found this document useful (0 votes)
172 views

Application Security - Input & Interface Controls

1. The document discusses controls for application input, interface controls, audit trails, and access controls that are important to evaluate for data integrity and security. 2. Key areas to review include input edits, error reporting, interface validation and reconciliation, authentication methods, password controls, authorization and access levels, transaction approval, session timeout settings, and developer access restrictions. 3. The auditor should test sample transactions, review documentation of control procedures, and verify that the necessary controls are implemented correctly within the application.

Uploaded by

Teddy Haryadi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
172 views

Application Security - Input & Interface Controls

1. The document discusses controls for application input, interface controls, audit trails, and access controls that are important to evaluate for data integrity and security. 2. Key areas to review include input edits, error reporting, interface validation and reconciliation, authentication methods, password controls, authorization and access levels, transaction approval, session timeout settings, and developer access restrictions. 3. The auditor should test sample transactions, review documentation of control procedures, and verify that the necessary controls are implemented correctly within the application.

Uploaded by

Teddy Haryadi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 47

Application Security –

Input & Interface Controls


Quinn Gaalswyk, CISA
Senior Information Systems Auditor
University of Minnesota
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
Application Input Control Types -
Edits
• Prevent input from being entered
that may cause data-integrity
problems
10 Common Input Edits
1. Numeric -
alphanumeric
restrictions

2. Dates and hour


fields set to convert
input into the correct
format
10 Common Input Edits
3. Transaction "reasonableness" checks
on inputs
10 Common Input Edits
4. Limited input fields prevent invalid entries
– E.g. Drop Down Lists

5. Duplicate entries not allowed for data that is to


be unique

6. “Logic" checks
– E.g. Parts Not Greater than Sum
10 Common Input Edits
7. “Calculation" checks on inputs
10 Common Input Edits
8. Programmed cutoff dates
– E.g. preventing wrong period inputs

9. Execution of a transaction not allowed until


valid data entered into all required fields

10.Database operatives disallowed


– E.g. * or =
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.
Error/Exception Report Considerations
• Who is reviewing the log?
– Confirm review documentation

• What activity/data is logged?


– Log Size
– Reviewing Time
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
Group Activity –
Identify Expected Edits and
Report Controls
Scenario: Edits & Reports Testing
eChecks AR/AP Application
What edits or reports would you expect to see?
Scenario: Edits & Reports Testing
eChecks AR/AP Application
What are the top controls you want to test?
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.
Common Interface Types
1. Automated interface
– Batch Processing (i.e. automated jobs)
– Manual kickoff
2. Manual - Typing Interface
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
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)
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
Common Interface Controls
1. Transfer Failure Notification/Reporting
–Timely and to appropriate individuals

2. Control totals and accompanying reporting


–Record Counts
–Total Amounts
–Hash Totals
Common Interface Controls
3. Header Footer Checks
– Interchange Control Envelope ISA - IEA

4. Reconciliation reports
– Review of control totals and/or discrepancies
Common Interface Controls
5. Transfers should be secured throughout
process
–Corruption and viewing
–Source system security
–File creation and storage
–Network security
Common Interface Controls
6. Input controls into the
system where valid –
interface edit
– Example: duplicate
transaction flag review or
prevent for a credit card
company
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.
Interface Example
Application Security –
Audit Trails
Quinn Gaalswyk, CISA
Senior Information Systems Auditor
University of Minnesota
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.
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
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.
Application Audit Trail Example
Application Controls –
Access Controls
Ted Wallerstedt, CISA, CIA
Principal Information Systems
Auditor
University of Minnesota
Authentication – Who are you?
#7. DOES AN AUTHENTICATION
METHOD EXIST?

• What are some ways that users can be


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

#12. ARE THERE STRONG


PASSWORD CONTROLS IN
PLACE?
• What password controls
do you expect to find?
Password Controls
• Length
• Complexity
• Change Interval
• History
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
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?
Application Administration
• Add/Delete users/groups
• Change users/groups
• Audit trail
• Reporting

#9. IS THE ADMIN FUNCTION


ADEQUATE?
User Provisioning
• Add/Delete users/groups
• Change users/groups
• Audit trail
• Reporting

#13. IS BUSINESS NEED VERIFIED


BEFORE ACCESS IS GRANTED?
User De-Provisioning
• User quits or is fired
• User changes jobs
• User goes on leave

#11. ARE RIGHTS REMOVED WHEN


NO LONGER NEEDED?
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?
Transaction Approval
EXAMPLES -
• Transactions limited by dollar amount
• Access requests
• Move to production
• Record of review
#10. IS THERE TRANSACTION
APPROVAL IN THE APPLICATION?
Session Timeout
• Password protected screen savers
• Required by UMN for HIPAA data
• 30 minutes or less

#14. ARE USERS LOGGED OUT WHEN


INACTIVE?
Data Encryption
• HTTPS/SSL
• PKI
• Whole Disk
• Record/field level

#15. IS DATA PROTECTED IN TRANSIT


AND AT REST?
Developer Access
• Segregation of Duties
• Unauthorized changes
• Disruption of service
• Unauthorized transactions

#16. CAN DEVELOPERS CHANGE


PRODUCTION SYSTEMS?
Activity – User Rights
You have requested a list of users and
roles for the application. Based on the
evidence:
• What issues do you have with the
access list?
• What questions do you have of the
admin?

You might also like