Skip to content

Instantly share code, notes, and snippets.

@deeso

deeso/threat-modeling-cc.md

Last active May 6, 2023 19:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save deeso/f7567d7eba02698a75c6beb279eedb5f to your computer and use it in GitHub Desktop.
Save deeso/f7567d7eba02698a75c6beb279eedb5f to your computer and use it in GitHub Desktop.
Download ZIP
checklist and cheatsheet for threat modeling
Raw
threat-modeling-cc.md

Threat Model Checklist and Cheatsheet

Overview

Threat modeling is systems based analysis that identifies potential security short comings. Based on these analyses, design requirements are adopted to mitigate security risks. Furthermore, during the verification stages, explicit tests can be created to focus on or around issues surfaced by the threat model.

Threat models should be performed

  1. A product is created
  2. A new feature is released
  3. Security incident occurs
  4. Architectural or infrastructure changes

Threat modeling goals from [3]

  1. Assess Scope - What are we working on? This might be as small as a sprint, or as large as a whole system.
  2. Identify what can go wrong - This can be as simple as a brainstorm, or as structured as using STRIDE, Kill Chains, or Attack Trees.
  3. Identify countermeasures or manage risk - Decide what you’re going to do about each threat. That might be to implement a mitigation, or to apply the accept/transfer/eliminate approaches of risk management.
  4. Assess your work - Did you do a good enough job for the system at hand?

Prerequisites to a threat model

  1. Understanding of how the product should be used
  2. General understanding of the products function, potential components and service/systems on which it depends
    1. An understanding of the attack surface
    2. An understanding of who or what (e.g. agents or actors) will use the system
    3. An understanding of data sources and sinks in the system
    4. An understanding of components, services and systems used by the product or fecture
  3. Imagination and creativity to think of ways to abuse the TM subject or ways to use the TM subject for abuse

Eight simple questions

  1. (abuse) How can this be abused and by whom?
  2. (system) What are we working on?
  3. (actors or agents) Who will be using it?
  4. (data, sources and sinks) What does it produce or consume?
  5. (data flow and functionality) How does it work?
  6. (abuse and attacks) What can go wrong?
  7. (remdiation and design requirements) What are we going to do about it?
  8. (metrics, verification and security testing) Did we do a good job?

Malicious Activities to consider from [2]

  1. Spoofing: Impersonating another user or system component to obtain its access to the system
  2. Tampering: Altering the system or data in some way that makes it less useful to the intended users
  3. Repudiation: Plausible deniability of actions taken under a given user or process
  4. Information Disclosure: Release of information to unauthorized parties (e.g., a data breach)
  5. Denial of Service: Making the system unavailable to the intended users
  6. Elevation of Privilege: Granting a user or process additional access to the system without authorization
  7. Remote code execution: Code (binary or strings) can be injected into the system and executed without control
  8. Lateral Movement: - Expanding control over the target network beyond the initial point of compromise.

Basic Checklist

  • Has a high-level system description been created?
  • Have major components, features, processes, services, etc. (e.g. attack surface enumeration) that the system is composed of been called out?
  • Have major components, features, processes, services, etc. (e.g. attack surface enumeration) that the system depends on been called out?
  • Have major components, features, processes, services, etc. (e.g. attack surface enumeration) that the system supports been called out?
  • Has a high-level diagram of the system been created showing data flow been created?
  • Have good and bad actors been identified?
  • Have good or benign scenarios been described?
  • Have feasible abuse or attack scenarios been identified?
  • Have recommendations or mitigations been suggested to minimize or eliminate malicious activity?
  • Have test cases been defined to verify that the anticipated malicious behavior is remediated or minimizes (see Malicious Activities)?

Example Checklists for Malicious Activities

Spoofing

  • What happens when messages are spoofed from an external service or component to an internal service?
  • What happens when messages are spoofed between components (e.g. internal or external)?
  • Can spoofed be sent to a service such that they allow for authentication or authorization bypass?

Tampering

  • What happens when messages tampered and sent to the service?
  • Disregarding the technical expertise, is it possible to detect when messages have been tampered and sent to the system?
  • What happens if an actor tampers with input parameters (e.g. injecting XSS, SQLi, Lua, etc.)?
  • What happens if an actor manipulates file metadata or content?
  • What happens to tampered input when its handled by the application?

Repudiation

  • What happens when an actor performs and activity?
  • Can an actor perform activities as another entity, and is this logged?
  • Where are all the places where an actor must be identifed to the system?
  • Can the actor perform activities in these places without being authorized or by assuming the identity of others?

Information Disclosure

  • Is it possible for an actor or entity to access data they should not have access to?
  • What kind of data is accessed by the system?
  • Can access patterns or processes be bypassed for specific data sources?
  • What happens if a bad actor is able to access the database with hashes representing confidential information?

Denial of Service

  • What happens if a bad actor submits a malformed file causes the file parser to fail?
  • Can an actor overload the system with too many requests?
  • Can an actor overload ancillary or auxillary services indirectly with requests or traffic?

Elevation of Privilege

  • What happens if a bad actor submits a malformed file causes the file parser to fail?
  • Can an actor overload the system with too many requests?
  • Can an actor overload ancillary or auxillary services indirectly with requests or traffic?
  • Are users minimized such that high-privilege is only used when absolutely necessary?

Remote code execution

  • What happens if a bad actor submits a malformed file causes the file parser to fail?
  • What happens if a bad actor submits malicious Lua plugins or code in a file?
  • What happens if a bad actor tampers with data going into shared data stores (e.g. databases)?

Lateral Movement

  • What happens if a bad actor breaks out of a Docker container?
  • Is there appropriate logging or monitoring in place to 1) baseline environment activity and 2) detect potential anomalies?
  • Are services using defense-in-depth properly and separating privileged activities and functions?

References and Additional Reading

  1. Threat Modeling Manifesto
  2. STRIDE-LM Threat Model
  3. Threat Modeling
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment