Upload
isabella-norman
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
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?
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.
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
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.
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.