Trin 5. Udvikl og test use cases
Gælder for:
- Microsoft Defender XDR
De anbefalede metoder til udrulning af Microsoft Defender XDR i SOC (Security Operations Center) afhænger af SOC-teamets aktuelle sæt værktøjer, processer og færdigheder. Det kan være en udfordring at opretholde cyberhygiejne på tværs af platforme på grund af den enorme mængde data, der kommer fra snesevis, hvis ikke hundredvis af sikkerhedskilder.
Sikkerhedsværktøjer er indbyrdes forbundne. Hvis du aktiverer en funktion i en sikkerhedsteknologi eller ændrer en proces, kan det også ødelægge en anden funktion. Derfor anbefaler Microsoft, at dit SOC-team formaliserer en metode til definition og prioritering af use cases. Use cases hjælper med at definere krav og testprocesser for SOC-handlinger på tværs af forskellige teams. Den opretter en metode til registrering af målepunkter for at bestemme, om de rigtige roller og en blanding af opgaver er justeret i forhold til det rigtige team med det rigtige færdighedssæt.
Udvikl og formaliser processen for use case
SOC bør definere en standard og en proces på højt niveau for udvikling af use cases, som skal reguleres af SOC-tilsynsteamet. SOC Tilsynsteamet bør arbejde med din virksomhed, it, juridiske, HR og andre grupper for at prioritere use cases for SOC, der i sidste ende vil gøre deres vej ind i SOC-teamets runbooks og playbooks. Prioriteten af use cases er baseret på målsætninger, f.eks. overholdelse af angivne standarder eller beskyttelse af personlige oplysninger.
SOC Tilsynsaktiviteter i forbindelse med udvikling af use case omfatter:
- Forudsætninger
- Personale- eller uddannelsesbehov
- Softwarelicenser
- Leverandørkontr.
- Administration af plan
- Vedligeholdelse af use case-registreringsdatabasen
- Vedligeholdelse/opdatering af skabeloner
For at facilitere processerne for oprettelse af runbook og playbook skal du oprette et beslutningstræ for use case. Dette figur viser et eksempel.
Når der er defineret og godkendt en standard for use case på højt niveau, er det næste trin at oprette og teste en faktisk use case. I følgende afsnit bruges scenarier til anti-phishing og trussels- og sårbarhedsscanning som eksempler.
Eksempel på brugseksempel 1: Ny phishing-variant
Det første trin i oprettelsen af en use case er at skitsere arbejdsprocessen ved hjælp af et historieforum. Her er et eksempel på et historieforum på højt niveau for en ny meddelelse om phishing-udnyttelse til et Threat Intelligence-team.
Aktivér arbejdsprocessen for use case, f.eks. 1
Når tekstenhedstavlen er blevet godkendt, er det næste trin at aktivere arbejdsprocessen for use case. Her er et eksempel på en proces til en anti-phishing-kampagne.
Eksempel 2 i brugseksempel: Scanning af trusler og sårbarheder
Et andet scenarie, hvor der kan bruges en use case, er til scanning af trusler og sårbarheder. I dette eksempel kræver SOC, at trusler og sårbarheder afhjælpes mod aktiver via godkendte processer, der omfatter scanning af aktiver.
Her er et eksempel på et storyboard på højt niveau for Admininstration af håndtering af sikkerhedsrisici til Microsoft Defender af aktiver.
Aktivér arbejdsprocessen for use case, f.eks. 2
Her er et eksempel på en proces til scanning af trusler og sårbarheder.
Analysér outputtet fra use case og de erfaringer, du har lært
Når en use case er blevet godkendt og testet, skal der identificeres huller blandt dine sikkerhedsteams sammen med personer, processer og de involverede Microsoft Defender XDR teknologier. Microsoft Defender XDR teknologier skal analyseres for at afgøre, om de er i stand til at opnå de ønskede resultater. Disse kan spores via en tjekliste eller en matrix.
I eksemplet med anti-phishing-scenariet kunne SOC-teams f.eks. have gjort opdagelserne i denne tabel.
| SOC-team | Krav | Mennesker opfylder kravene | Behandl for at opfylde kravet | Relevant teknologi | Identificeret mellemrum | Ændringslog for use case | Undtaget (Y/N) |
|---|---|---|---|---|---|---|---|
| Threat Intelligence- og Analytics-team | Datakilder fodrer trusselsintelligensmotorerne korrekt. | Threat Intelligence-analytiker/-tekniker | Fastsatte krav til datafeeds, udløser trusselsintelligens fra godkendte kilder | Microsoft Defender for Identity, Microsoft Defender for Endpoint | Threat Intelligence-teamet brugte ikke automatiseringsscript til at linke Microsoft Defender XDR API til trussels-Intel-motorer | Føj Microsoft Defender XDR som datakilder til trusselsprogrammer Opdater kørselsbog for use case |
N |
| Overvågningsteam | Datakilder forsyner overvågningsdashboards korrekt | Niveau 1,2 SOC-analytiker – overvågning & beskeder | Arbejdsproces til rapportering af sikker score for Security & Compliance Center | Undersøg beskeder i Microsoft Defender XDR Overvågning af sikker score |
Soc-analytikere kan ikke rapportere en vellykket ny phishing-variantregistrering for at forbedre Sikker score Få vist mailsikkerhedsrapporter på Microsoft Defender-portalen |
Føj en proces til sporing af sikker scoreforbedring til arbejdsprocesser i rapportering | N |
| Teknisk team og SecOps-team | Ændringskontrolopdateringer foretages i SOC-teamets runbooks | Niveau 2 SOC-tekniker | Meddelelsesprocedure for ændring af kontrol for SOC-team runbooks | Godkendte ændringer af sikkerhedsenheder | Ændringer af Microsoft Defender XDR forbindelse til SOC-sikkerhedsteknologien kræver godkendelse | Føj Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center til SOC-runbooks | Y |
Derudover kunne SOC-holdene have foretaget de opdagelser, der er beskrevet i nedenstående tabel, med hensyn til defender Vulnerability Management-scenariet, der er beskrevet ovenfor:
| SOC-team | Krav | Mennesker opfylder kravene | Behandl for at opfylde kravet | Relevant teknologi | Identificeret mellemrum | Ændringslog for use case | Undtaget (Y/N) |
|---|---|---|---|---|---|---|---|
| SOC-tilsyn | Alle aktiver, der er forbundet til godkendte netværk, identificeres og kategoriseres | SOC Tilsyn, BU ejere, programejere, it-aktiv ejere, osv. | Centraliseret system til administration af aktiver for at finde og vise aktivkategori og -attributter baseret på risiko. | ServiceNow eller andre aktiver. Oversigt over Microsoft 365-enheder |
Kun 70% af aktiverne er blevet opdaget. Microsoft Defender XDR afhjælpningssporing, der kun gælder for kendte aktiver | Ældre tjenester til administration af aktivlivscyklus for at sikre, at Microsoft Defender XDR har 100 % dækning | N |
| Tekniske & SecOps Teams | Høj indvirkning og kritiske sårbarheder i aktiver afhjælpes i henhold til politikken | SecOps-teknikere, SOC-analytikere: Sårbarhed & overholdelse af angivne standarder, sikkerhedskonstruktion | Defineret proces til kategorisering af høj risiko og kritiske sikkerhedsrisici | Admininstration af håndtering af sikkerhedsrisici til Microsoft Defender dashboards | Defender for Endpoint har identificeret høj indvirkning, enheder med høj besked uden afhjælpningsplan eller implementering af Microsofts anbefalede aktivitet | Tilføj en arbejdsproces for at give aktivejere besked, når afhjælpningsaktivitet er påkrævet inden for 30 dage pr. politik. Implementer et billetsystem for at give aktivejere besked om afhjælpningstrin. | N |
| Overvågningsteams | Trussels- og sårbarhedsstatus rapporteres via virksomhedens intranetportal | Soc-analytiker på niveau 2 | Automatisk genererede rapporter fra Microsoft Defender XDR, der viser status for afhjælpning af aktiver | Undersøg beskeder i Microsoft Defender XDR Overvågning af sikker score |
Der kommunikeres ingen visninger eller dashboardrapporter til aktivejere vedrørende aktivernes trussels- og sårbarhedsstatus. | Create automatiseringsscript til at udfylde status for afhjælpning af højrisiko- og kritisk aktivsårbarhed i organisationen. | N |
I disse eksempelanvendelsessager viste testen flere huller i SOC-teamets krav, der blev fastlagt som basispunkter for hvert teams ansvarsområder. Brugscasens tjekliste kan være lige så omfattende som nødvendigt for at sikre, at SOC-teamet er forberedt til Microsoft Defender XDR integration med nye eller eksisterende SOC-krav. Da dette er en iterativ proces, tjener use case-udviklingsprocessen og indholdet af use case-output naturligvis til at opdatere og modne SOC's runbooks med erfaringer.
Opdater produktions runbooks og playbooks
Når use case-test er blevet afhjulpet for alle huller, kan de erfaringer og målepunkter, der indsamles i dem, inkorporeres i soc-teamets produktions runbooks (operativsystemer) og playbooks (hændelsessvar og eskaleringsprocedurer).
Vedligeholdelse af SOC-teamets runbooks og playbooks kan organiseres på mange måder. Hvert SOC-team kan være ansvarlig for deres egne, eller der kan være en enkelt centraliseret version, som alle teams kan dele i et centralt lager. Administration af runbooks og strategibøger for de enkelte organisationer er baseret på størrelse, kompetencesæt, roller og opdeling af opgaver. Når en runbook er blevet opdateret, bør opdateringsprocessen for playbook følge.
Brug en standardstruktur til eskalering
Playbooks er de trin, SOC-holdene skal følge, når der opstår en rigtig begivenhed, baseret på vellykket integration og test af use case. Det er derfor altafgørende, at SOC følger en formaliseret tilgang til svar på hændelser, f.eks . NIST Incident Response Standard , der er blevet en af de førende branchestandarder for svar på hændelser.
NIST-processen for svar på fire trin indeholder fire faser:
- Under forberedelse
- Registrering og analyse
- Opbevaring, udryddelse og genopretning
- Aktivitet efter hændelse
Eksempel: Sporing af aktivitet i forberedelsesfasen
Et af de centrale fundamenter for en eskalering playbook er at sikre, at der er lidt flertydighed med hensyn til, hvad hvert SOC-team skal gøre før, under og efter en begivenhed eller hændelse. Det er derfor god praksis at angive trinvise instruktioner.
Forberedelsesfasen kan f.eks. indeholde en if/then- eller XoR-matrix med opgaver. I tilfælde af brugseksempel på den nye phishing-variant kan en sådan matrix se sådan ud:
| Hvorfor er eskalering berettiget? | Næste trin |
|---|---|
| Besked i SOC-overvågning bedømt som kritisk udløst >500/time | Gå til Playbook A, Sektion 2, Aktivitet 5 (med et link til playbook-sektionen) |
| eCommerce rapporterede potentielle DDoS-angreb | Aktivér Playbook B-sektion C, Aktivitet 19 (med et link til playbook-sektionen) |
| Direktør rapporterede en mistænkelig e-mail som et forsøg på phishing i spyd | Gå til Playbook 5, Sektion 2, Aktivitet 5 (med et link til playbook-sektionen) |
Når du har kørt forberedelsesfasen, skal organisationer aktivere de resterende faser som beskrevet af NIST:
- Registrering og analyse
- Opbevaring, udryddelse og genopretning
- Aktivitet efter hændelse
Næste trin
Trin 6. Identificer SOC-vedligeholdelsesopgaver
Tip
Vil du vide mere? Kontakt Microsoft Security-community'et i vores Tech Community: Microsoft Defender XDR Tech Community.