Hoe weet je of een pentest grondig genoeg is uitgevoerd?

Geplaatst op: 8 oktober 2026

Je hebt een pentest laten uitvoeren. Goed gedaan. Maar dan komt de echte vraag: was die test ook grondig genoeg? Een rapport met tientallen bevindingen klinkt indrukwekkend, maar zegt op zichzelf weinig over de werkelijke kwaliteit van de test. Een goede pentest kijkt verder dan bekende kwetsbaarheden en reproduceert hoe een echte aanvaller denkt en handelt. In dit artikel leer je stap voor stap hoe je de kwaliteit van een pentest beoordeelt, zodat je zeker weet of je beveiligingstest daadwerkelijk waarde heeft geleverd.

Wat een grondig pentestrapport moet bevatten

Begin bij het rapport zelf. Een kwalitatief hoogwaardig pentestrapport is meer dan een lijst met gevonden kwetsbaarheden. Het is een gestructureerd document dat je als organisatie in staat stelt om concrete actie te ondernemen. Controleer of het rapport de volgende elementen bevat:

• Een managementsamenvatting die zonder technische kennis leesbaar is en de belangrijkste risico’s helder benoemt
• Een gedetailleerde technische sectie met reproduceerbare bevindingen, inclusief bewijs (screenshots, logs of commando’s)
• Risicoclassificaties per bevinding, met uitleg waarom een kwetsbaarheid als hoog, middel of laag is beoordeeld
• Concrete aanbevelingen per bevinding, niet alleen “patch dit systeem”, maar ook uitleg over de impact als dat niet gebeurt
• Attack paths: een beschrijving van hoe losse zwaktes gecombineerd kunnen worden tot een volledige aanvalsketen

Dat laatste punt is cruciaal. Aanvallers zien geen losse bevindingen. Ze zien aanvalspaden. Een goed rapport laat zien hoe een combinatie van kleine zwaktes, elk onschuldig op zichzelf, kan leiden tot volledige toegang tot kritieke systemen. Ontbreekt die context in het rapport, dan mis je de essentie van wat een professionele pentest onderscheidt van een geautomatiseerde scan.

Controleer de scope en methodologie van de pentest

Een pentest is zo grondig als de afspraken die er vooraf over zijn gemaakt. Bekijk de scope en methodologie kritisch voordat je conclusies trekt uit de resultaten.

1. Controleer welke systemen, netwerken en applicaties zijn meegenomen. Was de scope breed genoeg om realistische aanvalsvectoren te dekken?
2. Vraag of ook externe aanvalsvectoren zijn getest, zoals phishing, supplychaintoegang en identiteitsbeheer
3. Kijk of de test handmatig is uitgevoerd of grotendeels geautomatiseerd. Automatische tools vinden bekende CVE’s, maar missen organisatiespecifieke risico’s zoals te ruime permissies, misconfiguraties in cloudplatformen of zwaktes in identiteitsbeheer
4. Verifieer of de methodologie aansluit op erkende frameworks zoals OWASP, PTES of MITRE ATT&CK

Een veelgemaakte fout is een te smalle scope accepteren. Als alleen de webapplicatie is getest maar de onderliggende cloudinfrastructuur buiten beschouwing is gelaten, heb je een onvolledig beeld. Vraag de uitvoerende partij expliciet te documenteren wat buiten scope viel en waarom.

Beoordeel de diepgang van de gevonden kwetsbaarheden

Het aantal gevonden kwetsbaarheden zegt weinig over de kwaliteit van de pentest. Een goede test vindt niet per se de meeste bevindingen, maar de meest relevante. Beoordeel de diepgang aan de hand van drie lagen:

Laag 1: Bekende kwetsbaarheden

Dit zijn publieke CVE’s, ontbrekende patches en bekende configuratiefouten. Een scanner kan dit vinden. Staan er alleen dit soort bevindingen in het rapport, dan is de test waarschijnlijk grotendeels geautomatiseerd uitgevoerd.

Laag 2: Individuele zwaktes

Denk aan verkeerde Azure-configuraties, te ruime accountrechten, identity weaknesses of onveilige applicatie-instellingen. Deze vereisen handmatig onderzoek en specifieke kennis van de omgeving. Een menselijke tester met offensieve ervaring vindt risico’s die een scanner structureel mist, juist omdat een aanvaller ook kijkt naar organisatiestructuren, leveranciersrelaties en permissies.

Laag 3: Gecorreleerde aanvalspaden

Dit is waar de echte diepgang zit. Vraag jezelf af: beschrijft het rapport hoe meerdere kleine zwaktes samen een gevaarlijk aanvalspad vormen? Een voorbeeld: een SSRF-kwetsbaarheid in combinatie met een managed identity, te ruime Azure RBAC-rechten en toegang tot een Key Vault kan leiden tot volledige controle over een cloudsubscriptie. Elk onderdeel afzonderlijk lijkt misschien laag risico. Samen zijn ze kritiek. Als het rapport dit soort gecorreleerde paden niet beschrijft, ontbreekt de diepste laag van de analyse. Meer over deze aanpak lees je op de pagina over red teaming.

Stel de juiste vragen aan de pentestaanbieder

Een goede manier om de kwaliteit van een pentest te beoordelen, is door gerichte vragen te stellen aan de partij die de test heeft uitgevoerd. Gebruik onderstaande vragen als leidraad:

1. Welke handmatige technieken zijn gebruikt naast geautomatiseerde tools? Een betrouwbare partij kan dit concreet beantwoorden.
2. Hebben jullie ook gekeken naar identiteiten, permissies en supplychaintoegang? Echte aanvallers beginnen hier vaak.
3. Zijn er gecorreleerde aanvalspaden onderzocht? Vraag om een voorbeeld uit het rapport.
4. Wat viel buiten scope en waarom? Dit geeft inzicht in bewuste keuzes versus blinde vlekken.
5. Hoe is de ernst van bevindingen bepaald? Risicoclassificatie moet gebaseerd zijn op exploiteerbaarheid en impact, niet alleen op technische ernst.

Kun je op deze vragen geen duidelijke antwoorden krijgen, dan is dat een signaal dat de test oppervlakkiger was dan gewenst. Een transparante aanbieder legt zijn werkwijze graag uit. Wil je alvast meer begrijpen over hoe security continu getest kan worden, dan geeft de pagina over Continuous-Q een goed beeld van wat doorlopend testen inhoudt.

Valideer de bevindingen met een tweede beoordeling

Zelfs een goed rapport heeft baat bij een onafhankelijke blik. Een tweede beoordeling helpt je te verifiëren of de bevindingen kloppen, of de aanbevelingen realistisch zijn en of er niets over het hoofd is gezien.

1. Laat een interne securityspecialist of een onafhankelijke derde partij de bevindingen doorlopen en beoordelen op volledigheid
2. Verifieer of de beschreven aanvalspaden daadwerkelijk reproduceerbaar zijn. Bevindingen zonder bewijs zijn moeilijk te prioriteren
3. Toets de aanbevelingen op haalbaarheid binnen jouw IT-omgeving. Een goede pentestaanbieder houdt rekening met de praktische context van jouw organisatie
4. Vergelijk de bevindingen met eerdere tests of bekende risico’s in jouw sector om te beoordelen of er blinde vlekken zijn

Met de bevindingen gevalideerd, heb je een betrouwbare basis om prioriteiten te stellen en verbeteringen door te voeren. Onthoud: de waarde van een pentest zit niet in het rapport zelf, maar in wat je ermee doet. Een grondig uitgevoerde test geeft je het inzicht dat nodig is om je beveiliging structureel te versterken.

Hoe Q-Cyber helpt bij het beoordelen en uitvoeren van grondige pentests

Bij Q-Cyber voeren we pentests uit zoals een echte aanvaller dat zou doen: handmatig, methodisch en gericht op de combinatie van zwaktes die samen de grootste risico’s vormen. We kijken verder dan bekende CVE’s en onderzoeken organisatiestructuren, identiteiten, cloudconfiguraties en supplychaintoegang. Zo krijg je niet alleen een lijst met bevindingen, maar een helder beeld van de werkelijke aanvalspaden in jouw omgeving.

Wat je van ons mag verwachten:

• Handmatige pentests uitgevoerd door gecertificeerde ethical hackers met offensieve securityervaring
• Rapportage op drie niveaus: bekende kwetsbaarheden, individuele zwaktes en gecorreleerde aanvalspaden
• Concrete aanbevelingen die aansluiten bij de praktische context van jouw organisatie
• Onafhankelijk advies, zonder afhankelijkheid van softwarepartijen of toeleveranciers
• Optionele doorgroei naar Continuous-Q, voor organisaties die veiligheid structureel willen borgen in plaats van eenmalig meten

Wil je weten of jouw beveiliging een grondige test doorstaat? Neem contact op en we bespreken samen wat een pentest voor jouw organisatie kan betekenen.

Lees meer

Single sign-on (SSO): voordelen en risico’s

Geplaatst op: 7 oktober 2026

Single sign-on (SSO) is een authenticatiemethode waarmee gebruikers met één set inloggegevens toegang krijgen tot meerdere applicaties en systemen. Dat klinkt praktisch, en dat is het ook, maar SSO brengt naast duidelijke voordelen ook serieuze beveiligingsrisico’s met zich mee. In dit artikel beantwoorden we de meest gestelde vragen over SSO: van de technische werking tot de beveiligingsaspecten en de vraag wanneer SSO de juiste keuze is voor jouw organisatie.

Wat zijn de grootste voordelen van SSO voor organisaties?

De grootste voordelen van single sign-on voor organisaties zijn verhoogde productiviteit, minder wachtwoordgerelateerde problemen en een betere gebruikerservaring. Medewerkers hoeven nog maar één keer in te loggen en hebben direct toegang tot alle gekoppelde systemen. Dit bespaart tijd, vermindert het aantal helpdeskvragen over vergeten wachtwoorden en verlaagt de drempel om sterke inlogprocedures te hanteren.

Concreet levert SSO organisaties de volgende voordelen op:

• Minder wachtwoordmoeheid: Medewerkers die tientallen systemen gebruiken, kiezen zonder SSO vaak voor zwakke of hergebruikte wachtwoorden. Met SSO is er nog maar één sterk wachtwoord nodig.
• Snellere onboarding en offboarding: Nieuwe medewerkers worden centraal toegevoegd, en als iemand de organisatie verlaat, volstaat het om één account te deactiveren om de toegang tot alle systemen te blokkeren.
• Centrale toegangscontrole: IT-beheerders hebben één plek waar ze gebruikersrechten beheren, wat het overzicht en de controle aanzienlijk verbetert.
• Betere compliance: Toegangsbeheer is makkelijker te auditen en te documenteren, wat helpt bij het voldoen aan regelgeving zoals NIS2 en andere verplichtingen.
• Hogere adoptie van beveiligingsmaatregelen: Wanneer inloggen eenvoudiger is, ervaren medewerkers minder weerstand tegen het gebruik van extra beveiligingslagen.

Voor grotere organisaties met veel applicaties is het gemak van SSO al snel merkbaar. Maar de voordelen zijn pas echt waardevol als de SSO-omgeving zelf goed is beveiligd.

Welke beveiligingsrisico’s kleven er aan single sign-on?

Het grootste beveiligingsrisico van SSO is het zogenoemde single point of failure: als een aanvaller toegang krijgt tot de centrale SSO-account, heeft hij in één klap toegang tot alle gekoppelde systemen. SSO concentreert de toegang, wat de impact van een gecompromitteerd account enorm vergroot ten opzichte van een omgeving zonder SSO.

Andere relevante risico’s zijn:

• Credential stuffing en phishing: Aanvallers richten zich bewust op SSO-accounts omdat de opbrengst van een succesvolle aanval veel groter is.
• Sessiekaping: Als een actieve SSO-sessie wordt onderschept, kan een aanvaller die sessie misbruiken zonder opnieuw in te hoeven loggen.
• Misconfiguratie van de identity provider: Fouten in de configuratie van de centrale authenticatiedienst kunnen leiden tot onbedoelde toegang of beveiligingslekken.
• Afhankelijkheid van één leverancier: Als de identity provider uitvalt of gecompromitteerd raakt, is de toegang tot alle gekoppelde applicaties tegelijk geblokkeerd of in gevaar.
• Onvoldoende logging en monitoring: Omdat alle authenticatie via één punt verloopt, is het cruciaal dat dit punt intensief wordt gemonitord. Ontbreekt dit, dan kunnen aanvallen lang onopgemerkt blijven.

Deze risico’s maken SSO niet per definitie onveilig, maar ze vereisen wel een bewuste en gelaagde beveiligingsaanpak. SSO zonder aanvullende maatregelen is een kwetsbare constructie.

Hoe werkt SSO technisch gezien?

SSO werkt door een centrale identity provider (IdP) te laten fungeren als vertrouwde authenticatiedienst voor meerdere applicaties. Wanneer een gebruiker inlogt bij de IdP, ontvangt hij een beveiligd token. Dit token wordt automatisch gepresenteerd aan andere gekoppelde applicaties, die het token verifiëren zonder de gebruiker opnieuw om inloggegevens te vragen.

De meest gebruikte technische protocollen achter SSO zijn:

• SAML (Security Assertion Markup Language): Een XML-gebaseerd protocol dat veel wordt gebruikt in bedrijfsomgevingen. De IdP stuurt een ondertekende authenticatieverklaring naar de applicatie.
• OAuth 2.0: Een autorisatieprotocol dat wordt gebruikt om applicaties namens de gebruiker toegang te geven, zonder het wachtwoord te delen. Wordt veel ingezet bij moderne webapplicaties en API’s.
• OpenID Connect (OIDC): Een authenticatielaag bovenop OAuth 2.0, waarmee applicaties de identiteit van een gebruiker kunnen verifiëren op basis van een token van de IdP.

In de praktijk verloopt het proces als volgt: een medewerker opent een applicatie, wordt doorgestuurd naar de centrale loginpagina van de IdP, logt eenmalig in en ontvangt een token. Alle andere applicaties die de IdP vertrouwen, accepteren dit token zonder nieuwe inlogprompt. De sessieduur en de geldigheid van tokens worden centraal beheerd, wat ook centrale controle over toegang mogelijk maakt.

Wat is het verschil tussen SSO en multi-factor authenticatie (MFA)?

SSO en multi-factor authenticatie (MFA) zijn twee verschillende beveiligingsconcepten die elkaar aanvullen, maar niet hetzelfde zijn. SSO bepaalt hoe een gebruiker toegang krijgt tot meerdere systemen via één inlogmoment. MFA bepaalt hoe sterk die authenticatie is door meerdere verificatiestappen te vereisen. De twee worden het beste samen ingezet.

Het onderscheid is eenvoudig samen te vatten:

• SSO gaat over gebruiksgemak en toegangsbeheer: één inlogmoment voor meerdere systemen.
• MFA gaat over authenticatiezekerheid: bewijs dat je bent wie je zegt te zijn via meerdere factoren, zoals een wachtwoord gecombineerd met een code op je telefoon.

In een goed ingerichte omgeving worden SSO en MFA gecombineerd. De gebruiker logt eenmalig in via de identity provider, maar die inlogstap vereist twee of meer verificatiefactoren. Zo geniet de organisatie van het gemak van SSO zonder in te leveren op authenticatiezekerheid. MFA op de SSO-laag is in feite een minimumvereiste om de risico’s van het single point of failure te beperken. Overigens is het gebruik van multi-factorauthenticatie ook een van de minimummaatregelen die NIS2 expliciet benoemt voor organisaties die onder die wetgeving vallen.

Wanneer is SSO de juiste keuze voor een organisatie?

SSO is de juiste keuze voor een organisatie wanneer medewerkers regelmatig werken met meerdere applicaties, wanneer toegangsbeheer centraal georganiseerd moet zijn, of wanneer de organisatie wil investeren in een volwassen identiteits- en toegangsbeheerstrategie. Hoe meer applicaties in gebruik zijn, hoe groter de winst van SSO op het gebied van beheer en beveiliging.

SSO is bijzonder geschikt in de volgende situaties:

• Organisaties met tien of meer applicaties die medewerkers dagelijks gebruiken.
• Omgevingen waar snelle onboarding en offboarding van medewerkers belangrijk zijn.
• Organisaties die werken met externe medewerkers, partners of leveranciers die toegang nodig hebben tot specifieke systemen.
• Bedrijven die moeten voldoen aan regelgeving rondom toegangsbeheer en auditbaarheid.
• Organisaties die MFA willen uitrollen op een gebruiksvriendelijke manier.

SSO is minder geschikt wanneer een organisatie slechts een handvol applicaties heeft, wanneer de IT-volwassenheid onvoldoende is om de identity provider goed te beheren, of wanneer er geen budget is voor de aanvullende beveiligingsmaatregelen die SSO vereist. Een slecht beheerde SSO-omgeving is gevaarlijker dan geen SSO.

Hoe beveilig je een SSO-omgeving tegen aanvallen?

Een SSO-omgeving beveilig je door meerdere lagen van beveiliging te combineren rondom de centrale identity provider. De belangrijkste maatregel is het verplicht stellen van MFA op de SSO-inlogstap, zodat een gestolen wachtwoord alleen niet voldoende is om toegang te krijgen. Aanvullend zijn monitoring, sterk sessiebeheer en regelmatige tests essentieel.

Een robuuste SSO-beveiliging bestaat uit de volgende elementen:

• MFA verplicht stellen: Elke gebruiker die inlogt via de identity provider moet minimaal twee factoren gebruiken.
• Sterk sessiebeheer: Stel maximale sessieduur in, forceer herauthenticatie bij gevoelige handelingen en zorg voor automatische uitlogfunctionaliteit bij inactiviteit.
• Monitoring en alerting: Houd alle authenticatiepogingen bij. Detecteer afwijkend gedrag zoals inlogpogingen vanuit ongebruikelijke locaties of op ongebruikelijke tijden.
• Minimale rechten per applicatie: Geef gebruikers via de SSO-omgeving alleen toegang tot de applicaties die ze daadwerkelijk nodig hebben.
• Regelmatige security tests: Voer periodiek penetratietests uit op de SSO-configuratie en de identity provider om kwetsbaarheden vroegtijdig te ontdekken.
• Patchbeheer van de identity provider: Houd de software van de IdP up-to-date, want kwetsbaarheden in populaire identity providers worden actief misbruikt.
• Zero-trust principes: Vertrouw niet blind op het SSO-token. Combineer SSO met contextuele toegangscontrole op basis van apparaatstatus, locatie en gedrag.

SSO-beveiliging is geen eenmalig project maar een doorlopende inspanning. Wie de identity provider goed beheert en monitort, plukt de vruchten van SSO zonder onnodig risico te lopen.

Hoe Q-Cyber helpt met SSO-beveiliging

Wij helpen organisaties bij het inrichten, beoordelen en versterken van hun SSO-omgeving. Of je nu overweegt SSO te implementeren of al gebruik maakt van een bestaande oplossing die je wilt laten toetsen, wij bieden concrete ondersteuning op maat. Onze aanpak is pragmatisch en onafhankelijk: we zijn niet gebonden aan softwarepartijen en geven advies dat past bij jouw specifieke situatie.

Wat we voor je kunnen doen:

• SSO security assessment: We beoordelen de configuratie van je identity provider en identificeren kwetsbaarheden in de inrichting.
• Penetratietesten op SSO-omgevingen: Via gerichte tests simuleren we aanvalsscenario’s op je authenticatieinfrastructuur.
• Beleid en toegangsbeheer: We schrijven of verbeteren het toegangsbeleid rondom SSO, inclusief MFA-vereisten en sessiebeheer.
• NIS2-aansluiting: We zorgen dat je SSO-inrichting aansluit op de toegangsbeheervereisten van NIS2, inclusief documentatie en auditbaarheid.
• Doorlopend advies via Continuous-Q: Als virtuele CISO denken we structureel mee over je identiteits- en toegangsstrategie.

Wil je weten hoe jouw SSO-omgeving er nu voor staat of hoe je hem veiliger kunt inrichten? Neem contact met ons op en we kijken samen naar de beste aanpak voor jouw organisatie.

Lees meer

Hoe gebruiken hackers leveranciers om een organisatie binnen te komen?

Geplaatst op: 7 oktober 2026

Hackers richten hun pijlen steeds vaker niet op de organisatie zelf, maar op de leveranciers die toegang hebben tot haar systemen. Een softwareleverancier, een IT-dienstverlener of een externe consultant met de juiste inloggegevens is voor een aanvaller een aantrekkelijker doelwit dan een goed beveiligde organisatie. Door één zwakke schakel in de leveranciersketen te compromitteren, krijgt een aanvaller indirect toegang tot tientallen of honderden klanten tegelijk. Dit is de kern van een supplychainaanval, en het is een van de snelst groeiende dreigingen in het huidige cyberlandschap.

In dit artikel lees je stap voor stap hoe je jouw organisatie beschermt tegen hackers van leveranciers die via third-party toegang binnenkomen. Van het in kaart brengen van externe toegangspunten tot het reageren op een gecompromitteerde leverancier: elke stap helpt je om supplychainbeveiliging te verankeren in de praktijk.

Herken de zwakke schakels in je leveranciersketen

Voordat je iets kunt beveiligen, moet je weten wat er te beveiligen valt. De eerste stap is begrijpen waarom leveranciers zo aantrekkelijk zijn als aanvalsvector. Een aanvaller denkt niet in termen van losse systemen, maar in toegangspaden. Hij stelt zichzelf de vraag: wie heeft er al toegang tot mijn doelwit, en hoe goed is die partij beveiligd?

Zwakke schakels zijn niet altijd de meest voor de hand liggende partijen. Denk niet alleen aan grote softwareleveranciers, maar ook aan:

• Kleinere IT-dienstverleners met beheertoegang tot je netwerk
• Clouddiensten die geïntegreerd zijn met je interne systemen
• Externe consultants met tijdelijke accounts die nooit zijn ingetrokken
• Softwaretools die automatisch updates ontvangen en daarmee code uitvoeren in je omgeving
• Leveranciers van je leveranciers, ook wel vierde partijen genoemd

Controleer na deze inventarisatie welke van deze partijen toegang heeft tot gevoelige systemen, klantdata of kritieke infrastructuur. Dit geeft je een eerste beeld van waar het third-partyrisico het grootst is. Pas als je weet wie er toegang heeft, kun je beoordelen hoe groot het risico per leverancier werkelijk is.

Breng al je externe toegangspunten in kaart

Met een overzicht van je leveranciers in handen is de volgende stap het documenteren van alle externe toegangspunten. Dit gaat verder dan een lijst met namen: je wilt per leverancier precies weten hoe, wanneer en via welk kanaal die toegang heeft tot jouw omgeving.

1. Inventariseer alle actieve accounts die zijn aangemaakt voor externe partijen, inclusief serviceaccounts en gedeelde logins.
2. Documenteer via welke methode elke leverancier verbinding maakt: VPN, Remote Desktop, API-koppeling, cloudomgeving of een combinatie.
3. Leg vast welke systemen en data elke externe partij kan bereiken na inloggen.
4. Controleer of er nog accounts actief zijn van leveranciers waarmee de samenwerking al is beëindigd.

Veel organisaties ontdekken in deze stap dat er aanzienlijk meer externe toegangspunten actief zijn dan verwacht. Vergeten accounts, brede rechten die ooit tijdelijk waren bedoeld en koppelingen die nooit zijn opgeschoond: dit zijn precies de ingangen die een aanvaller zoekt. Een handmatige pentest kan helpen om ook de minder zichtbare toegangspaden bloot te leggen die een interne inventarisatie mist.

Beoordeel het risico van elke leverancier

Niet elke leverancier vormt hetzelfde risico. Een partij die alleen facturen verwerkt via een afgeschermd portaal verschilt wezenlijk van een IT-dienstverlener die beheertoegang heeft tot je volledige netwerk. Het doel van deze stap is om prioriteit aan te brengen op basis van daadwerkelijk risico, zodat je je inspanningen gericht kunt inzetten.

Beoordeel elke leverancier op de volgende criteria:

• Toegangsniveau: Heeft de leverancier beheerdersrechten, of alleen leestoegang tot een beperkt systeem?
• Datagevoeligheid: Welke data kan de leverancier bereiken? Gaat het om persoonsgegevens, financiële informatie of bedrijfskritische systemen?
• Eigen beveiligingsvolwassenheid: Heeft de leverancier aantoonbare beveiligingsmaatregelen getroffen, zoals certificeringen of een eigen securitybeleid?
• Afhankelijkheid: Hoe groot is de impact als deze leverancier uitvalt of gecompromitteerd raakt?

Verdeel leveranciers op basis van deze beoordeling in risicocategorieën: hoog, gemiddeld en laag. Leveranciers in de hoogste categorie verdienen de meeste aandacht bij de volgende stappen. Dit maakt supplychainbeveiliging behapbaar, ook voor organisaties met een lange lijst aan externe partijen.

Stel minimale beveiligingseisen aan leveranciers

Zodra je weet welke leveranciers het hoogste risico vormen, is het tijd om concrete eisen te stellen. Cyberbeveiliging van leveranciers begint bij het contractueel vastleggen van wat je van externe partijen verwacht op het gebied van informatiebeveiliging.

1. Stel een minimale baseline op: welke beveiligingsmaatregelen zijn voor elke leverancier verplicht, ongeacht het risiconiveau?
2. Formuleer aanvullende eisen voor hoog-risicoleveranciers, zoals verplichte multifactorauthenticatie, periodieke pentests of aantoonbare naleving van NIS2 of ISO 27001.
3. Leg deze eisen vast in contracten of verwerkersovereenkomsten, inclusief het recht om naleving te controleren.
4. Communiceer de eisen actief naar bestaande leveranciers en maak ze onderdeel van het selectieproces voor nieuwe partijen.

Een veelgemaakte fout is het stellen van eisen zonder te controleren of ze worden nageleefd. Vraag leveranciers om bewijs, zoals een recent auditrapport, een ingevulde vragenlijst of een certificering. Wees daarin proportioneel: een kleine leverancier met beperkte toegang hoeft niet aan dezelfde eisen te voldoen als een partij die dagelijks toegang heeft tot kritieke systemen. Meer achtergrond over beleid en compliance vind je op de pagina over compliance en beleid.

Monitor leverancierstoegang continu op afwijkingen

Eenmalige controle is niet voldoende. Een leverancier die vandaag veilig is, kan morgen gecompromitteerd zijn. Continu monitoren van externe toegang is daarmee een van de meest effectieve maatregelen om een leveranciersaanval te voorkomen voordat er schade ontstaat.

Richt je monitoring in op de volgende signalen:

• Inlogpogingen buiten gebruikelijke tijden of vanuit onverwachte locaties
• Toegang tot systemen of data die buiten de normale werkzaamheden van de leverancier vallen
• Grote hoeveelheden data die worden gedownload of geëxporteerd via een extern account
• Meerdere mislukte inlogpogingen gevolgd door een succesvolle login
• Wijzigingen in rechten of configuraties uitgevoerd vanuit een leveranciersaccount

Koppel monitoring aan duidelijke escalatieprocedures: wie wordt gewaarschuwd bij een afwijking, en welke stappen worden dan gezet? Automatische alerts helpen, maar een menselijke beoordeling blijft nodig om onderscheid te maken tussen een onschuldige afwijking en een werkelijk incident. Continuous-Q® biedt hier een gestructureerde aanpak voor organisaties die dit continu willen borgen.

Wat te doen als een leverancier is gecompromitteerd

Ondanks alle voorzorgsmaatregelen kan het gebeuren dat een leverancier wordt aangevallen en dat aanvallers via die route jouw omgeving proberen te bereiken. Snelheid en een helder plan zijn dan doorslaggevend. Een leveranciersaanval voorkomen is het doel, maar voorbereid zijn op het scenario dat het toch misgaat, is minstens even belangrijk.

1. Isoleer direct alle toegang van de betreffende leverancier: blokkeer accounts, verbreek VPN-verbindingen en deactiveer API-koppelingen.
2. Breng in kaart welke systemen en data de leverancier kon bereiken en of er in de periode voor de ontdekking verdachte activiteit heeft plaatsgevonden.
3. Stel een intern crisisteam samen en informeer relevante stakeholders, inclusief de eigen directie en eventueel betrokken klanten.
4. Beoordeel of er een meldplicht geldt, bijvoorbeeld onder de AVG of NIS2, en handel daar tijdig naar.
5. Voer na het incident een grondige analyse uit: hoe kon de aanvaller via de leverancier binnenkomen, en welke maatregelen voorkomen herhaling?

Documenteer het incident volledig, ook als de schade beperkt bleek. Elk incident levert inzicht op in de zwakke plekken van je leveranciersketen en helpt je toekomstige aanvallen eerder te herkennen. Overweeg na een incident een redteamoefening om te toetsen of aanvallers via vergelijkbare routes nog steeds toegang kunnen krijgen.

Hoe Q-Cyber helpt met supplychainbeveiliging

Q-Cyber helpt organisaties om hun leveranciersketen te beveiligen met een combinatie van technische tests, onafhankelijk advies en continue monitoring. Wij kijken niet alleen naar losse kwetsbaarheden, maar onderzoeken de volledige aanvalsketen: welke leveranciers hebben toegang, via welke routes, en hoe kunnen die worden misbruikt?

Concreet bieden wij:

• Pentests gericht op third-party toegang: onze ethical hackers testen of externe toegangspunten kunnen worden misbruikt om dieper in je omgeving door te dringen.
• Beleidsadvies en leveranciersbeoordelingen: wij helpen bij het opstellen van beveiligingseisen voor leveranciers en het beoordelen van hun naleving.
• Continuous-Q®: voor organisaties die continu inzicht willen in hun aanvalsoppervlak, inclusief wijzigingen in leverancierstoegang en nieuwe risico’s.
• Incidentbegeleiding: als een leverancier is gecompromitteerd, helpen wij bij het snel in kaart brengen van de impact en het nemen van de juiste maatregelen.

Wil je weten hoe kwetsbaar jouw organisatie is via leveranciers? Neem contact op voor een vrijblijvend gesprek.

Lees meer

Identity and access management (IAM) voor het mkb

Geplaatst op: 6 oktober 2026

Identity and access management (IAM) is een verzameling processen, beleidsregels en technologieën waarmee een organisatie regelt wie toegang heeft tot welke systemen, gegevens en applicaties. Voor het mkb betekent dit concreet: de juiste medewerker krijgt toegang tot precies wat hij of zij nodig heeft, en niemand anders. In dit artikel beantwoorden we de meest gestelde vragen over IAM, van de basisprincipes tot de praktische implementatie en de relatie met NIS2.

Wat houdt identity and access management precies in?

Identity and access management is het geheel van processen en technologieën waarmee een organisatie digitale identiteiten beheert en bepaalt welke rechten daaraan zijn gekoppeld. Het omvat het aanmaken, beheren en verwijderen van gebruikersaccounts, het toewijzen van toegangsrechten en het bewaken van wie wat doet binnen de digitale omgeving van de organisatie.

In de praktijk gaat IAM over drie kernvragen: wie ben jij, wat mag jij, en kun je bewijzen dat jij het bent? Het eerste aspect is identiteitsbeheer: elke medewerker, leverancier of systeem krijgt een unieke digitale identiteit. Het tweede aspect is toegangsbeheer: op basis van die identiteit worden rechten toegewezen, vaak volgens het principe van least privilege, wat betekent dat iemand alleen toegang krijgt tot wat strikt noodzakelijk is voor zijn of haar functie. Het derde aspect is authenticatie: het verificatieproces dat bevestigt dat de persoon die inlogt ook daadwerkelijk degene is die hij of zij beweert te zijn.

Een volledig IAM-systeem regelt ook wat er gebeurt wanneer iemand van functie wisselt of de organisatie verlaat. Rechten worden dan aangepast of ingetrokken, zodat voormalige medewerkers geen toegang meer hebben tot bedrijfssystemen. Dit klinkt vanzelfsprekend, maar in de praktijk blijft dit bij veel organisaties een blinde vlek.

Waarom is IAM belangrijk voor het mkb?

IAM is voor het mkb belangrijk omdat ongecontroleerde toegang tot systemen en data een van de meest voorkomende oorzaken is van beveiligingsincidenten. Gestolen inloggegevens, voormalige medewerkers met actieve accounts en medewerkers met te ruime rechten zijn directe risicofactoren die met goed gebruikersbeheer grotendeels te voorkomen zijn.

Kleine en middelgrote bedrijven hebben vaak het idee dat ze te klein zijn om een interessant doelwit te zijn voor cybercriminelen. De praktijk wijst anders uit: mkb-organisaties worden juist vaker aangevallen omdat ze minder beveiligingsmaatregelen hebben getroffen dan grote ondernemingen. Een aanvaller die één geldig account weet te bemachtigen, heeft zonder sterk toegangsbeheer al snel toegang tot grote delen van de bedrijfsinfrastructuur.

Daarnaast groeit het mkb. Medewerkers komen en gaan, er worden cloudapplicaties toegevoegd, en externe partijen zoals leveranciers of freelancers krijgen tijdelijk toegang. Zonder een gestructureerde aanpak van identity and access management stapelen de risico’s zich op. Denk aan accounts die niet worden verwijderd na uitdiensttreding, of aan medewerkers die in de loop der jaren steeds meer rechten hebben verzameld zonder dat die ooit zijn opgeschoond.

Tot slot speelt regelgeving een rol. Wetgeving zoals de AVG en de NIS2-richtlijn stellen eisen aan hoe organisaties omgaan met toegang tot persoonsgegevens en kritieke systemen. Goed IAM is daarmee niet alleen een technische maatregel, maar ook een juridische verplichting.

Wat is het verschil tussen IAM, SSO en MFA?

IAM is het overkoepelende kader voor identiteits- en toegangsbeheer. Single sign-on (SSO) en multi-factorauthenticatie (MFA) zijn specifieke technologieën die onderdeel uitmaken van een IAM-strategie. SSO regelt hoe gebruikers inloggen, MFA versterkt de verificatie, en IAM bepaalt wat er daarna mag worden gedaan.

Wat is SSO en wat doet het?

Single sign-on stelt gebruikers in staat om met één set inloggegevens toegang te krijgen tot meerdere applicaties en systemen. In plaats van voor elke tool een apart wachtwoord te onthouden, logt een medewerker eenmalig in en heeft daarna toegang tot alle gekoppelde applicaties. Dit verhoogt het gebruiksgemak en vermindert het risico op zwakke of hergebruikte wachtwoorden, omdat medewerkers minder wachtwoorden hoeven te beheren.

Wat is MFA en waarom is het essentieel?

Multi-factorauthenticatie voegt een extra verificatiestap toe aan het inlogproces. Naast een wachtwoord moet de gebruiker een tweede bewijs leveren, zoals een code via een authenticatie-app, een sms-code of een biometrisch gegeven. Zelfs als een wachtwoord wordt gestolen, kan een aanvaller zonder die tweede factor niet inloggen. MFA is een van de meest effectieve maatregelen tegen accountovername en wordt dan ook expliciet genoemd als minimumvereiste in de NIS2-richtlijn.

Hoe implementeer je IAM als klein of middelgroot bedrijf?

IAM implementeer je als mkb-bedrijf stapsgewijs, te beginnen met een inventarisatie van wie toegang heeft tot wat. Je hoeft niet direct een volledig enterprise-platform te implementeren. Een pragmatische aanpak in fasen is voor de meeste kleine en middelgrote bedrijven de meest haalbare en effectieve route.

Een praktische aanpak ziet er als volgt uit:

1. Breng gebruikers en toegangsrechten in kaart. Maak een overzicht van alle accounts, welke systemen ze kunnen bereiken en of die rechten nog kloppen met de huidige functie van de medewerker.
2. Schoon bestaande rechten op. Verwijder accounts van medewerkers die uit dienst zijn en pas rechten aan die in de loop der tijd te ruim zijn geworden.
3. Stel een offboarding-proces in. Zorg dat er een vaste procedure bestaat voor het intrekken van toegang zodra iemand de organisatie verlaat of van rol wisselt.
4. Activeer MFA voor alle kritieke systemen. Begin met e-mail, cloudopslag en financiële applicaties. Dit is de snelste manier om het risico op accountmisbruik te verlagen.
5. Kies een centrale IAM-tool. Afhankelijk van je omgeving kun je werken met een bestaand platform zoals Microsoft Entra ID (voorheen Azure AD) of een vergelijkbare oplossing.
6. Documenteer en herhaal. IAM is geen eenmalig project. Plan periodieke reviews om toegangsrechten actueel te houden.

Het principe van least privilege is hierbij leidend: geef medewerkers alleen toegang tot wat ze daadwerkelijk nodig hebben voor hun werk. Dat klinkt eenvoudig, maar vraagt om bewuste keuzes bij elke nieuwe medewerker, elk nieuw systeem en elke functiewijziging.

Welke IAM-tools zijn geschikt voor het mkb?

Voor het mkb zijn er meerdere toegankelijke IAM-oplossingen beschikbaar die geen grote IT-afdeling vereisen. De keuze hangt af van je bestaande infrastructuur, het aantal gebruikers en de applicaties die je gebruikt. De meest praktische opties zijn platforms die IAM combineren met SSO en MFA in één beheeromgeving.

De meest gebruikte opties voor het mkb zijn:

• Microsoft Entra ID (Azure AD): Ideaal als je al werkt met Microsoft 365. Biedt SSO, MFA, conditional access en uitgebreid gebruikersbeheer. Voor veel mkb-bedrijven al inbegrepen bij de bestaande Microsoft-licentie.
• Google Workspace Identity: Vergelijkbaar met Microsoft Entra, maar dan voor organisaties die op het Google-ecosysteem draaien. Inclusief SSO en MFA-functionaliteit.
• Okta: Een onafhankelijk IAM-platform dat goed integreert met een brede set applicaties. Geschikt als je een gemengde omgeving hebt met meerdere cloudplatforms.
• JumpCloud: Een cloudgebaseerde directory-oplossing die populair is bij kleinere organisaties zonder on-premise Active Directory. Combineert gebruikersbeheer, SSO en MFA.

Let bij de keuze op integratiemogelijkheden met de applicaties die je al gebruikt, de beheerbaarheid voor een klein IT-team en de schaalbaarheid naarmate je organisatie groeit. Voor veel mkb-bedrijven is het slim om te beginnen met wat al beschikbaar is in de bestaande licenties, voordat je investeert in een nieuw platform.

Hoe verhoudt IAM zich tot NIS2-compliance?

IAM is een directe invulling van meerdere NIS2-verplichtingen. De NIS2-richtlijn schrijft expliciet voor dat organisaties toegangsbeheer, multi-factorauthenticatie en beleid voor beveiligingsmaatregelen voor personeel moeten implementeren. Een goed ingericht IAM-systeem dekt daarmee een substantieel deel van de technische zorgplicht die NIS2 oplegt.

Concreet raakt IAM de volgende NIS2-vereisten:

• Toegangsbeveiliging: NIS2 vereist dat organisaties beleid hebben voor wie toegang heeft tot welke systemen en data. IAM is de technische uitvoering van dat beleid.
• Multi-factorauthenticatie: MFA wordt in de NIS2-richtlijn expliciet genoemd als minimummaatregel voor het beveiligen van toegang tot kritieke systemen.
• Beveiligingsmaatregelen voor personeel: Het beheren van rechten bij indiensttreding, functiewijziging en uitdiensttreding valt onder de personeelsgerelateerde beveiligingseisen van NIS2.
• Risicogebaseerde aanpak: IAM helpt bij het beperken van de impact van een incident, doordat rechten beperkt zijn en een aanvaller minder bewegingsruimte heeft.

Organisaties die al werken aan NIS2-compliance doen er verstandig aan om IAM vroeg in het traject op te pakken. Het is een maatregel met direct aantoonbaar effect, die tegelijkertijd meerdere NIS2-vereisten afdekt. Meer achtergrond over de bredere verplichtingen van NIS2 vind je op de NIS2-regelgevingspagina.

Hoe Q-Cyber helpt met identity and access management

Q-Cyber helpt mkb-organisaties om IAM niet als losstaand technisch project te benaderen, maar als onderdeel van een bredere, samenhangende beveiligingsstrategie. We combineren technische kennis met beleidsmatige expertise, zodat je niet alleen de juiste tools inricht, maar ook de processen en het beleid eromheen goed op orde hebt.

Wat we concreet voor je kunnen doen:

• Gap-analyse: We brengen in kaart waar je toegangsbeheer nu tekortschiet en welke risico’s dat oplevert.
• Beleidsvorming: We schrijven een toegangsbeleid dat aansluit op jouw organisatie en voldoet aan NIS2-vereisten.
• Implementatieadvies: We adviseren welke IAM-tools het beste passen bij jouw omgeving, zonder binding aan softwarepartijen.
• NIS2-begeleiding: We begeleiden je door het volledige NIS2-traject, waarbij IAM een concrete bouwsteen is in de bredere compliance-aanpak.
• Virtuele CISO: Via Continuous-Q hebben we een team van specialisten beschikbaar als virtuele CISO, zodat je structureel wordt ondersteund zonder een fulltime beveiligingsexpert in dienst te hoeven nemen.

Wil je weten waar jouw organisatie staat op het gebied van toegangsbeheer en wat er nodig is om NIS2-compliant te worden? Neem contact op en we kijken samen naar een pragmatische aanpak die past bij jouw bedrijf.

Lees meer

Hoe kiest een hacker het makkelijkste aanvalspad?

Geplaatst op: 6 oktober 2026

Aanvallers kiezen hun doelwit niet willekeurig. Voordat een hacker ook maar één exploit afvuurt, heeft hij al een duidelijk beeld van hoe jouw organisatie in elkaar zit, waar de zwakke plekken zitten en welk pad hem het snelst naar zijn doel brengt. Dat proces is methodisch, geduldig en veel strategischer dan veel mensen denken.

In dit artikel lees je hoe een aanvaller een aanvalspad opbouwt, van de eerste verkenning tot het moment waarop hij toegang heeft. Door te begrijpen hoe een hacker denkt, kun je gerichte maatregelen nemen die er werkelijk toe doen, in plaats van alleen oppervlakkige kwetsbaarheden te dichten.

Zo bepaalt een hacker waar hij begint

De eerste fase van elke cyberaanval is verkenning. Een aanvaller begint niet met aanvallen, maar met observeren. Hij probeert te begrijpen hoe jouw organisatie is ingericht: welke systemen publiek bereikbaar zijn, welke leveranciers toegang hebben, welke medewerkers welke rechten bezitten en waar de grenzen van je beveiliging liggen.

Daarvoor gebruikt een hacker vaak openbare bronnen die je zelf ook kunt raadplegen. Denk aan LinkedIn-profielen om te achterhalen welke functies en rollen mensen hebben, vacatureteksten die hints geven over gebruikte technologie, publiek toegankelijke cloudomgevingen en domeininformatie via DNS-records. Dit heet ook wel OSINT, oftewel Open Source Intelligence. Het verrassende is dat een aanvaller soms al een goed beeld heeft van waar de organisatie kwetsbaar is, nog voordat hij ook maar één technisch hulpmiddel heeft ingezet.

Wat je hieruit kunt leren: beperk de hoeveelheid informatie die je onbedoeld publiek maakt. Controleer wat er via zoekmachines vindbaar is over jouw infrastructuur, en wees bewust van wat medewerkers delen op sociale media over interne systemen en processen.

Kwetsbaarheden rangschikken op aanvalspotentieel

Nadat een aanvaller een eerste beeld heeft, gaat hij systematisch kwetsbaarheden in kaart brengen. Hierbij is het belangrijk te begrijpen dat niet elke kwetsbaarheid even interessant is voor een hacker. Een aanvaller kijkt niet naar de ernst van een bevinding op zichzelf, maar naar het aanvalspotentieel: wat kan ik hiermee bereiken?

Er zijn globaal drie niveaus waarop een aanvaller kwetsbaarheden beoordeelt:

1. Bekende kwetsbaarheden (CVE’s): Dit zijn gepubliceerde beveiligingslekken in software waarvoor vaak al exploits beschikbaar zijn. Een aanvaller controleert als eerste of patches goed zijn doorgevoerd en of bekende exploits nog werken.
2. Configuratiefouten en identity weaknesses: Denk aan verkeerde Azure-instellingen, te ruime permissies op accounts, onveilige applicatie-instellingen of identities met meer rechten dan nodig. Deze zijn moeilijker automatisch te detecteren, maar bieden een aanvaller vaak meer speelruimte.
3. Gecombineerde aanvalspaden: Dit is waar het echt gevaarlijk wordt. Een aanvaller bekijkt hoe meerdere kleine zwaktes samen een werkend aanvalspad vormen. Een bevinding die op zichzelf weinig lijkt, kan in combinatie met een andere zwakte leiden tot volledige toegang tot kritieke systemen.

Een concreet voorbeeld: een SSRF-kwetsbaarheid (Server-Side Request Forgery) lijkt misschien beperkt in impact. Maar als die kwetsbaarheid toegang geeft tot een managed identity, die vervolgens Azure RBAC-rechten heeft, en daarmee toegang tot een Key Vault, dan kan een aanvaller uitgroeien tot subscription owner. Geen enkele afzonderlijke bevinding was kritiek, maar samen vormen ze een volledig aanvalspad. Dit is precies waarom het aantal gevonden kwetsbaarheden weinig zegt over hoe veilig je werkelijk bent. Meer over hoe dit soort aanvalspaden in kaart worden gebracht lees je op de pentestpagina.

Het aanvalspad samenstellen stap voor stap

Met de verzamelde informatie begint een aanvaller het eigenlijke aanvalspad te bouwen. Hij zoekt de route van de minste weerstand: de combinatie van kwetsbaarheden, misconfiguraties en rechten die hem het snelst naar zijn doel brengt, met het minste risico op detectie.

Zo bouwt een aanvaller een aanvalspad op:

1. Identificeer het einddoel: Wat wil de aanvaller bereiken? Toegang tot klantdata, financiële systemen, intellectueel eigendom of beheerdersrechten over de hele omgeving? Het einddoel bepaalt welke paden interessant zijn.
2. Breng de route in kaart: Welke systemen, accounts en rechten liggen tussen de buitenkant en het doel? Een aanvaller tekent mentaal een kaart van de organisatie en markeert waar overstapmomenten mogelijk zijn.
3. Zoek de zwakste schakel: Dat is niet altijd een technisch lek. Het kan een medewerker zijn met te veel rechten, een externe leverancier met directe netwerktoegang, of een cloudresource met een verkeerde instelling.
4. Test de route stap voor stap: Een goede aanvaller werkt methodisch en langzaam, om detectie te vermijden. Hij test elke stap in het aanvalspad voordat hij verdergaat.
5. Pas het pad aan als een stap mislukt: Als één route geblokkeerd is, zoekt hij een alternatief. Een aanvaller geeft niet op bij de eerste hindernis, maar verkent zijpaden.

Dit is ook waarom een traditionele vulnerability scan tekortschiet: die vindt losse bevindingen, maar ziet de verbindingen daartussen niet. Een echte aanvaller denkt in paden, niet in lijsten.

Herken de signalen van een verkenningsaanval

Verkenning laat sporen achter, als je weet waar je moet kijken. Veel organisaties missen deze vroege signalen omdat ze pas alarmeren bij daadwerkelijke inbraakpogingen. Maar juist in de verkenningsfase heb je de meeste kans om een aanvaller te stoppen.

Let op de volgende signalen die kunnen wijzen op actieve verkenning:

• Ongebruikelijk veel mislukte inlogpogingen op accounts, vooral buiten kantooruren
• Scans op poorten of services die normaal geen verkeer ontvangen
• Onbekende IP-adressen die DNS-informatie opvragen over jouw domein
• Medewerkers die phishingmails ontvangen die specifieke interne informatie bevatten
• Onverwachte API-aanroepen naar cloudresources vanuit onbekende locaties
• Accounts die rechten of configuraties opvragen die buiten hun normale gebruik vallen

Stel je logging en monitoring zo in dat deze activiteiten zichtbaar worden. Zonder zichtbaarheid op je eigen omgeving kun je een aanvaller niet herkennen voordat hij zijn aanvalspad heeft voltooid. Een redteamoefening kan helpen om te testen of jouw detectiemechanismen daadwerkelijk werken onder realistische aanvalsomstandigheden.

Sluit de makkelijkste aanvalspaden structureel af

Nu je begrijpt hoe een aanvaller denkt en handelt, kun je gericht de makkelijkste aanvalspaden afsluiten. Het gaat er niet om alles tegelijk op te lossen, maar om de routes die een aanvaller het minste moeite kosten zo snel mogelijk te blokkeren.

Werk de volgende stappen af in volgorde van prioriteit:

1. Patch bekende kwetsbaarheden consequent: Zorg dat patches snel en volledig worden doorgevoerd. Controleer of updates ook daadwerkelijk zijn toegepast en niet alleen zijn ingepland.
2. Beperk permissies op basis van het principe van minimale rechten: Geef accounts alleen toegang tot wat ze echt nodig hebben. Controleer regelmatig of rechten nog kloppen, zeker na functiewijzigingen of vertrek van medewerkers.
3. Controleer cloudconfiguraties actief: Veel aanvalspaden lopen via verkeerd geconfigureerde cloudresources. Voer periodiek een configuratiereview uit op Azure, AWS of andere cloudplatformen die je gebruikt.
4. Beveilig externe toegangspunten: Leveranciers, MSP’s en andere partijen met toegang tot jouw omgeving zijn een favoriet aanvalspad. Controleer welke toegang zij hebben en of die toegang nog noodzakelijk en veilig is.
5. Test combinaties, niet alleen losse bevindingen: Laat periodiek testen of kwetsbaarheden samen een aanvalspad vormen, ook als ze afzonderlijk laag scoren op ernst.

Controleer na elke maatregel of het aanvalspad daadwerkelijk is afgesloten, niet alleen of de maatregel technisch is doorgevoerd. Een bevinding oplossen betekent niet automatisch dat het aanvalspad verdwenen is. Soms bestaat er nog een alternatieve route die je over het hoofd ziet.

Hoe Q-Cyber helpt bij het blootleggen van aanvalspaden

Bij Q-Cyber denken we precies zoals een aanvaller dat doet: niet in losse kwetsbaarheden, maar in aanvalspaden. We helpen organisaties inzicht te krijgen in hoe een echte hacker hun omgeving zou benaderen en welke combinatie van zwaktes het grootste risico vormt.

Wat we concreet voor je doen:

• We voeren handmatige pentests uit waarbij onze ethical hackers actief zoeken naar gecombineerde aanvalspaden, niet alleen naar bekende CVE’s
• We analyseren identities, permissies, cloudconfiguraties en externe toegangspunten als onderdeel van een volledige aanvalsketen
• We leveren een helder rapport met concrete prioriteiten, zodat je weet welke aanvalspaden het meest urgent zijn om af te sluiten
• Via Continuous-Q® blijven we je omgeving continu monitoren, zodat nieuwe aanvalspaden snel worden gesignaleerd
• We adviseren onafhankelijk, zonder afhankelijkheid van softwarepartijen of andere toeleveranciers

Wil je weten welke aanvalspaden er nu in jouw organisatie openstaan? Neem contact met ons op en we kijken samen hoe we jouw beveiliging structureel kunnen versterken.

Lees meer

Least privilege principe: wat is het en hoe implementeer je het?

Geplaatst op: 5 oktober 2026

Het least privilege principe houdt in dat gebruikers, systemen en applicaties alleen de minimaal noodzakelijke toegangsrechten krijgen om hun taken uit te voeren. Niets meer, niets minder. Dit principe is een van de meest effectieve basismaatregelen binnen cybersecurity en vormt de ruggengraat van een goed toegangsbeheerbeleid. In dit artikel beantwoorden we de meest gestelde vragen over het principe, van de risico’s die het voorkomt tot de tools die je kunt inzetten.

Welke risico’s voorkomt het least privilege principe?

Het least privilege principe voorkomt dat een aanvaller of kwaadwillende medewerker met toegang tot één account of systeem meteen toegang heeft tot de hele organisatie. Door rechten te beperken tot wat strikt noodzakelijk is, beperk je de schade die kan ontstaan bij een beveiligingsincident, een geslaagde phishingaanval of misbruik van inloggegevens.

Concreet helpt het principe bij het beperken van de volgende risico’s:

• Laterale beweging door aanvallers: Een hacker die toegang krijgt tot een account met beperkte rechten kan niet zomaar doorstoten naar kritieke systemen of gevoelige data.
• Insiderdreigingen: Medewerkers kunnen bewust of onbewust schade aanrichten. Beperkte rechten verkleinen het aanvalsoppervlak aanzienlijk.
• Ransomware-verspreiding: Ransomware verspreidt zich via de rechten van het gecompromitteerde account. Hoe minder rechten, hoe beperkter de verspreiding.
• Onbedoelde fouten: Een medewerker die per ongeluk kritieke bestanden verwijdert of aanpast, kan dat alleen als hij daartoe de rechten heeft.
• Compliance-risico’s: Organisaties die onder wetgeving zoals NIS2 of andere regelgeving vallen, zijn verplicht toegangsbeheer aantoonbaar in te richten. Ontbrekend beleid leidt tot boetes en reputatieschade.

Het principe werkt als een ingebouwde begrenzing. Zelfs als een aanvaller of kwaadwillende succesvol binnenkomt, stuit hij op een muur van beperkte rechten die verdere schade inperkt. Dat maakt het een fundamenteel onderdeel van elke volwassen beveiligingsstrategie.

Wat is het verschil tussen least privilege en zero trust?

Het least privilege principe en zero trust zijn nauw verwant, maar niet hetzelfde. Least privilege is een specifiek toegangsbeheerconcept dat stelt dat rechten altijd minimaal moeten zijn. Zero trust is een bredere beveiligingsfilosofie die stelt dat niets en niemand automatisch wordt vertrouwd, ongeacht locatie of netwerk. Least privilege is een van de pijlers waarop zero trust rust.

Het verschil zit in de reikwijdte:

• Least privilege richt zich op het beperken van rechten en toegang per gebruiker, applicatie of systeem. Het beantwoordt de vraag: wie mag wat doen?
• Zero trust gaat verder en omvat ook netwerksegmentatie, continue verificatie van identiteit en apparaten, en het uitgangspunt dat ook interne gebruikers niet automatisch betrouwbaar zijn. Het beantwoordt de vraag: vertrouwen we dit verzoek, op dit moment, vanuit deze context?

In de praktijk betekent dit dat je zero trust niet kunt implementeren zonder het least privilege principe toe te passen. Omgekeerd kun je least privilege toepassen zonder een volledig zero trust-architectuur te hebben ingericht. Organisaties die beginnen met het structureel beperken van toegangsrechten via identity and access management (IAM), leggen daarmee automatisch een fundament voor een bredere zero trust-strategie.

Beide concepten versterken elkaar. Wie serieus werk wil maken van cybersecurity, doet er goed aan ze samen te beschouwen als onderdelen van een gelaagde verdedigingsstrategie.

Hoe implementeer je least privilege in de praktijk?

Het implementeren van het principe of least privilege begint met een grondige inventarisatie van wie toegang heeft tot welke systemen, data en applicaties. Vervolgens snoei je die rechten terug tot wat iemand daadwerkelijk nodig heeft voor zijn of haar functie. Dit klinkt eenvoudig, maar vraagt in de praktijk om een structurele aanpak en regelmatig onderhoud.

Een effectieve implementatie volgt globaal deze stappen:

1. Breng bestaande rechten in kaart: Gebruik een IAM-tool of directoryservice om een volledig overzicht te krijgen van alle gebruikersaccounts, serviceaccounts en applicatierechten.
2. Definieer rollen op basis van functie: Koppel rechten aan functies, niet aan individuen. Dit maakt beheer schaalbaar en voorkomt wildgroei van uitzonderingen.
3. Verwijder overbodige rechten: Accounts met meer rechten dan nodig zijn een risico. Saneer actief en verwijder rechten die niet meer nodig zijn, ook bij functiewijzigingen of uitdiensttreding.
4. Beperk beheerdersrechten: Geef beheerders alleen tijdelijk verhoogde rechten wanneer dat nodig is (Just-in-Time access). Vermijd permanente adminaccounts.
5. Stel periodieke toegangsreviews in: Rechten veranderen mee met de organisatie. Plan regelmatige reviews in om de situatie actueel te houden.
6. Documenteer en monitor: Leg vast wie welke rechten heeft en waarom. Monitor afwijkend gedrag via logging en alerting.

Een veelgemaakte fout is dat organisaties beginnen met goede intenties, maar na verloop van tijd weer vervallen in het ruimhartig toekennen van rechten om gebruikers niet te hinderen. Draagvlak bij management en heldere communicatie naar medewerkers zijn daarom net zo belangrijk als de technische uitvoering.

Welke tools ondersteunen het least privilege principe?

Er zijn verschillende categorieën tools die het least privilege principe ondersteunen binnen identity and access management. De juiste keuze hangt af van de omvang van de organisatie, de gebruikte infrastructuur en het volwassenheidsniveau van het beveiligingsbeleid.

IAM-platforms

Identity and access management platforms zoals Microsoft Entra ID (voorheen Azure AD), Okta of SailPoint bieden centrale controle over gebruikersrechten, rollen en toegangspolicies. Ze maken het mogelijk om rechten op schaal te beheren, automatisch in te trekken bij uitdiensttreding en auditlogs bij te houden. Voor organisaties die werken in een cloudomgeving zijn deze platforms vrijwel onmisbaar.

Privileged Access Management (PAM)

PAM-oplossingen zoals CyberArk, BeyondTrust of Delinea richten zich specifiek op het beheren van beheerdersrechten en geprivilegieerde accounts. Ze bieden functies zoals Just-in-Time access, sessieopname en automatische rotatie van wachtwoorden voor serviceaccounts. Dit zijn krachtige tools voor organisaties die hun meest risicovolle accounts willen beveiligen.

Naast deze platformen zijn ook directory-auditing tools, SIEM-oplossingen voor monitoring en cloudnative IAM-functies binnen AWS, Azure of Google Cloud waardevolle aanvullingen. De technologie is een middel, geen doel op zich. Zonder een helder beleid en een actuele inventarisatie leveren zelfs de beste tools onvoldoende resultaat.

Wanneer is een vulnerability scan zinvol naast least privilege?

Een vulnerability scan is zinvol naast het least privilege principe zodra je wilt weten of de beperkingen die je hebt ingesteld ook daadwerkelijk standhouden in de praktijk. Least privilege richt zich op het beperken van rechten, maar zegt niets over kwetsbaarheden in systemen zelf. Een vulnerability scan brengt technische zwaktes in kaart die een aanvaller kan misbruiken, ook als de toegangsrechten goed zijn ingericht.

De twee maatregelen vullen elkaar aan op een concreet punt: een aanvaller die door een kwetsbaarheid toegang krijgt tot een systeem, wordt vervolgens beperkt door het least privilege principe. Omgekeerd voorkomt least privilege niet dat een kwetsbaarheid wordt misbruikt om rechten te escaleren. Privilege escalation, waarbij een aanvaller via een softwarekwetsbaarheid hogere rechten verkrijgt dan zijn account heeft, is een veelgebruikte techniek die alleen door een combinatie van beide maatregelen wordt beperkt.

Een vulnerability scan is in het bijzonder zinvol wanneer:

• Je net een least privilege beleid hebt ingevoerd en wilt valideren of er nog technische achterdeuren openstaan.
• Er nieuwe systemen of applicaties zijn toegevoegd aan de omgeving.
• Je voldoet aan wet- en regelgeving die periodieke risicobeoordelingen vereist, zoals NIS2.
• Er een significante wijziging heeft plaatsgevonden in de infrastructuur, zoals een cloudmigratie.

Wie echt wil weten hoe weerbaar de organisatie is, combineert een vulnerability scan met een pentest. Daarmee simuleer je een echte aanval en zie je niet alleen welke kwetsbaarheden er zijn, maar ook hoe ver een aanvaller daadwerkelijk kan komen.

Hoe Q-Cyber helpt met toegangsbeheer en least privilege

Wij bij Q-Cyber helpen organisaties om het least privilege principe niet alleen te begrijpen, maar ook daadwerkelijk te implementeren en te borgen in beleid en processen. Dat doen we op een pragmatische, onafhankelijke manier, zonder binding aan softwarepartijen of leveranciers.

Wat wij concreet voor je kunnen betekenen:

• Gap-analyse toegangsbeheer: We brengen in kaart waar de huidige inrichting afwijkt van het least privilege principe en welke risico’s dat oplevert.
• Beleid op maat: We schrijven een toegangsbeheersbeleid dat aansluit op jouw organisatie, sector en eventuele wettelijke verplichtingen zoals NIS2.
• Vulnerability scans en pentests: We testen of de ingestelde beperkingen standhouden onder druk van een gesimuleerde aanval, inclusief privilege escalation-scenario’s.
• Virtuele CISO via Continuous-Q: Voor organisaties die structurele begeleiding nodig hebben, bieden we een team van specialisten dat continu meekijkt en adviseert.
• Trainingen voor bestuurders en medewerkers: We zorgen dat niet alleen de techniek op orde is, maar ook het bewustzijn in de organisatie.

Cybersecurity is geen eenmalig project, maar een levende capaciteit die je structureel inbedt in de kern van je organisatie. Wil je weten waar jouw organisatie staat en hoe je het least privilege principe concreet kunt versterken? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe kan één gehackt account leiden tot toegang tot andere systemen?

Geplaatst op: 5 oktober 2026

Eén gehackt account lijkt op het eerste gezicht misschien een beperkt probleem. Maar in de praktijk is het voor een aanvaller vaak slechts het beginpunt van een veel grotere operatie. Via een techniek die lateral movement heet, beweegt een cybercrimineel zich na een eerste inbraak zijwaarts door een netwerk, van systeem naar systeem, totdat hij toegang heeft tot precies de data of rechten die hij zoekt. Het resultaat kan verwoestend zijn: gestolen klantdata, gegijzelde systemen of volledige toegang tot cloudinfrastructuur.

In deze gids leer je stap voor stap hoe je dit aanvalspatroon herkent, kwetsbare plekken in je toegangsbeheer blootlegt en concrete maatregelen treft om de schade van een gecompromitteerd account te beperken. Elke stap bouwt voort op de vorige, zodat je aan het einde een solide verdediging hebt staan.

Herken de aanvalstechnieken achter laterale beweging

Begrijpen hoe aanvallers te werk gaan is de eerste vereiste voor een effectieve verdediging. Lateral movement is geen willekeurig proces. Aanvallers volgen een logische redenering: ze zoeken naar de weg van de minste weerstand, combineren kleine zwaktes en bouwen zo stap voor stap hun toegang uit. Wie dit patroon herkent, kan het onderbreken voordat er echte schade ontstaat.

De meest voorkomende technieken die aanvallers inzetten na een eerste inbraak zijn:

• Credential stuffing: gestolen gebruikersnamen en wachtwoorden worden getest op andere systemen, omdat mensen dezelfde inloggegevens hergebruiken.
• Pass-the-hash en pass-the-ticket: aanvallers stelen versleutelde authenticatietokens en gebruiken die om zich als een legitieme gebruiker voor te doen, zonder het wachtwoord te kennen.
• Privilege escalation: via misconfiguraties of te ruime rechten werkt een aanvaller zich op van een gewoon gebruikersaccount naar een beheerdersaccount.
• Misbruik van vertrouwde relaties: een aanvaller maakt gebruik van de bestaande vertrouwensband tussen systemen, bijvoorbeeld tussen een werkstation en een domeincontroller.
• Living-off-the-land: de aanvaller gebruikt ingebouwde systeemtools zoals PowerShell of WMI, zodat zijn activiteiten moeilijker te onderscheiden zijn van normaal gebruik.

Controleer na het doornemen van deze technieken of je securityteam of IT-afdeling elk van deze aanvalsvormen herkent en weet welke signalen ze achterlaten in logbestanden. Als dat niet het geval is, is dat zelf al een bevinding die om actie vraagt. Een goede basis is het bestuderen van het MITRE ATT&CK-framework, dat lateral movement als afzonderlijke tactiekcategorie beschrijft met concrete subtechnieken.

Breng de zwakste schakels in je toegangsbeheer in kaart

Aanvallers zoeken altijd naar de zwakste schakel. In de meeste organisaties zitten die zwakste schakels niet in spectaculaire technische kwetsbaarheden, maar in de dagelijkse inrichting van accounts, permissies en vertrouwensrelaties. Een aanvaller die één account compromitteert, kijkt direct verder: welke rechten heeft dit account, tot welke systemen heeft het toegang en welke andere accounts of resources zijn bereikbaar?

Voer de volgende inventarisatie uit om je blootstelling te begrijpen:

1. Maak een overzicht van alle accounts met beheerdersrechten, zowel lokaal als in de cloud. Vraag jezelf af: zijn al deze rechten nog nodig?
2. Identificeer serviceaccounts en geautomatiseerde processen die met hoge rechten draaien. Dit zijn favoriete doelwitten, omdat ze zelden worden gemonitord.
3. Controleer welke accounts toegang hebben tot meerdere systemen tegelijk, inclusief cloudomgevingen zoals Azure of Microsoft 365.
4. Zoek naar accounts die al lange tijd inactief zijn maar nog steeds actief staan. Slapende accounts zijn een makkelijk instappunt.
5. Breng in kaart welke externe partijen, leveranciers of MSP’s toegang hebben tot jullie systemen en met welke rechten.

Na deze inventarisatie heb je een concreet beeld van waar een aanvaller na een eerste inbraak naartoe kan bewegen. Veel organisaties schrikken van wat ze vinden: accounts die jaren geleden zijn aangemaakt en nooit zijn opgeschoond, serviceaccounts met domeinadminrechten die eigenlijk alleen een printserver hoeven te bereiken, of externe partijen met bredere toegang dan strikt noodzakelijk. Dit overzicht is de basis voor de volgende stap.

Beperk de schade met het principe van least privilege

Met de inventarisatie in handen kun je gericht aan de slag met het beperken van rechten. Het principe van least privilege houdt in dat elk account, elke applicatie en elke service alleen de toegang krijgt die strikt noodzakelijk is voor de taak die het uitvoert. Niets meer. Dit klinkt eenvoudig, maar in de praktijk is het een van de meest impactvolle maatregelen die je kunt nemen tegen lateral movement.

Implementeer least privilege stap voor stap:

1. Verwijder overbodige beheerdersrechten van gebruikersaccounts. Geef medewerkers een apart beheerdersaccount voor taken die dat vereisen, en laat ze dagelijkse werkzaamheden uitvoeren met een account zonder verhoogde rechten.
2. Beperk de rechten van serviceaccounts tot het absolute minimum. Een account dat alleen een database moet lezen, heeft geen schrijfrechten nodig.
3. Segmenteer je netwerk zodat systemen die niet met elkaar hoeven te communiceren dat ook niet kunnen. Zo beperk je hoever een aanvaller kan reiken vanuit één gehackt systeem.
4. Activeer multi-factor authenticatie (MFA) voor alle accounts, maar zeker voor accounts met verhoogde rechten. MFA maakt credential stuffing en gestolen wachtwoorden aanzienlijk minder effectief.
5. Stel tijdgebonden toegang in voor beheerderstaken via Privileged Access Management (PAM), zodat verhoogde rechten automatisch verlopen na gebruik.

Verifieer na het doorvoeren van deze aanpassingen of de wijzigingen ook daadwerkelijk van kracht zijn. Test of een gewoon gebruikersaccount nog steeds toegang kan krijgen tot systemen waar het geen toegang toe zou mogen hebben. Kleine fouten in de configuratie kunnen een heel privilegeschema ongedaan maken. Goed toegangsbeleid is hierbij een onmisbare basis.

Detecteer verdachte accountactiviteit voordat schade ontstaat

Zelfs met de beste preventieve maatregelen is het mogelijk dat een aanvaller toch een account compromitteert. Detectie is daarom minstens even belangrijk als preventie. Hoe eerder je afwijkend gedrag signaleert, hoe kleiner de schade blijft. Lateral movement laat vrijwel altijd sporen achter in logbestanden, maar alleen als je weet waar je op moet letten.

Stel de volgende detectiemechanismen in:

1. Activeer uitgebreide logging op authenticatiepogingen, inclusief mislukte inlogpogingen en inlogpogingen op ongebruikelijke tijdstippen of vanuit onbekende locaties.
2. Stel alerts in voor accounts die zich aanmelden op meerdere systemen in korte tijd. Dit is een klassiek signaal van lateral movement.
3. Monitor het gebruik van beheerderstools zoals PowerShell, Remote Desktop Protocol (RDP) en WMI, zeker als dit buiten kantooruren plaatsvindt.
4. Gebruik User and Entity Behavior Analytics (UEBA) als dat beschikbaar is. Deze tools leren het normale gedrag van accounts kennen en slaan alarm bij afwijkingen.
5. Stel een duidelijk escalatieproces in: wie wordt er gewaarschuwd als een alert afgaat, en wat is de eerste actie?

Een goede manier om te verifiëren of je detectie werkt, is een gesimuleerde aanval. Laat iemand bewust proberen om zich met een testaccount zijwaarts door het netwerk te bewegen en controleer of de alerts daadwerkelijk afgaan. Als dat niet het geval is, weet je dat je monitoring verder moet worden aangescherpt. Red teaming is een effectieve methode om dit realistisch te testen.

Test regelmatig of aanvallers kunnen doorbreken

De voorgaande stappen geven je een sterkere verdediging, maar geen garantie. Omgevingen veranderen continu: nieuwe applicaties worden uitgerold, accounts worden aangemaakt, cloudconfiguraties worden aangepast. Wat vandaag veilig is, hoeft morgen niet meer veilig te zijn. Regelmatig testen is daarom geen luxe maar een noodzaak.

Een professionele pentest gaat verder dan een automatische vulnerability scan. Waar een scanner bekende CVE’s en technische afwijkingen vindt, kijkt een menselijke tester naar de combinatie van zwaktes: hoe kunnen een misconfiguratie, een te ruim account en een onbeveiligde cloudresource samen leiden tot volledige toegang? Aanvallers zien geen losse bevindingen, ze zien aanvalspaden. Een goede pentest doet dat ook.

Houd bij het opzetten van een testcyclus rekening met het volgende:

• Voer minimaal één grondige pentest per jaar uit als baseline, maar test ook na significante wijzigingen in je IT-omgeving.
• Laat niet alleen de technische infrastructuur testen, maar ook de reactie van je team: herkennen zij een aanval als die plaatsvindt?
• Vraag na een pentest niet alleen om een lijst met bevindingen, maar om inzicht in de volledige aanvalsketen: welke combinatie van zwaktes maakt de grootste schade mogelijk?
• Gebruik de testresultaten als input voor de volgende cyclus van verbetering, niet als eindpunt.

Na het doorlopen van een testcyclus weet je niet alleen wat er kwetsbaar is op de testdag, maar ook waar de structurele risico’s in je omgeving zitten. Dat inzicht is de basis voor een verdediging die ook stand houdt als de omgeving verandert.

Hoe Q-Cyber helpt bij het stoppen van lateral movement

Bij Q-Cyber helpen we organisaties om niet alleen te begrijpen waar ze kwetsbaar zijn, maar ook hoe een echte aanvaller die kwetsbaarheden zou combineren tot een werkend aanvalspad. Onze aanpak is praktisch, onafhankelijk en gericht op wat er echt toe doet.

Wat we concreet voor je kunnen doen:

• Handmatige pentesten waarbij onze ethical hackers denken zoals een aanvaller: niet alleen losse kwetsbaarheden, maar volledige aanvalspaden inclusief lateral movement en privilege escalation.
• Inzicht in access paths en permissies via onze scans, zodat je precies weet welke accounts en configuraties het grootste risico vormen.
• Continu inzicht via Continuous-Q®, ons programma voor organisaties die niet alleen op de testdag inzicht willen, maar het hele jaar door.
• Advies en beleidsvorming rondom toegangsbeheer, least privilege en detectie, afgestemd op jouw specifieke omgeving.

Wil je weten hoe sterk jouw verdediging is tegen lateral movement en andere aanvalstechnieken? Neem contact met ons op en we kijken samen wat de meest effectieve eerste stap is voor jouw organisatie.

Lees meer

Welke sectoren vallen onder NIS2 in Nederland?

Geplaatst op: 4 oktober 2026

In Nederland vallen organisaties uit achttien kritieke sectoren onder de NIS2-richtlijn, ook wel de Cyberbeveiligingswet (Cbw) genoemd. Denk aan energie, transport, gezondheidszorg, drinkwater, digitale infrastructuur en de overheid. De richtlijn maakt daarbij onderscheid tussen essentiële en belangrijke entiteiten, waarbij de omvang en aard van de organisatie bepalen in welke categorie zij valt. In dit artikel beantwoorden we de meest gestelde vragen over NIS2-sectoren, verplichtingen en wat niet-naleving betekent voor jouw organisatie.

Hoeveel sectoren vallen er onder de NIS2-richtlijn?

De NIS2-richtlijn onderscheidt achttien sectoren die worden gezien als kritiek voor de samenleving en economie. Deze sectoren zijn verdeeld in twee groepen: elf sectoren met een hoge kritikaliteit en zeven andere kritieke sectoren. Samen vormen zij de reikwijdte van de richtlijn zoals die in Nederland is omgezet in de Cyberbeveiligingswet.

De elf sectoren met hoge kritikaliteit zijn:

• Energie (elektriciteit, olie, gas, warmte en waterstof)
• Transport (lucht, rail, water en wegvervoer)
• Bankwezen
• Infrastructuur voor de financiële markt
• Gezondheidszorg
• Drinkwater
• Afvalwater
• Digitale infrastructuur
• ICT-dienstverlening (beheer van ICT-diensten)
• Overheid
• Ruimtevaart

Daarnaast gelden zeven andere kritieke sectoren, waaronder post- en koeriersdiensten, afvalstoffenbeheer, chemische industrie, voedingsmiddelen, industrie en productie, digitale aanbieders en onderzoek. In Nederland vallen naar schatting ruim 10.000 organisaties direct onder de NIS2. Daarbovenop krijgen naar schatting 50.000 toeleveranciers van deze organisaties indirect met de richtlijn te maken wanneer er sprake is van risico’s in de keten.

Wat zijn essentiële entiteiten onder NIS2?

Essentiële entiteiten zijn organisaties die actief zijn in de elf sectoren met hoge kritikaliteit én die boven bepaalde omvangsdrempels uitkomen. Voor private organisaties betekent dit doorgaans: meer dan 250 medewerkers of een jaaromzet van meer dan 50 miljoen euro. Voor overheidsorganisaties geldt dit omvangscriterium uitdrukkelijk niet: alle gemeenten, provincies, waterschappen, ministeries en de meeste zelfstandige bestuursorganen (ZBO’s) worden automatisch als essentiële entiteit aangemerkt.

Essentiële entiteiten vallen onder het zwaarste toezichtregime. Dat betekent proactief toezicht, strengere eisen aan de meldplicht en hogere boetes bij niet-naleving. De Rijksinspectie Digitale Infrastructuur (RDI) is voor de overheid aangewezen als toezichthouder, met uitzondering van waterschappen, waarvoor de Inspectie Leefomgeving en Transport (ILT) die rol vervult.

Wat zijn belangrijke entiteiten onder NIS2?

Belangrijke entiteiten zijn organisaties die actief zijn in de zeven andere kritieke sectoren, of die in de elf hoogstkritieke sectoren actief zijn maar onder de drempel voor essentiële entiteiten blijven. Concreet gaat het om organisaties met 50 tot 250 medewerkers of een omzet tussen 10 en 50 miljoen euro.

Het verschil met essentiële entiteiten zit voornamelijk in de intensiteit van het toezicht. Belangrijke entiteiten vallen onder reactief toezicht: de toezichthouder treedt in principe pas op na een melding of incident. De inhoudelijke verplichtingen op het gebied van risicobeheer, meldplicht en bestuurlijke verantwoordelijkheid zijn grotendeels gelijk. Compliance en beleid spelen bij beide categorieën een centrale rol in het aantonen van naleving.

Hoe weet je of jouw organisatie onder NIS2 valt?

Organisaties zijn zelf verantwoordelijk voor het bepalen of zij onder de Cyberbeveiligingswet vallen. Er is geen centrale instantie die dit automatisch vaststelt. De wet hanteert een combinatie van sectorcriterium en omvangscriterium om te bepalen of een organisatie in scope is.

Praktische hulpmiddelen om dit te beoordelen zijn:

• NIS2 Zelfevaluatietool via regelhulpenvoorbedrijven.nl/NIS-2-NL/
• Flowchart Registratieplicht van het Nationaal Cyber Security Centrum (NCSC)

Voor overheidsorganisaties gelden vier wettelijke criteria om als overheidsinstantie te kwalificeren. De organisatie moet opgericht zijn om te voorzien in behoeften van algemeen belang zonder commercieel karakter, rechtspersoonlijkheid bezitten, grotendeels publiek gefinancierd zijn en de bevoegdheid hebben om besluiten in de zin van de Algemene wet bestuursrecht te nemen. Voldoet een organisatie aan alle vier criteria, dan valt zij onder de wet.

Twijfel je of jouw organisatie in scope valt? Vrijwillige registratie bij het NCSC-portaal is al mogelijk en geeft direct toegang tot informatie over actuele cyberdreigingen. Wie nu al actie onderneemt, staat straks sterker wanneer de wet volledig van kracht is.

Welke verplichtingen gelden voor organisaties binnen NIS2-sectoren?

Organisaties die onder de NIS2-richtlijn vallen, hebben drie hoofdverplichtingen: een zorgplicht, een registratieplicht en een meldplicht. Samen vormen deze verplichtingen de kern van wat de wet van organisaties vraagt op het gebied van cyberweerbaarheid.

Zorgplicht

De zorgplicht verplicht organisaties passende technische en organisatorische maatregelen te nemen om de continuïteit van dienstverlening te waarborgen. De basis is een gedegen risicobeoordeling. Minimummaatregelen die de richtlijn voorschrijft zijn onder meer:

• Beleid voor risicoanalyse en beveiliging van informatiesystemen
• Maatregelen voor bedrijfscontinuïteit en crisisbeheer
• Beveiliging van de toeleveringsketen (supply chain security)
• Beleid voor gebruik van cryptografie en encryptie
• Toegangsbeveiliging en multi-factorauthenticatie
• Beveiliging bij verwerving, ontwikkeling en onderhoud van systemen

Registratieplicht en meldplicht

Organisaties moeten zich registreren in het entiteitenregister via het NCSC-portaal. Daarnaast geldt een meldplicht voor significante cyberincidenten: een vroegtijdige waarschuwing binnen 24 uur na ontdekking, een vervolgmelding binnen 72 uur en een eindverslag uiterlijk één maand na het incident. Meldingen verlopen via het NCSC-portaal, dat ze automatisch doorstuurt naar het relevante CSIRT en de toezichthouder.

Naast deze drie verplichtingen legt de wet ook bestuurlijke verantwoordelijkheid neer bij de politieke of bestuurlijke leiding. Bestuurders zijn verplicht een training te volgen om beveiligingsrisico’s te kunnen beoordelen en weloverwogen keuzes te maken. Voor overheidsorganisaties is als bestuur in de zin van de wet de politieke leiding aangewezen, zoals ministers en wethouders.

Wat zijn de gevolgen als je als NIS2-sector niet voldoet?

Niet-naleving van de NIS2-richtlijn kan leiden tot aanzienlijke financiële sancties en reputatieschade. Essentiële entiteiten riskeren boetes tot maximaal 10 miljoen euro of 2% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is. Voor belangrijke entiteiten liggen de maximale boetes op 7 miljoen euro of 1,4% van de wereldwijde jaaromzet.

Naast financiële sancties kan de toezichthouder ook operationele maatregelen opleggen, zoals het tijdelijk beperken van activiteiten. Senior management kan bovendien persoonlijk aansprakelijk worden gesteld bij ernstige overtredingen, wat cybersecurity tot een directe boardroomverantwoordelijkheid maakt. Voor overheidsinstanties geldt overigens dat de specifieke aansprakelijkheidsbepaling voor bestuurders bij niet-naleving uitdrukkelijk niet van toepassing is, maar de bestuurlijke verantwoordelijkheid blijft wel volledig overeind.

De toezichthouder maakt bij overheidsorganisaties maximaal gebruik van bestaande verantwoordingsstructuren, zoals de ENSIA-methodiek voor gemeenten, om de administratieve lasten te beperken. De verwachting is bovendien dat minder intensief toezicht nodig is naarmate organisaties aantoonbaar volwassener zijn in hun informatiebeveiligingspraktijk. Wie nu investeert in een solide beveiligingsaanpak, bouwt dus niet alleen aan compliance maar ook aan minder toezichtdruk op termijn.

Hoe Q-Cyber helpt met NIS2-compliance

NIS2 is complex, maar het hoeft niet overweldigend te zijn. Wij begeleiden organisaties door het volledige NIS2-traject: van het bepalen of jouw organisatie in scope valt tot het implementeren van de juiste maatregelen en het trainen van bestuurders. Onze aanpak is pragmatisch, onafhankelijk en volledig afgestemd op jouw specifieke risicoprofiel.

Wat wij voor jouw organisatie doen:

• Gap-analyse: we brengen in kaart waar jouw organisatie staat ten opzichte van de NIS2-vereisten
• Beleidsschrijving op maat: we vertalen de wettelijke vereisten naar concrete, werkbare beleidsdocumenten
• Bestuurderstrainingen: we verzorgen trainingen zodat jouw leiding de beveiligingsrisico’s begrijpt en weloverwogen keuzes kan maken
• Technische maatregelen: via Continuous-Q bieden we virtuele CISO-diensten die cybersecurity structureel inbedden in jouw organisatie
• Onafhankelijk advies: zonder binding aan softwarepartijen of toeleveranciers adviseren we altijd in jouw belang

De Rijksoverheid adviseert organisaties om niet af te wachten totdat de wet volledig van kracht is. De risico’s zijn er immers nu al. Wil je weten waar jouw organisatie staat en welke stappen als eerste gezet moeten worden? Neem contact met ons op en we helpen je direct verder.

Lees meer

Wat is privilege escalation en hoe gebruiken hackers dit?

Geplaatst op: 4 oktober 2026

Privilege escalation is een van de meest gebruikte technieken in het arsenaal van een aanvaller. Zodra een hacker voet aan de grond heeft in een systeem, is de volgende stap bijna altijd hetzelfde: meer rechten bemachtigen. Meer rechten betekent meer toegang, meer controle en uiteindelijk meer schade. Begrijpen hoe dit werkt, is de eerste stap om jezelf er effectief tegen te verdedigen.

In dit artikel leggen we uit hoe je de tekenen van privilege escalation herkent, welke vormen er bestaan, hoe aanvallers deze aanval stap voor stap uitvoeren en wat je concreet kunt doen om je systemen te beschermen.

Zo herken je de tekenen van privilege escalation

Privilege escalation begint zelden met een grote, opvallende actie. Aanvallers werken bewust onder de radar en proberen zo lang mogelijk onopgemerkt te blijven. Toch zijn er signalen die erop wijzen dat iemand probeert zijn rechten te verhogen binnen een systeem of netwerk.

Let op de volgende waarschuwingssignalen in je omgeving:

• Accounts die plotseling toegang hebben tot systemen of bestanden waarvoor ze nooit rechten hadden
• Ongebruikelijke aanmeldpogingen buiten kantooruren of vanuit onbekende locaties
• Wijzigingen in groepslidmaatschappen of rollenbeleid die niet zijn aangevraagd
• Processen of services die draaien onder een account met hogere rechten dan nodig
• Onverwachte installaties van software of het aanmaken van nieuwe beheerdersaccounts
• Logbestanden die ontbreken of zijn aangepast, wat kan wijzen op pogingen om sporen te wissen

Veel van deze signalen zijn op zichzelf niet alarmerend. Een aanvaller combineert juist meerdere kleine afwijkingen tot een werkend aanvalspad. Verificatiepunt: controleer regelmatig je auditlogs en Identity and Access Management (IAM)-rapporten op bovenstaande afwijkingen. Als je twee of meer van deze signalen tegelijk ziet, is verder onderzoek noodzakelijk.

De twee hoofdvormen van privilege escalation uitgelegd

Binnen cyberbeveiliging onderscheiden experts twee fundamenteel verschillende vormen van privilege escalation. Beide zijn gevaarlijk, maar ze vereisen een andere aanpak om ze te detecteren en te voorkomen.

Verticale privilege escalation

Bij verticale privilege escalation probeert een aanvaller zijn rechten omhoog te tillen: van een gewone gebruiker naar een beheerder, of van een beheerder naar een systeemaccount. Dit is de meest bekende vorm. Een aanvaller exploiteert hierbij bijvoorbeeld een kwetsbaarheid in het besturingssysteem, een verkeerd geconfigureerde service of een zwakke plek in een applicatie die met te hoge rechten draait. Het einddoel is volledige controle over het systeem of de omgeving.

Horizontale privilege escalation

Bij horizontale privilege escalation blijft een aanvaller op hetzelfde rechtenniveau, maar breidt hij zijn toegang uit naar andere accounts of systemen op dat niveau. Denk aan een medewerker die toegang krijgt tot de bestanden van een collega zonder dat zijn eigen rechten formeel zijn verhoogd. Deze vorm is lastiger te detecteren omdat de rechten technisch gezien niet veranderen, maar de reikwijdte van de aanvaller wel groeit. In cloudomgevingen en netwerken met veel gekoppelde identiteiten is horizontale privilege escalation bijzonder effectief.

Beide vormen worden in de praktijk vaak gecombineerd. Een aanvaller begint horizontaal om meer accounts in handen te krijgen, en gebruikt vervolgens een van die accounts als springplank voor verticale privilege escalation.

Stap voor stap: hoe aanvallers privilege escalation uitvoeren

Een privilege-escalationaanval volgt zelden een willekeurig pad. Aanvallers denken strategisch en werken methodisch. Begrijpen hoe dit proces eruitziet, helpt je om de juiste verdedigingsmaatregelen op de juiste plek te zetten.

1. Initiële toegang verkrijgen: De aanvaller begint met een beperkt toegangspunt, vaak via phishing, een gestolen wachtwoord of een kwetsbare applicatie. Op dit punt heeft hij minimale rechten.
2. Verkenning uitvoeren: Vervolgens brengt de aanvaller de omgeving in kaart. Welke accounts bestaan er? Welke permissies hebben ze? Welke services draaien er met verhoogde rechten? Welke configuratiefouten zijn aanwezig? In cloudomgevingen zoals Azure of AWS kijkt een aanvaller specifiek naar managed identities, roltoewijzingen en misconfiguraties in IAM-beleid.
3. Kwetsbaarheden identificeren: De aanvaller zoekt naar exploiteerbare zwaktes. Dit kunnen bekende CVE’s zijn in niet-gepatchte software, maar ook te ruime permissies, onveilige serviceaccounts of misconfiguraties die op zichzelf onschuldig lijken.
4. Privilege escalation uitvoeren: Met de gevonden zwaktes verhoogt de aanvaller zijn rechten. Een klassiek voorbeeld in cloudomgevingen is een combinatie van SSRF (Server-Side Request Forgery), een managed identity, Azure RBAC-rechten en toegang tot een Key Vault. Geen van deze stappen is op zichzelf kritiek, maar samen leiden ze tot volledige controle over cloudresources.
5. Persistentie opbouwen: Zodra hogere rechten zijn verkregen, zorgt de aanvaller ervoor dat hij ook na een herstart of wachtwoordwijziging toegang behoudt. Dit kan via backdoors, nieuwe beheerdersaccounts of aanpassingen aan opstartscripts.
6. Laterale beweging en verdere exploitatie: Met verhoogde rechten beweegt de aanvaller door het netwerk, compromitteert aanvullende systemen en bereikt uiteindelijk zijn einddoel, of dat nu datadiefstal, ransomware of sabotage is.

Verificatiepunt: doorloop dit aanvalsscenario mentaal voor je eigen omgeving. Welke stap zou een aanvaller bij jullie het gemakkelijkst kunnen zetten? Dat is precies waar je verdediging het zwakst is.

Beveilig je systemen tegen privilege escalation

Het goede nieuws is dat privilege escalation voorkomen grotendeels neerkomt op het consequent toepassen van bekende beveiligingsprincipes. De meeste succesvolle privilege-escalationaanvallen maken gebruik van configuratiefouten en te ruime permissies, niet van geavanceerde zero-day exploits.

Neem de volgende maatregelen om je aanvalsoppervlak te verkleinen:

• Least-privilegeprincipe: Geef accounts alleen de rechten die strikt noodzakelijk zijn voor hun taak. Controleer en beperk permissies regelmatig, ook voor serviceaccounts en geautomatiseerde processen.
• Patchmanagement: Houd besturingssystemen, applicaties en firmware consequent up-to-date. Veel privilege-escalationaanvallen maken gebruik van bekende kwetsbaarheden in niet-gepatchte software.
• Multi-factor-authenticatie (MFA): Verplicht MFA voor alle accounts, en zeker voor accounts met verhoogde rechten. Dit maakt het stelen van een wachtwoord op zichzelf onvoldoende voor toegang.
• Segmentatie en isolatie: Beperk de bewegingsvrijheid van accounts en systemen binnen het netwerk. Zorg dat een gecompromitteerd account niet automatisch toegang geeft tot alle andere systemen.
• Monitoring en logging: Log alle authenticatie- en autorisatiegebeurtenissen en stel alerts in voor afwijkend gedrag. Zonder zicht op wat er gebeurt, is detectie onmogelijk.
• Regelmatige audits van permissies: Controleer periodiek welke accounts welke rechten hebben, inclusief rollen in cloudomgevingen. Permissiecreep, het onbedoeld ophopen van rechten over tijd, is een van de meest voorkomende oorzaken van escalation-risico’s.

Verificatiepunt: voer een interne audit uit van je IAM-configuratie en controleer of er accounts zijn met meer rechten dan ze nodig hebben. Kijk ook specifiek naar serviceaccounts en geautomatiseerde processen. Als je beleid rondom toegangsbeheer nog niet schriftelijk hebt vastgelegd, is dat een logische eerste stap.

Test je weerbaarheid met continue pentesting

Beveiligingsmaatregelen treffen is één ding. Weten of ze daadwerkelijk werken, is iets anders. Omgevingen veranderen continu: er worden applicaties aangepast, nieuwe accounts aangemaakt, permissies gewijzigd en cloudresources toegevoegd. Wat vandaag veilig is geconfigureerd, kan morgen een kwetsbaarheid zijn. Een jaarlijkse pentest geeft je inzicht op één moment, maar zegt niets over de overige 364 dagen.

Effectieve weerbaarheid tegen privilege escalation vereist een aanpak die meebeweegt met die veranderingen. Dat betekent in de praktijk:

• Een grondige baseline-pentest die niet alleen losse kwetsbaarheden opspoort, maar ook aanvalspaden in kaart brengt die ontstaan door combinaties van zwaktes
• Continue monitoring van wijzigingen in permissies, rollen en configuraties die nieuwe escalation-risico’s kunnen introduceren
• Periodieke herhaling van gerichte tests op de meest kritieke systemen en identiteiten
• Inzicht in hoe aanvallers jouw specifieke omgeving zouden benaderen, niet alleen een lijst met gevonden CVE’s

Een redteamoefening gaat hierin nog een stap verder: een gesimuleerde aanvaller probeert actief privilege escalation toe te passen in jouw omgeving, zodat je precies ziet waar de zwakste schakels zitten.

Hoe Q-Cyber helpt met privilege escalation

Wij bij Q-Cyber helpen organisaties om privilege escalation niet alleen te begrijpen, maar ook structureel te voorkomen en tijdig te detecteren. Onze aanpak gaat verder dan het uitvoeren van een standaard kwetsbaarheidsscan. We kijken zoals een echte aanvaller: we onderzoeken aanvalspaden, combinaties van misconfiguraties en identity-zwaktes die samen een groter risico vormen dan elk afzonderlijk.

Concreet bieden we hiervoor:

• Handmatige pentests waarbij onze ethical hackers actief proberen privileges te escaleren via dezelfde technieken als echte aanvallers, inclusief cloud- en identity-specifieke aanvalspaden
• Redteamoefeningen voor een realistische simulatie van hoe een aanvaller jouw omgeving zou doorlopen van initiële toegang tot volledige controle
• Continuous-Q®, ons programma voor continue offensieve security waarbij we na de baseline-pentest doorlopend meekijken naar nieuwe risico’s die ontstaan door wijzigingen in je omgeving
• Concrete rapportages met geprioriteerde bevindingen en praktisch advies, zodat je direct weet wat je als eerste moet aanpakken

Wil je weten hoe kwetsbaar jouw organisatie is voor privilege escalation? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer