Security incident respons

De voorbereiding van je Security Incident Respons

Sarah Dols

Over de gehele wereld is Amazon Web Services (AWS) de grootste cloud aanbieder. Het marktaandeel van het bekende cloud platform wordt op een prominente 32% geschat, tegenover 18% marktaandeel van Microsoft Azure. Maar dat deze platforms geliefd zijn, wil natuurlijk niet zeggen dat het ook 1000% waterdicht is. Ook hier kan het wel eens voorkomen dat er een incident met betrekking tot de beveiliging (Security Incident) voorkomt. Een goede en snelle reactie is hierbij van cruciaal belang. Om tot een juiste en snelle reactie te komen, is voorbereiding de belangrijkste taak. Maar hoe bereid je jezelf dan voor op zo’n beveiligingsincident?

Verantwoordelijkheid

Een groot voordeel van het gebruik van de cloud is dat een deel van de verantwoordelijkheden wordt overgenomen door de cloud aanbieder. Nou ben je als gebruiker niet alle verantwoordelijkheden kwijt. Ook voor jou als gebruiker blijven er nog werkzaamheden over. Wanneer je gebruik maakt van de diensten van een cloud aanbieder, deel je dus als het ware de verantwoordelijkheden. Zo deel je ook de verantwoordelijkheden op het gebied van veiligheid.

Om de verdeling van verantwoordelijkheden op het gebied van veiligheid overzichtelijk te maken, heeft Amazon een handige tabel gemaakt:

De 3 domeinen

Als consument ben je dus zelf verantwoordelijk voor een groot deel van de beveiliging. Dit lijkt misschien niet zo veel, maar vergis je niet! Want binnen jouw verantwoordelijkheden kunnen incidenten binnen verschillende domeinen voorkomen:

  • Domein van service

Wanneer er een incident voorkomt binnen het servicedomein, heeft dit waarschijnlijk te maken met de middelen- of configuratietoestemmingen. Vaak worden deze incidenten verholpen door exclusief gebruik te maken van bepaalde API’s.

  • Domein van infrastructuur

Wanneer er een incident plaatsvindt binnen het infrastructuurdomein, is dit waarschijnlijk gerelateerd aan het netwerk. Dit kan bijvoorbeeld te maken hebben met het verkeer binnen een VPC. De kans is groot dat de reactie op zo’n incident vraagt om interactie met het besturingssysteem van een instantie.

  • Domein van applicaties

De incidenten die plaatsvinden binnen het domein van de applicaties bevinden zich in de applicatiecode of de onderliggende software. De aanpak van deze incidenten kunnen vergelijkbaar zijn met die van incidenten binnen het infrastructuurdomein.

Het vinden van een incident

Hoe weet je dan wanneer er sprake is van een (schadelijk) incident? En wanneer is het noodzakelijk om te zoeken naar deze incidenten? Die ene kleine verandering is voor jou misschien geen rede tot paniek, maar kan in werkelijkheid wel een incident zijn. Wil jij je omgeving inspecteren op incidenten? Dan kan je het beste zoeken naar:

  • Activiteiten van kosten

Kom je ineens een hele hoge kostenpost tegen en heb je geen idee waar die verandering vandaan komt? Grote kans dat er een incident heeft voorgedaan. Zodra je een opmerkelijke stijging (of daling) in de kosten ziet, is het dus belangrijk om te inspecteren naar bedreigingen en incidenten in je cloud omgeving.

  • Partners van de aanbieder

Wanneer je gebruik maakt van een Cloudplatform, krijg je er een hele nieuwe vriendengroep bij. Zo heeft AWS in de afgelopen jaren aardig wat partners bij elkaar verzameld. En voor jou is dat heel fijn! Want vrienden helpen elkaar. Zo kunnen verschillende partners jou helpen met het monitoren en meten van jouw digitale omgeving.

  • Bedreigingen bijhouden

Wil je toch een andere vriendengroep dan de partners? Dan kan je er ook altijd voor kiezen om gebruik te maken van bedreigingsinformatie van derden. Hierdoor wordt het ook mogelijk om gebruik te maken van hun monitortools voor het identificeren van potentiële incidenten.

  • Loggen en monitoren

Je kan natuurlijk ook gewoon de aanbieder als je beste vriend inzetten en verder niemand nodig hebben. Want ook  zelf bieden zij verschillende producten voor het monitoren en loggen van (potentiële) incidenten. Enkele voorbeelden hiervan zijn CloudTrail en Route 53.

  • Aanbieder zelf neemt contact op

Het kan ook zo zijn dat de support afdeling van de aanbieder contact met jou opneemt. Wanneer deze contact met jou opneemt, is de kans groot dat er foutieve en/of schadelijke activiteiten plaatsvinden binnen jouw cloud omgeving. Hierbij geldt wel dat je goed moet opletten of je wel echt de aanbieder aan de lijn hebt. Hackers vinden het namelijk nog wel eens leuk zich voor te doen als AWS/Azure om zo toch bij je binnen te komen.

  • Contact met het team

Het incident wordt niet altijd geïdentificeerd door jou zelf, soms gebeurt dit door een klant, ontwikkelaar of medewerker. Voor die klant, ontwikkelaar of medewerker is het dan belangrijk dat zij weten waar zij terecht kunnen om een melding te maken. Daarom is het van belang dat voor de gehele organisatie, en stakeholders, duidelijk is hoe zij contact op moeten nemen met de juiste contactpersoon.

Voorbereiden van gebruikers

Kennis is key, vooral als het gaat om het beveiligen van een cloud omgeving. Maar deze kennis staat nooit stil. Hoe graag we het ook zouden willen, is het toch haast onmogelijk om alle mogelijke incidenten te voorspellen. Daarom is het belangrijk om de gehele organisatie te voorzien van de juiste kennis.

Het belangrijkste hierbij zijn de rollen die voorkomen wanneer er een incident plaatsvindt. Elke rol binnen een incident kent ook eigen verantwoordelijkheden. Voor alle stakeholders is het belangrijk dat zij weten welke verantwoordelijkheden bij welke rol horen. Stel dus een duidelijk proces op waarin dit wordt vermeld.

Daarnaast is het belangrijk om iedereen binnen de organisatie te voorzien van juiste trainingen en cursussen. Hierdoor blijft de technische kennis binnen de organisatie ook op peil en kan er snel en juist worden gehandeld wanneer er een incident plaatsvindt.

Voorbereiden van technologie

Een cloud omgeving is net als een huis. Je hebt verschillende stenen die bij elkaar worden gehouden door het cement. Deze bouwstenen hebben elk een eigen niveau. Elk niveau bestaat uit zijn eigen informatie en autoriteiten.

Niet iedereen heeft toegang tot dezelfde niveaus. Zo heeft alleen de administrator toegang tot allemaal, maar zal niet elke medewerker overal toegang tot hebben. Wanneer er een incident plaatsvindt, is het dus belangrijk dat degene die het incident gaat oplossen toegang heeft tot de juiste niveaus en informatie.

Voordat deze toegang toegewezen kan worden, moet er dus een inventarisatie worden gemaakt van alle aanwezige niveaus en accounts. Vervolgens moet worden beschreven welke accounts toegang hebben tot welk niveau. Het koppelen van de niveaus en accounts dient goed te worden gedocumenteerd en getest voor deze wordt gedeeld.

Zodra dit allemaal is getest, kunnen de processen alvast worden opgesteld. Dit is een intensief proces waarbij je gaat omschrijven welke stappen ondernomen moeten worden tijdens een incident.

Simulatie

Na het opstellen van de verschillende processen beschik je als het ware over een plan van aanpak voor tijdens incidenten. Maar hoe weet je dat de opgestelde processen ook daadwerkelijk werken wanneer een incident plaatsvindt? Daar kom je pas achter door de processen te testen. Voor het testen van de opgestelde processen is in principe een incident nodig, maar het is natuurlijk niet de bedoeling om een groep hackers los te laten op je netwerk.

Voor het testen van de opgestelde processen gebruik je zogenoemde SIRS, Security Incident Respons Simulations. SIRS zijn ‘neppe’ interne incidenten die ervoor zorgen dat de processen op een gestructureerde en gecontroleerde manier getest kunnen worden. Door middel van de simulatie kan je dus op een gecontroleerde manier een realistisch incident doorlopen. Handig he?

Iteratie

Nadat de opgestelde processen zijn getest door middel van deze simulaties, is duidelijk wat de sterke en zwakke punten van de processen zijn. Hierdoor weet je wat er moet veranderen aan de processen. Dankzij deze resultaten worden de processen dus steeds verbeterd. Dit maakt het opstellen van de processen een iteratief proces waarbij verbeteringen door middel van testen kunnen worden doorgevoerd.

Het is even doorzetten, maar door het uitvoeren van deze stappen zorg jij voor een beter beveiligde cloud omgeving. Wel zo fijn voor je partners, klanten en natuurlijk voor jezelf!

Kan jouw organisatie wel wat hulp gebruiken bij het opstellen van de processen voor security incidenten? Neem hier contact met ons op voor de mogelijkheden.

Voor meer informatie over Security Incident Respons binnen AWS verwijzen wij graag naar deze paper van AWS.

 

« Terug naar overzicht

Meer informatie?
Wij bellen je graag terug.