Secure Software Development
Chapter 2
Rasool Jalili & M.S. Dousti
Dept. of Computer Engineering
Spring 2012
A Risk Management
Framework
•
•
•
•
No noble thing can be done without risks.
Security is risk management
A continuous risk management process is a necessity.
Following the RMF is a full lifecycle activity,
– no matter whether you're working on a little project or
– a huge corporate application strategy.
• The basic idea is simple: identify, rank, track, and understand
software security risk as it changes over time.
• Central to the notion of risk management is the idea of describing
impact.
• There is nothing more frustrating to a technical person than
identifying a serious problem that never gets fixed.
• We can avoid that frustration by properly describing impact.
• RMF allows a consistent and repeatable expertise-driven approach to
risk management.
• Application of RMF in parallel with standard SDLC activities.
• For a small project, the RMF can be applied by a part-time team
member.
• The RMF can be applied even in non-software situations.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Fall 2010
Software Security 2
SWS
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 3
The Five Stages of
Activity
• Five fundamental activities.
– Understand the business context
– Identify the business and technical risks
– Combine and prioritize the risks, producing a
ranked set
– Define the risk mitigation strategy
– Carry out required fixes and validate that they
are correct
• RMF is a closed-loop process with five
basic activity stages, as mentioned.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 4
1: Understand the
Business Context
• Software risk management occurs in a
business context.
• Risks are unavoidable and are a necessary
part of software development.
• Commonly, business goals are neither
obvious nor explicitly stated.
• Business goals include but are not limited to
increasing revenue, meeting service-level
agreements (SLAs), reducing development
costs, and generating high return on
investment (ROI).
• to gather data to answer the all-important
Software Security 5
"Who cares?" question. )
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti
– Fall 2010
2: Identify the
Business &Technical
Risks
• Business risks directly threaten one or
more business goals.
• Business risks have impacts that include
– direct financial loss,
– damage to brand or reputation,
– violation of customer or regulatory constraints,
– exposure to liability, and
– increase in development costs.
• Risk management needs tying technical
risks to the business context in a
)
Software Security 6
meaningful way.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti
– Fall 2010
…
• Recognizing technical risks is a high-expertise
undertaking that usually requires years of
experience.
• Important to be able to discover and describe
technical risks and map them (through
business risks) to business goals.
• A technical risk is a situation that runs counter
to the planned design or implementation of
the system under consideration.
• Technical risks involve impacts such as
unexpected system crashes, avoidance of
controls, unauthorized data modification or
disclosure, and needless) reworkSoftware
of artifacts
Security 7
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti
– Fall 2010
3: Synthesize and
Rank the Risks
• Large numbers of risks will be apparent in almost
any given system.
• Identifying these risks is important, but it is the
prioritization of them that leads directly to creation
of value.
• The prioritization process must take into account
which business goals are the most important to the
organization.
• Typical risk metrics include but are not limited to
–
–
–
–
Risk likelihood,
Risk impact,
Risk severity, and
number of risks emerging and mitigated over time.
•Secure
Collection
and
display
ofDoustithese
metrics
be8
SW Development (SSD)
Grad. Course
(R. Jalili & M.S.
)
Software can
Security
– Fall 2010
Stage 4: Define the
Risk Mitigation
Strategy
• Technical analysts are pretty good at finding
technical problems, but not so good at
determining what to do about them.
• Nobody wants to hear about their problems
without hearing some suggested fixes. A risk
analysis is only as good as the mitigation
strategy it contains.
• It is always easier to break something than to
design something that can't be broken.
• Typical metrics to consider are financial in
nature and include estimated cost, ROI,
method effectiveness, and % of risk coverage.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 9
Stage 5: Carry Out
Fixes and Validate
• The central concern at this stage:
– to validate that software artifacts and
processes no longer bear unacceptable risk.
• This stage should define and leave in place
a repeatable, measurable, and verifiable
validation process that can be run from
time to time to continually verify artifact
quality.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 10
• Successful use of the RMF depends on
continuous and consistent identification
and storage of risk information as it
changes over time.
• The loop in the RMF shown in the Figure.
• Risk management is a continuous process.
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 11
Measurement
• One foundational approach that is critical to
any science is measurement.
• Look at this phrase:
“When you can measure what you are speaking
about, and express it in numbers, you know
something about it; but when you cannot measure
it, when you cannot express it in numbers, your
knowledge is of a meager and unsatisfactory kind: it
may be the beginning of knowledge, but ….”
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 12
Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti)
– Fall 2010
Software Security 13