777 lines
36 KiB
HTML
777 lines
36 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<title>Chapter 1: Core Security Principles - Field Manual for Resistance Operations</title>
|
||
<meta name="description" content="The five fundamental principles that must guide all resistance security decisions">
|
||
|
||
<!-- Favicon -->
|
||
<link rel="icon" type="image/x-icon" href="/assets/images/favicon.ico">
|
||
|
||
<!-- Stylesheets -->
|
||
<link rel="stylesheet" href="/assets/css/main.css">
|
||
|
||
<!-- Security headers -->
|
||
<meta http-equiv="X-Content-Type-Options" content="nosniff">
|
||
<meta http-equiv="X-Frame-Options" content="DENY">
|
||
<meta http-equiv="X-XSS-Protection" content="1; mode=block">
|
||
|
||
<!-- No tracking -->
|
||
<meta name="robots" content="noindex, nofollow">
|
||
<!-- Matomo
|
||
<script>
|
||
var _paq = window._paq = window._paq || [];
|
||
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */
|
||
_paq.push(['trackPageView']);
|
||
_paq.push(['enableLinkTracking']);
|
||
(function() {
|
||
var u="//stats.resist.is/";
|
||
_paq.push(['setTrackerUrl', u+'matomo.php']);
|
||
_paq.push(['setSiteId', '4']);
|
||
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
|
||
g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
|
||
})();
|
||
</script>
|
||
End Matomo Code -->
|
||
</head>
|
||
<body>
|
||
<header class="header">
|
||
<div class="container">
|
||
<div class="header-content">
|
||
<div class="logo">
|
||
<span class="omega">Ω</span>
|
||
<span>FM-R1</span>
|
||
</div>
|
||
<button class="nav-toggle" id="nav-toggle" aria-label="Toggle navigation">
|
||
☰
|
||
</button>
|
||
</div>
|
||
</div>
|
||
</header>
|
||
|
||
<div class="main-layout">
|
||
<nav class="sidebar" id="sidebar">
|
||
<nav class="main-navigation">
|
||
<!-- <div class="nav-header">
|
||
<div class="nav-subtitle">Field Manual for Resistance Operations</div>
|
||
</div>
|
||
-->
|
||
<div class="nav-sections">
|
||
<!-- Front Matter -->
|
||
<div class="nav-section">
|
||
<h3>Field Manual</h3>
|
||
<ul>
|
||
<li><a href="/" >Table of Contents</a></li>
|
||
<li><a href="/preface/" >Preface</a></li>
|
||
<li><a href="/introduction/" >Introduction</a></li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- Part I: Foundations -->
|
||
<div class="nav-section">
|
||
<h3>Part I: Foundations</h3>
|
||
<ul>
|
||
<li>
|
||
<a href="/parts/part-1/" >Part Overview</a>
|
||
<ul>
|
||
<li><a href="/chapters/chapter-1/" class="active">Ch 1: Core Security Principles</a></li>
|
||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- Part II: Communication -->
|
||
<div class="nav-section">
|
||
<h3>Part II: Communication</h3>
|
||
<ul>
|
||
<li>
|
||
<a href="/parts/part-2/" >Part Overview</a>
|
||
<ul>
|
||
<li><a href="/chapters/chapter-3/" >Ch 3: Communication Architecture</a></li>
|
||
<li><a href="/chapters/chapter-4/" >Ch 4: Secure Messaging</a></li>
|
||
<li><a href="/chapters/chapter-5/" >Ch 5: File Sharing</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- Part III: OpSec -->
|
||
<div class="nav-section">
|
||
<h3>Part III: OpSec</h3>
|
||
<ul>
|
||
<li>
|
||
<a href="/parts/part-3/" >Part Overview</a>
|
||
<ul>
|
||
<li><a href="/chapters/chapter-6/" >Ch 6: Hardware Security</a></li>
|
||
<li><a href="/chapters/chapter-7/" >Ch 7: Digital Hygiene</a></li>
|
||
<li><a href="/chapters/chapter-8/" >Ch 8: Operational Procedures</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- Part IV: Advanced -->
|
||
<div class="nav-section">
|
||
<h3>Part IV: Advanced</h3>
|
||
<ul>
|
||
<li>
|
||
<a href="/parts/part-4/" >Part Overview</a>
|
||
<ul>
|
||
<li><a href="/chapters/chapter-9/" >Ch 9: Intelligence Gathering</a></li>
|
||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- Appendices
|
||
<div class="nav-section">
|
||
<h3>Appendices</h3>
|
||
<ul>
|
||
<li><a href="/appendices/" >Appendices Overview</a></li>
|
||
<li><a href="/appendices/appendix-a/" >Appendix A: Essential Tools</a></li>
|
||
<li><a href="/appendices/appendix-b/" >Appendix B: Legal Considerations</a></li>
|
||
<li><a href="/appendices/appendix-c/" >Appendix C: Emergency Procedures</a></li>
|
||
<li><a href="/appendices/appendix-d/" >Appendix D: Glossary & References</a></li>
|
||
</ul>
|
||
</div>
|
||
-->
|
||
|
||
<!-- Quick Access -->
|
||
<div class="nav-section nav-quick-access">
|
||
<h3>Quick Access</h3>
|
||
<ul>
|
||
<li><a href="/appendices/appendix-a/" class="nav-emergency">Essential Tools</a></li>
|
||
<li><a href="/appendices/appendix-b/" class="nav-emergency">Legal Rights</a></li>
|
||
<li><a href="/appendices/appendix-c/" class="nav-emergency">Emergency Procedures</a></li>
|
||
<li><a href="/appendices/appendix-d/" class="nav-emergency">Glossary & References</a></li>
|
||
</ul>
|
||
</div>
|
||
|
||
<!-- External Links -->
|
||
<div class="nav-section">
|
||
<h3>External Links</h3>
|
||
<ul>
|
||
<li><a href="https://resist.is" target="_blank">resist.is</a></li>
|
||
<li><a href="https://activistchecklist.org" target="_blank">Activist Checklist</a></li>
|
||
<li><a href="https://signal.org" target="_blank">Signal</a></li>
|
||
<li><a href="https://briarproject.org" target="_blank">Briar</a></li>
|
||
<li><a href="https://element.io" target="_blank">Element</a></li>
|
||
<li><a href="https://tails.boum.org" target="_blank">Tails OS</a></li>
|
||
<li><a href="https://onionshare.org" target="_blank">OnionShare</a></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- Security Notice
|
||
<div class="nav-security-notice">
|
||
<div class="security-warning">
|
||
<strong>OPERATIONAL SECURITY REMINDER</strong><br>
|
||
This manual contains sensitive information. Ensure secure handling and storage. Practice compartmentalization and need-to-know principles.
|
||
</div>
|
||
</div> -->
|
||
|
||
<!-- Footer -->
|
||
<div class="nav-footer">
|
||
<div class="manual-info">
|
||
<div class="classification">FOR RESISTANCE USE ONLY</div>
|
||
<div class="version">Version 1.0 | FM-R1</div>
|
||
<div class="date">2025</div>
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
|
||
</nav>
|
||
|
||
<main class="content">
|
||
<div class="content-header">
|
||
<div class="manual-designation">FM-R1: FM-R1: Secure Communication Networks for Decentralized Resistance</div>
|
||
<div class="classification">UNCLASSIFIED</div>
|
||
|
||
<div class="section-number">Section 1-1 to 1-5</div>
|
||
|
||
</div>
|
||
|
||
<h1 id="chapter-1-core-security-principles">Chapter 1: Core Security Principles</h1>
|
||
|
||
<h2 id="chapter-overview">Chapter Overview</h2>
|
||
|
||
<p>This chapter establishes the five fundamental principles that must guide all resistance security decisions. These principles, derived from decades of resistance experience and modern security research, provide the conceptual framework for evaluating threats, designing countermeasures, and making operational decisions under pressure.</p>
|
||
|
||
<p><strong>Sections in this chapter:</strong></p>
|
||
<ul>
|
||
<li>1-1: Principle of Least Privilege</li>
|
||
<li>1-2: Need-to-Know Basis</li>
|
||
<li>1-3: Compartmentalization and Cell Structure</li>
|
||
<li>1-4: Zero Trust Verification</li>
|
||
<li>1-5: Metadata Minimization</li>
|
||
</ul>
|
||
|
||
<hr />
|
||
|
||
<h2 id="section-1-1-principle-of-least-privilege">Section 1-1: Principle of Least Privilege</h2>
|
||
|
||
<h3 id="definition">Definition</h3>
|
||
|
||
<p>The Principle of Least Privilege states that every person, process, and system should have access only to the minimum resources necessary to perform their legitimate function. In resistance operations, this means limiting access to information, tools, and capabilities to the smallest set required for operational effectiveness.</p>
|
||
|
||
<h3 id="application-in-resistance-operations">Application in Resistance Operations</h3>
|
||
|
||
<h4 id="information-access">Information Access</h4>
|
||
<ul>
|
||
<li><strong>Operational details</strong> are shared only with those who need them for their specific role</li>
|
||
<li><strong>Contact information</strong> is limited to direct operational relationships</li>
|
||
<li><strong>Strategic plans</strong> are known only to leadership and those implementing specific components</li>
|
||
<li><strong>Technical details</strong> are restricted to those responsible for implementation and maintenance</li>
|
||
</ul>
|
||
|
||
<h4 id="system-access">System Access</h4>
|
||
<ul>
|
||
<li><strong>Communication platforms</strong> grant access only to relevant channels and groups</li>
|
||
<li><strong>File repositories</strong> provide access only to documents needed for specific roles</li>
|
||
<li><strong>Administrative privileges</strong> are limited to the minimum number of trusted individuals</li>
|
||
<li><strong>Backup systems</strong> are accessible only to designated recovery personnel</li>
|
||
</ul>
|
||
|
||
<h4 id="physical-access">Physical Access</h4>
|
||
<ul>
|
||
<li><strong>Meeting locations</strong> are known only to attendees and necessary support personnel</li>
|
||
<li><strong>Safe houses</strong> are accessed only by those with operational need</li>
|
||
<li><strong>Equipment storage</strong> is limited to those responsible for specific tools or supplies</li>
|
||
<li><strong>Document storage</strong> is restricted to those who create, maintain, or use specific materials</li>
|
||
</ul>
|
||
|
||
<h3 id="implementation-guidelines">Implementation Guidelines</h3>
|
||
|
||
<div class="do-dont-list">
|
||
<div class="do-list">
|
||
<h4>DO</h4>
|
||
<ul>
|
||
<li>Regularly review and audit access permissions</li>
|
||
<li>Remove access immediately when roles change</li>
|
||
<li>Document access decisions and their justifications</li>
|
||
<li>Use role-based access control when possible</li>
|
||
<li>Implement time-limited access for temporary needs</li>
|
||
</ul>
|
||
</div>
|
||
<div class="dont-list">
|
||
<h4>DON'T</h4>
|
||
<ul>
|
||
<li>Grant access "just in case" it might be needed</li>
|
||
<li>Share credentials or allow access sharing</li>
|
||
<li>Assume that trust equals need for access</li>
|
||
<li>Delay removing access when it's no longer needed</li>
|
||
<li>Grant broad access to avoid managing specific permissions</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<h3 id="common-violations-and-consequences">Common Violations and Consequences</h3>
|
||
|
||
<p><strong>Violation:</strong> Sharing operational plans with all cell members regardless of their role
|
||
<strong>Consequence:</strong> Compromise of one member leads to exposure of entire operation</p>
|
||
|
||
<p><strong>Violation:</strong> Using shared accounts for multiple purposes
|
||
<strong>Consequence:</strong> Inability to track access or revoke permissions for specific individuals</p>
|
||
|
||
<p><strong>Violation:</strong> Granting administrative access to avoid permission requests
|
||
<strong>Consequence:</strong> Accidental or malicious damage to critical systems</p>
|
||
|
||
<hr />
|
||
|
||
<h2 id="section-1-2-need-to-know-basis">Section 1-2: Need-to-Know Basis</h2>
|
||
|
||
<h3 id="definition-1">Definition</h3>
|
||
|
||
<p>Need-to-Know is an information security principle that restricts access to sensitive information to only those individuals who require it to perform their duties. Unlike Least Privilege, which focuses on access controls, Need-to-Know addresses the content and scope of information sharing.</p>
|
||
|
||
<h3 id="information-classification">Information Classification</h3>
|
||
|
||
<h4 id="operational-classifications">Operational Classifications</h4>
|
||
|
||
<p><strong>CRITICAL</strong> - Information whose compromise would cause immediate operational failure</p>
|
||
<ul>
|
||
<li>Real names and personal details of participants</li>
|
||
<li>Specific operational plans and timelines</li>
|
||
<li>Location and access details for safe houses</li>
|
||
<li>Technical vulnerabilities and exploitation methods</li>
|
||
</ul>
|
||
|
||
<p><strong>SENSITIVE</strong> - Information whose compromise would significantly impact operations</p>
|
||
<ul>
|
||
<li>Communication protocols and procedures</li>
|
||
<li>General operational capabilities and resources</li>
|
||
<li>Training materials and educational content</li>
|
||
<li>Historical operational data and lessons learned</li>
|
||
</ul>
|
||
|
||
<p><strong>RESTRICTED</strong> - Information whose compromise would cause limited damage</p>
|
||
<ul>
|
||
<li>General security guidelines and best practices</li>
|
||
<li>Public-facing materials and propaganda</li>
|
||
<li>Non-sensitive logistical information</li>
|
||
<li>Educational resources available from public sources</li>
|
||
</ul>
|
||
|
||
<p><strong>UNCLASSIFIED</strong> - Information that can be shared without operational impact</p>
|
||
<ul>
|
||
<li>Publicly available tools and software</li>
|
||
<li>General security awareness materials</li>
|
||
<li>Historical information about resistance movements</li>
|
||
<li>Legal and political analysis available from public sources</li>
|
||
</ul>
|
||
|
||
<h3 id="information-sharing-protocols">Information Sharing Protocols</h3>
|
||
|
||
<h4 id="vertical-information-flow">Vertical Information Flow</h4>
|
||
<ul>
|
||
<li><strong>Upward reporting</strong> includes only information necessary for decision-making</li>
|
||
<li><strong>Downward direction</strong> provides only information necessary for task execution</li>
|
||
<li><strong>Status updates</strong> focus on operational requirements rather than comprehensive briefings</li>
|
||
<li><strong>Emergency communications</strong> may temporarily bypass normal restrictions</li>
|
||
</ul>
|
||
|
||
<h4 id="horizontal-information-flow">Horizontal Information Flow</h4>
|
||
<ul>
|
||
<li><strong>Peer coordination</strong> shares only information necessary for joint operations</li>
|
||
<li><strong>Cross-cell communication</strong> is limited to specific operational requirements</li>
|
||
<li><strong>Resource sharing</strong> includes only information necessary for effective utilization</li>
|
||
<li><strong>Mutual support</strong> provides assistance without unnecessary information disclosure</li>
|
||
</ul>
|
||
|
||
<h3 id="implementation-in-practice">Implementation in Practice</h3>
|
||
|
||
<h4 id="meeting-protocols">Meeting Protocols</h4>
|
||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Before sharing information in any meeting:
|
||
1. Identify who needs this specific information
|
||
2. Determine the minimum detail level required
|
||
3. Consider whether the information can be compartmentalized
|
||
4. Verify that all attendees have operational need for the information
|
||
5. Document what was shared and with whom
|
||
</code></pre></div></div>
|
||
|
||
<h4 id="communication-guidelines">Communication Guidelines</h4>
|
||
<ul>
|
||
<li>Use <strong>coded language</strong> for sensitive topics even in secure channels</li>
|
||
<li><strong>Separate conversations</strong> by topic and participant need</li>
|
||
<li><strong>Time-limit</strong> access to sensitive information when possible</li>
|
||
<li><strong>Verify recipient identity</strong> before sharing sensitive information</li>
|
||
</ul>
|
||
|
||
<div class="warning-box">
|
||
<div class="warning-title">Information Discipline</div>
|
||
<p>The natural human tendency is to share information to build trust and demonstrate competence. In resistance operations, this tendency must be consciously overcome. Information discipline requires constant vigilance and may feel antisocial, but it is essential for operational security.</p>
|
||
</div>
|
||
|
||
<hr />
|
||
|
||
<h2 id="section-1-3-compartmentalization-and-cell-structure">Section 1-3: Compartmentalization and Cell Structure</h2>
|
||
|
||
<h3 id="definition-2">Definition</h3>
|
||
|
||
<p>Compartmentalization is the practice of isolating information, people, and operations into discrete units (cells) that can function independently and have limited knowledge of other units. This structure prevents the compromise of one element from cascading through the entire organization.</p>
|
||
|
||
<h3 id="cell-structure-design">Cell Structure Design</h3>
|
||
|
||
<h4 id="basic-cell-characteristics">Basic Cell Characteristics</h4>
|
||
<ul>
|
||
<li><strong>Size limitation</strong>: 3-7 members for optimal security and effectiveness</li>
|
||
<li><strong>Functional focus</strong>: Each cell has a specific operational purpose</li>
|
||
<li><strong>Limited connectivity</strong>: Minimal connections to other cells</li>
|
||
<li><strong>Independent capability</strong>: Can operate without external support for extended periods</li>
|
||
<li><strong>Redundant skills</strong>: Multiple members can perform critical functions</li>
|
||
</ul>
|
||
|
||
<h4 id="cell-types">Cell Types</h4>
|
||
|
||
<p><strong>Operational Cells</strong></p>
|
||
<ul>
|
||
<li>Execute specific resistance activities</li>
|
||
<li>Have detailed knowledge of their operations only</li>
|
||
<li>Receive direction through secure channels</li>
|
||
<li>Report results through established protocols</li>
|
||
</ul>
|
||
|
||
<p><strong>Support Cells</strong></p>
|
||
<ul>
|
||
<li>Provide specialized services (technical, logistical, financial)</li>
|
||
<li>Have broad knowledge of capabilities but limited operational details</li>
|
||
<li>Serve multiple operational cells without knowing their specific activities</li>
|
||
<li>Maintain strict separation between different support functions</li>
|
||
</ul>
|
||
|
||
<p><strong>Communication Cells</strong></p>
|
||
<ul>
|
||
<li>Facilitate secure communication between other cells</li>
|
||
<li>Know communication protocols but not operational content</li>
|
||
<li>Provide technical infrastructure and training</li>
|
||
<li>Maintain multiple redundant communication channels</li>
|
||
</ul>
|
||
|
||
<p><strong>Leadership Cells</strong></p>
|
||
<ul>
|
||
<li>Coordinate strategic direction and resource allocation</li>
|
||
<li>Have broad operational awareness but limited tactical details</li>
|
||
<li>Make decisions based on summarized reports rather than raw intelligence</li>
|
||
<li>Maintain multiple independent communication channels</li>
|
||
</ul>
|
||
|
||
<h3 id="inter-cell-communication">Inter-Cell Communication</h3>
|
||
|
||
<h4 id="communication-protocols">Communication Protocols</h4>
|
||
<ul>
|
||
<li><strong>Scheduled contacts</strong> at predetermined intervals</li>
|
||
<li><strong>Emergency procedures</strong> for urgent communication needs</li>
|
||
<li><strong>Authentication methods</strong> to verify identity and message integrity</li>
|
||
<li><strong>Fallback procedures</strong> when primary communication channels fail</li>
|
||
</ul>
|
||
|
||
<h4 id="information-flow-management">Information Flow Management</h4>
|
||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Standard Communication Flow:
|
||
Operational Cell → Support Cell → Leadership Cell
|
||
|
||
Emergency Communication Flow:
|
||
Any Cell → Emergency Contact → Leadership Cell
|
||
|
||
Cross-Cell Coordination:
|
||
Cell A → Leadership Cell → Cell B
|
||
(Direct cell-to-cell communication only for specific authorized operations)
|
||
</code></pre></div></div>
|
||
|
||
<h4 id="security-measures">Security Measures</h4>
|
||
<ul>
|
||
<li><strong>Unique communication methods</strong> for each cell relationship</li>
|
||
<li><strong>Time-delayed communication</strong> to prevent real-time tracking</li>
|
||
<li><strong>Multiple authentication factors</strong> for sensitive communications</li>
|
||
<li><strong>Regular communication schedule changes</strong> to prevent pattern analysis</li>
|
||
</ul>
|
||
|
||
<h3 id="compromise-response">Compromise Response</h3>
|
||
|
||
<h4 id="isolation-procedures">Isolation Procedures</h4>
|
||
<p>When a cell is compromised:</p>
|
||
<ol>
|
||
<li><strong>Immediate isolation</strong> - Cut all communication with compromised cell</li>
|
||
<li><strong>Damage assessment</strong> - Determine what information was exposed</li>
|
||
<li><strong>Notification protocol</strong> - Alert affected cells through secure channels</li>
|
||
<li><strong>Operational adjustment</strong> - Modify plans based on exposed information</li>
|
||
<li><strong>Recovery planning</strong> - Develop procedures for reconstituting capabilities</li>
|
||
</ol>
|
||
|
||
<h4 id="continuity-planning">Continuity Planning</h4>
|
||
<ul>
|
||
<li><strong>Redundant capabilities</strong> across multiple cells</li>
|
||
<li><strong>Succession planning</strong> for key roles and functions</li>
|
||
<li><strong>Resource distribution</strong> to prevent single points of failure</li>
|
||
<li><strong>Alternative communication channels</strong> for emergency coordination</li>
|
||
</ul>
|
||
|
||
<div class="info-box">
|
||
<div class="info-title">Cell Discipline</div>
|
||
<p>Effective compartmentalization requires strict discipline from all participants. The temptation to share information across cell boundaries for efficiency or social reasons must be resisted. Remember: the inconvenience of compartmentalization is far less than the consequences of cascade compromise.</p>
|
||
</div>
|
||
|
||
<hr />
|
||
|
||
<h2 id="section-1-4-zero-trust-verification">Section 1-4: Zero Trust Verification</h2>
|
||
|
||
<h3 id="definition-3">Definition</h3>
|
||
|
||
<p>Zero Trust is a security model that assumes no user, device, or communication can be trusted by default, even if they are inside the organization’s network or have been previously verified. Every access request must be authenticated, authorized, and continuously validated.</p>
|
||
|
||
<h3 id="core-zero-trust-principles">Core Zero Trust Principles</h3>
|
||
|
||
<h4 id="never-trust-always-verify">Never Trust, Always Verify</h4>
|
||
<ul>
|
||
<li><strong>Identity verification</strong> required for every access request</li>
|
||
<li><strong>Device authentication</strong> before allowing network access</li>
|
||
<li><strong>Continuous monitoring</strong> of user and system behavior</li>
|
||
<li><strong>Regular re-authentication</strong> for ongoing access</li>
|
||
</ul>
|
||
|
||
<h4 id="assume-breach">Assume Breach</h4>
|
||
<ul>
|
||
<li><strong>Design systems</strong> to function even when partially compromised</li>
|
||
<li><strong>Limit blast radius</strong> of any potential compromise</li>
|
||
<li><strong>Monitor for indicators</strong> of compromise continuously</li>
|
||
<li><strong>Plan response procedures</strong> for various compromise scenarios</li>
|
||
</ul>
|
||
|
||
<h4 id="verify-explicitly">Verify Explicitly</h4>
|
||
<ul>
|
||
<li><strong>Multi-factor authentication</strong> for all sensitive access</li>
|
||
<li><strong>Behavioral analysis</strong> to detect anomalous activity</li>
|
||
<li><strong>Contextual verification</strong> based on location, time, and access patterns</li>
|
||
<li><strong>Cryptographic verification</strong> of message and file integrity</li>
|
||
</ul>
|
||
|
||
<h3 id="implementation-in-resistance-operations">Implementation in Resistance Operations</h3>
|
||
|
||
<h4 id="identity-verification">Identity Verification</h4>
|
||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Standard Verification Process:
|
||
1. Something you know (password, passphrase, coded response)
|
||
2. Something you have (device, token, physical key)
|
||
3. Something you are (biometric, behavioral pattern)
|
||
4. Somewhere you are (location verification, network analysis)
|
||
5. Someone you know (trusted introducer, mutual contact)
|
||
</code></pre></div></div>
|
||
|
||
<h4 id="communication-verification">Communication Verification</h4>
|
||
<ul>
|
||
<li><strong>Message authentication codes</strong> to verify sender identity</li>
|
||
<li><strong>Forward secrecy</strong> to limit damage from key compromise</li>
|
||
<li><strong>Out-of-band verification</strong> for critical communications</li>
|
||
<li><strong>Regular key rotation</strong> to limit exposure windows</li>
|
||
</ul>
|
||
|
||
<h4 id="device-trust">Device Trust</h4>
|
||
<ul>
|
||
<li><strong>Device registration</strong> and authentication before network access</li>
|
||
<li><strong>Regular security updates</strong> and vulnerability patching</li>
|
||
<li><strong>Behavioral monitoring</strong> for signs of compromise</li>
|
||
<li><strong>Remote wipe capabilities</strong> for lost or stolen devices</li>
|
||
</ul>
|
||
|
||
<h4 id="network-segmentation">Network Segmentation</h4>
|
||
<ul>
|
||
<li><strong>Micro-segmentation</strong> to limit lateral movement</li>
|
||
<li><strong>Encrypted communications</strong> for all network traffic</li>
|
||
<li><strong>Access logging</strong> and monitoring for all network activity</li>
|
||
<li><strong>Regular network topology changes</strong> to prevent mapping</li>
|
||
</ul>
|
||
|
||
<h3 id="continuous-verification">Continuous Verification</h3>
|
||
|
||
<h4 id="behavioral-monitoring">Behavioral Monitoring</h4>
|
||
<ul>
|
||
<li><strong>Baseline establishment</strong> for normal user behavior</li>
|
||
<li><strong>Anomaly detection</strong> for unusual access patterns</li>
|
||
<li><strong>Risk scoring</strong> based on multiple behavioral factors</li>
|
||
<li><strong>Adaptive authentication</strong> based on risk assessment</li>
|
||
</ul>
|
||
|
||
<h4 id="regular-re-authentication">Regular Re-authentication</h4>
|
||
<ul>
|
||
<li><strong>Time-based re-authentication</strong> for ongoing access</li>
|
||
<li><strong>Activity-based verification</strong> for sensitive operations</li>
|
||
<li><strong>Location-based challenges</strong> for access from new locations</li>
|
||
<li><strong>Privilege escalation verification</strong> for administrative functions</li>
|
||
</ul>
|
||
|
||
<div class="warning-box">
|
||
<div class="warning-title">Paranoia vs. Security</div>
|
||
<p>Zero Trust may seem paranoid, but it reflects the reality of operating in a hostile environment where compromise is not a matter of if, but when. The goal is not to prevent all compromise, but to limit its impact and maintain operational capability even under adverse conditions.</p>
|
||
</div>
|
||
|
||
<hr />
|
||
|
||
<h2 id="section-1-5-metadata-minimization">Section 1-5: Metadata Minimization</h2>
|
||
|
||
<h3 id="definition-4">Definition</h3>
|
||
|
||
<p>Metadata is “data about data” - information that describes the characteristics of communications and activities without revealing their content. In resistance operations, metadata analysis can reveal operational patterns, network structures, and behavioral indicators even when all content is encrypted.</p>
|
||
|
||
<h3 id="types-of-metadata">Types of Metadata</h3>
|
||
|
||
<h4 id="communication-metadata">Communication Metadata</h4>
|
||
<ul>
|
||
<li><strong>Sender and recipient</strong> identities and addresses</li>
|
||
<li><strong>Timestamps</strong> of message creation, transmission, and receipt</li>
|
||
<li><strong>Message size</strong> and format information</li>
|
||
<li><strong>Routing information</strong> including intermediate servers and networks</li>
|
||
<li><strong>Device information</strong> including hardware and software details</li>
|
||
</ul>
|
||
|
||
<h4 id="location-metadata">Location Metadata</h4>
|
||
<ul>
|
||
<li><strong>GPS coordinates</strong> from mobile devices and applications</li>
|
||
<li><strong>Network location</strong> data from Wi-Fi and cellular connections</li>
|
||
<li><strong>Movement patterns</strong> derived from sequential location data</li>
|
||
<li><strong>Association patterns</strong> based on co-location with other devices</li>
|
||
</ul>
|
||
|
||
<h4 id="behavioral-metadata">Behavioral Metadata</h4>
|
||
<ul>
|
||
<li><strong>Usage patterns</strong> including timing and frequency of activities</li>
|
||
<li><strong>Application usage</strong> and feature utilization patterns</li>
|
||
<li><strong>Network traffic patterns</strong> including volume and timing</li>
|
||
<li><strong>Device interaction patterns</strong> including typing and usage behaviors</li>
|
||
</ul>
|
||
|
||
<h4 id="financial-metadata">Financial Metadata</h4>
|
||
<ul>
|
||
<li><strong>Transaction timing</strong> and frequency patterns</li>
|
||
<li><strong>Payment methods</strong> and account relationships</li>
|
||
<li><strong>Geographic patterns</strong> of financial activity</li>
|
||
<li><strong>Association patterns</strong> with other financial accounts</li>
|
||
</ul>
|
||
|
||
<h3 id="metadata-analysis-capabilities">Metadata Analysis Capabilities</h3>
|
||
|
||
<h4 id="pattern-recognition">Pattern Recognition</h4>
|
||
<p>Modern data analysis can identify:</p>
|
||
<ul>
|
||
<li><strong>Communication networks</strong> and hierarchical structures</li>
|
||
<li><strong>Operational cycles</strong> and planning timelines</li>
|
||
<li><strong>Geographic patterns</strong> and safe house locations</li>
|
||
<li><strong>Behavioral signatures</strong> unique to specific individuals</li>
|
||
</ul>
|
||
|
||
<h4 id="predictive-analysis">Predictive Analysis</h4>
|
||
<p>Metadata can be used to:</p>
|
||
<ul>
|
||
<li><strong>Predict future activities</strong> based on historical patterns</li>
|
||
<li><strong>Identify key individuals</strong> based on network centrality</li>
|
||
<li><strong>Detect operational planning</strong> through communication pattern changes</li>
|
||
<li><strong>Locate physical meetings</strong> through device co-location analysis</li>
|
||
</ul>
|
||
|
||
<h3 id="minimization-strategies">Minimization Strategies</h3>
|
||
|
||
<h4 id="communication-minimization">Communication Minimization</h4>
|
||
<div class="do-dont-list">
|
||
<div class="do-list">
|
||
<h4>DO</h4>
|
||
<ul>
|
||
<li>Use different communication methods for different purposes</li>
|
||
<li>Vary timing and frequency of communications</li>
|
||
<li>Use intermediary systems to break direct connections</li>
|
||
<li>Employ time-delayed communication when possible</li>
|
||
<li>Use broadcast methods for one-to-many communication</li>
|
||
</ul>
|
||
</div>
|
||
<div class="dont-list">
|
||
<h4>DON'T</h4>
|
||
<ul>
|
||
<li>Use the same communication channel for all purposes</li>
|
||
<li>Maintain regular communication schedules</li>
|
||
<li>Allow direct communication between all network members</li>
|
||
<li>Use personal devices for resistance communications</li>
|
||
<li>Ignore the metadata implications of communication choices</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<h4 id="location-minimization">Location Minimization</h4>
|
||
<ul>
|
||
<li><strong>Disable location services</strong> on all devices used for resistance activities</li>
|
||
<li><strong>Use public Wi-Fi</strong> from locations unconnected to your identity</li>
|
||
<li><strong>Vary locations</strong> for different types of activities</li>
|
||
<li><strong>Avoid patterns</strong> in movement and location choices</li>
|
||
<li><strong>Use transportation methods</strong> that don’t create digital records</li>
|
||
</ul>
|
||
|
||
<h4 id="temporal-minimization">Temporal Minimization</h4>
|
||
<ul>
|
||
<li><strong>Randomize timing</strong> of communications and activities</li>
|
||
<li><strong>Use time delays</strong> to break real-time correlation</li>
|
||
<li><strong>Avoid regular schedules</strong> that create predictable patterns</li>
|
||
<li><strong>Coordinate timing</strong> to create false patterns when beneficial</li>
|
||
<li><strong>Use automated systems</strong> to decouple activity timing from human schedules</li>
|
||
</ul>
|
||
|
||
<h4 id="technical-minimization">Technical Minimization</h4>
|
||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Technical Metadata Reduction:
|
||
1. Use Tor or similar anonymization networks
|
||
2. Employ VPNs with no-logging policies
|
||
3. Use disposable email addresses and accounts
|
||
4. Regularly change device identifiers when possible
|
||
5. Use different devices for different operational purposes
|
||
</code></pre></div></div>
|
||
|
||
<h3 id="metadata-aware-operational-planning">Metadata-Aware Operational Planning</h3>
|
||
|
||
<h4 id="communication-planning">Communication Planning</h4>
|
||
<ul>
|
||
<li><strong>Map metadata exposure</strong> for all planned communications</li>
|
||
<li><strong>Design communication flows</strong> to minimize revealing patterns</li>
|
||
<li><strong>Plan for metadata analysis</strong> by adversaries</li>
|
||
<li><strong>Develop cover stories</strong> for unavoidable metadata patterns</li>
|
||
</ul>
|
||
|
||
<h4 id="activity-planning">Activity Planning</h4>
|
||
<ul>
|
||
<li><strong>Consider metadata implications</strong> of all operational activities</li>
|
||
<li><strong>Design operations</strong> to create misleading metadata when possible</li>
|
||
<li><strong>Plan timing</strong> to minimize correlation opportunities</li>
|
||
<li><strong>Coordinate activities</strong> to distribute metadata across multiple participants</li>
|
||
</ul>
|
||
|
||
<div class="success-box">
|
||
<div class="success-title">Metadata Discipline</div>
|
||
<p>Effective metadata minimization requires thinking about the digital traces of every action before taking it. This becomes second nature with practice, but initially requires conscious effort and planning. The investment in metadata discipline pays dividends in operational security and longevity.</p>
|
||
</div>
|
||
|
||
<hr />
|
||
|
||
<h2 id="chapter-summary">Chapter Summary</h2>
|
||
|
||
<p>The five core security principles covered in this chapter provide the foundation for all resistance security operations:</p>
|
||
|
||
<ol>
|
||
<li><strong>Least Privilege</strong> limits access to the minimum necessary for operational effectiveness</li>
|
||
<li><strong>Need-to-Know</strong> restricts information sharing to operational requirements</li>
|
||
<li><strong>Compartmentalization</strong> isolates operations to prevent cascade compromise</li>
|
||
<li><strong>Zero Trust</strong> assumes compromise and requires continuous verification</li>
|
||
<li><strong>Metadata Minimization</strong> reduces digital traces that reveal operational patterns</li>
|
||
</ol>
|
||
|
||
<p>These principles must be applied consistently across all aspects of resistance operations, from technical tool selection to operational planning to daily security practices. They are not merely guidelines but operational requirements for survival in a hostile environment.</p>
|
||
|
||
<h3 id="integration-and-balance">Integration and Balance</h3>
|
||
|
||
<p>While each principle is important individually, their real power comes from integrated application. Effective resistance security requires balancing these principles against operational requirements and human limitations. Perfect adherence to all principles simultaneously may be impossible, but conscious application of each principle to every security decision will dramatically improve operational security.</p>
|
||
|
||
<h3 id="next-steps">Next Steps</h3>
|
||
|
||
<p>Chapter 2 builds on these foundational principles by providing systematic approaches to threat assessment and operational environment analysis. Understanding these principles is essential preparation for the practical threat modeling exercises that follow.</p>
|
||
|
||
<hr />
|
||
|
||
<p><strong>Next:</strong> <a href="/chapters/chapter-2/">Chapter 2: Threat Assessment and Operational Environment →</a></p>
|
||
|
||
|
||
|
||
|
||
<nav class="section-nav">
|
||
|
||
<a href="/parts/part-1/" class="nav-link">
|
||
<span class="arrow">←</span>
|
||
<span>Part I: Foundations</span>
|
||
</a>
|
||
|
||
|
||
|
||
<a href="/chapters/chapter-2/" class="nav-link">
|
||
<span>Chapter 2: Threat Assessment</span>
|
||
<span class="arrow">→</span>
|
||
</a>
|
||
|
||
</nav>
|
||
|
||
</main>
|
||
</div>
|
||
|
||
<footer class="footer">
|
||
<div class="container">
|
||
<div class="footer-content">
|
||
<div class="organization">Department of Internautics</div>
|
||
<div>Bureau of Decentralized Resistance</div>
|
||
<div>FM-R1 - Version 1.0 - 2025-08-28</div>
|
||
<div style="margin-top: 1rem;">
|
||
<a href="https://resist.is" target="_blank">resist.is</a> |
|
||
<a href="https://git.hacker.supply/Department_of_Internautics/field_guide" target="_blank">Source Code</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</footer>
|
||
|
||
<!-- JavaScript -->
|
||
<script src="/assets/js/main.js"></script>
|
||
</body>
|
||
</html>
|
||
|