Crisiscommunicatie bij cyberincidenten is nog een jonge sport. Naar aanleiding van mijn kritiek op de veelvoorkomende salami-communicatiemethode, kreeg ik een reactie van iemand die het nu aan den lijve ondervonden heeft: het is héél moeilijk om alle betrokkenen voldoende te informeren én een vorm van zekerheid te geven tegelijkertijd. Dat klopt. Het is moeilijk om onmiddellijk perfect te weten wat er aan de hand is en hoe groot de schade is. Ik heb zelf een paar keer voor klanten in die schoenen gestaan en weet dat alles de eerste momenten vaag is en dat je tegelijkertijd moet oppassen om niet overdreven optimistisch of overdreven pessimistisch te zijn. En dat is de belangrijkste les die ik altijd heb voor dit soort communicatie: geef alleen de feiten die je zeker weet en filosofeer niet over wat zou kunnen zijn, negatief of positief. Het probleem dat ik altijd zie, is dat bij de meeste bedrijven die een cyberincident meemaken het managen van de reputatie belangrijker is dan voldoende transparant zijn tegenover de echte slachtoffers van de aanval: de bedrijven of individuen van wie je de data lekt of die gecompromitteerd zijn. Die moet je (wettelijk) snel en voldoende uitgebreid op de hoogte brengen, zodat de criminelen minder de kans krijgen om nog meer schade aan te richten. Zeg wat er gelekt of gecompromitteerd is, maar als je daar niet zeker van bent, zeg dan niet het expliciete zinnetje "Er zijn geen indicaties dat persoonsgegevens gelekt zijn". En die boodschap is vaak te belangrijk om aan communicatie-experts over te laten. Daarnaast vind ik het belangrijk dat bedrijven transparant zijn over hoe het gebeurd is, liefst naar een zo groot mogelijk publiek en niet enkel naar toezichthouders. Waarom? Omdat anderen eruit kunnen leren. Wat is er exact foutgegaan? Hoe zou je het voorkomen als je op voorhand had geweten wat je nu weet? Hoe kun je het structureel voorkomen? Deze lessons learned moeten aan een groter publiek kenbaar gemaakt worden. En dat doet misschien een beetje pijn, maar je maakt de wereld er beter mee. Niemand hangt graag zijn vuile was buiten, maar het zou je aanzien bij echte cybersecurityprofessionals en hopelijk ook bij gewone stervelingen enorm doen stijgen. Jaren geleden (2020) werd de Gemeente Willebroek gehackt. Ze werden door iedereen – vooral ook door de bevoegde minister op dat moment – voor de bus gegooid, ondanks zeer juiste beslissingen. Hun evaluatierapport werd publiek gedeeld en heeft heel wat gemeentes geholpen om hun eigen security op orde te brengen. Zonlicht (uv) is het beste ontsmettingsmiddel. Elke organisatie functioneert in een groter geheel, een samenleving. Tegenover die samenleving is het je verdomde plicht om transparant te zijn over wat er gebeurd is. In deze "interesting times" kun je het een organisatie maar beperkt kwalijk nemen dat ze een cyberincident heeft; het kan ons allemaal overkomen. De echte test is hoe je professioneel met zo'n cyberincident omgaat.👇 lnkd.in/p/eWka5tqK

De Broccoli-storm blijft op de softwarewereld inbeuken Vorige week leek het nog een probleem voor Node.js-developers. Zondag stuurde Microsoft noodpatches uit voor .NET 8, 9 en 10, Visual Studio en PowerShell. Zelfde bug. Eerst heette hij Node2Shell, daarna HTTP2Shell en ondertussen Broccoli2Shell, een knipoog naar Brotli, de bibliotheek waarin de fout zit. Het begon 8 maanden geleden met een simpele bugfix in de Brotli-repo. Een bugfix zoals er elke dag duizenden gebeuren in verschillende opensourceprojecten, die een programmatiefout oplost. Niemand zag er toen een potentieel securityprobleem in en er was ook geen aandacht voor. Tot het securityteam van OpenAI er met zijn AI-tool Codex op botste en zag dat je er een server mee kon overnemen. Nu is Brotli zo’n typisch nuttig stukje software ontwikkeld door Google dat zorgt voor zeer efficiënte compressie van de HTML of andere gestructureerde data die je over het netwerk doorstuurt. Het is één van de tientallen componenten die we gebruiken om op een snelle en makkelijke manier coole en efficiënte software te ontwikkelen. Want elk stukje software, elk product, open source of closed source, is een blokkendoos van andermans code in de vorm van libraries die een developer in staat stellen om zijn eigen oplossing te bouwen. Het is de reden waarom software-innovatie zo snel en betaalbaar kan. Maar er is ook een donkere zijde. Als er in zo’n bouwsteen een fout zit, in dit geval één met serieuze veiligheidscomplicaties, dan sleurt die alles mee wat erop gebouwd is. Eén populaire bibliotheek lek, en een hele keten (supply chain) aan oplossingen is ook lek. De afgelopen week bleek dat de ogenschijnlijk onbelangrijke bug van februari misbruikt kan worden om in verschillende aanvalssituaties (crash, memory leak of in het ergste geval het uitvoeren van code) servers en toepassingen te compromitteren. Het begon met een advies rond Node.js, maar ondertussen zijn tientallen tools, frameworks, programmeeromgevingen, proxy’s, databanken, archieftools en zelfs firmware geïmpacteerd. En daar zit de echte les. Veel software gebruikt niet de Brotli van je besturingssysteem, maar bundelt een eigen kopie. Je Linux-server updaten volstaat dus niet: elke leverancier moet zelf patchen. Een mooi voorbeeld is 3CX, een telefooncentrale die haar eigen .NET-runtime meelevert. Beheerders vragen zich op het forum af of ze getroffen zijn. En terwijl Node.js, Python, .NET, Ruby en PHP ondertussen een fix hebben, wachten DuckDB, Apache Arrow, enkele 7-Zip-varianten en de UEFI-firmwarecode EDK II er nog op. Geen paniek: er is nog geen misbruik in het wild gemeld en in veel software staat Brotli-decompressie niet standaard aan. Maar er circuleren wel al proof-of-concepts, dus dat kan snel veranderen. Het wordt weer een week om alle updates goed op te volgen. En misschien ook allemaal eens werk maken van die software-bill-of-materials... 😉 👇 lnkd.in/p/edR4WSfH

Sociale media backuppen en beveiligen Hoe belangrijk zijn de inhoud, toegang en contacten van je socialemedia-accounts voor jou en je bedrijf? Wat me bij veel CYSSME-gesprekken met kmo's opvalt, is hoe belangrijk sociale media als LinkedIn, Insta(gram), Facebook en YouTube geworden zijn als marketing en portfolio voor hun bedrijf. Het is voor hen een marketingkanaal, een portfolio om zich te tonen en een manier om met bestaande en nieuwe klanten te communiceren. Alleen over de beveiliging en vooral de weerbaarheid van deze online activiteiten denkt men zelden na. De eerlijkheid gebiedt te zeggen dat ik er zelf ook niet echt mee bezig was, terwijl toch bijna 55% van de leads van mijn bedrijf uit mijn persoonlijke profiel en, in mindere mate, de bedrijfsprofielen komt. Daarom een korte cursus backup en beveiliging van de voornaamste sociale media. In de eerste plaats zijn het accounts die je goed moet beveiligen. Gebruik altijd een goed opgezet account, met MFA (waarvan je ook de recoverycodes hebt) en een correct, up-to-date e-mailadres en gsm-nummer. Wees ook voorzichtig waar je met je SM-accounts inlogt en aan welke tools en applicaties je allemaal à volonté toegangsrechten geeft. Dit geldt zeker voor een bedrijfsaccount, waarvoor je best ook een tweede account als backup-admin aanmaakt. Alles wat belangrijk is, moet je ook regelmatig op een correcte manier backuppen. En hier hebben we gelukkig de GDPR-wetgeving, die je inzage geeft in al je persoonsgegevens. In een ruime context is heel je socialemediaverkeer een persoonsgegeven. Om dit recht makkelijk te laten uitoefenen (en geen hele supportdesk te moeten voorzien), hebben de meeste sociale media dit geautomatiseerd en kan je het online aanvragen. Meer details en directe links zitten in de cheat sheet in het Nederlands en Engels in de PDF onderaan 👇 Je doet op de juiste plek een aanvraag en een paar minuten tot een paar uur later krijg je een downloadlink voor een zipbestand met alles wat je ooit op dat specifieke platform hebt uitgevreten, in één gestructureerd archief. Dan is het zaak om te controleren of het archief correct is en het op de juiste manier veilig (niet toegankelijk voor derden) en op meerdere plaatsen (3-2-1-regel) te bewaren. Neem dit archief mee in je gewone backups. Het enige wat je niet op deze manier kan backuppen, is een LinkedIn company profile. Daar heb ik zelf geen oplossing voor gevonden, en ook van de meeste advertisingaccounts kan je niet echt een gestructureerde backup maken. Hou er wel rekening mee dat de downloadlinks niet blijven staan en al na enkele dagen (meestal 72 uur tot 4 dagen) vervallen. Ik heb nergens goeie structurele backupsoftware gevonden die dit automatiseert, dus je gaat het op vaste tijdstippen, zoals elke 3 maanden, opnieuw moeten doen. Tips, trucs, voortschrijdende inzichten, dingen die ik vergeten ben? Comments! 👇 lnkd.in/p/e4BSTccX

𝗖𝘆𝗯𝗲𝗿𝗶𝗻𝗰𝗶𝗱𝗲𝗻𝘁 𝗶𝗻 𝗱𝗲 𝗱𝗶𝗴𝗶𝘁𝗮𝗹𝗲 𝗵𝗮𝗻𝗱𝘁𝗲𝗸𝗲𝗻𝗶𝗻𝗴𝗱𝗶𝗲𝗻𝘀𝘁 𝘃𝗮𝗻 𝗩𝗮𝗻𝗱𝗲𝗻 𝗕𝗿𝗼𝗲𝗹𝗲, 𝗺𝗲𝗲𝗿𝗱𝗲𝗿𝗲 𝗴𝗲𝗺𝗲𝗲𝗻𝘁𝗲𝘀 𝗴𝗲𝗶̈𝗺𝗽𝗮𝗰𝘁𝗲𝗲𝗿𝗱 Vorige week donderdag en vrijdag heeft een externe aanvaller toegang gekregen tot onderdelen van eSignFlow en SignService. Dit is een ondertekendienst die veel gemeentes gebruiken om de veelheid aan documenten die ze uitsturen digitaal te ondertekenen. Hij of zij zou dit naar verluid gedaan hebben met sleutels die hij of zij eerst ontfutseld heeft uit een publiek bereikbare beheeromgeving. Het bedrijf heeft uit voorzorg de omgeving tot zaterdag offline gehaald en ondertussen terug opgestart. De API's die veel van deze processen automatiseren, werken op dit moment nog niet terug. Gezien er heel wat gemeentes van deze dienstverlening gebruikmaken, is de impact op de dienstverlening aanzienlijk. Niet enkel Vanden Broele gaat hier veel werk mee hebben, ook de lokale gemeentes zelf zullen in het kader van de GDPR-wetgeving en NIS2 aan de slag moeten om te onderzoeken wat er aan de hand is en dit op de juiste manier aan de toezichthouders en eventuele slachtoffers te melden. Met wat we nu weten, heeft Vanden Broele alles goed opgevangen en is de gelekte data volgens eigen zeggen beperkt tot metadata en gaat het niet om de documenten zelf. Niks wijst er op dit moment op dat er gemorreld is met de digitale handtekeningen zelf. Ik hoop dat de salami-methode voor één keer niet van toepassing is. Maar zoals altijd kan je beter safe than sorry zijn en de komende maanden uitkijken. Pas op voor eventuele phishing of andere social engineering in naam van eSignflow of je gemeente. Met de buitgemaakte informatie kan die phishing er heel officieel en heel correct uitzien. Aarzel ook niet om deze aanvallen te melden bij Safeonweb. Het is de zoveelste aanval op de kritische basisinfrastructuur van onze digitale overheid. Het zal ook niet de laatste zijn. Onze cyberweerbaarheid wordt duchtig getest. lnkd.in/p/eYHrMeHC

Markdown: terug naar de inhoud, niet de verpakking Als ik op restaurant ga, heb ik weinig vertrouwen in eentje met een ellenlange menukaart met tientallen opties. Het geeft keuzestress, maar vooral: je weet dat niks vers is en dat de microgolfoven het werk doet. Zo voelt MS Office voor mij ook. Een menukaart met zoveel opties dat een kat zijn jongen er niet in terugvindt. Bij het Microsoft-team dat Office bouwt, zit volgens mij een hele ploeg die bij elke nieuwe release simpele gebruikers als mezelf desoriënteert door alles opnieuw om te gooien. Ook LibreOffice, dat ik zelf gebruik, geeft me met al zijn opties vaak writer's block. Ik hou van schrijven en presenteren. Het is voor mij geen werk, het is een passie die me stimuleert om na te denken en me geestelijk gezond en happy houdt. Maar ik betrap me er steeds vaker op dat het afwerken, dat nette, gelayoute document of die aanvaardbare eindpresentatie, me meer tijd en energie kost dan datgene waar het om gaat: de inhoud. Stiekem verlang ik terug naar het blauwe scherm van WordPerfect 5.1 onder MS-DOS. Je kon er eigenlijk alleen tekst in produceren, zonder tientallen toeters en bellen. Het is pas beginnen fout te gaan toen ik mijn thesis schreef op een machine met Chicago (de bèta van Windows 95) en Word. Het gekke is: de betere oplossing staat al jaren voor mijn neus. Voor de technische kanten van mijn job gebruik ik al jaren vi(m) en Markdown. Maar voor de echte teksten greep ik toch altijd naar een echte tekstverwerker. Ik heb nooit de klik gemaakt. Nu wel. Want koppel je Markdown aan Marp, Pandoc of het simpele Hugo, dan maak je van je content snel en efficiënt alles wat je wil: een mooi pdf-documentje, een slidedeck, een statische website, tot zelfs een heel epub-e-book. Combineer dat met git en je houdt al je wijzigingen bij, of je werkt makkelijk met meerdere mensen aan hetzelfde document of dezelfde presentatie. En ik ben niet alleen. Quasi elke AI gebruikt Markdown als default, en notitie-apps zoals Obsidian zijn er volledig op gebouwd. Je hoeft dus niet die-hard in vi of Visual Studio Code te werken: er zijn zachtere methodes. Je schrijft gewoon. De template doet de rest, zo automagisch mogelijk. Terug focus op de inhoud, niet op de verpakking. Suggesties, comments, opmerkingen, advies in de comments 👇 linkedin.com/posts/jangulden…

I've been doing Linux since the early '90s, when you had to install your Slackware box from three boxes of floppies. We've built solutions around the penguin for decades, back when you just offered "a solution" and never talked about Linux and open source because it was seen as something weird, almost communist. I've seen the Tuxes appear, first supported by guerrilla campaigns, and the first big players like IBM coming on board. A time when you saw plastic and plush Tuxes everywhere, at every trade fair, in every office space. And then Linux became the lingua franca of the whole internet, and even Microsoft picked it up. And strangely, Linux and Tux began to disappear from the office spaces, the trade fairs, the car windows. Linux was everywhere but hidden, and nobody talked about it anymore. I've talked about this with Peter Dens: at the whole "Trefdag Digitaal Vlaanderen" no tux-penguin was to be seen. Even though the chief of Digitaal Vlaanderen is sceptical about open source and Linux, we have won. Our (and I do say our) pet project has become mainstream and powers innovation today. It even powers Microsoft's cloud. Linux is big business, with IBM offering 34 billion for Red Hat, a fully open source company that can, just like other players such as SUSE, Canonical and hundreds of other companies, offer a high level of support and innovation. So you're not tied down to one player to be milked like a cow. But we need to reclaim our identity, bring back the penguin, use it as a symbol, a rallying cry to take the final step in what Linus Torvalds jokingly called world domination. So proudly put your plush penguin back on your desk, put a sticker on your laptop and car, and claim your identity as an open source believer and a penguin lover. And open source and Linux companies, dust off the old Tuxes and bring them proudly to the next trade fair and event. Not because Linux has to become sexy (it was all along), but as a symbol of how our bright technological future will be built. lnkd.in/p/eHRK3FVz

Storm: Node2Shell groeit uit tot HTTP2Shell Het stormt de laatste dagen zowel in de fysieke als in de virtuele wereld. Eergisteren hadden we het over Node2Shell: een klassieke buffer overflow, meer bepaald een out-of-bounds write (OOB), in één onderliggende library binnen Node.js. Het gaat om Google Brotli, de compressietechnologie die webverkeer compacter en efficiënter maakt (CVE-2026-111497). Zo'n overflow stelt een snode aanvaller in staat om systemen plat te leggen of, in het slechtste scenario, via een shell permanente toegang te forceren. Alleen zit Brotli niet enkel in Node.js. Vrijwel elke applicatie die gecomprimeerd webverkeer (HTML, XML of JSON) verwerkt, kan het onder de motorkap hebben zitten: Python, C++ en vermoedelijk nog een reeks andere omgevingen. Ik ben al opgelucht dat Nginx en Apache er, voor zover we nu weten en buiten exotische configuraties, geen last van lijken te hebben. Op die manier groeit één kwetsbaarheid in het wankele kaartenhuis van onderliggende libraries, met wat AI-hulp, razendsnel uit tot meerdere door scriptkiddies uitbuitbare exploits. We hebben er weer een acuut probleem bij, en het bekende circus van monitoren, patchen en controleren begint opnieuw. Na het opruimen van elke storm trekken we lessen. Voor mij is het signaal duidelijk: de speeltijd is voorbij. We moeten de maatregelen die we al jaren kennen eindelijk eens structureel afvinken. α Minimaliseer wat aangevallen kan worden. Wat niet draait, niet publiek bereikbaar is of achter een Web Application Firewall zit, raak je niet zomaar. Security by obscurity lost de fout niet op, maar koopt wel kostbare reactietijd. Pas firewalls, SD-WAN en WAF's consequent toe. β Bouw een geautomatiseerd proces om alles up-to-date te houden. Niet alleen de vertrouwde Microsoft-omgevingen, maar je totale softwarestack. γ Log en analyseer centraal. Gebruik een SIEM die helpt afwijkingen direct op te merken en achteraf te reconstrueren wat er gebeurd is. δ Breng je softwarecomponenten in kaart met een Software Bill of Materials (SBOM). De EU Cyber Resilience Act verplicht dit pas eind 2027 voor leveranciers, maar niets houdt je tegen om die inventaris nu al op te vragen voor elke externe en opensourcetoepassing, of zelf op te stellen voor eigen software. Maak dit alles structureel, want dit werk stopt nooit meer. Vrij naar Nike: Just do it. Er zijn massa's closed- en vooral opensourcetools, en natuurlijk ook consultants, om je te helpen en het beter of makkelijker te maken. Zelf nog vragen, tips en verbeteringen zet ze bij follow-up en meer informatie in de comments 👇 #sbom #cra #cybersecurity #cyberresilience #node2shell #https2shell lnkd.in/p/e478y8TQ

Wanneer loopt de emmer over? Wanneer zegt de burger die elke maand meer dan de helft van zijn inkomen afgeeft aan een staat die haar deel van het contract niet nakomt, genoeg is genoeg? Worden alle bij dit debacle betrokken (onder)zoeksrechters op staande voet ontslagen wegens incompetentie? #dtv

Two weeks ago, Stef Schampaert & Barbara Descheemaecker asked me to give the closing note at @RedHat Summit in Brussels. The idea was to combine what I had seen that day, my thoughts, and how we go forward in open source and as a society in general. As usual, I talked off the cuff, based on 3 slides and a couple of notes on a piece of paper. Because the subject matter is so important, I decided to write out the ideas of the talk further. I talk about the interesting times we live in, the 2 elephants in the room (AI and digital self-determination), and what I think is the solution: the lingua franca, open source. And I gave them homework to think about on the, probably long, way back home that night. Thanks for asking me and for listening. And feel free to comment, add, disagree or agree in the comments.👇 lnkd.in/p/euz3xiGC

Node2shell-exploit – het hele web moet eraan Door het lawaai rond de recente PHP-bugs is me dit even ontgaan, maar er is ook een remote-code-execution-bug uit voor dat andere platform waar we al onze webapplicaties op bouwen: Node.js. De exploit, die naast CVE-2026-111497 ook de mythische naam node2shell wordt toegedicht, misbruikt een ordinaire memory-overflow/out-of-bounds-bug in de Brotli-decoder om hem plat te leggen of in bepaalde gevallen eigen code te laten uitvoeren op het Node.js-systeem. Brotli is een Google-compressiealgoritme dat Google in 2015 uitbracht en dat vooral goed is in het comprimeren van webcontent. Iets wat dus, m.a.w., heel veel gebruikt wordt in webomgevingen. Er is nog weinig nieuws over aanvallen in het wild met deze bug, maar zoals altijd is het beter nu te kijken waar er allemaal gepatcht moet worden. Als alternatief kan je ook de juiste regels op je Web Application Firewall aanzetten om deze aanval te onderscheppen en onschadelijk te maken. Ik kreeg gisteren op Twitter het verwijt dat ik PHP de schuld gaf. Niks is minder waar: elke technologie, elk stuk software, elke library in een keten van een internetoplossing is kwetsbaar en moet permanent up-to-date gehouden worden. En buiten een duidelijke ideologische voorkeur voor open source probeer ik geen fanboy te zijn van de ene technologie eerder dan de andere. Maar wat een boer niet kent, dat vreet hij niet. Dus: rol de mouwen op, check in je inventaris waar je Node.js gebruikt, check de versies en patch op een structurele manier. Aan de arbeid! lnkd.in/p/eCDTAM68

Post-patching gedachten bij de PHP-ellende Zelfs de Vlaamse overheid en toezichthouders op het vlak van informatieveiligheid als het CCB en het NCSC moesten deze week hun websites uit voorzorg downbrengen. Dat zegt veel over hoe weinig weerbaar we wel zijn. Het stof is een beetje gaan liggen, en dan is het altijd goed om even na te denken over wat we geleerd hebben. Ik heb veel goeie dingen gezien, maar soms was het ook een slecht theater van onvoorbereidheid, gebrek aan organisatie en onzin. Het goede is vooral dat het au sérieux genomen werd en dat er prompt gereageerd werd door de gebruikers van PHP. Begrijp me niet verkeerd: preventief downbrengen is geen slechte beslissing, maar het toont direct onze zwakheden. Het leert veel mensen ook hoe afhankelijk ze geworden zijn van SaaS-cloudoplossingen. Ik zag bv. iemand van een advocatenbureau dat zich specialiseert in cyber vertellen dat ze de contactgegevens van bepaalde klanten niet had in deze crisis, omdat Teamleader proactief zijn site had platgelegd. Een paar dingen die we hieruit kunnen leren: Als je echt met cyberweerbaarheid bezig bent, heb je ook een statische kopie van je website (good old HTML, nauwelijks risico) met een maillink als contact, die je online kan zetten als dit soort dingen gebeurt. Dan moet je niet ineens alles offline halen. Dit kan al met een simpel wget-commando (zie comments). Iedereen die essentiële dingen in een SaaS-oplossing heeft staan, moet eens nadenken hoe hij daar op zijn minst elke nacht een back-up van draait naar een lokale opslag, in een formaat dat toegankelijk is als die SaaS-provider het opgeeft. Wat in de NIS2- en CRA-wetgeving beschreven staat, is wel degelijk nodig om cyberweerbaar en veilig te zijn: een inventaris, een incidentenplan, updateprocedures, etc. Laten we dit verhaal als een cyberweerbaarheidstest zien. Ik verwijt niemand de dode hoeken en hiaten die ze in hun plannen hebben. De paniek kwam eigenlijk door een mislukte, gecontroleerde Responsible Disclosure: de proof-of-concept en sommige patches lekten al uit voor het release-moment van de officiële patches. Ook hier moeten we als digitale samenleving aan werken. En laten we direct ook eens nadenken hoe we als gemeenschap de opensourceproducten waar we allemaal op bouwen financieel en qua bijdragen kunnen ondersteunen. Last but not least stelt het samenzweringsduiveltje op mijn schouder altijd de vraag: "Cui bono", wie wordt hier beter van? (Open)AI heeft zich duidelijk kunnen profileren, net als de Cloudflares, Akamai en Fastly van deze wereld, die hun beurskoers nog zien stijgen terwijl ze eigenlijk al heel hoog staan. Meer info in de comments 👇 lnkd.in/p/eS_V8CS4

(Digitaal) Vlaanderen en open source Ik was er gisterenavond niet bij toen Jan Smedts van Digitaal Vlaanderenzijn keynote gaf. Op de trefdag hoorde ik wel dat hij zich negatief over open source zou hebben uitgelaten. Maar wat heeft hij nu precies gezegd? “Andere Europese landen kiezen resoluut voor open source. Dat kan daarin een element zijn, maar we moeten voorbij de slogans kunnen kijken. Open source is niet automatisch meer soeverein”, zegt hij; “Code waar niemand kennis van heeft, die niemand onderhoudt en waarvoor niemand verantwoordelijkheid neemt, maakt ons niet onafhankelijk. Dan hebben we gewoon een afhankelijkheid zonder telefoonnummer.” Digitaal Vlaanderen heeft in het verleden (te) vaak voor closed source gekozen. En ik kan me soms niet van de indruk ontdoen dat men hoopt dat de wolk rond digitale soevereiniteit snel overwaait, zodat het weer business as usual wordt. Zelf heb ik een andere, praktische kijk op wat open source betekent voor soevereiniteit. Zoals elke software moet ook open source inderdaad onderhouden worden. Het enige verschil met closed source: je hebt de code al in handen. Je kan er desnoods zelf, of met een andere partner, mee verder. En dat eeuwige riedeltje dat niemand in de industrie open source professioneel ondersteunt? Please. Red Hat, SUSE Kangaroot en tientallen andere bedrijven die ik nu nog vergeet zijn er actief mee bezig. “Open source is geen besparingsstrategie. Wie meer autonomie wil, moet bereid zijn om te investeren in mensen, in kennis en in verantwoordelijkheid. Soevereiniteit is niet gratis. Autonomie heeft een prijs, maar afhankelijkheid heeft er één die je niet zelf bepaalt.” Eens. Open source is niet gratis en heeft ook een prijs. Maar die ligt zeker niet hoger dan die van de lock-in waarin we ons vandaag hebben vastgereden. Vastgebonden koeien kunnen nu eenmaal niet anders dan zich vier keer per dag te laten (uit)melken. Ik heb een droom... Een informaticasector die zich toelegt op open oplossingen die overheidsklanten blijven gebruiken. Niet omdat ze niet weg kunnen, maar omdat ze zo goed zijn. In Vlaanderen en België geven we met imec, Aikido Security, Odoo, TechWolf en honderden andere kleine ondernemers met minder hippe tech de technologische evolutie al vorm. De overheid moet ze vooral laten doen en een ondersteunend, digitaal kader leveren dat hen helpt onze samenleving beter te maken. Zou dat geen goeie zaak zijn? linkedin.com/posts/jangulden…

De PHP wake-upcall Af en toe heb je als mens een wake-upcall nodig om je keuzes te evalueren en jezelf enigszins terug op het rechte pad te brengen. Gisteren was zo'n wake-upcall. Ik bedoel niet voor de arme securit en systeembeheerders die opnieuw aan de slag moe(s)ten om de natie te redden van 2 te vroeg gelekte PHP-exploit. Neen, over hoe we met onze digitale infrastructuur omgaan, en vooral al die dingen waarvan we weten dat ze goed voor ons zijn en die we zouden moeten doen, maar eigenlijk op de lange baan schuiven. Ik heb zelf gisteren meerdere keren gedacht: dit had ik eerder anders moeten aanpakken. Het zou me veel miserie bespaard hebben. Responsible disclosure is bij deze twee kritische kwetsbaarheden ook niet goed verlopen. Eerst lekte uit dat er twee grote CVE's met een score >9 aankwamen voor PHP, wat bij iedereen die een beetje snapt wat dit betekent al een verhoogde bloeddruk met zich meebracht. En dan is een bedrijf (om Chainguard niet bij naam te noemen) dat in de loop zat nog zo lomp geweest om al 's ochtends, ruim voor de officiële disclosure om 16:00 Belgische tijd, een patch online te zwieren. Dit gaf de moderne, door AI bewapende scriptkiddies iets om een exploit uit te reverse-engineeren. Resultaat: paniek en een hele hoop websites die het licht uitdeden en uit voorzorg afgezet werden. Het leert me ook dat elke maatregel die door vele ambetanterikken zoals ik en door de standaarden naar voren geschoven wordt als belangrijk, zijn nut heeft. Als je een inventaris hebt en je cloud- en softwareleveranciers alle software en dependencies laat oplijsten, was het gisteren een stuk makkelijker om te vinden waar je kwetsbaarheden zitten. Allemaal dingen waarvan we al lang zeggen dat ze belangrijk zijn en die ondertussen in standaarden en wetgeving als NIS2 en de CRA afgedwongen worden. We moeten ook leren dat we onze updates structureel uit te voeren, ook voor die oude PHP 5.dinges onder de applicatie die we nauwelijks nog gebruiken. En misschien ook eens nadenken over een begin van lifecyclemanagement voor onze IT-infra. Een ander belangrijk element is sterk doorgedreven segmentatie: netwerktechnisch kan je tot een absoluut minimum beperken wie aan bijvoorbeeld PHP-gebaseerde management- en monitoringtools kan. Firewalling, of nog verder doorgedreven met iets als OpenZiti websites voor interne doeleinden helemaal dark maken, is een goed idee. Net als een goede Web Application Firewall ook kan helpen. Ook onze operationele securityaanpak wordt op zo'n moment getest: heb je zichtbaarheid op wat er op je systemen gebeurt, kan je (al dan niet met AI geholpen) anomalieën en andere rare verschijnselen op je infrastructuur zien opduiken? Dit gaat nog weken, maanden nazinderen, net zoals Log4Shell, Heartbleed en andere voorgaande securitycrises in het software-hart van onze digitale samenleving. Maar "Never waste a good crisis": laten we er nu uit proberen te leren. Wat heb ik gemist en wat hebben jullie hieruit geleerd? 👇 linkedin.com/posts/jangulden…

Goede ;-)

PHP-websites uit voorzorg down De paniek zit er duidelijk in rond de nieuwe PHP-lekken (PHP2Shell, CVE-2026-109618 en CVE-2026-109619) die vandaag zijn opgedoken. Normaal zouden we vandaag om 16:00 de patches krijgen. Maar de details zijn vooraf gelekt, en nu heerst er een lichte vorm van paniek. Het gaat om lekken met een score van 9.2 die mogelijk remote code execution toelaten zonder in te loggen. Mogelijk zijn alle versies vanaf PHP 5 getroffen. Er wordt al wereldwijd gescand naar kwetsbare servers. CERT-EU raadt organisaties die niet meteen kunnen patchen aan om hun sites offline te halen. Een aantal organisaties kiest het zekere voor het onzekere en legt zijn website tijdelijk plat, in Japan, maar volgens berichten ook bij de Nederlandse overheid. En er draait wel wat op PHP: alle WordPress-, Drupal- en Joomla-sites, Magento-webshops, heel wat hostingplatformen en control panels. Of grote namen als Wikipedia, Tumblr, Etsy, Flickr, Mailchimp en Mollie. Better safe than sorry. Ik begrijp dan ook dat je internet-facing websites tijdelijk downbrengt. Voor mij is het de motivatie om iets te doen dat ik al lang plan: de ba.be-website eindelijk omzetten van WordPress naar een statische site (Hugo). Gewoon HTML, geen database, geen plugins, geen PHP. Stukken sneller, minder miserie en een veel kleiner aanvalsoppervlak. lnkd.in/p/eKP653tG

Zware PHP-kwetsbaarheden, patch vanmiddag aangekondigd Het wordt een drukke woensdag. Vandaag, 21 oktober, om 16:00 Belgische tijd (14:00 UTC) brengt het PHP-securityteam patches uit voor twee kwetsbaarheden met een CVSS-score van 9.2. We weten nog niet precies wat er aan de hand is, maar die score zegt genoeg: dit is ernstig. PHP zit onder de motorkap van zo'n 70% van de websites. De komende dagen moeten dus heel wat Linux- en Windows-servers, Docker-images en andere stukken internetinfrastructuur geüpdatet worden. Ik ga ervan uit dat het PHP-team de distributies en andere spelers al op voorhand heeft ingelicht, zodat er snel overal updates beschikbaar zijn. Dus: zorg dat je om 16:00 klaar bent om op de php-website op te volgen wat er aan de hand is. In tijden van AI is snel patchen belangrijker dan ooit. Op basis van een patch de bug terugvinden en er een exploit van bouwen, gaat vandaag stukken sneller en makkelijker dan vroeger. Het team houdt zich trouwens het recht voor om vroeger te releasen als er misbruik opduikt. Systeembeheerders: doe vanmiddag nog een dutje. Vanavond is het testen, patchen en updaten. lnkd.in/p/eTYpn4Vp

E-mail als groot datalek Datalekken hoeven niet alleen van hackers met complexe aanvalstechnieken te komen. Er zijn zoveel manieren waarop je als niet-wakkere eindgebruiker gevoelige data en vaak ook persoonsgegevens uit lompigheid kan lekken. Iedereen zegt nu meteen dat dit oud nieuws is en hen nooit zal overkomen. Maar wie echt in zijn eigen ziel kijkt, heeft al stommiteiten uitgehaald met e-mail. Het blijft verbazingwekkend hoe slecht populaire e-mailsoftware eigenlijk in elkaar zit. Vooral hoe makkelijk je dingen naar de foute bestemmeling stuurt doordat de autofill plots een verkeerde Pier, Sus of Janneke selecteert. En dan vertrekt die vertrouwelijke mail naar de verkeerde persoon, met alle gevolgen van dien. Dan zijn er carbon copy (cc) en blind carbon copy (bcc). Het doordacht inzetten van die velden is de afgelopen decennia uitgegroeid tot een strategisch talent in het steekspel van kantoorpolitiek. Over overdadig cc-gebruik, te veel mensen cc'en, mensen bewust weglaten of stiekem in bcc zetten moet iemand maar eens een boek schrijven. Ik word er altijd een beetje moe van. Als je het verschil tussen cc en bcc niet kent, lek je voor je het weet kritieke bedrijfsinformatie. Een organisatie die alle klanten een update stuurt met iedereen gewoon in cc, deelt haar volledige klantenbestand met de buitenwereld en vermoedelijk ook met minstens één concurrent. Je schendt daarmee meteen de privacy van je klanten, want zeker bij gevoelige diensten (ik laat jullie fantasie dit zelf invullen) heeft niemand er zaken mee wie klant bij jou is. Wettelijk moet je zoiets in veel gevallen zelfs melden aan de toezichthouder als officieel datalek. Begint iedereen vervolgens vrolijk op reply all te drukken, dan zit je midden in een complete storm. Elke paar weken zie ik wel weer zo een paar abuisjes in mijn inbox belanden. Het kan helaas nog veel pijnlijker. De Londense Metropolitan Police Service onderzoekt al geruime tijd het misbruik door voormalig Harrods-eigenaar Mohamed Al Fayed. Onlangs stuurden ze een update naar 143 slachtoffers, maar zetten hen allemaal samen in cc. Weg anonimiteit van slachtoffers in een uiterst gevoelig strafonderzoek met kwetsbare mensen. Onaanvaardbaar. Het blijft me ook verbazen welke gevoelige documenten mensen zomaar onbeveiligd rondmailen, zonder enige encryptie van het bestand of de inhoud. Je weet nooit waar je bericht terechtkomt, waar het onderweg wordt opgeslagen of naar wie het doorgestuurd raakt. We praten al dertig jaar over asymmetrische e-mailencryptie zoals PGP of S/MIME, maar laten we eerlijk zijn: vrijwel niemand gebruikt het in de dagelijkse praktijk. Ik zie het gebruik ervan eerder afnemen dan toenemen. Eigenlijk is dat onbegrijpelijk. Controleer dus altijd naar wie je mailt, wees zuinig met de cc-knop en als je echt gevoelige informatie verstuurt, versleutel dan liefst de e-mail of op zijn minst het bestand dat je meestuurt. 👇 lnkd.in/p/eV-WMKwz

Revolut ligt plat, en de oorzaak ligt vermoedelijk bij Google. Sinds vanochtend werken de app en zelfs de kaartbetalingen van Revolut niet of nauwelijks. In een wereld waar contant geld steeds minder gebruikt wordt, veroorzaakt dat logischerwijze flink wat problemen. Geen Revolut, geen koffie of broodje vanmiddag. Het blijft niet beperkt tot Revolut. In het Verenigd Koninkrijk melden ook klanten van Lloyds, Bank of Scotland en HSBC storingen. Ook Rightmove, Royal Mail, DPD, Halifax en Vinted zijn getroffen. Wie dieper in de supply chain kijkt, ziet dat de Londense Google Cloud-regio europe-west2 sinds 8u10 Belgische tijd met zware netwerkstoringen kampt. Het verband is nog niet officieel bevestigd, maar de timing spreekt boekdelen. Het toont maar weer eens hoe kwetsbaar onze digitale samenleving is en hoe sterk we onze toekomst gebouwd hebben op een handvol grote leveranciers. Eén cloudregio in Londen, en miljoenen mensen in heel Europa kunnen niet meer betalen. Ik ga seffens een broodje halen en ga het ostentatief betalen met de cash die in mijn gsm-hoesje zit. Misschien moeten we allemaal maar weer wat vaker cash gebruiken. lnkd.in/p/eaw5Bw3v