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.

A personal threat model follows the same logic as the corporate STRIDE work we describe in STRIDE Threat Modeling in Sprints: A Full Microservice Walkthrough, but the central asset shifts: you are the system. List raw assets on 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; the same researcher doxxed by real name on a Russian forum can take permanent damage. That matrix will tell 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.

Define your adversary honestly. 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, scrapers selling your data to brokers. Each one 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 LUKS with an external keyfile and a USB keylogger audit. Do not mix the layers.

With adversary and asset on paper, pick your operating system as a consequence, not as an identity. 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.

Communication deserves its own chapter inside the model. 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. Metadata hygiene from Metadata Hygiene: Stripping EXIF, PDF and Office Before You Publish belongs here too, because a report PDF with the author real name in XMP has burned more researchers than any browser zero day. Run exiftool before every upload, no exceptions.

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