Een security assessment laat zien waar je organisatie echt kwetsbaar is. Niet op papier, maar in de praktijk. Je ontdekt welke systemen risico lopen en welke zwakke plekken direct aandacht vragen.

Wat is een security assessment?

Veel organisaties gebruiken de term security assessment alsof het ‘gewoon’ een scan is. Dat is te kort door de bocht. Je beoordeelt risico’s, beveiligingsmaatregelen, technische kwetsbaarheden en de vraag wat er gebeurt als iemand een zwakke plek ook echt misbruikt.

Daarmee zit je al snel op het snijvlak van risicoanalyse, technische toetsing en besluitvorming. Dat is ook precies waarom dit onderwerp relevant is voor IT-teams, management en securityprofessionals. Je wilt niet alleen weten wat er mis is. Je wilt vooral weten wat eerst moet.

Werk je aan webbeveiliging, dan raakt dit ook onderwerpen als XSS, security headers en een stevig WordPress-beveiligingsbeleid. Een assessment helpt om te bepalen waar die maatregelen het hardst nodig zijn.

Waarom veel assessments weinig opleveren

De grootste fout zit meestal niet in de techniek. Die zit in de aanpak. Veel organisaties willen direct testen, scannen en rapporteren. Daardoor slaan ze de voorbereiding over. Het resultaat is voorspelbaar. Een lang rapport met veel bivindingen. Punt.

Drie problemen komen steeds terug:

• de scope is te breed of juist vaag
• er is geen compleet overzicht van assets en eigenaren
• bevindingen worden niet vertaald naar een herstelplan

Dan krijg je dus wel output, maar geen grip. En grip is juist het hele doel van een security assessment.

Begin met scope

Een assessment start met afbakening. Je moet vooraf bepalen wat je wilt bereiken, welke systemen in scope zitten, welke testmethoden zijn toegestaan en wie beslist als er iets ernstigs boven tafel komt. Dat klinkt bestuurlijk, maar het voorkomt juist chaos tijdens de uitvoering.

Vragen die je vooraf moet beantwoorden

• Wat is het doel van de assessment?
• Welke systemen, applicaties en omgevingen neem je mee?
• Test je alleen detectie en configuratie, of ook misbruikbaarheid?
• Wie is eigenaar van elk domein of systeem?
• Welke downtime of testimpact is acceptabel?
• Wanneer is het traject voor jou geslaagd?

Juist hier gaat het vaak mis bij middelgrote organisaties. Alles komt in scope, waardoor niets meer scherp is. Dan test je te breed en leer je te weinig.

Bron: Riskpal

Asset-inventarisatie (vaak onderschat)

Je kunt geen serieuze security assessment uitvoeren zonder te weten wat je precies hebt staan. Toch ontbreekt dat overzicht vaak. Er zijn servers, SaaS-tools, cloudresources, endpoints, API-koppelingen en accounts, maar niemand heeft het totaalbeeld.

Een werkbaar assetoverzicht bevat in elk geval de technische identiteit van een systeem, de eigenaar, de businessfunctie, de data die wordt verwerkt en de mate van exposure. Pas dan kun je bepalen wat een kwetsbaarheid echt betekent.

Wat je per asset minimaal wilt weten

• hostname, IP-adres of cloudresource-ID
• welk team of welke eigenaar verantwoordelijk is
• of het systeem internet-facing is of intern draait
• welke data of processen eraan hangen
• welke accounts, rechten en koppelingen erbij horen
• of logging en monitoring aanwezig zijn

Zonder deze basis wordt prioriteren gokken. Met deze basis wordt prioriteren opeens veel logischer.

Wat is het verschil tussen een assessment, vulnerability assessment en pentest?

Deze begrippen worden vaak op één hoop gegooid, maar dat zorgt voor verkeerde verwachtingen.

Security assessment

Dit is de brede variant. Je kijkt naar risico, maatregelen, technische zwaktes, detectie en opvolging. Het doel is betere besluitvorming.

Vulnerability assessment

Hier ligt de focus op het vinden en ordenen van kwetsbaarheden. Vaak gebeurt dat met scanners, configuratiecontroles en beperkte verificatie.

Pentest

Een penetratietest gaat verder. Dan wordt actief gevalideerd of een kwetsbaarheid ook echt misbruikbaar is en wat de schade kan zijn.

De juiste keuze hangt af van je vraag. Wil je breed inzicht. Dan past een security assessment. Wil je laten zien of een aanvaller echt binnen kan komen. Dan kom je sneller uit bij een pentest.

Niet elk systeem vraagt dezelfde testdiepte

Een veelgemaakte fout is dat organisaties elk systeem hetzelfde behandelen. Dat werkt niet. Een publiek bereikbare klantportal vraagt een andere aanpak dan een intern testsysteem. Een identity-platform verdient meer aandacht dan een losse demo-VM. En een OT-omgeving vraagt vaak terughoudendheid, omdat beschikbaarheid daar zwaarder weegt.

De vraag is dus niet alleen: wat is kwetsbaar? De echte vraag is: waar doet een kwetsbaarheid het meeste pijn?

• Hoge exposure en hoge schade. Diep testen en strak opvolgen.
• Lage exposure maar hoge schade. Focus op hardening, rechten en logging.
• Hoge exposure maar lagere schade. Patchen, configureren en basisbeveiliging op orde brengen.

Zo ziet een volwassen assessment eruit

Een volwassen assessment bestaat uit meerdere lagen. Niet omdat dat indrukwekkend staat, maar omdat één methode nooit genoeg beeld geeft.

1. Voorbereiding

Je bepaalt scope, contactpersonen, rules of engagement, kritieke systemen en testvensters.

2. Dataverzameling

Je haalt configuraties, logs, architectuurinformatie, IAM-data en assetinformatie op. Zonder bewijs wordt een bevinding al snel een discussiepunt.

3. Technische toetsing

Hier gebruik je scans, handmatige controles en waar nodig selectieve validatie. Voor webapplicaties sluiten teams vaak aan op de OWASP WSTG en voor ontwikkel- en controledoelen op de OWASP ASVS.

4. Prioritering

Bevindingen worden niet alleen gescoord op technische ernst, maar ook op misbruikkans, exposure en bedrijfsgevolg.

5. Rapportage en herstel

Een bruikbaar rapport vertaalt technische bevindingen naar acties. Wie moet wat oplossen. Binnen welke termijn. En hoe toon je aan dat het echt is opgelost.

Waarom CVSS alleen niet genoeg is

Veel teams kijken eerst naar CVSS. Dat is logisch, maar niet genoeg. CVSS zegt iets over de technische ernst van een kwetsbaarheid. Het zegt niet automatisch of die kwetsbaarheid ook actief wordt misbruikt, hoe bereikbaar het systeem is en hoeveel schade jouw organisatie oploopt als het misgaat.

Daarom is het slimmer om meerdere signalen te gebruiken. Denk aan CVSS voor ernst, EPSS voor kans op exploitatie in de praktijk en de CISA KEV-catalogus voor kwetsbaarheden waarvan bekend is dat ze al actief zijn misbruikt.

Juist die combinatie helpt om weg te blijven van paniek om het verkeerde issue en vertraging bij het juiste issue.

Een praktisch model voor prioriteit

Voor veel organisaties werkt een simpel model beter dan een ingewikkelde scorekaart. Kijk per bevinding naar vier onderdelen:

• technische ernst. Hoe zwaar is de kwetsbaarheid technisch gezien?
• misbruikbaarheid. Is er zicht op actief misbruik of hoge kans daarop?
• exposure. Is het systeem internet-facing, partner-facing of intern?
• bedrijfsgevolg. Wat gebeurt er bij uitval, dataverlies of misbruik?

Dat levert vaak betere keuzes op dan blind varen op één score. Een middelzware kwetsbaarheid op een publiek identity-systeem kan voor jouw organisatie veel gevaarlijker zijn dan een hoge score op een intern labplatform.

Rapportage moet leiden tot actie

Een security assessment is niet klaar zodra het rapport verstuurd is. Dat is juist het moment waarop het echte werk begint. Elke finding moet gekoppeld zijn aan een eigenaar, een deadline, een herstelactie en een manier om de fix later te controleren.

Wat een finding minimaal moet bevatten

• titel en unieke referentie
• geraakte systemen of assets
• bewijs van de bevinding
• uitleg van het aanvalspad in gewone taal
• prioriteit en onderbouwing
• aanbevolen fix
• eigenaar en planning
• plan voor hertoetsing

Daar sluit ook incident response op aan. Want als je tijdens een assessment iets ernstigs ontdekt, moet duidelijk zijn hoe je organisatie reageert. Lees daar meer over in de vijf stappen van cyber security incident response.

Voorkom dit bij security assessments

• te veel systemen tegelijk in scope zetten
• geen eigenaar koppelen aan bevindingen
• scanresultaten zonder handmatige controle overnemen
• rapporteren zonder herstelplan
• wel severity noemen, maar geen businesscontext
• geen hertoetsing uitvoeren na fixes
• logging en detectie vergeten mee te nemen

Vooral dat laatste zie je vaak. Een kwetsbaarheid oplossen is één ding. Zien dat iemand dezelfde route probeerde te misbruiken is minstens zo belangrijk. Daarom hoort detectie ook thuis in een volwassen assessment. Denk aan logverzameling, alerts en waar passend een SIEM-aanpak.

Slotwoord

Een security assessment is geen vinklijst en ook geen rapport om indruk mee te maken. Het is een hulpmiddel om betere keuzes te maken. Welke systemen verdienen direct aandacht. Welke kwetsbaarheden zijn echt gevaarlijk. Waar moet je team nu aan werken. En hoe bewijs je later dat het risico echt kleiner is geworden.

Wie het strak aanpakt, begint met scope, bouwt daarna op asset-inzicht, toetst gericht, prioriteert op echte risico’s en eindigt pas na herstel en hertoetsing. Dan wordt een assessment geen papieren oefening, maar een stuurmiddel voor beveiliging.

Bronnen

• NIST SP 800-30
• NIST SP 800-115
• NIST Cybersecurity Framework 2.0
• CISA KEV Catalog
• CVSS
• EPSS
• OWASP WSTG
• OWASP ASVS