Del via


Trinn 5. Utvikle og teste brukstilfeller

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.

Beslutningsprosessen for brukstilfeller

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.

Arbeidsflyten for et brukstilfelle for en anti-phishing-kampanje

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.

En detaljert arbeidsflyt for brukstilfeller 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.

En brukstilfellearbeidsflyt for Håndtering av trusler og sikkerhetsproblemer

Aktiver brukstilfellearbeidsflyten for eksempel 2

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

En detaljert arbeidsflyt for brukstilfeller for Håndtering av trusler og sikkerhetsproblemer

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:

  1. Forberedelse
  2. Gjenkjenning og analyse
  3. Oppdeving, utryddelse og gjenoppretting
  4. 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.