Undersöka katalog- och identitetsinformation i Sophos ITDR

Directory i Sophos ITDR är arbetsytan med det inventarium över identiteter, grupper, enheter och appar som ITDR samlar in från de anslutna identitetsleverantörerna. Översiktskorten visar antalet övervakade objekt. Ett klick öppnar motsvarande vy. Vid en undersökning går man från detta samlade inventarium via ett visningsnamn till objektets detaljinformation.

Snabbväg: Gå till My Products > Identity > Directory, välj först rätt flik, använd sökning och filter och kontrollera uppgifternas ursprung. Öppna Display Name för en användare och pröva sedan en konkret hypotes i vart och ett av områdena Summary, Activity Log, Findings, Insights, Group Membership och Dark Web Intelligence. En enskild tagg, en hög Risk Score eller en ovanlig inloggning är en prioriteringssignal, men utgör inte i sig ett bevis på kompromettering.

Klargör produktgränserna före undersökningen

ITDR Directory är inte katalogtjänsten i Sophos Fusion (tidigare Sophos Central). Den visar säkerhetskontext som har samlats in av ITDR-integrationen eller ITDR-sensorn. Global Settings > Platform > Directory service tillhandahåller däremot användare och grupper för gemensamt använda Central-funktioner och produkter. Det medför tre viktiga avgränsningar:

• En identitet som saknas i ITDR Directory åtgärdas inte genom att köra Central Directory Sync på nytt. Kontrollera först ITDR-integrationen, vilka objekt identitetsleverantören har och deras insamlingsstatus.
• Ett objekt i ITDR Directory är inte automatiskt en hanterad Central-användare och innebär inte att en produkt har tilldelats eller att Endpoint har installerats.
• Filter, taggar och enbart öppnandet av detaljsidor i ITDR ändrar inga katalogobjekt i Entra ID, Active Directory, Intune eller Central. Tekniska korrigeringar utförs i källsystemet och valideras därefter i ITDR. Separat från detta kan uttryckligen godkända responsåtgärder vara tillgängliga via de avsedda ingångarna under Actions.

Sophos XDR har också ett annat syfte. ITDR Directory tillhandahåller inventerings-, säkerhetsläges- och identitetskontext. En XDR-fråga eller XDR-undersökning korrelerar däremot telemetri och händelser från datakällor som stöds. Activity Log i Identity Details är därför inte en fullständig XDR-tidslinje, och ett ITDR-fynd är inte automatiskt en XDR-detektering. Vid en övergripande hotundersökning korreleras bekräftade ITDR-indikationer med tillgängliga data från XDR, Endpoint, Entra och nätverket, utan att avsaknad av telemetri tolkas som ett resultat utan avvikelser.

Tolka innehållet i Directory korrekt

Ingången under My Products > Identity > Directory innehåller fyra flikar med olika funktioner:

Sökfälten avgränsar respektive vy efter namn. Sökning och filter påverkar endast den information som visas och har samlats in av ITDR. Att en sökning inte ger någon träff bevisar därför varken att objektet inte finns hos leverantören eller att det har raderats. Kontrollera stavning, flik, aktiva filter, leverantörens klientorganisation och insamlingstidpunkten innan ärendet eskaleras.

Söka, sortera och filtrera identiteter

Identities kan visas som kort eller lista. Som standard sorteras användarna alfabetiskt. I sorteringsmenyn går det exempelvis att välja fallande Risk Score för att hitta de identiteter som bör undersökas först. Search Identities filtrerar efter namn.

Vilka filter som är lämpliga beror på undersökningen. För den första prioriteringen avgränsar Status den kontostatus som identitetsleverantören rapporterar, medan Risk Severity avgränsar intervallet för beräknad Risk Score. Is Admin avser den administratörskontext som antingen anges av leverantören eller fastställs utifrån identifierade privilegierade roller. Is VIP avser valet för VIP Monitoring och Is Compromised förekomsten av aktiva läckor med inloggningsuppgifter. Is Dormant hittar konton för vilka ingen inloggning har registrerats under de senaste 90 dagarna.

För bedömning av kontot finns Department och Employee Type som organisationsattribut, förutsatt att leverantören tillhandahåller dem. Is Guest anger ett gästkonto hos identitetsleverantören. Is Cloud Only anger ett konto som endast finns hos molnidentitetsleverantören och saknar lokala identifierare. MFA-kontexten tillhandahålls av Has MFA, Has Passwordless MFA, Primary MFA Method och MFA Method. Country och Region filtrerar efter de platsattribut som underhålls hos leverantören.

Ett tomt filtervärde är inte ett negativt resultat. Om leverantören inte tillhandahåller ett attribut, om licensen begränsar API-åtkomsten eller om Microsoft ännu inte har gjort uppdaterad information tillgänglig kan ITDR inte fylla i fältet tillförlitligt. Detta gäller särskilt data om MFA, administratörer, enheter och aktiviteter.

I kortvyn visar pilen längst ned på kortet ytterligare information. Endast ett kort åt gången kan vara expanderat. I listvyn expanderar pilen till vänster en rad. Via kolumnmenyn går det att fästa kolumner, anpassa storleken automatiskt, återställa, lägga till eller ta bort kolumner. Dessa visningsinställningar ändrar varken objektet eller dess bedömning.

Om responsåtgärder har godkänts i förväg är de tillgängliga för en användare via Actions på det expanderade kortet eller via kolumnen Actions i listvyn. Om ett alternativ eller en åtgärd är tillgänglig beror på identitetsstatus och konfiguration. Dessutom krävs nödvändiga operatörsbehörigheter och den interna godkännandeprocessen för att utföra den. Filter, taggar och öppnandet av detaljinformation är separata, icke-förändrande funktioner. Efter att en åtgärd har utförts kontrolleras resultatet i källsystemet och därefter det uppdaterade tillståndet i ITDR.

Använd ikoner och taggar som kontext, inte som ett omdöme

Ikonerna betecknar User, MFA User, Deleted User, Locked User, Admin, Guest eller Service. De ytterligare taggarna beskriver olika egenskaper och ska inte tolkas som ett samlat riskomdöme: Admin innebär att kontot har identifierats som administratör, Guest betecknar en gäst i klientorganisationen, Deleted User en användare som har raderats hos leverantören och Locked User ett inaktiverat konto.

MFA User avser aktiverad MFA, Compromised en aktiv läcka med inloggningsuppgifter och Dormant Account en identitet utan registrerad inloggning under de senaste 90 dagarna. Cloud Only innebär att det inte finns några lokala identifierare. För Hybrid finns lokala identifierare och de synkroniseras mellan molnet och den lokala miljön. Human klassificerar identiteten som en mänsklig användare. VIP anger att VIP Monitoring har konfigurerats.

Human och Non-Human Identity (NHI) får inte blandas ihop. Ett mänskligt konto representerar en person. NHI omfattar framför allt Service Principals, appar och andra maskinidentiteter. En Service-ikon ger motsvarande kontext i identitetsvyn. Klientorganisationens lokala Enterprise Applications undersöks på fliken Apps. Att ett visningsnamn låter som en person eller en tjänst är inte en tillförlitlig klassificering.

Skilj mellan Application Object och Service Principal

Ett Application Object i Microsoft Entra är den globala definitionen av en registrerad app i dess hemklientorganisation. Det beskriver bland annat appens identitetskonfiguration och har ett app- eller klient-ID. En Service Principal av typen Application är den konkreta, lokala instansen av appen i en viss klientorganisation. Den refererar till Application Object och fastställer vad appen får göra, vem som får åtkomst till den och vilka resurser den får komma åt i den aktuella klientorganisationen. Denna koppling gäller inte alla typer av Service Principal: en Service Principal av typen Managed identity har inget kopplat Application Object, och en Legacy Service Principal har ingen kopplad appregistrering.

Fliken Apps visar de Enterprise Applications som ITDR har hämtat från den övervakade Entra-klientorganisationen, alltså apprelaterade lokala instanser i klientorganisationen, och inte bara ytterligare en lista över globala appregistreringar. Av detta går det varken att dra slutsatsen att alla typer av Service Principal från Entra visas där eller att all NHI-kontext som visas har en appregistrering. En app med stöd för flera klientorganisationer kan ha ett Application Object i hemklientorganisationen men en egen Service Principal av typen Application i var och en av flera klientorganisationer där appen används. Därför måste Display Name, klientorganisation, app-/klient-ID, objekt-ID, ägare och behörigheter jämföras tillsammans. Identiska namn innebär inte att det är samma objekt. Olika lokala Service Principal-objekt av denna typ kan referera till samma globala app.

Öppna App Details via Display Name. Kontrollera där de metadata som ITDR har hämtat samt tabellerna över appägare, länkade Findings och behörigheter. En ovanlig eller riskfylld behörighet valideras hos leverantören mot det avsedda verksamhetssyftet, utgivaren, samtycket och den ansvariga ägaren. Visningen i Directory återkallar inte i sig något samtycke och tar inte bort någon behörighet.

Undersöka grupper och enheter

Under Groups kan sökningen avgränsas med fyra filter: Deleted avser grupper som har raderats hos leverantören, Mail Enabled grupper som kan ta emot e-post och Security Enabled grupper som kan styra åtkomst till resurser. Assignable to Roles betecknar grupper som kan tilldelas roller.

Ett klick på Group Name öppnar Group Details med hämtade gruppmetadata samt tabeller över tilldelade användare, grupper och appar. Vid en åtkomstgranskning bekräftas grupptyp, ägare, direkta och nästlade relationer samt verksamhetsbehovet i källsystemet. Mail Enabled säger ingenting om huruvida en grupp används för behörigheter. För detta är Security Enabled relevant.

Under Devices går det att söka efter enheter och filtrera efter State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed och Compliant. Vyn omfattar personliga och företagsägda enheter som har registrerats i Microsoft Entra ID. Ett enhetsobjekt är en identitet hos leverantören. Microsoft Entra registered, Microsoft Entra joined och Microsoft Entra hybrid joined är olika registrerings- respektive anslutningskontexter och är inte detsamma som att Sophos Endpoint Agent är installerad.

Öppna Device Details via Display Name. Beroende på enhetstyp visar sidan hämtade metadata, tilldelade identiteter, relevanta Findings och annan tillgänglig information. Managed, Compliant, Rooted och Ownership är leverantörsuppgifter. Om de saknas dokumenteras värdet som ej tillgängligt respektive okänt för undersökningen. Tillstånden ”unmanaged”, ”non-compliant” eller ”not rooted” får lika lite härledas av detta som personligt eller företagsägt innehav. Ett värde som saknas är dessutom inte detsamma som värdet Unknown, när leverantören uttryckligen har rapporterat detta.

Undersöka Identity Details systematiskt

På fliken Identities öppnar ett klick på Display Name sidan Identity Details. I stället för att läsa alla flikar utan hypotes rekommenderas följande arbetsgång:

1. Bekräfta objektet: Jämför visningsnamn, status, typ, e-postadresser och leverantörskontext med den förväntade användaren.
2. Förstå prioriteten: Kontrollera Risk Score, bidragande faktorer, öppna Findings, Compromised, Admin samt MFA- och Dormant-kontexten. Ett poängvärde prioriterar undersökningen men ersätter den inte.
3. Rimlighetsbedöm profil och tillgångar: Jämför roll, avdelning, region, organisationsstruktur och tilldelade Intune-enheter med den avsedda profilen.
4. Undersök aktivitet: Ange tidsperiod och kontrollera lyckade och misslyckade inloggningar, tider, länder, IP-adresser och ASN efter avvikelser.
5. Öppna länkad evidens: Undersök Findings, Detections, grupper och Dark Web-poster var för sig i stället för att dra slutsatser om orsaken utifrån en sammanfattning.
6. Validera i källsystemet: Kontrollera mot Entra ID, lokalt AD, Intune och vid behov XDR-telemetri. Utför därefter tekniska ändringar i respektive källsystem. Om en uttryckligen godkänd ITDR-respons ska användas i stället, använd en tillgänglig ingång under Actions.
7. Följ upp resultatet: Kontrollera resultatet hos leverantören och i ITDR igen efter korrigeringen eller responsen. Dokumentera vilken visning som redan har uppdaterats och vilken som fortfarande inväntar nästa insamlingskörning.

Summary

Summary sammanför profil, prioritet och senaste aktivitet. Under Details finns tillgängliga Entra ID-uppgifter som roll, avdelning, status, land och region, tidpunkt för skapande och ändring, senaste lösenordsbyte samt ytterligare tilldelade e-postadresser. Assets visar de Intune-enheter som har tilldelats användaren i Entra ID. Multi-Factor Authentication anger MFA-leverantör, primär MFA-metod och andra konfigurerade MFA-typer. Organization ger organisationskontexten med chefer, direktrapporterande medarbetare och organisationsstruktur. Ett klick på en person öppnar personen på en ny flik.

För säkerhetsbedömningen visar Recent Detections Open Detections från de senaste sju dagarna och Closed Detections från de senaste 30 dagarna. View All leder till Insights. Risk Score innehåller den aktuella poängen och de viktigaste bidragande faktorerna. Top Sign-in Locations sammanfattar de vanligaste inloggningsplatserna med aktivitet från offentliga och privata IP-adresser. Om data finns tillgängliga delar Commonly Used Entities upp lyckade autentiseringar under de senaste 30 dagarna efter IP Addresses, Browser, Asset Name och OS Version.

Under Top Sign-in Locations > View Details visas för de senaste 30 dagarna i synnerhet geografisk plats, ASN och frekvens för de viktigaste IP-adresserna. IP type och Login outcome används där som filter. De förutsätts inte vara resultatkolumner som alltid visas. Privata IP-adresser ska inte tolkas geografiskt på samma sätt som offentliga adresser. En vanligt förekommande stad kan bero på utgående trafik via VPN eller molntjänster. Ett okänt land kan motivera en kontroll, men utgör ännu ingen incident utan kontext om tid, enhet och leverantör.

Activity Log

Activity Log visar autentiseringsaktivitet för den period som har valts högst upp till höger. Total Activities, Successful Logins och Failed Logins ger först en bild av volymen. För den geografiska bedömningen visar Top sign-in locations länder, IP-adresser, antal och fördelningen mellan offentliga respektive privata IP-adresser. Authentication locations kompletterar detta med de vanligaste autentiseringarna under de senaste 30 dagarna efter IP-adress och ASN samt en sökning efter plats, IP eller ASN. Det tidsmässiga förloppet visas i Logins per day, där lyckade och misslyckade inloggningar är separerade, och i Activity map som en värmekarta efter veckodag och tid på dygnet.

Denna ITDR-vy sammanfattar aggregat och mönster. Den visar inte någon händelsetabell där samtliga dessa uppgifter står bredvid varandra för varje enskild inloggning. Browser, Asset Name och OS Version ska i stället bedömas som 30-dagarsprofilaggregat för lyckade autentiseringar under Summary > Commonly Used Entities och får inte tillskrivas en enskild post i Activity Log. För händelsekorrelation med exakt tidpunkt och tidszon, resultat, käll-IP, ASN, land, enhet, webbläsare, operativsystem eller närliggande Detections används de Entra- respektive XDR-händelseloggar som finns tillgängliga. Många misslyckade försök i ITDR-aggregaten kan bero på användarfel, inaktuella inloggningsuppgifter eller ett angrepp. Det är först korrelationen med händelsedata som avgör detta.

Findings, Insights, Group Membership och Dark Web Intelligence

Findings listar fynd för denna identitet efter risk. Den fullständiga texten i Recommendation visas när pekaren förs över den. Ett klick på fyndets namn öppnar detaljinformationen. Kontrollera då status, risk, kategori, berört underlag och rekommenderad korrigering. Att ändra status manuellt är inte detsamma som att genomföra den tekniska korrigeringen hos leverantören.

Insights visar som standard Open Detections för de senaste sju dagarna. Perioden kan ändras med Date Picker. Closed Detections omfattar de senaste 30 dagarna. Att standardperioden är tom på resultat utesluter därför inte äldre aktivitet.

Group Membership listar användarens grupper. Sökfältet avgränsar listan. Ett klick på Group Name öppnar gruppen och dess övriga medlemmar. Oväntade medlemskap som är privilegierade, kan tilldelas roller, är nästlade eller inte längre behövs i verksamheten är särskilt relevanta. Ändringar görs i källsystemet.

Dark Web Intelligence visar läckta dataposter som är kopplade till identiteten. Öppna respektive post via Breach Source. En post dokumenterar att inloggningsuppgifter har röjts. För bedömningen ska tidpunkten för läckan, publicerings- respektive intrångskontexten, kontostatusen och det senaste lösenordsbytet kontrolleras tillsammans. Posten bevisar inte automatiskt att de inloggningsuppgifter som används för närvarande är giltiga eller att en inloggning har ägt rum.

Ta hänsyn till leverantörsgränser och uppdateringstider

Sophos ITDR stöder Microsoft Entra ID och lokalt Active Directory, men alla leverantörer tillhandahåller inte samma objekt och fält. Molnspecifika data som Intune-tillgångar, Service Principals i Entra, MFA-metoder eller Entra-inloggningsaktivitet kan saknas i en rent lokal AD-integration. Omvänt samlar den lokala ITDR-sensorn in ytterligare AD-objekttyper för kontroller av säkerhetsläget. Det innebär inte automatiskt att molnflikarna blir fullständiga.

Efter den första fullständiga hämtningen från Entra kontrollerar ITDR uppdateringar med olika intervall beroende på datatyp: information om användare, Service Principals, appar, grupper och enheter ungefär var tionde minut, MFA-konfiguration ungefär var 15:e minut, senaste användarinloggning ungefär var sjätte timme och domändata ungefär var 24:e timme. Detta är insamlingsintervall, inte någon garanti för att Microsoft redan tillhandahåller ändrad källinformation via sitt API.

Entra ID P1 eller P2 krävs för den avsedda omfattningen av ITDR-data. Med Entra ID Free är API:er och kontroller av säkerhetsläget begränsade. En integration kan därför visa Provisioning Failed. Efter en licensuppgradering kan administratörs- eller MFA-uppgifter hos Microsoft vara inaktuella i upp till en vecka. Kontrollera i så fall först motsvarande aktivitetsrapport i Microsoft Entra. Om inte ens leverantörsvyn har uppdaterats kan ITDR ännu inte visa ett nyare tillstånd.

MFA från tredje part i en äldre Okta- eller Duo-konfiguration kan också visas som oskyddad eftersom Entra inte lagrar MFA-informationen på användarnivå. Visningen Has MFA = false får då inte betraktas isolerat som bevis på att MFA-kontroll saknas. Leverantörskonfigurationen, Conditional Access, aktuella External Authentication Methods och ett kontrollerat inloggningstest måste stämma överens.

Validering och felsökning

Objektet saknas eller visas på fel flik

1. Återställ aktiv sökning och aktiva filter och kontrollera stavning samt alternativa visningsnamn.
2. Kontrollera om Identities, Groups, Devices eller Apps är rätt objekttyp.
3. Bekräfta klientorganisationen och den identitetsleverantör som är källsystem. Skilj för appar mellan Application Object, Service Principal, app-/klient-ID och objekt-ID.
4. Sök efter objektet direkt hos leverantören och kontrollera status, radering samt gäst-, moln-, hybrid- eller tjänstekontext.
5. Kontrollera status och senaste lyckade hämtning under inställningarna för ITDR-integrationen. Starta inte om Central Directory Sync som ersättning.
6. Kontrollera igen först efter det datatypsspecifika insamlingsfönstret och dokumentera tidpunkterna.

Filter-, MFA-, administratörs- eller enhetsfältet är tomt eller oväntat

• Ta bort filter och kontrollera råattributet hos leverantören.
• Kontrollera Entra-licensen, API-tillgängligheten och integrationens status.
• Kontrollera för MFA även leverantören, primär och övriga metoder samt tredjepartskonfigurationen.
• Skilj för enheter mellan registrering respektive anslutning, Intune-hantering, efterlevnad och Sophos Endpoint-skydd.
• Efter licens- eller attributändringar ska inte bara ITDR utan först den uppdaterade leverantörsvyn valideras.
• Dokumentera ”tomt”, No data eller en tagg som saknas som okänt, inte som ”nej”.

Inloggningsplatsen eller aktivitetsmönstret verkar misstänkt

Jämför först period, inloggningsvolym, aggregat för lyckade och misslyckade inloggningar, länder, IP-adresser, ASN och dags-/tidsmönster i Activity Log. Under Top Sign-in Locations går det att använda IP type och Login outcome som filter.

Bedöm Browser, Asset Name och OS Version separat under Commonly Used Entities som 30-dagarsaggregat. Korrelera därefter den exakta händelsetiden och tidszonen samt resultat, enhet, webbläsare och operativsystem för en enskild inloggning i de tillgängliga Entra- respektive XDR-händelseloggarna. Kontrollera även tillhörande Findings och Insights.

NAT, VPN, mobilnät, utgående molntrafik och resor kan ändra platsen som visas. Vid bekräftad risk får responsåtgärder endast utföras enligt den interna incidentprocessen och med nödvändiga behörigheter.

Verifiera visningen efter en åtgärd

Bekräfta först den tekniska ändringen i källsystemet. Vänta därefter till den förväntade ITDR-insamlingstidpunkten, återställ filter och öppna samma identitet respektive objekt igen. Kontrollera det korrigerade fältet, beroende taggar, tillhörande Findings och den relevanta undersökningsperioden. Risk Score, Findings och leverantörsattribut kan ha olika uppdateringscykler. Att poängen fortfarande är oförändrad motbevisar inte att källändringen lyckades. Om visningen fortfarande är felaktig efter det förväntade tidsfönstret ska leverantörsunderlag, klientorganisation, objekt-ID, ändringstid, integrationsstatus och skärmbilder sparas för eskalering.

Avsluta undersökningen spårbart

Dokumentera slutligen objekt, klientorganisation, leverantör och identitetstyp. Notera även använd sökning och använda filter, undersökningsperiod, granskade detaljområden, saknade leverantörsdata samt resultaten av valideringen i källsystemet och i ITDR. Håll kontext för Human och NHI samt Application Object och Service Principal åtskilda.