Wat een cyberverzekering wel en niet dekt

Steeds meer organisaties sluiten een cyberverzekering af. Dat is een logische stap, want de financiële gevolgen van een incident kunnen groot zijn. Het probleem ontstaat zodra een organisatie de verzekering ziet als vervanging van beveiligingsbeleid, in plaats van als aanvulling erop.

Dat onderscheid is belangrijker dan het lijkt, en het wordt vaak pas duidelijk op het moment dat het te laat is: bij het indienen van een claim.

Waarom verzekeraars steeds strenger worden

Cyberverzekeraars hebben de afgelopen jaren fors meer uitbetaald dan ze hadden voorzien. Ransomware-aanvallen, datalekken en bedrijfsonderbreking door cyberincidenten zijn vaker voorgekomen en hebben hogere schadebedragen opgeleverd dan de premies dekten. Het gevolg: verzekeraars stellen scherpere eisen aan de organisaties die ze verzekeren.

Waar een paar jaar geleden een vragenlijst van een pagina voldoende was, vragen verzekeraars nu om concreet bewijs van genomen maatregelen. Multifactorauthenticatie, een actueel patchbeleid, segmentatie van het netwerk, een werkend back-upproces: dit zijn geen suggesties meer, maar voorwaarden voor dekking.

Wie deze eisen niet kan aantonen, betaalt een hogere premie, krijgt een lagere dekking, of wordt simpelweg niet verzekerd.

Wat een polis vaak niet dekt

Een cyberverzekering wekt soms de indruk dat alle financiële gevolgen van een incident worden afgedekt. In de praktijk zijn er belangrijke uitsluitingen die organisaties pas ontdekken als het te laat is.

Verlies door nalatigheid

Als een organisatie kan aantonen dat ze structureel heeft nagelaten basismaatregelen te nemen, bijvoorbeeld het niet installeren van bekende beveiligingsupdates, kan een verzekeraar de claim afwijzen. De polis dekt risico, niet onachtzaamheid.

Reputatieschade

De financiële impact van klantverlies, een dalende beurskoers of een verslechterde concurrentiepositie is zelden volledig gedekt. Verzekeraars vergoeden doorgaans de directe kosten van een incident, niet de langetermijngevolgen voor de marktpositie.

Boetes en sancties

Boetes die door toezichthouders worden opgelegd, bijvoorbeeld onder de AVG of straks de Cyberbeveiligingswet, zijn in veel polissen uitgesloten of slechts beperkt gedekt. De gedachte achter deze uitsluiting: een verzekering mag niet fungeren als vrijwaring voor het overtreden van de wet.

Statelijke aanvallen

Veel polissen bevatten een uitsluiting voor aanvallen die worden toegeschreven aan statelijke actoren, een zogenaamde “act of war” clausule. Het probleem: attributie van een aanval aan een staat is vaak onduidelijk, wat tot langdurige juridische geschillen kan leiden over de vraag of een incident wel of niet is gedekt.

Verlies van onderhandelingspositie

Sommige polissen vereisen dat de verzekeraar wordt geraadpleegd voordat losgeld wordt betaald of voordat met een aanvaller wordt onderhandeld. Organisaties die zelfstandig handelen, lopen het risico dat de uiteindelijke kosten niet worden vergoed.

De polis werkt pas als de basis op orde is

Dit is de kern van het probleem met de gedachte dat een verzekering voldoende is: een polis is een vangnet voor onverwachte schade, niet een vervanging voor het beperken van risico. Verzekeraars verwachten, en eisen steeds vaker contractueel, dat een organisatie een redelijk niveau van beveiliging op orde heeft voordat de dekking ingaat.

Dat betekent in de praktijk dat de meeste organisaties hun beveiligingsniveau eerst moeten verbeteren om verzekerbaar te worden, niet andersom. De verzekering is het sluitstuk, niet het startpunt.

Wat verzekeraars in de praktijk vragen

De exacte eisen verschillen per verzekeraar en per sector, maar een aantal voorwaarden komt structureel terug:

• Multifactorauthenticatie op alle externe toegang en kritieke systemen
• Een actueel en getest back-upproces, gescheiden van het productienetwerk
• Een gedocumenteerd patchbeleid met aantoonbare uitvoering
• Endpoint detection en monitoring op kritieke systemen
• Een incidentresponsplan met duidelijke verantwoordelijkheden
• Beperkte en gecontroleerde toegang tot beheerdersaccounts

Organisaties die deze maatregelen niet op orde hebben, lopen het risico dat een claim wordt afgewezen op basis van onvolledige of onjuiste informatie bij het aanvragen van de polis.

Drie vragen voor bestuurders

Kunnen we de vragenlijst van onze verzekeraar nu eerlijk en volledig invullen? Niet wat we denken dat klopt, maar wat daadwerkelijk aantoonbaar is. Het verschil tussen die twee wordt zichtbaar bij een claim, niet bij het afsluiten van de polis.

Weten we precies wat onze polis wel en niet dekt? Lees de polisvoorwaarden, met name de uitsluitingen. Een goedkope polis met brede uitsluitingen biedt minder zekerheid dan een duurdere polis met een beperkter maar duidelijker dekkingsgebied.

Is onze beveiliging het startpunt of het sluitstuk van ons risicobeleid? Als het antwoord “sluitstuk” is, ligt daar het eerste werk. Een verzekering corrigeert geen structureel gebrek aan beveiliging.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties hun beveiligingsniveau in kaart te brengen en te verbeteren tot een niveau dat aansluit op wat verzekeraars eisen. We ondersteunen bij het beoordelen van polisvoorwaarden in samenhang met de daadwerkelijke beveiligingssituatie, zodat dekking en realiteit op elkaar aansluiten.

Wil je weten of jouw organisatie voldoet aan de eisen van moderne cyberverzekeraars? Neem contact op voor een vrijblijvend gesprek.

NIS2 in de praktijk: wat de toezichthouder echt van je verwacht

De Cyberbeveiligingswet, de Nederlandse uitwerking van de Europese NIS2-richtlijn, staat op het punt in werking te treden. Op 15 april 2026 stemde de Tweede Kamer in met het wetsvoorstel. De wet ligt nu ter goedkeuring voor aan de Eerste Kamer, met 1 juli 2026 als verwachte ingangsdatum. Wie nu nog denkt dat dit ver weg is, rekent verkeerd.

Veel directeuren en bestuurders weten dat NIS2 bestaat. Veel minder weten wat er concreet van hen wordt gevraagd zodra de wet ingaat. Dat onderscheid is belangrijk, want NIS2 is geen technische checklist die je aan de IT-afdeling kunt overdragen. Het is een wet die bestuurders persoonlijk verantwoordelijk maakt.

Twee wetten, niet één

Wat in de discussie over NIS2 vaak ondersneeuwt: de Tweede Kamer stemde op 15 april niet in met één, maar met twee wetsvoorstellen. Naast de Cyberbeveiligingswet (Cbw) is ook de Wet weerbaarheid kritieke entiteiten (Wwke) aangenomen, de Nederlandse implementatie van de Europese CER-richtlijn.

Waar de Cbw zich richt op digitale weerbaarheid, gaat de Wwke over fysieke weerbaarheid: de continuïteit van organisaties die essentiële diensten leveren, zoals energie, water, transport en zorg. Een belangrijk verschil met de Cbw: bij de Wwke bepaal je niet zelf of je onder de wet valt. De verantwoordelijke minister wijst organisaties aan. De regering streeft ernaar beide wetten gelijktijdig in werking te laten treden.

Voor wie geldt dit eigenlijk?

NIS2 onderscheidt twee categorieën organisaties: essentiële entiteiten en belangrijke entiteiten. Het verschil zit in de sector en de omvang van de organisatie. Essentiële entiteiten zitten in sectoren zoals energie, transport, drinkwater, bankwezen, financiële marktinfrastructuur, zorg en digitale infrastructuur. Belangrijke entiteiten zitten onder andere in postdiensten, afvalbeheer, chemie, voedsel, productie van bepaalde goederen en digitale dienstverlening.

Binnen die sectoren geldt de wet in de regel voor middelgrote en grote organisaties: vanaf 50 medewerkers of een jaaromzet van meer dan 10 miljoen euro. Kleinere organisaties kunnen alsnog onder de wet vallen als ze een kritieke rol spelen in hun sector.

Er is nog een derde groep die vaak wordt onderschat: leveranciers. Als jouw organisatie diensten levert aan een partij die onder NIS2 valt, ga je er gegarandeerd mee te maken krijgen. Niet via de wet zelf, maar via de eisen die je klant aan jou gaat stellen. De keten is zo sterk als de zwakste schakel, en die gedachte staat letterlijk aan de basis van de richtlijn.

Twijfel je of jouw organisatie onder de wet valt? De Rijksoverheid heeft hiervoor de NIS2 Zelfevaluatie gelanceerd, waarmee je zelf kunt nagaan aan welke verplichtingen je moet voldoen.

Wat de wet daadwerkelijk vraagt

NIS2 draait om drie verplichtingen: een zorgplicht, een meldplicht en een registratieplicht.

Zorgplicht

De zorgplicht houdt in dat je een risicobeoordeling uitvoert en op basis daarvan passende technische, organisatorische en operationele maatregelen neemt. Dat klinkt abstract, maar het komt neer op een aantal concrete stappen: weten welke systemen en gegevens kwetsbaar zijn, weten wat de gevolgen zijn als die uitvallen of worden gestolen, en vervolgens maatregelen nemen die in verhouding staan tot dat risico.

Dit is geen eenmalige exercitie. De zorgplicht is doorlopend: risico’s veranderen, dus de beoordeling en de maatregelen moeten meebewegen.

Meldplicht

Bij een significant incident geldt een strikte meldtermijn. Een eerste melding moet binnen 24 uur bij de toezichthouder liggen, gevolgd door een uitgebreidere melding binnen 72 uur. Dat is fors sneller dan veel organisaties nu gewend zijn, en het vraagt om een proces dat al klaarstaat voordat er iets misgaat. Een incidentresponsplan dat pas tijdens de crisis wordt opgesteld, voldoet niet.

Registratieplicht

Organisaties die onder de wet vallen, moeten zich registreren bij de toezichthouder. Die registratie geeft de overheid zicht op welke partijen onder de wet vallen en hoe de digitale weerbaarheid er sectorbreed voor staat.

De bestuurlijke verantwoordelijkheid: dit is het deel dat vaak wordt gemist

Het meest onderschatte element van NIS2 is de positie van het bestuur. De wet legt de verantwoordelijkheid voor cyberrisico’s niet bij de IT-afdeling, maar bij het bestuur als geheel. Dat betekent in de praktijk drie dingen.

Ten eerste: bestuurders moeten de genomen maatregelen goedkeuren en toezicht houden op de uitvoering. Niet aftekenen omdat de IT-manager het vraagt, maar daadwerkelijk begrijpen wat er speelt en een afgewogen besluit nemen.

Ten tweede: er geldt een verplichte trainingsplicht voor bestuurders. Je moet als bestuur voldoende kennis hebben om de risico’s en de genomen maatregelen te kunnen beoordelen. Onwetendheid is geen verdediging.

Ten derde, en dit is de kern: bij onvoldoende naleving kan het bestuur persoonlijk aansprakelijk worden gesteld. In ernstige gevallen kan dat leiden tot een bestuursverbod. Daarnaast kunnen de boetes voor de organisatie zelf oplopen tot 10 miljoen euro of 2 procent van de wereldwijde jaaromzet, afhankelijk van wat hoger uitvalt. Dit verschuift cybersecurity van een operationeel onderwerp naar een boardroom-onderwerp.

Hoe ver moet je gaan?

Een veelgestelde vraag is hoeveel een organisatie precies moet doen om te voldoen. Er is geen vaste checklist die voor elke organisatie hetzelfde is, want NIS2 werkt met het principe van passendheid: de maatregelen moeten in verhouding staan tot het risico, de omvang en de aard van de organisatie.

Wat in de praktijk wel als basis geldt:

• Een actuele risicobeoordeling van systemen en gegevens
• Toegangsbeheer en multifactorauthenticatie voor kritieke systemen
• Een werkend incidentresponsplan, inclusief geoefende meldprocedures
• Beleid voor leveranciersbeheer en ketenrisico’s
• Bewustwording en training, ook op bestuursniveau
• Encryptie van gevoelige gegevens
• Een proces voor het structureel evalueren en bijstellen van maatregelen

Organisaties die al werken met ISO 27001 hebben een voorsprong. De normen overlappen voor een groot deel, en een goed ingericht informatiebeveiligingsmanagementsysteem dekt veel van wat NIS2 vraagt.

Waarom nu beginnen, ook al is de wet nog niet officieel in werking

Een redenering die je vaak hoort: de wet is er nog niet, dus we wachten tot die er is. Dat is om twee redenen riskant.

De eerste reden is praktisch. De meeste organisaties hebben vier tot zes maanden nodig om hun cybersecurity en leveranciersbeheer op het vereiste niveau te krijgen. Wie wacht tot de wet ingaat, begint te laat.

De tweede reden is inhoudelijk. Een aantal recente incidenten in Nederland, waaronder grootschalige datalekken bij organisaties die met de overheid samenwerken, laat zien dat het risico niet wacht op wetgeving. Minister Van Weel verwoordde het bij de stemming in de Tweede Kamer treffend: de dreiging van cyberaanvallen en verstoringen is geen abstract risico meer, maar dagelijkse realiteit. De wet is uitgesteld, het risico niet.

Drie vragen om mee te beginnen

1. Vallen wij onder de Cyberbeveiligingswet, direct of als leverancier? Bepaal je sector, omvang en positie in de keten. Dit is het startpunt van elke verdere stap.
2. Hebben we een actuele risicobeoordeling? Niet een document van drie jaar geleden, maar een beoordeling die de huidige situatie weerspiegelt en die regelmatig wordt bijgewerkt.
3. Kan ons bestuur uitleggen welke risico’s we lopen en welke maatregelen we daarvoor hebben genomen? Als het antwoord nee is, ligt daar de eerste prioriteit. Niet bij een nieuwe tool, maar bij bestuurlijke kennis en betrokkenheid.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties NIS2 vertalen naar een praktisch en haalbaar plan. We voeren risicobeoordelingen uit, beoordelen of bestaande maatregelen voldoende zijn, en ondersteunen bij het inrichten van een proces voor leveranciersbeheer en incidentrespons dat aansluit op wat de wet vraagt.

Wil je weten of jouw organisatie onder de Cyberbeveiligingswet valt en waar je nu zou moeten beginnen? Neem contact op voor een vrijblijvend gesprek.

Zero trust: wat het betekent buiten de marketingfolder

Als je de afgelopen jaren leveranciers van beveiligingssoftware hebt gesproken, is de kans groot dat zero trust voorbij is gekomen. Soms als productfeature, soms als architectuurvisie, soms als antwoord op een vraag die je niet had gesteld.

Dat heeft de term geen goed gedaan. Want het onderliggende idee is helder en praktisch nuttig. Het is alleen begraven geraakt onder een laag marketing.

Wat zero trust eigenlijk betekent

Het traditionele beveiligingsmodel gaat uit van een kasteel. Alles binnen het bedrijfsnetwerk is vertrouwd, alles erbuiten niet. Wie eenmaal binnen is, kan vrij bewegen. Dat model dateert uit een tijd dat medewerkers op kantoor werkten, data op lokale servers stond en applicaties niet in de cloud draaiden.

Die situatie bestaat lang niet overal meer. Medewerkers werken thuis, onderweg en op locatie bij klanten. Applicaties draaien in public clouds zoals AWS en Azure of in een datacenter. Leveranciers hebben toegang tot interne systemen. De grens van het kasteel is daarmee vervaagd.

Zero trust stelt daar een ander uitgangspunt tegenover: vertrouw niets en niemand standaard, ongeacht de locatie. Niet de medewerker die al tien jaar in dienst is, niet het apparaat dat al jaren op het netwerk zit, niet de applicatie die van binnen het netwerk verbinding maakt. Elke toegangspoging wordt geverifieerd, elke keer opnieuw.

Dat klinkt streng. In de praktijk merkt een medewerker er weinig van als het goed is ingericht.

Drie principes die het concreet maken

• Verifieer altijd (always verify)
  Toegang wordt pas verleend nadat identiteit, apparaat en context zijn geverifieerd. Wie is dit, welk apparaat gebruikt hij, vanwaar maakt hij verbinding en welke rechten zijn daarvoor nodig? Multifactorauthenticatie is een basisonderdeel van dit principe. Het gaat ook verder: een apparaat zonder actuele updates of zonder beveiligingssoftware kan worden geweigerd, zelfs als de gebruikersidentiteit klopt.
• Verleen minimale toegang (least privilege)
  Medewerkers krijgen alleen toegang tot wat ze nodig hebben voor hun werk, niet meer. Een medewerker van de financiële afdeling heeft geen toegang nodig tot de productiesystemen. Een leverancier die een specifieke applicatie onderhoudt, heeft geen toegang nodig tot de rest van het netwerk. Dit principe heet least privilege en is een van de meest effectieve maatregelen om schade te beperken als een account wordt gecompromitteerd.
• Ga uit van inbreuk (assume breach)
  Dit is het meest ongemakkelijke principe, maar ook het meest eerlijke. Ontwerp systemen en processen alsof een aanvaller al binnen is. Wat kan hij bereiken? Hoe ver kan hij bewegen? Hoe snel wordt hij opgemerkt? Wie dit serieus neemt, investeert in segmentatie, monitoring en detectie, niet alleen in het voorkomen van toegang.

Waarom dit nu actueel is

Zero trust is geen nieuw concept. Het werd al in 2010 geïntroduceerd door analist John Kindervag bij Forrester Research. Wat veranderd is, is de context.

De reeks kwetsbaarheden die de afgelopen maanden publiek is gemaakt, laat een patroon zien: aanvallers die via een beperkt account volledige systeemrechten weten te verkrijgen. Copy Fail, Dirty Frag, MiniPlasma, CIFSwitch. Allemaal variaties op hetzelfde thema: een gebruiker met beperkte rechten die door een fout in het systeem uitgroeit tot beheerder met volledige controle.

Zero trust verkleint de schade van precies dit type aanval. Als toegang consequent wordt beperkt tot wat nodig is, en als systemen zijn gesegmenteerd zodat een gecompromitteerd account niet direct toegang geeft tot alles, dan is de impact van zo’n kwetsbaarheid aanzienlijk kleiner. De aanvaller komt wel binnen, maar kan een stuk minder.

Wat het in de praktijk vraagt

Zero trust implementeren is geen project met een einddatum. Het is een richting die je inslaat en stap voor stap uitwerkt. De meeste organisaties beginnen met de meest impactvolle onderdelen.

Identiteit en toegangsbeheer

Wie heeft toegang tot wat, en is dat nog actueel? Voormalige medewerkers, oud-leveranciers, accounts met te brede rechten: dit is waar de meeste organisaties de meeste winst boeken met de minste inspanning.

• Multifactorauthenticatie
  Een gestolen wachtwoord is niet genoeg voor toegang als MFA is ingeschakeld. Dit is een van de meest effectieve en relatief goedkope maatregelen die een organisatie kan nemen.
• Netwerksegmentatie
  Verdeel het netwerk in zones. Een aanvaller die toegang krijgt tot een zone, kan niet automatisch door naar de rest. Dit beperkt de schade bij een incident aanzienlijk. In sommige situaties kan het zelfs waardevol zijn om microsegmentatie te doen waarbij alle devices van elkaar geïsoleerd zijn.
• Monitoring en detectie
  Als je uitgaat van inbreuk, moet je ook kunnen zien wanneer er iets misgaat. Logging, alerting en actieve monitoring zijn geen luxe maar een basisonderdeel van een volwassen beveiligingsaanpak.

Wat zero trust niet is

Zero trust is geen product dat je koopt. Geen leverancier die zegt dat zijn platform zero trust is, verkoopt je daarmee een complete aanpak. Hij verkoopt je een onderdeel dat bij een zero trust strategie past, of niet.

Het is ook geen binaire keuze. Je bent nooit klaar met zero trust, net zoals je nooit klaar bent met risicomanagement. Het is een continu proces van verbeteren, controleren en aanpassen aan een veranderende omgeving.

Wat het wel is: een nuttig kader om beveiligingsbeslissingen aan te toetsen. Verleent deze maatregel minimale toegang? Verifiëren we identiteit en context? Zijn we voorbereid op inbreuk? Wie die drie vragen consequent stelt, maakt betere keuzes dan wie dat niet doet.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties een praktische invulling te geven aan zero trust principes, zonder onnodige complexiteit en zonder de belofte dat één oplossing alle problemen oplost. We brengen in kaart waar de grootste risico’s zitten, welke stappen het meest impact hebben en hoe dat aansluit op de bestaande omgeving en het beschikbare budget.

Wil je weten waar jouw organisatie staat en waar de meeste winst te behalen valt? Neem contact op voor een vrijblijvend gesprek.

Wat een cyberaanval echt kost: verder dan de directe schade

Als organisaties nadenken over het risico van een cyberaanval, gaat de gedachte al snel naar de directe schade: verloren data, versleutelde systemen, herstelkosten. Begrijpelijk, want dat zijn de meest tastbare gevolgen. Maar wie de totale impact wil begrijpen, kijkt verder dan die eerste laag.

De werkelijke kosten van een cyberaanval bestaan uit meerdere onderdelen, en de indirecte schade is in de praktijk vaak groter dan de directe. Dat maakt het ook een bestuurlijk vraagstuk, niet alleen een IT-probleem.

De directe kosten: wat je meteen ziet

De meest zichtbare kosten zijn de kosten die direct voortvloeien uit het incident zelf. Die omvatten onder andere:

• Herstelkosten voor systemen en data
  Het terugzetten van systemen, het herstellen van data en het opnieuw inrichten van omgevingen kost tijd en geld. Bij een ransomware-aanval komen daar mogelijk de kosten van professionele decryptiediensten bij, als back-ups niet voldoende blijken.
• Forensisch onderzoek
  Na een incident moet worden onderzocht hoe de aanvaller binnen is gekomen, hoe lang hij toegang heeft gehad en welke systemen en data zijn geraakt. Dat vereist gespecialiseerde expertise en neemt tijd in beslag, soms weken.
• Juridische bijstand en compliance
  Bij een datalek moeten getroffen personen en in veel gevallen de Autoriteit Persoonsgegevens worden geïnformeerd, binnen 72 uur na ontdekking. Dat proces vereist juridische begeleiding. Als de melding te laat of onvolledig is, kunnen daar sancties op volgen.
• Crisismanagement en communicatie
  Hoe communiceer je naar klanten, leveranciers en de pers? Organisaties die dit niet van tevoren hebben geregeld, huren in een crisis externe communicatiespecialisten in. Dat zijn geen kleine rekeningen.

De indirecte kosten: wat je pas later ziet

De indirecte kosten zijn moeilijker te kwantificeren, maar in de praktijk minstens zo groot. Ze manifesteren zich niet altijd direct na het incident, maar in de weken en maanden daarna.

• Omzetverlies door stilstand
  Systemen die niet beschikbaar zijn, betekenen processen die stilliggen. Gemiddeld zijn organisaties na een ransomware-aanval twee tot vier weken beperkt operationeel. De kosten lopen door; de omzet valt weg.
• Reputatieschade
  Klanten die afhaken, contracten die niet worden verlengd, partners die twijfelen. Reputatieschade is de moeilijkst te kwantificeren post, maar onderzoek laat consistent zien dat het de grootste langetermijnimpact heeft.
• Verhoogde verzekeringspremies
  Na een incident stijgen cyberverzekeringspremies aanzienlijk, of wordt een organisatie in het geheel moeilijker verzekerbaar. Dat effect houdt meerdere jaren aan.
• Productiviteitsverlies
  Medewerkers die niet kunnen werken, IT-personeel dat weken in crisisstand zit, management dat wordt opgeslokt door het incident. De uren zijn zelden zichtbaar in de schadeberekening, maar de kosten zijn reëel.
• Aansprakelijkheid
  Als klantdata is gelekt, kunnen getroffen partijen schadeclaims indienen. Onder NIS2 zijn bestuurders bovendien persoonlijk verantwoordelijk voor het beveiligingsbeleid van de organisatie. Niet-nakoming kan leiden tot persoonlijke aansprakelijkheid.
• Concurrentiepositie
  Terwijl jouw organisatie herstelt, staat de concurrentie niet stil. Klanten die tijdelijk naar een concurrent overstappen, keren niet altijd terug. Dat effect is lastig te meten, maar in sectoren met weinig loyaliteit structureel merkbaar.

Wat zeggen de cijfers?

IBM publiceert jaarlijks een rapport over de kosten van datalekken. De gemiddelde kosten van een datalek lagen in 2024 wereldwijd op 4,88 miljoen dollar, een stijging van tien procent ten opzichte van het jaar daarvoor. Voor Europa liggen de gemiddelden iets lager, maar de richting is dezelfde. Voor het mkb, dat minder reserves heeft om een incident op te vangen, is de relatieve impact vaak groter dan voor grote organisaties.

Die cijfers zijn gemiddelden. De werkelijke kosten per incident variëren sterk en zijn afhankelijk van de omvang van de aanval, de sector, de voorbereiding van de organisatie en de snelheid van respons. Organisaties die een goed ingericht incidentresponsplan hadden, leden gemiddeld aanzienlijk minder schade dan organisaties die dat niet hadden.

Preventie versus herstel: de rekensom

De vraag die bestuurders zichzelf zouden moeten stellen, is niet “hoeveel kost goede beveiliging?” maar “hoeveel kost een incident dat we hadden kunnen voorkomen?”

Preventieve maatregelen zoals patchbeheer, toegangscontrole, monitoring en incidentresponsplanning hebben een vaste, beheersbare kostprijs. De kosten van een incident zijn variabel, onvoorspelbaar en in de meeste gevallen een veelvoud van wat preventie had gekost.

Dat is geen argument voor ongelimiteerde beveiligingsinvesteringen. Het is een argument voor bewuste keuzes: welke risico’s zijn acceptabel, welke niet, en wat is de kostprijs van de maatregelen die die afweging rechtvaardigen?

Drie vragen voor bestuurders

• Wat zou een week stilstand ons kosten?
  Niet alleen in omzet, maar ook in personeelskosten, contractverplichtingen en reputatie. Dit getal helpt de juiste schaal te bepalen voor beveiligingsinvesteringen.
• Zijn we verzekerbaar en onder welke voorwaarden?
  Cyberverzekeraars stellen steeds hogere eisen aan de beveiligingsmaatregelen van organisaties. Wie niet aan die eisen voldoet, betaalt meer of wordt niet gedekt bij een claim.
• Wat is onze persoonlijke aansprakelijkheid als bestuurder?
  Onder NIS2 zijn bestuurders van organisaties die onder de richtlijn vallen persoonlijk verantwoordelijk voor het beveiligingsbeleid. Dat maakt cybersecurity een onderwerp voor de boardroom, niet alleen voor de IT-afdeling.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties inzicht te krijgen in hun werkelijke risicoprofiel en de kosten die daarmee samenhangen. We vertalen technische kwetsbaarheden naar zakelijke impact, ondersteunen bij het maken van gefundeerde beveiligingskeuzes en helpen bij het inrichten van maatregelen die aansluiten op wat de organisatie nodig heeft.

Wil je weten wat een incident jouw organisatie zou kosten en welke maatregelen dat risico het meest effectief verkleinen? Neem contact op voor een vrijblijvend gesprek.

CIFSwitch: een negentien jaar oude Linux-kwetsbaarheid die nu actie vraagt

Een kwetsbaarheid die sinds 2007 in de Linux-kernel aanwezig is, maakt het mogelijk om volledige systeemrechten te verkrijgen op een breed scala aan Linux-omgevingen. Er is een werkende aanvalscode gepubliceerd. Een kernelpatch is beschikbaar maar wordt nog uitgerold door de distributies.

Linux-gebruikers en -beheerders zijn de afgelopen weken geconfronteerd met een reeks kwetsbaarheden: Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt en PinTheft kwamen allemaal in korte tijd naar buiten. CIFSwitch is de nieuwste in die reeks, en onderscheidt zich door zijn leeftijd: de fout bestaat al negentien jaar.

De kwetsbaarheid werd ontdekt door een beveiligingsonderzoeker van SpaceX, die een uitgebreide technische toelichting en een werkende aanvalscode heeft gepubliceerd. Actief misbruik is op het moment van schrijven nog niet gemeld, maar de beschikbaarheid van die aanvalscode verlaagt de drempel voor misbruik aanzienlijk.

Wat is CIFS en waarom is dit relevant?

CIFS, voluit Common Internet File System, is een protocol waarmee Linux-systemen bestanden en mappen op andere computers in een netwerk kunnen benaderen. Vergelijkbaar met hoe een Windows-computer een gedeelde netwerkschijf koppelt. Dit protocol wordt veel gebruikt in bedrijfsomgevingen waar Linux-servers samenwerken met andere systemen, bijvoorbeeld bij gedeelde opslag of bestandsuitwisseling tussen servers.

Wanneer zo’n gedeelde schijf is beveiligd met Kerberos-authenticatie, een veelgebruikte methode in zakelijke netwerken, dan vraagt de Linux-kernel een hulpprogramma om die authenticatie af te handelen. Dat hulpprogramma draait met volledige beheerdersrechten. De fout in CIFSwitch zit in het feit dat de kernel niet controleert of verzoeken aan dat hulpprogramma daadwerkelijk van de kernel zelf afkomstig zijn. Een aanvaller kan die controle omzeilen, het hulpprogramma misleiden en via die weg volledige systeemrechten verkrijgen.

Welke systemen zijn kwetsbaar?

De kwetsbaarheid is niet universeel: of een systeem daadwerkelijk kwetsbaar is, hangt af van een combinatie van factoren. Denk aan de versie van de Linux-kernel, de aanwezigheid van het cifs-utils pakket in versie 6.14 of hoger, en de configuratie van beveiligingsbeleid op het systeem.

Distributies die in de standaardconfiguratie kwetsbaar zijn, zijn onder andere bepaalde versies van Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux en Amazon Linux, maar uitsluitend als cifs-utils geïnstalleerd is. Nieuwere versies zoals Ubuntu 26.04, Fedora 40 tot en met 44, CentOS Stream 10 en Rocky Linux 10 zijn dankzij strengere standaardinstellingen voor beveiligingsbeleid niet kwetsbaar via de standaardconfiguratie.

Kortom: niet elke Linux-omgeving loopt risico, maar de combinatie van een ouder systeem met gedeelde netwerkschijven via Kerberos is een duidelijk risicogebied.

Wat nu te doen

• Installeer de kernelupdate zodra die beschikbaar is voor jouw distributie
  De upstream kernelpatch is beschikbaar. De grote distributies rollen deze momenteel uit. Controleer of de update beschikbaar is voor jouw omgeving en voer deze zo snel mogelijk door.
• Schakel de CIFS-module uit als die niet wordt gebruikt
  Veel systemen hebben de CIFS-module geladen zonder dat die actief wordt gebruikt. Het uitschakelen ervan elimineert het aanvalspad volledig op die systemen.
• Controleer of de CIFS-module actief is:
  lsmod | grep cifs
• Schakel de module permanent uit:
  echo "install cifs /bin/false" > /etc/modprobe.d/disable-cifs.conf
rmmod cifs 2>/dev/null
• Verwijder cifs-utils als het niet nodig is
  Het hulpprogramma cifs-utils is een vereiste voor de aanval. Op systemen waar geen gebruik wordt gemaakt van CIFS-gedeelde schijven, kan het pakket worden verwijderd.
• Verwijder cifs-utils (Debian/Ubuntu):
  apt remove cifs-utils
• Verwijder cifs-utils (Red Hat/CentOS/AlmaLinux):
  dnf remove cifs-utils
• Schakel onbevoegde gebruikersnaamruimten uit
  De aanval maakt gebruik van een Linux-functie waarmee gewone gebruikers geïsoleerde omgevingen kunnen aanmaken. Op systemen waar dit niet noodzakelijk is, kan deze functie worden uitgeschakeld als aanvullende beveiligingsmaatregel. Let op: dit kan invloed hebben op containergebaseerde omgevingen zoals Docker.
• Schakel onbevoegde gebruikersnaamruimten uit:
  sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" >> /etc/sysctl.conf

Een patroon dat aandacht verdient

CIFSwitch is de zesde kwetsbaarheid van dit type die in korte tijd publiek is gemaakt voor Linux. Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt en PinTheft gingen eraan vooraf. Dat is geen toeval: zodra een onderzoeker diep in een onderdeel van de kernel duikt, vindt hij er vaker meer. De aanpak verspreidt zich ook: andere onderzoekers gebruiken dezelfde methoden om vergelijkbare fouten te vinden in andere onderdelen.

Voor organisaties die Linux draaien, betekent dit dat de afgelopen maanden een bovengemiddeld aantal kwetsbaarheden in dit besturingssysteem publiek is geworden. Wie patchbeheer niet structureel heeft georganiseerd, heeft de afgelopen weken meerdere keren achter de feiten aangelopen.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals CIFSwitch. We brengen in kaart welke systemen risico lopen, beoordelen of tijdelijke maatregelen correct zijn doorgevoerd en ondersteunen bij het inrichten van een patchproces dat aansluit op de snelheid waarmee dit soort dreigingen zich de afgelopen tijd hebben ontwikkeld.

Wil je weten of jouw Linux-omgeving kwetsbaar is of hoe jullie patchproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

YellowKey: een USB-stick waarmee BitLocker-versleuteling op Windows omzeild wordt

BitLocker is de ingebouwde versleutelingsfunctie van Windows waarmee organisaties hun laptops en servers beschermen tegen onbevoegde toegang. De gedachte is eenvoudig: als een laptop wordt gestolen of kwijtgeraakt, kan een dief zonder de juiste sleutel niets met de gegevens. Die aanname staat nu onder druk.

Een beveiligingsonderzoeker heeft een kwetsbaarheid gepubliceerd, YellowKey genaamd, waarmee BitLocker-versleuteling op Windows 11 en Windows Server 2022 en 2025 volledig kan worden omzeild. De aanvalscode is publiek beschikbaar op GitHub. Microsoft heeft de kwetsbaarheid inmiddels erkend onder CVE-2026-45585 en tijdelijke mitigatiestappen gepubliceerd. Een definitieve patch is nog in ontwikkeling.

Hoe werkt de aanval?

De aanval is verrassend eenvoudig uit te voeren. Wie fysieke toegang heeft tot een computer, kopieert een mapje met de naam FsTx naar een USB-stick. Vervolgens wordt de computer opgestart vanuit die USB-stick, waarna een fout in de Windows-herstelomgeving wordt misbruikt om toegang te krijgen tot de versleutelde schijf, zonder dat daarvoor een wachtwoord of herstelsleutel nodig is.

De kwetsbaarheid zit in de manier waarop de Windows Recovery Environment omgaat met een specifieke registerwaarde. Via die fout kan een kwaadaardig programma worden uitgevoerd voordat het besturingssysteem volledig is geladen, waarmee de pre-boot authenticatie van BitLocker volledig wordt omzeild.

Voor misbruik is fysieke toegang tot de computer vereist. De kwetsbaarheid treft Windows 11, Windows Server 2022 en Windows Server 2025. Windows 10 is niet kwetsbaar. Dat betekent dat de aanval relevant is in scenario’s waarbij een laptop of server in verkeerde handen valt, bijvoorbeeld bij diefstal, verlies of onbeheerde toegang tijdens onderhoud of reparatie.

Wat dit betekent voor organisaties

Veel organisaties vertrouwen op BitLocker als laatste verdedigingslinie voor laptops van medewerkers. De redenering is begrijpelijk: als een laptop wordt gestolen, zijn de gegevens onleesbaar. Die aanname klopt niet meer voor organisaties die Windows 11 draaien zonder aanvullende maatregelen.

De drempel voor misbruik is laag. De aanvalscode is publiek, de benodigde kennis minimaal en een USB-stick kost een paar euro. Dat maakt dit niet alleen een risico bij gerichte aanvallen, maar ook bij opportunistisch misbruik na diefstal of verlies van een apparaat.

De publieke beschikbaarheid van de YellowKey-aanvalscode verlaagt de drempel aanzienlijk, ook voor minder technisch onderlegde aanvallers.

Mitigatie: wat Microsoft adviseert

Microsoft heeft twee tijdelijke mitigatieopties gepubliceerd. Beide vereisen handmatig werk per apparaat door een systeembeheerder. Er is nog geen geautomatiseerde patch beschikbaar.

• Optie 1: Verwijder het kwetsbare onderdeel uit de herstelomgeving
  De aanval werkt doordat een kwaadaardig programma automatisch wordt gestart wanneer de Windows-herstelomgeving wordt geladen. Door dat programma uit het herstelimage te verwijderen en daarna de BitLocker-vertrouwensrelatie met de herstelomgeving te herstellen, wordt de aanvalsmethode geblokkeerd. Dit is de technisch grondigste aanpak en vereist uitvoering per apparaat.
  
  Mounten van het WinRE-image, verwijderen van autofstx.exe uit de BootExecute-registerwaarde en herstellen van BitLocker-vertrouwen:
  reagentc /disable
mkdir C:\WinRE
reagentc /info
# Noteer het pad naar Winre.wim, bijv. C:\Windows\System32\Recovery\Winre.wim
dism /Mount-Image /ImageFile:"C:\Windows\System32\Recovery\Winre.wim" /index:1 /MountDir:C:\WinRE
reg load HKLM\WinRE_System C:\WinRE\Windows\System32\config\SYSTEM
reg delete "HKLM\WinRE_System\ControlSet001\Control\Session Manager" /v BootExecute /f
reg add "HKLM\WinRE_System\ControlSet001\Control\Session Manager" /v BootExecute /t REG_MULTI_SZ /d "autocheck autochk *" /f
reg unload HKLM\WinRE_System
dism /Unmount-Image /MountDir:C:\WinRE /commit
reagentc /enable
manage-bde -protectors -disable C:
manage-bde -protectors -enable C:
  
• Optie 2: Voeg een BitLocker-pincode toe (eenvoudiger, maar beperkter)
  Het koppelen van BitLocker aan een persoonlijke pincode of een BIOS-wachtwoord blokkeert de huidige versie van YellowKey. Dit is de sneller te implementeren optie, maar let op: de onderzoeker heeft aangegeven ook een variant te hebben die TPM met pincode omzeilt. Die variant is echter vooralsnog niet publiek gemaakt.
  
  Inschakelen van TPM+PIN via Group Policy (voor beheerde omgevingen):
  Via Group Policy Editor:
  Computer Configuration > Administrative Templates >
Windows Components > BitLocker Drive Encryption >
Operating System Drives >
"Require additional authentication at startup"
  Stel in:
  Configure TPM startup PIN = Require startup PIN with TPM

• Aanvullend: stel een BIOS-wachtwoord in en beperk opstartopties
  De aanval vereist dat de computer opstart vanaf een externe USB-stick. Door in het BIOS de opstartvolgorde te beperken tot de interne schijf en dit te beveiligen met een wachtwoord, wordt het aanvalspad verder verkleind. Dit is een eenvoudige maar effectieve aanvullende maatregel, met name voor laptops die buiten de kantooromgeving worden gebruikt.

Bredere aanbevelingen voor organisaties

• Breng in kaart welke apparaten uitsluitend op TPM vertrouwen
  Laptops die buiten kantoor worden gebruikt, zijn het meest kwetsbaar bij diefstal of verlies. Zorg dat deze apparaten als eerste worden voorzien van de mitigatie.
• Controleer of Windows Server 2022 en 2025 in scope zijn
  De kwetsbaarheid treft ook servers. Hoewel fysieke toegang tot een server in een datacenter lastiger te realiseren is, verdient dit aandacht voor servers in minder beveiligde omgevingen zoals kantooromgevingen of co-locaties.
• Sla BitLocker-herstelsleutels veilig op
  Het toevoegen van een pincode heeft alleen zin als de pincode ook daadwerkelijk geheim blijft en de herstelsleutel niet eenvoudig toegankelijk is. Zorg dat herstelsleutels centraal en beveiligd worden opgeslagen, bijvoorbeeld via Microsoft Intune of Active Directory, en niet lokaal op het apparaat.
• Houd de patchstatus actief in de gaten
  Microsoft werkt aan een definitieve patch. Zodra die beschikbaar is, moet deze prioriteit krijgen bij de uitrol, ook op apparaten waar de tijdelijke mitigatie al is doorgevoerd.
• Ga voor een multilayer oplossing
  Door bijvoorbeeld voor een encryptie-oplossing van een andere partij te kiezen waarbij bij elke boot een wachtwoord of PIN-code altijd vereist is.

De kern van het probleem

YellowKey laat zien dat encryptie alleen niet voldoende is als beveiligingsmaatregel. BitLocker beschermt gegevens op een versleuteld apparaat, maar die bescherming is afhankelijk van hoe het is geconfigureerd. Een standaardinstallatie zonder pincode of BIOS-beveiliging biedt bij fysieke toegang minder bescherming dan veel organisaties aannemen. Daarbij zijn wij van mening dat encryptie waarbij elke keer het wachtwoord ingevuld moet worden uit het oogpunt van security altijd beter is.

Dat is de les die hier wordt onderstreept: versleuteling is een laag in een beveiligingsstrategie, geen sluitende oplossing op zichzelf. Wie dat begrijpt, begrijpt ook waarom de configuratie van die versleuteling minstens zo belangrijk is als het feit dat die aanstaat.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties beoordelen of hun encryptieconfiguratie aansluit op de huidige dreigingen. We brengen in kaart welke apparaten kwetsbaar zijn, ondersteunen bij het doorvoeren van mitigatiestappen en adviseren over een structurele aanpak van endpoint-beveiliging die verder gaat dan het standaard inschakelen van BitLocker.

Wil je weten of jouw organisatie kwetsbaar is voor YellowKey of hoe jullie BitLocker-configuratie er voor staat? Neem contact op voor een vrijblijvend gesprek.

Nieuwe zero-day in Windows geeft aanvallers volledige systeemtoegang op volledig bijgewerkte systemen

Deze week werd MiniPlasma gepubliceerd: een zero-day kwetsbaarheid in Windows waarvoor geen patch beschikbaar is. Via deze kwetsbaarheid kan iemand met gewone gebruikerstoegang volledige systeemrechten verkrijgen op elk Windows-systeem, inclusief systemen die volledig zijn bijgewerkt met de laatste updates van mei 2026.

Een zero-day betekent dat de kwetsbaarheid publiek bekend is voordat de softwareleverancier een oplossing heeft uitgebracht. Aanvallers kunnen er direct gebruik van maken. Microsoft heeft nog geen patch aangekondigd en heeft de kwetsbaarheid nog niet voorzien van een officieel nummer.

Wat er precies speelt

De kwetsbaarheid zit in een onderdeel van Windows dat verantwoordelijk is voor de synchronisatie van bestanden met cloudopslag, zoals OneDrive. Via een fout in dat onderdeel kan een aanvaller een proces opstarten met de hoogst mogelijke systeemrechten, de zogenaamde SYSTEM-rechten. Wie op dat niveau toegang heeft, heeft volledige controle over het systeem: bestanden inzien, aanpassen of verwijderen, andere gebruikers beheren, beveiligingssoftware uitschakelen.

Voor dit soort aanvallen is lokale toegang tot een systeem vereist, dat wil zeggen: de aanvaller moet al een account op het systeem hebben, of al op een andere manier toegang hebben verkregen. Dat klinkt als een beperking, maar in de praktijk is het dat niet. Phishing, een gestolen wachtwoord of een andere kwetsbaarheid die eerder is misbruikt, zijn gebruikelijke manieren om die eerste voet tussen de deur te krijgen. MiniPlasma is dan de volgende stap: van beperkte toegang naar volledige controle.

Getest op volledig bijgewerkte systemen

Meerdere onafhankelijke onderzoekers hebben bevestigd dat de aanvalscode werkt op Windows 11 met de meest recente updates van mei 2026. Een standaard gebruikersaccount zonder beheerdersrechten is voldoende om een omgeving te openen met volledige SYSTEM-rechten. De aanval werkt niet op de meest recente testversie van Windows 11, de zogenaamde Insider Preview Canary-build, wat erop wijst dat Microsoft bezig is met een oplossing, maar die is voor reguliere Windows-gebruikers nog niet beschikbaar.

Dat is precies wat een zero-day gevaarlijk maakt: de aanvalsmethode is beschikbaar, de oplossing nog niet.

Onderdeel van een bredere reeks

MiniPlasma staat niet op zichzelf. De afgelopen weken zijn er meerdere vergelijkbare kwetsbaarheden in Windows publiek gemaakt, waaronder BlueHammer, RedSun, YellowKey en GreenPlasma. Van de eerste twee is inmiddels bevestigd dat ze actief worden misbruikt in aanvallen. Samen vormen ze een ongewoon grote hoeveelheid publiek beschikbare aanvalsmethoden voor een besturingssysteem dat wereldwijd op honderden miljoenen systemen draait.

Voor organisaties betekent dit dat het aanvalsoppervlak op Windows-omgevingen de afgelopen weken aanzienlijk is vergroot, ook op systemen die volledig zijn bijgewerkt.

Wat nu te doen

Omdat er nog geen patch beschikbaar is, zijn de opties beperkt. Toch zijn er maatregelen die het risico verkleinen.

• Beperk lokale toegang tot systemen
  MiniPlasma vereist een bestaand account op het systeem. Hoe strikter de toegangscontrole, hoe kleiner de kans dat een aanvaller die eerste stap kan zetten. Controleer welke gebruikers toegang hebben tot welke systemen en verwijder onnodige accounts of rechten.
  Door te beperken wie er een lokale Administrator is beperk je deze kans ook.
• Schakel het Cloud Filter-onderdeel uit waar het niet nodig is
  De kwetsbaarheid zit in een onderdeel dat gekoppeld is aan cloudbestandssynchronisatie. Op systemen waar dat niet actief wordt gebruikt, kan de onderliggende driver worden uitgeschakeld. Vraag je IT-afdeling of leverancier dit te beoordelen, als je actief OneDrive gebruikt is de kans groot dat het Cloud Filter nodig is.
• Controleer of de Cloud Filter driver actief is:
  sc query cldflt
• Schakel de driver uit op systemen waar cloudbestandssynchronisatie niet nodig is:
  sc config cldflt start=disabled
sc stop cldflt
• Versterk detectie op verdacht gedrag
  Zorg dat verdachte escalatie van gebruikersrechten wordt gesignaleerd. Processen die onverwacht met SYSTEM-rechten worden gestart door een gewone gebruiker, zijn een duidelijk signaal. Goede monitoringtools herkennen dit patroon.
• Houd patchupdates actief in de gaten
  Zodra Microsoft een officiële patch uitbrengt, is snelle uitrol noodzakelijk. Gezien de reeks van recente kwetsbaarheden is de verwachting dat dit via een reguliere of spoedpatch zal gebeuren. Zorg dat je patchproces snel genoeg kan reageren.

Wat dit betekent voor jouw organisatie

Een zero-day zonder beschikbare patch vraagt om een andere aanpak dan een reguliere kwetsbaarheid. Updaten lost het probleem nu niet op. Wat wel helpt: het aanvalsoppervlak verkleinen, toegang beperken en zorgen dat verdacht gedrag op systemen wordt opgemerkt.

De combinatie van meerdere publiek beschikbare aanvalsmethoden voor Windows, waarvan sommige al actief worden misbruikt, laat zien dat de druk op Windows-omgevingen momenteel hoger is dan gebruikelijk. Organisaties die hun beveiliging primair baseren op het bijhouden van updates, merken nu dat dat niet altijd voldoende is.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals MiniPlasma, ook als er nog geen patch beschikbaar is. We beoordelen of tijdelijke maatregelen correct zijn doorgevoerd, ondersteunen bij het inrichten van detectie op verdacht gedrag en zorgen dat patchprocessen aansluiten op de snelheid waarmee dit soort dreigingen zich ontwikkelen.

Wil je weten of jouw Windows-omgeving kwetsbaar is of hoe jullie beveiligingsproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

Dirty Frag: een nieuwe Linux-kwetsbaarheid terwijl de vorige nog niet is gedicht

Weken na Copy Fail is er opnieuw een ernstige kwetsbaarheid in Linux gepubliceerd. Dirty Frag werkt op een andere manier dan de vorige, waardoor eerdere tijdelijke maatregelen geen bescherming bieden. Er is nog geen definitieve patch beschikbaar.

Begin mei schreven we over Copy Fail, een kwetsbaarheid in Linux die bijna negen jaar onopgemerkt bleef en inmiddels actief wordt misbruikt. Vorige week werd Dirty Frag gepubliceerd: een nieuwe kwetsbaarheid in hetzelfde besturingssysteem, door dezelfde onderzoeker ontdekt, met een vergelijkbare impact maar via een andere aanvalsmethode.

Het onderscheid is relevant, want organisaties die de tijdelijke maatregel voor Copy Fail hebben doorgevoerd, zijn met die maatregel niet beschermd tegen Dirty Frag.

Wat er aan de hand is

Dirty Frag maakt het mogelijk dat iemand met beperkte toegang tot een Linux-systeem zichzelf volledige beheerdersrechten geeft. Net als bij Copy Fail gaat het om een aanval die alleen in het geheugen plaatsvindt, nauwelijks sporen achterlaat en consistent werkt, zonder dat er sprake is van geluk of timing.

De kwetsbaarheid combineert twee fouten in de Linux-kernel die samen een aanval mogelijk maken. De oudste van die twee bestaat al sinds 2017, de tweede sinds 2023. Vrijwel alle grote Linux-varianten zijn kwetsbaar: Ubuntu, Red Hat, CentOS, AlmaLinux, openSUSE en Fedora zijn bevestigd getroffen.

Wat de situatie extra urgent maakt: de aanvalscode is publiek beschikbaar voordat er een definitieve patch is. De embargo op volledige publicatie werd op 7 mei doorbroken door een derde partij, waarna de onderzoeker in overleg met de beheerders besloot de technische details alsnog te publiceren. Op het moment van schrijven zijn er voor de meeste distributies nog geen definitieve kernelpatches uitgebracht.

Belangrijk: de maatregel voor Copy Fail helpt hier niet

In onze vorige blogpost adviseerden we een specifieke tijdelijke maatregel voor Copy Fail: het uitschakelen van de algif_aead kernelmodule. Die maatregel is nog steeds relevant voor Copy Fail, maar biedt geen bescherming tegen Dirty Frag. De twee kwetsbaarheden werken via andere onderdelen van de kernel.

Organisaties die die stap al hebben gezet, zijn dus nog steeds kwetsbaar voor deze nieuwe aanval. Dat vraagt om aanvullende actie.

Wat nu te doen

Zolang er geen definitieve patch beschikbaar is, zijn er tijdelijke maatregelen die de aanvalsoppervlakte verkleinen. Vraag je systeembeheerder of IT-leverancier de volgende stappen door te voeren:

• Stap 1: Schakel de kwetsbare kernelmodules uit
  Dirty Frag maakt gebruik van specifieke netwerkonderdelen in de Linux-kernel. Die onderdelen kunnen worden uitgeschakeld. Voor de meeste organisaties heeft dit geen merkbare impact op de dagelijkse werking van systemen. Voer daarna ook een geheugencache-reset uit om eventuele sporen te wissen.
  
  Schakel de modules uit en reset de geheugencache:
  sudo printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_caches
• Stap 2: Controleer of systemen mogelijk al zijn aangetast
  Microsoft heeft gesignaleerd dat er al beperkt actief misbruik plaatsvindt, waarbij aanvallers na toegang via SSH onmiddellijk proberen hogere rechten te verkrijgen. Als je twijfelt of systemen al zijn blootgesteld, is forensisch onderzoek verstandig voordat je alleen de tijdelijke maatregel toepast. Een mitigatie wist namelijk geen sporen van een aanval die al heeft plaatsgevonden.
• Stap 3: Houd de patchstatus actief in de gaten
  Distributies werken aan kernelpatches. Zodra die beschikbaar zijn voor jouw omgeving, moeten ze zo snel mogelijk worden doorgevoerd. De tijdelijke maatregel vervangt de definitieve patch niet.
• Stap 4: Vergeet de cloud niet
  Ook in cloudplatforms en containeromgevingen kan Dirty Frag worden misbruikt, afhankelijk van de configuratie. Controleer of de tijdelijke maatregel ook in die omgevingen is doorgevoerd en of je provider aanvullende guidance heeft gepubliceerd.

Wat dit zegt over de bredere situatie

Copy Fail en Dirty Frag zijn geen toevallige samenloop. Ze zijn onderdeel van een bredere klasse van kwetsbaarheden in Linux die de afgelopen jaren zijn ontdekt, waaronder Dirty Cow in 2016 en Dirty Pipe in 2022. Dezelfde onderzoeker die Copy Fail vond, ontdekte Dirty Frag juist doordat hij de eerste kwetsbaarheid zo grondig onderzocht.

Dat patroon is veelzeggend: wie een kwetsbaarheid vindt, vindt er vaak meer. En de beschikbaarheid van AI-tools versnelt dat proces. De tijd tussen het vinden van een fout en het publiceren van werkende aanvalscode wordt korter. Voor organisaties betekent dat een structurele druk op patchprocessen die niet zijn ingericht op snelheid.

De vraag is niet meer of er nieuwe kwetsbaarheden komen. De vraag is of jouw organisatie snel genoeg kan reageren als ze er zijn.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties grip te houden op kwetsbaarheden zoals Copy Fail en Dirty Frag. We beoordelen of tijdelijke maatregelen correct zijn doorgevoerd, ondersteunen bij het inrichten van een patchproces dat aansluit op de huidige snelheid van dreigingen, en helpen bij het bepalen of systemen mogelijk al zijn aangetast.

Wil je weten of jouw omgeving kwetsbaar is of hoe jullie patchproces er voor staat? Neem contact op voor een vrijblijvend gesprek.

Copy Fail: een Linux-kwetsbaarheid die al negen jaar onopgemerkt was en nu directe actie vraagt

Een ernstige kwetsbaarheid in Linux is publiek gemaakt. De fout zit al sinds 2017 in vrijwel alle versies, er is een werkende aanvalsmethode beschikbaar, en de aanval laat nauwelijks sporen achter. Organisaties die Linux gebruiken, moeten dit nu oppakken.

Vorige week werd een kwetsbaarheid in Linux publiek gemaakt onder de naam Copy Fail (CVE-2026-31431). De fout zat al negen jaar verborgen in het besturingssysteem en treft vrijwel alle gangbare versies die sinds 2017 zijn uitgebracht. Inmiddels is er een werkende aanvalsmethode beschikbaar die publiek toegankelijk is.

Dit is geen theoretisch risico. Het is een concrete kwetsbaarheid waarvoor actie vereist is.

Wat er aan de hand is

Linux is het besturingssysteem waarop een groot deel van de digitale infrastructuur draait: servers, cloudplatforms, webapplicaties en bedrijfssystemen. Ook veel Nederlandse organisaties maken er gebruik van, soms direct, soms indirect via hun cloud- of hostingprovider.

De kwetsbaarheid zit in een onderdeel van Linux dat verantwoordelijk is voor encryptie. Via die fout kan iemand met gewone, beperkte toegang tot een systeem zichzelf volledige beheerdersrechten geven. Dat betekent: volledige controle over het systeem, inclusief alle data die erop staat of doorheen gaat.

Wat deze kwetsbaarheid onderscheidt

Kwetsbaarheden in software worden regelmatig ontdekt en verholpen. Copy Fail wijkt op een aantal punten af van wat normaal gangbaar is.

• Betrouwbaar en eenvoudig uit te voeren
  De aanval werkt consistent, vereist geen geavanceerde kennis en is gebaseerd op een klein, publiek beschikbaar script. De drempel voor misbruik is laag.
• Moeilijk te detecteren
  De manipulatie vindt alleen in het geheugen plaats. Bestanden op de harde schijf worden niet gewijzigd, waardoor gangbare beveiligingstools die controleren op bestandswijzigingen niets signaleren.
• Werkt ook in cloud- en containeromgevingen
  De kwetsbaarheid kan de isolatie tussen containers doorbreken. Een aanval vanuit één applicatie kan daarmee het volledige systeem raken, inclusief andere omgevingen op dezelfde server.
• Treft vrijwel alle Linux-omgevingen
  Ubuntu, Red Hat, Amazon Linux, SUSE: alle grote varianten zijn kwetsbaar. Het maakt niet uit welke versie of configuratie, als het systeem sinds 2017 niet specifiek is aangepast, is het waarschijnlijk kwetsbaar.

Voor welke organisaties is dit relevant?

Dit speelt voor elke organisatie die gebruikmaakt van Linux-servers, cloudplatforms zoals AWS, Azure of Google Cloud, gecontaineriseerde applicaties, of externe leveranciers en hostingpartijen die op Linux-infrastructuur draaien. In de praktijk betekent dat: de meeste organisaties met een IT-omgeving van enige omvang.

Wat moet er nu gebeuren?

Er zijn twee sporen: een tijdelijke maatregel voor nu, en een structurele oplossing voor de iets langere termijn.

• Direct: schakel het kwetsbare onderdeel uit
  De kwetsbaarheid zit in een specifieke module van de Linux-kernel, het onderdeel dat encryptieoperaties afhandelt voor toepassingen die daar gebruik van maken. Deze module kan worden uitgeschakeld zonder dat dit voor de meeste organisaties merkbare gevolgen heeft voor de werking van systemen. Vraag je systeembeheerder of IT-leverancier dit te controleren en indien nodig uit te schakelen. Dit is de tijdelijke mitigatie tot de patch is doorgevoerd.

• Controleer of de module actief is:
  lsmod | grep algif_aead
• Schakel de module permanent uit en verwijder hem uit het geheugen:
  echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
update-initramfs -u -k all
rmmod algif_aead

• Structureel: installeer de kernelupdate
  De definitieve oplossing is een update van de Linux-kernel. Die update is beschikbaar en wordt momenteel uitgerold door de grote distributeurs. Laat bevestigen dat alle betrokken systemen zijn bijgewerkt, inclusief systemen bij externe leveranciers en in cloudomgevingen.
• Vergeet de cloudomgeving niet
  Cloudproviders rollen updates soms automatisch uit, maar niet altijd. Zeker als je zelf verantwoordelijk bent voor het beheer van virtuele machines of containers, is een expliciete controle noodzakelijk.

De bredere context

Copy Fail werd ontdekt door beveiligingsonderzoekers die AI inzetten om kwetsbaarheden te vinden. Wat normaal weken of maanden zou kosten, duurde in dit geval ongeveer een uur. Dat is een ontwikkeling die doorzet: zowel aanvallers als verdedigers zetten steeds vaker AI in, en de snelheid waarmee nieuwe kwetsbaarheden worden gevonden en misbruikt neemt toe.

Voor organisaties betekent dat: de tijd tussen ontdekking van een kwetsbaarheid en actief misbruik wordt korter. Patchbeheer dat niet structureel is georganiseerd, levert daarmee een steeds groter risico op.

Wat RiskGuard hierin doet

RiskGuard helpt organisaties inzicht te krijgen in kwetsbaarheden in hun infrastructuur en zorgt dat patchprocessen aansluiten op de snelheid waarmee dreigingen zich ontwikkelen. We ondersteunen bij het in kaart brengen van risico’s, het beoordelen van maatregelen en het inrichten van structureel vulnerability management.

Wil je weten of jouw Linux-omgeving kwetsbaar is, of hoe jullie patchproces er meer in het algemeen voor staat? Neem contact op voor een vrijblijvend gesprek.