Elk bedrijf doet wel iets met security, steeds mee bedrijven laten penetratietesten uitvoeren. Waarom eigenlijk? En wat laat je nou wel en wat laat je niet testen?
Deze vraag zie ik steeds meer bij klanten langskomen, de urgentie om iets te doen met security bestaat wel. Het is echter lastig om te zien welke soort test en welke scope de vraag beantwoord. De meeste bedrijven zien door de verschillende soorten testen en de vele hippe kreten; “Red Teaming, APT (advanced persistence threat), Vulnerability scan, Security Audit etc.” de spreekwoordelijke bomen in het bos niet meer.
Aangezien ik in dit artikel in wil gaan op security testing in zijn verschillende vormen lijkt het verstandig eerst het verschil uit te leggen tussen een audit en een test. Bij een audit worden verschillende maatregelen / procedures etc. bekeken. Bij een test, het woord zegt het al, worden de maatregelen niet alleen bekeken maar vooral getest om vast te stellen in hoeverre ze effectief blijken.
De testen die ik in dit korte artikel wil onderscheiden zijn:
- Applicatieve Penetratietest: Onderdeel van de product life cycle;
- Externe Penetratietest als onderdeel van een periodieke zoektocht naar kwetsbaarheden in internetgebonden infrastructuur en applicaties;
- Interne Penetratietest: Doel is de resterende kwetsbaarheden in het interne netwerk bloot te leggen om deze te kunnen aanpakken;
- Aanvals simulatie (Red Teaming): Testen in hoeverre een organisatie als geheel bestand is tegen een daadwerkelijke gerichte aanval. Zowel preventieve, detectieve en reactieve kracht worden hier getest.
Als je als bedrijf met security aan de slag gaat is het verstandig een plan op te stellen om zo kosten-efficiënt mogelijk de bestaande risico’s af te dekken. Het uitvoeren van een aanvals simulatie is meestal weggegooid geld als men al weet dat de beveiliging (preventief, detectief en reactief) verre van optimaal is. Een applicatieve penetratietest op een van de websites beantwoord anderzijds niet de vraag over hoe het er nu in brede zin voor staat met de beveiliging.
Toch kloppen klanten vaak aan met de vraag of ik de nieuwe website die ze net hebben gebouwd wil testen, voordat ik hier in duik neem ik graag de tijd om te bekijken en bespreken hoe de organisatie afhankelijk is van ICT en waar de kroonjuwelen te vinden zijn. Het uitgebreide leveranciers portaal dat al acht jaar trouw zijn diensten bewijst is vaak minstens net zo kwetsbaar of zelfs kwetsbaarder dan de nieuw ontwikkelde web applicatie.
Mijn advies aan klanten is dan ook om eerst een lat te leggen, dit kun je doen door een bredere externe penetratietest te laten uitvoeren over alle componenten die zichtbaar zijn van het internet, ditzelfde zou je ook kunnen uitvoeren voor het interne netwerk. Op het moment dat deze nul meting is gedaan blijkt vaak dat er al zoveel te verbeteren valt dat het uitvoeren van gerichtere testen op applicaties helemaal niet zal leiden tot een betere algehele beveiliging.
De klant is dan vaak gebaat bij een goede analyse van de aangetroffen problemen om er zo voor te zorgen dat hij niet enkel het gevonden issue laat oplossen maar ook de oorzaak wegneemt waardoor deze situatie heeft kunnen ontstaan. Je kunt een missende patch snel na een security test installeren, prima! De vraag hoe het kan dat die patch miste is voor de langere termijn echter veel belangrijker. Na een aantal iteraties voort men een hertest uit om te zien of de incidenten uit de eerste test zijn weggenomen, aangevuld met een steekproef om te zien of achterliggende problemen zijn verminderd. Als dit het geval is en de lat lijkt behoorlijk hoger te liggen kan een men dit testen door nog een volledige test uit te voeren op het interne en externe netwerk.
Naast het verhelpen van zoveel mogelijk kwetsbaarheden zal een organisatie ook moeten werken aan detectieve maatregelen. Er zullen altijd nieuwe kwetsbaarheden gevonden worden in software producten, het is bijna onmogelijk altijd met alle software op alle systemen helemaal bij te zijn. Goede detectieve maatregelen zorgen er voor dat een aanval tijdig kan worden opgemerkt en de schade behoorlijk beperkt kan worden. Veelal denkt men dat er zoveel mogelijk gemonitord moet worden, echter blijkt dan vaak dat er wel meldingen komen maar dat er geen actie op wordt ondernomen. Er zou een duidelijk onderscheid gemaakt moeten worden tussen het reguliere monitoren van beschikbaarheid en onverwachte foutsituaties en het monitoren op specifieke security kenmerken die altijd een alarm en opvolging vereisen.
Denk hierbij aan een server in het DMZ of het interne netwerk die een connectie naar buiten maakt naar een onverwacht systeem (er zou een White list kunnen zijn van servers die legitiem benaderd mogen worden). Een hit op een dergelijke regel betekend altijd dat er iets mis is, een goed onderhouden set van regels die altijd als automatisch gevolg hebben dat er een security incident wordt aangemaakt en afgehandeld kunnen een bedrijf helpen de kans op detectie fors te vergroten.
Op het moment dat de organisatie van mening is dat al deze componenten op niveau zijn is het tijd een aanval te simuleren om te zien of deze gedetecteerd wordt en of de organisatie capabel is een dergelijke aanval af te slaan of te beperken.
Terug naar de vraag om een los, nieuw te introduceren product te testen, indien een organisatie een redelijk beeld heeft van de beveiligingsstatus van de omgeving is het absoluut verstandig componenten die hieraan worden toegevoegd te testen, bij voorkeur enige tijd voor de release zodat het ontwikkelteam nog tijd heeft de gevonden kwetsbaarheden op te lossen en een hertest kan worden uitgevoerd. Nadat het product live is gegaan kan het product worden meegenomen in de reguliere planning. Grote aanpassingen aan een product of het toevoegen van nieuwe kanalen, bijvoorbeeld mobiele apps, verdienen een zelfde soort aanpak voordat deze worden geïntroduceerd.
Meer dan eens wordt een security test uitgevoerd vanuit een verplichting, als onderdeel van een audit over certificering. Hier schuilt een groot gevaar voor een vals gevoel van veiligheid, immers als je niet wilt weten welke kwetsbaarheden er in je product zitten en je wordt door een derde verplicht een test uit te voeren dan kies je hiervoor de goedkoopste tester in de hoop dat deze niets vindt. Vervolgens wordt een dun rapport met gejuich ontvangen en een vals gevoel van veiligheid is geboren.
Mocht dit niet de insteek zijn dan is het wellicht verstandig te de planning voor de reguliere testen zo te plannen dat de uitgevoerde test ook gebruikt kan worden voor de audit of certificering en uiteraard te zorgen voor specialisten diep in de materie duiken om alle kwetsbaarheden boven water te krijgen.
Een veel gevoerd product in de security testing wereld, de zogeheten blackbox test geeft aan dat zelfs bij veel partijen die testen uitvoeren bovengenoemde verschillen nog lastig zijn. Een penetratietest met als doel zoveel mogelijk kwetsbaarheden boven water te krijgen zonder vooraf informatie te ontvangen gaat niet leiden tot identificatie van een maximaal aantal kwetsbaarheden, een test zonder informatie vooraf maar met de andere kenmerken van een penetratietest (met name beperkte scope) gaat geen realistisch beeld geven van de weerbaarheid van de organisatie als geheel.
Samenvattend: een blackbox penetratietest is een test met een identiteitscrisis, een door derden verplichte test levert vaak een vals gevoel van veiligheid. Om security testing goed te regelen is het verstandig met een expert een plan op te stellen om de juiste verhoudingen te vinden tussen de verschillende penetratietesten met als doel zoveel mogelijk kwetsbaarheden te identificeren gevolgd door aan als simulatie testen (Red Teaming) om de weerbaarheid van de organisatie als geheel te testen en te verbeteren.
