Threat Hunting Schweiz: Wenn Detection-Regeln nicht mehr reichen

Threat Hunting ist die hypothesen-getriebene Suche nach Angreifern, die durch bestehende Detection-Regeln schlüpfen. Es ergänzt SIEM- und EDR-Alarme, ersetzt sie nicht. Ziel ist es, die Dauer strukturell zu senken, in der Angreifer unentdeckt bleiben; laut Mandiant M-Trends 2026 liegt dieser Median bei 14 Tagen. Dafür suchen Analysten aktiv nach Tactics, Techniques und Procedures (TTPs), statt auf einen Alarm zu warten.

SOC as a ServiceAlleThreat Hunting Schweiz: Wenn Detection-Regeln nicht mehr reichen

Abgrenzung zu Nachbarthemen

Threat Hunting sucht Angreifer, die bereits im Netz sein könnten. Attack Surface Management reduziert die exponierte Angriffsfläche, damit weniger Angreifer überhaupt einen Fuss in die Tür bekommen. Penetrationstest und Red Team Assessment simulieren Angriffe punktuell und zeitlich begrenzt. Threat Hunting ist eine laufende SOC-Disziplin, kein Projekt.

Warum Detection-Regeln allein zu wenig sind

Detection-Content deckt bekannte Muster ab. Angreifer wissen das und arbeiten bewusst innerhalb der Toleranzen, die eine Regel nicht auslösen. Living-off-the-Land, legitime Admin-Werkzeuge und langsame Aktivitäten in Off-Hours sind darauf ausgelegt, unter der Alarmschwelle zu bleiben. Threat Hunting akzeptiert diese Realität und startet mit einer Hypothese.

Grundprinzip

Alerting fragt: Was ist gerade passiert? Threat Hunting fragt: Wo würde ich mich verstecken, wenn ich hier drin wäre, und wie beweise ich, dass niemand dort ist?

Das Hunt-Modell: Hypothese, Daten, Beweis

Hypothese formulieren, gestützt auf Threat Intelligence, TTPs aus MITRE ATT&CK oder umgebungsspezifisches Wissen (z.B. neu freigegebener SaaS-Zugang, Fusion, Layoffs).
Datengrundlage prüfen: sind die Log-Quellen vollständig, sind Retention und Feldabdeckung ausreichend, wo sind blinde Flecken?
Suche ausführen: Queries im SIEM/XDR, EDR-Telemetrie, Identity- und Cloud-Audit-Logs. Ergebnis ist ein bestätigter Fund, eine widerlegte Hypothese oder eine identifizierte Datenlücke.
Erkenntnis zurückspielen: neue Detection-Regel, Änderung an bestehendem Content, Log-Quelle nachziehen oder Awareness-Thema.
Dokumentieren mit Hypothese, Query, Ergebnis und Datum. Nachweisbar für Audit (ISO 27001 A.5.27, A.8.16) und für die eigene Governance.

Ein realistischer Hunt-Backlog im Schweizer Kontext

Hunt-Thema	MITRE ATT&CK-Bezug	Warum in der Schweiz relevant
Token-Diebstahl und Session Hijacking in M365/Entra	T1550.004, T1539	Hoher M365-Anteil in Schweizer KMU, MFA-Bypass ist der reale Einstiegsvektor.
Business Email Compromise und Mail-Regel-Manipulation	T1114, T1564.008	Verknüpft mit CH-typischen Zahlungsflüssen und Sprachwechsel DE/EN/FR.
Living-off-the-Land: PowerShell, WMI, PsExec-ähnliches Verhalten	T1059.001, T1047, T1021.002	Standard-Admin-Werkzeuge in fast jedem Windows-Netz, klassisch untertriggert.
OAuth-App-Consent und ungewöhnliche Zustimmungen	T1528	Weit verbreitet als Post-MFA-Persistenz, oft ohne Alarm.
Ungewöhnliche Datenexfiltration in Cloud-Speicher	T1567.002	revDSG-Datenkategorien im Fokus, Meldeschwellen können ausgelöst werden.
OT-nahe Auffälligkeiten in Fertigungsumgebungen	T1210, T0886	Schweizer Manufacturing-KMU mit Purdue-Modell und Legacy-Systemen.

Kein Hunt-Backlog ohne Umgebungsbezug. Themen aus Standardliteratur ohne Anpassung an den Kunden ergeben zufällige Funde.

Was Threat Hunting messbar liefert

Neue oder verschärfte Detection-Regeln pro Quartal, direkt aus Hunts abgeleitet.
Identifizierte und geschlossene Log-Lücken, dokumentiert im Coverage-Register.
Reduktion der Zeit, in der ein Angreifer unentdeckt bleiben könnte (Dwell Time).
Nachweise für ISO-27001-Klausel 10 (kontinuierliche Verbesserung) und Annex-A-Controls A.5.27 und A.8.16.

Threat Hunting ohne Rückkopplung in Detection-Content ist Zeitverschwendung. Jeder Hunt endet mit einer der drei Antworten: neue Regel, geschlossene Datenlücke oder widerlegte Hypothese mit Datum. Alles andere bleibt ein Bericht ohne Wirkung. Für die zugrundeliegenden Kennzahlen siehe MTTD und MTTR.

Anti-Muster im Threat Hunting

Hunts ohne Hypothese: freies Wühlen in Logs endet in Alert-Fatigue und produziert keine reproduzierbaren Ergebnisse.
Einmal-Hunts als Marketing-Übung: ein Hunt-Report pro Jahr ist keine Disziplin, sondern eine Momentaufnahme.
Hunts ohne Datenbasis: Fehlen zentrale Log-Quellen, liefern die Suchen falsche Sicherheit.
Hunts ohne Rückkopplung: Funde, die nicht in Detection-Regeln oder Log-Coverage einfliessen, werden beim nächsten Angriff nicht bemerkt.

Einordnung im SOC-Betrieb

Threat Hunting ist Bestandteil eines reifen SOC-Betriebs. Wie ANOMAL Detection, Response und Hunting zusammenführt, steht auf SOC as a Service Schweiz. Für den 24/7-Rahmen siehe SOC 24/7 Betrieb, für die Anbieter-Bewertung SOC-Anbieter Vergleich.

Häufige Fragen

Ist Threat Hunting dasselbe wie ein Pentest?

Nein. Ein Pentest ist ein zeitlich begrenzter, autorisierter Angriff von aussen oder innen, mit dem Ziel Schwachstellen zu finden. Threat Hunting ist die laufende Suche nach echten Angreifern, die bereits im Netz sein könnten. Pentest ist ein Projekt, Hunting ist eine SOC-Disziplin.

Wie oft sollte gejagt werden?

Ein realistischer Rhythmus für Schweizer KMU sind zwei bis vier priorisierte Hunts pro Monat, gemischt aus TTP-getrieben und umgebungsspezifisch. Wichtiger als Frequenz ist Rückkopplung: jeder Hunt endet mit neuer Regel, geschlossener Datenlücke oder widerlegter Hypothese.

Braucht Threat Hunting eigene Werkzeuge?

Nein. SIEM, EDR und Identity-Logs reichen in der Regel, wenn die Log-Qualität stimmt. Zusatzwerkzeuge (Jupyter, Notebook-basierte Analysen, spezialisierte Hunt-Plattformen) helfen bei Reifegraden mit hoher Datenmenge, sind aber nicht Voraussetzung.

Wie belegt man Threat Hunting im Audit?

Über ein Hunt-Register mit Datum, Hypothese, Query, Datenquellen und Ergebnis, verknüpft mit den daraus entstandenen Detection-Regeländerungen. Deckt ISO 27001 A.5.27 (Lernen aus Vorfällen), A.8.16 (Überwachung) und Klausel 10 (kontinuierliche Verbesserung) ab. Für den Gesamtrahmen siehe [ISO 27001 und SOC](/de/soc/iso-27001-und-soc).

Ersetzt KI-gestützte Analyse manuelles Threat Hunting?

Nein, sie verschiebt den Fokus. KI kann Anomalien und Cluster vorschlagen und Analysten entlasten. Die Hypothesenbildung, Umgebungskenntnis und Bewertung bleiben menschliche Aufgaben. Wer nur Modell-Scores verfolgt, bekommt bloss eine weitere Alarmquelle.

Weiterlesen im Cluster

MTTD und MTTR: Die zwei SOC-Kennzahlen, auf die es ankommt

Mean Time to Detect (MTTD) misst, wie schnell ein SOC einen Angriff erkennt. Mean Time to Respond oder Contain (MTTR, MTTC) misst, wie schnell er gestoppt ist. Beide Werte sind der einzige verlässliche Nachweis, dass ein SOC arbeitet und nicht nur läuft.

Wie ein 24/7-SOC in der Praxis funktioniert

Ein 24/7-SOC arbeitet in überlappenden Analystenschichten mit klaren Tiers, Playbooks und einer Eskalationsmatrix bis zur Geschäftsleitung. Alarme laufen aus EDR, Identity, Cloud und Netzwerk in ein zentrales SIEM oder XDR, werden auf L1 triagiert, auf L2/L3 ermittelt und ausserhalb des Kunden-Tenants nie «liegen gelassen». Zielwerte für kritische Fälle: MTTR bis 60 Minuten, MTTC zwischen 1 und 4 Stunden.

SOC-Anbieter vergleichen: die neutrale Auswahl-Checkliste

Ein SOC-Anbieter-Vergleich funktioniert nicht über Logos, sondern über nachprüfbare Kriterien: Datenumfang, Response-Autorität im Kunden-Tenant, Nachweis-Artefakte, Reaktionszeiten und Vertragswerk. Diese Seite listet die Fragen, mit denen Angebote nebeneinander gestellt werden. Bewusst ohne Namen, damit die Checkliste auch dann trägt, wenn ANOMAL nicht auf der Shortlist ist.

Penetrationstest Schweiz: Angriffsflächen finden, bevor Angreifer es tun

Ein Penetrationstest ist eine gezielte Angriffssimulation gegen definierte Systeme, ausgeführt von Schweizer Testern nach dokumentierter Methodik. Ergebnis ist keine Toolausgabe, sondern ein nachvollziehbarer Bericht mit priorisierten Findings, Beweiswert für Regulator und Versicherer, und Empfehlungen, die zur eigenen Umgebung passen. ANOMAL testet Web, Cloud, Active Directory, APIs und interne Netze.

SOC as a Service in der Schweiz: Kompletter Leitfaden

SOC as a Service ist ein extern betriebenes Security Operations Center, das Ihre Umgebung rund um die Uhr überwacht, Angriffe erkennt und die Reaktion auslöst. Laut Mandiant M-Trends 2026 blieben Angreifer 2025 im Median 14 Tage unentdeckt. Mit einem SOC, das rund um die Uhr erkennt und bewertet, liegt die Erkennungszeit deutlich kürzer.

Kurzdefinitionen im Glossar nachschlagen