Architecture (A2): SDL Activities and Best Practices 111
methodology.
16
The latest version of the Trike tool can be downloaded at
the Source Forge website at http://sourceforge.net/projects/trike/files/trike.
A security auditing team can use it to describe the security characteris-
tics of a system from its high-level architecture to its low-level implemen-
tation details. The goal of Trike is to automate the repetitive parts of threat
modeling. Trike automatically generates threats (and some attacks) based
on a description of the system, but this requires that the user describe the
system to Trike and check whether these threats and attacks apply.
17
A key
element of Trike is the empowerment, involvement, and communications
with the key stakeholders with complete progress and task status transpar-
ency so that they know the level of risk and can evaluate acceptance of the
risk throughout the software development process.
4.3.3.8 PASTA (Process for Attack Simulation and
Threat Analysis)
In 2011, a new application threat modeling methodology developed
by Marco Morana and Tony Uceda Velez was presented. PASTA is a
seven-step process that is applicable to most application development
methodologies and is platform-agnostic. It not only aligns business
objectives with technical requirements it also takes into account compli-
ance requirements, business impact analysis, and a dynamic approach
to threat management, enumeration, and scoring. The process begins
with a clear definition of business objectives, security and compliance
requirements, and business impact analysis. Similar to the Microsoft
process, the application is decomposed into components, with use case
diagrams and DFDs to illustrate the threat model with which threat and
vulnerability analysis can be performed. The next step involves use of
threat trees, abuse cases, scoring systems, and enumerations for further
reference in analysis. Following this, the threat model is viewed from an
attacker perspective by attack modeling in attack trees and attack sur-
face analysis. In the final step, risk and business impact can be qualified
and quantified, and necessary countermeasures identified. This process
combines the best of various threat modeling approaches, with the attack
trees serving as an attacker-centric means of viewing a threat, as well
as, in combination with risk and impact analysis, helping to create an
asset-centric means of planning a mitigation strategy. The threat trees,
112 Core Software Security
with mapping of threats to existing vulnerabilities, work in favor of easy
and scalable threat management. Beyond the technical aspects, the risk
and business impact analysis take threat modeling beyond just a software
development exercise to involve participation of key decision makers in
the vulnerability management process. What differentiates this method-
ology from Trike is that it focuses on involving risk management steps
in the final stage of the process. This ensures that it is not limited to a
specific risk estimation formula.
18
The seven-step PASTA Threat Modeling Methodology is as follows:
19
1. Define Objectives
• Identify business objectives
• Identify security and compliance requirements
• Business impact analysis
2. Define Technical Scope
• Capture the boundaries of the technical environment
• Capture infrastructure, application, and software dependencies
3. Application Decomposition
• Identify uses cases and define application entry points and trust
levels
• Indentify actors, assets, services, roles and data sources
• Data flow diagramming and trust boundaries
4. Threat Analysis
• Probabilistic attack scenarios analysis
• Regression analysis on security events
• Threat intelligence correlation and analytics
5. Vulnerability and Weakness Analysis
• Queries of existing vulnerability reports and issues tracking
• Threat to existing vulnerability mapping using threat trees
• Design flaw analysis using use and abuse cases
• Scorings (CVSS/CWSS) and enumerations (CWE/CVE)
Architecture (A2): SDL Activities and Best Practices 113
6. Attack Modeling
• Attack surface analysis
• Attack tree development and attack library management
• Attack to vulnerability and exploits analysis using attack trees
7. Risk and Impact Analysis
• Qualify and quantify business impact
• Countermeasure identification and residual risk analysis
• ID risk mitigation strategies
There is also fairly new threat-modeling tool called ThreatModeler,
developed by MyAppSecurity, Inc., that supports the PASTA methodol-
ogy. ThreatModeler is a threat modeling product which brings a mind
mapping approach to threat modeling. It allows companies to scale their
threat modeling initiative across thousands of applications easily and
effortlessly. ThreatModeler automatically generates threats and classi-
fies them under various risk categories. It provides a centralized threat
management platform where organizations can define threats related
to network, host, applications, mobile, Web services, etc., and associate
attributes such as technical impacts, business impacts, and threat agents
to better understand a threat and prioritize mitigation strategies.
20,21
Although its original focus was on banking malware threats, PASTA
certainly has applicability across all software applications and will fit well
into most SDLCs. It will be interesting to see how widely it is accepted in
industry over the next few years.
4.3.3.9 CVSS
Another risk assessment methodology that is very popular and is used exten-
sively by corporate product security incident response teams (PSIRTs) and
internal software security groups to classify externally discovered software
vulnerabilities is the U.S. government’s Common Vulnerability Scoring
System (CVSS). The National Infrastructure Advisory Council (NIAC)
commissioned CVSS to support the global Vulnerability Disclosure
Framework. CVSS is currently maintained by the Forum of Incident
Response and Security Teams (FIRST),
22
and was a joint effort involving
114 Core Software Security
many companies, including CERT/CC, Cisco Systems, DHS/MITRE,
eBay, Internet Security Systems, Microsoft, Qualys, and Symantec. The
CVSS model is designed to provide end users with an overall composite
score representing the severity and risk of a vulnerability. It is derived from
metrics and formulas. The metrics are in three distinct categories that can
be quantitatively or qualitatively measured. Base metrics contain qualities
that are intrinsic to any given vulnerability; these qualities do not change
over time or in different environments. Temporal metrics contain charac-
teristics of a vulnerability that evolve over the lifetime of the vulnerability.
Environmental metrics contain characteristics of a vulnerability that are
related to an implementation in a specific user’s environment. Scoring is
the process of combining all metric values according to specific formulas
and based on a series of measurements called metrics based on expert
assessment which is described below:
23
• Base scoring is computed by the vendor or originator with the inten-
tion of being published, and, once set, is not expected to change.
Base scoring is also computed from confidentiality, integrity, and
availability. This is the foundation that is modified by the temporal
and environmental metrics. The base score has the largest bearing
on the final score and represents vulnerability severity.
• Temporal scoring is also computed by vendors and coordinators for
publication, and modifies the base score. It allows for the introduc-
tion of mitigating factors to reduce the score of a vulnerability and
is designed to be reevaluated at specific intervals as a vulnerability
ages. The temporal score represents vulnerability urgency at specific
points in time.
• Environment scoring is optionally computed by end-user organiza-
tions and adjusts the combined base-temporal score. This adjusted
combined score should be considered the final score and represents
a moment in time, tailored to a specific environment. User organi-
zations should use this score to prioritize responses within their
own environments.
A useful tool is the the Common Vulnerability Scoring System
Version2 Calculator, which can be found on the National Institute of
Standards and Technology (NIST) National Vulnerability Database web-
site at http://nvd.nist.gov/cvss.cfm?calculator&version=2.
Architecture (A2): SDL Activities and Best Practices 115
The CVSS has become an industry standard for assessing the severity
of computer system security vulnerabilities. It establishes a measure of
how much concern vulnerability should warrant compared to other vul-
nerabilities so that mitigation efforts can be prioritized. As of the writing
of this book, the current version of CVSS is version 2.
The CVSS is typically used by an internal software security group to
respond to a security researcher or other source that has notified you that
your software product has vulnerability. This provides the ability to keep
your severity ratings normalized, consistent, and accurate. The scores are
also used in the communication to the customers acknowledging that
there is a vulnerability in the product that they have purchased, the sever-
ity of the vulnerability, and what your company is doing to mitigate that
vulnerability, including any patch releases for the vulnerability. In turn,
a security researcher will likely use the CVSS ranking system to provide
a risk rating to the company within whose software product they have
found a vulnerability, so that the vendor has a good idea of the severity of
the vulnerability that is being disclosed and the details of what to verify
with its product development team.
It should be noted that the CVSS is not a threat modeling methodol-
ogy and is not used to find or reduce the attack surface or to help specify
risks within a piece of code. It is, rather, a risk scoring system and it
adds complexities that don’t exist in STRIDE and DREAD. It is used
to calculate risks that are identified post-product release in addition to
environmental factors.
4.3.3.10 OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability
Evaluation) is a very complex risk methodology approach originat-
ing from Carnegie Mellon University’s Software Engineering Institute
(SEI) in collaboration with the SEI Computer Emergency Response
Team (CERT). OCTAVE focuses on organizational risk, not technical
risk. It comprises a suite of tools, techniques, and methods for risk-based
information security strategic assessment and planning. There are three
OCTAVE methods: (1) the original OCTAVE method, which forms the
basis for the OCTAVE body of knowledge; (2) OCTAVE-S, for smaller
organizations; and (3) OCTAVE-Allegro, a streamlined approach for
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.