DREAD Category LowRisk(1) MediumRisk(2) HighRisk (3) SubtotalRisk
Scores
DamagePotential(D)
Reproducibilit y (R)
lbl()
Exp
l
oita
b
i
l
ity
(
E
)
AffectedUsers(A)
Discoverability(D) TotalRiskScore
Figure 4.8 DREAD threat rating table.
Architecture (A2): SDL Activities and Best Practices 107
Exploitability
Low (value = 1): The attack requires an extremely skilled person and
in-depth knowledge every time to exploit.
Medium (value = 2): A skilled programmer could make the attack,
and then repeat the steps.
High (value = 3): A novice programmer could make the attack in a
short time.
Affected Users
Low (value = 1): Very small percentage of users, obscure feature;
affects anonymous users.
Medium (value = 2): Some users, nondefault configuration.
High (value = 3): All users, default configuration, key customers.
Discoverability
Low (value = 1): The bug is obscure, and it is unlikely that users will
work out damage potential.
Medium (value = 2): The vulnerability is in a seldom-used part of
the product, and only a few users should come across it. It would
take some thinking to see malicious use.
High (value = 3): Published information explains the attack. The
vulnerability is found in the most commonly used feature and is
very noticeable.
These numbers can then be put into a matrix similar to the one shown
in Figure 4.8. After you count and sum the values for a given threat, the
result will fall in the range of 5 to 15. Threats with overall ratings of 12
to 15 are typically considered high risk, those with ratings from 8 to 11 as
medium risk, and and those with ratings from 5 to 7 as low risk.
4.3.3.5 Web Application Security Frame
The Web Application Security Frame, also called the Application Security
Frame (ASF), uses categories to organize common security vulnerabilities
108 Core Software Security
focused on Web software applications. If you use these categories when
you review your application design to create a threat model, you can sys-
tematically reveal the threats and vulnerabilities specific to your applica-
tion architecture. There are nine frame categories; sample questions used
in the process are listed below.
Web Application Security Frame Categories and Assessment
Questions
12
• Input and Data Validation
How do you know that the input your application receives is valid
and safe? Input validation refers to how your application filters,
scrubs, or rejects input before additional processing. Consider con-
straining input through entry points and encoding output through
exit points. Do you trust data from sources such as databases and
file shares?
• Authentication
Who are you? Authentication is the process whereby an entity proves
the identity of another entity, typically through credentials, such as
a user name and password.
• Authorization
What can you do? Authorization is how your application provides
access controls for resources and operations.
• Configuration Management
Who does your application run as? Which databases does it connect
to? How is your application administered? How are these settings
secured? Configuration management refers to how your application
handles these operational issues.
• Sensitive Data
How does your application handle sensitive data? Sensitive data
refers to how your application handles any data that must be pro-
tected either in memory, over the network, or in persistent stores.
• Session Management
How does your application handle and protect user sessions? A ses-
sion refers to a series of related interactions between a user and your
Web application.
Architecture (A2): SDL Activities and Best Practices 109
• Cryptography
How are you keeping secrets (confidentiality)? How are you
tamper-proofing your data or libraries (integrity)? How are you
providing seeds for random values that must be cryptographically
strong? Cryptography refers to how your application enforces confi-
dentiality and integrity.
• Exception Management
When a method call in your application fails, what does your appli-
cation do? How much do you reveal? Do you return friendly error
information to end users? Do you pass valuable exception informa-
tion back to the caller? Does your application fail gracefully?
• Auditing and Logging
Who did what and when? Auditing and logging refer to how your
application records security-related events.
4.3.3.6 The Generic Risk Model
Microsoft threat modeling processes such as STRIDE and DREAD may
not be appropriate for your application, and you may want to use other
threat risk models or modify the Microsoft processes for your own use,
adopting the most appropriate threat modeling methodologies for your
own organization. Using qualitative values such as high, medium, and
low can also help avoid the ranking becoming too subjective, as with the
numbering system used in DREAD.
These examples help in the calculation of the overall risk values by
assigning qualitative values such as high, medium, and low to likeli-
hood and impact factors. Here too, using qualitative values rather than
numeric ones as in the DREAD model helps avoid the ranking becoming
overly subjective.
An example of a more subjective model is the Generic Risk Model,
which takes into consideration the likelihood (e.g., the probability of an
attack) and the impact (e.g., damage potential) and is represented mathe-
matically as
13
Risk = Likelihood × Impact
The likelihood or probability is defined by the ease of exploitation, which
depends mainly on the type of threat and the system characteristics, and
110 Core Software Security
by the possibility to realize a threat, which is determined by the existence
of an appropriate countermeasure. The following is a set of considerations
for determining ease of exploitation:
1. Can an attacker exploit this remotely?
2. Does the attacker need to be authenticated?
3. Can the exploit be automated?
The impact depends mainly on the damage potential and the extent
of the impact, such as the number of components that are affected by a
threat. Examples to determine the damage potential are
1. Can an attacker completely take over and manipulate the system?
2. Can an attacker gain administration access to the system?
3. Can an attacker crash the system?
4. Can the attacker obtain access to sensitive information such as
secrets, PII
Examples to determine the number of components that are affected
by a threat include:
1. How many data sources and systems can be impacted?
2. How “deep” into the infrastructure can the threat agent go?
4.3.3.7 Trike
An alternative threat modeling methodology to STRIDE and DREAD is
Trike. Trike is a unified conceptual framework for security auditing from
a risk management perspective through the generation of threat models
in a reliable, repeatable manner.
14
Trike uses a threat modeling framework
that is similar to the Microsoft threat modeling methodologies. However,
Trike differs in that it uses a risk-based approach with distinct implemen-
tation, threat, and risk models, instead of using the STRIDE/DREAD
aggregated threat model (attacks, threats, and weaknesses).
15
Trike is distinguished from other threat modeling methodologies by
the high levels of automation possible within the system, the defensive
perspective of the system, and the degree of formalism present in the
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.