This document provides an overview of threat modeling in information security. It discusses three main approaches to threat modeling: software-centric, asset-centric, and attacker-centric. It also outlines the antecedents of threat modeling in military theory, behavioral theory, and early tech industry practices. Finally, it discusses present and future directions for threat modeling, including software-centric, asset-centric, and attacker-centric approaches, as well as how to introduce threat modeling processes in an organization.

1. Companion to HPSR Threat Intelligence Podcast Episode 13
Threat Intelligence Briefing
Episode 13, May 2014
HP Security Research
Table of contents
Overview.......................................................................................................................................................................................... 2
What needs modeling? ................................................................................................................................................................ 2
Approaches to threat modeling ................................................................................................................................................. 2
Software-centric modeling..................................................................................................................................................... 2
Asset-centric modeling............................................................................................................................................................ 2
Attacker-centric modeling ...................................................................................................................................................... 3
Antecedents and analogues ....................................................................................................................................................... 3
Classic military theory.............................................................................................................................................................. 3
Behavioral theory...................................................................................................................................................................... 3
Early tech-industry thinking ................................................................................................................................................... 4
Present and future of threat modeling .................................................................................................................................... 4
Software-centric approaches................................................................................................................................................. 4
Asset-centric approaches ....................................................................................................................................................... 5
Attacker-centric approaches.................................................................................................................................................. 5
Big bets and related efforts.................................................................................................................................................... 7
Modeling in your organization.................................................................................................................................................... 7
In summary..................................................................................................................................................................................... 9
An administrative note from HPSR............................................................................................................................................ 9
References and selected further reading ................................................................................................................................ 9

2. Episode 13
Thank you for subscribing to Episode 13 of the HP Security Briefing. In this
edition we discuss the history of and current trends in threat modeling, with an
emphasis on approaches to introducing threat-modeling processes to the
reader’s enterprise.
Overview
In the hours after a flood, emergency responders standing at the edge of the water stop worrying about the next wave and
start to contemplate trends in the weather. When the adrenaline subsides in any adversarial situation, rational thinkers look
at next steps, next days, and the long term.
Many enterprises might argue it’s all anyone can do to combat attacks on software, networks, and other assets as they’re
discovered. Effective security strategy, however, entails getting out in front of attacks to the greatest extent possible. That
process, whether it’s applied to software development, network management, or any number of other tech-related
processes in the enterprise, is called threat modeling.
In this briefing, we give an overview of the threat-modeling landscape for information security – what it affects, how it got
this way, what the current notable conditions are, and how to introduce the pertinent concepts to your organization.
What needs modeling?
At its base, threat modeling is yet another permutation of risk management, the soul of information security. Threat
modeling asks that we assign value to our assets, examine them closely for potential vulnerabilities, assess what risks
those vulnerabilities pose to our enterprise, and plan to mitigate them (or not). Threat modeling is not auditing -- though
auditing can be useful as we determine which assets or controls merit the modeling effort – but a way of learning from the
past to manage future risk.
Above all, threat modeling is, as most things are in the enterprise, a method of resource allocation – a way to plan for where
fires may start in your organization, so you can keep your fire trucks garaged as often as possible.
Approaches to threat modeling
Approaches to threat modeling can be divided into three general types: software-centric, asset- or system-centric, and
attacker-centric.
Software-centric modeling
Software-centric threat modeling aims to stamp out vulnerabilities before they come into being, by examining how
applications are built and how data flows through them and quelling any bad behaviors at the design and implementation
stages (that is, before the application is released). Software houses that follow a Software Development Lifecycle (SDL)
process usually have multiple checkpoints in the process to catch and eliminate as many issues as possible. Such modeling
doesn’t catch every vulnerability, but at its best it eliminates a vast amount of “low-hanging fruit” and makes it obvious to
developers where particular care must be taken.
Asset-centric modeling
Asset-centric or system-centric threat modeling is generally an inward-looking process that starts with an examination of
what has value to an organization, or to its people or processes. Valuation guides us toward appropriate protections, and
often includes an examination of what could happen to the assets and the effect if something were to happen to them.
Outcomes are often oriented toward the appropriate controls and budget priorities, rather than focusing on the software or

3. potential attackers. This kind of modeling may be somewhat insular, but it is often an effective way to approach highly
regulated data or industries.
Attacker-centric modeling
Attacker-centric threat modeling draws on experiences and theories about attacks on an infrastructure or against certain
types of data or entities, with the goal of providing an estimate of how anticipated attacks might progress, and how to deal
with them if they do. This type of model might be more appropriate when assets are less important than the motivation of
adversaries towards an organization or state, or when a pattern of intrusions is repeated over multiple targets.
Antecedents and analogues
As with earlier forms of conflict, threat and response in the realm of information security generally implies that someone’s
on offense and someone’s on defense. That’s why classic military theory, reaching back hundreds of years and drawing on
knowledge of offensive and defensive strategy (and how things turned out), is perhaps the most important body of
knowledge to feed into modern threat modeling.
Classic military theory
Beleaguered IT professionals may yearn for the age when Carl von Clausewitz could accurately write in On War that “the
defensive form of war is intrinsically stronger than the offense.” [1] A more useful concept for our era is that of “relative
superiority,” which flows from defense to offense as conflict unfolds. The concept of relative superiority, which was
developed by Adm. William McRaven in his Theory of Special Operations, [2] has been adopted as a key concept in modern
kinetic warfare and, for information security’s purposes, mirrors the asymmetrical nature of the threats enterprises face.
McRaven defines three basic properties of relative superiority:
- It is achieved at the pivotal point in an engagement.
- Once it is achieved, it must be sustained to result in victory.
- If it is lost, it is difficult to regain. [3]
McRaven’s model lists six essential principles of special operations, which could be posted on the wall of any attacker’s lair:
simplicity, security, repetition, surprise, speed, and purpose. [4] Though put forth in Spec Ops as a guide for offensive action,
the model and its principles are of equal use for attackers and defenders.
A second military concept, the kill chain, denotes a process of dependencies (ideally a chain of events, though in war as in
life the chain’s links are not always in perfect order) that concludes with the destruction or severe incapacitation of a target.
The steps of the classic military kill chain are:
- Target identification
- Dispatch of force to target
- Decision and order to commence attack
- Destruction of target
or, commonly: Find, Fix, Track, Target, Engage, and Assess. [5]
Unlike McRaven’s relative-superiority concept, which agrees with von Clausewitz in giving defenders the upper hand (at least
initially), the kill-chain model focuses on offensive action and provides a way of characterizing successful action on an
attacker’s part.
Behavioral theory
Beyond military theory, we find sociology and cultural studies. What von Clausewitz called the “moral” aspect of warfighting
[6] is more currently thought of as the psychology or sociology of those participating or affected. Analysis of human
motivations and assumptions in information security has antecedents in the work of social psychologists such as Geert
Hofstede, originally sponsored by IBM. [7] His longitudinal studies of cultural differences manifested across IBM’s global
workplace has informed generations of studies on how differences in worldview, shared by entire populations, filter down to
the level of small-group or individual actions. [8]

4. Hofstede’s original theory of “cultural dimensions” started with a multi-decade survey of over one hundred thousand IBM
employees around the globe. [9] It is has since expanded to provide statistically useful data for people in dozens of
countries. [10] It posited four dimensions of behavior that correlate well with nationality, and while Hofstede often cautions
against using the data to attribute individual behavior, it provides a sound basis on which to differentiate between groups.
[11] This is a particularly useful concept for attacker-based threat modeling, especially when large pools of behavioral data
are available, but generations of would-be anthropologists will attest that the data needs to be handled with care and
extrapolated very, very cautiously.
Anthropology and sociology often dovetail with military studies, especially where counterinsurgency efforts – “hearts and
minds” outreach strategies – are concerned. For instance, the Human Terrain System ethnographic-intelligence push put
forward by Gen. Petraeus in both Iraq and Afghanistan was based in part on the work of cultural anthropologists. However,
neither all military folk nor all anthropologists are comfortable with this pairing; therefore, we should consider sociology and
cultural studies as a separate thread to military theory for our purposes. [12]
Early tech-industry thinking
Of course, the software industry hasn’t just woken up to the importance of thinking through potential security issues in
code. Threat modeling has existed for years as a known, if occasionally underappreciated, aspect of software development.
In particular, Microsoft – which had a fire lit under its collective feet by then-CEO Bill Gates in 2002 after a series of security-
related incidents [13] – developed various approaches to threat modeling for application development in the early 2000s.
The most extensible approaches made their way into SDL (software development lifecycle) schema throughout the tech
industry. [14]
Present and future of threat modeling
Of the three threat-modeling approaches we listed above (software-centric, system/asset-centric, attacker-centric), those
that tackle application development are probably the most mature.
Software-centric approaches
No software created by humans (or by any process created by humans) is likely to be free of all bugs, and even the best
coding practices aren’t a perfect guarantee of security. That said, the software industry has been implementing (or trying to
implement) security awareness in its development processes for years now. [15] Many of the underlying concepts have
come, as mentioned above, from people who are now or have previously been employed by Microsoft and involved in its
Trustworthy Computing initiative. [16]
STRIDE is a threat modeling method developed by Microsoft to address software security threats. [17] The name is a
mnemonic for six categories of threat:
- Spoofing of user identity
- Tampering
- Repudiation
- Information disclosure
- Denial of Service (DoS)
- Elevation of privilege [18]
While STRIDE was originally developed for modeling during the software development process, it has been used for many
other technical development, implementation, and operations activities. Recognizing that a broader framework was
necessary over the software development lifecycle, Microsoft (among others) promotes the use of tools such as STRIDE at
each stage of development – effectively making it a Security Development Lifecycle (SDL). [19]
DREAD is another mnemonic security modeling method developed by Microsoft, with five general categories for risk rating
of security threats:
- Damage - how bad would an attack be?
- Reproducibility - how easy is it to reproduce the attack?
- Exploitability - how much work is it to launch the attack?

5. - Affected users - how many people will be impacted?
- Discoverability - how easy is it to discover the threat? [20]
When considering a specific exploit for software or processes, each category is given a numeric rating of 3 for high, 2 for
medium, 1 for low, and 0 for none. [21] The result is often used to prioritize mitigation of exploits, though the method can
be adapted to attacker-centric use.
The Open Web Application Security Project (OWASP) and others also promote data flow diagramming (DFD) as a detailed
method for finding the functions of software and the potential points where functions or data could be co-opted. Data
flows, stores, processes, interactors, and trust boundaries for an application or system are broken down into individual
components and mapped against STRIDE or another tool to build a software-specific threat model. [22] Appropriate
controls can then be selected for each component.
Asset-centric approaches
Carnegie Mellon University's Software Engineering Institute (SEI) developed the original version of OCTAVE (Operationally
Critical Threat, Asset, and Vulnerability Evaluation) in 2001 to meet US Department of Defense compliance requirements.
[23] SEI describes it as "a suite of tools, techniques, and methods for risk-based information security strategic assessment
and planning.” [24] Early versions of OCTAVE attempted, as they say, to boil the ocean, providing such a wealth of guidance
that most practitioners found them hard to actually use. Since then, OCTAVE has been updated and split into multiple
versions. OCTAVE Allegro is the most recently developed method and is actively supported by the CERT Division. [25] Allegro
focuses on a fast, iterative approach with four essential phases:
- Developing criteria for measuring risk, and ensuring that organizational drivers are understood
- Building asset-based threat profiles
- Identifying vulnerabilities in infrastructure
- Developing relevant security strategy and plans [26]
OCTAVE Allegro defines five areas of potential risk, with a sixth left as an exercise for the modeler:
- Financial
- Reputation and consumer confidence
- Productivity
- Fines and legal penalties
- Safety and health
- User-defined (the ad hoc category) [27]
Elsewhere, the delightfully named PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-analysis
process that the authors promote as adaptable to most threat-modeling methods. [28] The process begins with definition
of business objectives, security and compliance requirements, and business impact analysis based on potential threats. [29]
This information is then used to create threat trees, abuse cases, selection of a relevant scoring system, and enumeration of
high-impact cases for further review. With enough information, the model can also provide an attacker’s perspective by
using attack trees and attack surface analysis. Typically, a process like PASTA is used to provide metrics for risk and
business impact that can be used for control selection.
Trike, an open-source methodology and toolset, focuses on the security auditing process from the risk-management
perspective with distinct implementation, threat, and risk models. [30] The process starts with a requirement model
defining the acceptable level of risk for assets, followed by DFDs showing the implementation of each asset. Threats are
enumerated based on the DFD, giving risk values and highlighting areas needing additional controls. Though a work in
progress, Trike promises to automate certain (tedious) parts of the modeling process. [31]
Attacker-centric approaches
The most widely known paradigm for looking at attacks on software and infrastructure is the Cyber Kill Chain, developed by
the CSIRT (Computer Security Incident Response Team) at Lockheed Martin. [32] As one would guess, the Cyber Kill Chain
(also referred to as the LM Kill Chain or intrusion kill chain) is derived from the military model described above, with some
adjustments for the non-corporeal nature of the battleground. [33]

6. The Cyber Kill Chain consists of seven steps (commonalities), adapted from the military version:
- Reconnaissance
- Weaponization (or Packaging)
- Delivery
- Exploit
- Installation
- Command and control
- Actions on objectives [p] [34]
As with the military model, the Cyber Kill Chain delineates attacker actions, and as with the military model the defenders
against such attacks will have more success if they break the chain early in the attack. [35] However, the kill-chain model
focuses primarily on malware-borne attacks and exploit and control dependencies in specific instances. [36] Characterizing
a persistent attack, strategy changes, or relative success may require a surrounding framework.
FlipIT is a game-theory approach to modeling attack activities, where an attacker and defender seek to maximize control of
assets in a move-by-move model. [37] Adversaries may not know what the other has done until they attempt to move or
use assets, requiring analysis of the effect of activity rather than focusing on systems or software. [38] FlipIT's notion that
an attacker could periodically have full control of a system is uncomfortably close to the experience of many IT operations
staff examining an environment in which an advanced intruder is persistent, and the flow of each game or run can inform
how the organization should react in a given situation. (Anyone who’s had to ask their enterprise’s executives for additional
resources to keep fighting an attacker that’s been successfully repelled once can understand how superiority can slip away
after initial success.)
Threat Genomics is a threat modeling approach originally developed within Microsoft TwC Security. [39] It combines
dependency concepts from the kill-chain approach with a broader framework similar to FlipIT, but drawn from McRaven's
relative-superiority concept. [40] The system identifies ten types of activities in an attack which may occur in sequence,
parallel, or not at all:
- Reconnaissance
- Commencement
- Entry
- Foothold
- Lateral movement
- Acquisition of control
- Acquisition of target
- Implementation / actions on objectives
- Concealment /maintenance
- Withdrawal [41]
As with the Cyber Kill Chain model, attackers’ steps can be missing or out of order. However, in the threat genomics model,
the particular sequence of the steps in a particular attack (and to a lesser extent their duration) provide intelligence as to the
nature of that attack and the best way to stymie it. In contrast, Cyber Kill Chain looks to correlate indicators of three types –
Atomic (individual data points), Computed (computer-generated data points such as hashes), and Behavioral (combinations
of other types of indicators) within each step to establish that intelligence. [42]
The thesis of Threat Genomics is that attacker movement -- not the tools the attackers use, and not individual data points --
is the primary means of determining what sort of attack is underway, what the target and endgame may be, and even who
the attacker might be. [43] For instance, two different attackers might attempt denial of service against a particular target,
but their behaviors before and after clearly differentiate a disorganized Anonymous-style attack from one undertaken by a
disciplined adversary with military or other organizational prowess backing its play. Understanding the behavior sequences
of specific attackers can aid in identifying attacks even when evidence of specific steps isn’t present for analysis.
Another threat model predicated on tracking the progress of attacks is the Cyber Exploitation Life Cycle, proposed in 2010
by Mandiant. [44] That model has eight steps:

7. - Initial reconnaissance
- Penetration
- Gaining a foothold
- Appropriating privileges
- Internal reconnaissance
- Maintaining presence
- Exfiltration
- Mission accomplished [45]
Cyber Kill Chain, Threat Genomics, and Cyber Exploitation Life Cycle may extend forward to attribution based on attacker
activity (for example, using Dr. Char Sample's work on soft markers in computer network attacks) [46], but all of these bring
their theories back to the realm of the real by mapping controls to the phases of the event. This details the actions or tools
that might be appropriate to avoid, detect, react to, or simply survive an attacker at each stage of the conflict. Readers will
recognize these choices as Defense in Depth 101 [47], but with enhanced situational awareness and perhaps a more wisely
spent budget. Understanding how individual attacks fit into the chosen schema can help enterprises prioritize spending and
deployment of resources.
Big bets and related efforts
OCTAVE continues to be a big player in the threat modeling arena, propelled in part by its orientation toward government
requirements. However, there's much buzz recently over the US Federal Risk and Authorization Management Program
(FedRAMP), which is a risk management program for "large outsourced and multi-agency information systems used by the
U.S. government" (hosted infrastructure often referred to as "cloud computing"). [48] Where previously the service
providers might conduct a risk assessment (including threat modeling) for each service or customer, FedRAMP allows the
service provider to assess their entire service offering. [49]
In a nutshell, the FedRAMP process centers around System Security Plans (SSP), a 400-page template that the provider
uses to define system assets, boundaries, policies and controls – including 298 controls defined by NIST 800-53. [50] Most
systems fall into the FIPS 199 moderate category, which is a qualitative rating that guides the following threat modeling and
control assessment process. [51] While formidable, this process allows service providers to do one detailed threat model
and security plan instead of multiple iterations.
The Common Attack Pattern Enumeration and Classification (CAPEC) is a large-scale and continually evolving list of common
attack patterns, though it is heavily oriented toward malware and attacker tooling. [52] Patterns include information on
what an adversary is attempting to do, how it’s attempted, and how defenders might mitigate the attempt’s effectiveness.
[53] Documenting such patterns can aid developers and model designers in planning for them.
Another major effort underway is oriented toward defining attack activities in a standard format, and allowing exchange of
the information between organizations that have been reticent to do so. The U.S. Department of Homeland Security has
sponsored the development of STIX (Structured Threat Information Expression) [54] and TAXII (Trusted Automated
Exchange of Indicator Information) [55] with MITRE. While STIX may be considered a small step past the CybOx (Cyber
Observable eXpression) [56] work that defined a schema for defining facts and patterns of observed attacks, the
combination with a transport mechanism has much promise for threat management as well as threat modeling.
Modeling in your organization
Bringing threat modeling into an organization that hasn’t formalized a process before – or one large enough to have
multiple and conflicting attempts underway – can prove an exciting political challenge for managers, who will need buy-in
from their peers, their reports, and (ultimately) from management. Though for the purposes of this briefing we stipulate
that readers are equal to that challenge, practical guides such as Adam Shostack’s Threat Modeling: Designing for Security
provide advice on socializing the threat-modeling uptake process. [57]
We also assume that you have ascertained what products or processes in your organization may benefit from threat
modeling, as per the suggestions in the first section of this paper. Once you know that, you’ll cycle through three
interlocking questions:

8. Stakeholders -- who’s in the room?
Events -- what could go wrong?
Outcomes -- what happens then?
What remains is to follow the focus or priorities of your organization. Software, asset, or threat-focused models aren't
intrinsically better or worse than one another. They are simply different tools to use depending on where you are and what
your enterprise is doing.
Choose a model. You’ve got to start somewhere, and the practice of threat modeling is sufficiently mature as to give you
options. Choose one that seems reasonable and start; you can always back up and try another later.
Consider alternate methods. That said, the gaps between two ways of thinking about a problem can be very interesting
places. Don’t be doctrinaire, especially if you’re attempting to meld the work of two or more teams. This maxim also pays
off when working with the developers; when two different groups come together, the usual clash between viewpoints and
assumptions can sometimes point to potential security issues.
Try quick iterations with qualitative estimations to see what fits. The Agile development model has much to offer in this
context. [58] It’s far better to throw many things at the wall and sift through the debris than to bog down on the search for
perfection.
Don't write novels. Consider the operations-management genius of David Lee Roth, who slipped a demand for “no brown
M&Ms!” into Van Halen’s long and complicated concert-tour rider (the document that details all the preparations that venues
must undertake to put on a show). He threw that in there as a simple check as to whether venue managers had truly read
and understood the whole rider, since non-compliance could literally endanger the lives of the band and the audience. [59]
However, we regret to inform you that you are not in Van Halen, and that you have very few means of ensuring that all
shareholders read and understand your entire threat assessment. Keep it as concise and direct as possible, and remember
to prepare an executive-summary version for your leadership / budget team.
Focus on actual risk, rather than academic elegance. There are no brownie points awarded to security folks who can quote
chapter-and-verse of their favorite model but can’t muster the flexibility to adapt their plans to their real-work risk profile.
Whether it’s attempting to get a full tally of every possible organizational variable or attempting to cram everything into a
series of little boxes set forth in your favorite threat-modeling textbook, avoid letting the perfect be the enemy of the good.
Have fun, seriously. You’ve heard exhortations to “think like a bad guy” when you threat-model, and getting outside your
own head can be highly useful to the process. Games are a very good way of doing that, especially if you lack an intracranial
bad guy. In addition to the FlipIT game described above and playable online [60], there’s the points-based “Elevation of
Privilege” card game, which teaches STRIDE thinking. [61] Further afield is the “Persistence of Threat” baseball-style card
deck, which helps modelers see how Threat Genomics works by breaking down high-profile attacks such as Shady Rat,
Stuxnet, and the TJX breach. [62]

9. In summary
Threat modeling provides a structure by which security professionals can manage risk to assets in their organizations. It
draws from disciplines such as military history, anthropology, and computer science. Threat-modeling schema can be
divided into three types – software-centric, asset-centric, and attacker-centric – with models within each group differing in
how factors such as attacker movement, tool use, and type of attack(s) used are weighted. When embarking on the threat-
modeling process, security professionals must continually take into consideration the stakeholders, potential targets, and
likely outcomes affected by their efforts.
An administrative note from HPSR
Observant readers may have noted that the name of this whitepaper series has changed – goodbye to Threat Briefing, hello
(with this edition) to the HP Security Briefing. We believe the change reflects the true span of HPSR’s mandate: innovative
research, relevant security intelligence, and world-class thought leadership. Threats will always be a part of life in
information security, but as our examination of the modeling process makes clear, there’s much more to good security than
simply reacting to individual crises as they arise. As with the first responders at the beginning of this briefing, we hope to
help you look beyond a single incident’s flood waters to the larger forces that can cause them.
Learn more at
hp.com/hpsr
References and selected further reading
[1] Von Clausewitz, Carl, On War. The military classic provides us with an abundance of fundamental concepts. The
great Prussian general was famously skeptical that war could be reduced to charts and graphs and statistics, which
causes one to wonder what he’d make of some of threat modeling’s more mechanistic approaches.
[2, 3, 4] McRaven, William H., Spec Ops: Case Studies in Special Operations Warfare: Theory and Practice. New York:
Random House, 2009. Lays out McRaven’s theory of relative superiority and provides a selection of examples
throughout military history that illustrate his approach’s underlying principles.
[5] Tirpak, John A., “Find, Fix, Track, Target, Engage, Assess,” Air Force Magazine, July 2000. Online at
http://www.airforcemag.com/magazinearchive/pages/2000/july%202000/0700find.aspx .
[6] von Clausewitz, ibid.
[7, 8, 9, 10, 11] Hofstede, Geert, Culture’s Consequences: Comparing Values, Behaviors, Institutions and Organizations
Across Nations. Thousand Oaks, CA: Sage, 2001. The groundbreaking social psychologist and his son continue to work
and add material semi-regularly to http://www.geerthofstede.nl/ , including cautions about using their research
incautiously. The edition cited here is a substantial update and rewrite of the original 1980 text.
[12] Isenberg, David, “Touchy Feely in the Kill Chain,” Asia Times, 18 December 2007,
http://www.atimes.com/atimes/Middle_East/IL18Ak01.html . Cultural studies and military theory can make for uneasy
bedfellows, as this news article shows.
[13] Gates, Bill, “Memo from Bill Gates,” https://www.microsoft.com/en-
us/news/features/2012/jan12/gatesmemo.aspx . Still referred to twelve years later as “The BillG Memo” in Microsoft’s
Trustworthy Computing group.
[14] Howard, Michael, Steve Lipner, “The Trustworthy Computing Security Development Lifecycle,” March 2005,
http://msdn.microsoft.com/en-us/library/ms995349.aspx .

10. [15] Arghire, Ionut, “Adoption of Microsoft’s Security Development Lifecycle Spreads,” Softpedia, May 17 2012,
http://news.softpedia.com/news/Adoption-of-Microsoft-s-Security-Development-Lifecycle-SDL-Spreads-
270248.shtml .
[16] LeBlanc, David and Michael Howard, Writing Secure Code. Redmond, WA: Microsoft Press, 2002. A standard
reference work on the subject for Windows shops, but with applicability beyond that platform.
[17] Hernan, Shawn, Scott Lambert, Tomasz Oswalt, Adam Shostack, “Uncover Security Design Flaws Using the STRIDE
Approach.” MSDN Magazine, November 2006, posted to http://msdn.microsoft.com/en-us/magazine/cc163519.aspx .
A crisp overview of how STRIDE, DFD, and other Microsoft-born modeling constructs fit into that company’s Security
Development Lifecycle.
[18] Shostack, Adam, “Elevation of Privilege” (EoP Card Game). http://www.microsoft.com/security/sdl/adopt/eop.aspx
. A simple card game that teaches the STRIDE model in a fun way. The deck may be printed out, and an accompanying
video explains the rules. Aces are high.
[19] Davis, Noopur, “Secure Software Development Life Cycle Processes,” Department of Homeland Security, July 5,
2006. Online at https://buildsecurityin.us-cert.gov/articles/knowledge/sdlc-process/secure-software-development-
life-cycle-processes
[20, 21] LeBlanc, David, “DREADful,” from David LeBlanc’s Web Log, August 14, 2007. Online at
http://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx .
[22] OWASP Wiki, “Application Threat Modeling,” https://www.owasp.org/index.php/Application_Threat_Modeling . A
very good wiki page that shows how STRIDE, DREAD, and DFD combine.
[23, 24] Software Engineering Institute at Carnegie Mellon University, “OCTAVE,”
http://www.cert.org/resilience/products-services/octave/ .
[25] Software Engineering Institute at Carnegie Mellon University, “OCTAVE Allegro Method,”
http://www.cert.org/resilience/products-services/octave/octave-allegro-method.cfm
[26, 27] Carali, Richard A., James F. Stevens, Lisa R. Young, William R. Wilson, “Introducing OCTAVE Allegro: Improving
the Information Security Risk Assessment Process,” May 2007. Online at
http://resources.sei.cmu.edu/asset_files/TechnicalReport/2007_005_001_14885.pdf .
[28, 29] VerSprite, “PASTA Abstract: Process for Attack Simulation and Threat Assessment Abstract,”
http://versprite.com/docs/PASTA_Abstract.pdf , 2013.
[30] Larcom, Brenda and Eleanor Saitta for Stach & Liu, Trike (overview), http://octotrike.org/ . An overview of the
open-source system for automating certain parts of the modeling process.
[31] Larcom, Brenda and Eleanor Saitta for Stach & Liu, Trike (overview), Trike (docs),
http://www.octotrike.org/docs.shtml .
[32] Lockheed Martin, Cyber Kill Chain, http://www.lockheedmartin.com/us/what-we-do/information-
technology/cyber-security/cyber-kill-chain.html .
[33] Hutchins, Eric, Michael Cloppert, Rohan Amin Ph.D.; Lockheed Martin, “Intelligence-Driven Computer Network

11. Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains.” Posted 21 November 2010 at
http://papers.rohanamin.com/wp-content/uploads/papers.rohanamin.com/ 2011/08/iciw2011.pdf . A seminal paper
laying out the Cyber Kill Chain model, written under the auspices of Lockheed Martin.
[34] Lockheed Martin, ibid. The graphic on the right-hand side of the page is an elegant summary.
[35] Hutchins et al., ibid.
[36] Ricotta, Jim, “The cyber attack kill chain defense: How what the Air Force does applies to cyber security,”
http://www.enterprisecioforum.com/en/blogs/jim-ricotta/cyber-attack-kill-chain-defense. CIO, April 9, 2013.
[37, 38] van Dijk, Marten, Ari Juels, Alina Oprea, Ronald L. Rivest, “FlipIt: The Game of ‘Stealthy Takeover.” Cryptology
ePrint Archive: Report 2012/103, (February 2012), https://eprint.iacr.org/2012/103.pdf . The paper that introduced
FlipIT and its expected uses.
[39] Espenschied, Jon and Angela Gunn, “Threat Genomics: An evolution and recombination of best-available models
and techniques for characterizing and understanding computer network threats.” Presented at Metricon 7, August
2012; paper at https://github.com/ajaquith/securitymetrics/blob/master/source/attachments/Metricon-7-paper-
Threat-Genomics-Espenschied-Gunn-2012.pdf . A deep-dive look at the Threat Genomics model.
[40] Conversation with Jon Espenschied, May 2014.
[41] Espenschied et al., ibid.
[42] Cloppert, Mike, “Security Intelligence: Attacking the Cyber Kill Chain.” Posted 14 October 2009 at http://digital-
forensics.sans.org/blog/2009/10/14/security-intelligence-attacking-the-kill-chain/ This article is the third in a series
by one of the fathers of the kill-chain model; the entire series is highly worthwhile reading.
[43] Espenschied et al., ibid.
[44, 45] Kostadinov, DImitar, “The Cyber Exploitation Life Cycle.” Posted to Infosec Institute on 22 March 013 at
http://resources.infosecinstitute.com/the-cyber-exploitation-life-cycle/ . A good summary of Mandiant’s asset-based
model.
[46] Sample, Char, “Applicability of Cultural Markers in Computer Network Attack Attribution.” Posted July 2013 to
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=73423 . Sample applies the work of Geert Hofstede and
other sociologists to the task of attacker characterization and attribution. A similar line of inquiry appears in the Threat
Genomics model (though with the act of attribution de-emphasized).
[47] National Security Agency, “Defense in Depth: A practical strategy for achieving Information Assurance in today’s
highly networked environments,” http://www.nsa.gov/ia/_files/support/defenseindepth.pdf . Slightly dated, but the
concept is foundational.
[48] FedRamp, http://cloud.cio.gov/fedramp . The definitive guide to the Federal Risk and Authorization Management
Program (FedRAMP), the federal government’s standard for evaluating cloud services.
[49] FedRAMP CSP, http://cloud.cio.gov/fedramp/csp . Guidance for Cloud Service Providers (CSPs).
[50] National Institute of Standards and Technology, “Special Publications (800 Series): 800-53,”
http://csrc.nist.gov/publications/PubsSPs.html#800-53 . A new iteration of NIST SP 800-53 is expected in early June
2014.

12. [51] National Institute of Standards and Technology, “FIPS PUB 199: Standards for Security Categorization of Federal
Information and Information Systems,” http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf .
[52, 53] MITRE Corporation, “Common Attack Pattern Enumeration and Classification (CAPEC).”
http://capec.mitre.org/about/documents.html . A set of papers and slide decks explaining the official CAPEC schema.
[54] MITRE Corporation, “Structured Threat Information eXpression: A Structured Language for Cyber Threat
Intelligence Information,” http://stix.mitre.org/ . MITRE’s guide to its threat-information expression standard, used with
TAXII.
[55] MITRE Corporation, “Trusted Automated eXchange of Indicator Information: Enabling Cyber Threat Information
Exchange,” http://taxii.mitre.org/. MITRE’s guide to the transport mechanism that dovetails with the STIX language.
[56] MITRE Corporation, “Cyber Observable eXpression: A Structured Language for Cyber Observables,”
http://cybox.mitre.org/ . A schema for standardizing descriptions of observed phenomena.
[57] Shostack, Adam, Threat Modeling: Designing for Security. Indianapolis IN: Wiley, 2014. Shostack divides this
magisterial book into guidance focused on Microsoft’s STRIDE model and forward-looking advice on emerging models
(including some discussed in this paper).
[58] All About Agile, “What Is Agile? (10 Key Principles of Agile),” http://www.allaboutagile.com/what-is-agile-10-key-
principles/ . By no means a comprehensive look at the philosophy, nor it is the famous manifesto (linked from this
page), but a snappy overview of the methods and sensibility.
[59] Brenner, Bill, “Security Reminders Inspired By Van Halen’s Brown M&M Test,”
https://blogs.akamai.com/2013/08/infosecs-brown-mm-test.html .
[60] Heilman, Ethan, “FlipIt: The Game of Stealthy Takeover,” playable online at
http://ethanheilman.github.io/flipIt/playable_with_instructions.html .
[61] Shostack, Elevation of Privilege, ibid.
[62] Espenschied, Jon for Microsoft, “Persistence of Threat” (card deck), 2012. Online version currently unavailable.
Additional recommended reading:
Gamal, Maher Mohamed, Dr. Bahaa Hasan, Dr. Abdel Fatah Hegazy, “A security analysis framework powered by an
expert system,” International Journal of Computer Science and Security (IJCSS), VOl 4, Issue 6, 2011.
http://www.cscjournals.org/csc/download/issuearchive/IJCSS/volume4/IJCSS_V4_I6.pdf#page=17 . Interesting
research on an open-source framework built around an expert system that uses the CAPEC schema.
Hall, Wayne Michael and Gary Citrenbaum, Intelligence Analysis: How to think in complex environments. Santa Barbara,
CA: ABC-CLIO, 2010. Somewhat orthogonal to the nuts-and-bolts of threat modeling, but an invigorating read when
attempting to “think like a bad guy.”
Jager, Sheila Miyoshi, “On the Uses of Cultural Knowledge.” Monograph published by the Strategic Studies Institute in
November 2007 and posted at http://www.strategicstudiesinstitute.army.mil/pdffiles/pub817.pdf . The study
mentioned in the David Isenberg article, cited above.
Monson-Haefel, Richard (ed.), 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts.
Sebastopol, CA: O’Reilly, 2009. The process of threat modeling is closely analogous to that of software architecture.
Both use design patterns as a way to find, isolate and solve recurring problems.