Hoe stel je een informatiebeveiligingsbeleid op?

Geplaatst op: 18 september 2026

Een informatiebeveiligingsbeleid opstellen begint met het vastleggen van de doelstellingen, scope, verantwoordelijkheden en maatregelen die jouw organisatie hanteert om informatie te beschermen. Het beleid vormt de schriftelijke basis waarop alle overige beveiligingsmaatregelen en procedures steunen. In dit artikel beantwoorden we de meest gestelde vragen over het schrijven van een sterk informatiebeveiligingsbeleid, van de inhoud tot de aansluiting op NIS2-verplichtingen.

Wat moet er in een informatiebeveiligingsbeleid staan?

Een informatiebeveiligingsbeleid bevat minimaal de beveiligingsdoelstellingen van de organisatie, de scope van het beleid, de rolverdeling en verantwoordelijkheden, de risicobereidheid en de maatregelen die worden ingezet om informatie te beschermen. Daarnaast hoort er een verwijzing in te staan naar onderliggende procedures en een beschrijving van hoe het beleid wordt gehandhaafd en getoetst.

In de praktijk ziet een goed informatiebeveiligingsbeleid er als volgt uit:

• Doelstelling en context: Waarom bestaat dit beleid en welke waarden beschermt het?
• Scope: Op welke systemen, processen, locaties en medewerkers is het beleid van toepassing?
• Principes en uitgangspunten: De kernbeginselen zoals vertrouwelijkheid, integriteit en beschikbaarheid (de CIA-triade).
• Rollen en verantwoordelijkheden: Wie is waarvoor verantwoordelijk, van bestuur tot eindgebruiker?
• Risicobereidheid: Welk niveau van risico accepteert de organisatie?
• Maatregelen: Een overzicht van de technische en organisatorische beveiligingsmaatregelen.
• Incidentbeheer: Hoe wordt omgegaan met beveiligingsincidenten?
• Naleving en handhaving: Hoe wordt gecontroleerd of het beleid wordt nageleefd?
• Verwijzingen: Links naar onderliggende procedures, werkinstructies en standaarden zoals ISO 27001 of de BIO2.

Het beleid hoeft geen technisch handboek te zijn. Het is een strategisch document dat richting geeft. De technische details horen thuis in onderliggende procedures en werkinstructies. Houd de taal toegankelijk zodat iedereen in de organisatie begrijpt wat er van hen wordt verwacht.

Hoe bepaal je de scope van je informatiebeveiligingsbeleid?

De scope van een informatiebeveiligingsbeleid bepaal je door in kaart te brengen welke informatiesystemen, processen, locaties en medewerkers onder het beleid vallen. Een goede scope is zo breed dat alle kritieke informatie wordt gedekt, maar zo concreet dat het beleid uitvoerbaar blijft. Begin altijd met een inventarisatie van de informatie die de organisatie verwerkt en de risico’s die daarbij horen.

Bij het bepalen van de scope spelen de volgende vragen een rol:

• Welke informatiesystemen en applicaties verwerken gevoelige of kritieke gegevens?
• Welke bedrijfsprocessen zijn afhankelijk van die systemen?
• Zijn er externe partijen, leveranciers of cloudproviders die toegang hebben tot jouw informatie?
• Welke locaties of afdelingen zijn relevant, inclusief thuiswerkers?
• Welke wet- en regelgeving is van toepassing, zoals de AVG of de Cyberbeveiligingswet?

Een veelgemaakte fout is het opstellen van een beleid dat op papier alles omvat, maar in de praktijk nergens concreet op ingaat. Kies liever een heldere, afgebakende scope die je daadwerkelijk kunt handhaven. Als de organisatie groeit of de dienstverlening verandert, pas je de scope aan bij de eerstvolgende herziening.

Voor organisaties die onder de NIS2-regelgeving vallen, is het bijzonder belangrijk om de toeleveringsketen mee te nemen in de scope. De zorgplicht vereist namelijk inzicht in de cybersecuritymaatregelen van leveranciers die toegang hebben tot jouw systemen of gegevens.

Wie is verantwoordelijk voor het informatiebeveiligingsbeleid?

De eindverantwoordelijkheid voor het informatiebeveiligingsbeleid ligt bij het bestuur of de directie van de organisatie. Het dagelijks beheer en de uitvoering worden doorgaans belegd bij een Chief Information Security Officer (CISO) of een vergelijkbare functionaris. Lijnmanagers zijn verantwoordelijk voor de naleving binnen hun eigen afdeling of domein.

Een heldere rolverdeling ziet er in de meeste organisaties als volgt uit:

• Bestuur of directie: Stelt het beleid vast, draagt eindverantwoordelijkheid en zorgt voor voldoende budget en prioriteit.
• CISO of Information Security Officer (ISO): Ontwikkelt, beheert en actualiseert het beleid en adviseert het bestuur.
• Lijnmanagers: Zorgen dat medewerkers het beleid kennen en naleven.
• Medewerkers: Handelen conform het beleid en melden afwijkingen of incidenten.
• IT-afdeling: Implementeert de technische maatregelen die voortvloeien uit het beleid.

Onder de Cyberbeveiligingswet (de Nederlandse implementatie van NIS2) is de bestuurlijke verantwoordelijkheid voor informatiebeveiliging wettelijk verankerd. Voor overheidsorganisaties is dat de politieke leiding, zoals ministers of wethouders. Bestuurders zijn verplicht een training te volgen om beveiligingsrisico’s te kunnen herkennen en beoordelen. Dit maakt informatiebeveiliging nadrukkelijk een boardroomonderwerp en geen louter technische aangelegenheid.

Hoe vaak moet een informatiebeveiligingsbeleid worden herzien?

Een informatiebeveiligingsbeleid moet minimaal jaarlijks worden herzien. Daarnaast is een tussentijdse herziening noodzakelijk na ingrijpende veranderingen in de organisatie, de technologie of de dreigingsomgeving. Denk aan een overname, een nieuwe cloudstrategie, een ernstig beveiligingsincident of nieuwe wet- en regelgeving.

Jaarlijkse herziening is de standaard die wordt gehanteerd in gangbare normenkaders zoals ISO 27001 en de Baseline Informatiebeveiliging Overheid (BIO2). Bij die herziening stel je jezelf de volgende vragen:

• Is de scope nog actueel, of zijn er nieuwe systemen, processen of leveranciers bijgekomen?
• Zijn de verantwoordelijkheden nog correct belegd?
• Zijn er nieuwe dreigingen of kwetsbaarheden die om aanpassing vragen?
• Zijn er incidenten geweest waaruit lessen zijn getrokken die in het beleid moeten worden verwerkt?
• Zijn er wettelijke of regelgevende wijzigingen die impact hebben op het beleid?

Het vastleggen van de herzieningsdatum en de versiehistorie in het document zelf is een goede praktijk. Zo is altijd aantoonbaar wanneer het beleid voor het laatst is beoordeeld en welke wijzigingen zijn doorgevoerd. Dit is ook relevant voor toezichthouders die willen zien dat informatiebeveiliging actief wordt beheerd en niet slechts op papier bestaat.

Wat is het verschil tussen een informatiebeveiligingsbeleid en een beveiligingsprocedure?

Een informatiebeveiligingsbeleid beschrijft wat de organisatie wil bereiken en waarom, terwijl een beveiligingsprocedure beschrijft hoe dat in de praktijk wordt uitgevoerd. Het beleid is strategisch en richtinggevend; de procedure is operationeel en stap-voor-stap.

Het onderscheid is eenvoudig te illustreren aan de hand van een voorbeeld. Het informatiebeveiligingsbeleid stelt dat toegang tot gevoelige systemen uitsluitend is voorbehouden aan geautoriseerde medewerkers. De bijbehorende procedure beschrijft vervolgens hoe een toegangsaanvraag wordt ingediend, wie die aanvraag goedkeurt, hoe toegang wordt ingetrokken bij vertrek en hoe dit wordt geregistreerd.

De hiërarchie ziet er in de meeste organisaties als volgt uit:

1. Beleid: Het overkoepelende document met doelstellingen, principes en verantwoordelijkheden.
2. Standaarden en richtlijnen: Specificeren de minimale eisen en aanbevelingen per onderwerp, zoals wachtwoordbeleid of versleutelingsstandaarden.
3. Procedures: Stap-voor-stap beschrijvingen van hoe specifieke taken worden uitgevoerd.
4. Werkinstructies: Gedetailleerde instructies voor specifieke systemen of handelingen.

Een veelgemaakte fout is het samenvoegen van beleid en procedures in één document. Dit maakt het document onnodig lang, moeilijk te onderhouden en lastig te communiceren. Houd beide gescheiden en zorg voor duidelijke verwijzingen vanuit het beleid naar de onderliggende procedures.

Hoe sluit een informatiebeveiligingsbeleid aan op NIS2-verplichtingen?

Een informatiebeveiligingsbeleid sluit aan op NIS2-verplichtingen door expliciet de zorgplicht te adresseren die de Cyberbeveiligingswet oplegt. Dat betekent dat het beleid aantoonbaar ingaat op risicobeheersing, toegangsbeheer, cryptografie, incidentbeheer, bedrijfscontinuïteit en supply chain-beveiliging. NIS2 vereist niet alleen dat maatregelen worden genomen, maar ook dat cybersecurity structureel is ingebed in beleid, processen en bestuur.

De NIS2-richtlijn, die in Nederland wordt omgezet via de Cyberbeveiligingswet (Cbw), stelt concrete eisen aan de inhoud van het beveiligingsbeleid. De volgende elementen moeten aantoonbaar zijn geborgd:

• Risicoanalyse en beleid: Een gedocumenteerde aanpak voor het identificeren en beheersen van cybersecurityrisico’s.
• Incidentbeheer: Procedures voor detectie, respons en melding van beveiligingsincidenten, inclusief de verplichting om ernstige incidenten binnen 24 uur te melden bij de bevoegde autoriteit.
• Bedrijfscontinuïteit: Maatregelen voor back-up, herstel en crisisbeheersing.
• Supply chain-beveiliging: Inzicht in en eisen aan de cybersecuritymaatregelen van leveranciers.
• Toegangsbeheer en cryptografie: Beleid voor wie toegang heeft tot welke systemen en hoe gegevens worden versleuteld.
• Bestuurlijke verantwoordelijkheid: Aantoonbare betrokkenheid van het bestuur, inclusief het volgen van een verplichte training.

Voor overheidsorganisaties biedt de BIO2 een praktisch normenkader dat grotendeels de NIS2-zorgplicht invult. Organisaties die al werken conform de BIO2 hebben daarmee een solide basis voor NIS2-compliance. Voor private organisaties biedt ISO 27001 een vergelijkbaar houvast. In beide gevallen geldt dat het beleid niet alleen moet bestaan, maar ook aantoonbaar moet worden uitgevoerd en periodiek getoetst.

Hoe Q-Cyber helpt met het opstellen van een informatiebeveiligingsbeleid

Een goed informatiebeveiligingsbeleid opstellen vraagt om meer dan een sjabloon invullen. Het vereist inzicht in de specifieke risico’s van jouw organisatie, kennis van de geldende wet- en regelgeving en de vaardigheid om beleid te schrijven dat zowel bestuurlijk gedragen als operationeel uitvoerbaar is. Wij combineren technische expertise met beleidsmatige kennis en helpen organisaties concreet verder:

• Wij voeren een gap-analyse uit om te bepalen welke onderdelen van het beleid ontbreken of onvoldoende zijn uitgewerkt.
• Wij schrijven een op maat gemaakt informatiebeveiligingsbeleid dat aansluit op jouw sector, risicoprofiel en eventuele NIS2-verplichtingen.
• Wij verzorgen trainingen voor bestuurders die voldoen aan de trainingsplicht onder de Cyberbeveiligingswet.
• Via onze Continuous-Q dienstverlening bieden wij een virtuele CISO die het beleid actief beheert, actualiseert en bewaakt.
• Wij adviseren pragmatisch en onafhankelijk, zonder binding aan softwarepartijen of toeleveranciers.

Of je nu voor het eerst een informatiebeveiligingsbeleid opstelt of een bestaand beleid wilt versterken met het oog op NIS2: wij helpen je verder. Neem contact op voor een vrijblijvend gesprek over jouw situatie.

Lees meer

Wat is een security baseline?

Geplaatst op: 17 september 2026

Een security baseline is een minimumset van beveiligingsmaatregelen die een organisatie verplicht toepast op alle systemen, netwerken en processen. Het is het vertrekpunt voor cybersecurity: de ondergrens waaronder geen enkel systeem mag zakken. Elke organisatie die serieus omgaat met IT-beveiliging heeft zo’n baseline nodig, ongeacht haar omvang of sector. In dit artikel beantwoorden we de meest gestelde vragen over het opstellen, onderhouden en toepassen van een cybersecurity baseline.

Waarom hebben organisaties een security baseline nodig?

Organisaties hebben een security baseline nodig omdat, zonder een vastgesteld minimumniveau van beveiliging, ieder systeem en ieder team zijn eigen aanpak hanteert, wat onvermijdelijk leidt tot blinde vlekken en inconsistente bescherming. Een beveiligingsbaseline zorgt voor een gedeeld fundament waarop alle verdere beveiligingsmaatregelen worden gebouwd.

In de praktijk zien we dat cyberaanvallen maar al te vaak binnenkomen via de zwakste schakel: een server zonder patchbeheer, een account zonder multi-factorauthenticatie, of een afdeling die nooit een bewustwordingstraining heeft gevolgd. Een IT-beveiligingsbaseline sluit die zwakke plekken systematisch af door voor de hele organisatie dezelfde basisvereisten te stellen.

Daarnaast is een security baseline steeds vaker een wettelijke verplichting. Onder de NIS2-richtlijn en de Cyberbeveiligingswet moeten organisaties aantoonbaar passende technische en organisatorische maatregelen nemen. Een gedocumenteerde en geïmplementeerde baseline vormt het bewijs dat een organisatie haar zorgplicht serieus neemt. Voor overheden geldt bovendien de Baseline Informatiebeveiliging Overheid (BIO2) als verplicht normenkader.

Tot slot maakt een baseline het gesprek over cybersecurity behapbaar. In plaats van eindeloze discussies over welke maatregel wel of niet nodig is, biedt de baseline een helder referentiekader voor bestuurders, IT-teams en auditors.

Wat hoort er in een security baseline thuis?

Een security baseline bevat de minimale beveiligingsmaatregelen die voor alle systemen en medewerkers binnen een organisatie gelden, ongeacht het specifieke risicoprofiel van een afdeling of applicatie. Denk aan patchbeheer, toegangsbeheer, encryptie, logging en bewustwording.

Concreet bestaat een volledige cybersecurity baseline doorgaans uit de volgende onderdelen:

• Toegangsbeheer: sterke wachtwoorden, multi-factorauthenticatie en het principe van minimale rechten (least privilege)
• Patchbeheer: tijdig installeren van beveiligingsupdates voor alle systemen en software
• Encryptie: versleuteling van gegevens in transit en in rust, inclusief beleid voor het gebruik van cryptografie
• Logging en monitoring: vastleggen van relevante gebeurtenissen en actief bewaken op afwijkingen
• Netwerksegmentatie: scheiden van systemen zodat een aanvaller niet vrij door het netwerk kan bewegen
• Back-up en herstel: regelmatige, geteste back-ups en een gedocumenteerd herstelproces
• Bewustwording: periodieke training voor medewerkers over phishing, social engineering en veilig gedrag
• Supply chain-beveiliging: inzicht in de beveiligingsmaatregelen van leveranciers en partners
• Incidentrespons: een beschreven proces voor het detecteren, melden en afhandelen van beveiligingsincidenten

Welke specifieke normen en drempelwaarden je hanteert, hangt af van het gekozen referentiekader. Gangbare kaders zijn ISO 27002, de BIO2 voor overheidsorganisaties of het NIST Cybersecurity Framework. Belangrijk is dat de baseline niet alleen technisch van aard is: organisatorische en beleidsmatige maatregelen zijn minstens zo essentieel.

Hoe stel je een security baseline op?

Je stelt een security baseline op door eerst een risicoanalyse uit te voeren, vervolgens een passend normenkader te kiezen, de minimummaatregelen te definiëren en deze te documenteren en te implementeren. Het is een gestructureerd proces dat start vanuit de risico’s van de organisatie, niet vanuit een willekeurige lijst met technische maatregelen.

Stap 1: Breng de context en risico’s in kaart

Inventariseer welke systemen, gegevens en processen kritisch zijn voor de organisatie. Stel vast welke dreigingen realistisch zijn en wat de potentiële impact is van een beveiligingsincident. Deze risicoanalyse vormt de onderbouwing voor de keuzes die je later maakt.

Stap 2: Kies een normenkader als basis

Gebruik een erkend kader als startpunt, zoals ISO 27002, de BIO2 of het NIST Cybersecurity Framework. Zo hoef je niet alles zelf te bedenken en kun je aantonen dat je baseline is gebaseerd op breed geaccepteerde standaarden. Voor organisaties die onder de NIS2 vallen, biedt de mapping van NIS2-maatregelen ten opzichte van ISO 27002 en de BIO een handig overzicht van verplichte, optionele en situationele maatregelen.

Stap 3: Definieer de minimummaatregelen

Vertaal de uitkomsten van je risicoanalyse en het gekozen normenkader naar concrete, meetbare maatregelen. Formuleer ze zo specifiek dat een IT-beheerder precies weet wat er van hem verwacht wordt. Denk aan: “Alle accounts met beheerdersrechten maken gebruik van multi-factorauthenticatie” in plaats van “Toegangsbeveiliging is op orde.”

Stap 4: Documenteer, communiceer en implementeer

Een baseline die alleen op papier bestaat, heeft geen waarde. Zorg voor draagvlak bij bestuurders en IT-teams, leg de baseline vast in beleid, en zet een implementatieplan op. Een penetratietest of vulnerability scan kan helpen om te toetsen of de geïmplementeerde maatregelen daadwerkelijk werken zoals bedoeld.

Wat is het verschil tussen een security baseline en een security policy?

Een security baseline beschrijft de minimale technische en organisatorische maatregelen die een organisatie verplicht implementeert. Een security policy is het overkoepelende beleidsdocument dat de doelstellingen, verantwoordelijkheden en uitgangspunten van de informatiebeveiliging vastlegt. De baseline is dus een concrete uitwerking van de policy.

Vergelijk het met een bouwproject: de security policy is het bestemmingsplan dat bepaalt wat er mag worden gebouwd en waarom. De security baseline is het bouwbesluit dat de minimale technische eisen vastlegt waaraan elk gebouw moet voldoen. Beide zijn nodig, maar ze opereren op een ander abstractieniveau.

In de praktijk betekent dit het volgende onderscheid:

• Security policy: “Wij beschermen de vertrouwelijkheid, integriteit en beschikbaarheid van onze informatiesystemen en houden ons aan geldende wet- en regelgeving.”
• Security baseline: “Alle servers draaien een ondersteunde versie van het besturingssysteem, worden maandelijks gepatcht en loggen authenticatiegebeurtenissen naar een centrale SIEM.”

Een security policy zonder baseline blijft vaag en moeilijk te handhaven. Een baseline zonder policy mist de strategische inbedding en het bestuurlijk mandaat. De twee documenten versterken elkaar en vormen samen de ruggengraat van een volwassen beveiligingsprogramma.

Hoe weet je of je security baseline nog actueel is?

Je weet dat een security baseline actueel is als deze regelmatig wordt getoetst aan nieuwe dreigingen, gewijzigde wet- en regelgeving en veranderingen in de IT-omgeving van de organisatie. Een baseline die twee jaar geleden is opgesteld en sindsdien niet is herzien, is in de meeste gevallen verouderd.

Concrete signalen dat een herziening nodig is:

• Er zijn nieuwe technologieën of systemen in gebruik genomen die niet in de baseline zijn opgenomen
• Er heeft een beveiligingsincident plaatsgevonden dat heeft aangetoond dat de huidige maatregelen ontoereikend zijn
• Wet- en regelgeving is gewijzigd, zoals de inwerkingtreding van de Cyberbeveiligingswet (verwacht in 2026)
• Een externe audit of penetratietest heeft kwetsbaarheden blootgelegd die de baseline niet afdekt
• Het dreigingslandschap is veranderd, bijvoorbeeld door de opkomst van nieuwe aanvalstechnieken

Als goede praktijk geldt: beoordeel de baseline minimaal één keer per jaar formeel, en voer tussentijdse updates door na significante wijzigingen in de organisatie of het dreigingslandschap. Koppel dit beoordelingsmoment bij voorkeur aan de jaarlijkse risicoanalyse, zodat de baseline altijd aansluit op de actuele risico’s. Organisaties die gebruik maken van een virtuele CISO-dienst hebben een vaste sparringpartner die dit proces structureel bewaakt.

Hoe Q-Cyber helpt met het opstellen van een security baseline

Een goede security baseline opstellen klinkt overzichtelijk, maar vraagt in de praktijk om technische kennis, beleidsexpertise en een helder beeld van de risico’s die specifiek voor jouw organisatie gelden. Wij helpen organisaties bij elke stap van dit proces, van risicoanalyse tot implementatie en borging.

Wat wij concreet voor je doen:

• Gap-analyse: we brengen in kaart waar jouw huidige beveiliging afwijkt van een erkend normenkader zoals ISO 27002 of de BIO2
• Beleid op maat: we schrijven een security baseline die aansluit op jouw organisatie, sector en wettelijke verplichtingen, waaronder NIS2
• Technische toetsing: via vulnerability scans en penetratietests valideren we of de geïmplementeerde maatregelen daadwerkelijk werken
• Training en bewustwording: we verzorgen trainingen voor bestuurders en medewerkers zodat de baseline niet alleen op papier bestaat
• Continu beheer: via onze vCISO-dienst bewaken we proactief of jouw baseline actueel blijft en passen we deze aan bij nieuwe dreigingen of regelgeving

Wij werken onafhankelijk, zonder binding aan softwarepartijen, en geven altijd pragmatisch advies dat past bij de realiteit van jouw organisatie. Wil je weten waar jouw baseline nu staat en wat er nodig is om die op het gewenste niveau te brengen? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Veilig softwareontwikkeling: basisprincipes

Geplaatst op: 16 september 2026

Veilige softwareontwikkeling betekent dat beveiliging structureel is ingebouwd in elk onderdeel van het ontwikkelproces, van ontwerp tot deployment. De basisprincipes omvatten threat modeling, secure coding, geautomatiseerde beveiligingstests en continue monitoring. Dit geldt voor elk team dat software bouwt of beheert, ongeacht de omvang of sector. De vragen hieronder behandelen de meest essentiële aspecten van softwarebeveiliging in de praktijk.

Wat zijn de grootste beveiligingsrisico’s bij softwareontwikkeling?

De grootste beveiligingsrisico’s bij softwareontwikkeling zijn onveilige invoerverwerking, gebrekkig toegangsbeheer, blootstelling van gevoelige gegevens en het gebruik van kwetsbare afhankelijkheden. Deze risico’s komen terug in vrijwel elke applicatie en zijn verantwoordelijk voor het overgrote deel van succesvolle aanvallen op softwaresystemen.

De OWASP Top 10 is de meest gebruikte referentie voor veelvoorkomende kwetsbaarheden in webapplicaties. Denk aan SQL-injectie, waarbij een aanvaller via invoervelden directe toegang tot een database kan krijgen, of aan broken access control, waarbij gebruikers buiten hun eigen rechten kunnen handelen. Cross-site scripting (XSS) en onveilige deserialisatie zijn andere klassiekers die jaar na jaar terugkeren.

Naast de technische kwetsbaarheden is er een organisatorisch risico dat vaak onderschat wordt: het gebruik van verouderde of onbeheerde softwarecomponenten. Veel applicaties zijn opgebouwd uit open source bibliotheken. Als die bibliotheken niet actief worden bijgehouden, ontstaan er kwetsbaarheden in de toeleveringsketen, ook wel supply chain-risico’s genoemd. Aanvallers richten zich steeds vaker op deze zwakke schakels in plaats van op de applicatie zelf.

Een ander structureel risico is het ontbreken van beveiligingsvereisten in de beginfase van een project. Wanneer beveiliging pas laat in het ontwikkeltraject wordt meegenomen, zijn kwetsbaarheden al diep ingebakken in de architectuur en zijn ze kostbaar om te herstellen.

Wat is het verschil tussen security by design en security testing?

Security by design betekent dat beveiliging vanaf het eerste ontwerp wordt meegenomen als een fundamentele vereiste, niet als een toevoeging achteraf. Security testing is het achteraf controleren of een gebouwde applicatie kwetsbaarheden bevat. Beide zijn noodzakelijk, maar security by design voorkomt problemen terwijl security testing ze opspoort.

Bij security by design stelt een team al in de ontwerpfase vragen als: welke data verwerken we, wie heeft toegang tot welke functionaliteit en hoe gaan we om met authenticatie en autorisatie? Deze keuzes worden vastgelegd in de architectuur voordat er ook maar één regel code is geschreven. Het gevolg is dat beveiligingsmaatregelen organisch onderdeel worden van de applicatiestructuur.

Security testing, zoals een penetratietest, vindt plaats nadat software is gebouwd. Een tester of geautomatiseerd systeem probeert actief kwetsbaarheden te vinden door de applicatie aan te vallen op dezelfde manier als een kwaadwillende dat zou doen. Dit is waardevol, maar het heeft een beperking: als de architectuur fundamenteel onveilig is, kunnen tests symptomen blootleggen maar de oorzaak niet wegnemen.

De meest volwassen aanpak combineert beide: een stevige beveiligingsbasis door design, aangevuld met regelmatige tests om te verifiëren dat de implementatie ook in de praktijk werkt. Security by design zonder testing is zelfgenoegzaam. Security testing zonder design is dweilen met de kraan open.

Hoe werkt threat modeling in de praktijk?

Threat modeling is een gestructureerde methode waarbij een team systematisch nadenkt over wie een applicatie zou willen aanvallen, hoe dat zou kunnen gebeuren en welke schade dat zou veroorzaken. In de praktijk gebeurt dit tijdens de ontwerpfase, vaak aan de hand van een dataflowdiagram en een gestandaardiseerd raamwerk zoals STRIDE.

Een praktische threat modeling sessie volgt doorgaans vier stappen:

1. Modelleer het systeem: teken de architectuur uit, inclusief alle datastromen, componenten, gebruikers en externe systemen.
2. Identificeer bedreigingen: gebruik een raamwerk zoals STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) om systematisch bedreigingen per component te benoemen.
3. Beoordeel risico’s: weeg de kans en impact van elke bedreiging af om prioriteiten te stellen.
4. Bepaal tegenmaatregelen: koppel aan elke relevante bedreiging een concrete maatregel, of accepteer bewust een risico als de impact laag genoeg is.

Threat modeling hoeft niet ingewikkeld te zijn. Een whiteboard sessie van twee uur met het ontwikkelteam en een security specialist levert al aanzienlijk meer inzicht op dan geen sessie. Het doel is niet perfectie, maar bewustzijn: weet het team wat ze bouwen, voor wie en wat er mis kan gaan?

Threat modeling is ook een levend document. Wanneer de architectuur verandert, een nieuwe integratie wordt toegevoegd of een nieuwe gebruikersrol wordt geïntroduceerd, is het tijd om het model te herzien.

Welke secure coding-principes moet elk ontwikkelteam kennen?

Elk ontwikkelteam moet minimaal de volgende secure coding-principes beheersen: inputvalidatie, het principe van least privilege, veilig sessiebeheer, foutafhandeling zonder informatielekkage en het gebruik van bewezen cryptografische standaarden. Deze principes vormen de ruggengraat van basisprincipes softwarebeveiliging en zijn van toepassing ongeacht de gebruikte programmeertaal of het platform.

Input validatie en output encoding

Vertrouw nooit op invoer van een gebruiker of een extern systeem. Valideer altijd of invoer voldoet aan het verwachte formaat, type en bereik, en gebruik output encoding om te voorkomen dat data als uitvoerbare code wordt geïnterpreteerd. Dit is de primaire verdediging tegen injectie-aanvallen en cross-site scripting.

Least privilege en veilig sessiebeheer

Elke component, gebruiker en service mag alleen toegang hebben tot wat strikt noodzakelijk is voor zijn functie. Dit beperkt de schade als een onderdeel wordt gecompromitteerd. Combineer dit met veilig sessiebeheer: gebruik korte sessietijden, veilige cookies met de juiste attributen en invalideer sessies direct na uitloggen of na een wachtwoordwijziging.

Twee andere principes die elk team moet internaliseren: foutmeldingen mogen nooit technische details bevatten die een aanvaller helpen, en cryptografie moet altijd gebaseerd zijn op actuele, gestandaardiseerde algoritmen. Zelf cryptografie implementeren is een veelgemaakte fout die bijna altijd tot kwetsbaarheden leidt.

Wanneer moet een organisatie een penetratietest laten uitvoeren?

Een organisatie moet een penetratietest laten uitvoeren bij de lancering van een nieuwe applicatie, na significante architectuurwijzigingen, bij de verwerking van gevoelige of persoonsgebonden data en als onderdeel van een jaarlijkse beveiligingscyclus. Voor organisaties die onder regelgeving zoals NIS2 vallen, is periodieke penetratietesting bovendien een verwachte maatregel binnen de zorgplicht.

Naast deze vaste momenten zijn er specifieke situaties die een directe aanleiding vormen voor een test:

• Na een beveiligingsincident, om te achterhalen hoe de aanvaller is binnengekomen en of er nog andere kwetsbaarheden bestaan.
• Voorafgaand aan een audit of certificering, zoals ISO 27001 of een NIS2-compliance check.
• Bij de integratie van een overgenomen applicatie of systeem waarvan de beveiligingsstatus onbekend is.
• Wanneer een derde partij toegang krijgt tot kritieke systemen via een nieuwe koppeling of API.

Een penetratietest simuleert een echte aanval op een gecontroleerde manier. De tester probeert actief in te breken, rapporteert wat er is gevonden en geeft advies over herstel. De waarde zit niet alleen in de gevonden kwetsbaarheden, maar ook in het inzicht dat een externe, onbevooroordeelde blik oplevert over de werkelijke staat van de beveiliging. Meer informatie over wat een dergelijke test inhoudt, vind je op de pagina over pentesten.

Hoe integreer je beveiliging in een CI/CD-pipeline?

Beveiliging integreer je in een CI/CD-pipeline door geautomatiseerde beveiligingscontroles toe te voegen als verplichte stappen in het buildproces. Dit omvat statische code-analyse (SAST), controle op kwetsbare afhankelijkheden (SCA) en dynamische tests (DAST) die draaien als onderdeel van elke deploymentcyclus. Dit principe staat bekend als DevSecOps.

De meest effectieve integratie volgt een gelaagde aanpak:

• Bij elke commit: voer een statische analyse uit die de broncode controleert op bekende kwetsbare patronen, zoals hardcoded wachtwoorden of onveilige functies.
• Bij elke build: controleer automatisch of gebruikte bibliotheken en afhankelijkheden bekende kwetsbaarheden bevatten via tools zoals Dependabot of Snyk.
• Bij deployment naar een testomgeving: voer dynamische tests uit die de draaiende applicatie aanvallen op veelvoorkomende kwetsbaarheden.
• Voor productie: voer een handmatige review uit van beveiligingsgevoelige wijzigingen en zorg dat secrets nooit in de codebase terechtkomen via secrets scanning.

Een veelgemaakte fout is het toevoegen van te veel beveiligingstools tegelijk, waardoor de pipeline traag wordt en ontwikkelaars meldingen gaan negeren. Begin met een beperkte set van hoge-waarde controles, stel drempelwaarden in die daadwerkelijk de build laten falen bij kritieke bevindingen en bouw van daaruit verder. Beveiliging in de pipeline werkt alleen als het team de resultaten serieus neemt en er actief op handelt.

Voor organisaties die willen weten hoe hun huidige beveiligingspraktijk zich verhoudt tot de eisen van relevante wet- en regelgeving, biedt de pagina over cybersecurity regelgeving een goed startpunt.

Hoe Q-Cyber helpt met veilige softwareontwikkeling

Veilige softwareontwikkeling is geen eenmalig project, maar een doorlopend proces dat technische kennis, beleid en bewustzijn combineert. Q-Cyber ondersteunt organisaties bij het opbouwen van die capaciteit, van de eerste risicoanalyse tot de implementatie van concrete maatregelen. Onze aanpak is pragmatisch en onafhankelijk: we zijn niet gebonden aan softwarepartijen en adviseren wat werkelijk past bij jouw organisatie en risicoprofiel.

Wat we concreet bieden op het gebied van softwarebeveiliging:

• Penetratietesten en vulnerability scans om kwetsbaarheden in applicaties en infrastructuur bloot te leggen voordat aanvallers dat doen.
• Secure development advies inclusief threat modeling sessies en begeleiding bij het opzetten van een DevSecOps aanpak.
• Beleidsvorming en NIS2-begeleiding voor organisaties die moeten aantonen dat softwarebeveiliging structureel is geborgd in processen en governance.
• Trainingen en bewustwording voor ontwikkelteams en bestuurders, zodat beveiliging niet alleen op papier staat maar ook in de praktijk wordt toegepast.
• Virtuele CISO-diensten via ons Continuous-Q programma, waarbij een team van specialisten structureel meekijkt en adviseert.

Wil je weten waar jouw organisatie nu staat en welke stappen het meeste impact hebben? Neem contact op en we denken graag met je mee.

Lees meer

Wat is applicatiebeveiliging en waarom is het belangrijk?

Geplaatst op: 15 september 2026

Applicatiebeveiliging is het geheel van maatregelen, processen en technieken waarmee software en applicaties worden beschermd tegen ongeautoriseerde toegang, aanvallen en datalekken. Het is een essentieel onderdeel van elke cybersecuritystrategie, omdat applicaties direct in contact staan met gebruikers, klanten en gevoelige bedrijfsdata. In dit artikel beantwoorden we de meest gestelde vragen over app security: van de risico’s en kwetsbaarheden tot praktische tests en het juiste moment om te beginnen.

Welke risico’s ontstaan er zonder applicatiebeveiliging?

Zonder applicatiebeveiliging lopen organisaties het risico dat aanvallers via kwetsbare software toegang krijgen tot systemen, klantgegevens stelen, processen verstoren of ransomware installeren. Applicaties zijn een van de meest aangevallen ingangspunten voor cybercriminelen, juist omdat ze vaak direct verbonden zijn met databases en bedrijfskritische informatie.

De gevolgen van een succesvolle aanval via een onbeveiligde applicatie zijn breed. Denk aan datalekken waarbij persoonsgegevens van klanten op straat belanden, financiële schade door bedrijfsonderbreking, reputatieschade en juridische aansprakelijkheid. Onder wetgeving zoals de NIS2-richtlijn kunnen organisaties bovendien forse boetes verwachten als zij onvoldoende maatregelen hebben genomen om hun systemen te beveiligen.

Naast directe schade zijn er ook indirecte risico’s. Een gecompromitteerde applicatie kan als springplank dienen naar andere systemen binnen het netwerk, waardoor een aanvaller zich steeds verder kan bewegen door de infrastructuur. Dit maakt softwarebeveiliging niet alleen een technisch vraagstuk, maar ook een bedrijfsrisico dat aandacht verdient op bestuursniveau.

Hoe werkt applicatiebeveiliging in de praktijk?

Applicatiebeveiliging werkt door op meerdere niveaus beveiligingsmaatregelen in te bouwen: tijdens het ontwerp en de ontwikkeling van software, bij de uitrol en het beheer, en door continue monitoring en testing achteraf. Het is geen eenmalige actie, maar een doorlopend proces dat meegroeit met de applicatie en het dreigingslandschap.

In de praktijk betekent dit dat beveiliging al vroeg in de softwareontwikkeling wordt meegenomen, een aanpak die ook wel “security by design” wordt genoemd. Ontwikkelaars schrijven code volgens veilige standaarden, voeren code reviews uit en gebruiken geautomatiseerde tools om kwetsbaarheden te detecteren voordat software live gaat.

Na de livegang is continue aandacht nodig. Applicaties worden regelmatig getest op nieuwe kwetsbaarheden, software-updates worden tijdig doorgevoerd en toegangsrechten worden strak beheerd. Authenticatiemechanismen zoals multi-factorauthenticatie zorgen ervoor dat alleen bevoegde gebruikers toegang krijgen. Logging en monitoring maken het mogelijk om verdacht gedrag vroegtijdig te signaleren en snel te reageren op incidenten.

Wat zijn de meest voorkomende kwetsbaarheden in applicaties?

De meest voorkomende kwetsbaarheden in applicaties zijn SQL-injectie, cross-site scripting (XSS), onveilige authenticatie, verkeerde configuraties en het gebruik van verouderde of kwetsbare softwarecomponenten. Deze zwakke plekken komen voor in zowel maatwerksoftware als standaardapplicaties en vormen de basis van het overgrote deel van succesvolle aanvallen.

Een overzicht van veelvoorkomende kwetsbaarheden:

• SQL-injectie: aanvallers manipuleren databasequery’s via invoervelden om ongeautoriseerde toegang te krijgen tot gegevens.
• Cross-site scripting (XSS): kwaadaardige scripts worden geïnjecteerd in webpagina’s die vervolgens worden uitgevoerd in de browser van andere gebruikers.
• Onveilige authenticatie: zwak wachtwoordbeleid, ontbrekende meerfactorauthenticatie of slecht beheerde sessies geven aanvallers eenvoudig toegang.
• Verkeerde configuraties: standaardinstellingen, open poorten of te ruime toegangsrechten creëren onnodige aanvalsoppervlakken.
• Verouderde componenten: softwarebibliotheken of frameworks met bekende kwetsbaarheden die niet tijdig zijn bijgewerkt.
• Onvoldoende encryptie: gevoelige data die onversleuteld wordt opgeslagen of verstuurd, is kwetsbaar voor onderschepping.

De OWASP Top 10 is een veelgebruikte referentie binnen de wereld van cybersecurityapplicaties. Deze lijst beschrijft de tien meest kritieke beveiligingsrisico’s voor webapplicaties en wordt regelmatig bijgewerkt op basis van actuele dreigingsinformatie. Het is een nuttig startpunt voor elke organisatie die de beveiliging van haar software serieus neemt.

Wanneer moet een organisatie beginnen met applicatiebeveiliging?

Een organisatie moet beginnen met applicatiebeveiliging op het moment dat software wordt ontwikkeld of aangeschaft, en niet pas nadat een applicatie al live is. Hoe eerder beveiliging wordt meegenomen in het proces, hoe goedkoper en effectiever het is om kwetsbaarheden te verhelpen.

Beveiligingsproblemen die vroeg in de ontwikkeling worden ontdekt, zijn aanzienlijk eenvoudiger en goedkoper op te lossen dan problemen die pas na de livegang aan het licht komen. Dit principe staat bekend als “shift left”: beveiliging verschuift naar het begin van de ontwikkelcyclus in plaats van als nagedachte aan het einde toe te voegen.

Voor organisaties die al bestaande applicaties in gebruik hebben zonder formeel beveiligingsbeleid, is het antwoord simpel: nu beginnen. Elke dag zonder adequate app security is een dag waarop risico’s onnodig groot zijn. Een eerste stap kan een penetratietest zijn om inzicht te krijgen in de huidige staat van beveiliging, gevolgd door een gestructureerd plan om kwetsbaarheden te verhelpen en processen te verbeteren.

Wat is het verschil tussen applicatiebeveiliging en netwerkbeveiliging?

Applicatiebeveiliging richt zich op het beveiligen van software en de data die applicaties verwerken, terwijl netwerkbeveiliging zich richt op de bescherming van de infrastructuur waarmee systemen met elkaar communiceren. Beide zijn noodzakelijk, maar ze beschermen tegen verschillende soorten aanvallen op verschillende niveaus.

Netwerkbeveiliging omvat maatregelen zoals firewalls, intrusion detection systems en VPN-verbindingen. Het doel is om ongeautoriseerd verkeer buiten de deur te houden en de communicatie tussen systemen te beveiligen. Netwerkbeveiliging beschermt de “snelwegen” waarover data reist.

Applicatiebeveiliging gaat een laag dieper. Een aanvaller die via een legitieme verbinding een applicatie bereikt, wordt door netwerkbeveiliging niet tegengehouden. Pas als de applicatie zelf goed beveiligd is, worden aanvallen zoals SQL-injectie of XSS geblokkeerd. Beide vormen van beveiliging vullen elkaar aan en zijn samen onderdeel van een gelaagde cybersecurityaanpak. Wie alleen op netwerkbeveiliging vertrouwt, laat een groot deel van het aanvalsoppervlak onbeschermd.

Hoe test je de beveiliging van een applicatie?

De beveiliging van een applicatie test je door een combinatie van geautomatiseerde scans, handmatige code reviews en penetratietests uit te voeren. Elke methode heeft zijn eigen sterktes en samen geven ze een compleet beeld van de kwetsbaarheden in een applicatie.

Geautomatiseerde scans

Geautomatiseerde tools scannen de broncode of de lopende applicatie op bekende kwetsbaarheden. Static Application Security Testing (SAST) analyseert de code zonder de applicatie uit te voeren, terwijl Dynamic Application Security Testing (DAST) de applicatie test terwijl deze actief is. Deze tools zijn snel en schaalbaar, maar missen soms de nuance die menselijke testers wel oppikken.

Penetratietests en ethisch hacken

Bij een penetratietest simuleert een ethische hacker een echte aanval op de applicatie. De tester probeert actief kwetsbaarheden te misbruiken om te bepalen hoe ver een aanvaller zou kunnen komen. Dit geeft een realistisch beeld van de werkelijke beveiligingsstatus en brengt kwetsbaarheden aan het licht die geautomatiseerde tools missen. Een red team gaat nog een stap verder door een volledige aanvalssimulatie uit te voeren, inclusief social engineering en andere geavanceerde technieken.

Naast technische tests is ook het beoordelen van het beveiligingsbeleid rondom applicaties waardevol. Zijn toegangsrechten goed ingericht? Worden updates tijdig uitgerold? Is er een procedure voor het melden en afhandelen van kwetsbaarheden? Technische tests en beleidsmatige beoordeling samen geven de meest volledige blik op de staat van applicatiebeveiliging binnen een organisatie.

Hoe Q-Cyber helpt met applicatiebeveiliging

Wij begrijpen dat applicatiebeveiliging voor veel organisaties complex en overweldigend kan aanvoelen. Toch is het een van de meest concrete stappen die een organisatie kan zetten om haar digitale weerbaarheid te vergroten. Q-Cyber helpt organisaties van elke omvang om grip te krijgen op hun softwarebeveiliging, zonder onnodige complexiteit of binding aan softwarepartijen.

Wat wij voor uw organisatie kunnen doen:

• Penetratietests en vulnerability scans: wij testen uw applicaties op kwetsbaarheden met een combinatie van geautomatiseerde tools en handmatige expertise, inclusief ethisch hacken door ons red team.
• Beleidsvorming en advies: wij schrijven concreet beveiligingsbeleid rondom applicatieontwikkeling en -beheer, afgestemd op uw organisatie en eventuele NIS2-verplichtingen.
• Virtuele CISO via Continuous-Q: via ons Continuous-Q programma bieden wij doorlopende begeleiding door een team van specialisten, zodat applicatiebeveiliging structureel is ingebed in uw organisatie.
• Trainingen en bewustwording: wij verzorgen trainingen voor ontwikkelaars, beheerders en bestuurders zodat iedereen begrijpt welke rol zij spelen in de beveiliging van applicaties.
• Onafhankelijk advies: wij werken zonder binding aan softwarepartijen en geven altijd pragmatisch, eerlijk advies dat past bij uw situatie.

Wacht niet tot een incident u dwingt om in actie te komen. Neem contact op met Q-Cyber en ontdek hoe wij uw organisatie kunnen helpen om applicatiebeveiliging structureel en effectief aan te pakken.

Lees meer

Hoe weet je of een pentest daadwerkelijk handmatig is uitgevoerd?

Geplaatst op: 15 september 2026

Je hebt een pentest laten uitvoeren en het rapport ligt op tafel. Maar hoe weet je of die test daadwerkelijk handmatig is uitgevoerd door een ervaren ethical hacker, of dat je in werkelijkheid betaalt voor een geautomatiseerde scan met een duur logo erop? Het onderscheid is cruciaal. Een handmatige pentest ontdekt aanvalspaden die geautomatiseerde tools structureel missen. Een geautomatiseerde scan doet dat niet, maar presenteert zich soms wel als volwaardige penetratietest.

In deze gids leer je stap voor stap hoe je de kwaliteit van een pentest verifieert: van het beoordelen van het rapport tot het stellen van de juiste vragen en het herkennen van rode vlaggen. Zo weet je zeker dat je investering daadwerkelijk waarde heeft opgeleverd.

Wat een echt handmatige pentest onderscheidt van een geautomatiseerde scan

Begrijp eerst het fundamentele verschil voordat je een rapport beoordeelt of vragen stelt. Een geautomatiseerde vulnerability scan werkt op basis van bekende CVE-databases en vergelijkt je omgeving met een lijst van bekende zwakheden. Dat is nuttig voor basishygiëne, maar het stopt daar ook. Een echte handmatige pentest gaat aanzienlijk verder en werkt op drie lagen:

• Laag 1 – Bekende kwetsbaarheden: Bekende CVE’s, publieke exploits en controle of patches correct zijn uitgevoerd. Dit is wat een geautomatiseerde scan ook kan.
• Laag 2 – Individuele zwakheden: Verkeerde Azure-configuraties, te ruime permissies, identity weaknesses en onveilige applicatie-instellingen. Deels automatiseerbaar, maar vereist menselijk oordeel.
• Laag 3 – Gecorreleerde aanvalspaden: Hier voegt een handmatige penetratietest echte waarde toe. Een ethical hacker onderzoekt wat er gebeurt als meerdere kleine zwaktes worden gecombineerd. Denk aan een keten als SSRF naar managed identity naar Azure RBAC naar Key Vault naar subscription owner. Los van elkaar lijkt geen enkele bevinding kritiek. Samen leiden ze tot volledige toegang tot cloudresources.

Het kernprincipe dat je moet onthouden: aanvallers zien geen losse bevindingen, zij zien aanvalspaden. Een geautomatiseerde scan rapporteert bevindingen. Een handmatige pentest reconstrueert aanvalspaden. Als je rapport alleen een lijst van CVE’s bevat zonder narratief over hoe een aanvaller ze zou combineren, is dat een sterke aanwijzing dat er weinig handmatig werk aan te pas is gekomen.

Beoordeel het rapport op tekenen van handmatig werk

Open het rapport en analyseer het op structuur en inhoud. Een kwalitatief handmatig pentestrapport heeft herkenbare kenmerken die je kunt controleren zonder zelf technisch expert te zijn.

1. Controleer de executive summary: Bevat die een verhaallijn over hoe een aanvaller te werk zou gaan, of is het een samenvatting van aantallen gevonden kwetsbaarheden? Een handmatig rapport vertelt een aanvalsverhaal.
2. Zoek naar omgevingsspecifieke details: Staan er screenshots, commando’s of outputs in die specifiek zijn voor jouw systemen, jouw domeinnamen, jouw applicatiestructuur? Generieke beschrijvingen zonder bewijs zijn een waarschuwingssignaal.
3. Beoordeel de bevindingen op diepgang: Een handmatige bevinding beschrijft de exploitatiestap, het bewijs van uitvoering en de specifieke impact voor jouw organisatie. Een geautomatiseerde bevinding kopieert de CVE-beschrijving en plakt daar een CVSS-score bij.
4. Let op attack path-analyse: Worden bevindingen in verband gebracht met elkaar? Staat er beschreven hoe een aanvaller bevinding A gebruikt als opstap naar bevinding B? Zo niet, dan ontbreekt de meest waardevolle laag van handmatig pentestwerk.
5. Tel de low-severitybevindingen: Paradoxaal genoeg is een rapport zonder low-severitybevindingen soms een slecht teken. Handmatige testers ontdekken ook kleine misconfiguraties die geautomatiseerde tools overslaan, juist omdat die in een aanvalsketen gevaarlijk kunnen zijn.

Verwacht je na deze analyse een rapport dat concreet is, omgevingsspecifiek en opgebouwd als een aanvalsverhaal? Dan is de kans groot dat er daadwerkelijk handmatig werk is verricht. Ontbreekt die diepgang, dan is het tijd om vragen te stellen.

Stel de juiste vragen aan je pentestprovider

Met je rapport als uitgangspunt ga je het gesprek aan met de pentestprovider. De antwoorden op onderstaande vragen onthullen snel of je met een echte handmatige test te maken hebt gehad. Stel deze vragen bij voorkeur vóór je een nieuwe opdracht plaatst, maar ze zijn ook waardevol als evaluatiegesprek achteraf.

1. Welke tools hebben jullie gebruikt en wat hebben jullie handmatig gedaan? Een eerlijke provider benoemt beide. Elke serieuze pentest combineert geautomatiseerde tools voor verkenning met handmatige analyse voor exploitatie en attack path-reconstructie. Een antwoord als “wij doen alles handmatig” of “wij gebruiken alleen tools” is allebei een rode vlag.
2. Hoeveel uur heeft de tester actief in mijn omgeving doorgebracht? Een volwaardige handmatige pentest van een gemiddeld netwerk of applicatie kost meerdere dagen. Als het antwoord enkele uren is voor een complexe omgeving, kloppen de getallen niet.
3. Kun je uitleggen hoe bevinding X en bevinding Y samen een aanvalsketen vormen? Kies twee bevindingen uit je rapport en vraag dit concreet. Een handmatige tester kan dit direct beantwoorden. Iemand die een scan heeft gedraaid, kan dat niet.
4. Welke bevindingen hebben jullie handmatig gevalideerd en hoe? Geautomatiseerde tools produceren false positives. Handmatige testers valideren elke bevinding. Vraag naar het validatieproces.
5. Welke certificeringen hebben de testers die mijn omgeving hebben getest? Denk aan OSCP, CEH of vergelijkbare offensieve certificeringen. Vraag specifiek wie de test heeft uitgevoerd, niet welke certificeringen het bedrijf in algemene zin bezit.

Na dit gesprek heb je een helder beeld van de werkwijze achter je rapport. Zijn de antwoorden vaag, defensief of inconsistent met wat er in het rapport staat, dan is verdere technische validatie aan te raden.

Valideer de bevindingen technisch na afloop

Als je intern technische capaciteit hebt, of toegang tot een onafhankelijke partij, kun je een steekproef van de bevindingen zelf valideren. Dit hoeft geen volledige hertest te zijn. Een gerichte validatie van drie tot vijf bevindingen geeft al veel inzicht in de betrouwbaarheid van het volledige rapport.

1. Selecteer een mix van bevindingen: Kies minimaal één high-severity en één low-severitybevinding. Zo test je zowel de kwaliteit van de kritieke als de minder urgente rapportage.
2. Controleer of de bevinding reproduceerbaar is: Kan je eigen team of een tweede partij de bevinding bevestigen op basis van de beschrijving in het rapport? Een goede handmatige bevinding bevat genoeg detail om reproduceerbaar te zijn.
3. Vergelijk de bevindingen met een geautomatiseerde scan: Voer zelf een gratis of goedkope vulnerability scan uit op hetzelfde scope. Staan alle bevindingen uit het pentestrapport ook in de geautomatiseerde scan, en staan er geen bevindingen in het rapport die alleen een handmatige tester had kunnen vinden? Dan is er reden tot twijfel. Een handmatige pentest zou bevindingen moeten bevatten die een geautomatiseerde scan mist.
4. Beoordeel de aanbevelingen op specificiteit: Generieke aanbevelingen zoals “update uw software” of “implementeer sterker wachtwoordbeleid” wijzen op geautomatiseerde output. Handmatige aanbevelingen zijn specifiek voor jouw architectuur en configuratie.

Na deze technische validatie weet je of de bevindingen standhouden. Als meerdere bevindingen niet reproduceerbaar zijn of als alle bevindingen ook door een geautomatiseerde scan worden gevonden, heb je sterke aanwijzingen dat de pentest niet de diepgang had die je betaald hebt.

Herken rode vlaggen bij twijfelachtige pentestleveranciers

Sommige signalen zijn al zichtbaar voordat je het rapport ontvangt. Leer deze rode vlaggen herkennen zodat je ze in een volgende selectieronde kunt vermijden. Zie ook de achtergrond bij offensieve security voor meer context over hoe kwalitatief pentestwerk eruitziet.

• Een onrealistisch lage prijs: Een handmatige pentest kost tijd van gekwalificeerde professionals. Als de prijs te laag is om meerdere dagen menselijk werk te dekken, is de kans groot dat er vooral tools draaien.
• Een te snel opgeleverd rapport: Een volwaardige handmatige pentest duurt meerdere dagen tot weken, afhankelijk van de scope. Een rapport dat binnen 24 uur na de startdatum wordt opgeleverd, is vrijwel zeker geautomatiseerd.
• Geen kickoff of scopegesprek: Handmatige testers willen begrijpen wat ze testen en waarom. Een provider die geen vragen stelt over je architectuur, dreigingsmodel of kritieke assets, test waarschijnlijk niet handmatig.
• Geen mogelijkheid tot toelichting: Een serieuze pentestpartij staat achter haar bevindingen en kan die mondeling toelichten. Als een provider weigert of niet in staat is om bevindingen te verduidelijken, is dat een ernstig signaal.
• Rapport bevat alleen CVSS-scores zonder context: CVSS-scores zijn nuttig, maar een handmatige pentest vertaalt die naar de specifieke impact voor jouw organisatie. Alleen scores zonder contextuele duiding wijzen op geautomatiseerde output.
• Geen aandacht voor aanvalspaden: Als het rapport geen enkele verwijzing bevat naar hoe bevindingen gecombineerd kunnen worden, ontbreekt de meest waardevolle dimensie van handmatig pentestwerk.

Met deze rode vlaggen in gedachten ben je beter uitgerust om leveranciers te beoordelen voordat je een opdracht plaatst. Zo voorkom je dat je budget gaat naar een geautomatiseerde scan die zich voordoet als een handmatige penetratietest. Voor organisaties die twijfelen over hun huidige testprogramma kan ook red teaming een waardevolle aanvulling zijn om te toetsen of een aanvaller daadwerkelijk door de verdediging heen kan breken.

Hoe Q-Cyber helpt bij het kiezen van een betrouwbare pentest

Bij Q-Cyber begrijpen we dat de markt voor penetratietesten onoverzichtelijk is. Leveranciers die geautomatiseerde scans verkopen als handmatige pentests ondermijnen het vertrouwen in de hele sector en laten organisaties met een vals gevoel van veiligheid achter. Onze aanpak is daarom gebouwd op transparantie en technische diepgang.

• Volledig handmatig uitgevoerd: Onze ethical hackers werken zoals echte aanvallers, inclusief creatieve technieken die nog niet in standaard beveiligingsplaybooks staan.
• Attack path-rapportage: We rapporteren niet alleen losse bevindingen, maar reconstrueren hoe een aanvaller meerdere zwakheden combineert tot een volledige aanvalsketen.
• Omgevingsspecifiek en concreet: Elke bevinding is voorzien van bewijs, reproductiestappen en een aanbeveling die past bij jouw specifieke architectuur.
• Onafhankelijk advies: We zijn niet gebonden aan softwarepartijen of toeleveranciers, waardoor ons advies altijd in jouw belang is.
• Optioneel: continu testen via Continuous-Q®: Voor organisaties die verder willen gaan dan een jaarlijkse momentopname bieden we een programma waarbij testen een doorlopend proces wordt in plaats van een eenmalige meting.

Wil je zeker weten dat je volgende pentest daadwerkelijk handmatig en kwalitatief is? Neem contact op en we denken graag met je mee over de juiste aanpak voor jouw organisatie.

Lees meer

Hoe beveilig je mobiele apparaten van medewerkers?

Geplaatst op: 14 september 2026

Mobiele apparaten van medewerkers beveilig je door een combinatie van technisch beleid, beheeroplossingen en gebruikersbewustzijn. Denk aan Mobile Device Management (MDM), sterke authenticatie, encryptie en een duidelijk BYOD-beleid. Deze maatregelen gelden voor elk apparaat dat toegang heeft tot bedrijfsdata, ongeacht of het eigendom is van de medewerker of de organisatie. In dit artikel beantwoorden we de meest gestelde vragen over mobiele beveiliging voor bedrijven.

Welke risico’s brengen mobiele apparaten van medewerkers met zich mee?

Mobiele apparaten van medewerkers vormen een van de meest kwetsbare toegangspunten in een bedrijfsnetwerk. Ze worden gebruikt op onbeveiligde wifi-netwerken, raken kwijt of worden gestolen, en draaien vaak verouderde software. Elk van deze situaties kan leiden tot ongeautoriseerde toegang tot bedrijfsdata of systemen.

De risico’s zijn concreet en divers. Een verloren smartphone met toegang tot bedrijfse-mail is een direct datalek. Een medewerker die verbinding maakt via een openbaar wifinetwerk in een café is kwetsbaar voor een man-in-the-middle-aanval. En een privéapparaat waarop ook zakelijke apps staan, maar dat nooit een beveiligingsupdate heeft ontvangen, is een open deur voor aanvallers.

De meest voorkomende risico’s op een rij:

• Verlies of diefstal van het apparaat, met directe toegang tot bedrijfsdata als gevolg
• Onbeveiligde netwerken zoals openbare wifi waarbij dataverkeer kan worden onderschept
• Verouderde software en apps met bekende kwetsbaarheden die niet zijn gepatcht
• Phishing via sms of messaging-apps, ook wel smishing genoemd
• Ongecontroleerde app-installaties die malware of spyware kunnen bevatten
• Zwakke of hergebruikte wachtwoorden zonder multi-factor authenticatie

Wat dit extra complex maakt, is dat medewerkers mobiele apparaten gebruiken buiten de traditionele beveiligingsperimeter van het kantoornetwerk. De grenzen van het bedrijfsnetwerk zijn daarmee in de praktijk verdwenen, en geldende regelgeving zoals NIS2 vraagt organisaties expliciet om ook deze risico’s te adresseren als onderdeel van hun zorgplicht.

Wat is Mobile Device Management en hoe werkt het?

Mobile Device Management (MDM) is een beheersysteem waarmee organisaties mobiele apparaten centraal kunnen beheren, beveiligen en monitoren. Via een MDM-platform kunnen IT-beheerders op afstand beleid afdwingen, apps installeren of verwijderen, en apparaten wissen als ze verloren of gestolen zijn. MDM werkt via een agent die op het apparaat wordt geïnstalleerd en verbinding maakt met een centrale beheerconsole.

Een MDM-oplossing geeft organisaties zichtbaarheid en controle over elk apparaat dat toegang heeft tot bedrijfssystemen. Zodra een apparaat is ingeschreven, kan de IT-afdeling onder andere:

• Verplichte schermvergrendeling en encryptie instellen
• Zakelijke en privédata van elkaar scheiden via een zogenaamde container
• Apparaten op afstand blokkeren of wissen bij verlies of diefstal
• App-gebruik beperken tot een goedgekeurde lijst
• Beveiligingsupdates automatisch uitrollen
• Naleving van beveiligingsbeleid monitoren en rapporteren

Moderne MDM-platforms, ook wel Unified Endpoint Management (UEM) genoemd, ondersteunen niet alleen smartphones en tablets maar ook laptops en andere eindpunten. Bekende oplossingen zijn Microsoft Intune, Jamf en VMware Workspace ONE. De keuze voor een specifiek platform hangt af van de bestaande IT-infrastructuur, het besturingssysteem van de apparaten en de gewenste beheerfunctionaliteit.

Belangrijk om te weten: MDM is geen wondermiddel. Het biedt controle over apparaatinstellingen, maar vervangt niet het bewustzijn van medewerkers of een breder beveiligingsbeleid. Het is een technische laag binnen een bredere aanpak van mobiele beveiliging voor bedrijven.

Wat is het verschil tussen BYOD, COPE en CYOD?

BYOD, COPE en CYOD zijn drie modellen voor het gebruik van mobiele apparaten op de werkvloer, en ze verschillen in wie het apparaat bezit en wie de controle heeft. BYOD staat voor Bring Your Own Device (privéapparaat, zakelijk gebruik), COPE voor Corporate Owned, Personally Enabled (zakelijk apparaat, ook privégebruik toegestaan), en CYOD voor Choose Your Own Device (medewerker kiest uit een goedgekeurde lijst, bedrijf is eigenaar).

BYOD: flexibel maar risicovol

Bij BYOD brengen medewerkers hun eigen smartphone of tablet mee en gebruiken die ook voor werk. Dit is populair vanwege het gebruiksgemak en de kostenbesparing, maar het stelt hoge eisen aan het beveiligingsbeleid. Het bedrijf heeft beperkte controle over het apparaat zelf. Een goede BYOD-aanpak vereist minimaal een MDM-oplossing met containerisatie, zodat zakelijke en privédata strikt gescheiden blijven.

COPE: controle met gebruiksgemak

Bij COPE koopt de organisatie de apparaten aan en beheert ze volledig, maar medewerkers mogen ze ook privé gebruiken. Dit geeft de IT-afdeling maximale controle over beveiliging en configuratie, terwijl medewerkers toch één apparaat voor alles kunnen gebruiken. COPE is doorgaans de veiligste optie, maar brengt hogere kosten met zich mee en vraagt om duidelijke afspraken over privacygebruik.

CYOD: balans tussen keuze en controle

CYOD combineert elementen van beide modellen. De medewerker kiest een apparaat uit een door de organisatie goedgekeurde selectie. Het bedrijf blijft eigenaar en beheert het apparaat, maar de medewerker heeft enige keuzevrijheid. Dit model werkt goed voor organisaties die standaardisatie willen zonder de gebruikerstevredenheid te schaden.

Welk model het beste past, hangt af van de omvang van de organisatie, het risicoprofiel en de mate van controle die nodig is. In sectoren met strenge compliance-eisen, zoals zorg of financiën, verdient COPE of CYOD de voorkeur boven BYOD.

Welke maatregelen zijn het meest effectief voor mobiele beveiliging?

De meest effectieve maatregelen voor de beveiliging van smartphones van medewerkers combineren technische controles met duidelijk beleid en bewustwording. Geen enkele maatregel staat op zichzelf: beveiliging werkt als een gelaagd systeem waarbij meerdere lagen samen de kans op een incident verkleinen.

De maatregelen met de grootste impact:

1. Multi-factor authenticatie (MFA) voor toegang tot zakelijke apps en systemen. Dit is een van de meest genoemde minimummaatregelen onder NIS2 en voorkomt dat een gestolen wachtwoord direct leidt tot een inbraak.
2. Encryptie van de opgeslagen data op het apparaat, zodat informatie onleesbaar is bij verlies of diefstal.
3. MDM met remote wipe, zodat apparaten op afstand gewist kunnen worden als ze kwijtraken.
4. Automatische schermvergrendeling na korte inactiviteit, gecombineerd met een sterke pincode of biometrische beveiliging.
5. Scheiding van zakelijke en privédata via containerisatie, met name bij BYOD-omgevingen.
6. Regelmatige software-updates en patchbeheer, bij voorkeur automatisch afgedwongen via MDM.
7. Bewustwordingstraining voor medewerkers, gericht op herkenning van phishing, smishing en social engineering.
8. VPN-gebruik bij verbinding via onbekende of openbare netwerken.

De combinatie van technische maatregelen en menselijk bewustzijn is doorslaggevend. Technologie kan veel afdwingen, maar een medewerker die een phishinglink aanklikt op zijn telefoon omzeilt elke technische barrière als er geen bewustzijn is.

Hoe stel je een mobiel beveiligingsbeleid op voor je organisatie?

Een mobiel beveiligingsbeleid stel je op door te beginnen met een inventarisatie van alle apparaten en gebruiksscenario’s, gevolgd door het vastleggen van regels voor toegang, gebruik en incidentrespons. Het beleid moet aansluiten op het risicoprofiel van de organisatie en begrijpelijk zijn voor medewerkers, niet alleen voor de IT-afdeling.

Een praktisch stappenplan:

1. Inventariseer welke apparaten toegang hebben tot bedrijfsdata en welk model van toepassing is (BYOD, COPE of CYOD).
2. Bepaal het risiconiveau per type data en gebruiker. Niet elk apparaat heeft toegang tot dezelfde informatie nodig.
3. Definieer minimumvereisten voor apparaten die toegang mogen krijgen, zoals een minimale OS-versie, verplichte encryptie en MFA.
4. Leg verantwoordelijkheden vast: waar is de organisatie verantwoordelijk voor, en wat wordt van de medewerker verwacht?
5. Beschrijf de procedure bij verlies of diefstal, inclusief meldplicht en de stappen die de IT-afdeling neemt.
6. Communiceer het beleid actief aan medewerkers en zorg voor een begrijpelijke samenvatting naast het volledige document.
7. Evalueer en actualiseer het beleid minimaal jaarlijks, of na een significant incident.

Een goed beleid is niet alleen een document, maar een levend kader dat medewerkers begrijpen en naleven. Koppel het beleid aan concrete trainingen en maak duidelijk wat de gevolgen zijn van niet-naleving. Voor organisaties die onder NIS2-regelgeving vallen, is een gedocumenteerd beveiligingsbeleid voor mobiele apparaten geen optie maar een verplichting.

Wanneer is een vulnerability scan zinvol voor mobiele omgevingen?

Een vulnerability scan is zinvol voor mobiele omgevingen zodra medewerkers smartphones of tablets gebruiken voor toegang tot bedrijfssystemen, en zeker wanneer er geen actueel inzicht is in de beveiligingsstatus van die apparaten. Scans helpen kwetsbaarheden te identificeren in apps, configuraties en netwerkkoppelingen voordat aanvallers ze kunnen misbruiken.

Specifieke momenten waarop een scan bijzonder waardevol is:

• Bij de introductie van een nieuw MDM-platform of een wijziging in het apparaatbeleid
• Na een beveiligingsincident waarbij een mobiel apparaat betrokken was
• Wanneer de organisatie overstapt van BYOD naar COPE of een ander model
• Als onderdeel van een bredere penetratietest of beveiligingsaudit
• Bij voorbereiding op NIS2-compliance of een externe audit

Een vulnerability scan voor mobiele omgevingen richt zich op aspecten als verouderde app-versies, onveilige netwerkconfiguraties, zwakke authenticatie-instellingen en mogelijke datalekken via app-permissies. Het resultaat is een concreet overzicht van risico’s met prioritering, zodat de IT-afdeling gericht actie kan ondernemen.

Reguliere scans, bij voorkeur meerdere keren per jaar, geven organisaties een actueel beeld van hun kwetsbaarhedenprofiel. In een omgeving waar apparaten en apps voortdurend veranderen, is een eenmalige scan onvoldoende. Structureel testen hoort bij een volwassen aanpak van mobiele beveiliging.

Hoe Q-Cyber helpt met de beveiliging van mobiele apparaten

Wij helpen organisaties om mobiele beveiliging structureel en pragmatisch aan te pakken, van beleid tot technische uitvoering. Of je nu worstelt met het opzetten van een BYOD-beleid, wil weten hoe kwetsbaar je mobiele omgeving is, of moet voldoen aan NIS2-verplichtingen: wij denken met je mee en leveren concrete resultaten.

Wat wij voor je kunnen doen:

• Opstellen van een mobiel beveiligingsbeleid dat aansluit op jouw organisatie en risicoprofiel
• Uitvoeren van vulnerability scans op mobiele omgevingen om kwetsbaarheden in kaart te brengen
• Advies over MDM-implementatie, onafhankelijk van softwarepartijen
• NIS2-begeleiding, inclusief gap-analyse, beleidsschrijving en trainingen voor bestuurders
• Bewustwordingstrainingen voor medewerkers over veilig gebruik van mobiele apparaten
• Virtuele CISO-diensten via Continuous-Q voor doorlopend advies en toezicht

Wij werken onafhankelijk, zonder binding aan softwareleveranciers, en leveren advies dat echt past bij jouw situatie. Wil je weten waar jouw organisatie nu staat? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe gebruiken hackers trust relationships tussen organisaties?

Geplaatst op: 14 september 2026

Hackers beginnen zelden met het kraken van een wachtwoord of het uitbuiten van een bekende kwetsbaarheid. Steeds vaker kiezen aanvallers een slimmere route: ze misbruiken het vertrouwen dat organisaties onderling hebben opgebouwd. Een leverancier met toegang tot jouw netwerk, een MSP die systemen beheert, een partner die gegevens uitwisselt – elk van deze verbindingen is een potentieel aanvalspad. Dit fenomeen staat bekend als het misbruiken van trust relationships, en het is een van de meest effectieve technieken in het arsenaal van moderne cybercriminelen.

In deze gids leer je stap voor stap hoe je de vertrouwensrelaties binnen en rondom jouw organisatie in kaart brengt, beveiligt en actief test. Zo zorg je ervoor dat aanvallers geen gebruik kunnen maken van de verbindingen die jij bewust hebt opgebouwd.

Herken welke vertrouwensrelaties jouw organisatie blootstellen

Voordat je iets kunt beveiligen, moet je weten wat er bestaat. Veel organisaties hebben in de loop der jaren tientallen vertrouwde verbindingen opgebouwd zonder dat dit centraal is bijgehouden. Denk aan IT-leveranciers met beheertoegang, softwareleveranciers die gegevens synchroniseren, of cloudplatformen die via serviceaccounts met elkaar communiceren. Elk van deze relaties vertegenwoordigt een potentiële ingang voor een aanvaller die trust relationships wil misbruiken.

Begin met een gestructureerde inventarisatie van alle externe en interne vertrouwensrelaties. Stel jezelf bij elke verbinding de vraag: wie heeft toegang, tot wat, en waarom?

1. Breng alle externe partijen in kaart die toegang hebben tot jouw netwerk, systemen of data – inclusief MSP’s, leveranciers en cloudproviders.
2. Documenteer welke technische mechanismen die toegang mogelijk maken: VPN-tunnels, API-koppelingen, federated identity, serviceaccounts of gedeelde certificaten.
3. Identificeer welke interne accounts of systemen automatisch vertrouwen genieten op basis van groepslidmaatschap, domeinvertrouwen of configuratie.
4. Noteer voor elke relatie het toegangsniveau: leesrechten, schrijfrechten, beheertoegang of volledige controle over systemen.

Na deze stap heb je een overzicht van alle verbindingen die een aanvaller in theorie zou kunnen misbruiken. Vertrouwensrelaties die je niet kende, kun je ook niet beveiligen. Een veelgemaakte fout is dat organisaties zich richten op de bekende kwetsbaarheden, terwijl de echte risico’s schuilgaan in de verbindingen die als vanzelfsprekend worden beschouwd.

Breng het aanvalspad via trust relationships in kaart

Met je inventarisatie op orde is de volgende stap het denken zoals een aanvaller. Een hacker die een supplychainaanval uitvoert, kijkt niet naar losse kwetsbaarheden – hij kijkt naar hoe hij via vertrouwde verbindingen van de ene omgeving naar de andere kan bewegen. Dit noemen we laterale beweging via trust relationships, en het is precies de reden waarom een MSP zo’n aantrekkelijk doelwit is: wie de MSP compromitteert, heeft direct toegang tot alle klanten van die MSP.

Analyseer voor elke vertrouwde verbinding wat er mogelijk is als die verbinding wordt misbruikt. Volg daarbij de logica van een aanvaller die stap voor stap verder beweegt door jouw omgeving.

1. Stel per vertrouwde verbinding vast: wat is het ergste dat een aanvaller kan doen als hij deze verbinding overneemt?
2. Kijk of meerdere kleine vertrouwensrelaties gecombineerd kunnen worden tot een groter aanvalspad – bijvoorbeeld: leverancierstoegang via VPN, gecombineerd met een te ruim serviceaccount, gecombineerd met een cloudconfiguratie die escalatie mogelijk maakt.
3. Identificeer welke vertrouwensrelaties leiden naar kritieke systemen, gevoelige data of beheerfuncties.
4. Prioriteer de aanvalspaden op basis van impact en kans: welke combinaties zijn het meest realistisch én het meest schadelijk?

Na deze analyse heb je geen lijst met losse kwetsbaarheden, maar een beeld van werkelijke aanvalspaden. Dat is precies het verschil tussen een oppervlakkige vulnerability scan en echte offensieve security: aanvallers zien geen findings, ze zien aanvalspaden. Jij zou dat ook moeten doen.

Stel beperkingen in op vertrouwde verbindingen

Nu je weet welke vertrouwensrelaties bestaan en welke risico’s ze vertegenwoordigen, is het tijd om actie te ondernemen. Het doel is niet om alle externe verbindingen te verwijderen – dat is onrealistisch en onwenselijk. Het doel is om het principe van least privilege consequent toe te passen: elke partij krijgt alleen de toegang die strikt noodzakelijk is, niets meer.

1. Verwijder vertrouwensrelaties die niet langer actief of noodzakelijk zijn. Oude leverancierstoegang die nooit is ingetrokken, is een open deur.
2. Beperk de scope van bestaande toegang: heeft een leverancier beheertoegang tot het hele netwerk nodig, of volstaat toegang tot één specifiek systeem?
3. Implementeer tijdgebonden toegang voor externe partijen, zodat verbindingen automatisch verlopen en bewust opnieuw moeten worden aangevraagd.
4. Segmenteer je netwerk zodat een gecompromitteerde vertrouwde verbinding niet automatisch toegang geeft tot kritieke systemen – laterale beweging in het netwerk wordt zo beperkt.
5. Dwing meervoudige authenticatie af op alle externe toegangspunten, ook voor serviceaccounts en geautomatiseerde koppelingen waar mogelijk.

Controleer na het doorvoeren van deze maatregelen of de beoogde beperkingen daadwerkelijk werken. Test of een externe partij nog steeds toegang heeft tot systemen die buiten hun scope vallen. Een configuratiewijziging die op papier correct lijkt, kan in de praktijk anders uitpakken door overerving van rechten of uitzonderingen in groepsbeleid.

Monitor afwijkend gedrag op vertrouwde accounts

Technische beperkingen alleen zijn niet voldoende. Aanvallers die eenmaal toegang hebben via een vertrouwde verbinding, gedragen zich aanvankelijk vaak normaal – ze gebruiken legitieme accounts en bewegen zich binnen de grenzen van de toegekende rechten. Detectie vereist daarom dat je begrijpt wat normaal gedrag is, zodat je afwijkingen tijdig herkent.

Stel monitoring in die specifiek gericht is op vertrouwde accounts en externe verbindingen. Dit zijn de plekken waar een aanvaller het langst onopgemerkt kan blijven als er geen actieve bewaking is.

1. Definieer een baseline van normaal gedrag voor elke vertrouwde externe verbinding: op welke tijden is er activiteit, welke systemen worden benaderd, hoeveel data wordt overgedragen?
2. Stel alerts in op afwijkingen van die baseline: toegang buiten kantooruren, ongebruikelijke bestemmingen, grote hoeveelheden gedownloade data of pogingen om rechten te escaleren.
3. Log alle activiteit van externe accounts centraal en zorg dat die logs niet toegankelijk zijn voor de externe partij zelf.
4. Koppel monitoring aan een duidelijk escalatieproces: wie wordt gewaarschuwd bij een alert, en welke stappen worden dan gezet?

Een goed ingesteld monitoringsysteem verkleint de tijd tussen een succesvolle inbraak via een trust relationship en de detectie ervan. Hoe sneller je een aanvaller detecteert, hoe minder schade hij kan aanrichten. Voor organisaties die dieper willen gaan in hun detectiemogelijkheden, biedt red teaming een manier om te toetsen of jouw monitoring ook echt werkt onder realistische aanvalsomstandigheden.

Test je eigen trust relationships voordat aanvallers dat doen

De laatste en misschien wel belangrijkste stap is het actief testen van de vertrouwensrelaties die je hebt geïdentificeerd en beveiligd. Technische maatregelen en monitoring geven je vertrouwen, maar pas een echte test laat zien of de beveiliging ook standhoudt als iemand er gericht tegenaan gaat. Dit is precies waar een aanvaller anders denkt dan een beheerder: hij zoekt naar de combinaties die jij over het hoofd hebt gezien.

Plan een gerichte test van jouw trust relationships als onderdeel van een bredere pentestscope. Zorg dat de test niet alleen kijkt naar bekende kwetsbaarheden, maar expliciet de vraag stelt: kan een aanvaller via een vertrouwde verbinding verder bewegen in onze omgeving?

1. Stel een testscope op die specifiek de externe vertrouwensrelaties omvat: leverancierstoegang, MSP-verbindingen, cloudkoppelingen en federated identity.
2. Vraag de pentester om niet alleen losse kwetsbaarheden te rapporteren, maar om werkelijke aanvalspaden te demonstreren die gebruikmaken van trust relationships.
3. Verifieer na de test of de aanbevelingen zijn geïmplementeerd en test opnieuw of de aanvalspaden daadwerkelijk zijn gesloten.
4. Herhaal de test na significante wijzigingen in je omgeving: nieuwe leveranciers, cloudmigraties, reorganisaties of wijzigingen in toegangsrechten.

Een eenmalige test geeft je een momentopname. Maar je omgeving verandert continu: nieuwe leveranciers komen erbij, accounts worden aangemaakt, rechten worden aangepast. Alleen door regelmatig te testen weet je zeker dat de aanvalspaden die je vandaag hebt gesloten, morgen ook nog gesloten zijn. Meer weten over hoe continu testen werkt? Bekijk dan wat Continuous-Q® inhoudt.

Hoe Q-Cyber helpt bij het beveiligen van trust relationships

Trust relationships misbruiken is een van de meest onderschatte aanvalstechnieken van dit moment. Het vereist geen zero-dayexploit – het vereist alleen dat een aanvaller begrijpt hoe jouw organisatie is verbonden met de wereld om haar heen. Wij helpen organisaties om die verbindingen te doorgronden, te beveiligen en actief te testen.

Wat wij concreet bieden:

• Gerichte pentests op trust relationships en supplychainrisico’s, waarbij onze ethical hackers denken zoals een aanvaller en werkelijke aanvalspaden blootleggen in plaats van losse kwetsbaarheden.
• Attack path analyse, waarbij we meerdere kleine zwaktes combineren om te laten zien hoe een aanvaller van een leveranciersaccount naar kritieke systemen kan bewegen.
• Continuous-Q®, ons programma voor doorlopende offensieve security dat ervoor zorgt dat jouw beveiliging niet alleen op de testdag klopt, maar het hele jaar door.
• Onafhankelijk advies, zonder binding aan softwarepartijen of leveranciers – zodat onze aanbevelingen altijd in jouw belang zijn.

Wil je weten hoe jouw organisatie ervoor staat als het gaat om het beveiligen van vertrouwensrelaties? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat zijn de NIS2-eisen voor multi-factor authenticatie?

Geplaatst op: 13 september 2026

Onder de NIS2-richtlijn is het gebruik van multi-factor authenticatie (MFA) een verplichte beveiligingsmaatregel voor alle organisaties die onder de wet vallen. MFA wordt expliciet genoemd als minimumvereiste binnen de zorgplicht, naast andere technische maatregelen zoals cryptografie en toegangsbeheer. In dit artikel beantwoorden we de meest gestelde vragen over NIS2 MFA-eisen, welke methoden volstaan en hoe je een NIS2-conforme implementatie aanpakt.

Voor welke organisaties is MFA verplicht onder NIS2?

Multi-factor authenticatie is verplicht voor alle organisaties die onder de NIS2-richtlijn vallen, zowel essentiële als belangrijke entiteiten. In Nederland gaat het om ruim 10.000 organisaties die direct onder de wet vallen, waaronder gemeenten, provincies, waterschappen, ministeries en een groot deel van de kritieke sectoren zoals energie, transport, gezondheidszorg en digitale infrastructuur.

De Nederlandse omzetting van NIS2 loopt via de Cyberbeveiligingswet (Cbw), waarvan de inwerkingtreding wordt verwacht in Q2 2026. Maar ook organisaties die niet rechtstreeks onder de wet vallen, kunnen indirect te maken krijgen met de MFA-verplichting. Leveranciers en ketenpartners van NIS2-plichtige organisaties worden namelijk steeds vaker gecontroleerd op hun beveiligingsniveau, omdat de NIS2-zorgplicht ook supply chain security omvat.

Overheidsorganisaties worden automatisch als essentiële entiteit aangemerkt. Voor zelfstandige bestuursorganen (ZBO’s) en gemeenschappelijke regelingen geldt een individuele beoordeling aan de hand van vier wettelijke criteria. Organisaties zijn zelf verantwoordelijk voor het bepalen of zij onder de wet vallen. Hulpmiddelen daarvoor zijn de NIS2-zelfevaluatie en de Flowchart Registratieplicht van het NCSC.

Wat schrijft de NIS2-richtlijn precies voor over MFA?

De NIS2-richtlijn schrijft voor dat organisaties multi-factor authenticatie of continue authenticatie moeten toepassen als onderdeel van hun zorgplicht. Dit is geen vrijblijvend advies, maar een minimummaatregel die expliciet in de richtlijn (Richtlijn 2022/2555) is opgenomen naast andere verplichte beveiligingsmaatregelen.

De richtlijn formuleert de MFA-verplichting als onderdeel van een bredere set beveiligingsmaatregelen die organisaties passend en evenredig moeten implementeren op basis van een risicobeoordeling. Andere minimummaatregelen zijn onder meer:

• Beleid voor risicoanalyse en beveiliging van informatiesystemen
• Maatregelen voor bedrijfscontinuïteit en crisisbeheer
• Beveiliging van de toeleveringsketen
• Beleid en procedures voor gebruik van cryptografie en encryptie
• Beveiligingsmaatregelen voor personeel en toegangsbeheer

De formulering “multi-factor authenticatie of continue authenticatie” geeft organisaties enige ruimte in de keuze van methode, maar de kern is duidelijk: wachtwoorden alleen zijn niet langer voldoende. De Nederlandse Cyberbeveiligingswet werkt deze verplichting verder uit via het Cyberbeveiligingsbesluit (Cbb) en sectorspecifieke ministeriële regelingen. Voor de overheid geldt de Baseline Informatiebeveiliging Overheid 2 (BIO2) als normatief kader, dat de NIS2-zorgplicht concreet invult.

Welke MFA-methoden voldoen aan de NIS2-eisen?

De NIS2-richtlijn schrijft geen specifieke technische methode voor, maar vereist dat de gekozen authenticatiemethode daadwerkelijk een extra beveiligingslaag toevoegt bovenop een wachtwoord. De methode moet passen bij het risicoprofiel van de organisatie en de gevoeligheid van de systemen die worden beveiligd.

In de praktijk worden de volgende MFA-methoden als NIS2-conform beschouwd:

• Authenticator-apps zoals Microsoft Authenticator of Google Authenticator, die tijdgebonden eenmalige codes (TOTP) genereren
• Hardware tokens zoals YubiKeys of smartcards, die een fysiek object vereisen naast een wachtwoord
• Biometrische verificatie in combinatie met een andere factor, zoals vingerafdruk plus pincode
• Pushnotificaties via een beveiligde authenticatie-app op een geregistreerd apparaat
• Continue authenticatie, waarbij het systeem voortdurend het gedrag van de gebruiker monitort en bij afwijkingen aanvullende verificatie vereist

SMS-gebaseerde verificatie wordt in beveiligingskringen steeds vaker als onvoldoende beschouwd vanwege kwetsbaarheden zoals SIM-swapping. Hoewel de NIS2-richtlijn SMS niet expliciet verbiedt, is het raadzaam om te kiezen voor robuustere methoden, zeker voor toegang tot gevoelige systemen of beheerdersaccounts. De keuze moet altijd worden onderbouwd vanuit een risicoanalyse.

Wat zijn de gevolgen als een organisatie geen MFA implementeert?

Organisaties die geen MFA implementeren terwijl zij onder de NIS2-richtlijn vallen, riskeren aanzienlijke boetes en toezichtmaatregelen. Essentiële entiteiten kunnen boetes oplopen tot 10 miljoen euro of 2% van de wereldwijde jaaromzet. Belangrijke entiteiten riskeren boetes tot 7 miljoen euro of 1,4% van de jaaromzet.

Naast financiële sancties zijn er ook operationele en bestuurlijke gevolgen. De NIS2-richtlijn legt de verantwoordelijkheid voor cyberweerbaarheid nadrukkelijk bij het bestuur van een organisatie. Bestuurders moeten aantoonbaar voldoende kennis hebben en weloverwogen beslissingen nemen over informatiebeveiliging. Bij ernstige overtredingen kan het senior management persoonlijk aansprakelijk worden gesteld, wat cybersecurity tot een echte boardroomkwestie maakt.

Daar komen de indirecte gevolgen nog bij. Een datalek of cyberincident dat mede mogelijk was door het ontbreken van MFA, leidt tot een meldplicht bij het NCSC binnen 24 uur. Organisaties zijn verplicht een vroegtijdige waarschuwing te geven, gevolgd door een aanvullende melding binnen 72 uur en een eindverslag binnen een maand. De reputatieschade en operationele verstoring die daarmee gepaard gaan, zijn voor veel organisaties minstens zo ingrijpend als de boete zelf.

Hoe implementeer je MFA op een manier die NIS2-compliant is?

Een NIS2-conforme MFA-implementatie begint met een risicoanalyse die bepaalt welke systemen, gebruikersgroepen en toegangspunten het hoogste risico vormen. Op basis daarvan kies je de meest passende authenticatiemethode per context. Een one-size-fits-all aanpak werkt zelden goed en voldoet ook zelden aan de eis van “passende en evenredige maatregelen”.

Een praktische aanpak voor NIS2-conforme MFA-implementatie ziet er als volgt uit:

1. Breng toegangspunten in kaart — Inventariseer alle systemen, applicaties en netwerktoegang binnen uw organisatie, inclusief die van leveranciers en externe beheerders.
2. Prioriteer op basis van risico — Begin met beheerdersaccounts, systemen met gevoelige data en externe toegang via VPN of cloudplatforms.
3. Kies een geschikte MFA-methode — Weeg gebruiksgemak af tegen veiligheid. Authenticator-apps zijn voor de meeste organisaties een goede balans; hardware tokens zijn geschikt voor hoog-risico toegang.
4. Leg de keuzes vast in beleid — Documenteer welke methoden zijn toegestaan, voor welke systemen MFA verplicht is en hoe uitzonderingen worden beheerd. Dit is essentieel voor aantoonbare NIS2-compliance.
5. Train medewerkers en bestuurders — Technische implementatie zonder bewustwording werkt niet. NIS2 vereist expliciet dat bestuurders voldoende kennis hebben over cyberbeveiliging.
6. Test en monitor continu — Voer regelmatig penetratietests uit om te controleren of de authenticatiemaatregelen ook in de praktijk standhouden.

Vergeet daarbij de toeleveringsketen niet. NIS2 vereist dat u inzicht heeft in de beveiligingsmaatregelen van uw leveranciers. Als een externe partij toegang heeft tot uw systemen, moet ook die toegang worden beveiligd met MFA. Een red team assessment kan helpen om zwakke plekken in de authenticatieketen bloot te leggen voordat een aanvaller dat doet.

Hoe Q-Cyber helpt met NIS2 MFA-compliance

NIS2-compliance rondom multi-factor authenticatie is meer dan een technische instelling. Het vraagt om beleid, risicoanalyse, aantoonbaarheid en bestuurlijke betrokkenheid. Wij begeleiden organisaties door dit hele traject, van de eerste gap-analyse tot een volledig gedocumenteerde en werkende implementatie.

Wat wij concreet voor uw organisatie kunnen doen:

• Een NIS2 gap-analyse uitvoeren om te bepalen waar uw organisatie nu staat ten opzichte van de MFA-verplichting en andere zorgplichtmaatregelen
• Beleid op maat schrijven dat voldoet aan de eisen van de Cyberbeveiligingswet en aansluit op uw specifieke risicoprofiel
• Technische tests uitvoeren via pentests en red teaming om te controleren of uw authenticatiebeveiliging ook in de praktijk werkt
• Trainingen verzorgen voor bestuurders en medewerkers, zodat de organisatie als geheel NIS2-bewust opereert
• Als virtuele CISO optreden via Continuous-Q, zodat u altijd een onafhankelijke expert aan uw zijde heeft

Wij werken volledig onafhankelijk, zonder binding aan softwarepartijen of leveranciers. Dat betekent dat ons advies altijd in uw belang is, niet in dat van een tool of platform. Wacht niet tot de Cyberbeveiligingswet in werking treedt: de risico’s zijn er nu al. Neem contact op en ontdek hoe wij uw organisatie NIS2-compliant maken.

Lees meer

Wat onderzoekt een hacker voordat hij een bedrijf probeert binnen te dringen?

Geplaatst op: 13 september 2026

Voordat een hacker ook maar één technisch aanvalsmiddel inzet, heeft hij al uitgebreid huiswerk gemaakt. De verkenningsfase, ook wel reconnaissance genoemd, is het fundament van vrijwel elke succesvolle cyberaanval. Een aanvaller brengt eerst in kaart hoe een organisatie is opgebouwd, wie er werken, welke systemen er aan het internet hangen en waar de zwakke plekken zitten. Hoe gedetailleerder dat beeld, hoe gerichter de aanval. In dit artikel beantwoorden we de meest gestelde vragen over wat een hacker onderzoekt voordat hij een bedrijf probeert binnen te dringen.

Welke informatie is openbaar beschikbaar over jouw bedrijf?

Verrassend veel. Zonder ook maar één systeem aan te raken kan een hacker via openbare bronnen een gedetailleerd beeld opbouwen van jouw organisatie. Denk aan domeinnamen, IP-adressen, e-mailformaten, gebruikte softwareplatforms, SSL-certificaten en zelfs interne bestandsnamen die via zoekmachines vindbaar zijn. Dit noemen we OSINT, ofwel Open Source Intelligence.

Zoekmachines indexeren meer dan de meeste mensen beseffen. Via geavanceerde zoekoperatoren, ook wel “Google dorks” genoemd, kan een aanvaller documenten, inlogpagina’s en configuratiebestanden vinden die eigenlijk niet bedoeld zijn voor publieke toegang. Daarnaast zijn er gespecialiseerde tools en databases die historische DNS-gegevens, gelekte inloggegevens en bekende kwetsbaarheden per domein bijhouden. Informatie die jij als organisatie misschien allang bent vergeten, kan voor een aanvaller nog steeds actueel en bruikbaar zijn.

Hoe gebruiken hackers OSINT om een doelwit in kaart te brengen?

OSINT-technieken stellen hackers in staat om een volledig aanvalsplan te maken zonder ook maar één alarm te activeren. Via platforms als Shodan, Censys en diverse certificaatregisters brengen aanvallers in kaart welke systemen een organisatie online heeft staan, welke softwareversies er draaien en welke subdomeinen er bestaan. Omdat dit allemaal publieke informatie is, laat de aanvaller in deze fase geen sporen achter.

Concreet kan een aanvaller via OSINT het volgende achterhalen:

• Welke cloudproviders en SaaS-platforms een organisatie gebruikt
• Welke e-mailbeveiliging (of het gebrek daaraan) er actief is
• Historische datalekken met bijbehorende wachtwoorden of e-mailadressen
• Technologiestacks via headers, cookies en metadata van websites
• Interne structuur via openbare documenten met metadata

Het gevaarlijke aan OSINT is juist dat het zo laagdrempelig is. Een aanvaller hoeft geen geavanceerde hacker te zijn om deze informatie te verzamelen. De informatie is er gewoon, en wie weet waar hij moet kijken, vindt het. Een grondige penetratietest begint daarom altijd met een externe verkenning vanuit het perspectief van een aanvaller.

Wat zoeken hackers in vacatures en social media?

Vacatures en sociale media zijn voor een hacker een goudmijn aan informatie over de interne werking van een organisatie. Uit een vacature voor een systeembeheerder kan een aanvaller afleiden welke technologieën een bedrijf gebruikt, welke beveiligingstools er aanwezig zijn en zelfs welke kennis er intern ontbreekt. Sociale media geven inzicht in de organisatiestructuur, namen van medewerkers en hun functies.

LinkedIn is daarbij bijzonder waardevol voor aanvallers. Via het netwerk van een organisatie kunnen ze zien wie er werkt, welke rollen ze bekleden en via welke externe partijen of leveranciers het bedrijf verbonden is. Dat laatste is relevant omdat aanvallers steeds vaker kiezen voor aanvallen via de supply chain: door een leverancier of MSP te compromitteren, krijgen ze indirect toegang tot de eigenlijke doelorganisatie.

Vacatureteksten bevatten bovendien regelmatig specifieke versienummers, productbenamingen of interne terminologie die een aanvaller helpt zijn aanval te preciseren. Een vacature die vraagt om ervaring met een specifieke firewallversie vertelt een aanvaller precies welk systeem hij moet onderzoeken op bekende kwetsbaarheden.

Hoe ontdekken aanvallers kwetsbare systemen aan de buitenkant?

Aanvallers scannen het volledige externe aanvalsoppervlak van een organisatie met gespecialiseerde tools die het internet systematisch doorzoeken op open poorten, actieve diensten en bekende kwetsbaarheden. Dit heet externe reconnaissance en vormt de technische tegenhanger van de informatie die via OSINT wordt verzameld. Systemen die onbedoeld aan het internet hangen, verouderde software draaien of verkeerd geconfigureerd zijn, vallen hierbij direct op.

Wat aanvallers hierbij onderscheidt van een eenvoudige vulnerability scanner, is de manier waarop ze bevindingen interpreteren. Een geautomatiseerde scanner rapporteert losse kwetsbaarheden. Een aanvaller kijkt naar de combinatie: welke systemen zijn bereikbaar, welke identiteiten en permissies hangen eraan, en hoe kunnen meerdere kleine zwaktes samen leiden tot een werkend aanvalspad? Dit onderscheid is precies waarom een handmatige penetratietest verder gaat dan een automatische scan.

Voorbeelden van wat aanvallers aan de buitenkant zoeken:

• Onbeveiligde remoteaccessdiensten zoals RDP of VPN zonder MFA
• Verlopen of zwak geconfigureerde SSL-certificaten
• Vergeten testomgevingen of subdomeinen die niet meer worden onderhouden
• Publiek toegankelijke beheerinterfaces van routers, firewalls of servers
• Cloudresources die per ongeluk publiek toegankelijk zijn gemaakt

Waarom zijn medewerkers een primair doelwit in de verkenningsfase?

Medewerkers zijn voor aanvallers interessant omdat zij de menselijke toegangspoort vormen tot systemen die technisch goed beveiligd kunnen zijn. In de verkenningsfase verzamelt een aanvaller namen, e-mailadressen, functies en gedragspatronen van medewerkers om gerichte phishing- of socialengineeringaanvallen voor te bereiden. Hoe meer een aanvaller weet over een specifieke medewerker, hoe overtuigender en gevaarlijker de aanval.

Aanvallers richten zich daarbij niet willekeurig op medewerkers. Ze zoeken specifiek naar personen met verhoogde rechten of toegang tot gevoelige systemen, zoals systeembeheerders, financiële medewerkers of directieleden. Ook nieuwe medewerkers zijn een aantrekkelijk doelwit, omdat zij minder vertrouwd zijn met interne procedures en daardoor sneller geneigd zijn op een verzoek in te gaan zonder het te verifiëren.

Daarnaast kijken aanvallers naar medewerkers die betrokken zijn bij leveranciers of externe partijen. Via een medewerker die toegang heeft tot klantomgevingen of supplychainsystemen, kan een aanvaller zijn bereik ver buiten de eigen organisatie uitbreiden. Dit maakt bewustwording en security awareness een onmisbaar onderdeel van een volwassen beveiligingsaanpak.

Hoe weet je of jouw organisatie al in het vizier van een hacker ligt?

In de meeste gevallen weet je dat niet, en dat is precies wat de verkenningsfase zo gevaarlijk maakt. Omdat een aanvaller in deze fase uitsluitend gebruikmaakt van openbare informatie en passieve technieken, laat hij vrijwel geen sporen achter in jouw systemen. Toch zijn er signalen en maatregelen die kunnen helpen om vroegtijdig te detecteren of jouw organisatie actief wordt verkend.

Enkele indicatoren om op te letten:

• Ongebruikelijk veel zoekopdrachten op jouw domeinnaam of subdomeinen in serverlogs
• Herhaalde inlogpogingen op externe diensten vanuit onbekende locaties
• Phishingmails die intern jargon of namen van collega’s bevatten, wat duidt op voorafgaand onderzoek
• Meldingen van medewerkers over verdachte LinkedIn-verbindingsverzoeken van onbekende profielen

De beste manier om te begrijpen hoe jouw organisatie eruitziet vanuit het perspectief van een aanvaller, is door zelf die blik aan te nemen. Een redteamoefening simuleert precies wat een echte aanvaller zou doen in de verkenningsfase en daarna, zodat kwetsbaarheden aan het licht komen voordat een echte aanvaller ze ontdekt.

Hoe Q-Cyber helpt bij het begrijpen van jouw aanvalsoppervlak

Wij bij Q-Cyber helpen organisaties om hun eigen kwetsbaarheid te zien door de ogen van een aanvaller. Niet met een lijst van losse bevindingen, maar met inzicht in hoe een echte aanvaller jouw organisatie zou verkennen en welke aanvalspaden daadwerkelijk gevaarlijk zijn. Concreet bieden we:

• Handmatige penetratietesten waarbij onze ethical hackers dezelfde verkennings- en aanvalstechnieken gebruiken als echte cybercriminelen
• Externe aanvalsoppervlakanalyse om te achterhalen wat er over jouw organisatie openbaar vindbaar is
• Redteamoefeningen die de volledige aanvalsketen simuleren, van OSINT tot toegang
• Continu inzicht via Continuous-Q® zodat je niet alleen op de testdag weet waar je staat, maar het hele jaar door

Een eenmalige scan of jaarlijkse test vertelt je hoe je er op dat moment voor staat. Maar aanvallers stoppen niet na die ene dag. Wil je weten hoe jouw organisatie eruitziet vanuit het perspectief van een hacker? Neem contact met ons op en we kijken samen wat de beste aanpak is voor jouw situatie.

Lees meer