Maak kennis met de levenscyclus incidentrespons

Wat is een levenscyclus van incidentrespons?

Incidentrespons is het proces van een organisatie om te reageren op IT-bedreigingen zoals cyberaanvallen, inbreuk op de beveiliging en serverdowntime.

De levenscyclus van incidentrespons is het stapsgewijze framework van je organisatie voor het identificeren van en reageren op een uitval of beveiligingsdreiging.

1. Detecteer het incident

Onze incidentdetectie begint meestal met monitoring- en waarschuwingstools. Maar soms vertellen klanten of teamleden ons als eerst over een incident.

Aangezien incidentwaarschuwingen afkomstig van verschillende bronnen afkomstig kunnen zijn, kan het hebben van een oplossing die veel verschillende waarschuwings- en rapportagetools integreert het verschil betekenen tussen een onsamenhangende, omslachtige respons en een samenhangende, samenwerkingsgericht respons. Een oplossing zoals Jira Service Management stelt teams in staat om waarschuwingen aan te passen en te filteren voor alle bewaking-, logging- en CI/CD-tools om ervoor te zorgen dat teams incidenten snel aanpakken en waarschuwingsmoeheid voorkomen.

2. Stel communicatiekanalen voor teams op

Een belangrijke eerste stap is het opzetten van de communicatiekanalen van het incidentteam. Het doel op dit punt is om teamcommunicatie te concentreren op bekende plaatsen, zoals een speciaal Slack-kanaal en een videoconferentiebrug.

Binnen Jira Service Management kan het coördineren van incidentrespons soepel verlopen. Teams kunnen niet alleen communiceren op een manier die voor hen het beste werkt, in Slack of met videovergaderingen, maar ook communiceren met klanten wordt eenvoudiger dankzij automatisering en maatwerk. We behandelen externe communicatie in stap 4.

3. Beoordeel de impact en pas een ernstniveau toe

Nu is het tijd om de impact van het incident te beoordelen, zodat het team kan beslissen met wie er nog meer contact moet worden opgenomen en wat er met klanten en belanghebbenden moet worden gecommuniceerd. Het toekennen van een ernstniveau identificeert niet alleen de impact van het incident, maar legt ook de basis voor oplossingsplannen en externe communicatie. In Jira Service Management worden bij de escalatie van een incident en het toewijzen van ernst geautomatiseerde acties en meldingen aan responders geactiveerd om op de hoogte te blijven van de voortgang van de oplossing.

4. Communiceer met klanten

We streven ernaar om zo snel mogelijk intern en extern te communiceren met belanghebbenden. Snel en nauwkeurig communiceren helpt bij het opbouwen van vertrouwen bij klanten en de rest van de organisatie. Zoals eerder vermeld, krijgt je team de mogelijkheid om te werken hoe zij willen doordat je kunt aanpassen hoe je communiceert. Dit maakt op zijn beurt weer snellere probleemoplossing mogelijk. De mogelijkheid om communicatie aan te passen, stelt je team ook in staat om controle te krijgen over welke boodschap ze willen uitdragen en wanneer. Bovendien kan je team tijd besparen middenin een incident met geautomatiseerde antwoorden vanuit een ticket, die rechtstreeks naar de klant worden gestuurd.

5. Escaleer naar de juiste responders

De aanvankelijke responders moeten vaak andere teams bij het incident betrekken door ze op te roepen met behulp van een waarschuwingsfunctie in Jira Service Management. Breng responders rechtstreeks naar het incidentticket door gerelateerde tickets te groeperen en relevante responders direct op het ticket te taggen. Op deze manier worden meldingen gecoördineerd en heeft iedereen de volledige context.

6. Delegeer rollen voor incidentrespons

Wanneer extra teamleden zich bij responsteam voegen, delegeert de incidentmanager een rol aan hen. Op dit moment is het handig om een goed draaiboek voor incidentrespons te hebben: vooraf ontwikkeld waarin duidelijke rollen en verantwoordelijkheden worden geschetst. Personen in het incidentresponsteam zijn bekend met elke rol en weten waarvoor ze verantwoordelijk zijn tijdens een incident.

7. Los het incident op

Een incident is opgelost als de huidige of dreigende impact op het bedrijf is geëindigd. Op dat moment eindigt de noodrespons en gaat het team verder met secundaire taken en de postmortem.

Idealiter houdt je oplossing voor incidentmanagement een robuuste tijdlijn voor incidenten bij, wat het geval is als je Jira Service Management gebruikt. Responders hebben achteraf toegang tot essentiële incidentgegevens en kunnen een rapport ontwikkelen waarmee teams soortgelijke incidenten in de toekomst kunnen vermijden en de oorzaak kunnen achterhalen. Postmortems kunnen ook als hulpmiddel dienen, voor als er weer iets soortgelijks gebeurt.

De levenscyclus van NIST-incidentrespons

Een andere branchestandaard levenscyclus voor incidentrespons is afkomstig van The National Institute of Standards and Technology, of NIST. NIST is een overheidsinstantie die normen en werkwijzen vaststelt rond onderwerpen als incidentrespons en cyberbeveiliging.

NIST staat voor National Institute of Standards and Technology. Ze zijn een Amerikaanse overheidsinstantie die zichzelf trots "een van de oudste natuurwetenschappelijke laboratoria van het land" noemen. Ze werken met alles wat met technologie te maken heeft, inclusief cyberbeveiliging, waar ze een van de twee branchestandaard go-to's zijn geworden voor incidentrespons met hun responsstappen voor incidenten.

Net als Atlassian gelooft NIST dat niet elk incident kan worden voorkomen. Het is dus het beste om voorbereid te zijn:

"Preventieve activiteiten op basis van de resultaten van risicobeoordelingen kunnen het aantal incidenten verminderen, maar niet alle incidenten kunnen worden voorkomen. Een incidentresponscapaciteit is daarom noodzakelijk om incidenten snel op te sporen, verlies en vernietiging tot een minimum te beperken, de zwakke punten die werden misbruikt te verhelpen en IT-services te herstellen." — NIST

De NIST-levenscyclus voor incidentrespons verdeelt de incidentrespons in vier hoofdfasen: voorbereiden, detectie en analyse, inperken, uitroeien en herstellen, en activiteit na de gebeurtenis.

Fase 1: Voorbereiden

De voorbereidingsfase omvat het werk dat een organisatie doet om zich voor te bereiden op incidentrespons, inclusief het instellen van de juiste tools en middelen en het trainen van het team. Deze fase omvat werkzaamheden om incidenten te voorkomen.

Fase 2: Detectie en analyse

Het nauwkeurig detecteren en beoordelen van incidenten is volgens NIST voor veel organisaties vaak het moeilijkste onderdeel van incidentrespons.

Fase 3: Inperken, uitroeien en herstellen

Deze fase richt zich op het zo klein mogelijk houden van de impact van incident en het beperken van serviceonderbrekingen.

Fase 4: Activiteit na de gebeurtenis

Leren en verbeteren na een incident is een van de belangrijkste onderdelen van incidentrespons en wordt het vaakst genegeerd. In deze fase worden de inspanningen met betrekking tot incidenten en incidentrespons geanalyseerd. De doelen hier zijn om de kans te beperken dat het incident zich opnieuw voordoet en manieren te identificeren om toekomstige incidentresponsactiviteiten te verbeteren.

Incidentrespons voor moderne DevOps-teams

In het afgelopen decennium heeft de DevOps-beweging teams geholpen bij het hervormen van de manier waarop ze software bouwen, implementeren en bedienen. Daarnaast zijn er innovaties over hoe deze teams reageren op incidenten.

De DevOps-aanpak voor het beheren van incidenten verschilt niet heel erg van de traditionele stappen van effectief incidentmanagement. DevOps-incidentbeheer omvat een expliciete nadruk op het betrekken van ontwikkelteams vanaf het begin, waaronder bij op afroepdiensten, en het toewijzen van werk op basis van expertise, niet op functietitels.

Incidentrespons en continue verbetering

In de opening van dit artikelen praatten we over cycli versus rechte lijnen. Je zult iets zien dat al deze benaderingen van incidentmanagement iets gemeen hebben: ze zijn niet lineair. Elke benadering bevat dezelfde basisonderdelen: manieren om incidenten te definiëren, te detecteren en te identificeren, manieren om snel te reageren en actie te ondernemen om incidenten te beperken, en manieren om incidenten te analyseren om toekomstige detectie en respons te verbeteren. Het heeft geen zin om een incident te analyseren dat al is gebeurd alleen omwille van dat incident. Je kunt niet teruggaan in de tijd en veranderen wat er is gebeurd. Je leert van het incident om de toekomstige detectie en reactie te verbeteren. Constant, continu leren en verbeteren is hoe teams die cyclus sluiten.

Er zijn veel bewegende onderdelen in het (niet-lineaire) incidentresponsproces. Elke stap met geïntegreerde samenwerkings- en communicatietools bijhouden, is eenvoudig met een oplossing voor incidentmanagement zoals Jira Service Management. Centraliseer waarschuwingen en breng teams samen met de flexibiliteit om snel op incidenten te reageren en deze op te oplossen.