Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Aanpassingen ICR3 - update links - toevoeging Warning Banner
Note

Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:

  • Nieuw toegevoegde tekst wordt overal in het rood weergegeven

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.). 

Een penetratietest is het strikte minimum dat je kunt en moet doen aan veiligheidstesten. Deze test gaat heel wat kwetsbaarheden opvangen die de hierboven beschreven testen ook identificeren. Het is geen 1-op-1 vervanging ervan en het is een kostelijkere manier om hetzelfde te bereiken. Hoe vroeger je kwetsbaarheden identificeert, hoe makkelijker en goedkoper je ze kunt oplossen. Dit doe je door security (en bij uitbreiding privacy) standaard in je design mee te nemen – algemeen heet dit Security/Privacy by Design. Dit concept en hoe je dit kunt meenemen in je levenscyclus, staat ook beschreven in het Beleidsdocument “Ontwikkeling en gebruik van toepassingen”

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 Penetratie testen doe je penetratie testensowieso (ook) in de productieomgeving. 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 te doen?

  • 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 - distributed reflective denial-of-service (DRDoS) 

    • Brute force attack paraatheidBuffer overflow/memory leakattacks (credential stuffing, password spraying, multi-factor authentication bypass) 

    • Memory management flaw attacks (use after free, race conditions, buffer overflow) 

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

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

    • Downgrade attacks die (gebruik maken van verouderde protocollen)

    • Exploit servers

    • Input errorsvalidation

    • Privilege escalation

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

    • Supply chain attacks

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
kwetsbaar-heden
oplossen binnen

Gemiddelde en
Kleine risico
kwetsbaar-heden
oplossen binnen

Kleine risico kwetsbaar-heden oplossen binnen

Soort test

Toepassingen die
persoons-gebonden
informatie bevatten
(ongeacht de klasse)

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

2 werkweken 

4 werkweken

Opnemen in een volgende release

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

Opnemen in een volgende release

Black box
Grey box
White Box

Klasse 1 en 2
(Vertrouwelijkheid en/of
Integriteit)

Minstens 1 keer per

2

jaar

 4 werkweken

8

6 werkweken

Opnemen in een volgende release

Grey box
White Box

Je maakt een risico-afweging van de gevonden kwetsbaarheden

...

. Hierbij hou je rekening met het feit of een toepassing naar het internet ontsloten is. Als deze toepassingen kwetsbaarheden hebben, los je deze altijd prioritair op en dit ongeacht hun informatieclassificatie

...

. De gegeven termijnen zijn maxima. Je kunt dus bijvoorbeeld een “fix” in een volgende release van je toepassing integreren, zolang deze binnen de verwachte oplostermijn past

...

. Het streefdoel is dat je zoveel mogelijk kwetsbaarheden oplost in de mate van hetfinancieel/projectmatig haalbare volgens het hierboven beschreven schema

...

. Als er na de remediëring nog rest-risico’s zijn, moet de toepassingsbeheerder deze formeel laten aanvaarden door het top management, zoals beschreven staat

...

in https://vlaamseoverheid.atlassian.net/wiki/x/R5MHpwE

...

. Na het oplossen van kwetsbaarheden, moet je altijd een nieuwe test doen om er zeker van te zijn dat de kwetsbaarheden in productie opgelost zijn

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 

...

Opgelegde beperkingen? 

Penetratietesten dienen net zoals de vulnerability scans zorgvuldig te worden uitgevoerd om de veiligheid van systemen te testen zonder de operationele werking in gevaar te brengen. Deze testen mogen op geen enkel moment de primaire systeemfuncties verstoren. De stabiliteit, beschikbaarheid en prestaties van de systemen moeten te allen tijde gewaarborgd blijven. 

Bij penetratietesten, die standaard op afstand worden uitgevoerd, moeten de nodige voorzorgsmaatregelen worden getroffen om datalekken te voorkomen, met name wanneer er gevoelige gegevens worden verwerkt. Dit houdt in dat: 

  • Alle gegevens die tijdens de test worden verwerkt, versleuteld moeten zijn. 

  • Toegang tot systemen en gevoelige informatie strikt beperkt wordt tot geautoriseerde testers. 

  • Log- en monitoringsystemen ingezet worden om ongeautoriseerde toegang te detecteren en te voorkomen. 

  • Penetratietesten buiten piekuren plaatsvinden om de impact op de operationele continuïteit te minimaliseren. 

De resultaten van penetratietesten moeten vertrouwelijk worden behandeld, en er moet een duidelijke follow-upstrategie zijn voor het aanpakken van gedetecteerde kwetsbaarheden zonder de dagelijkse werking van het systeem te verstoren.