Beveiligingswaarschuwing als digitale buienradar

“Er bestaat geen slecht weer – alleen slechte kleding” aldus het Scandinavische gezegde. En tegenwoordig kunnen we ons daar steeds beter op voorbereiden met nauwkeurige weersvoorspellingen en buienradars die bijna tot op de minuut aangeven wanneer je de eerste druppels kunt verwachten.

Ironisch genoeg is een online buienradar die waarschuwt voor nieuwe beveiligingsproblemen vaak nog ver te zoeken – wat misschien nog het dichtst in de buurt komt, is het uitwisselen van zogenaamde Threat Intelligence. Hierbij wordt geautomatiseerd of handmatig informatie over geslaagde of verijdelde aanvallen of over kwetsbaarheden gedeeld door bedrijven of overheden met het doel anderen te waarschuwen. Dit komt in allerlei vormen en smaken – van trendrapportages zoals het Data Breach Investigations Report of ons eigen Digital Defense Report tot korte dreigingsbulletins.

Wat moet je nu doen als je verantwoordelijk bent voor IT of beveiliging en een dergelijke waarschuwing belandt op je bureau? Grote bedrijven hebben vaak hun eigen threat intelligence teams die dit soort meldingen systematisch analyseren – maar wat als zo’n eigen dienst niet aanwezig is binnen de organisatie? We zullen in deze blog stapsgewijs door de analyse, actie en afronding gaan om een afweging te maken over wat te doen in het geval van een beveiligingswaarschuwing of daadwerkelijke dreiging.

Analyse

Allereerst is het goed om de bron van de waarschuwing op waarde te schatten – is dit gebaseerd op objectieve dataverzameling en -interpretatie en kun je er echt iets mee, of is dit niet met zekerheid te zeggen?

De vraag die hierbij wellicht het beste helpt, is: “Wat is het doel van de partij die de waarschuwing uitstuurt?” Gaat het bijvoorbeeld om een leverancier die een beveiligingsproduct probeert te verkopen en het probleem bij zijn oplossing heeft gezocht? Komt het van een bevriende relatie in dezelfde industrie die probeert om het hele ecoysteem van bedrijven veiliger te maken? Komt het van een overheidspartij?

Vervolgens is het zaak om te kijken wat de aard van de beschreven informatie is, door onder meer naar de volgende aspecten te kijken:

• Gaat het om een bevestigde aanval of kwetsbaarheid? Of beschrijft iemand een meer theoretisch mechanisme dat alleen in heel specifieke situaties voorkomt?
• Hoe gemakkelijk is de beschreven techniek te repliceren? Een aanval die bijvoorbeeld fysieke toegang vereist, is zeker niet onmogelijk om te realiseren – maar is een stuk lastiger om op grote schaal uit te voeren.
• Is het beschreven probleem relevant voor mij en mijn organisatie? Wordt software gebruikt die wij ook in gebruik hebben, of is sprake van het actief aanvallen van een bepaalde industrie waar ik ook onderdeel van uitmaak?

Op basis van deze eerste analyse, kan een beknopt plan gemaakt worden. Probeer hierbij te formuleren: “Hoe kan ik bewijzen of ontkrachten dat dit relevant is voor mijn organisatie?”

Actie

Het plan uit de Analysefase is hierbij leidend. Veelal zal in deze fase gekeken worden of bepaalde kwetsbare software in gebruik is, of dat bepaalde Indicators of Compromise (IOCs) – digitale sporen die aangeven dat een aanval uitgevoerd is of voorbereid wordt – aanwezig zijn op je systemen of netwerk.

Een vastomlijnd stappenplan is hiervoor niet direct te geven, maar een aantal elementen zullen vaak terugkeren:

• Heeft onze organisatie een zo volledig mogelijk en zo actueel mogelijk inzicht van de systemen, software en clouddiensten? Kunnen wij onze omgeving doorzoeken op Indicators of Compromise – bijvoorbeeld of kwaadaardige software op de systemen voorkomt of dat vanuit het netwerk met een kwaadaardig IP-adres op het internet gecommuniceerd wordt?
• Bevat de binnengekomen melding ook al stappen over hoe het beschreven probleem voorkomen of gedetecteerd kan worden? Zijn deze uitvoerbaar binnen de organisatie?
• Moeten wij op basis van de eerste bevindingen een meer gedetailleerde triage uitvoeren en op basis daarvan eventueel de incident response procedure opstarten?

Afronding

Na de afronding van de vorige fase (en eventueel incidentonderzoek als er daadwerkelijk iets aan de hand lijkt te zijn), is het verstandig om de bevindingen en geleerde lessen vast te leggen en waar nodig de procedures, tools en afspraken aan te passen. De analysestappen uit de vorige fase zijn eigenlijk een soort vingeroefeningen voor een echt incident – en in veel gevallen loopt men tegen praktische problemen aan die idealiter opgelost dienen te zijn voor de volgende waarschuwing binnenkomt.

Dit kunnen problemen rondom tooling zijn (Kunnen wij snel onze omgeving doorzoeken? Kunnen wij verdachte systemen isoleren?) maar vaak loopt men ook tegen organisatorische aspecten aan (Hebben wij goede afspraken gemaakt over hoe snel leveranciers bepaalde acties moeten uitvoeren?). Ook is het goed om te evalueren hoe effectief de melding verwerkt kon worden – wellicht zijn er nog informele contacten die versterkt kunnen worden om de volgende keer samen een melding te analyseren.

Zorg tot slot voor een goede rapportage. Laat ook de rest van de organisatie weten hoe jullie hier als securityteam mee bezig zijn geweest. Dat helpt niet alleen om te laten zien waar jullie als team aan werken, het helpt ook om collega’s alert te maken en te houden met betrekking tot verdachte zaken die zij wellicht in hun systemen tegenkomen.

Conclusie

Zoals gezegd, een digitale buienradar die tot op de minuut voorspelt wanneer de druppels vallen is in veel gevallen nog een utopie – maar door dreigingsinformatie systematisch te analyseren en te gebruiken als vingeroefening wanneer het nog droog is, kan men stap voor stap de weerbaarheid op een hoger niveau krijgen. Juist als het zonnetje schijnt, is het een goed moment om die goede kleding uit het gezegde te kopen, of om een paraplu klaar te leggen.