Hoppa till innehållet
Avanet
Logga in

Använd Sophos XDR Threat Intelligence Explorer

Threat Intelligence Explorer gör hotinformationen från Sophos Counter Threat Unit (CTU) sökbar i Sophos Fusion (tidigare Sophos Central). Här går det att undersöka malwarefamiljer, analyser och kända hotgrupper och jämföra deras sammanhang med Detections från den egna miljön. En post i denna kunskapsbas är inte i sig en träff i den egna tenanten och inte en bekräftad kompromettering.

Kort arbetsflöde: öppna Security Operations > Threat Intelligence, sök via Malware, Threat Report eller Threat Group, läs tillgängliga detaljer och skilj Related Detections från Related Detectors. Först de egna händelserna visar om det undersökta sambandet är relevant för ett konkret Case.

Förutsättningar och gränser

Explorer kräver en XDR- eller Enterprise-licens. Detta arbetsflöde beskriver vyn Security Operations. Threat Analysis Center finns kvar som Classic-vy; befintliga runbooks för utredningar och Cases kan därför fortfarande visa den menyvägen. Blanda inte ihop benämningarna i de två vyerna.

CTU uppdaterar sin hotinformation utifrån incidentutredningar, global hotbevakning, tekniska malware- och kampanjanalyser samt samarbete med partner och myndigheter. Denna information beskriver hotläget; Detections och Events i tenanten beskriver den aktivitet som faktiskt observerats i den egna miljön. En utredning behöver båda nivåerna.

Tre begrepp är viktiga:

  • En Indicator of Compromise (IOC) är exempelvis en indikator som i en analys pekar på en möjlig kompromettering. Dess betydelse bedöms tillsammans med tidpunkt, ursprung och observerat beteende.
  • En Detector är detektionslogiken som skapar en Detection utifrån ovanliga eller misstänkta Events. En relaterad Detector är inte samma sak som en redan befintlig träff.
  • Tactics, Techniques and Procedures (TTPs) beskriver en angripares tillvägagångssätt. Liknande TTP:er eller samma malware bevisar inte att en viss grupp har angripit den egna tenanten.

Explorer används här som ingång till research och utredning. Att läsa om eller filtrera en malwarefamilj innebär inte att en Firewall Threat Feed, blockeringsregel eller svarsåtgärd konfigureras.

Sök innan resultaten avgränsas

Sökfältet uppe till höger söker i Malware, Threat Reports och Threat Groups. En term från en Detection eller rapport, exempelvis Emotet, är en lämplig utgångspunkt. Värdet är bara ett sökexempel; använd det namn som faktiskt ska undersökas.

  1. Öppna en av de tre vyerna under Security Operations > Threat Intelligence och ange sökbegreppet.
  2. Välj en konkret träff för att se detaljerna. Om träfflistan först ska jämföras, välj View in table eller See all. Motsvarande tabell filtreras då till sökresultaten.
  3. Lägg först därefter till ytterligare filter. Då går det att se om ett snävt filter har uteslutit användbara resultat.
  4. Klicka på X till höger i sökfältet för att börja om med en ny sökning. Det raderar sökningen och återställer även tabellfiltren. Anteckna viktiga sökbegrepp och filter i utredningsprotokollet först.

Flera filter är användbara när de besvarar en konkret fråga. Ett känt malwarenamn tillsammans med en CVE är en annan undersökning än en sökning efter aktuella ransomwarerapporter för en bransch. För många kriterier från början gör en tom lista svår att tolka.

Undersök en malwarefamilj

Malware innehåller tekniska analyser, IOC:er och kopplingar till hotaktörer. Tabellen sorteras som standard först efter den Threat Priority som CTU har satt för viktiga eller aktuella hot och därefter efter senaste uppdatering. Ordningen prioriterar hotinformation, inte Severity för en egen Detection.

De dokumenterade filtren har olika syften:

  • Malware söker efter familjenamn, exempelvis Emotet eller TrickBot.
  • Type avgränsar klassificeringen, exempelvis Trojan, Ransomware eller Backdoor.
  • Threat Group söker efter malware med en koppling till en viss grupp, exempelvis GOLD MYSTIC eller BRONZE BUTLER.
  • CVE söker efter malware som utnyttjar en viss sårbarhet. Använd exempelvis CVE-2021-44228 när just den sårbarheten är föremål för utredningen. Filtret ersätter inte kontrollen av om de egna systemen faktiskt är berörda.

Klicka på familjenamnet för att öppna detaljpanelen på sidan. Läs först Malware family overview för beskrivning och klassificering, därefter Technical details för beteende, förmågor och indikatorer. Solution and mitigation innehåller rekommenderade skyddsåtgärder. Rekommendationerna granskas mot den egna plattformen och befintligt skydd; genomför dem inte enbart på grund av en sökträff.

Relaterad hotinformation finns, när den är tillgänglig, på egna flikar:

  • Threat Group anger grupper som använder denna malware.
  • Threat Report leder till relaterade CTU-rapporter.
  • Related Detections visar Detection-data från den egna miljön.
  • Related Detectors visar Sophos XDR-detektorer som känner igen denna malware.

Med ikonen New Tab kan detaljvyn öppnas i en ny flik. Därifrån kan URL:en kopieras som en exakt hänvisning i utredningsprotokollet. Det är mer användbart än enbart familjenamnet när flera analytiker ska granska samma post.

Välj Threat Report för den konkreta frågan

Threat Report innehåller CTU-publikationer som dagliga lägesrapporter, fördjupade analyser och hotmeddelanden. För en konkret Detection söker man först efter malware, grupp eller CVE; för en regelbunden lägesbild passar ämne och publikationstyp.

Filtren skiljer mellan innehåll och publikationsform:

  • Threat Report söker efter rapportnamn, exempelvis Daily Threat Brief eller Ransomware Analysis.
  • Report Type är den allmänna publikationskategorin, exempelvis Advisory, Analysis eller Brief.
  • Category anger en mer specifik typ, exempelvis Customer Advisory, Threat Analysis eller CTU TIPS.
  • Threat Type avgränsar vilka hot som behandlas, exempelvis Ransomware, APT eller Cybercrime.
  • Threat Actor Type skiljer mellan aktörstyper som Nation-state, Cybercriminal och Hacktivist.
  • Target Geography söker efter geografisk inriktning, exempelvis Europe eller Global.
  • Target Sectors avgränsar de branscher som diskuteras, exempelvis Financial, Healthcare eller Government.
  • Threat Group, Malware och CVE söker efter de grupper, malwarefamiljer och sårbarheter som behandlas i rapporten.

Target Geography och Target Sectors hjälper till att prioritera men utesluter inte risk för den egna miljön. Opportunistiska angrepp kan drabba alla regioner och branscher även utan en särskild målpreferens. Begränsa därför inte lägesbilden enbart till den egna branschen.

Klicka på rapportnamnet och läs detaljpanelen. Beroende på rapport finns Full report text, Executive summary, Technical details och Indicators of compromise tillgängliga. Alla publikationer innehåller inte alla dessa delar. Indicators of compromise kan innehålla relaterade IOC:er och signaturer. Sammanfattningen ger orientering; för utredningen är de konkreta tekniska uppgifterna och deras gränser avgörande.

När de finns visar Related Detections egna Detections och Related Detectors XDR-detektorer som nämns i rapporten. Även här är tillgänglig detektionslogik och en observerad träff i tenanten två olika saker. Öppna hela rapporten via New Tab och kopiera vid behov URL:en till Case.

Bedöm Threat Group som en arbetshypotes

Threat Group beskriver kända hotgrupper och deras TTP:er. Vyn är användbar när en rapport nämner en grupp, ett känt alias ska identifieras eller den egna försvarsförmågan mot vissa tillvägagångssätt ska bedömas.

Filtren omfattar identitet, avsikt och tillvägagångssätt:

  • Threat Group söker efter gruppbeteckning, exempelvis GOLD MYSTIC eller BRONZE ATLAS.
  • Thematic Area avgränsar tematiskt eller regionalt sammanhang, exempelvis Cybercrime, China eller Russia.
  • Aliases söker efter alternativa namn som APT1, Lazarus Group eller FIN7.
  • Status skiljer mellan aktuella aktivitetslägen, exempelvis Active och Inactive.
  • Motivation beskriver drivkrafter som Financial, Political eller Military.
  • Objectives beskriver mål som Financial Gain, Espionage eller Disruption.
  • Target Geography och Target Sectors söker efter geografiska respektive branschspecifika målmönster.
  • Malware söker efter relaterade familjer; Tools efter verktyg och tekniker som används, exempelvis PowerShell, Mimikatz eller PsExec.

Även grupper utan en särskild målpreferens kan drabba den egna regionen eller branschen. En tom lista efter ett branschfilter är därför inget klartecken.

Efter ett klick på gruppnamnet innehåller detaljpanelen Group description med bakgrund och bedömda förmågor, Attribution assessment med geografisk eller organisatorisk attribution, Activity timeline med kampanjer och operationer samt analys av Tactics, Techniques, and Procedures. New Tab öppnar detaljerna så att en direkt hänvisning kan kopieras.

Attribution assessment är fortfarande en bedömning från CTU. Den bevisar varken vem som ligger bakom en egen incident eller att varje användning av samma malware hör till denna grupp. Anteckna därför exempelvis ”Beteendet stämmer med de beskrivna teknikerna” i Case och dokumentera separat vilka egna Events som stöder påståendet. En definitiv aktörsattribution kräver mer evidens än en träff på namn, verktyg eller malware.

Från hotinformation till Detection och Case

Threat Intelligence berikar Detections automatiskt med relevant sammanhang; flera XDR-detektorer använder dessa data för detektion. Det innebär inget löfte om att varje beskriven teknik upptäcks i varje tenant. Utredningen går därför från sammanhanget tillbaka till de faktiska händelserna.

Kontrollera egna Detections

Om Related Detections innehåller träffar, öppna en lämplig träff och använd New Tab för att visa hela Detection-detaljvyn. Sök alternativt under Security Operations > Detections. Standardperioden där är 72 timmar; för en äldre incident måste perioden ändras. Kontrollera filter och Include Options så att anpassade eller redan triagerade Detections inte oavsiktligt utesluts.

Kontrollera följande i Detection:

  1. Läs Affected Entities, den utlösande Detector, tillgängliga tidsuppgifter samt Severity och Confidence på Summary. First and Last Activity anger händelsetidpunkter; Inserted At anger när posten registrerades.
  2. Öppna händelserna som ledde till Detection på Events. Visa vid behov underliggande Detection-data på JSON. Sammanfattningen ersätter inte denna evidens.
  3. Kontrollera relaterade öppna och stängda Detections samt Cases på Insights. Befintliga Cases kan undvika dubbelarbete; stängda Cases ger historiskt utredningssammanhang.
  4. För mer hotinformation, klicka på sköldikonen i Affected Entities eller välj en entitet med denna ikon på Entities. Därmed fungerar förflyttningen från Detection till hotinformation även i motsatt riktning.

För en fördjupad undersökning av endpoint-processer och grafer finns Runbooken för Detections och Threat Graphs. Den behandlar även Classic-vyn. Att egna Detections saknas i en hotinformationspost bevisar varken en ren tenant eller fullständig telemetri. Om ytterligare frågor behövs förklarar Runbooken för Data Collection och Live Discover datagrunden och det klassiska frågeflödet.

Koppla relevant evidens till ett Case

Kontrollera före tillägget om ett Case redan finns för samma utredning och om det går att redigera. Cases med status Closed är skrivskyddade, med undantag för Status och Archive; arkiverade Cases tillåter endast Unarchive. Använd sådana Cases i första hand som historiskt sammanhang, inte som självklart redigerbara mål för ny evidens, kommentarer eller ny tilldelning. För MDR-Cases beror tillgängliga åtgärder och alternativ för Assignee även på vem som hanterar Case. Kontrollera de åtgärder som faktiskt är tillgängliga före en ändring och klargör saknade möjligheter med ansvarig handläggare.

Vid överlämningen måste tabellåtgärden skiljas från hela Detection-detaljvyn. De officiella anvisningarna använder inte genomgående samma benämningar för detaljvyn; därför finns ingen tillförlitligt belagd universell menyväg för alla vyer här:

  • Markerade rader i Detections-tabellen: välj önskade Detections och öppna Actions > Add to Case.
  • Hela Detection-detaljvyn: detaljanvisningen anger de direkta åtgärderna Add to Existing Case och Create New Case under Actions. Case-anvisningen beskriver däremot Actions > Add to Case för enskilda Detections, följt av Existing Case eller New Case. Använd den åtgärd som faktiskt visas för ett befintligt respektive nytt Case; leta inte efter en benämning som saknas i denna vy.

Om dialogen Add to Case visas gäller följande steg:

  • För ett befintligt Case, välj Existing Case, sök efter och välj Case och spara med Save to Existing Case.
  • För ett nytt Case, välj New Case, ange Case Type, valfritt en mall, titel, Case Severity och Case Status. Lägg till första fynd och sammanhang via pennikonen vid Key Findings och välj sedan Create New Case.

Vid flerval, kontrollera om endast markerade Detections eller alla Detections i tabellen läggs till. Ta inte med en hel resultatlista utan granskning. Det kan ta några minuter innan evidensen visas i Case; öppna sedan mål-Case och kontrollera den faktiska kopplingen.

För MDR-kunder kräver Case-typerna Investigation och Other även Managed By. Valet avgör vem som hanterar Case och kan inte ändras efter att det har satts. Kontrollera det mot avsett ansvar före sparandet. En senare ändring av Assignee ändrar inte Managed By.

I ett redigerbart Case, dokumentera den kopierade hotinformations-URL:en och de konkreta uppgifter som används som utredningssammanhang, exempelvis i Key Findings eller, om funktionen är tillgänglig, som kommentar på hela Case-detaljsidan via Comments > Comment > Save. Skilj research från tenant-evidens: vad säger rapporten, vad visar egna Events och vad är fortfarande en hypotes? Enbart URL:en bevarar inte innehållet i en analys som kan uppdateras senare; relevanta uppgifter och tidpunkt hör därför hemma i anteckningen.

Den befintliga guiden för Cases och Detection Rules beskriver det klassiska flödet. För Security Operations, följ benämningsvarianterna ovan och de åtgärder som visas i tenanten. Explorer ersätter varken en ansvarig analytiker eller beslutet om begränsning eller sanering.

Exempel: undersök en malwareindikation spårbart

Anta att en egen Detection nämner en malwarefamilj som ännu inte är tillräckligt känd. Exemplet nedan hävdar inte att en sådan träff finns:

  1. Sök efter det faktiska familjenamnet; Emotet är bara ett exempelvärde. Välj inte omedelbart även en bransch eller grupp.
  2. Läs beskrivning, tekniska detaljer och skyddsrekommendationer. Granska en tillgänglig rapport om det observerade beteendet under Threat Report.
  3. Sök efter egna träffar under Related Detections. Kontrollera varje relevant träff mot enhet eller entitet, händelsetid och konkreta Events. Använd Related Detectors för att förstå vilken detektionslogik som hör till sammanhanget.
  4. Om en grupp nämns, jämför dess TTP:er och aktivitetstidslinje. Behandla attributionen som en bedömning även om enskilda kännetecken stämmer.
  5. Koppla relevanta Detections till ett befintligt eller nytt Case. Anteckna i Case: undersökt hotinformationspost, tidpunkt för research, sökbegrepp och filter, hänvisningar till egna Detections, belagda likheter, öppna frågor och nästa handläggare.

Ett användbart resultat kan också vara att rapporten bara visar en allmän likhet. Dokumentera då denna gräns i stället för att dra slutsatsen att en kompromettering har skett eller identifiera en viss angripare.

Kontrollera resultatet och lös vanliga återvändsgränder

Undersökningen är spårbar när en annan analytiker kan öppna samma hotinformationspost, förstå de använda filtren och följa varje slutsats tillbaka till egna Detection- och Event-data. Vid Case-överlämning, kontrollera dessutom att rätt Detections finns i rätt Case och att nästa åtgärd är tilldelad en ansvarig handläggare. Om Case går att redigera och åtgärden är tillgänglig kan handläggaren väljas i hela Case-detaljvyn under Manage Case > Assignee.

Om resultaten inte stämmer hjälper följande kontroller:

  • Inga sökträffar: kontrollera stavning och för grupper Aliases. Ta bort extra filter; återställ sökning och tabellfilter med X i sökfältet och börja om bredare. En tom sökning säger inte i sig något om miljöns risk.
  • För många träffar: lägg till ett relevant kännetecken, exempelvis Type för malware eller Report Type och Threat Type för rapporter. Avgränsa även tidsperioden i Detections. Detections-tabellen är begränsad till 10 000 resultat; aggregerade filterresultat omfattar högst 1 000. En bred vy är därför ingen fullständig inventering.
  • Rapport utan förväntade IOC:er eller flikar: tillgängligt innehåll beror på rapporten. Läs hela texten och den relaterade hotinformation som finns utan att förutsätta saknat innehåll eller viss täckning.
  • Detektorer finns, men inga egna träffar: skilj Detector-sammanhang från observerad Detection. Kontrollera tidsperiod, filter och telemetri som finns tillgänglig för utredningen. Kör inte malware och stäng inte av skydd som test.
  • Explorer är inte tillgänglig: kontrollera först XDR-/Enterprise-licens och använd tenant. Om den nya navigeringen saknas, kontrollera meddelanden om övergången i konsolen; dra inte slutsatsen att produkten har ett tekniskt fel utifrån en saknad meny.
  • Case-evidens syns ännu inte: vänta några minuter på bearbetningen och kontrollera sedan urval och mål-Case igen. Skapa inte omedelbart ett andra Case.

Sökning och filter används här endast för research; för en omstart räcker den beskrivna återställningen. Att lägga till evidens eller kommentarer, och särskilt det oföränderliga valet av Managed By, ändrar däremot Case. Runbooken ger inget generellt ångra-steg för detta. Felaktiga kopplingar klargörs och dokumenteras tillsammans med ansvarig Case-handläggare. Stäng inte Cases som städåtgärd: en stängning ändrar även bedömningarna av tillhörande Detections.

För löpande drift, granska regelbundet nya malwareposter, gruppaktiviteter och rapporter. Branschfilter kan fokusera lägesbilden men bör komplettera den allmänna överblicken. Resultaten hör hemma i incidenthanteringen; gruppers TTP:er kan användas för hotmodellering, malwareanalyser för planering och kontroll av egna skyddsåtgärder. Ny hotinformation är anledning till en ny bedömning, inte automatiskt ett bevis för att en konfigurationsändring behövs.