Академический Документы
Профессиональный Документы
Культура Документы
Module 5
System development acquisition and maintenance
2
Salient features of ISA Course 2.0
Introduction
Secure SDLC
4
Learning Objectives
Understand basic concept of Systems development life cycle (SDLC)and how it has changed over a period of time due
to changes in technology and environment, that has prompted for adoption of additional phases in SDLC.
Steps added in different phases due to security requirements (Secure SDLC or SSDLC)
5
What is SDLC?
6
System Development life cycle (SDLC)
An information system
undergoes following steps:
• Conceptualization
• Feasibility
• Design and development
• Testing
• Implementation
• Use
• Retirement(replacement)
7
Organization of chapters
Chapter 1 provides the basic information about SDLC that is required for IS auditor and project
manager involved in SDLC activities. The chapter tries to answer why it is called life cycle? What
are typical activities or phases through which development happens? These activities have
undergone changes over a period of time and hence knowledge about these changes and security
requirements in SDLC are covered.
Chapter 2 focuses on actions organizations need to take when to initiating SDLC project. This
covers initial phases of SLDC covering feasibility study, requirement definition, expected benefits
to organization and developing business case for SDLC project. Decision about execution of next
phases is based on business case and hence it necessary to understand these activities. Phase 1
feasibility study and Phase 2 requirement definition of typical SDLC phases (discussed in chapter
1) are covered in this chapter (2).
8
Organization of chapters
Chapter 3 provides the basic knowledge on project management with focus on SDLC. Once the
organization has decided to initiate project for automated solution using SDLC, IS auditor may be
involved in reviewing project. Hence IS auditor need to have knowledge about SDLC project
management activities so as to audit the project or part of team. The contents are focused on Phase 3
and 4 for typical SDLC discussed in chapter 1. This chapter does not cover Project management in
general but focuses on practices required for executing SDLC project.
Chapter 4 introduces models and methods used for System design and development that goes
together. To ensure that final system meet business requirements, project manager and system analyst
need to decide upon development method for new application. IS auditor need to know basic
characteristics of these methods. All these methods have common objectives of application
development, with many stapes being similar.
9
Organization of chapters
Chapter 5 discusses software acquisition and outsourcing of development. In case organization has
decided to purchase the software that means phase 3, 4 and 5 of typical SDLC is not responsibility
of organization, but the accountability of actions cannot be outsourced. This chapter describes the
process for acquisition and/or outsourcing development, in case an organization has decided to
acquire software or outsourced development and provides inputs on controls to be adopted.
10
Organization of chapters
11
When is SDLC initiated?
When one or more of following situations arise:
12
What is SDLC?
A process of examining a business situation with the intent of
improving it through better procedures and methods.
13
Phases of typical SDLC
14
Phases of traditional SDLC
Feasibility Study
Requirement Definition/Analysis
System analysis
System Design
Development and programming
Testing
User Acceptance Testing
Implementation
Support and maintenance
15
Feasibility Study
16
Feasibility Study: Audit points
Review the documentation for the reasonableness
Review cost justification/benefits should be verified along with the schedule of
when the anticipated benefits will be realized.
Identify if the business need used to justify the system actually exists or not
18
Requirement definition: Audit points
Identify the affected users and the key team members on the project to verify
that they are having an appropriate representation.
Review the existing data flow diagrams and other related specifications like
transforms, data descriptions, etc., to ensure that they cover the user needs
19
System analysis
Understanding and analyzing requirements to define problem
Existing process Expectations and gaps
20
System Analysis: Audit points
Verify that the management has approved the initiation of the project and the
cost.
22
System Design: Audit points .. 1
Review the system flowcharts for adherence to the general design
Review the input , processing and output controls designed into the system are appropriate
Assess the adequacy of the audit trails which provide traceability and accountability
Verify the key calculations and processes for correctness and completeness
Interview the users to ascertain their level understanding of the system design, input to the
system , screen formats and output reports
23
System Design: Audit points .. 2
Verify that the system can identify erroneous data correctly and handles it invalid transaction
Review the Quality Assurance & Quality Control results of the programs developed during
the phase.
Verify that the design for its completeness and correctness and meets the requirements.
Verify that functional data created during requirement phase is complete and test plan has
been developed during this phase.
24
Development and Coding
Prepare Work breakdown for coding by team to transform design into
code/program/function/object for coding depending upon required functionalities and
hosting platform
25
Development and Coding
Reliable
Robust
Accurate
A good program must
be:
Efficient
Usable
Readable
26
Development: Audit points
User acceptance testing(UAT) also known as final acceptance testing (Is defined as separate phase
due to formalization of process
Intermittent testing:
• Unit testing
• Interface testing
• Integration testing
• System testing
• Regression testing
28
Testing : Audit points … 1
Review the test plan for completeness and correctness
Review error reports for their precision in recognizing erroneous data & for resolution of errors.
Verify cyclical processes for correctness( example: year -end process, quarter-end process)
Interview the end-users of the system for their understanding of the new methods, procedures and
operating instructions.
Review the system and end-users documentation to determine its completeness and correctness.
29
Testing : Audit points … 2
Reconciliation of control totals and converted data should be performed to check for the integrity of the
data after conversion
Review unit test plans and system test plans to determine that tests for internal control are addressed
Verify that the system security is functioning as designed by developing and executing access tests.
Ensure test plans and rest results are maintained for reference and audit
30
UAT
Utilization of
Definition of Design of test
Execution of the results to
test strategies cases and
the tests verify system
and procedures scenarios
readiness
Note: It is expected that the test plan, data and results are to be maintained
for subsequent audits. 32
UAT : Audit points
34
Implementation : Audit points
Determine that the formal acceptance has been signed by the Project development
team, user management, Quality Assurance, Security or Audit officer.
Verify that the system has been installed according to the organization’s change
control procedures
Review the programmed procedure used for scheduling and running the system
along with the system parameters used in executing the production schedule.
35
Implementation : Audit points
Verify all conversion of data to ensure that they are correct and
complete before implementing the system and user sign-off is
obtained in this regard.
36
Support and Operations
Determine if the cost benefits identified in the feasibility study are being measured.
Review the program change requests performed to assess the type of changes required of the system
Review the controls built into the system to ensure that they are operating to design.
Review operator’s error logs to determine if there are any resource or operating problems inherent with the
system. Logs may indicate the inappropriate planning or testing of the system prior to implementation.
Review input and output control balances and reports to verify that the system is processing data accurately.
38
Support and maintenance : Audit points … 1
Evaluate the adequacy of the organization’s procedures for authorizing,
prioritizing and tracking system changes.
Evaluate the adequacy of the organization’s procedures for dealing “emergency” program
changes.
Evaluate the adequacy of the security access restrictions over the use of the “emergency”
logon-ids.
Verify the existence and adequacy of the records for system changes.
40
Changes in SDLC
41
Revised SDLC phases
Options of product availability and Outsourcing of
development has introduced changes in SDLC phases.
Based on Decision after feasibility study, organization
selects one of the three path
SDLC Phase Outsourcing Product
Acquisition
Feasibility Study
Requirement Definition
Analysis Vendor selection Product selection
Design Requirement baseline RFP
Development Agreement and SLA Procurement and
contract
Testing Vendor follows SDLC Configuration
UAT
Implementation
Support and Maintenance 42
Make or Buy
Feasibility study takes into consideration ‘what is being done
in industry?’ Based on this information organization may
choose one of three options:
• Develop software using in-house resources
• Hire a third party vendor to develop the software (i.e.
outsource software development)
• Purchase customizable software that is available in market.
43
Make or Buy
Important Points:
44
Selection of Vendor / product
Product
Outsourcing
acquisition
(Phase 3B)
(Phase 3C)
45
Outsourcing (Phase 3B)
Organization may hire a third party firm having necessary skills and
experience to develop software specifically for organization’s use.
The third party shall follow SDLC process for development
46
Product acquisition (Phase 3C)
Identify various products
Select product
47
Requirement Finalization and RFP
Outsourcing (phase 4B)
Vendor may need to baseline the requirements to estimate the effort for arriving at commercials of proposal
Based on outcome of earlier gap analysis request for proposal is sent to product vendors/suppliers
48
Contract, SLA and Purchase
• Defining terms of contract for application development
Outsourcing • Defining terms for service levels for delivery, support
(Phase 5B) and maintenance
• Sign-off
Product
• Issuing purchase order based on proposal and accepted
acquisition terms of contract
(Phase 5C)
49
Development and Configuration
Outsourcing (Phase 6B) Product acquisition (Phase 6C)
51
What is Secure SDLC?
Embedding security in application development is referred as SSDLC or Secure SDLC
52
Additional tasks in SDLC for security
53
Requirement Definition
Security Steps
• Identify security requirements including compliance
for privacy and data loss
• Determine risks associated with security and prepare
mitigation plan
• Train users on identification and fixing of security bugs
54
Design Phase
Security Steps
55
Development Phase
Security Steps
• Develop and implement security coding
practices(e.g. input data validation, simple
coding)
• Train developers on security coding practices
56
Testing Phase
Security Steps
57
Implementation Phase
Security Steps
59
SDLC: Risk management
60
SDLC: Risk management
Typical Risk
62
Mitigation
Most risks can be mitigated by implementing best practices / standards for:
Suitable methodology
Project management Coding practices Automated tools And so on….
(Like Prototyping)
In order to mitigate risks in time, it is best to perform risk assessment during each
phase of SDLC.
63
Examples of mitigation .. 1
Risk Mitigation plan
Inaccurate Select prototyping model to finalize the requirements
requirements Meet various stake holders to confirm identified requirements
definition
Inappropriate Understand technical and performance requirements (e.g. user
selection of platform response time, number of transactions per second etc.) and determine
(hardware, operating technical specification of proposed platform
system, database
In case platform specifications are available (existing hardware); ensure
etc.)
that application development can address requirements.
Understand organization baseline for infrastructure and incorporate in
design
64
Examples of mitigation .. 2
Risk Mitigation plan
Compromise on Ensure standard coding practices are adopted
quality and testing Provide enough time for building test cases to cover all function,
resulting in bugs performance and security requirements
after implementation
Build test cases along with design
Missing or Ensure completion of documentation along with design and
incomplete development. Standardization of coding practice helps in this process
documentation Ensure documentation experts and technical writers are part of team
Absence of skilled Consider outsourcing or hiring skilled resources on contract
resources
65
Examples of mitigation .. 3
Risk Mitigation plan
Scope creep (changing Perform scope base lining
requirements) Introduce change management process to evaluate and adopt changes in
requirements
Poor coding Develop and implement standard coding practices
techniques
Inadequate Ensure technical writers and document specialist are part of team
documentation
Inadequate QC and Plan QA process along with project and development plan
QA (including testing Implement standard coding practices
inadequacies) Implement performance monitoring process
66
Examples of mitigation .. 4
Risk Mitigation plan
Lack of proper change Perform scope base lining
control and controls Introduce change management process to evaluate and adopt changes in
over promotion into requirements
production
Inappropriate Understand requirements and select appropriate development method
processes for suitable for identified requirements.
development
Technical Ensure integration and system testing are performed on target platforms
vulnerabilities, and
how these could
materialize and be
controlled/addressed
67
SDLC: Roles and responsibilities
68
SDLC: Roles and Responsibilities … 1
Steering Committee
Program Manager
Project Manager
69
Steering Committee
Systems Analyst
Module Leader/Team
Leader
Programmers
Database Administrator
(DBA)
73
Systems Analyst
The system analyst also has a
responsibility to understand existing
problem/system/data flow and new
requirements. System analysts convert
the user’s requirements in the system
requirements in order to design new
system.
74
Module Leader/Team Leader
75
Programmers
76
Database Administrator (DBA)
Domain
Specialist
78
Quality Assurance Team
80
Domain Specialist
Technology Specialist
Documentation Specialist
IS Auditor
82
Technology Specialist
As a member of the
team, IS auditor can
ensure that controls
required for process for
which application is
being developed are
included in
requirements.
85
Summary
86
What we learned?
What is SDLC?
Secure SDLC
87
Questions
88
1. System development life cycle (SDLC)
primarily refers to the process of:
A. Developing IT based solution to improve business service delivery.
B. Acquiring upgraded version of hardware for existing applications.
C. Redesigning network infrastructure as per service provider’s needs.
D. Understanding expectations of business managers from technology.
Answer: A
SDLC primarily focuses on identifying IT based solution to improve
business processes delivering services to customers. Other activities may
be part of SDLC however, these are IT projects not SDLC projects.
89
2. Organizations should adopt programming/coding
standards mainly because, it:
A. is a requirement for programming using high level languages.
B. helps in maintaining and updating system documentation.
C. is required for security and quality assurance function of SDLC.
D. has been globally accepted practice by large organizations.
Answer: C
Adopting coding standards helps organization in ensuring quality of coding
and in minimizing the errors. It also helps in reducing obvious errors which
may lead to vulnerabilities in application. A is not true since it is required for
all languages; B is partially true but is not the main reason. D is not main
reason.
90
3. Which of the following is main reason to
perform User acceptance testing (UAT)?
A. To train and educate users on features of new solution.
B. To confirm form users that solution meets requirements.
C. To complete formality of sign-off to mark end of project.
D. To finalize the implementation plan for new IT solution.
Answer: B
UAT is mainly conducted to confirm from the users and application owners
that application meets their requirements. Sign-off is a formality to be
completed only if requirements are met. Training and implementation
planning are different activities which are not dependent on UAT.
91
4. An organization decided to purchase a configurable application
product instead of developing in-house. The outcome of which of the
following SDLC phase helped organization in this decision?
A. Requirement definition
B. Feasibility Study
C. System analysis
D. Development phase
Answer: B
Make or buy decision is the outcome of feasibility study where
technical, economical and social feasibilities are considered.
92
5. In which of the following phases of SDLC,
controls for security must be considered FIRST?
A. Requirement definition
B. Feasibility study
C. System design
D. Implementation
Answer: C
Security requirements must be considered during requirement definition.
However, the nature of controls to be implemented for security must be
considered first during design phase. This will ensure that necessary security
controls are built while developing application. Security controls are
implemented and not designed during implementation phase.
93
6. IS auditor has been part of SDLC project team. Which of the
following situation does not prevent IS auditor from performing
post implementation review? The IS Auditor has:
A. designed the security controls.
B. implemented security controls.
C. selected security controls.
D. developed integrated test facility.
Answer: D
Active role of IS auditor in design and development of controls affects the
independence. Hence, IS auditor cannot perform review or audit of the
application system. However, developing integrated test facility within
application is not a control, but a facility to be used by auditors in future.
Hence, this does not impact independence of IS auditor
94
Additional References
Please refer to the following documents for more information:
Highlights of ISA Course 2.0
Body of Knowledge of ISA course 2.0
Frequently asked Questions on ISA Course 2.0
ISA Course 2.0 DVD
www.cit.icai.in
www.icai.org
www.isaca.org
95
Thank you!
Questions?
Email: cit@icai.in
96