Undersök och åtgärda Sophos ITDR Dark Web Intelligence

Dark Web Intelligence visar de läckageposter som Sophos har samlat in för de konfigurerade domänerna. Syftet med den här körboken är inte att behandla varje träff som aktuell åtkomst till ett konto. Först kontrolleras identitet, tidsreferens, lösenordstyp och läckagestatus. Därefter svarar man endast genom en godkänd process för den identitet som faktiskt är kopplad.

Credential Leaks med status Active höjer en identitets Risk Score. Historiska poster förblir dock synliga även när de är inaktiva. Tabellen fungerar därför både som en arbetsvy över nuvarande risker och som bevis på äldre upptäckter.

Snabbflöde

1. Öppna My Products > Identity > Dark Web Intelligence och dokumentera standardfiltren.
2. Prioritera en aktiv post och dokumentera Source, kopplad identitet, lösenordstyp samt Publish Date, Leaked Date och Breach Date.
3. Kontrollera varför posten är Active; likställ inte enskilda rader med unika konton eller lösenord.
4. För en associerad Finding, jämför den visade allvarligheten med matrisen med hjälp av kontotyp, lösenordstyp och MFA-styrka.
5. Bekräfta ansvar och godkännande. Utför först därefter det lämpliga, redan godkända svaret.
6. Åtgärda autentiseringsuppgifterna i ansvarig Identity Provider enligt den godkända processen. Använd inte Finding eller läckagestatus som en ersättning för den åtgärden.
7. Granska statusen, Finding och Risk Score igen efter minst en 15-minuterscykel och dokumentera underlaget.

Vyer och standardfilter

Direktåtkomst

My Products > Identity > Dark Web Intelligence

När du öppnar denna sida direkt filtreras tabellen till läckstatus Active och identitetsstatus Active. Innan du undersöker, spara en skärmdump eller anteckning av de aktiva filtren. En tom standardvy bevisar inte att det inte finns några historiska läckdata; för denna kontroll, utöka medvetet statusfiltren.

Åtkomst via Identity Overview

Identity Overview > Credential Leaks

Om du klickar på ett mätvärde i widgeten Credential Leaks öppnar Dark Web Intelligence med en sektion som matchar mätvärdet:

Breached Email Accounts och Unique Passwords Breached är de aggregerade mätvärdena för underliggande data. Det finns inget ytterligare tabellfilter som fullt ut återspeglar deras unika räknemetod. Därför kan mätvärdet inte rekonstrueras exakt från de tabellrader som är synliga efter klicket.

Tolka mått korrekt

Måtten ovan Dark Web Intelligence hänvisar till aktiva läckor:

Dessa värden använder olika enheter: källor, läckageregistreringar, konton och unika lösenord. De kan inte läggas ihop eller valideras bara genom att räkna tabellrader.

Undersök en läckagepost

1. Definiera omfattningen

Först, notera filtren och sorteringen. För den första sorteringen är åtminstone dessa egenskaper relevanta:

• Läckagestatus Active eller Inactive
• Identitetsstatus och kopplad identitet
• Plaintext eller Hashed
• Admin-, icke-admin- eller VIP-kontext, om angivet
• Source
• Publish Date, Leaked Date och Breach Date
• associerad Finding, om närvarande

Prioritera inte enbart efter den senaste tidsstämpeln i tabellen. En post med ny Publish Date kan innehålla äldre innehåll, särskilt för combolistor.

2. Öppna detaljer

Klicka på fältet Source. Detaljpanelen visar ytterligare information om läckan och, om tillgängligt, den länkade identiteten. Innan du svarar måste tabellraden och detaljpanelen hänvisa till samma källa och identitet.

Om ingen identitet tilldelas, förblir posten relevant för den historiska undersökningen, men anses inaktiv. Actions är inaktiverad i detta fall. Tilldela inte en identitet baserat på en gissning, och agera inte mot ett konto med liknande namn.

3. Dela upp datumfälten

Publish Date

Den tidpunkt då Sophos först upptäckte läckageregistret i de data som analyserades. Det hänvisar varken till tiden för offentlig tillgång eller nödvändigtvis till händelsetiden.

Leaked Date

Datumet då datamängden blev offentligt tillgänglig. Detta datum jämförs med senaste lösenordsändring för att bedöma om inloggningsuppgifternas risk är aktuell.

Breach Date

Tidpunkten då den underliggande överträdelsen inträffade. Den ger kontext för incidenten, men kan vara otillgänglig.

En saknad Breach Date gör inte Leaked Date till den bekräftade intrångstiden. På samma sätt bevisar inte en ny Publish Date att lösenordet nyligen har komprometterats. För statuslogiken är det avgörande om den senaste lösenordsändringen är före eller efter den relevanta första läckagetiden.

4. Bedöm dubbletter och combolistor

Samma person kan förekomma i flera rader inom en källa. Vanliga orsaker inkluderar:

• personen förekommer flera gånger i den ursprungliga datamängden;
• samma innehåll identifierades i en generell källa såsom en combolist;
• äldre läckdata blir synliga igen i en senare hittad samling.

Flera rader innebär därför inte automatiskt flera komprometterade konton eller flera aktuella lösenordskompromisser. Jämför källa, datum, lösenordstyp och kopplad identitet för varje rad. Mätvärdena Emails och Unique Passwords tillämpar dedupliceringslogik; tabellraderna dedupliceras inte på samma sätt.

När en läcka är Active eller Inactive

Ett läckage är Active om båda villkoren uppfylls:

1. Posten kan kopplas till en aktiv identitet i en konfigurerad Identity Provider.
2. Det senaste lösenordsbytet för det associerade kontot är före den första läcktiden.

Active innebär därför en risk kopplad till autentiseringsuppgifter som fortfarande är relevant. Statusen ensam bevisar inte ett lyckat inloggningsförsök av en tredje part eller en pågående attack.

En läcka är Inactive om minst ett av de dokumenterade scenarierna gäller:

• Det finns ingen matchande identitet i de konfigurerade Identity Providers.
• Den senaste lösenordsändringen är efter tidpunkten för läckan.
• Kontots lösenord har nyligen ändrats.
• Kontot har inaktiverats eller raderats.
• En relaterad Finding har fått status Resolved eller Dismissed.

Historiska data om övervakade domäner samlas in och behålls. En inaktiv datamängd är därför varken felaktig eller irrelevant på grund av dess ålder. Den kan förklara varför samma person eller källa dyker upp flera gånger.

När en Finding skapas

Sophos beskriver följande bearbetning för Findings om komprometterade konton:

1. Sophos kontrollerar om en aktiv identitet finns i de konfigurerade Identity Providers.
2. Sophos avgör utifrån tillgängliga historiska data när klartextvärdet eller hashen läcktes för första gången. Syftet är bland annat att identifiera gammalt innehåll i nya kombolistor.
3. Med ett klartextvärde jämför Sophos värdet med de globala kraven på lösenordskomplexitet från Microsoft Entra ID för att sortera ut ogiltiga värden.
4. Sophos jämför tidpunkten då lösenordet först läcktes med den senaste lösenordsändringen. Om den första läckan inträffade efter den ändringen skapar Sophos en Finding.

Findings skapas endast för aktiva identiteter. Rådata förblir synlig på Dark Web Intelligence även om ingen aktiv identitet är kopplad.

Allvarlighetsmatris för komprometterade konton

Enligt Sophos beror allvaret i Finding på kontotyp, lösenordstyp och styrkan på MFA:

Matrisen hjälper till att prioritera arbetet, men ersätter inte en bedömning av det enskilda fallet. Särskilt för administratörskonton måste den faktiska kontokopplingen bekräftas före en åtgärd. En lägre allvarlighetsgrad betyder inte att ingen korrigering krävs.

Hantera lösenordsvärden

Sophos uppger att företaget varken lagrar lösenord i klartext eller hashvärden och inte heller kan samla in dessa värden från Identity Providers. Under insamlingen tillämpar Sophos sin egen hash på observerade värden och kategoriserar sedan datamängden som Plaintext eller Hashed. Enligt Sophos gör denna metod det möjligt att fastställa unika värden och härledda mätvärden utan att lagra det underliggande lösenordsvärdet.

Operativt innebär detta:

• Plaintext beskriver typen av läckageinnehåll som observerats, inte ett lösenord som är tillgängligt i Sophos Fusion (tidigare Sophos Central).
• Försök inte att återställa det ursprungliga värdet från Sophos Fusion, skärmdumpar eller exporteringar.
• Kopiera inte misstänkta lösenord, hashvärden eller nya inloggningsuppgifter till ärenden, anteckningar eller chattmeddelanden.
• Ställ in ett nytt lösenord uteslutande via den godkända processen för Identity Provider och behandla det i det avsedda lösenordssystemet.

Auktoriserat svar och åtgärd

Bestäm innan du vidtar någon åtgärd

Innan Actions måste alla följande punkter uppfyllas:

• Den länkade identiteten bekräftas tydligt av detaljpanelen.
• Kontoinnehavaren, kontotypen och affärsfunktionen är kända.
• Det nuvarande läckagestatuset, lösenordstypen och tre datumfält har kontrollerats.
• Response Actions är auktoriserade för klientorganisationen.
• Personen som utför handlingen är auktoriserad för den specifika identiteten och förväntade påverkan.
• Den ansvariga tjänste- eller systemförvaltaren är involverad i privilegierade eller delade konton.

Om något av dessa villkor inte är uppfyllt utlöses ingen åtgärd. Posten skickas till den ansvariga personen i Identity- eller säkerhetsteamet tillsammans med tidsstämpel, filterstatus och information om det godkännande som saknas.

Svara i Dark Web Intelligence

Om Response Actions är auktoriserade, är de tillgängliga för länkade identiteter i tabellen eller i läckagedetaljerna:

1. Öppna rätt rad eller detaljpanelen för den bekräftade identiteten.
2. Välj Actions.
3. Välj endast den redan godkända Response Action.
4. Granska och följ alla instruktioner och bekräftelser på skärmen.
5. Dokumentera åtgärd, utförare, tidpunkt, målidentitet och synligt resultat, men registrera inga autentiseringsuppgifter.

Använd endast Response Actions som erbjuds i klientorganisationen och har auktoriserats av organisationen. Om ingen lämplig identitet finns kommer Actions förbli inaktiverad; detta får inte kringgås.

Åtgärda riskerna med autentiseringsuppgifter

Teknisk åtgärd sker via Identity Provider som är ansvarig för kontot och den godkända autentiseringsprocessen:

1. Kontrollera senaste lösenordsbyte och kontostatus för den bekräftade identiteten mot läcktiden.
2. Om det inte är möjligt att utesluta att de inloggningsuppgifter som observerats i läckan fortfarande är giltiga, initiera eller utför en auktoriserad lösenordsändring för exakt detta konto.
3. Om ett konto är inaktiverat eller raderat, bekräfta leverantörens status istället för att återaktivera kontot för åtgärd.
4. Om posten inte är kopplad till en identitet, behandla den som en historisk, inaktiv läcka och gissa inte kontots identitet.
5. Hantera en associerad Finding enligt den avsedda processen först när den faktiska åtgärden av autentiseringsuppgifterna har dokumenterats. Använd Dismissed endast efter tekniskt dokumenterat beslut, inte för att förkorta kön.

Dra inte några slutsatser om ytterligare konto-, session-, MFA- eller katalogändringar från läckerapporten. Sådana åtgärder kräver en separat bekräftad anledning och det godkännande som krävs för dem.

15-minuters takt och validering

Sophos kontrollerar Dark Web Intelligence var 15:e minut. Sophos övervakar och samlar kontinuerligt in läckageresultat; om ett aktivt läckage upptäcks genereras vanligtvis en Finding inom 15 minuter. “Vanligtvis” är inte en garanterad maxgräns för tid.

Registrera inte ett slutligt lyckat resultat omedelbart efter åtgärden. Gör i stället följande:

1. Registrera sluttiden för lösenordsbytet eller den bekräftade kontoförändringen med tidszon.
2. Vänta minst en fullständig 15-minuterscykel. Tänk på att Sophos inhämtning av uppdaterade data från Identity Provider kan kräva extra tid.
3. Öppna My Products > Identity > Dark Web Intelligence igen.
4. Sök efter samma identitet och källa med samma filter.
5. Kontrollera om läckan har ändrats från Active till Inactive och om den visade identitetsstatusen är korrekt.
6. Kontrollera den associerade Finding separat. Att ingen ny Finding visas är inte tillräckligt bevis om läckan fortfarande är Active.
7. Övervaka identitetens Risk Score som en uppföljningssignal. Det är inte det primära beviset på lösenordsändringen.
8. Dokumentera utgångsvärde, åtgärd, slutförandetid, valideringstid och slutstatus.

Acceptanskriterier

Bearbetningen är endast slutförd när:

• Identitet och läckakälla är tydligt dokumenterade;
• lösenordstyp och datumfält har utvärderats;
• åtgärden av autentiseringsuppgifterna har bekräftats i ansvarig Identity Provider eller kontot har bevisligen inaktiverats eller raderats;
• den åtgärdade läckagerapporten är inte längre Active efter bearbetning;
• den associerade Finding har hanterats genom en kontrollerad process;
• inga hemliga värden finns i dokumentationen.

Om posten förblir Active efter flera 15-minuterscykler, kontrollera först det faktiska senaste lösenordsbytet, kontots status och den kopplade identiteten igen. Om denna information är korrekt och statusen fortfarande inte kan förklaras, måste filtreringstillstånd, källa, alla tre datumfält, identitetsreferens, Finding-referens och tidsstämpel registreras. Eskalera sedan till Sophos support. Gör inga ytterligare kontoförändringar baserat på en gissning.

Triageringsjournal

Klientorganisation / miljö:
Valideringstid med tidszon:
Sökväg och aktiva filter:
Source:
Länkad identitet:
Identitetsstatus:
Kontotyp: Admin / Icke-Admin / otydlig
VIP-övervakning: ja / nej / oklart
Lösenordstyp: Plaintext / Hashed
Läckagestatus före åtgärd:
Publish Date:
Leaked Date:
Breach Date: Värde / ej tillgängligt
Flera rader eller kombinationslistkontext:
Finding-referens och allvarlighetsgrad:
Senaste lösenordsändring enligt Identity Provider:
Godkännande av svar:
Auktoriserad åtgärd utförd:
Sluttid med tidszon:
Validering efter 15-minuters cykel:
Läckagestatus efter åtgärden:
Finding-status efter åtgärden:
Risk Score som en uppföljningssignal:
Öppen avvikelse / eskalering:

Undvik vanliga misstag

• Räkna varje tabellrad som ett separat konto: Dubbletter och kombinationslistor kan skapa flera rader för samma person.
• Publish Date läses som Breach Date: De tre datumfälten beskriver olika händelser; Breach Date kan saknas.
• Tolka Inactive som raderad: Historiska data förblir intakta och kan fortfarande vara synliga.
• Betrakta en tom standardvy som ett klartecken: Direktåtkomst visar som standard endast aktiva läckor för aktiva identiteter.
• Stäng en Finding manuellt istället för att åtgärda: En statusändring ändrar inga inloggningsuppgifter i Identity Provider.
• Tvinga fram Actions utan en kopplad identitet: Utan en matchande identitet är knappen avsiktligt inaktiverad.
• Förväxla Plaintext med ett hämtbart lösenord: Sophos säger att varken okrypterade värden eller hashvärden lagras.
• Förvänta dig en omedelbar uppdatering: Kontrollcykeln körs var 15:e minut; identitetsdata från upstream kan kräva ytterligare bearbetningstid.