Testen van technische veiligheidsmaatregelen
Doelgroep:
Dit artikel is voor mensen in de organisatie die willen testen of de technische beveiligingsmaatregelen die zij hebben getroffen om hun digitale risico’s te mitigeren, de organisatie afdoende beschermen. We gaan er in dit artikel dus vanuit dat je al een of meer technische beveiligingsmaatregelen hebt getroffen die jouw informatiesystemen dienen te beschermen.
Voorbeelden:
- Een security officer wil inzicht in de kwetsbaarheden van zijn ict-landschap.
- Een projectleider wil het beveiligingsniveau van een informatiesysteem weten en in hoeverre aan de beveiligingseisen wordt voldaan.
- Een applicatie-eigenaar wil aantonen dat een applicatie geen bekende kwetsbaarheden bevat.
Definitie:
Een securitytest is een middel om de kwaliteit van een specifieke of meerdere beveiligingsmaatregelen te onderzoeken op kwetsbaarheden.
Een securitytest biedt een bepaalde mate van zekerheid maar geen absolute garanties dat jouw beveiligingsmaatregelen goed functioneren. Iedere tester pakt het op zijn manier aan en niet iedere kwetsbaarheid is altijd vindbaar. Nieuwe kwetsbaarheden die nog niet bekend waren tijdens een test, vindt hij of zij lang niet altijd meteen. Er zijn bovendien altijd weer verbeteringen mogelijk. Testen is idealiter onderdeel van een kwaliteitscyclus en geen check achteraf. Wanneer pas na het afronden van een ontwikkelproces aandacht is voor security, levert een securitytest soms vervelende verrassingen en vertragingen op.
Achtergrond
Voor kwetsbaarheden en bijbehorende risico’s hebben veel organisaties de nodige mitigerende maatregelen getroffen. Met een securitytest toets je de kwaliteit van een specifieke of meerdere beveiligingsmaatregelen. De testmarkt is echter groot en heterogeen, het is niet gemakkelijk daarin de juiste keuze te maken. Voor iedere aanleiding en doel en voor ieder proces is er wel een test op de markt.
De aanleiding om te willen testen zijn vaak grote veranderingen in de ict-infrastructuur van een organisatie. Of je nou inzicht wilt in de kwetsbaarheden van het ict-landschap, wilt weten of een dienst of product tegen bepaalde dreigingen bestand is, of een aangeschafte applicatie of product geen bekende kwetsbaarheden bevat: een securitytest ligt in deze situaties voor de hand.
Ook het adopteren van een securitystandaard waarin een securitytest, bijvoorbeeld periodiek, is voorgeschreven vormt vaak een aanleiding. Net als wet- en regelgeving. Voorbeeld van dat laatste is de Cyberbeveiligingswet (NIS2). De daarin genoemde zorgplicht voor essentiële entiteiten en het melden van beveiligingslekken, maken periodiek testen essentieel.
Dit artikel gaat je ondersteunen bij het bepalen van de scope en de diepte van de test voor het door jou opgestelde doel. We bieden een overzicht op hoofdlijnen van veelgebruikte testmethoden en in het verlengde daarvan bieden we je de vragen waarmee je een goede leverancier kiest bij het doel dat je hebt.
We leggen de focus op de technische beveiligingsmaatregelen die je als organisatie hebt getroffen. Bij testen kun je echter ook denken aan het testen of processen goed zijn ingericht, bijvoorbeeld een crisismanagement-proces of coordinated vulnerability disclosure. Ook kun je testen of de mensen in jouw organisatie phishing herkennen of bestand zijn tegen social engineering of weten hoe om te gaan met mensen die zich ongenodigd fysieke toegang tot de werkplek hebben verschaft. Over het testen van processen, social engineering en fysieke toegang gaat deze publicatie echter niet. Evenmin zijn we in dit artikel volledig op technisch vlak, daarvoor is het testaanbod te groot. Wel bespreken we enkele typen tests op hoofdlijnen. Realiseer je dat er (veel) meer mogelijk is op het vlak van testen en wat je wilt testen dan wij in het korte bestek kunnen bespreken.
Stap 1: Bepaal het doel en formuleer onderzoeksvragen
Voordat je begint met het kiezen van een test, bepaal je het doel. We gaan er in deze publicatie vanuit dat de organisatie al bepaalde beveiligingsmaatregelen heeft genomen om kwetsbaarheden en bijbehorende risico’s te mitigeren. Het NCSC adviseert dat te doen op basis van te beschermen belangen, dreigingen daarvoor, kwetsbaarheden en risico’s. Doordat een test vaak beperkt is in tijd, is het belangrijk dat de uit te voeren tests passen bij de specifieke zorgen die je hebt over de te beschermen belangen en de risico’s die daarbij een rol spelen. Tests voer je uit op de technische beveiligingsmaatregelen die juist die belangen moeten beschermen.
Vragen die je helpen om het doel te bepalen:
- Wat wil je realiseren met een securitytest?
- Welke beveiligingsmaatregel(en) wil je doorlichten?
- Welke inzichten heb je nodig?
Wees concreet in je doelstelling
Bedenk vooraf welke beveiligingsmaatregel je wilt testen. Met een te brede of vage scope loop je het risico dat de test ofwel te kostbaar wordt, ofwel te weinig diepgang kent.
Wees zo concreet mogelijk bij het omschrijven van het doel van de securitytest en doe dat in de vorm van een onderzoeksvraag.
Een te algemeen geformuleerde onderzoeksvraag is: is onze bedrijfsgeheime informatie veilig? Er zijn namelijk heel veel manieren waarop een aanvaller die informatie buit kan maken. Denk aan het misbruiken van kwetsbaarheden in technische beveiligingsmaatregelen, maar ook social engineering of het stelen van klantgegevens. Andere onderzoeksvragen die een te brede of vage scope hebben (of niet over een technische beveiligingsmaatregel gaan en dus buiten de scope van dit artikel vallen) zijn:
- Is mijn organisatie vatbaar voor ransomware?
- Is het autorisatiebeleid op orde voor vertrouwelijke informatie?
- Functioneert het incidentresponseteam wel als er een incident is?
Onderzoeksvragen of doelen moet je dan ook concreet en specifiek formuleren.
Goede onderzoeksvragen voor een securitytest gericht op technische beveiligingsmaatregelen:
- Is mijn applicatie veilig afgeschermd van de buitenwereld? Lees: veilig geconfigureerd?
- Is mijn informatiesysteem goed afgeschermd? Lees: zijn er geen openstaande poorten en dergelijke?
- Bevat mijn broncode veelvoorkomende kwetsbaarheden?
Stap 2: Bepaal wat en hoe je gaat testen
Als je een specifieke onderzoeksvraag hebt gedefinieerd, heb je vervolgens de keuze welke elementen van jouw informatiesysteem onderdeel zijn van de testscope, welke test daarvoor geschikt is en hoeveel informatie je de tester vooraf wilt geven.
Bepaal de scope van je test
De inbreng van de systeemeigenaar, architect, technisch specialist en securityspecialist heb je nodig om de scope van jouw test in kaart te brengen. Geef hierbij ook aan wat niet in de scope zit van de test zodat de uitvoerders van de test geen verkeerde aannames kunnen doen. Denk aan:
Externe infrastructuur
De infrastructuur (ip-reeksen, VPN, firewalls) die vanaf het internet beschikbaar is. Alle kwaadwillenden kunnen deze bereiken.
Interne infrastructuur
Dit is de infrastructuur die achter de beschermende laag van bijvoorbeeld een VPN of firewall zit. Dit is ook belangrijk om te testen en defense-in-depth toe te passen. Wanneer een kwaadwillende door de VPN of firewall heen is, hoe ver kan deze dan het netwerk binnendringen en wat kan de eigenaar hiertegen doen? Ook een ontevreden werknemer die kwaad wil heeft dit uitgangspunt.
Applicatiecode
De programmacode die een taak uitvoert, zoals een webapplicatie, script, mobiele applicatie of speciaal programma.
Stap 3: Bepaal de beste test voor het doel dat je hebt
De derde stap is bepalen welke test het beste past bij jouw doel en scope. In het kader van het testen van technische beveiligingsmaatregelen bespreken we hier drie soorten tests/scan: Een kwetsbaarhedenassessment, een penetratietest en broncodereview.
Met een kwetsbaarhedenscan scan je op bekende kwetsbaarheden en ontbrekende patches. Ook zwakke securityconfiguraties zoals standaardwachtwoorden of onvoldoende encryptie, onveilig ingestelde netwerkservices, veelvoorkomende webapplicatie-issues of informatielekken, laat deze securitytest zien.
Bij een penetratietest (ook wel pentest) kruipt een daarvoor getrainde pentester in de rol van aanvaller. Hij zoekt naar kwetsbaarheden en probeert deze uit te buiten. Hierbij maakt de pentester gebruik van uiteenlopende tools en procedures. Waar een kwetsbaarhedenassessment een scan is in de breedte is, gaat een pentest de diepte in.
Bij een broncodereview inspecteert een expert de broncode van een applicatie met als doel kwetsbaarheden in die broncode te ontdekken. Het is een systematisch onderzoek naar programmeerfouten die tijdens de ontwikkeling over het hoofd zijn gezien. Een goede broncodereview vereist specifieke kennis van en vaardigheden in de gebruikte programmeertalen, frameworks, externe componenten en afhankelijkheden. Geautomatiseerde statische analyses, compositieanalyses en handmatige reviews zijn vaak onderdeel van een broncodereview.
Stel jezelf de volgende vragen om een passende test te selecteren:
Een kwetsbaarheidsassessment en pentest richten zich primair op de infrastructuur van jouw netwerk. Een broncodereview richt zich op de applicatiecode. Kies een test die past bij jouw doel.
Een security-test is een time-boxed activiteit, waarin de tester jouw infrastructuur of code onderzoekt in een bepaald tijdsbestek op best-effort basis. Met een vulnerability- of kwetsbaarhedenassessment dringt de securitytester de systemen niet binnen, wat snelheid in het proces brengt. Zo ben je snel (en goedkoper) op de hoogte van kwetsbaarheden die van toepassing zijn op de onderzochte systemen. Een penetratietest en broncodereview zullen doorgaans meer tijd en budget vergen.
De verschillende testen realiseren verschillende inzichten. Een kwetsbaarheidsassessment wijst doorgaans niet uit welke gevolgen een kwetsbaarheid kan hebben voor jouw dienst of organisatie. Als je echter wilt weten of en in hoeveel schade de kwetsbaarheid kan uitmonden, is een pentest op zijn plaats. Als opdrachtgever weet je vervolgens of een kwaadwillende daadwerkelijk schade kan aanrichten met de gevonden kwetsbaarheid. Een pentest is doorgaans ook geschikter voor het vinden van onbekende kwetsbaarheden.
We adviseren je om te starten met een kwetsbaarhedenassessment en het verhelpen van de bevindingen die hieruit voortkomen. Heb je als organisatie nog geen kwetsbaarhedenassessment uitgevoerd dan kan een pentest minder effectief zijn. De kwetsbaarheden had je waarschijnlijk ook kunnen vinden en verhelpen met een (laagdrempeliger) kwetsbaarhedenassessment.
Lees meer over kwetsbaarheden beheer in de NCSC publicatie Verbeter je kwetsbaarhedenbeheer.
en zie ook CIS Control 20: Procedures and Resources: https://www.cisecurity.org/controls/cis-controls-list/
Bepaal hoeveel informatie je vooraf aan de securitytesters geeft
Als opdrachtgever geef je de testers informatie voorafgaand aan de test. De mate waarin je dat doet, is afhankelijk van vanuit welk perspectief de test plaatsvindt.
Stel jezelf de volgende vragen
Zonder informatie vooraf weet de tester niets. Dit heet black-box-testen. Je geeft bijvoorbeeld alleen een ip-adres, domeinnaam of bedrijfsnaam. Dit komt overeen met de informatie die een aanvaller zou hebben die zich niet expliciet richt op jouw organisatie. Afhankelijk van jouw test kan de tester extra informatie opzoeken middels OSINT (Open Source Intelligence, waarbij gezocht wordt naar openbaar beschikbare informatie via bijvoorbeeld zoekmachines).
Als de tester gedeeltelijke informatie vooraf heeft, bijvoorbeeld inloggegevens van een gebruiker met een bepaalde rol binnen het systeem, dan spreken we van een grey-box-test. Zo test je wat een aanvaller kan bereiken als hij al bepaalde rechten in een systeem heeft verworven. Een ander voorbeeld van een grey box is een tester toegang tot jouw interne netwerk geven om te testen hoe ver hij kan komen als hij de eerste beschermingslaag van jouw netwerk weet te passeren.
Een tester met veel informatie voorafgaand aan de test, noemen we een white-box-test. Denk aan ontwerpdocumentatie, inloggegevens, voorbeeldberichten en broncode, ook als er geen broncodereview wordt uitgevoerd.
Stap 4: Selecteer een geschikte opdrachtnemer
Je hebt nu aan de ene kant bepaald welk doel je voor ogen hebt met de test, welk informatiesysteem je wilt testen en welke test daarvoor geschikt is en je hebt aan de andere kant bepaald hoeveel informatie je de tester wilt meegeven. Op basis van jouw keuzes in bovenstaande mogelijkheden ben je in staat om een leverancier te zoeken.
Er zijn veel leveranciers die dezelfde soort test aanbieden. Er is helaas nog geen eenduidigheid in de markt over wat precies wordt onderzocht, hoe daarover gerapporteerd wordt en wat daarmee bewezen wordt. Leveranciers kunnen zich wel al laten certificeren volgens het CCV-certificatieschema Cybersecurity Pentesten. Meer informatie hierover kun je vinden op: Pentesten – Het CCV.
Wij adviseren om niet over een nacht ijs te gaan maar je goed te oriënteren, onder meer door een marktverkenning te doen en door het voeren van kennismakingsgesprekken. Dat is mede belangrijk omdat een leverancier tijdens een test in aanraking komt met verschillende zaken die gevoelig zijn voor jouw organisatie. Denk aan de toegang tot jouw infrastructuur en broncode, maar ook zicht op de kwetsbaarheden daarin. Het opbouwen van vertrouwen in de leverancier en het maken van passende afspraken is daarom belangrijk.
We verwijzen je ook graag naar een andere artikel die over Uitbesteden gaat.
Maak kennis met potentiële leveranciers
Houd een kennismakingsgesprek met een of enkele potentiële opdrachtnemers. Doe dit face-to-face, vanwege de gevoeligheid van de te delen informatie maar ook vanwege de samenwerkingsrelatie. Of er, met andere woorden, een klik is. De leverancier/opdrachtnemer heeft in dit gesprek ook de kans om uitgebreider in te gaan op verwachtingen van jou/de opdrachtgever en de omvang van het te testen informatiesysteem.
In Checklist A geven we je een aantal vragen die je kunt stellen tijdens kennismakingsgesprekken. Gebruik deze naar eigen inzicht om een beeld te vormen van de leveranciers.
Voer een intakegesprek
Is de kennismaking naar tevredenheid verlopen en heb je een keuze gemaakt voor een bepaalde leverancier, houd dan een intake (vervolggesprek) om nadere afspraken te maken. Het hoofddoel van de intake is het verzamelen van de benodigde informatie, zodat de opdrachtnemer zijn voorstel (offerte of plan van aanpak) kan maken.
Tijdens een intake bespreek je altijd een aantal gevoelige zaken.
- een eventuele geheimhoudingsverklaring waarmee de betrokken partijen akkoord dienen te gaan als maatregel tegen het uitlekken van gevoelige informatie
- afspreken en vastleggen hoe je wilt omgaan met bevindingen die in aanmerking komen voor coordinated vulnerability disclosure (cvd)
- over het verwerken van persoonsgegevens afspraken maken. Het kan immers zijn dat bij het uitvoeren van de opdracht persoonsgegevens worden verwerkt door de leverancier, waarvoor jij verantwoordelijk bent. Volgens de AVG ben je in dat geval verplicht daarover afspraken te maken.
- een vrijwaringsclausule om de leverancier comfort te bieden bij de uitvoering van de opdracht. Het uitvoeren van een pentest kan immers het betrokken systeem verstoren, waardoor schade kan ontstaan. Het is niet wenselijk om pas over een vrijwaring na te denken wanneer de schade zich al heeft voorgedaan.
- protocollen afspreken voor veilige communicatie, opslag en verwijdering van gegevens, en verspreiding van de rapportage, zodat de informatie en discussies rondom de test niet in de openbaarheid komen.
In Checklist B vind je een aantal onderwerpen die je tijdens het intakegesprek bespreekt met de leverancier.
Stap 5: Faciliteer en voer de regie
Testers op de juiste manier faciliteren is een randvoorwaarde voor een goede testuitvoering. Met een gedegen voorbereiding voorkom je dat tests moeten worden uitgesteld of bepaalde resultaten niet worden behaald
- Zorg voor een securitytestbegeleidersrol: een medewerker/collega die de testers opvangt en ervoor zorgt dat er een korte lijn tussen de testers en de opdrachtgever bestaat. Zo kun je snel zaken ophelderen. Dit helpt bijvoorbeeld om workarounds voor onvoorziene omstandigheden snel af te spreken en zo onnodig oponthoud te voorkomen.
- Betrek de medewerkers van jouw organisatie, zoals systeem- en/of netwerkbeheerders, door frequente updates te geven van bevindingen en voortgang.
- Zorg dat de juiste werkplekken voor de testers zijn ingericht met netwerkverbinding, tenzij testers geen informatiesysteem van buitenaf hoeven benaderen.
- Zorg dat de juiste omgevingen beschikbaar zijn tijdens de test en er niet gelijktijdig andere activiteiten plaatsvinden, zoals grote wijzigingen, back-up- en restore-acties of andere tests die de resultaten kunnen beïnvloeden.
- Licht stakeholders in over de aanstaande test. Denk aan het datacenter en identityproviders.
In checklist C vind je een gedetailleerder overzicht van de zaken die je moet regelen of onderhouden om de test beheerst uit te laten voeren.
Stap 6: Borgen van de resultaten
Met de resultaten van de securitytest wil je de organisatie natuurlijk verbeteren. Betrek daarom tijdig de juiste stakeholders, niet alleen aan het begin van de securitytest maar ook wanneer de oplevering nadert. Bijvoorbeeld door een face-to-face-bijeenkomst te organiseren waar je de bevindingen doorspreekt voordat de definitieve oplevering plaatsvindt.
De impact van de (technische) bevindingen op de business, de oorzaken ervan en de moeite om het op te lossen, heb je nu helder. Zorg ervoor dat de betrokkenen het verslag kunnen lezen.
Plan snel na oplevering een evaluatie in
Plan kort na de oplevering van de resultaten een evaluatie in met de betrokkenen, zodat je gebruikmaakt van het momentum van de securitytest. Wacht hiermee niet te lang, dan loop je het risico dat er nooit meer iets mee gebeurt door overige prioriteiten in het dagelijks werk van de betrokkenen.
Denk aan de volgende vragen voor de evaluatie:
- Zijn deze resultaten conform afspraken over kwaliteit (diepgang, argumentatie, bewijzen)?
- Zijn de resultaten zelf een verrassing voor de organisatie?
- Welke conclusie kan getrokken worden uit de bevindingen en achterliggende oorzaken?
Borg de verbeteringen
De organisatie heeft baat bij duidelijke verbeterpunten. Of het nou de externe of interne infrastructuur betreft, wat je hebt uitbesteed of dat op applicatieniveau verbeteringen mogelijk zijn.
Verduidelijk daarom op welke componenten van het informatiesysteem de bevindingen van toepassing zijn en welke partijen daarvoor verantwoordelijk zijn. Zie erop toe dat de bevindingen worden neergelegd waar de verantwoordelijkheid ligt, zowel binnen als buiten de organisatie. Communiceer daarover en houd de afhandeling bij. Borg dit in een proces.
Registreer de bevindingen uit securitytestrapportages bijvoorbeeld in servicemanagementpakketten die de organisatie al gebruikt. Dit kun je ook gebruiken om erop toe te zien dat actiepunten worden uitgevoerd.
Zoek aansluiting bij het overkoepelende risicomanagementproces om je bevindingen optimaal te borgen in de organisatie. Leg vast hoe de organisatie omgaat met eventuele restrisico’s bij het niet of onvolledig opvolgen van de aanbevelingen.
Testen kun je doen als eenmalige activiteit. Bijvoorbeeld als je van een specifieke, nieuwe applicatie wilt weten of de broncode geen fouten bevat. Echter, het verbeteren van de informatiesystemen van de organisatie doe je het beste in een cyclisch verbeterproces. Het klassieke proces van de PDCA-cyclus is plannen (plan), uitvoeren (do), evalueren (check) en bijstellen (act). Je hebt in deze publicatie deze processtappen of fasen doorlopen. Omdat het een cyclisch proces is, ben je na het doorvoeren van de verbeteringen weer bij plannen aanbeland. Hieraan geef je invulling door een hertest te plannen voor de veiligheidsmaatregel die je hebt verbeterd of wellicht is nu een ander informatiesysteem aan de beurt.
Checklists
Wil je weten hoe de leverancier te werk gaat? Maak dan gebruik van de volgende vragen:
- Hoe flexibel is de leverancier in het geval er iets aan jouw kant verandert?
- Welke processen heeft de leverancier ingericht om de testgegevens te beschermen?
- Hoe communiceert de leverancier (in aanloop naar, tijdens en na de test?)
Gebruik de volgende vragen om te onderzoeken hoe vakbekwaam de leverancier is:
- Heeft de leverancier een solide reputatie? Bespreek ook wat je zelf al te weten bent gekomen, een open gesprek is altijd een goed idee
- Heeft de leverancier vakbekwame securitytesters, vaardigheden, referenties; ervaring met te testen technologieën of maatregelen? En garandeert de leverancier dat deze vakbekwame mensen jouw test uitvoeren?
- Wat weet je over de kwaliteit van dienstverlening en toegevoegde waarde?
- Heeft de leverancier kennis van jouw branche of organisatie?
- Wat zijn de research- & developmentcapaciteiten van de leverancier?
- Kan de leverancier een voorbeeldrapportage delen, zodat je een beeld kunt vormen bij het resultaat?
Een intakegesprek houd je nadat je een leverancier hebt gekozen, een geheimhoudingsverklaring hebt laten tekenen en op hoofdlijnen een contract hebt gesloten.
Nader te bespreken dan wel afspraken over maken:
- de tester (persoon) die de test zal uitvoeren. Zorg ervoor dat je vertrouwen hebt in de (vakinhoudelijke bekwaamheid van) deze tester
- doorspreken van het opgestelde securitytestprofiel en initiële opdrachtformulering door de opdrachtgever
- toelichting op de risicoanalyse en uitwerking van de dreigingsanalyse met verdere input van de opdrachtnemer
- verduidelijking van de aanleiding, doelstelling, beoogde resultaten en specifieke onderzoeksvragen en eventuele specifieke (geprioriteerde) aandachtsgebieden binnen de test
- het plan van aanpak van de opdrachtnemer
- uitleg van wat nadrukkelijk wel en niet in scope is
- planning, budget en opleveringsvorm
- eventueel vervolg, planning van de hertest
- de communicatie vooraf, tijdens en na de securitytest. Spreek af dat je direct contact hebt bij urgente bevindingen.
Heb je het volgende geregeld?
- methode van validatie en classificatie van bevindingen
- testen van autorisaties (met en zonder testaccounts, black box, grey box of white box)
- inloggegevens voor de tester
- monitoring van aanvalspogingen
Bespreek hoe je communiceert tijdens het testen. Denk aan:
- frequente updates van bevindingen en voortgang, bijvoorbeeld een korte dagelijkse stand-up
- direct contact bij urgente bevindingen
- afstemming van de prioriteiten als meer tijd dan afgesproken aan een bepaald onderdeel is besteed
- scopewijzigingen tijdens het testen tijdig afstemmen.
Bepaal of de tester toestemming moet hebben voor:
- bruteforce-aanvallen (of bijvoorbeeld alleen offline)
- testen die denial of service (verstoring van de dienstverlening) teweeg kunnen brengen
- testen op productie- of acceptatieomgeving.
Jouw voorbereiding als opdrachtgever heeft potentieel een grote impact op de test.
Hoe wil je als opdrachtgever omgaan met:
- whitelisting van de testers, dat wil zeggen het toestaan van bepaalde verkeersstromen afkomstig van de testers. Dit kan ook tijdens het testen aan bod komen, maar dit moet grotendeels al tijdens de intake en de voorbereidingen bekend zijn.
- scope-wijzigingen tijdens de test: door wijzigingen in scope tijdens de test vanwege nieuwe inzichten, kan het voorkomen dat de test achteraf niet meer volledig de vooraf afgesproken scope dekt
- duidelijkheid over de behoefte aan een hertest (binnen afzienbare tijd na afstemmen bevindingen)
- Rules of Engagement (spelregels van de test).
- beheerders of ontwikkelaars mee laten kijken met de uitvoering van de securitytest zodat zij ervan kunnen leren.
Bij kwetsbaarhedenassessments en penetratietests is het voor de testers vaak onbekend waar blokkerende verdedigingslagen zoals een firewall of IDS zitten. Als je al eerder hebt bepaald dat deze verdedigingslagen niet binnen de scope van de test vallen is het onnodig tijdrovend om dit tijdens de test te omzeilen of ongedaan te maken.