Sophos ITDR Findings untersuchen und bearbeiten

Unter My Products > Identity > Findings zeigt Sophos ITDR die Ergebnisse der Prüfungen gegen die angebundene Identitätsinfrastruktur. Die Tabelle ist standardmässig nach Risiko sortiert. Ein Finding ist dabei weder automatisch der Beweis für eine aktive Kompromittierung noch eine XDR Detection oder ein XDR Case. Es ist ein ITDR-Arbeitsobjekt, das bewertet, im zuständigen Identitätssystem bearbeitet und anschliessend erneut geprüft werden muss.

Der sichere Kurzablauf lautet:

1. Offene Findings nach Risk priorisieren und mit Filtern auf einen überschaubaren Arbeitskorb eingrenzen.
2. Finding Details, Description, Definition und Recommendation lesen; bei Bedarf Rohdaten unter Result und Änderungen unter History prüfen.
3. Auswirkung und Abhängigkeiten im eigenen Umfeld bewerten, bevor man eine Konfiguration ändert.
4. Die Ursache im betroffenen Identitätssystem oder Dienst beheben, nicht nur den ITDR-Status ändern.
5. Den Zustand zuerst beim Provider und danach in ITDR validieren.
6. Ein Finding nur bewusst auf Resolved oder Dismissed setzen. Manuell auf Resolved zu wechseln ist keine Abhilfemassnahme.

Status, Risikostufen und Kategorien richtig lesen

Status

Resolved und Dismissed werden von ITDR nicht mehr als Risiko für die Umgebung gewertet. Sie sind trotzdem fachlich verschieden: Resolved steht für eine behobene Ursache oder ein gemindertes Risiko, Dismissed für eine bewusste Risikoentscheidung.

Risk

Die Risikostufe stammt aus der zugrunde liegenden Prüfung und hilft beim Sortieren. Innerhalb derselben Stufe sollten exponierte privilegierte Identitäten, Hinweise auf kompromittierte Zugangsdaten und Findings mit grossem Wirkungsbereich zuerst untersucht werden. Die konkrete Recommendation bleibt dabei wichtiger als eine pauschale Massnahme.

Category

ITDR verwendet folgende Kategorien. Die Bezeichnungen bleiben in der englischen Sophos-Oberfläche unverändert:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

Die Kategorie beschreibt die Art der Prüfung und kann, wo passend, am MITRE-ATT&CK-Modell ausgerichtet sein. Sie ersetzt weder die Detailanalyse noch die Prüfung, ob eine beobachtete Konfiguration im eigenen Betrieb beabsichtigt ist.

Findings filtern und einen Arbeitskorb bilden

Das einklappbare Filtermenü links neben der Identity Findings-Tabelle kombiniert folgende Filter:

• Risk: Risikostufe des Findings.
• Status: Open, Resolved oder Dismissed.
• Reference Type: Art des betroffenen Objekts.
• Category: Kategorie des Findings.
• Is New: Findings, die innerhalb der letzten sieben Tage erstmals gesehen wurden.
• Finding: Titel des Findings.
• First Seen: Zeitpunkt der ersten Beobachtung.
• Last Seen: Zeitpunkt der letzten Beobachtung.
• Last Modified: Zeitpunkt der letzten Änderung.

Für Reference Type stehen exakt diese Werte zur Verfügung:

• User Object
• Application
• Group Object
• Device Object
• Tenant Configuration

Ausgewählte Filter erscheinen oberhalb der Tabelle. Mit X entfernt man einen einzelnen Filter, mit Clear All alle Filter. Tabelle und URL werden mit der Auswahl dynamisch aktualisiert. Dadurch kann man eine gefilterte URL als Arbeitsansicht speichern oder mit Kollegen teilen. Vor dem Teilen sollte man trotzdem prüfen, ob die Empfänger Zugriff auf denselben Central-Tenant haben und ob die URL in ein dafür freigegebenes Ticket gehört.

Ein brauchbarer erster Arbeitskorb ist Status = Open und anschliessend Risk = Critical beziehungsweise High. Danach grenzt man nach Category, Reference Type oder Is New ein. So bleiben neue kritische Identitätsrisiken sichtbar, ohne ältere offene Punkte zu verlieren.

Ein Finding vollständig untersuchen

Ein Klick auf den Link in der Spalte Findings öffnet das Detailpanel. Es zeigt das zugehörige Objekt, Risiko sowie First Seen, Last Seen, Last Modified und die Empfehlung. Über das New Tab-Symbol öffnet man die vollständige Seite in einem neuen Tab.

Panel und vollständige Ansicht enthalten:

• Finding Details: Zusammenfassung mit Risikostufe, Status, Kommentaren, Zeitstempeln und Tags.
• Description: Beschreibung des Findings.
• Definition: Informationen zur zugehörigen Identitätsprüfung und deren Referenzen.
• Recommendation: Sophos-Empfehlung zur Reduktion des konkreten Risikos.

Für eine belastbare Triage sollte man mindestens folgende Fragen beantworten:

1. Welches Objekt ist betroffen und stimmt Reference Type mit dem erwarteten Objekt überein?
2. Besteht der in Description und Definition beschriebene Zustand noch beim Identitätsanbieter?
3. Wie weit reichen Berechtigungen, Abhängigkeiten und mögliche Auswirkungen einer Änderung?
4. Passt die Recommendation zur eigenen Umgebung und ist die Änderung intern autorisiert?
5. Zeigen First Seen, Last Seen und Last Modified ein neues, wiederkehrendes oder bereits bearbeitetes Problem?

Finding Details zeigt Kommentare und Tags. Für die Findings-Seite beschreibt die Sophos-Dokumentation jedoch weder eine Zuweisungsfunktion noch Bedienelemente zum Erstellen oder Ändern von Kommentaren und Tags. Zuständigkeit und Änderungsnachweis gehören deshalb in das freigegebene Change- oder Ticketsystem; Kommentare ersetzen weder ein Change-Ticket noch den Nachweis der Änderung im Quellsystem.

Result als Rohdaten prüfen

Der Tab Result zeigt die Rohausgabe der ausgeführten Prüfung im JSON-Format. Er ist besonders hilfreich, wenn die Zusammenfassung nicht erkennen lässt, welches Attribut, Objekt oder Ergebnis zur Bewertung geführt hat.

JSON-Schlüssel und Werte sollte man als Befund der konkreten Prüfung lesen und daraus kein allgemeines Schema ableiten. Relevante Objektkennungen, Zustände und Zeitangaben sollten mit der aktuellen Anzeige beim Identitätsanbieter verglichen werden. Sensible Rohdaten gehören nur in freigegebene Tickets oder Untersuchungsnotizen.

Änderungen über History nachvollziehen

Der Tab History zeigt frühere Aktionen am Finding. Mit View Diff öffnet man die exakten Änderungen. Dort lassen sich Statuswechsel und andere Bearbeitungsschritte zeitlich nachvollziehen. So kann man eine unerwartete Wiedereröffnung von einem neuen Finding unterscheiden.

Ursache beheben und Wirkung validieren

⚠️ Vor Änderungen prüfen: Eine Sophos-Empfehlung muss zur eigenen Umgebung, Risikotoleranz und Änderungsfreigabe passen. Änderungen an Rollen, Authentifizierung, Conditional Access, Anwendungen oder anderen Identitätsobjekten können Benutzer, Applikationen und Zugriffe beeinträchtigen. Abhängigkeiten und Rückfallplan deshalb vor der Umsetzung klären.

Die eigentliche Abhilfe findet im System statt, in dem ITDR das Problem erkannt hat, beispielsweise im angebundenen Identitätsanbieter oder im zuständigen Anwendungsdienst. Der Status in ITDR steuert nur den Findings-Workflow. Er ändert die Provider-Konfiguration nicht.

Ein kontrollierter Abschluss besteht aus vier Schritten:

1. Provider-Zustand prüfen: Bestätigen, dass die autorisierte Änderung gespeichert und für das betroffene Objekt wirksam ist.
2. Finding erneut prüfen: Zugehöriges Objekt, Last Seen, Result und History kontrollieren. Ein veralteter oder unveränderter Befund ist noch kein Erfolgsnachweis.
3. Automatisches Verhalten abwarten: Wenn das Finding bei einer erneuten Prüfung nicht mehr erscheint, löst ITDR es automatisch auf und fügt dazu einen Kommentar hinzu. Die Entra-ID-Posture-Checks und Dormant-Resource-Checks laufen im Regelfall alle zwei Stunden; der organisationsweite Risk Posture Score wird täglich aktualisiert.
4. Ergebnis dokumentieren: Provider-Nachweis, Finding-Status, Zeitstempel und gegebenenfalls View Diff im freigegebenen Arbeitsnachweis festhalten. Bleibt das Finding nach einem erwarteten Prüfintervall offen, Provider-Zustand, betroffenes Objekt und JSON-Ergebnis erneut vergleichen, statt den Status wiederholt manuell umzuschalten.

Ein manuell auf Resolved gesetztes Finding kann vom System wieder auf Open gesetzt werden, sobald ITDR denselben Zustand erneut beobachtet. Das ist kein Fehler im Statusmodell, sondern ein Hinweis, dass die Ursache weiterhin vorhanden ist, wieder auftrat oder in den von ITDR ausgewerteten Daten noch sichtbar ist.

Dismissed nur als bewusste Risikoentscheidung verwenden

⚠️ Dismissed unterdrückt weitere Findings: Wird ein Finding verworfen, erzeugt ITDR für dieses Problem am betreffenden Objekt keine neuen Findings. Das Finding bleibt in der Tabelle, wird aber aus dem Dashboard und aus dem organisationsweiten Risk Posture Score ausgeschlossen. Eine vorschnelle Verwerfung kann deshalb ein weiterhin bestehendes oder später erneut relevantes Risiko aus der normalen Sicht nehmen.

Dismissed ist nur sinnvoll, wenn der Zustand erwartet ist, eine Abhilfe nachweislich nicht möglich oder betrieblich nicht vertretbar ist und die zuständige Stelle das Restrisiko akzeptiert. Dazu sollten mindestens Objekt, Begründung, kompensierende Kontrollen, Freigabe und Wiedervorlage ausserhalb von ITDR dokumentiert werden. Ein technisch nicht lösbares Finding kann alternativ Open bleiben; dann bleibt das Risiko im Score und in der laufenden Beobachtung sichtbar.

Credential Compromise priorisieren

Findings zu kompromittierten Accounts werden nur für aktive Identitäten erzeugt. ITDR prüft dafür unter anderem, ob eine aktive Identität vorhanden ist, wann ein Klartextpasswort oder Hash erstmals geleakt wurde und ob dieses Datum nach dem letzten Passwortwechsel liegt. Bei einem Klartextwert wird zusätzlich gegen die globalen Passwortkomplexitätsanforderungen von Microsoft Entra ID geprüft. Rohdaten können unabhängig davon unter Dark Web Intelligence sichtbar sein.

Wenn ein Finding erzeugt wird, bestimmt ITDR die Risikostufe nach Kontotyp, Art des Leaks und MFA-Stärke:

Für die Reihenfolge bedeutet das: Zuerst Critical, danach High bearbeiten; innerhalb derselben Stufe privilegierte Konten und Klartext-Leaks zuerst untersuchen. Ein niedrigerer Wert bei vorhandener oder phishing-resistenter MFA bedeutet nicht, dass das Finding ignoriert werden darf. Die freigegebenen Schutz- und Abhilfemassnahmen werden im zuständigen Identitätssystem und nach dem eigenen Incident-Response-Prozess ausgeführt. Anschliessend werden Provider-Zustand, Finding und Verlauf wie oben beschrieben validiert. Der Status allein bestätigt keine sichere Identität.

Zuständigkeit von Kunde, MDR und XDR trennen

Sophos ITDR ist eine vom Kunden überwachte Lösung. Auch mit separat lizenziertem Sophos MDR bleiben die routinemässige Triage und Verwaltung der Findings beim Kunden. Das MDR Operations Team konzentriert sich auf aktive Identitätsbedrohungen und kann einzelne kritische oder hohe Findings in seine Untersuchung einbeziehen, wenn sie auf eine aktive Bedrohung hindeuten. Daraus folgt weder die automatische Übernahme aller Findings noch die Durchführung von Änderungen beim Identitätsanbieter.

Für jedes eskalierte Finding sollte deshalb eindeutig dokumentiert sein:

• wer die Triage und Risikoentscheidung verantwortet,
• wer Änderungen im Identitätssystem autorisiert und ausführt,
• ob ein Hinweis auf eine aktive Bedrohung an den vereinbarten MDR-Prozess übergeben wurde,
• wer die technische Wirkung und den ITDR-Status abschliessend validiert.

ITDR Findings bleiben dabei von XDR Detections und XDR Cases getrennt. Identitätskontext kann eine weitergehende Untersuchung unterstützen. Status, Kommentare und Abschluss des ITDR-Findings gehören jedoch weiterhin zum ITDR-Arbeitsablauf und sind nicht mit dem XDR- oder MDR-Arbeitsablauf gleichzusetzen.