Afgelopen week vond de flitswebinar “Wachtwoord vergeten? Prima!” in samenwerking met Thales plaats. 

Michiel Linders van Thales ging dieper in op snelle, makkelijke en veilige authenticatie met FIDO tokens. Voor wie niet bij de webinar kon zijn: hij is gelukkig terug te kijken. Hij staat hieronder!

FIDO token aanvragen

Na afloop van de webinar ontvingen deelnemers een FIDO-token om zelf uit te proberen. Er zijn er nog een paar over. Een FIDO token aanvragen? Of de FIDO token die u al heeft installeren? Bekijk dan deze pagina.

“Geen tot weinig false positives”: het is een uitspraak die regelmatig te horen is in de cyber security. Maar ook buiten de cyber security wereld spreekt men steeds vaker over false positives. Bijvoorbeeld wanneer het gaat om Covid-19 zelftests.

Maar: wat zijn die false positives precies? En waarom is het goed als er “geen tot weinig” false positives voorkomen bij bijvoorbeeld een SIEM of SOC? In dit artikel: alles over false positives, false negatives, hun gevaren en: hoe cyber security professionals met die gevaren omgaan.

Allereerst: wat is de definitie van “false positive”?

We gaan het niet moeilijker maken dan het is. In de cyber security is de false positive in basis een onterechte melding van een potentiële threat. Met andere woorden: u ontvangt een alert (SIEM event), terwijl er geen potentieel gevaar is. In de praktijk betekent dat onnodig tijdverlies. Want vaak komt pas na een onderzoek naar de melding naar voren dat het om een false positive ging. Niet zo handig dus.

Voorbeeld van een cyber security false positive

Eerst een voorbeeld buiten de cyber security: de eerder genoemde Covid-19 zelftest. De grote zorg bij deze test was dat mensen die wél corona hebben, toch de uitslag “negatief” kregen na zo’n test. Iemand die wel ziek is maar geen positieve testuitslag krijgt, heeft te maken met een false positive.

Een false positive in de cyber security kan een alert na een grote reeks mislukte inlogpogingen zijn. Mislukte inlogpogingen zijn verdacht en kunnen wijzen op o.a. een brute force attack. Maar hebben we hier te maken met een collega die zijn wachtwoord gewoon vergeten is en daarom vaak zonder succes inlogt? Dan is er onterecht een melding geweest: een false positive.

Het gevaar van false positives

We benoemden al dat false positives onnodig veel tijd kosten. Het is enorm frustrerend om keer op keer onderzoek te doen naar een melding die achteraf onterecht blijkt te zijn. Daar zit meteen ook het gevaar: het kan zijn dat mensen hun gedrag aan gaan passen aan deze false positives. Hoe dat zit? Een voorbeeld die velen vast herkennen:

De meeste bedrijfspanden zijn voorzien van een anti-inbraakalarm. Goede alarmen zijn vaak zo afgesteld dat ze alleen reageren op bewegingen van mensen (potentiële inbrekers). Maar er zijn ook alarmen die al af gaan bij kleinere bewegende objecten zoals een kat, een poster die van de muur valt of zelfs een vogel die voorbij vliegt.

Gaat zo’n anti-inbraakalarm te vaak onterecht af? Dan vertelt ons brein ons dat het vast weer een vogel is en we niet hoeven te gaan kijken. Maar daar zit wel het gevaar: want wat nou als het één keer wél een inbreker is? En er ook dan niemand op af gaat om te kijken? Tsja, dan zijn alle spullen weg. En zo zit het ook met false positives in de cyber security. Dan is ineens alle data versleuteld.

Wat is een false negative dan?

Voor we verder in gaan op hoe false positives ontstaan én hoe ze te voorkomen zijn, eerst even meer over de false negative. Die krijgt vaak wat minder aandacht. Dat komt doordat ze in de cyber security praktijk – gelukkig – wat minder vaak voorkomen dan false positives. Maar áls er spraken is van een false negative zijn de gevolgen vaak groot.

Een false negative betekent namelijk dat er geen alert is geweest terwijl die er wel had moeten zijn. Er is dus gevaar, maar het is niet gedetecteerd. De uitkomst? Een hacker die vrij spel heeft, want niemand heeft op tijd in kunnen grijpen.

Liever false positives dan false negatives

Niets is naarder dan een SIEM of SOC hebben, maar vervolgens toch slachtoffer zijn van een aanval omdat er geen alert is geweest. Daarom zijn cyber security oplossingen zo afgesteld, dat de kans op een false negative (binnen de scope van de oplossing) zo klein mogelijk is. Liever een melding teveel dan een melding te weinig, tenslotte.

Maar zoals we eerder al benoemden: een overschot aan false positives is óók gevaarlijk en dus onwenselijk. En helaas zijn er nog genoeg security oplossingen op de markt die stikken van de false positives. IP4Sure doet er alles aan false negatives te voorkomen én de false positives zo laag mogelijk te houden. Hoe? Dat leggen we uit.

Hoe gaan onze cyber security professionals hiermee om?

Betrouwbare SIEM-software ontwikkelen en instellen is volgens experts te vergelijken met een spelletje “Wie is het?”. Oké, het is niet zo simpel als het spelen van een spel, maar de principes komen overeen. Tijdens het spel stellen spelers elkaar vragen om zo stap voor stap plaatjes van gezichten die niet overeen komen met de Mystery Person van de tegenspeler te elimineren. Te algemene vragen leveren niets op, maar te specifieke vragen ook niet.

Zo werkt het bij het instellen van een SIEM ook. Stellen we te algemene regels op? Dan krijgt u een berg aan false positives voorgeschoteld. Stellen we te specifieke regels op? Dan is er een kans dat echte incidenten die nét niet helemaal overeen komen met de omschrijving alsnog gemist worden. False negatives dus. De kunst zit hem in het opstellen van regels die beide scenario’s voorkomen.

Het schrijven van SIEM regels

Stel, Richard is een threat. Dan is die threat te omschrijven als “Een man met donkere gezichtsbeharing”. Maar zoals u ziet, is Richard niet de enige die overeen komt met die omschrijving: Alex, Philip en Max ook. Met deze omschrijving zorgen deze drie mannen ook voor een alert, ook al is enkel Richard de threat. In totaal kent het spel 24 personen, dus 4 is een hoog percentage false positives.

Een betere regel is “Een kale man met een donkere baard”. Deze omschrijving is iets specifieker en komt enkel overeen met Richard. Deze regel levert daardoor geen false positives op. Een voorbeeld van een omschrijving die false negatives op kan leveren? Die hebben we ook:

“Een kale man met een donkere baard en een oorbel”. Deze omschrijving komt vast overeen met een hele specifieke threat die een variatie is op Richard. Maar komt Richard zelf binnen? Dan levert deze regel geen alert op, terwijl hij wel een threat is. Een false negative dus.

SIEM regels in de cyber security praktijk

Natuurlijk is de praktijk niet zo simpel als een spelletje “Wie is het?”. Er komt veel kijken bij het ontwikkelen van SIEM-regels die effectief zijn én geen tot weinig false positives opleveren. Vaak analyseren professionals bestaande data om aan de hand daarvan passende SIEM-regels te schrijven.

De IP4Sure SOC

Teveel false positives is niet veilig, en teveel false negatives al helemaal niet. De IP4Sure SOC is zo opgebouwd, dat beide scenario’s niet zomaar voor komen. Ook concessies in de reikwijdte van de monitoring vanwege te lage budgetten (waardoor u dus ook belangrijke meldingen mist) zijn niet nodig.

We hebben er alles aan gedaan een SOC te bieden die toegankelijk én veilig is. Lees hier meer over de IP4Sure SOC. Vragen over onze SOC of over dit onderwerp? Neem vrijblijvend contact met ons op.

Een security incident is niemands idee van een ideale maandag. Weinigen staan te springen om een kwetsbaarheid in hun digitale infrastructuur. Toch zijn security incidenten als een soort “cadeau” te zien. Het is een kans om te leren. En: een kans om het nooit meer te laten gebeuren.

Zeker in een tijd waarin de digitale dreiging steeds meer toeneemt, is het belangrijk een les te trekken uit security incidenten. De vraag is tegenwoordig niet of u er last van gaat krijgen, maar wanneer. Zonde om een incident te laten gebeuren, het op te lossen en er vervolgens weer een te krijgen. Dat ene incident geeft namelijk heel veel informatie.
 

Wat er vaak gebeurt bij een security incident

Een eerste – logische – reactie op een security incident is een vinger in de dijk stoppen. De kwDe vulnerability scan, de pentest en hun verschillenetsbaarheid verhelpen en verdergaan. Ja, het is een oplossing. Maar niet dé oplossing. Want wat doet u wanneer er nog een security incident optreedt? Ook daar een vinger in stoppen?

Het is goed om te begrijpen dat een technische kwetsbaarheid vaak niet opzichzelfstaand is. Ja, een vinger in de dijk verhelpt dat ene gat. Maar als de volledige dijk niet goed gebouwd is, breekt deze op een gegeven moment toch echt door. Dat is met een digitale infrastructuur hetzelfde. Een kwetsbaarheid is regelmatig een teken dat er meer aan de hand is.
 

Een kwetsbaarheid komt nooit alleen

Meestal is zo’n security incident een signaal dat er iets op grotere schaal niet klopt. Waar rook is, is vuur. Enkel focussen op het herstellen van hetgeen dat rookt, is dus niet voldoende. Het is regelmatig een voorbode dat er meer problemen kunnen gaan ontstaan.

Hoe dat kan? Vaak ontstaat een kwetsbaarheid doordat een mens deze in het proces over het hoofd heeft gezien. Dat betekent dat er een kans is dat wanneer het proces hetzelfde blijft, er in de toekomst door dezelfde fout weer nieuwe kwetsbaarheden ontstaan.
 

Voorkom dat u pleisters blijft plakken

Waarschijnlijk hebben we ons punt gemaakt: een security incident is niet één losstaand iets, maar juist een gebeurtenis die wat zegt over uw volledige security. Een gebeurtenis waar veel uit te leren is. De natuurlijke reactie op een incident is vaak reactief in actie komen, maar een proactieve en preventieve benadering die verder kijkt dan dat ene incident verbetert de volledige security.
 

Zo leert u voortaan van een security incident

Natuurlijk, stap één is en blijft altijd het verhelpen van de kwetsbaarheid. Maar daarna komt het belangrijkste: goed snappen waarom het gebeurd is. Waarom heeft dit specifieke security incident plaatsgevonden? Waarin werd er technisch tekort gekomen? Welke fout is er in het proces gemaakt waardoor het heeft kunnen gebeuren?

Denk bijvoorbeeld aan het bouwen van een webapplicatie. Soms kan een ontwikkelaar per ongeluk een kwetsbaarheid coderen en deze zonder extra controle toevoegen aan de applicatie. Een foutje kan altijd gebeuren. Maar dat deze niet op tijd gedetecteerd is, wijst op een tekortkoming in het proces. Dan is het dus zaak niet alleen specifiek het security incident op te lossen, maar er ook voor te zorgen dat deze fout niet nog eens voor kan komen.
 

Stappen om te doorlopen na het implementeren van een oplossing

Er zeker van zijn dat een security incident meer dan alleen hoofdpijn en slapeloze nachten oplevert? Doorloop dan na het oplossen van een incident altijd de volgende stappen:

1. Is er iets gebeurd door misconfiguraties door de mens?
2. Kan het zijn dat de fout die dit security incident heeft veroorzaakt ook op andere plekken zit?
3. Haal iemand erbij die met een frisse blik naar de infrastructuur kijkt.
4. Degene die kennis heeft van de infrastructuur moet nieuwe kennis doortrekken.

Securityminded implementatie

Al met al mag er in zijn geheel meer securityminded gekeken worden naar de digitale omgeving van organisaties. Het is beter meteen met cybersecurity in het achterhoofd te gaan implementeren, dan achteraf problemen op te lossen. Securityminded werken is een stuk minder duur, minder risicovol en minder tijdrovend.

Dus leer van incidenten! Want door het ten harte te nemen, kunt u er de volgende keer aan het begin al rekening mee houden.