Maximale effectiviteit van een pentest met de Assume Breach aanpak

Veel organisaties laten de beveiliging van hun applicaties, systemen en netwerken periodiek testen, om erachter te komen wat het risico is van bepaalde kwetsbaarheden die uitgebuit kunnen worden. Vaak zijn deze tests technisch georiënteerd en hebben als doel het aanvalsoppervlak te verkleinen, door de verkregen inzichten te gebruiken om maatregelen te nemen. Maar is dit voldoende? De cijfers uit het laatste rapport van Verizon spreken dit in ieder geval tegen, bijvoorbeeld door het feit dat 82% van de breaches een menselijke fout betreft.

Red team oefeningen

De menselijke factor, hoe neem je die mee in bijvoorbeeld een pentest? Je ziet nog maar weinig bedrijven daar een oplossing voor bieden. Er zijn andere diensten die dit wel meenemen en dat zijn de zogeheten Red Team oefeningen. Deze oefeningen zijn kostbaar, maar wel heel nuttig. Het werkt zo: vooraf wordt een realistische dreiging met bijbehorend aanvalspad bepaald. Dit aanvalspad wordt vervolgens, idealiter onaangekondigd, uitgevoerd door een team van offensive security engineers en ethische hackers. Het doel? Het beoordelen of alle securitymaatregelen op orde zijn, dat processen en protocollen gevolgd worden, en dat alles binnen de afgesproken tijd om de impact van onbeschikbaarheid af te dekken. Een Red team oefening duurt normaal gesproken tussen de twee en de vier weken en wordt er typisch één bepaalde dreiging gesimuleerd via een aanvalspad.

Aanvalspad

Een aanvalspad is een aaneenschakeling van acties waarin een hacker profiteert van meerdere kwetsbaarheden in het systeem. Deze kwetsbaarheden richten zich niet alleen op de techniek, maar ook op de menselijke fouten. Als voorbeeld: Een hacker onderzoekt wie er allemaal werken bij een organisatie, d.m.v. open social networks en met al dan niet geavanceerde zoek queries op bekende search engines. Dit verkennende proces wordt ook wel Open Source Intelligents, of OSINT, genoemd. Vervolgens ontdekt hij ook een aantal valide e-mailadressen en hieruit kan hij opmaken dat de e-mailadressen zijn gevormd door een patroon: voornaam.achternaam@organisatie.nl.

Zijn volgende actie is om een phishing link te sturen waarin de geadresseerden een gewilde Excel kunnen downloaden. Het lukt hem ook om de mail te versturen uit een nieuw domein dat hij voor de gelegenheid geregistreerd heeft; organisatie.net. Een aantal medewerkers klikken op de link, maar moeten zich aanmelden. De aanmelding komt vertrouwd over, maar ondertussen melden de slachtoffers zich aan op een loginscherm dat de hacker heeft nagemaakt op zijn nepdomein. Hierdoor heeft de hacker een aantal logingegevens van medewerkers te pakken.

Het doel van de hacker is om uiteindelijk gevoelige gegevens buit te maken. Hier moeten nog een aantal drempels genomen worden. Eenmaal op het interne netwerk waar hij zich toegang tot kon verschaffen met de buitgemaakte login gegevens, vindt de hacker bij één van de medewerkers een tekstbestand in een folder met een wachtwoord van een productiedatabase. Het lukt hem om op de database in te loggen en uiteindelijk allerlei gevoelige informatie te verkrijgen.

Voor de duidelijkheid: Een phishing-aanval die tot een inbraak leidt, is NIET de schuld van een eindgebruiker, maar eerder van het ontbreken van voldoende beveiligingsmaatregelen. Veel organisaties zijn niet van plan alle beveiliging af te hangen van één enkele gebruiker, maar de maatregelen die worden genomen om systemen te verdedigen, zeggen vaak iets anders.

Pentest

Een Red team exercitie is dus heel nuttig, omdat de beveiligingsmaatregelen van een organisatie worden getoetst. Echter, een red team exercitie is pas nuttig als eerst een aantal maatregelen op orde zijn (omdat deze juist getest worden). Daarnaast speelt het kostenaspect. Een pentest daarentegen heeft een heel ander doel: en dat is het verkleinen van het aanvalsoppervlak. Een aanvalsoppervlak is bijvoorbeeld een extern gerichte webapplicatie. Vaak wordt een pentest voorafgegaan door een zogeheten kwetsbaarhedenscan: dit is een nuttige en goedkope manier om via tooling inzichtelijk te krijgen welke kwetsbaarheden er aanwezig zijn. Denk aan verouderde softwareversies van systemen, het ontbreken van multi-factor authentication of onnodig openstaande netwerkpoorten. De pentest borduurt hierop voort en probeert ook echt deze kwetsbaarheden uit te buiten om zo tot een juiste impactbepaling te komen, zodat maatregelen genomen kunnen worden die in lijn zijn met het budget.

Echter, de juiste scope en afspraken bepalen de effectiviteit van een pentest. Onvolwassen organisaties zullen zeggen: probeer maar eerst eens op het netwerk te komen. Voor je het weet, worden alle tijd en energie verspild om überhaupt in te breken. Dit is zonde, omdat er geen tijd meer is om onderzoek te doen naar de uitbuiting van kwetsbaarheden op het netwerk.

Assume Breach

Het Assume Breach model helpt bij het vergroten van de effectiviteit van een pentest. Wat betekent Assume Breach? Ga ervan uit dat een hacker al binnen is. Dit lukt hem namelijk uiteindelijk toch wel, al dan niet door menselijke fouten. Zoals ook in het beschreven voorbeeld van phishing toegelicht wordt. Twijfel je of dit realistisch is? Bedenk het volgende: in een organisatie van 1000 medewerkers zal er vast wel iemand tussen zitten die in een phishing-val trapt.

Dit wil niet zeggen dat er helemaal niet gekeken moet worden om de ‘schil’ te doorbreken. Je moet de buitenkant zeker testen, maar besteed hier een time-boxed periode aan. Focus vooral op het feit dat de hacker al binnen is. Dan kunnen andere zaken aan het licht komen, zoals: is alle toegang wel goed afgeschermd? Een voorbeeldconstatering is dat er maar tien mensen toegang zouden moeten hebben tot het klanteninfosysteem met vele klantrecords die gevoelig zijn. Echter, de test wijst uit dat er meer dan 200 zijn, door een misconfiguratie van de autorisatierollen. En het account van de persoon die gebruikt is van het slachtoffer, kan hier ook bij.

Samenvattend, het is dus altijd nuttig en kosteneffectief om het aanvalsoppervlak met een kwetsbaarhedenscan te kunnen verkleinen. Een pentest doet hier nog een schep bovenop door ook de risico’s van de uitbuiting van een kwetsbaarheid aan te tonen. Maar de toevoeging van de Asssume breach aanpak, de menselijke fout vooral meenemend in een pentest geeft nét deze extra dimensie om te controleren of de bestaande beveiligingsmaatregelen in de kern ook op orde zijn. De ervaring leert dat genomen beveiligingsmaatregelen een harde korst, maar een zachte kern bewerkstelligen. Dit weten aanvallers ook. Het daarom is het zaak deze kern zoveel mogelijk mee te nemen in de pentest.

Lees ook:

Gerelateerde berichten...