Openbaar Ministerie bevestigt dat lek in Citrix NetScaler is misbruikt

Het Nederlandse Openbaar Ministerie is daadwerkelijk gehackt, blijkt uit een toelichting van directeur Informatievoorziening OM Hans Moonen, die in handen is van NRC. Het duurt mogelijk nog weken om het netwerk veilig te stellen en te achterhalen of en welke informatie gestolen is.

Vorige week ging het OM offline, omdat er zorgen waren over een kritiek beveiligingsprobleem in de Citrix NetScaler-software. Dat lek is ook daadwerkelijk misbruikt, blijkt uit een toespraak van Hans Moonen, directeur van Informatievoorziening OM (IVOM). Die organisatie is verantwoordelijk voor de ict van het OM. "We mogen en kunnen geen enkel risico lopen om weer met het internet te verbinden zónder dat we weten dat de actor ons netwerk uit is", zegt Moonen in een opname van een korte toelichting, die in handen is van NRC.

Het OM heeft de Nederlandse Autoriteit Persoonsgegevens telefonisch ingelicht over een mogelijk datalek en aangifte gedaan. Het OM verwacht nog weken offline te zijn, zei de organisatie maandag. Moonen zegt dat hij ongeveer 1500 servers binnen het OM telt en dat een automatische beveiligingsscan van een server ongeveer vier uur duurt.

Moonen vertelt dat het OM woensdag 16 juli is ingelicht door het Nationaal Cybersecurity Centrum over het lek in de NetScaler-software, naar aanleiding van een 'gerichte scan' van het NCSC. Toen had het OM het lek volgens hem al gedicht. Het lek werd op 17 juni in de CVE-database geregistreerd met het nummer CVE-2025-5777. Hoeveel tijd het OM daarna nodig had om het probleem te patchen, wil Moonen nog niet delen.

Reacties (130)

[BytePhantomX]

Zover ik weet is de tijdslijn als volgt:

• 17 juni CVE bekend
• 18 juni NCSC brengt medium/high bericht naar buiten
• 19 juni NCSC verandert naar high/high met misbruik op korte termijn zeer waarschijnlijk
• 20 juni eerst compromises (wordt pas begin juli bekend)
• 24 juni OM heeft de update gedaan: https://cyberplace.social/@GossiTheDog/114893287965794089

Kevin Beaumont is zo'n beetje de bron van al het nieuws rondom deze kwetsbaarheid en heeft ook een scan draaien van kwetsbare instances. In die scan heeft hij gezien dat de status van het OM verandert op 24 juni, dus circa 7 dagen na het uitkomen van de kwetsbaarheid.

Blog post van Kevin met veel details: https://doublepulsar.com/citrixbleed-2-situation-update-everybody-already-got-owned-503c6d06da9f

En een blogpost van GreyNoise met de nodige details en tijdslijnen:
https://www.greynoise.io/blog/exploitation-citrixbleed-2-cve-2025-5777-before-public-poc

Of zeven dagen snel genoeg is? Ik vind persoonlijk van niet. Als het NCSC een high/high uitbrengt met misbruik op korte termijn zeer waarschijnlijk, moet je eigenlijk dezelfde dag nog patchen. Zeker als overheidspartij waar statelijke actoren interesse in hebben. Zijn ze bizar laat, wat mij betreft zeker niet. 7 dagen is in een complexe omgeving als het OM eigenlijk best netjes. Zie ook mijn eerder toelichting op hoe complex het kan zijn: BytePhantomX in 'OM gaat offline door beveiligingsprobleem, datalek niet uitgesloten - update'

[Knul]

Volgens de Baseline Informatiebeveiliging Overheid, die het OM ook moet volgen, was het OM nét op tijd. Interessanter is de tweede zin:

12.6.1.1:

Als de kans op misbruik en de verwachte schade beide hoog zijn (NCSC-

classificatie kwetsbaarheidswaarschuwingen), worden patches zo snel mogelijk,

maar uiterlijk binnen een week geïnstalleerd. In de tussentijd worden op

basis van een expliciete risicoafweging mitigerende maatregelen getroffen.

De mitigerende maatregelen zijn - voor zover ik nu weet - niet genomen. Ben benieuwd of er daadwerkelijk een risicoafweging is gedaan.

[Reactie gewijzigd door Knul op 23 juli 2025 10:06]

[banaj]

Als je gevoelige systemen direct aan internet hangt ben je af, en kun je beter direct al je luitjes bij risicomanagement ontslaan. Of vervolgen wegens nalatigheid.

Nu lijkt het erop dat men een kritieke 1day pas na een week patcht en daardoor gehackt wordt. Wat een verassing... Maar wel voldaan aan het beleid!

Er zijn ook veel 0days. Altijd. Daarmee kan een aanvaller met genoeg geld en tijd je altijd hacken als je systeem aan internet hangt. Als je dat niet begrijpt en je gevoelige systemen direct online mikt dan heb je het dus compleet niet begrepen.

[K0L3N]

Volgens mij is hier juist het probleem dat dus de tussenlaag om dingen veilig naar buiten te tunnelen kwetsbaar bleek te zijn.

[supersnathan94]

Is alleen niet de eerste keer.

Dit is citrix bleed 2. In 2023 hadden we 1 al. Daar had toen het een en ander aan protocollen voor geschreven moeten worden, maar dat is niet echt goed gegaan dus.

[TheMak]

Hoe ziet zo een risico afweging er uit? Je zit toch met veel onbekende parameters. Kans dat je gehackt vs kans dat systeem niet meer werkt na patch

[sOid]

Dat hangt van de kwetsbaarheid af. Je kan bijvoorbeeld te maken hebben met een High/High-kwetsbaarheid. Maar als er bijvoorbeeld:

• nog geen PoC beschikbaar is
• de kwetsbaarheid samenhangt met de specifieke configuratie van een systeem/applicatie
• je de kwetsbaarheid alleen kan uitbuiten als je op een bepaald VLAN zit of al ingelogd moet zijn als admin op dat systeem

Dan is het risico voor jouw specifieke organisatie misschien geen H/H maar een M/H of L/H.

[TwiekertBOB]

Het is in mijn ogen te laat, of het is niet te laat.

Daar zijn als het goed is interne richtlijnen voor opgesteld.

Als het niet op tijd is volgens de eigen richtlijnen (en dat zou moeten, gezien de high high en zoals je benoemt: de statelijke actoren die interesse hebben.

Kun je het niet diezelfde dag patchen dan moet je in mijn ogen er al voor kiezen om de hele boel offline te halen.
Dat hebben ze nu pas na de hack gedaan.

Dus linksom of rechtsom: ze hebben grote fouten gemaakt.
Nu maar hopen dat de schade beperkt is en dat er geleerd wordt.

[The Zep Man]

Het is in mijn ogen te laat, of het is niet te laat.

Daar zijn als het goed is interne richtlijnen voor opgesteld.

Een aanvaller geeft niets om interne richtlijnen. Er is nu gewoon te laat gemitigeerd om misbruik te voorkomen. Als dat risico wordt erkend en wordt geaccepteerd door de organisatie, inclusief de gevolgen, dan is er natuurlijk niets aan de hand.

[TwiekertBOB]

Ben ik het volledig mee eens. Wat ik probeerde te duiden is dat je als organisatie richtlijnen hebt die passen bij wat je als organisatie acceptabel vindt. Die richtlijnen komen voort uit impact van mogelijke breach, maar ook kosten en wat technisch (qua complexiteit) mogelijk is.


Maar los van die richtlijnen kunnen we nu wel vaststellen, door de actie van de organisatie om alles offline te halen, dat hier of eerder gepatched had moeten worden, of dat het netwerk eerder offline gehaald had moeten worden tot er wel gepatched kon worden.

[Rudie_V]

Of zeven dagen snel genoeg is? Ik vind persoonlijk van niet.

Sommige groeperingen hebben na een uur al een exploit gemaakt als een beveiligingsfout bekend wordt gemaakt. Met dat in het achterhoofd zou je eigenlijk direct offline moeten gaan totdat de patch is geïnstalleerd.

[BytePhantomX]

Dat is een heel makkelijk statement. Als je dat echter bij elke kwetsbaarheid doet, dan heb je meerdere lange verstoringen in je continuïteit, waarvan het merendeel absoluut niet nodig is.

De vraag is welke risicoafweging maak je en wanneer. Achteraf super makelijk te zeggen, het OM had een andere afweging moeten maken. Alleen op dat moment was het volgende bekend:

• NCSC: high/high misbruik op korte termijn waarschijnlijk. Wat is dan korte termijn, uren, dagen, weken? Daar is geen duiding bij gegeven.
• Citrix: CVE met een hoge score, maar donwplayed het direct. Eerste is het niet vanaf buiten bereikbaar dus geen prio. Dan moeten ze dat bijstellen, maar ze zien geen hack pogingen. Pas na flinke druk van o.a. NCSC's wereldwijd en iemand als Kevin Beaumont geven ze schoorvoetend toe dat er misbruik van wordt gemaakt.

Als je het principe direct offline gaat hanteren, dan moet je dat voor alle internet facing dingen doen. Ga maar eens na wat een gemiddelde enterprise aan het internet heeft hangen wat cruciaal is voor de continuïtet:

• Firewalls (bijna elke leverancier heeft CVE's). Die offline, betekent alles offline.
• Ivanti recent paar keer super kwetsbaar. Offline halen -> alle (remote) werkplekken offline
• SharePoint nu recent -> nu nog een onpremises sharepoint aan het internet hangen, dat heb je waarschijnlijk alleen maar omdat je niet anders kan, anders was je allang naar Office365 of iets anders gemigreerd.

Dat is afgelopen maanden al meerdere keren cruciale systemen offline die de werkplek platlegt. Dat houdt je als security en IT echt niet vol in organisaties waar bijna 24x7 gewerkt wordt en er grote werkdruk is richting deadlines etc. Je ziet nu ook dat de maatschappelijke impact groot is op ons rechtssysteem dat al flink onder druk stond.

[Rudie_V]

Ik snap dat het heel makkelijk gezegd is, maar kan je het risico nemen als er groeperingen zijn die binnen een uur een exploit hebben en gericht gaan scannen? Dat zal elke organisatie voor zichzelf moeten afwegen.
Dit is ook niet het eerste Citrix probleem met zo'n mogelijke impact. Dus je kon het verwachten, zeker als OM zijnde. Het is naief om te denken dat je geen target bent in zo'n situatie. Elke server die direct aan het internet hangt is een target, zeker als er bugs bekend zijn dan komen er snel exploits, dus zal je ook snel moeten handelen. Dat is de realiteit.

In dit geval lijkt Citrix ook een rol gespeeld te hebben door eerst de ernst niet toe te geven, dat is ook iets wat je Citrix kan kwalijk nemen en wat beter moet. Dan had het misschien voorkomen kunnen worden.

Ik snap dat er veel getest moet worden voordat je zo'n patch kan installeren op je productie omgeving en misschien is de 7 dagen van het OM nog snel, maar blijkbaar niet snel genoeg nog. En in de toekomst zal 7 dagen waarschijnlijk weer niet snel genoeg zijn. Dus er zal beter nagedacht moeten worden over de toegang tot zulke systemen.

[Left]

Denk je werkelijk dat grote organisaties met kritieke data, bijvoorbeeld banken, een service online houden wanneer een CVE gepubliceerd is? En hackers dus de gelegenheid geven om je rekening leeg te halen, omdat anders de werkdruk te hoog zou worden?

Ieder fintech bedrijf waar ik gewerkt wordt probeert ofwel onmiddellijk het lek te patchen, of treft mitigation measures. Bv de service offline halen of de rechten beperken.

[BytePhantomX]

Fijn dat veel organisatie dit wel goed op orde hebben en van fintech verwacht ik eigenlijk niet anders. Echter is dat niet de realiteit bij veel organisaties, zeker niet bij een OM dat al geplaagd is met allerlei IT uitdagingen.

Zou het beter moeten? Zeker. Maar ik vind dat hier soms nog weleens makkelijk over de complexiteit heen wordt gestapt en simpele oplossingen worden gepresenteerd die geen recht doen aan de complexiteit. Als je kijkt naar hoeveel instances nu nog kwetsbaar zijn, dan is 7 dagen beter dan het gemiddeld. Maar blijkbaar nog niet goed genoeg.

Ps. hadden ze overigens alle sessie ook ingetrokken, dan waren ze waarschijnlijk op tijd geweest met 7 dagen. Alleen dat advies lag er toen nog niet.

[Reactie gewijzigd door BytePhantomX op 23 juli 2025 13:50]

[Cobalt]

Je mist nog een stuk in je tijdspad. Namelijk vanaf welke versie zat de lek erin. Want de gene die de lek heeft misbruikt kan al ver voor de CVE melding de lek zelf hebben gevonden.

[YoMarK]

Dat klopt, maar dat valt het OM niet aan te rekenen natuurlijk. Patchtijd van 7 dagen is niet al te vlot, maar het is ook niet dramatisch.

Zeker omdat het het laatste jaar echt dramatisch is met de CVE's voor NetScalers en omdat dat meestal wel los loopt kan ik me voorstellen dat men gedacht heeft: we plannen dit even even ipv direct alles te laten vallen.

Helaas is dat de verkeerde keuze geweest.

[Left]

7 dagen is helemaal niet netjes. Als een CVE niet binnen 7 dagen na publicatie gepatcht kan worden, dan kun je met zo'n kritieke organisatie als het OM gewoon die service helemaal niet gebruiken. Het risico is te groot.


Ik kan je verzekeren dat hackers die CVE publicaties scherp in het oog houden. Bij het OM hebben ze dus 7 dagen de tijd gekregen om in te breken. Ter referentie: het examen voor certified ehtical hacker geeft je maar 24 uur de tijd ..

[B Tender]

Ik kan je verzekeren dat hackers die CVE publicaties scherp in het oog houden.

Ik ben een leek op dat gebied maar is het dan wel zo handig dat dit breed bekend is in 'het wereldje'. Het is alsof je in de Telegraaf zet: "De code van de kluis van de Nederlandsche Bank is 15648984 en waarschijnlijk duurt het wel een paar dagen voordat ze de code hebben veranderd". Dan is het wachten op ellende.

Nogmaals, ik ben écht leek op dit vlak, maar zou Citrix lekken als deze niet beter zélf 'stilletjes' kunnen patchen i.p.v. dit over te laten aan IT-afdelingen wereldwijd terwijl er (gechargeerd) groot wordt rondgetoeterd "Beste inbrekers, het is hier en hier zo lek als een mandje, dus sla snel je slag nu het nog kan!"

[furian88]

persoonlijk vind ik bij zulke risico's dat je het direct hoort uit te voeren, ongeacht de impact voor de business op dat moment.

afgelopen zondagavond zijn wij onze SharePoint servers nog afgegaan na de CVE die daarvoor uitgegeven werd. Indien nodig geweest waren er dan ook gewoon direct mitigerende maatregelen genomen (was niet nodig gelukkig).


Bij zaken zoals (semi)overheid\OM etc zijn de belangen te groot en dient er gewoon direct actie ondernomen te worden.. en dan voornamelijk hoe de wereld er momenteel voor staat!

[Osxy]

Dat is jou mening en het OM zal hier beleid op hebben. Of een week binnen hun beleid valt lijkt het wel op, of dat beleid dus juist is? Je zou zeggen van niet, want het is fout gegaan maar zonder het hele plaatje te kennen is dat echt niet hard te stellen.

[furian88]

Ongeacht mijn mening of niet. In de huidige wereld met China en Rusland zou het een prio 1 moeten zijn waar direct actie op ondernomen had moeten worden. Ik kan me ook niet indenken dat ze dit nu niet zelf inzien en hun regeltjes wat gaan aanpassen.

[feuniks]

persoonlijk vind ik bij zulke risico's dat je het direct hoort uit te voeren, ongeacht de impact voor de business op dat moment.

Het als een kip zonder kop uitvoeren van een change is nooit een goed idee. Stel dat er een kritieke patch voor de database server is, je voert die meteen uit en een tijdje zie je dat de database corrupt aan het raken is. Wat dan?

Er is geen goede oplossing op dit moment. Alleen kan ik zeggen dat we het allemaal veel te complex hebben gemaakt. Aan de ene kant hebben we een OS waar software op kan draaien die 25 jaar oud is (en waarvoor je dus vandaag software kunt maken met tools en technieken van 25 jaar geleden) en aan de andere kant heb je software dat ergens in een hoek van het Internet leeft. Alles is aan elkaar geknoopt en niemand heeft meer een totaalplaatje van de hele omgeving, wat er allemaal gebruikt wordt en hoe de paden lopen. We zijn kwetsbaar en we worden steeds kwetsbaarder. Toen ik 30 jaar geleden begon in deze business was het overzichtelijk. Patchen deze we eenmaal per maand. Systemen rolden we uit door een systeem in te richten en vervolgens een ghost image ervan te maken en te distribueren over de machines die je in wilde spoelen. Het aantal applicaties dat Internet nodig had was op een hand te tellen. Zelfs voor vuurwerkslachtoffers. Wat we wel hadden was een CD server waar de nodige CDs in zaten, zodat applicaties daar hun data vanaf konden lezen. We zijn op het punt gekomen dat we eens goed moeten kijken hoe we verder willen. Eigenlijk hoe we verder moeten. Moeten we niet een beetje terug in de tijd met meer lokaal en minder online. Met minder programma's die te veel willen doen en vooral met minder punten die aangevallen kunnen worden.

[furian88]

ik mag toch hopen dat een grote partij als het OM een change kalender heeft en gebruikt en daar de juiste mensen tussen heeft zitten.

[feuniks]

Inderdaad en juist daarom zal een patch niet zomaar uitgevoerd worden, omdat het een kritiek lek dicht. Juist daarom zal dit een proces doorlopen. Juist daarom kost het tijd. En juist daarom is het nu fout gegaan.

[Joystick]

Ik ben het helemaal met je eens dat je zsm moet patchen bij een kritieke update.

Het is alleen jammer genoeg niet zo makkelijk sinds te snel patchen andere dingen weer om kunnen vallen.Ik erken de Mobile Iron kwetsbaarheid van afgelopen maanden, die moesten wij als overheid ook opeens gaan patchen en zsm! We hebben toen besloten dat de server dicht gezet kon worden diezelfde dag nog en moesten toen kijken wat er omviel (server was al deels vervangen). Ook al denk je dat dingen niet gaan omvallen, toch krijg je belletjes en klachten en andere monitorings issues die je niet verwacht.

[Ruben279]

Het is wel vreemd dat in de tijdslijn die NCSC zelf op de website heeft staan over deze case, als volgt is;

18 juni

Het NCSC brengt beveiligingsadvies NCSC-2025-0196 uit over kwetsbaarheden CVE-2025-5777 en CVE-2025-5349 in Citrix Netscaler ADC en Netscaler Gateway. Dit beveiligingsadvies is in de dagen daarna meerdere malen bijgewerkt op basis van nieuwe informatie.

Maar de publicatie op de officiële Citrix pagina was al op 17 juni.. Hoe kan het dat het NCSC dit pas na een dag op haar eigen pagina publiceert. Juist met CVE's is het belangrijk om de snelheid erin te houden, dus dat verwacht ik dan ook van het NCSC.

[The Zep Man]

Zijn ze bizar laat, wat mij betreft zeker niet. 7 dagen is in een complexe omgeving als het OM eigenlijk best netjes.

Het is netjes, maar niet snel genoeg. Dat kan op verschillende manieren opgelost worden:
• Meer middelen om sneller updates door te kunnen voeren (reductie benodigde tijd).
• Meer middelen om het landschap minder complex te maken (reductie benodigde tijd).
• Meer middelen om (tijdelijke) mitigaties door te voeren (meer tijd).

Verder spreken we hier over een publiek frontend. Dat is een ingang tot je organisatie vanuit de buitenwereld. Daar hoort de juiste prioriteit bij met betrekking tot hardening en onderhoud.

[Reactie gewijzigd door The Zep Man op 23 juli 2025 10:11]

[pegagus]

"Niet snel genoeg"en "juiste prioriteit" zonder verder maar enige onderbouwing is dit wel heel erg "beste stuurlui staan aan wal". Ook het OM heeft het te doen met beperkte middelen en heeft keuzes te maken. Daarbij kun je nooit helemaal iets uitsluiten en zijn "meer middelen" voor ICT misschien wel niet gewenst in de doelstellingen van de organisatie, omdat dit ten koste gaat van andere zaken.

[The Zep Man]

"Niet snel genoeg"en "juiste prioriteit" zonder verder maar enige onderbouwing is dit wel heel erg "beste stuurlui staan aan wal".

De onderbouwing is dat een kwetsbaarheid met een erkend hoog risico niet op tijd gemitigeerd werd voordat deze werd misbruikt.

Ook het OM heeft het te doen met beperkte middelen en heeft keuzes te maken.

En soms zijn die keuzes niet goed genoeg, zo blijkt.

Daarbij kun je nooit helemaal iets uitsluiten

Wat geen reden is om risico's zomaar te accepteren.

en zijn "meer middelen" voor ICT misschien wel niet gewenst in de doelstellingen van de organisatie, omdat dit ten koste gaat van andere zaken.

Als meer of het herprioriteren van middelen niet gewenst is, dan moet de organisatie meer downtime accepteren als onderdeel van het behalen van diens doelstellingen. Hou daarbij rekening dat deze downtime ook middelen kost. Niet alleen om op te lossen, maar ook om in te halen.

Wij hoeven het OM of de overheid in het algemeen niet met fluwelen handschoenen te behandelen. Fouten worden gemaakt en moeten erkend worden. Fouten kunnen opgelost worden. In de aanname dat de huidige situatie ongewenst is, lijkt het mij dat hier een verkeerde risicoanalyse aan ten grondslag ligt. Dat is een goed punt om bij te beginnen om dit in de toekomst te voorkomen.

[Reactie gewijzigd door The Zep Man op 23 juli 2025 11:12]

[pegagus]

Waar baseer jij je oordeel op? Achteraf kijk je een koe in zijn kont en kom je wellicht tot de conclusie dat je andere keuzes moet gaan maken. Maar die analyse moet nog worden gemaakt en wel door het OM. Uit onderstaande berichten blijkt in ieder geval dat het niet bekend is hoeveel tijd er überhaupt heeft gezeten tussen bekend worden en patchen.

En dan kan het wel eens iets heel anders zijn dan "meer middelen". Ook uit onderstaande berichten blijkt dat andere organisaties binnen een dag de zaak weer gedicht hadden. Dan zit het wellicht veel eerder in de sfeer van taken en verantwoordelijkheden en wellicht iets heel simpels als "vervanging tijdens vakantie".

[TheMak]

Ik zou zeggen minder middelen. Op ons werk hebben we een lijst van honderd items die mis zouden kunnen gaan bij een change. Je moet je leinggevende plechtig laten beloven dat je daarop gecontroleerd hebt. En buitenstaanders letten er op.

[feuniks]

Eigenlijk heb je drie opties:

1) Meteen patchen en hopen dat het medicijn niet schadelijker was dan de kwaal.
Helaas hebben we in het verleden veel te vaak patches gezien waar veel problemen mee waren. Van blue screens tot missie kritische applicaties die uitvielen. Vandaar dat patches bij elke verstandige organisatie eerst door de patchstraat moeten en dat kost tijd.

2) Alle patches grondig doortesten op een accent omgeving, waarna die gefaseerd naar productie gebracht wordt.
Voor de omgeving zelf en de software die erop staat het veiligste. Je loopt het minste risico dat er dingen omvallen, je medewerkers niet kunnen werken of er verlies van data is. Alleen loop je dan het risico dat je met een lek te maken hebt dat actief misbruikt wordt en je dus iemand in je netwerk hebt zitten die je daar niet wil hebben.

3) De link met het Internet doorsnijden totdat je getest en gepatched hebt.
Dit geeft je de mogelijkheid om alles goed door te testen en te patchen zonder dat de kans bestaat dat in de tussentijd al iemand je aanvalt. Alleen vallen dan bepaalde zaken uit. Zo heb je geen ontsluiting van het Internet. Alle applicaties die Internet nodig hebben, werken dus niet. Als je mailservers in je eigen server ruimte staan, dan werkt dat ook niet en zaken als thuis werken of vestigingen die via Internet aan de hoofdvestiging gekoppeld zijn vallen uit. Wellicht is dat trouwens een voordeel, want daarmee is iedereen zich ervan bewust dat er snel getest moet worden. Ik zie nu nog dat te veel key users laat testen, omdat ze geen tijd hebben.

Alle drie de opties hebben voor en nadelen. En voor alle drie de opties moet je hoger management hebben dat begrijpt wat de problemen van de drie opties zijn. Bovendien moeten ze de ballen hebben om een beslissing te nemen en daarvoor te staan. Ook voor de consequenties. En dat is dan inclusief bijvoorbeeld een ministerie dat tijdens de algemene beschouwingen tegen de minister zegt dat ze eruit liggen en dat de ambtenaren de vragen van de kamer niet kunnen behandelen, omdat er een risico is. En daar wringt de schoen heel vaak. Beveiliging is complex. De gemiddelde omgeving van een organisatie is complex. En men begrijpt nog steeds niet dat er keuzes gemaakt moeten worden die tijd, geld en wellicht zelfs imagoverlies kosten.

[moredruid]

Door de opbouw van een Netscaler (zie het als een soort proxy/loadbalancer die uit meerdere systemen bestaat) kun je dit prima gefaseerd patchen zonder al te veel downtime voor de eindgebruikers tenzij er een afhankelijkheid tussen de 2 patchlevels zit die de boel breekt. Dat zie je al na 1 systeem patchen, waarna je de boel kunt terugdraaien of het gepatchte systeem isoleert om het te testen om het daarna weer in produktie te hangen en de rest ook te patchen.

De vraag of het sneller had gekund ligt bij het OM. Technisch kan het altijd sneller (zet het vinkje aan om kritieke securitypatches automatisch zsm te installeren) echter in een complexe omgeving met bijzondere beveiligingseisen kan dit niet zomaar, elke wijziging moet worden gereviewed voordat deze gepatched mag worden zodat men de risico's en gevolgen kan inschatten.

Dat hackers zich niets aantrekken van dit soort processen is logisch. Maar dat soort processen (change board oid of in dit geval een urgente meeting specifiek voor deze patch) zijn in het leven geroepen om een reden. Het feit dat ze nog steeds bestaan wijst erop dat ze van waarde zijn. Dit zomaar wegschuiven lijkt me niet verstandig.

[xmenno]

Wat ik gewoon even tussen de regels door lees:
Het OM is woensdagavond 16 juli om 20.00 uur door het Nationaal Cybersecurity Centrum (NCSC) ingelicht over de kwetsbaarheid in Citrix, zegt Moonen.
Aanleiding, zegt hij, was een „gerichte scan” van het NCSC naar de kwetsbaarheid in Citrix. Dat lek had het OM gedicht, zegt Moonen. „Desondanks zag het NCSC aanleiding om ons daarover te contacten.”
Als ze het lek hadden gedicht, hoe heeft het NCSC het lek dan toch kunnen vinden?
Ik trek dan de conclusie dat ze op donderdag 17 juli hebben gepatched, zijn gaan onderzoeken en daarna op donderdagavond hebben besloten offline te gaan.

Als je dan eenmaal toegang hebt tot de Citrix Netscaler dan ben je er natuurlijk nog niet, ik neem aan dat mensen op hun desktop inloggen met een 2-factor of iets en dat ze dus langer bezig zijn geweest om ook teogang tot de achterliggende systemen te krijgen.

Minister van Justitie en Veiligheid David van Weel schreef in zijn brief al dat het OM uit voorzorg heeft losgekoppeld was van het internet., maar in dezelfde brief staat dat er gebruik is gemaakt van deze mogelijke kwetsbaarheid.

[BytePhantomX]

Als je inlogt op Citrix (of veel willekeurige andere diensten), dan meld je aan met gebruikersnaam, wachtwoord en MFA. Echter wil je dat niet doen voor elke request dat jouw systeem naar de server doet (soms enkele duizenden per minuut). Technisch wordt dat opgelost door na authenticatie een sessie token te maken en die aan de client te geven. De client kan dan alle verzoeken auhtenticeren met die sessie-token.

Door slimme encryptie is zo'n sessie token in de praktijk niet te hackken. Wat je echter wel kan doen is die token proberen te bemachtigen, waarna je kan authenticeren, en je dus niet hoeft te beschikken over gebruikersnaam, wachtwoord en MFA. Dit is op het moment een heel groot issue met Phishing bij Microsoft. (Een willekeurig blog met wat meer uitleg: https://abnormal.ai/blog/cybercriminals-evilginx-mfa-bypass)

Wat deze CVE zo vervelend maakte was dat aanvallers die sessietokens van gebruikers uit het geheugen van de netscaler kunnen lezen zonder zich te hoeven aanmelden. Actoren hebben dus die tokens gestolen voordat gepatched is. Maar na patchen is het lek wel dicht, maar zijn die sessie tokens nog steeds geldig. Het advies om alle sessies in te trekken is pas veel later uitgegeven dan 24 juni.

[xmenno]

Ik snap hem, dat maakt het ook lastiger om te kunnen zeggen dat de patch op tijd is geïnstalleerd, als tijdens dat process de tokens bewaard zijn gebleven.

[Mellow Jack]

Als ik het euvel goed begrijp kunnen ze hiermee rdp flows overnemen. Nu heb ik er niet heel veel onderzoek naar gedaan maar als ze RDP sessies kunnen kapen dan hebben ze geen MFA nodig want dat doet de gebruiker bij het opzetten van de sessie.

Even aangenomen dat het OM dit soort zaken gebruikt

[Reactie gewijzigd door Mellow Jack op 23 juli 2025 09:25]

[xmenno]

Zie het ja, IP van de sessie kan veranderen. Dat is wel heel erg ouderwets makkelijk.
https://www.netscaler.com/blog/news/evaluating-netscaler-logs-for-indicators-of-attempted-exploitation-of-cve-2025-5777/

[DdeM]

Als ze het lek hadden gedicht, hoe heeft het NCSC het lek dan toch kunnen vinden?

Wie zegt er dat ze het lek hebben gevonden? Ze hebben een gerichte scan gedaan naar de kwetsbaarheid, én besloten het OM in te lichten over die kwetsbaarheid. Kan dus net zo goed zijn dat die scan niets opleverde, of juist aantoonde dat de boel al gepatched was, maar het risico dat het misbruikt was dermate was dat ze het toch nodig vonden het OM in te lichten zodat die zelf nog konden checken of er wel of geen misbruik van is gemaakt. En dat was overduidelijk een zeer goed besluit van het NCSC.

[Blokker_1999]

Ik ben blij dat we nu ook bevestiging hebben dat het lek zeer snel na bekendmaking is gedicht geweest. Hopelijk zal dit een hoop mensen doen inzien dat men bij de overheid soms wel snel kan handellen en het zeker niet altijd het gevolg is van trage patching.

--edit--

damnit, niet goed wakker blijkbaar en gemist dat er juli ipv juni staat.

[Reactie gewijzigd door Blokker_1999 op 23 juli 2025 09:24]

[Bierkameel]

Heb je het artikel wel gelezen?

"Hoeveel tijd het OM daarna nodig had om het probleem te patchen, wil Moonen nog niet delen."

[GertMenkel]

Als ik deze draad volg (van de cybersecurityonderzoeker die CitrixBleed 2 onder de aandacht bracht, en naar wiens blog het NCSC ook linkt), lijkt het erop dat volgens zijn scans de patch op 24 juni is uitgevoerd. Het misbruik moet dan dus in de week tussen de release van de patch en de installatie ongeveer een week later zijn gebeurd.

Aangezien Citrix de boel stilletjes heeft geprobeerd te houden over dit lek, patchen in een week tijd nog best een prestatie. Helemaal aangezien de originele CVE beweerde dat het een fout was in de managementinterface (die je normaliter afschermt, waardoor je de tijd kunt nemen om de patch te evalueren) terwijl de hoofdingang ook kwetsbaar was. Die correctie van de CVE was pas op 23 juni aangebracht, wat betekent dat het OM de dag dat ze wisten dat ze kwetsbaar waren al een patch hebben uitgerold.

Maar goed, dat is wat de externe scan aantoont, die de kwetsbaarheid niet exploit (zou zwaar illegaal zijn natuurlijk); als het OM automatische exploits probeerde te voorkomen door alleen de headers en HTML zo te herschrijven dat de patch toegepast lijkt, zou dat ook kunnen verklaren dat de server als gepatcht in de scan verschijnt.

[Reactie gewijzigd door GertMenkel op 23 juli 2025 10:03]

[zalazar]

Ja precies zoals Bierkameel al zegt, we weten niet hoe lang het geduurd heeft. En dat trage gedoe is niet alleen bij de overheid zo maar bij veel grote bedrijven. Vaak zijn er te veel change managment regels zodat je hier heel veel werk aan hebt en het zorgt er voor dat je de patch niet direct kan doorvoeren.

Voor dit soort vulnerabilities zouden uitzonderingen moeten zijn zodat je ondanks dat het downtime kost, en ook al hebben mensen hier last van, direct aan de slag kunt.

[segil]

ja wat een goed idee! Laten we gelijk die patch uitrollen zonder te testen. What could possibly go wrong?!

[flaskk]

Even snapshots maken van de betreffende servers en gaan met die banaan, testen duurt dagen...

[Joenino]

Precies dit! Ik mag ook hopen dat het OM een HA paar heeft van hun netscalers. Dan even de passieve uit, snapshotje, weer aan, updaten en kijken of hij goed terug komt, zoja live zetten en kijken wat er gebeurd. In het ergste geval schakel je weer terug naar de inmiddels passieve en je bent weer live.

Gaat de geupdaten stuk hoppa snapshot terug en je bent weer live. Zo moeilijk is het echt niet. Gebruik je hardware matige Netscalers tsjah dan heb je inderdaad een uitdaging als het mis gaat.

Maar wat ook helpt is gewoon een bloody geoblock inregelen op je firewall. Waarom zou china bv op je netscaler moeten kunnen connecten of Rusland. Hiermee haal je al heel veel kansen weg bij portentiele hack pogingen.

[SunnieNL]

Maar wat ook helpt is gewoon een bloody geoblock inregelen op je firewall. Waarom zou china bv op je netscaler moeten kunnen connecten of Rusland. Hiermee haal je al heel veel kansen weg bij portentiele hack pogingen.

Gebruiken die niet gewoon een VPN?

[Joenino]

Dat kan zeker dat sommige dat doen maar de hoeveelheid aanvallen die ik uit bepaalde landen al zie aankomen op de firewalls die ik onde rogen krijg zijn enorm. Dus door alleen al alle landen waar je geen zaken mee doe of geen relatie mee hebt al te blokkeren voor enige vorm van toegang win je al een hele boel.

Dan blijven de VPN gebruikers over maar ook die haal je er op een gegeven moment uit.

Het is altijd beetje kat en muis spel met dat soort dingen.

[zalazar]

Ik zeg niet dat je het niet moet uittesten op bijvoorbeeld een Dev, Accp of Pre-prod omgeving maar dat je daarna direct moet kunnen installeren op productie. Nu wordt er vaak gewacht op change management en wordt er een downtime window gezocht. Daarnaast zijn er ook voor het testen van de patch op een niet productie omgeving vaak changes nodig die doorlooptijd kosten.

Een hacker wacht echt niet tot jij gepatched hebt.

[Reactie gewijzigd door zalazar op 24 juli 2025 00:11]

[Aalard99]

Dat staat er niet, er staat juist expliciet in het artikel dat het onbekend is hoe lang het heeft geduurd voordat het lek gedicht was, aldus Moonen. De CVE is op 17 juni bekend gemaakt en in een scan op 16 juli( een maand later) was het systeem in ieder geval gepatched, onbekend wanneer dit gedaan was.

[Reactie gewijzigd door Aalard99 op 23 juli 2025 09:11]

[dutchgio]

Dat staat er niet. Ze zijn op 16 juli door het NCSC er over ingelicht, toen hadden ze het wel al gedicht. Maar de kwetsbaarheid zelf was een maand eerder al bekend, op 17 juni. Het was in elk geval te laat gezien er misbruik van is gemaakt.

[Blokker_1999]

damnit, wie verzint het om 2 maanden te benoemen met bijna identieke namen?

* Blokker_1999 needs to wake up ...

[dutchgio]

Ja dat maakt het inderdaad wel wat verwarrend, het staat er ook niet heel duidelijk zo.

[Reactie gewijzigd door dutchgio op 23 juli 2025 09:28]

[SPee]

Julius Caesar! Daarvoor heette de maand quintilis.

[Left]

Zeer snel? Het heeft een maand geduurd!

Ik kan je vertellen dat hackers die CVE database voortdurend in de gaten houden en als er een nieuwe CVE opduikt, dan kunnen ze direct aan de slag. Reken maar dat er een heleboel mensen geinteresseerd zijn in de data van het OM. Een maand niets doen is een eeuwigheid en een onvergeeflijke blunder.

[Marve79]

Inderdaad, wij krijgen gewoon die security bulletins van Citrix, die zijn vaak zelfs private en vallen zelfs onder een NDA. Toen ik deze kreeg en een CVE score van 9.3 zag heb ik alles laten vallen en ben ik direct gaan patchen. Waarom zou je in godsnaam dat risico willen lopen. Bij de overheid krijgen ze die mails ook gewoon.

[krakendmodem]

Dan komt er een team bij elkaar en wordt er een spoedchange gestart om dit te verhelpen. Ook bij de overheid. Je gaat niet even zomaar een change doorvoeren zonder eerst de gebruikers op de hoogte te brengen. Tenzij je op de servicedesk honderden telefoontjes wil beantwoorden van gebruikers die uit Citrix worden geknikkerd.

Die Citrix patch werd hier bijvoorbeeld dezelfde dag nog uitgevoerd. Ook overheid.

[Bongoarnhem]

Dank voor je goede reactie, mooi om te horen dat het bij jouw departement/onderdeel zo snel ging.

Ik heb veelvuldig met overheids IT te maken gehad en man wat heb ik een ellende gezien op dat gebied(en nog steeds). Maar dat krijg je als je voor een dubbeltje op de eerste rang wilt zitten.

[krakendmodem]

Ik heb ook bij verschillende (rijks)overheden gezeten, het kan dus ook wel goed gaan. Maar inderdaad, je komt inderdaad oude meuk tegen soms en collega’s die niet altijd mee willen gaan met de tijd.

[flaskk]

Dan ben je aardig kortzichtig, ik heb jaren lang bij een ict dienstverlener gezeten in de private sector en daar was altijd gedoe met updates omdat onze managers bang waren voor downtime door updates/patches. Effect was dat de updates/patches vaker werden uitgesteld.

Nu bij de Rijksoverheid, de zelfde dag van de patch zijn er snapshots gemaakt en de servers geupdate.

Wat mij wel opvalt is dat er veel meer downtime is qua storingen en dat vind men "normaal" dus dat is denk ik beetje de weegschaal, of alles gelijk updaten en fingers crossed of afwachten en dan updaten.

[Reactie gewijzigd door flaskk op 23 juli 2025 12:28]

[Bockelaar]

OM heeft nagenoeg zijn hele omgeving uitbesteed aan grote IT dienstverleners in Nederland. Dat zijn geen ambtenaren maar consultants :+

[qless]

Is dit niet het zoveelste lek in citrix?

[Triblade_8472]

Nee, het is het zoveelste lek in Netscaler. Een bedrijf en een product zijn twee heel verschillende dingen.


Maar het komt niet voor in de top 50 producten met meeste vulnerabilities.

https://www.cvedetails.com/top-50-products.php?year=0

[RubenNL]

Op het eerste gezicht vindt ik deze lijst niet zo bruikbaar.

Sommige software wordt uitgesplitst in versies (Windows Server 2016 is los van Windows Server 2019). Dit lijkt alleen bij Windows [server] te worden toegepast. De overige producten zijn alle versies van samengevoegd.

EDIT: ook bij MacOS wordt dit gedaan (MacOS vs MacOS X)

[EnigmA-X]

Dat is een lijst met enerzijds bekende en anderzijds waarschijnlijk ook gepatchte kwetsbaarheden.

Onbekende kwetsbaarheden staan er niet op. Daarnaast denk ik dat er ook een verschil zit qua FOSS software, of juist niet. Ook het type software speelt een rol.

De vraag die je daarom zou kunnen stellen is of die lijst nou juist veilige of onveilige software weergeeft… of een mix en niet zo veelzeggend is.

[Triblade_8472]

Het was dan ook een reactie op het commentaar of dit niet het "zoveelste" lek is. Ik wil alleen aangeven dat het altijd erger kan.

[sassas]

Dat heb je niet aangegeven met die lijst. Het aantal problemen doen er niet zo toe, zeket niet als ze snel ge-fixt zijn. Dat wil zeggen dar er waarschijnlijk veel aan wordt gewerkt. Wat WEL belangrijk is de CVSS critical scores: https://www.cvedetails.com/vulnerability-list/cvssscoremin-9/cvssscoremax-10/vulnerabilities.html?published_since=2024-07-23&published_before=2025-07-23

[Triblade_8472]

Als het commentaar het woord "zoveelste" bevat, dan gaat dat over kwantiteit.

[sassas]

JIj wist heus wel dat het om het zoveelste kritieke lek zou gaan, want medium of low patchen hebben we het niet over. Daar zijn er zat van.

[Bor]

Citrix is nogal een breed begrip, namelijk de bedrijfsnaam waaronder diverse zeer uiteenlopende producten worden ontwikkeld en verkocht. De Netscaler lineup is daar slechts 1 van en ja, daar zitten helaas vaker lekken in.

Een eerdere groot lek leide nog tot 'citrix files' op de snelwegen toen bedrijven hun Netscalers loskoppelen of uitzetten en mensen hierdoor niet meer remote konden werken.

Met enige regelmaat komen er CVE's voorbij in de Netscaler lineup. Het is een relatief complex product.

[Reactie gewijzigd door Bor op 23 juli 2025 09:18]

[YoMarK]

Dat klopt, met een NetScaler kan je 'van alles' afhankelijk van de licentie en de inrichting. Maar je kan een punt maken dat dit het product wel onveilig maakt.

Citrix zelf ziet in z'n CVE's door de bomen het bos niet meer of bij een bepaald type inrichting(b.v. HTTP loadbalancer of VDI telewerk gateway) je nu wél of niet kwetsbaar bent. Ik ben geen echte expert, maar ik heb het idee/gevoel dat de attack surface vaak groter is dan nodig(waar klanten het voor gebruiken).

[SlimNewRatSkin]

Ik krijg steeds meer de indruk dat Citrix, net als bijvoorbeeld SAP, het soort product is dat niet alleen onveilig, maar ook veel te duur, veel te gecompliceerd en veel te traag is, maar dat toch door gladde verkopers verkocht wordt aan CxO figuren die geen benul hebben van waar gebruikers en beheerders in de praktijk tegenaan lopen.
Bovendien lijkt Citrix me een typisch money-driven bedrijf dat alleen geïnteresseerd is in aandeelhouderswaarde en directiebonussen. Dan krijg je dit soort software die door iedereen gehaat wordt, maar toch overal gebruikt wordt.

[Marve79]

Mwah niet mee eens, Citrix maakt wel hele goede software voor remote werken. Het feit ook dat Netscalers wereldwijd breed worden toegepast wil ook zeggen dat er niet heel veel alternatieven zijn. Het is ook een zwitsers zakmes, het kan gewoon ontzettend veel en daardoor heb je ook veel lekken.

Er zijn zeker alternatieven voor Citrix, maar die gaan je op de lange termijn enkel geld kosten door gebrekkige functionaliteit, slecht te beheren, slechte gebruikerservaring etc. Of je hebt nog allerlei andere 3rd party meuk nodig om het draaiende te houden, bijv Azure Virtual Desktop heb je bijna verplicht Nerdio nodig anders is het niet te doen.

Dat gezegd hebbende, Citrix is toen wel overgenomen door een investeerder, en dus inderdaad wel meer money-driven geworden.

[Reactie gewijzigd door Marve79 op 23 juli 2025 15:27]

[dutchgio]

Dezelfde dooddoener dat Windows elke maand een patch tuesday heeft.

[GertMenkel]

Ja en nee. Netscaler is bedoeld om beveiliging te bieden, en het lekken van geheugen als je een verzoek stuurt met een incomplete form body vind ik toch ondermaats voor een securityproduct. Bij het vorige CitrixBleed-lek ging het ook om een slordige fout, maar deze is wel heel slecht. Het artikel van watchtowr.com bevat de details.

Ieder product bevat bugs, maar een product dat beveiliging zou moeten bieden zou niet zo veel, zo zware, zo slordige bugs moeten bevatten in mijn optiek.

[Marve79]

De basis van Netscaler draait op FreeBSD, maar de schil die Citrix erop legt is zo lek als een mandje inderdaad. Ik vermoed dat dat vooral komt door besparingen, programmeurs in India enzo bijv. Netscaler is een beetje de 737 MAX-8 van Citrix.

[GertMenkel]

Ieder product heeft bugs. Aan de andere kant heeft Citrix Netscaler altijd gevaarlijke bugs, omdat het een beveiligingsproduct is.

De kwaliteit van deze software lijkt wel ondermaats. Diverse PoC's staan op Github, en over de vorige CitrixBleed was ook al een artikel geschreven. De vorige keer was de oorzaak dat Citrix JSON genereerde met een call naar snprintf() die over een buffer heen ging als een header zoals Host: lang genoeg was.

Het feit dat ze zelf hun eigen string concatenation JSON serializer schrijven in C zegt mij meer dan genoeg over hun beveiligingsarchitectuur, eerlijk gezegd. Dat gezegd hebbende, Citrix heeft honderden producten de wereld ingeslingerd, dus lang niet alle bugs met het labeltje Citrix erop zijn van toepassing.

[Floort]

Ik wist niet dat je telefonisch melding mocht doen bij de AP.

[MuddyMagical]

Wellicht meer een vooraankondiging dan een daadwerkelijke melding?

[Quintiemero]

Daar is het maken van een voorlopige melding voor. Maar misschien zijn er kortere lijntjes, of, waren bang dat de AP het via nieuws zou horen en de voorlopige melding nog niet was gedaan. Aanname natuurlijk

[metalmania_666]

Gezien het belang, kan een telefonisch contact vooraf handig zijn.

Er staat niet bij dat de aangifte ook telefonisch gedaan is. Van wat ik nog weet van 5 jaar terug was het een uitgebreid formulier wat je moet invullen.

[Moartn]

Er werkt 6000 man bij het OM, hoezo hebben ze dan 15.000 servers?

[PaulHelper]

Wat maakt dit zo bijzonder? Zolang je de diensten kunt beheren dan hoeft schaal niet direct superveel mensen te vereisen. Het hangt er vanaf hoeveel losse dingen beheerd moeten worden, stel je hebt 1 of 5 grote applicaties die vooral schalen dan is dat geen probleem voor relatief weinig mensen. Als ze honderden diensten op die servers beheren is het misschien wel weinig.

[Blokker_1999]

Als ik het aantal virtuele servers in mijn bedrijf tel ten opzichte van het personeelsaantal dan hebben wij in verhouding zelfs meer servers per persoon dan het OM. zo vreemd hoeft dat echt niet altijd te zijn. En neen, ook wij zijn geen kleine onderneming met maar een handvol mensen.

[Knul]

NRC spreekt over 1500 servers, lijkt me een tikfoutje van Tweakers.

[Die_ene_gast]

Steppingstones, test, acceptatie, productiesystemen (tap) e.d.
En als je service niet een monolithisch is, dan heb je voor 1 service dus meerdere servers. Dan gaat het hard samen met je tap erbij. Gooi er nog een paar gebouwsystemen in en je hebt zo een stuk of 10 extra servers(vergeet tap niet ook even, dus keer 3). Dan je IAM servers, VPN vanuit thuis, de servers voor security, ruimte reservering, mail, de schermen in het hoofdgebouw, intranet, teams, sharepoint, office, bizztalk, ADs en vast veel troep die ik nog vergeet.

15k is wel een beetje veel, maar je komt zo aan de honderden (virtuele) machines.

[lenwar]

Dat gaat al heel snel.

Meerdere ontwikkel-omgevingen (iedere ontwikkelaar z'n eigen VMs (ik noem maar wat)., test-omgevingen, acceptatie-omgevingen. (dat is al snel veel niet-prod servers voor iedere prod-server.)

Maar goed. Er is weinig over te zeggen, zolang we niet weten hoe ze werken enzo, maar het kan allemaal heel erg snel gaan.

[Noob_Saibot]

Ik gok ook veel legacy

[yevgeny]

Als het oude openVMS servers zijn, is het in ieder geval veilig.

[GreatDictator]

Legacy maar wellicht ook veel dubbel uitgevoerd (high-availability), OTAP-straten etc. Kan snel gaan.

[FabiandJ]

Ik denk dat veel mensen vergeten dat bij een organisatie/bedrijf niet alle servers die ze hebben alleen productie omgevingen zijn. Maar inderdaad zoals je zegt er hele Ontwikkel/Test/Acceptatie/Productie (OTAP) straten en of varianten hiervan zijn.

Dus stel het zijn er 15.000 dan zijn maar zo minimaal 1/4 hiervan productie systemen, de rest zit er allemaal voor en dan heb je nog niet eens rekening gehouden met omgevingen die dubbel uitgevoerd zijn.

En waarschijnlijk werken ze nog met steppingstones wat losse servers zijn, waarop je moet inloggen en kan inloggen als je de juiste rechten hebt voordat je op de server komt waarop je daadwerkelijk moet zijn.

[Reactie gewijzigd door FabiandJ op 23 juli 2025 09:09]

[georgeboot]

Dat getal viel mij inderdaad ook op. Klinkt me ook als erg veel.

[grasmanek94]

Geen flauw idee maar bij mij thuis heb ik meer (actieve) PC's (servers, desktops, etc) dan mensen.

[Reactie gewijzigd door grasmanek94 op 23 juli 2025 08:55]

[Standeman]

Omdat het OM niet een compleet geïsoleerde entiteit is. Ze schijnen nogal samen te werken met politie en justitie. Ongetwijfeld ook partijen als advocaten bureaus en binnenlandse zaken (AIVD). En met cloud omgevingen is het niet zo lastig om een servertje in de lucht te schoppen voor een specifieke taak.

[Reactie gewijzigd door Standeman op 23 juli 2025 09:12]

[SuperDre]

Misschien dat het artikel inmiddels is aangepast, maar je hebt 1 nulletje teveel. Zijn er nog steeds best veel.

[veltnet]

waarschijnlijk weet die goede man niet het verschil tussen services en servers. Het is de directeur dus de kans is groot dat die niet veel weet van wat hij zegt

[Reactie gewijzigd door veltnet op 29 juli 2025 15:28]

[Die_ene_gast]

Weer citrix? Is het niet tijd dat we dat de deur uitdoen?

[DinX]

Als je al een Citrix omgeving erachter draaien hebt is de meest logische oplossing om Netscaler ADC te gebruiken om zaken als desktops en applicaties remote aan te bieden.
Buiten Parallels heb je ook niet super veel alternatieven voor iets op dergelijke schaal on prem te hosten.

Of je moet al bijna je halve virtuele infrastructuur gaan ombouwen naar iets als Omnissa Horizon. Dan ben je ook al quasi verplicht VMware al hypervisor te hebben. Die laatste wordt daarbij ook al minder populair sinds hun licentiestrategie van de afgelopen 2 jaar.

Hier is alles de afgelopen jaren gemigreerd naar Nutanix AHV. Dan ben je quasi aangewezen op Citrix voor desktop en applicatie virtualisatie.
Je kan daar dan wel F5 BigIP voor zetten en dergelijke, maar dat werkt toch allemaal net wat minder gestroomlijnd dan er gewoon Citrix Netscaler voor te zetten.

Dus neem Citrix gaat niet snel de deur uit gaan in dergelijke groottes van organisaties.

[Die_ene_gast]

Ik snap dat het waarschijnlijk simpeler is gezegd dan gedaan, maar dit is niet de eerste keer dat Citrix voor grote problemen zorgt.

[M3m3nt0m0r1]

Want Citrix is verantwoordelijk voor het patch beleid bij bedrijven? Nee.

Als een bedrijf een lakse houding heeft is dat hun probleem.

[ictertje]

Ik snap al die haat naar Citrix niet, Microsoft producten zijn net zo vaak, al dan niet vaker, lek als een mandje. Citrix levert mooie producten doe goed werken en daarom ook ingezet worden door grote organisaties/enterprises en ,mits goed ingericht, tevens rete stabiel.

ik krijg echt de kriebels van opmerkingen als "weer citrix" of "Citrix doet het weer niet".
ik kan je vertellen als Workspace Consultant dat het 9 van de 10 keer NIET aan citrix ligt maar aan de infra er omheen (firewall/netwerk/AD etc.). Maar doordat daardoor je virtuele desktop (in de volksmond "Citrix") het niet doet, ligt het probleem natuurlijk bij....jawel.... CITRIX.

Sorry voor mijn frustratie, ik ben de generalisering van citrix afgelopen dagen zat:P.

[Die_ene_gast]

Mijn ervaring met citrix is gewoon super slecht dan

[Triblade_8472]

Ik zie het nut niet echt in van deze mededeling "Moonen zegt dat hij ongeveer 15.000 servers binnen het OM telt en dat een automatische beveiligingsscan van een server ongeveer vier uur duurt."

(@Ossian geeft hierboven aan dat de NRC meld dat het maar 1.500 servers zijn, niet 15.000)


Kunnen ze automatisch scans niet parallel draaien ofzo...? Dan ben je na 4 uur klaar. Of in batches van 100 servers bijvoorbeeld, dan ben je na 2,5 dagen klaar.

[HollowGamer]

Opnieuw beginnen zou veel beter zijn. Stel er is een actor binnen geweest (grote kans dus), dan kan je beter de server nuken, en alles weer syncen wat je nodig hebt.

Zo'n scan klinkt leuk, maar zal nooit alles kunnen zien, zeker niet met de malware van tegenwoordig.

Wat mij verontrust, is hoe je dus als actor schijnbaar bij al die systemen kan komen. Ik snap dat dit bedrijven niet waterdicht is, maar je verwacht toch van het OM een heel hoge standaard. Citrix is je begint punt, maar daarna heb je nog allemaal portals, rechten en authorisatie. Daarnaast lijken me updates en monitoring essentieel, daar heb je geen maand voor nodig lijkt me.

Wij hadden een Nederlands bedrijf gespecialiseerd in dit soort gevallen, de andere is omgevallen door de partner van de eigenaar ervan. Ik zie niet zo goed wie deze * gaat oplossen, want met beide haal je ook weer actors binnen (Fox-it is in Amerikaanse handen).

Ik merk bij mijzelf dat het vertrouwen zo laag in overheden, dat ik er al vanuit ga dat ze hun werk niet goed doen. Zo'n app om je leeftijd straks te checken, dat gaan dezelfde gasten runnen als die nu werken bij het OM.

Misschien moeten we toch echt eens straffen gaan uitdelen, gok dat echt wel mensen hebben gewaarschuwd (zoals bij BD), maar dit te duur was of wel een maandje later kon. Diegene die daar verantwoordelijk zijn geweest, mag weleens strafrechtelijk worden vervolgd. Je werkt bij het OM, niet bij IKEA.

[Reactie gewijzigd door HollowGamer op 23 juli 2025 09:35]

[Bockelaar]

Ik merk bij mijzelf dat het vertrouwen zo laag in overheden, dat ik er al vanuit ga dat ze hun werk niet goed doen. Zo'n app om je leeftijd straks te checken, dat gaan dezelfde gasten runnen als die nu werken bij het OM.

het OM heeft al meer dan 10 jaar de boel geoutsourced/uitbesteed aan een paar grote IT boeren in NL. Wijzen naar de overheeid is in dit geval niiet de juiste richting :)

[HollowGamer]

Weet je dat zeker? Ik dacht namelijk dat dit onderdeel wel grotendeels nog in eigen beheer was. Zoals bijvoorbeeld ook bij de Politie.

Heel veel wordt geoutsourced, en heel veel kennis is daardoor weg. Schijnbaar is het goedkoper dan mensen in dienst nemen.. maar betwijfel of dat op langer termijn ook zo is.

[Bockelaar]

zie bijvoorbeeld https://www.computable.nl/2012/11/12/om-besteedt-applicatiebeheer-uit-aan-capgemini/

en https://www.computable.nl/2017/12/30/2017-93-deals-publieke-cloud-verandert-alles/

[Reactie gewijzigd door Bockelaar op 23 juli 2025 12:45]

[dutchgio]

FoxIT is Brits, niet Amerikaans. Het is onderdeel van de NCC group.

[HollowGamer]

Ah sorry, dacht Amerikaans.

Maar goed, de Britten zijn misschien nog erger. Kijkend ook naar hoe ze het rechtvaardig vonden dat Apple maar hun encryptie eisen moest verlagen.

[BytePhantomX]

Wij hadden een Nederlands bedrijf gespecialiseerd in dit soort gevallen, de andere is omgevallen door de partner van de eigenaar ervan. Ik zie niet zo goed wie deze * gaat oplossen, want met beide haal je ook weer actors binnen (Fox-it is in Amerikaanse handen).

Alsof je door het inschakelen van bedrijf x of y die toevalling in buitenlandse (in dit geval Britse) handen is, direct een andere actor binnenhaalt. Dat is wel een hele alu-hoed interpertatie van aandeelhouderschap. Daarnaast kennen dit soort bedrijven goede informatiescheiding op basis van need-to-know en/of worden dit soort onderzoeken niet eens opgeslagen op de infrastructuur van zo'n bedrijf. Goede kans dat zo'n onderzoek staatsgeheim wordt gesclassificeerd en dan mag het niet eens elders worden opgeslagen.

[downtime]

Moeilijk te zeggen. Het zullen wel virtuele servers zijn dus je moet oppassen dat de hosts en storage niet overbelast raken omdat alle VM’s tegelijk scannen. Dus alles tegelijk klinkt niet als een goed idee.

[keejoz]

Dit viel mij ook op, ik stel me toch vragen bij deze uitspraken.

[Ossian]

NRC heeft het over 1500 servers.

Hij telde vijftienhonderd computerservers binnen het OM

[PaulHelper]

Jup ik denk een Lees fout, 15 duizend ipv 15 honderd. Hopelijk past tweakers het snel aan.

[Left]

Moonen vertelt dat het OM woensdag 16 juli is ingelicht door het Nationaal Cybersecurity Centrum over het lek in de NetScaler-software, naar aanleiding van een 'gerichte scan' van het NCSC. Toen had het OM het lek volgens hem al gedicht. Het lek werd op 17 juni in de CVE-database geregistreerd met het nummer CVE-2025-5777

Wacht ff. Het OM is dus een volle maand doorgehobbeld met een critical vulnerability in hun Citrix software, en het NCC heeft hun uiteindelijk wakker moeten schudden?
Zo'n CVE database hoor je te monitoren, als er een nieuwe CVE opduikt hoort je cybersecurity team onmiddellijk aan het werk te gaan. Ik heb bij diverse fintech bedrijven gewerkt en daar is dat absoluut normaal.


Dat een instantie als het OM met zoveel supergevoelige informatie niet zo'n policy lijkt te hebben is echt niet goed te praten.

[Reactie gewijzigd door Left op 23 juli 2025 09:15]