From e13092693c093d26c35d29c31ab0a611cc389258 Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Thu, 20 Mar 2025 14:02:35 -0700 Subject: [PATCH 1/6] add threat model draft --- _layouts/threatmodel.html | 194 ++++++++++++++++++++++++++++++++++++++ threatmodel.md | 9 ++ 2 files changed, 203 insertions(+) create mode 100644 _layouts/threatmodel.html create mode 100644 threatmodel.md diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html new file mode 100644 index 0000000..52161f6 --- /dev/null +++ b/_layouts/threatmodel.html @@ -0,0 +1,194 @@ + + + {%- include head.html -%} + + {%- include header.html -%} +
+
+ +
+
+

Distrust Threat Model

+
+

Executive Summary

+

This document outlines a high-assurance threat model for mission-critical systems. We assume that adversaries are highly sophisticated, well funded, and patient, with access to an extensive arsenal of attack techniques—from zero-day vulnerabilities (often combined into complex exploit chains) to physical breaches, supply chain compromises, and advanced side-channel attacks. Real-world incidents, such as the SolarWinds attack and tactics reminiscent of the Stuxnet incident, illustrate the threat environment we plan for.

+

This model is designed to guide organizations in implementing layered defenses that align with their specific risk profiles. It is structured into four levels, ranging from basic protections to defenses capable of withstanding state-level adversaries.

+
+
+ +
+
+

Scope and Context

+

Scope: This threat model applies to systems handling sensitive operations and critical infrastructure, covering both digital and physical attack vectors.

+

Assets Protected: Sensitive data, cryptographic keys, operational control systems, and key hardware/firmware components.

+
+
+ +
+
+

General Threat Model Assumptions

+
    +
  • All screens and displays are assumed to be observable by adversaries.
    • +
  • Input devices, such as keyboards, are assumed to be monitored or logged by potential attackers.
    • +
  • Any system components (firmware or bootloaders) not verified on every boot are considered at risk.
    • +
  • Network-connected systems and administrative endpoints are potential compromise points.
    • +
  • Insider threats are assumed; some personnel or third-party maintainers may be compromised.
    • +
  • Physical attacks are viable and likely, given the history of supply chain and infrastructure breaches.
    • +
  • Side-channel attacks (similar to those observed with Spectre/Meltdown) represent realistic threats.
    • +
+
+
+ +
+
+

Threat Model Levels

+

The threat model is structured into four levels, each corresponding to increasingly sophisticated adversary capabilities and controls. Organizations can choose the appropriate level based on their risk tolerance and operational needs.

+ +
+
+ +
+
+

Level 1

+
Adversary
+

A low-skilled individual targeting many organizations. This adversary relies on broad, unsophisticated tactics—such as phishing—to steal credentials or sensitive data.

+
Attacks
+
    +
  • Phishing campaigns to steal credentials or sensitive data.
    • +
  • Injecting malware into systems via remote attacks.
    • +
+
Requirements
+
    +
  • MUST enforce hardware-anchored authentication for critical actions.
    • +
  • MUST require hardware-anchored authorization for sensitive operations.
    • +
  • MUST validate operations using a threshold-based policy to prevent single-point compromises.
    • +
+
Reference Design
+
    +
  • Ensure that all users performing critical operations use robust, hardware-based authentication methods (e.g., FIDO2, smart cards).
    • +
  • Implement backend systems that require cryptographic signatures from known, secure devices before approving sensitive actions.
    • +
  • Store audit logs and critical keys in tamper-evident, append-only databases.
    • +
  • Employ cryptographic challenges (e.g., hashing operation requests) that must be signed by hardware tokens.
    • +
+
+
+ +
+
+

Level 2

+
Adversary
+

A skilled and resourceful individual targeting a single organization. This adversary employs focused social engineering, vulnerability exploitation, and man-in-the-middle attacks—similar to tactics observed during the WannaCry outbreak.

+
Attacks
+
    +
  • Compromising a team member with privileged access.
    • +
  • Injecting malicious code into software components.
    • +
  • Exploiting vulnerabilities shortly after public disclosure.
    • +
+
Requirements
+
    +
  • + Production Access: +
      +
    • MUST NOT be possible by any single individual—use multi-factor, multi-party authorization.
      • +
    • MUST be conducted via dedicated, tamper-evident workstations.
      • +
    • MUST utilize hardware security modules (HSMs) for critical key management.
      • +
    +
    • +
  • + Software Integrity: +
      +
    • MUST be built deterministically with reproducible builds.
      • +
    • MUST undergo extensive security review and be signed by trusted keys.
      • +
    • MUST be kept up-to-date with all known security patches.
      • +
    +
    • +
+
Reference Design & Key Management
+
    +
  • Create offline certificate authority (CA) keys and store them securely.
    • +
  • Use air-gapped systems to generate keys and transfer them to hardware tokens.
    • +
  • Implement immutable, attested environments (e.g., TPM-based, cloud enclaves) to manage critical keys.
    • +
+
+
+ +
+
+

Level 3

+
Adversary
+

An organized group with significant funding and diverse expertise. Such adversaries can coordinate multi-faceted attacks and may have already compromised parts of the environment, representing coordinated internal and external threats.

+
Attacks
+
    +
  • Coercing or compromising internal personnel to tamper with systems.
    • +
  • Exploiting sophisticated zero-day vulnerabilities against internet-connected components.
    • +
+
Requirements
+
    +
  • MUST require multi-key signatures stored in geographically separate locations.
    • +
  • MUST enforce independent validations at each signing location.
    • +
  • MUST maintain strict segregation of duties among different teams.
    • +
+
+
+ +
+
+

Level 4

+
Adversary
+

A state actor or similarly well-resourced entity capable of executing advanced attacks—including supply chain subversion, side-channel exploitation, and insider manipulation. Techniques seen in operations by groups like the Equation Group underscore the sophistication at this level.

+
Attacks
+
    +
  • Compromising the supply chain of any hardware or firmware component.
    • +
  • Relocating devices for rapid, covert attacks followed by restoration to the original environment.
    • +
  • Utilizing advanced side-channel attacks (e.g., Differential Fault Analysis) and non-deterministic operations.
    • +
  • Data remanence attacks that extract sensitive information even after deletion.
    • +
+
Requirements
+
    +
  • + All Signing Systems: +
      +
    • MUST have dual implementations of all policy and signing logic.
      • +
    • MUST use multiple, unrelated hardware supply chains for cryptographic material.
      • +
    • MUST produce deterministic outputs verified independently.
      • +
    • MUST store keys in facilities with high physical and environmental security (e.g., Class III vaults, per NSA TEMPEST guidelines).
      • +
    • MUST continuously monitor environmental conditions and enforce destruction protocols upon significant deviations.
      • +
    • MUST employ robust, multi-factor physical access controls.
      • +
    +
    • +
+
+
+ +
+
+

Mitigation Principles

+
    +
  • Elimination of Single Points of Failure: The design ensures that no single component or individual can compromise the system. Multiple layers of control span software, firmware, hardware, and operational processes.
    • +
  • Transparency and Verification: Fully open source software and firmware enable thorough security reviews.
    • +
  • Minimized Supply Chain Dependencies: Custom, purpose-specific tooling reduces reliance on external components, thereby mitigating supply chain risks.
    • +
  • Deterministic Builds: We strive for fully reproducible builds to ensure consistency and detect unauthorized modifications. Projects like StageX exemplify this approach.
    • +
  • Secure Hardware & Physical Controls: Hardware is selected for its ability to disable network access or for lacking wireless interfaces, and robust tamper-evident measures are implemented.
    • +
  • Environmental and Side-Channel Mitigations: Techniques such as TEMPEST (refer to NSA TEMPEST) and soundproofing help block unauthorized emanations and physical attacks.
    • +
+
+
+ +
+
+

Summary

+

This threat model is designed to ensure the resilience and integrity of mission-critical systems by preparing for a wide range of potential attacks—from common remote threats to highly sophisticated state-level adversaries. It is especially important for organizations handling sensitive operations, managing critical infrastructure, or storing highly confidential information.

+

Importantly, the model’s four-tier structure allows organizations to select the appropriate level of defense based on their risk profile. For many, the robust controls of Level 1 or Level 2 may be sufficient, while only those facing exceptionally high risks need to implement the extensive measures of Level 3 or Level 4.

+

References: NIST SP 800-30, ISO 27005, and OWASP Threat Modeling Framework

+
+
+
+
+ + + diff --git a/threatmodel.md b/threatmodel.md new file mode 100644 index 0000000..9c40f89 --- /dev/null +++ b/threatmodel.md @@ -0,0 +1,9 @@ +--- +title: Threat Model +tagline: Distrust | Threat Model +summary: The type of threat we seek to mitigate +layout: threatmodel +permalink: /threatmodel.html +thumbnail: /assets/base/threatmodel-thumbnail.png +--- + From cacf399736af14013485cd2f322eeded8157fdcd Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Sat, 26 Apr 2025 13:38:18 -0700 Subject: [PATCH 2/6] feat: simplify content --- _layouts/threatmodel.html | 145 +++++++------------------------------- 1 file changed, 26 insertions(+), 119 deletions(-) diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html index 52161f6..32f3ed4 100644 --- a/_layouts/threatmodel.html +++ b/_layouts/threatmodel.html @@ -3,30 +3,18 @@ {%- include head.html -%} {%- include header.html -%} -
+
-
-

Distrust Threat Model

-
-

Executive Summary

-

This document outlines a high-assurance threat model for mission-critical systems. We assume that adversaries are highly sophisticated, well funded, and patient, with access to an extensive arsenal of attack techniques—from zero-day vulnerabilities (often combined into complex exploit chains) to physical breaches, supply chain compromises, and advanced side-channel attacks. Real-world incidents, such as the SolarWinds attack and tactics reminiscent of the Stuxnet incident, illustrate the threat environment we plan for.

-

This model is designed to guide organizations in implementing layered defenses that align with their specific risk profiles. It is structured into four levels, ranging from basic protections to defenses capable of withstanding state-level adversaries.

+

Distrust Threat Model

+

Unlike conventional frameworks (e.g., STRIDE, PASTA) that focus on identifying and mitigating specific risks, the Distrust Threat Model, rather than modeling threats as potential risks, assumes that systems are already compromised. This pessimistic, assumption-driven approach focuses on building systems that can survive and remain secure even when critical components fail or are actively under attack by sophisticated threat actors at all levels.

-

Scope and Context

-

Scope: This threat model applies to systems handling sensitive operations and critical infrastructure, covering both digital and physical attack vectors.

-

Assets Protected: Sensitive data, cryptographic keys, operational control systems, and key hardware/firmware components.

-
-
- -
-
-

General Threat Model Assumptions

+

Assumptions

  • All screens and displays are assumed to be observable by adversaries.
  • Input devices, such as keyboards, are assumed to be monitored or logged by potential attackers.
    • @@ -41,14 +29,9 @@
    -

    Threat Model Levels

    -

    The threat model is structured into four levels, each corresponding to increasingly sophisticated adversary capabilities and controls. Organizations can choose the appropriate level based on their risk tolerance and operational needs.

    - +

    Levels

    +

    While the end-goal is to adequately address the risks which stem from the assumptions, organizations are at varying levels of maturity and often need a path towards mitigating threats in a phased approach. To this end, the threat model defines 4 levels, each corresponding to increasingly more sophisticated threat actors as the levels increase. Each threat actor is assumed to have access to specific methods of attack limited by factors such as cost to execute, sophistication, time required etc.

    +

    It is a reasonable approach to apply different threat model levels to different parts of systems. It's also worth noting that essentially no companies, to our knowledge meet adequate controls for Level 4 adversaries except for select nation states organizations and militaries.

    @@ -56,24 +39,12 @@

    Level 1

    Adversary
    -

    A low-skilled individual targeting many organizations. This adversary relies on broad, unsophisticated tactics—such as phishing—to steal credentials or sensitive data.

    +

    An unskilled or lightly skilled individual leveraging widely available tools and publicly known vulnerabilities. Their attacks are largely opportunistic and automated, rather than targeted.

    Attacks
      -
    • Phishing campaigns to steal credentials or sensitive data.
      • -
    • Injecting malware into systems via remote attacks.
      • -
    -
    Requirements
    -
      -
    • MUST enforce hardware-anchored authentication for critical actions.
      • -
    • MUST require hardware-anchored authorization for sensitive operations.
      • -
    • MUST validate operations using a threshold-based policy to prevent single-point compromises.
      • -
    -
    Reference Design
    -
      -
    • Ensure that all users performing critical operations use robust, hardware-based authentication methods (e.g., FIDO2, smart cards).
      • -
    • Implement backend systems that require cryptographic signatures from known, secure devices before approving sensitive actions.
      • -
    • Store audit logs and critical keys in tamper-evident, append-only databases.
      • -
    • Employ cryptographic challenges (e.g., hashing operation requests) that must be signed by hardware tokens.
      • +
    • Scanning for and exploiting known vulnerabilities with public exploits.
      • +
    • Phishing attempts using off-the-shelf kits.
      • +
    • Basic malware deployment (e.g., ransomware-as-a-service).
@@ -82,37 +53,13 @@

Level 2

Adversary
-

A skilled and resourceful individual targeting a single organization. This adversary employs focused social engineering, vulnerability exploitation, and man-in-the-middle attacks—similar to tactics observed during the WannaCry outbreak.

+

A skilled and resourceful individual specifically targeting a single organization. This adversary employs focused efforts to breach systems, including sophisticated social engineering and exploitation of newly disclosed vulnerabilities.

Attacks
    -
  • Compromising a team member with privileged access.
    • -
  • Injecting malicious code into software components.
    • -
  • Exploiting vulnerabilities shortly after public disclosure.
    • -
-
Requirements
-
    -
  • - Production Access: -
      -
    • MUST NOT be possible by any single individual—use multi-factor, multi-party authorization.
      • -
    • MUST be conducted via dedicated, tamper-evident workstations.
      • -
    • MUST utilize hardware security modules (HSMs) for critical key management.
      • -
    -
    • -
  • - Software Integrity: -
      -
    • MUST be built deterministically with reproducible builds.
      • -
    • MUST undergo extensive security review and be signed by trusted keys.
      • -
    • MUST be kept up-to-date with all known security patches.
      • -
    -
    • -
-
Reference Design & Key Management
-
    -
  • Create offline certificate authority (CA) keys and store them securely.
    • -
  • Use air-gapped systems to generate keys and transfer them to hardware tokens.
    • -
  • Implement immutable, attested environments (e.g., TPM-based, cloud enclaves) to manage critical keys.
    • +
  • Focused spear-phishing campaigns against key personnel.
  • +
  • Rapid exploitation of vulnerabilities shortly after public disclosure ("N-day" exploitation).
    • +
  • Man-in-the-middle (MitM) attacks against poorly secured communications.
    • +
  • Injection of malicious code into development pipelines.
@@ -121,17 +68,13 @@

Level 3

Adversary
-

An organized group with significant funding and diverse expertise. Such adversaries can coordinate multi-faceted attacks and may have already compromised parts of the environment, representing coordinated internal and external threats.

+

An organized, well-funded group possessing diverse expertise across multiple domains (malware, supply chain, network exploitation, physical access, insider recruitment). Capable of sustained campaigns combining internal and external compromise.

Attacks
    -
  • Coercing or compromising internal personnel to tamper with systems.
    • +
  • Coercion or recruitment of internal personnel ("insider threats").
  • Exploiting sophisticated zero-day vulnerabilities against internet-connected components.
    • -
-
Requirements
-
    -
  • MUST require multi-key signatures stored in geographically separate locations.
    • -
  • MUST enforce independent validations at each signing location.
    • -
  • MUST maintain strict segregation of duties among different teams.
    • +
  • Persistence and lateral movement after initial breach.
    • +
  • Coordinated, multi-stage attacks across digital and physical realms.
@@ -140,51 +83,15 @@

Level 4

Adversary
-

A state actor or similarly well-resourced entity capable of executing advanced attacks—including supply chain subversion, side-channel exploitation, and insider manipulation. Techniques seen in operations by groups like the Equation Group underscore the sophistication at this level.

+

A state-backed or similarly resourced entity capable of executing the most advanced forms of cyber and physical attacks, including full-spectrum operations across the supply chain, hardware, firmware, and human factors..

Attacks
    -
  • Compromising the supply chain of any hardware or firmware component.
    • -
  • Relocating devices for rapid, covert attacks followed by restoration to the original environment.
    • -
  • Utilizing advanced side-channel attacks (e.g., Differential Fault Analysis) and non-deterministic operations.
    • -
  • Data remanence attacks that extract sensitive information even after deletion.
    • +
  • Supply chain compromise of hardware, firmware, or software prior to deployment.
    • +
  • Physical relocation of assets for tampering (e.g., interdiction of shipments).
    • +
  • Advanced side-channel attacks (e.g., Differential Fault Analysis, TEMPEST attacks).
    • +
  • Data remanence extraction techniques targeting decommissioned or wiped systems.
    • +
  • Sophisticated deception and counter-forensics to evade detection.
-
Requirements
-
    -
  • - All Signing Systems: -
      -
    • MUST have dual implementations of all policy and signing logic.
      • -
    • MUST use multiple, unrelated hardware supply chains for cryptographic material.
      • -
    • MUST produce deterministic outputs verified independently.
      • -
    • MUST store keys in facilities with high physical and environmental security (e.g., Class III vaults, per NSA TEMPEST guidelines).
      • -
    • MUST continuously monitor environmental conditions and enforce destruction protocols upon significant deviations.
      • -
    • MUST employ robust, multi-factor physical access controls.
      • -
    -
    • -
-
- - -
-
-

Mitigation Principles

-
    -
  • Elimination of Single Points of Failure: The design ensures that no single component or individual can compromise the system. Multiple layers of control span software, firmware, hardware, and operational processes.
    • -
  • Transparency and Verification: Fully open source software and firmware enable thorough security reviews.
    • -
  • Minimized Supply Chain Dependencies: Custom, purpose-specific tooling reduces reliance on external components, thereby mitigating supply chain risks.
    • -
  • Deterministic Builds: We strive for fully reproducible builds to ensure consistency and detect unauthorized modifications. Projects like StageX exemplify this approach.
    • -
  • Secure Hardware & Physical Controls: Hardware is selected for its ability to disable network access or for lacking wireless interfaces, and robust tamper-evident measures are implemented.
    • -
  • Environmental and Side-Channel Mitigations: Techniques such as TEMPEST (refer to NSA TEMPEST) and soundproofing help block unauthorized emanations and physical attacks.
    • -
-
-
- -
-
-

Summary

-

This threat model is designed to ensure the resilience and integrity of mission-critical systems by preparing for a wide range of potential attacks—from common remote threats to highly sophisticated state-level adversaries. It is especially important for organizations handling sensitive operations, managing critical infrastructure, or storing highly confidential information.

-

Importantly, the model’s four-tier structure allows organizations to select the appropriate level of defense based on their risk profile. For many, the robust controls of Level 1 or Level 2 may be sufficient, while only those facing exceptionally high risks need to implement the extensive measures of Level 3 or Level 4.

-

References: NIST SP 800-30, ISO 27005, and OWASP Threat Modeling Framework

From d848a460f88186f334413050b153872ce09d3614 Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Sat, 26 Apr 2025 13:45:37 -0700 Subject: [PATCH 3/6] feat: apply styling --- _layouts/threatmodel.html | 13 +++++++------ _sass/base.scss | 2 -- 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html index 32f3ed4..631f18c 100644 --- a/_layouts/threatmodel.html +++ b/_layouts/threatmodel.html @@ -3,22 +3,23 @@ {%- include head.html -%} {%- include header.html -%} -
+
-

Distrust Threat Model

-

Unlike conventional frameworks (e.g., STRIDE, PASTA) that focus on identifying and mitigating specific risks, the Distrust Threat Model, rather than modeling threats as potential risks, assumes that systems are already compromised. This pessimistic, assumption-driven approach focuses on building systems that can survive and remain secure even when critical components fail or are actively under attack by sophisticated threat actors at all levels.

+

Distrust Threat Model

+

Unlike conventional frameworks (e.g., STRIDE, PASTA) that focus on identifying and mitigating specific risks, the Distrust Threat Model, rather than modeling threats as potential risks, assumes that systems are already compromised. This pessimistic, assumption-driven approach focuses on building systems that can survive and remain secure even when critical components fail or are actively under attack by sophisticated threat actors at all levels.

-

Assumptions

+

Assumptions

  • All screens and displays are assumed to be observable by adversaries.
  • Input devices, such as keyboards, are assumed to be monitored or logged by potential attackers.
  • Any system components (firmware or bootloaders) not verified on every boot are considered at risk.
    • +
  • Standard consumer hardware is compromised.
  • Network-connected systems and administrative endpoints are potential compromise points.
  • Insider threats are assumed; some personnel or third-party maintainers may be compromised.
  • Physical attacks are viable and likely, given the history of supply chain and infrastructure breaches.
    • @@ -29,7 +30,7 @@
    -

    Levels

    +

    Levels

    While the end-goal is to adequately address the risks which stem from the assumptions, organizations are at varying levels of maturity and often need a path towards mitigating threats in a phased approach. To this end, the threat model defines 4 levels, each corresponding to increasingly more sophisticated threat actors as the levels increase. Each threat actor is assumed to have access to specific methods of attack limited by factors such as cost to execute, sophistication, time required etc.

    It is a reasonable approach to apply different threat model levels to different parts of systems. It's also worth noting that essentially no companies, to our knowledge meet adequate controls for Level 4 adversaries except for select nation states organizations and militaries.

    @@ -56,7 +57,7 @@

    A skilled and resourceful individual specifically targeting a single organization. This adversary employs focused efforts to breach systems, including sophisticated social engineering and exploitation of newly disclosed vulnerabilities.

    Attacks
      -
    • Focused spear-phishing campaigns against key personnel.
    • +
    • Focused spear-phishing campaigns against key personnel.
    • Rapid exploitation of vulnerabilities shortly after public disclosure ("N-day" exploitation).
    • Man-in-the-middle (MitM) attacks against poorly secured communications.
    • Injection of malicious code into development pipelines.
      • diff --git a/_sass/base.scss b/_sass/base.scss index beb0869..0974058 100644 --- a/_sass/base.scss +++ b/_sass/base.scss @@ -438,8 +438,6 @@ a:hover { margin-bottom: 50px; } - - .powered-by .card { display: flex; flex-direction: column; From 358dccf1070763dbb55d93a167913359dff4e5aa Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Thu, 1 May 2025 16:10:28 -0700 Subject: [PATCH 4/6] feat: update content --- _layouts/threatmodel.html | 66 +++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 34 deletions(-) diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html index 631f18c..e4d901b 100644 --- a/_layouts/threatmodel.html +++ b/_layouts/threatmodel.html @@ -8,23 +8,7 @@

      Distrust Threat Model

      -

      Unlike conventional frameworks (e.g., STRIDE, PASTA) that focus on identifying and mitigating specific risks, the Distrust Threat Model, rather than modeling threats as potential risks, assumes that systems are already compromised. This pessimistic, assumption-driven approach focuses on building systems that can survive and remain secure even when critical components fail or are actively under attack by sophisticated threat actors at all levels.

      -
      -
      - -
      -
      -

      Assumptions

      -
        -
      • All screens and displays are assumed to be observable by adversaries.
        • -
      • Input devices, such as keyboards, are assumed to be monitored or logged by potential attackers.
        • -
      • Any system components (firmware or bootloaders) not verified on every boot are considered at risk.
        • -
      • Standard consumer hardware is compromised.
        • -
      • Network-connected systems and administrative endpoints are potential compromise points.
        • -
      • Insider threats are assumed; some personnel or third-party maintainers may be compromised.
        • -
      • Physical attacks are viable and likely, given the history of supply chain and infrastructure breaches.
        • -
      • Side-channel attacks (similar to those observed with Spectre/Meltdown) represent realistic threats.
        • -
      +

      Unlike conventional frameworks (e.g., STRIDE, PASTA) that focus on identifying and mitigating specific risks, the Distrust Threat Model assumes that at some level systems are already compromised. This pessimistic, assumption-driven approach focuses on building systems that can remain secure even when up against the worst case adversary that have reason to target an organization.

      @@ -32,20 +16,23 @@

      Levels

      While the end-goal is to adequately address the risks which stem from the assumptions, organizations are at varying levels of maturity and often need a path towards mitigating threats in a phased approach. To this end, the threat model defines 4 levels, each corresponding to increasingly more sophisticated threat actors as the levels increase. Each threat actor is assumed to have access to specific methods of attack limited by factors such as cost to execute, sophistication, time required etc.

      -

      It is a reasonable approach to apply different threat model levels to different parts of systems. It's also worth noting that essentially no companies, to our knowledge meet adequate controls for Level 4 adversaries except for select nation states organizations and militaries.

      +

      It is a reasonable approach to apply different threat model levels to different parts of systems relative to the amount of value they protect.

    Level 1

    +

    Defense against remote adversaries with limited resources.

    Adversary
    -

    An unskilled or lightly skilled individual leveraging widely available tools and publicly known vulnerabilities. Their attacks are largely opportunistic and automated, rather than targeted.

    -
    Attacks
    +

    An unskilled or lightly skilled individual leveraging widely available tools and publicly known vulnerabilities. Their attacks are largely opportunistic and automated. We do however assume they can be very patient and willing to work across a long time horizon.

    +
    Capabilities
    • Scanning for and exploiting known vulnerabilities with public exploits.
    • Phishing attempts using off-the-shelf kits.
    • Basic malware deployment (e.g., ransomware-as-a-service).
      • +
    • Making malicious changes to open source libraries
      • +
    • Buying expired domain names
    @@ -53,14 +40,19 @@

    Level 2

    +

    Defense against insiders.

    Adversary
    -

    A skilled and resourceful individual specifically targeting a single organization. This adversary employs focused efforts to breach systems, including sophisticated social engineering and exploitation of newly disclosed vulnerabilities.

    -
    Attacks
    +

    We assume the adversary is an individual or system that already has some level of privilige or trust inside the organization. This could be anything from a disgruntled employee to a compromised work station or server.

    +
    Capabilities
      -
    • Focused spear-phishing campaigns against key personnel.
      • -
    • Rapid exploitation of vulnerabilities shortly after public disclosure ("N-day" exploitation).
      • -
    • Man-in-the-middle (MitM) attacks against poorly secured communications.
      • +
    • Can execute any code on at least one work station.
      • +
    • Can exfiltrate any secrets exposed to system memory.
      • +
    • Can use reputation to fast track change deployment.
      • +
    • Administrative privileges (email, MDM, AWS etc.)
      • +
    • Unencrypted traffic interception.
    • Injection of malicious code into development pipelines.
      • +
    • Physical access to all devices in the office.
      • +
    • Ability to impersonate unsigned actions of other empyoyees
    @@ -68,13 +60,16 @@

    Level 3

    +

    Defense against well-funded organizations.

    Adversary

    An organized, well-funded group possessing diverse expertise across multiple domains (malware, supply chain, network exploitation, physical access, insider recruitment). Capable of sustained campaigns combining internal and external compromise.

    -
    Attacks
    +
    Capabilies
      -
    • Coercion or recruitment of internal personnel ("insider threats").
      • -
    • Exploiting sophisticated zero-day vulnerabilities against internet-connected components.
      • -
    • Persistence and lateral movement after initial breach.
      • +
    • Deployment of agents willing to commit physical violence.
      • +
    • Compromised third party insiders (GitHub, AWS etc.)
      • +
    • Ability to do extensive reconnoisance on all personnell.
      • +
    • Access to large botnets or server farms.
      • +
    • Ability to purchase 0-day exploits for any internet connected device.
    • Coordinated, multi-stage attacks across digital and physical realms.
    @@ -83,15 +78,18 @@

    Level 4

    +

    Defense against nation state actors.

    Adversary

    A state-backed or similarly resourced entity capable of executing the most advanced forms of cyber and physical attacks, including full-spectrum operations across the supply chain, hardware, firmware, and human factors..

    -
    Attacks
    +
    Capabilities
      -
    • Supply chain compromise of hardware, firmware, or software prior to deployment.
      • -
    • Physical relocation of assets for tampering (e.g., interdiction of shipments).
      • -
    • Advanced side-channel attacks (e.g., Differential Fault Analysis, TEMPEST attacks).
      • -
    • Data remanence extraction techniques targeting decommissioned or wiped systems.
      • +
    • Observe all displays and input devices in public areas.
      • +
    • Ability to tamper with a major hardware/firmware supply chain.
      • +
    • Access to any network-connected system.
      • +
    • Advanced side-channel attacks (RF, power, magnetic etc.).
      • +
    • Data extraction from insufficiently wiped systems.
    • Sophisticated deception and counter-forensics to evade detection.
      • +
    • Maximal access to computational resources.
    From 79965662ca9c649e9a07cd41834cc1e084a9d095 Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Fri, 2 May 2025 11:58:12 -0700 Subject: [PATCH 5/6] fix: spelling errors --- _layouts/threatmodel.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html index e4d901b..e3659d3 100644 --- a/_layouts/threatmodel.html +++ b/_layouts/threatmodel.html @@ -42,7 +42,7 @@

    Level 2

    Defense against insiders.

    Adversary
    -

    We assume the adversary is an individual or system that already has some level of privilige or trust inside the organization. This could be anything from a disgruntled employee to a compromised work station or server.

    +

    We assume the adversary is an individual or system that already has some level of privilege or trust inside the organization. This could be anything from a disgruntled employee to a compromised work station or server.

    Capabilities
    • Can execute any code on at least one work station.
      • @@ -52,7 +52,7 @@
    • Unencrypted traffic interception.
    • Injection of malicious code into development pipelines.
    • Physical access to all devices in the office.
      • -
    • Ability to impersonate unsigned actions of other empyoyees
      • +
    • Ability to impersonate unsigned actions of other employees
@@ -63,12 +63,12 @@

Defense against well-funded organizations.

Adversary

An organized, well-funded group possessing diverse expertise across multiple domains (malware, supply chain, network exploitation, physical access, insider recruitment). Capable of sustained campaigns combining internal and external compromise.

-
Capabilies
+
Capabilities
  • Deployment of agents willing to commit physical violence.
  • Compromised third party insiders (GitHub, AWS etc.)
    • -
  • Ability to do extensive reconnoisance on all personnell.
    • -
  • Access to large botnets or server farms.
    • +
  • Ability to do extensive reconnaissance on all personnel.
    • +
  • Access to large bot-nets or server farms.
  • Ability to purchase 0-day exploits for any internet connected device.
  • Coordinated, multi-stage attacks across digital and physical realms.
From 6532b7919cc6aec718ce6ca5214866a7b8553192 Mon Sep 17 00:00:00 2001 From: Anton Livaja Date: Tue, 6 May 2025 08:39:20 -0700 Subject: [PATCH 6/6] fix: add footer --- _layouts/threatmodel.html | 1 + 1 file changed, 1 insertion(+) diff --git a/_layouts/threatmodel.html b/_layouts/threatmodel.html index e3659d3..40247e2 100644 --- a/_layouts/threatmodel.html +++ b/_layouts/threatmodel.html @@ -95,6 +95,7 @@
+ {%- include footer.html -%}