Undersöka Sophos ITDR Directory och Identity Details

Sophos ITDR Directory är arbetsinventariet för identiteter, icke-mänskliga identiteter (NHI:er), grupper och enheter som ITDR hämtar från anslutna identitetsleverantörer. Mätvärdeskorten visar antalet övervakade objekt; ett klick öppnar motsvarande vy. Vid en undersökning går du från detta samlade inventarium till objektets detaljdata genom att välja dess visningsnamn.

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

Ikoner markerar User, MFA User, Deleted User, Locked User, Admin eller Guest. De ytterligare taggarna beskriver olika egenskaper och ska inte tolkas som en gemensam riskbedömning: Admin innebär att kontot har identifierats som ett administratörskonto, Guest anger en gäst i klientorganisationen, Deleted User ett konto 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 är klassificeringstaggar, inte risknivåer. Ett mänskligt konto representerar en person. NHI:er omfattar bland annat Service Principals, applikationer, Agent Identities, Agent Identity Blueprints och andra maskinidentiteter. NHI-objekten undersöks i Non-Human Identities. Ett valfritt användarkonto som är parat med en agent visas däremot i Identities med taggen Agent Identity. Ett visningsnamn som 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.

Vyn Non-Human Identities omfattar Enterprise Applications, andra Service Principals och Microsoft Entra Agent ID-objekt som ITDR har hämtat från den övervakade Entra-klientorganisationen. Den är varken begränsad till Service Principals av typen Application eller en andra lista över globala appregistreringar. Det garanterar dock inte att alla objekt hos leverantören redan har hämtats. Alla visade NHI-kontexter har inte en appregistrering. En applikation för flera klientorganisationer kan ha ett Application Object i sin hemklientorganisation men en egen Service Principal av typen Application i var och en av flera klientorganisationer som använder den. Jämför därför Display Name, klientorganisation, App/Client ID, Object ID, ägare och behörigheter tillsammans. Samma namn innebär inte samma objekt; olika lokala Service Principals av den här typen kan hänvisa till samma globala applikation.

Filtrera NHI:er och läs Non-Human Identity Details

Search Non-Human Identities begränsar vyn efter namn. Följande filter finns för en riktad granskning:

• Status: status hos leverantören, exempelvis Active, Disabled eller Deleted.
• Resource Type: underliggande objekttyp, exempelvis Application, ServiceIdentity, ManagedIdentity, SocialIdp eller Legacy. Dessa UI-värden garanterar inte att det finns en tillhörande appregistrering.
• Has Password Credentials: om en lösenordsbaserad autentiseringsuppgift är konfigurerad.
• Has Key Credentials: om en certifikatbaserad autentiseringsuppgift är konfigurerad.
• Is Agent: om objektet klassificeras som Agent Identity eller Agent Identity Blueprint Principal.
• Agent Type: val av Agent Identity eller Blueprint Principal.

För agentinventariet kan du exempelvis börja med Is Agent, välja önskad Agent Type och öppna Display Name. Filtren för autentiseringsuppgifter beskriver det enskilda objektets konfiguration, inte uppgifternas giltighet eller ett lyckat autentiseringstest. Särskilt för agenter behöver även den överordnade blueprinten beaktas; en agent utan eget lösenord är inte automatiskt ett objekt utan åtkomstmöjligheter.

Via Display Name öppnar du Non-Human Identity Details. Under Details länkar visningsnamnet till objektet i Microsoft Entra admin center. Status anger aktivt, inaktiverat eller raderat; Type anger den underliggande resurstypen, exempelvis Application eller ServiceIdentity. Created At, Updated At och Deleted At visar tidpunkter i objektets livscykel. Dessa metadata är inte inloggningshändelser.

App Owners listar användare eller Service Principals med teknisk administrativ kontroll över autentiseringsuppgifter, konfiguration och behörigheter. Varje post visar visningsnamn, användartyp, roll, avdelning och status. Findings innehåller fynd som hör till NHI:n, ordnade efter risk; ett klick öppnar detaljerna. För statusbeslut och efterföljande validering följer du arbetsflödet för fynd.

Under Permissions skiljer du Application Permissions – direkt beviljade app-only-behörigheter – från Delegated Permissions, som gäller för en inloggad användares räkning. Båda tabellerna visar API-namn, claim-värde, behörighet, behörighetstyp och datum då behörigheten beviljades. Validera en avvikande behörighet hos leverantören mot avsett verksamhetsbehov, utgivare, samtycke och ansvarig ägare. Visningen i Directory återkallar inte i sig något samtycke och tar inte bort någon behörighet.

Agent Identity Blueprint, Blueprint Principal och körningsidentitet

En agent som bygger på Microsoft Entra Agent ID består av sammanhörande objekt, inte en enda appregistrering:

• Agent Identity Blueprint är behållaren för autentiseringsuppgifter och policyer som en eller flera agenter etableras från. Den innehåller autentiseringsuppgifterna.
• Blueprint Principal är posten som skapas i klientorganisationen när blueprinten läggs till. Den används för att administrera och granska blueprinten i klientorganisationen.
• Agent Identity är AI-agentens faktiska identitet vid körning. Den har inget eget lösenord eller någon egen hemlighet, utan autentiserar sig med en token via den överordnade blueprinten.

För Agent Identities och Blueprint Principals visar Details även Agent: Yes och Semantic role med Agent Identity eller Blueprint Principal. I NHI-detaljerna finns Blueprint lineage endast för Agent Identities och länkar till tillhörande Blueprint Principal. Omvänt visar fliken Child Identities för en Blueprint Principal alla Agent Identities som etablerats från den. På så sätt kan du identifiera beroende agenter innan den gemensamma blueprinten ändras. Ett fynd på en enskild körningsidentitet får inte utan kontroll antas gälla alla Child Identities.

Granska App Owners och Sponsors separat

Fliken Sponsors visas för Agent Identities och Blueprint Principals. Den listar användare eller grupper som ansvarar för agentens syfte och livscykel, utan att denna relation ger dem teknisk administrativ åtkomst. App Owners administrerar däremot autentiseringsuppgifter, konfiguration och behörigheter tekniskt. En sponsortilldelning innebär därför inte behörighet att ändra objektet.

Vid en överlämning klargörs verksamhetsbeslutet med Sponsors och det tekniska genomförandet med App Owners. En planerad ändring av autentiseringsuppgifter i en gemensam blueprint påverkar exempelvis fler än den agent som undersöks: följ först Blueprint lineage, kontrollera Child Identities för Blueprint Principal och stäm av berörda syften och åtkomstberoenden med ansvariga parter. Ändringar genomförs endast i källsystemet och efter godkännande; en statusändring i ITDR ersätter inte denna kontroll.

Det parade agentanvändarkontot i Identities

Microsoft erbjuder ett valfritt agent’s user account, exempelvis för uppgifter med postlådor eller Teams-liknande funktioner där agenten behöver agera som användare. Kontot är parat med en Agent Identity men fungerar som en användare snarare än en Service Principal. ITDR visar det därför under Identities med taggen Agent Identity och öppnar Identity Details, inte NHI-detaljsidan.

Under Summary > Details visar ett sådant konto Agent: Yes för parningen och Blueprint lineage som hänvisning till blueprinten som den parade Agent Identity etablerades från. Området Sponsors anger användare och grupper som ansvarar för den parade agentens livscykel och åtkomst. Microsofts manager-roll för dessa konton visas för närvarande inte i ITDR; en saknad manager-post bevisar därför inte att ansvar saknas. Dokumentera användarkonto, körningsidentitet och blueprintrelation separat vid en undersökning och jämför dem med uppgifterna hos leverantören.

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.

Den valda identiteten är markerad i organisationsdiagrammet. Varje personkort visar namn, roll och avdelning eller team, relevanta ikoner och taggar som Admin, aktuell Risk Score uppe till höger samt antalet öppna fynd per risknivå eller en uppgift om att det inte finns några. För ett agentanvändarkonto kontrolleras även agentfälten och Sponsors som beskrivs ovan; den mänskliga rapporteringsstrukturen är inte likvärdig med dessa ansvarsförhållanden.

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 Non-Human Identities är rätt vy. Det parade agentanvändarkontot hör hemma i Identities, medan Agent Identity och Blueprint Principal hör hemma i NHI-vyn.
3. Bekräfta klientorganisation och ansvarig identitetsleverantör; skilj för applikationer mellan Application Object, Service Principal, App/Client ID och Object ID, och kontrollera för agenter även Semantic role och Blueprint lineage.
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.