323
2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 1 2007 CISA ® Review Course Chapter 3 Systems and Infrastructure Life Cycle Management

Chap3 2007 Cisa Review Course

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 1

2007 CISA® Review Course

Chapter 3

Systems and Infrastructure Life Cycle Management

Page 2: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 2

Process Area Overview . . .

• Business Realization• Project Management Structure• Project Management Practices• Business Application Development• Alternative Application Development

Approaches• Infrastructure Development / Acquisition

Practices• Information Systems Maintenance Practices• System Development Tools and Productivity

Aids

Page 3: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 3

. . . Process Area Overview

• Process Improvement Practices• Application Controls• Auditing Application Controls• Auditing Systems Development, Acquisition and

Maintenance• Business Application Systems

Page 4: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 4

Process Area Objective

Ensure that the CISA candidate…

Understands and can provide assurance that the management practices for the development/acquisition, testing, implementation, maintenance, and disposal of systems and infrastructure will meet the organization’s objectives.

Page 5: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 5

Process Area Summary

According to the CISA Certification Board, this Process Area will represent

approximately 16% of the CISA examination (approximately 32 questions).

Page 6: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 6

3.1 BUSINESS REALIZATIONPortfolio/Program

Management

A program can be seen as a group of projects and time-bound tasks that are closely linked together throughcommon objectives, a common budget, intertwinedschedules and strategies. Like projects, programs have alimited time frame (start and end date) and organizationalboundaries.

Page 7: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 7

• Program scope, program financials (costs, resources

cash-flow, etc.), program schedules, and program

objectives and deliverables• Program context and environment• Program communication and culture• Program organization

3.1 BUSINESS REALIZATIONPortfolio/Program

Management

Page 8: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 8

The objectives of project portfolio management are:

• Optimization of the results of the project portfolio (not of the individual projects) • Prioritizing and scheduling projects• Resource coordination (internal and external)• Knowledge transfer throughout the projects

3.1 BUSINESS REALIZATIONPortfolio/Program

Management

Page 9: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 9

An important consideration in any IT project, whether it be the development of a new system or the investment in new infrastructure, is the business case. It has been increasingly recognized that the achievement of business benefits should drive projects.

3.1.2 Business Case Development and Approval:

3.1 BUSINESS REALIZATION Portfolio/Program

Management

Page 10: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 10

This concept is called benefits management or benefits realization. It requires:• Describing benefits management or benefits realization• Assigning a measure and target• Establishing a tracking/measuring regime • Documenting the assumption• Establishing key responsibilities for realization• Validating the benefits predicted in the business• Planning the benefit that is to be realized

3.1.3. Benefit realization techniques:

3.1 BUSINESS REALIZATIONPortfolio/Program

Management

Page 11: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 11

3.2 PROJECT MANAGEMENT STRUCTURE

Today, many approaches to project management exist. Some are focused on software development, others have a more general approach; some concentrate on a holistic and systemic view, others provide a very detailed workflow including templates for document creation.

Page 12: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 12

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.1 General Aspects:

A project is normally a one-time effort. It can be complex; involves an element of risk, with a specific objective, deliverable, and start and end dates; and is divisible into explicit phases

Page 13: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 13

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.2 Project Context and Environment:

• Importance of the project in the organization• Connection between the organization’s strategy and the project• Relationship between the project and other projects• Connection between the project to the underlying business case

Page 14: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 14

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.3 Project Organizational Forms:

Three major forms of organizational alignment for project management can be observed:

• Influence project organization• Pure project organization • Matrix project organization

Page 15: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 15

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.4 Project Communication and Culture:

Depending on the size and complexity of the project and the affected parties, communication when initiating the project management project process, may be achieved by:

• One-on-one meetings• Kick-off meetings• Project start workshops• A combination thereof

Page 16: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 16

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.5 Project Objectives:

A project needs clearly defined results that are specific, measurable, achievable, relevant and time bound (SMART).

A holistic project view ensures the consideration and consolidation of all closely coupled objectives. These objectives are broken down into main objectives, additional objectives and nonobjectives.

Page 17: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 17

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.6 Roles and Responsibilities of groups and individuals:

To achieve a successful completion and implementation of any new system, it is advisable that the audit function has an active part, where appropriate, in the life cycle development of the business application. This will facilitate efforts to ensure that proper controls are designed and implemented in the new system.

Page 18: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 18

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.6 Roles and Responsibilities of groups and individuals:

The various roles and responsibilities of groups/individuals that may be involved in the development process are summarized as follows:

• Senior Management• User Management• Project Steering Committee• Project Sponsor• Systems Development Management• Project Manager . . .

Page 19: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 19

3.2 PROJECT MANAGEMENT STRUCTURE

3.2.6 Roles and Responsibilities of groups and individuals:

• Systems Development Project Team• User Project Team• Security Officer• Quality Assurance

Page 20: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 20

3.3 PROJECT MANAGEMENT PRACTICES

Project management is the application of knowledge, skills, tools and techniques applied to a broad range of activities to achieve a stated objective, such as meeting the defined user requirements and deadlines for an IS project.

Page 21: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 21

3.3 PROJECT MANAGEMENT PRACTICES

There are three elements or dimensions of a project that should always be taken into account:

• Time/duration — How long will it take to complete the project?• Cost/resources — How much will it cost?• Deliverables — What has to be done?

Page 22: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 22

3.3 PROJECT MANAGEMENT PRACTICES

A project will be initiated by a project manager or sponsor gathering the information required to gain approval for the project to be created. This will often be compiled into a terms of reference or project charter that states the objective of the project, the stakeholders in the system to be produced, and the project manager and sponsor. Approval of a project initiation document (PID) or a project request document (PRD) is the authority for a project to begin.

3.3.1 Initiation of a project:

Page 23: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 23

3.3 PROJECT MANAGEMENT PRACTICES

The project manager needs to determine:• The various tasks that need to be performed to produce the expected business application system• The sequence or the order in which these tasks need to be performed• The duration or the time window for each task• The priority of each task • The IT resources that are available and required to perform these tasks • Budget or costing for each of these tasks• Source and means of funding

3.3.2 Project Planning:

Page 24: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 24

3.3 PROJECT MANAGEMENT PRACTICES

Software size estimation relates to methods of determining the relative physical size of the application software to be developed. It can be used as a guide to the allocation of resources, estimates of time and cost required for its development, and as a comparison of the total effort required to the resources available.

Software Size Estimation:

Page 25: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 25

3.3 PROJECT MANAGEMENT PRACTICES

The traditional and simplest method in measuring size by counting the number of lines of source code, measured in SLOC, is referred to as kilo lines of code (KLOC). An alternative but similar metric is thousand delivered source instructions (KDSI). This method has proved to be superior when using structured programming languages, such as BASIC or COBOL.

Lines of Source Code:

Page 26: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 26

3.3 PROJECT MANAGEMENT PRACTICES

Function Point Analysis:

The function point analysis (FPA) technique was developed in the late 1970s and has become widely used for estimating complexity in developing large business applications.

Page 27: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 27

3.3 PROJECT MANAGEMENT PRACTICES

FPA Feature Points:

In most standard applications, lists of functions are identified and the corresponding effort is estimated. In web-enabled applications, the development effort depends on the number of screens (forms), number of images, type of images (static or animated), features to be enabled, interfaces and cross referencing that is required.

Page 28: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 28

3.3 PROJECT MANAGEMENT PRACTICES

Cost Budgets:

The estimates for each task should contain some or all of the following elements:• Personnel hours by type (e.g., system analyst, programmer, clerical)• Machine hours (predominantly computer time as well as duplication facilities, office equipment and communication equipment)• Other external costs, such as third-party software, licensing of tools for the project, consultant or contractor fees, training costs, certification costs (if required) and occupation costs (if extra space is required for the project).

Page 29: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 29

3.3 PROJECT MANAGEMENT PRACTICES

Software Cost EstimationCost estimation is a consequence of software size estimation.

This is a necessary step in properly scoping to adequately scope a project. There are automated techniques for cost

estimation of projects at each phase of system development.

Page 30: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 30

Software Cost Estimation

3.3 PROJECT MANAGEMENT PRACTICES

To use these products, a system is usually divided into main components, and a set of cost drivers is established. Components include:• Source code language• Execution time constraints• Main storage constraints• Data storage constraints • Computer access• The target machine used for development • The security environment• Staff experience

Page 31: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 31

Scheduling and Establishing the Time Frame:

3.3 PROJECT MANAGEMENT PRACTICES

This is achieved by arranging tasks according to:• Earliest start date, by considering the logical sequential relationship among tasks and attempting to perform tasks in parallel wherever possible• Latest expected finish date, by considering the estimate of hours per the budget and the expected availability of personnel or other resources and allowing for known, elapsed-time considerations (holidays, recruitment time, full-time/part-time employees)

Page 32: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 32

Critical Path Methodology

3.3 PROJECT MANAGEMENT PRACTICES

All project management techniques compute what is called a critical path. Since a project consists of an ordered set of independent activities, it can be represented as a network where activities are shown as branches connected at nodes immediately preceding and immediately following activities.

Page 33: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 33

Gantt Charts:

3.3 PROJECT MANAGEMENT PRACTICES

Gantt charts can be constructed to aid in scheduling the activities (tasks) needed to complete a project. The charts show when an activity should begin and when it should end.

Page 34: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 34

3.3 PROJECT MANAGEMENT PRACTICES

Program Evaluation Review Technique:

The Program Evaluation Review Technique (PERT) is a network management technique often used in system development projects based on well-defined events and activities for specific project management tasks.

Page 35: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 35

3.3 PROJECT MANAGEMENT PRACTICES

Timebox Management:

Timebox management is another project management technique for defining and deploying software deliverables within a relatively short and fixed period of time and with predetermined specific resources.

Page 36: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 36

3.3 3 GENERAL PROJECT MANAGEMENT

Documentation:

Automated documentation tools to handle the production, validation and maintenance of system and program documentation. These tools often allow the user to input program and system parameters without having to learn high-powered word processing functions. The package then generates program narratives and flowcharts from the input provided by the user.

Page 37: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 37

3.3 3 GENERAL PROJECT MANAGEMENT

Office Automation:

Office automation reduces programmer involvement in functions that are required to comply with policies and staff meetings. Types of office automation tools that have proven to be useful and productive are electronic mail systems, voice-messaging systems, automated time management tools (such as electronic calendars and date reminders), automated libraries, and filing and retrieval systems.

Page 38: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 38

3.3.4 PROJECT CONTROLLING

The controlling activities of a project include management of scope, resource usage and risk. It is important that new requirements for the project are documented and, if approved, allocated appropriate resources. Control of change during a project ensures that projects are completed within stakeholders’ expectations of time, use of funds and quality objectives.

Page 39: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 39

3.3.5 CLOSING A PROJECT

A project should have a finite life, so at some point it is closed and the new or modified system is handed over to the users and/or system support staff. At this point, there may still be some issues that need to be resolved—ownership of which needs to be assigned. The project sponsor should be satisfied that the system produced is acceptable and ready for delivery.

Page 40: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 40

3.4 BUSINESS APPLICATION DEVELOPMENT

Companies often commit significant information technology resources (e.g., people, applications, facilities, technology) to develop, acquire and maintain application systems that are critical to the effective functioning of key business processes. These systems, in turn, often control critical information assets and should be considered an asset that needs to be effectively managed and controlled.

Page 41: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 41

3.4 BUSINESS APPLICATION DEVELOPMENT

The implementation process for business applications, commonly referred to as an SDLC, begins when an individual application is initiated as a result of one or more of the following situations:

• A new opportunity that relates to a new or existing business process• A problem that relates to an existing business process• A new opportunity that will enable the organization to take advantage of technology• A problem with the current technology

Page 42: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 42

3.4 BUSINESS APPLICATION DEVELOPMENT

From an IS auditor’s perspective, such an approach, with defined life cycle phases and specific points for

review and evaluation, provides the following advantages:

• The IS auditor’s influence is significantly increased when there are formal procedures and guidelines identifying each phase in the business application life cycle and the extent

of auditor involvement.• The IS auditor can review all relevant areas and phases

of the systems development project and report independently to management on the adherence to

planned objectives and company procedures.

Page 43: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 43

3.4 BUSINESS APPLICATION DEVELOPMENT

• The IS auditor can identify selected parts of the system and become involved in the technical aspects on the basis of their skills and abilities.• The IS auditor can provide an evaluation of the methods and techniques applied through the development phases of the business application life cycle.

Page 44: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 44

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.1 THE TRADIONAL SYSTEM DEVELOPMENT LIFE CYCLE APPROACH:

Over the years, business application development has occurred largely through the use of the traditional SDLC phases. Also referred to as the waterfall technique, this life cycle approach is the oldest and most widely used for developing business applications.

Page 45: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 45

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.1THE TRADITIONAL SYSTEM DEVELOPMENT LIFE CYCLE APPROACH:

SDLC PHASE: Feasibility• Requirements• Design• Selection• Development• Configuration• Implementation• Post Implementation

Page 46: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 46

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.2 INTEGRATED RESOURCE MANAGEMENT SYSTEMS:

A growing number of organizations—public and private—are shifting from separate groups of interrelated applications to a fully integrated corporate solution. Such solutions are often marketed as enterprise resource planning (ERP) solutions. Many vendors, mainly from Europe and the US, have been focusing on this market and offer packages with commercial names, such as SAP, PeopleSoft, Oracle Financials, SSG (Baan) or J.D. Edwards.

Page 47: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 47

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.3 DESCRIPTION OF TRADITIONAL SLDC PHASES

FEASIBILITY STUDY

Once the determination has been made to move forward with a project, an analysis begins to clearly define the need and to identify alternatives for addressing the need. This analysis is known as the feasibility study.

Page 48: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 48

3.4 BUSINESS APPLICATION DEVELOPMENT

REQUIREMENTS DEFINITION

Requirements definition is concerned with identifying and specifying the business requirements of the system chosen for development during the feasibility study. Requirements include descriptions of what a system should do, how users will interact with a system, conditions under which the system will operate, and the information criteria the system should meet. CobiT’s framework principles for information criteria show that this includes issues associated with effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability.

Page 49: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 49

3.4 BUSINESS APPLICATION DEVELOPMENT

ENTITY RELATIONSHIP DIAGRAMS

An ERD depicts a system’s data and how these data interrelate. An ERD can be used as a requirements analysis tool to obtain an understanding of the data a system needs to capture and manage. In this case, the ERD represents a logical data model. An ERD can also be used later in the development cycle, as a design tool that helps document the actual database schema that will be implemented. Used in this way, the ERD represents a physical data model.

Page 50: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 50

3.4 BUSINESS APPLICATION DEVELOPMENT

SOFTWARE ACQUISITIONSoftware acquisition is not a phase in the standard SDLC. However, if a decision was reached to acquire rather than develop software, is the process that should occur after the requirements definition phase.The feasibility study should contain documentation that supports the decision to acquire the software. 1. Software is required for a generic business process for which vendors are available and software can be implemented as-is. 2. Vendor’s software needs to be customized to suit business processes.3. Software needs to be developed by the vendor.

Page 51: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 51

An organization decides to purchase a package instead of developing it. In such a case, the design and development phases of a traditional software development life cycle (SDLC) would be replaced with:

 A. selection and configuration phases.B. feasibility and requirements phases.C. implementation and testing phases.D. nothing; replacement is not required.

Chapter 3 Question 6

Page 52: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 52

3.4 BUSINESS APPLICATION DEVELOPMENT

RFP CONTENTS

• Product vs. Systems Requirements• Customer References• Vendor viability / financial stability• Availability of complete and reliable documentation• Vendor Support• Source code availability• Number of years experience in offering the product• A list of recent or planned enhacements to the product, with dates• Number of client sites using the product with a list of current users• Acceptance testing of the product

Page 53: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 53

3.4 BUSINESS APPLICATION DEVELOPMENT

DESIGN

Based on the general preliminary design and user requirements defined in the requirements definition phase, a detailed design can be developed.

Once business processes have been documented and it is understood how those processes might be executed in the new system, involvement of users during the design phase is limited.

Page 54: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 54

3.4 BUSINESS APPLICATION DEVELOPMENT

DEVELOPMENT . . .

Key activities performed in a test/development environment include:• Coding and developing program and system-level documents• Debugging and testing programs developed• Developing programs to convert data from the old system for use on the new system• Creating user procedures to handle transition to the new system• Training selected users on the new system since their participation will be needed• Ensuring modifications are documented and applied accurately and completely to vendor-acquired software to ensure that future updated versions of the vendor’s code can be applied

Page 55: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 55

Chapter 3 Question 4

User specifications for a project using the traditional SDLC methodology have not been met. An IS auditor looking for a cause should look in which of the following areas?

A. Quality assurance B. Requirements C. DevelopmentD. User training

Page 56: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 56

3.4 BUSINESS APPLICATION DEVELOPMENT

. . . DEVELOPMENT

IT’S NECESSARY TO CONSIDER:• Programming methods and techniques.• Online Programming facilities.• Programming languages.• Programming Debugging.• Testing.• Elements of a software testing process.• Testing classification.• Other types of testing.• Automated application testing.

Page 57: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 57

To assist in testing a core banking system being acquired, an organization has provided the vendor with sensitive data from its existing production system. An IS auditor’s PRIMARY concern is that the data should be:

 A. sanitized. B. complete. C. representative. D. current.

Chapter 3 Question 3

Page 58: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 58

3.4 BUSINESS APPLICATION DEVELOPMENT

IMPLEMENTATION . . .

During the implementation phase, the actual operation of the new information system is established and tested. Final user-acceptance testing is conducted in this environment.

Page 59: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 59

3.4 BUSINESS APPLICATION DEVELOPMENT

IMPLEMENTATION PLANNING

Once developed and ready for operation, the new system delivered by the project will need an efficient support structure. It is not enough to just set up a support structure defining some roles and naming some people to fulfill these roles. These people will need to acquire new skills.

Page 60: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 60

3.4 BUSINESS APPLICATION DEVELOPMENT

IMPLEMENTATION PLANNING

The main goals are to: • Provide appropriate support structures for first- second- and third- line support teams • Provide a single point of contact (SPOC)• Provide roles and skills definitions with applicable training plans

Page 61: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 61

3.4 BUSINESS APPLICATION DEVELOPMENT

IMPLEMENTATION PLANNING

To achieve significant improvement of the situation, it is necessary to address some important questions such as: • How can the existing support staff be involved in the setup of the new project without neglecting the currently running system? • What is the gap of “know-how” that must be addressed in the training plan? • How big is the difference from the current legacy environment operation to the operation of the new platform?

Page 62: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 62

3.4 BUSINESS APPLICATION DEVELOPMENT

IMPLEMENTATION PLANNING

Such a project shall include the following requirements and expectations:

• There should be a smooth transition from the existing platform to the new platform without any negative effect on users of the system. • There should be maximum employment of the existing support staff to operate the new system environment and keep the effort of new hires at a minimum level.

Page 63: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 63

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures- Gap Analysis

One possible approach to determine the gap—the differences between the current support organization and the future one—is to schedule workshops with the appropriate staff members who are dealing with system operational tasks or support processes at present. This shall also include representatives of the current helpdesk unit.

Page 64: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 64

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures- Role Definitions

The main objectives of an operations manager are:

• Motivate and develop the operational staff under their control to ensure that all information and communication technologies (ICT) services meet their SLA targets, within the agreed financial budget; ensure that these staffs have up-to-date job descriptions, are regularly appraised and have a current training plan for personal development; arrange for the recruitment of staff as necessary.

Page 65: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 65

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures- Role Definitions

• Develop and maintain controls and procedures to ensure that the operational processes run efficiently and that, in the event of failure, operations can recover services, in accordance with a predefined and tested recovery or continuity plan, to agreed fallback levels of service within the agreed targeted recovery time. • Ensure that the physical environment is maintained and secure, according to contractual requirements and business needs. • Ensure that any new ICT infrastructure meets the agreed operability and manageability criteria for live running prior to accepting them for operational use.

Page 66: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 66

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

• Plan and oversee the installation of ICT infrastructure and liaise regularly with vendor staff to ensure adequate support is provided. • Ensure that all operational management reports and information are produced in a timely fashion for all other ICT, service and business management processes. • Ensure that all contractual documentation relevant to maintenance contracts is complete. • Ensure that operational processes are continually developed and improved. • Ensure that all operational staff is aware of and comply with all operational, ICT and service management processes.

Page 67: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 67

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

The main responsibilities of the operation manager are:• Be the owner of all of the ICT operations processes. • Manage operational activities on a day-to-day shift basis, ensuring that all agreed operational targets are met. • Direct operations staff to run the ICT production cycle in line with the controls and processes established to meet production deadlines and ensure that there is an effective handover with other shifts—to maintain the level of ICT services across shift boundaries.

Page 68: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 68

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

• Develop, maintain and enforce acceptance criteria and procedures for the implementation of new ICT infrastructure into the operational environment. • Ensure that all operational ICT infrastructures are operated in accordance with security, environmental and all other organizational policies. • Ensure, with problem management/specialist support/vendor assistance as required.• Provide regular feedback on operational performance to ICT management, recommending any improvements required.

Page 69: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 69

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

• Handle all exceptions within scope and escalate, where necessary, those matters beyond the appropriate level of authority. • Ensure that ICT infrastructure, environmental housekeeping procedures and system backups are performed to the prescribed standard. • Look after operations personnel matters, including staff development, training, education, performance reviews, appraisals, disciplinary issues and counseling.

Page 70: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 70

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

• Train operations staff in new services, applications and equipment, and arrange and run any necessary training, ensuring that appropriate operational documentation is produced. • Check the completion of acceptance criteria for all new and changed services. • Be responsible for quality assurance, validation and acceptance of all ICT infrastructure component deliveries. • Ensure that all third-party personnel are appropriately supervised within all ICT operational environments.

Page 71: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 71

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 1- Develop To-Be Support Structures - Role Definitions

• Manage the operational budget ensuring that actual expenditure is within the forecasted level. • Regularly review ICT operational processes for efficiency, effectiveness and compliance with a view to instigating a continuous process of improvement within all ICT operational areas.• Manage the operational budget ensuring that actual expenditure is within the forecasted level. • Regularly review ICT operational processes for efficiency, effectiveness and compliance with a view to instigating a continuous process of improvement within all ICT operational areas.

Page 72: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 72

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 2- Establish Support Functions - Service Level Agreement

The SLA shall at least consider the following items:

• Operating time• Support time• Mean time between failures (MTBF)• Mean time to repair (MTTR)• Response time (technical)

Page 73: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 73

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 2- Establish Support Functions - Implementation Plan / Knowledge Transfer Plan

Due to best practices the transfer should follow the shadowing and relay-baton method. This approach is the best suitable concept to transfer knowledge, but also to transfer responsibility in a transparent way. The metaphor of the “relay-baton” expresses exactly what must be achieved.

Page 74: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 74

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 2- Establish Support Functions - Training Plans

The training plans for the staff shall show all of the required trainings in terms of:

• Content• Scheduling information• Duration• Delivery Mechanism (Classroom and/or web-based)• The train-the-trainer concept

Page 75: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 75

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 2- Establish Support Functions - Training Plans

The following list gives an impression about work tasks defined to fulfill the overall project goal:

• Collate existing support structure documentation.• Review existing IT organization model.• Define the new support organization structure.• Define the new support processes.• Map the new process to the organization model.• Execute the new organization model.• Establish support functions.

Page 76: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 76

3.4 BUSINESS APPLICATION DEVELOPMENT

Phase 2- Establish Support Functions - Training Plans

• Develop communications material for support staff.• Conduct briefing and training sessions.• Review mobilization progress.• Transfer to new organization structure.• Review of items above.

Page 77: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 77

3.4 BUSINESS APPLICATION DEVELOPMENT

End – User Training

To create the training strategy, the organization must name a training administrator who should identify users who need to be trained with respect to their specific job functions. Consideration should be given to the following format and delivery mechanisms:

• Case studies• Role-based training• Lecture and breakout sessions• Modules at different experience levels• Practical sessions on how to use the system

Page 78: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 78

3.4 BUSINESS APPLICATION DEVELOPMENT

End – User Training

• Remedial computer training (if needed)• Online sessions on the web or on a CD-ROM

Page 79: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 79

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion

A data conversion exercise is done when a new system is being implemented to replace an existing system for reasons such as a software upgrade or the installation and implementation of a new system.

Page 80: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 80

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion

Another important goal set is to minimize risk. • Minimize risks• Minimize disturbances on daily work• Segment, migrate and progressively put into service applications and data• Handle security and confidentiality• Manage the coexistence of legacy and migrated operations• Ensure data consistency and integrity during the migration

Page 81: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 81

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion – Refining Migration Scenario

Module analysis has to be completed to scope the implementation projects regarding functional modules and data entities. Based on this information and analyzing the business requirements, the implementation project’s plan will be refined.

Page 82: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 82

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion – Refining Migration Scenario

• Support migration process —To administrate the enterprise repository during the project, a support process has to be designed and set up. Due to the recommendation that this repository will be used upon completion of the project to manage the software components of the new architecture, this process has to be conforming to development processes. The enterprise repository administration and report generation supports the migration by mainly reverse-engineering the changes in the legacy architecture and running impact analysis reports.

Page 83: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 83

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion – Refining Migration Scenario

• Migration infrastructure —The project team has to cover the specification of the migration infrastructure in the migration project. This approach ensures the consistency of the architecture and gives the ability to guarantee the functionality of the fallback scenario. To do this, the migration project will complete a high-level analysis of the legacy and new data model to establish links between them, which will be refined later.

Page 84: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 84

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion – Fall Back(Rollback) ScenarioBest practices appreciate the approach of the staged deployment of applications to mitigate the risk on the mission-critical applications. For this reason, components to reverse the data conversion are needed.

Page 85: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 85

3.4 BUSINESS APPLICATION DEVELOPMENT

Data Conversion – Fall Back Scenario

The key points to be taken into consideration in a data conversion project are to ensure:

• Completeness of data conversion• Integrity of data • Confidentiality• Consistency of data• Continuity• That a latest copy of the data before conversion from the old platform and the first copy of the data after conversion on the new platform should be maintained separately in the archival for any reference in future

Page 86: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 86

3.4 BUSINESS APPLICATION DEVELOPMENT

Cutover (Go Live) Techniques

Changeover refers to an approach to shift users from using application from the existing (old) system to the replacing (new) system. This is possible only after testing the new system with respect to its program and relevant data. This is sometimes called the go-live technique as it enables the start of the new system. This approach is also called the cutover technique as it helps in cutting out from the older system and moving over to the newer system.

Page 87: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 87

3.4 BUSINESS APPLICATION DEVELOPMENT

Cutover (Go Live) Techniques

Parallel changeover:

This technique includes, along the time line, running the old system, then running both the old and new systems in parallel, and finally changing over to the new system fully after gaining confidence on the working of the new system. In this approach, the users will have to use both systems during the period of overlap.

Page 88: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 88

3.4 BUSINESS APPLICATION DEVELOPMENT

Cutover (Go Live) Techniques

Phased Changeover:

In this approach, the older system is broken into deliverable modules. Initially, the first module of the older system is phased out using the first module of the newer system. Then, the second module of the older system is phased out, using the second module of the newer system and so forth until reaching the last module. Thus, the changeover from the older system to the newer system takes place in a preplanned, phased manner.

Page 89: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 89

3.4 BUSINESS APPLICATION DEVELOPMENT

Cutover (Go Live) Techniques

Abrupt Changeover:

In this approach, the newer system is changed over from the older system on a cutoff date and time and the older system is discontinued once changeover to the new system takes place.

Page 90: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 90

3.4 BUSINESS APPLICATION DEVELOPMENT

Certification / Accreditation

Certification is the process by which an assessor organization, through their empanelled assessors or auditors, examines the level of compliance of an organization in meeting certain requirements, such as standards, policies, processes, procedures, work instructions and guidelines. The end product of the certification process is the presentation of a certificate defining the scope of assessment, which includes location, process, resources, etc., and attesting that the assessed organization is compliant with the certification standards.

Page 91: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 91

3.4 BUSINESS APPLICATION DEVELOPMENT

Postimplementation Review

Following the successful implementation of a new or extensively modified system, it is beneficial to verify that the system has been properly designed and developed and that proper controls have been built into the system.

Page 92: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 92

3.4 BUSINESS APPLICATION DEVELOPMENT

Post Implementation Review

As such, a postimplementation review should meet the following objectives:• Assess the adequacy of the system:

– Does the system meet user requirements and management’s objectives?

– Have access controls been adequately defined and implemented?• Evaluate the projected cost benefits or (ROI) measurements.

Page 93: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 93

• Develop recommendations that address the system’s inadequacies and deficiencies.• Develop a plan for implementing the recommendations.• Assess the development project process:

– Were the chosen methodologies, standards and techniques followed?

– Were appropriate project management techniques used?

3.4 BUSINESS APPLICATION DEVELOPMENT

Post Implementation Review

Page 94: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 94

3.4 BUSINESS APPLICATION DEVELOPMENT

Post Implementation Review

It is important to note that for a postimplementation review to be effective, the information to be reviewed should be identified during the project startup phase, and collected during each stage of the project. For instance, the project manager might establish certain checkpoints to measure effectiveness of software processes and accuracy of software estimates during the project execution. Business measurements should also be established upfront, and collected before the project begins and after the project is implemented.

Page 95: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 95

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.4 Risk Associated With Software Development

One type of risk is business risk relating to the likelihood that the new system may not meet the users’ business needs, requirements and expectations. For example, the business requirements that were to be addressed by the new system are still unfulfilled, and the process has been a waste of resources. In such a case, even if the system is implemented, it will most likely be under-utilized and not maintained, making it obsolete in a short period of time.

Page 96: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 96

When introducing thin client architecture, which of the following risks regarding servers is significantly increased?

 A. IntegrityB. ConcurrencyC. ConfidentialityD. Availability

Chapter 3 Question 8

Page 97: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 97

3.4 BUSINESS APPLICATION DEVELOPMENT

Software project risks exist at multiple levels, such as:• Within the project, e.g., risks associated with not identifying the right requirements to deal with the business problem or opportunity the system is meant to address, and not managing the project to deliver within time and cost constraints• With suppliers, e.g., failure to clearly communicate requirements and expectations resulting in suppliers not delivering on time, at expected cost and/or with deficient quality

3.4.4 Risk Associated With Software Development . . .

Page 98: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 98

3.4 BUSINESS APPLICATION DEVELOPMENT

• Within the organization, e.g., stakeholders not providing needed inputs or committing resources to the project, and changing organizational priorities and politics• With the external environment, e.g., impacts on the projects caused by the actions and changing preferences of customers, competitors, government/regulators and economic conditions

. . . Risk Associated With Software Development

Page 99: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 99

3.4 BUSINESS APPLICATION DEVELOPMENT

. . . Risk Associated With Software Development

The IS auditor should also review the management discipline over a project related to the following:

• The project meeting cooperative goals and objectives• Project planning, including effective estimates of resources and time.• Control over scope creep where a software baseline does not exist, meaning that requirements can be added into the software design and the development process is uncontrolled.

Page 100: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 100

3.4 BUSINESS APPLICATION DEVELOPMENT

. . . Risk Associated With Software Development

• Management tracking over software design and development activities• Senior management support provided to the software project’s design and development efforts• Periodic review and risk analysis in each project phase

Page 101: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 101

3.4 BUSINESS APPLICATION DEVELOPMENT

3.4.5 Use of Structured Analysis, Design and DevelopmentTechniques

• Develop system context diagrams (e.g., high-level business process flow schema).• Perform hierarchical data flow/control flow decomposition.• Develop control transformations.• Develop minispecifications.• Develop data dictionaries.• Define all external events — inputs from external environment.• Define single transformation data flow diagrams from each external event.

Page 102: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 102

3.5 ALTERNATIVE APPLICATION DEVELOPMENT APPROACHES

In the face of increasing system complexity and the need to implement new systems quicker to achieve benefits before the business changes, software development practitioners have developed alternative development strategies to reduce development time and maintenance costs or to improve the quality of software.

Page 103: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 103

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

Given these factors, other approaches an IS auditor may encounter include:

• Incremental or progressive development — The system is built in stages or releases rather than being delivered in its entirety in one implementation. The separate releases are often still large undertakings that operate as discrete subprojects.

Page 104: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 104

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

• Iterative development — This involves building the system in iterations or increments, with feedback occurring after each increment to facilitate any necessary adjustment of project plans and software development products.

Page 105: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 105

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

• Evolutionary development — Prototyping is used to build a working model that is used to elicit/verify requirements and explore design issues. Eventually, the prototype is hardened, so it can be implemented into production, or perhaps the system is recoded based on learning from the prototype

Page 106: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 106

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

• Spiral development — A series of prototypes is used to develop a solution, to the point of detailed design, build and test. The solution spirals out from the initial limited prototype to become progressively more expansive and detailed.

Page 107: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 107

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

• Agile development — The project is broken down into relatively short, time-boxed iterations. From the earliest iterations, the emphasis is to produce actual working functionality, although software release may not always coincide with completion of an increment.

Page 108: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 108

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.1 Agile Development:

Agile development refers to a family of similar development processes that espouse a nontraditional way of developing complex systems. One of the first agile processes emerged in the early 1990s —Scrum.

Page 109: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 109

ALTERNATIVE APPLICATION DEVELOPMENT APPROACHES

Agile Development:

Agile development processes have a number of common characteristics:

• The use of small, time-boxed subprojects or iterations. In this instance, each iteration forms the basis for planning the next iteration.• Replanning the project at the end of each iteration (referred to as a “sprint” in Scrum) including reprioritizing requirements, identifying any new requirements and determining within which release delivered functionality should be implemented.

Page 110: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 110

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.1 Agile Development:

• Relatively greater reliance, compared to traditional methods, on tacit knowledge.• A heavy influence on mechanisms to effectively disseminate tacit knowledge and promote teamwork. Team meetings to verbally discuss progress and issues occur daily but with strict time limits.• At least some of the agile methods stipulate pair-wise programming (two persons code the same part of the system) as a means of sharing knowledge and as a quality check.

Page 111: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 111

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.1 Agile Development:

• A change in the role of the project manager, from one primarily concerned with planning the project, allocating tasks and monitoring progress to that of a facilitator and advocate. Responsibility for planning and control devolves to the team members.

Page 112: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 112

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.1 Agile Development:

Agile development does not ignore the concerns of traditional software development but approaches them from a different perspective:

• Agile development only plans for the next iteration of development in detail, rather than planning subsequent development phases far out in time. • Agile development’s adaptive approach to requirements does not emphasize managing a requirements baseline.

Page 113: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 113

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.1 Agile Development:

• Agile development’s focus is to quickly prove an architecture by building actual functionality vs. formally defining “early-on” software and data architecture in increasingly more detailed models and descriptions. • Agile development assumes limits to defect testing, but attempts to validate functions through a frequent-build test cycle and correct problems in the next subproject, before too much time and cost is incurred.• Agile development does not emphasize defined and repeatable processes, but instead performs and adapts its development based on frequent inspections.

Page 114: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 114

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.2 Prototyping

Prototyping, also known as heuristic or evolutionary development, is the process of creating a system through controlled trial and error procedures to reduce the level of risks in developing the system. That is, it enables the developer and customer to understand and react to risks at each evolutionary level (using prototyping as a risk reduction mechanism).

Page 115: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 115

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.2 Prototyping

There are two basic methods or approaches to prototyping:

1. Build the model to create the design (i.e., the mechanism for defining requirements). Then, based on that model, develop the system design with all the performance, quality and maintenance features needed.2. Gradually, build the actual system that will operate in production using a fourth-generation language (4GL) that has been determined to be appropriate for the system being built.

Page 116: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 116

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.3 Rapid Application Development:

The techniques include the use of:• Small, well-trained development teams• Evolutionary prototypes• Integrated power tools that support modeling, prototyping and component reusability• A central repository• Interactive requirements and design workshops• Rigid limits on development time frames

Page 117: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 117

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.3Rapid Application Development:

The RAD methodology has four major stages:

1. The concept definition stage defines the business functions and data subject areas that the system will support and determines the system scope.2. The functional design stage uses workshops to model the system’s data and processes and build a working prototype of critical system components.

Page 118: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 118

3.6 ALTERNATE FORMS OF SOFTWARE PROJECT

ORGANIZATION

3.6.3 Rapid Application Development:

3. The development stage completes the construction of the physical database and application system, builds the conversion system, and develops user aids and deployment work plans.4. The deployment stage includes final-user testing and training, data conversion and the implementation of the application system.

Page 119: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 119

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.1 Data – Oriented System Development

Data-oriented system development (DOSD) is a method for representing software requirements by focusing on data and their structure. There are institutions, such as stock exchanges, and service providers, such as airlines, telephone companies, etc., that generate time-dependent data.

Page 120: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 120

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.2 Object – Oriented System Development

Object-oriented system development (OOSD) is the process of solution specification and modeling where data and procedures can be grouped into an entity known as an object. An object’s data are referred to as its attributes, and its functionality is referred to as its methods.

Page 121: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 121

3.7 ALTERNATIVE DEVELOPMENT METHODS

Applications that use object – oriented technology are:

• Web applications• E-business applications• Computer-aided software engineering (CASE) for software development• Office automation for e-mail and work orders• Artificial intelligence• Computer-aided manufacturing (CAM) for production and process control

Page 122: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 122

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.3 Component – Based Development

The basic types of components are:

• In-process client components—These components must run from within a container of some kind, such as a web browser; they cannot run on their own.• Stand-alone client components—Applications that expose services to other software can be used as components. Well-known examples are Microsoft’s Excel and Word.

Page 123: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 123

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.3 Component – Based Development

• Stand-alone server components—Processes running on servers that provide services in standardized ways can be components.• In-process server components—These run on servers within containers. Examples include Microsoft’s Transaction Server (MTS) and Sun’s Enterprise Java Beans (EJB).

Page 124: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 124

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.4 Web – Based Application Development

Web-based application development is an important emerging software development approach designed to achieve easier and more effective integration of code modules within and between enterprises.

Page 125: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 125

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.5 Reengineering:

Reengineering is a process of updating an existing system by extracting and reusing design and program components. This process is used to support major changes in the way an organization operates. A number of tools are now available to support this.

Page 126: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 126

  When conducting a review of business process reengineering, an IS auditor found that a key preventive control had been removed. In this case, the IS auditor should:

 A. inform management of the finding and determine whether

management is willing to accept the potential material risk of not having that preventive control.

B. determine if a detective control has replaced the preventive control during the process and, if it has, not report the removal of the preventive control.

C. recommend that this and all control procedures that existed before the process was reengineered be included in the new process.

D. develop a continuous audit approach to monitor the effects

of the removal of the preventive control.

Chapter 3 Question 1

Page 127: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 127

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.6 Reverse Reengineering:

• Decompiling object or executable code into source code and using it to analyze the program• Utilizing the reverse-engineered application as a black box test and unveiling its functionality using test data

Page 128: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 128

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.6 Reverse Reengineering:

The major advantages of reverse engineering are:

• Faster development and reduced SDLC duration• The creation of an improved system using the reverse-engineered application drawbacks

Page 129: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 129

3.7 ALTERNATIVE DEVELOPMENT METHODS

3.7.6 Reverse Reengineering:

The IS auditor should be aware of the following risks:

• Software license agreements often contain clauses prohibiting the licensee from reverse engineering the software, so that any trade secrets or programming techniques are not compromised.• Decompilers are relatively new tools with functions that depend on specific computers, operating systems and programming languages.

Page 130: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 130

The physical architecture analysis, the definition of a new one and the necessary road map to move from one to the other is a critical task for an IT department. Its impact is not only economic, but also technological, as it decides many other choices downstream, such as operational procedures, training needs, installation issues and total cost of ownership (TCO).

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 131: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 131

In this first section, steps are listed to arrive at the choice of a good physical architecture and the way to define a possible road map for supporting the migration of the technical architecture to the new one to reach the following goals:• To successfully analyze the existing architecture• To design a new architecture, which takes into account the existing architecture as well as a company’s particular constraints, such as:

– Reduce costs– Increase functionality– Minimum impact on daily work– Security and confidentiality issues– Progressive migration to the new architecture

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 132: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 132

• To write the functional requirements of this new architecture• To develop a proof of concept based on these functional requirements:

– To characterize price, functionality, and performance– To identify additional requirements that will be used later

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 133: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 133

Thus, ICT departments often face these requirements. The suggested solution must:

• Ensure alignment of the IT systems with corporate standards• Provide appropriate levels of security• Integrate with current IT systems• Consider IT industry trends • Provide future operational flexibility to support business processes • Allow for projected growth in infrastructure without major upgrades• Include technical architecture considerations for information security, secure storage, etc.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 134: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 134

• Ensure cost-effective, day-to-day operational support• Allow the usage of standardized hardware and software• Maximize ROI, cost transparency and operational efficiency

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 135: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 135

3.8.1 Project Phases of Physical Arquitecture Analysis:

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 136: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 136

3.8.1 Project Phases of Physical Arquitecture Analysis:Review of existing arquitecture

Special care must be taken in characterizing all the operational constraints that impact physical architecture, such as:

• Ground issues• Size limits• Weight limits• Current supply• Physical security issues

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 137: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 137

3.8.1 Project Phases of Physical Arquitecture Analysis:Analysis and Design

After reviewing the existing architecture, the design of the actual physical architecture has to be analyzed and again compared against best practices and business requirements.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 138: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 138

3.8.1 Project Phases of Physical Arquitecture Analysis:Draft Functional Requirements

With the first physical architecture design in hand, the first (draft) of functional requirements is composed. They are the input for the next step and the vendor selection process.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 139: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 139

3.8.1 Project Phases of Physical Arquitecture Analysis:Vendor and Product Selection

While the draft functional requirements are written, the vendor selection process is started in parallel. This process is described in detail later in this section.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 140: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 140

3.8.1 Project Phases of Physical Arquitecture Analysis:Writing Functional Requirements

After finishing the draft functional requirements and feeding the second part of this project, the functional requirements document is written, which will be introduced at the second architecture workshop with staff from all affected parties.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 141: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 141

3.8.1 Project Phases of Physical Arquitecture Analysis:Proof of Concept

• The basic setup of the core security infrastructure • Correct functionality of auditing components • Basic, but functional implementation of security measures as defined• Secured transactions• Characterization in terms of installation constraints and limits (server size, server current consumption, server weight, server room physical security)• Performance • Resiliency • Funding and costing model

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 142: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 142

3.8.1 Planning implementation ofInfrastructure:

To ensure the quality of the results, it is necessary to use a phased approach to fit the whole puzzle together. It is also fundamental to set up the communication processes to other projects like the one described earlier.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 143: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 143

3.8.2 Planning implementation ofinfrastructure

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 144: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 144

3.8.2 Planning implementation ofinfrastructure : - Procurement Phase

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 145: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 145

3.8.2 Planning implementation ofinfrastructure : - Delivery Time

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 146: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 146

3.8.2 Planning implementation ofinfrastructure : - Installation Plan

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 147: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 147

3.8.2 Planning implementation ofinfrastructure : - Installation Test Plan

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 148: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 148

3.8.3 Critical Success Factors Include:• The right skilled staff must attend workshops and participate for the whole project duration to avoid

delays.• The documentation needed for carrying out the work

needs to be ready at project start-up.• Decision makers must be involved at all steps, to ensure that all necessary decisions can be made

quickly.• To get prepared, part one of the project (Analysis of Physical Architecture) must be completed and the

needed infrastructure decisions must be made.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 149: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 149

3.8.4 Hardware Acquisition:

Selection of a computer hardware and software environment frequently requires the preparation of a specification for distribution to hw / sw vendors and criteria for evaluating vendor proposals. This specification is sometimes presented to vendors in the form of an invitation to tender (ITT), also known an RFP.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 150: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 150

For acquiring a system the ITT, or specification, should include the following:

• Organizational descriptions indicating whether the computer facilities are centralized or decentralized, distributed or outsourced• Information processing requirements, such as:

– Major, existing application systems and future application systems– Workload and performance requirements– Processing approaches

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 151: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 151

• Hardware requirements, such as:

– CPU speed– Disk space requirements– Memory requirements– Number of CPUs required– Peripheral devices– Data preparation/input devices that accept and convert data for machine processing– Direct entry devices – Networking capability– Number of terminals or nodes the system needs to support

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 152: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 152

• System software applications, such as:

– Operating system software (current version and any required upgrades)– Compilers– Program library software– Database management software and programs– Communications software– Access control software

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 153: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 153

• Support requirements, such as:– System maintenance (for preventive, detective (fault reporting) or corrective purposes) – Training (user and technical staff)– Backups (daily and disaster backups)

• Adaptability requirements, such as:– HW / SW upgrade capabilities– Compatibility with existing hw/sw platforms– Changeover to other equipment capabilities

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 154: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 154

• Constraints, such as:– Staffing levels– Existing hardware capacity– Delivery dates

• Conversion requirements, such as:– Test time for the hw/sw– System conversion facilities– Cost/pricing schedule

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 155: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 155

Acquisition Steps:

• Testimonials or visits with other users• Provisions for competitive bidding• Analysis of bids against requirements• Comparison of bids against each other, using predefined evaluation criteria• Analysis of the vendor’s financial condition• Analysis of the vendor’s capability to provide maintenance and support

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 156: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 156

Acquisition Steps:

• Review of delivery schedules against requirements• Analysis of hw/sw upgrade capability• Analysis of security and control facilities• Evaluation of performance against requirements• Review and negotiation of price• Review of contract terms• Preparation of a formal written report summarizing the analysis for each of the alternatives and justifying the selection based on benefits and cost

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 157: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 157

Acquisition Steps:

The criteria and data used for evaluating vendor proposals should be properly planned. The following are some of the criteria that should be considered in the evaluation process:

• Turnaround time—The time that the helpdesk or vendor takes to fix a problem from the moment it is logged in

• Response time—The time a system takes to respond to a specific query by the user

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 158: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 158

Acquisition Steps:

• System reaction time—The time taken for logging into a system or getting connected to a network• Throughput—The quantity of useful work made by the system per unit of time.• Workload—The capacity to handle the required volume of work, or the volume of work that the vendor’s system can handle in a given time frame• Compatibility—The capability of an existing application to run successfully on the newer system supplied by the vendor

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 159: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 159

Acquisition Steps:

• Capacity—The capability of the newer system to handle a number of simultaneous requests from the network for the application and the volume of data that it can handle from each of the users• Utilization—The system availability time vs. the system downtime

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 160: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 160

3.8.5 System Software Acquisition:

Every time a technological development has allowed for increased computing speeds or new capabilities, these have been absorbed immediately by the demands placed on computing resources by more ambitious applications. Consequently, improvements have led to decentralized, interconnected open systems through functions bundled in operating system software to meet these needs. For example, network management and connectivity are features now found in most operating systems.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 161: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 161

3.8.5 System Software Acquisition:When selecting new system software, a number of business and technical issues must be considered, including:• Business, functional and technical needs and specifications• Cost and benefit(s)• Obsolescence• Compatibility with existing systems• Security• Demands on existing staff• Training and hiring requirements• Future growth needs• Impact on system and network performance

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 162: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 162

3.8.6 System Software Implementation:

System software implementation involves identifying features, configuration options and controls for a standard configuration to apply across the organization.

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

Page 163: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 163

3.8 INFRASTRUCTURE DEVELOPMENT / ACQUISITION PRACTICES

All test results should be documented, reviewed and approved by technically qualified subject matter experts prior to production use.Change control procedures are designed to ensure that changes are authorized and do not disrupt processing. This requires that IS management and personnel are aware of and involved in the system software change process.

3.8.7 System Software Change Control Procedures:

Page 164: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 164

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

System maintenance practices refer primarily to the process of managing change to application systems while maintaining the integrity of both the production source and executable code. Once a system is moved into production, it seldom remains static.

Page 165: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 165

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

The change management process begins with authorizing changes to occur. For this purpose, a methodology should exist for prioritizing and approving system change requests. Change requests are initiated from end users as well as operational staff, and system development/maintenance staff.

3.9.1 Change Management Process Overview:

Page 166: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 166

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• That existing functionality is not damaged by the change• That system performance is not degraded because of the change• That no security exposures have been created because of the change

Testing Changed Programs:

Page 167: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 167

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• Access to program libraries should be restricted.• Supervisory reviews should be conducted.• Change requests should be approved and documented.• Potential impact of changes should be assessed.

Auditing Program Changes:

Page 168: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 168

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• The change request should be documented on a standard form, paying particular attention to the following:– The change specifications should be adequately described, a cost analysis developed and a target date established. – The change form should be signed by the user to designate approval.– The change form should be reviewed and approved by programming management.– The work should be assigned to an analyst, programmer and programming group leader for supervision.

Auditing Program Changes:

Page 169: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 169

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• A sample of program changes made during the audit period should be selected and traced to the maintenance form to determine whether the changes are authorized, check that the form has appropriate approvals, and compare the date on the form with the date of production update for agreement.• If an independent group updates the program changes in production, the IS auditor should determine before the update whether procedures exist to ensure possession of the change request form.

Auditing Program Changes:

Page 170: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 170

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

There may be times when emergency changes are required to resolve system problems and enable critical “production job” processing to continue. Procedures should primarily exist in the application’s operations manual to ensure emergency fixes can be performed without compromising the integrity of the system.

Emergency Changes:

Page 171: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 171

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

Once user management has approved the change, the modified programs can be moved into the production environment. A group that is independent of computer programming should perform the migration of programs from test to production. Groups such as computer operations, quality assurance or a designated change control group should perform this function.

Deploying Changes Back into Production:

Page 172: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 172

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• The programmer has access to production libraries containing programs and data including object code.• The user responsible for the application was not aware of the change (no user signed the maintenance change request approving the start of the work).• A change request form and procedures were not formally established.• The appropriate management official did not sign the change form approving the start of the work.

Change Exposures:

Page 173: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 173

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

• The user did not sign the change form signifying acceptance before the change was updated.• The changed source code was not properly reviewed by the appropriate programming personnel.• The appropriate management official did not sign the change form approving the program for update to production.• The programmer put in extra code for personal benefit.• Changes received from the acquired software vendor were not tested or the vendor was allowed to load the changes directly into production/site.

Change Exposures:

Page 174: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 174

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

Because of the difficulties associated with exercising control over programming maintenance activities, some organizations implement configuration management systems. In a configuration management system, maintenance requests must be formally documented and approved by a change control group.

3.9.2 Configuration Management:

Page 175: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 175

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

As part of the software configuration management task, the maintainer performs the following task steps:1. Develop the configuration management plan.2. Baseline the code and associated documents.3. Analyze and report on the results of configuration control.4. Develop the reports that provide configuration status information.5. Develop release procedures.6. Perform configuration control activities, such as identification and recording of the request.7. Update the configuration status accounting database.

3.9.2 Configuration Management:

Page 176: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 176

3.9 INFORMATION SYSTEMS MAINTENANCE PRACTICES

Tools will support change management and release management by providing automated support for:

1. Identification of items affected by a proposed change to assist with impact assessment 2. Recording configuration items affected by authorized changes 3. Implementation of changes in accordance with authorization

records.4. Registering of configuration item changes when authorized

changes and releases are implemented.5. Recording of baselines related to releases to which to revert with

known consequences.

3.9.2 Configuration Management:

Page 177: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 177

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

Code generators are tools, often incorporated with CASE products, that generate program code based upon parameters defined by a systems analyst or on data/entity flow diagrams developed by the design module of a CASE product.

3.10.1 Code Generators:

Page 178: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 178

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

Application development efforts require collecting, organizing and presenting a substantial amount of data at the application, systems and program levels. A substantial amount of the application development effort involves translating this information into program logic and code for subsequent testing, modification and implementation. This often is a time consuming process, but it is necessary to develop, use and maintain computer applications.

3.10.2 Computer - Aided Software Engineering:

Page 179: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 179

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

CASE products are generally divided into three categories:

1. Upper CASE—These products are used to describe and document business and application requirements.

2. Middle CASE—These products are used for developing the detailed designs.

3. Lower CASE—These products are involved with the generation of program code and database definitions.

3.10.2 Computer - Aided Software Engineering:

Page 180: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 180

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

The IS auditor should gain assurances that approvals are obtained for the appropriate specifications, users continue to be involved in the development process and investments in CASE tools yield benefits in quality and speed. Other key issues the IS auditor needs to consider with CASE include the following:

3.10.2 Computer - Aided Software Engineering:

Page 181: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 181

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

• CASE tools help in the application design process, but do not ensure that the design, programs and system are correct or that they fully meet the needs of the organization.

• CASE tools should complement and fit into the application development methodology, but there needs to be a methodology in place for CASE to be effective.

• The integrity of data moved between CASE products or between manual and CASE processes needs to be monitored and controlled.

3.10.2 Computer - Aided Software Engineering:

Page 182: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 182

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

• Changes to the application should be reflected in stored CASE product data.• Just like a traditional application, application controls need to be designed.• The CASE repository (the database that stores and organizes the

documentation, models and other outputs from the different phases) needs to be secured on a need-to-know basis.

3.10.2 Computer - Aided Software Engineering:

Page 183: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 183

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

While a standard definition of a 4GL does not exist, the common characteristics of 4GLs are the following:

• Nonprocedural language—Most 4GLs do not obey the procedural paradigm of continuous statement execution and subroutine call and control structures.

• Environmental independence (portability)—Many 4GLs are portable across computer architectures, operating systems and telecommunications monitors.

3.10.3 Fourth Generation Languages:

Page 184: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 184

3.10 SYSTEM DEVELOPMENT TOOLS & PRODUCTIVITY

AIDS

• Software facilities—These facilities include the ability to design or paint retrieval screen formats, develop computer-aided training routines or help screens, and produce graphical outputs.

• Programmer workbench concepts—The programmer has access through the terminal to easy filing facilities, temporary storage, text editing and operating system commands.

• Simple language subsets—4GLs generally have simple language subsets that can be used by less-skilled users in an information center.

3.10.3 Fourth Generation Languages:

Page 185: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 185

3.10 PROCESS IMPROVEMENTPRACTICES

“Business is in reality the underlying business process and successful business implies efficient underlying business processes. Everything else that constitutes a business is losing its uniqueness and becoming a commodity. It is no wonder that the efficient organization of processes is becoming a boardroom agenda the world over.” (N. S. Nagaraj et al., BPM Part I: An Emerging Trend, SETLabs, 2001)

3.11.1 Business Process Reengineering and Process Change Projects:

Page 186: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 186

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

Page 187: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 187

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

The steps in a successful BPR are:

• Define the areas to be reviewed.• Develop a project plan.• Gain an understanding of the process under review.• Redesign and streamline the process.• Implement and monitor the new process.• Establish a continuous improvement process.

Page 188: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 188

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

As a reengineering process takes hold, new results begin to emerge:• New business priorities, based on value and customer requirements• A concentration on process as a means of improving product, service and profitability• New approaches to organizing and motivating people inside and outside the enterprise• New approaches to the use of technologies in developing, producing and delivering goods and services

Page 189: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 189

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

• As a subset, new approaches to the use of information as well as powerful and more accessible information technologies• Refined roles for suppliers, including outsourcing, joint development, quick response, just-in-time inventory and support• Often, redefined roles for clients and customers, providing them with more direct and active participation in the enterprise’s business process

Page 190: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 190

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

A successful BPR/process change project requires the project team to perform the following for the existing processes:

• Process decomposition to the lowest level required for effectively assessing a business process, typically referred to as an elementary process, which is a unit of work performed with a definitive input and output.

Page 191: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 191

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.1 Business Process Reengineering and Process Change Projects:

• Identify customers, process-based managers or process owners responsible for beginning-to-end processes.

• Document the elementary process-related profile information, including: – Duration – Trigger – Frequency – Effort – Responsibility – Input and output – External interfaces – System interaction – Risk and control information – Performance measurement information – Identified problematic areas and its root causes

Page 192: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 192

3.11 PROCESS IMPROVEMENTPRACTICES

BPR Methods & TechniquesBenchMarking Process:

Benchmarking is about improving business processes. It is defined as a continuous, systematic process for evaluating the products, services and work processes of organizations recognized as representing best practices for the purpose of organizational improvement.

Page 193: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 193

3.11 PROCESS IMPROVEMENTPRACTICES

BPR Methods & TechniquesBenchMarking Process:

1. Plan—In the planning stage, critical processes are identified for the benchmarking exercise. 2. Research—The team should collect baseline data about its own processes, before collecting this data about others. 3. Observe—The next step is to collect data and visit the benchmarking partner. 4. Analyze—This step involves summarizing and interpreting the data collected and analyzing the gaps between an organization’s process and its partner’s process.

Page 194: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 194

During which of the following steps in the business process reengineering should the benchmarking team visit the benchmarking partner?

 A. Observation B. Planning C. Analysis D. Adaptation

Chapter 3 Question 10

Page 195: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 195

3.11 PROCESS IMPROVEMENTPRACTICES

BPR Methods & TechniquesBenchMarking Process:

5. Adapt—Adapting the results of benchmarking can be the most difficult step. In this step, the team needs to translate the findings into a few core principles and work down from principles to strategies, to action plans.

6. Improve—Continuous improvement is the key focus in a benchmarking exercise. Benchmarking links each process in an organization with an improvement strategy and organizational goals.

Page 196: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 196

3.11 PROCESS IMPROVEMENTPRACTICES

BPR Audit & Evaluation Techniques:

When reviewing an organization’s business process change (reengineering) efforts, IS auditors must determine whether:

• The organization’s change efforts are consistent with the overall culture and strategic plan of the organization.• The reengineering team is making an effort to minimize any negative impact the change might have on the organization’s staff.• The change management team has documented lessons to be learned after the completion of the BPR/process change project.

Page 197: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 197

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.2 ISO 9126:

Attributes evaluated include the following:

• Functionality —• Reliability —• Usability —• Efficiency —• Maintainability —• Portability —

Page 198: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 198

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.3 Software Capability Maturity Model:

The software capability maturity model (CMM), developed by Carnegie Melon’s Software Engineering Institute and various industry and government affiliates in the early 1990s, is a process maturity model or framework that helps organizations improve their software life cycle processes.

Page 199: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 199

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.3 Software Capability Maturity Model:

The five maturity levels attainable by software organizations include:

1. Initial —2. Repeatable —3. Defined —4. Managed —5. Optimizing —

Page 200: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 200

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.4 Capability Maturity Model Integration:Supporters of the CMMI see it as less directly aligned with the

traditional waterfall approach toward development and better aligned with contemporary software development practices including:

• Iterative development• Early definition of architecture• Model-based design notation• Component-based development• Demonstration-based assessment of intermediate development products• Use of scalable, configurable processes

Page 201: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 201

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.5 ISO 15504:

ISO/IEC TR 15504, also known as SPICE (Software Process Improvement and Capability Determination), is based on CMM and Bootstrap and was first published in 1998 (ISO/IEC TR 15504:1998). Based on the feedback of more than 4,000 assessments, it has been republished during 2003-2005 as a full international standard.

Page 202: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 202

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.4 ISO 15504:Reference models for SPICE include: • Software life cycle processes—Through ISO/IEC 12207 AMD1/2• System life cycle processes—Through ISO/IEC 15288• Human-centered life cycle processes—Through ISO 18529• Component-based development processes—Through the

OOSPICE project• IT service management processes—Through a SPICE user group

initiative• Quality management system processes—Through SPICE for 9000

(S9K)• Automotive embedded software—Through Automotive SPICE• Medical device software—Through the Medi SPICE initiative

Page 203: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 203

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.5 ISO 15504:

Page 204: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 204

3.11 PROCESS IMPROVEMENTPRACTICES

3.11.5 ISO 15504:

Page 205: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 205

3.12 APPLICATION CONTROLS

Application controls refer to the transactions and data relating to each computer-based application system; therefore, they are specific to each. The objectives of application controls, which may be manual or programmed, are to ensure the completeness and accuracy of the records and the validity of the entries made therein resulting from both manual and programmed processing.

Page 206: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 206

3.12 APPLICATION CONTROLS

They include methods for ensuring that:

• Only complete, accurate and valid data are entered and updated in a computer system• Processing accomplishes the correct task• Processing results meet expectations• Data are maintained

Page 207: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 207

3.12 APPLICATION CONTROLS

• Identifying the significant application components and the flow of transactions through the system, and gaining a detailed understanding of the application by reviewing the available documentation and interviewing appropriate personnel

• Identifying the application control strengths, and evaluating the impact of the control weaknesses on the development of a testing strategy by analyzing the accumulated information

The IS Auditor’s tasks include:

Page 208: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 208

3.12 APPLICATION CONTROLS

• Testing the controls to ensure their functionality and effectiveness by applying appropriate audit procedures• Evaluating the control environment to determine that control objectives were achieved through analyzing the test results and other audit evidence• Considering the operational aspects of the application to ensure its efficiency and effectiveness by comparing the system with efficient programming standards, analyzing procedures used and comparing them to management’s objectives for the system

The IS Auditor’s tasks include:

Page 209: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 209

3.12 APPLICATION CONTROLS

Input control procedures must ensure that every transaction to be processed is received, processed and recorded accurately and completely. These controls should ensure that only valid and authorized information is input and that these transactions are only processed once. In an integrated systems environment, output generated by one system is the input for another system.

3.12.1 Input / Origination Controls:

Page 210: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 210

3.12 APPLICATION CONTROLS

Types of authorization include:

• Signatures on batch forms or source documents • Online access controls• Unique Passwords • Terminal or client workstation identification• Source documents

Input Authorization:

Page 211: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 211

3.12 APPLICATION CONTROLS

Types of batch controls include:

• Total monetary amount —• Total items —• Total documents —• Hash totals —

Batch Controls and Balancing:

Page 212: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 212

3.12 APPLICATION CONTROLS

Types of batch balancing include:

• Batch registers —• Control accounts —• Computer agreement —

Batch Controls and Balancing:

Page 213: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 213

3.12 APPLICATION CONTROLS

Input error handling can be processed by:

• Rejecting only transactions with errors —• Rejecting the whole batch of transactions —• Holding the batch in suspense —• Accepting the batch and flagging error transactions —

Error reporting and handling:

Page 214: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 214

3.12 APPLICATION CONTROLS

Input control technique include:• Transaction log —• Reconciliation of data —• Documentation —• Error correction procedures — These include:– Logging of errors, Timely corrections, Upstream resubmission, Approval of corrections, Suspense file, Error file, Validity of corrections• Anticipation —• Transmittal log — • Cancellation of source documents —

Error Reporting and Handling:

Page 215: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 215

3.12 APPLICATION CONTROLS

Processing procedures and controls ensure the reliability of application program processing. IS auditors need to understand the procedures and controls that can be exercised over processing to evaluate what exposures are covered by these controls and what exposures remain.

3.12.2 Procesing procedures & controls:

Page 216: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 216

3.12 APPLICATION CONTROLS

Procedures should be established to ensure that input data are validated and edited as close to the time and point of origination as possible. Preprogrammed input formats ensure that data are input to the correct field in the correct format. If input procedures allow supervisor overrides of data validation and editing, automatic logging should occur.

Data validation & editing procedures:

Page 217: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 217

3.12 APPLICATION CONTROLS

Processing controls ensure the completeness and accuracy of accumulated data. They ensure that data on a file/database remains complete and accurate until changed as a result of authorized processing or modification routines. The following are processing control techniques that can be used to address the issues of completeness and accuracy of accumulated data:

Processing Controls:

Page 218: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 218

A hash total of employee numbers is part of the input to a payroll master file update program. The program compares the hash total with the corresponding control total. What is the purpose of this procedure ?

 A. Verify that employee numbers are valid.B. Verify that only authorized employees are paid.C. Detect errors in payroll calculations.D. Detect the erroneous update of records.

Chapter 3 Question 2

Page 219: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 219

3.12 APPLICATION CONTROLS

• Manual recalculations — • Editing —• Run-to-run totals — • Programmed controls — • Reasonableness verification of calculated amounts — • Limit checks on calculated amounts — • Reconciliation of file totals — • Exception reports —

Processing Controls:

Page 220: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 220

APPLICATION CONTROLS

• System control parameters — • Standing data — • Master data/balance data —• Transaction files —

Data File Control Procedures:

Page 221: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 221

3.12 APPLICATION CONTROLS

Output controls provide assurance that the data delivered to users will be presented, formatted and delivered in a consistent and secure manner.

• Logging and storage of negotiable, sensitive and critical forms in a secure place• Computer generation of negotiable instruments, forms and signatures• Report distribution• Balancing and reconciling• Output error handling• Output report retention• Verification of receipt of reports

3.12.3 Output Controls:

Page 222: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 222

3.12 APPLICATION CONTROLS

Specific matters to consider in the business process control assurance are:

• Process maps• Process controls• Assess business risks within the process• Benchmark with the best practices• Roles and responsibilities• Activities and tasks • Data restrictions

3.12.4 Business Process Control Assurance:

Page 223: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 223

3.12 AUDITING APPLICATION CONTROLS

• Identifying the significant application components and the flow of transactions through the system

• Identifying the application control strengths and evaluating the impact of the control weaknesses to develop a testing strategy by analyzing the accumulated information

• Reviewing application system documentation to provide an understanding of the functionality of the application

The IS auditor´s tasks include the following:

Page 224: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 224

3.13 AUDITING APPLICATION CONTROLS

The following documentation should be reviewed to gain an understanding of an application’s development:

– System development methodology documents —– Functional design specifications —– Program changes —– User manuals —– Technical reference documentation —

The IS auditor´s tasks include the following:

Page 225: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 225

3.13 AUDITING APPLICATION CONTROLS

• The quality of internal controls• Economic conditions• Recent accounting system changes• Time elapsed since last audit• Complexity of operations• Changes in operations/environment• Recent changes in key positions• Time in existence• Competitive environment

3.13.2 Risk Assessment Model to Analyze Application Controls

Page 226: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 226

3.13 AUDITING APPLICATION CONTROLS

• Assets at risk• Prior audit results• Staff turnover• Transaction volume• Regulatory agency impact• Monetary volume• Sensitivity of transactions• Impact of application failure

3.13.2 Risk Assessment Model to Analyze Application ’sControl:

Page 227: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 227

3.13 AUDITING APPLICATION CONTROLS

Some of the user procedures that should be observed and tested include:

• Separation of duties — • Authorization of input — • Balancing — • Error control and correction — • Distribution of reports — • Review and testing of access authorizations and capabilities —

3.13.3 Observing and Testing user ’s Performing Procedures:

Page 228: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 228

3.13 AUDITING APPLICATION CONTROLS

Data integrity testing is a set of substantive tests that examines the accuracy, completeness, consistency and authorization of data presently held in a system. It employs testing similar to that used for input control.

3.13.4 Data Integrity Testing:

Page 229: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 229

3.13 AUDITING APPLICATION CONTROLS

• Atomicity —• Consistency —• Isolation —• Durability —

3.13.5 Data Integrity in Online Transaction Processing Systems:

Page 230: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 230

3.13 AUDITING APPLICATION CONTROLS

3.13.6 Test Application Systems:

Page 231: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 231

3.13 AUDITING APPLICATION CONTROLS

3.13.6 Test Application Systems:

Page 232: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 232

3.13 AUDITING APPLICATION CONTROLS

3.13.6 Test Application Systems:

Page 233: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 233

3.13 AUDITING APPLICATION CONTROLS

3.13.6 Test Application Systems:

Page 234: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 234

3.13 AUDITING APPLICATION CONTROLS

3.13.7 Continuous Online Auditing:

Continuous online auditing is becoming increasingly important in today’s e-business world, because it provides a method for the IS auditor to collect evidence on system reliability, while normal processing takes place. The approach allows IS auditors to monitor the operation of such a system on a continuous basis and to gather selective audit evidence through the computer.

Page 235: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 235

3.13 AUDITING APPLICATION CONTROLS

3.13.8 Online Auditing Techniques:

1. Systems control audit review file and embedded audit modules (SCARF/EAM) —2. Snapshots —3. Audit hooks —4. Integrated test facilities (ITF) —5. Continuous and intermittent simulation (CIS) —

Page 236: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 236

3.13 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.13.8 Online Auditing Techniques:

The IS auditor’s tasks in system development, acquisition and maintenance generally include the following:

• Determine the main components, objectives and user requirements • Determine and rank the major risks to, and exposures

• Identify controls to mitigate the risks • Advise the project team regarding the design of the system and implementation of controls• Monitor the systems development process to ensure that controls are implemented

Page 237: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 237

The IS auditor’s tasks in system development, acquisition and maintenance generally includes various aspects.Tracking information in a change management system includes:– History of all work order activity– History of logins and logouts by programmers– History of program deletions

• Participate in post implementation reviews.• Evaluate system maintenance standards and procedures • Test system maintenance procedures • Evaluate the system maintenance process.• Determine the adequacy of production library security

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

Page 238: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 238

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.1 Project Management:

Throughout the project management process, the IS auditor should analyze the associated risks and exposures inherent in each phase of the SDLC and ensure the appropriate control mechanisms are in place to minimize these risks in a cost-effective manner.

Page 239: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 239

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.1 Project Management:

The IS auditor should review the adequacy of the following project management activities:

• Levels of oversight by project committee/board• Risk management methods within the project• Cost management• Processes for planning and dependency management• Reporting processes to senior management• Change control processes• Stakeholder management involvement

Page 240: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 240

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.2 Feasibility Study:

The IS auditor should perform the following functions:• Review the documentation produced in this phase for reasonableness.• Determine whether all cost justifications/benefits are verifiable, and present them showing the anticipated benefits to be realized.• Identify and determine the criticality of the need.• Determine if a solution can be achieved with systems already in place. • Determine the reasonableness of the chosen solution.

Page 241: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 241

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.3 Requirement Definitions:

The IS auditor should perform the following functions:• Obtain the detailed requirements definition document• Identify the key team members on the project team• Verify that project initiation and cost • Review the conceptual design specifications • Review the conceptual design • Determine whether a reasonable number of vendors received a

proposal covering the project scope and user requirements.• Review the user acceptance testing (UAT) specification.• Determine whether the application is a candidate for the use of an

embedded audit routine.

Page 242: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 242

When auditing the requirements phase of a software acquisition, the IS auditor should:

 A. assess the feasibility of the project timetable.B. assess the vendor’s proposed quality processes.C. ensure that the best software package is acquired.D. review the completeness of the specifications.

Chapter 3 Question 7

Page 243: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 243

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.4 Software Acquisition Process:

The IS auditor should perform the following functions:• Analyze the documentation from the feasibility study to determine whether the decision to acquire a solution was appropriate.• Review the RFP to ensure it covers the items listed in this section.• Determine whether the selected vendor is supported by RFP documentation.• Attend agenda-based presentations and conference room pilots to ensure that the system matches the vendor’s response to the RFP.• Review the vendor contract prior to its signing to ensure it includes the items listed.• Ensure the contract is reviewed by legal counsel before it is signed.

Page 244: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 244

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.5 Detailed Design and Development:

The IS auditor should perform the following functions:• Review the system flowcharts for adherence to the general design.

• Review the input, processing and output controls designed into the

system for appropriateness.• Interview the key users of the system to determine their understanding of how the system will operate• Assess the adequacy of audit trails to provide traceability and accountability of system transactions.• Verify the integrity of key calculations and processes.• Verify that the system can identify and process erroneous data correctly.

Page 245: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 245

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.5 Detailed Design and Development:

• Review the quality assurance results of the programs developed during this phase.• Verify that all recommended corrections to programming errors were made and that the recommended audit trails or embedded audit modules were coded into the appropriate programs.

Page 246: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 246

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.6 Testing:

Testing is crucial in determining that the user requirements have been validated, the system is performing as anticipated and the internal controls work as intended. Therefore, it is essential that the IS auditor be involved in reviewing this phase and perform the following:

• Review the test plan for completeness• Reconcile control totals and converted data.• Review error reports for their precision in recognizing erroneous data and for resolution of errors.

Page 247: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 247

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.6 Testing:

• Verify cyclical processing for correctness • Interview end users of the system for their understanding of new methods, procedures and operating instructions.• Review system and end-user documentation to determine its completeness, and verify its accuracy during the test phase.• Review parallel testing results for accuracy.• Verify that system security is functioning as designed by developing and executing access tests.

Page 248: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 248

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.6Testing:

• Review unit and system test plans to determine whether tests for internal controls are planned and performed.• Review the user acceptance testing and ensure that the accepted software has been delivered to the implementation team. The vendor should not be able to replace this version.• Review procedures used for recording and following through on error reports.

Page 249: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 249

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.7 Implementation Phase:

The IS auditor should verify that appropriate sign-offs have been obtained prior to implementation, and perform the following:

• Review the programmed procedures used for scheduling and running the system along with system parameters used in executing the production schedule.• Review all system documentation to ensure its completeness and that all recent updates from the testing phase have been incorporated.• Verify all conversion of data to ensure they are correct and complete before implementing the system in production.

Page 250: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 250

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

Post Implementation Review:

The IS auditor should perform the following functions:

• Determine if the system’s objectives and requirements were achieved.• Determine if the cost benefits identified in the feasibility study are being measured, analyzed and accurately reported to management.• Review program change requests performed to assess the type of changes required of the system. • Review controls built into the system to ensure that they are operating according to design.

Page 251: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 251

An IS auditor is performing a project review to identify whether a new application has met business objectives. Which of the following test reports offers the most assurance that business objectives are met?

 A. User acceptanceB. PerformanceC. SociabilityD. Penetration

Chapter 3 Question 9

Page 252: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 252

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.8 Post Implementation Review:

• Review operators’ error logs to determine if there are any resource or operating problems inherent within the system. • Review input and output control balances and reports to verify that the system is processing data accurately.

Page 253: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 253

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.9 System Change Procedures & the program Migration Process:

In this regard, the IS auditor should consider the following:

• The use and existence of a methodology for authorizing, prioritizing and tracking system change requests from the user• Whether emergency change procedures are addressed in the operations manuals• Whether change control is a formal procedure for the user and the development groups

Page 254: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 254

3.14 AUDITING SYSTEM DEVELOPMENT ACQUISITION

AND MAINTENANCE

3.14.9 System Change Procedures & the program Migration Process:

• Whether the change control log ensures all changes shown were resolved• The user’s satisfaction with the turnaround—timeliness and cost— of change requests• The adequacy of the security access restrictions over production source and executable modules• The adequacy of the organization’s procedures for dealing with emergency program changes• The adequacy of the security access restrictions over the use of the emergency logon IDs

Page 255: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 255

3.15 BUSINESS APPLICATION SYSTEMS

To develop effective audit programs the IS auditor must obtain a clear understanding of the application system under review. Some types of application systems and the related processes are described in the following sections.

Numerous financial and operational functions are computerized for the purpose of improving efficiency and increasing the reliability of information.

Page 256: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 256

3.15 BUSINESS APPLICATION SYSTEMS

3.15.1 Electronic Commerce:

Electronic commerce (e-commerce), is one of the most popular e-business implementations. It is the buying and selling of goods online, usually via the Internet. Typically, a web site will advertise goods and services, and the buyer will fill in a form on the web site to select the items to be purchased and provide delivery and payment details, or banking services, such as transfers, payment orders, etc. The web site may gather details about customers and offer other items that may be of interest.

Page 257: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 257

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Models:

• Business-to-consumer (B-to-C) relationships —• Business-to-business (B-to-B) relationships —• Business-to-employee (B-to-E) relationships —• Business-to-government (B-to-G) relationships —• Consumer-to-government (C-to-G) relationships —• Exchange-to-exchange (X-to-X) relationships —

Page 258: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 258

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Architectures:

There are a large number of choices to be made in determining an appropriate e-commerce architectures. Initially, e-commerce architectures were either two-tiered (i.e., client browser and web server), or three-tiered (i.e., client browser, web server and database server). With increasing emphasis on integrating the web channel with a business’ internal legacy systems and the systems of its business partners, company systems now typically will run on different platforms, running different software and with different databases.

Page 259: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 259

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Risks:

• Confidentiality — • Integrity —• Availability — • Authentication and nonrepudiation —• Power shift to customers —

Page 260: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 260

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Requirements:

Some e-commerce requirements include:

• Build a business case (IT as an enabler).• Develop a clear business purpose.• Use technology to first improve costs.• Build business case around the four Cs: customers, costs, competitors and capabilities.

Page 261: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 261

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Audit & Control Issues:

• A set of security mechanisms and procedures that, taken together, constitute a security architecture for e-commerce (e.g., Internet firewalls, PKI, encryption, certificates and password management)• Firewall mechanisms that are in place to mediate between the public network (the Internet) and an organization’s private network• A process whereby participants in an e-commerce transaction can be identified uniquely and positively

Page 262: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 262

3.15 BUSINESS APPLICATION SYSTEMS

E – Commerce Audit & Control Issues:

• Digital signatures, so the initiator of an e-commerce transaction can be uniquely associated with it. Attributes of digital signatures include:– The digital signature is unique to the person using it.– It can be verified.– The mechanism for generating and affixing the signature is under the sole control of the person using it.– It is linked to data in such a manner that if the data are changed, the digital signature is invalidated.• An infrastructure to manage and control public key pairs

Page 263: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 263

3.15 BUSINESS APPLICATION SYSTEMS

3.15.2 Electronic Data Interchange (EDI):

EDI, in use for more than 20 years, is one of the first e-commerce applications in use between business partners for transmitting business transactions between organizations with dissimilar computer systems. It involves the exchange and transmittal of business documents, such as invoices, purchase orders and shipping notices, in a standard, machine-processable format.

Page 264: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 264

3.15 BUSINESS APPLICATION SYSTEMS

3.15.2 Electronic Data Interchange (EDI):

The benefits associated with the adoption of EDI include: • Less paperwork• Fewer errors during the exchange of information• Improved information flow, database-to-database and company-to- company• No unnecessary rekeying of data• Fewer delays in communication• Improved invoicing and payment processes

Page 265: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 265

3.15 BUSINESS APPLICATION SYSTEMS

Traditional EDI:

1. Communications handler —2. EDI interface — The interface consists of two components:

– EDI translator– Application interface

3. Application system —

Page 266: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 266

3.15 BUSINESS APPLICATION SYSTEMS

Web Based EDI:

• Internet-through-Internet service providers offer a generic network access for all computers connected to the Internet • Its ability to attract new partners via web-based sites to exchange information• New security products available to address issues of confidentiality, authentication, data integrity and nonrepudiation of origin and return• Improvements in the x.12 EDI formatting standard

Page 267: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 267

3.15 BUSINESS APPLICATION SYSTEMS

3.15.4 Controls in EDI Environment:

• Standards should be set to indicate the message format and content

are valid to avoid transmission errors.• Controls should be in place to ensure standard transmissions are properly converted for the application software by the translation application. • The receiving organization must have controls in place to test the reasonableness of messages received. This should be based upon a trading partner’s transaction history or documentation received that substantiates special situations.

Page 268: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 268

Which of the following procedures should be implemented to help ensure the completeness of inbound transactions via electronic data interchange (EDI)?

 A. Segment counts built into the transaction set trailerB. A log of the number of messages received, periodically verified with the transaction originatorC. An electronic audit trail for accountability and trackingD. Matching acknowledgement transactions received to the log of EDI messages sent

Chapter 3 Question 5

Page 269: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 269

3.15 BUSINESS APPLICATION SYSTEMS

3.15.4 Controls in EDI Environment:

• Controls should be established to guard against manipulation of data in active transactions, files and archives. Attempts to change records should be recorded by the system for management review and attention. • Procedures should be established to determine messages are only from authorized parties and that transmissions are properly authorized.• Direct or dedicated transmission channels among the parties should exist to reduce the risk of tapping into the transmission lines.

Page 270: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 270

3.15 BUSINESS APPLICATION SYSTEMS

3.15.4 Controls in EDI Environment:

• Data should be encrypted using algorithms agreed to by the parties involved.• Electronic signatures should be in the transmissions to identify the source and destination.• Message authentication codes should exist to ensure that what is sent is received.

Page 271: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 271

3.15 BUSINESS APPLICATION SYSTEMS

Receipt of Inbound Transactions:

• Use appropriate encryption techniques when using public Internet infrastructures for communication in assuring confidentiality, authenticity and integrity of transactions.• Perform edit checks to identify erroneous, unusual or invalid transactions prior to updating application.• Perform additional computerized checking to assess transaction reasonableness, validity, etc. (Consider expert system front ends

for complex comparisons.)• Log each inbound transaction upon receipt.• Use control totals on receipt of transactions.

Page 272: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 272

3.15 BUSINESS APPLICATION SYSTEMS

Receipt of Inbound Transactions:

• Segment count totals built into the transaction set trailer by the sender.• Control techniques in the processing of individual transactions.• Ensure the exchange of control totals of transactions • Maintain a record of the number of messages received/sent • Arrange for security over temporary files and data transfer to ensure that inbound transactions are not altered or erased between time of transaction receipt and application updates.

Page 273: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 273

3.15 BUSINESS APPLICATION SYSTEMS

Outbound Transactions:

The control considerations for outbound transactions are as follows:

• Controlling the set up and change of trading partner details• Comparing transactions with trading partner transaction profiles• Matching the trading partner number to the trading master file, prior to transmission• Limiting the authority of users within the organization to initiate specific EDI transactions• Segregating initiation and transmission responsibilities for high- risk transactions

Page 274: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 274

3.15 BUSINESS APPLICATION SYSTEMS

Outbound Transactions:

• Documenting management sign-off on programmed procedures and subsequent changes• Logging all payment transactions to a separate file, which is reviewed for authorization before transmission• Segregating duties within the transaction cycle, particularly where transactions are automatically generated by the system• Segregating access to different authorization processes in a transaction cycle

Page 275: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 275

3.15 BUSINESS APPLICATION SYSTEMS

Outbound Transactions:

• Reporting large (value) or unusual transactions for review prior to or after transmission• Logging outbound transactions in a secure temporary file until authorized and due for transmission• Requiring paperless authorization, which would establish special access to authorization fields (probably two levels, requiring the intervention of different users) within the computer system

Page 276: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 276

3.15 BUSINESS APPLICATION SYSTEMS

Auditing EDI:

• Internet encryption processes in place to assure authenticity, integrity, confidentiality and nonrepudiation of transactions• Edit checks to identify erroneous, unusual or invalid transactions prior to updating the application• Additional computerized checking to assess transaction reasonableness and validity• Each inbound transaction to ensure it is logged upon receipt• The use of control totals upon receipt of transactions• Segment count totals built into transaction set trailers by the sender

Page 277: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 277

3.15 BUSINESS APPLICATION SYSTEMS

Auditing EDI:

• Batch control totals built into the functional group headers by the sender• The validity of the sender against trading partner details by:– Using control fields within an EDI message at either the transaction, function, group or interchange level– Using VAN sequential control numbers or reports– Sending an acknowledgement transaction to inform the sender of message receipt. The sender should then match this against a file/log of EDI messages sent.

Page 278: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 278

3.15 BUSINESS APPLICATION SYSTEMS

3.15.5 Electronic Mail:

Electronic mail (e-mail), may be the most heavily used feature of the Internet or LANs in an organization. At the most basic level, the e-mail process can be divided into two principal components:

• Mail servers, which are hosts that deliver, forward and store mail• Clients, which interface with users and allow users to read, compose, send and store e-mail messages

E-mail messages are sent in the same way as most Internet data. When a user sends an e-mail message, it is first broken up by the TCP protocol into IP packets.

Page 279: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 279

3.15 BUSINESS APPLICATION SYSTEMS

Security Issues of E-Mail:

• Flaws in the configuration of mail server application • Denial-of-service (DoS) attacks may be directed to the mail server denying or hindering valid users an ability to use the mail server. • Sensitive information transmitted unencrypted between mail server

and e-mail client may be intercepted. • Information within the e-mail may be altered at some point between the sender and recipient. • Viruses and other types of malicious code may be distributed throughout an organization via e-mail. • Users may send inappropriate, proprietary or other sensitive information via e-mail leading to a legal exposure.

Page 280: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 280

3.15 BUSINESS APPLICATION SYSTEMS

Standards of E-Mail Security:

• Address the security aspects of the deployment of a mail server through maintenance and administration standards • Ensure that the mail server application is deployed, configured and managed to meet the security policy and guidelines laid down by management• Consider the implementation of encryption technologies to protect user authentication and mail data

Page 281: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 281

3.15 BUSINESS APPLICATION SYSTEMS

Standards of E-Mail Security:

Digital signatures are a good method of securing e-mail transmissions in that:

• The signature can not be forged.• The signature is authentic and encrypted.• The signature cannot be reused (a signature on one document cannot be transferred to another document).• The signed document cannot be altered; any alteration to the document (whether or not it has been encrypted) renders the signature invalid.

Page 282: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 282

3.15 BUSINESS APPLICATION SYSTEMS

3.15.7 Electronic Banking:

Banking organizations have been delivering electronic services to consumers and businesses remotely for years. Electronic funds transfer (including small payments and corporate cash management systems), publicly accessible automated machines for currency withdrawal and retail account management are global fixtures.

Continuing technological innovation and competition among existing banking organizations and new market entrants has allowed for a much wider array of electronic banking products and services for retail and wholesale banking customers.

Page 283: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 283

3.15 BUSINESS APPLICATION SYSTEMS

Risk Management Challenges in E-Banking:

• The speed of change relating to technological and service innovation in e-banking is unprecedented. • Transactional e-banking web sites and associated retail and wholesale business applications are typically integrated• E-banking increases banks’ dependence on information technology• The Internet is ubiquitous and global by nature.

Page 284: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 284

3.15 BUSINESS APPLICATION SYSTEMS

Risk Management Controls for E-Banking:

• Board and management oversight:1. Effective management oversight of e-banking activities2. Establishment of a comprehensive security control process3. Comprehensive due diligence and management oversight process

for outsourcing relationships and other third-party dependencies

• Security controls:4. Authentication of e-banking customers5. Nonrepudiation and accountability for e-banking transactions6. Appropriate measures to ensure segregation of duties7. Proper authorization controls within e-banking systems, databases

and applications

Page 285: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 285

3.15 BUSINESS APPLICATION SYSTEMS

Risk Management Controls for E-Banking:

8. Data integrity of e-banking transactions, records and information9. Establishment of clear audit trails for e-banking transactions10. Confidentiality of key bank information• Legal and reputational risk management:11. Appropriate disclosures for e-banking services12. Privacy of customer information13. Capacity, business continuity and contingency planning to

ensure availability of e-banking systems and services14. Incident response planning

Page 286: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 286

3.15 BUSINESS APPLICATION SYSTEMS

3.15.8 Electronic Finance:

Changing the face of the financial services industry, electronic finance (e-finance) is enabling new providers to emerge within and across countries, including online banks, brokerages and companies that allow consumers to compare financial services, such as mortgage loans and insurance policies. Advantages of this approach to consumers are:

• Lower costs• Increased breadth and quality• Widening access to financial services• A-synchrony (time-decoupled)• A - topy (location-decoupled)

Page 287: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 287

3.15 BUSINESS APPLICATION SYSTEMS

3.15.9 Payment Systems:

There are two types of parties involved in all payment systems, the issuers and the users. An issuer is an entity that operates the payment service. An issuer holds the items that the payments represent (e.g., cash held in regular bank accounts). The users of the payment service perform two main functions—making payments and receiving payments—and therefore can be described as a payer or a payee respectively.

Page 288: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 288

3.15 BUSINESS APPLICATION SYSTEMS

3.15.9 Payment Systems (Electronic Money Model):

The objective of electronic money systems is to emulate physical cash. An issuer attempts to do this by creating digital certificates, which are then purchased (or withdrawn) by the users, who then redeem (deposit) them with the issuer at a later date. In the interim, certificates can be transferred between users to trade for goods or services.

Page 289: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 289

3.15 BUSINESS APPLICATION SYSTEMS

3.15.9 Payment Systems (Electronic Money Model):

Some advantages of electronic money systems are:

• The payer does not need to be online (generally) at the time of the purchase (since the electronic money can be stored on the payer’s computer).• The payer can have unconditional untraceability (albeit at the expense of lost interest on deposits).

Page 290: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 290

3.15 BUSINESS APPLICATION SYSTEMS

3.15.9 Payment Systems (Electronic Checks Model):

Electronic check systems model real-world checks quite well and are, thus, relatively simple to understand and implement. A user writes an electronic check, which is a digitally signed instruction to pay.

Some advantages of electronic check systems are: • Easy to understand and implement • The availability of electronic receipts, allowing users to resolve

disputes without involving the issuer• No need for payer to be online to create a payment

Page 291: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 291

3.15 BUSINESS APPLICATION SYSTEMS

3.15.9 Payment Systems (Electronic Transfer Model):

Electronic transfer systems are the simplest of the three payment models. The payer simply creates a payment transfer instruction, signs it digitally and sends it to the issuer. The issuer then verifies the signature on the request and performs the transfer. This type of system requires the payer to be online, but not the payee.

Some advantages of electronic transfer systems are: • Easy to understand and implement • The payee does not need to be online, a considerable advantage in some circumstances (e.g., paying employee wages)

Page 292: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 292

3.15 BUSINESS APPLICATION SYSTEMS

3.15.10 Integrated Manufacturing Systems:

Integrated manufacturing systems (IMS) have a long history, and accordingly, there has been quite a diverse group of models and approaches.

Some of the integrated manufacturing systems include bill of materials (BOM), BOM processing (BOMP), manufacturing resources planning (MRP), computer assised design (CAD), computer-integrated manufacturing (CIM), and manufacturing accounting and production (MAP).

Page 293: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 293

3.15 BUSINESS APPLICATION SYSTEMS

3.15.11 Electronic Funds Transfer:

As the Internet continues to transform commercial transactions, the method of payment is one bothersome concept that will take on an increasingly significant role in the relationship between seller and buyer. The underlying goal of the automated environment is to wring out costs inherent in the business processes. Electronic funds transfer (EFT) is the exchange of money via telecommunications without currency actually changing hands. In other words, EFT is the electronic transfer of funds between a buyer, seller and his/her respective financial institution.

Page 294: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 294

3.15 BUSINESS APPLICATION SYSTEMS

3.15.12 Controls in an EFT:

• All of the equipment and communication linkages are tested to effectively and reliably transmit and receive data. • Each party uses security procedures that are reasonably sufficient for affecting the authorized transmission of data and for protecting business records and data from improper access. • There are guidelines set for the receipt of data and to ensure that the receipt date and time for data transmitted are the date and time the data has been received.

Page 295: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 295

3.15 BUSINESS APPLICATION SYSTEMS

3.15.12 Controls in an EFT:

• Upon receipt of data, the receiving party will immediately transmit an acknowledgment or notification to communicate to the sender that a successful transmission occurred.• Data encryption standards are set.• Standards for unintelligible transmissions are set.• Regulatory requirements for enforceability of electronic data transmitted and received are explicitly stated.

Page 296: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 296

3.15 BUSINESS APPLICATION SYSTEMS

3.15.13 Integrated Customer File:

Integrated customer files provide details regarding all business relationships a customer maintains with an organization. The integration aids in customer analysis and marketing. An example of an integrated file is an integrated banking customer file. The file includes data regarding the customer loans, checking accounts, savings accounts and any certificates of deposit.

Page 297: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 297

3.15 BUSINESS APPLICATION SYSTEMS

3.15.14 Office Automation:

Currently, many offices use a variety of electronic devices and techniques to aid in the conduct of business. Word processors, automated spreadsheets and electronic mail are used daily in many offices. Local area networks link local offices and computers to facilitate the use of these technologies. Office automation devices and networks may contain sensitive data; however, access controls and security are frequently weak or nonexistent.

Page 298: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 298

3.15 BUSINESS APPLICATION SYSTEMS

3.15.15 Automated Teller Machine:

An automated teller machine (ATM) is a specialized form of the point-of-sale (POS) terminal that is designed for the unattended use by a customer of a financial institution. These customarily allow a range of banking and debit operations, especially financial deposits and cash withdrawals. ATMs are usually located in uncontrolled areas to facilitate easy access to customers after hours. This facility can be within a bank, across local banks and in banks outside a region. They are becoming known as retail EFT networks, transferring information and money over communication lines.

Page 299: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 299

3.15 BUSINESS APPLICATION SYSTEMS

3.15.15 Automated Teller Machine:

Recommended internal control guidelines for ATMs, apart from what has been provided for any EFT, include the following:

• Written policies and procedures covering personnel, security controls, operations, disaster recovery credit and check authorization, floor limits, override, settlement, and balancing• Reconciliation of all general ledger accounts related to retail EFTs and review of exception items and suspense accounts• Procedures for PIN issuance and protection during storage• Procedures for the security of PINs during delivery and the restriction of access to a customer’s

Page 300: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 300

3.15 BUSINESS APPLICATION SYSTEMS

3.15.15 Automated Teller Machine:

• Systems should be designed, tested and controlled to preclude retrieval of stored PINs in any nonencrypted form. • Controls over plastic card procurement should be adequate with a written agreement between the card manufacturer and the bank that details control procedures and methods of resolution to be followed if problems occur.• Controls and audit trails of the transactions that have been made in the ATM.

Page 301: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 301

3.15 BUSINESS APPLICATION SYSTEMS

Audit of ATM:

• Review measures to establish proper customer identification and maintenance of their confidentiality• Review file maintenance and retention system to trace transactions• Review exception reports to provide an audit trail• Review daily reconciliation of ATM machine transactions, including: – Review segregation of duties in the opening of ATM and recount of deposit – Review the procedures made for the retained cards• Review encryption key change management procedures

Page 302: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 302

3.15 BUSINESS APPLICATION SYSTEMS

3.15.16 Cooperative Processing Systems:

Cooperative processing systems are divided into segments so different parts may run on different independent computer devices. The system divides the problem into units that are processed in a number of environments and communicates the results among them to produce a solution to the total problem. The system must be designed to minimize and maintain the integrity of communication between the component parts and to use the most appropriate processor for each of the problem units.

Page 303: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 303

3.15 BUSINESS APPLICATION SYSTEMS

3.15.17 Voice Response Ordering Systems:

Voice response ordering systems are systems in which the user interacts with the computer over a telephone connection in response to verbal instructions given by the computer system. The customer communicates by using a tone-generating device, which might be the keypad of the telephone itself.

Page 304: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 304

3.15 BUSINESS APPLICATION SYSTEMS

3.15.18 Purchase Accounting Systems:

When financial transactions are processed, frequently they go through more than one system. In a department store, a sale is first processed in the sales accounting system, then processed by the accounts receivable system (if the purchase was by credit card) and, for either cash or credit sales, through the inventory system (when they are linked). That same sale might trigger the purchase accounting system to replace depleted inventory.

Page 305: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 305

3.15 BUSINESS APPLICATION SYSTEMS

3.15.18 Purchase Accounting Systems:

Most purchase accounting systems perform three basic accounting functions:

1. Accounts payable processing—Recording transactions in the accounts payable records2. Goods received processing—Recording details of goods received, but not yet invoiced3. Order processing—Recording goods ordered, but not yet received The computer may be involved in each of these activities, and the extent to which they are computerized determines the complexity of the purchase accounting system.

Page 306: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 306

3.15 BUSINESS APPLICATION SYSTEMS

3.15.19 Image Processing:

Image processing is computer manipulation of images. Some of the many algorithms used in image processing include convolution (on which many others are based), fast Fourier transform (FFT), discrete cosine transform (DCT), thinning (or skeletonization), edge detection and contrast enhancement.

Page 307: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 307

3.15 BUSINESS APPLICATION SYSTEMS

3.15.19 Image Processing:

Most businesses that perform image processing obtain benefits from using the imaging system. Examples of potential benefits are:

• Item processing (e.g., signature storage and retrieval)• Immediate retrieval via a secure optical storage medium• Increased productivity• Improved control over paper files• Reduced deterioration due to handling• Enhanced disaster recovery procedures

Page 308: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 308

3.15 BUSINESS APPLICATION SYSTEMS

3.15.20 Artificial Intelligence and Expert Systems:

Artificial intelligence is the study and application of the principles by which:

• Knowledge is acquired and used• Goals are generated and achieved• Information is communicated• Collaboration is achieved• Concepts are formed• Languages are developed

Page 309: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 309

3.15 BUSINESS APPLICATION SYSTEMS

3.15.20 Artificial Intelligence and Expert Systems:

Artificial intelligence fields include, among others:• Expert systems • Natural and artificial (such as programming) languages • Neural networks • Intelligent text management • Theorem proving• Abstract reasoning• Pattern recognition• Voice recognition • Problem solving• Machine translation of foreign languages

Page 310: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 310

3.15 BUSINESS APPLICATION SYSTEMS

3.15.21 Business Intelligence:

Business intelligence (BI) is a broad field of IT that encompasses the collection and dissemination of information to assist decision making and assess organizational performance.

Investments in BI technology can be applied to enhance understanding of a wide range of business questions.

Page 311: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 311

3.15 BUSINESS APPLICATION SYSTEMS

3.15.21 Business Intelligence:

Some typical areas in which BI is applied for measurement and analysis purposes include:

• Process cost, efficiency and quality• Customer satisfaction with product and service offerings• Customer profitability, including determination of which attributes are useful predictors of customer profitability• Staff and business unit achievement of key performance indicators• Risk management, e.g., by identifying unusual transaction patterns and accumulation of incident and loss statistics

Page 312: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 312

3.15 BUSINESS APPLICATION SYSTEMS

3.15.21 Business Intelligence Governance:

To maximize the value an organization obtains from its BI initiatives, an effective BI governance process needs to be in place.

An important part of the governance process involves determining which BI initiatives to fund, what priority to assign to initiatives and how to measure their return on investment. This is particularly important, as the investment needed to build BI infrastructure, such as a data warehouse (DW), is considerable. Additionally, the scope and complexity of an organization wide DW means that, realistically, it must be built in stages.

Page 313: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 313

3.15 BUSINESS APPLICATION SYSTEMS

3.15.22 Decision Support Systems:

A decision support system (DSS) is an interactive system that provides the user with easy access to decision models and data from a wide range of sources, to support semi structured decision-making tasks typically for business purposes.

Page 314: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 314

3.15 BUSINESS APPLICATION SYSTEMS

3.15.22 Decision Support Systems:

Typical information that a decision support application might gather and present would be:

• Comparative sales figures between one week and the next • Projected revenue figures based on new product sales assumptions • The consequences of different decision alternatives, given past experience in the described context

Page 315: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 315

3.15 BUSINESS APPLICATION SYSTEMS

DSS FrameWorks:

1. The degree of structure in the decision process being supported2. The management level at which decision making takes place

Page 316: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 316

3.15 BUSINESS APPLICATION SYSTEMS

DSS FrameWorks:

This framework also portrays all information system efforts as addressing distinct types of problems, depending on the above two factors.

The management-level dimension is broken into three parts:1. Operational control2. Management control3. Strategic planningThe decision-structure dimension is also broken into three parts:1. Structured2. Semi structured3. Unstructured

Page 317: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 317

3.15 BUSINESS APPLICATION SYSTEMS

Risk Factors:

Developers should be prepared for eight implementation risk factors:

1. Nonexistent or unwilling users2. Multiple users or implementers3. Disappearing users, implementers or maintainers4. Inability to specify purpose or usage patterns in advance5. Inability to predict and cushion impact on all parties6. Lack or loss of support7. Lack of experience with similar systems8. Technical problems and cost-effectiveness issues

Page 318: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 318

3.15 BUSINESS APPLICATION SYSTEMS

Customer Relationship Management:

The emerging customer driven business trend is around the wants and needs of the customers. With the customer’s expectations constantly raising, these objectives are becoming more difficult to achieve. This emphasizes the importance of focusing on information relating to transaction data, preferences, purchase patterns, status, contact history, demographic information and service trends of customers, rather than on products.

Page 319: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 319

3.15 BUSINESS APPLICATION SYSTEMS

Customer Relationship Management:

It is possible to distinguish between operational and analytical CRM. Operational CRM is concerned with maximizing the utility of the customer’s service experience, while also capturing useful data about the customer interaction. Analytical CRM seeks to turn the data an organization has captured about its customers and their interactions with the organization into information that allows greater value to be obtained from the customer base. Among uses of analytical CRM are increasing customer product holdings or “share of customer wallet,” moving customers into higher margin products, moving customers to lower cost service channels, increasing marketing success rates, and making pricing decisions.

Page 320: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 320

3.15 BUSINESS APPLICATION SYSTEMS

Supply Chain Management:

SCM is about linking the business processes between the related entities, e.g., the buyer and the seller. The link is provided to all the connected areas, such as managing logistics and the exchange of information, services and goods between supplier, consumer, warehouse, wholesale/retail distributors and the manufacturer of goods.

Page 321: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 321

3.16 Chapter 3 Case Study

A major retailer asked the IS auditor to review their readiness for complying with credit card company requirements for protecting cardholder information. The IS auditor subsequently learned the following information. The retailer uses wireless point-of-sale registers that connect to application servers located at each store. These registers use wired equivalent protection (WEP) encryption. The application server, usually located in the middle of the store’s customer service area, forwards all sales data over a frame relay network to database servers located at the retailer’s corporate headquarters, and using strong encryption over an Internet virtual private network (VPN) to the credit card processor for approval of the sale. Corporate databases are located on a protected screened subset of the corporate local area network. Additionally, weekly aggregate sales data by product line is copied from the corporate databases to magnetic media and mailed to a third party for analysis of buying patterns. It was noted that the retailer’s database software has not been patched in over two years. This is because vendor support for the database package was dropped due to management’s plans to eventually upgrade to a new ERP system.

Page 322: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 322

  1. Which of the following would present the MOST significant risk to the retailer?

A. Wireless point-of-sale registers use WEP encryption.B. Databases patches are severely out-of-date.C. Credit cardholder information is sent over the Internet.D. Aggregate sales data are mailed to a third party.

PRACTICE QUESTIONSCASE STUDY

Page 323: Chap3 2007 Cisa Review Course

2007 CISA© Review Course © 2006 ISACA All rights reserved www.isaca.org Chap 3 - Pag - 323

  2. Based on the case study, which of the following controls would be the MOST important to implement?

A. Store application servers should be located in a secure area.B. Point-of-sale registers should use two-factor authentication.C. Wireless access points should use MAC address filtering.D. Aggregate sales data sent offsite should be encrypted.

PRACTICE QUESTIONSCASE STUDY