OWASP recognizes that the adoption of a Microsoft modeling process may be a controversial choice in some organizations. If STRIDE / DREAD is unacceptable due to unfounded prejudice, we recommend that every organization trial the various threat models against an existing application or design. This will allow the organization to determine which approach works best for them, and adopt the most appropriate threat modeling tools for their organization.
Performing threat modeling provides a far greater return than any control in this Guide. It is vital that threat modeling takes place.
Trike is a threat modeling framework with similarities to the Microsoft threat model process. However, Trike is differentiated by using a risk based approach with distinct implementation, threat and risk models, instead of using a mixed threat model (attacks, threats, and weaknesses) as represented by STRIDE / DREAD.
From the Trike paper, Trike aims to:
With assistance from the system stakeholders, ensure that the risk this system entails to each asset is acceptable to all stakeholders.
Be able to tell whether we have done this.
Communicate what we’ve done and its effects to the stakeholders.
Empower stakeholders to understand and reduce the risks to themselves and other stakeholders implied by their actions within their domains.
For more information, please review the “Further Reading” section below. The OWASP Guide 2.1 (due November 2005) will have more details on Trike.
Australian Standard / New Zealand Standard AS/NZS 4360, first issued in 1999, is the world’s first formal standard for documenting and managing risk, and is still one of the few formal standards for managing risk. It was updated in 2004.
AS/NZS 4360’s approach is simple (it’s only 28 pages long) and flexible, and does not lock organizations into any particular method of risk management as long as the risk management fulfils the AS/NZS 4360 five steps. It provides several sets of risk tables and allows organizations to adopt their own.
The five major components of AS/NZS 4360’s iterative approach are:
Establish the context – establish what is to be risk treated, i.e. which assets / systems are important
Identify the risks – within the systems to be treated, what risks are apparent?
Analyze the risks – look at the risks and determine if there are any supporting controls
Evaluate the risks – determine the residual risk
Treat the risks – describe the method to treat the risks so that risks selected by the business can be mitigated.
AS/NZS 4360 assumes that risk will be managed by an operational risk style of group, and that the organization has adequate skills in house, and risk management groups to identify, analyze, and treat the risks.
Why you would use AS/NZS 4360:
AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as using just likelihood and consequence to determine an overall risk.
AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS 4360 compatible approach
You are an Australian organization, and thus may be required to use it if you are audited externally on a regular basis, or justify why you are not using it. Luckily, the STRIDE / DREAD model referred to above is AS/NZS 4360 compatible.
Why you would not use AS/NZS 4360:
AS/NZS 4360’s approach works far better for business or systemic risks than technical risks
AS/NZS 4360 does not discuss methods to perform a structured threat risk modeling exercise
As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.
Although AS 4360 can be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methods.
The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the outputs of this group is the Common Vulnerability Scoring System (CVSS).
Why you would use CVSS:
You have just received notification from a security researcher or other source that your product has a vulnerability, and you wish to ensure that it has a trustworthy severity rating so as to alert your users to the appropriate level of action required when you release the patch
You are a security researcher, and have found several exploits for a program. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as compared to their rating.
The use of CVSS is recommended for use by US government departments by the working group – it is unclear if this is policy at the time of writing.
Why you would not use CVSS:
CVSS does not find or reduce attack surface area (i.e. design flaws), nor help enumerate possible risks from any arbitrary piece of code as it is not designed for that purpose.
CVSS is more complex than STRIDE / DREAD, as it aims to model the risk of announced vulnerabilities as applied to released software.
CVSS risk ranking is complex – a spreadsheet is required to calculate the risks as the assumption behind CVSS is that a single risk has been announced, or a worm or Trojan has been released targeting a small number of attack vectors.
The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.
Octave is a heavyweight risk Methodology approach from CMU’s Software Engineering Institute in collaboration with CERT. OCTAVE is targeted not at technical risk, but organizational risk.
OCTAVE consists of two versions: OCTAVE – for large organizations and OCTAVE-S for small organizations, both of which have catalogs of practices, profiles, and worksheets to document the OCTAVE outcomes. OCTAVE is popular with many sites.
OCTAVE is useful when:
Implementing a culture of risk management and control within an organization
Documenting and measuring business risk
Documenting and measuring overall IT security risk, particularly as it relates to whole of company IT risk management
Documenting risks surrounding complete systems
When an organization is mature, does not have a working risk methodology in place, and requires a robust risk management framework to be put in place
The downsides of Octave are:
OCTAVE is incompatible with AS 4360, as it forces Likelihood=1 (i.e. a threat will always occur). This is also inappropriate for many organizations. OCTAVE-S has an optional inclusion of probability, but this is not part of OCTAVE.
Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement
It does not provide a list of out of the box practices for web application security risks
OWASP does not expect OCTAVE to be used by designers or developers of applications, and thus it misses the raison d’être of threat modeling – which is to be used during all stages of development by all participants to reduce the risk of the application becoming vulnerable to attack.
Comparing threat modeling approaches
Here is how roughly the CVSS measures up to STRIDE / DREAD:
| Metric | Attribute | Description | Closest STRIDE / DREAD |
| CVSS Base Metrics | Access vector | Local or remote access? | ~ Exploitability |
| CVSS Base Metrics | Access complexity | How hard to reproduce the exploit | Reproducibility |
| CVSS Base Metrics | Authentication | Anonymous or authenticated? | ~ Exploitability |
| CVSS Base Metrics | Confidentiality impact | Impact of confidentiality breach | Information Disclosure |
| CVSS Base Metrics | Integrity impact | Impact of integrity breach | Tampering |
| CVSS Base Metrics | Availability impact | Impact of system availability breach | Denial of Service |
| CVSS Base Metrics | Impact bias | Bias equal for CIA, or biased towards one or more of CIA? | No equivalent |
| CVSS Temporal | Exploitability | How easy is the breach to exploit? | Exploitability |
| CVSS Temporal | Remediation Level | Is a fix available? | No equivalent |
| CVSS Temporal | Report confidence | How reliable is the original report of the vulnerability? | No equivalent |
| CVSS Environmental | Collateral Damage | How bad is the damage if the threat were realized? | Damage potential |
| CVSS Environmental | Target Distribution | How many servers are affected if the threat were realized? | Affected users (not directly equivalent) |
Alternatively, here is how STRIDE / DREAD map to CVSS:
| STRIDE attribute | Description | Closest CVSS attribute |
| Spoofing identity | How can users obviate controls to become another user or act as another user? | No direct equivalent |
| Tampering with data | Can data be tampered with by an attacker to get the application to obviate security controls or take over the underlying systems (eg SQL injections) | Integrity |
| Repudiation | Can users reject transactions due to a lack of traceability within the application? | No direct equivalent |
| Information disclosure | Can authorization controls be obviated which would then lead to sensitive information being exposed which should not be? | Confidentiality |
| Denial of service | Can an attacker prevent authorized users from accessing the system? | Availability |
| Elevation of privilege | Can an anonymous attacker become a user, or an authenticated user act as an administrator or otherwise change to a more privileged role? | No direct equivalent |
| DREAD attribute | Description … if the threat is realized | Closest CVSS attribute |
| Damage potential | What damage may occur? | Collateral damage |
| Reproducibility | How easy is it for a potential attack to work? | ~ Access complexity |
| Exploitability | What do you need (effort, expertise) to make the attack work? | Exploitability |
| Affected users | How many users would be affected by the attack? | Target distribution |
| Discoverability | How easy is for it attackers to discover the issue? | No direct equivalent |
In general, CVSS is useful for released software and the number of realized vulnerabilities is small. CVSS should produce similar risk rankings regardless of reviewer, but many of the biases built into the overall risk calculation are subjective (i.e. local and remote or which aspect of the application is more important), and thus there may disagreement of the resulting risk ranking.
STRIDE/DREAD is useful to reduce attack surface area, improve design, and eliminate vulnerabilities before they are released. It can also be used by reviewers to rank and enumerate threats in a structured way, and produce similar risk rankings regardless of reviewer.
In the few previous pages, we have touched on the basic principles of web application security. Applications that honor the underlying intent of these principles will be more secure than their counterparts who are minimally compliant with specific controls mentioned later in this Guide.
