<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->

# Operational Security Reference

## Threat Modeling for Privacy

Five-question framework: (1) What to protect? (2) From whom? (3) How likely?
(4) Consequences of failure? (5) Acceptable burden? — assets, adversaries,
capabilities, risks, controls.

Adversary categories for operational privacy:
- **ISP/network observer** — sees DNS queries, connection metadata, SNI
- **Platform/app vendor** — sees content, metadata, account linkage
- **Targeted attacker** — device compromise, phishing, supply chain
- **Legal process** — subpoena to service provider, border crossing device search
- **Mass surveillance** — bulk collection programs (PRISM, MUSCULAR-class)

Controls map to threat tier. Sealed sender protects against platform-level
metadata; VeraCrypt hidden volumes protect against border device searches;
Tor protects against ISP/network observer. Overshooting threat model creates
usability friction without proportionate benefit.

**Anti-pattern:** Applying maximum-security controls uniformly — Tor for Gmail,
Signal for pizza orders. Threat model first; tool selection follows.

---

## LINDDUN Threat Taxonomy

LINDDUN is the privacy equivalent of STRIDE:
- **L**inkability — link data across contexts to profile subject
- **I**dentifiability — identify subject from data
- **N**on-repudiation — subject can't deny their actions
- **D**etectability — infer that data/activity exists
- **D**isclosure — expose personal information beyond intent
- **U**nawareness — subject unaware of processing
- **N**on-compliance — regulatory/policy violations

Apply LINDDUN in data flow diagrams: annotate each flow and store with LINDDUN
properties, identify mitigations (anonymization, encryption, aggregation, access control).

---

## Adversary-Tier Control Mapping

| Threat Tier | Example Adversary | Key Controls |
|---|---|---|
| Network observer | ISP, Wi-Fi operator | Encrypted DNS (DoH/DoT), VPN/Tor, HTTPS-only |
| Platform vendor | Cloud/app provider | E2EE (Signal), client-side encryption (Cryptomator), sealed sender |
| Targeted attacker | APT, stalker | Device hardening, MFA, disappearing messages, safety number verification |
| Legal process | Law enforcement, border agents | VeraCrypt hidden volumes, plausible deniability, minimal data retention |
| Mass surveillance | Intelligence agencies | Tor, air-gapped systems, metadata minimization |

---

## Operational Privacy Principles

1. **Threat model before tool selection** — define adversary capabilities before choosing controls
2. **Proportionate controls** — match security burden to actual risk level
3. **Metadata is content** — protecting message content without protecting metadata is incomplete
4. **Assume compromise** — design workflows assuming any single component may be compromised
5. **Compartmentalization** — separate identities, devices, and contexts to limit blast radius
6. **Verify, don't trust** — verify safety numbers, check certificate transparency, audit linked devices

---

## OpSec Anti-Patterns

- Using Signal with real phone number publicly linked while expecting anonymity
- Encrypting files but leaving filenames/metadata exposed
- Using maximum-security controls uniformly without threat modeling (creates usability friction)
- Trusting public instances of privacy tools (PrivateBin, Yopass) for high-value secrets
- Cross-contaminating identities across browser containers or accounts
- Storing encryption passwords/keyfiles adjacent to encrypted volumes

---
v1.1 | Validated: 2026-03-13
