Stap 5. Use cases ontwikkelen en testen

Artikel
04/28/2024

Van toepassing op:

Microsoft Defender XDR

De aanbevolen methoden voor het implementeren van Microsoft Defender XDR in uw Security Operations Center (SOC) zijn afhankelijk van de huidige set hulpprogramma's, processen en vaardigheden van het SOC-team. Het onderhouden van cyberhygiëne op alle platforms kan lastig zijn vanwege de enorme hoeveelheid gegevens die afkomstig is van tientallen, zo niet honderden beveiligingsbronnen.

Beveiligingshulpprogramma's zijn onderling gerelateerd. Het inschakelen van een functie in een beveiligingstechnologie of het wijzigen van een proces kan op zijn beurt een andere functie onderbreken. Daarom raadt Microsoft uw SOC-team aan om een methode te formaliseren voor het definiëren en prioriteren van use cases. Use cases helpen bij het definiëren van vereisten en testprocessen voor SOC-bewerkingen in verschillende teams. Er wordt een methodologie gemaakt voor het vastleggen van metrische gegevens om te bepalen of de juiste rollen en een combinatie van taken zijn afgestemd op het juiste team met de juiste vaardigheden.

Use Case-proces ontwikkelen en formaliseren

Het SOC moet een standaard en proces op hoog niveau definiëren voor het ontwikkelen van use cases, die worden gereguleerd door het SOC-toezichtsteam. Het SOC Oversight-team moet samenwerken met uw bedrijf, IT, juridische afdeling, HR en andere groepen om prioriteit te geven aan use cases voor de SOC die uiteindelijk hun weg vinden in de runbooks en playbooks van het SOC-team. De prioriteit van use cases is gebaseerd op doelstellingen, zoals naleving of privacy.

SOC Oversight-activiteiten met betrekking tot de ontwikkeling van use case zijn onder andere:

Vereisten
Personeels- of trainingsbehoeften
Softwarelicenties
Contractering leverancier
Plan beheren
Use-caseregister bijhouden
Sjablonen onderhouden/bijwerken

Maak een beslissingsstructuur voor use-case om de processen voor het maken van runbooks en playbooks te vergemakkelijken. In deze afbeelding ziet u een voorbeeld.

Zodra een use-casestandaard op hoog niveau is gedefinieerd en goedgekeurd, is de volgende stap het maken en testen van een werkelijke use-case. In de volgende secties worden scenario's voor antiphishing en het scannen van bedreigingen en beveiligingsproblemen als voorbeelden gebruikt.

Voorbeeld van use case 1: nieuwe phishingvariant

De eerste stap bij het maken van een use case is het schetsen van de werkstroom met behulp van een storyboard. Hier volgt een voorbeeld van een storyboard op hoog niveau voor een nieuwe phishing-exploitmelding aan een Threat Intelligence-team.

De use case-werkstroom aanroepen, bijvoorbeeld 1

Zodra het storyboard is goedgekeurd, is de volgende stap het aanroepen van de use case-werkstroom. Hier volgt een voorbeeldproces voor een antiphishingcampagne.

Voorbeeld van use case 2: scannen op bedreigingen en beveiligingsproblemen

Een ander scenario waarin een use case kan worden gebruikt, is voor het scannen van bedreigingen en beveiligingsproblemen. In dit voorbeeld vereist de SOC dat bedreigingen en beveiligingsproblemen worden hersteld tegen assets via goedgekeurde processen die het scannen van assets omvatten.

Hier volgt een voorbeeld van een storyboard op hoog niveau voor het Microsoft Defender Vulnerability Management van assets.

De use case-werkstroom aanroepen, bijvoorbeeld 2

Hier volgt een voorbeeldproces voor het scannen van bedreigingen en beveiligingsproblemen.

De uitvoer van de use-case en geleerde lessen analyseren

Nadat een use-case is goedgekeurd en getest, moeten hiaten tussen uw beveiligingsteams worden geïdentificeerd, samen met personen, processen en de Microsoft Defender XDR technologieën die hierbij betrokken zijn. Microsoft Defender XDR technologieën moeten worden geanalyseerd om te bepalen of ze de gewenste resultaten kunnen bereiken. Deze kunnen worden bijgehouden via een controlelijst of een matrix.

In het voorbeeld van het antiphishingscenario kunnen de SOC-teams bijvoorbeeld de ontdekkingen in deze tabel hebben gedaan.

SOC-team	Vereiste	Mensen om te voldoen aan de vereiste	Proces om te voldoen aan de vereiste	Relevante technologie	Hiaat geïdentificeerd	Wijzigingslogboek voor use-case	Uitzondering (Y/N)
Bedreigingsinformatie- en analyseteam	Gegevensbronnen voeden de bedreigingsinformatie-engines op de juiste manier.	Threat Intelligence-analist/technicus	Vereisten voor gegevensfeeds vastgesteld, triggers voor bedreigingsinformatie uit goedgekeurde bronnen	Microsoft Defender for Identity, Microsoft Defender voor Eindpunt	Threat Intelligence-team heeft geen automation-script gebruikt om Microsoft Defender XDR API te koppelen aan bedreigingsinformatie-engines	Microsoft Defender XDR als gegevensbronnen toevoegen aan bedreigingsengines Runbook voor use-case bijwerken	N
Bewakingsteam	Gegevensbronnen voeren de bewakingsdashboards op de juiste manier door	Laag 1,2 SOC-analist– Bewaking & waarschuwingen	Werkstroom voor het rapporteren van beveiligingsscore & compliancecentrum	Waarschuwingen onderzoeken in Microsoft Defender XDR Bewaking van beveiligingsscore	Geen mechanisme voor SOC-analisten om geslaagde detectie van nieuwe phishingvarianten te melden om de secure score te verbeteren Beveiligingsrapporten voor e-mail weergeven in de Microsoft Defender-portal	Een proces toevoegen voor het bijhouden van verbetering van de secure score aan rapportagewerkstromen	N
Engineering en SecOps Team	Wijzigingen van besturingselementen worden uitgevoerd in de SOC-teamrunbooks	Laag 2 SOC Engineer	Meldingsprocedure voor wijzigingsbeheer voor SOC-teamrunbooks	Goedgekeurde wijzigingen in beveiligingsapparaten	Voor wijzigingen in Microsoft Defender XDR connectiviteit met SOC-beveiligingstechnologie is goedkeuring vereist	Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center toevoegen aan SOC-runbooks	J

Bovendien hadden de SOC-teams de ontdekkingen kunnen doen die in de onderstaande tabel worden beschreven met betrekking tot het Defender Vulnerability Management-scenario dat hierboven wordt beschreven:

SOC-team	Vereiste	Mensen om te voldoen aan de vereiste	Proces om te voldoen aan de vereiste	Relevante technologie	Hiaat geïdentificeerd	Wijzigingslogboek voor use-case	Uitzondering (Y/N)
SOC-toezicht	Alle assets die zijn verbonden met goedgekeurde netwerken worden geïdentificeerd en gecategoriseerd	SOC-toezicht, BU-eigenaren, toepassingseigenaren, IT-asseteigenaren, enzovoort.	Gecentraliseerd assetbeheersysteem voor het detecteren en vermelden van assetcategorieën en kenmerken op basis van risico.	ServiceNow of andere assets. Microsoft 365-apparaatinventaris	Slechts 70% van de activa is ontdekt. Microsoft Defender XDR alleen effectief voor bekende activa	Volwassen beheerservices voor assetlevenscyclus om ervoor te zorgen dat Microsoft Defender XDR 100% dekking heeft	N
Engineering & SecOps Teams	Grote impact en kritieke beveiligingsproblemen in assets worden hersteld volgens beleid	SecOps-technici, SOC-analisten: Beveiligingsproblemen & Compliance, Security Engineering	Gedefinieerd proces voor het categoriseren van beveiligingsproblemen met een hoog risico en kritieke beveiligingsproblemen	dashboards Microsoft Defender Vulnerability Management	Defender voor Eindpunt heeft apparaten met een hoge impact en hoge waarschuwingen geïdentificeerd zonder herstelplan of implementatie van door Microsoft aanbevolen activiteiten	Voeg een werkstroom toe om eigenaren van activa te informeren wanneer herstelactiviteit binnen 30 dagen per beleid is vereist; Implementeer een ticketsysteem om asseteigenaren op de hoogte te stellen van herstelstappen.	N
Teams bewaken	Bedreigings- en beveiligingsstatus wordt gerapporteerd via de intranetportal van het bedrijf	Laag 2 SOC-analist	Automatisch gegenereerde rapporten van Microsoft Defender XDR met de herstelvoortgang van assets	Waarschuwingen onderzoeken in Microsoft Defender XDR Bewaking van beveiligingsscore	Er worden geen weergaven of dashboardrapporten doorgegeven aan eigenaren van activa met betrekking tot de bedreigings- en beveiligingsstatus van assets.	Creatie automatiseringsscript om de status van herstel van beveiligingsproblemen met een hoog risico en kritieke activa voor de organisatie in te vullen.	N

In deze voorbeeldgebruiksvoorbeelden hebben de tests verschillende hiaten aan het licht gebracht in de vereisten van het SOC-team die zijn vastgesteld als basislijnen voor de verantwoordelijkheden van elk team. De controlelijst voor use case kan zo uitgebreid zijn als nodig is om ervoor te zorgen dat het SOC-team is voorbereid op de Microsoft Defender XDR integratie met nieuwe of bestaande SOC-vereisten. Omdat dit een iteratief proces is, dienen het ontwikkelingsproces van use-case en de inhoud van de use case-uitvoer natuurlijk om de runbooks van de SOC bij te werken en te rijpen met geleerde lessen.

Productie-runbooks en playbooks bijwerken

Zodra het testen van de use-case is hersteld voor alle hiaten, kunnen de geleerde lessen en metrische gegevens die erin zijn verzameld, worden opgenomen in de productierunbooks (operationele processen) en playbooks (reacties op incidenten en escalatieprocedures) van uw SOC-team.

Het onderhoud van de runbooks en playbooks van het SOC-team kan op verschillende manieren worden georganiseerd. Elk SOC-team kan verantwoordelijk zijn voor hun eigen, of er kan één gecentraliseerde versie zijn voor alle teams om te delen in een centrale opslagplaats. Runbook- en playbookbeheer voor afzonderlijke organisaties is gebaseerd op grootte, vaardigheden, rollen en scheiding van taken. Zodra een runbook is bijgewerkt, moet het updateproces van het playbook volgen.

Een standaardframework gebruiken voor escalatie

Playbooks zijn de stappen die de SOC-teams moeten volgen wanneer er een echte gebeurtenis plaatsvindt, op basis van de geslaagde integratie en test van de use case. Daarom is het noodzakelijk dat de SOC een geformaliseerde benadering van incidentrespons volgt, zoals de NIST Incident Response Standard , die een van de toonaangevende industriestandaarden voor incidentrespons is geworden.

Het NIST-reactieproces met vier stappen voor incidenten bestaat uit vier fasen:

Voorbereiding
Detectie en analyse
Insluiting, uitroeiing en herstel
Activiteit na incident

Voorbeeld: Activiteit van de voorbereidingsfase bijhouden

Een van de basisbeginselen van een escalatieplaybook is ervoor te zorgen dat er weinig onduidelijkheid is over wat elk SOC-team moet doen voor, tijdens en na een gebeurtenis of incident. Daarom is het raadzaam om stapsgewijze instructies op te geven.

De voorbereidingsfase kan bijvoorbeeld een als/dan- of XoR-matrix van taken bevatten. In het geval van de nieuwe use case van de phishingvariant kan een dergelijke matrix er als volgt uitzien:

Waarom is escalatie gerechtvaardigd?	Volgende stap
Waarschuwing in SOC-bewaking geclassificeerd als kritiek geactiveerd >500/uur	Ga naar Playbook A, sectie 2, activiteit 5 (met een koppeling naar de playbooksectie)
eCommerce heeft mogelijke DDoS-aanval gerapporteerd	Playbook B-sectie C, activiteit 19 aanroepen (met een koppeling naar de playbook-sectie)
Executive heeft een verdachte e-mail gerapporteerd als spear-phishingpoging	Ga naar Playbook 5, sectie 2, activiteit 5 (met een koppeling naar de playbooksectie)

Na het uitvoeren van de voorbereidingsfase moeten organisaties de resterende fasen aanroepen, zoals beschreven door NIST:

Detectie en analyse
Insluiting, uitroeiing en herstel
Activiteit na incident

Volgende stap

Stap 6. SOC-onderhoudstaken identificeren

Tip

Wil je meer weten? Engage met de Microsoft Security-community in onze Tech Community: Microsoft Defender XDR Tech Community.

Delen via