Sophos ITDR Directory und Identity Details untersuchen

Das Directory von Sophos ITDR ist das Arbeitsinventar für Identitäten, nicht-menschliche Identitäten (NHIs), Gruppen und Geräte, die ITDR aus den verbundenen Identitätsprovidern erfasst. Die Kennzahlenkarten zeigen die Anzahl überwachter Objekte; ein Klick öffnet die entsprechende Sicht. Für eine Untersuchung wechselt man von diesem Gesamtbestand über einen Anzeigenamen zu den Detaildaten des Objekts.

Schnellweg: Unter My Products > Identity > Directory zuerst den richtigen Tab wählen, Suche und Filter anwenden und die Datenherkunft prüfen. Bei einem Benutzer Display Name öffnen, danach in Summary, Activity Log, Findings, Insights, Group Membership und Dark Web Intelligence jeweils eine konkrete Hypothese prüfen. Ein einzelnes Tag, ein hoher Risk Score oder eine ungewöhnliche Anmeldung ist ein Priorisierungssignal, aber allein noch kein Nachweis einer Kompromittierung.

Produktgrenzen vor der Untersuchung klären

Das ITDR Directory ist nicht der Verzeichnisdienst von Sophos Fusion (ehemals Sophos Central). Es zeigt den von der ITDR-Integration oder dem ITDR-Sensor erfassten Sicherheitskontext. Dagegen stellt Global Settings > Platform > Directory service Benutzer und Gruppen für gemeinsam genutzte Central-Funktionen und Produkte bereit. Daraus folgen drei wichtige Grenzen:

• Eine fehlende Identität im ITDR Directory wird nicht durch einen erneuten Central Directory Sync behoben. Zuerst werden die ITDR-Integration, der Providerbestand und dessen Erfassungsstand geprüft.
• Ein Objekt im ITDR Directory ist nicht automatisch ein verwalteter Central-Benutzer und belegt keine Produktzuweisung oder Endpoint-Installation.
• Filter, Tags und das blosse Öffnen von Detailseiten in ITDR ändern keine Entra-ID-, Active-Directory-, Intune- oder Central-Verzeichnisobjekte. Technische Korrekturen erfolgen im führenden System und werden danach in ITDR validiert; davon getrennt können ausdrücklich autorisierte Response-Aktionen über die dafür vorgesehenen Actions-Einstiege verfügbar sein.

Auch Sophos XDR hat einen anderen Zweck. Das ITDR Directory liefert Inventar-, Posture- und Identitätskontext. Eine XDR-Abfrage oder XDR-Investigation korreliert dagegen Telemetrie und Ereignisse aus unterstützten Datenquellen. Activity Log in Identity Details ist deshalb keine vollständige XDR-Timeline, und ein ITDR-Finding ist nicht automatisch eine XDR-Detection. Für eine fallübergreifende Bedrohungsuntersuchung werden bestätigte ITDR-Hinweise mit den verfügbaren XDR-, Endpoint-, Entra- und Netzwerkdaten korreliert, ohne fehlende Telemetrie als unauffälliges Ergebnis zu interpretieren.

Den Directory-Bestand richtig lesen

Der Einstieg unter My Products > Identity > Directory bietet vier fachlich unterschiedliche Tabs:

Suchfelder grenzen die jeweilige Sicht nach Namen ein. Suche und Filter wirken nur auf die angezeigten, von ITDR erfassten Daten. Kein Treffer beweist daher weder die Nichtexistenz beim Provider noch die Löschung eines Objekts. Vor einer Eskalation werden Schreibweise, Tab, aktive Filter, Provider-Tenant und Erfassungszeitpunkt kontrolliert.

Identitäten suchen, sortieren und filtern

Identities kann als Karten- oder Listenansicht dargestellt werden. Standardmässig sind Benutzer alphabetisch sortiert. Über das Sortiermenü lässt sich beispielsweise Risk Score absteigend wählen, um die zuerst zu untersuchenden Identitäten zu finden. Search Identities filtert nach Namen.

Welche Filter sinnvoll sind, hängt von der Untersuchung ab. Für die erste Priorisierung grenzen Status den vom Identitätsprovider gemeldeten Kontostatus und Risk Severity den Bereich des berechneten Risk Score ein. Is Admin steht für den vom Provider beziehungsweise anhand erkannter privilegierter Rollen gesetzten Admin-Kontext, Is VIP für die Auswahl zum VIP Monitoring und Is Compromised für vorhandene aktive Zugangsdaten-Leaks. Is Dormant findet Konten, für die seit mehr als 90 Tagen keine Anmeldung erfasst wurde.

Für die Einordnung des Kontos stehen Department und Employee Type als Organisationsattribute zur Verfügung, sofern der Provider sie liefert. Is Guest kennzeichnet ein Gastkonto beim Identitätsprovider; Is Cloud Only ein Konto, das nur beim Cloud-Identitätsprovider und ohne lokale Identifikatoren vorhanden ist. Den MFA-Kontext liefern Has MFA, Has Passwordless MFA, Primary MFA Method und MFA Method. Nach beim Provider gepflegten Ortsattributen filtern Country und Region.

Ein leerer Filterwert ist kein negatives Ergebnis. Wenn der Provider ein Attribut nicht liefert, die Lizenz den API-Zugriff begrenzt oder Microsoft aktualisierte Daten noch nicht bereitgestellt hat, kann ITDR das Feld nicht zuverlässig befüllen. Dies gilt besonders für MFA-, Admin-, Geräte- und Aktivitätsdaten.

In der Kartenansicht blendet der Pfeil am Kartenende weitere Informationen ein; jeweils nur eine Karte kann erweitert sein. In der Listenansicht erweitert der Pfeil links eine Zeile. Über das Spaltenmenü lassen sich Spalten anheften, automatisch dimensionieren, zurücksetzen, hinzufügen oder entfernen. Diese Darstellungseinstellungen verändern weder das Objekt noch seine Bewertung.

Wenn Response-Aktionen zuvor autorisiert wurden, stehen sie für einen Benutzer über Actions in der erweiterten Karte oder über die Spalte Actions in der Listenansicht zur Verfügung. Ob ein Einstieg beziehungsweise eine Aktion verfügbar ist, hängt von Identitätsstatus und Konfiguration ab; die Ausführung setzt zudem die erforderliche Operatorberechtigung und den internen Freigabeprozess voraus. Filter, Tags und das Öffnen von Details bleiben davon getrennte, nicht verändernde Funktionen. Nach einer ausgeführten Aktion werden das Ergebnis im führenden Provider und anschliessend der aktualisierte Zustand in ITDR geprüft.

Icons und Tags als Kontext, nicht als Urteil verwenden

Icons kennzeichnen User, MFA User, Deleted User, Locked User, Admin oder Guest. Die zusätzlichen Tags beschreiben verschiedene Eigenschaften und sind nicht als gemeinsames Risikourteil zu lesen: Admin bedeutet, dass das Konto als Administrator erkannt wurde, Guest bezeichnet einen Gast im Tenant, Deleted User ein beim Provider gelöschtes und Locked User ein deaktiviertes Konto.

MFA User steht für aktivierte MFA, Compromised für einen aktiven Zugangsdaten-Leak und Dormant Account für eine Identität ohne erfasste Anmeldung in den letzten 90 Tagen. Cloud Only bedeutet, dass keine lokalen Identifikatoren vorhanden sind; bei Hybrid sind lokale Identifikatoren vorhanden und zwischen Cloud und lokaler Umgebung synchronisiert. Human ordnet die Identität einem menschlichen Benutzer zu, VIP kennzeichnet die Konfiguration für VIP Monitoring.

Human und Non Human sind Klassifikationstags, keine Risikostufen. Ein menschliches Konto repräsentiert eine Person. Zu NHI gehören insbesondere Service Principals, Anwendungen, Agent Identities, Agent Identity Blueprints und andere Maschinenidentitäten. Die NHI-Objekte werden in Non-Human Identities untersucht. Ein optionales, mit einem Agenten gepaartes Benutzerkonto erscheint dagegen in Identities mit dem Tag Agent Identity. Dass ein Anzeigename wie eine Person oder ein Dienst klingt, ist keine belastbare Klassifikation.

Application Object und Service Principal unterscheiden

Ein Microsoft-Entra-Application Object ist die globale Definition einer registrierten Anwendung in ihrem Home-Tenant. Es beschreibt unter anderem die Identitätskonfiguration der Anwendung und besitzt eine App beziehungsweise Client ID. Bei einem Service Principal des Typs Application ist der Service Principal die konkrete lokale Instanz dieser Anwendung in einem bestimmten Tenant. Dieser Typ referenziert das Application Object und bestimmt im betreffenden Tenant, was die App tun darf, wer darauf zugreifen kann und auf welche Ressourcen sie zugreifen darf. Diese Zuordnung gilt nicht für jeden Service-Principal-Typ: Ein Service Principal des Typs Managed identity hat kein zugeordnetes Application Object; ein Legacy Service Principal hat keine zugeordnete App-Registrierung.

Die Sicht Non-Human Identities umfasst die von ITDR abgerufenen Enterprise Applications, weitere Service Principals und Microsoft-Entra-Agent-ID-Objekte im überwachten Entra-Tenant. Sie ist weder auf Service Principals des Typs Application beschränkt noch eine zweite Liste globaler App-Registrierungen. Daraus folgt aber keine Garantie, dass jedes beim Provider vorhandene Objekt bereits erfasst wurde. Nicht jeder dargestellte NHI-Kontext besitzt eine App-Registrierung. Eine mehrmandantenfähige Anwendung kann ein Application Object im Home-Tenant, aber je einen eigenen Service Principal des Typs Application in mehreren konsumierenden Tenants besitzen. Deshalb müssen Display Name, Tenant, App/Client ID, Object ID, Owner und Berechtigungen zusammen verglichen werden. Gleiche Namen bedeuten nicht dasselbe Objekt; unterschiedliche lokale Service Principals dieses Typs können auf dieselbe globale Anwendung verweisen.

NHIs filtern und Non-Human Identity Details lesen

Search Non-Human Identities grenzt die Sicht nach Namen ein. Für eine gezielte Prüfung stehen folgende Filter zur Verfügung:

• Status: Providerstatus, beispielsweise Active, Disabled oder Deleted.
• Resource Type: zugrunde liegender Objekttyp, beispielsweise Application, ServiceIdentity, ManagedIdentity, SocialIdp oder Legacy. Diese UI-Werte dürfen nicht mit einer Garantie für eine zugehörige App-Registrierung verwechselt werden.
• Has Password Credentials: ob ein Passwort-Credential konfiguriert ist.
• Has Key Credentials: ob ein Zertifikat-Credential konfiguriert ist.
• Is Agent: ob das Objekt als Agent Identity oder Agent Identity Blueprint Principal klassifiziert ist.
• Agent Type: Auswahl von Agent Identity oder Blueprint Principal.

Für den Agentenbestand beginnt man beispielsweise mit Is Agent, wählt dann den benötigten Agent Type und öffnet Display Name. Die Credential-Filter beschreiben die Konfiguration des jeweiligen Objekts, nicht die Gültigkeit seiner Credentials oder einen erfolgreichen Authentifizierungstest. Gerade bei Agenten muss der übergeordnete Blueprint mitbetrachtet werden; ein Agent ohne eigenes Passwort ist nicht automatisch ein Objekt ohne Zugriffsmöglichkeiten.

Mit Display Name öffnet man Non-Human Identity Details. Unter Details ist der Anzeigename mit dem Objekt im Microsoft Entra admin center verknüpft. Status zeigt aktiv, deaktiviert oder gelöscht; Type den zugrunde liegenden Ressourcentyp, beispielsweise Application oder ServiceIdentity. Created At, Updated At und Deleted At ordnen den Objektlebenszyklus zeitlich ein. Diese Metadaten sind keine Anmeldeereignisse.

App Owners listet Benutzer oder Service Principals mit technischer administrativer Kontrolle über Credentials, Konfiguration und Berechtigungen. Pro Eintrag werden Anzeigename, Benutzertyp, Rolle, Abteilung und Status gezeigt. Findings enthält die zum NHI gehörenden Findings nach Risiko; ein Klick öffnet deren Details. Für Statusentscheidungen und die anschliessende Validierung gilt der Findings-Arbeitsablauf.

Unter Permissions trennt man Application Permissions – direkt gewährte App-only-Berechtigungen – von Delegated Permissions, die im Namen eines angemeldeten Benutzers gelten. Beide Tabellen zeigen API-Name, Claim-Wert, Berechtigung, Berechtigungstyp und Gewährungsdatum. Eine auffällige Berechtigung wird im Provider gegen den vorgesehenen Geschäftszweck, den Publisher, den Consent und den zuständigen Owner validiert. Die Directory-Anzeige selbst widerruft keinen Consent und entfernt keine Berechtigung.

Agent Identity Blueprint, Blueprint Principal und Laufzeitidentität

Ein auf Microsoft Entra Agent ID aufgebauter Agent besteht aus zusammengehörigen Objekten, nicht aus einer einzigen App-Registrierung:

• Der Agent Identity Blueprint ist der Container für Credentials und Policies, aus dem ein oder mehrere Agenten bereitgestellt werden. Er enthält die Anmeldedaten.
• Der Blueprint Principal ist der beim Hinzufügen des Blueprints im Tenant angelegte Datensatz. Über ihn wird der Blueprint im Tenant verwaltet und auditiert.
• Die Agent Identity ist die tatsächliche Laufzeitidentität des KI-Agenten. Sie hält kein eigenes Passwort oder Secret, sondern verwendet für die Authentifizierung ein Token über den übergeordneten Blueprint.

Bei Agent Identities und Blueprint Principals zeigt Details zusätzlich Agent: Yes und Semantic role mit Agent Identity oder Blueprint Principal. Blueprint lineage ist in den NHI-Details nur bei Agent Identities vorhanden und verlinkt den zugehörigen Blueprint Principal. Umgekehrt zeigt der Tab Child Identities eines Blueprint Principals alle daraus bereitgestellten Agent Identities. So lässt sich vor einer Änderung am gemeinsamen Blueprint feststellen, welche Agenten davon abhängig sind. Aus einem Finding an einer einzelnen Laufzeitidentität darf nicht ohne Prüfung auf denselben Befund bei allen Child Identities geschlossen werden.

App Owners und Sponsors getrennt prüfen

Der Tab Sponsors erscheint bei Agent Identities und Blueprint Principals. Dort stehen Benutzer oder Gruppen, die Zweck und Lebenszyklus des Agenten verantworten, ohne über diese Beziehung technische administrative Zugriffe zu erhalten. App Owners verwalten dagegen technisch Credentials, Konfiguration und Berechtigungen. Eine Sponsor-Zuordnung ist deshalb keine Berechtigung, das Objekt zu ändern.

Für eine Übergabe werden die fachliche Entscheidung mit den Sponsors und die technische Umsetzung mit den App Owners geklärt. Beispielsweise betrifft eine geplante Credential-Änderung an einem gemeinsamen Blueprint nicht nur den untersuchten Agenten: Zuerst Blueprint lineage verfolgen, am Blueprint Principal Child Identities prüfen und die betroffenen Zwecke sowie Zugriffsabhängigkeiten mit den zuständigen Stellen abgleichen. Änderungen werden nur im führenden System und nach Freigabe umgesetzt; ein Statuswechsel in ITDR ersetzt diese Prüfung nicht.

Das gepaarte Agent-Benutzerkonto in Identities

Microsoft bietet optional ein agent’s user account, etwa für Mailbox- oder Teams-artige Aufgaben, bei denen der Agent wie ein Benutzer handeln muss. Dieses Konto ist mit einer Agent Identity gepaart, verhält sich aber wie ein Benutzer statt wie ein Service Principal. ITDR zeigt es deshalb unter Identities mit Agent Identity-Tag und öffnet dafür Identity Details, nicht die NHI-Detailseite.

Unter Summary > Details zeigt ein solches Konto Agent: Yes für die Paarung sowie Blueprint lineage als Verweis auf den Blueprint, aus dem die gepaarte Agent Identity bereitgestellt wurde. Der Bereich Sponsors nennt die Benutzer und Gruppen, die Lebenszyklus und Zugriff des gepaarten Agenten verantworten. Microsofts Manager-Rolle für diese Konten wird derzeit nicht in ITDR angezeigt; ein fehlender Manager-Eintrag beweist daher keine fehlende Zuständigkeit. Benutzerkonto, Laufzeitidentität und Blueprint-Beziehung werden bei einer Untersuchung getrennt dokumentiert und im Provider abgeglichen.

Gruppen und Geräte untersuchen

Unter Groups lässt sich die Suche mit vier Filtern eingrenzen: Deleted steht für beim Provider gelöschte Gruppen, Mail Enabled für Gruppen, die E-Mail empfangen können, und Security Enabled für Gruppen, die Zugriffe auf Ressourcen steuern können. Assignable to Roles kennzeichnet Gruppen, denen Rollen zugewiesen werden können.

Ein Klick auf Group Name öffnet Group Details mit den abgerufenen Gruppenmetadaten sowie Tabellen der zugeordneten Benutzer, Gruppen und Anwendungen. Bei einer Zugriffsprüfung werden Gruppentyp, Owner, direkte und verschachtelte Beziehungen sowie die fachliche Notwendigkeit im führenden Provider bestätigt. Mail Enabled sagt nichts darüber aus, ob eine Gruppe für Berechtigungen verwendet wird; dafür ist Security Enabled relevant.

Unter Devices kann nach Geräten gesucht und nach State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed und Compliant gefiltert werden. Die Sicht umfasst in Microsoft Entra ID registrierte persönliche und firmeneigene Geräte. Ein Geräteobjekt ist eine Identität im Provider; Microsoft Entra registered, Microsoft Entra joined und Microsoft Entra hybrid joined sind unterschiedliche Registrierungs- beziehungsweise Join-Kontexte und nicht gleichbedeutend mit einem installierten Sophos Endpoint Agent.

Über Display Name öffnet man Device Details. Je nach Gerätetyp zeigt die Seite abgerufene Metadaten, zugeordnete Identitäten, relevante Findings und weitere verfügbare Informationen. Managed, Compliant, Rooted oder Ownership sind Providerangaben. Fehlen sie, wird der Wert für die Untersuchung als nicht verfügbar beziehungsweise unbekannt dokumentiert. Daraus dürfen die Zustände «unmanaged», «non-compliant» oder «not rooted» ebenso wenig abgeleitet werden wie persönlicher oder firmeneigener Besitz. Ein fehlender Wert ist ausserdem nicht mit einem vom Provider ausdrücklich gemeldeten Wert Unknown gleichzusetzen.

Identity Details systematisch untersuchen

In Identities öffnet ein Klick auf Display Name die Seite Identity Details. Statt jeden Tab ohne Hypothese zu lesen, empfiehlt sich folgender Ablauf:

1. Objekt bestätigen: Anzeigename, Status, Typ, E-Mail-Adressen und Providerkontext mit dem erwarteten Benutzer abgleichen.
2. Priorität verstehen: Risk Score, beitragende Faktoren, offene Findings, Compromised, Admin, MFA- und Dormant-Kontext prüfen. Ein Score priorisiert die Untersuchung, ersetzt sie aber nicht.
3. Profil und Assets plausibilisieren: Rolle, Abteilung, Region, Organisationsstruktur und zugeordnete Intune-Geräte mit dem Sollprofil vergleichen.
4. Aktivität untersuchen: Zeitraum setzen, erfolgreiche und fehlgeschlagene Anmeldungen, Zeiten, Länder, IP-Adressen und ASNs auf Abweichungen prüfen.
5. Verknüpfte Evidenz öffnen: Findings, Detections, Gruppen und Dark-Web-Datensätze einzeln untersuchen, statt aus einer Zusammenfassung auf die Ursache zu schliessen.
6. Im führenden System validieren: Entra ID, lokales AD, Intune und gegebenenfalls XDR-Telemetrie gegenprüfen. Technische Änderungen danach im jeweiligen führenden System vornehmen. Ist stattdessen eine ausdrücklich freigegebene ITDR-Response vorgesehen, dafür einen verfügbaren Actions-Einstieg verwenden.
7. Ergebnis nachziehen: Nach der Korrektur oder Response das Ergebnis beim Provider und in ITDR erneut kontrollieren und dokumentieren, welche Anzeige bereits aktualisiert wurde und welche noch auf den nächsten Erfassungslauf wartet.

Summary

Summary verbindet Profil, Priorität und jüngste Aktivität. Unter Details stehen die verfügbaren Entra-ID-Angaben wie Rolle, Abteilung, Status, Land und Region, Erstellungs- und Änderungszeitpunkt, letzter Passwortwechsel sowie weitere zugeordnete E-Mail-Adressen. Assets zeigt die dem Benutzer in Entra ID zugeordneten Intune-Geräte. Multi-Factor Authentication nennt MFA-Provider, primäre MFA-Methode und weitere konfigurierte MFA-Typen. Den organisatorischen Kontext liefert Organization mit Vorgesetzten, direkten Reports und Organisationsstruktur; ein Klick auf eine Person öffnet sie in einem neuen Tab.

Die ausgewählte Identität ist im Organisationsdiagramm hervorgehoben. Jede Personenkarte zeigt Name, Rolle und Abteilung beziehungsweise Team, relevante Icons und Tags wie Admin, den aktuellen Risk Score oben rechts und die Zahl offener Findings nach Risikostufe beziehungsweise den Hinweis, dass keine vorhanden sind. Bei einem Agent-Benutzerkonto werden zusätzlich die oben beschriebenen Agent-Felder und Sponsors geprüft; die menschliche Reporting-Struktur ist nicht mit diesen Verantwortungsbeziehungen gleichzusetzen.

Für die Sicherheitsbewertung zeigt Recent Detections die Open Detections der letzten sieben Tage und die Closed Detections der letzten 30 Tage; View All führt zu Insights. Risk Score enthält den aktuellen Score und die wichtigsten beitragenden Faktoren. Top Sign-in Locations fasst die häufigsten Anmeldeorte mit öffentlicher und privater IP-Aktivität zusammen. Sofern Daten vorhanden sind, gliedert Commonly Used Entities erfolgreiche Authentifizierungen der letzten 30 Tage nach IP Addresses, Browser, Asset Name und OS Version.

Unter Top Sign-in Locations > View Details erscheinen für die letzten 30 Tage insbesondere geografischer Ort, ASN und Häufigkeit der wichtigsten IP-Adressen. IP type und Login outcome dienen dort als Filter; sie werden nicht als zwingend angezeigte Ergebnisspalten vorausgesetzt. Private IP-Adressen sind nicht geografisch wie öffentliche Adressen zu interpretieren. Eine häufige Stadt kann durch VPN- oder Cloud-Egress entstehen; ein unbekanntes Land kann eine Prüfung rechtfertigen, ist aber ohne Zeit-, Geräte- und Providerkontext noch kein Vorfall.

Activity Log

Activity Log zeigt Authentifizierungsaktivität für den oben rechts gewählten Zeitraum. Total Activities, Successful Logins und Failed Logins liefern zuerst das Volumen. Für die räumliche Einordnung zeigt Top sign-in locations Länder, IP-Adressen, Anzahl und die Verteilung auf öffentliche beziehungsweise private IPs. Authentication locations ergänzt die häufigsten Authentifizierungen der letzten 30 Tage nach IP-Adresse und ASN sowie eine Suche nach Ort, IP oder ASN. Den zeitlichen Verlauf stellen Logins per day mit getrennten erfolgreichen und fehlgeschlagenen Anmeldungen und die Activity map als Heatmap nach Wochentag und Tageszeit dar.

Diese ITDR-Sicht fasst Aggregate und Muster zusammen. Sie zeigt keine Ereignistabelle, in der all diese Angaben pro Anmeldung nebeneinanderstehen. Browser, Asset Name und OS Version sind stattdessen als 30-Tage-Profilaggregate erfolgreicher Authentifizierungen unter Summary > Commonly Used Entities zu bewerten und dürfen keinem einzelnen Eintrag im Activity Log zugeschrieben werden. Für eine Ereigniskorrelation mit exaktem Zeitpunkt und Zeitzone, Ergebnis, Quell-IP, ASN, Land, Gerät, Browser, Betriebssystem oder benachbarten Detections werden die jeweils verfügbaren Entra- beziehungsweise XDR-Ereignislogs herangezogen. Häufige Fehlversuche in den ITDR-Aggregaten können Benutzerfehler, veraltete Credentials oder einen Angriff darstellen; erst die Korrelation mit Ereignisevidenz entscheidet.

Findings, Insights, Group Membership und Dark Web Intelligence

Findings listet Findings dieser Identität nach Risiko. Der vollständige Text in Recommendation erscheint beim Darüberfahren; ein Klick auf den Finding-Namen öffnet die Details. Dabei werden Status, Risiko, Kategorie, betroffene Evidenz und empfohlene Behebung geprüft. Das manuelle Ändern eines Status ist nicht dasselbe wie die technische Behebung im Provider.

Insights zeigt Open Detections standardmässig für die letzten sieben Tage; der Zeitraum lässt sich über den Date Picker ändern. Closed Detections umfasst die letzten 30 Tage. Ein leerer Standardzeitraum schliesst ältere Aktivität daher nicht aus.

Group Membership listet die Gruppen des Benutzers. Das Suchfeld grenzt die Liste ein; ein Klick auf Group Name öffnet die Gruppe und ihre weiteren Mitglieder. Besonders relevant sind unerwartete privilegierte, rollenfähige, verschachtelte oder fachlich nicht mehr benötigte Mitgliedschaften. Änderungen erfolgen im führenden Provider.

Dark Web Intelligence zeigt Leak-Datensätze, die mit der Identität verknüpft sind. Über Breach Source öffnet man den jeweiligen Datensatz. Ein Datensatz dokumentiert die Offenlegung von Zugangsdaten. Für die Einordnung sind Leak-Zeitpunkt, Veröffentlichungs- beziehungsweise Breach-Kontext, Kontostatus und letzter Passwortwechsel gemeinsam zu prüfen. Der Datensatz beweist nicht automatisch, dass die aktuell verwendeten Credentials gültig sind oder dass eine Anmeldung stattgefunden hat.

Providergrenzen und Aktualisierungszeiten berücksichtigen

Sophos ITDR unterstützt Microsoft Entra ID und lokales Active Directory, doch nicht jeder Provider liefert dieselben Objekte und Felder. Cloud-spezifische Daten wie Intune-Assets, Entra-Service-Principals, MFA-Methoden oder Entra-Anmeldeaktivität können in einer rein lokalen AD-Integration fehlen. Umgekehrt erfasst der lokale ITDR-Sensor zusätzliche AD-Objekttypen für Posture-Prüfungen; das macht die Cloud-Tabs nicht automatisch vollständig.

Nach dem initialen vollständigen Entra-Abruf prüft ITDR Aktualisierungen je Datentyp in unterschiedlichen Intervallen: Benutzer-, Service-Principal-, App-, Gruppen- und Gerätedetails ungefähr alle zehn Minuten, MFA-Konfiguration ungefähr alle 15 Minuten, letzte Benutzeranmeldung ungefähr alle sechs Stunden und Domaindaten ungefähr alle 24 Stunden. Das sind Erfassungsintervalle, keine Garantie, dass Microsoft eine geänderte Quellinformation bereits über seine API liefert.

Entra ID P1 oder P2 ist für den vorgesehenen ITDR-Datenumfang erforderlich. Mit Entra ID Free sind APIs und Posture-Prüfungen eingeschränkt; eine Integration kann deshalb Provisioning Failed zeigen. Nach einem Lizenzupgrade können Admin- oder MFA-Angaben bei Microsoft bis zu einer Woche veraltet bleiben. In diesem Fall wird zuerst der entsprechende Microsoft-Entra-Aktivitätsbericht geprüft. Ist bereits die Provideranzeige nicht aktualisiert, kann ITDR noch keinen neueren Stand darstellen.

Drittanbieter-MFA in einer älteren Okta- oder Duo-Konfiguration kann ebenfalls als nicht geschützt erscheinen, weil Entra die MFA-Information nicht auf Benutzerebene speichert. Eine Anzeige Has MFA = false darf dann nicht isoliert als Beweis fehlender MFA-Kontrolle behandelt werden. Providerkonfiguration, Conditional Access, aktuelle External Authentication Methods und ein kontrollierter Anmeldetest müssen zusammenpassen.

Validierung und Troubleshooting

Objekt fehlt oder erscheint im falschen Tab

1. Aktive Suche und Filter zurücksetzen und Schreibweise sowie alternativen Anzeigenamen prüfen.
2. Kontrollieren, ob Identities, Groups, Devices oder Non-Human Identities die richtige Sicht ist. Das gepaarte Agent-Benutzerkonto gehört in Identities, Agent Identity und Blueprint Principal in die NHI-Sicht.
3. Tenant und führenden Identitätsprovider bestätigen; bei Anwendungen Application Object, Service Principal, App/Client ID und Object ID unterscheiden, bei Agenten zusätzlich Semantic role und Blueprint lineage prüfen.
4. Das Objekt direkt beim Provider suchen und Status, Löschung, Gast-, Cloud-, Hybrid- oder Servicekontext prüfen.
5. Unter den ITDR-Integrationseinstellungen Zustand und letzten erfolgreichen Abruf prüfen. Nicht ersatzweise Central Directory Sync neu starten.
6. Erst nach dem datentypspezifischen Erfassungsfenster erneut prüfen und Zeitpunkte dokumentieren.

Filter, MFA-, Admin- oder Gerätefeld ist leer oder unerwartet

• Filter entfernen und das Rohattribut im Provider prüfen.
• Entra-Lizenz, API-Verfügbarkeit und Integrationszustand kontrollieren.
• Bei MFA zusätzlich Provider, primäre und weitere Methode sowie Drittanbieter-Konfiguration prüfen.
• Bei Geräten zwischen Registrierung beziehungsweise Join, Intune-Verwaltung, Compliance und Sophos-Endpoint-Schutz unterscheiden.
• Nach Lizenz- oder Attributänderungen nicht nur ITDR, sondern zuerst die aktualisierte Provideranzeige validieren.
• «Leer», No data oder ein fehlender Tag als unbekannt dokumentieren, nicht als «nein».

Anmeldeort oder Aktivitätsmuster wirkt verdächtig

Im Activity Log zuerst den Zeitraum sowie Anmeldevolumen, Erfolgs- und Fehlschlag-Aggregate, Länder, IP-Adressen, ASN und Tages-/Zeitmuster vergleichen. Unter Top Sign-in Locations lassen sich IP type und Login outcome als Filter einsetzen.

Browser, Asset Name und OS Version separat unter Commonly Used Entities als 30-Tage-Aggregate einordnen. Exakte Ereigniszeit und Zeitzone sowie Ergebnis, Gerät, Browser und Betriebssystem einer einzelnen Anmeldung anschliessend in den verfügbaren Entra- beziehungsweise XDR-Ereignislogs korrelieren. Dabei auch die zugehörigen Findings und Insights prüfen.

NAT, VPN, Mobilfunk, Cloud-Egress und Reisen können den angezeigten Ort verändern. Bei bestätigtem Risiko Response-Schritte nur gemäss internem Incident-Prozess und mit den erforderlichen Berechtigungen ausführen.

Anzeige nach einer Behebung verifizieren

Die technische Änderung zuerst im führenden System bestätigen. Danach den erwarteten ITDR-Erfassungszeitpunkt abwarten, Filter zurücksetzen und dieselbe Identität beziehungsweise dasselbe Objekt erneut öffnen. Geprüft werden das korrigierte Feld, abhängige Tags, zugehörige Findings und der relevante Untersuchungszeitraum. Risk Score, Findings und Providerattribute können unterschiedliche Aktualisierungszyklen haben; ein noch unveränderter Score widerlegt die erfolgreiche Quelländerung nicht. Bleibt die Anzeige über das erwartete Fenster hinaus falsch, werden Providerbeleg, Tenant, Objekt-ID, Änderungszeit, Integrationszustand und Screenshots für die Eskalation gesichert.

Untersuchung nachvollziehbar abschliessen

Zum Abschluss Objekt, Tenant, Provider und Identitätstyp dokumentieren. Ebenfalls festhalten: verwendete Suche und Filter, Untersuchungszeitraum, geprüfte Detailbereiche, fehlende Providerdaten sowie die Ergebnisse der Validierung im führenden System und in ITDR. Human- und NHI-Kontext sowie Application Object und Service Principal bleiben dabei getrennt.