No threat risk model (an assessment of software, network or other risks and threats) is complete without a methodology for rating threats. In an earlier article we addressed two common and simple threat risk models, both developed by Microsoft — STRIDE and DREAD — along with the more complex CVSS (Common Vulnerability Scoring System). Here we look at how three others rate threats: Trike, MIL-STD-882E and OCTAVE.
Trike is an open source threat modeling methodology with a distinct threat rating component. It delves beyond threat modeling and into “attack graph[ing],” requiring extensive parsing and detail.
For threat rating purposes, however, it is much simpler. In the world of Trike, every attack falls into one of two attack types: elevations of privilege or denials of service. (This solves the cross-correlation problems presented by the more simplistic — and more redundant — STRIDE, as discussed in the earlier article.)
With this in mind, Trike assesses the risks of these attacks impacting assets presented by four specific actions, comprising the acronym CRUD:
(The creators of Trike acknowledge that a fifth and “exotic” action, “invoking,” is possible — and thereby assessable — in an environment that “is specifically intended to move around code and execute that same code as part of the core function of the system.” But they spend no more than a paragraph discussing and quickly dismissing it because of the rarity of the situation.)
A threat rating chart using Trike will list all possible assets connected with the system being assessed; external assets are included as well. For each asset, the risk of either attack type is assessed on a five-point scale for each CRUD action.
Trike also takes human actors into account — such as an administrator, an account holder or an anonymous user or reader. Separately, actors are rated on a five-point scale for the risk they are assumed to present to a system based on trust. A trusted administrator with full privileges, for example, would get a rating of one, whereas an anonymous user with the most limited access would get a high rating. They are also rated on a three-point scale – always, sometimes, never – for each of the CRUD actions they have access to perform upon each asset.
Five-point scales are used throughout the threat modeling aspects of Trike, as well (for instance, for assessing weaknesses). For those used to modern, three-point DREAD methodology, even a five-point rating system for risk — which Trike’s creators indicate is based on probability — can seem too vague.
Unfortunately, this is not the only aspect in which Trike lacks directness and specificity. As with many open-source tools/methodologies and their websites, both Trike and its site could use a lot of work. The website has not been updated in years. Trike version 2.0 — Trike’s “current” version — has not been documented; version 1.5 was never fully documented either.
The Trike paper and corresponding documentation present interesting ways of thinking about fully assessing threats, and the website and paper themselves plainly disclaim that what it describes needs more rigorous testing and may not work perfectly, but the complexity of Trike potentially limits its usefulness for the neophyte. In the end, Trike’s best use for the time being may be as an academic thought experiment — providing theory to underpin the practical workings of a more straightforward threat assessment system.
MIL-STD-882E, a Department of Defense methodology, uses two scales for rating risks: a four-point severity rating scale and a six-point likelihood scale. Unlike with other threat models, MIL-STD-882E goes ahead and specifically defines what each point on the scale means, as shown in these images from a DoD report below:
The two scales combine to form a simple yet detailed risk assessment matrix, as shown here:
“The DoD’s system tends to result in a higher ranking, which equates to a higher value for the cost of a life,” writes security researcher Craig Smith in his new book, The Car Hacker’s Handbook. “Also, MIL-STD-882E is designed to be applied throughout the life cycle of a system, including disposal, which is a nice fit with a secure development life cycle.”
Nonetheless, Smith finds MIL-STD-882E too simplistic a methodology for assessing malicious threats. “When rating threats, we want more detail than just Risk = Probability x Severity,” pens Smith.
Still, MIL-STD-882E does have some depth. Similar to how Trike assesses the risk of human actors, MIL-STD-882E assesses the “software safety criticality” of software systems based on their level of autonomy or automation – potentially making it especially useful for virtualized environments and systems where any form of machine learning or rudimentary AI is employed.
Additionally, MIL-STD-882E offers the benefits of being straightforward and well defined, helping to make up for what it lacks in depth. Thus MIL-STD-882E is a great “starter” methodology for those less experienced with threat-rating theory, while remaining useful for more experienced security analysts as well.
OCTAVE (aka the Operationally Critical Threat, Asset and Vulnerability Evaluation), although jointly developed by the U.S Computer Emergency Readiness Team (US-CERT) and Carnegie Mellon’s Software Engineering Institute, is less of a methodology for assessing technological risk and more of a methodology for assessing organizational risk. Indeed, the voluminous reports that describe OCTAVE criteria read like business-school manuals.
The upside of OCTAVE is that it is at once in-depth and flexible. The downside of OCTAVE is that it is at once in-depth and flexible.
OCTAVE rates risks, likelihoods and impacts on a three-point scale. Additionally, OCTAVE implementation requires teams to specifically define for themselves what each of the three points on each respective scale actually mean.
While ideally anyone using a different threat-rating methodology would determine specific definitions for their ratings anyway, OCTAVE is unique here for getting people to think more carefully about how they choose to rate threats. On the other hand, this still — potentially — represents a weakness when compared to MIL-STD-882E, which flat-out tells those who use it what each rating means.
OCTAVE is more flexible. Probability analyses are “optional,” the only requirement being thoroughness; analysis teams are directed to consider a variety of factors that can influence probability, as well as to explicitly determine the exact numerical thresholds for “high,” “medium” and “low” probabilities.
OCTAVE is far from perfect; its documentation, while detailed, is at times tediously dense and vague. Some engineers and programmers may not like OCTAVE because, being geared more toward organizational risk, it uses “fluffier” business language to describe risk.
On the other hand, by presenting so many questions for analysis teams to consider, OCTAVE — like Trike (debatably) and unlike MIL-STD-882E (debatably) — forces them to think deeply about the methodology behind the threat-rating methodology.
As such, OCTAVE — whether or not it is right for any particular project or organization — presents an ideal to strive for: adaptability. OCTAVE, in its present incarnation, can be easily combined with other threat-rating methodologies — and, as such, allows the threat analyst to imagine how any combination of threat-rating methodologies (whether OCTAVE-inclusive or not) could be picked and chosen from a la carte for one’s particular purpose.
This approach is no stranger to security professionals and has even been explicitly advised; ultimately, you have to choose what works best for you and your goals.
“Expand, bend, or throw out [threat-rating methodology] ideas … as necessary,” Tom Olzak, CEO of Erudio Security, urged readers in his March 2006 paper on STRIDE and DREAD, A Practical Approach to Threat Modeling. “The objective isn’t adherence to some process articulated one Saturday afternoon by [an] IT professional. Instead, it’s the secure operation of your network.”
Joe Stanganelli, principal of Beacon Hill Law, is a Boston-based attorney, corporate-communications and data-privacy consultant, writer, speaker and bridge player. Follow him on Twitter at @JoeStanganelli.