DISA MODULE III

Adv. Prashant Mali [BSc(Phy),MSc(Comp Sci),CNA,ISO 27001 LA,LLB]President – Cyber Law ConsultingBoard Member – Amity University’s Amity School of Cyber Crime and Cyber LawDirector on Board – National Security Database (A Govt of India Supported Project for hiring Ethical Hackers)Founder Faculty – DISA (ICAI)Speaker & Author

www.cyberlawconsulting.comwww.prashantmali.com

Module 3

There are three tasks within this content area:

• Evaluate the processes by which application systems

are developed and implemented in an organization.

• Evaluate the processes by which application systems

are acquired and implemented in an organization.

• Evaluate the processes by which application systems

are maintained in an organization.

Project Initiation

• A new opportunity that relates to a new or existing

business process

• A problem that relates to an actual business process

• A new opportunity that will enable the organization to

take advantage of technology

• A problem with current technology

IS Auditors Role

Formalize procedures and guidelines identifying each

phase of the system life cycle

Report independently to management on adherence to

planned objectives

May become involved in technical aspects on basis of

their skills and abilities.

Evaluate methods and techniques utilized in the systems

development project.

SSDM Feasibility StudyFeasibility Study

Requirements DefinitionRequirements Definition

Design / AnalysisDesign / Analysis AcquisitionAcquisition

ProgrammingProgramming CustomizationCustomization

Alpha TestingAlpha Testing

Beta TestingBeta Testing

ImplementationImplementation

Roles & Responsibilities1. Senior Management

2. User Management

3. Project Steering Committee

4. Project Sponsor

5. Systems Development Management

6. Project Manager

7. Project Team

8. User Project Team

9. Security Officer

10. Quality Assurance

Risks Development effort ends in failure

Does not meet users’ business needs

Exceeds limits of financial resources

Exceeds project deadlines

Incompatibility with existing systems

Competitive disadvantage

De-motivated employees

Calamities are of two kinds: misfortunes to ourselves, and good fortune to others. Ambrose Bierce

Feasibility Study Time frame for which the solution is required

Determine if a computerized solution is required or

desired.

Determine if existing system can correct the situation

with slight or no modification

Determine if vendor product offers solution to the

problem

Determine the approximate cost to develop the system

Determine if the solution fits the business strategy

Build or Buy

• Date by which the system is required to be functional

• Cost to develop the system as opposed to buying it

• Resources in manpower and hardware required

• Interfacing with other systems

Guidelines for Bureaucrats:

1. When in charge, ponder.

2. When in trouble, delegate.

3. When in doubt, mumble. -- James H. Borden

Requirements Definition• Define the problem or need that requires resolution

• Define major requirements of the solution system

• Define access controls

• Define management information needs

• General design of the system is developed and

presented to the user

• Project schedule for developing, testing and

implementing the system is developed.

• Commitments are gained from system developers and

users for contributing necessary resources.

Software Acquisition - RFP• System Requirements fulfilled by the product

• Customer References

• List of client sites

• Vendor financial stability

• Availability of complete and reliable documentation

• Vendor support

• Source code availability - escrow facility

• Number of years of experience in offering product

• List of planned enhancements to the product

• Acceptance testing is allowed before purchase

Software Acquisition Contract• Specific description of the deliverables, their costs, and

delivery dates

• Commitment for delivery of documentation, fixes,

upgrades, new release notifications and training

• Allowance for escrow arrangement for source code

• Provision of a reasonable acceptance testing period

before purchase decision is made

• Maintenance agreement

• Allowance for copying software for business continuity

efforts

• Payment schedule and penalty clauses, if any.

Acceptance Testing Use your data

See how many attempts it takes to install the software

correctly

Determine the responsiveness of the vendor staff

See what works as advertised - and what doesn’t.

Ask what your user’s think about the product’s usability

Does the product cause your client and/or server

systems to crash or lock up ?

Find out what performance is like in your environment.

SDLC

What is a Software Development Life Cycle?

There are three Generic Identifiable Phases

Definition Phase

Development Phase

Maintenance Phase

Definition Phase

Definition Phase focuses on – WHAT

What information is to be processed?

What functions and performance are desired?

What interfaces are to be established?

What design constraints exist?

What validation criteria are required to define a

successful system?

Development Phase

Development Phase focuses on – HOW

How data structures to be designed?

How S/W architectures are to be designed?

How procedure details are to be implemented?

How the design will be translated into code?

How testing will be performed?

Development Phase

Three specific steps in the Development Phase -

Design

Coding

Testing

Maintenance PhaseThe Maintenance Phase focuses on change that is

associated with –

Error Correction

Adaptation required as the software environment

evolves

Enhancements brought about by changing customer

requirements

Reengineering carried out for performance

improvements

Reapplying the steps of definition and development.

Normative Models To evaluate a systems development model, a

normative model is needed to undertake the

evaluation.

The actual practice is compared against this model to

identify discrepancies and to pinpoint where controls

are operating effectively or ineffectively.

There are many normative models - the standards

used by a small system developed by end users using

a high-level language must be different from those

applied to the development of a large, technologically

complex system.

SDLC - Waterfall ModelRequirements

Definition

RequirementsDefinition

High LevelAnalysis & Design

High LevelAnalysis & Design

Low LevelAnalysis & Design

Low LevelAnalysis & Design

Programming Programming

Unit Testing &Integration

Unit Testing &Integration

SystemTesting

SystemTesting

AcceptanceTesting

AcceptanceTesting

Waterfall ModelAdvantages

Simplicity

Explicitly defines intermediate products of each stage

Disadvantages

Too much planning required

Rigidity - Inability to adopt to change

Failure to accommodate developing technology

Requirements DefinitionRequirements Analysis and Specification Methods

Requirements analysis is the first technical step in the

software engineering process

Software scope refined into a concrete specification

It becomes the foundation for all future activities.

Role of SRS Bridge the communication gap between the client, the

user, and the developer.

Help clients in understanding their own needs.

The SRS must correctly define all the software

requirements, but no more.

The SRS should not describe any design, verification,

or project management details except design

constraints.

SRS Phase Activities Problem or Requirement Analysis

Understanding the problem, the goal and the

constraints

Requirement Specification

Specifying what has been found during analysis

SRS - Problem DefinitionUnderstanding the problem, the goal and the constraints

Boundaries of the system to be examined

Organizational and resource constraints

Tentative objectives of the new system

SRA - FASTFacilitated Application Specification Technique (FAST)

Creation of a joint team of customers and developers to

identify the problem

To propose elements of the solution

To negotiate different approaches

To specify a preliminary set of solution requirements

Best approach if Joint Application Development (JAD)

developed by IBM.

SRA - JADJoint Application Development Guidelines

Conduct meeting at a neutral site attended by

Developers and Customers

Rules for preparation and participation are established

A facilitator is appointed to control the meeting

A definition mechanism is used (flip charts, wall

stickers)

The goal is to identify problems, propose elements of

the solution, negotiate different approaches and specify

a preliminary set of solution requirements in a

supportive environment

SRA - ModelingModels are created to gain a better understanding of

the actual entity to be built. Models must be capable of

illustrating :

The information that the software transforms

The function

The sub-function

Behavior of the system

SRA - Partitioning Problems that are too large to be understood as a

whole are partitioned into segments that can be more

easily understood

Interfaces between these parts are established

Overall function or objective can be accomplished.

SRS - CharacteristicsCharacteristics of a good SRS :

Unambiguous

Complete

Verifiable

Consistent

Modifiable

Traceable

Usable during the operations & maintenance phase

SRS - Document1. Introduction

1.1 Purpose1.2 Scope1.3 Definition, Acronyms, and

Abbreviations1.4 References1.5 Overview

2. General Description2.1 Product Perspective2.2 Product functions2.3 User Characteristics2.4 General Constraints2.5 Assumptions and Dependencies

SRS - Document3. Specific Requirements

3.1 Functional Requirements

3.2 External Interface Requirements

3.3 User Interface Requirements

3.4 Performance Requirements

3.5 Design Constraints

3.6 Attributes

3.7 Other Requirements

Appendices

Index

SDLC - Analysis and Design1. Functional Specifications are finalized

2. Design Specifications are created

3. Data Flow Diagrams are created

4. Object Models are developed

5. System flowcharts are developed

6. Define all inputs from external environment

7. Develop data structures

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.

Design Considerations Design of Inputs

Design of Outputs

Design of Files

Design of Databases

Design of Procedures

Design of program specifications

User Interfaces Use cases can help perform task analysis to

understand the nature of the users work.

Include the capability for the user to cancel an interaction after it is started.

Give user multiple ways of accomplishing each action like closing a window or file.

Put highest priority information at upper left corner.

Emphasize readability by using active voice for communicating ideas

Limit the number of colours – too many colours will distract the user

Limit the use of fonts and avoid the use of ornate fonts.

Maintenance Methods

Maintenance is the last phase of the life cycle.

Defined as : Modification of a software product after

delivery, to correct faults, to improve performance or

other attributes, or to adapt the product to a modified

environment.

Accounts for the majority of cost spent on computer

software (50%)

Types of Maintenance

Corrective Maintenance – modification initiated by defects

– design errors, logic errors, or coding errors

Adaptive Maintenance – change driven by need to

accommodate modifications in the environment of the

software system. For example, government policy dictates

change to ECU and hence changes required in banking

software.

Types of Maintenance

Perfective Maintenance – changes undertaken to expand

existing requirements of a system; i.e. adding modules,

revising existing modules, etc.

Preventive Maintenance – prevent malfunctions or

improve maintainability of software; i.e. code

restructuring, optimization, document updating.

Maintainability

Maintainability is defined as the ease with which

software can be understood, corrected, adapted,

and/or enhanced.

Maintainability is one of the key concerns that should

guide the execution of all steps of the software

engineering process.

Maintainability when properly considered will enhance

the ease with which the product is maintained after

release.

Maintainability factors

Factors that control Maintainability

Disciplined and engineering approach to design,

coding, reviews, and testing

Good software configuration management

Availability of qualified staff

Understandable system structure

Ease of system handling

Use of standardized programming languages and

operating system.

Standardized structure of documentation.

What the User wanted

User-Centered Design

Traditional User-Centered

Technology driven User driven

Limited function teams Multidisciplinary teams

Component focus Solution focus

Coding first User validation first

Code defect view User view on quality

Limited focus Prime focus on usability

Focus on current Focus on current andcustomers future customers

V Model

RequirementsAnalysis

RequirementsAnalysis

System DesignSystem Design

Program DesignProgram Design

Coding Coding

SystemTesting

SystemTesting

Unit Testing &Integration

Unit Testing &Integration

Validate Requirements

Validate/VerifyDesign

AcceptanceTesting

Phased Development Model

DevelopedSystem 1.0

DevelopedSystem 1.0

Release 1.0Release 1.0

Developers

Users

DevelopedSystem 2.0

DevelopedSystem 2.0

Release 2.0Release 2.0

DevelopedSystem 3.0

DevelopedSystem 3.0

Release 3.0Release 3.0

Time

Phased Development ModelAdvantages

Markets created before complete development

Training and concepts can begin in an early release

Frequent releases help developers to swiftly fix other

unanticipated bugs

Focus on areas of expertise in different releases

Prototyping

Customer EvaluationOf Prototype

Customer EvaluationOf Prototype

CustomerSatisfied

CustomerSatisfied

Full scaleDevelopment

Full scaleDevelopment

RequirementsGathering

RequirementsGathering

QuickDesign

QuickDesign

BuildingPrototype

BuildingPrototype

RefiningPrototype

RefiningPrototype

Prototyping1. Get user requirements

2. Build a prototype with limited features - screens,

interactive edits, and sample reports

3. Get user feedback

4. Modify the prototype

5. Continue refining the prototype until user is satisfied

that it meets requirements

6. Once user acceptance is finalized, build the full scale

system.

A disciplined approach must be followed so that users

do not assume the prototype to be the end product.

RAD1. Small, well-trained development teams

2. Evolutionary prototypes

3. Integrated power tools

4. Central repository

5. Interactive requirements and design workshops

6. Rigid limits on development time frames

Reverse Engineering

1. It is the process of analyzing an existing program in an

effort to create a representation of the program at a

higher level of abstraction than source code.

2. Is performed when no specification other than the

code was developed for the product.

3. Is called the process of specification recovery or

design recovery.

It is always darkest before dawn.

So if you are going to steal your neighbor’s newspaper, that is the time to do it.

Re-Engineering

1. Associated technique of Reverse Engineering.

2. Examining and altering a target system to implement a

desired modification.

3. Consists of two steps: Reverse Engineering and

Forward Engineering

Big Bang ModelBy far, the simplest method of software development.

Final Product

Post Implementation Review

Good judgement comes from experience.

Experience comes from bad judgement.

1. Participation by Project

team and end users

2. Verification / Validation

3. Access Controls

4. ROI

5. What did we learn ?

Object-oriented System DesignOOSD or OOPS defines an object in terms of its

properties and the procedures governing their use.

Advantages:

1. Unrestricted variety of data types

2. Means to model complex relationships

3. Objects can be manipulated easily

4. Increased efficiency through re-usability of objects

Auditors Role - Systems Development Determine areas that require controls

Determine and rank major risks and exposures

Identify controls to mitigate risks and exposures

Advise regarding design and implementation of the controls

Monitor development process for implementation of the controls

Participate in post implementation reviews

Evaluate system maintenance standards and procedures

Test system maintenance standards and procedures

Evaluate the adequacy of production library security and integrity

Senior Management Commits to the project and approves the necessary

resources to complete the project within time and

budget restraints.

This commitment from senior management helps

ensure involvement by those needed to complete the

project.

Track Record Of Information

User Management Assumes ownership of the project and the resulting

system.

They allocate qualified representatives to the team.

The user management should take active interest in

the following functions:

System requirements definition

Acceptance testing

User training

Steering Committee Provides overall direction and ensures appropriate

representation of all relevant parties.

Senior representatives from each function affected by

the new system and the Project Manager should be part

of the Steering Committee.

It is responsible for the cost and the project timetables.

Rule of thumb - The greater the impact of the software

on the business, the higher the post of the management

representative on the Steering Committee.

Steering Committee functions Review project progress regularly and hold emergency

meetings when required.

Serve as coordinator and advisor - members of the

committee should be available to answer questions and

make user related decisions about the system and

program design.

Take corrective action - the committee should mark

progress and take action or make recommendations

regarding personnel changes on the project team, re-

planning budgets, etc.

In the worst case, the committee may recommend that

the project be halted.

Project Sponsor Provides funding for the project

The Project Sponsor is typically the senior manager in

charge of the business function affected by the

application.

Data and application ownership are assigned to the

project sponsor.

Works with the project manager to define success

parameters. It is crucial that success is translated to

measurable terms.

Systems Dev. Management Provides technical support for the hardware and software

environments and strategic direction.

Strategic system development issues:

Produce a product below a given cost

Increase task variety in the jobs supported by the system.

Maintain the existing organizational power structure

Systems Development Management assumes operating support and maintenance activities after installation.

Project Manager Provides overall direction of the project

Ensures project adheres to local standards

Ensures that deliverables are a quality product

Resolves inter-departmental conflicts

Monitors and controls cost and project timetable

Project Team Completes assigned tasks

Communicates effectively with the end users by

actively involving them in the development process.

Works according to local standards and user

requirements

Advises project manager of the necessary project plan

deviation.

User Project Team Should have major involvement in the requirements

analysis and user acceptance testing phases

The involvement should be continuous for the duration

of the project.

Advise the project manager on issues relating to user

interface design, performance criteria changes, etc.

Security Officer Has the responsibility of assuring that the systems

development life cycle design adheres to corporate

security policies

Tests system security prior to implementation

Receives adequate training on any new security

systems, procedures, or responsibilities after

implementation.

Quality Assurance Review that results and deliverables at the end of each

phase conform to requirements

The QA team should give their independent views, their

implications and impact on the development at the end

of the review.

The review should be carried out simultaneously with

the development work.

Generally the QA team is independent of the

development team.

Auditors Role - Feasibility Study

Review the documentation produced in this phase for

reasonableness

Determine that cost justifications are verifiable and show the

anticipated benefits to be realized

Identify and determine criticality of the need

Determine if a solution can be achieved with systems

already in place

Determine the reasonableness of the solution

Auditors Role - Requirements Definition Verify accuracy of RD document through interviews with

relevant user departments

Verify that affected user departments have adequate representation on the team

Verify that project costs have received proper management approval

Review the conceptual design specifications to ensure that they address the needs of the user.

Review the conceptual design specifications to ensure that control specifications have been defined.

Determine whether the application is a candidate for embedded audit routines. If so, request the routines to be incorporated in the conceptual design.

Auditors Role - Software Acquisition

Analyze the feasibility study document to determine that

the decision to acquire the solution was appropriate.

Review the RFQ to ensure that it covers all the items

listed.

Determine whether the vendor selected is supported by

the RFQ documentation.

Review the vendor contract prior to its signing to ensure

that it includes the items listed.

Ensure the contract is reviewed by legal counsel before it

is signed.

Functional RequirementsInputs

Source of Inputs

Quantity

Units of measurement

Timing

Ranges of valid inputs to include accuracy and

tolerances

Details of operator control requirements

Functional RequirementsProcessing

Validity checks on the input data

Exact sequence of operations to include timing of events

Responses to abnormal situations i.e. overflow, communication failure, error handling

Parameters affected by the operations

Requirements for degraded operation

Any methods i.e. equations, mathematical algorithms, logical operations, etc. used to transform system inputs into corresponding outputs

Functional RequirementsOutputs

Destination of the outputs

Quantity

Units of measurements

Timing

Range of valid outputs to include accuracy and tolerances

Deposition of illegal values

Error messages

Hardware Interfaces Logical characteristics of each interface between

software product and the hardware components of the system.

Devices supported and protocols

Software Interfaces Details of required software products to be used i.e.

data management system and operating systems and other applications

Purpose of interfacing software

Define in terms of message content and format

Performance Requirements Static Performance Requirements

Number of terminals supported

Number of simultaneous users supported

Number of files and records to be handled

Sizes of tables and files

Dynamic Performance Requirements

Number of transactions and tasks

Amount of data to be processed within certain time periods for both normal and peak workload conditions.

All these requirements must be stated in measurable terms.

Design Constraints

Standards Compliance

Report Format

Data Naming conventions

Accounting Procedures

Audit Tracing

Attributes Availability

Security

Restriction on certain commands

Control access to data

Provide different kinds of access requirements

for different people

Require the use of passwords

Cryptography techniques

Keep specific logs or history data sets

Maintainability

Transferability (from one environment to another)

Other Requirements Database operations

Various modes of operations

Periods of interactive operations and periods of unattended operations

Data processing support functions

Backup and recovery operations

Physical Data Flow Diagram

CentralMonitoring

UpdateLog

LocalMonitoring

Patient

Nurse

VitalSigns

Patientbounds

Patientdata

FormattedPatient

data

Patient Log

WarningMessage

ReportLogdata

Physical DFD

Advantages of Physical DFD

Describe interaction between physical components

which is easy to understand

Users relate to easily to them

Provide a way to validate and verify current view of the

system.

Logical DFD

Logical DFD is derived from the Physical version by :

Show actual data needed in a process not documents

that contain them.

Remove routing information to show flow between

procedures and not people/locations

Consolidate redundant data stores

Remove unnecessary processes

Logical DFD

Logical DFD explodes processes for more detail

Patient

Monitoring

System

Vital Signs Checking

Update Patient Logs

Corrective Action

Control Flow Model Not needed for all applications

Required for applications that are driven by events

rather than by data

When system produces control flow information rather

than reports and displays

When system processes information with a large

concern for timing and performance

Such cases require control flow modeling in addition to

DFD modeling.

Other Diagrams

Collaborative Diagram – elements of a system work

together to accomplish the systems objectives.

Component Diagram

Deployment Diagram – Physical architecture of

computer-based system and shows connections

between the devices.

Auditors Role - Design & Programming

Verify the system flowcharts for adherence to the general design.

Review the input, processing, and output controls designed into the system for appropriateness.

Interview key users of the system to assess their level of input into the design of interfaces.

Assess the adequacy of audit trails to provide traceability of system transactions.

Verify the integrity of key calculations and processes.

Verify that the system can identify and process erroneous data correctly.

Review the QA results of programs developed.

Verify that the recommended corrections to programming errors were made.

Auditors Role - Post Implementation

Determine end users utilization and overall satisfaction with the system.

Determine that the benefits identified in the feasibility study are being measured, analyzed and accurately reported to the management.

Review program change requests to assess the types of changes required in the system. These may point to problems in design, programming, or interpretation of user requirements.

Use the embedded audit routines to review the efficacy of the controls built into the system.

Review system error logs to determine if there are any resource problems.

OOPS

• Encapsulation

• Inheritance

• Polymorphism

OOPS - Data Types

OOPS - objects

Design ConsiderationsCoupling Strength of relations between modules Ideally must be very low or loose as this maximizes

independence between modules

How to achieve loose coupling? Control number of parameters passed between

modules Avoid passing unnecessary data to called modules Maintain superior/subordinate relationship between

calling and called modules Pass data not control information

Design ConsiderationsCohesion

Contents of a module are so designed that they

perform a specific function

The contents of a module can be studied on the

basis of the function performed, data used, logic, any

other characteristic.

Types of Cohesion :

Coincidental – Logical – Temporal – Procedural

– Sequential - Functional

Design Considerations

Span of Control

Refers to number of subordinate modules controlled

by a calling module.

Accepted practice of having not more than 5-7 sub-

modules called by a module.

Excessive span of control creates overhead in

determining which module to invoke, establish calling

sequences to pass data and obtain results.