Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
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.

...

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 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 op de pagina 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

...