Steg 5: Utveckla och testa användningsfall

Artikel
04/26/2024

Gäller för:

Microsoft Defender XDR

De rekommenderade metoderna för att distribuera Microsoft Defender XDR i Security Operations Center (SOC) beror på SOC-teamets aktuella uppsättning verktyg, processer och kompetensuppsättningar. Det kan vara svårt att upprätthålla cyberhygienen på olika plattformar på grund av den stora mängden data som kommer från dussintals, om inte hundratals, säkerhetskällor.

Säkerhetsverktyg är kopplade till varandra. Att aktivera en funktion i en säkerhetsteknik eller ändra en process kan i sin tur bryta en annan. Därför rekommenderar Microsoft att SOC-teamet formaliserar en metod för att definiera och prioritera användningsfall. Användningsfall hjälper dig att definiera krav och testprocesser för SOC-åtgärder i olika team. Den skapar en metod för att samla in mått för att avgöra om rätt roller och blandning av uppgifter är anpassade till rätt team med rätt kompetensuppsättning.

Utveckla och formalisera användningsfallsprocessen

SOC bör definiera en högnivåstandard och process för att utveckla användningsfall, som skulle regleras av SOC-tillsynsteamet. SOC Oversight-teamet bör arbeta med din verksamhet, IT, juridiska, HR och andra grupper för att prioritera användningsfall för SOC som så småningom kommer att ta sig in i SOC-teamets runbooks och spelböcker. Prioriteten för användningsfall baseras på mål, till exempel efterlevnad eller sekretess.

SOC-tillsynsaktiviteter som rör användningsfallsutveckling omfattar:

Krav
Personal- eller utbildningsbehov
Programvarulicenser
Leverantörskontrakt
Hantera plan
Underhålla register för användningsfall
Underhålla/uppdatera mallar

Skapa ett beslutsträd för användningsfall för att underlätta processerna för att skapa runbook och spelböcker. Den här bilden visar ett exempel.

När en standard för högnivåanvändningsfall har definierats och godkänts är nästa steg att skapa och testa ett faktiskt användningsfall. I följande avsnitt används scenarier för skydd mot nätfiske, hot och sårbarhetsgenomsökning som exempel.

Exempel på användningsfall 1: Ny nätfiskevariant

Det första steget i att skapa ett användningsfall är att beskriva arbetsflödet med hjälp av en artikeltavla. Här är ett exempel på en övergripande berättelsetavla för ett nytt meddelande om nätfiskeexploatering till ett hotinformationsteam.

Anropa arbetsflödet för användningsfall till exempel 1

När anslagstavlan har godkänts är nästa steg att anropa arbetsflödet för användningsfall. Här är en exempelprocess för en kampanj mot nätfiske.

Exempel på användningsfall 2: Genomsökning av hot och sårbarhet

Ett annat scenario där ett användningsfall kan användas är för hot- och sårbarhetsgenomsökning. I det här exemplet kräver SOC att hot och sårbarheter åtgärdas mot tillgångar via godkända processer som inkluderar genomsökning av tillgångar.

Här är ett exempel på en övergripande storyboard för Microsoft Defender – hantering av säkerhetsrisker av tillgångar.

Anropa arbetsflödet för användningsfall till exempel 2

Här är en exempelprocess för genomsökning av hot och sårbarheter.

Analysera utdata och lärdomar från användningsfall

När ett användningsfall har godkänts och testats bör luckor mellan dina säkerhetsteam identifieras, tillsammans med personer, processer och de Microsoft Defender XDR tekniker som ingår. Microsoft Defender XDR tekniker bör analyseras för att avgöra om de kan uppnå önskade resultat. Dessa kan spåras via en checklista eller en matris.

I exemplet med scenariot mot nätfiske kan SOC-teamen till exempel ha gjort identifieringarna i den här tabellen.

SOC-teamet	Krav	Personer för att uppfylla kraven	Process för att uppfylla krav	Relevant teknik	Identifierad lucka	Ändringslogg för användningsfall	Undantag (Y/N)
Team för hotinformation och analys	Datakällor matar in hotinformationsmotorerna korrekt.	Analytiker/tekniker för hotinformation	Dataflödeskrav upprättade, hotinformationsutlösare från godkända källor	Microsoft Defender for Identity, Microsoft Defender för Endpoint	Teamet för hotinformation använde inte automatiseringsskript för att länka Microsoft Defender XDR API med hotinformationsmotorer	Lägga till Microsoft Defender XDR som datakällor i hotmotorer Uppdatera användningsfallskörningsbok	N
Övervakningsteam	Datakällor matar in övervakningsinstrumentpanelerna korrekt	SOC-analytiker på nivå 1,2 – Övervakning & aviseringar	Arbetsflöde för rapportering av säkerhetspoäng & Efterlevnadscenter	Undersöka aviseringar i Microsoft Defender XDR Övervakning av säkerhetspoäng	Ingen mekanism för SOC-analytiker att rapportera lyckad ny identifiering av nätfiskevarianter för att förbättra säkerhetspoängen Visa säkerhetsrapporter för e-post i Microsoft Defender-portalen	Lägga till en process för att spåra förbättringar av säkerhetspoäng i rapporteringsarbetsflöden	N
Teknik- och SecOps-team	Uppdateringar av ändringskontroll görs i SOC-teamets runbooks	SOC-tekniker på nivå 2	Ändra kontrollmeddelandeproceduren för SOC-team-runbooks	Godkända ändringar av säkerhetsenheter	Ändringar av Microsoft Defender XDR anslutning till SOC-säkerhetsteknik kräver godkännande	Lägg till Microsoft Defender for Cloud Apps, Defender för identitet, Defender för Endpoint, Security & Compliance Center i SOC-runbooks	J

Dessutom kunde SOC-teamen ha gjort de identifieringar som beskrivs i tabellen nedan när det gäller scenariot defender vulnerability management som beskrivs ovan:

SOC-teamet	Krav	Personer för att uppfylla kraven	Process för att uppfylla krav	Relevant teknik	Identifierad lucka	Ändringslogg för användningsfall	Undantag (Y/N)
SOC-tillsyn	Alla tillgångar som är anslutna till godkända nätverk identifieras och kategoriseras	SOC Oversight, BU-ägare, programägare, IT-tillgångsägare osv.	Centraliserat tillgångshanteringssystem för att identifiera och lista tillgångskategorier och attribut baserat på risk.	ServiceNow eller andra tillgångar. Microsoft 365-enhetsinventering	Endast 70 % av tillgångarna har identifierats. Microsoft Defender XDR åtgärdsspårning gäller endast för kända tillgångar	Mogna livscykelhanteringstjänster för tillgångar för att säkerställa att Microsoft Defender XDR har 100 % täckning	N
Teknik & SecOps Teams	Hög påverkan och kritiska sårbarheter i tillgångar åtgärdas enligt principen	SecOps-tekniker, SOC-analytiker: Sårbarhet & efterlevnad, säkerhetsteknik	Definierad process för kategorisering av hög risk och kritiska sårbarheter	Microsoft Defender – hantering av säkerhetsrisker instrumentpaneler	Defender för Endpoint har identifierat hög påverkan, hög aviseringsenheter utan åtgärdsplan eller implementering av Microsofts rekommenderade aktivitet	Lägg till ett arbetsflöde för att meddela tillgångsägare när reparationsaktivitet krävs inom 30 dagar per princip. Implementera ett biljettsystem för att meddela tillgångsägare om reparationssteg.	N
Övervaka Team	Hot- och sårbarhetsstatus rapporteras via företags intranätportalen	SOC-analytiker på nivå 2	Automatiskt genererade rapporter från Microsoft Defender XDR som visar reparationsförloppet för tillgångar	Undersöka aviseringar i Microsoft Defender XDR Övervakning av säkerhetspoäng	Inga vyer eller instrumentpanelsrapporter kommuniceras till tillgångsägare om hot och sårbarhetsstatus för tillgångar.	Skapa automationsskript för att fylla i status för sårbarhetsreparation med hög risk och kritisk tillgång till organisationen.	N

I de här exempelanvändningsfallen visade testningen flera luckor i SOC-teamets krav som fastställdes som baslinjer för ansvarsområdena för varje team. Checklistan för användningsfall kan vara så omfattande som behövs för att säkerställa att SOC-teamet är förberett för Microsoft Defender XDR integrering med nya eller befintliga SOC-krav. Eftersom detta är en iterativ process kan användningsfallsutvecklingsprocessen och utdatainnehållet för användningsfall naturligt uppdatera och mogna SOC:s runbooks med lärdomar.

Uppdatera produktions-runbooks och spelböcker

När användningsfallstestningen har åtgärdats för alla luckor kan de lärdomar och mått som samlas in i dem införlivas i SOC-teamets produktions runbooks (driftsprocesser) och spelböcker (incidenthantering och eskaleringsförfaranden).

Underhåll av SOC-teamets runbooks och spelböcker kan organiseras på många olika sätt. Varje SOC-team kan ansvara för sina egna, eller så kan det finnas en enda central version som alla team kan dela på en central lagringsplats. Runbook- och spelbokshantering för enskilda organisationer baseras på storlek, kompetensuppsättning, roller och uppdelning av uppgifter. När en runbook har uppdaterats bör uppdateringsprocessen för spelboken följa.

Använda ett standardramverk för eskalering

Spelböcker är de steg som SOC-teamen måste följa när en verklig händelse inträffar, baserat på lyckad integrering och test av användningsfallet. Därför är det viktigt att SOC följer en formaliserad metod för incidenthantering, till exempel NIST Incident Response Standard som har blivit en av de ledande branschstandarderna för incidenthantering.

Nist-processen med fyra stegs incidenthantering innehåller fyra faser:

Förberedelse
Identifiering och analys
Inneslutning, utrotning och återställning
Aktivitet efter incident

Exempel: Spåra förberedelsefasaktivitet

En av grunderna i en eskaleringsspelbok är att se till att det finns liten tvetydighet om vad varje SOC-team ska göra före, under och efter en händelse eller incident. Därför är det bra att lista ut stegvisa instruktioner.

Förberedelsefasen kan till exempel innehålla en if/then- eller XoR-matris med uppgifter. När det gäller det nya exemplet på nätfiskevariant kan en sådan matris se ut så här:

Varför är eskalering berättigad?	Nästa steg
Avisering i SOC-övervakning klassificerad som kritisk utlöst >500/timme	Gå till Spelbok A, Avsnitt 2, Aktivitet 5 (med en länk till spelboksavsnittet)
E-handel rapporterade potentiell DDoS-attack	Anropa spelbok B-avsnitt C, aktivitet 19 (med en länk till spelboksavsnittet)
Chef rapporterade ett misstänkt e-postmeddelande som spear phishing-försök	Gå till Spelbok 5, Avsnitt 2, Aktivitet 5 (med en länk till spelboksavsnittet)

När förberedelsefasen har körts bör organisationer anropa de återstående faserna enligt NIST:s beskrivning:

Identifiering och analys
Inneslutning, utrotning och återställning
Aktivitet efter incident

Nästa steg

Steg 6. Identifiera SOC-underhållsaktiviteter

Tips

Vill du veta mer? Engage med Microsofts säkerhetscommunity i vår Tech Community: Microsoft Defender XDR Tech Community.

Dela via