public
/
website
5
0
Fork 0
Code Issues 8 Pull Requests 3 Packages Projects Releases Wiki Activity

add threat model draft

This commit is contained in:
Anton Livaja 2025-03-20 14:02:35 -07:00
parent 4111cd2eaf
commit dada5f5da9
Signed by: anton
GPG Key ID: 44A86CFF1FDF0E85
2 changed files with 203 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

194
_layouts/threatmodel.html Normal file
View File

@ -0,0 +1,194 @@
<!DOCTYPE html>
<html lang="{{ page.lang | default: site.lang | default: en }}">
{%- include head.html -%}
<body>
{%- include header.html -%}
<div class="container">
<main>
<!-- Executive Summary and Scope -->
<section class="flex-container">
<div class="flex-container-inner">
<h2>Distrust Threat Model</h2>
<br>
<h3>Executive Summary</h3>
<p>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 <a href="https://www.cisa.gov/solarwinds" target="_blank">SolarWinds attack</a> and tactics reminiscent of the <a href="https://en.wikipedia.org/wiki/Stuxnet" target="_blank">Stuxnet</a> incident, illustrate the threat environment we plan for.</p>
<p>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.</p>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3>Scope and Context</h3>
<p><strong>Scope:</strong> This threat model applies to systems handling sensitive operations and critical infrastructure, covering both digital and physical attack vectors.</p>
<p><strong>Assets Protected:</strong> Sensitive data, cryptographic keys, operational control systems, and key hardware/firmware components.</p>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3>General Threat Model Assumptions</h3>
<ul>
<li>All screens and displays are assumed to be observable by adversaries.</li>
<li>Input devices, such as keyboards, are assumed to be monitored or logged by potential attackers.</li>
<li>Any system components (firmware or bootloaders) not verified on every boot are considered at risk.</li>
<li>Network-connected systems and administrative endpoints are potential compromise points.</li>
<li>Insider threats are assumed; some personnel or third-party maintainers may be compromised.</li>
<li>Physical attacks are viable and likely, given the history of supply chain and infrastructure breaches.</li>
<li>Side-channel attacks (similar to those observed with Spectre/Meltdown) represent realistic threats.</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3>Threat Model Levels</h3>
<p>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.</p>
<ul>
<li><a href="#level-1">Level 1</a></li>
<li><a href="#level-2">Level 2</a></li>
<li><a href="#level-3">Level 3</a></li>
<li><a href="#level-4">Level 4</a></li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3 id="level-1">Level 1</h3>
<h5>Adversary</h5>
<p>A low-skilled individual targeting many organizations. This adversary relies on broad, unsophisticated tactics—such as phishing—to steal credentials or sensitive data.</p>
<h5>Attacks</h5>
<ul>
<li>Phishing campaigns to steal credentials or sensitive data.</li>
<li>Injecting malware into systems via remote attacks.</li>
</ul>
<h5>Requirements</h5>
<ul>
<li><strong>MUST</strong> enforce hardware-anchored authentication for critical actions.</li>
<li><strong>MUST</strong> require hardware-anchored authorization for sensitive operations.</li>
<li><strong>MUST</strong> validate operations using a threshold-based policy to prevent single-point compromises.</li>
</ul>
<h5>Reference Design</h5>
<ul>
<li>Ensure that all users performing critical operations use robust, hardware-based authentication methods (e.g., FIDO2, smart cards).</li>
<li>Implement backend systems that require cryptographic signatures from known, secure devices before approving sensitive actions.</li>
<li>Store audit logs and critical keys in tamper-evident, append-only databases.</li>
<li>Employ cryptographic challenges (e.g., hashing operation requests) that must be signed by hardware tokens.</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3 id="level-2">Level 2</h3>
<h5>Adversary</h5>
<p>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 <a href="https://en.wikipedia.org/wiki/WannaCry_ransomware_attack" target="_blank">WannaCry outbreak</a>.</p>
<h5>Attacks</h5>
<ul>
<li>Compromising a team member with privileged access.</li>
<li>Injecting malicious code into software components.</li>
<li>Exploiting vulnerabilities shortly after public disclosure.</li>
</ul>
<h5>Requirements</h5>
<ul>
<li>
<strong>Production Access:</strong>
<ul>
<li><strong>MUST NOT</strong> be possible by any single individual—use multi-factor, multi-party authorization.</li>
<li><strong>MUST</strong> be conducted via dedicated, tamper-evident workstations.</li>
<li><strong>MUST</strong> utilize hardware security modules (HSMs) for critical key management.</li>
</ul>
</li>
<li>
<strong>Software Integrity:</strong>
<ul>
<li><strong>MUST</strong> be built deterministically with reproducible builds.</li>
<li><strong>MUST</strong> undergo extensive security review and be signed by trusted keys.</li>
<li><strong>MUST</strong> be kept up-to-date with all known security patches.</li>
</ul>
</li>
</ul>
<h5>Reference Design &amp; Key Management</h5>
<ul>
<li>Create offline certificate authority (CA) keys and store them securely.</li>
<li>Use air-gapped systems to generate keys and transfer them to hardware tokens.</li>
<li>Implement immutable, attested environments (e.g., TPM-based, cloud enclaves) to manage critical keys.</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3 id="level-3">Level 3</h3>
<h5>Adversary</h5>
<p>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.</p>
<h5>Attacks</h5>
<ul>
<li>Coercing or compromising internal personnel to tamper with systems.</li>
<li>Exploiting sophisticated zero-day vulnerabilities against internet-connected components.</li>
</ul>
<h5>Requirements</h5>
<ul>
<li><strong>MUST</strong> require multi-key signatures stored in geographically separate locations.</li>
<li><strong>MUST</strong> enforce independent validations at each signing location.</li>
<li><strong>MUST</strong> maintain strict segregation of duties among different teams.</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3 id="level-4">Level 4</h3>
<h5>Adversary</h5>
<p>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 <a href="https://en.wikipedia.org/wiki/Equation_Group" target="_blank">Equation Group</a> underscore the sophistication at this level.</p>
<h5>Attacks</h5>
<ul>
<li>Compromising the supply chain of any hardware or firmware component.</li>
<li>Relocating devices for rapid, covert attacks followed by restoration to the original environment.</li>
<li>Utilizing advanced side-channel attacks (e.g., Differential Fault Analysis) and non-deterministic operations.</li>
<li>Data remanence attacks that extract sensitive information even after deletion.</li>
</ul>
<h5>Requirements</h5>
<ul>
<li>
<strong>All Signing Systems:</strong>
<ul>
<li><strong>MUST</strong> have dual implementations of all policy and signing logic.</li>
<li><strong>MUST</strong> use multiple, unrelated hardware supply chains for cryptographic material.</li>
<li><strong>MUST</strong> produce deterministic outputs verified independently.</li>
<li><strong>MUST</strong> store keys in facilities with high physical and environmental security (e.g., Class III vaults, per NSA TEMPEST guidelines).</li>
<li><strong>MUST</strong> continuously monitor environmental conditions and enforce destruction protocols upon significant deviations.</li>
<li><strong>MUST</strong> employ robust, multi-factor physical access controls.</li>
</ul>
</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3>Mitigation Principles</h3>
<ul>
<li><strong>Elimination of Single Points of Failure:</strong> The design ensures that no single component or individual can compromise the system. Multiple layers of control span software, firmware, hardware, and operational processes.</li>
<li><strong>Transparency and Verification:</strong> Fully open source software and firmware enable thorough security reviews.</li>
<li><strong>Minimized Supply Chain Dependencies:</strong> Custom, purpose-specific tooling reduces reliance on external components, thereby mitigating supply chain risks.</li>
<li><strong>Deterministic Builds:</strong> We strive for fully reproducible builds to ensure consistency and detect unauthorized modifications. Projects like <a href="https://codeberg.org/stagex/stagex" target="_blank">StageX</a> exemplify this approach.</li>
<li><strong>Secure Hardware &amp; Physical Controls:</strong> Hardware is selected for its ability to disable network access or for lacking wireless interfaces, and robust tamper-evident measures are implemented.</li>
<li><strong>Environmental and Side-Channel Mitigations:</strong> Techniques such as TEMPEST (refer to <a href="https://www.nsa.gov/" target="_blank">NSA TEMPEST</a>) and soundproofing help block unauthorized emanations and physical attacks.</li>
</ul>
</div>
</section>
<section class="flex-container">
<div class="flex-container-inner">
<h3>Summary</h3>
<p>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.</p>
<p>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.</p>
<p><em>References: NIST SP 800-30, ISO 27005, and OWASP Threat Modeling Framework</em></p>
</div>
</section>
</main>
</div>
</body>
</html>

9
threatmodel.md Normal file
View File

@ -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
---