| Note |
|---|
Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:
|
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.
...
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
...
Hoedanigheid/ | Frequentie | Kritische, Significante | Gemiddelde en | Kleine risico kwetsbaar-heden oplossen binnen | Soort test |
|---|---|---|---|---|---|
Toepassingen die | Bij de release van een | 2 werkweken | 4 werkweken | Opnemen in een volgende release | Black box |
Klasse 3, 4 en 5 (Vertrouwelijkheid en/of | Bij de release van een | 2 werkweken | 4 werkweken | Opnemen in een volgende release | Black box |
Klasse 1 en 2 | Minstens 1 keer per 2 jaar | 4 werkweken | 8 werkweken | Opnemen in een volgende release | Grey 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 5.5. Minimale maatregelen - proces risicobeheer 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
...
Opmerking |
|---|