draft of field manua
This commit is contained in:
parent
d28218de89
commit
4a6b9f922f
24
Gemfile
Normal file
24
Gemfile
Normal file
|
@ -0,0 +1,24 @@
|
|||
source "https://rubygems.org"
|
||||
|
||||
gem "jekyll", "~> 4.4"
|
||||
gem "minima", "~> 2.5"
|
||||
|
||||
group :jekyll_plugins do
|
||||
gem "jekyll-feed", "~> 0.12"
|
||||
gem "jekyll-sitemap"
|
||||
end
|
||||
|
||||
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||
# and associated library.
|
||||
platforms :mingw, :x64_mingw, :mswin, :jruby do
|
||||
gem "tzinfo", ">= 1", "< 3"
|
||||
gem "tzinfo-data"
|
||||
end
|
||||
|
||||
# Performance-booster for watching directories on Windows
|
||||
gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
|
||||
|
||||
# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
|
||||
# do not have a Java counterpart.
|
||||
gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]
|
||||
|
107
Gemfile.lock
Normal file
107
Gemfile.lock
Normal file
|
@ -0,0 +1,107 @@
|
|||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
addressable (2.8.7)
|
||||
public_suffix (>= 2.0.2, < 7.0)
|
||||
base64 (0.3.0)
|
||||
colorator (1.1.0)
|
||||
concurrent-ruby (1.3.5)
|
||||
csv (3.3.5)
|
||||
em-websocket (0.5.3)
|
||||
eventmachine (>= 0.12.9)
|
||||
http_parser.rb (~> 0)
|
||||
eventmachine (1.2.7)
|
||||
ffi (1.17.2)
|
||||
ffi (1.17.2-arm64-darwin)
|
||||
ffi (1.17.2-x86_64-darwin)
|
||||
forwardable-extended (2.6.0)
|
||||
google-protobuf (3.25.8)
|
||||
google-protobuf (3.25.8-arm64-darwin)
|
||||
google-protobuf (3.25.8-x86_64-darwin)
|
||||
google-protobuf (3.25.8-x86_64-linux)
|
||||
http_parser.rb (0.8.0)
|
||||
i18n (1.14.7)
|
||||
concurrent-ruby (~> 1.0)
|
||||
jekyll (4.4.1)
|
||||
addressable (~> 2.4)
|
||||
base64 (~> 0.2)
|
||||
colorator (~> 1.0)
|
||||
csv (~> 3.0)
|
||||
em-websocket (~> 0.5)
|
||||
i18n (~> 1.0)
|
||||
jekyll-sass-converter (>= 2.0, < 4.0)
|
||||
jekyll-watch (~> 2.0)
|
||||
json (~> 2.6)
|
||||
kramdown (~> 2.3, >= 2.3.1)
|
||||
kramdown-parser-gfm (~> 1.0)
|
||||
liquid (~> 4.0)
|
||||
mercenary (~> 0.3, >= 0.3.6)
|
||||
pathutil (~> 0.9)
|
||||
rouge (>= 3.0, < 5.0)
|
||||
safe_yaml (~> 1.0)
|
||||
terminal-table (>= 1.8, < 4.0)
|
||||
webrick (~> 1.7)
|
||||
jekyll-feed (0.17.0)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-sass-converter (3.0.0)
|
||||
sass-embedded (~> 1.54)
|
||||
jekyll-seo-tag (2.8.0)
|
||||
jekyll (>= 3.8, < 5.0)
|
||||
jekyll-sitemap (1.4.0)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-watch (2.2.1)
|
||||
listen (~> 3.0)
|
||||
json (2.13.2)
|
||||
kramdown (2.5.1)
|
||||
rexml (>= 3.3.9)
|
||||
kramdown-parser-gfm (1.1.0)
|
||||
kramdown (~> 2.0)
|
||||
liquid (4.0.4)
|
||||
listen (3.9.0)
|
||||
rb-fsevent (~> 0.10, >= 0.10.3)
|
||||
rb-inotify (~> 0.9, >= 0.9.10)
|
||||
mercenary (0.4.0)
|
||||
minima (2.5.2)
|
||||
jekyll (>= 3.5, < 5.0)
|
||||
jekyll-feed (~> 0.9)
|
||||
jekyll-seo-tag (~> 2.1)
|
||||
pathutil (0.16.2)
|
||||
forwardable-extended (~> 2.6)
|
||||
public_suffix (6.0.2)
|
||||
rake (13.3.0)
|
||||
rb-fsevent (0.11.2)
|
||||
rb-inotify (0.11.1)
|
||||
ffi (~> 1.0)
|
||||
rexml (3.4.2)
|
||||
rouge (4.6.0)
|
||||
safe_yaml (1.0.5)
|
||||
sass-embedded (1.69.5)
|
||||
google-protobuf (~> 3.23)
|
||||
rake (>= 13.0.0)
|
||||
sass-embedded (1.69.5-arm64-darwin)
|
||||
google-protobuf (~> 3.23)
|
||||
sass-embedded (1.69.5-x86_64-darwin)
|
||||
google-protobuf (~> 3.23)
|
||||
terminal-table (3.0.2)
|
||||
unicode-display_width (>= 1.1.1, < 3)
|
||||
unicode-display_width (2.6.0)
|
||||
webrick (1.9.1)
|
||||
|
||||
PLATFORMS
|
||||
arm64-darwin
|
||||
ruby
|
||||
x86_64-darwin
|
||||
x86_64-linux
|
||||
|
||||
DEPENDENCIES
|
||||
http_parser.rb (~> 0.6.0)
|
||||
jekyll (~> 4.4)
|
||||
jekyll-feed (~> 0.12)
|
||||
jekyll-sitemap
|
||||
minima (~> 2.5)
|
||||
tzinfo (>= 1, < 3)
|
||||
tzinfo-data
|
||||
wdm (~> 0.1.1)
|
||||
|
||||
BUNDLED WITH
|
||||
2.5.23
|
477
_chapters/chapter-1.md
Normal file
477
_chapters/chapter-1.md
Normal file
|
@ -0,0 +1,477 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Chapter 1: Core Security Principles"
|
||||
description: "The five fundamental principles that must guide all resistance security decisions"
|
||||
section_number: "1-1 to 1-5"
|
||||
prev_page:
|
||||
title: "Part I: Foundations"
|
||||
url: "/parts/part-1/"
|
||||
next_page:
|
||||
title: "Chapter 2: Threat Assessment"
|
||||
url: "/chapters/chapter-2/"
|
||||
---
|
||||
|
||||
# Chapter 1: Core Security Principles
|
||||
|
||||
## Chapter Overview
|
||||
|
||||
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.
|
||||
|
||||
**Sections in this chapter:**
|
||||
- 1-1: Principle of Least Privilege
|
||||
- 1-2: Need-to-Know Basis
|
||||
- 1-3: Compartmentalization and Cell Structure
|
||||
- 1-4: Zero Trust Verification
|
||||
- 1-5: Metadata Minimization
|
||||
|
||||
---
|
||||
|
||||
## Section 1-1: Principle of Least Privilege
|
||||
|
||||
### Definition
|
||||
|
||||
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.
|
||||
|
||||
### Application in Resistance Operations
|
||||
|
||||
#### Information Access
|
||||
- **Operational details** are shared only with those who need them for their specific role
|
||||
- **Contact information** is limited to direct operational relationships
|
||||
- **Strategic plans** are known only to leadership and those implementing specific components
|
||||
- **Technical details** are restricted to those responsible for implementation and maintenance
|
||||
|
||||
#### System Access
|
||||
- **Communication platforms** grant access only to relevant channels and groups
|
||||
- **File repositories** provide access only to documents needed for specific roles
|
||||
- **Administrative privileges** are limited to the minimum number of trusted individuals
|
||||
- **Backup systems** are accessible only to designated recovery personnel
|
||||
|
||||
#### Physical Access
|
||||
- **Meeting locations** are known only to attendees and necessary support personnel
|
||||
- **Safe houses** are accessed only by those with operational need
|
||||
- **Equipment storage** is limited to those responsible for specific tools or supplies
|
||||
- **Document storage** is restricted to those who create, maintain, or use specific materials
|
||||
|
||||
### Implementation Guidelines
|
||||
|
||||
<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>
|
||||
|
||||
### Common Violations and Consequences
|
||||
|
||||
**Violation:** Sharing operational plans with all cell members regardless of their role
|
||||
**Consequence:** Compromise of one member leads to exposure of entire operation
|
||||
|
||||
**Violation:** Using shared accounts for multiple purposes
|
||||
**Consequence:** Inability to track access or revoke permissions for specific individuals
|
||||
|
||||
**Violation:** Granting administrative access to avoid permission requests
|
||||
**Consequence:** Accidental or malicious damage to critical systems
|
||||
|
||||
---
|
||||
|
||||
## Section 1-2: Need-to-Know Basis
|
||||
|
||||
### Definition
|
||||
|
||||
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.
|
||||
|
||||
### Information Classification
|
||||
|
||||
#### Operational Classifications
|
||||
|
||||
**CRITICAL** - Information whose compromise would cause immediate operational failure
|
||||
- Real names and personal details of participants
|
||||
- Specific operational plans and timelines
|
||||
- Location and access details for safe houses
|
||||
- Technical vulnerabilities and exploitation methods
|
||||
|
||||
**SENSITIVE** - Information whose compromise would significantly impact operations
|
||||
- Communication protocols and procedures
|
||||
- General operational capabilities and resources
|
||||
- Training materials and educational content
|
||||
- Historical operational data and lessons learned
|
||||
|
||||
**RESTRICTED** - Information whose compromise would cause limited damage
|
||||
- General security guidelines and best practices
|
||||
- Public-facing materials and propaganda
|
||||
- Non-sensitive logistical information
|
||||
- Educational resources available from public sources
|
||||
|
||||
**UNCLASSIFIED** - Information that can be shared without operational impact
|
||||
- Publicly available tools and software
|
||||
- General security awareness materials
|
||||
- Historical information about resistance movements
|
||||
- Legal and political analysis available from public sources
|
||||
|
||||
### Information Sharing Protocols
|
||||
|
||||
#### Vertical Information Flow
|
||||
- **Upward reporting** includes only information necessary for decision-making
|
||||
- **Downward direction** provides only information necessary for task execution
|
||||
- **Status updates** focus on operational requirements rather than comprehensive briefings
|
||||
- **Emergency communications** may temporarily bypass normal restrictions
|
||||
|
||||
#### Horizontal Information Flow
|
||||
- **Peer coordination** shares only information necessary for joint operations
|
||||
- **Cross-cell communication** is limited to specific operational requirements
|
||||
- **Resource sharing** includes only information necessary for effective utilization
|
||||
- **Mutual support** provides assistance without unnecessary information disclosure
|
||||
|
||||
### Implementation in Practice
|
||||
|
||||
#### Meeting Protocols
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
#### Communication Guidelines
|
||||
- Use **coded language** for sensitive topics even in secure channels
|
||||
- **Separate conversations** by topic and participant need
|
||||
- **Time-limit** access to sensitive information when possible
|
||||
- **Verify recipient identity** before sharing sensitive information
|
||||
|
||||
<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>
|
||||
|
||||
---
|
||||
|
||||
## Section 1-3: Compartmentalization and Cell Structure
|
||||
|
||||
### Definition
|
||||
|
||||
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.
|
||||
|
||||
### Cell Structure Design
|
||||
|
||||
#### Basic Cell Characteristics
|
||||
- **Size limitation**: 3-7 members for optimal security and effectiveness
|
||||
- **Functional focus**: Each cell has a specific operational purpose
|
||||
- **Limited connectivity**: Minimal connections to other cells
|
||||
- **Independent capability**: Can operate without external support for extended periods
|
||||
- **Redundant skills**: Multiple members can perform critical functions
|
||||
|
||||
#### Cell Types
|
||||
|
||||
**Operational Cells**
|
||||
- Execute specific resistance activities
|
||||
- Have detailed knowledge of their operations only
|
||||
- Receive direction through secure channels
|
||||
- Report results through established protocols
|
||||
|
||||
**Support Cells**
|
||||
- Provide specialized services (technical, logistical, financial)
|
||||
- Have broad knowledge of capabilities but limited operational details
|
||||
- Serve multiple operational cells without knowing their specific activities
|
||||
- Maintain strict separation between different support functions
|
||||
|
||||
**Communication Cells**
|
||||
- Facilitate secure communication between other cells
|
||||
- Know communication protocols but not operational content
|
||||
- Provide technical infrastructure and training
|
||||
- Maintain multiple redundant communication channels
|
||||
|
||||
**Leadership Cells**
|
||||
- Coordinate strategic direction and resource allocation
|
||||
- Have broad operational awareness but limited tactical details
|
||||
- Make decisions based on summarized reports rather than raw intelligence
|
||||
- Maintain multiple independent communication channels
|
||||
|
||||
### Inter-Cell Communication
|
||||
|
||||
#### Communication Protocols
|
||||
- **Scheduled contacts** at predetermined intervals
|
||||
- **Emergency procedures** for urgent communication needs
|
||||
- **Authentication methods** to verify identity and message integrity
|
||||
- **Fallback procedures** when primary communication channels fail
|
||||
|
||||
#### Information Flow Management
|
||||
```
|
||||
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)
|
||||
```
|
||||
|
||||
#### Security Measures
|
||||
- **Unique communication methods** for each cell relationship
|
||||
- **Time-delayed communication** to prevent real-time tracking
|
||||
- **Multiple authentication factors** for sensitive communications
|
||||
- **Regular communication schedule changes** to prevent pattern analysis
|
||||
|
||||
### Compromise Response
|
||||
|
||||
#### Isolation Procedures
|
||||
When a cell is compromised:
|
||||
1. **Immediate isolation** - Cut all communication with compromised cell
|
||||
2. **Damage assessment** - Determine what information was exposed
|
||||
3. **Notification protocol** - Alert affected cells through secure channels
|
||||
4. **Operational adjustment** - Modify plans based on exposed information
|
||||
5. **Recovery planning** - Develop procedures for reconstituting capabilities
|
||||
|
||||
#### Continuity Planning
|
||||
- **Redundant capabilities** across multiple cells
|
||||
- **Succession planning** for key roles and functions
|
||||
- **Resource distribution** to prevent single points of failure
|
||||
- **Alternative communication channels** for emergency coordination
|
||||
|
||||
<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>
|
||||
|
||||
---
|
||||
|
||||
## Section 1-4: Zero Trust Verification
|
||||
|
||||
### Definition
|
||||
|
||||
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.
|
||||
|
||||
### Core Zero Trust Principles
|
||||
|
||||
#### Never Trust, Always Verify
|
||||
- **Identity verification** required for every access request
|
||||
- **Device authentication** before allowing network access
|
||||
- **Continuous monitoring** of user and system behavior
|
||||
- **Regular re-authentication** for ongoing access
|
||||
|
||||
#### Assume Breach
|
||||
- **Design systems** to function even when partially compromised
|
||||
- **Limit blast radius** of any potential compromise
|
||||
- **Monitor for indicators** of compromise continuously
|
||||
- **Plan response procedures** for various compromise scenarios
|
||||
|
||||
#### Verify Explicitly
|
||||
- **Multi-factor authentication** for all sensitive access
|
||||
- **Behavioral analysis** to detect anomalous activity
|
||||
- **Contextual verification** based on location, time, and access patterns
|
||||
- **Cryptographic verification** of message and file integrity
|
||||
|
||||
### Implementation in Resistance Operations
|
||||
|
||||
#### Identity Verification
|
||||
```
|
||||
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)
|
||||
```
|
||||
|
||||
#### Communication Verification
|
||||
- **Message authentication codes** to verify sender identity
|
||||
- **Forward secrecy** to limit damage from key compromise
|
||||
- **Out-of-band verification** for critical communications
|
||||
- **Regular key rotation** to limit exposure windows
|
||||
|
||||
#### Device Trust
|
||||
- **Device registration** and authentication before network access
|
||||
- **Regular security updates** and vulnerability patching
|
||||
- **Behavioral monitoring** for signs of compromise
|
||||
- **Remote wipe capabilities** for lost or stolen devices
|
||||
|
||||
#### Network Segmentation
|
||||
- **Micro-segmentation** to limit lateral movement
|
||||
- **Encrypted communications** for all network traffic
|
||||
- **Access logging** and monitoring for all network activity
|
||||
- **Regular network topology changes** to prevent mapping
|
||||
|
||||
### Continuous Verification
|
||||
|
||||
#### Behavioral Monitoring
|
||||
- **Baseline establishment** for normal user behavior
|
||||
- **Anomaly detection** for unusual access patterns
|
||||
- **Risk scoring** based on multiple behavioral factors
|
||||
- **Adaptive authentication** based on risk assessment
|
||||
|
||||
#### Regular Re-authentication
|
||||
- **Time-based re-authentication** for ongoing access
|
||||
- **Activity-based verification** for sensitive operations
|
||||
- **Location-based challenges** for access from new locations
|
||||
- **Privilege escalation verification** for administrative functions
|
||||
|
||||
<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>
|
||||
|
||||
---
|
||||
|
||||
## Section 1-5: Metadata Minimization
|
||||
|
||||
### Definition
|
||||
|
||||
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.
|
||||
|
||||
### Types of Metadata
|
||||
|
||||
#### Communication Metadata
|
||||
- **Sender and recipient** identities and addresses
|
||||
- **Timestamps** of message creation, transmission, and receipt
|
||||
- **Message size** and format information
|
||||
- **Routing information** including intermediate servers and networks
|
||||
- **Device information** including hardware and software details
|
||||
|
||||
#### Location Metadata
|
||||
- **GPS coordinates** from mobile devices and applications
|
||||
- **Network location** data from Wi-Fi and cellular connections
|
||||
- **Movement patterns** derived from sequential location data
|
||||
- **Association patterns** based on co-location with other devices
|
||||
|
||||
#### Behavioral Metadata
|
||||
- **Usage patterns** including timing and frequency of activities
|
||||
- **Application usage** and feature utilization patterns
|
||||
- **Network traffic patterns** including volume and timing
|
||||
- **Device interaction patterns** including typing and usage behaviors
|
||||
|
||||
#### Financial Metadata
|
||||
- **Transaction timing** and frequency patterns
|
||||
- **Payment methods** and account relationships
|
||||
- **Geographic patterns** of financial activity
|
||||
- **Association patterns** with other financial accounts
|
||||
|
||||
### Metadata Analysis Capabilities
|
||||
|
||||
#### Pattern Recognition
|
||||
Modern data analysis can identify:
|
||||
- **Communication networks** and hierarchical structures
|
||||
- **Operational cycles** and planning timelines
|
||||
- **Geographic patterns** and safe house locations
|
||||
- **Behavioral signatures** unique to specific individuals
|
||||
|
||||
#### Predictive Analysis
|
||||
Metadata can be used to:
|
||||
- **Predict future activities** based on historical patterns
|
||||
- **Identify key individuals** based on network centrality
|
||||
- **Detect operational planning** through communication pattern changes
|
||||
- **Locate physical meetings** through device co-location analysis
|
||||
|
||||
### Minimization Strategies
|
||||
|
||||
#### Communication Minimization
|
||||
<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>
|
||||
|
||||
#### Location Minimization
|
||||
- **Disable location services** on all devices used for resistance activities
|
||||
- **Use public Wi-Fi** from locations unconnected to your identity
|
||||
- **Vary locations** for different types of activities
|
||||
- **Avoid patterns** in movement and location choices
|
||||
- **Use transportation methods** that don't create digital records
|
||||
|
||||
#### Temporal Minimization
|
||||
- **Randomize timing** of communications and activities
|
||||
- **Use time delays** to break real-time correlation
|
||||
- **Avoid regular schedules** that create predictable patterns
|
||||
- **Coordinate timing** to create false patterns when beneficial
|
||||
- **Use automated systems** to decouple activity timing from human schedules
|
||||
|
||||
#### Technical Minimization
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
### Metadata-Aware Operational Planning
|
||||
|
||||
#### Communication Planning
|
||||
- **Map metadata exposure** for all planned communications
|
||||
- **Design communication flows** to minimize revealing patterns
|
||||
- **Plan for metadata analysis** by adversaries
|
||||
- **Develop cover stories** for unavoidable metadata patterns
|
||||
|
||||
#### Activity Planning
|
||||
- **Consider metadata implications** of all operational activities
|
||||
- **Design operations** to create misleading metadata when possible
|
||||
- **Plan timing** to minimize correlation opportunities
|
||||
- **Coordinate activities** to distribute metadata across multiple participants
|
||||
|
||||
<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>
|
||||
|
||||
---
|
||||
|
||||
## Chapter Summary
|
||||
|
||||
The five core security principles covered in this chapter provide the foundation for all resistance security operations:
|
||||
|
||||
1. **Least Privilege** limits access to the minimum necessary for operational effectiveness
|
||||
2. **Need-to-Know** restricts information sharing to operational requirements
|
||||
3. **Compartmentalization** isolates operations to prevent cascade compromise
|
||||
4. **Zero Trust** assumes compromise and requires continuous verification
|
||||
5. **Metadata Minimization** reduces digital traces that reveal operational patterns
|
||||
|
||||
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.
|
||||
|
||||
### Integration and Balance
|
||||
|
||||
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.
|
||||
|
||||
### Next Steps
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Chapter 2: Threat Assessment and Operational Environment →](/chapters/chapter-2/)
|
||||
|
698
_chapters/chapter-2.md
Normal file
698
_chapters/chapter-2.md
Normal file
|
@ -0,0 +1,698 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Chapter 2: Threat Assessment and Operational Environment"
|
||||
description: "Systematic approaches to understanding and responding to threats in resistance operations"
|
||||
section_number: "2-1 to 2-4"
|
||||
prev_page:
|
||||
title: "Chapter 1: Core Security Principles"
|
||||
url: "/chapters/chapter-1/"
|
||||
next_page:
|
||||
title: "Part II: Communication Systems"
|
||||
url: "/parts/part-2/"
|
||||
---
|
||||
|
||||
# Chapter 2: Threat Assessment and Operational Environment
|
||||
|
||||
## Chapter Overview
|
||||
|
||||
This chapter provides systematic methodologies for understanding and responding to threats in resistance operations. Effective threat assessment is the foundation of all security planning, enabling resistance practitioners to allocate resources appropriately and design countermeasures that address actual rather than imagined risks.
|
||||
|
||||
**Sections in this chapter:**
|
||||
- 2-1: Understanding Your Adversary
|
||||
- 2-2: Threat Model Development
|
||||
- 2-3: Risk Assessment Framework
|
||||
- 2-4: Operational Security (OpSec) Fundamentals
|
||||
|
||||
---
|
||||
|
||||
## Section 2-1: Understanding Your Adversary
|
||||
|
||||
### Definition
|
||||
|
||||
Adversary analysis is the systematic study of hostile forces to understand their capabilities, motivations, limitations, and likely courses of action. In resistance operations, this analysis must encompass both state and non-state actors who pose threats to operational security and participant safety.
|
||||
|
||||
### Adversary Categories
|
||||
|
||||
#### State Security Services
|
||||
**Capabilities:**
|
||||
- Mass surveillance infrastructure and legal authorities
|
||||
- Advanced technical capabilities including cyber operations
|
||||
- Extensive human intelligence networks and informant recruitment
|
||||
- Legal powers including arrest, detention, and asset seizure
|
||||
- International cooperation and intelligence sharing agreements
|
||||
|
||||
**Motivations:**
|
||||
- Maintaining regime stability and suppressing dissent
|
||||
- Protecting state secrets and critical infrastructure
|
||||
- Demonstrating effectiveness to political leadership
|
||||
- Career advancement and institutional prestige
|
||||
|
||||
**Limitations:**
|
||||
- Bureaucratic constraints and inter-agency competition
|
||||
- Resource limitations and competing priorities
|
||||
- Legal and political constraints (even in authoritarian systems)
|
||||
- Technical limitations and skill gaps
|
||||
- Public scrutiny and accountability mechanisms
|
||||
|
||||
#### Law Enforcement Agencies
|
||||
**Capabilities:**
|
||||
- Local surveillance and investigation resources
|
||||
- Access to criminal justice system and prosecution powers
|
||||
- Community informant networks and public cooperation
|
||||
- Specialized units for cybercrime and domestic terrorism
|
||||
- Coordination with federal and international agencies
|
||||
|
||||
**Motivations:**
|
||||
- Enforcing existing laws and maintaining public order
|
||||
- Responding to political pressure and public concerns
|
||||
- Protecting institutional reputation and effectiveness
|
||||
- Career advancement and performance metrics
|
||||
|
||||
**Limitations:**
|
||||
- Legal constraints and constitutional protections
|
||||
- Resource limitations and competing priorities
|
||||
- Training gaps in technical and political areas
|
||||
- Public accountability and oversight mechanisms
|
||||
- Jurisdictional limitations and coordination challenges
|
||||
|
||||
#### Private Intelligence Contractors
|
||||
**Capabilities:**
|
||||
- Specialized technical capabilities and cutting-edge tools
|
||||
- Flexibility and rapid response capabilities
|
||||
- Access to commercial data sources and partnerships
|
||||
- International operations with minimal oversight
|
||||
- Experienced personnel recruited from government agencies
|
||||
|
||||
**Motivations:**
|
||||
- Financial profit and contract renewal
|
||||
- Demonstrating value to government and corporate clients
|
||||
- Expanding market share and capabilities
|
||||
- Maintaining competitive advantage
|
||||
|
||||
**Limitations:**
|
||||
- Profit motive may conflict with thoroughness
|
||||
- Limited legal authorities and powers
|
||||
- Dependence on client relationships and contracts
|
||||
- Potential for exposure and public scrutiny
|
||||
- Competition with other contractors and agencies
|
||||
|
||||
#### Hostile Political Organizations
|
||||
**Capabilities:**
|
||||
- Grassroots networks and community presence
|
||||
- Media access and propaganda capabilities
|
||||
- Political influence and institutional connections
|
||||
- Volunteer networks and ideological motivation
|
||||
- Potential for violence and intimidation
|
||||
|
||||
**Motivations:**
|
||||
- Advancing political ideology and agenda
|
||||
- Suppressing opposition movements and activities
|
||||
- Demonstrating power and influence
|
||||
- Protecting organizational interests and reputation
|
||||
|
||||
**Limitations:**
|
||||
- Limited resources compared to state actors
|
||||
- Legal constraints and public scrutiny
|
||||
- Internal divisions and competing priorities
|
||||
- Dependence on volunteer networks and public support
|
||||
- Vulnerability to infiltration and disruption
|
||||
|
||||
### Capability Assessment Framework
|
||||
|
||||
#### Technical Capabilities
|
||||
```
|
||||
Assessment Matrix:
|
||||
1. Surveillance Infrastructure
|
||||
- Mass data collection capabilities
|
||||
- Real-time monitoring systems
|
||||
- Data analysis and correlation tools
|
||||
- International cooperation agreements
|
||||
|
||||
2. Cyber Operations
|
||||
- Offensive cyber capabilities
|
||||
- Defensive monitoring systems
|
||||
- Technical expertise and resources
|
||||
- Legal authorities and constraints
|
||||
|
||||
3. Human Intelligence
|
||||
- Informant recruitment and management
|
||||
- Infiltration capabilities
|
||||
- Social engineering expertise
|
||||
- Community presence and influence
|
||||
```
|
||||
|
||||
#### Operational Capabilities
|
||||
- **Geographic reach** and jurisdictional authority
|
||||
- **Response time** and deployment capabilities
|
||||
- **Coordination mechanisms** between different agencies
|
||||
- **Resource allocation** and priority setting processes
|
||||
- **Legal authorities** and operational constraints
|
||||
|
||||
#### Intelligence Capabilities
|
||||
- **Collection methods** and information sources
|
||||
- **Analysis capabilities** and expertise levels
|
||||
- **Dissemination networks** and information sharing
|
||||
- **Retention policies** and data management systems
|
||||
- **Quality control** and verification processes
|
||||
|
||||
### Motivation Analysis
|
||||
|
||||
#### Primary Motivations
|
||||
Understanding what drives adversary actions helps predict their behavior and identify potential vulnerabilities:
|
||||
|
||||
**Institutional Interests:**
|
||||
- Organizational survival and growth
|
||||
- Budget allocation and resource competition
|
||||
- Performance metrics and success measures
|
||||
- Reputation and public perception
|
||||
|
||||
**Individual Motivations:**
|
||||
- Career advancement and professional recognition
|
||||
- Financial incentives and job security
|
||||
- Ideological commitment and personal beliefs
|
||||
- Social pressure and peer expectations
|
||||
|
||||
**Political Factors:**
|
||||
- Electoral considerations and public opinion
|
||||
- Policy priorities and resource allocation
|
||||
- International relationships and obligations
|
||||
- Crisis response and emergency authorities
|
||||
|
||||
### Limitation Assessment
|
||||
|
||||
#### Resource Constraints
|
||||
- **Budget limitations** and competing priorities
|
||||
- **Personnel shortages** and skill gaps
|
||||
- **Technical limitations** and equipment constraints
|
||||
- **Time pressures** and operational demands
|
||||
|
||||
#### Legal and Political Constraints
|
||||
- **Constitutional protections** and legal precedents
|
||||
- **Oversight mechanisms** and accountability requirements
|
||||
- **Public scrutiny** and media attention
|
||||
- **Political considerations** and policy constraints
|
||||
|
||||
#### Operational Constraints
|
||||
- **Bureaucratic processes** and approval requirements
|
||||
- **Coordination challenges** between agencies
|
||||
- **Information sharing** limitations and restrictions
|
||||
- **Geographic limitations** and jurisdictional boundaries
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Intelligence Gathering</div>
|
||||
<p>Adversary analysis requires ongoing intelligence collection through open sources, operational observation, and network reporting. This information must be systematically collected, analyzed, and updated to maintain accuracy and relevance.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 2-2: Threat Model Development
|
||||
|
||||
### Definition
|
||||
|
||||
A threat model is a structured representation of potential threats to an organization, operation, or individual, including the assets being protected, potential attackers, attack vectors, and consequences of successful attacks. Threat modeling provides the analytical foundation for security planning and resource allocation.
|
||||
|
||||
### Threat Modeling Process
|
||||
|
||||
#### Step 1: Asset Identification
|
||||
**Information Assets:**
|
||||
- Operational plans and strategic documents
|
||||
- Communication records and contact information
|
||||
- Financial records and resource information
|
||||
- Technical documentation and system configurations
|
||||
- Personal information about participants and supporters
|
||||
|
||||
**Physical Assets:**
|
||||
- Personnel safety and freedom
|
||||
- Equipment and technology resources
|
||||
- Financial resources and funding sources
|
||||
- Safe houses and meeting locations
|
||||
- Communication infrastructure and networks
|
||||
|
||||
**Operational Assets:**
|
||||
- Network relationships and trust connections
|
||||
- Operational capabilities and expertise
|
||||
- Reputation and public support
|
||||
- Legal protections and political cover
|
||||
- Time and opportunity windows
|
||||
|
||||
#### Step 2: Threat Actor Identification
|
||||
For each asset category, identify potential threat actors:
|
||||
|
||||
```
|
||||
Threat Actor Analysis Template:
|
||||
Actor: [Name/Type]
|
||||
Motivation: [Why they would target this asset]
|
||||
Capability: [What they can do to compromise it]
|
||||
Opportunity: [When/how they could act]
|
||||
Impact: [Consequences of successful attack]
|
||||
Likelihood: [Probability assessment]
|
||||
```
|
||||
|
||||
#### Step 3: Attack Vector Analysis
|
||||
**Technical Attack Vectors:**
|
||||
- Network intrusion and system compromise
|
||||
- Communication interception and analysis
|
||||
- Device compromise and malware deployment
|
||||
- Data theft and information exfiltration
|
||||
- Service disruption and denial of service
|
||||
|
||||
**Human Attack Vectors:**
|
||||
- Social engineering and manipulation
|
||||
- Infiltration and insider threats
|
||||
- Coercion and blackmail
|
||||
- Recruitment and turning of participants
|
||||
- Information gathering through relationships
|
||||
|
||||
**Physical Attack Vectors:**
|
||||
- Surveillance and tracking
|
||||
- Search and seizure operations
|
||||
- Physical intimidation and violence
|
||||
- Asset seizure and resource disruption
|
||||
- Location compromise and raid operations
|
||||
|
||||
#### Step 4: Impact Assessment
|
||||
**Immediate Impacts:**
|
||||
- Operational disruption and mission failure
|
||||
- Personnel safety and security compromise
|
||||
- Resource loss and financial damage
|
||||
- Information disclosure and intelligence loss
|
||||
- Legal consequences and prosecution
|
||||
|
||||
**Long-term Impacts:**
|
||||
- Network compromise and relationship damage
|
||||
- Reputation loss and public support erosion
|
||||
- Capability degradation and skill loss
|
||||
- Strategic disadvantage and position weakness
|
||||
- Movement suppression and broader impact
|
||||
|
||||
### Threat Modeling Methodologies
|
||||
|
||||
#### STRIDE Framework
|
||||
**Spoofing:** Impersonating legitimate users or systems
|
||||
**Tampering:** Modifying data or systems without authorization
|
||||
**Repudiation:** Denying actions or transactions
|
||||
**Information Disclosure:** Exposing sensitive information
|
||||
**Denial of Service:** Preventing legitimate access to resources
|
||||
**Elevation of Privilege:** Gaining unauthorized access or permissions
|
||||
|
||||
#### PASTA (Process for Attack Simulation and Threat Analysis)
|
||||
1. **Define Objectives:** Establish scope and goals
|
||||
2. **Define Technical Scope:** Identify systems and components
|
||||
3. **Application Decomposition:** Break down into components
|
||||
4. **Threat Analysis:** Identify potential threats
|
||||
5. **Weakness and Vulnerability Analysis:** Find security gaps
|
||||
6. **Attack Modeling:** Simulate attack scenarios
|
||||
7. **Risk and Impact Analysis:** Assess consequences
|
||||
|
||||
#### OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)
|
||||
- **Organizational View:** Internal security practices and policies
|
||||
- **Technological View:** Technical vulnerabilities and weaknesses
|
||||
- **Strategy and Plan View:** Risk mitigation and security strategy
|
||||
|
||||
### Threat Scenario Development
|
||||
|
||||
#### Scenario Template
|
||||
```
|
||||
Threat Scenario: [Descriptive Name]
|
||||
|
||||
Background:
|
||||
- Current operational context
|
||||
- Recent events and triggers
|
||||
- Adversary capabilities and motivations
|
||||
|
||||
Attack Sequence:
|
||||
1. Initial access or opportunity
|
||||
2. Escalation and exploitation
|
||||
3. Impact and consequences
|
||||
4. Potential responses and countermeasures
|
||||
|
||||
Indicators:
|
||||
- Early warning signs
|
||||
- Detection opportunities
|
||||
- Confirmation methods
|
||||
|
||||
Mitigation:
|
||||
- Preventive measures
|
||||
- Response procedures
|
||||
- Recovery plans
|
||||
```
|
||||
|
||||
#### Example Scenarios
|
||||
|
||||
**Scenario 1: Communication Compromise**
|
||||
- Adversary intercepts encrypted communications
|
||||
- Traffic analysis reveals network structure
|
||||
- Key participants identified and targeted
|
||||
- Operational plans exposed and disrupted
|
||||
|
||||
**Scenario 2: Infiltration Operation**
|
||||
- Hostile agent joins resistance network
|
||||
- Gains trust and access over time
|
||||
- Collects intelligence on operations and participants
|
||||
- Provides information for coordinated arrests
|
||||
|
||||
**Scenario 3: Technical Surveillance**
|
||||
- Mass surveillance system deployed
|
||||
- Communication metadata collected and analyzed
|
||||
- Behavioral patterns identified and tracked
|
||||
- Predictive analysis enables preemptive action
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Scenario Planning</div>
|
||||
<p>Threat scenarios should be realistic and based on actual adversary capabilities and historical precedents. Avoid both underestimating threats (leading to inadequate security) and overestimating them (leading to paralysis and ineffective operations).</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 2-3: Risk Assessment Framework
|
||||
|
||||
### Definition
|
||||
|
||||
Risk assessment is the systematic evaluation of potential threats to determine their likelihood and impact, enabling informed decisions about security investments and operational procedures. Risk assessment translates threat models into actionable priorities for security planning.
|
||||
|
||||
### Risk Calculation Methodology
|
||||
|
||||
#### Basic Risk Formula
|
||||
```
|
||||
Risk = Threat × Vulnerability × Impact
|
||||
|
||||
Where:
|
||||
- Threat = Likelihood of attack occurring
|
||||
- Vulnerability = Probability of attack succeeding
|
||||
- Impact = Consequences of successful attack
|
||||
```
|
||||
|
||||
#### Qualitative Risk Assessment
|
||||
**Likelihood Scale:**
|
||||
- **Very High (5):** Almost certain to occur within 1 month
|
||||
- **High (4):** Likely to occur within 6 months
|
||||
- **Medium (3):** Possible within 1 year
|
||||
- **Low (2):** Unlikely within 2 years
|
||||
- **Very Low (1):** Rare or theoretical
|
||||
|
||||
**Impact Scale:**
|
||||
- **Critical (5):** Mission failure, life-threatening consequences
|
||||
- **High (4):** Major operational disruption, serious legal consequences
|
||||
- **Medium (3):** Moderate disruption, manageable consequences
|
||||
- **Low (2):** Minor inconvenience, limited impact
|
||||
- **Very Low (1):** Negligible impact
|
||||
|
||||
**Risk Matrix:**
|
||||
```
|
||||
Impact → VL L M H C
|
||||
Likelihood ↓
|
||||
Very High M H H C C
|
||||
High L M H H C
|
||||
Medium L L M H H
|
||||
Low VL L L M H
|
||||
Very Low VL VL L L M
|
||||
|
||||
Legend: VL=Very Low, L=Low, M=Medium, H=High, C=Critical
|
||||
```
|
||||
|
||||
### Risk Assessment Process
|
||||
|
||||
#### Step 1: Threat Inventory
|
||||
Create comprehensive list of identified threats from threat modeling process:
|
||||
- Categorize by threat actor and attack vector
|
||||
- Document current intelligence and evidence
|
||||
- Assess threat actor capabilities and motivations
|
||||
- Identify information gaps and uncertainties
|
||||
|
||||
#### Step 2: Vulnerability Assessment
|
||||
For each threat, assess organizational vulnerabilities:
|
||||
|
||||
**Technical Vulnerabilities:**
|
||||
- Unpatched software and system weaknesses
|
||||
- Insecure configurations and default settings
|
||||
- Weak encryption and authentication mechanisms
|
||||
- Inadequate monitoring and detection capabilities
|
||||
|
||||
**Procedural Vulnerabilities:**
|
||||
- Inadequate security policies and procedures
|
||||
- Insufficient training and awareness programs
|
||||
- Poor access control and permission management
|
||||
- Weak incident response and recovery capabilities
|
||||
|
||||
**Human Vulnerabilities:**
|
||||
- Social engineering susceptibility
|
||||
- Insider threat potential
|
||||
- Security culture weaknesses
|
||||
- Stress and pressure responses
|
||||
|
||||
#### Step 3: Impact Analysis
|
||||
Assess potential consequences of successful attacks:
|
||||
|
||||
**Operational Impact:**
|
||||
- Mission disruption and failure
|
||||
- Capability loss and degradation
|
||||
- Resource depletion and damage
|
||||
- Timeline delays and setbacks
|
||||
|
||||
**Security Impact:**
|
||||
- Personnel safety and freedom
|
||||
- Information disclosure and intelligence loss
|
||||
- Network compromise and relationship damage
|
||||
- Legal consequences and prosecution
|
||||
|
||||
**Strategic Impact:**
|
||||
- Movement effectiveness and credibility
|
||||
- Public support and political position
|
||||
- Long-term viability and sustainability
|
||||
- Broader resistance movement impact
|
||||
|
||||
#### Step 4: Risk Prioritization
|
||||
Rank risks based on calculated scores and strategic importance:
|
||||
|
||||
**Priority Categories:**
|
||||
- **Critical Risks:** Immediate attention required
|
||||
- **High Risks:** Address within 30 days
|
||||
- **Medium Risks:** Address within 90 days
|
||||
- **Low Risks:** Address as resources permit
|
||||
- **Accepted Risks:** Monitor but no immediate action
|
||||
|
||||
### Risk Treatment Strategies
|
||||
|
||||
#### Risk Mitigation
|
||||
Reduce likelihood or impact through security controls:
|
||||
- **Preventive Controls:** Block or deter attacks
|
||||
- **Detective Controls:** Identify attacks in progress
|
||||
- **Corrective Controls:** Respond to and recover from attacks
|
||||
- **Compensating Controls:** Alternative measures when primary controls fail
|
||||
|
||||
#### Risk Transfer
|
||||
Shift risk to other parties or systems:
|
||||
- **Insurance:** Financial protection against losses
|
||||
- **Outsourcing:** Transfer operational risks to service providers
|
||||
- **Partnerships:** Share risks with allied organizations
|
||||
- **Legal Protections:** Use legal mechanisms to limit exposure
|
||||
|
||||
#### Risk Acceptance
|
||||
Consciously accept certain risks:
|
||||
- **Residual Risk:** Remaining risk after mitigation measures
|
||||
- **Strategic Risk:** Risks necessary for mission accomplishment
|
||||
- **Resource Constraints:** Risks that cannot be addressed with available resources
|
||||
- **Temporary Acceptance:** Short-term acceptance pending future mitigation
|
||||
|
||||
#### Risk Avoidance
|
||||
Eliminate risk by avoiding the activity:
|
||||
- **Operational Changes:** Modify operations to eliminate risk
|
||||
- **Technology Alternatives:** Use different tools or methods
|
||||
- **Geographic Relocation:** Move operations to safer locations
|
||||
- **Timing Adjustments:** Delay operations until risks decrease
|
||||
|
||||
<div class="success-box">
|
||||
<div class="success-title">Risk Management</div>
|
||||
<p>Effective risk management is an ongoing process that requires regular review and updates. Risk assessments should be updated whenever significant changes occur in the threat environment, organizational capabilities, or operational requirements.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 2-4: Operational Security (OpSec) Fundamentals
|
||||
|
||||
### Definition
|
||||
|
||||
Operational Security (OpSec) is the process of protecting critical information and activities from adversary intelligence collection and analysis. OpSec focuses on identifying and controlling information that could be used to compromise operations, rather than just protecting classified information.
|
||||
|
||||
### OpSec Process
|
||||
|
||||
#### Step 1: Identify Critical Information
|
||||
**Critical Information Categories:**
|
||||
- **Who:** Personnel identities, roles, and relationships
|
||||
- **What:** Operational objectives, methods, and capabilities
|
||||
- **When:** Timing, schedules, and deadlines
|
||||
- **Where:** Locations, routes, and geographic areas
|
||||
- **Why:** Motivations, strategies, and decision-making processes
|
||||
- **How:** Methods, procedures, and technical details
|
||||
|
||||
**Critical Information Examples:**
|
||||
```
|
||||
Personnel Information:
|
||||
- Real names and personal details
|
||||
- Communication addresses and identifiers
|
||||
- Role assignments and responsibilities
|
||||
- Skill sets and expertise areas
|
||||
- Personal vulnerabilities and pressure points
|
||||
|
||||
Operational Information:
|
||||
- Mission objectives and success criteria
|
||||
- Operational timelines and milestones
|
||||
- Resource requirements and allocations
|
||||
- Coordination mechanisms and protocols
|
||||
- Contingency plans and alternatives
|
||||
|
||||
Technical Information:
|
||||
- Communication methods and frequencies
|
||||
- Security procedures and protocols
|
||||
- Equipment specifications and capabilities
|
||||
- Software configurations and vulnerabilities
|
||||
- Network architecture and access points
|
||||
```
|
||||
|
||||
#### Step 2: Analyze Threats
|
||||
Apply threat modeling to identify how adversaries might collect and use critical information:
|
||||
|
||||
**Collection Methods:**
|
||||
- **Technical Collection:** Electronic surveillance and monitoring
|
||||
- **Human Collection:** Informants, infiltration, and social engineering
|
||||
- **Open Source Collection:** Public information and social media
|
||||
- **Physical Collection:** Surveillance and document recovery
|
||||
|
||||
**Analysis Capabilities:**
|
||||
- **Pattern Analysis:** Identifying trends and behaviors
|
||||
- **Network Analysis:** Mapping relationships and structures
|
||||
- **Predictive Analysis:** Forecasting future activities
|
||||
- **Correlation Analysis:** Connecting disparate information sources
|
||||
|
||||
#### Step 3: Analyze Vulnerabilities
|
||||
Identify how critical information might be exposed:
|
||||
|
||||
**Information Leakage Points:**
|
||||
- **Communication Channels:** Insecure or monitored communications
|
||||
- **Behavioral Patterns:** Predictable activities and routines
|
||||
- **Physical Evidence:** Documents, equipment, and traces
|
||||
- **Social Interactions:** Casual conversations and relationships
|
||||
- **Digital Footprints:** Online activities and data trails
|
||||
|
||||
**Vulnerability Assessment Questions:**
|
||||
```
|
||||
For each piece of critical information:
|
||||
1. Who has access to this information?
|
||||
2. How is this information stored and transmitted?
|
||||
3. What activities might reveal this information?
|
||||
4. What patterns might indicate this information?
|
||||
5. How could an adversary collect this information?
|
||||
6. What would an adversary do with this information?
|
||||
```
|
||||
|
||||
#### Step 4: Assess Risk
|
||||
Evaluate the likelihood and impact of information compromise:
|
||||
|
||||
**Risk Factors:**
|
||||
- **Information Value:** How useful is this to adversaries?
|
||||
- **Collection Difficulty:** How hard is it for adversaries to obtain?
|
||||
- **Analysis Complexity:** How difficult is it to interpret and use?
|
||||
- **Operational Impact:** What happens if this is compromised?
|
||||
- **Mitigation Cost:** How expensive is it to protect?
|
||||
|
||||
#### Step 5: Apply Countermeasures
|
||||
Implement measures to protect critical information:
|
||||
|
||||
**Information Control Measures:**
|
||||
- **Classification:** Formal information protection levels
|
||||
- **Compartmentalization:** Limiting access on need-to-know basis
|
||||
- **Sanitization:** Removing sensitive details from communications
|
||||
- **Disinformation:** Providing false information to confuse adversaries
|
||||
|
||||
**Activity Control Measures:**
|
||||
- **Pattern Breaking:** Varying routines and procedures
|
||||
- **Timing Control:** Coordinating activities to minimize exposure
|
||||
- **Location Security:** Protecting meeting places and safe houses
|
||||
- **Communication Security:** Using secure channels and protocols
|
||||
|
||||
### OpSec Planning
|
||||
|
||||
#### OpSec Plan Template
|
||||
```
|
||||
1. Mission Overview
|
||||
- Objectives and scope
|
||||
- Timeline and milestones
|
||||
- Success criteria
|
||||
|
||||
2. Critical Information List
|
||||
- Information categories
|
||||
- Sensitivity levels
|
||||
- Access requirements
|
||||
|
||||
3. Threat Assessment
|
||||
- Adversary capabilities
|
||||
- Collection methods
|
||||
- Analysis capabilities
|
||||
|
||||
4. Vulnerability Analysis
|
||||
- Exposure points
|
||||
- Risk factors
|
||||
- Mitigation priorities
|
||||
|
||||
5. Countermeasure Plan
|
||||
- Protective measures
|
||||
- Implementation timeline
|
||||
- Responsibility assignments
|
||||
|
||||
6. Monitoring and Review
|
||||
- Effectiveness metrics
|
||||
- Review schedule
|
||||
- Update procedures
|
||||
```
|
||||
|
||||
#### Implementation Guidelines
|
||||
|
||||
**Training and Awareness:**
|
||||
- **OpSec Education:** Understanding principles and importance
|
||||
- **Threat Briefings:** Current adversary capabilities and methods
|
||||
- **Procedure Training:** Specific protective measures and protocols
|
||||
- **Regular Updates:** Ongoing education and reinforcement
|
||||
|
||||
**Monitoring and Enforcement:**
|
||||
- **Compliance Monitoring:** Checking adherence to OpSec procedures
|
||||
- **Incident Reporting:** Documenting OpSec failures and near-misses
|
||||
- **Corrective Action:** Addressing violations and weaknesses
|
||||
- **Continuous Improvement:** Updating procedures based on experience
|
||||
|
||||
**Integration with Operations:**
|
||||
- **Planning Integration:** OpSec considerations in all operational planning
|
||||
- **Execution Monitoring:** Real-time OpSec awareness during operations
|
||||
- **Post-Operation Review:** Analyzing OpSec effectiveness and lessons learned
|
||||
- **Feedback Loop:** Incorporating lessons into future planning
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">OpSec Discipline</div>
|
||||
<p>OpSec is only as strong as its weakest link. All participants must understand and consistently apply OpSec principles. A single careless action can compromise an entire operation and endanger all participants.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Chapter Summary
|
||||
|
||||
Chapter 2 has provided the analytical framework necessary for understanding and responding to threats in resistance operations:
|
||||
|
||||
**Section 2-1** established methodologies for analyzing adversary capabilities, motivations, and limitations across different threat actor categories.
|
||||
|
||||
**Section 2-2** introduced systematic threat modeling approaches for identifying and analyzing potential attacks against resistance operations.
|
||||
|
||||
**Section 2-3** provided risk assessment frameworks for prioritizing threats and allocating security resources effectively.
|
||||
|
||||
**Section 2-4** covered operational security fundamentals for protecting critical information and activities from adversary intelligence collection.
|
||||
|
||||
### Integration with Security Planning
|
||||
|
||||
The threat assessment and OpSec methodologies covered in this chapter provide the analytical foundation for all subsequent security planning and implementation. The communication systems, operational procedures, and advanced techniques covered in later parts of this manual should be selected and configured based on the threat assessment and risk analysis conducted using these frameworks.
|
||||
|
||||
### Continuous Process
|
||||
|
||||
Threat assessment and OpSec are not one-time activities but ongoing processes that must be regularly updated as the operational environment changes. New threats emerge, adversary capabilities evolve, and operational requirements shift, requiring continuous monitoring and adaptation of security measures.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Part II: Secure Communication Systems →](/parts/part-2/)
|
||||
|
980
_chapters/chapter-3.md
Normal file
980
_chapters/chapter-3.md
Normal file
|
@ -0,0 +1,980 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Chapter 3: Communication Layer Architecture"
|
||||
description: "Multi-layer communication strategy and protocol selection for resistance operations"
|
||||
section_number: "3-1 to 3-6"
|
||||
prev_page:
|
||||
title: "Part II: Communication Systems"
|
||||
url: "/parts/part-2/"
|
||||
next_page:
|
||||
title: "Chapter 4: Secure Messaging"
|
||||
url: "/chapters/chapter-4/"
|
||||
---
|
||||
|
||||
# Chapter 3: Communication Layer Architecture
|
||||
|
||||
## Chapter Overview
|
||||
|
||||
This chapter establishes the multi-layer communication architecture that forms the backbone of secure resistance communications. Rather than relying on a single communication method, effective resistance networks employ multiple complementary systems, each optimized for specific security requirements and operational scenarios.
|
||||
|
||||
**Sections in this chapter:**
|
||||
- 3-1: Multi-Layer Communication Strategy
|
||||
- 3-2: High-Risk Real-Time Communication (Layer 1)
|
||||
- 3-3: Secure Collaboration Systems (Layer 2)
|
||||
- 3-4: Failsafe and Offline Methods (Layer 3)
|
||||
- 3-5: Anonymous Broadcasting (Layer 4)
|
||||
- 3-6: Communication Protocol Selection
|
||||
|
||||
---
|
||||
|
||||
## Section 3-1: Multi-Layer Communication Strategy
|
||||
|
||||
### Architectural Principles
|
||||
|
||||
The multi-layer communication architecture is based on several key principles derived from both historical resistance experience and modern security research:
|
||||
|
||||
#### Defense in Depth
|
||||
No single communication system can address all security requirements and operational scenarios. Multiple layers provide redundancy and ensure that compromise of one system does not eliminate all communication capabilities.
|
||||
|
||||
#### Appropriate Security
|
||||
Different communications require different security levels. Using maximum security for all communications is both unnecessary and operationally ineffective, while using insufficient security for critical communications is dangerous.
|
||||
|
||||
#### Operational Effectiveness
|
||||
Communication systems must support actual operational requirements. Systems that are too complex, slow, or unreliable will be abandoned in favor of less secure but more usable alternatives.
|
||||
|
||||
#### Metadata Minimization
|
||||
Each layer employs different strategies for minimizing metadata exposure, from onion routing to time delays to broadcast methods that eliminate recipient identification.
|
||||
|
||||
### Layer Selection Criteria
|
||||
|
||||
#### Security Requirements
|
||||
```
|
||||
Security Level Assessment:
|
||||
1. Content Sensitivity
|
||||
- Public information (low security)
|
||||
- Internal coordination (medium security)
|
||||
- Operational details (high security)
|
||||
- Critical intelligence (maximum security)
|
||||
|
||||
2. Participant Risk
|
||||
- Public supporters (low risk)
|
||||
- Active participants (medium risk)
|
||||
- Cell leaders (high risk)
|
||||
- Key operatives (maximum risk)
|
||||
|
||||
3. Adversary Capabilities
|
||||
- Local law enforcement (basic capabilities)
|
||||
- Federal agencies (advanced capabilities)
|
||||
- Intelligence services (sophisticated capabilities)
|
||||
- Authoritarian regimes (comprehensive capabilities)
|
||||
```
|
||||
|
||||
#### Operational Requirements
|
||||
- **Timing:** Real-time vs. asynchronous communication needs
|
||||
- **Participants:** One-to-one, small group, or broadcast requirements
|
||||
- **Content:** Text, files, voice, or multimedia sharing needs
|
||||
- **Reliability:** Tolerance for delays, failures, or service interruptions
|
||||
- **Accessibility:** Technical skill requirements and device compatibility
|
||||
|
||||
#### Resource Constraints
|
||||
- **Technical Resources:** Server infrastructure and maintenance capabilities
|
||||
- **Financial Resources:** Software licensing and hosting costs
|
||||
- **Human Resources:** Technical expertise and training requirements
|
||||
- **Time Constraints:** Implementation timeline and operational deadlines
|
||||
|
||||
### Layer Architecture Overview
|
||||
|
||||
#### Layer 1: High-Risk Real-Time Communication
|
||||
**Primary Tools:** Session Messenger, Briar
|
||||
**Security Features:**
|
||||
- Onion routing for metadata protection
|
||||
- Peer-to-peer architecture with no central servers
|
||||
- Ephemeral messaging with automatic deletion
|
||||
- Offline mesh networking capabilities
|
||||
|
||||
**Use Cases:**
|
||||
- Time-sensitive operational coordination
|
||||
- Emergency communications during active operations
|
||||
- High-risk participant communications
|
||||
- Situations requiring maximum anonymity
|
||||
|
||||
#### Layer 2: Secure Collaboration Systems
|
||||
**Primary Tools:** Element/Matrix (self-hosted), CryptPad
|
||||
**Security Features:**
|
||||
- End-to-end encryption with forward secrecy
|
||||
- Self-hosted infrastructure under resistance control
|
||||
- Rich collaboration features with security
|
||||
- Persistent storage with access controls
|
||||
|
||||
**Use Cases:**
|
||||
- Ongoing operational planning and coordination
|
||||
- Document collaboration and version control
|
||||
- Group communications and decision-making
|
||||
- Resource sharing and logistical coordination
|
||||
|
||||
#### Layer 3: Failsafe and Offline Methods
|
||||
**Primary Tools:** OnionShare, encrypted email, physical methods
|
||||
**Security Features:**
|
||||
- No dependence on internet infrastructure
|
||||
- Asynchronous communication with time delays
|
||||
- Multiple redundant channels and methods
|
||||
- Resistance to network disruption and censorship
|
||||
|
||||
**Use Cases:**
|
||||
- Emergency communications when other systems fail
|
||||
- Backup channels for critical information
|
||||
- Communications in areas with limited internet access
|
||||
- Long-term information storage and retrieval
|
||||
|
||||
#### Layer 4: Anonymous Broadcasting
|
||||
**Primary Tools:** Tor hidden services, distributed platforms
|
||||
**Security Features:**
|
||||
- Strong sender anonymity protection
|
||||
- Censorship resistance and high availability
|
||||
- One-to-many communication model
|
||||
- Public accessibility without authentication
|
||||
|
||||
**Use Cases:**
|
||||
- Public communications and propaganda
|
||||
- Information distribution to supporters
|
||||
- Coordination of public actions and events
|
||||
- Counter-narrative and information warfare
|
||||
|
||||
### Implementation Strategy
|
||||
|
||||
#### Phased Deployment
|
||||
```
|
||||
Phase 1: Foundation (Weeks 1-4)
|
||||
- Implement basic secure messaging (Signal/Session)
|
||||
- Establish fundamental security procedures
|
||||
- Train core participants in basic tools
|
||||
|
||||
Phase 2: Collaboration (Weeks 5-8)
|
||||
- Deploy self-hosted Matrix server
|
||||
- Implement CryptPad for document collaboration
|
||||
- Establish group communication protocols
|
||||
|
||||
Phase 3: Advanced Security (Weeks 9-12)
|
||||
- Implement Briar for high-risk scenarios
|
||||
- Establish OnionShare for file transfers
|
||||
- Deploy emergency communication channels
|
||||
|
||||
Phase 4: Full Architecture (Weeks 13-16)
|
||||
- Integrate all layers into coherent system
|
||||
- Implement advanced security protocols
|
||||
- Establish training and support systems
|
||||
```
|
||||
|
||||
#### Integration Planning
|
||||
- **Tool Selection:** Choose specific tools for each layer based on requirements
|
||||
- **Protocol Development:** Establish procedures for using each layer appropriately
|
||||
- **Training Programs:** Ensure all participants can use required tools effectively
|
||||
- **Maintenance Planning:** Establish ongoing support and update procedures
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Layer Coordination</div>
|
||||
<p>The four layers are designed to work together, not in isolation. Effective implementation requires clear protocols for when to use each layer and how to coordinate between them while maintaining security.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 3-2: High-Risk Real-Time Communication (Layer 1)
|
||||
|
||||
### Purpose and Requirements
|
||||
|
||||
Layer 1 provides maximum security for time-sensitive communications during high-risk operations. This layer prioritizes security and anonymity over convenience and features, making it suitable for:
|
||||
|
||||
- Coordination during active operations
|
||||
- Emergency communications under surveillance
|
||||
- Communications between high-value targets
|
||||
- Situations where compromise would have immediate severe consequences
|
||||
|
||||
### Technical Architecture
|
||||
|
||||
#### Onion Routing
|
||||
Layer 1 systems use onion routing (similar to Tor) to protect communication metadata:
|
||||
|
||||
```
|
||||
Communication Path:
|
||||
User A → Entry Node → Middle Node → Exit Node → User B
|
||||
|
||||
Each hop only knows:
|
||||
- Entry Node: User A's identity, Middle Node's identity
|
||||
- Middle Node: Entry Node's identity, Exit Node's identity
|
||||
- Exit Node: Middle Node's identity, User B's identity
|
||||
|
||||
No single node knows both sender and recipient
|
||||
```
|
||||
|
||||
#### Peer-to-Peer Architecture
|
||||
- **No Central Servers:** Eliminates single points of failure and control
|
||||
- **Distributed Routing:** Messages route through multiple peer nodes
|
||||
- **Mesh Networking:** Devices can communicate directly when in proximity
|
||||
- **Offline Capability:** Store-and-forward messaging when network unavailable
|
||||
|
||||
#### Ephemeral Messaging
|
||||
- **Automatic Deletion:** Messages deleted after reading or time expiration
|
||||
- **No Persistent Storage:** No long-term message history maintained
|
||||
- **Forward Secrecy:** Compromise of current keys doesn't expose past messages
|
||||
- **Deniable Authentication:** Cannot prove who sent specific messages
|
||||
|
||||
### Primary Tools
|
||||
|
||||
#### Session Messenger
|
||||
**Strengths:**
|
||||
- Built on Signal Protocol with onion routing
|
||||
- No phone number or personal information required
|
||||
- Automatic message deletion and forward secrecy
|
||||
- Desktop and mobile applications available
|
||||
|
||||
**Configuration:**
|
||||
```
|
||||
Security Settings:
|
||||
- Enable disappearing messages (shortest duration)
|
||||
- Disable read receipts and typing indicators
|
||||
- Use random Session ID, not linked to identity
|
||||
- Enable onion routing for all communications
|
||||
- Disable message notifications and previews
|
||||
```
|
||||
|
||||
**Operational Procedures:**
|
||||
- Create new Session ID for each operation or role
|
||||
- Use only on dedicated devices not linked to identity
|
||||
- Communicate only through Tor or VPN connections
|
||||
- Delete and recreate Session ID regularly
|
||||
|
||||
#### Briar Messenger
|
||||
**Strengths:**
|
||||
- True peer-to-peer with no servers required
|
||||
- Bluetooth and WiFi direct communication capability
|
||||
- Tor integration for internet communications
|
||||
- Open source with strong security audit history
|
||||
|
||||
**Configuration:**
|
||||
```
|
||||
Network Settings:
|
||||
- Enable Tor for internet connections
|
||||
- Enable Bluetooth for local mesh networking
|
||||
- Enable WiFi for local area networking
|
||||
- Disable location services and contact access
|
||||
```
|
||||
|
||||
**Operational Procedures:**
|
||||
- Use only on dedicated devices with clean identities
|
||||
- Enable mesh networking only in secure environments
|
||||
- Regularly update contact lists and remove old contacts
|
||||
- Use time-limited contact sharing for new connections
|
||||
|
||||
### Security Protocols
|
||||
|
||||
#### Identity Management
|
||||
- **Compartmentalized Identities:** Different identities for different operations
|
||||
- **Identity Rotation:** Regular creation of new identities and retirement of old ones
|
||||
- **Identity Verification:** Out-of-band verification of contact identities
|
||||
- **Identity Separation:** No linking between different operational identities
|
||||
|
||||
#### Communication Protocols
|
||||
```
|
||||
Standard Communication Protocol:
|
||||
1. Verify recipient identity through out-of-band channel
|
||||
2. Establish secure session using verified identity
|
||||
3. Communicate using coded language even in encrypted channels
|
||||
4. Confirm message receipt through separate channel if critical
|
||||
5. Delete conversation and rotate identity if compromised
|
||||
```
|
||||
|
||||
#### Emergency Procedures
|
||||
- **Duress Codes:** Predetermined signals indicating compromise or coercion
|
||||
- **Emergency Contacts:** Backup communication methods for crisis situations
|
||||
- **Burn Procedures:** Rapid deletion of all communication evidence
|
||||
- **Fallback Channels:** Alternative communication methods when primary fails
|
||||
|
||||
### Operational Considerations
|
||||
|
||||
#### Performance Limitations
|
||||
- **Slower Message Delivery:** Onion routing introduces latency
|
||||
- **Limited Features:** Focus on security over convenience features
|
||||
- **Battery Drain:** Mesh networking and encryption consume more power
|
||||
- **Network Dependencies:** Requires sufficient peer nodes for routing
|
||||
|
||||
#### Training Requirements
|
||||
- **Technical Complexity:** Requires understanding of security concepts
|
||||
- **Operational Discipline:** Strict adherence to security protocols required
|
||||
- **Emergency Procedures:** All participants must know emergency protocols
|
||||
- **Regular Practice:** Skills must be maintained through regular use
|
||||
|
||||
#### Use Case Guidelines
|
||||
<div class="do-dont-list">
|
||||
<div class="do-list">
|
||||
<h4>DO Use Layer 1 For:</h4>
|
||||
<ul>
|
||||
<li>Time-sensitive operational coordination</li>
|
||||
<li>Communications during active surveillance</li>
|
||||
<li>High-risk participant communications</li>
|
||||
<li>Emergency situations requiring maximum security</li>
|
||||
<li>Coordination of sensitive operations</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="dont-list">
|
||||
<h4>DON'T Use Layer 1 For:</h4>
|
||||
<ul>
|
||||
<li>Routine administrative communications</li>
|
||||
<li>Large file transfers or media sharing</li>
|
||||
<li>Group discussions with many participants</li>
|
||||
<li>Long-term document storage or collaboration</li>
|
||||
<li>Public or semi-public communications</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 3-3: Secure Collaboration Systems (Layer 2)
|
||||
|
||||
### Purpose and Requirements
|
||||
|
||||
Layer 2 balances security with collaboration functionality, providing encrypted group communications, file sharing, and document collaboration while maintaining strong security protections. This layer supports:
|
||||
|
||||
- Ongoing operational planning and coordination
|
||||
- Secure document collaboration and version control
|
||||
- Group decision-making and consensus building
|
||||
- Resource sharing and logistical coordination
|
||||
|
||||
### Technical Architecture
|
||||
|
||||
#### Self-Hosted Infrastructure
|
||||
Layer 2 systems use self-hosted infrastructure to maintain control over security and data:
|
||||
|
||||
```
|
||||
Infrastructure Components:
|
||||
- Matrix Homeserver (Element/Synapse)
|
||||
- CryptPad Collaboration Server
|
||||
- File Storage Server (Nextcloud/ownCloud)
|
||||
- VPN Server for secure access
|
||||
- Backup and Recovery Systems
|
||||
```
|
||||
|
||||
#### End-to-End Encryption
|
||||
- **Message Encryption:** All messages encrypted before leaving sender device
|
||||
- **File Encryption:** Documents encrypted both in transit and at rest
|
||||
- **Key Management:** Cryptographic keys managed by participants, not servers
|
||||
- **Forward Secrecy:** Regular key rotation prevents retroactive decryption
|
||||
|
||||
#### Access Control
|
||||
- **Role-Based Access:** Different permission levels for different participants
|
||||
- **Room/Channel Security:** Separate encrypted spaces for different purposes
|
||||
- **Invitation-Only:** New participants require invitation from existing members
|
||||
- **Audit Logging:** Secure logging of access and administrative actions
|
||||
|
||||
### Primary Tools
|
||||
|
||||
#### Element/Matrix (Self-Hosted)
|
||||
**Capabilities:**
|
||||
- Encrypted group messaging and voice/video calls
|
||||
- File sharing with encryption and access controls
|
||||
- Room-based organization with different security levels
|
||||
- Federation capability for connecting multiple servers
|
||||
|
||||
**Server Setup:**
|
||||
```
|
||||
Synapse Server Configuration:
|
||||
- Deploy on dedicated server with full disk encryption
|
||||
- Configure behind VPN with restricted access
|
||||
- Enable end-to-end encryption for all rooms
|
||||
- Disable federation with public Matrix servers
|
||||
- Implement strong authentication and access controls
|
||||
```
|
||||
|
||||
**Client Configuration:**
|
||||
```
|
||||
Element Security Settings:
|
||||
- Enable cross-signing for device verification
|
||||
- Verify all room participants and their devices
|
||||
- Enable secure backup for encryption keys
|
||||
- Disable read receipts and typing notifications
|
||||
- Use strong, unique passwords with 2FA
|
||||
```
|
||||
|
||||
#### CryptPad Collaboration Platform
|
||||
**Capabilities:**
|
||||
- Real-time collaborative document editing
|
||||
- Spreadsheets, presentations, and forms
|
||||
- File storage with encryption and sharing controls
|
||||
- Anonymous usage without account requirements
|
||||
|
||||
**Server Setup:**
|
||||
```
|
||||
CryptPad Configuration:
|
||||
- Self-host on secure server infrastructure
|
||||
- Configure with strong encryption settings
|
||||
- Disable analytics and external connections
|
||||
- Implement access controls and user limits
|
||||
- Regular security updates and monitoring
|
||||
```
|
||||
|
||||
**Usage Protocols:**
|
||||
```
|
||||
Document Security Procedures:
|
||||
1. Create documents only on self-hosted instance
|
||||
2. Use strong passwords for document protection
|
||||
3. Share access links only through secure channels
|
||||
4. Regularly review and revoke document access
|
||||
5. Export and backup important documents securely
|
||||
```
|
||||
|
||||
### Security Protocols
|
||||
|
||||
#### Server Security
|
||||
- **Hardened Operating System:** Minimal installation with security updates
|
||||
- **Network Security:** Firewall configuration and intrusion detection
|
||||
- **Access Control:** Strong authentication and limited administrative access
|
||||
- **Monitoring:** Security logging and anomaly detection
|
||||
- **Backup Security:** Encrypted backups with secure key management
|
||||
|
||||
#### Operational Security
|
||||
```
|
||||
Communication Security Procedures:
|
||||
1. Verify participant identities before adding to groups
|
||||
2. Use coded language for sensitive topics
|
||||
3. Regularly rotate encryption keys and passwords
|
||||
4. Monitor for unusual activity or access patterns
|
||||
5. Implement incident response procedures for compromise
|
||||
```
|
||||
|
||||
#### Data Management
|
||||
- **Data Classification:** Different security levels for different information types
|
||||
- **Retention Policies:** Automatic deletion of old messages and files
|
||||
- **Export Controls:** Secure procedures for data export and migration
|
||||
- **Sanitization:** Secure deletion of sensitive data when no longer needed
|
||||
|
||||
### Operational Procedures
|
||||
|
||||
#### Group Management
|
||||
```
|
||||
Secure Group Creation Process:
|
||||
1. Define group purpose and security requirements
|
||||
2. Identify necessary participants and their roles
|
||||
3. Create encrypted room/channel with appropriate settings
|
||||
4. Invite participants through secure out-of-band verification
|
||||
5. Establish group communication protocols and procedures
|
||||
6. Regular review of membership and access permissions
|
||||
```
|
||||
|
||||
#### Document Collaboration
|
||||
- **Version Control:** Track document changes and maintain version history
|
||||
- **Access Management:** Control who can view, edit, and share documents
|
||||
- **Review Processes:** Establish procedures for document review and approval
|
||||
- **Security Marking:** Clear labeling of document sensitivity levels
|
||||
|
||||
#### File Sharing
|
||||
- **Secure Upload:** Encrypt files before uploading to shared storage
|
||||
- **Access Controls:** Limit file access to authorized participants only
|
||||
- **Download Security:** Verify file integrity and scan for malware
|
||||
- **Sharing Protocols:** Secure procedures for sharing files with external parties
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Server Compromise</div>
|
||||
<p>Self-hosted infrastructure requires ongoing security maintenance and monitoring. Server compromise can expose all communications and files, making proper security hardening and incident response planning essential.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 3-4: Failsafe and Offline Methods (Layer 3)
|
||||
|
||||
### Purpose and Requirements
|
||||
|
||||
Layer 3 provides backup communication channels that function independently of internet infrastructure and resist network disruption, censorship, and surveillance. This layer ensures communication capability when other systems fail and provides:
|
||||
|
||||
- Emergency communications during network outages
|
||||
- Backup channels for critical information transfer
|
||||
- Communications in areas with limited internet access
|
||||
- Long-term information storage and dead drop systems
|
||||
|
||||
### Technical Architecture
|
||||
|
||||
#### Asynchronous Communication
|
||||
Layer 3 systems use store-and-forward methods that don't require simultaneous online presence:
|
||||
|
||||
```
|
||||
Asynchronous Communication Flow:
|
||||
Sender → Intermediate Storage → Recipient
|
||||
|
||||
Benefits:
|
||||
- No real-time correlation between sender and recipient
|
||||
- Resistance to network timing analysis
|
||||
- Functionality during partial network outages
|
||||
- Time delays that complicate surveillance
|
||||
```
|
||||
|
||||
#### Multiple Transport Methods
|
||||
- **Internet-Based:** OnionShare, encrypted email, file hosting
|
||||
- **Physical Media:** USB drives, SD cards, printed materials
|
||||
- **Radio Communications:** Shortwave, amateur radio, mesh networks
|
||||
- **Human Couriers:** Trusted individuals carrying messages or media
|
||||
|
||||
#### Redundant Channels
|
||||
- **Primary Channel:** Main method for routine backup communications
|
||||
- **Secondary Channels:** Alternative methods for different scenarios
|
||||
- **Emergency Channels:** Last-resort methods for crisis situations
|
||||
- **Verification Channels:** Separate methods for confirming message receipt
|
||||
|
||||
### Primary Tools and Methods
|
||||
|
||||
#### OnionShare
|
||||
**Capabilities:**
|
||||
- Anonymous file sharing over Tor network
|
||||
- No central servers or account requirements
|
||||
- Automatic deletion after download or time expiration
|
||||
- Website hosting for anonymous information distribution
|
||||
|
||||
**Configuration:**
|
||||
```
|
||||
OnionShare Security Settings:
|
||||
- Use Tor Browser for all access
|
||||
- Enable automatic shutdown after download
|
||||
- Set short expiration times for shared files
|
||||
- Use strong passwords for protected shares
|
||||
- Access only from secure, anonymous devices
|
||||
```
|
||||
|
||||
**Operational Procedures:**
|
||||
```
|
||||
Secure File Transfer Process:
|
||||
1. Create encrypted archive of files to share
|
||||
2. Generate OnionShare link with password protection
|
||||
3. Share link and password through separate secure channels
|
||||
4. Monitor for successful download and automatic shutdown
|
||||
5. Verify receipt through separate communication channel
|
||||
```
|
||||
|
||||
#### Encrypted Email Systems
|
||||
**Recommended Services:**
|
||||
- ProtonMail with Tor access
|
||||
- Tutanota with anonymous signup
|
||||
- Self-hosted email with PGP encryption
|
||||
- Temporary email services for one-time use
|
||||
|
||||
**Security Configuration:**
|
||||
```
|
||||
Email Security Setup:
|
||||
- Create accounts using Tor and anonymous information
|
||||
- Use strong, unique passwords with 2FA when available
|
||||
- Enable PGP encryption for all sensitive communications
|
||||
- Configure automatic message deletion
|
||||
- Access only through Tor or secure VPN
|
||||
```
|
||||
|
||||
#### Physical Dead Drops
|
||||
**Digital Dead Drops:**
|
||||
- Hidden USB drives in public locations
|
||||
- QR codes with encrypted data in public spaces
|
||||
- Steganography in publicly posted images
|
||||
- Data hidden in public file sharing services
|
||||
|
||||
**Physical Dead Drops:**
|
||||
- Traditional spy craft methods adapted for resistance
|
||||
- Predetermined locations for leaving messages or materials
|
||||
- Signal systems for indicating message availability
|
||||
- Security protocols for dead drop servicing
|
||||
|
||||
### Security Protocols
|
||||
|
||||
#### Time Delay Security
|
||||
```
|
||||
Operational Time Delays:
|
||||
- Minimum 24-hour delay between message creation and pickup
|
||||
- Random additional delays to prevent pattern analysis
|
||||
- Staggered access times to avoid correlation
|
||||
- Multiple intermediate steps to break timing chains
|
||||
```
|
||||
|
||||
#### Channel Separation
|
||||
- **Different Channels for Different Purposes:** No single channel used for multiple types of communication
|
||||
- **Identity Separation:** Different identities and accounts for each channel
|
||||
- **Geographic Separation:** Different physical locations for different channels
|
||||
- **Temporal Separation:** Different time periods for different channel usage
|
||||
|
||||
#### Verification Procedures
|
||||
```
|
||||
Message Verification Process:
|
||||
1. Cryptographic signatures to verify sender authenticity
|
||||
2. Predetermined code words or phrases for verification
|
||||
3. Separate channel confirmation of message receipt
|
||||
4. Cross-reference with other intelligence sources
|
||||
5. Verification of message integrity and completeness
|
||||
```
|
||||
|
||||
### Operational Procedures
|
||||
|
||||
#### Emergency Communication Protocols
|
||||
```
|
||||
Emergency Communication Sequence:
|
||||
1. Attempt primary communication channels (Layers 1-2)
|
||||
2. If primary channels fail, activate Layer 3 protocols
|
||||
3. Use predetermined emergency contact methods
|
||||
4. Implement duress codes if under coercion
|
||||
5. Activate backup communication networks
|
||||
6. Establish new primary channels when possible
|
||||
```
|
||||
|
||||
#### Dead Drop Management
|
||||
- **Location Security:** Choose locations that are publicly accessible but not under surveillance
|
||||
- **Servicing Protocols:** Establish regular schedules for checking and maintaining dead drops
|
||||
- **Signal Systems:** Use predetermined signals to indicate message availability or compromise
|
||||
- **Backup Locations:** Maintain multiple dead drop locations for redundancy
|
||||
|
||||
#### Long-Term Storage
|
||||
- **Encrypted Archives:** Create encrypted backups of critical information
|
||||
- **Distributed Storage:** Store copies in multiple secure locations
|
||||
- **Access Procedures:** Establish protocols for accessing stored information
|
||||
- **Update Procedures:** Regular updates and verification of stored information
|
||||
|
||||
<div class="success-box">
|
||||
<div class="success-title">Resilience Planning</div>
|
||||
<p>Layer 3 methods require advance planning and preparation. Emergency communication channels must be established and tested before they are needed, as crisis situations provide no time for setup and configuration.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 3-5: Anonymous Broadcasting (Layer 4)
|
||||
|
||||
### Purpose and Requirements
|
||||
|
||||
Layer 4 provides one-to-many communication capabilities with strong sender anonymity and censorship resistance. This layer supports public-facing communications while protecting the identity and location of the sender:
|
||||
|
||||
- Public communications and propaganda distribution
|
||||
- Information sharing with supporters and sympathizers
|
||||
- Coordination of public actions and demonstrations
|
||||
- Counter-narrative and information warfare operations
|
||||
|
||||
### Technical Architecture
|
||||
|
||||
#### Anonymity Networks
|
||||
Layer 4 systems use anonymity networks to protect sender identity:
|
||||
|
||||
```
|
||||
Tor Hidden Services Architecture:
|
||||
Publisher → Tor Network → Hidden Service → Public Access
|
||||
|
||||
Anonymity Features:
|
||||
- Publisher identity hidden from readers
|
||||
- Publisher location hidden from network operators
|
||||
- Content hosted on distributed network
|
||||
- Censorship resistance through multiple access points
|
||||
```
|
||||
|
||||
#### Content Distribution Networks
|
||||
- **Distributed Hosting:** Content replicated across multiple servers and networks
|
||||
- **Mirror Sites:** Multiple copies of content on different platforms
|
||||
- **Peer-to-Peer Distribution:** Content shared through BitTorrent and similar networks
|
||||
- **Social Media Integration:** Automated posting to multiple social media platforms
|
||||
|
||||
#### Censorship Resistance
|
||||
- **Domain Fronting:** Hide destination of web traffic behind legitimate services
|
||||
- **Decentralized Platforms:** Use blockchain and peer-to-peer publishing platforms
|
||||
- **Multiple Access Methods:** Provide various ways to access the same content
|
||||
- **Rapid Migration:** Ability to quickly move content to new platforms
|
||||
|
||||
### Primary Tools and Platforms
|
||||
|
||||
#### Tor Hidden Services
|
||||
**Capabilities:**
|
||||
- Anonymous website hosting with .onion addresses
|
||||
- Protection against traffic analysis and censorship
|
||||
- No central authority or registration required
|
||||
- Integration with standard web technologies
|
||||
|
||||
**Setup Procedures:**
|
||||
```
|
||||
Hidden Service Configuration:
|
||||
1. Install and configure Tor on secure server
|
||||
2. Generate .onion address and private keys
|
||||
3. Configure web server to serve content locally
|
||||
4. Test access through Tor Browser
|
||||
5. Implement security hardening and monitoring
|
||||
```
|
||||
|
||||
#### Distributed Publishing Platforms
|
||||
**IPFS (InterPlanetary File System):**
|
||||
- Decentralized file storage and distribution
|
||||
- Content-addressed storage with cryptographic verification
|
||||
- Peer-to-peer distribution without central servers
|
||||
- Integration with blockchain naming systems
|
||||
|
||||
**Blockchain Platforms:**
|
||||
- Ethereum-based publishing platforms
|
||||
- Bitcoin blockchain data storage
|
||||
- Decentralized autonomous organization (DAO) governance
|
||||
- Cryptocurrency-based incentive systems
|
||||
|
||||
#### Social Media Automation
|
||||
**Multi-Platform Publishing:**
|
||||
- Automated posting to Twitter, Facebook, Telegram, etc.
|
||||
- Content adaptation for different platform requirements
|
||||
- Scheduled publishing and content calendars
|
||||
- Analytics and engagement monitoring
|
||||
|
||||
**Account Management:**
|
||||
```
|
||||
Anonymous Account Creation:
|
||||
1. Use Tor Browser for all account creation
|
||||
2. Use temporary email addresses for registration
|
||||
3. Provide minimal or false personal information
|
||||
4. Use VPN or proxy for additional protection
|
||||
5. Maintain separate identities for different purposes
|
||||
```
|
||||
|
||||
### Security Protocols
|
||||
|
||||
#### Publisher Anonymity
|
||||
- **Identity Separation:** Complete separation between publisher identity and real identity
|
||||
- **Location Security:** Publish only from secure, anonymous locations
|
||||
- **Device Security:** Use dedicated devices not linked to real identity
|
||||
- **Network Security:** Always use Tor or VPN for all publishing activities
|
||||
|
||||
#### Content Security
|
||||
```
|
||||
Content Publication Security:
|
||||
1. Remove metadata from all files before publication
|
||||
2. Use generic writing style to avoid stylometric analysis
|
||||
3. Avoid revealing specific knowledge or experiences
|
||||
4. Use stock images or create original graphics
|
||||
5. Review content for operational security implications
|
||||
```
|
||||
|
||||
#### Platform Security
|
||||
- **Account Security:** Strong passwords, 2FA, and secure recovery methods
|
||||
- **Platform Diversity:** Use multiple platforms to avoid single points of failure
|
||||
- **Backup Systems:** Maintain copies of all content and account information
|
||||
- **Migration Planning:** Prepare for rapid migration if platforms are compromised
|
||||
|
||||
### Operational Procedures
|
||||
|
||||
#### Content Planning
|
||||
```
|
||||
Publication Planning Process:
|
||||
1. Define target audience and communication objectives
|
||||
2. Develop content calendar and publication schedule
|
||||
3. Create content following security and anonymity guidelines
|
||||
4. Review content for operational security implications
|
||||
5. Coordinate publication across multiple platforms
|
||||
6. Monitor engagement and adjust strategy as needed
|
||||
```
|
||||
|
||||
#### Crisis Communication
|
||||
- **Rapid Response:** Ability to quickly publish time-sensitive information
|
||||
- **Emergency Protocols:** Predetermined procedures for crisis communications
|
||||
- **Backup Channels:** Alternative publication methods if primary channels fail
|
||||
- **Coordination:** Integration with other resistance communication efforts
|
||||
|
||||
#### Audience Engagement
|
||||
- **Feedback Channels:** Secure methods for receiving audience feedback
|
||||
- **Community Building:** Foster engagement while maintaining security
|
||||
- **Information Verification:** Procedures for verifying and fact-checking information
|
||||
- **Counter-Narrative:** Respond to hostile propaganda and disinformation
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Attribution Risk</div>
|
||||
<p>Even with strong technical anonymity, writing style, content knowledge, and publication patterns can potentially identify authors. Careful attention to operational security is essential for maintaining publisher anonymity.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Section 3-6: Communication Protocol Selection
|
||||
|
||||
### Decision Framework
|
||||
|
||||
Selecting appropriate communication protocols requires systematic evaluation of security requirements, operational needs, and available resources. This section provides frameworks for making these decisions systematically rather than ad hoc.
|
||||
|
||||
### Security Requirements Assessment
|
||||
|
||||
#### Threat Level Analysis
|
||||
```
|
||||
Threat Level Matrix:
|
||||
Low Medium High Critical
|
||||
Content Risk L1-4 L1-3 L1-2 L1 Only
|
||||
Participant L2-4 L1-3 L1-2 L1 Only
|
||||
Timing Risk L2-4 L1-3 L1-2 L1 Only
|
||||
Network Risk L3-4 L2-4 L1-3 L1-2
|
||||
|
||||
Legend: L1=Layer 1, L2=Layer 2, etc.
|
||||
```
|
||||
|
||||
#### Risk Factor Evaluation
|
||||
**Content Sensitivity:**
|
||||
- **Public Information:** Can be disclosed without operational impact
|
||||
- **Internal Coordination:** Useful to adversaries but not immediately damaging
|
||||
- **Operational Details:** Could compromise specific operations if disclosed
|
||||
- **Critical Intelligence:** Would cause immediate severe damage if compromised
|
||||
|
||||
**Participant Risk Level:**
|
||||
- **Public Supporters:** Known association with resistance but not operational roles
|
||||
- **Active Participants:** Involved in resistance activities but not leadership
|
||||
- **Cell Leaders:** Responsible for operational coordination and planning
|
||||
- **Key Operatives:** Critical to resistance operations and high-value targets
|
||||
|
||||
**Timing Sensitivity:**
|
||||
- **Routine Communications:** No time pressure for delivery
|
||||
- **Coordination Required:** Timely delivery important for effectiveness
|
||||
- **Time-Critical Operations:** Immediate delivery required for success
|
||||
- **Emergency Situations:** Delay could result in immediate harm
|
||||
|
||||
### Operational Requirements Assessment
|
||||
|
||||
#### Communication Characteristics
|
||||
```
|
||||
Requirement Assessment:
|
||||
1. Participants
|
||||
- One-to-one communication
|
||||
- Small group (3-10 participants)
|
||||
- Large group (10+ participants)
|
||||
- Broadcast (one-to-many)
|
||||
|
||||
2. Content Type
|
||||
- Text messages only
|
||||
- File sharing required
|
||||
- Voice/video communication
|
||||
- Collaborative editing
|
||||
|
||||
3. Timing Requirements
|
||||
- Real-time communication required
|
||||
- Near real-time acceptable (minutes)
|
||||
- Asynchronous acceptable (hours)
|
||||
- Delayed acceptable (days)
|
||||
|
||||
4. Reliability Requirements
|
||||
- Mission-critical (must not fail)
|
||||
- Important (failure causes problems)
|
||||
- Useful (failure is inconvenient)
|
||||
- Optional (failure is acceptable)
|
||||
```
|
||||
|
||||
#### Technical Constraints
|
||||
- **Device Capabilities:** Smartphone, computer, or specialized hardware requirements
|
||||
- **Network Requirements:** Internet, cellular, or offline capability needs
|
||||
- **Technical Expertise:** User skill level and training requirements
|
||||
- **Infrastructure:** Server hosting and maintenance capabilities
|
||||
|
||||
### Protocol Selection Matrix
|
||||
|
||||
#### Layer 1 Selection Criteria
|
||||
**Use Layer 1 When:**
|
||||
- Content sensitivity is high or critical
|
||||
- Participants are high-risk or key operatives
|
||||
- Real-time communication is required under surveillance
|
||||
- Maximum anonymity and metadata protection needed
|
||||
|
||||
**Layer 1 Tool Selection:**
|
||||
```
|
||||
Session Messenger:
|
||||
- Best for: Routine high-security communications
|
||||
- Strengths: Easy to use, good mobile support
|
||||
- Limitations: Requires internet connection
|
||||
|
||||
Briar:
|
||||
- Best for: Offline and mesh networking scenarios
|
||||
- Strengths: No servers, offline capability
|
||||
- Limitations: More complex setup and usage
|
||||
```
|
||||
|
||||
#### Layer 2 Selection Criteria
|
||||
**Use Layer 2 When:**
|
||||
- Collaboration features are required
|
||||
- Group communication with multiple participants
|
||||
- File sharing and document collaboration needed
|
||||
- Persistent communication history is valuable
|
||||
|
||||
**Layer 2 Tool Selection:**
|
||||
```
|
||||
Element/Matrix:
|
||||
- Best for: Group communications and coordination
|
||||
- Strengths: Rich features, federation capability
|
||||
- Limitations: Requires server infrastructure
|
||||
|
||||
CryptPad:
|
||||
- Best for: Document collaboration and editing
|
||||
- Strengths: Real-time collaboration, no accounts required
|
||||
- Limitations: Limited to document-based collaboration
|
||||
```
|
||||
|
||||
#### Layer 3 Selection Criteria
|
||||
**Use Layer 3 When:**
|
||||
- Backup communication channels needed
|
||||
- Network disruption or censorship expected
|
||||
- Asynchronous communication is acceptable
|
||||
- Maximum reliability and availability required
|
||||
|
||||
#### Layer 4 Selection Criteria
|
||||
**Use Layer 4 When:**
|
||||
- Public communication and information distribution
|
||||
- Sender anonymity is critical
|
||||
- Censorship resistance is required
|
||||
- One-to-many communication model needed
|
||||
|
||||
### Implementation Guidelines
|
||||
|
||||
#### Protocol Transition Procedures
|
||||
```
|
||||
Escalation Procedures:
|
||||
Normal Operations → Layer 2 (Collaboration)
|
||||
Increased Surveillance → Layer 1 (High Security)
|
||||
Network Disruption → Layer 3 (Failsafe)
|
||||
Public Communications → Layer 4 (Broadcasting)
|
||||
|
||||
De-escalation Procedures:
|
||||
Emergency → Layer 3 → Layer 1 → Layer 2
|
||||
Crisis → Layer 1 → Layer 2 → Normal Operations
|
||||
```
|
||||
|
||||
#### Multi-Layer Coordination
|
||||
- **Layer Integration:** Use multiple layers simultaneously for different purposes
|
||||
- **Information Flow:** Establish procedures for moving information between layers
|
||||
- **Verification:** Cross-verify critical information through multiple layers
|
||||
- **Backup Activation:** Automatic failover to backup layers when primary fails
|
||||
|
||||
#### Training and Adoption
|
||||
- **Progressive Training:** Start with basic tools before introducing complex systems
|
||||
- **Scenario-Based Practice:** Train using realistic operational scenarios
|
||||
- **Regular Exercises:** Maintain skills through regular practice and drills
|
||||
- **Feedback Integration:** Incorporate user feedback into protocol refinement
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Protocol Evolution</div>
|
||||
<p>Communication protocols must evolve as threats change, technology advances, and operational requirements shift. Regular review and updating of protocol selection criteria ensures continued effectiveness and security.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Chapter Summary
|
||||
|
||||
Chapter 3 has established the multi-layer communication architecture that provides the foundation for secure resistance communications:
|
||||
|
||||
**Section 3-1** introduced the strategic framework and principles underlying the multi-layer approach to communication security.
|
||||
|
||||
**Section 3-2** detailed Layer 1 systems for high-risk real-time communication with maximum security and anonymity protection.
|
||||
|
||||
**Section 3-3** covered Layer 2 systems that balance security with collaboration functionality for ongoing operational coordination.
|
||||
|
||||
**Section 3-4** described Layer 3 failsafe and offline methods that provide backup communication capabilities independent of internet infrastructure.
|
||||
|
||||
**Section 3-5** explained Layer 4 anonymous broadcasting systems for public communications with sender anonymity and censorship resistance.
|
||||
|
||||
**Section 3-6** provided systematic frameworks for selecting appropriate communication protocols based on security requirements and operational needs.
|
||||
|
||||
### Integration and Implementation
|
||||
|
||||
The multi-layer architecture provides a comprehensive framework for resistance communications, but effective implementation requires:
|
||||
|
||||
- **Systematic Assessment:** Regular evaluation of security requirements and operational needs
|
||||
- **Progressive Implementation:** Gradual deployment starting with basic tools and building complexity
|
||||
- **Ongoing Training:** Continuous education and skill development for all participants
|
||||
- **Regular Review:** Periodic assessment and updating of communication protocols and procedures
|
||||
|
||||
### Next Steps
|
||||
|
||||
Chapter 4 builds on this architectural foundation by providing detailed configuration and operational guidance for the secure messaging systems that form the core of Layers 1 and 2. Understanding the architectural principles covered in this chapter is essential preparation for the practical implementation guidance that follows.
|
||||
|
||||
---
|
||||
|
||||
**Next:** [Chapter 4: Secure Messaging and Voice Communications →](/chapters/chapter-4/)
|
||||
|
1592
_chapters/chapter-4.md
Normal file
1592
_chapters/chapter-4.md
Normal file
File diff suppressed because it is too large
Load Diff
1323
_chapters/chapter-5.md
Normal file
1323
_chapters/chapter-5.md
Normal file
File diff suppressed because it is too large
Load Diff
123
_config.yml
Normal file
123
_config.yml
Normal file
|
@ -0,0 +1,123 @@
|
|||
# Field Guide for Subversives - Jekyll Configuration
|
||||
|
||||
title: "Field Manual for Resistance Operations"
|
||||
subtitle: "FM-R1: Secure Communication Networks for Decentralized Resistance"
|
||||
description: "A comprehensive guide to secure communication and operational security for newcomers to resistance movements"
|
||||
baseurl: ""
|
||||
url: "https://guide.resist.is"
|
||||
|
||||
# Organization info
|
||||
organization: "Department of Internautics"
|
||||
bureau: "Bureau of Decentralized Resistance"
|
||||
manual_designation: "FM-R1"
|
||||
classification: "UNCLASSIFIED"
|
||||
version: "1.0"
|
||||
date: "2025-08-28"
|
||||
|
||||
# Build settings
|
||||
markdown: kramdown
|
||||
highlighter: rouge
|
||||
permalink: /:categories/:title/
|
||||
|
||||
# Collections
|
||||
collections:
|
||||
parts:
|
||||
output: true
|
||||
permalink: /:collection/:name/
|
||||
chapters:
|
||||
output: true
|
||||
permalink: /:collection/:name/
|
||||
sections:
|
||||
output: true
|
||||
permalink: /:collection/:name/
|
||||
appendices:
|
||||
output: true
|
||||
permalink: /:collection/:name/
|
||||
|
||||
# Default layouts
|
||||
defaults:
|
||||
- scope:
|
||||
path: ""
|
||||
type: "pages"
|
||||
values:
|
||||
layout: "default"
|
||||
- scope:
|
||||
path: ""
|
||||
type: "parts"
|
||||
values:
|
||||
layout: "part"
|
||||
- scope:
|
||||
path: ""
|
||||
type: "chapters"
|
||||
values:
|
||||
layout: "chapter"
|
||||
- scope:
|
||||
path: ""
|
||||
type: "sections"
|
||||
values:
|
||||
layout: "section"
|
||||
- scope:
|
||||
path: ""
|
||||
type: "appendices"
|
||||
values:
|
||||
layout: "appendix"
|
||||
|
||||
# Navigation structure
|
||||
navigation:
|
||||
- title: "Table of Contents"
|
||||
url: "/"
|
||||
- title: "Preface"
|
||||
url: "/preface/"
|
||||
- title: "Introduction"
|
||||
url: "/introduction/"
|
||||
- title: "Part I: Foundations"
|
||||
url: "/parts/part-1/"
|
||||
children:
|
||||
- title: "Chapter 1: Core Security Principles"
|
||||
url: "/chapters/chapter-1/"
|
||||
- title: "Chapter 2: Threat Assessment"
|
||||
url: "/chapters/chapter-2/"
|
||||
- title: "Part II: Communication Systems"
|
||||
url: "/parts/part-2/"
|
||||
children:
|
||||
- title: "Chapter 3: Communication Architecture"
|
||||
url: "/chapters/chapter-3/"
|
||||
- title: "Chapter 4: Secure Messaging"
|
||||
url: "/chapters/chapter-4/"
|
||||
- title: "Chapter 5: File Sharing"
|
||||
url: "/chapters/chapter-5/"
|
||||
- title: "Part III: Operational Security"
|
||||
url: "/parts/part-3/"
|
||||
children:
|
||||
- title: "Chapter 6: Hardware Security"
|
||||
url: "/chapters/chapter-6/"
|
||||
- title: "Chapter 7: Digital Hygiene"
|
||||
url: "/chapters/chapter-7/"
|
||||
- title: "Chapter 8: Operational Procedures"
|
||||
url: "/chapters/chapter-8/"
|
||||
- title: "Part IV: Advanced Operations"
|
||||
url: "/parts/part-4/"
|
||||
children:
|
||||
- title: "Chapter 9: Network Resilience"
|
||||
url: "/chapters/chapter-9/"
|
||||
- title: "Chapter 10: Counter-Intelligence"
|
||||
url: "/chapters/chapter-10/"
|
||||
- title: "Appendices"
|
||||
url: "/appendices/"
|
||||
|
||||
# Plugins
|
||||
plugins:
|
||||
- jekyll-sitemap
|
||||
- jekyll-feed
|
||||
|
||||
# Exclude from processing
|
||||
exclude:
|
||||
- Gemfile
|
||||
- Gemfile.lock
|
||||
- node_modules
|
||||
- vendor/bundle/
|
||||
- vendor/cache/
|
||||
- vendor/gems/
|
||||
- vendor/ruby/
|
||||
- README.md
|
||||
|
86
_includes/navigation.html
Normal file
86
_includes/navigation.html
Normal file
|
@ -0,0 +1,86 @@
|
|||
<div class="nav-section">
|
||||
<h3>Field Manual</h3>
|
||||
<ul>
|
||||
<li><a href="{{ '/' | relative_url }}" {% if page.url == '/' %}class="active"{% endif %}>Table of Contents</a></li>
|
||||
<li><a href="{{ '/preface/' | relative_url }}" {% if page.url == '/preface/' %}class="active"{% endif %}>Preface</a></li>
|
||||
<li><a href="{{ '/introduction/' | relative_url }}" {% if page.url == '/introduction/' %}class="active"{% endif %}>Introduction</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part I: Foundations</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="{{ '/parts/part-1/' | relative_url }}" {% if page.url contains '/parts/part-1' %}class="active"{% endif %}>Part Overview</a>
|
||||
<ul>
|
||||
<li><a href="{{ '/chapters/chapter-1/' | relative_url }}" {% if page.url contains '/chapters/chapter-1' %}class="active"{% endif %}>Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-2/' | relative_url }}" {% if page.url contains '/chapters/chapter-2' %}class="active"{% endif %}>Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part II: Communication</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="{{ '/parts/part-2/' | relative_url }}" {% if page.url contains '/parts/part-2' %}class="active"{% endif %}>Part Overview</a>
|
||||
<ul>
|
||||
<li><a href="{{ '/chapters/chapter-3/' | relative_url }}" {% if page.url contains '/chapters/chapter-3' %}class="active"{% endif %}>Ch 3: Communication Architecture</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-4/' | relative_url }}" {% if page.url contains '/chapters/chapter-4' %}class="active"{% endif %}>Ch 4: Secure Messaging</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-5/' | relative_url }}" {% if page.url contains '/chapters/chapter-5' %}class="active"{% endif %}>Ch 5: File Sharing</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part III: OpSec</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="{{ '/parts/part-3/' | relative_url }}" {% if page.url contains '/parts/part-3' %}class="active"{% endif %}>Part Overview</a>
|
||||
<ul>
|
||||
<li><a href="{{ '/chapters/chapter-6/' | relative_url }}" {% if page.url contains '/chapters/chapter-6' %}class="active"{% endif %}>Ch 6: Hardware Security</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-7/' | relative_url }}" {% if page.url contains '/chapters/chapter-7' %}class="active"{% endif %}>Ch 7: Digital Hygiene</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-8/' | relative_url }}" {% if page.url contains '/chapters/chapter-8' %}class="active"{% endif %}>Ch 8: Operational Procedures</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part IV: Advanced</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="{{ '/parts/part-4/' | relative_url }}" {% if page.url contains '/parts/part-4' %}class="active"{% endif %}>Part Overview</a>
|
||||
<ul>
|
||||
<li><a href="{{ '/chapters/chapter-9/' | relative_url }}" {% if page.url contains '/chapters/chapter-9' %}class="active"{% endif %}>Ch 9: Network Resilience</a></li>
|
||||
<li><a href="{{ '/chapters/chapter-10/' | relative_url }}" {% if page.url contains '/chapters/chapter-10' %}class="active"{% endif %}>Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="{{ '/appendices/' | relative_url }}" {% if page.url contains '/appendices' %}class="active"{% endif %}>Quick Reference</a></li>
|
||||
<li><a href="{{ '/appendices/tools/' | relative_url }}" {% if page.url contains '/appendices/tools' %}class="active"{% endif %}>Tool Guides</a></li>
|
||||
<li><a href="{{ '/appendices/resources/' | relative_url }}" {% if page.url contains '/appendices/resources' %}class="active"{% endif %}>External Resources</a></li>
|
||||
<li><a href="{{ '/appendices/glossary/' | relative_url }}" {% if page.url contains '/appendices/glossary' %}class="active"{% endif %}>Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
96
_layouts/default.html
Normal file
96
_layouts/default.html
Normal file
|
@ -0,0 +1,96 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>{% if page.title %}{{ page.title }} - {% endif %}{{ site.title }}</title>
|
||||
<meta name="description" content="{% if page.description %}{{ page.description }}{% else %}{{ site.description }}{% endif %}">
|
||||
|
||||
<!-- Favicon -->
|
||||
<link rel="icon" type="image/x-icon" href="{{ '/assets/images/favicon.ico' | relative_url }}">
|
||||
|
||||
<!-- Stylesheets -->
|
||||
<link rel="stylesheet" href="{{ '/assets/css/main.css' | relative_url }}">
|
||||
|
||||
<!-- 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">
|
||||
</head>
|
||||
<body>
|
||||
<header class="header">
|
||||
<div class="container">
|
||||
<div class="header-content">
|
||||
<div class="logo">
|
||||
<span class="omega">Ω</span>
|
||||
<span>{{ site.manual_designation }}</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">
|
||||
{% include navigation.html %}
|
||||
</nav>
|
||||
|
||||
<main class="content">
|
||||
<div class="content-header">
|
||||
<div class="manual-designation">{{ site.manual_designation }}: {{ site.subtitle }}</div>
|
||||
<div class="classification">{{ site.classification }}</div>
|
||||
{% if page.section_number %}
|
||||
<div class="section-number">Section {{ page.section_number }}</div>
|
||||
{% endif %}
|
||||
</div>
|
||||
|
||||
{{ content }}
|
||||
|
||||
{% if page.prev_page or page.next_page %}
|
||||
<nav class="section-nav">
|
||||
{% if page.prev_page %}
|
||||
<a href="{{ page.prev_page.url | relative_url }}" class="nav-link">
|
||||
<span class="arrow">←</span>
|
||||
<span>{{ page.prev_page.title }}</span>
|
||||
</a>
|
||||
{% else %}
|
||||
<div></div>
|
||||
{% endif %}
|
||||
|
||||
{% if page.next_page %}
|
||||
<a href="{{ page.next_page.url | relative_url }}" class="nav-link">
|
||||
<span>{{ page.next_page.title }}</span>
|
||||
<span class="arrow">→</span>
|
||||
</a>
|
||||
{% else %}
|
||||
<div></div>
|
||||
{% endif %}
|
||||
</nav>
|
||||
{% endif %}
|
||||
</main>
|
||||
</div>
|
||||
|
||||
<footer class="footer">
|
||||
<div class="container">
|
||||
<div class="footer-content">
|
||||
<div class="organization">{{ site.organization }}</div>
|
||||
<div>{{ site.bureau }}</div>
|
||||
<div>{{ site.manual_designation }} - Version {{ site.version }} - {{ site.date }}</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' | relative_url }}"></script>
|
||||
</body>
|
||||
</html>
|
||||
|
138
_parts/part-1.md
Normal file
138
_parts/part-1.md
Normal file
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Part I: Foundations of Resistance Security"
|
||||
description: "Core security principles and threat assessment methodologies for resistance operations"
|
||||
prev_page:
|
||||
title: "Introduction"
|
||||
url: "/introduction/"
|
||||
next_page:
|
||||
title: "Chapter 1: Core Security Principles"
|
||||
url: "/chapters/chapter-1/"
|
||||
---
|
||||
|
||||
# Part I: Foundations of Resistance Security
|
||||
|
||||
## Overview
|
||||
|
||||
Part I establishes the theoretical and practical foundations necessary for all resistance security operations. Before implementing any technical measures or operational procedures, resistance practitioners must understand the fundamental principles that govern security in hostile environments and develop the analytical skills necessary to assess threats and design appropriate countermeasures.
|
||||
|
||||
This part addresses the most critical question in resistance security: **How do you think about security in a way that leads to effective protection?**
|
||||
|
||||
## Learning Objectives
|
||||
|
||||
Upon completing Part I, you will be able to:
|
||||
|
||||
- Apply core security principles to evaluate and design resistance operations
|
||||
- Conduct systematic threat assessments for your specific operational environment
|
||||
- Develop risk management strategies appropriate to your threat level
|
||||
- Understand the relationship between security measures and operational effectiveness
|
||||
- Recognize common security failures and their underlying causes
|
||||
|
||||
## Chapter Overview
|
||||
|
||||
### Chapter 1: Core Security Principles (1-1 to 1-5)
|
||||
|
||||
The five fundamental principles that must guide all resistance security decisions:
|
||||
|
||||
**1-1: Principle of Least Privilege** - Limiting access to the minimum necessary for operational effectiveness
|
||||
|
||||
**1-2: Need-to-Know Basis** - Compartmentalizing information to prevent cascade failures
|
||||
|
||||
**1-3: Compartmentalization and Cell Structure** - Organizing resistance networks to contain compromise
|
||||
|
||||
**1-4: Zero Trust Verification** - Assuming compromise and requiring continuous authentication
|
||||
|
||||
**1-5: Metadata Minimization** - Reducing the digital traces that reveal operational patterns
|
||||
|
||||
### Chapter 2: Threat Assessment and Operational Environment (2-1 to 2-4)
|
||||
|
||||
Systematic approaches to understanding and responding to threats:
|
||||
|
||||
**2-1: Understanding Your Adversary** - Analyzing capabilities, motivations, and limitations of hostile forces
|
||||
|
||||
**2-2: Threat Model Development** - Creating structured assessments of risks and vulnerabilities
|
||||
|
||||
**2-3: Risk Assessment Framework** - Quantifying and prioritizing security investments
|
||||
|
||||
**2-4: Operational Security (OpSec) Fundamentals** - Translating threat assessments into practical procedures
|
||||
|
||||
## The Security Mindset
|
||||
|
||||
Before diving into specific principles and procedures, it's essential to understand the fundamental shift in thinking required for effective resistance security. This shift involves:
|
||||
|
||||
### From Convenience to Security
|
||||
|
||||
In normal life, we optimize for convenience, efficiency, and ease of use. In resistance operations, security becomes the primary consideration, with convenience secondary. This doesn't mean making things unnecessarily difficult, but rather accepting that some inconvenience is the price of safety.
|
||||
|
||||
### From Trust to Verification
|
||||
|
||||
Normal social and professional relationships operate on trust and good faith. Resistance operations must assume that trust can be compromised, either through infiltration or coercion, and build verification mechanisms into all critical processes.
|
||||
|
||||
### From Reactive to Proactive
|
||||
|
||||
Most people respond to security threats after they become apparent. Resistance operations must anticipate threats and implement countermeasures before they're needed, because by the time a threat is obvious, it may be too late to respond effectively.
|
||||
|
||||
### From Individual to Collective
|
||||
|
||||
Personal security practices focus on protecting yourself. Resistance security must consider how your actions affect the safety of others in your network, and how their actions affect your safety.
|
||||
|
||||
## Common Misconceptions
|
||||
|
||||
### "Encryption Solves Everything"
|
||||
|
||||
While encryption is essential, it only protects the content of communications, not the metadata that reveals who is talking to whom, when, and from where. Metadata analysis can reveal network structures and operational patterns even when all communications are encrypted.
|
||||
|
||||
### "If You Have Nothing to Hide..."
|
||||
|
||||
This argument fundamentally misunderstands the nature of authoritarian surveillance. The goal is not just to find evidence of wrongdoing, but to map networks, predict behavior, and suppress dissent before it becomes effective.
|
||||
|
||||
### "They're Too Powerful to Resist"
|
||||
|
||||
While authoritarian regimes have significant advantages, they also have limitations and vulnerabilities. Understanding both their capabilities and their constraints is essential for developing effective resistance strategies.
|
||||
|
||||
### "Perfect Security is Possible"
|
||||
|
||||
No security system is perfect, and pursuing perfect security often leads to systems so complex and restrictive that they cannot be used effectively. The goal is appropriate security for your specific threat environment and operational requirements.
|
||||
|
||||
## Integration with Subsequent Parts
|
||||
|
||||
The principles and methodologies covered in Part I provide the foundation for all subsequent technical and operational guidance:
|
||||
|
||||
- **Part II** applies these principles to design secure communication systems
|
||||
- **Part III** translates them into practical operational security procedures
|
||||
- **Part IV** extends them to advanced scenarios and specialized threats
|
||||
|
||||
Each technical recommendation and operational procedure in later parts derives from the fundamental principles established here. Understanding these foundations is essential for adapting the manual's guidance to your specific circumstances and for making sound security decisions when facing novel situations.
|
||||
|
||||
## Study Approach
|
||||
|
||||
### For Individual Study
|
||||
|
||||
1. **Read each section completely** before moving to the next
|
||||
2. **Take notes** on how principles apply to your specific situation
|
||||
3. **Work through examples** using scenarios relevant to your operations
|
||||
4. **Review regularly** as these concepts must become second nature
|
||||
|
||||
### For Group Study
|
||||
|
||||
1. **Discuss each principle** and its implications for your organization
|
||||
2. **Develop case studies** based on your operational environment
|
||||
3. **Practice threat modeling** for actual or hypothetical operations
|
||||
4. **Create reference materials** summarizing key concepts for quick review
|
||||
|
||||
### For Training Others
|
||||
|
||||
1. **Use concrete examples** rather than abstract concepts
|
||||
2. **Connect principles to practical consequences** of security failures
|
||||
3. **Encourage questions** and discussion of edge cases
|
||||
4. **Provide opportunities to practice** threat assessment skills
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Foundation First</div>
|
||||
<p>Do not skip Part I to get to "more practical" technical content. The principles covered here determine whether technical measures will be effective or merely provide a false sense of security. Every security failure can be traced back to a violation of these fundamental principles.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**Ready to begin?** Start with [Chapter 1: Core Security Principles →](/chapters/chapter-1/)
|
||||
|
258
_parts/part-2.md
Normal file
258
_parts/part-2.md
Normal file
|
@ -0,0 +1,258 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Part II: Secure Communication Systems"
|
||||
description: "Multi-layer communication architectures and secure messaging systems for resistance operations"
|
||||
prev_page:
|
||||
title: "Chapter 2: Threat Assessment"
|
||||
url: "/chapters/chapter-2/"
|
||||
next_page:
|
||||
title: "Chapter 3: Communication Architecture"
|
||||
url: "/chapters/chapter-3/"
|
||||
---
|
||||
|
||||
# Part II: Secure Communication Systems
|
||||
|
||||
## Overview
|
||||
|
||||
Part II addresses the critical challenge of maintaining secure communications within resistance networks operating under advanced surveillance. This part provides comprehensive guidance for implementing multi-layer communication architectures that balance security requirements with operational effectiveness.
|
||||
|
||||
Communication security is the backbone of resistance operations. Without secure communications, resistance networks cannot coordinate activities, share intelligence, or maintain operational security. However, communication also represents the greatest vulnerability, as every communication creates metadata that can be analyzed to reveal network structures, operational patterns, and individual behaviors.
|
||||
|
||||
## Learning Objectives
|
||||
|
||||
Upon completing Part II, you will be able to:
|
||||
|
||||
- Design and implement multi-layer communication architectures appropriate to your threat environment
|
||||
- Configure and operate secure messaging systems including Session, Element/Matrix, Briar, and Signal
|
||||
- Establish secure file sharing and collaboration systems using CryptPad, OnionShare, and encrypted cloud storage
|
||||
- Implement communication protocols that minimize metadata exposure and maximize operational security
|
||||
- Develop contingency communication plans for various compromise and failure scenarios
|
||||
|
||||
## The Communication Security Challenge
|
||||
|
||||
### The Metadata Problem
|
||||
|
||||
Modern surveillance systems focus less on communication content (which can be encrypted) and more on communication metadata (which reveals patterns even when content is protected). Every digital communication generates metadata including:
|
||||
|
||||
- **Sender and recipient identities** and network addresses
|
||||
- **Timing information** including send/receive timestamps
|
||||
- **Location data** from device GPS and network connections
|
||||
- **Communication patterns** including frequency and duration
|
||||
- **Device information** including hardware and software details
|
||||
|
||||
This metadata can be analyzed to:
|
||||
- Map network structures and identify key participants
|
||||
- Predict operational activities and timing
|
||||
- Locate physical meetings and safe houses
|
||||
- Identify behavioral patterns and vulnerabilities
|
||||
|
||||
### The Usability-Security Tension
|
||||
|
||||
Perfect communication security would require:
|
||||
- No digital communications whatsoever
|
||||
- Face-to-face meetings only in secure locations
|
||||
- Perfect operational security from all participants
|
||||
- No time-sensitive coordination requirements
|
||||
|
||||
Perfect operational effectiveness would require:
|
||||
- Instant communication between all participants
|
||||
- Rich multimedia sharing and collaboration
|
||||
- Real-time coordination and decision-making
|
||||
- Seamless integration with existing tools and workflows
|
||||
|
||||
Practical resistance communications must balance these competing requirements through carefully designed architectures that provide appropriate security for specific use cases while maintaining operational effectiveness.
|
||||
|
||||
## Multi-Layer Communication Strategy
|
||||
|
||||
Part II is organized around a four-layer communication architecture that provides different security levels for different operational requirements:
|
||||
|
||||
### Layer 1: High-Risk Real-Time Communication
|
||||
**Use Case:** Time-sensitive coordination during active operations
|
||||
**Security Level:** Maximum security, minimal metadata
|
||||
**Tools:** Session Messenger, Briar mesh networking
|
||||
**Characteristics:**
|
||||
- Onion routing and metadata protection
|
||||
- Peer-to-peer architecture with no central servers
|
||||
- Ephemeral messaging with automatic deletion
|
||||
- Offline capability and mesh networking
|
||||
|
||||
### Layer 2: Secure Collaboration Systems
|
||||
**Use Case:** Planning, document sharing, and ongoing coordination
|
||||
**Security Level:** High security with collaboration features
|
||||
**Tools:** Element/Matrix (self-hosted), CryptPad
|
||||
**Characteristics:**
|
||||
- End-to-end encryption with forward secrecy
|
||||
- Self-hosted infrastructure under resistance control
|
||||
- Rich collaboration features including file sharing
|
||||
- Persistent storage with secure access controls
|
||||
|
||||
### Layer 3: Failsafe and Offline Methods
|
||||
**Use Case:** Emergency communications and backup channels
|
||||
**Security Level:** Maximum reliability and availability
|
||||
**Tools:** OnionShare, encrypted email, physical dead drops
|
||||
**Characteristics:**
|
||||
- No dependence on internet infrastructure
|
||||
- Asynchronous communication with time delays
|
||||
- Multiple redundant channels and methods
|
||||
- Resistance to network disruption and censorship
|
||||
|
||||
### Layer 4: Anonymous Broadcasting
|
||||
**Use Case:** Public communications and propaganda distribution
|
||||
**Security Level:** Sender anonymity and censorship resistance
|
||||
**Tools:** Tor hidden services, distributed publishing platforms
|
||||
**Characteristics:**
|
||||
- One-to-many communication model
|
||||
- Strong sender anonymity protection
|
||||
- Censorship resistance and availability
|
||||
- Public accessibility without authentication
|
||||
|
||||
## Chapter Overview
|
||||
|
||||
### Chapter 3: Communication Layer Architecture (3-1 to 3-6)
|
||||
|
||||
Establishes the theoretical framework and practical implementation of multi-layer communication systems:
|
||||
|
||||
**3-1: Multi-Layer Communication Strategy** - Overall architecture and layer selection criteria
|
||||
|
||||
**3-2: High-Risk Real-Time Communication (Layer 1)** - Maximum security for time-sensitive operations
|
||||
|
||||
**3-3: Secure Collaboration Systems (Layer 2)** - Balancing security with collaboration needs
|
||||
|
||||
**3-4: Failsafe and Offline Methods (Layer 3)** - Backup and emergency communication channels
|
||||
|
||||
**3-5: Anonymous Broadcasting (Layer 4)** - Public communications and information distribution
|
||||
|
||||
**3-6: Communication Protocol Selection** - Choosing appropriate tools and methods for specific scenarios
|
||||
|
||||
### Chapter 4: Secure Messaging and Voice Communications (4-1 to 4-8)
|
||||
|
||||
Provides detailed configuration and operational guidance for secure messaging systems:
|
||||
|
||||
**4-1: Session Messenger Configuration** - Maximum security messaging with onion routing
|
||||
|
||||
**4-2: Element/Matrix Self-Hosted Setup** - Secure collaboration platform implementation
|
||||
|
||||
**4-3: Briar Peer-to-Peer Messaging** - Decentralized messaging without servers
|
||||
|
||||
**4-4: Signal Security Best Practices** - Operational security for mainstream secure messaging
|
||||
|
||||
**4-5: Voice Communication Security** - Secure voice calls and audio communications
|
||||
|
||||
**4-6: Group Communication Management** - Security protocols for multi-participant communications
|
||||
|
||||
**4-7: Message Verification and Authentication** - Ensuring message integrity and sender verification
|
||||
|
||||
**4-8: Communication Scheduling and Protocols** - Operational procedures for secure communications
|
||||
|
||||
### Chapter 5: File Sharing and Collaboration (5-1 to 5-6)
|
||||
|
||||
Covers secure systems for document collaboration and file sharing:
|
||||
|
||||
**5-1: CryptPad Secure Document Collaboration** - Real-time collaborative editing with encryption
|
||||
|
||||
**5-2: OnionShare Anonymous File Transfer** - Secure file sharing over Tor network
|
||||
|
||||
**5-3: Encrypted Cloud Storage (Mega/Proton)** - Secure cloud storage for resistance operations
|
||||
|
||||
**5-4: Digital Dead Drops** - Asynchronous file sharing without direct contact
|
||||
|
||||
**5-5: Version Control for Sensitive Documents** - Managing document versions and changes securely
|
||||
|
||||
**5-6: Collaborative Security Protocols** - Operational procedures for secure collaboration
|
||||
|
||||
## Implementation Approach
|
||||
|
||||
### Progressive Implementation
|
||||
|
||||
Part II is designed for progressive implementation, allowing resistance networks to start with basic secure communications and gradually add more sophisticated capabilities:
|
||||
|
||||
**Phase 1: Basic Secure Messaging**
|
||||
- Implement Signal or Session for basic communications
|
||||
- Establish basic operational security procedures
|
||||
- Train participants in secure communication practices
|
||||
|
||||
**Phase 2: Collaboration Infrastructure**
|
||||
- Deploy self-hosted Matrix server for group communications
|
||||
- Implement CryptPad for document collaboration
|
||||
- Establish file sharing protocols using OnionShare
|
||||
|
||||
**Phase 3: Advanced Architecture**
|
||||
- Implement full multi-layer communication strategy
|
||||
- Deploy Briar for high-security scenarios
|
||||
- Establish emergency and backup communication channels
|
||||
|
||||
**Phase 4: Operational Integration**
|
||||
- Integrate communication systems with operational planning
|
||||
- Implement advanced security protocols and procedures
|
||||
- Establish training and support systems for network participants
|
||||
|
||||
### Security Considerations
|
||||
|
||||
Each communication system and protocol covered in Part II includes specific security considerations:
|
||||
|
||||
**Technical Security:**
|
||||
- Encryption strength and implementation quality
|
||||
- Metadata protection and anonymity features
|
||||
- Infrastructure security and server hardening
|
||||
- Software updates and vulnerability management
|
||||
|
||||
**Operational Security:**
|
||||
- User authentication and access control
|
||||
- Communication protocols and procedures
|
||||
- Incident response and compromise recovery
|
||||
- Training and security awareness
|
||||
|
||||
**Strategic Security:**
|
||||
- Threat model alignment and risk assessment
|
||||
- Backup and redundancy planning
|
||||
- Legal considerations and jurisdiction issues
|
||||
- Long-term sustainability and maintenance
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Communication Discipline</div>
|
||||
<p>The most sophisticated communication systems are worthless without proper operational discipline. All participants must understand and consistently follow communication protocols, security procedures, and operational security practices.</p>
|
||||
</div>
|
||||
|
||||
## Integration with Other Parts
|
||||
|
||||
Part II builds directly on the foundational principles and threat assessment methodologies covered in Part I:
|
||||
|
||||
- **Core Security Principles** guide the selection and configuration of communication systems
|
||||
- **Threat Assessment** determines appropriate security levels and tool selection
|
||||
- **Risk Assessment** informs decisions about acceptable trade-offs between security and usability
|
||||
- **OpSec Fundamentals** provide the procedural framework for secure communication operations
|
||||
|
||||
Part II also provides the foundation for the operational security procedures covered in Part III and the advanced techniques covered in Part IV.
|
||||
|
||||
## Getting Started
|
||||
|
||||
### For Technical Implementation
|
||||
|
||||
1. **Start with threat assessment** to determine appropriate security levels
|
||||
2. **Begin with basic tools** (Signal or Session) before implementing complex systems
|
||||
3. **Test all systems thoroughly** in safe environments before operational use
|
||||
4. **Implement gradually** with proper training and support for all participants
|
||||
|
||||
### For Operational Planning
|
||||
|
||||
1. **Map communication requirements** to the four-layer architecture
|
||||
2. **Develop communication protocols** appropriate to your threat environment
|
||||
3. **Establish training programs** for all communication tools and procedures
|
||||
4. **Plan for contingencies** including system compromise and failure scenarios
|
||||
|
||||
### For Network Leadership
|
||||
|
||||
1. **Assess current communication practices** against security requirements
|
||||
2. **Develop implementation timeline** for improved communication security
|
||||
3. **Allocate resources** for infrastructure, training, and ongoing maintenance
|
||||
4. **Establish governance** for communication system management and security
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Implementation Priority</div>
|
||||
<p>Focus first on implementing basic secure messaging (Chapter 4) before attempting to deploy complex multi-layer architectures. Solid implementation of fundamental tools is more valuable than poorly implemented advanced systems.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**Ready to begin?** Start with [Chapter 3: Communication Layer Architecture →](/chapters/chapter-3/)
|
||||
|
411
_site/assets/css/main.css
Normal file
411
_site/assets/css/main.css
Normal file
|
@ -0,0 +1,411 @@
|
|||
* {
|
||||
box-sizing: border-box;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
html {
|
||||
font-size: 16px;
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: "Courier New", "Monaco", "Menlo", monospace;
|
||||
font-size: 16px;
|
||||
line-height: 1.6;
|
||||
color: #ffffff;
|
||||
background-color: #000000;
|
||||
min-height: 100vh;
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-family: "Arial", "Helvetica", sans-serif;
|
||||
font-weight: bold;
|
||||
margin-bottom: 1rem;
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2.5rem;
|
||||
color: #00ff00;
|
||||
text-align: center;
|
||||
margin-bottom: 2rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 2px;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 2rem;
|
||||
color: #0066ff;
|
||||
border-bottom: 2px solid #0066ff;
|
||||
padding-bottom: 0.5rem;
|
||||
margin-top: 2rem;
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.5rem;
|
||||
color: #00ff00;
|
||||
margin-top: 1.5rem;
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-size: 1.25rem;
|
||||
color: #ffffff;
|
||||
margin-top: 1rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
a {
|
||||
color: #0066ff;
|
||||
text-decoration: none;
|
||||
transition: color 0.3s ease;
|
||||
}
|
||||
a:hover {
|
||||
color: #00ff00;
|
||||
text-decoration: underline;
|
||||
}
|
||||
a:visited {
|
||||
color: #66a3ff;
|
||||
}
|
||||
|
||||
ul, ol {
|
||||
margin-bottom: 1rem;
|
||||
padding-left: 2rem;
|
||||
}
|
||||
ul li, ol li {
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
code {
|
||||
background-color: #1a1a1a;
|
||||
color: #00ff00;
|
||||
padding: 0.2rem 0.4rem;
|
||||
border-radius: 3px;
|
||||
font-family: "Courier New", "Monaco", "Menlo", monospace;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
|
||||
pre {
|
||||
background-color: #1a1a1a;
|
||||
color: #ffffff;
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
overflow-x: auto;
|
||||
margin-bottom: 1rem;
|
||||
border-left: 4px solid #00ff00;
|
||||
}
|
||||
pre code {
|
||||
background: none;
|
||||
padding: 0;
|
||||
color: inherit;
|
||||
}
|
||||
|
||||
table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
margin-bottom: 1rem;
|
||||
background-color: #1a1a1a;
|
||||
}
|
||||
table th, table td {
|
||||
padding: 0.75rem;
|
||||
text-align: left;
|
||||
border-bottom: 1px solid #333333;
|
||||
}
|
||||
table th {
|
||||
background-color: #333333;
|
||||
color: #00ff00;
|
||||
font-weight: bold;
|
||||
}
|
||||
table tr:hover {
|
||||
background-color: #272727;
|
||||
}
|
||||
|
||||
.container {
|
||||
max-width: 1200px;
|
||||
margin: 0 auto;
|
||||
padding: 0 1rem;
|
||||
}
|
||||
|
||||
.header {
|
||||
background-color: #000000;
|
||||
border-bottom: 2px solid #00ff00;
|
||||
padding: 1rem 0;
|
||||
position: sticky;
|
||||
top: 0;
|
||||
z-index: 100;
|
||||
}
|
||||
.header .header-content {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
}
|
||||
.header .logo {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
font-size: 1.5rem;
|
||||
font-weight: bold;
|
||||
color: #00ff00;
|
||||
}
|
||||
.header .logo .omega {
|
||||
font-size: 2rem;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.header .nav-toggle {
|
||||
display: none;
|
||||
background: none;
|
||||
border: none;
|
||||
color: #ffffff;
|
||||
font-size: 1.5rem;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
.main-layout {
|
||||
display: flex;
|
||||
min-height: calc(100vh - 80px);
|
||||
}
|
||||
|
||||
.sidebar {
|
||||
width: 300px;
|
||||
background-color: #0d0d0d;
|
||||
border-right: 1px solid #333333;
|
||||
padding: 2rem 1rem;
|
||||
overflow-y: auto;
|
||||
position: sticky;
|
||||
top: 80px;
|
||||
height: calc(100vh - 80px);
|
||||
}
|
||||
.sidebar .nav-section {
|
||||
margin-bottom: 2rem;
|
||||
}
|
||||
.sidebar .nav-section h3 {
|
||||
color: #00ff00;
|
||||
font-size: 1rem;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 1px;
|
||||
}
|
||||
.sidebar .nav-section ul {
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
}
|
||||
.sidebar .nav-section ul li {
|
||||
margin-bottom: 0.25rem;
|
||||
}
|
||||
.sidebar .nav-section ul li a {
|
||||
display: block;
|
||||
padding: 0.5rem;
|
||||
border-radius: 3px;
|
||||
transition: background-color 0.3s ease;
|
||||
}
|
||||
.sidebar .nav-section ul li a:hover {
|
||||
background-color: #333333;
|
||||
text-decoration: none;
|
||||
}
|
||||
.sidebar .nav-section ul li a.active {
|
||||
background-color: #0066ff;
|
||||
color: #000000;
|
||||
}
|
||||
.sidebar .nav-section ul li ul {
|
||||
margin-left: 1rem;
|
||||
margin-top: 0.5rem;
|
||||
}
|
||||
.sidebar .nav-section ul li ul a {
|
||||
font-size: 0.9rem;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.content {
|
||||
flex: 1;
|
||||
padding: 2rem;
|
||||
max-width: calc(100% - 300px);
|
||||
}
|
||||
.content .content-header {
|
||||
margin-bottom: 2rem;
|
||||
padding-bottom: 1rem;
|
||||
border-bottom: 1px solid #333333;
|
||||
}
|
||||
.content .content-header .manual-designation {
|
||||
color: #00ff00;
|
||||
font-size: 0.9rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 1px;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
.content .content-header .classification {
|
||||
color: #ffaa00;
|
||||
font-size: 0.8rem;
|
||||
text-transform: uppercase;
|
||||
font-weight: bold;
|
||||
}
|
||||
.content .section-nav {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
margin-top: 3rem;
|
||||
padding-top: 2rem;
|
||||
border-top: 1px solid #333333;
|
||||
}
|
||||
.content .section-nav .nav-link {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: 0.75rem 1.5rem;
|
||||
background-color: #1a1a1a;
|
||||
border: 1px solid #333333;
|
||||
border-radius: 5px;
|
||||
transition: all 0.3s ease;
|
||||
}
|
||||
.content .section-nav .nav-link:hover {
|
||||
background-color: #0066ff;
|
||||
color: #000000;
|
||||
text-decoration: none;
|
||||
}
|
||||
.content .section-nav .nav-link .arrow {
|
||||
font-size: 1.2rem;
|
||||
margin: 0 0.5rem;
|
||||
}
|
||||
|
||||
.warning-box {
|
||||
background-color: rgba(255, 170, 0, 0.1);
|
||||
border-left: 4px solid #ffaa00;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
}
|
||||
.warning-box .warning-title {
|
||||
color: #ffaa00;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
.info-box {
|
||||
background-color: rgba(0, 102, 255, 0.1);
|
||||
border-left: 4px solid #0066ff;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
}
|
||||
.info-box .info-title {
|
||||
color: #0066ff;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
.success-box {
|
||||
background-color: rgba(0, 255, 0, 0.1);
|
||||
border-left: 4px solid #00ff00;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
}
|
||||
.success-box .success-title {
|
||||
color: #00ff00;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
.do-dont-list {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 1rem;
|
||||
margin: 1rem 0;
|
||||
}
|
||||
.do-dont-list .do-list, .do-dont-list .dont-list {
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
}
|
||||
.do-dont-list .do-list h4, .do-dont-list .dont-list h4 {
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
.do-dont-list .do-list ul, .do-dont-list .dont-list ul {
|
||||
margin: 0;
|
||||
padding-left: 1.5rem;
|
||||
}
|
||||
.do-dont-list .do-list {
|
||||
background-color: rgba(0, 255, 0, 0.1);
|
||||
border: 1px solid #00ff00;
|
||||
}
|
||||
.do-dont-list .do-list h4 {
|
||||
color: #00ff00;
|
||||
}
|
||||
.do-dont-list .dont-list {
|
||||
background-color: rgba(255, 0, 0, 0.1);
|
||||
border: 1px solid #ff0000;
|
||||
}
|
||||
.do-dont-list .dont-list h4 {
|
||||
color: #ff0000;
|
||||
}
|
||||
|
||||
.footer {
|
||||
background-color: #333333;
|
||||
padding: 2rem 0;
|
||||
margin-top: 4rem;
|
||||
text-align: center;
|
||||
border-top: 2px solid #00ff00;
|
||||
}
|
||||
.footer .footer-content {
|
||||
color: white;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
.footer .footer-content .organization {
|
||||
color: #00ff00;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
@media (max-width: 768px) {
|
||||
.header .nav-toggle {
|
||||
display: block;
|
||||
}
|
||||
.main-layout {
|
||||
flex-direction: column;
|
||||
}
|
||||
.sidebar {
|
||||
width: 100%;
|
||||
position: static;
|
||||
height: auto;
|
||||
display: none;
|
||||
}
|
||||
.sidebar.active {
|
||||
display: block;
|
||||
}
|
||||
.content {
|
||||
max-width: 100%;
|
||||
padding: 1rem;
|
||||
}
|
||||
.do-dont-list {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
}
|
||||
@media print {
|
||||
body {
|
||||
background: white;
|
||||
color: black;
|
||||
}
|
||||
.header, .sidebar, .footer, .section-nav {
|
||||
display: none;
|
||||
}
|
||||
.content {
|
||||
max-width: 100%;
|
||||
padding: 0;
|
||||
}
|
||||
a {
|
||||
color: black;
|
||||
text-decoration: underline;
|
||||
}
|
||||
}
|
||||
|
||||
/*# sourceMappingURL=main.css.map */
|
1
_site/assets/css/main.css.map
Normal file
1
_site/assets/css/main.css.map
Normal file
File diff suppressed because one or more lines are too long
166
_site/assets/js/main.js
Normal file
166
_site/assets/js/main.js
Normal file
|
@ -0,0 +1,166 @@
|
|||
// Field Guide for Subversives - Main JavaScript
|
||||
|
||||
document.addEventListener('DOMContentLoaded', function() {
|
||||
// Mobile navigation toggle
|
||||
const navToggle = document.getElementById('nav-toggle');
|
||||
const sidebar = document.getElementById('sidebar');
|
||||
|
||||
if (navToggle && sidebar) {
|
||||
navToggle.addEventListener('click', function() {
|
||||
sidebar.classList.toggle('active');
|
||||
});
|
||||
}
|
||||
|
||||
// Smooth scrolling for anchor links
|
||||
const anchorLinks = document.querySelectorAll('a[href^="#"]');
|
||||
anchorLinks.forEach(link => {
|
||||
link.addEventListener('click', function(e) {
|
||||
e.preventDefault();
|
||||
const target = document.querySelector(this.getAttribute('href'));
|
||||
if (target) {
|
||||
target.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
});
|
||||
}
|
||||
});
|
||||
});
|
||||
|
||||
// Add security warning for external links
|
||||
const externalLinks = document.querySelectorAll('a[href^="http"]:not([href*="' + window.location.hostname + '"])');
|
||||
externalLinks.forEach(link => {
|
||||
link.addEventListener('click', function(e) {
|
||||
if (!confirm('You are about to visit an external site. Ensure you are using secure browsing practices. Continue?')) {
|
||||
e.preventDefault();
|
||||
}
|
||||
});
|
||||
|
||||
// Add visual indicator for external links
|
||||
link.setAttribute('title', 'External link - opens in new tab');
|
||||
link.setAttribute('target', '_blank');
|
||||
link.setAttribute('rel', 'noopener noreferrer');
|
||||
});
|
||||
|
||||
// Keyboard navigation
|
||||
document.addEventListener('keydown', function(e) {
|
||||
// Alt + Left Arrow: Previous page
|
||||
if (e.altKey && e.key === 'ArrowLeft') {
|
||||
const prevLink = document.querySelector('.section-nav .nav-link:first-child');
|
||||
if (prevLink && prevLink.href) {
|
||||
window.location.href = prevLink.href;
|
||||
}
|
||||
}
|
||||
|
||||
// Alt + Right Arrow: Next page
|
||||
if (e.altKey && e.key === 'ArrowRight') {
|
||||
const nextLink = document.querySelector('.section-nav .nav-link:last-child');
|
||||
if (nextLink && nextLink.href) {
|
||||
window.location.href = nextLink.href;
|
||||
}
|
||||
}
|
||||
|
||||
// Escape: Close mobile menu
|
||||
if (e.key === 'Escape' && sidebar && sidebar.classList.contains('active')) {
|
||||
sidebar.classList.remove('active');
|
||||
}
|
||||
});
|
||||
|
||||
// Print functionality
|
||||
function addPrintButton() {
|
||||
const contentHeader = document.querySelector('.content-header');
|
||||
if (contentHeader) {
|
||||
const printButton = document.createElement('button');
|
||||
printButton.textContent = 'Print Section';
|
||||
printButton.className = 'print-button';
|
||||
printButton.style.cssText = `
|
||||
background: #333;
|
||||
color: #00ff00;
|
||||
border: 1px solid #00ff00;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 3px;
|
||||
cursor: pointer;
|
||||
font-family: inherit;
|
||||
margin-top: 1rem;
|
||||
`;
|
||||
printButton.addEventListener('click', function() {
|
||||
window.print();
|
||||
});
|
||||
contentHeader.appendChild(printButton);
|
||||
}
|
||||
}
|
||||
|
||||
addPrintButton();
|
||||
|
||||
// Security reminder
|
||||
function showSecurityReminder() {
|
||||
const reminder = document.createElement('div');
|
||||
reminder.style.cssText = `
|
||||
position: fixed;
|
||||
bottom: 20px;
|
||||
right: 20px;
|
||||
background: rgba(255, 170, 0, 0.9);
|
||||
color: #000;
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
max-width: 300px;
|
||||
font-size: 0.9rem;
|
||||
z-index: 1000;
|
||||
display: none;
|
||||
`;
|
||||
reminder.innerHTML = `
|
||||
<strong>Security Reminder:</strong> Ensure you're using Tails OS or a secure browser when accessing this guide.
|
||||
<button onclick="this.parentElement.style.display='none'" style="float: right; background: none; border: none; font-size: 1.2rem; cursor: pointer;">×</button>
|
||||
`;
|
||||
document.body.appendChild(reminder);
|
||||
|
||||
// Show reminder after 30 seconds
|
||||
setTimeout(() => {
|
||||
reminder.style.display = 'block';
|
||||
}, 30000);
|
||||
|
||||
// Auto-hide after 10 seconds
|
||||
setTimeout(() => {
|
||||
reminder.style.display = 'none';
|
||||
}, 40000);
|
||||
}
|
||||
|
||||
// Only show security reminder on first visit
|
||||
if (!localStorage.getItem('security_reminder_shown')) {
|
||||
showSecurityReminder();
|
||||
localStorage.setItem('security_reminder_shown', 'true');
|
||||
}
|
||||
|
||||
// Add copy-to-clipboard functionality for code blocks
|
||||
const codeBlocks = document.querySelectorAll('pre code');
|
||||
codeBlocks.forEach(block => {
|
||||
const button = document.createElement('button');
|
||||
button.textContent = 'Copy';
|
||||
button.className = 'copy-button';
|
||||
button.style.cssText = `
|
||||
position: absolute;
|
||||
top: 0.5rem;
|
||||
right: 0.5rem;
|
||||
background: #333;
|
||||
color: #00ff00;
|
||||
border: 1px solid #00ff00;
|
||||
padding: 0.25rem 0.5rem;
|
||||
border-radius: 3px;
|
||||
cursor: pointer;
|
||||
font-size: 0.8rem;
|
||||
`;
|
||||
|
||||
const pre = block.parentElement;
|
||||
pre.style.position = 'relative';
|
||||
pre.appendChild(button);
|
||||
|
||||
button.addEventListener('click', function() {
|
||||
navigator.clipboard.writeText(block.textContent).then(() => {
|
||||
button.textContent = 'Copied!';
|
||||
setTimeout(() => {
|
||||
button.textContent = 'Copy';
|
||||
}, 2000);
|
||||
});
|
||||
});
|
||||
});
|
||||
});
|
||||
|
716
_site/chapters/chapter-1/index.html
Normal file
716
_site/chapters/chapter-1/index.html
Normal file
|
@ -0,0 +1,716 @@
|
|||
<!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">
|
||||
</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">
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
971
_site/chapters/chapter-2/index.html
Normal file
971
_site/chapters/chapter-2/index.html
Normal file
|
@ -0,0 +1,971 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Chapter 2: Threat Assessment and Operational Environment - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Systematic approaches to understanding and responding to threats in resistance operations">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<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>
|
||||
|
||||
<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/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" class="active">Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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 2-1 to 2-4</div>
|
||||
|
||||
</div>
|
||||
|
||||
<h1 id="chapter-2-threat-assessment-and-operational-environment">Chapter 2: Threat Assessment and Operational Environment</h1>
|
||||
|
||||
<h2 id="chapter-overview">Chapter Overview</h2>
|
||||
|
||||
<p>This chapter provides systematic methodologies for understanding and responding to threats in resistance operations. Effective threat assessment is the foundation of all security planning, enabling resistance practitioners to allocate resources appropriately and design countermeasures that address actual rather than imagined risks.</p>
|
||||
|
||||
<p><strong>Sections in this chapter:</strong></p>
|
||||
<ul>
|
||||
<li>2-1: Understanding Your Adversary</li>
|
||||
<li>2-2: Threat Model Development</li>
|
||||
<li>2-3: Risk Assessment Framework</li>
|
||||
<li>2-4: Operational Security (OpSec) Fundamentals</li>
|
||||
</ul>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="section-2-1-understanding-your-adversary">Section 2-1: Understanding Your Adversary</h2>
|
||||
|
||||
<h3 id="definition">Definition</h3>
|
||||
|
||||
<p>Adversary analysis is the systematic study of hostile forces to understand their capabilities, motivations, limitations, and likely courses of action. In resistance operations, this analysis must encompass both state and non-state actors who pose threats to operational security and participant safety.</p>
|
||||
|
||||
<h3 id="adversary-categories">Adversary Categories</h3>
|
||||
|
||||
<h4 id="state-security-services">State Security Services</h4>
|
||||
<p><strong>Capabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Mass surveillance infrastructure and legal authorities</li>
|
||||
<li>Advanced technical capabilities including cyber operations</li>
|
||||
<li>Extensive human intelligence networks and informant recruitment</li>
|
||||
<li>Legal powers including arrest, detention, and asset seizure</li>
|
||||
<li>International cooperation and intelligence sharing agreements</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Motivations:</strong></p>
|
||||
<ul>
|
||||
<li>Maintaining regime stability and suppressing dissent</li>
|
||||
<li>Protecting state secrets and critical infrastructure</li>
|
||||
<li>Demonstrating effectiveness to political leadership</li>
|
||||
<li>Career advancement and institutional prestige</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Limitations:</strong></p>
|
||||
<ul>
|
||||
<li>Bureaucratic constraints and inter-agency competition</li>
|
||||
<li>Resource limitations and competing priorities</li>
|
||||
<li>Legal and political constraints (even in authoritarian systems)</li>
|
||||
<li>Technical limitations and skill gaps</li>
|
||||
<li>Public scrutiny and accountability mechanisms</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="law-enforcement-agencies">Law Enforcement Agencies</h4>
|
||||
<p><strong>Capabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Local surveillance and investigation resources</li>
|
||||
<li>Access to criminal justice system and prosecution powers</li>
|
||||
<li>Community informant networks and public cooperation</li>
|
||||
<li>Specialized units for cybercrime and domestic terrorism</li>
|
||||
<li>Coordination with federal and international agencies</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Motivations:</strong></p>
|
||||
<ul>
|
||||
<li>Enforcing existing laws and maintaining public order</li>
|
||||
<li>Responding to political pressure and public concerns</li>
|
||||
<li>Protecting institutional reputation and effectiveness</li>
|
||||
<li>Career advancement and performance metrics</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Limitations:</strong></p>
|
||||
<ul>
|
||||
<li>Legal constraints and constitutional protections</li>
|
||||
<li>Resource limitations and competing priorities</li>
|
||||
<li>Training gaps in technical and political areas</li>
|
||||
<li>Public accountability and oversight mechanisms</li>
|
||||
<li>Jurisdictional limitations and coordination challenges</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="private-intelligence-contractors">Private Intelligence Contractors</h4>
|
||||
<p><strong>Capabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Specialized technical capabilities and cutting-edge tools</li>
|
||||
<li>Flexibility and rapid response capabilities</li>
|
||||
<li>Access to commercial data sources and partnerships</li>
|
||||
<li>International operations with minimal oversight</li>
|
||||
<li>Experienced personnel recruited from government agencies</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Motivations:</strong></p>
|
||||
<ul>
|
||||
<li>Financial profit and contract renewal</li>
|
||||
<li>Demonstrating value to government and corporate clients</li>
|
||||
<li>Expanding market share and capabilities</li>
|
||||
<li>Maintaining competitive advantage</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Limitations:</strong></p>
|
||||
<ul>
|
||||
<li>Profit motive may conflict with thoroughness</li>
|
||||
<li>Limited legal authorities and powers</li>
|
||||
<li>Dependence on client relationships and contracts</li>
|
||||
<li>Potential for exposure and public scrutiny</li>
|
||||
<li>Competition with other contractors and agencies</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="hostile-political-organizations">Hostile Political Organizations</h4>
|
||||
<p><strong>Capabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Grassroots networks and community presence</li>
|
||||
<li>Media access and propaganda capabilities</li>
|
||||
<li>Political influence and institutional connections</li>
|
||||
<li>Volunteer networks and ideological motivation</li>
|
||||
<li>Potential for violence and intimidation</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Motivations:</strong></p>
|
||||
<ul>
|
||||
<li>Advancing political ideology and agenda</li>
|
||||
<li>Suppressing opposition movements and activities</li>
|
||||
<li>Demonstrating power and influence</li>
|
||||
<li>Protecting organizational interests and reputation</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Limitations:</strong></p>
|
||||
<ul>
|
||||
<li>Limited resources compared to state actors</li>
|
||||
<li>Legal constraints and public scrutiny</li>
|
||||
<li>Internal divisions and competing priorities</li>
|
||||
<li>Dependence on volunteer networks and public support</li>
|
||||
<li>Vulnerability to infiltration and disruption</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="capability-assessment-framework">Capability Assessment Framework</h3>
|
||||
|
||||
<h4 id="technical-capabilities">Technical Capabilities</h4>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Assessment Matrix:
|
||||
1. Surveillance Infrastructure
|
||||
- Mass data collection capabilities
|
||||
- Real-time monitoring systems
|
||||
- Data analysis and correlation tools
|
||||
- International cooperation agreements
|
||||
|
||||
2. Cyber Operations
|
||||
- Offensive cyber capabilities
|
||||
- Defensive monitoring systems
|
||||
- Technical expertise and resources
|
||||
- Legal authorities and constraints
|
||||
|
||||
3. Human Intelligence
|
||||
- Informant recruitment and management
|
||||
- Infiltration capabilities
|
||||
- Social engineering expertise
|
||||
- Community presence and influence
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="operational-capabilities">Operational Capabilities</h4>
|
||||
<ul>
|
||||
<li><strong>Geographic reach</strong> and jurisdictional authority</li>
|
||||
<li><strong>Response time</strong> and deployment capabilities</li>
|
||||
<li><strong>Coordination mechanisms</strong> between different agencies</li>
|
||||
<li><strong>Resource allocation</strong> and priority setting processes</li>
|
||||
<li><strong>Legal authorities</strong> and operational constraints</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="intelligence-capabilities">Intelligence Capabilities</h4>
|
||||
<ul>
|
||||
<li><strong>Collection methods</strong> and information sources</li>
|
||||
<li><strong>Analysis capabilities</strong> and expertise levels</li>
|
||||
<li><strong>Dissemination networks</strong> and information sharing</li>
|
||||
<li><strong>Retention policies</strong> and data management systems</li>
|
||||
<li><strong>Quality control</strong> and verification processes</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="motivation-analysis">Motivation Analysis</h3>
|
||||
|
||||
<h4 id="primary-motivations">Primary Motivations</h4>
|
||||
<p>Understanding what drives adversary actions helps predict their behavior and identify potential vulnerabilities:</p>
|
||||
|
||||
<p><strong>Institutional Interests:</strong></p>
|
||||
<ul>
|
||||
<li>Organizational survival and growth</li>
|
||||
<li>Budget allocation and resource competition</li>
|
||||
<li>Performance metrics and success measures</li>
|
||||
<li>Reputation and public perception</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Individual Motivations:</strong></p>
|
||||
<ul>
|
||||
<li>Career advancement and professional recognition</li>
|
||||
<li>Financial incentives and job security</li>
|
||||
<li>Ideological commitment and personal beliefs</li>
|
||||
<li>Social pressure and peer expectations</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Political Factors:</strong></p>
|
||||
<ul>
|
||||
<li>Electoral considerations and public opinion</li>
|
||||
<li>Policy priorities and resource allocation</li>
|
||||
<li>International relationships and obligations</li>
|
||||
<li>Crisis response and emergency authorities</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="limitation-assessment">Limitation Assessment</h3>
|
||||
|
||||
<h4 id="resource-constraints">Resource Constraints</h4>
|
||||
<ul>
|
||||
<li><strong>Budget limitations</strong> and competing priorities</li>
|
||||
<li><strong>Personnel shortages</strong> and skill gaps</li>
|
||||
<li><strong>Technical limitations</strong> and equipment constraints</li>
|
||||
<li><strong>Time pressures</strong> and operational demands</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="legal-and-political-constraints">Legal and Political Constraints</h4>
|
||||
<ul>
|
||||
<li><strong>Constitutional protections</strong> and legal precedents</li>
|
||||
<li><strong>Oversight mechanisms</strong> and accountability requirements</li>
|
||||
<li><strong>Public scrutiny</strong> and media attention</li>
|
||||
<li><strong>Political considerations</strong> and policy constraints</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="operational-constraints">Operational Constraints</h4>
|
||||
<ul>
|
||||
<li><strong>Bureaucratic processes</strong> and approval requirements</li>
|
||||
<li><strong>Coordination challenges</strong> between agencies</li>
|
||||
<li><strong>Information sharing</strong> limitations and restrictions</li>
|
||||
<li><strong>Geographic limitations</strong> and jurisdictional boundaries</li>
|
||||
</ul>
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Intelligence Gathering</div>
|
||||
<p>Adversary analysis requires ongoing intelligence collection through open sources, operational observation, and network reporting. This information must be systematically collected, analyzed, and updated to maintain accuracy and relevance.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="section-2-2-threat-model-development">Section 2-2: Threat Model Development</h2>
|
||||
|
||||
<h3 id="definition-1">Definition</h3>
|
||||
|
||||
<p>A threat model is a structured representation of potential threats to an organization, operation, or individual, including the assets being protected, potential attackers, attack vectors, and consequences of successful attacks. Threat modeling provides the analytical foundation for security planning and resource allocation.</p>
|
||||
|
||||
<h3 id="threat-modeling-process">Threat Modeling Process</h3>
|
||||
|
||||
<h4 id="step-1-asset-identification">Step 1: Asset Identification</h4>
|
||||
<p><strong>Information Assets:</strong></p>
|
||||
<ul>
|
||||
<li>Operational plans and strategic documents</li>
|
||||
<li>Communication records and contact information</li>
|
||||
<li>Financial records and resource information</li>
|
||||
<li>Technical documentation and system configurations</li>
|
||||
<li>Personal information about participants and supporters</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Physical Assets:</strong></p>
|
||||
<ul>
|
||||
<li>Personnel safety and freedom</li>
|
||||
<li>Equipment and technology resources</li>
|
||||
<li>Financial resources and funding sources</li>
|
||||
<li>Safe houses and meeting locations</li>
|
||||
<li>Communication infrastructure and networks</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Operational Assets:</strong></p>
|
||||
<ul>
|
||||
<li>Network relationships and trust connections</li>
|
||||
<li>Operational capabilities and expertise</li>
|
||||
<li>Reputation and public support</li>
|
||||
<li>Legal protections and political cover</li>
|
||||
<li>Time and opportunity windows</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-2-threat-actor-identification">Step 2: Threat Actor Identification</h4>
|
||||
<p>For each asset category, identify potential threat actors:</p>
|
||||
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Threat Actor Analysis Template:
|
||||
Actor: [Name/Type]
|
||||
Motivation: [Why they would target this asset]
|
||||
Capability: [What they can do to compromise it]
|
||||
Opportunity: [When/how they could act]
|
||||
Impact: [Consequences of successful attack]
|
||||
Likelihood: [Probability assessment]
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="step-3-attack-vector-analysis">Step 3: Attack Vector Analysis</h4>
|
||||
<p><strong>Technical Attack Vectors:</strong></p>
|
||||
<ul>
|
||||
<li>Network intrusion and system compromise</li>
|
||||
<li>Communication interception and analysis</li>
|
||||
<li>Device compromise and malware deployment</li>
|
||||
<li>Data theft and information exfiltration</li>
|
||||
<li>Service disruption and denial of service</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Human Attack Vectors:</strong></p>
|
||||
<ul>
|
||||
<li>Social engineering and manipulation</li>
|
||||
<li>Infiltration and insider threats</li>
|
||||
<li>Coercion and blackmail</li>
|
||||
<li>Recruitment and turning of participants</li>
|
||||
<li>Information gathering through relationships</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Physical Attack Vectors:</strong></p>
|
||||
<ul>
|
||||
<li>Surveillance and tracking</li>
|
||||
<li>Search and seizure operations</li>
|
||||
<li>Physical intimidation and violence</li>
|
||||
<li>Asset seizure and resource disruption</li>
|
||||
<li>Location compromise and raid operations</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-4-impact-assessment">Step 4: Impact Assessment</h4>
|
||||
<p><strong>Immediate Impacts:</strong></p>
|
||||
<ul>
|
||||
<li>Operational disruption and mission failure</li>
|
||||
<li>Personnel safety and security compromise</li>
|
||||
<li>Resource loss and financial damage</li>
|
||||
<li>Information disclosure and intelligence loss</li>
|
||||
<li>Legal consequences and prosecution</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Long-term Impacts:</strong></p>
|
||||
<ul>
|
||||
<li>Network compromise and relationship damage</li>
|
||||
<li>Reputation loss and public support erosion</li>
|
||||
<li>Capability degradation and skill loss</li>
|
||||
<li>Strategic disadvantage and position weakness</li>
|
||||
<li>Movement suppression and broader impact</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="threat-modeling-methodologies">Threat Modeling Methodologies</h3>
|
||||
|
||||
<h4 id="stride-framework">STRIDE Framework</h4>
|
||||
<p><strong>Spoofing:</strong> Impersonating legitimate users or systems
|
||||
<strong>Tampering:</strong> Modifying data or systems without authorization
|
||||
<strong>Repudiation:</strong> Denying actions or transactions
|
||||
<strong>Information Disclosure:</strong> Exposing sensitive information
|
||||
<strong>Denial of Service:</strong> Preventing legitimate access to resources
|
||||
<strong>Elevation of Privilege:</strong> Gaining unauthorized access or permissions</p>
|
||||
|
||||
<h4 id="pasta-process-for-attack-simulation-and-threat-analysis">PASTA (Process for Attack Simulation and Threat Analysis)</h4>
|
||||
<ol>
|
||||
<li><strong>Define Objectives:</strong> Establish scope and goals</li>
|
||||
<li><strong>Define Technical Scope:</strong> Identify systems and components</li>
|
||||
<li><strong>Application Decomposition:</strong> Break down into components</li>
|
||||
<li><strong>Threat Analysis:</strong> Identify potential threats</li>
|
||||
<li><strong>Weakness and Vulnerability Analysis:</strong> Find security gaps</li>
|
||||
<li><strong>Attack Modeling:</strong> Simulate attack scenarios</li>
|
||||
<li><strong>Risk and Impact Analysis:</strong> Assess consequences</li>
|
||||
</ol>
|
||||
|
||||
<h4 id="octave-operationally-critical-threat-asset-and-vulnerability-evaluation">OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)</h4>
|
||||
<ul>
|
||||
<li><strong>Organizational View:</strong> Internal security practices and policies</li>
|
||||
<li><strong>Technological View:</strong> Technical vulnerabilities and weaknesses</li>
|
||||
<li><strong>Strategy and Plan View:</strong> Risk mitigation and security strategy</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="threat-scenario-development">Threat Scenario Development</h3>
|
||||
|
||||
<h4 id="scenario-template">Scenario Template</h4>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Threat Scenario: [Descriptive Name]
|
||||
|
||||
Background:
|
||||
- Current operational context
|
||||
- Recent events and triggers
|
||||
- Adversary capabilities and motivations
|
||||
|
||||
Attack Sequence:
|
||||
1. Initial access or opportunity
|
||||
2. Escalation and exploitation
|
||||
3. Impact and consequences
|
||||
4. Potential responses and countermeasures
|
||||
|
||||
Indicators:
|
||||
- Early warning signs
|
||||
- Detection opportunities
|
||||
- Confirmation methods
|
||||
|
||||
Mitigation:
|
||||
- Preventive measures
|
||||
- Response procedures
|
||||
- Recovery plans
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="example-scenarios">Example Scenarios</h4>
|
||||
|
||||
<p><strong>Scenario 1: Communication Compromise</strong></p>
|
||||
<ul>
|
||||
<li>Adversary intercepts encrypted communications</li>
|
||||
<li>Traffic analysis reveals network structure</li>
|
||||
<li>Key participants identified and targeted</li>
|
||||
<li>Operational plans exposed and disrupted</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Scenario 2: Infiltration Operation</strong></p>
|
||||
<ul>
|
||||
<li>Hostile agent joins resistance network</li>
|
||||
<li>Gains trust and access over time</li>
|
||||
<li>Collects intelligence on operations and participants</li>
|
||||
<li>Provides information for coordinated arrests</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Scenario 3: Technical Surveillance</strong></p>
|
||||
<ul>
|
||||
<li>Mass surveillance system deployed</li>
|
||||
<li>Communication metadata collected and analyzed</li>
|
||||
<li>Behavioral patterns identified and tracked</li>
|
||||
<li>Predictive analysis enables preemptive action</li>
|
||||
</ul>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Scenario Planning</div>
|
||||
<p>Threat scenarios should be realistic and based on actual adversary capabilities and historical precedents. Avoid both underestimating threats (leading to inadequate security) and overestimating them (leading to paralysis and ineffective operations).</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="section-2-3-risk-assessment-framework">Section 2-3: Risk Assessment Framework</h2>
|
||||
|
||||
<h3 id="definition-2">Definition</h3>
|
||||
|
||||
<p>Risk assessment is the systematic evaluation of potential threats to determine their likelihood and impact, enabling informed decisions about security investments and operational procedures. Risk assessment translates threat models into actionable priorities for security planning.</p>
|
||||
|
||||
<h3 id="risk-calculation-methodology">Risk Calculation Methodology</h3>
|
||||
|
||||
<h4 id="basic-risk-formula">Basic Risk Formula</h4>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Risk = Threat × Vulnerability × Impact
|
||||
|
||||
Where:
|
||||
- Threat = Likelihood of attack occurring
|
||||
- Vulnerability = Probability of attack succeeding
|
||||
- Impact = Consequences of successful attack
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="qualitative-risk-assessment">Qualitative Risk Assessment</h4>
|
||||
<p><strong>Likelihood Scale:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Very High (5):</strong> Almost certain to occur within 1 month</li>
|
||||
<li><strong>High (4):</strong> Likely to occur within 6 months</li>
|
||||
<li><strong>Medium (3):</strong> Possible within 1 year</li>
|
||||
<li><strong>Low (2):</strong> Unlikely within 2 years</li>
|
||||
<li><strong>Very Low (1):</strong> Rare or theoretical</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Impact Scale:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Critical (5):</strong> Mission failure, life-threatening consequences</li>
|
||||
<li><strong>High (4):</strong> Major operational disruption, serious legal consequences</li>
|
||||
<li><strong>Medium (3):</strong> Moderate disruption, manageable consequences</li>
|
||||
<li><strong>Low (2):</strong> Minor inconvenience, limited impact</li>
|
||||
<li><strong>Very Low (1):</strong> Negligible impact</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Risk Matrix:</strong></p>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Impact → VL L M H C
|
||||
Likelihood ↓
|
||||
Very High M H H C C
|
||||
High L M H H C
|
||||
Medium L L M H H
|
||||
Low VL L L M H
|
||||
Very Low VL VL L L M
|
||||
|
||||
Legend: VL=Very Low, L=Low, M=Medium, H=High, C=Critical
|
||||
</code></pre></div></div>
|
||||
|
||||
<h3 id="risk-assessment-process">Risk Assessment Process</h3>
|
||||
|
||||
<h4 id="step-1-threat-inventory">Step 1: Threat Inventory</h4>
|
||||
<p>Create comprehensive list of identified threats from threat modeling process:</p>
|
||||
<ul>
|
||||
<li>Categorize by threat actor and attack vector</li>
|
||||
<li>Document current intelligence and evidence</li>
|
||||
<li>Assess threat actor capabilities and motivations</li>
|
||||
<li>Identify information gaps and uncertainties</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-2-vulnerability-assessment">Step 2: Vulnerability Assessment</h4>
|
||||
<p>For each threat, assess organizational vulnerabilities:</p>
|
||||
|
||||
<p><strong>Technical Vulnerabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Unpatched software and system weaknesses</li>
|
||||
<li>Insecure configurations and default settings</li>
|
||||
<li>Weak encryption and authentication mechanisms</li>
|
||||
<li>Inadequate monitoring and detection capabilities</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Procedural Vulnerabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Inadequate security policies and procedures</li>
|
||||
<li>Insufficient training and awareness programs</li>
|
||||
<li>Poor access control and permission management</li>
|
||||
<li>Weak incident response and recovery capabilities</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Human Vulnerabilities:</strong></p>
|
||||
<ul>
|
||||
<li>Social engineering susceptibility</li>
|
||||
<li>Insider threat potential</li>
|
||||
<li>Security culture weaknesses</li>
|
||||
<li>Stress and pressure responses</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-3-impact-analysis">Step 3: Impact Analysis</h4>
|
||||
<p>Assess potential consequences of successful attacks:</p>
|
||||
|
||||
<p><strong>Operational Impact:</strong></p>
|
||||
<ul>
|
||||
<li>Mission disruption and failure</li>
|
||||
<li>Capability loss and degradation</li>
|
||||
<li>Resource depletion and damage</li>
|
||||
<li>Timeline delays and setbacks</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Security Impact:</strong></p>
|
||||
<ul>
|
||||
<li>Personnel safety and freedom</li>
|
||||
<li>Information disclosure and intelligence loss</li>
|
||||
<li>Network compromise and relationship damage</li>
|
||||
<li>Legal consequences and prosecution</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Strategic Impact:</strong></p>
|
||||
<ul>
|
||||
<li>Movement effectiveness and credibility</li>
|
||||
<li>Public support and political position</li>
|
||||
<li>Long-term viability and sustainability</li>
|
||||
<li>Broader resistance movement impact</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-4-risk-prioritization">Step 4: Risk Prioritization</h4>
|
||||
<p>Rank risks based on calculated scores and strategic importance:</p>
|
||||
|
||||
<p><strong>Priority Categories:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Critical Risks:</strong> Immediate attention required</li>
|
||||
<li><strong>High Risks:</strong> Address within 30 days</li>
|
||||
<li><strong>Medium Risks:</strong> Address within 90 days</li>
|
||||
<li><strong>Low Risks:</strong> Address as resources permit</li>
|
||||
<li><strong>Accepted Risks:</strong> Monitor but no immediate action</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="risk-treatment-strategies">Risk Treatment Strategies</h3>
|
||||
|
||||
<h4 id="risk-mitigation">Risk Mitigation</h4>
|
||||
<p>Reduce likelihood or impact through security controls:</p>
|
||||
<ul>
|
||||
<li><strong>Preventive Controls:</strong> Block or deter attacks</li>
|
||||
<li><strong>Detective Controls:</strong> Identify attacks in progress</li>
|
||||
<li><strong>Corrective Controls:</strong> Respond to and recover from attacks</li>
|
||||
<li><strong>Compensating Controls:</strong> Alternative measures when primary controls fail</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="risk-transfer">Risk Transfer</h4>
|
||||
<p>Shift risk to other parties or systems:</p>
|
||||
<ul>
|
||||
<li><strong>Insurance:</strong> Financial protection against losses</li>
|
||||
<li><strong>Outsourcing:</strong> Transfer operational risks to service providers</li>
|
||||
<li><strong>Partnerships:</strong> Share risks with allied organizations</li>
|
||||
<li><strong>Legal Protections:</strong> Use legal mechanisms to limit exposure</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="risk-acceptance">Risk Acceptance</h4>
|
||||
<p>Consciously accept certain risks:</p>
|
||||
<ul>
|
||||
<li><strong>Residual Risk:</strong> Remaining risk after mitigation measures</li>
|
||||
<li><strong>Strategic Risk:</strong> Risks necessary for mission accomplishment</li>
|
||||
<li><strong>Resource Constraints:</strong> Risks that cannot be addressed with available resources</li>
|
||||
<li><strong>Temporary Acceptance:</strong> Short-term acceptance pending future mitigation</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="risk-avoidance">Risk Avoidance</h4>
|
||||
<p>Eliminate risk by avoiding the activity:</p>
|
||||
<ul>
|
||||
<li><strong>Operational Changes:</strong> Modify operations to eliminate risk</li>
|
||||
<li><strong>Technology Alternatives:</strong> Use different tools or methods</li>
|
||||
<li><strong>Geographic Relocation:</strong> Move operations to safer locations</li>
|
||||
<li><strong>Timing Adjustments:</strong> Delay operations until risks decrease</li>
|
||||
</ul>
|
||||
|
||||
<div class="success-box">
|
||||
<div class="success-title">Risk Management</div>
|
||||
<p>Effective risk management is an ongoing process that requires regular review and updates. Risk assessments should be updated whenever significant changes occur in the threat environment, organizational capabilities, or operational requirements.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="section-2-4-operational-security-opsec-fundamentals">Section 2-4: Operational Security (OpSec) Fundamentals</h2>
|
||||
|
||||
<h3 id="definition-3">Definition</h3>
|
||||
|
||||
<p>Operational Security (OpSec) is the process of protecting critical information and activities from adversary intelligence collection and analysis. OpSec focuses on identifying and controlling information that could be used to compromise operations, rather than just protecting classified information.</p>
|
||||
|
||||
<h3 id="opsec-process">OpSec Process</h3>
|
||||
|
||||
<h4 id="step-1-identify-critical-information">Step 1: Identify Critical Information</h4>
|
||||
<p><strong>Critical Information Categories:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Who:</strong> Personnel identities, roles, and relationships</li>
|
||||
<li><strong>What:</strong> Operational objectives, methods, and capabilities</li>
|
||||
<li><strong>When:</strong> Timing, schedules, and deadlines</li>
|
||||
<li><strong>Where:</strong> Locations, routes, and geographic areas</li>
|
||||
<li><strong>Why:</strong> Motivations, strategies, and decision-making processes</li>
|
||||
<li><strong>How:</strong> Methods, procedures, and technical details</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Critical Information Examples:</strong></p>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Personnel Information:
|
||||
- Real names and personal details
|
||||
- Communication addresses and identifiers
|
||||
- Role assignments and responsibilities
|
||||
- Skill sets and expertise areas
|
||||
- Personal vulnerabilities and pressure points
|
||||
|
||||
Operational Information:
|
||||
- Mission objectives and success criteria
|
||||
- Operational timelines and milestones
|
||||
- Resource requirements and allocations
|
||||
- Coordination mechanisms and protocols
|
||||
- Contingency plans and alternatives
|
||||
|
||||
Technical Information:
|
||||
- Communication methods and frequencies
|
||||
- Security procedures and protocols
|
||||
- Equipment specifications and capabilities
|
||||
- Software configurations and vulnerabilities
|
||||
- Network architecture and access points
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="step-2-analyze-threats">Step 2: Analyze Threats</h4>
|
||||
<p>Apply threat modeling to identify how adversaries might collect and use critical information:</p>
|
||||
|
||||
<p><strong>Collection Methods:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Technical Collection:</strong> Electronic surveillance and monitoring</li>
|
||||
<li><strong>Human Collection:</strong> Informants, infiltration, and social engineering</li>
|
||||
<li><strong>Open Source Collection:</strong> Public information and social media</li>
|
||||
<li><strong>Physical Collection:</strong> Surveillance and document recovery</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Analysis Capabilities:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Pattern Analysis:</strong> Identifying trends and behaviors</li>
|
||||
<li><strong>Network Analysis:</strong> Mapping relationships and structures</li>
|
||||
<li><strong>Predictive Analysis:</strong> Forecasting future activities</li>
|
||||
<li><strong>Correlation Analysis:</strong> Connecting disparate information sources</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-3-analyze-vulnerabilities">Step 3: Analyze Vulnerabilities</h4>
|
||||
<p>Identify how critical information might be exposed:</p>
|
||||
|
||||
<p><strong>Information Leakage Points:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Communication Channels:</strong> Insecure or monitored communications</li>
|
||||
<li><strong>Behavioral Patterns:</strong> Predictable activities and routines</li>
|
||||
<li><strong>Physical Evidence:</strong> Documents, equipment, and traces</li>
|
||||
<li><strong>Social Interactions:</strong> Casual conversations and relationships</li>
|
||||
<li><strong>Digital Footprints:</strong> Online activities and data trails</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Vulnerability Assessment Questions:</strong></p>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>For each piece of critical information:
|
||||
1. Who has access to this information?
|
||||
2. How is this information stored and transmitted?
|
||||
3. What activities might reveal this information?
|
||||
4. What patterns might indicate this information?
|
||||
5. How could an adversary collect this information?
|
||||
6. What would an adversary do with this information?
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="step-4-assess-risk">Step 4: Assess Risk</h4>
|
||||
<p>Evaluate the likelihood and impact of information compromise:</p>
|
||||
|
||||
<p><strong>Risk Factors:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Information Value:</strong> How useful is this to adversaries?</li>
|
||||
<li><strong>Collection Difficulty:</strong> How hard is it for adversaries to obtain?</li>
|
||||
<li><strong>Analysis Complexity:</strong> How difficult is it to interpret and use?</li>
|
||||
<li><strong>Operational Impact:</strong> What happens if this is compromised?</li>
|
||||
<li><strong>Mitigation Cost:</strong> How expensive is it to protect?</li>
|
||||
</ul>
|
||||
|
||||
<h4 id="step-5-apply-countermeasures">Step 5: Apply Countermeasures</h4>
|
||||
<p>Implement measures to protect critical information:</p>
|
||||
|
||||
<p><strong>Information Control Measures:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Classification:</strong> Formal information protection levels</li>
|
||||
<li><strong>Compartmentalization:</strong> Limiting access on need-to-know basis</li>
|
||||
<li><strong>Sanitization:</strong> Removing sensitive details from communications</li>
|
||||
<li><strong>Disinformation:</strong> Providing false information to confuse adversaries</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Activity Control Measures:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Pattern Breaking:</strong> Varying routines and procedures</li>
|
||||
<li><strong>Timing Control:</strong> Coordinating activities to minimize exposure</li>
|
||||
<li><strong>Location Security:</strong> Protecting meeting places and safe houses</li>
|
||||
<li><strong>Communication Security:</strong> Using secure channels and protocols</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="opsec-planning">OpSec Planning</h3>
|
||||
|
||||
<h4 id="opsec-plan-template">OpSec Plan Template</h4>
|
||||
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>1. Mission Overview
|
||||
- Objectives and scope
|
||||
- Timeline and milestones
|
||||
- Success criteria
|
||||
|
||||
2. Critical Information List
|
||||
- Information categories
|
||||
- Sensitivity levels
|
||||
- Access requirements
|
||||
|
||||
3. Threat Assessment
|
||||
- Adversary capabilities
|
||||
- Collection methods
|
||||
- Analysis capabilities
|
||||
|
||||
4. Vulnerability Analysis
|
||||
- Exposure points
|
||||
- Risk factors
|
||||
- Mitigation priorities
|
||||
|
||||
5. Countermeasure Plan
|
||||
- Protective measures
|
||||
- Implementation timeline
|
||||
- Responsibility assignments
|
||||
|
||||
6. Monitoring and Review
|
||||
- Effectiveness metrics
|
||||
- Review schedule
|
||||
- Update procedures
|
||||
</code></pre></div></div>
|
||||
|
||||
<h4 id="implementation-guidelines">Implementation Guidelines</h4>
|
||||
|
||||
<p><strong>Training and Awareness:</strong></p>
|
||||
<ul>
|
||||
<li><strong>OpSec Education:</strong> Understanding principles and importance</li>
|
||||
<li><strong>Threat Briefings:</strong> Current adversary capabilities and methods</li>
|
||||
<li><strong>Procedure Training:</strong> Specific protective measures and protocols</li>
|
||||
<li><strong>Regular Updates:</strong> Ongoing education and reinforcement</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Monitoring and Enforcement:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Compliance Monitoring:</strong> Checking adherence to OpSec procedures</li>
|
||||
<li><strong>Incident Reporting:</strong> Documenting OpSec failures and near-misses</li>
|
||||
<li><strong>Corrective Action:</strong> Addressing violations and weaknesses</li>
|
||||
<li><strong>Continuous Improvement:</strong> Updating procedures based on experience</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Integration with Operations:</strong></p>
|
||||
<ul>
|
||||
<li><strong>Planning Integration:</strong> OpSec considerations in all operational planning</li>
|
||||
<li><strong>Execution Monitoring:</strong> Real-time OpSec awareness during operations</li>
|
||||
<li><strong>Post-Operation Review:</strong> Analyzing OpSec effectiveness and lessons learned</li>
|
||||
<li><strong>Feedback Loop:</strong> Incorporating lessons into future planning</li>
|
||||
</ul>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">OpSec Discipline</div>
|
||||
<p>OpSec is only as strong as its weakest link. All participants must understand and consistently apply OpSec principles. A single careless action can compromise an entire operation and endanger all participants.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="chapter-summary">Chapter Summary</h2>
|
||||
|
||||
<p>Chapter 2 has provided the analytical framework necessary for understanding and responding to threats in resistance operations:</p>
|
||||
|
||||
<p><strong>Section 2-1</strong> established methodologies for analyzing adversary capabilities, motivations, and limitations across different threat actor categories.</p>
|
||||
|
||||
<p><strong>Section 2-2</strong> introduced systematic threat modeling approaches for identifying and analyzing potential attacks against resistance operations.</p>
|
||||
|
||||
<p><strong>Section 2-3</strong> provided risk assessment frameworks for prioritizing threats and allocating security resources effectively.</p>
|
||||
|
||||
<p><strong>Section 2-4</strong> covered operational security fundamentals for protecting critical information and activities from adversary intelligence collection.</p>
|
||||
|
||||
<h3 id="integration-with-security-planning">Integration with Security Planning</h3>
|
||||
|
||||
<p>The threat assessment and OpSec methodologies covered in this chapter provide the analytical foundation for all subsequent security planning and implementation. The communication systems, operational procedures, and advanced techniques covered in later parts of this manual should be selected and configured based on the threat assessment and risk analysis conducted using these frameworks.</p>
|
||||
|
||||
<h3 id="continuous-process">Continuous Process</h3>
|
||||
|
||||
<p>Threat assessment and OpSec are not one-time activities but ongoing processes that must be regularly updated as the operational environment changes. New threats emerge, adversary capabilities evolve, and operational requirements shift, requiring continuous monitoring and adaptation of security measures.</p>
|
||||
|
||||
<hr />
|
||||
|
||||
<p><strong>Next:</strong> <a href="/parts/part-2/">Part II: Secure Communication Systems →</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<nav class="section-nav">
|
||||
|
||||
<a href="/chapters/chapter-1/" class="nav-link">
|
||||
<span class="arrow">←</span>
|
||||
<span>Chapter 1: Core Security Principles</span>
|
||||
</a>
|
||||
|
||||
|
||||
|
||||
<a href="/parts/part-2/" class="nav-link">
|
||||
<span>Part II: Communication Systems</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>
|
||||
|
1243
_site/chapters/chapter-3/index.html
Normal file
1243
_site/chapters/chapter-3/index.html
Normal file
File diff suppressed because it is too large
Load Diff
1687
_site/chapters/chapter-4/index.html
Normal file
1687
_site/chapters/chapter-4/index.html
Normal file
File diff suppressed because it is too large
Load Diff
1443
_site/chapters/chapter-5/index.html
Normal file
1443
_site/chapters/chapter-5/index.html
Normal file
File diff suppressed because it is too large
Load Diff
1
_site/feed.xml
Normal file
1
_site/feed.xml
Normal file
|
@ -0,0 +1 @@
|
|||
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://guide.resist.is/feed.xml" rel="self" type="application/atom+xml" /><link href="https://guide.resist.is/" rel="alternate" type="text/html" /><updated>2025-08-28T19:48:01-04:00</updated><id>https://guide.resist.is/feed.xml</id><title type="html">Field Manual for Resistance Operations</title><subtitle>A comprehensive guide to secure communication and operational security for newcomers to resistance movements</subtitle></feed>
|
343
_site/index.html
Normal file
343
_site/index.html
Normal file
|
@ -0,0 +1,343 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Table of Contents - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Field Manual for Resistance Operations - A comprehensive guide to secure communication and operational security for decentralized resistance movements">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<div class="nav-section">
|
||||
<h3>Field Manual</h3>
|
||||
<ul>
|
||||
<li><a href="/" class="active">Table of Contents</a></li>
|
||||
<li><a href="/preface/" >Preface</a></li>
|
||||
<li><a href="/introduction/" >Introduction</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
||||
<h1 id="field-manual-for-resistance-operations">Field Manual for Resistance Operations</h1>
|
||||
|
||||
<div class="manual-designation" style="text-align: center; margin-bottom: 2rem;">
|
||||
<div style="font-size: 1.2rem; color: #00ff00;">FM-R1</div>
|
||||
<div style="font-size: 1rem; color: #ffffff;">FM-R1: Secure Communication Networks for Decentralized Resistance</div>
|
||||
<div style="font-size: 0.9rem; color: #0066ff; margin-top: 1rem;">Department of Internautics</div>
|
||||
<div style="font-size: 0.9rem; color: #0066ff;">Bureau of Decentralized Resistance</div>
|
||||
<div style="font-size: 0.8rem; color: #ffaa00; margin-top: 1rem;">UNCLASSIFIED</div>
|
||||
<div style="font-size: 0.8rem; color: #ffffff;">Version 1.0 - 2025-08-28</div>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<h2 id="table-of-contents">Table of Contents</h2>
|
||||
|
||||
<h3 id="front-matter">Front Matter</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/preface/">Preface</a></strong> - Purpose, scope, and how to use this manual</li>
|
||||
<li><strong><a href="/introduction/">Introduction</a></strong> - Threat landscape and security fundamentals</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="part-i-foundations-of-resistance-security">Part I: Foundations of Resistance Security</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/parts/part-1/">Part I Overview</a></strong> - Core principles and threat assessment
|
||||
<ul>
|
||||
<li><strong><a href="/chapters/chapter-1/">Chapter 1: Core Security Principles</a></strong> (1-1 to 1-5)
|
||||
<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>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-2/">Chapter 2: Threat Assessment and Operational Environment</a></strong> (2-1 to 2-4)
|
||||
<ul>
|
||||
<li>2-1: Understanding Your Adversary</li>
|
||||
<li>2-2: Threat Model Development</li>
|
||||
<li>2-3: Risk Assessment Framework</li>
|
||||
<li>2-4: Operational Security (OpSec) Fundamentals</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="part-ii-secure-communication-systems">Part II: Secure Communication Systems</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/parts/part-2/">Part II Overview</a></strong> - Multi-layer communication architecture
|
||||
<ul>
|
||||
<li><strong><a href="/chapters/chapter-3/">Chapter 3: Communication Layer Architecture</a></strong> (3-1 to 3-6)
|
||||
<ul>
|
||||
<li>3-1: Multi-Layer Communication Strategy</li>
|
||||
<li>3-2: High-Risk Real-Time Communication (Layer 1)</li>
|
||||
<li>3-3: Secure Collaboration Systems (Layer 2)</li>
|
||||
<li>3-4: Failsafe and Offline Methods (Layer 3)</li>
|
||||
<li>3-5: Anonymous Broadcasting (Layer 4)</li>
|
||||
<li>3-6: Communication Protocol Selection</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-4/">Chapter 4: Secure Messaging and Voice Communications</a></strong> (4-1 to 4-8)
|
||||
<ul>
|
||||
<li>4-1: Session Messenger Configuration</li>
|
||||
<li>4-2: Element/Matrix Self-Hosted Setup</li>
|
||||
<li>4-3: Briar Peer-to-Peer Messaging</li>
|
||||
<li>4-4: Signal Security Best Practices</li>
|
||||
<li>4-5: Voice Communication Security</li>
|
||||
<li>4-6: Group Communication Management</li>
|
||||
<li>4-7: Message Verification and Authentication</li>
|
||||
<li>4-8: Communication Scheduling and Protocols</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-5/">Chapter 5: File Sharing and Collaboration</a></strong> (5-1 to 5-6)
|
||||
<ul>
|
||||
<li>5-1: CryptPad Secure Document Collaboration</li>
|
||||
<li>5-2: OnionShare Anonymous File Transfer</li>
|
||||
<li>5-3: Encrypted Cloud Storage (Mega/Proton)</li>
|
||||
<li>5-4: Digital Dead Drops</li>
|
||||
<li>5-5: Version Control for Sensitive Documents</li>
|
||||
<li>5-6: Collaborative Security Protocols</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="part-iii-operational-security-procedures">Part III: Operational Security Procedures</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/parts/part-3/">Part III Overview</a></strong> - Hardware, digital hygiene, and operational procedures
|
||||
<ul>
|
||||
<li><strong><a href="/chapters/chapter-6/">Chapter 6: Hardware and Infrastructure Security</a></strong> (6-1 to 6-8)
|
||||
<ul>
|
||||
<li>6-1: Untraceable Hardware Acquisition</li>
|
||||
<li>6-2: Tails OS Installation and Configuration</li>
|
||||
<li>6-3: Device Compartmentalization</li>
|
||||
<li>6-4: Physical Security Measures</li>
|
||||
<li>6-5: Network Access Security</li>
|
||||
<li>6-6: Hardware Disposal and Sanitization</li>
|
||||
<li>6-7: Faraday Cage and Signal Blocking</li>
|
||||
<li>6-8: Power and Charging Security</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-7/">Chapter 7: Digital Hygiene and Privacy</a></strong> (7-1 to 7-6)
|
||||
<ul>
|
||||
<li>7-1: Browser Security Configuration</li>
|
||||
<li>7-2: Search Engine Privacy</li>
|
||||
<li>7-3: VPN and Tor Usage</li>
|
||||
<li>7-4: Social Media Operational Security</li>
|
||||
<li>7-5: Email Security and Anonymous Accounts</li>
|
||||
<li>7-6: Digital Footprint Minimization</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-8/">Chapter 8: Operational Procedures</a></strong> (8-1 to 8-8)
|
||||
<ul>
|
||||
<li>8-1: Cell Organization and Management</li>
|
||||
<li>8-2: Meeting Security Protocols</li>
|
||||
<li>8-3: Coded Language and Communication</li>
|
||||
<li>8-4: Surveillance Detection and Evasion</li>
|
||||
<li>8-5: Emergency Procedures and Protocols</li>
|
||||
<li>8-6: Information Sanitization</li>
|
||||
<li>8-7: Operational Planning Security</li>
|
||||
<li>8-8: Post-Operation Security Review</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="part-iv-advanced-resistance-operations">Part IV: Advanced Resistance Operations</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/parts/part-4/">Part IV Overview</a></strong> - Network resilience and counter-intelligence
|
||||
<ul>
|
||||
<li><strong><a href="/chapters/chapter-9/">Chapter 9: Network Resilience and Redundancy</a></strong> (9-1 to 9-5)
|
||||
<ul>
|
||||
<li>9-1: Mesh Network Implementation</li>
|
||||
<li>9-2: Offline Communication Systems</li>
|
||||
<li>9-3: Emergency Communication Protocols</li>
|
||||
<li>9-4: Network Failure Recovery</li>
|
||||
<li>9-5: Distributed Infrastructure Planning</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><strong><a href="/chapters/chapter-10/">Chapter 10: Counter-Intelligence and Security Culture</a></strong> (10-1 to 10-6)
|
||||
<ul>
|
||||
<li>10-1: Infiltration Detection and Prevention</li>
|
||||
<li>10-2: Information Verification Procedures</li>
|
||||
<li>10-3: Security Culture Development</li>
|
||||
<li>10-4: Compartmentalized Knowledge Management</li>
|
||||
<li>10-5: Trust Networks and Verification</li>
|
||||
<li>10-6: Operational Security Training</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="appendices">Appendices</h3>
|
||||
<ul>
|
||||
<li><strong><a href="/appendices/">Appendix A: Quick Reference Guides</a></strong> - Emergency checklists and procedures</li>
|
||||
<li><strong><a href="/appendices/tools/">Appendix B: Tool Configuration Guides</a></strong> - Step-by-step setup instructions</li>
|
||||
<li><strong><a href="/appendices/resources/">Appendix C: External Resources and Links</a></strong> - Recommended tools and organizations</li>
|
||||
<li><strong><a href="/appendices/glossary/">Appendix D: Glossary of Terms</a></strong> - Definitions and terminology</li>
|
||||
</ul>
|
||||
|
||||
<hr />
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Security Notice</div>
|
||||
<p>This manual contains sensitive information about resistance operations and security practices. Ensure you are accessing this content through secure channels (Tails OS, Tor Browser, or other anonymizing tools) and following proper operational security protocols.</p>
|
||||
</div>
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">For Newcomers</div>
|
||||
<p>If you are new to resistance operations, start with the <strong>Preface</strong> and <strong>Introduction</strong>, then proceed through <strong>Part I: Foundations</strong> before advancing to more technical sections. Each chapter builds upon previous knowledge.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<p><strong>Distribution:</strong> This manual is designed for decentralized distribution through secure channels. Share responsibly and only with trusted individuals who have a legitimate need for this information.</p>
|
||||
|
||||
<p><strong>Updates:</strong> This manual will be updated regularly as new threats emerge and technologies evolve. Check the source repository for the latest version.</p>
|
||||
|
||||
<p><strong>Support:</strong> For questions or contributions, contact the Bureau of Decentralized Resistance through secure channels only.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
</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>
|
||||
|
392
_site/introduction/index.html
Normal file
392
_site/introduction/index.html
Normal file
|
@ -0,0 +1,392 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Introduction - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Threat landscape overview and fundamental security concepts for resistance operations">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<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/" class="active">Introduction</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
||||
<h1 id="introduction">Introduction</h1>
|
||||
|
||||
<h2 id="the-modern-resistance-environment">The Modern Resistance Environment</h2>
|
||||
|
||||
<p>Resistance movements in the 21st century face unprecedented challenges. Unlike historical resistance operations that primarily contended with human intelligence networks and physical surveillance, modern movements must operate within a digital panopticon of mass surveillance, algorithmic analysis, and predictive policing.</p>
|
||||
|
||||
<p>The scenario addressed in this manual—resistance against a technologically advanced authoritarian regime—represents the ultimate stress test for operational security. The adversary possesses:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Total spectrum surveillance</strong> across digital communications</li>
|
||||
<li><strong>Massive data processing capabilities</strong> for pattern recognition and network analysis</li>
|
||||
<li><strong>Legal and extralegal powers</strong> to compel cooperation from technology companies</li>
|
||||
<li><strong>Advanced persistent threat capabilities</strong> for targeted device compromise</li>
|
||||
<li><strong>Extensive human intelligence networks</strong> including informants and infiltrators</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="the-digital-battlefield">The Digital Battlefield</h3>
|
||||
|
||||
<p>Every digital action creates metadata that can be analyzed to reveal:</p>
|
||||
<ul>
|
||||
<li><strong>Communication patterns</strong> - who talks to whom, when, and how frequently</li>
|
||||
<li><strong>Location data</strong> - movement patterns and association networks</li>
|
||||
<li><strong>Behavioral profiles</strong> - interests, habits, and predictive models</li>
|
||||
<li><strong>Social graphs</strong> - relationship mapping and influence networks</li>
|
||||
<li><strong>Operational indicators</strong> - planning cycles and activity patterns</li>
|
||||
</ul>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Critical Understanding</div>
|
||||
<p>The most dangerous misconception in modern resistance is believing that encryption alone provides security. While encryption protects content, metadata analysis can reveal operational structures, timing, and relationships even when communications are encrypted.</p>
|
||||
</div>
|
||||
|
||||
<h2 id="fundamental-security-concepts">Fundamental Security Concepts</h2>
|
||||
|
||||
<h3 id="defense-in-depth">Defense in Depth</h3>
|
||||
|
||||
<p>No single security measure is sufficient. Effective resistance security requires multiple overlapping layers:</p>
|
||||
|
||||
<ol>
|
||||
<li><strong>Technical measures</strong> - Encryption, anonymization, secure hardware</li>
|
||||
<li><strong>Operational procedures</strong> - Compartmentalization, communication protocols, meeting security</li>
|
||||
<li><strong>Human factors</strong> - Training, security culture, psychological resilience</li>
|
||||
<li><strong>Physical security</strong> - Safe houses, surveillance detection, document security</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="threat-modeling">Threat Modeling</h3>
|
||||
|
||||
<p>Before implementing any security measures, you must understand:</p>
|
||||
|
||||
<p><strong>Assets</strong> - What are you protecting?</p>
|
||||
<ul>
|
||||
<li>Lives and freedom of participants</li>
|
||||
<li>Operational plans and intelligence</li>
|
||||
<li>Communication networks and infrastructure</li>
|
||||
<li>Financial resources and supplies</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Adversaries</strong> - Who are you protecting against?</p>
|
||||
<ul>
|
||||
<li>State security services and law enforcement</li>
|
||||
<li>Private intelligence contractors</li>
|
||||
<li>Informants and infiltrators</li>
|
||||
<li>Hostile political organizations</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Capabilities</strong> - What can your adversaries do?</p>
|
||||
<ul>
|
||||
<li>Technical surveillance and cyber operations</li>
|
||||
<li>Physical surveillance and infiltration</li>
|
||||
<li>Legal powers and extrajudicial actions</li>
|
||||
<li>Resource advantages and institutional support</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Consequences</strong> - What happens if security fails?</p>
|
||||
<ul>
|
||||
<li>Arrest, prosecution, and imprisonment</li>
|
||||
<li>Physical harm or assassination</li>
|
||||
<li>Network compromise and operational failure</li>
|
||||
<li>Broader movement suppression</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="the-security-usability-balance">The Security-Usability Balance</h3>
|
||||
|
||||
<p>Perfect security is incompatible with operational effectiveness. Every security measure introduces complexity, reduces convenience, and creates potential failure points. The art of resistance security lies in finding the optimal balance between:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Security requirements</strong> based on threat assessment</li>
|
||||
<li><strong>Operational needs</strong> for communication and coordination</li>
|
||||
<li><strong>Human limitations</strong> in following complex procedures</li>
|
||||
<li><strong>Resource constraints</strong> in time, money, and technical expertise</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="core-principles-for-resistance-operations">Core Principles for Resistance Operations</h2>
|
||||
|
||||
<h3 id="1-assume-compromise">1. Assume Compromise</h3>
|
||||
|
||||
<p>Operate under the assumption that some level of compromise is inevitable:</p>
|
||||
<ul>
|
||||
<li>Design systems that remain functional even if partially compromised</li>
|
||||
<li>Limit the damage any single compromise can cause</li>
|
||||
<li>Plan for detection and response to security breaches</li>
|
||||
<li>Maintain operational capability under surveillance</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="2-minimize-attack-surface">2. Minimize Attack Surface</h3>
|
||||
|
||||
<p>Reduce the number of ways you can be compromised:</p>
|
||||
<ul>
|
||||
<li>Use the minimum number of tools and platforms necessary</li>
|
||||
<li>Limit the amount of sensitive data stored or transmitted</li>
|
||||
<li>Reduce the number of people with access to critical information</li>
|
||||
<li>Eliminate unnecessary digital and physical traces</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="3-compartmentalization">3. Compartmentalization</h3>
|
||||
|
||||
<p>Organize information and access on a need-to-know basis:</p>
|
||||
<ul>
|
||||
<li>Structure operations in independent cells</li>
|
||||
<li>Limit cross-cell knowledge and communication</li>
|
||||
<li>Use different tools and identities for different purposes</li>
|
||||
<li>Prevent single points of failure from compromising entire networks</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="4-operational-discipline">4. Operational Discipline</h3>
|
||||
|
||||
<p>Maintain consistent security practices:</p>
|
||||
<ul>
|
||||
<li>Follow established procedures even when inconvenient</li>
|
||||
<li>Resist the temptation to take shortcuts under pressure</li>
|
||||
<li>Regularly review and update security practices</li>
|
||||
<li>Train all participants in proper security procedures</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="5-continuous-adaptation">5. Continuous Adaptation</h3>
|
||||
|
||||
<p>Security is not a destination but an ongoing process:</p>
|
||||
<ul>
|
||||
<li>Monitor for new threats and vulnerabilities</li>
|
||||
<li>Update tools and procedures as technology evolves</li>
|
||||
<li>Learn from security incidents and near-misses</li>
|
||||
<li>Share knowledge and best practices across the movement</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="the-human-element">The Human Element</h2>
|
||||
|
||||
<p>Technology can only provide the foundation for security—human behavior determines whether that foundation holds. The most sophisticated technical measures are worthless if participants:</p>
|
||||
|
||||
<ul>
|
||||
<li>Use personal devices for resistance activities</li>
|
||||
<li>Discuss sensitive matters in insecure environments</li>
|
||||
<li>Fail to follow established communication protocols</li>
|
||||
<li>Compromise operational security for convenience</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="building-security-culture">Building Security Culture</h3>
|
||||
|
||||
<p>Effective resistance security requires developing a culture where:</p>
|
||||
<ul>
|
||||
<li>Security consciousness becomes second nature</li>
|
||||
<li>Participants understand the reasoning behind security measures</li>
|
||||
<li>Peer accountability reinforces proper procedures</li>
|
||||
<li>Security education is ongoing and practical</li>
|
||||
<li>Mistakes are treated as learning opportunities rather than failures</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="scope-of-this-manual">Scope of This Manual</h2>
|
||||
|
||||
<p>This manual provides practical guidance for implementing the security concepts outlined above. It is organized to support both learning and reference use:</p>
|
||||
|
||||
<p><strong>Part I: Foundations</strong> establishes the theoretical framework and threat assessment methodologies that inform all subsequent technical recommendations.</p>
|
||||
|
||||
<p><strong>Part II: Communication Systems</strong> provides detailed guidance for implementing secure communication networks using proven tools and techniques.</p>
|
||||
|
||||
<p><strong>Part III: Operational Security</strong> covers the human and procedural elements necessary to maintain security in practice.</p>
|
||||
|
||||
<p><strong>Part IV: Advanced Operations</strong> addresses specialized topics for mature resistance networks operating under extreme threat conditions.</p>
|
||||
|
||||
<p><strong>Appendices</strong> provide quick reference materials, detailed configuration guides, and external resources for continued learning.</p>
|
||||
|
||||
<h2 id="getting-started">Getting Started</h2>
|
||||
|
||||
<p>The journey from security novice to competent resistance operator requires patience, practice, and mentorship. This manual provides the roadmap, but you must walk the path:</p>
|
||||
|
||||
<ol>
|
||||
<li><strong>Master the fundamentals</strong> before attempting advanced techniques</li>
|
||||
<li><strong>Practice in safe environments</strong> before operational deployment</li>
|
||||
<li><strong>Seek guidance</strong> from experienced practitioners</li>
|
||||
<li><strong>Start with basic security measures</strong> and gradually increase complexity</li>
|
||||
<li><strong>Maintain operational security</strong> throughout your learning process</li>
|
||||
</ol>
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Learning Path</div>
|
||||
<p>New practitioners should follow this sequence:</p>
|
||||
<ol>
|
||||
<li><strong>Part I</strong> - Understand core principles and threat assessment</li>
|
||||
<li><strong>Chapter 6</strong> - Set up secure hardware and Tails OS</li>
|
||||
<li><strong>Chapter 4</strong> - Configure basic secure messaging</li>
|
||||
<li><strong>Chapter 7</strong> - Implement digital hygiene practices</li>
|
||||
<li><strong>Remaining chapters</strong> - Add capabilities as needed</li>
|
||||
</ol>
|
||||
</div>
|
||||
|
||||
<h2 id="a-note-on-courage">A Note on Courage</h2>
|
||||
|
||||
<p>Resistance requires courage—not the absence of fear, but action in spite of fear. The security measures in this manual cannot eliminate risk; they can only manage it. Every person who chooses resistance accepts some level of danger in service of a greater cause.</p>
|
||||
|
||||
<p>This manual honors that courage by providing the best possible guidance for staying safe while fighting for justice. Use it wisely, share it responsibly, and remember that your security protects not just yourself, but everyone who depends on you.</p>
|
||||
|
||||
<hr />
|
||||
|
||||
<p><strong>The stakes are high. The tools are available. The choice is yours.</strong></p>
|
||||
|
||||
<p><strong>Next:</strong> <a href="/parts/part-1/">Part I: Foundations of Resistance Security →</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<nav class="section-nav">
|
||||
|
||||
<a href="/preface/" class="nav-link">
|
||||
<span class="arrow">←</span>
|
||||
<span>Preface</span>
|
||||
</a>
|
||||
|
||||
|
||||
|
||||
<a href="/parts/part-1/" class="nav-link">
|
||||
<span>Part I: Foundations</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>
|
||||
|
312
_site/parts/part-1/index.html
Normal file
312
_site/parts/part-1/index.html
Normal file
|
@ -0,0 +1,312 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Part I: Foundations of Resistance Security - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Core security principles and threat assessment methodologies for resistance operations">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<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>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part I: Foundations</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="/parts/part-1/" class="active">Part Overview</a>
|
||||
<ul>
|
||||
<li><a href="/chapters/chapter-1/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
||||
<h1 id="part-i-foundations-of-resistance-security">Part I: Foundations of Resistance Security</h1>
|
||||
|
||||
<h2 id="overview">Overview</h2>
|
||||
|
||||
<p>Part I establishes the theoretical and practical foundations necessary for all resistance security operations. Before implementing any technical measures or operational procedures, resistance practitioners must understand the fundamental principles that govern security in hostile environments and develop the analytical skills necessary to assess threats and design appropriate countermeasures.</p>
|
||||
|
||||
<p>This part addresses the most critical question in resistance security: <strong>How do you think about security in a way that leads to effective protection?</strong></p>
|
||||
|
||||
<h2 id="learning-objectives">Learning Objectives</h2>
|
||||
|
||||
<p>Upon completing Part I, you will be able to:</p>
|
||||
|
||||
<ul>
|
||||
<li>Apply core security principles to evaluate and design resistance operations</li>
|
||||
<li>Conduct systematic threat assessments for your specific operational environment</li>
|
||||
<li>Develop risk management strategies appropriate to your threat level</li>
|
||||
<li>Understand the relationship between security measures and operational effectiveness</li>
|
||||
<li>Recognize common security failures and their underlying causes</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="chapter-overview">Chapter Overview</h2>
|
||||
|
||||
<h3 id="chapter-1-core-security-principles-1-1-to-1-5">Chapter 1: Core Security Principles (1-1 to 1-5)</h3>
|
||||
|
||||
<p>The five fundamental principles that must guide all resistance security decisions:</p>
|
||||
|
||||
<p><strong>1-1: Principle of Least Privilege</strong> - Limiting access to the minimum necessary for operational effectiveness</p>
|
||||
|
||||
<p><strong>1-2: Need-to-Know Basis</strong> - Compartmentalizing information to prevent cascade failures</p>
|
||||
|
||||
<p><strong>1-3: Compartmentalization and Cell Structure</strong> - Organizing resistance networks to contain compromise</p>
|
||||
|
||||
<p><strong>1-4: Zero Trust Verification</strong> - Assuming compromise and requiring continuous authentication</p>
|
||||
|
||||
<p><strong>1-5: Metadata Minimization</strong> - Reducing the digital traces that reveal operational patterns</p>
|
||||
|
||||
<h3 id="chapter-2-threat-assessment-and-operational-environment-2-1-to-2-4">Chapter 2: Threat Assessment and Operational Environment (2-1 to 2-4)</h3>
|
||||
|
||||
<p>Systematic approaches to understanding and responding to threats:</p>
|
||||
|
||||
<p><strong>2-1: Understanding Your Adversary</strong> - Analyzing capabilities, motivations, and limitations of hostile forces</p>
|
||||
|
||||
<p><strong>2-2: Threat Model Development</strong> - Creating structured assessments of risks and vulnerabilities</p>
|
||||
|
||||
<p><strong>2-3: Risk Assessment Framework</strong> - Quantifying and prioritizing security investments</p>
|
||||
|
||||
<p><strong>2-4: Operational Security (OpSec) Fundamentals</strong> - Translating threat assessments into practical procedures</p>
|
||||
|
||||
<h2 id="the-security-mindset">The Security Mindset</h2>
|
||||
|
||||
<p>Before diving into specific principles and procedures, it’s essential to understand the fundamental shift in thinking required for effective resistance security. This shift involves:</p>
|
||||
|
||||
<h3 id="from-convenience-to-security">From Convenience to Security</h3>
|
||||
|
||||
<p>In normal life, we optimize for convenience, efficiency, and ease of use. In resistance operations, security becomes the primary consideration, with convenience secondary. This doesn’t mean making things unnecessarily difficult, but rather accepting that some inconvenience is the price of safety.</p>
|
||||
|
||||
<h3 id="from-trust-to-verification">From Trust to Verification</h3>
|
||||
|
||||
<p>Normal social and professional relationships operate on trust and good faith. Resistance operations must assume that trust can be compromised, either through infiltration or coercion, and build verification mechanisms into all critical processes.</p>
|
||||
|
||||
<h3 id="from-reactive-to-proactive">From Reactive to Proactive</h3>
|
||||
|
||||
<p>Most people respond to security threats after they become apparent. Resistance operations must anticipate threats and implement countermeasures before they’re needed, because by the time a threat is obvious, it may be too late to respond effectively.</p>
|
||||
|
||||
<h3 id="from-individual-to-collective">From Individual to Collective</h3>
|
||||
|
||||
<p>Personal security practices focus on protecting yourself. Resistance security must consider how your actions affect the safety of others in your network, and how their actions affect your safety.</p>
|
||||
|
||||
<h2 id="common-misconceptions">Common Misconceptions</h2>
|
||||
|
||||
<h3 id="encryption-solves-everything">“Encryption Solves Everything”</h3>
|
||||
|
||||
<p>While encryption is essential, it only protects the content of communications, not the metadata that reveals who is talking to whom, when, and from where. Metadata analysis can reveal network structures and operational patterns even when all communications are encrypted.</p>
|
||||
|
||||
<h3 id="if-you-have-nothing-to-hide">“If You Have Nothing to Hide…”</h3>
|
||||
|
||||
<p>This argument fundamentally misunderstands the nature of authoritarian surveillance. The goal is not just to find evidence of wrongdoing, but to map networks, predict behavior, and suppress dissent before it becomes effective.</p>
|
||||
|
||||
<h3 id="theyre-too-powerful-to-resist">“They’re Too Powerful to Resist”</h3>
|
||||
|
||||
<p>While authoritarian regimes have significant advantages, they also have limitations and vulnerabilities. Understanding both their capabilities and their constraints is essential for developing effective resistance strategies.</p>
|
||||
|
||||
<h3 id="perfect-security-is-possible">“Perfect Security is Possible”</h3>
|
||||
|
||||
<p>No security system is perfect, and pursuing perfect security often leads to systems so complex and restrictive that they cannot be used effectively. The goal is appropriate security for your specific threat environment and operational requirements.</p>
|
||||
|
||||
<h2 id="integration-with-subsequent-parts">Integration with Subsequent Parts</h2>
|
||||
|
||||
<p>The principles and methodologies covered in Part I provide the foundation for all subsequent technical and operational guidance:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Part II</strong> applies these principles to design secure communication systems</li>
|
||||
<li><strong>Part III</strong> translates them into practical operational security procedures</li>
|
||||
<li><strong>Part IV</strong> extends them to advanced scenarios and specialized threats</li>
|
||||
</ul>
|
||||
|
||||
<p>Each technical recommendation and operational procedure in later parts derives from the fundamental principles established here. Understanding these foundations is essential for adapting the manual’s guidance to your specific circumstances and for making sound security decisions when facing novel situations.</p>
|
||||
|
||||
<h2 id="study-approach">Study Approach</h2>
|
||||
|
||||
<h3 id="for-individual-study">For Individual Study</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Read each section completely</strong> before moving to the next</li>
|
||||
<li><strong>Take notes</strong> on how principles apply to your specific situation</li>
|
||||
<li><strong>Work through examples</strong> using scenarios relevant to your operations</li>
|
||||
<li><strong>Review regularly</strong> as these concepts must become second nature</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="for-group-study">For Group Study</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Discuss each principle</strong> and its implications for your organization</li>
|
||||
<li><strong>Develop case studies</strong> based on your operational environment</li>
|
||||
<li><strong>Practice threat modeling</strong> for actual or hypothetical operations</li>
|
||||
<li><strong>Create reference materials</strong> summarizing key concepts for quick review</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="for-training-others">For Training Others</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Use concrete examples</strong> rather than abstract concepts</li>
|
||||
<li><strong>Connect principles to practical consequences</strong> of security failures</li>
|
||||
<li><strong>Encourage questions</strong> and discussion of edge cases</li>
|
||||
<li><strong>Provide opportunities to practice</strong> threat assessment skills</li>
|
||||
</ol>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Foundation First</div>
|
||||
<p>Do not skip Part I to get to "more practical" technical content. The principles covered here determine whether technical measures will be effective or merely provide a false sense of security. Every security failure can be traced back to a violation of these fundamental principles.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<p><strong>Ready to begin?</strong> Start with <a href="/chapters/chapter-1/">Chapter 1: Core Security Principles →</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<nav class="section-nav">
|
||||
|
||||
<a href="/introduction/" class="nav-link">
|
||||
<span class="arrow">←</span>
|
||||
<span>Introduction</span>
|
||||
</a>
|
||||
|
||||
|
||||
|
||||
<a href="/chapters/chapter-1/" class="nav-link">
|
||||
<span>Chapter 1: Core Security Principles</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>
|
||||
|
462
_site/parts/part-2/index.html
Normal file
462
_site/parts/part-2/index.html
Normal file
|
@ -0,0 +1,462 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Part II: Secure Communication Systems - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Multi-layer communication architectures and secure messaging systems for resistance operations">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<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>
|
||||
|
||||
<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/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Part II: Communication</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="/parts/part-2/" class="active">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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
||||
<h1 id="part-ii-secure-communication-systems">Part II: Secure Communication Systems</h1>
|
||||
|
||||
<h2 id="overview">Overview</h2>
|
||||
|
||||
<p>Part II addresses the critical challenge of maintaining secure communications within resistance networks operating under advanced surveillance. This part provides comprehensive guidance for implementing multi-layer communication architectures that balance security requirements with operational effectiveness.</p>
|
||||
|
||||
<p>Communication security is the backbone of resistance operations. Without secure communications, resistance networks cannot coordinate activities, share intelligence, or maintain operational security. However, communication also represents the greatest vulnerability, as every communication creates metadata that can be analyzed to reveal network structures, operational patterns, and individual behaviors.</p>
|
||||
|
||||
<h2 id="learning-objectives">Learning Objectives</h2>
|
||||
|
||||
<p>Upon completing Part II, you will be able to:</p>
|
||||
|
||||
<ul>
|
||||
<li>Design and implement multi-layer communication architectures appropriate to your threat environment</li>
|
||||
<li>Configure and operate secure messaging systems including Session, Element/Matrix, Briar, and Signal</li>
|
||||
<li>Establish secure file sharing and collaboration systems using CryptPad, OnionShare, and encrypted cloud storage</li>
|
||||
<li>Implement communication protocols that minimize metadata exposure and maximize operational security</li>
|
||||
<li>Develop contingency communication plans for various compromise and failure scenarios</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="the-communication-security-challenge">The Communication Security Challenge</h2>
|
||||
|
||||
<h3 id="the-metadata-problem">The Metadata Problem</h3>
|
||||
|
||||
<p>Modern surveillance systems focus less on communication content (which can be encrypted) and more on communication metadata (which reveals patterns even when content is protected). Every digital communication generates metadata including:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Sender and recipient identities</strong> and network addresses</li>
|
||||
<li><strong>Timing information</strong> including send/receive timestamps</li>
|
||||
<li><strong>Location data</strong> from device GPS and network connections</li>
|
||||
<li><strong>Communication patterns</strong> including frequency and duration</li>
|
||||
<li><strong>Device information</strong> including hardware and software details</li>
|
||||
</ul>
|
||||
|
||||
<p>This metadata can be analyzed to:</p>
|
||||
<ul>
|
||||
<li>Map network structures and identify key participants</li>
|
||||
<li>Predict operational activities and timing</li>
|
||||
<li>Locate physical meetings and safe houses</li>
|
||||
<li>Identify behavioral patterns and vulnerabilities</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="the-usability-security-tension">The Usability-Security Tension</h3>
|
||||
|
||||
<p>Perfect communication security would require:</p>
|
||||
<ul>
|
||||
<li>No digital communications whatsoever</li>
|
||||
<li>Face-to-face meetings only in secure locations</li>
|
||||
<li>Perfect operational security from all participants</li>
|
||||
<li>No time-sensitive coordination requirements</li>
|
||||
</ul>
|
||||
|
||||
<p>Perfect operational effectiveness would require:</p>
|
||||
<ul>
|
||||
<li>Instant communication between all participants</li>
|
||||
<li>Rich multimedia sharing and collaboration</li>
|
||||
<li>Real-time coordination and decision-making</li>
|
||||
<li>Seamless integration with existing tools and workflows</li>
|
||||
</ul>
|
||||
|
||||
<p>Practical resistance communications must balance these competing requirements through carefully designed architectures that provide appropriate security for specific use cases while maintaining operational effectiveness.</p>
|
||||
|
||||
<h2 id="multi-layer-communication-strategy">Multi-Layer Communication Strategy</h2>
|
||||
|
||||
<p>Part II is organized around a four-layer communication architecture that provides different security levels for different operational requirements:</p>
|
||||
|
||||
<h3 id="layer-1-high-risk-real-time-communication">Layer 1: High-Risk Real-Time Communication</h3>
|
||||
<p><strong>Use Case:</strong> Time-sensitive coordination during active operations
|
||||
<strong>Security Level:</strong> Maximum security, minimal metadata
|
||||
<strong>Tools:</strong> Session Messenger, Briar mesh networking
|
||||
<strong>Characteristics:</strong></p>
|
||||
<ul>
|
||||
<li>Onion routing and metadata protection</li>
|
||||
<li>Peer-to-peer architecture with no central servers</li>
|
||||
<li>Ephemeral messaging with automatic deletion</li>
|
||||
<li>Offline capability and mesh networking</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="layer-2-secure-collaboration-systems">Layer 2: Secure Collaboration Systems</h3>
|
||||
<p><strong>Use Case:</strong> Planning, document sharing, and ongoing coordination
|
||||
<strong>Security Level:</strong> High security with collaboration features
|
||||
<strong>Tools:</strong> Element/Matrix (self-hosted), CryptPad
|
||||
<strong>Characteristics:</strong></p>
|
||||
<ul>
|
||||
<li>End-to-end encryption with forward secrecy</li>
|
||||
<li>Self-hosted infrastructure under resistance control</li>
|
||||
<li>Rich collaboration features including file sharing</li>
|
||||
<li>Persistent storage with secure access controls</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="layer-3-failsafe-and-offline-methods">Layer 3: Failsafe and Offline Methods</h3>
|
||||
<p><strong>Use Case:</strong> Emergency communications and backup channels
|
||||
<strong>Security Level:</strong> Maximum reliability and availability
|
||||
<strong>Tools:</strong> OnionShare, encrypted email, physical dead drops
|
||||
<strong>Characteristics:</strong></p>
|
||||
<ul>
|
||||
<li>No dependence on internet infrastructure</li>
|
||||
<li>Asynchronous communication with time delays</li>
|
||||
<li>Multiple redundant channels and methods</li>
|
||||
<li>Resistance to network disruption and censorship</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="layer-4-anonymous-broadcasting">Layer 4: Anonymous Broadcasting</h3>
|
||||
<p><strong>Use Case:</strong> Public communications and propaganda distribution
|
||||
<strong>Security Level:</strong> Sender anonymity and censorship resistance
|
||||
<strong>Tools:</strong> Tor hidden services, distributed publishing platforms
|
||||
<strong>Characteristics:</strong></p>
|
||||
<ul>
|
||||
<li>One-to-many communication model</li>
|
||||
<li>Strong sender anonymity protection</li>
|
||||
<li>Censorship resistance and availability</li>
|
||||
<li>Public accessibility without authentication</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="chapter-overview">Chapter Overview</h2>
|
||||
|
||||
<h3 id="chapter-3-communication-layer-architecture-3-1-to-3-6">Chapter 3: Communication Layer Architecture (3-1 to 3-6)</h3>
|
||||
|
||||
<p>Establishes the theoretical framework and practical implementation of multi-layer communication systems:</p>
|
||||
|
||||
<p><strong>3-1: Multi-Layer Communication Strategy</strong> - Overall architecture and layer selection criteria</p>
|
||||
|
||||
<p><strong>3-2: High-Risk Real-Time Communication (Layer 1)</strong> - Maximum security for time-sensitive operations</p>
|
||||
|
||||
<p><strong>3-3: Secure Collaboration Systems (Layer 2)</strong> - Balancing security with collaboration needs</p>
|
||||
|
||||
<p><strong>3-4: Failsafe and Offline Methods (Layer 3)</strong> - Backup and emergency communication channels</p>
|
||||
|
||||
<p><strong>3-5: Anonymous Broadcasting (Layer 4)</strong> - Public communications and information distribution</p>
|
||||
|
||||
<p><strong>3-6: Communication Protocol Selection</strong> - Choosing appropriate tools and methods for specific scenarios</p>
|
||||
|
||||
<h3 id="chapter-4-secure-messaging-and-voice-communications-4-1-to-4-8">Chapter 4: Secure Messaging and Voice Communications (4-1 to 4-8)</h3>
|
||||
|
||||
<p>Provides detailed configuration and operational guidance for secure messaging systems:</p>
|
||||
|
||||
<p><strong>4-1: Session Messenger Configuration</strong> - Maximum security messaging with onion routing</p>
|
||||
|
||||
<p><strong>4-2: Element/Matrix Self-Hosted Setup</strong> - Secure collaboration platform implementation</p>
|
||||
|
||||
<p><strong>4-3: Briar Peer-to-Peer Messaging</strong> - Decentralized messaging without servers</p>
|
||||
|
||||
<p><strong>4-4: Signal Security Best Practices</strong> - Operational security for mainstream secure messaging</p>
|
||||
|
||||
<p><strong>4-5: Voice Communication Security</strong> - Secure voice calls and audio communications</p>
|
||||
|
||||
<p><strong>4-6: Group Communication Management</strong> - Security protocols for multi-participant communications</p>
|
||||
|
||||
<p><strong>4-7: Message Verification and Authentication</strong> - Ensuring message integrity and sender verification</p>
|
||||
|
||||
<p><strong>4-8: Communication Scheduling and Protocols</strong> - Operational procedures for secure communications</p>
|
||||
|
||||
<h3 id="chapter-5-file-sharing-and-collaboration-5-1-to-5-6">Chapter 5: File Sharing and Collaboration (5-1 to 5-6)</h3>
|
||||
|
||||
<p>Covers secure systems for document collaboration and file sharing:</p>
|
||||
|
||||
<p><strong>5-1: CryptPad Secure Document Collaboration</strong> - Real-time collaborative editing with encryption</p>
|
||||
|
||||
<p><strong>5-2: OnionShare Anonymous File Transfer</strong> - Secure file sharing over Tor network</p>
|
||||
|
||||
<p><strong>5-3: Encrypted Cloud Storage (Mega/Proton)</strong> - Secure cloud storage for resistance operations</p>
|
||||
|
||||
<p><strong>5-4: Digital Dead Drops</strong> - Asynchronous file sharing without direct contact</p>
|
||||
|
||||
<p><strong>5-5: Version Control for Sensitive Documents</strong> - Managing document versions and changes securely</p>
|
||||
|
||||
<p><strong>5-6: Collaborative Security Protocols</strong> - Operational procedures for secure collaboration</p>
|
||||
|
||||
<h2 id="implementation-approach">Implementation Approach</h2>
|
||||
|
||||
<h3 id="progressive-implementation">Progressive Implementation</h3>
|
||||
|
||||
<p>Part II is designed for progressive implementation, allowing resistance networks to start with basic secure communications and gradually add more sophisticated capabilities:</p>
|
||||
|
||||
<p><strong>Phase 1: Basic Secure Messaging</strong></p>
|
||||
<ul>
|
||||
<li>Implement Signal or Session for basic communications</li>
|
||||
<li>Establish basic operational security procedures</li>
|
||||
<li>Train participants in secure communication practices</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Phase 2: Collaboration Infrastructure</strong></p>
|
||||
<ul>
|
||||
<li>Deploy self-hosted Matrix server for group communications</li>
|
||||
<li>Implement CryptPad for document collaboration</li>
|
||||
<li>Establish file sharing protocols using OnionShare</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Phase 3: Advanced Architecture</strong></p>
|
||||
<ul>
|
||||
<li>Implement full multi-layer communication strategy</li>
|
||||
<li>Deploy Briar for high-security scenarios</li>
|
||||
<li>Establish emergency and backup communication channels</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Phase 4: Operational Integration</strong></p>
|
||||
<ul>
|
||||
<li>Integrate communication systems with operational planning</li>
|
||||
<li>Implement advanced security protocols and procedures</li>
|
||||
<li>Establish training and support systems for network participants</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="security-considerations">Security Considerations</h3>
|
||||
|
||||
<p>Each communication system and protocol covered in Part II includes specific security considerations:</p>
|
||||
|
||||
<p><strong>Technical Security:</strong></p>
|
||||
<ul>
|
||||
<li>Encryption strength and implementation quality</li>
|
||||
<li>Metadata protection and anonymity features</li>
|
||||
<li>Infrastructure security and server hardening</li>
|
||||
<li>Software updates and vulnerability management</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Operational Security:</strong></p>
|
||||
<ul>
|
||||
<li>User authentication and access control</li>
|
||||
<li>Communication protocols and procedures</li>
|
||||
<li>Incident response and compromise recovery</li>
|
||||
<li>Training and security awareness</li>
|
||||
</ul>
|
||||
|
||||
<p><strong>Strategic Security:</strong></p>
|
||||
<ul>
|
||||
<li>Threat model alignment and risk assessment</li>
|
||||
<li>Backup and redundancy planning</li>
|
||||
<li>Legal considerations and jurisdiction issues</li>
|
||||
<li>Long-term sustainability and maintenance</li>
|
||||
</ul>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Communication Discipline</div>
|
||||
<p>The most sophisticated communication systems are worthless without proper operational discipline. All participants must understand and consistently follow communication protocols, security procedures, and operational security practices.</p>
|
||||
</div>
|
||||
|
||||
<h2 id="integration-with-other-parts">Integration with Other Parts</h2>
|
||||
|
||||
<p>Part II builds directly on the foundational principles and threat assessment methodologies covered in Part I:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Core Security Principles</strong> guide the selection and configuration of communication systems</li>
|
||||
<li><strong>Threat Assessment</strong> determines appropriate security levels and tool selection</li>
|
||||
<li><strong>Risk Assessment</strong> informs decisions about acceptable trade-offs between security and usability</li>
|
||||
<li><strong>OpSec Fundamentals</strong> provide the procedural framework for secure communication operations</li>
|
||||
</ul>
|
||||
|
||||
<p>Part II also provides the foundation for the operational security procedures covered in Part III and the advanced techniques covered in Part IV.</p>
|
||||
|
||||
<h2 id="getting-started">Getting Started</h2>
|
||||
|
||||
<h3 id="for-technical-implementation">For Technical Implementation</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Start with threat assessment</strong> to determine appropriate security levels</li>
|
||||
<li><strong>Begin with basic tools</strong> (Signal or Session) before implementing complex systems</li>
|
||||
<li><strong>Test all systems thoroughly</strong> in safe environments before operational use</li>
|
||||
<li><strong>Implement gradually</strong> with proper training and support for all participants</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="for-operational-planning">For Operational Planning</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Map communication requirements</strong> to the four-layer architecture</li>
|
||||
<li><strong>Develop communication protocols</strong> appropriate to your threat environment</li>
|
||||
<li><strong>Establish training programs</strong> for all communication tools and procedures</li>
|
||||
<li><strong>Plan for contingencies</strong> including system compromise and failure scenarios</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="for-network-leadership">For Network Leadership</h3>
|
||||
|
||||
<ol>
|
||||
<li><strong>Assess current communication practices</strong> against security requirements</li>
|
||||
<li><strong>Develop implementation timeline</strong> for improved communication security</li>
|
||||
<li><strong>Allocate resources</strong> for infrastructure, training, and ongoing maintenance</li>
|
||||
<li><strong>Establish governance</strong> for communication system management and security</li>
|
||||
</ol>
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Implementation Priority</div>
|
||||
<p>Focus first on implementing basic secure messaging (Chapter 4) before attempting to deploy complex multi-layer architectures. Solid implementation of fundamental tools is more valuable than poorly implemented advanced systems.</p>
|
||||
</div>
|
||||
|
||||
<hr />
|
||||
|
||||
<p><strong>Ready to begin?</strong> Start with <a href="/chapters/chapter-3/">Chapter 3: Communication Layer Architecture →</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<nav class="section-nav">
|
||||
|
||||
<a href="/chapters/chapter-2/" class="nav-link">
|
||||
<span class="arrow">←</span>
|
||||
<span>Chapter 2: Threat Assessment</span>
|
||||
</a>
|
||||
|
||||
|
||||
|
||||
<a href="/chapters/chapter-3/" class="nav-link">
|
||||
<span>Chapter 3: Communication Architecture</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>
|
||||
|
328
_site/preface/index.html
Normal file
328
_site/preface/index.html
Normal file
|
@ -0,0 +1,328 @@
|
|||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Preface - Field Manual for Resistance Operations</title>
|
||||
<meta name="description" content="Purpose, scope, and guidance for using the Field Manual for Resistance Operations">
|
||||
|
||||
<!-- 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">
|
||||
</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">
|
||||
<div class="nav-section">
|
||||
<h3>Field Manual</h3>
|
||||
<ul>
|
||||
<li><a href="/" >Table of Contents</a></li>
|
||||
<li><a href="/preface/" class="active">Preface</a></li>
|
||||
<li><a href="/introduction/" >Introduction</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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/" >Ch 1: Core Security Principles</a></li>
|
||||
<li><a href="/chapters/chapter-2/" >Ch 2: Threat Assessment</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
|
||||
<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: Network Resilience</a></li>
|
||||
<li><a href="/chapters/chapter-10/" >Ch 10: Counter-Intelligence</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="nav-section">
|
||||
<h3>Appendices</h3>
|
||||
<ul>
|
||||
<li><a href="/appendices/" >Quick Reference</a></li>
|
||||
<li><a href="/appendices/tools/" >Tool Guides</a></li>
|
||||
<li><a href="/appendices/resources/" >External Resources</a></li>
|
||||
<li><a href="/appendices/glossary/" >Glossary</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
</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>
|
||||
|
||||
<h1 id="preface">Preface</h1>
|
||||
|
||||
<h2 id="purpose">Purpose</h2>
|
||||
|
||||
<p>This Field Manual (FM-R1) provides comprehensive guidance for establishing and maintaining secure communication networks within decentralized resistance movements. It is specifically designed for individuals and groups operating under the threat of an authoritarian regime with advanced surveillance capabilities.</p>
|
||||
|
||||
<p>The manual synthesizes proven operational security practices, modern cryptographic tools, and time-tested resistance strategies into a coherent framework that can be implemented by newcomers to resistance operations while remaining valuable to experienced practitioners.</p>
|
||||
|
||||
<h2 id="scope">Scope</h2>
|
||||
|
||||
<p>This manual covers:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Core security principles</strong> fundamental to all resistance operations</li>
|
||||
<li><strong>Threat assessment methodologies</strong> for understanding your operational environment</li>
|
||||
<li><strong>Multi-layer communication architectures</strong> for different security requirements</li>
|
||||
<li><strong>Specific tool configurations</strong> for secure messaging, file sharing, and collaboration</li>
|
||||
<li><strong>Operational security procedures</strong> for maintaining security discipline</li>
|
||||
<li><strong>Advanced techniques</strong> for network resilience and counter-intelligence</li>
|
||||
</ul>
|
||||
|
||||
<p>This manual does <strong>not</strong> cover:</p>
|
||||
|
||||
<ul>
|
||||
<li>Specific tactical operations or direct action planning</li>
|
||||
<li>Legal advice or guidance on laws in specific jurisdictions</li>
|
||||
<li>Physical security beyond basic operational security measures</li>
|
||||
<li>Weapons, explosives, or other kinetic capabilities</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="target-audience">Target Audience</h2>
|
||||
|
||||
<h3 id="primary-audience">Primary Audience</h3>
|
||||
<ul>
|
||||
<li><strong>Newcomers to resistance operations</strong> who need foundational knowledge</li>
|
||||
<li><strong>Cell leaders and coordinators</strong> responsible for communication security</li>
|
||||
<li><strong>Technical personnel</strong> implementing secure infrastructure</li>
|
||||
<li><strong>Training coordinators</strong> developing security education programs</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="secondary-audience">Secondary Audience</h3>
|
||||
<ul>
|
||||
<li><strong>Experienced activists</strong> seeking to improve their security practices</li>
|
||||
<li><strong>Journalists and researchers</strong> working in high-risk environments</li>
|
||||
<li><strong>Civil liberties organizations</strong> operating under surveillance</li>
|
||||
<li><strong>International solidarity groups</strong> supporting resistance movements</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="how-to-use-this-manual">How to Use This Manual</h2>
|
||||
|
||||
<h3 id="for-newcomers">For Newcomers</h3>
|
||||
<ol>
|
||||
<li><strong>Start with the fundamentals</strong>: Read the Introduction and Part I completely before proceeding</li>
|
||||
<li><strong>Follow the progressive structure</strong>: Each chapter builds upon previous knowledge</li>
|
||||
<li><strong>Practice in safe environments</strong>: Test tools and procedures before operational use</li>
|
||||
<li><strong>Seek mentorship</strong>: Connect with experienced practitioners through secure channels</li>
|
||||
<li><strong>Start simple</strong>: Implement basic security measures before advancing to complex systems</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="for-experienced-practitioners">For Experienced Practitioners</h3>
|
||||
<ul>
|
||||
<li>Use as a <strong>reference guide</strong> for specific tools and procedures</li>
|
||||
<li><strong>Adapt recommendations</strong> to your specific threat environment</li>
|
||||
<li><strong>Contribute improvements</strong> through secure feedback channels</li>
|
||||
<li><strong>Train others</strong> using this manual as a curriculum foundation</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="for-technical-implementation">For Technical Implementation</h3>
|
||||
<ul>
|
||||
<li>Follow <strong>configuration guides</strong> in the appendices exactly</li>
|
||||
<li><strong>Test all systems</strong> thoroughly before deployment</li>
|
||||
<li><strong>Maintain operational security</strong> during setup and maintenance</li>
|
||||
<li><strong>Document customizations</strong> securely for future reference</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="security-considerations-for-this-manual">Security Considerations for This Manual</h2>
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Operational Security Warning</div>
|
||||
<p>Accessing, storing, or distributing this manual may be considered suspicious activity by hostile authorities. Take appropriate precautions:</p>
|
||||
<ul>
|
||||
<li>Access only through Tails OS, Tor Browser, or similar anonymizing tools</li>
|
||||
<li>Do not store on personal devices connected to your real identity</li>
|
||||
<li>Share only through secure channels with trusted individuals</li>
|
||||
<li>Consider the legal implications in your jurisdiction</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<h3 id="recommended-access-methods">Recommended Access Methods</h3>
|
||||
<ol>
|
||||
<li><strong>Tails OS</strong> - Boot from USB for maximum anonymity</li>
|
||||
<li><strong>Tor Browser</strong> - Use on a dedicated, clean device</li>
|
||||
<li><strong>Public Wi-Fi</strong> - Access from locations unconnected to your identity</li>
|
||||
<li><strong>Printed copies</strong> - For offline reference, dispose of securely when no longer needed</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="distribution-guidelines">Distribution Guidelines</h3>
|
||||
<ul>
|
||||
<li>Share only with individuals who have demonstrated commitment to resistance operations</li>
|
||||
<li>Use secure communication channels (Signal, Briar, OnionShare) for distribution</li>
|
||||
<li>Verify recipient identity through trusted intermediaries</li>
|
||||
<li>Consider compartmentalization - not everyone needs access to all sections</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="acknowledgments">Acknowledgments</h2>
|
||||
|
||||
<p>This manual builds upon decades of resistance experience and the work of countless individuals who have risked their freedom and lives for justice. Special recognition goes to:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Historical resistance movements</strong> whose strategies inform our approach</li>
|
||||
<li><strong>Digital rights organizations</strong> developing the tools we depend on</li>
|
||||
<li><strong>Security researchers</strong> who identify vulnerabilities and develop countermeasures</li>
|
||||
<li><strong>Current practitioners</strong> who provide feedback and real-world testing</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="feedback-and-updates">Feedback and Updates</h2>
|
||||
|
||||
<p>This manual is a living document that must evolve with changing threats and technologies. Feedback is essential for maintaining its effectiveness and accuracy.</p>
|
||||
|
||||
<h3 id="secure-feedback-channels">Secure Feedback Channels</h3>
|
||||
<ul>
|
||||
<li><strong>Matrix</strong>: Contact @sparticus:weresist.is through Element</li>
|
||||
<li><strong>OnionShare</strong>: Check resist.is for current feedback drop locations</li>
|
||||
<li><strong>Dead drops</strong>: Physical and digital locations announced through secure channels</li>
|
||||
</ul>
|
||||
|
||||
<h3 id="update-distribution">Update Distribution</h3>
|
||||
<ul>
|
||||
<li><strong>Primary source</strong>: git.hacker.supply/Department_of_Internautics/field_guide</li>
|
||||
<li><strong>Mirror sites</strong>: Announced through resistance networks</li>
|
||||
<li><strong>Version control</strong>: Each update includes detailed changelog and verification signatures</li>
|
||||
</ul>
|
||||
|
||||
<h2 id="legal-disclaimer">Legal Disclaimer</h2>
|
||||
|
||||
<p>This manual is provided for educational purposes only. The authors and distributors:</p>
|
||||
|
||||
<ul>
|
||||
<li>Do not advocate for illegal activities in any jurisdiction</li>
|
||||
<li>Cannot be held responsible for how this information is used</li>
|
||||
<li>Recommend consulting legal counsel familiar with your local laws</li>
|
||||
<li>Emphasize that resistance activities carry inherent legal and physical risks</li>
|
||||
</ul>
|
||||
|
||||
<p>Users are solely responsible for understanding and complying with applicable laws in their jurisdiction and for assessing the risks of their activities.</p>
|
||||
|
||||
<hr />
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Getting Started</div>
|
||||
<p>Ready to begin? Proceed to the <strong>Introduction</strong> to understand the threat landscape and fundamental security concepts that underpin all resistance operations.</p>
|
||||
</div>
|
||||
|
||||
<p><strong>Next:</strong> <a href="/introduction/">Introduction →</a></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<nav class="section-nav">
|
||||
|
||||
<div></div>
|
||||
|
||||
|
||||
|
||||
<a href="/introduction/" class="nav-link">
|
||||
<span>Introduction</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>
|
||||
|
1
_site/robots.txt
Normal file
1
_site/robots.txt
Normal file
|
@ -0,0 +1 @@
|
|||
Sitemap: https://guide.resist.is/sitemap.xml
|
40
_site/sitemap.xml
Normal file
40
_site/sitemap.xml
Normal file
|
@ -0,0 +1,40 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<urlset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd" xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
<url>
|
||||
<loc>https://guide.resist.is/chapters/chapter-1/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/chapters/chapter-2/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/chapters/chapter-3/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/chapters/chapter-4/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/chapters/chapter-5/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/parts/part-1/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/parts/part-2/</loc>
|
||||
<lastmod>2025-08-28T19:48:01-04:00</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/</loc>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/introduction/</loc>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://guide.resist.is/preface/</loc>
|
||||
</url>
|
||||
</urlset>
|
500
assets/css/main.scss
Normal file
500
assets/css/main.scss
Normal file
|
@ -0,0 +1,500 @@
|
|||
---
|
||||
---
|
||||
|
||||
// Field Guide for Subversives - Main Stylesheet
|
||||
// Inspired by resist.is design with military field manual structure
|
||||
|
||||
// Color scheme (based on resist.is)
|
||||
$bg-color: #000000;
|
||||
$text-color: #ffffff;
|
||||
$accent-green: #00ff00;
|
||||
$accent-blue: #0066ff;
|
||||
$accent-red: #ff0000;
|
||||
$border-color: #333333;
|
||||
$code-bg: #1a1a1a;
|
||||
$warning-color: #ffaa00;
|
||||
|
||||
// Typography
|
||||
$font-family-base: 'Courier New', 'Monaco', 'Menlo', monospace;
|
||||
$font-family-heading: 'Arial', 'Helvetica', sans-serif;
|
||||
$font-size-base: 16px;
|
||||
$line-height-base: 1.6;
|
||||
|
||||
// Layout
|
||||
$max-width: 1200px;
|
||||
$sidebar-width: 300px;
|
||||
$header-height: 80px;
|
||||
|
||||
// Base styles
|
||||
* {
|
||||
box-sizing: border-box;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
html {
|
||||
font-size: $font-size-base;
|
||||
scroll-behavior: smooth;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: $font-family-base;
|
||||
font-size: $font-size-base;
|
||||
line-height: $line-height-base;
|
||||
color: $text-color;
|
||||
background-color: $bg-color;
|
||||
min-height: 100vh;
|
||||
}
|
||||
|
||||
// Typography
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-family: $font-family-heading;
|
||||
font-weight: bold;
|
||||
margin-bottom: 1rem;
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2.5rem;
|
||||
color: $accent-green;
|
||||
text-align: center;
|
||||
margin-bottom: 2rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 2px;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 2rem;
|
||||
color: $accent-blue;
|
||||
border-bottom: 2px solid $accent-blue;
|
||||
padding-bottom: 0.5rem;
|
||||
margin-top: 2rem;
|
||||
margin-bottom: 1.5rem;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.5rem;
|
||||
color: $accent-green;
|
||||
margin-top: 1.5rem;
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
h4 {
|
||||
font-size: 1.25rem;
|
||||
color: $text-color;
|
||||
margin-top: 1rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
// Links
|
||||
a {
|
||||
color: $accent-blue;
|
||||
text-decoration: none;
|
||||
transition: color 0.3s ease;
|
||||
|
||||
&:hover {
|
||||
color: $accent-green;
|
||||
text-decoration: underline;
|
||||
}
|
||||
|
||||
&:visited {
|
||||
color: lighten($accent-blue, 20%);
|
||||
}
|
||||
}
|
||||
|
||||
// Lists
|
||||
ul, ol {
|
||||
margin-bottom: 1rem;
|
||||
padding-left: 2rem;
|
||||
|
||||
li {
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
// Code and preformatted text
|
||||
code {
|
||||
background-color: $code-bg;
|
||||
color: $accent-green;
|
||||
padding: 0.2rem 0.4rem;
|
||||
border-radius: 3px;
|
||||
font-family: $font-family-base;
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
|
||||
pre {
|
||||
background-color: $code-bg;
|
||||
color: $text-color;
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
overflow-x: auto;
|
||||
margin-bottom: 1rem;
|
||||
border-left: 4px solid $accent-green;
|
||||
|
||||
code {
|
||||
background: none;
|
||||
padding: 0;
|
||||
color: inherit;
|
||||
}
|
||||
}
|
||||
|
||||
// Tables
|
||||
table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
margin-bottom: 1rem;
|
||||
background-color: $code-bg;
|
||||
|
||||
th, td {
|
||||
padding: 0.75rem;
|
||||
text-align: left;
|
||||
border-bottom: 1px solid $border-color;
|
||||
}
|
||||
|
||||
th {
|
||||
background-color: $border-color;
|
||||
color: $accent-green;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
tr:hover {
|
||||
background-color: lighten($code-bg, 5%);
|
||||
}
|
||||
}
|
||||
|
||||
// Layout components
|
||||
.container {
|
||||
max-width: $max-width;
|
||||
margin: 0 auto;
|
||||
padding: 0 1rem;
|
||||
}
|
||||
|
||||
.header {
|
||||
background-color: $bg-color;
|
||||
border-bottom: 2px solid $accent-green;
|
||||
padding: 1rem 0;
|
||||
position: sticky;
|
||||
top: 0;
|
||||
z-index: 100;
|
||||
|
||||
.header-content {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
}
|
||||
|
||||
.logo {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
font-size: 1.5rem;
|
||||
font-weight: bold;
|
||||
color: $accent-green;
|
||||
|
||||
.omega {
|
||||
font-size: 2rem;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
.nav-toggle {
|
||||
display: none;
|
||||
background: none;
|
||||
border: none;
|
||||
color: $text-color;
|
||||
font-size: 1.5rem;
|
||||
cursor: pointer;
|
||||
}
|
||||
}
|
||||
|
||||
.main-layout {
|
||||
display: flex;
|
||||
min-height: calc(100vh - #{$header-height});
|
||||
}
|
||||
|
||||
.sidebar {
|
||||
width: $sidebar-width;
|
||||
background-color: lighten($bg-color, 5%);
|
||||
border-right: 1px solid $border-color;
|
||||
padding: 2rem 1rem;
|
||||
overflow-y: auto;
|
||||
position: sticky;
|
||||
top: $header-height;
|
||||
height: calc(100vh - #{$header-height});
|
||||
|
||||
.nav-section {
|
||||
margin-bottom: 2rem;
|
||||
|
||||
h3 {
|
||||
color: $accent-green;
|
||||
font-size: 1rem;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 1px;
|
||||
}
|
||||
|
||||
ul {
|
||||
list-style: none;
|
||||
padding: 0;
|
||||
|
||||
li {
|
||||
margin-bottom: 0.25rem;
|
||||
|
||||
a {
|
||||
display: block;
|
||||
padding: 0.5rem;
|
||||
border-radius: 3px;
|
||||
transition: background-color 0.3s ease;
|
||||
|
||||
&:hover {
|
||||
background-color: $border-color;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
&.active {
|
||||
background-color: $accent-blue;
|
||||
color: $bg-color;
|
||||
}
|
||||
}
|
||||
|
||||
ul {
|
||||
margin-left: 1rem;
|
||||
margin-top: 0.5rem;
|
||||
|
||||
a {
|
||||
font-size: 0.9rem;
|
||||
color: lighten($text-color, 20%);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
.content {
|
||||
flex: 1;
|
||||
padding: 2rem;
|
||||
max-width: calc(100% - #{$sidebar-width});
|
||||
|
||||
.content-header {
|
||||
margin-bottom: 2rem;
|
||||
padding-bottom: 1rem;
|
||||
border-bottom: 1px solid $border-color;
|
||||
|
||||
.manual-designation {
|
||||
color: $accent-green;
|
||||
font-size: 0.9rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 1px;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
.classification {
|
||||
color: $warning-color;
|
||||
font-size: 0.8rem;
|
||||
text-transform: uppercase;
|
||||
font-weight: bold;
|
||||
}
|
||||
}
|
||||
|
||||
.section-nav {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
margin-top: 3rem;
|
||||
padding-top: 2rem;
|
||||
border-top: 1px solid $border-color;
|
||||
|
||||
.nav-link {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: 0.75rem 1.5rem;
|
||||
background-color: $code-bg;
|
||||
border: 1px solid $border-color;
|
||||
border-radius: 5px;
|
||||
transition: all 0.3s ease;
|
||||
|
||||
&:hover {
|
||||
background-color: $accent-blue;
|
||||
color: $bg-color;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.arrow {
|
||||
font-size: 1.2rem;
|
||||
margin: 0 0.5rem;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Special components
|
||||
.warning-box {
|
||||
background-color: rgba($warning-color, 0.1);
|
||||
border-left: 4px solid $warning-color;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
|
||||
.warning-title {
|
||||
color: $warning-color;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
}
|
||||
|
||||
.info-box {
|
||||
background-color: rgba($accent-blue, 0.1);
|
||||
border-left: 4px solid $accent-blue;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
|
||||
.info-title {
|
||||
color: $accent-blue;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
}
|
||||
|
||||
.success-box {
|
||||
background-color: rgba($accent-green, 0.1);
|
||||
border-left: 4px solid $accent-green;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
border-radius: 0 5px 5px 0;
|
||||
|
||||
.success-title {
|
||||
color: $accent-green;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
}
|
||||
|
||||
.do-dont-list {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 1rem;
|
||||
margin: 1rem 0;
|
||||
|
||||
.do-list, .dont-list {
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
|
||||
h4 {
|
||||
margin-bottom: 0.5rem;
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
ul {
|
||||
margin: 0;
|
||||
padding-left: 1.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
.do-list {
|
||||
background-color: rgba($accent-green, 0.1);
|
||||
border: 1px solid $accent-green;
|
||||
|
||||
h4 {
|
||||
color: $accent-green;
|
||||
}
|
||||
}
|
||||
|
||||
.dont-list {
|
||||
background-color: rgba($accent-red, 0.1);
|
||||
border: 1px solid $accent-red;
|
||||
|
||||
h4 {
|
||||
color: $accent-red;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Footer
|
||||
.footer {
|
||||
background-color: $border-color;
|
||||
padding: 2rem 0;
|
||||
margin-top: 4rem;
|
||||
text-align: center;
|
||||
border-top: 2px solid $accent-green;
|
||||
|
||||
.footer-content {
|
||||
color: lighten($text-color, 20%);
|
||||
font-size: 0.9rem;
|
||||
|
||||
.organization {
|
||||
color: $accent-green;
|
||||
font-weight: bold;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Responsive design
|
||||
@media (max-width: 768px) {
|
||||
.header {
|
||||
.nav-toggle {
|
||||
display: block;
|
||||
}
|
||||
}
|
||||
|
||||
.main-layout {
|
||||
flex-direction: column;
|
||||
}
|
||||
|
||||
.sidebar {
|
||||
width: 100%;
|
||||
position: static;
|
||||
height: auto;
|
||||
display: none;
|
||||
|
||||
&.active {
|
||||
display: block;
|
||||
}
|
||||
}
|
||||
|
||||
.content {
|
||||
max-width: 100%;
|
||||
padding: 1rem;
|
||||
}
|
||||
|
||||
.do-dont-list {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 1.5rem;
|
||||
}
|
||||
}
|
||||
|
||||
// Print styles
|
||||
@media print {
|
||||
body {
|
||||
background: white;
|
||||
color: black;
|
||||
}
|
||||
|
||||
.header, .sidebar, .footer, .section-nav {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.content {
|
||||
max-width: 100%;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
a {
|
||||
color: black;
|
||||
text-decoration: underline;
|
||||
}
|
||||
}
|
||||
|
166
assets/js/main.js
Normal file
166
assets/js/main.js
Normal file
|
@ -0,0 +1,166 @@
|
|||
// Field Guide for Subversives - Main JavaScript
|
||||
|
||||
document.addEventListener('DOMContentLoaded', function() {
|
||||
// Mobile navigation toggle
|
||||
const navToggle = document.getElementById('nav-toggle');
|
||||
const sidebar = document.getElementById('sidebar');
|
||||
|
||||
if (navToggle && sidebar) {
|
||||
navToggle.addEventListener('click', function() {
|
||||
sidebar.classList.toggle('active');
|
||||
});
|
||||
}
|
||||
|
||||
// Smooth scrolling for anchor links
|
||||
const anchorLinks = document.querySelectorAll('a[href^="#"]');
|
||||
anchorLinks.forEach(link => {
|
||||
link.addEventListener('click', function(e) {
|
||||
e.preventDefault();
|
||||
const target = document.querySelector(this.getAttribute('href'));
|
||||
if (target) {
|
||||
target.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
});
|
||||
}
|
||||
});
|
||||
});
|
||||
|
||||
// Add security warning for external links
|
||||
const externalLinks = document.querySelectorAll('a[href^="http"]:not([href*="' + window.location.hostname + '"])');
|
||||
externalLinks.forEach(link => {
|
||||
link.addEventListener('click', function(e) {
|
||||
if (!confirm('You are about to visit an external site. Ensure you are using secure browsing practices. Continue?')) {
|
||||
e.preventDefault();
|
||||
}
|
||||
});
|
||||
|
||||
// Add visual indicator for external links
|
||||
link.setAttribute('title', 'External link - opens in new tab');
|
||||
link.setAttribute('target', '_blank');
|
||||
link.setAttribute('rel', 'noopener noreferrer');
|
||||
});
|
||||
|
||||
// Keyboard navigation
|
||||
document.addEventListener('keydown', function(e) {
|
||||
// Alt + Left Arrow: Previous page
|
||||
if (e.altKey && e.key === 'ArrowLeft') {
|
||||
const prevLink = document.querySelector('.section-nav .nav-link:first-child');
|
||||
if (prevLink && prevLink.href) {
|
||||
window.location.href = prevLink.href;
|
||||
}
|
||||
}
|
||||
|
||||
// Alt + Right Arrow: Next page
|
||||
if (e.altKey && e.key === 'ArrowRight') {
|
||||
const nextLink = document.querySelector('.section-nav .nav-link:last-child');
|
||||
if (nextLink && nextLink.href) {
|
||||
window.location.href = nextLink.href;
|
||||
}
|
||||
}
|
||||
|
||||
// Escape: Close mobile menu
|
||||
if (e.key === 'Escape' && sidebar && sidebar.classList.contains('active')) {
|
||||
sidebar.classList.remove('active');
|
||||
}
|
||||
});
|
||||
|
||||
// Print functionality
|
||||
function addPrintButton() {
|
||||
const contentHeader = document.querySelector('.content-header');
|
||||
if (contentHeader) {
|
||||
const printButton = document.createElement('button');
|
||||
printButton.textContent = 'Print Section';
|
||||
printButton.className = 'print-button';
|
||||
printButton.style.cssText = `
|
||||
background: #333;
|
||||
color: #00ff00;
|
||||
border: 1px solid #00ff00;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 3px;
|
||||
cursor: pointer;
|
||||
font-family: inherit;
|
||||
margin-top: 1rem;
|
||||
`;
|
||||
printButton.addEventListener('click', function() {
|
||||
window.print();
|
||||
});
|
||||
contentHeader.appendChild(printButton);
|
||||
}
|
||||
}
|
||||
|
||||
addPrintButton();
|
||||
|
||||
// Security reminder
|
||||
function showSecurityReminder() {
|
||||
const reminder = document.createElement('div');
|
||||
reminder.style.cssText = `
|
||||
position: fixed;
|
||||
bottom: 20px;
|
||||
right: 20px;
|
||||
background: rgba(255, 170, 0, 0.9);
|
||||
color: #000;
|
||||
padding: 1rem;
|
||||
border-radius: 5px;
|
||||
max-width: 300px;
|
||||
font-size: 0.9rem;
|
||||
z-index: 1000;
|
||||
display: none;
|
||||
`;
|
||||
reminder.innerHTML = `
|
||||
<strong>Security Reminder:</strong> Ensure you're using Tails OS or a secure browser when accessing this guide.
|
||||
<button onclick="this.parentElement.style.display='none'" style="float: right; background: none; border: none; font-size: 1.2rem; cursor: pointer;">×</button>
|
||||
`;
|
||||
document.body.appendChild(reminder);
|
||||
|
||||
// Show reminder after 30 seconds
|
||||
setTimeout(() => {
|
||||
reminder.style.display = 'block';
|
||||
}, 30000);
|
||||
|
||||
// Auto-hide after 10 seconds
|
||||
setTimeout(() => {
|
||||
reminder.style.display = 'none';
|
||||
}, 40000);
|
||||
}
|
||||
|
||||
// Only show security reminder on first visit
|
||||
if (!localStorage.getItem('security_reminder_shown')) {
|
||||
showSecurityReminder();
|
||||
localStorage.setItem('security_reminder_shown', 'true');
|
||||
}
|
||||
|
||||
// Add copy-to-clipboard functionality for code blocks
|
||||
const codeBlocks = document.querySelectorAll('pre code');
|
||||
codeBlocks.forEach(block => {
|
||||
const button = document.createElement('button');
|
||||
button.textContent = 'Copy';
|
||||
button.className = 'copy-button';
|
||||
button.style.cssText = `
|
||||
position: absolute;
|
||||
top: 0.5rem;
|
||||
right: 0.5rem;
|
||||
background: #333;
|
||||
color: #00ff00;
|
||||
border: 1px solid #00ff00;
|
||||
padding: 0.25rem 0.5rem;
|
||||
border-radius: 3px;
|
||||
cursor: pointer;
|
||||
font-size: 0.8rem;
|
||||
`;
|
||||
|
||||
const pre = block.parentElement;
|
||||
pre.style.position = 'relative';
|
||||
pre.appendChild(button);
|
||||
|
||||
button.addEventListener('click', function() {
|
||||
navigator.clipboard.writeText(block.textContent).then(() => {
|
||||
button.textContent = 'Copied!';
|
||||
setTimeout(() => {
|
||||
button.textContent = 'Copy';
|
||||
}, 2000);
|
||||
});
|
||||
});
|
||||
});
|
||||
});
|
||||
|
135
index.md
Normal file
135
index.md
Normal file
|
@ -0,0 +1,135 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Table of Contents"
|
||||
description: "Field Manual for Resistance Operations - A comprehensive guide to secure communication and operational security for decentralized resistance movements"
|
||||
---
|
||||
|
||||
# {{ site.title }}
|
||||
|
||||
<div class="manual-designation" style="text-align: center; margin-bottom: 2rem;">
|
||||
<div style="font-size: 1.2rem; color: #00ff00;">{{ site.manual_designation }}</div>
|
||||
<div style="font-size: 1rem; color: #ffffff;">{{ site.subtitle }}</div>
|
||||
<div style="font-size: 0.9rem; color: #0066ff; margin-top: 1rem;">{{ site.organization }}</div>
|
||||
<div style="font-size: 0.9rem; color: #0066ff;">{{ site.bureau }}</div>
|
||||
<div style="font-size: 0.8rem; color: #ffaa00; margin-top: 1rem;">{{ site.classification }}</div>
|
||||
<div style="font-size: 0.8rem; color: #ffffff;">Version {{ site.version }} - {{ site.date }}</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## Table of Contents
|
||||
|
||||
### Front Matter
|
||||
- **[Preface](/preface/)** - Purpose, scope, and how to use this manual
|
||||
- **[Introduction](/introduction/)** - Threat landscape and security fundamentals
|
||||
|
||||
### Part I: Foundations of Resistance Security
|
||||
- **[Part I Overview](/parts/part-1/)** - Core principles and threat assessment
|
||||
- **[Chapter 1: Core Security Principles](/chapters/chapter-1/)** (1-1 to 1-5)
|
||||
- 1-1: Principle of Least Privilege
|
||||
- 1-2: Need-to-Know Basis
|
||||
- 1-3: Compartmentalization and Cell Structure
|
||||
- 1-4: Zero Trust Verification
|
||||
- 1-5: Metadata Minimization
|
||||
- **[Chapter 2: Threat Assessment and Operational Environment](/chapters/chapter-2/)** (2-1 to 2-4)
|
||||
- 2-1: Understanding Your Adversary
|
||||
- 2-2: Threat Model Development
|
||||
- 2-3: Risk Assessment Framework
|
||||
- 2-4: Operational Security (OpSec) Fundamentals
|
||||
|
||||
### Part II: Secure Communication Systems
|
||||
- **[Part II Overview](/parts/part-2/)** - Multi-layer communication architecture
|
||||
- **[Chapter 3: Communication Layer Architecture](/chapters/chapter-3/)** (3-1 to 3-6)
|
||||
- 3-1: Multi-Layer Communication Strategy
|
||||
- 3-2: High-Risk Real-Time Communication (Layer 1)
|
||||
- 3-3: Secure Collaboration Systems (Layer 2)
|
||||
- 3-4: Failsafe and Offline Methods (Layer 3)
|
||||
- 3-5: Anonymous Broadcasting (Layer 4)
|
||||
- 3-6: Communication Protocol Selection
|
||||
- **[Chapter 4: Secure Messaging and Voice Communications](/chapters/chapter-4/)** (4-1 to 4-8)
|
||||
- 4-1: Session Messenger Configuration
|
||||
- 4-2: Element/Matrix Self-Hosted Setup
|
||||
- 4-3: Briar Peer-to-Peer Messaging
|
||||
- 4-4: Signal Security Best Practices
|
||||
- 4-5: Voice Communication Security
|
||||
- 4-6: Group Communication Management
|
||||
- 4-7: Message Verification and Authentication
|
||||
- 4-8: Communication Scheduling and Protocols
|
||||
- **[Chapter 5: File Sharing and Collaboration](/chapters/chapter-5/)** (5-1 to 5-6)
|
||||
- 5-1: CryptPad Secure Document Collaboration
|
||||
- 5-2: OnionShare Anonymous File Transfer
|
||||
- 5-3: Encrypted Cloud Storage (Mega/Proton)
|
||||
- 5-4: Digital Dead Drops
|
||||
- 5-5: Version Control for Sensitive Documents
|
||||
- 5-6: Collaborative Security Protocols
|
||||
|
||||
### Part III: Operational Security Procedures
|
||||
- **[Part III Overview](/parts/part-3/)** - Hardware, digital hygiene, and operational procedures
|
||||
- **[Chapter 6: Hardware and Infrastructure Security](/chapters/chapter-6/)** (6-1 to 6-8)
|
||||
- 6-1: Untraceable Hardware Acquisition
|
||||
- 6-2: Tails OS Installation and Configuration
|
||||
- 6-3: Device Compartmentalization
|
||||
- 6-4: Physical Security Measures
|
||||
- 6-5: Network Access Security
|
||||
- 6-6: Hardware Disposal and Sanitization
|
||||
- 6-7: Faraday Cage and Signal Blocking
|
||||
- 6-8: Power and Charging Security
|
||||
- **[Chapter 7: Digital Hygiene and Privacy](/chapters/chapter-7/)** (7-1 to 7-6)
|
||||
- 7-1: Browser Security Configuration
|
||||
- 7-2: Search Engine Privacy
|
||||
- 7-3: VPN and Tor Usage
|
||||
- 7-4: Social Media Operational Security
|
||||
- 7-5: Email Security and Anonymous Accounts
|
||||
- 7-6: Digital Footprint Minimization
|
||||
- **[Chapter 8: Operational Procedures](/chapters/chapter-8/)** (8-1 to 8-8)
|
||||
- 8-1: Cell Organization and Management
|
||||
- 8-2: Meeting Security Protocols
|
||||
- 8-3: Coded Language and Communication
|
||||
- 8-4: Surveillance Detection and Evasion
|
||||
- 8-5: Emergency Procedures and Protocols
|
||||
- 8-6: Information Sanitization
|
||||
- 8-7: Operational Planning Security
|
||||
- 8-8: Post-Operation Security Review
|
||||
|
||||
### Part IV: Advanced Resistance Operations
|
||||
- **[Part IV Overview](/parts/part-4/)** - Network resilience and counter-intelligence
|
||||
- **[Chapter 9: Network Resilience and Redundancy](/chapters/chapter-9/)** (9-1 to 9-5)
|
||||
- 9-1: Mesh Network Implementation
|
||||
- 9-2: Offline Communication Systems
|
||||
- 9-3: Emergency Communication Protocols
|
||||
- 9-4: Network Failure Recovery
|
||||
- 9-5: Distributed Infrastructure Planning
|
||||
- **[Chapter 10: Counter-Intelligence and Security Culture](/chapters/chapter-10/)** (10-1 to 10-6)
|
||||
- 10-1: Infiltration Detection and Prevention
|
||||
- 10-2: Information Verification Procedures
|
||||
- 10-3: Security Culture Development
|
||||
- 10-4: Compartmentalized Knowledge Management
|
||||
- 10-5: Trust Networks and Verification
|
||||
- 10-6: Operational Security Training
|
||||
|
||||
### Appendices
|
||||
- **[Appendix A: Quick Reference Guides](/appendices/)** - Emergency checklists and procedures
|
||||
- **[Appendix B: Tool Configuration Guides](/appendices/tools/)** - Step-by-step setup instructions
|
||||
- **[Appendix C: External Resources and Links](/appendices/resources/)** - Recommended tools and organizations
|
||||
- **[Appendix D: Glossary of Terms](/appendices/glossary/)** - Definitions and terminology
|
||||
|
||||
---
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Security Notice</div>
|
||||
<p>This manual contains sensitive information about resistance operations and security practices. Ensure you are accessing this content through secure channels (Tails OS, Tor Browser, or other anonymizing tools) and following proper operational security protocols.</p>
|
||||
</div>
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">For Newcomers</div>
|
||||
<p>If you are new to resistance operations, start with the <strong>Preface</strong> and <strong>Introduction</strong>, then proceed through <strong>Part I: Foundations</strong> before advancing to more technical sections. Each chapter builds upon previous knowledge.</p>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
**Distribution:** This manual is designed for decentralized distribution through secure channels. Share responsibly and only with trusted individuals who have a legitimate need for this information.
|
||||
|
||||
**Updates:** This manual will be updated regularly as new threats emerge and technologies evolve. Check the source repository for the latest version.
|
||||
|
||||
**Support:** For questions or contributions, contact the Bureau of Decentralized Resistance through secure channels only.
|
||||
|
196
introduction.md
Normal file
196
introduction.md
Normal file
|
@ -0,0 +1,196 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Introduction"
|
||||
description: "Threat landscape overview and fundamental security concepts for resistance operations"
|
||||
prev_page:
|
||||
title: "Preface"
|
||||
url: "/preface/"
|
||||
next_page:
|
||||
title: "Part I: Foundations"
|
||||
url: "/parts/part-1/"
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
## The Modern Resistance Environment
|
||||
|
||||
Resistance movements in the 21st century face unprecedented challenges. Unlike historical resistance operations that primarily contended with human intelligence networks and physical surveillance, modern movements must operate within a digital panopticon of mass surveillance, algorithmic analysis, and predictive policing.
|
||||
|
||||
The scenario addressed in this manual—resistance against a technologically advanced authoritarian regime—represents the ultimate stress test for operational security. The adversary possesses:
|
||||
|
||||
- **Total spectrum surveillance** across digital communications
|
||||
- **Massive data processing capabilities** for pattern recognition and network analysis
|
||||
- **Legal and extralegal powers** to compel cooperation from technology companies
|
||||
- **Advanced persistent threat capabilities** for targeted device compromise
|
||||
- **Extensive human intelligence networks** including informants and infiltrators
|
||||
|
||||
### The Digital Battlefield
|
||||
|
||||
Every digital action creates metadata that can be analyzed to reveal:
|
||||
- **Communication patterns** - who talks to whom, when, and how frequently
|
||||
- **Location data** - movement patterns and association networks
|
||||
- **Behavioral profiles** - interests, habits, and predictive models
|
||||
- **Social graphs** - relationship mapping and influence networks
|
||||
- **Operational indicators** - planning cycles and activity patterns
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Critical Understanding</div>
|
||||
<p>The most dangerous misconception in modern resistance is believing that encryption alone provides security. While encryption protects content, metadata analysis can reveal operational structures, timing, and relationships even when communications are encrypted.</p>
|
||||
</div>
|
||||
|
||||
## Fundamental Security Concepts
|
||||
|
||||
### Defense in Depth
|
||||
|
||||
No single security measure is sufficient. Effective resistance security requires multiple overlapping layers:
|
||||
|
||||
1. **Technical measures** - Encryption, anonymization, secure hardware
|
||||
2. **Operational procedures** - Compartmentalization, communication protocols, meeting security
|
||||
3. **Human factors** - Training, security culture, psychological resilience
|
||||
4. **Physical security** - Safe houses, surveillance detection, document security
|
||||
|
||||
### Threat Modeling
|
||||
|
||||
Before implementing any security measures, you must understand:
|
||||
|
||||
**Assets** - What are you protecting?
|
||||
- Lives and freedom of participants
|
||||
- Operational plans and intelligence
|
||||
- Communication networks and infrastructure
|
||||
- Financial resources and supplies
|
||||
|
||||
**Adversaries** - Who are you protecting against?
|
||||
- State security services and law enforcement
|
||||
- Private intelligence contractors
|
||||
- Informants and infiltrators
|
||||
- Hostile political organizations
|
||||
|
||||
**Capabilities** - What can your adversaries do?
|
||||
- Technical surveillance and cyber operations
|
||||
- Physical surveillance and infiltration
|
||||
- Legal powers and extrajudicial actions
|
||||
- Resource advantages and institutional support
|
||||
|
||||
**Consequences** - What happens if security fails?
|
||||
- Arrest, prosecution, and imprisonment
|
||||
- Physical harm or assassination
|
||||
- Network compromise and operational failure
|
||||
- Broader movement suppression
|
||||
|
||||
### The Security-Usability Balance
|
||||
|
||||
Perfect security is incompatible with operational effectiveness. Every security measure introduces complexity, reduces convenience, and creates potential failure points. The art of resistance security lies in finding the optimal balance between:
|
||||
|
||||
- **Security requirements** based on threat assessment
|
||||
- **Operational needs** for communication and coordination
|
||||
- **Human limitations** in following complex procedures
|
||||
- **Resource constraints** in time, money, and technical expertise
|
||||
|
||||
## Core Principles for Resistance Operations
|
||||
|
||||
### 1. Assume Compromise
|
||||
|
||||
Operate under the assumption that some level of compromise is inevitable:
|
||||
- Design systems that remain functional even if partially compromised
|
||||
- Limit the damage any single compromise can cause
|
||||
- Plan for detection and response to security breaches
|
||||
- Maintain operational capability under surveillance
|
||||
|
||||
### 2. Minimize Attack Surface
|
||||
|
||||
Reduce the number of ways you can be compromised:
|
||||
- Use the minimum number of tools and platforms necessary
|
||||
- Limit the amount of sensitive data stored or transmitted
|
||||
- Reduce the number of people with access to critical information
|
||||
- Eliminate unnecessary digital and physical traces
|
||||
|
||||
### 3. Compartmentalization
|
||||
|
||||
Organize information and access on a need-to-know basis:
|
||||
- Structure operations in independent cells
|
||||
- Limit cross-cell knowledge and communication
|
||||
- Use different tools and identities for different purposes
|
||||
- Prevent single points of failure from compromising entire networks
|
||||
|
||||
### 4. Operational Discipline
|
||||
|
||||
Maintain consistent security practices:
|
||||
- Follow established procedures even when inconvenient
|
||||
- Resist the temptation to take shortcuts under pressure
|
||||
- Regularly review and update security practices
|
||||
- Train all participants in proper security procedures
|
||||
|
||||
### 5. Continuous Adaptation
|
||||
|
||||
Security is not a destination but an ongoing process:
|
||||
- Monitor for new threats and vulnerabilities
|
||||
- Update tools and procedures as technology evolves
|
||||
- Learn from security incidents and near-misses
|
||||
- Share knowledge and best practices across the movement
|
||||
|
||||
## The Human Element
|
||||
|
||||
Technology can only provide the foundation for security—human behavior determines whether that foundation holds. The most sophisticated technical measures are worthless if participants:
|
||||
|
||||
- Use personal devices for resistance activities
|
||||
- Discuss sensitive matters in insecure environments
|
||||
- Fail to follow established communication protocols
|
||||
- Compromise operational security for convenience
|
||||
|
||||
### Building Security Culture
|
||||
|
||||
Effective resistance security requires developing a culture where:
|
||||
- Security consciousness becomes second nature
|
||||
- Participants understand the reasoning behind security measures
|
||||
- Peer accountability reinforces proper procedures
|
||||
- Security education is ongoing and practical
|
||||
- Mistakes are treated as learning opportunities rather than failures
|
||||
|
||||
## Scope of This Manual
|
||||
|
||||
This manual provides practical guidance for implementing the security concepts outlined above. It is organized to support both learning and reference use:
|
||||
|
||||
**Part I: Foundations** establishes the theoretical framework and threat assessment methodologies that inform all subsequent technical recommendations.
|
||||
|
||||
**Part II: Communication Systems** provides detailed guidance for implementing secure communication networks using proven tools and techniques.
|
||||
|
||||
**Part III: Operational Security** covers the human and procedural elements necessary to maintain security in practice.
|
||||
|
||||
**Part IV: Advanced Operations** addresses specialized topics for mature resistance networks operating under extreme threat conditions.
|
||||
|
||||
**Appendices** provide quick reference materials, detailed configuration guides, and external resources for continued learning.
|
||||
|
||||
## Getting Started
|
||||
|
||||
The journey from security novice to competent resistance operator requires patience, practice, and mentorship. This manual provides the roadmap, but you must walk the path:
|
||||
|
||||
1. **Master the fundamentals** before attempting advanced techniques
|
||||
2. **Practice in safe environments** before operational deployment
|
||||
3. **Seek guidance** from experienced practitioners
|
||||
4. **Start with basic security measures** and gradually increase complexity
|
||||
5. **Maintain operational security** throughout your learning process
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Learning Path</div>
|
||||
<p>New practitioners should follow this sequence:</p>
|
||||
<ol>
|
||||
<li><strong>Part I</strong> - Understand core principles and threat assessment</li>
|
||||
<li><strong>Chapter 6</strong> - Set up secure hardware and Tails OS</li>
|
||||
<li><strong>Chapter 4</strong> - Configure basic secure messaging</li>
|
||||
<li><strong>Chapter 7</strong> - Implement digital hygiene practices</li>
|
||||
<li><strong>Remaining chapters</strong> - Add capabilities as needed</li>
|
||||
</ol>
|
||||
</div>
|
||||
|
||||
## A Note on Courage
|
||||
|
||||
Resistance requires courage—not the absence of fear, but action in spite of fear. The security measures in this manual cannot eliminate risk; they can only manage it. Every person who chooses resistance accepts some level of danger in service of a greater cause.
|
||||
|
||||
This manual honors that courage by providing the best possible guidance for staying safe while fighting for justice. Use it wisely, share it responsibly, and remember that your security protects not just yourself, but everyone who depends on you.
|
||||
|
||||
---
|
||||
|
||||
**The stakes are high. The tools are available. The choice is yours.**
|
||||
|
||||
**Next:** [Part I: Foundations of Resistance Security →](/parts/part-1/)
|
||||
|
138
preface.md
Normal file
138
preface.md
Normal file
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
layout: default
|
||||
title: "Preface"
|
||||
description: "Purpose, scope, and guidance for using the Field Manual for Resistance Operations"
|
||||
next_page:
|
||||
title: "Introduction"
|
||||
url: "/introduction/"
|
||||
---
|
||||
|
||||
# Preface
|
||||
|
||||
## Purpose
|
||||
|
||||
This Field Manual (FM-R1) provides comprehensive guidance for establishing and maintaining secure communication networks within decentralized resistance movements. It is specifically designed for individuals and groups operating under the threat of an authoritarian regime with advanced surveillance capabilities.
|
||||
|
||||
The manual synthesizes proven operational security practices, modern cryptographic tools, and time-tested resistance strategies into a coherent framework that can be implemented by newcomers to resistance operations while remaining valuable to experienced practitioners.
|
||||
|
||||
## Scope
|
||||
|
||||
This manual covers:
|
||||
|
||||
- **Core security principles** fundamental to all resistance operations
|
||||
- **Threat assessment methodologies** for understanding your operational environment
|
||||
- **Multi-layer communication architectures** for different security requirements
|
||||
- **Specific tool configurations** for secure messaging, file sharing, and collaboration
|
||||
- **Operational security procedures** for maintaining security discipline
|
||||
- **Advanced techniques** for network resilience and counter-intelligence
|
||||
|
||||
This manual does **not** cover:
|
||||
|
||||
- Specific tactical operations or direct action planning
|
||||
- Legal advice or guidance on laws in specific jurisdictions
|
||||
- Physical security beyond basic operational security measures
|
||||
- Weapons, explosives, or other kinetic capabilities
|
||||
|
||||
## Target Audience
|
||||
|
||||
### Primary Audience
|
||||
- **Newcomers to resistance operations** who need foundational knowledge
|
||||
- **Cell leaders and coordinators** responsible for communication security
|
||||
- **Technical personnel** implementing secure infrastructure
|
||||
- **Training coordinators** developing security education programs
|
||||
|
||||
### Secondary Audience
|
||||
- **Experienced activists** seeking to improve their security practices
|
||||
- **Journalists and researchers** working in high-risk environments
|
||||
- **Civil liberties organizations** operating under surveillance
|
||||
- **International solidarity groups** supporting resistance movements
|
||||
|
||||
## How to Use This Manual
|
||||
|
||||
### For Newcomers
|
||||
1. **Start with the fundamentals**: Read the Introduction and Part I completely before proceeding
|
||||
2. **Follow the progressive structure**: Each chapter builds upon previous knowledge
|
||||
3. **Practice in safe environments**: Test tools and procedures before operational use
|
||||
4. **Seek mentorship**: Connect with experienced practitioners through secure channels
|
||||
5. **Start simple**: Implement basic security measures before advancing to complex systems
|
||||
|
||||
### For Experienced Practitioners
|
||||
- Use as a **reference guide** for specific tools and procedures
|
||||
- **Adapt recommendations** to your specific threat environment
|
||||
- **Contribute improvements** through secure feedback channels
|
||||
- **Train others** using this manual as a curriculum foundation
|
||||
|
||||
### For Technical Implementation
|
||||
- Follow **configuration guides** in the appendices exactly
|
||||
- **Test all systems** thoroughly before deployment
|
||||
- **Maintain operational security** during setup and maintenance
|
||||
- **Document customizations** securely for future reference
|
||||
|
||||
## Security Considerations for This Manual
|
||||
|
||||
<div class="warning-box">
|
||||
<div class="warning-title">Operational Security Warning</div>
|
||||
<p>Accessing, storing, or distributing this manual may be considered suspicious activity by hostile authorities. Take appropriate precautions:</p>
|
||||
<ul>
|
||||
<li>Access only through Tails OS, Tor Browser, or similar anonymizing tools</li>
|
||||
<li>Do not store on personal devices connected to your real identity</li>
|
||||
<li>Share only through secure channels with trusted individuals</li>
|
||||
<li>Consider the legal implications in your jurisdiction</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
### Recommended Access Methods
|
||||
1. **Tails OS** - Boot from USB for maximum anonymity
|
||||
2. **Tor Browser** - Use on a dedicated, clean device
|
||||
3. **Public Wi-Fi** - Access from locations unconnected to your identity
|
||||
4. **Printed copies** - For offline reference, dispose of securely when no longer needed
|
||||
|
||||
### Distribution Guidelines
|
||||
- Share only with individuals who have demonstrated commitment to resistance operations
|
||||
- Use secure communication channels (Signal, Briar, OnionShare) for distribution
|
||||
- Verify recipient identity through trusted intermediaries
|
||||
- Consider compartmentalization - not everyone needs access to all sections
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
This manual builds upon decades of resistance experience and the work of countless individuals who have risked their freedom and lives for justice. Special recognition goes to:
|
||||
|
||||
- **Historical resistance movements** whose strategies inform our approach
|
||||
- **Digital rights organizations** developing the tools we depend on
|
||||
- **Security researchers** who identify vulnerabilities and develop countermeasures
|
||||
- **Current practitioners** who provide feedback and real-world testing
|
||||
|
||||
## Feedback and Updates
|
||||
|
||||
This manual is a living document that must evolve with changing threats and technologies. Feedback is essential for maintaining its effectiveness and accuracy.
|
||||
|
||||
### Secure Feedback Channels
|
||||
- **Matrix**: Contact @sparticus:weresist.is through Element
|
||||
- **OnionShare**: Check resist.is for current feedback drop locations
|
||||
- **Dead drops**: Physical and digital locations announced through secure channels
|
||||
|
||||
### Update Distribution
|
||||
- **Primary source**: git.hacker.supply/Department_of_Internautics/field_guide
|
||||
- **Mirror sites**: Announced through resistance networks
|
||||
- **Version control**: Each update includes detailed changelog and verification signatures
|
||||
|
||||
## Legal Disclaimer
|
||||
|
||||
This manual is provided for educational purposes only. The authors and distributors:
|
||||
|
||||
- Do not advocate for illegal activities in any jurisdiction
|
||||
- Cannot be held responsible for how this information is used
|
||||
- Recommend consulting legal counsel familiar with your local laws
|
||||
- Emphasize that resistance activities carry inherent legal and physical risks
|
||||
|
||||
Users are solely responsible for understanding and complying with applicable laws in their jurisdiction and for assessing the risks of their activities.
|
||||
|
||||
---
|
||||
|
||||
<div class="info-box">
|
||||
<div class="info-title">Getting Started</div>
|
||||
<p>Ready to begin? Proceed to the <strong>Introduction</strong> to understand the threat landscape and fundamental security concepts that underpin all resistance operations.</p>
|
||||
</div>
|
||||
|
||||
**Next:** [Introduction →](/introduction/)
|
||||
|
Loading…
Reference in New Issue
Block a user