Document toolboxDocument toolbox

5.6.6. De details over penetratietesten

Wat is het?

Bij een penetratietest vraag je een tester om kwetsbaarheden van een bepaalde toepassing te onderzoeken. Dit gebeurt met een vooraf bepaalde scope: welk(e) (deel van een) toepassing moet de tester benaderen en met welke aanvalsvectoren. Deze testen gebeuren in principe altijd in de productieomgeving.

Het kan hierbij een toegevoegde waarde zijn om te werken met een gecertificeerde tester. Wat echter belangrijker is, is dat er duidelijke afspraken zijn over testscenario’s en de modaliteiten van de tets (scope, aanvalsvectoren, timing, etc.). 

In welke omgeving doe je penetratietesten?

  • Als de acceptatieomgeving op exact dezelfde manier is ingericht als de productieomgeving, kan een penetratietest gebeuren in de acceptatieomgeving vóór een gewijzigde toepassing live gaat. Dit geldt dan enkel voor testen in het kader van een wijziging

  • In deze omgeving doe je penetratie testen. Om de mogelijke impact op productie te beperken, kun je de timing wel zo voorzien dat het niet conflicteert met piekmomenten (bijvoorbeeld in een weekend, niet bij een maandafsluiting).

  • Recurrente testen gebeuren in de productieomgeving

Wat?

  • Er zijn drie soorten tests die je kunt doen:

    • “White box”: hierbij heeft de tester informatie over de manier waarop de toepassing is geïmplementeerd en over de interne werking van de organisatie (architectuur, organigram, etc.)

    • “Black box”: hierbij heeft de tester in principe geen, of bijna geen informatie over de toepassing of de organisatie 

    • “Grey box”: hierbij krijgt de tester een deel van de informatie, maar niet zoveel als bij een white box

  • Bij het testen houd je rekening met een bepaalde scope. In het zoeken naar mogelijke kwetsbaarheden, moet de penetration tester minstens rekening houden met deze aanvalsvectoren, kwetsbaarheden en technieken:

    • De OWASP top 10 kwetsbaarheden

    • (D)DoS paraatheid

    • Brute force attack paraatheid

    • Buffer overflow/memory leak

    • Check tegen gekende CVE reports (zie link op p.3)

    • Credential hunting (default passwoorden, hardgecodeerde gebruikersnamen of wachtwoorden)

    • Downgrade attacks die gebruik maken van verouderde protocollen

    • Exploit servers

    • Input errors

    • Privilege escalation

    • Zoeken naar niet-ondersteunde versies van programma’s of systemen

 

Dit is een overzicht van de verschillende termijnen die je moet respecteren voor het uitvoeren van de tests en het remediëren van ontdekte kwetsbaarheden. Het zegt ook welk soort test je kunt uitvoeren in de gegeven context.

Hoedanigheid/
Informatieklasse van de
toepassing

Frequentie 

Kritische, Significante
en Grote risico
kwetsbaarheden
oplossen binnen2

 

Gemiddelde en
Kleine risico
kwetsbaarheden
oplossen binnen

Soort test

Hoedanigheid/
Informatieklasse van de
toepassing

Frequentie 

Kritische, Significante
en Grote risico
kwetsbaarheden
oplossen binnen2

 

Gemiddelde en
Kleine risico
kwetsbaarheden
oplossen binnen

Soort test

 

Toepassingen die
persoonsgebonden
informatie bevatten
(ongeacht de klasse)

Bij de release van een
nieuwe versie, of minstens 1
keer per jaar

2 werkweken 

4 werkweken

Black box
Grey box
White Box

Klasse 3, 4 en 5

(Vertrouwelijkheid en/of
Integriteit)

 

Bij de release van een
nieuwe versie, of minstens 1
keer per jaar

2 werkweken 

4 werkweken

Black box
Grey box
White Box

Klasse 1 en 2
(Vertrouwelijkheid en/of
Integriteit)

Minstens 1 keer per 2 jaar

 4 werkweken

8 werkweken

 

Grey box
White Box

 

Welke tools?

  • Bij voorkeur gebeurt deze test door een gecertifieerd tester. Deze tester kan zelf bepalen welke tools nodig zijn om het gewenste resultaat te behalen 

  • Dit is een dienst die de Vlaamse overheid op dit moment alleen inkoopt en waarvoor geen interne medewerkers voorzien zijn

  • Dit is een dienst die je kunt afnemen binnen het raamcontract

 

Scope?

  • Alle online toepassingen

  • Alle websites

  • Alle intern ontsloten toepassingen (enkel toegankelijk voor geauthenticeerde gebruikers op het Vlaamse overheid-netwerk)

  • Dit kan gaan om toepassingen of websites in eigen beheer, die van de centrale dienstverlening,of die bij een leverancier 

Opmerking
Red & Blue teaming (samen ook wel Purple Teaming genoemd), is nog niet opgenomen in dit Beleidsdocument. De bedoeling van deze oefeningen in om de effectiviteit van een SOC of incident response team te testen in het geval er een aanval zou zijn. Het is dus het uitvoeren van een fictieve aanval. Entiteiten die deze oefeningen al willen uitvoeren, kunnen dit uiteraard doen in overleg met de nodige teams en instanties

Opmerking
Red & Blue teaming (samen ook wel Purple Teaming genoemd), is nog niet opgenomen in dit Beleidsdocument. De bedoeling van deze oefeningen in om de effectiviteit van een SOC of incident response team te testen in het geval er een aanval zou zijn. Het is dus het uitvoeren van een fictieve aanval. Entiteiten die deze oefeningen al willen uitvoeren, kunnen dit uiteraard doen in overleg met de nodige teams en instanties