Trinn 5. Utvikle og teste brukstilfeller

Artikkel
04/27/2024

Gjelder for:

Microsoft Defender XDR

De anbefalte metodene for å distribuere Microsoft Defender XDR i Security Operations Center (SOC) avhenger av SOC-teamets gjeldende sett med verktøy, prosesser og kompetansesett. Å opprettholde cyberhygiene på tvers av plattformer kan være utfordrende på grunn av den enorme mengden data som kommer fra dusinvis, om ikke hundrevis av sikkerhetskilder.

Sikkerhetsverktøy er koblet sammen. Hvis du slår på én funksjon i en sikkerhetsteknologi eller endrer en prosess, kan det i sin tur ødelegge en annen. Derfor anbefaler Microsoft at SOC-teamet formaliserer en metode for å definere og prioritere brukstilfeller. Brukstilfeller bidrar til å definere krav og testprosesser for SOC-operasjoner på tvers av ulike team. Det oppretter en metode for å registrere måledata for å avgjøre om de riktige rollene og blandingen av oppgaver er justert til riktig team med riktig kompetansesett.

Utvikle og formalisere brukstilfelleprosess

SOC bør definere en standard og prosess på høyt nivå for utvikling av brukstilfeller, som vil bli regulert av SOC Oversight-teamet. SOC Oversight-teamet bør samarbeide med bedriften din, IT, juridiske, HR og andre grupper for å prioritere brukstilfeller for SOC som til slutt vil komme seg inn i SOC-teamets runbooks og playbooks. Prioritet for brukstilfeller er basert på målsettinger, for eksempel samsvar eller personvern.

SOC Oversight aktiviteter knyttet til bruk saksutvikling inkluderer:

Krav
Bemannings- eller opplæringsbehov
Programvarelisenser
Leverandørkontrakt
Administrere plan
Vedlikeholder brukstilfelleregister
Vedlikeholde/oppdatere maler

Opprett et beslutningstre for brukstilfeller for å forenkle prosessene for oppretting av runbook og strategiplan. Denne illustrasjonen viser et eksempel.

Når en standard for brukstilfeller på høyt nivå er definert og godkjent, er neste trinn å opprette og teste et faktisk brukstilfelle. Avsnittene nedenfor bruker scenarier for skanning av anti-phishing og trussel og sårbarhet som eksempler.

Eksempel på brukstilfelle 1: Ny phishing-variant

Det første trinnet i å opprette et brukstilfelle er å skissere arbeidsflyten ved hjelp av en artikkeltavle. Her er et eksempel på en historietavle på høyt nivå for et nytt varsling om phishing-utnyttelse til et trusselintelligens-team.

Aktiver brukstilfellearbeidsflyten for eksempel 1

Når artikkeltavlen er godkjent, er neste trinn å aktivere arbeidsflyten for brukstilfeller. Her er en eksempelprosess for en anti-phishing-kampanje.

Eksempel på brukstilfelle 2: Skanning av trusler og sikkerhetsproblemer

Et annet scenario der et brukstilfelle kan brukes, er for skanning av trusler og sårbarheter. I dette eksemplet krever SOC at trusler og sårbarheter utbedres mot ressurser via godkjente prosesser som inkluderer skanning av ressurser.

Her er et eksempel på en artikkeltavle på høyt nivå for Microsoft Defender Vulnerability Management av aktiva.

Aktiver brukstilfellearbeidsflyten for eksempel 2

Her er en eksempelprosess for skanning av trusler og sårbarheter.

Analyser utdata og erfaringer for brukstilfeller

Etter at et brukstilfelle er godkjent og testet, bør hull mellom sikkerhetsteamene identifiseres, sammen med personer, prosesser og Microsoft Defender XDR teknologiene som er involvert. Microsoft Defender XDR teknologier bør analyseres for å avgjøre om de er i stand til å oppnå ønskede resultater. Disse kan spores via en sjekkliste eller en matrise.

I eksemplet med anti-phishing-scenarioer kan for eksempel SOC-teamene ha gjort funnene i denne tabellen.

SOC-team	Kravet	Folk for å oppfylle kravet	Prosess for å oppfylle krav	Relevant teknologi	Gap identifisert	Endringslogg for brukstilfeller	Fritatt (Y/N)
Trusselintelligens- og analyseteam	Datakilder mater trusselintelligensmotorene på riktig måte.	Trusselintelligensanalytiker/ingeniør	Krav til datafeed etablert, trusselintelligensutløsere fra godkjente kilder	Microsoft Defender for identitet, Microsoft Defender for endepunkt	Threat Intelligence-teamet brukte ikke automatiseringsskript til å koble Microsoft Defender XDR API med trusselintelligensmotorer	Legge til Microsoft Defender XDR som datakilder i trusselmotorer Kjør bok for brukstilfeller for oppdateringstilfeller	N
Overvåkingsteam	Datakilder mater overvåkingsinstrumentbordene på riktig måte	Nivå 1,2 SOC-analytiker – overvåking & varsler	Arbeidsflyt for rapportering av sikkerhets- & samsvarssenter – sikker poengsum	Undersøke varsler i Microsoft Defender XDR Overvåking av sikker poengsum	Ingen mekanisme for SOC-analytikere til å rapportere vellykket ny phishing-variantregistrering for å forbedre sikker poengsum Vise e-postsikkerhetsrapporter i Microsoft Defender-portalen	Legg til en prosess for sporing av forbedring av sikker poengsum i rapporteringsarbeidsflyter	N
Engineering og SecOps Team	Endringskontrolloppdateringer gjøres i SOC-teamets runbooks	Soc-ingeniør på nivå 2	Endre kontrollvarslingsprosedyre for SOC-teamets runbooks	Godkjente endringer i sikkerhetsenheter	Endringer i Microsoft Defender XDR tilkobling til SOC-sikkerhetsteknologi krever godkjenning	Legg til Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center i SOC-kjørebøker	Y

I tillegg kunne SOC-teamene ha gjort funnene som er beskrevet i tabellen nedenfor, med hensyn til Defender Vulnerability Management-scenarioet som er beskrevet ovenfor:

SOC-team	Kravet	Folk for å oppfylle kravet	Prosess for å oppfylle krav	Relevant teknologi	Gap identifisert	Endringslogg for brukstilfeller	Fritatt (Y/N)
SOC-tilsyn	Alle ressurser som er koblet til godkjente nettverk, identifiseres og kategoriseres	SOC Oversight, BU-eiere, programeiere, IT-eiere osv.	Sentralisert ressursstyringssystem for å oppdage og liste aktivakategori og attributter basert på risiko.	ServiceNow eller andre aktiva. Microsoft 365 Device Inventory	Bare 70% av eiendelene har blitt oppdaget. Microsoft Defender XDR utbedringssporing bare effektiv for kjente aktiva	Modne administrasjonstjenester for ressurslivssyklus for å sikre at Microsoft Defender XDR har 100 % dekning	N
Engineering & SecOps Teams	Høy innvirkning og kritiske sårbarheter i eiendeler utbedres i henhold til policyen	SecOps-ingeniører, SOC-analytikere: Vulnerability & Compliance, Security Engineering	Definert prosess for kategorisering av høy risiko og kritiske sårbarheter	Microsoft Defender Vulnerability Management instrumentbord	Defender for Endpoint har identifisert høy effekt, høy varsling enheter uten utbedringsplan eller implementering av Microsoft anbefalt aktivitet	Legg til en arbeidsflyt for å varsle aktivaeiere når utbedringsaktivitet kreves innen 30 dager per policy. Implementer et billettsystem for å varsle ressurseiere om utbedringstrinn.	N
Overvåking av team	Status for trussel og sårbarhet rapporteres via intranettportalen for firmaet	Soc-analytiker på nivå 2	Automatisk genererte rapporter fra Microsoft Defender XDR som viser utbedringsfremdrift for aktiva	Undersøke varsler i Microsoft Defender XDR Overvåking av sikker poengsum	Ingen visninger eller instrumentbordrapporter blir kommunisert til aktivaeiere angående trussel- og sårbarhetsstatus for aktiva.	Opprett automatiseringsskript for å fylle ut statusen høy risiko og kritisk utbedring av aktivasårbarhet til organisasjonen.	N

I disse eksempelbrukstilfellene viste testingen flere hull i SOC-teamets krav som ble etablert som opprinnelige planer for ansvarsområder for hvert team. Sjekklisten for brukstilfeller kan være så omfattende som nødvendig for å sikre at SOC-teamet er forberedt på Microsoft Defender XDR integrering med nye eller eksisterende SOC-krav. Siden dette er en gjentakende prosess, tjener brukstilfelleutviklingsprosessen og utdatainnholdet for brukstilfeller naturlig til å oppdatere og modne SOCs runbooks med erfaringer.

Oppdatere produksjonskjøringsbøker og strategibøker

Når brukstilfelletesting er utbedret for alle hull, kan erfaringene og måledataene som samles inn i dem, innlemmes i SOC-teamets produksjonskjøringsbøker (driftsprosesser) og strategibøker (hendelsessvar og eskaleringsprosedyrer).

Vedlikehold av SOC-teamets runbooks og playbooks kan organiseres på en rekke måter. Hvert SOC-team kan være ansvarlig for sine egne, eller det kan være en enkelt sentralisert versjon for alle team å dele i et sentralt repositorium. Administrasjon av runbook og strategiplan for individuelle organisasjoner er basert på størrelse, ferdighetssett, roller og segregering av oppgaver. Når en runbook er oppdatert, bør oppdateringsprosessen for strategiplanen følge.

Bruk et standard rammeverk for eskalering

Strategibøker er trinnene SOC-teamene må følge når en ekte hendelse inntreffer, basert på vellykket integrering og test av brukstilfellet. Derfor er det viktig at SOC følger en formalisert tilnærming til hendelsesrespons, for eksempel NIST Incident Response Standard som har blitt en av de ledende industristandardene for hendelsesrespons.

NIST firetrinns hendelsesresponsprosess inkluderer fire faser:

Forberedelse
Gjenkjenning og analyse
Oppdeving, utryddelse og gjenoppretting
Aktivitet etter hendelser

Eksempel: Sporing av forberedelsesfaseaktivitet

Et av hovedgrunnlaget for en videresendingsstrategi er å sikre at det er liten tvetydighet med hensyn til hva hvert SOC-team skal gjøre før, under og etter en hendelse eller hendelse. Derfor er det god praksis å liste opp trinnvise instruksjoner.

Forberedelsesfasen kan for eksempel inkludere en if/then- eller XoR-matrise med oppgaver. Når det gjelder det nye eksemplet på phishing-variant, kan en slik matrise se slik ut:

Hvorfor garanteres eskalering?	Neste trinn
Varsel i SOC-overvåking klassifisert som kritisk utløst >500/time	Gå til Strategiplan A, Del 2, Aktivitet 5 (med en kobling til strategiplandelen)
e-handel rapporterte mulig DDoS-angrep	Aktiver strategiplan B-inndeling C, aktivitet 19 (med en kobling til strategiplandelen)
Executive rapporterte en mistenkelig e-post som spyd phishing-forsøk	Gå til Strategiplan 5, Del 2, Aktivitet 5 (med en kobling til strategiplandelen)

Etter å ha utført forberedelsesfasen, bør organisasjoner aktivere de gjenværende fasene som beskrevet av NIST:

Gjenkjenning og analyse
Oppdeving, utryddelse og gjenoppretting
Aktivitet etter hendelser

Neste trinn:

Trinn 6. Identifiser SOC-vedlikeholdsoppgaver

Tips

Vil du lære mer? Kommuniser med Microsoft Sikkerhet-fellesskapet i det tekniske fellesskapet vårt: Microsoft Defender XDR Tech Community.

Del via