Overzicht van reactie op incidenten

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

De reactie op incidenten heeft de grootste directe invloed op de totale gemiddelde tijd die moet worden bevestigd (MTTA) en de gemiddelde tijd om (MTTR) te herstellen die meten hoe goed beveiligingsbewerkingen in staat zijn om het risico van de organisatie te verminderen. Teams voor incidentrespons zijn sterk afhankelijk van goede werkrelaties tussen teams voor het opsporen van bedreigingen, intelligentie en incidentbeheer (indien aanwezig) om het risico daadwerkelijk te verminderen. Zie SecOps-metrische gegevens voor meer informatie.

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

Proces voor reactie 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:

• Adresaanvallen die variëren met het bedrijfsrisico en de impact van het incident, die kunnen variëren van een geïsoleerde website die niet langer beschikbaar is voor inbreuk op referenties op beheerdersniveau.
• Definieer het doel van het antwoord, 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 moet overwegen in uw plan voor reactie op incidenten. Zodra uw plan voor incidentrespons is ingesteld, test u het regelmatig voor de ernstigste soorten 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 de organisatiestructuur en mogelijkheden en historische ervaring, kunt u rekening houden met de set aanbevelingen en aanbevolen procedures in dit artikel voor het reageren op beveiligingsincidenten.

Tijdens een incident is het van cruciaal belang om:

• Blijf kalm

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

• Doe geen kwaad

  Controleer of uw antwoord is ontworpen en uitgevoerd op een manier die verlies van gegevens, verlies van bedrijfskritieke functionaliteit en bewijsverlies voorkomt. Vermijd beslissingen die uw vermogen kunnen beschadigen om forensische tijdlijnen te maken, hoofdoorzaak te identificeren en kritieke lessen te leren.

• Uw juridische afdeling betrekken

  Bepaal of ze rechtshandhaving willen betrekken, zodat u uw onderzoeks- en herstelprocedures op de juiste wijze kunt plannen.

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

  Bevestig dat alles wat u met uw klanten deelt en het publiek is gebaseerd op het advies van uw juridische afdeling.

• Hulp krijgen wanneer dat nodig is

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

Net als bij het diagnosticeren en behandelen van een medische ziekte, vereist onderzoek en reactie van cyberbeveiliging voor een groot incident het verdedigen van een systeem 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 deze kritieke balansen aanhalen:

• Snelheid

  Balans tussen de noodzaak om snel te handelen om belanghebbenden te bevredigen met het risico van gehaaste beslissingen.

• Informatie delen

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

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 risico's te verminderen en te voldoen aan de behoeften van belanghebbenden.

Notitie

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

Best practices voor antwoorden

Het reageren op incidenten kan effectief worden uitgevoerd vanuit zowel technische als operationele perspectieven met deze aanbevelingen.

Notitie

Zie de handleiding voor de verwerking van NIST-computerbeveiligingsincidenten voor gedetailleerdere richtlijnen voor 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 komen vaak terug voor hun doel (gegevens/systemen) in een toekomstige aanval.

Hier volgen enkele handige tips:

• Bestanden niet uploaden naar onlinescanners

  Veel kwaadwillende personen controleren exemplaren op services zoals VirusTotal voor detectie van gerichte malware.

• Houd zorgvuldig rekening met wijzigingen

  Tenzij u een dreigende bedreiging ondervindt van het verliezen van bedrijfskritieke gegevens, zoals verwijdering, versleuteling en exfiltratie, moet u het risico van het niet aanbrengen van de wijziging met de verwachte zakelijke impact in balans krijgen. Het is bijvoorbeeld mogelijk dat het tijdelijk afsluiten van de internettoegang van uw organisatie nodig is om bedrijfskritieke assets te beveiligen tijdens een actieve aanval.

  Als er wijzigingen nodig zijn wanneer het risico dat een actie niet wordt uitgevoerd, hoger is dan het risico dat deze actie wordt uitgevoerd, documenteert u de actie in een wijzigingslogboek. Wijzigingen die zijn aangebracht tijdens het reageren op incidenten zijn gericht op het verstoren van de aanvaller en kunnen van invloed zijn op het bedrijf. U moet deze wijzigingen terugdraaien na het herstelproces.

• Onderzoek niet voor altijd

  U moet uw onderzoeksinspanningen meedogenloos prioriteren. Voer bijvoorbeeld alleen forensische analyse uit op eindpunten die aanvallers 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 organisatiebronnen).

• Informatie delen

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

• Toegang tot de juiste expertise

  Bevestig dat u personen integreert met diepgaande kennis van de systemen in het onderzoek, zoals intern personeel of externe entiteiten zoals leveranciers, niet alleen beveiligingsgenegenegeners.

• Anticipeer een verminderde responsmogelijkheid

  Plan 50% van uw personeel op 50% van de normale capaciteit vanwege situatiestress.

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

Best practices voor reactie op bewerkingen

Voor beveiligingsbewerkingen (SecOps) aspecten van incidentrespons zijn hier enkele doelen die u moet overwegen:

• Gefocust blijven

  Bevestig dat 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 vast voor operationele activiteiten ter ondersteuning van het crisisteam en bevestig dat technische, juridische en communicatieteams elkaar op de hoogte houden.

• Het perspectief van uw bedrijf behouden

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

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 zijn ge sidelined om incidentonderzoeken te ondersteunen. Dit werk moet nog worden uitgevoerd.

• Vermijd verspilling van uitgaven

  Veel belangrijke incidenten resulteren in de aankoop van dure beveiligingshulpprogramma's onder druk die nooit worden geïmplementeerd of gebruikt. Als u tijdens het onderzoek geen hulpprogramma kunt implementeren en gebruiken, waaronder het inhuren en trainen van meer medewerkers met de vaardighedensets die nodig zijn om het hulpprogramma te bedienen, stelt u de aanschaf uit totdat u klaar bent met het onderzoek.

• Toegang tot diepgaande expertise

  Bevestig dat u vragen en problemen kunt escaleren naar diepgaande experts op kritieke platforms. Deze mogelijkheid vereist mogelijk toegang tot het besturingssysteem en de leverancier van toepassingen voor bedrijfskritieke systemen en bedrijfsbrede onderdelen, zoals desktops en servers.

• Informatiestromen tot stand brengen

  Stel duidelijke richtlijnen en verwachtingen in voor de informatiestroom tussen senior leidinggevenden voor incidenten en belanghebbenden van de organisatie. Zie planning voor reactie op incidenten voor meer informatie.

Best practices voor herstel

Herstel van incidenten kan effectief worden uitgevoerd vanuit zowel technische als operationele perspectieven 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:

• Kook de oceaan niet

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

• Vermijd afleidingen

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

Hier volgen enkele handige tips:

• Nooit alle wachtwoorden in één keer opnieuw instellen

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

• Uitvoering van hersteltaken consolideren

  Tenzij u een dreigende bedreiging ondervindt van het verlies van bedrijfskritieke gegevens, moet u een geconsolideerde bewerking plannen om snel alle gecompromitteerde resources (zoals hosts en accounts) te herstellen en gecompromitteerde resources te herstellen wanneer u ze vindt. Het comprimeren van dit tijdvenster maakt het moeilijk voor aanvalsoperators om persistentie aan te passen en te behouden.

• Bestaande hulpprogramma's gebruiken

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

• Vermijd het afzetten van uw kwaadwillende persoon

  Als praktisch moet u stappen ondernemen om de informatie te beperken die beschikbaar is voor kwaadwillende gebruikers over de herstelbewerking. 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.

  Soc (Security Operations Center) van Microsoft maakt gebruik van een niet-productie Microsoft 365-tenant voor veilige communicatie en samenwerking voor leden van het incidentresponsteam.

Best practices 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 te maken met een beperkt bereik. Hoewel plannen kunnen veranderen op basis van adversary-activiteit of nieuwe informatie, moet u zorgvuldig werken om bereikuitbreiding te beperken en meer taken uit te voeren.

• Het eigendom van een duidelijk plan hebben

  Herstelbewerkingen omvatten veel mensen die veel verschillende taken tegelijk uitvoeren, dus wijs een projectleider aan voor de operatie voor duidelijke besluitvorming en definitieve informatie om tussen het crisisteam te stromen.

• Communicatie tussen belanghebbenden onderhouden

  Werk samen met communicatieteams om tijdige updates en actief verwachtingsbeheer te bieden voor belanghebbenden van de organisatie.

Hier volgen enkele handige tips:

• Uw mogelijkheden en limieten kennen

  Het beheren van belangrijke beveiligingsincidenten is zeer lastig, zeer complex en nieuw voor veel professionals in de branche. Overweeg om expertise van externe organisaties of professionele services in te brengen als uw teams overweldigd zijn of niet zeker zijn over wat u vervolgens moet doen.

• De geleerde lessen vastleggen

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

Communicatie op directie- en bestuursniveau voor incidentrespons kan lastig zijn als dit niet wordt geoefend of verwacht. Zorg ervoor dat u een communicatieplan hebt voor het beheren van voortgangsrapportage en verwachtingen voor herstel.

Proces voor reactie op incidenten voor SecOps

Houd rekening met deze algemene richtlijnen over het reactieproces voor incidenten voor uw SecOps en personeel.

1. Beslissen en handelen

Nadat een hulpprogramma voor bedreigingsdetectie, zoals Microsoft Sentinel of Microsoft Defender XDR, een waarschijnlijke aanval detecteert, wordt er een incident gemaakt. De gemiddelde tijd om te bevestigen (MTTA) meting van SOC-reactiesnelheid begint met de tijd dat uw beveiligingspersoneel de aanval opmerkt.

Een analist in dienst wordt 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 de gemiddelde tijd om (MTTR)-meting te herstellen.

Aangezien de analist die eigenaar is van het incident een hoog genoeg vertrouwensniveau ontwikkelt dat ze het verhaal en de omvang van de aanval begrijpen, kunnen ze snel overschakelen naar 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 kunnen ze een lijst maken met gecompromitteerde resources om alles tegelijk op te schonen (ook wel big bang genoemd)

• Opschonen terwijl je gaat

  Voor de meeste typische incidenten die vroeg in de aanvalsbewerking worden gedetecteerd, kunnen analisten de artefacten snel opschonen wanneer ze ze vinden. Deze praktijk stelt de aanvaller in een 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 al redundante toegangsmechanismen voor uw omgeving heeft ingesteld en heeft ingesteld. Deze praktijk wordt vaak gezien in klantincidenten die worden onderzocht door het Microsofts Incident Response Team. In deze benadering moeten analisten voorkomen dat ze de kwaadwillende persoon afleveren totdat ze de aanwezigheid van de aanvaller volledig ontdekken, omdat verrassing kan helpen bij het volledig verstoren van hun werking.

  Microsoft heeft geleerd dat gedeeltelijke herstel vaak tips geeft aan een kwaadwillende persoon, waardoor ze een kans krijgen om te reageren en het incident snel erger te maken. De aanvaller kan de aanval bijvoorbeeld verder verspreiden, hun toegangsmethoden wijzigen om detectie te omzeilen, hun sporen te bedekken en gegevens en systeemschade en vernietiging toe te brengen voor wraak.

  Het opschonen van phishing en schadelijke e-mailberichten kan vaak worden gedaan zonder de aanvaller te ontslaan, maar het opschonen van hostmalware en het vrijmaken van controle over accounts heeft een hoge kans op detectie.

Dit zijn niet eenvoudig beslissingen te nemen en er is geen vervanging voor ervaring bij het maken van deze beoordelingsoproepen. Een samenwerkingswerkomgeving en -cultuur in uw SOC zorgt ervoor dat analisten elkaars ervaring kunnen aanboren.

De specifieke reactiestappen zijn afhankelijk van de aard van de aanval, maar de meest voorkomende procedures die door analisten worden gebruikt, kunnen 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 samen met IT-bewerkingen en toepassingseigenaren om snel herstel van deze resources te regelen.

• Gebruikersaccounts

  Besturingselement vrijmaken door het account uit te schakelen en het wachtwoord opnieuw in te schakelen voor gecompromitteerde accounts. 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 voor Cloud Apps.

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

• Serviceaccounts

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

• E-mails

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

• Overige

  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. Na het opschonen van incidenten

Omdat u geen voordeel hebt van geleerde lessen totdat u toekomstige acties wijzigt, integreert u altijd nuttige informatie die uit het onderzoek naar uw SecOps is geleerd.

Bepaal de verbindingen tussen eerdere en toekomstige incidenten door dezelfde bedreigingsactoren of -methoden en leg deze lessen vast om te voorkomen dat handmatig werk en vertragingen in de analyse in de toekomst worden herhaald.

Deze bevindingen kunnen vele vormen aannemen, maar algemene 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 (inclusief Microsoft) worden geïnformeerd over 'zero day'-beveiligingsproblemen, zodat ze beveiligingspatches kunnen maken en distribueren.

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

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

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

Resources voor reactie op incidenten

• Planning voor uw SOC
• Playbooks voor gedetailleerde richtlijnen voor het reageren op veelvoorkomende aanvalsmethoden
• Microsoft Defender XDR-incidentrespons
• Microsoft Defender voor Cloud (Azure)
• Reactie op microsoft Sentinel-incidenten
• Microsoft Incident Response team guide shares best practices for security teams and leaders
• Handleidingen voor het reageren op incidenten van Microsoft helpen beveiligingsteams verdachte activiteiten te analyseren

Belangrijke Microsoft-beveiligingsbronnen

Bron	Beschrijving
Microsoft Digital Defense-rapport 2023	Een rapport dat kennis omvat van beveiligingsexperts, beoefenaars en verdedigers bij Microsoft om mensen overal te helpen zich te beschermen tegen cyberdreigingen.
Naslagarchitecturen voor Microsoft Cybersecurity	Een set visuele architectuurdiagrammen met de mogelijkheden van Microsoft voor cyberbeveiliging en hun integratie met Microsoft-cloudplatforms zoals Microsoft 365 en Microsoft Azure en cloudplatforms en apps van derden.
Minuten belangrijk infographic downloaden	Een overzicht van hoe het SecOps-team van Microsoft incidentrespons doet om lopende aanvallen te beperken.
Azure Cloud Adoption Framework-beveiligingsbewerkingen	Strategische richtlijnen voor leiders die een beveiligingsbewerkingsfunctie tot stand brengen of moderniseren.
Aanbevolen procedures voor Microsoft-beveiliging voor beveiligingsbewerkingen	Hoe u uw SecOps-centrum het beste kunt gebruiken om sneller te gaan dan de aanvallers die gericht zijn op uw organisatie.
Microsoft-cloudbeveiliging voor IT-architectenmodel	Beveiliging in Microsoft-cloudservices en -platforms voor identiteits- en apparaattoegang, bedreigingsbeveiliging en gegevensbeveiliging.
Microsoft-beveiligingsdocumentatie	Aanvullende beveiligingsrichtlijnen van Microsoft.