OPSEC for Security Researchers: Building a Personal Threat Model

A security researcher who starts with Tor before having a threat model ends up with three phones, five email accounts and zero real anonymity. We have seen this play out repeatedly at Basilisk OffSec: an analyst wants to publish an SSRF writeup against a cloud provider, installs Whonix on impulse, but stays logged into the same Google account they always use and uploads screenshots with EXIF intact. OPSEC is not tool shopping, it is risk engineering. The starting point is answering three concrete questions: who wants to harm me, what are they technically capable of, and what do I lose if they win. Without those answers every Tails versus Qubes comparison turns into theater. This guide rebuilds the discipline from first principles so that every control you deploy maps to a documented threat instead of a vague feeling that you should be more private.

What a personal threat model actually is

A threat model is a structured argument about who might attack you, what they want, how they could get it, and what you will do about it. It borrows directly from the corporate STRIDE work in STRIDE Threat Modeling in Sprints: A Full Microservice Walkthrough, but the central asset shifts: you are the system. The output is not a feeling, it is a living document, ideally a plain threat-model.md in an encrypted vault, containing four sections: assets, adversaries, attack vectors and countermeasures. Every control you later buy or configure must trace back to a line in that file. If you cannot point to the threat a tool mitigates, you are collecting tools, not reducing risk, and complexity itself becomes a vulnerability because you can no longer reason about your own setup.

Inventory your assets with a CIA matrix

List raw assets in a spreadsheet: legal identity, research identities, CTF operational accounts, PGP keys, crypto wallets, physical devices, source contacts, unpublished drafts. For each one mark three columns: confidentiality, integrity, availability. A malware researcher who loses lab access for two days barely suffers on availability; the same researcher doxxed by real name on a Russian forum takes permanent confidentiality damage. That matrix tells you where to spend money on a hardware wallet (Personal Crypto: Hardware Wallets, Passphrase and Coercion-Resistant Backup) and where to spend paranoia on compartmentalization. Rank each asset with a simple high/medium/low so the document forces prioritization rather than treating a throwaway CTF handle and your home address as equally sensitive.

Define your adversary honestly, in tiers

Most researchers do not realistically face a state intelligence service deploying NSO Pegasus. They do face a single stalker with lazy OSINT, a ransomware crew you mocked on Twitter, a corporate lawyer angry about your disclosure, an ex partner with physical access to the home router, and scrapers selling your data to brokers. Model adversaries in tiers by capability and motivation: opportunistic (automated scrapers, credential stuffers), targeted-amateur (an individual with time but little budget), and resourced (organized crime, a well-funded litigant). Each tier demands a different technical response. Against the data broker the defense is bureaucratic and follows the playbook in Anti-Doxxing Personal Security: Removing Data from Brazilian Data Brokers. Against the ex with physical access it is full-disk LUKS with an external keyfile and a USB keylogger audit. Do not mix the layers or you will overspend against one tier while leaving another wide open.

Map attack vectors before choosing controls

With assets and adversaries on paper, enumerate the paths between them. Typical vectors for a researcher are account takeover through password reuse, device compromise through a malicious PDF or a poisoned lab sample, network correlation that links a research identity to the legal one, physical access to an unencrypted or suspended laptop, and social engineering of a mobile carrier for a SIM swap. For each vector write the current exposure and the single most effective mitigation. SIM swap is defeated by moving every second factor off SMS onto hardware keys or TOTP; device compromise from samples is contained by never detonating malware outside an isolated VM as covered in your lab hygiene routine. The vector list is what turns an abstract fear into an ordered backlog.

Choose the operating system as a consequence

Pick your operating system from the model, not as an identity badge. The technical comparison in Tails, Whonix or Qubes OS: Which to Pick for Each OPSEC Scenario shows Tails fits short amnesic sessions, Whonix fits VM network isolation, and Qubes fits per-domain compartmentalization. If you write AWS writeups, Qubes with one qube dedicated to credentials and another running Burp and the DVWA lab from Web Pentesting From Scratch: Building a Safe Lab with DVWA, Juice Shop and Burp Suite solves the problem without drama. If you go into the field to meet a source, Tails on a USB stick with minimal persistence is more defensible. Mixing everything inside a single Ubuntu install with Tor Browser is the worst of both worlds: high complexity, low guarantees, and no clean boundary when one identity is burned.

Compartmentalize identities so a breach stays local

Compartmentalization is the single control that limits blast radius the most. Assign each identity its own browser profile or Qubes qube, its own email, its own payment rail, and never reuse a username across them. A leaked forum bio that mentions your city must not sit in the same context as your legal banking. Use a password manager with distinct vaults, generate every account with a unique passphrase, and treat any accidental cross-login as an incident: rotate credentials and re-evaluate what the two identities now share. The goal is that compromising the noisy CTF identity teaches an attacker nothing about the researcher who publishes under a pseudonym.

Communication OPSEC belongs in the model

Communication deserves its own chapter. Signal protects content but leaks your social graph through the phone number; SimpleX has no persistent identifier; Session runs over Lokinet. The right pick depends on who you talk to and what happens if metadata leaks. The comparison in Comms OPSEC: Signal, SimpleX and Session Technically Compared lists latency numbers and discovery models. Add a simple rule: each research identity has its own channel and never crosses with the personal one. Register accounts on a clean device, avoid linking a research Signal to your primary SIM, and prefer contact methods that do not require handing your real phone number to a source who may themselves be compromised or subpoenaed.

Metadata hygiene is not optional

Metadata hygiene from Metadata Hygiene: Stripping EXIF, PDF and Office Before You Publish belongs here because a report PDF with the author's real name in the XMP block has burned more researchers than any browser zero day. Run exiftool -all= file.jpg on images before every upload and inspect PDFs with exiftool report.pdf to catch author, producer and creation-tool fields. Office documents carry the author name, revision history and sometimes the local username in the path. Build the strip step into your publishing pipeline so it happens by default, not by memory, because the one time you forget is the one time it matters.

Test the model by running OSINT against yourself

Finally, test your model by running OSINT against yourself. Use Maltego and Spiderfoot as described in Ethical OSINT: Investigating Your Own Digital Footprint with Maltego and Spiderfoot, starting from your primary email, Twitter handle and mobile number. If you can reach your home address in ten minutes, any low-tier adversary can too. Document what leaked, fix what is fixable and accept what is already public by adjusting the model instead of pretending it is private. Re-run the exercise quarterly and diff the results so you can see whether your controls are actually shrinking the footprint or just adding friction to your own workflow.

A ten-line checklist to start today

Condense the work into a checklist you can run in one sitting: write the four-section threat-model.md; list assets with a CIA rating; define adversaries in tiers; enumerate vectors with one mitigation each; move every second factor off SMS; enable full-disk encryption on all devices; separate at least the legal identity from the loudest research identity; pick messengers per identity; wire exiftool into publishing; and run self-OSINT. Tick each line, store the file encrypted, and set a calendar reminder to review it every quarter. The checklist is deliberately boring because reliable OPSEC is boring and repeatable, not clever and fragile.

FAQ: do I need Tor and a VPN together?

Only if your model demands it. Stacking Tor over a VPN adds a trust dependency on the VPN provider and rarely improves anonymity against the adversaries most researchers actually face; it mainly hides Tor use from your ISP. Decide from the vector list: if the threat is network correlation by a resourced adversary, Tor alone with bridges is usually the reasoned answer, and a VPN is a separate control for hiding the fact that you use Tor, not a magnification of anonymity. Never treat a consumer VPN as anonymity infrastructure.

FAQ: how often should I revisit the model?

Quarterly for a full review, and immediately after any life change that alters your assets or adversaries: a new job, a public disclosure, a move, a relationship ending with someone who had physical access to your devices. Treat a real incident as a forced review. The document is worthless if it is written once and never touched, because your exposure changes continuously as accounts age, services get breached and new data brokers ingest old leaks.

Practical takeaway: block two hours this weekend, open a markdown file called threat-model.md, fill in assets, adversaries, vectors and countermeasures, and review it every quarter. Buy or install a new tool only after that document exists. The researchers who stay uncompromised for years are not the ones with the most exotic tooling; they are the ones whose every control traces back to a written, honest assessment of who is actually coming for them.