Testen van technische veiligheidsmaatregelen

Of het nou de dienstverlening of de bedrijfsvoering van de organisatie betreft, de betrouwbaarheid van de informatiesystemen in jouw organisatie is cruciaal. Door een securitytest te doen, krijg je inzicht in de kwetsbaarheden en de risico’s van zo’n informatiesysteem. Daarmee is ‘testen’ een noodzakelijk onderdeel van goed risicomanagement. Maar welk doel heb je eigenlijk met testen? En welke securitytest is daarvoor de beste keuze? Waarop moet je letten als je een leverancier inhuurt en hoe borg je de resultaten? Deze publicatie leidt je daar naartoe.

Over deze publicatieDeze publicatie is een herziene versie van een eerdere whitepaper over dit onderwerp die het NCSC heeft gepubliceerd in 2019. Aan de oorspronkelijke whitepaper Securitytesten hebben verschillende organisaties bijgedragen uit zowel het publieke als private domein. 

Doelgroep: 

Deze publicatie 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 deze publicatie 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.

Wat verstaan we onder een securitytest?

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 NIS2/Cyberbeveiligingswet. De daarin genoemde zorgplicht voor essentiële entiteiten en het melden van beveiligingslekken, maken periodiek testen essentieel.

De publicatie die nu voor je ligt, 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.

In deze publicatie leggen we 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 deze publicatie volledig op technisch vlak, daarvoor is het testaanbod te groot. In deze publicatie bespreken we wel 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 van deze publicatie kunnen bespreken.

Wat je met deze publicatie in handen hebt, zijn de handvatten voor een door jou in te richten proces, dat bij jouw organisatie past. We bieden je de stappen die je doorloopt om vanaf het doel dat je hebt, de juiste test te kiezen, een leverancier daarvoor te zoeken en de resultaten te borgen.

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 deze publicatie 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:

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:

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

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.

In de onderstaande paragrafen geven we handvatten om een leverancier te selecteren en welke afspraken je moet maken voordat deze een test uitvoert.

We verwijzen je hier ook graag naar een andere publicatie van het NCSC 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.

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

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.

Checklists