Trend

ITDR: Identity Threat Detection and Response für die Schweiz

ITDR (Identity Threat Detection and Response) erkennt Angriffe auf Identitäten selbst, nicht nur auf Endpoints oder Netzwerke. Ziel sind Konten, Tokens, Sessions, Berechtigungen und Identity-Provider wie Entra ID oder Okta. ITDR erweitert EDR und SIEM um Signale, die nur im Identity-Layer sichtbar sind: Impossible Travel, Consent-Phishing, Refresh-Token-Missbrauch, Rollen-Missbrauch, Angriffe auf Federation und Directory-Objekte. Für Schweizer Unternehmen mit M365, Entra ID und regulierten Prozessen ist ITDR heute so wichtig wie EDR vor fünf Jahren.

SOC as a ServiceAlleITDR: Identity Threat Detection and Response für die Schweiz

Abgrenzung: ITDR vs Token-Diebstahl vs Glossar

Diese Seite behandelt ITDR als Kategorie: welche Signale erkannt werden, wie ITDR in ein SOC eingebettet wird und wie es sich zu EDR und SIEM verhält. Der konkrete Angriffsvektor Token-Diebstahl (Adversary-in-the-Middle, Refresh-Token-Wiederverwendung, Session-Hijacking) ist auf Token-Diebstahl und Session-Hijacking beschrieben. Für eine Kurzdefinition siehe Glossar ITDR. Für den operativen SOC-Rahmen: SOC as a Service Schweiz.

Kurzform

Token-Diebstahl ist ein Angriff. ITDR ist die Detection- und Response-Disziplin, die solche Angriffe im Identity-Layer sichtbar macht und stoppt.

Welche Signale ITDR erkennt

Signal	Was passiert	Warum EDR/SIEM allein es oft verpasst
Refresh-Token-Wiederverwendung	Ein gestohlener Refresh-Token wird von einem anderen Gerät oder IP-Bereich eingelöst.	Der eigentliche Login sieht sauber aus; nur der Identity-Provider sieht den Kontextwechsel.
Consent-Phishing / OAuth-App-Missbrauch	Nutzer erteilt einer bösartigen App weitreichende Graph-Berechtigungen; Angreifer greift Mail und Files ab.	Kein klassischer Login-Alert, kein Malware-Signal auf dem Endpoint.
Impossible Travel und ungewöhnliche Geolocation	Anmeldung aus Bern und drei Minuten später aus Singapur mit derselben Session.	SIEM sieht Logs, aber ohne Identity-Kontext keine Baseline pro Nutzer.
Privilege-Escalation im Directory	Neue Rollenzuweisung, Hinzufügen zu Global Admins, Änderungen an Conditional-Access-Policies.	Aktion sieht wie normale Admin-Arbeit aus; ITDR unterscheidet erwartet vs anomal.
MFA-Fatigue und Push-Bombing	Angreifer löst wiederholt MFA-Prompts aus, bis der Nutzer bestätigt.	Einzelner fehlgeschlagener Login wirkt harmlos; erst das Muster ist der Alert.
Federation- und Golden-SAML-Angriffe	Angreifer schmiedet SAML-Tokens mit gestohlenem Signing-Zertifikat und umgeht Login komplett.	Nichts auf dem Endpoint, nichts im SIEM-Standardfeed; nur Directory- und Signing-Telemetrie zeigt es.

ITDR im Verhältnis zu EDR, SIEM und MDR

ITDR ersetzt weder EDR noch SIEM noch ein Managed-Detection-Angebot (MDR). Es schliesst die Lücke, die entsteht, wenn Angriffe nicht mehr am Endpoint oder im Netzwerk stattfinden, sondern am Identity-Provider. Ein modernes SOC korreliert ITDR-Signale mit EDR- und SIEM-Signalen: Ein verdächtiger Token-Einsatz gewinnt an Gewicht, wenn der zugehörige Endpoint einen Info-Stealer-Hit hatte. Umgekehrt wird ein EDR-Alert schwerwiegender, wenn parallel ein Consent-Grant auf ein sensitives Postfach erfolgt.

Warum ITDR in der Schweiz jetzt Pflicht wird

M365 und Entra ID sind in Schweizer KMU und Konzernen Standard; Angreifer wissen das und zielen auf die Identity-Ebene, siehe BEC in M365.
Token-Diebstahl umgeht klassisches MFA; ohne ITDR-Signale bleibt der Angriff bis zur Datenabfluss-Phase unbemerkt.
revDSG- und FINMA-Vorgaben verlangen Nachvollziehbarkeit über wer wann was; ohne Identity-Telemetrie ist das nachträglich nicht rekonstruierbar. Siehe revDSG und SOC und SOC & FINMA-Anforderungen.
ISG-Meldepflicht: Kompromittierte Identitäten mit Zugriff auf Personendaten können die 24h-Meldung auslösen, siehe SOC & ISG-Meldepflicht.

So wird ITDR in ein SOC eingebettet

Telemetrie-Anbindung: Sign-In-Logs, Audit-Logs, Risk-Detections, Directory-Änderungen aus Entra ID, Okta oder AD; ergänzt um Graph-Aktivitäten in M365.
Use-Case-Katalog: Token-Replay, Consent-Grants an unbekannte Apps, MFA-Bombing, Rollenwechsel ausserhalb Change-Windows, Session-Nutzung ausserhalb Gerätekontext.
Response-Playbooks: Session-Invalidation, Refresh-Token-Revocation, Passwort-Reset, App-Consent-Widerruf, temporäre Sperre; alle Aktionen dokumentiert und einer verantwortlichen Person zurechenbar.
Korrelation mit EDR und SIEM im SOC-Fall-Prozess; keine isolierten Alerts.
Metriken: MTTD und MTTR auch für Identity-Fälle, nicht nur für Endpoint-Fälle.

Voraussetzung: phishing-resistente MFA

ITDR reduziert Impact, ersetzt aber keine harten Kontrollen. Phishing-resistente MFA (FIDO2, Passkeys, zertifikatsbasiert), Conditional Access mit Geräte-Compliance und Continuous Access Evaluation sind die Grundlage; ITDR erkennt, was trotzdem durchkommt.

Häufige Fragen

Was ist der Unterschied zwischen ITDR und EDR?

EDR beobachtet den Endpoint (Prozesse, Dateien, Speicher). ITDR beobachtet die Identität (Anmeldungen, Tokens, Rollen, Consent-Grants). Angriffe wie Token-Diebstahl oder Consent-Phishing hinterlassen auf dem Endpoint kaum Spuren; sie sind nur im Identity-Layer sichtbar. Siehe auch [EDR](/de/glossar/edr).

Reicht Entra ID Protection als ITDR?

Es ist ein Baustein, kein vollständiges ITDR. Entra ID Protection liefert Risk-Signale (Risky Sign-In, Risky User). Ein SOC braucht zusätzlich Detection-Regeln auf Graph-Aktivitäten, Consent-Grants, App-Registrations sowie Response-Playbooks. Für risikobasierte Erkennung ist mindestens Entra ID P2 nötig.

Wie verhält sich ITDR zu MDR?

MDR ist ein Bereitstellungsmodell (Managed Detection and Response). ITDR ist eine Detection-Kategorie. Ein gutes MDR-Angebot für die Schweiz enthält ITDR-Use-Cases; ein MDR ohne Identity-Coverage ist unvollständig. Siehe [Was ist MDR](/de/soc/was-ist-mdr).

Ist ITDR auch für KMU relevant?

Ja. Sobald M365 oder ein SaaS-Portfolio im Einsatz ist, ist die Identity-Ebene der primäre Angriffsweg. Für KMU lässt sich ITDR pragmatisch als Teil eines Managed SOC beziehen, siehe [SOC für KMU](/de/soc/soc-fuer-kmu).

Welche Response-Aktionen gehören zu ITDR?

Session-Invalidation, Refresh-Token-Revocation, Passwort-Reset, Widerruf bösartiger OAuth-App-Consents, temporäre Sperre, Rollen-Rollback. Jede Aktion muss dokumentiert und im Nachhinein einer verantwortlichen Person zurechenbar sein, damit revDSG- und FINMA-Nachvollziehbarkeit erfüllt ist.

Weiterlesen im Cluster

Token-Diebstahl und Session-Hijacking erkennen und stoppen

Token-Diebstahl bedeutet, dass Angreifer den Session- oder Refresh-Token eines bereits authentifizierten Nutzers stehlen und damit MFA umgehen. Der klassische Weg ist Reverse-Proxy-Phishing (Adversary-in-the-Middle), zunehmend auch Info-Stealer auf dem Endpoint. Ein SOC erkennt das über Token-Nutzung ausserhalb des Nutzerkontexts, nicht über den Login selbst. Verteidigung heisst: phishing-resistente MFA, Continuous Access Evaluation, Token-Bindung und Detection auf Refresh-Token-Wiederverwendung.

Business Email Compromise in Microsoft 365 erkennen und stoppen

Business Email Compromise (BEC) in Microsoft 365 ist selten ein Malware-Fall, sondern eine Kette aus Phishing, Session- oder Token-Diebstahl, Inbox-Regeln und OAuth-Consent-Missbrauch. Ein SOC erkennt BEC über korrelierte Signale aus Entra ID, Exchange Online und Defender for Cloud Apps, nicht über den E-Mail-Text allein. Reaktion heisst: Session widerrufen, Inbox-Regeln entfernen, OAuth-Consents zurückziehen, MFA neu erzwingen, dokumentiert nach ISG- und Versicherungslogik.

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.

Was ist MDR? Managed Detection and Response erklärt

Managed Detection and Response (MDR) ist die verbreitete Bezeichnung für einen Service, der Angriffe erkennt, untersucht und reagiert, inklusive Isolation kompromittierter Systeme. MDR ist kein Werkzeug und keine Plattform, sondern ein Vertrag mit definierten Reaktionspflichten. Bei ANOMAL ist diese Leistung Teil von SOC as a Service.

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.

Kurzdefinitionen im Glossar nachschlagen