Architecture (A2): SDL Activities and Best Practices 121
modeling/architecture security analysis process. The following criteria are
used to categorize your final list from this process:
• Fully mitigated threats: Threats that have appropriate counter-
measures in place and do not expose vulnerability or cause impact.
• Partially mitigated threats: Threats partially mitigated by one or
more countermeasures, which represent vulnerabilities that can only
partially be exploited and cause a limited impact.
• Nonmitigated threats: Threats that have no countermeasures and
represent vulnerabilities that can be fully exploited and cause an
impact
31
Now that you have categorized your threats in one of the three catego-
ries above, you have a choice to make concerning what strategy you are
going to pursue. Your choices of action will likely fall under one of the
following five options:
1. Do nothing: for example, hope for the best.
2. Inform about the risk: for example, warn your user population about
the risk.
3. Mitigate the risk: for example, by putting countermeasures in place.
4. Accept the risk: for example, after evaluating the impact of the
exploitation (business impact).
5. Transfer the risk: for example, through contractual agreements and
insurance.
32
Your decision as to which of the strategies listed above will be used will
depend on several factors:
• The impact an exploitation of a threat can have
• The likelihood of its occurrence
• The costs for transferring (i.e., costs for insurance) or avoiding (i.e.,
costs or losses due to redesign) it.
33
Risk in this sense is an identified threatening situation due to the
potential presence of an actor, motivation, and vulnerability with a sig-
nificant probability and business impact. The risk of a threat is not the
issue, but rather an identified risk that has been ranked in severity with a
122 Core Software Security
significant business consequence as the result of the outcome of a threat.
The probability of the threat is considered separately because it is affected
by the motivation of the actor and the specifics and external factors affect-
ing the vulnerability. Business impact is also a key element of risk that
is affected by both the type of actor, which can be state, industrial, or
criminal, and the specifics of the vulnerability. This can be visualized as
shown in Figure 4.9.
In this section we have shown some of the options and standard
methodologies that can be used to assess your threats, rank your risk, and
develop a risk mitigation plan. The process we have described is visualized
in Figure 4.10.
The bottom line is that risk assessment is about business risk and
results in trade-offs as it relates to security risk to the software, the system
it interacts with, and the overall business risk management strategy. It is
important for security professionals to know this, and that is why we have
included two popular overall business risk assessment methodologies that
focus on information security risk, specifically, OCTAVE and AS/NZS
ISO 31000:2009. As with the ecosystem the software is part of, the risk
assessment methodology used for secure software development will also
have points of intersection with the overall business risk management
methodology, and those areas need to be taken into account as part of the
software risk analysis.
Ultimately this will be a business decision. This is why one decision
may be to fix vulnerabilities only where the cost to fix is less than the
potential business impact that might result from exploitation of the vul-
nerability, or why another decision may be made to accept the risk when
the loss of some security controls (e.g., confidentiality, integrity, and
availability) risks only a small degradation of the service, not a loss of a
critical business function.
34
Threat
Probability
Business
Impact
Risk
Figure 4.9 Elements of risk.
Figure 4.10 A holistic approach for software security risk assessment.
ThreatModeling
x IdentifySecurityObjectives
x SurveytheApplication
Di
Architectural
Threat Analysis
Rankingof
Threats
RiskAnalysis
x
D
ecompose
i
t
x IdentifyThreats
x IdentifyVulnerabilities
Threat
Analysis
Threats
Risk
Miti
g
ation
g
Plan
124 Core Software Security
4.4 Open-Source Selection
There has been an increasing trend in the software industry over the last
few years to draw on the strengths of both open-source and proprietary
software to deliver the highest value at the lowest cost. The blend of both
is called “mixed source” and is becoming a dominant practice in industry.
Understanding and managing the licensing of your software assets will
be critical as open source becomes an ever-greater part of the software
develop ment landscape, but this is beyond the scope of our discussion
and will be handled by others on the software development team.
There is an ongoing debate as to whether open-source software
increases software security or is detrimental to it, but the bottom line is
that you are importing software into your software application or solu-
tion that your company did not develop or have security oversight over.
This will require an extensive review, typically called a third-party security
assessment, that will be conducted by your software security architect, a
third party, or a combination of both. While it may be tempting to rely
on tools and a cursory review of the open-source development processes,
without the proper training and experience it is easy to misinterpret
results, and difficult to create an actionable remediation strategy. That
is why senior software security architects or the third-party equivalent
must be involved in this review process. They have years of code security
auditing experience, routinely review and mitigate highly complex and
advanced software security and architectural challenges, know how to
identify and examine vulnerable points in design, and can uncover flaws
that may result in a security compromise. Without the proper training
and experience it is easy to misinterpret results, and difficult to create
any necessary actionable remediation strategy. Essentially, the review of
any open-source software or component used in your software product
will require both tool assessment and follow-on threat modeling and risk
assessment conducted by a seasoned software security architect.
4.5 Privacy Information Gathering and Analysis
It is important to consider if the system will transmit, store, or create infor-
mation that may be considered privacy information early in the SDLC.
The gathering of information and identification and plan for implement-
ing proper safeguards and security controls, including processes to address
Architecture (A2): SDL Activities and Best Practices 125
privacy information incident handling and reporting requirements, is
determined at this stage. This stage of the SDL is where the information
gathering and analysis for the Privacy Impact Assessment (PIA) begins.
The analysis phase determines how PII will be handled to ensure that it
conforms to applicable legal, regulatory, and policy requirements regarding
privacy; what the risks and effects of collecting, maintaining, and dissemi-
nating privacy information in identifiable form in the software and overall
system being developed or one that it potentially interfaces with in a cloud
or SaaS environment; and examine and evaluate protections and alterna-
tive processes for handling information to mitigate potential privacy risks.
4.6 Key Success Factors and Metrics
4.6.1 Key Success Factors
Success of this second phase of the SDL depends on how well the SDLC
identifies the threats, requirements, and constraints in functionality and
integration and mitigates the risk. Key success factors for this second
phase are listed in Table 4.1.
Table 4.1 Key Success Factors
Key Success Factor Description
1. Identification of business
requirements and risks
Mapping of business requirements and
risks defined in terms of CIA
2. Effective threat modeling Identifying threats for the software
3. Effective architectural threat analysis Analysis of threats to the software and
probability of threat materializing
4. Effective risk mitigation strategy Risk acceptance, tolerance, and
mitigation plan per business
requirements
5. Accuracy of DFDs Data flow diagrams used during threat
modeling
Success Factor 1: Identification of Business Requirements
and Risks
During this phase, key stakeholders including the software security group
help write out business risks and requirements. Business requirements are
defined through the CIA pillars of information security. It is imperative
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.