An Overview of E-Commerce Application Development

1. An Overview of E-Commerce Application Development & Related Audit Considerations By: Anita Montgomery, CIA Adapted From An ISACA Presentation

2. Agenda • Overview of System Development Life Cycle Development methodologies and how they govern the development process • Audit issues and control objectives including: • Project deliverables for each phase of the SDLC • Application control framework • Regulatory compliance and security issues • Useful resources to remember

3. Overview of the System Development Life Cycle Systems development includes: • Identification, development or acquisition of IT solutions • Implementation and integration into the business process • Changes in and maintenance of existing systems Source: COBIT 3rd Edition

4. Types of methodologies used to govern the development process include:

5. Traditional System DevelopmentLife Cycle Methodology – High Level Analysis Design Construction Testing Implementation Maintenance

6. Rapid System Development Methodology – High Level Iterative Process JAD Session Prototyping UAT Implementation Maintenance

7. Traditional Requirements analysis Design phase Acquire/develop Testing Implementation CobiT Identify automated solutions Acquire and maintain solutions Install and accredit Traditional Development Mapping to CobiT

8. Traditional Methodology in Detail • Per phase • Deliverables to consider

9. IS/IT Change Management Process Project Initiation- Analysis Design Construction Testing Implementation Post Evaluation Infrastructure Requirements Definition Process Area: Project Initiation Process Objective: During project initiation, a high-level estimate of project scope, work effort, deliverable timeframes, and business impact are produced. Feasibility and alternative solutions studies, and cost benefit analysis are performed. Senior management approval of the project is obtained. Adapted from a slide contributed by Thomas Festing

10. Project Initiation Deliverables Include: • Statement of Work or Work Order including estimates of resources needed • Feasibility, Alternative Solution, and Build or Buy Studies • Cost/Benefit Analysis • Formal project approval by senior management to proceed

11. IS/IT Change Management Process Project Initiation- Analysis Design Construction Testing Implementation Post Evaluation Infrastructure Requirements Definition Process Area: Analysis Process Objective: Upon project approval, further analysis takes place. Concepts are expanded upon and documented. Detailed specifications are obtained specific to the client’s requirements, project scope, and the effort necessary to deliver the solution. Client and senior management approvals of detailed business requirements/use cases are obtained. Adapted from a slide contributed by Thomas Festing

12. Analysis Deliverables Include: • Detailed Business Requirements and/or Use Cases • Regulatory requirements are approved by legal/compliance • Formal approval by the business owner of the business requirements to proceed

13. IS/IT Change Management Process Project Initiation /Analysis Design Construction Testing Implementation Post Evaluation Infrastructure Analysis/Design Process Area: Design Process Objective: The design phase defines and demonstrates “how” the project will deliver the intended solution. Functional specifications describe detailed system flow. Technical specifications describe or illustrate the technical requirements, hardware or illustrate the functional requirements, processing environment and /software configurations, data/screen information, security requirements and throughput/benchmarks. Courtesy: Thomas Festing

14. Design Deliverables Include: • Functional specifications describe detailed system flow • Technical specifications including processing environment, hardware and software configurations • Screen Design • Security requirements • Performance and scalability planning • Disaster recovery planning • Formal approval of all deliverables by appropriate management to proceed including the information security function

15. IS/IT Change Management Process Project Initiation /Analysis Design Build/ Development Testing Implementation Post Evaluation Infrastructure Build Development Process Area: Build/Development Process Objective: The Build/Development Phase creates the requested solution through the use of established development/vendor management methodologies. Logical controls provide integrity over the development activity through secured development and staging libraries. Version and integrity controls are maintained through software management tools. Systems based unit and integration testing are performed. System, user, training, and operating manuals are created. Vendor management processes direct transformation/implementation by third parties. Courtesy: Thomas Festing

16. Construction Deliverables Include: • Programming standards for specific technologies used • Evidence of the application control structure (input, output, and processing controls) including: • Flow charts, data conversion plans, data flow diagrams, entity relationship diagrams, balancing routines, audit trails, reporting, etc… • Test plans, scripts, and results for unit testing • Problem/defect tracking and resolution tools, policies, and procedures • Formal approval of code, application control structure and unit testing to proceed • Note: Project deliverables commonly include artifacts from object oriented and structured methodologies

17. IS/IT Change Management Process Project Initiation /Analysis Design Build/ Development Testing Implementation Post Evaluation Infrastructure Testing Process Area: Testing Process Objective: The testing phase executes system, regression, performance, and user acceptance testing based on the test plans, scripts, and cases necessary to approve the project for implementation. Testing is coordinated with a quality assurance group to provide segregation of duties. User acceptance testing is conducted to ensure the system performs as intended. Adapted from a slide contributed by: Thomas Festing

18. Testing Deliverables Include: • A documented test/quality plan • Test scripts or use cases and test results • Problem definition, tracking, prioritization, and resolution mechanisms, policies, and procedures • Formal approval of all test artifacts by appropriate parties • Quality Assurance • IT Management • Business Owner approval of user acceptance testing scripts and results

19. IS/IT Change Management Process Project Initiation /Analysis Design Build/ Development Testing Implementation Post Evaluation Infrastructure Implementation Process Area: Implementation Process Objective : Implementation and “back out” plan are defined. System documentation is completed. User training is conducted. Operating and recovery procedures are finalized and tested. Affected systems/parties are defined and notified. Supporting staff are scheduled. The “system” is moved from the “test” to the “production” environment. Adapted from a slide contributed by: Thomas Festing

20. Implementation Deliverables Include: • A documented implementation plan • “Roll back” or “back out” plan • Completed system, user, training, and operating manuals • Documented disaster recovery/business continuity plans • Emergency contact information including escalation procedures • Formal “Go” decision approval from the business owner, IT management, information security, legal, and compliance

21. Post Implementation Evaluation Shortly after implementation, a post implementation review or post mortem should be conducted. The purpose of this review is to: • Determine the system delivered actually performs as intended in the production environment • Document and communicate lessons learned to ensure efficient and effective use of IT resources in the future

22. Traditional Development Is Great But- It’s largely a static process and may not efficiently provide for: • Changes to project requirements • Agility in a dynamic environment • Rapid scheduling requirements put on development teams in competitive business environments

23. E-business Systems Development - In Detail E-business development is very complex • Technology is relatively new • Systems touch customers not internal users • The Internet provides its own inherent risks • Looks good  success • Great functionality  success

24. E-business Systems Development Effective development in E-business • Traditional methodologies can work • Organizations at CMM level 3+ • Other methodologies used include: • Rapid Development using prototyping • RAD/authoring tools • Object Oriented Analysis and Design used in combination with Traditional or Rapid Methodologies

25. E-business Systems Development CMM Level 1 • Ad hoc process CMM Level 2 • Processes are repeatable, based on past experience but vary from project to project CMM Level 3 • Standardized processes through development and project management Courtesy: Carnegie-Mellon Software Engineering Institute

26. E-business Systems Development CMM Level 4 • Processes are managed and measured against bench-marks CMM Level 5 • Processes are managed, measured and optimized for improvement using prior efforts Courtesy: Carnegie-Mellon Software Engineering Institute

27. E-business Systems Development Rapid Development or Prototyping • Adds components together • Works well in e-business • Use Cases describe functionality • Commonly used approach

28. Overview Of E-businessSystems Development Risks of prototyping: • Testing may be cut short • Unauthorized use of intellectual property • Negative user perception due to limited prototype functionality • Scope creep due to iteration process

29. E-business Systems Development – Object Oriented Object oriented methodologies • Use a lifecycle approach • Based on concepts, modeling, and deliverables

30. Object Oriented Methodologies • Full lifecycle for both business and technical issues • Full set of concepts/models which are self-consistent (follow strict set of rules) • Use Cases, represent the requirements in some cases, class diagrams and sequence diagrams are artifacts of OO • Flow charts and dataflow diagrams are used as well

31. Overview of E-businessSystems Development Projects are managed: • Based on multiple tasks, each undergoing an identical process • Each task goes through a process multiple times (usually) • Milestones are established to ensure processes are complete before next iteration begins

32. Overview of E-businessSystems Development Phases • Each phase has specific deliverables and can have multiple iterations • Phase is complete when all required deliverables are complete Courtesy: Rational Software Corporation

33. Overview of Activity Per Phase Courtesy: Rational Software Corporation

34. Overview of E-businessSystems Development Inception • Project vision • Business case • Development plan • Project plan • Risk identification/mitigation

35. Overview of E-businessSystems Development Elaboration • Updated project plan • Architecture • Initial design • Development plan • “Finalized” project plan • “Finalized” risk identification/mitigation

36. Overview of E-businessSystems Development Construction • Updated project plan • Software modules • Completed testing • User procedures • Final project plan • Final risk identification/mitigation

37. Overview of E-businessSystems Development Transition • Completed project plan • Completed documentation • Completed software

38. Perl CGI scripts HTML, XML, XHTML Java Javascript Active Server Pages ActiveX controls Firewalls Web-servers Front-end Middleware Back-end Commonly Used Terms

39. E-Business System Development • Complex • E-business systems are typically multi-platform • Involve multiple technologies • Security is complex

40. E-business Systems Development Considerations • Applications/systems are not shielded from outside • Applications are accessed by un-trusted users

41. Considerations Continued Issues in E-business development: • Pressure for rapid rollout/continuous change • Limited budgetary control • Quality • Interfaces to legacy systems • Reengineering of processes • Outsourcing/co-sourcing • Legal and regulatory issues

42. Considerations Continued Finally: • Enterprise sites often span multiple development groups • Behavior with other applications may not be accurately predicted due to the complexity of production environments

43. What to Audit SDLC/Project Management Activities: • Compliance with methodology • Deliverable requirements • Approvals • Security and compliance issues • Quality assurance and testing

44. Audit Considerations Quality Assurance Issues: • Extent of testing varies • Baseline versus comprehensive • Testing tools • Testing is more complex as technology and exposures are more complex

45. Audit Considerations Change management is usually poorly controlled: • Numerous changes to sites • Aggressive schedules can compromise QA processes

46. Audit Considerations Legal and Regulatory Compliance • Consumer sites are exposed to local, national, and international laws and regulations • Privacy in US  European privacy • Other countries, there is no privacy

47. Regulatory and Compliance Issues • CA Civil Code 1798.82 (Federal legislation in process as of 11-03) • GLB- governing financial data • HIPAA- governing healthcare information • EU Directive – privacy of personal data • OCC and FRB Guidelines for Banks • Sarbanes Oxley – financial transactions

48. Security Issues • Types of sites differ • Business to Customer • Business to Employee • Business to Business • All of the above require different levels of security and maintenance

49. Security Issues Continued Security: • Minimum of 5 points to control over transmission • Router and server configurations • Databases and applications • Vendor Security • Vulnerabilities inherent to technologies and development language used • Notification requirements in the event of breach

50. Internet Realities The Internet is inherently insecure: • The level of insecurity is pervasive • Security weaknesses exist at all levels of the OSI model • Security was (and still is) an after-thought