Sophos ITDR Identity Risk Score sicher bewerten

Der Identity Risk Score bewertet das Risiko einer einzelnen Benutzeridentität auf einer Skala von 0 bis 10. Er verbindet die Wahrscheinlichkeit eines Sicherheitsvorfalls mit der möglichen Auswirkung einer kompromittierten Identität. Ein hoher Wert ist deshalb ein Signal für die Priorisierung, aber weder ein Beweis für eine Kompromittierung noch eine automatische Handlungsanweisung.

Für die tägliche Triage gilt: Nach Risk Score absteigend sortieren, die Contributing factors der obersten Identitäten lesen und zuerst offene kritische oder hohe Findings sowie direkt beeinflussbare Security Factors bearbeiten. Der Zahlenwert allein reicht für eine sichere Entscheidung nicht aus.

Wo der Risk Score zu finden ist

Sophos ITDR zeigt den Wert an drei Stellen:

• Unter My Products > Identity > Directory > Identities enthält die Tabelle die Spalte Risk Score. In der Kartenansicht steht der Wert oben rechts auf der jeweiligen Karte.
• Nach Auswahl einer Identität zeigt Identity Details > Summary das Panel Risk Score mit Current score, Contributing factors und dem Zeitpunkt der letzten Berechnung.
• Unter My Products > Identity > Identity Overview kombiniert das Widget Top 5 Risky Users hohe Scores mit offenen Findings. Pro Eintrag erscheinen Identitätsname, offene Findings nach Schweregrad und aktueller Score.

Für eine vollständige Prüfung ist der Weg über Directory > Identities > Identity Details > Summary entscheidend. Das Overview-Widget ist eine kurze Priorisierungshilfe und ersetzt die Detailansicht nicht.

Die fünf Score-Bänder richtig lesen

Die Bandgrenzen sind fest, die Gewichtung der Faktoren jedoch nicht. Aus einer Liste von Attributen lässt sich daher kein exakter Score vorausberechnen. Auch zwei Benutzer mit derselben Funktion können unterschiedliche Werte haben, etwa wegen MFA-Status, administrativer Rollen, Gaststatus, Findings, Anmeldeort oder bisheriger Alert- und Untersuchungsaktivität.

Ein niedriger Score ist ebenfalls keine Sicherheitsgarantie. Er sagt aus, wie das Modell die derzeit verfügbaren Signale bewertet. Fehlende Telemetrie, eine noch nicht aufgebaute Baseline oder ein später entdecktes Finding können die Einordnung verändern.

Welche Identitäten einen Score erhalten

Risk Scores werden derzeit für Active Benutzeridentitäten aus Microsoft Entra ID und lokalem Active Directory berechnet. Für Identitäten, die beim Identity Provider als Deleted oder Disabled geführt werden, erscheint kein Risk Score. Der Score umfasst derzeit keine Anwendungs- oder Service-Principal-Identitäten.

Diese Grenze ist beim Vergleich wichtig: Eine Identität ohne Wert ist nicht automatisch risikoarm. Zuerst Identitätstyp und Status beim angebundenen Identity Provider prüfen. Erst wenn es sich um eine aktive Benutzeridentität handelt, ist ein fehlender Wert ein Diagnosehinweis.

Security Factors und Profile Factors unterscheiden

Das Panel Contributing factors unterscheidet zwei Wirkungsrichtungen:

• Factors raising Risk Score zeigt Faktoren, die den aktuellen Wert erhöhen.
• Factors lowering Risk Score zeigt Faktoren, die ihn senken.

Innerhalb beider Richtungen trennt Sophos zwischen Security Factors und Profile Factors.

Security Factors: zuerst hier handeln

Security Factors beschreiben Sicherheitszustand, Konfiguration und bekannte Aktivität. Direkt beeinflussbar sind insbesondere:

• fehlende MFA;
• MFA ohne passwortlose Methode;
• offene Findings, im Panel als Identity Exposures bezeichnet;
• administrative oder privilegierte Verzeichnisrollen;
• Gaststatus;
• aktive Credential Leaks;
• eine grosse Zahl verknüpfter E-Mail-Adressen.

Weitere Signale sind ein hybrides, aus einem lokalen Verzeichnis synchronisiertes Konto sowie historische Alert- und Untersuchungsaktivität. Diese beiden Punkte sind nicht durch eine einzelne Änderung an der Identität zu beseitigen: Der Hybridstatus beschreibt die Verzeichnisarchitektur, während die Historie frühere Alerts und Untersuchungen abbildet.

Senkend wirken unter anderem durchgesetzte MFA, eine passwortlose MFA-Methode, eine bisherige Historie ohne belastende Alerts oder Untersuchungen, behobene oder als Dismissed markierte Findings, entfernte unnötige Adminrollen und weniger verknüpfte E-Mail-Adressen. Das Modell gewichtet diese Signale; die Liste ist keine additive Punktetabelle.

Profile Factors: Kontext statt Reparaturziel

Profile Factors beziehen sich auf Eigenschaften der Identität, beispielsweise:

• Department;
• Job Title;
• City;
• Employee Type;
• vorhandener oder fehlender Manager;
• VIP-Überwachung, im Panel als High-value identity, prioritize monitoring sichtbar.

Diese Merkmale können den Score erhöhen oder senken, sind aber in der Regel keine sicherheitstechnische Fehlkonfiguration. Abteilung, Funktion oder Standort sollten nicht geändert werden, nur um eine Zahl zu reduzieren. Korrigiert werden dürfen falsche oder veraltete Stammdaten; fachlich richtige Profildaten bleiben bestehen und dienen als Risikokontext.

Leere Felder wie Department, Employee Type oder Job Title sind nicht zwingend neutral. Das Modell kann fehlende Angaben anhand ähnlicher Identitäten berücksichtigen und daraus Risikokontext ableiten. Vollständige und korrekte Verzeichnisdaten liefern deshalb einen präziseren Kontext, garantieren aber weder einen bestimmten Score noch dessen Richtung.

Aktive Credential Leaks, Hybridstatus und VIP-Überwachung können den Score erhöhen, tragen laut Sophos jedoch nicht zur Senkung bei. Auch daraus folgt nicht, dass VIP-Monitoring entfernt werden sollte: Die Kennzeichnung macht eine wertvolle Identität bewusst sichtbarer und sollte nicht als kosmetische Score-Korrektur entfernt werden.

Was No data bedeutet

Zeigt ein Abschnitt im Risk-Score-Panel No data, sind in dieser konkreten Kategorie keine Faktoren aufgeführt. Das bedeutet nicht automatisch, dass für die gesamte Identität keine Daten vorhanden sind oder dass ihre Integration fehlerhaft ist.

Prüfen Sie deshalb nacheinander:

1. Steht No data nur unter einem Teilbereich wie den senkenden Profile Factors?
2. Werden in den anderen Gruppen Faktoren angezeigt?
3. Ist unten im Panel ein plausibler Zeitpunkt für die letzte Berechnung sichtbar?
4. Ist die Identität eine aktive Benutzeridentität?
5. Sind erwartete Verzeichnisattribute und Findings an ihren jeweiligen Stellen vorhanden?

Erst wenn mehrere erwartete Bereiche fehlen, der Berechnungszeitpunkt unplausibel ist oder eine aktive Benutzeridentität gar keinen Score erhält, sollte die Datenbereitstellung der Integration geprüft werden.

Baseline und Berechnungszyklen berücksichtigen

Bei einem neuen Tenant oder einer neu aufgenommenen Benutzeridentität baut ITDR zunächst ein Verhaltensprofil auf. Viele neue Identitäten können deshalb bis zu 30 Tage im Band Informational bleiben. Diese Zeitspanne ist eine mögliche Aufbauphase und keine Wartefrist, während der Findings ignoriert werden dürfen: Offene Findings können auch bei einer neuen Identität zu einem höheren Score führen.

Scores durchlaufen einen täglichen Bewertungszyklus. Zusätzlich kann eine Neuberechnung erfolgen, wenn ITDR eine Kontoänderung beobachtet oder ein Finding geändert wird. Ein Score kann sich auch ohne sichtbare Verzeichnisänderung von einem Tag zum nächsten verschieben, weil das Modell historische Alert- und Untersuchungsaktivität einbezieht und sich deren zeitliche Gewichtung verändert.

Nach dem Beheben eines Findings kann ein aktualisierter Wert kurzfristig erscheinen. Behobene Findings wirken bis zum nächsten täglichen Scoring-Zyklus noch mit reduzierter Gewichtung weiter; die vollständige Auswirkung ist daher erst im Score des Folgetags sichtbar. Aus diesen beiden Mechanismen darf weder eine garantierte Aktualisierungsminute noch eine exakt vorhersagbare Punkteänderung abgeleitet werden.

Grenzen des ML-Modells

Der Risk Score stammt aus einem Machine-Learning-Modell und nicht aus einer festen Checkliste. Faktoren sind nicht gleich gewichtet. Gleiche sichtbare Faktoren müssen deshalb bei zwei Identitäten weder denselben Score noch dieselbe Veränderung erzeugen.

Das Modell wird laut Sophos anhand aggregierter Verhaltens- und Kontosignale der ITDR-Kundenbasis trainiert; der Score einer Identität wird mit den aktuellen Daten des eigenen Tenants berechnet. Für den Betrieb bleiben dennoch klare Grenzen:

• Der Score erklärt Priorität, nicht die Ursache eines Vorfalls. Dafür sind Findings und weitere Untersuchungsergebnisse nötig.
• Ein hoher Wert beweist keine Kompromittierung. Eine privilegierte Identität mit schwacher Posture kann auch ohne beobachtete verdächtige Aktivität hoch eingestuft werden.
• Ein niedriger Wert beweist keine Unbedenklichkeit.
• Die angezeigten Faktoren sind die operative Erklärung für diese Identität, aber keine Formel, aus der sich der Zahlenwert reproduzieren lässt.
• Eine Score-Änderung ist allein kein Nachweis dafür, dass eine Massnahme technisch erfolgreich war.

Der sichere Ansatz lautet deshalb: Ursache im Panel lesen, die zugrunde liegende Konfiguration oder das Finding separat verifizieren und den Score erst danach als zusätzliches Wirkungssignal verwenden.

Identitäten sicher priorisieren

Eine reine Sortierung nach dem höchsten Zahlenwert kann wertvollen Kontext übersehen. Nutzen Sie folgenden Ablauf:

1. Unter Directory > Identities nach Risk Score absteigend sortieren.
2. Bei den obersten Identitäten Identity Details > Summary öffnen.
3. Unter Contributing factors prüfen, ob offene kritische oder hohe Identity Exposures vorhanden sind.
4. Kritische und hohe Findings sowie aktive Credential Leaks vor reinem Profilkontext priorisieren.
5. Bei gleicher Dringlichkeit privilegierte, administrative und als VIP überwachte Identitäten wegen ihrer möglichen Auswirkung zuerst untersuchen.
6. Für jede Massnahme den Ausgangswert, das Band, den Zeitstempel und den konkreten erhöhenden Faktor festhalten.
7. Nur die zugrunde liegende Ursache beheben, nicht den Score kosmetisch optimieren.

Typische sichere Massnahmen sind das Beheben kritischer und hoher Findings an ihrer Ursache, das Durchsetzen von MFA und – wenn möglich – das Bereitstellen einer passwortlosen MFA-Methode. Aktive Credential Leaks werden nach dem freigegebenen Incident-Prozess behandelt. Nicht benötigte Adminrollen werden entzogen, nicht mehr benötigte verknüpfte E-Mail-Adressen entfernt; Gastkonten können bei fachlicher Eignung in verwaltete Konten überführt werden. Jede Änderung benötigt die im eigenen Unternehmen üblichen Freigaben und eine separate Funktionskontrolle.

Wirkung nach einer Massnahme validieren

Eine belastbare Kontrolle trennt technische Wirksamkeit von Modellreaktion:

1. Ausgangszustand sichern: Identität, Current score, Band, Factors raising Risk Score, offene Findings und Zeitstempel der letzten Berechnung notieren.
2. Ursache beheben: Beispielsweise MFA im Identity Provider tatsächlich durchsetzen oder eine unnötige Rolle nach Freigabe entfernen. Nicht mehrere unabhängige Faktoren gleichzeitig ändern, wenn die Wirkung nachvollziehbar bleiben soll.
3. Technischen Zustand prüfen: Im zuständigen System kontrollieren, dass die Änderung wirksam ist. Der Risk Score ist dafür nicht der Primärnachweis.
4. ITDR-Daten prüfen: In Identity Details > Summary bestätigen, dass der betreffende Faktor oder das Finding nach der Verarbeitung korrekt dargestellt wird.
5. Neuberechnung abwarten: Den Zeitstempel unten im Panel beachten. Bei einem behobenen Finding die kurzfristige Aktualisierung prüfen und den nächsten täglichen Zyklus für die vollständige Wirkung berücksichtigen.
6. Ergebnis vergleichen: Score, Band und Faktoren mit dem Ausgangszustand vergleichen. Erwartet wird eine konsistente Darstellung der behobenen Ursache, nicht eine vorab festgelegte Punktzahl.
7. Restursachen bearbeiten: Bleibt der Wert hoch, die übrigen Security Factors, offenen Findings und danach den Profilkontext prüfen.

Die Prüfung ist abgeschlossen, wenn drei Punkte bestätigt sind: Die technische Massnahme ist wirksam, ITDR zeigt den zugrunde liegenden Faktor korrekt an und die nächste Score-Berechnung ist mit den verbleibenden Signalen plausibel.

Troubleshooting bei unerwarteten Scores

Der Score steigt plötzlich stark an

Öffnen Sie zuerst die Detailansicht und suchen Sie unter Factors raising Risk Score nach neuen Identity Exposures, insbesondere kritischen oder hohen Findings. Vergleichen Sie danach MFA, Rollen, Gaststatus, Credential Leaks und den Berechnungszeitpunkt. Ein Sprung beweist keinen Incident, verlangt bei einem kritischen oder hohen Band aber eine zeitnahe Untersuchung.

Der Score sinkt nach der Behebung nicht wie erwartet

Prüfen Sie, ob die Änderung im zuständigen Identity Provider wirklich wirksam ist und ITDR den aktualisierten Faktor bereits zeigt. Bei einem behobenen Finding kann bis zum nächsten täglichen Zyklus eine reduzierte Restgewichtung bestehen. Bleibt der Score danach erhöht, untersuchen Sie die übrigen Faktoren; erwarten Sie keine feste Punktedifferenz für eine einzelne Massnahme.

Der Score ändert sich ohne Verzeichnisänderung

Das ist nicht automatisch ein Fehler. Tägliche Neuberechnung sowie hinzukommende oder alternde Alert- und Untersuchungsaktivität können den Wert verändern. Dokumentieren Sie alten und neuen Score, beide Berechnungszeitpunkte und die angezeigten Faktoren. Erst bei widersprüchlichen Daten oder einem unplausiblen Zeitstempel ist die Integration weiter zu prüfen.

Eine aktive Benutzeridentität hat keinen Score

Bestätigen Sie beim Identity Provider zuerst den Status Active, den Identitätstyp Benutzer und die Zuordnung zur angebundenen Entra-ID- oder Active-Directory-Quelle. Prüfen Sie anschliessend, ob andere aktuelle Attribute derselben Identität in ITDR erscheinen. Deleted, Disabled, Anwendungen und Service Principals liegen ausserhalb des aktuellen Score-Umfangs.

Viele neue Identitäten bleiben Informational

Prüfen Sie Onboarding-Datum und offene Findings. Innerhalb der möglichen Baseline-Phase von bis zu 30 Tagen kann dies normal sein. Offene Findings müssen trotzdem sofort bearbeitet werden. Bleiben viele Identitäten auch nach 30 Tagen im Band Informational, prüfen Sie Berechnungszeitpunkt, angezeigte Faktoren und Datenaktualität, um festzustellen, ob ITDR die erwarteten Signale verarbeitet.

Wenn sich ein unerwarteter Zustand nicht erklären lässt, sichern Sie Identitätsbezeichnung ohne unnötige personenbezogene Zusatzdaten, Quelle, Status, Score, Band, sichtbare Faktoren, Berechnungszeitpunkt, relevante Finding-IDs und den Zeitpunkt der letzten freigegebenen Änderung. Diese Angaben ermöglichen eine gezielte Eskalation, ohne aus dem Score selbst eine nicht belegte Ursache abzuleiten.