Threat

Modeling with STRIDE

Slides adapted from Threat

Modeling: Designing for Security
(Wiley, 2014) by Adam Shostack
 Wouldn’t it be beHer to find
security issues before you write
a line of code?
So how can you do that?
 Ways to Find Security Issues
•  StaLc analysis of code
•  Fuzzing or other dynamic tesLng
•  Pen test/red team
•  Wait for bug reports aPer release
 Ways to Find Security Issues (2)
•  Threat modeling!
–  Think about security issues early
–  Understand your requirements beHer
–  Don’t write bugs into the code
–  And the subject of this lesson
So…how do you threat model?
 DefiniLons
•  What is a threat?
•  How is it different from a
–  vulnerability,
–  risk,
–  or just a problem?
•  What is a model?
 Think Like an AHacker?
•  Like thinking like a professional chef!
–  Even if you can, are you the chef at Olive Garden
or Mario Batalli’s?
•  Thinking like an aHacker – or focusing on
them is risky
–  What do they know? What will they do?
–  If you get these wrong, your threat modeling will
go astray
•  So don’t start from aHackers!
 Focus on Assets?
•  Assets: valuable things – the business cares!
•  But what’s an asset?
–  Something an aHacker wants?
–  Something you want to protect?
–  A stepping stone?
 Focus On What You’re Building!
•  Need an engineering approach
–  Predictable
–  Reliable
–  Scalable to a large product
•  Can’t be dependent on one brilliant person
•  Ideally, you understand it
•  Concrete and testable?
 How to Threat Model (Summary)
•  What are you building?
•  What can go wrong?
•  What are you going to do about it?
•  Check your work on 1-3
 What Are You Building?
•  Create a model of the soPware/system/
technology
•  A model abstracts away the details so you can
look at the whole
 What Are Some Modeling Methods?
•  Whiteboard diagrams
•  Brainstorming
•  Structured (“formal”) diagrams
–  Data flow diagrams
–  Swim lanes
–  State machines
•  MathemaLcal representaLons of code
Data Flow Diagram (Example)
Appendix E ■ Case Studies 513

DB
DBA (human) Users
(human)

DB Cluster
Web Clients
Acme SQL Account

Front End(s) Database DB Admin Log analysis

SQL Clients

Data Management Logs

Key:

Trust
External Entity Process data flow Data Store
Boundary
 Trust Boundaries
•  A trust boundary is everywhere two (or more)
principals interact
•  All interesLng boundaries are semi-permeable
–  Air gaps
–  Firewalls
–  Require policy mechanisms (which are hard)
•  Formal methods help build boundaries
–  IsolaLon
–  Type safety
–  Policy languages
–  Reference monitors/kernels
 between each participan
has extended swim lan
structure discussion of

Swim Lane Diagrams this extension ceremonie

“Human Factors and Us
A sample swim lane d

•  Show two or more enLLes Client

SYN
Server

communicaLng, each “in a lane”

SYN-ACK
•  Useful for network
communicaLon ACK

•  Lanes have implicit boundaries Data

between them

Figure 2-6: Swim lane diagram

 the appropriate security validations.
A very simple state machine for a door is shown in Figure
Wikipedia). The door has three states: opened, closed, and loc

State Machines
entered by a transition. The “deadbolt” system is much easier t
on the knob, which can be locked from either state, creating
diagram and user experience. Obviously, state diagrams can
quickly. You could imagine a more complex state diagram tha

•  Helpful for considering what changes

state that can result from either open or closed. (I started draw
trouble deciding on labels. Obviously, doors that can be ajar ar
and should not be deployed.) You don’t want to make archit
security state just to make modeling easier, but often simple models are ea
and reflect better engineering.
–  For example, unauthenLcated to
authenLcated
–  User to root/admin Opened

•  Rarely shows boundaries

Close door Open door
Transition
condition
Lock deadbolt
Transition
Closed Locked

Unlock deadbolt
State
 How to Threat Model (Summary)
•  What are you building?
•  What can go wrong?
•  What are you going to do about it?
•  Check your work on 1-3
 What Can Go Wrong?
•  Fun to brainstorm
•  Mnemonics, trees or libraries of threats can all
help structure thinking
•  Structure helps get you towards completeness
and predictability
•  STRIDE is a mnemonic
–  Spoofing, Tampering, RepudiaLon, InformaLon
Disclosure, Denial of Service, ElevaLon of Privilege
–  Easy, right?
 STRIDE
Threat Property DefiniLon Example
Violated
Spoofing AuthenLcaLon ImpersonaLng Pretending to be any of Bill Gates, Paypal.com
something or someone or ntdll.dll
else.
Tampering Integrity Modifying data or code Modifying a DLL on disk or DVD, or a packet as it
traverses the network

RepudiaLon Non-repudiaLon Claiming to have not “I didn’t send that email,” “I didn’t modify that
performed an acLon. file,” “I certainly didn’t visit that web site, dear!”

InformaLon ConfidenLality Exposing informaLon Allowing someone to read the Windows source
Disclosure to someone not code; publishing a list of customers to a web
authorized to see it site.
Denial of Service Availability Deny or degrade Crashing Windows or a web site, sending a
service to users packet and absorbing seconds of CPU Lme, or
rouLng packets into a black hole.

ElevaLon of Privilege AuthorizaLon Gain capabiliLes Allowing a remote internet user to run
without proper commands is the classic example, but going
authorizaLon from a limited user to admin is also EoP.
 Using STRIDE
•  Consider how each STRIDE threat could
impact each part of the model
–  “How could a clever aHacker spoof this part of the
system?...tamper with?… etc.”
•  Track issues as you find them
–  “aHacker could pretend to be a client & connect”
•  Track assumpLons
–  “I think that connecLon is always over SSL”
•  Consolidate into an aHack tree

 Spoofing On the Local Machine
Threat Example What the A7acker Does Notes/Examples
Spoofing a process Creates a file before the Then your process relies on
real process it
Abuses names Create a version of “sudo”
and alter PATH
Spoofing a filename Creates a file in the local Library, executable or
directory config file
Creates a link, changes it Also called ‘race condiLon’
or TOCTOU
Creates many files in a Code can easily create all
target directory possible /tmp/foo.random
 Spoofing Over a Network
Threat Example What the A7acker Does Notes/Examples
Spoofing a machine ARP spoofing
IP spoofing
DNS spoofing
DNS compromise Can be at the TLD, registrar
or DNS server
IP redirecLon
Spoofing a person Take over account “Stranded in London”
Set the display name
Spoofing a role Declares themselves to be SomeLmes opening a
that role special account, semng up
a domain/website, other
“verifiers”
 Tampering with a File
Threat Example What the A7acker Does Notes/Examples
Modifying a file… … which you own and you
rely on
… which they own and you
rely on
Modifying a file on a …you own
server…
…they own (or take over)
Modifies links or redirects Redirects are super-
common on the web, and
oPen rot away
 Tampering with Memory
Threat Example What the A7acker Does Notes/Examples
Modifying code Changes your code to suit Hard to defend against if
themselves the aHacker is running
code inside the trust
boundaries
Modifying data they’ve Supplies data to a pass by Works because of TOCTOU
supplied reference API, then issues
changes it
Supplies data into a shared
memory segment, then
changes it
 Tampering with a Network
Threat Example What the A7acker Does Notes/Examples
Redirects the flow of data Uses an aHack at some Pakistan/YouTube
to their machine network layer to redirect
traffic
Modifies data flowing over Easier (and more fun) with
the network wireless networks
Uses network tampering to
improve spoofing aHacks
 RepudiaLon
Threat Example What the A7acker Does Notes/examples
RepudiaLng an acLon Claims to have not Maybe they did, maybe they
clicked didn’t, maybe they’re honestly
confused
Claims to not have 1. Electronic or physical
received 2. Receipt is strange; does a client
downloading email mean you’ve
seen it? Did a network proxy pre-
fetch images? Was a package leP
on a porch?
Claims to be a fraud
vicLm
Uses someone else’s
account
 RepudiaLon AHacks on Logs
Threat Example What the A7acker Does Notes/Examples
Discovers there are no logs
Modifies data flowing over Puts data in the logs to </tr></html>
the network confuse you
 InformaLon Disclosure (Processes)
Threat Example What the A7acker Does Notes/Examples
Extracts user data Exploits bugs like SQL Can find this by looking to
injecLon to read db tables data stores, but here the
issue is the process
returning data it shouldn’t
Reads error messages
Extracts machine secrets Reads error messages Cannot connect to
database ‘foo’ as user ‘sql’
with password ‘&IO*(^&’
Exploits bugs “Heartbleed”
 InformaLon Disclosure (Data Stores)
Sub-category What the A7acker Does
Permissions Take advantage of missing or inappropriate ACLs
Take advantage of bad database permissions
File files protected by obscurity
Security Find crypto keys on disk or in memory
Get data from logs/temp files
Get data from swap files
See interesLng informaLon in filenames/directory names
Network See data traversing a network
Misc Obtain device, boot in new OS
InformaLon Disclosure (Data Flow)
Sub-category What the A7acker Does
Network Read data on a network
Redirects traffics to enable reading data on the network
Metadata Learns secrets by analyzing traffic
Learns who talks to whom by watching the DNS
Learns who talks to whom by analyzing social network
informaLon
 Denial of Service
Threat Example What the A7acker Does Notes/Examples
Against a process Absorb memory (ram or disk)
Absorb CPU
Uses a process as an amplifier
Against business logic “Too many login
aHempts”
Against a data store Fills the data store
Makes enough requests to slow the
system
Against a data flow Consumes network resources
Can be temporary (as the aHack conLnues; fill the network) or persist beyond that (fill
a disk)
 ElevaLon of Privilege (“EoP”)
Threat Example What the A7acker Does Notes/Examples
EoP Against process via Sends inputs the code Very common, usually high
corrupLon doesn’t handle properly impact
Gains read/write access to WriLng memory more
memory obviously bad
EoP via misused
authorizaLon checks
EoP via buggy Centralizing checking
authorizaLon checks makes consistency,
correctness easier
EoP via data tampering Modify bits on disk
 Using STRIDE
•  Consider how each STRIDE threat could
impact each part of the model
–  “How could a clever aHacker spoof this part of the
system?...tamper with?… etc.”
•  Track issues as you find them
–  “aHacker could pretend to be a client & connect”
•  Track assumpLons
–  “I think that connecLon is always over SSL”
•  Consolidate into an aHack tree

 When to Find Threats
•  Start at the beginning of your project
–  Create a model of what you’re building
–  Do a first pass for threats
•  Dig deep as you work through features
–  Think about how threats apply to your miLgaLons
•  Check your design & model matches as you
get close to shipping
AHackers Respond to Your Defenses
 Playing Chess
•  The ideal aHacker will follow the road you
defend
–  Ideal aHackers are like spherical cows — they’re a
useful model for some things
•  Real aHackers will go around your defenses
•  Your defenses need to be broad and deep
 “Orders of MiLgaLon”
By Example:
Order Threat MiEgaEon
1st Window smashing Reinforced glass
2nd Window smashing Alarm
3rd Cut alarm wire Heartbeat signal
4th Fake heartbeat Cryptographic signal integrity

•  Thus window smashing is a first order threat, cumng

alarm wire, a third-order threat
•  Easy to get stuck arguing about orders
•  Are both stronger glass & alarms 1st order
miLgaLons? (Who cares?!)
•  Focus on the concept of interplay between
miLgaLons & further aHacks
 How to Approach SoPware
•  Depth first
–  The most fun and “insLnctual”
–  Keep following threats to see where they go
–  Can be useful skill development, promoLng “flow”

•  Breadth first
–  The most conservaLve use of Lme
–  Most likely to result in good coverage
Tracking Threats and AssumpLons
•  There are an infinite number of ways to
structure this
•  Use the one that works reliably for you
•  (Hope doesn’t work reliably)
 Example Threat Tracking Tables
Diagram Element Threat Type Threat Bug ID
Data flow #4, web Tampering Add orders without 4553 “Need
server to business payment checks integrity controls
logic on channel”
Info disclosure Payment 4554 “need crypto”
instruments sent in #PCI
clear

Threat Type Diagram Element(s) Threat Bug ID

Tampering Web browser AHacker modifies 4556 “Add order-
our JavaScript order checking logic to
checking server”
Data flow #2 from Failure to 4557 “Add enforce
browser to server authenLcate HTTPS everywhere”

Both are fine, help you iterate over diagrams in different ways
 Example AssumpLon Tracking
AssumpEon Impact if it’s Who to talk Who’s Follow-up Bug #
wrong to following up by date
It’s ok to Availability Alice Bob April 15 4555
ignore will be
denial of below spec
service
within the
data center

•  Impact is someLmes so obvious it’s not worth filling out

•  Who to talk to is not always obvious, it’s ok to start out blank
•  Tracking assumpLons in bugs helps you not lose track
•  Treat the assumpLon as a bug – you need to resolve it
 The Customer/Vendor Boundary
•  There is always a trust boundary when:
–  Your code goes to someone else’s (device/premises)
–  Their data comes to your code
•  Lawyers, pretending do not eliminate human trust issues
•  You need to think about it while deciding what
happens over the data flow shown

Your soPware Your soPware

Your data center Customer device

 Generic API Threat Model
•  Perform security checks inside the boundary
•  Copy before validaLon for purpose
–  Is hHp://evil.org/pwnme.html “valid”?
•  Define the purpose for data, validate near that
definiLon
•  Manage error reporLng
•  Document what checks happen where
•  Do crypto in constant Lme
•  Address the security requirements for your API
 How to Threat Model (Summary)
•  What are you building?
•  What can go wrong?
•  What are you going to do about it?
•  Check your work on 1-3
 What Are You Going to Do About It?
•  For each threat:
–  Fix it!
–  MiLgate with standard or custom approaches
–  Accept it?
–  Transfer the risk?
•  For each assumpLon:
–  Check it
–  Wrong assumpLons lead to reconsider what goes
wrong
 Fix It!
•  The best way to fix a security bug is to remove
funcLonality
–  For example, if SSL doesn’t have a “heartbeat”
message, the “heartbleed bug” couldn’t exist
–  You can only take this so far
–  OPenLmes end up making risk tradeoffs
•  MiLgate the risk in various ways (next slide)
 MiLgate
•  Add/use technology to prevent aHacks
•  For example, prevent tampering:
–  Network: Digital signatures, cryptographic integrity
tools, crypto tunnels such as SSH or IPsec
•  Developers, sysadmins have different toolkits for
miLgaLng problems
•  Standard approaches available which have been
tested & worked through
•  SomeLmes you need a custom approach
 Some Technical Ways to Address
Threat MiEgaEon Technology Developer Example Sysadmin Example
Spoofing AuthenLcaLon Digital signatures, AcLve Passwords, crypto
directory, LDAP tunnels
Tampering Integrity, permissions Digital signatures ACLs/permissions,
crypto tunnels
RepudiaLon Fraud prevenLon, Customer history risk Logging
logging, signatures management
InformaLon Permissions, Permissions (local), PGP, Crypto tunnels
disclosure encrypLon SSL
Denial of service Availability ElasLc cloud design Load balancers, more
capacity
ElevaLon of AuthorizaLon, isolaLon Roles, privileges, input Sandboxes, firewalls
privilege validaLon for purpose,
(fuzzing*)

* Fuzzing/fault injecLon is not a miLgaLon, but a great tesLng technique

See chapter 8, Threat Modeling for more
 Custom MiLgaLons
•  SomeLmes the standard technologies don’t
work for your situaLon
•  Requires custom miLgaLons (or risk
acceptance)
•  Easy to get a custom miLgaLon wrong
•  Hard and expensive to test (page 176)
 AccepLng Risk
•  Works best when it’s your risk
–  Your organizaLon can accept risk
–  Be careful about “accepLng” risk for your
customers.
•  Customer risk acceptance
–  Via user interface
–  SomeLmes the customer has details you can’t
have (is this network your work or a coffee shop?)
 Transferring Risk
•  Via license agreements, terms of service, etc.
•  Silently
•  Both can lead to unhappy customers
–  Threat that no one reads ToS
–  Surprise!
–  Media blowups
 Some Technical Ways to Address
Threat MiEgaEon Technology Developer Example Sysadmin Example
Spoofing AuthenLcaLon Digital signatures, AcLve Passwords, crypto
directory, LDAP tunnels
Tampering Integrity, permissions Digital signatures ACLs/permissions,
crypto tunnels
RepudiaLon Fraud prevenLon, Customer history risk Logging
logging, signatures management
InformaLon Permissions, Permissions (local), PGP, Crypto tunnels
disclosure encrypLon SSL
Denial of service Availability ElasLc cloud design Load balancers, more
capacity
ElevaLon of AuthorizaLon, isolaLon Roles, privileges, input Sandboxes, firewalls
privilege validaLon for purpose,
(fuzzing*)

* Fuzzing/fault injecLon is not a miLgaLon, but a great tesLng technique

See chapter 8, Threat Modeling for more
 Understanding AuthenLcaLon
•  To prove or show (something, esp. a claim or
an ar>s>c work) to be true or genuine
•  Applies to all sorts of things
–  Programs or libraries on disk
–  Remote machines
–  People (a complex subject, covered later in the
course)
 TacLcs for AuthenLcaLon
•  Local
–  Leverage the OS/program (database, web server, etc)
–  Defaults are not always secure
•  Remote machines
–  Cryptographic methods (more reliable)
–  Consistency checking DNS, IP, route (less reliable)
•  Cryptographic key exchange
–  DNSSec, PKI, etc: All involve trust delegaLon
–  Manual: expensive, someLmes worthwhile for
exisLng business relaLonships
 Developer Ways to Address Spoofing
•  Leverage the OS
–  Use full pathnames (what does open(“foo.txt”)
find?)
–  Make pathnames canonical
•  Resolving links including ../ or symlinks
•  Remove %20 or other encoding
–  Check permissions
–  Shared directories are usually troublesome
•  Cryptographic idenLfiers & validaLon
OperaLonal Ways to Address Spoofing
•  Difficult to improve local (on-system) name
resoluLon when the code is done
•  Possible to use SSH or IPSec or other crypto
tunneling to reduce spoofing issues over the
network
Technologies for Addressing Spoofing
•  AuthenLcaLng computers
–  IPSec, DNSSec, SSH Host keys
–  Kerberos
–  Windows Domain authenLcaLon
–  PKI with SSL/TLS
•  AuthenLcaLng bits (files, messages, etc)
–  Digital signatures
–  Hashes (appropriately managed)

Technologies for Addressing Spoofing (2)
1.  Something you know, like a password
2.  Something you have, like an access card
3.  Something you are (or are measured to be)
–  “Biometrics”
–  Fingerprints, vein paHerns, photographs
4.  Someone you know who can authenLcate you
•  The first three are tradiLonal, #4 is new
•  “MulL-factor authenLcaLon” usually means more than
one from the list
–  Some people call channels a factor
–  Many of them should threat model beHer
 Understanding Integrity
•  To interfere with (something) in order to cause
damage or make unauthorized altera>ons
•  Can apply to data wherever it is, including:
–  Disk
–  Network
–  Memory
 TacLcs for Integrity
•  System defenses
–  Permissions (operaLng system/program)
•  Cryptographic defenses
–  Digital signatures
–  Hashes/MACs
•  Logging and audit
–  These do not prevent, but may deter
–  Generally used as a fallback or defense in depth
 Developer Ways to Address Integrity
•  Use permissions as provided
•  Cryptography is required over a network
•  ImplemenLng a permission system is hard
–  Lots of mistakes have been made & documented
OperaLonal Ways to Address Integrity
•  Add addiLonal protecLons
–  Tripwire-like systems on local machine
–  Tunneling over network
•  Tripwire: acLng on
alerts is key!
–  Don’t be these folks ->
•  Good alert design is a pre-requisite
–  Too many alerts, people will be overwhelmed
–  Too few, they’ll miss stuff
 Technologies for Addressing Integrity
•  Protect files with
–  Digital signatures
–  ACLs/permissions
–  Hashes
–  Windows Mandatory Integrity Control features
–  Unix immutability
•  Protect network traffic with
–  SSL
–  SSH
–  IPSec
–  Digital signatures

 Understanding Non-RepudiaLon
•  Repudia>on: To refuse to accept or be
associated with; deny the truth or validity of
some statement
•  Non-repudiaLon are the tools & technologies
to establish what happened — ideally to the
saLsfacLon of everyone involved or impacted
•  Bridges business & technical levels
•  RepudiaLon can be a feature
–  “Off The Record”
 TacLcs for Non-RepudiaLon
•  Fraud prevenLon
–  Internal fraud such as embezzlement
–  “Customer” fraud prevenLon
•  Logs
–  As much as you can, keep for as long as you can
•  Cryptography
 “Customer” Fraud PrevenLon
•  Alice’s account is taken over & abused (or)
•  Bob creates an account for fraud
•  Must manage both
•  Stable customers are good, predictable
•  Technologies/services
–  ValidaLon services
–  Customer history sharing
–  MulL-merchant data
–  Purchase device tracking
 Developer Ways to Address
•  Log business logic
–  Eg “For this transacLon, we saw that geolocate(ip)
was ‘SeaHle,’ which is typical for this account.”
•  Cryptographic digital signatures
–  Most useful today between business partners, not
consumer-usable
 OperaLonal Ways to Address
•  OperaLons get stuck invesLgaLng
–  Table-top exercises may expose issues that the
logs don’t exist
•  Scaling
–  Logs may end up in diverse places
–  Dedicated people
–  Specialized tooling
 Technologies for Addressing
RepudiaLon
•  Logs
–  Logging
–  Log analysis tools
–  Secured log storage
•  Digital signatures
•  Secure Lme stamps
•  Trusted third parLes

 Understanding ConfidenLality
•  To ensure that informa>on is only disclosed to
authorized par>es
•  Secrets in data
–  Yours: financial results, new product plans
–  Entrusted to you: private data
–  Complex rules: Who can see that Facebook post?
•  Secrets also exist in metadata
–  “Layoff leHer for Alice.docx”, “Janlayoff/alice.docx”
–  Calls to an STD clinic (repeatedly?!)
 TacLcs for ConfidenLality
•  On a system
–  ACLs/permissions
–  Cryptography
•  Between systems
–  Cryptography
•  To hide the existence of informaLon
–  Steganography
 Developer Ways to Address
•  Permissions/ACLs
•  Cryptography
–  Data (file on disk, email message)
–  Container (volume encrypLon, email connecLons)
–  Requires proper key management
–  Remember: EncrypLon doesn’t provide
authenLcaLon or integrity
 OperaLonal Ways to Address
•  Add permissions/ACLs
•  Volume encrypLon
–  Protects if the machine is stolen and powered
down
–  Doesn’t protect against an aHacker who breaks in
•  Network encrypLon (SSH, SSL, IPSec)
 Technologies for ConfidenLality
•  ProtecLng files
–  ACLs/Permissions
–  EncrypLon
–  Appropriate key management
•  ProtecLng network data
–  EncrypLon
–  Appropriate key management
•  CommunicaLon headers/act of communicaLon
–  Mix networks
–  Onion rouLng
–  Steganography
 Understanding Availability
•  Being able to meet a defined or implied SLA
•  AHacks can absorb any resource
–  Disk, network, CPU
•  AHacks can be transient or require intervenLon
–  Network flooding stops when aHacker does
–  Fork bomb (eg: while(1) {fork();}) might need reboot
–  Full disk might require human intervenLon
 TacLcs for Availability
•  Have enough resources to serve requests
•  Proof of work
–  … “Proves Not to Work”
–  Bitcoin uses high cost proofs
•  Proof of communicaLon
 Developer Ways to Address
•  Avoid fixed-size buffers
–  For example, 5 half-open TCP connecLons
•  Consider
–  Resources you consume per request
–  How many requests you’ll serve
–  Clever aHacks that balloon resource use
–  Recovery
 OperaLonal Ways to Address
•  Quotas
•  ElasLc cloud systems to add more resources
 Technologies for Addressing DoS
•  ACLs
•  Filters
•  Quotas (rate limits, thresholding, throHling)
•  High availability design
•  Extra bandwidth
•  Cloud services
 Understanding AuthorizaLon
•  Eleva>on of Privilege is one class of
authorizaLon bypass
–  The only one covered here
–  AuthorizaLon systems are their own sub-field
 TacLcs for AuthorizaLon
•  Limit the aHack surface
–  For example, small number of setuid programs
–  Use sandboxes for network-exposed code
–  Don’t run as root/admin
–  Be aware that there’s oPen elevaLon paths for
semi-privileged accounts
•  Comprehensible, manageable permissions
systems
 Developer Ways to Address
•  Limit the aHack surface
•  Carefully define purpose & validaLon rules for
inbound data
•  Define what you’ll accept, not what you reject
•  Reject bad input, don’t try to saniLze
•  Looped canonicalizaLon rouLnes
•  Transform from one form to another (e.g.,
markdown to html)
 OperaLonal Ways to Address
•  Defense in depth
•  Run each target as its own unique limited user
–  Unix “nobody” account ended up quite privileged
•  Sandboxes
 Technologies for Addressing
•  ACLs
•  Groups or role membership
•  Role based access controls
•  Windows privileges (runas)/Unix sudo
•  Chroot, apparmor, other unix sandboxes
•  MOICE Windows sandbox
•  Input validaLon for defined purposes
 How to Threat Model (Summary)
•  What are you building?
•  What can go wrong?
•  What are you going to do about it?
•  Check your work on 1-3
 Check Your Work
•  Requirements engineering and quality
assurance
•  Check that you covered all the threats &
assumpLons
•  Check that each is covered well
 TesLng SoPware You Make
•  All threats you find can be tested
•  In agile shops that rely on Test-Driven
Development (TDD), threat modeling is a
great way to design tests
•  Start with a test to execute the threat
•  ConLnue with tests that bypass miLgaLons
(aka 2nd order aHacks)
•  AutomaLon vs manual

 PenetraLon TesLng
•  Aka “ethical hacking,” “red teaming”
•  Improve the security of your code by breaking
it
•  Differs from threat modeling
–  Done late
–  Hard to judge scope
–  SomeLmes “black box” where testers start
without knowledge of system
 TesLng SoPware You Acquire
•  Build a soPware model
–  Use the documentaLon and actual soPware
–  See if they include a threat model or security
operaLons guide
•  Look for threats
•  Address the issues you find
 Build a SoPware Model
•  Components
–  Start with the binaries, databases, dependencies
–  Some will likely merge into a single process for
threat modeling purposes
•  Trust boundaries
–  Account(s) used
–  Sockets, RPC
–  Admin interfaces
•  Look at pla•orm changes on install
•  Diagram as you find things
 Look for Threats
•  Use the model you’ve created
•  This is similar to looking for threats in any
other soPware
–  You’re less familiar with it
–  It may include relevant documentaLon
–  (If not, what does that tell you?)
•  Use STRIDE, CAPEC, aHack trees, etc.
 Address the Issues You Find
•  Ask the creator to fix them
–  Be ready to discuss views of requirements, tradeoffs
–  Some backwards vendors will threaten you (this is a
red flag they don’t understand security)
•  Look for an alternaLve
–  Easier if you TM early
•  MiLgate yourself
–  Using operaLonal security techniques from earlier
classes on “what to do about it”
 QA’ing the Threat Modeling Process
•  Another aspect of checking your work
•  Check soPware model/reality conformance
•  Check that each task and process is done
•  Bug checking: Look at each TM bug
–  Is it closed properly (fixed, not won•ix)?
–  Is there a test case?
–  Tags on bugs really helpful here
 Recap
•  Think like an aHacker isn’t repeatable
•  Focusing on assets and aHackers doesn’t work for
most people
•  4 quesLons
–  What are you building?
–  What can go wrong?
–  What are you going to do about it
–  Checking your work
•  For more, Threat Modeling Designing for Security