Module 3
Module 3
MANAGEMENT
MODULE 3
IMPORTANTCE OF RISK MANAGEMENT
INTEGRATION OF RISK MANAGEMENTIN SDLC
RISK ASSESSMENT
THREAT IDENTIFICATION
VULNERABILITY IDENTIFICATION
CONTROL ANALYSIS – IMPACT ANANLYSIS
RISK DETERMINATION- RISK LEVEL MATRIX – CONTROL RECOMMEDATIONS
Risk Management
Risk is the potential for a problem that can cause the loss of something valuable.
Unnecessary risk can cost you time and money, especially in the IT industry where most
software projects have some element of risk Source
Risk management is the process of identifying, assessing and controlling threats to an
organization's capital and earnings.
These threats, or risks, could stem from a wide variety of sources, including financial
uncertainty,
◦ legal liabilities,
◦ strategic management errors,
◦ Accidents &
◦ Natural disasters.
Risk Management
IT security threats and data-related risks, and the risk management strategies to alleviate
them, have become a top priority for digitized companies.
As a result, a risk management plan increasingly includes companies' processes for identifying
and controlling threats to its digital assets, including proprietary corporate data, a customer's
personally identifiable information (PII) and intellectual property.
What Is Risk In Software Engineering?
Very simply, a risk is a potential problem.
◦ It’s an activity or event that may compromise the success of a software development project.
◦ Risk is the possibility of suffering loss, and total risk exposure to a specific project will account for both
the probability and the size of the potential loss.
1. End user requirements are obtained through documentation, client interviews, observation and questionnaires
2. Pros and cons of current system are identified so as to avoid the cons and carry forward the pros in the new system.
3. Any Specific user proposals are used to prepare the specifications and solutions for the shortcomings discovered in
step two are found.
Support from Risk Management Activities –
Identify assets that need to be protected and assigning their criticality in terms of confidentiality, integrity and
availability
Identify threats and resulting risk to those assets
Determine existing security controls to reduce that risks
2. System analysis and
requirement definition:
Five sub phases
1. Feasibility study
2. requirement elicitation
3. requirement analysis
4. requirement validation
5. requirement documentation
3. System Design:
This is the second phase of SDLC wherein system architecture must be established and all
requirements that are documented needs to be addressed.
In this phase the system (operations and features) is described in detail using screen layouts,
pseudocode, business rules, process diagrams etc.
Support from Risk Management Activities –
◦ Accurate Classification of assets criticality
◦ Planned controls accurately identified
3. System Design:
1. Examine requirement Document – It is quite important for the developers to be a part of
examining requirement document to ensure understandability of requirements listed in
requirement document.
Risk Factors –
RD is not clear for developers: It is necessary for the developers to be involved in requirements
definition and analysis phase otherwise they won’t be having a good understanding of the
system to be developed. They will be unable to start designing on solid understanding of the
requirements of the system. Hence will land up creating a design for the system other than the
intended one.
3. System Design:
2. Choosing the architectural design method activity – It is method to decompose system into
components. Thus it is a way to define software system components. There exist many methods
for architectural design like structured object oriented, Jackson system development and formal
methods. But there is no standard architectural design method.
Risk Factors –
Improper Architectural Design method: As discussed above there is no standard architectural
design method, one can choose most suitable method depending upon the project’s need. But
it is important to choose method with utmost care. If chosen incorrectly it may result in
problems in system implementation and integration. Even if implementation and integration are
successful it may be possible that the architectural design may not work successfully on current
machine. The choice of programming language depends upon the architectural model chosen.
3. System Design:
3. Choosing the programming language activity –Choosing programming language should be
done side by side with architectural method. As programming language should be compatible
with the architectural method chosen.
Risk Factors –
Improper choice of programming language: Incorrect choice of programming language may
not support chosen architectural method. Thus may reduce the maintainability and portability
of the system.
3. System Design:
4.Constructing physical model activity – The physical model consisting of
symbols is a simplified description of hierarchical organized system.
Risk Factors –
Complex system: If the system to be developed is very large and complex then it will create problems for
developers. as developers will get confused and will not be able to make out from where to start and how
to decompose such large and complex system into components.
Complicated design: For a large complex system it may be possible due to confusion and lack of enough
skills, developers may create a complicated design, which will be difficult to implement.
Large size components: In case of large size components that are further decomposable into sub
components, may suffer difficulty in implementation and also poses difficulty for assigning functions to
these components.
Unavailability of expertise for reusability: Lack of proper expertise to determine the components that can
be reused pose a serious risk to project. As developing components from scratch takes lot of time in
comparison to reusing the components. Thus delaying the projection completion.
Less reusable components: Incorrect estimation of reusable components during analysis phase leads to
two serious risk to the project- first delay in project completion and second is budget over run. Developers
will be surprised to see that the percentage of the code that was considered ready, needs to be rewritten
from scratch and it will eventually make project budget over run.
3. System Design:
5. Verifying design activity – Verifying design means to ensure that the design is the correct
solution for the system under construction and it meets all user requirements.
Risk Factors –
Difficulties in verifying design to requirements: Sometimes it is quite difficult for the developer
to check whether the proposed design meets all user requirements or not. In order to make
sure that design is correct solution for the system it is necessary that design meets all
requirements.
Many feasible solutions: When verifying design, developer may come across many alternate
solutions for the same problem Thus, for choosing best possible design that meets all
requirements is difficult. Choice depends upon the system and its nature.
Incorrect design: While verifying design it might be possible that the proposed design either
matches few requirements or no requirement at all. It may be possible that it is a completely
different design.
3. System Design:
6 Specifying design activity – This activity involves following main tasks: Identify the components
and defines data flow between them
For each identified component state its function, data input, data output and resource utilization.
Risk Factors –
Difficulty in allocating functions to components: Developers may face difficulty in allocating
functions to components in two cases- first when the system is not decomposed correctly and
secondly if the requirement documentation is not done properly them in that case developers will
find it difficult to identify functions for the components as functional requirements constitute the
functions of the components.
Extensive specification: Extensive specification of module processing should be avoided to keep
design document as small as possible.
Omitting data processing functions: Data processing functions like create, read are the operations
that components perform on data. Accidental omission of these functions should be avoided.
3. System Design:
7. Documenting design activity - In this phase design document(DD) is prepared. This will help
to control and coordinate the project during implementation and other phases.
Risk Factors –Incomplete DD: Design document should be detailed enough explaining each
component, sub components, sub sub components in full detail so that developers may work
independently on different modules. If DD lacks this features then programmers cannot work
independently.
◦ Inconsistent DD: If same function is carried out by more than one component. Then in that case it will
result in redundancy in design document and will eventually result in inconsistent document.
◦ Unclear DD: If the design document do not clearly define components and is written in uncommon
natural language, then in that case it might be difficult for the developers to understand the proposed
design.
◦ Large DD: Design document should be detailed enough to list all components will full details about
functions, input, output, resources required etc. It should not contain unnecessary information. Large
design document will be difficult for the programmers to understand .
4. Development:
This stage involves the actual coding of the software as per the agreed upon requirements
between developer and client.
Support from Risk Management Activities –All designed controls are implemented during this
stage.
This phase involves two steps:
Coding
Unit Testing.
4. Development: Coding Activity
Coding Activity – This step involves writing the source code for the system to be developed. User interfaces are developed
in this step. Each developed module is then tested in unit testing step.
Risk Factors :
◦ Unclear design document: If the design document is large and unclear it will be difficult for the
programmer to understand the document and to find out from where to start coding.
◦ Lack of independent working environment: Due to unclear and incomplete design document it is
difficult for the team of developers to assign independent modules to work on.
◦ Wrong user interface and user functions developed: Incomplete, inconsistent and unclear design
documents leads to wrongly implemented user interface and functions. Poor user interface reduces
the acceptability of the system in the real environment among the customers.
◦ Programming language incompatible with architectural design: choice of architectural method solely
drives the choice of programming language. They must be chosen in sequence otherwise if
incompatible, programming language may not work with the chosen method.
◦ Repetitive code: In large projects there arises need to rewrite the same piece of code again and again.
This consumes lot of time and also increase lines of code.
◦ Modules developed by different programmers: In large projects, modules are divided between the
programmers. But different programmer has a different style and way of thinking. This lead to a
inconsistent, complex and ambiguous code.
4. Development: Unit Testing Activity
Unit Testing Activity – Each module is tested individually to check whether it meets the specified requirements or not
and perform the functions it is intended to do
Risk Factors –
◦ Lack of fully automated testing tools: Even till today unit testing is not fully automated. This makes
testing process boring and monotonous. Testers don’t bother to generate all possible test cases.
◦ Code not understandable by reviewers: During unit testing, developers need to review and make
changes to the code. If the code is not understandable it will be very difficult to update the code.
◦ Coding drivers and stubs: During unit testing, modules need data from other module or need to pass
data to other module. As no module is completely independent in itself. Stub is the piece pf code
that replaces the module that accepts data from module being tested. Driver is the piece of code
that replaces the module that passes data to the module being tested. Coding drivers and stubs
consumes lot of time and effort. Since these will not be delivered with the final system so these are
considered extras.
◦ Poor documentation of test cases: Test cases need to be documented properly so that these can be
used in future.
◦ Testing team not experienced: Testing team is not experienced enough to handle the automated
tools and to write short concise code for drivers and stubs.
◦ Poor regression testing: Regression testing means to rerun all successful test cases when a change is
made. This saves time and effort but it can be time consuming if all test cases are selected for rerun.
5. Integration and System Testing:
n this phase, first all modules are independently checked for errors, bugs. Then they are
related with their dependents and dependency is checked for errors and finally all modules are
integrated into one complete software and checked as a whole for bugs.
Support from Risk Management Activities –
In this phase designed controls are tested to see whether they work accurately in integrated
environment.
This phase includes three activities:
Integration Activity,
Integration Testing Activity,
System Testing Activity.
5. Integration and System Testing:
Integration Activity – In this phase individual units are combined into one working system.
Risk Factors
Difficulty in combining components: Integration should be done incrementally else it will very
difficult to locate errors and bugs. The wrong sequence of integration will eventually hamper
the functionality for which the system was designed.
Integrate wrong versions of components: Developing a system involves writing multiple
versions of the same component. If incorrect version of the component is selected for
integration it may not produce the desired functionality.
Omissions: Integration of components should be done carefully. Single missed component may
result in error and bugs, that will be difficult to locate.
5. Integration and System Testing:
Integration Testing Activity – After integrating the components next step is to test whether the
components interface correctly and to evaluate their integration. This process is known as
integration testing.
Risk Factors –
◦ Bugs during integration: If wrong versions of components are integrated or components are
accidentally omitted, then it will result in bugs and errors in the resultant system.
◦ Data loss through interface: Wrong integration leads to a data loss between the components where
the number of parameters in the calling component do not match the number of parameters in the
called component.
◦ Desired functionality not achieved: Errors and bugs introduced during integration results in a system
that fails to generate the desired functionality.
◦ Difficulty in locating and repairing errors: If integration is not done incrementally, it results in errors
and bugs that are hard to locate. Even of the bugs are located, they need to be fixed. Fixing error in
one component may introduce error in other components. Thus it becomes quite cumbersome to
locate and repair errors.
5. Integration and System Testing:
System Testing Activity – In this step integrated system is tested to ensure that it meets all the
system requirements gathered from the users.
Risk Factors
◦ Unqualified testing team: Lack of good testing team is a major setback for a good software as testers
may misuse the available resources and testing tools.
◦ Limited testing resources: Time, budget, tools if not used properly or unavailable may delay project
delivery.
◦ Not possible to test in real environment: Sometimes it is not able to test system in the real
environment due to lack of budget, time constraints etc.
◦ Testing cannot cope up with requirements change: Users requirements often change during entire
software development life cycle, so test cases should be designed to handle such changes. If not
designed properly they will not be able to cope up with change.
◦ System being tested is not testable enough: If the requirements are not verifiable, then In that case it
becomes quite difficult to test such system.
6. Installation, Operation and Acceptance Testing:
This is the last and longest phase in SDLC. In this system is delivered, installed, deployed and
tested for user acceptance.
Support from Risk Management Activities –
The system owner will want to ensure that the prescribed controls, including any physical or
procedural controls, are in place prior to the system going live. Decisions regarding risks
identified must be made prior to system operation.
This phase involves three activities:
◦ Installation,
◦ Operation,
◦ Acceptance Testing.
6. Installation, Operation and Acceptance Testing:
Installation Activity – The software system is delivered and installed at the customer site.
Risk Factors –
◦ Problems in installation: If deployers are not experienced enough or if the system is complex and
distributed, then in that case it becomes difficult to install the software system.
◦ Change in environment: Sometimes the installed software system don’t work correctly in the real
environment, in some cases due to hardware advancement.
6. Installation, Operation and Acceptance Testing:
Operation Activity: Here end users are given training on how to use software system and its
services.
Risk Factors
New requirements emerge: While using system, sometimes users feel need to add new
requirements.
Difficulty in using system: Being a human it is always difficult in the beginning to accept a
change or we can say to accept a new system. But this should not go for a long otherwise this
will be a serious threat to acceptability of the system.
6. Installation, Operation and Acceptance Testing:
Acceptance Testing Activity -Delivered system is put into acceptance testing to check
Risk Factors –
◦ User resistance to change: It is human behavior to resist any new change in the surroundings. But for
the success of a new delivered system it is very important that the end users accept the system and
start using it.
◦ Too many software faults : Software faults should be discovered earlier before the system operation
phase, as discovery in the later phases leads to high cost in handling these faults.
◦ Insufficient data handling: New system should be developed keeping in mind the load of user data it
will have to handle in real environment.
◦ Missing requirements: while using the system it might be possible that the end users discover some of
the requirements and capabilities are missing.
◦ whether it meets all user requirements or not.
7. Maintenance:
In this stage, the system is assessed to ensure it does not become obsolete. This phase also
involves continuous evaluation of the system in terms of performance and changes are made
time to time to initial software to make it up-to date.
Errors, faults discovered during acceptance testing are fixed in this phase. This step involves
making improvements to the system, fixing errors, enhancing services and upgrading software.
Support from Risk Management Activities –
Any change to a system has the potential to reduce the effectiveness of existing controls, or to
otherwise have some impact on the confidentiality, availability, or integrity of the system. The
solution is to ensure that a risk assessment step is included in evaluating system changes.
Risk Factors –
◦ Budget overrun: Finding errors and fixing them involves repeating few steps in SDLC again. Thus
exceeding the budget.
◦ Problems in upgrading: Constraints from end user or not so flexible architecture of the system forces it
to be not easily maintainable.
8. Disposal:
In this phase, plans are developed for discarding system information, hardware and software to
make transition to a new system. The purpose is to prevent any possibility of unauthorized
disclosure of sensitive data due to improper disposal of information. All of this should be done
in accordance with the organization’s security requirements.
Support from Risk Management Activities –
Risk Management plan developed must also include threats to confidentiality of residual data,
proper procedures and controls to reduce risk of data theft due to improper disposal. However,
by identifying the risk early in the project, the controls could be documented in advance
ensuring proper disposition.
Risk Factors
◦ Lack of knowledge for proper disposal: Proper disposal of information requires a experienced team,
having a plan on how to handle the residual data.
◦ Lack of proper procedures: Sometimes in hurry to launch a new system, organization sidelines the task
of disposal. Procedures used to handle residual data should be properly documented, so that they can
be used in future.
Types of Risks in Software Development and
How to Deal with Them
6. Human Resource
While working with people, someone may unexpectedly become unavailable. This person
may be a vital member of the team, which has the chance of creating a variety of risks,
starting from a simple knowledge gap to ending with an extended timeline and overspent
budget.
The person may be from the development team or the client-side, actively involved in the
project.
It is critical for your team to maintain proper documentation of every detail of the project.
Software development documentation is an active and continuous process.
Types of Risks in Software Development and
How to Deal with Them
7. Communication Risks
Just like in any other project, a breakdown in
communication during software development is
disastrous. Effective team risk management strategies are
essential in ensuring project success, and one critical
aspect to consider is the potential for communication
breakdown.
A breakdown in communication within the development
team can lead to delays and lower productivity
Regular meetings of all stakeholders are an excellent way
to keep everyone engaged and communication flowing
Threat Modelling and Threat Analysis
Threat modeling is a process of predicting all potential threats to an organization's
ecosystem and the vulnerabilities at risk of being explored by them.
,
Threat analysis, however, focuses on how an attacker could exploit vulnerabilities in order
to gain access to resources or sensitive data.
The two processes have overlapping approaches that together to achieve the same threat
mitigation goal.
Threat modeling is heavily dependent on metrics such as mean time between failure
(MTBF) when calculating vulnerability severity, whereas threat analysis will take into
account factors such as attack vector complexity when assessing the likelihood of
exploitation.
A more concise summary of the difference is Threat Modelling is more theoretical in nature
while Threat Analysis requires a technical understanding.
Threat Modelling - with an
O - Levelexample
DFD
1- level DFD
10 Threat Modelling Methodologies
1. STRIDE
The STRIDE methodology is used as a framework in Microsoft's Threat Modelling Tool.
The term STRIDE is a mnemonic for the different tenants of the methodology:
◦ S - Spoofing: When a threat assumes a false identity. This violated the Authentication property.
◦ T - Tampering: The modification of system data to achieve malicious goals. This violates the Integrity property.
◦ R - Repudiation: An intruder's ability to deny malicious activity in the absence of sufficient proof. This violates the
non-repudiation property.
◦ I - Information Disclosure: The exposure of information an intruder it not authorized to access. This violates the
confidentiality property.
◦ D - Denial of Service: An adversary exhausts system resources through malicious means. This violates the availability
property.
◦ E - Elevation of privilege - The execution of commands beyond the jurisdiction of account privileges. This violates the
authorization property.
10 Threat Modelling Methodologies
2. P.A.S.T.A
The Process for Attack Simulation and Threat Analysis (PASTA). Is a risk-centric methodology consisting of
seven steps. The process offers dynamic threat enumeration and assigns each of them a score.
The PASTA methodology opens threat modelling to the strategic input of stakeholders. It's very effective at
identifying commonly overlooked exploitation scenarios because it creates an attacker-centric produce asset-
centric outputs.
.
10 Threat Modelling Methodologies
3. Trike
Trike is a security auditing framework that turns a threat model into a risk management tool. A Trike audit begins by creating a matrix
summarizing the relationships between actors, actions, and assets.
The column of this matrix represents system assets and the rows represent actors. Each element of the matrix is divide into four parts
representing the actions of CRUD:
◦ Creating
◦ Reading
◦ Updating
◦ Deleting
Each element of this matrix is then mapped to actors and assets with a Data Flow Diagram (DFD) to identify any threats. An attack tree i
then created with all discovered threats becoming root nodes.
The goal is to assign each actor a score based on level of risk (0= no risk and 5 = maximum risk) for each action, or asset interaction. Each
action should be assigned a permission rating - always, sometimes, or never).
10 Threat Modelling Methodologies
4. VAST
◦ The Visual, Agile, and Simple Threat (VAST) model is a security method that assumes the attacker has an unlimited
number of ways to attack. It was developed by Bruce Schneier, a well-known American cryptographer.
◦ The VAST model allows security teams to assess risk from two different perspectives - architectural and operational.
◦ Architectural threat models are represented through process-flow diagrams and operational threat models are
represented through Data Flow Diagrams.
10 Threat Modelling Methodologies
5. Attack Trees
An attack tree started with a root node
denotes an attacker's primary objective
and children nodes that branch off it.
Each child node represents a condition
that makes the parent node a possibility.
These child nodes can further branch out
into "AND" and "OR" conditions.
10 Threat Modelling Methodologies
6. CVSS
The Common Vulnerability Scoring System (CVSS) was developed by NIST. It classifies each
vulnerability by a severity score out of 10, with 10 being the most critical. The CVSS provides a
standardized scoring system for all network vulnerabilities.
The NIST publishes a regularly updated list of CVEs that organizations can use to optimize
their threat mitigation efforts.
10 Threat Modelling Methodologies
7. O.C.T.A.V.E
The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) method is a risk-based assessment.
OCTAVE focuses on organizational risks and not technological risks.
◦ This method combines STRIDE, attack trees, and CVSS methods. This method is ideal of systems with specific
interdependencies between components.
◦ First, attack trees are created for each STRIDE category to map a relationship between attack categories and
attack tree components. Then, each of these components is assigned a severity score with the CVSS method.
10 Threat Modelling
Methodologies
9. D.R.E.A.D
This method is last in this list since its effectiveness as a threat model has been called into question.
Microsoft discontinued using DREAD in 2008 due to inconsistent ratings.
The DREAD model uses 5 categories to rank each security risks:
◦ Damage Potential: Ranks the damage quotient caused by an exploited weakness.
◦ Reproducibility: Ranks how easily a cyberattack and be reproduced.
◦ Exploitability: Rates the difficulty of launching a specific cyber attack.
◦ Affected Users: Assigns a value representing the number of users impacted if an exploitation is proliferated.
◦ Discoverability: Assigns a value denoting how easy it is to discover a given threat.
10 Threat Modelling
Methodologies
10. MITRE
◦ MITRE ATT&CK is a framework for cybersecurity, that breaks down the lifecycle of an attack into 14 stages (called
“Tactics” by MITRE).
◦ Each stage has its own set requirements but still following six overarching themes:
◦ Pre-attack planning;
◦ Post-attack features
◦ Adversary interaction/behavioral analysis;
◦ Tools and techniques used (i.e., what malware was deployed)
◦ Intelligence gathering after an incident has been detected
◦ Application log review
◦ MITRE ATT&CK does not cover a comprehensive list of all cyberattack methods, but it offers a simple checklist for
a quick assessment of potential vulnerabilities in your system.