Pentesten vs. BAS in een notendop

Pentesten vs. BAS in een notendop

Auteur: Tiennot van Dilst, CISSP, CEH, CIPP/e, CxCE, CTO / Security Expert

Pentesten en wat te verwachten

Tijdens mijn werkzaamheden in security heb ik onnoemlijk veel leuke en interessante projecten uit mogen voeren. Deels op het vlak compliance, en deels als infrastructuur pentester.

Pentesten is toch wel een stukje wat ik altijd bijzonder heb gevonden. Ik mocht zaken doen welke veelal voor andere personen verboden zijn. Wanneer een nieuwe applicatie of een nieuw stuk infrastructuur werd opgeleverd werden ik en mijn ethical hack team ingehuurd om te kijken of de architecten, ontwikkelaars en beheerders alles wel op de juiste manier hadden bedacht, ontwikkeld, opgeleverd en ingeregeld.  Ik zal even in vogelvlucht beschrijven hoe een dergelijk proces in zijn werk ging.

Een klant gaf aan dat ze een specifiek IT gerelateerd project getest wilde zien (veelal bij oplevering of bij een belangrijke wijziging). Vanuit de verkooporganisatie werd een vergadering met de klant belegd. Tijdens deze vergadering werd besproken wat er precies getest diende te worden. Denk hierbij aan applicatie, infrastructuur, API’s, design en soms bijvoorbeeld code. En wat absoluut niet.

Tijdens dit gesprek probeerden we ook de gebruikte technologie vast te stellen en welke methodologie er gebruikt diende te worden - Black box, Grey box of White box (Crystal box). Daarnaast werden de starttijden, doorlooptijden en de deliverables vastgesteld.

Zodra de klantopdracht binnen was, nam de projectmanager contact op met de klant om zaken zoals toegang, werkplekken verblijf voor de consultants (wanneer onsite) te regelen. Tijdens de kick-off vergadering, voorafgaand aan de eigenlijke test, werden de laatste voorbereidingen gecontroleerd en de checklists werden nagelopen.

Tijdens de uitvoering van de test was er meestal de afspraak dat bevindingen met een hoog of kritiek risico tijdens de test al gemeld werden naar de opdrachtgever. Uiteraard alleen als dit mogelijk was, veel bevindingen werden namelijk gedaan na de daadwerkelijke test, tijden de QA of analytische fase. En aan het einde van de test volgde meestal een afsluitende bijeenkomst waarin de tot dan toe gedane bevindingen aan de klant gepresenteerd werden.

Na de testperiode - in veel gevallen minimaal een week - werden de uitkomsten van de testen en de output van de tools geanalyseerd, beoordeeld en de rapportage werd opgesteld. Het rapport ging doorgaans tweemaal langs onze kwaliteitscontrole alvorens het naar de klant gestuurd werd. Deze laatste fase nam meestal 2 weken in beslag. 

Ik probeer met dit bovenstaande te beschrijven, dat er rekening gehouden moet worden met een tijd van minimaal 4-6 weken tussen het eerste contact tussen pentest partij en opdrachtgever en het opleveren van de daadwerkelijk rapportage. En dit is in veel gevallen best positief ingeschat.

Er even vanuit gaande dat ik voor wat betreft doorlooptijd gelijk heb, het dus betekent dat de opdrachtgever na 4 tot 6 weken de problemen in de applicatie pas echt kon gaan oplossen.  En veelal diende de reparaties ook weer opnieuw getest te worden. Want een fix voor een probleem kan namelijk een nieuwe security bug elders in de applicatie introduceren. Wel moet ik erbij zeggen dat de hertesten in veel van de gevallen 2 tot 5 dagen kostte met meestal niet meer dan 1 dag voor de rapportage.

Hoe realistisch zijn pentesten eigenlijk?

Laat me beginnen om aan te geven dat pentesten ontzettend belangrijk zijn. Omdat ze wel heel veel problemen aan het licht brengen die anders nooit gevonden waren. Echter voor een organisatie kan het uitvoeren van periodieke pentesten ook een vals gevoel van veiligheid introduceren.

Meer dan eens heb ik één van de managers in een organisatie horen zeggen dat ze veilig zijn omdat er periodiek pentesten uitgevoerd worden en dat er doorgaans niet zoveel gevonden wordt. Echter wat een hoop mensen vergeten is dat de pentesten meestal uitgevoerd worden op een bepaalde applicatie, of een bepaald stuk van de infrastructuur met een stringent ingeregelde scope waarin onder andere zaken vastgelegd zijn over:

• hoe een applicatie te benaderen;

< >hoelang mag er getest worden;welke methodologieën en testen gebruiken we wel, maar vooral ook niet;met welke intensiteit kan er worden getest;vanaf welke locatie mag er getest worden;

En hier komt eigenlijk al gelijk iets naar boven wat volgens mij in veel gevallen niet duidelijk genoeg bekend is bij de organisaties welke pentesten laten uitvoeren.

Een hacker heeft namelijk geen scope of limitatie… een hacker heeft 2 dingen… tijd en een doel!

We mogen natuurlijk geen appels met peren vergelijken. Een pentest is eigenlijk bedoeld om een afgebakend deel van de IT te testen (omgeving / applicatie of infrastructuur), waarbij een groot deel van de mitigerende maatregelen veelal niet getest worden. Echter er leeft, zoals eerder beschreven, bij veel organisaties nog steeds het gevoel dat ze testen hebben uitgevoerd en dus veilig zijn.

Maar wat krijgen we ervoor?

Tijdens een pentest is de tester eigenlijk op zoek naar wat vergelijkbaar is met het bepalen van de symptomen van een ziekte, zeker wanneer we onder de zogenaamde “Blackbox Methodologie” werken. De tester vindt de kwetsbaarheden, en veelal is het aan de organisatie om (veel later) te beoordelen waardoor deze kwetsbaarheden optreden. Een tweede ding waar men zeker rekening mee dient te houden is dat eigenlijk nooit alle kwetsbaarheden gevonden worden. Sterker nog, om een applicatie goed in kaart te krijgen en te zorgen dat de meeste kwetsbaarheden opgelost kunnen worden zijn vaak meerdere testen nodig. Het mooiste zou zijn om dat te doen na iedere grote verandering in een systeem en na iedere security patch die geïnstalleerd is.

Last but not least, vanwege de randvoorwaarden van de pentest word wel de techniek getest (LET OP, alleen van het deel dat in scope is), echter processen zoals monitoring en incident response worden niet meegenomen.

En mijn ervaring is, dat dit voor heel veel organisaties niet haalbaar is. De kosten en/of inzet gemoeid met een pentest zijn aanzienlijk, evenals de onderbrekingen in de productie omgevingen. Afgezien nog van het feit dat er heel veel kwaliteitsverschillen zijn in de aangeboden pentesters.

Conclusie voor Pentesten

Zeker belangrijk is om goed voor ogen te houden wat de uitkomst is en wat daarmee te bereiken valt. Na een pentest en fix-ronde, is slechts een afgebakend deel van de totale omgeving getest.

Na de eerst volgende update, of in sommige gevallen zelfs, na de eerste IT gerelateerde configuratiewerkzaamheden liggen de kaarten al anders.

Breach en Attack Simulatie (BAS) in combinatie met handmatige pentesten kunnen de IT- en OT- omgevingen naar een hoger beveiligingsniveau tillen en vanwege het continue en geautomatiseerde karakter van de simulaties daar houden.

Daarnaast geeft BAS de mogelijkheid om meer dan de techniek te testen, ook de processen zoals SOC, Incident Respons, Forensics, en meer.