An Overview of E-Commerce Application Development

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

JAD Session

Prototyping

UAT

Implementation

Maintenance

Iterative Process

7

Traditional Development Mapping to CobiT

Traditional Requirements

analysis Design phase Acquire/develop Testing Implementation

CobiT Identify automated

solutions Acquire and

maintain solutions Install and accredit

8

Traditional Methodology in Detail

Per phase Deliverables to consider

9

Project Initiation-Analysis

Design Implementation Post EvaluationTesting

Infrastructure

IS/IT Change Management Process

Construction

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.

Requirements Definition

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

Project Initiation-Analysis


Infrastructure


Construction

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.

Requirements Definition

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

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.

Analysis/Design

Project Initiation/Analysis


Infrastructure


Construction

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

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.

Build Development



Infrastructure


Build/ Development

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

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.

Testing



Infrastructure


Build/ Development

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

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.

Implementation



Infrastructure


Build/ Development

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


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


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


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


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


Inception Project vision Business case Development plan Project plan Risk identification/mitigation

35


Elaboration Updated project plan Architecture Initial design Development plan “Finalized” project plan “Finalized” risk identification/mitigation

36


Construction Updated project plan Software modules Completed testing User procedures Final project plan Final risk identification/mitigation

37


Transition Completed project plan Completed documentation Completed software

38

Commonly Used Terms

Perl CGI scripts HTML, XML, XHTML Java Javascript Active Server

Pages ActiveX controls

Firewalls Web-servers Front-end Middleware Back-end

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


Change management is usually poorly controlled:

Numerous changes to sites Aggressive schedules can compromise

QA processes

46


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

51

Warning:

Multi-Product = Multi-Regulated!

52

Example 1:

View the Countrywide homepage at: www.mycountrywide.com

53

54

Example 2:

View the Countrywide bank homepage at: www.countrywidebank.com

55

56

Example 3:

View an Interstitial page

57

58

Vendor Issues

Vendor solutions always require customization Vendors may not comply with enterprise

requirements such as: Encryption requirements Disaster recovery policies and procedures Documentation standards State specific regulatory requirements

59

Conclusions

Organization’s that view e-business systems as being no different than legacy or ERP systems are asking for problems

Issues with these systems are more complex than what most organization’s have dealt in the past

The scope is often enterprise wide and global in reach

60

Conclusions

Success is based on strong processes

Many methodologies used Testing is usually major weakness Vendor security is often an issue Enterprise assets are often exposed to

non-trusted outsiders

61

Resources to Remember

OCC Advisory on Web Development Gartner and Meta Groups for best practice

standards ISACA and IIA for audit programs, support

and training Seek participation early from enterprise

resources; Legal, Compliance, Security, Extranet, Internal, and External Audit

62

Useful Links

Official CA legislative information:

http://www.leginfo.ca.gov/

Federal Legislation:

http://thomas.loc.gov/

Audit Net:

http://www.auditnet.org/asapind.htm

World Wide Web Consortium:

http://www.w3.org/

63

Useful Links Continued

GLB:http://www.ffiec.gov/ffiecinfobase/resources/elect_bank/con-15usc_6801_6805-gramm_leach_bliley_act.pdf

OCC:

http://www.occ.treas.gov/FFIEC Booklets:

http://www.ffiec.gov/ffiecinfobase/html_pages/it_01.html

Regulatory Resources by IT Booklet:http://www.ffiec.gov/ffiecinfobase/resources/re_01.html

64

Thank you and Questions ?

Presented by Anita Montgomery, CIA

Contact Information:

[email protected]

Documents

An Overview of E-Commerce Application Development