Overzicht van reactie op incidenten

Incidentrespons is de praktijk van het onderzoeken en herstellen van actieve aanvalscampagnes in uw organisatie. Dit maakt deel uit van de secops-discipline (security operations) en is voornamelijk reactief van aard.

Incidentrespons heeft de grootste directe invloed op de totale gemiddelde tijd om te bevestigen (MTTA) en de gemiddelde tijd om te herstellen (MTTR) die meten hoe goed beveiligingsbewerkingen in staat zijn om organisatierisico's te verminderen. Incidentresponsteams zijn sterk afhankelijk van goede werkrelaties tussen teams voor het opsporen van bedreigingen, inlichtingen en incidentbeheer (indien aanwezig) om het risico daadwerkelijk te verminderen. Zie Metrische SecOps-gegevens voor meer informatie.

Zie Cloud SOC-functies voor meer informatie over rollen en verantwoordelijkheden voor beveiligingsbewerkingen.

Proces voor het reageren op incidenten

De eerste stap is het hebben van een plan voor het reageren op incidenten dat zowel interne als externe processen omvat voor het reageren op cyberbeveiligingsincidenten. In het plan moet worden beschreven hoe uw organisatie het volgende moet doen:

• Aanvallen aanpakken die variëren met het bedrijfsrisico en de impact van het incident, die kunnen variëren van een geïsoleerde website die niet meer beschikbaar is voor inbreuk op referenties op beheerdersniveau.
• Definieer het doel van de reactie, zoals een terugkeer naar de service of om juridische of public relations-aspecten van de aanval af te handelen.
• Geef prioriteit aan het werk dat moet worden uitgevoerd in termen van het aantal personen dat aan het incident en hun taken moet werken.

Zie het artikel Over het plannen van reacties op incidenten voor een controlelijst met activiteiten die u kunt overwegen op te nemen in uw plan voor incidentrespons. Zodra uw plan voor incidentrespons is ingesteld, test u het regelmatig op de meest ernstige typen cyberaanvallen om ervoor te zorgen dat uw organisatie snel en efficiënt kan reageren.

Hoewel het incidentresponsproces van elke organisatie kan verschillen op basis van organisatiestructuur en mogelijkheden en historische ervaring, moet u rekening houden met de set aanbevelingen en best practices in dit artikel voor het reageren op beveiligingsincidenten.

Tijdens een incident is het essentieel om:

• Kalm blijven

  Incidenten zijn zeer verstorend en kunnen emotioneel geladen worden. Blijf kalm en richt u op het prioriteren van uw inspanningen op de meest impactvolle acties.

• Doe geen kwaad

  Controleer of uw antwoord is ontworpen en uitgevoerd op een manier die verlies van gegevens, verlies van bedrijfskritieke functionaliteit en verlies van bewijs voorkomt. Het vermijden van beslissingen kan schadelijk zijn voor het maken van forensische tijdlijnen, het identificeren van de hoofdoorzaak en het leren van kritieke lessen.

• Uw juridische afdeling betrekken

  Bepaal of ze van plan zijn om rechtshandhaving in te schakelen, zodat u uw onderzoek- en herstelprocedures op de juiste wijze kunt plannen.

• Wees voorzichtig bij het openbaar delen van informatie over het incident

  Controleer of alles wat u met uw klanten en het publiek deelt, is gebaseerd op het advies van uw juridische afdeling.

• Hulp krijgen wanneer dat nodig is

  Maak gebruik van diepgaande expertise en ervaring bij het onderzoeken van en reageren op aanvallen van geavanceerde aanvallers.

Net als bij het diagnosticeren en behandelen van een medische ziekte, moeten cyberbeveiligingsonderzoek en -respons op een groot incident een systeem verdedigen dat beide is:

• Kritiek belangrijk (kan niet worden afgesloten om eraan te werken).
• Complex (meestal buiten het begrip van één persoon).

Tijdens een incident moet u de volgende kritieke saldi vinden:

• Snelheid

  Maak een balans tussen de noodzaak om snel te handelen om belanghebbenden tevreden te stellen met het risico van gehaaste beslissingen.

• Informatie delen

  Informeer onderzoekers, belanghebbenden en klanten op basis van het advies van uw juridische afdeling om de aansprakelijkheid te beperken en onrealistische verwachtingen te voorkomen.

Dit artikel is ontworpen om het risico voor uw organisatie voor een cyberbeveiligingsincident te verlagen door veelvoorkomende fouten te identificeren om te voorkomen en richtlijnen te bieden over welke acties u snel kunt ondernemen om het risico te verminderen en te voldoen aan de behoeften van belanghebbenden.

Notitie

Zie Uw herstelplan voorbereiden voor aanvullende richtlijnen voor het voorbereiden van uw organisatie op ransomware en andere soorten aanvallen met meerdere fasen.

Best practices voor antwoorden

Met deze aanbevelingen kunt u effectief reageren op incidenten vanuit zowel technisch als operationeel perspectief.

Notitie

Zie de NIST Computer Security Incident Handling Guide (NIST Computer Security Incident Handling Guide) voor aanvullende gedetailleerde richtlijnen in de branche.

Best practices voor technische reacties

Voor de technische aspecten van incidentrespons zijn hier enkele doelen die u moet overwegen:

• Probeer het bereik van de aanvalsbewerking te identificeren.

  De meeste kwaadwillende personen gebruiken meerdere persistentiemechanismen.

• Identificeer indien mogelijk het doel van de aanval.

  Permanente aanvallers keren vaak terug voor hun doel (gegevens/systemen) in een toekomstige aanval.

Hier volgen enkele handige tips:

• Upload geen bestanden naar onlinescanners

  Veel kwaadwillende instanties controleren het aantal exemplaren op services zoals VirusTotal voor detectie van gerichte malware.

• Overweeg wijzigingen zorgvuldig

  Tenzij u te maken krijgt met een onmiddellijke dreiging van verlies van bedrijfskritieke gegevens, zoals verwijdering, versleuteling en exfiltratie, kunt u het risico van het niet aanbrengen van de wijziging in balans brengen met de verwachte bedrijfsimpact. Zo kan het bijvoorbeeld nodig zijn om de internettoegang van uw organisatie tijdelijk af te sluiten om bedrijfskritieke assets te beschermen tijdens een actieve aanval.

  Als er wijzigingen nodig zijn waarbij het risico om een actie niet uit te voeren groter is dan het risico om een actie uit te voeren, documenteert u de actie in een wijzigingenlogboek. Wijzigingen die worden aangebracht tijdens het reageren op incidenten, zijn gericht op het verstoren van de aanvaller en kunnen een negatieve invloed hebben op het bedrijf. U moet deze wijzigingen na het herstelproces terugdraaien.

• Niet voor altijd onderzoeken

  U moet meedogenloos prioriteit geven aan uw onderzoeksinspanningen. Voer bijvoorbeeld alleen forensische analyses uit op eindpunten die aanvallers daadwerkelijk hebben gebruikt of gewijzigd. In een groot incident waarbij een aanvaller beheerdersbevoegdheden heeft, is het bijvoorbeeld praktisch onmogelijk om alle mogelijk aangetaste resources te onderzoeken (waaronder mogelijk alle organisatieresources).

• Informatie delen

  Controleer of alle onderzoeksteams, inclusief alle interne teams en externe onderzoekers of verzekeringsmaatschappijen, hun gegevens met elkaar delen op basis van het advies van uw juridische afdeling.

• Toegang tot de juiste expertise

  Controleer of u personen met diepgaande kennis van de systemen in het onderzoek integreert, zoals interne medewerkers of externe entiteiten zoals leveranciers, niet alleen beveiligingsgeneers.

• Anticipeer op verminderde reactiemogelijkheden

  Plan voor 50% van uw personeel dat op 50% van de normale capaciteit werkt vanwege situationele stress.

Een belangrijke verwachting die moet worden beheerd met belanghebbenden, is dat u de eerste aanval mogelijk nooit kunt identificeren, omdat de gegevens die hiervoor nodig zijn, mogelijk zijn verwijderd voordat het onderzoek wordt gestart, zoals een aanvaller die zijn sporen afdekt door logboeken te rollen.

Aanbevolen procedures voor reactie op bewerkingen

Voor secops-aspecten (security operations) van incidentrespons zijn hier enkele doelen die u moet overwegen:

• Gefocust blijven

  Controleer of u de focus houdt op bedrijfskritieke gegevens, de impact van de klant en het voorbereiden op herstel.

• Coördinatie en rolhelderheid bieden

  Stel afzonderlijke rollen in voor operaties ter ondersteuning van het crisisteam en controleer of technische, juridische en communicatieteams elkaar op de hoogte houden.

• Uw bedrijfsperspectief behouden

  U moet altijd rekening houden met de impact op bedrijfsactiviteiten door zowel kwaadwillende acties als uw eigen reactieacties.

Hier volgen enkele handige tips:

• Overweeg het Incident Command System (ICS) voor crisisbeheer

  Als u geen permanente organisatie hebt die beveiligingsincidenten beheert, raden we u aan de ICS te gebruiken als een tijdelijke organisatiestructuur om de crisis te beheren.

• Doorlopende dagelijkse bewerkingen intact houden

  Zorg ervoor dat normale SecOps niet volledig buiten de regels worden geplaatst om incidentonderzoeken te ondersteunen. Dit werk moet nog worden uitgevoerd.

• Vermijd verspillende uitgaven

  Veel grote incidenten leiden tot de aankoop van dure beveiligingshulpprogramma's onder druk die nooit worden geïmplementeerd of gebruikt. Als u tijdens het onderzoek een hulpprogramma niet kunt implementeren en gebruiken, zoals het inhuren en trainen van extra personeel met de vaardigheden die nodig zijn om het hulpprogramma te gebruiken, stelt u de aanschaf uit tot nadat u het onderzoek hebt voltooid.

• Toegang tot diepgaande expertise

  Controleer of u de mogelijkheid hebt om vragen en problemen te escaleren naar diepgaande experts op kritieke platforms. Hiervoor is mogelijk toegang vereist tot het besturingssysteem en de leverancier van de toepassing voor bedrijfskritieke systemen en bedrijfsbrede onderdelen, zoals desktops en servers.

• Informatiestromen instellen

  Stel duidelijke richtlijnen en verwachtingen vast voor de informatiestroom tussen senior leiders van incidentrespons en belanghebbenden van de organisatie. Zie Planning van reactie op incidenten voor meer informatie.

Aanbevolen procedures voor herstel

Het herstellen van incidenten kan effectief worden uitgevoerd vanuit zowel technisch als operationeel perspectief met deze aanbevelingen.

Aanbevolen procedures voor technisch herstel

Voor de technische aspecten van het herstellen van een incident zijn hier enkele doelen die u moet overwegen:

• De oceaan niet koken

  Beperk het antwoordbereik zodat de herstelbewerking binnen 24 uur of minder kan worden uitgevoerd. Plan een weekend om rekening te houden met onvoorziene gebeurtenissen en corrigerende maatregelen.

• Afleiding voorkomen

  Langetermijninvesteringen in beveiliging, zoals het implementeren van grote en complexe nieuwe beveiligingssystemen of het vervangen van antimalwareoplossingen, uitstellen tot na de herstelbewerking. Alles wat geen directe en onmiddellijke invloed heeft op de huidige herstelbewerking is een afleiding.

Hier volgen enkele nuttige tips:

• Nooit alle wachtwoorden tegelijk opnieuw instellen

  Wachtwoordherstel moet zich eerst richten op bekende gecompromitteerde accounts op basis van uw onderzoek en zijn mogelijk beheerders- of serviceaccounts. Als dit gerechtvaardigd is, mogen gebruikerswachtwoorden alleen op een gefaseerde en gecontroleerde manier opnieuw worden ingesteld.

• Uitvoering van hersteltaken consolideren

  Tenzij u te maken krijgt met een dreigend risico op verlies van bedrijfskritieke gegevens, moet u een geconsolideerde bewerking plannen om snel alle gecompromitteerde resources (zoals hosts en accounts) te herstellen in plaats van gecompromitteerde resources te herstellen wanneer u deze vindt. Het comprimeren van dit tijdvenster maakt het moeilijk voor aanvalsoperators om zich aan te passen en persistentie te behouden.

• Bestaande hulpprogramma's gebruiken

  Onderzoek en gebruik de mogelijkheden van hulpprogramma's die u al hebt geïmplementeerd voordat u een nieuw hulpprogramma probeert te implementeren en leer een nieuw hulpprogramma tijdens een herstelbewerking.

• Voorkom dat je kwaadwillende persoon wordt afgeknijpen

  Praktisch gezien moet u stappen ondernemen om de informatie die beschikbaar is voor kwaadwillende gebruikers over de herstelbewerking te beperken. Aanvallers hebben doorgaans toegang tot alle productiegegevens en e-mail in een groot cyberbeveiligingsincident. Maar in werkelijkheid hebben de meeste aanvallers geen tijd om al uw communicatie te controleren.

  Het Security Operations Center (SOC) van Microsoft heeft een niet-productie-Microsoft 365-tenant gebruikt voor veilige communicatie en samenwerking voor leden van het incidentresponsteam.

Aanbevolen procedures voor herstel van bewerkingen

Voor de operationele aspecten van het herstellen van een incident zijn hier enkele doelen die u moet overwegen:

• Een duidelijk plan en een beperkt bereik hebben

  Werk nauw samen met uw technische teams om een duidelijk plan op te stellen met een beperkt bereik. Hoewel plannen kunnen veranderen op basis van kwaadwillende activiteiten of nieuwe informatie, moet u zorgvuldig werken om de uitbreiding van het bereik te beperken en extra taken aan te nemen.

• Het eigendom van een duidelijk plan hebben

  Bij herstelbewerkingen zijn veel mensen betrokken die veel verschillende taken tegelijk uitvoeren, dus wijs een projectleider aan voor de operatie voor duidelijke besluitvorming en definitieve informatie om door het crisisteam te stromen.

• Communicatie met belanghebbenden onderhouden

  Werk met communicatieteams om tijdig updates en actief verwachtingsbeheer te bieden aan belanghebbenden van de organisatie.

Hier volgen enkele nuttige tips:

• Uw mogelijkheden en limieten kennen

  Het beheren van grote beveiligingsincidenten is zeer uitdagend, zeer complex en nieuw voor veel professionals in de branche. U moet overwegen om expertise van externe organisaties of professionele services in te brengen als uw teams overweldigd zijn of niet zeker weten wat u moet doen.

• De geleerde lessen vastleggen

  Bouw en verbeter rolspecifieke handboeken voor SecOps voortdurend, zelfs als het uw eerste incident is zonder schriftelijke procedures.

Communicatie op management- en bestuursniveau voor incidentrespons kan lastig zijn als deze niet wordt geoefend of verwacht. Zorg ervoor dat u een communicatieplan hebt om voortgangsrapportage en verwachtingen voor herstel te beheren.

Incidentresponsproces voor SecOps

Bekijk deze algemene richtlijnen over het incidentresponsproces voor uw SecOps en personeel.

1. Beslissen en handelen

Nadat een hulpprogramma voor bedreigingsdetectie, zoals Microsoft Sentinel of Microsoft 365 Defender een waarschijnlijke aanval heeft gedetecteerd, wordt er een incident gemaakt. De MTTA-meting (Mean Time to Acknowledge) van soc-reactiesnelheid begint met het moment dat deze aanval wordt opgemerkt door uw beveiligingspersoneel.

Een analist in dienst is gedelegeerd of neemt eigenaar van het incident en voert een eerste analyse uit. De tijdstempel hiervoor is het einde van de MTTA-responsiviteitsmeting en begint met de MTTR-meting (Mean Time to Remedite).

Als de analist die eigenaar is van het incident een hoog genoeg niveau van vertrouwen ontwikkelt om het verhaal en de omvang van de aanval te begrijpen, kunnen ze snel overstappen op het plannen en uitvoeren van opschoonacties.

Afhankelijk van de aard en het bereik van de aanval kunnen uw analisten aanvalsartefacten opschonen (zoals e-mailberichten, eindpunten en identiteiten) of ze kunnen een lijst met gecompromitteerde resources samenstellen om allemaal tegelijk op te schonen (bekend als een big bang)

• Opschonen naar gebruik

  Voor de meeste typische incidenten die vroeg in de aanvalsbewerking worden gedetecteerd, kunnen analisten de artefacten snel opschonen wanneer ze deze vinden. Dit plaatst de kwaadwillende persoon in het nadeel en voorkomt dat ze verdergaan met de volgende fase van hun aanval.

• Voorbereiden op een big bang

  Deze benadering is geschikt voor een scenario waarin een kwaadwillende persoon zich al heeft gevestigd en redundante toegangsmechanismen tot uw omgeving heeft ingesteld. Dit wordt vaak gezien in klantincidenten die worden onderzocht door het Detectie- en antwoordteam (DART) van Microsoft. Bij deze benadering moeten analisten voorkomen dat ze de kwaadwillende persoon omverwijzen totdat de aanwezigheid van de aanvaller volledig wordt gedetecteerd, omdat verrassingen kunnen helpen bij het volledig verstoren van hun werking.

  Microsoft heeft geleerd dat gedeeltelijke herstel vaak een kwaadwillende persoon uit de weg haalt, waardoor deze de kans krijgt om te reageren en het incident snel erger te maken. De aanvaller kan de aanval bijvoorbeeld verder verspreiden, zijn toegangsmethoden wijzigen om detectie te omzeilen, zijn sporen bedekken en gegevens en systeemschade en vernietiging voor wraak toebrengen.

  Het opschonen van phishing en schadelijke e-mails kan vaak worden uitgevoerd zonder de aanvaller om te zetten, maar het opschonen van hostmalware en het vrijmaken van de controle over accounts heeft een grote kans op detectie.

Dit zijn geen eenvoudige beslissingen om te nemen en er is geen vervanging voor ervaring met het maken van deze beoordelingsgesprekken. Een samenwerkingsomgeving en -cultuur in uw SOC zorgt ervoor dat analisten kunnen gebruikmaken van elkaars ervaring.

De specifieke reactiestappen zijn afhankelijk van de aard van de aanval, maar de meest voorkomende procedures die door analisten worden gebruikt, zijn:

• Clienteindpunten (apparaten)

  Isoleer het eindpunt en neem contact op met de gebruiker of IT-bewerkingen/helpdesk om een herinstallatieprocedure te starten.

• Server of toepassingen

  Werk met IT-bewerkingen en toepassingseigenaren om snel herstel van deze resources te regelen.

• Gebruikersaccounts

  Beheer vrijmaken door het account uit te schakelen en het wachtwoord voor gecompromitteerde accounts opnieuw in te schakelen. Deze procedures kunnen zich ontwikkelen naarmate uw gebruikers overstappen op verificatie zonder wachtwoord met behulp van Windows Hello of een andere vorm van meervoudige verificatie (MFA). Een afzonderlijke stap is het verlopen van alle verificatietokens voor het account met Microsoft Defender for Cloud Apps.

  Uw analisten kunnen ook het telefoonnummer en de apparaatinschrijving van de MFA-methode controleren om ervoor te zorgen dat het niet is gekaapt door contact op te nemen met de gebruiker en deze gegevens zo nodig opnieuw in te stellen.

• Serviceaccounts

  Vanwege het hoge risico van service- of bedrijfsimpact, moeten uw analisten samenwerken met de recordeigenaar van het serviceaccount, waarbij ze zo nodig terugvallen op IT-bewerkingen, om snel herstel van deze resources te regelen.

• E-mails

  Verwijder de aanvals- of phishing-e-mail en wis deze soms om te voorkomen dat gebruikers verwijderde e-mailberichten herstellen. Sla altijd een kopie van de oorspronkelijke e-mail op om later te zoeken naar analyse na een aanval, zoals kopteksten, inhoud en scripts of bijlagen.

• Anders

  U kunt aangepaste acties uitvoeren op basis van de aard van de aanval, zoals het intrekken van toepassingstokens en het opnieuw configureren van servers en services.

2. Opschonen na incidenten

Omdat u geen voordeel hebt van geleerde lessen totdat u toekomstige acties wijzigt, moet u altijd alle nuttige informatie die u tijdens het onderzoek hebt geleerd, integreren in uw SecOps.

Bepaal de verbindingen tussen eerdere en toekomstige incidenten door dezelfde bedreigingsactoren of -methoden en leg deze leerstof vast om herhaling van handmatig werk en analyse in de toekomst te voorkomen.

Deze lessen kunnen een aantal vormen aannemen, maar veelvoorkomende procedures omvatten analyse van:

• Indicatoren van inbreuk (IOC's).

  Noteer alle toepasselijke IOC's, zoals bestands-hashes, schadelijke IP-adressen en e-mailkenmerken in uw SOC-systemen voor bedreigingsinformatie.

• Onbekende of niet-gepatchte beveiligingsproblemen.

  Uw analisten kunnen processen initiëren om ervoor te zorgen dat ontbrekende beveiligingspatches worden toegepast, onjuiste configuraties worden gecorrigeerd en leveranciers (waaronder Microsoft) op de hoogte worden gesteld van 'zero day'-beveiligingsproblemen, zodat ze beveiligingspatches kunnen maken en distribueren.

• Interne acties, zoals het inschakelen van logboekregistratie voor assets die betrekking hebben op uw cloud- en on-premises resources.

  Controleer uw bestaande beveiligingsbasislijnen en overweeg beveiligingsmaatregelen toe te voegen of te wijzigen. Zie bijvoorbeeld de Handleiding voor beveiligingsbewerkingen van Azure Active Directory voor informatie over het inschakelen van het juiste controleniveau in de directory voordat het volgende incident plaatsvindt.

Controleer uw reactieprocessen om eventuele hiaten die tijdens het incident zijn gevonden, te identificeren en op te lossen.

Resources voor incidentrespons

• Overzicht van Microsoft-beveiligingsproducten en -resources voor nieuwe rollen en ervaren analisten
• Plannen voor uw SOC
• Playbooks voor gedetailleerde richtlijnen voor het reageren op veelvoorkomende aanvalsmethoden
• reactie op Microsoft 365 Defender-incidenten
• Microsoft Defender for Cloud (Azure)
• Reactie op Microsoft Sentinel-incidenten

Belangrijke Microsoft-beveiligingsresources

Resource	Beschrijving
Microsoft Digital Defense Report 2021	Een rapport dat kennis bevat van beveiligingsexperts, beoefenaars en verdedigers bij Microsoft om mensen overal in staat te stellen zich te verdedigen tegen cyberdreigingen.
Referentiearchitecturen voor Microsoft Cybersecurity	Een set visuele architectuurdiagrammen die de cyberbeveiligingsmogelijkheden van Microsoft en hun integratie met Microsoft-cloudplatforms zoals Microsoft 365 en Microsoft Azure en cloud-apps van derden laten zien.
Minuten zijn belangrijk om infographic te downloaden	Een overzicht van hoe het SecOps-team van Microsoft reageert op incidenten om lopende aanvallen te beperken.
Azure Cloud Adoption Framework-beveiligingsbewerkingen	Strategische richtlijnen voor leiders die een beveiligingsfunctie tot stand brengen of moderniseren.
Best practices voor beveiliging van Microsoft voor beveiligingsbewerkingen	Hoe u uw SecOps-centrum het beste kunt gebruiken om sneller te navigeren dan de aanvallers die op uw organisatie zijn gericht.
Microsoft-cloudbeveiliging voor IT-architectenmodel	Beveiliging in Microsoft-cloudservices en -platforms voor identiteits- en apparaattoegang, bedreigingsbeveiliging en gegevensbeveiliging.
Documentatie over Microsoft-beveiliging	Aanvullende beveiligingsrichtlijnen van Microsoft.