OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell

Ein Security-Researcher, der mit Tor anfaengt ohne Bedrohungsmodell, landet bei drei Telefonen, fuenf Mailkonten und null echter Anonymitaet. Wir haben das bei Basilisk OffSec mehrfach gesehen: ein Analyst will einen SSRF-Writeup gegen einen Cloud-Provider veroeffentlichen, installiert spontan Whonix, bleibt aber im selben Google-Konto wie immer eingeloggt und laedt Screenshots mit intaktem EXIF hoch. OPSEC ist kein Tool-Shopping, es ist Risikoarbeit. Der Startpunkt sind drei konkrete Fragen: wer will mir schaden, wozu sind diese Akteure technisch faehig und was verliere ich, wenn sie gewinnen. Ohne diese Antworten wird jeder Vergleich zwischen Tails und Qubes zum Theater. Dieser Leitfaden baut die Disziplin von Grund auf neu auf, damit jede Massnahme auf eine dokumentierte Bedrohung zeigt statt auf ein diffuses Gefuehl, privater sein zu muessen.

Was ein persoenliches Bedrohungsmodell wirklich ist

Ein Bedrohungsmodell ist ein strukturiertes Argument darueber, wer dich angreifen koennte, was der Akteur will, wie er es bekommt und was du dagegen tust. Es folgt derselben Logik wie das Corporate-STRIDE-Vorgehen aus STRIDE Threat Modeling im Sprint: Vollstaendiges Beispiel an einem Microservice, aber das zentrale Asset verschiebt sich: du bist das System. Das Ergebnis ist kein Gefuehl, sondern ein lebendes Dokument, idealerweise ein einfaches threat-model.md in einem verschluesselten Vault mit vier Abschnitten: Assets, Gegner, Angriffsvektoren, Gegenmassnahmen. Jede spaeter gekaufte oder konfigurierte Massnahme muss auf eine Zeile in dieser Datei zurueckfuehren. Wenn du die Bedrohung nicht benennen kannst, die ein Tool mildert, sammelst du Werkzeuge statt Risiko zu senken, und die Komplexitaet selbst wird zur Schwachstelle.

Assets mit einer CIA-Matrix inventarisieren

Liste rohe Assets in einer Tabelle: rechtliche Identitaet, Forschungsidentitaeten, operative CTF-Konten, PGP-Schluessel, Krypto-Wallets, physische Geraete, Quellenkontakte, unveroeffentlichte Drafts. Markiere pro Eintrag drei Spalten: Vertraulichkeit, Integritaet, Verfuegbarkeit. Ein Malware-Forscher, der zwei Tage keinen Laborzugang hat, leidet kaum bei der Verfuegbarkeit; derselbe Forscher mit Klarnamen in einem russischen Forum geoutet nimmt dauerhaften Vertraulichkeitsschaden. Diese Matrix sagt, wo Geld in eine Hardware-Wallet (Private Krypto: Hardware Wallets, Passphrase und Zwangsresistentes Backup) sinnvoll ist und wo Paranoia in Kompartimentierung gehoert. Bewerte jedes Asset mit hoch/mittel/niedrig, damit das Dokument Priorisierung erzwingt statt ein Wegwerf-CTF-Handle und deine Wohnadresse gleich sensibel zu behandeln.

Definiere deinen Gegner ehrlich und in Stufen

Die meisten Researcher haben realistisch keinen Staatsgeheimdienst mit NSO Pegasus als Gegner. Sehr wohl aber: einen einzelnen Stalker mit lahmem OSINT, eine Ransomware-Crew, die du auf Twitter veralbert hast, den Anwalt einer Firma, die wegen deines Disclosures wuetend ist, einen Ex-Partner mit physischem Zugriff auf den Heimrouter, Scraper, die deine Daten an Data Broker verkaufen. Modelliere Gegner in Stufen nach Faehigkeit und Motivation: opportunistisch (automatisierte Scraper, Credential-Stuffing), gezielt-amateurhaft (eine Person mit Zeit, wenig Budget) und ressourcenstark (organisierte Kriminalitaet, finanzstarker Klaeger). Gegen den Data Broker ist die Verteidigung buerokratisch und folgt dem Rezept aus Personliche Anti-Doxxing-Sicherheit: Daten von brasilianischen Data Brokers entfernen. Gegen den Ex mit physischem Zugriff sind es Full-Disk-LUKS mit externem Keyfile und ein USB-Keylogger-Audit. Misch die Ebenen nicht.

Angriffsvektoren kartieren, bevor du Massnahmen waehlst

Mit Assets und Gegnern auf Papier zaehlst du die Pfade dazwischen auf. Typische Vektoren fuer einen Researcher sind Kontouebernahme durch Passwort-Wiederverwendung, Geraetekompromittierung durch ein boeses PDF oder ein vergiftetes Labor-Sample, Netzkorrelation, die eine Forschungsidentitaet mit der rechtlichen verknuepft, physischer Zugriff auf ein unverschluesseltes oder suspendiertes Notebook und Social Engineering des Mobilfunkanbieters fuer einen SIM-Swap. Schreibe pro Vektor die aktuelle Exposition und die einzelne wirksamste Gegenmassnahme. SIM-Swap wird geschlagen, indem jeder zweite Faktor von SMS auf Hardware-Keys oder TOTP wandert; Sample-Kompromittierung wird eingedaemmt, indem Malware nie ausserhalb einer isolierten VM detoniert wird. Kontouebernahme wird durch eindeutige Passphrasen pro Dienst plus Passkeys entschaerft, und Netzkorrelation durch strikte Trennung von Tor-Circuits pro Identitaet. Die Vektorliste macht aus abstrakter Angst ein geordnetes Backlog, das du nach Aufwand gegen Wirkung sortierst und Stueck fuer Stueck abarbeitest statt alles gleichzeitig anzugehen.

Das Betriebssystem als Konsequenz waehlen

Waehle das Betriebssystem aus dem Modell, nicht als Identitaets-Abzeichen. Der technische Vergleich in Tails, Whonix oder Qubes OS: Welches fuer Welches OPSEC-Szenario zeigt, dass Tails fuer kurze amnesische Sessions taugt, Whonix fuer Netzisolierung in einer VM, Qubes fuer Kompartimentierung pro Domain. Wer AWS-Writeups schreibt, loest das Problem mit Qubes, einer Qube fuer Credentials und einer weiteren mit Burp plus dem DVWA-Lab aus Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen ohne Drama. Wer ins Feld faehrt und eine Quelle trifft, faehrt mit Tails auf USB-Stick und minimaler Persistenz besser. Alles in ein einziges Ubuntu mit Tor Browser zu schieben ist das schlechteste Modell: hohe Komplexitaet, niedrige Garantien und keine saubere Grenze, wenn eine Identitaet verbrannt ist.

Identitaeten kompartimentieren, damit ein Bruch lokal bleibt

Kompartimentierung begrenzt den Schadensradius am staerksten. Gib jeder Identitaet ein eigenes Browserprofil oder eine eigene Qube, eine eigene Mail, einen eigenen Zahlungsweg und wiederverwende nie einen Nutzernamen. Eine geleakte Forumsbio, die deine Stadt nennt, darf nicht im selben Kontext wie dein rechtliches Banking liegen. Nutze einen Passwortmanager mit getrennten Vaults, erzeuge jedes Konto mit eigener Passphrase und behandle jeden versehentlichen Cross-Login als Vorfall: Credentials rotieren und neu bewerten, was die zwei Identitaeten jetzt teilen. Das Ziel ist, dass die Kompromittierung der lauten CTF-Identitaet einem Angreifer nichts ueber den Researcher verraet, der unter Pseudonym publiziert. In der Praxis heisst das getrennte Zahlungswege, getrennte Wiederherstellungs-Mails und die Regel, dass ein Geraet immer nur eine Identitaet zur Zeit bedient. Notiere im Modell explizit, welche Bruecken zwischen Kontexten unvermeidlich bleiben, etwa ein gemeinsames Bankkonto, und behandle diese bewusst als das schwaechste Glied.

Kommunikations-OPSEC gehoert ins Modell

Kommunikation verdient ein eigenes Kapitel. Signal schuetzt Inhalte, leakt aber den Social Graph ueber die Telefonnummer; SimpleX hat keinen persistenten Identifier; Session laeuft ueber Lokinet. Die Wahl haengt davon ab, mit wem du sprichst und was passiert, wenn Metadaten leaken. Der Vergleich in Kommunikations-OPSEC: Signal, SimpleX und Session Technisch Verglichen liefert Latenzzahlen und Discovery-Modelle. Ergaenze eine simple Regel: jede Forschungsidentitaet bekommt einen eigenen Kanal, niemals Kreuzung mit dem privaten. Registriere Konten auf einem sauberen Geraet, verknuepfe ein Forschungs-Signal nicht mit deiner Haupt-SIM und bevorzuge Kontaktwege, die deine echte Nummer nicht an eine womoeglich selbst kompromittierte Quelle uebergeben.

Metadaten-Hygiene ist nicht optional

Metadaten-Hygiene aus Metadaten-Hygiene: EXIF, PDF und Office vor der Veroffentlichung saubern gehoert hierher, weil ein Report-PDF mit dem echten Autor im XMP mehr Researcher verbrannt hat als jeder Browser-Zero-Day. Lass exiftool -all= bild.jpg vor jedem Upload laufen und pruefe PDFs mit exiftool report.pdf, um Autor, Producer und Erstellungstool zu fangen. Office-Dokumente tragen den Autornamen, die Revisionshistorie und teils den lokalen Benutzernamen im Pfad. Baue den Strip-Schritt in deine Publikationspipeline, damit er per Default passiert, nicht aus dem Gedaechtnis, denn genau das eine vergessene Mal ist das eine Mal, das zaehlt.

Teste das Modell mit OSINT gegen dich selbst

Zum Schluss teste dein Modell, indem du OSINT gegen dich selbst fuehrst. Nutze Maltego und Spiderfoot wie in Ethisches OSINT: Den Eigenen Digitalen Fussabdruck mit Maltego und Spiderfoot Untersuchen beschrieben und starte mit Hauptmail, Twitter-Handle und Handynummer. Wenn du in zehn Minuten an deiner Hausadresse landest, schafft das auch jeder kleinere Gegner. Dokumentiere, was geleakt ist, repariere, was reparierbar ist, und akzeptiere, was bereits oeffentlich ist, indem du das Modell anpasst statt Privatheit vorzutaeuschen. Wiederhole die Uebung quartalsweise und mache ein Diff der Ergebnisse, um zu sehen, ob deine Massnahmen den Fussabdruck wirklich verkleinern.

Eine Zehn-Zeilen-Checkliste fuer heute

Verdichte die Arbeit in eine Checkliste fuer eine Sitzung: schreibe das vierteilige threat-model.md; liste Assets mit CIA-Bewertung; definiere Gegner in Stufen; zaehle Vektoren mit je einer Gegenmassnahme; verschiebe jeden zweiten Faktor von SMS weg; aktiviere Full-Disk-Verschluesselung auf allen Geraeten; trenne mindestens die rechtliche Identitaet von der lautesten Forschungsidentitaet; waehle Messenger pro Identitaet; verdrahte exiftool in die Publikation; und fuehre Selbst-OSINT durch. Hake jede Zeile ab, speichere die Datei verschluesselt und setze eine Kalendererinnerung fuer die quartalsweise Pruefung. Die Checkliste ist bewusst langweilig, weil verlaessliche OPSEC langweilig und wiederholbar ist, nicht clever und fragil.

FAQ: brauche ich Tor und ein VPN zusammen?

Nur wenn dein Modell es verlangt. Tor ueber ein VPN zu stapeln fuegt eine Vertrauensabhaengigkeit zum VPN-Anbieter hinzu und verbessert die Anonymitaet gegen die real relevanten Gegner selten; es verbirgt vor allem die Tor-Nutzung vor deinem Provider. Entscheide aus der Vektorliste: geht es um Netzkorrelation durch einen ressourcenstarken Gegner, ist Tor allein mit Bridges meist die begruendete Antwort, und ein VPN ist eine getrennte Massnahme, um die Tor-Nutzung zu verbergen, keine Verstaerkung der Anonymitaet. Behandle ein Consumer-VPN nie als Anonymitaets-Infrastruktur.

FAQ: wie oft ueberarbeite ich das Modell?

Quartalsweise fuer eine volle Pruefung und sofort nach jeder Lebensaenderung, die deine Assets oder Gegner veraendert: neuer Job, ein oeffentliches Disclosure, ein Umzug, das Ende einer Beziehung mit jemandem, der physischen Zugriff auf deine Geraete hatte. Behandle einen echten Vorfall als erzwungene Pruefung. Das Dokument ist wertlos, wenn es einmal geschrieben und nie angefasst wird, weil sich deine Exposition laufend aendert, waehrend Konten altern, Dienste geleakt werden und neue Data Broker alte Leaks aufnehmen.

Praktisches Takeaway: blocke am Wochenende zwei Stunden, oeffne eine Markdown-Datei threat-model.md, trage Assets, Gegner, Vektoren und Gegenmassnahmen ein und ueberpruefe quartalsweise. Neue Tools erst, wenn dieses Dokument existiert. Die Researcher, die jahrelang unkompromittiert bleiben, haben nicht das exotischste Werkzeug, sondern jene, deren Massnahmen alle auf eine geschriebene, ehrliche Einschaetzung zurueckfuehren, wer wirklich hinter ihnen her ist. Fange klein an, dokumentiere ehrlich und erweitere das Modell, sobald sich deine Lage aendert; genau diese Bescheidenheit unterscheidet echte OPSEC von der Sammlung glaenzender Werkzeuge, die im Ernstfall nichts halten.