1. Advanced Accounting Information Systems Day 24 Application Security October 19, 2009

2. Announcements –Will return quiz 5 and assignment 4 on Wednesday –Midterm grades were submitted on Friday –Review on Wednesday –150 point midterm on Friday In class – systems documentation, sql queries (80 points) Out of class – four essay questions, you pick the two to write on, maximum of two double-spaced pages per essay question (70 points) –Covers systems development, general systems documentation concepts, IT auditing, internal controls –Available 10/21/09; due 10/28/09

3. Objectives – Application Security Understand the basis of application design and the development process Develop an understanding of various risks and controls associated with applications and application programming Apply security principles and concepts such as authentication, authorization, session management, and defense in depth to application security Understand assurance considerations for reviewing application security

4. Question for today Identify common risks to application security and suggest at least one control to mitigate each risk

5. Key to Remember Breach in one environment may affect other environments

6. Illustration Application security concerns

7. Functions provided by Application Software Applications –Programs designed to provide some functionality to end users (ultimate users of the applications) Email Spreadsheeting Word processing Web browsing Process payroll, inventory, and revenue transactions

8. Application Software vs Systems Software

9. Application Architecture Distributed architecture –Total functionality provided is distributed over more than one machine –Presentation layer Responsible for the look and feel of the application Receiving user input, displaying output, managing user interface, webpages –Business layer Receives input from presentation tier and subjects it to appropriate business logic – validate all input according to rules, pull data from a back-end database, process appropriate business transactions, and output results back to the presentation tier for display

10. Application Architecture Distributed architecture –Data layer Back-end tier – manages application –related data – supported by relational database such as Oracle, DB@ or SQL server –Thin-client application vs fat-client application – depends upon how tiers are split between user’s computer (client) and remove machine that provides the service (server)

11. Application Architecture Two tier –Business tier and data tier are merged together Three tier –Each tier is distinctly segregated from each other N-tier

12. Application Architecture

13. Advantages of Application Tiers Allows for parallel development of different tiers of the application Builds ‘black box’ type layers Allows for easier maintenance and support because it is easier to change and upgrade a single segregated tier relative to making changes in a monolithic application Layers offer the greater flexibility in distribution as the tiers could reside anywhere from a single computer to services and clients around the world

14. Management Concerns Application security –Commercial software developer If product has security lapses, potential customers won’t buy it, poor reputation –User of commercial applications Attack on application security can be costly –Zero-day exploit »Takes advantage of a security vulnerability as soon as it becomes known and before the software company has time to fix the vulnerability »Viruses and worms attacking applications have unintentional or intentional effect of overflooding networks »Application developed internally vs externally

15. Common Risks and Controls – Boundary Checking Checking the length (boundaries) of the input Buffer (allocated memory space to store inputs) overflow attacks Return address –Skilled programmers take advantage of overflow to overwrite sensitive portions of memory that contain the address of the next set of code to be executed Risks –Denial of service –Execution of code of attacker’s choice Controls –C++ = not good –Java and Perl better

16. Common Risks and Controls – Input Manipulation Application accepts user input and processes it without any filtering or adequate sanitization SQL Injection LDAP Injection Application Specific Input Attacks Risks Controls –Reject known bad data –Clean bad data –Accept only valid data

17. Common Risks and Controls – Application Authentication Process of verifying the identity of the user before allowing access to the application HTTP basic authentication HTTP digest authentication Third-party based authentication Risks Controls

18. Common Risks and Controls – Session Management Session – series of transactions a user would conduct while the user is interacting with the application –During a session application should not forget who you are (i.e. maintain state) else you would have to tediously prove your identity every step of the way Two ways to maintain state –Client-side session management (cookies or zoo hand stamp) Persistent vs nonpersistent Secure vs nonsecure (secure cookie only protects contents from sniffing during transit, besides that, it is just as suseptible to attacks (content modification) as nonsecure cookies –Server-side management (session IDs or zoo ticket stub) Risks Controls

19. Common Risks and Controls – Session Management via Cookies

20. Common Risks and Controls – Session Management via Session IDs

21. Common Risks and Controls – Change Control and Change Management Process of managing changes for a given software application or a specific system –Request for change –Change authorization and approval –Change documentation –Change testing –Scheduling of the change implementation –Implementation and follow-up Risks Controls

22. Common Risks and Controls – Application Infrastructure Security can not be assured if surrounding environment (containing operating systems, networks, databases, etc) is not secure Need to look at each layer around the application – defense-in- depth or security-in-depth principle Risks Controls

23. Assurance Considerations Security should NOT be an afterthought (role of internal IT audit in systems development) Development teams are educated to –Write secure code –Design strong authentication and authorization modules –Minimize application privileges –Ensure application closes when it fails instead of failing open Inputs from users should never be accepted at face value When reviewing applications, IT auditors also need to review security of operating systems, databases, and networks Applications should be designed to run on least amount of privileges (minimum rights) Applications should NOT include hidden backdoors or secret entry points that allow privileged access – Minneapolis example (be careful about allowing entry features for debugging problems or application maintenance) Need to review change control policies and procedures Standardization and reuse of application components minimizes development costs and effort – these components need careful review before being granted extensive usage

24. Vocabulary Review Application authentication Application software Buffer overflows Business tier Change control Change management Cookie Data tier Distributed architecture Fat-client application HTML form field HTML form-based authentication HTTP basic authentication HTTP digest authentication HTTP headers

25. Vocabulary Review Input manipulation Light weight directory access protocol Presentation tier Return address Segregation of duties Session IDs Session management SQL injection system software Thin-client application Third-party-based authentication Two-three-N-tier applications Zero-day exploit

26. Questions for Wednesday Discussion questions 2, 3, 4, and 10