Logistiek bedrijf Veerman meldt datalek met gegevens van 320.000 medewerkers

Illustratie bij dit bericht.
Logistiek bedrijf Veerman heeft een datalek gemeld waarbij gegevens van ongeveer 320.000 medewerkers toegankelijk zijn geweest voor onbevoegden.
Het gaat om naam, adres en contactgegevens. Volgens de organisatie zijn er geen aanwijzingen dat de gegevens verder zijn verspreid.
Wat er precies gebeurde
De melding is gedaan bij de toezichthouder. Er loopt een intern onderzoek naar de oorzaak.
Het lek ontstond doordat een systeem verkeerd was ingesteld. Betrokkenen zijn per brief geinformeerd.
'Geen aanwijzingen dat de gegevens verder zijn verspreid' betekent meestal: we weten het niet.
Eens, met een kanttekening: In een kleine omgeving lukt dat prima, met duizend werkplekken wordt het een ander verhaal.
Dank voor het artikel. Kort, concreet en met bronvermelding, precies wat je wil lezen op een vrijdagmiddag.
Ondertussen wel weer een prima reden om je logging op orde te hebben. Achteraf reconstrueren zonder logs is onbegonnen werk.
Melden bij de toezichthouder is verplicht, maar in de praktijk zie je dat organisaties eerst hun juristen bellen.
Hoeveel van dit soort meldingen krijgen we per week? Op een gegeven moment gaan mensen ze negeren.
Mooi voorbeeld waarom open source niet automatisch veiliger is, maar wel controleerbaarder.
Niet helemaal. De documentatie zegt iets anders, maar de praktijk geeft jou gelijk.
Voor de thuisgebruiker: controleer even je router. Die dingen krijgen zelden vanzelf een update.
Zit hier al een uur naar te kijken. De kern is een ontbrekende inputvalidatie, de rest is ruis.
Backups. Getest. Offline. Blijft het saaiste maar beste advies dat er is.
Aanvullend: De documentatie zegt iets anders, maar de praktijk geeft jou gelijk.
Dat is te kort door de bocht. Ik heb het hier net getest en kan het bevestigen.
Het is te makkelijk om de beheerder de schuld te geven. Als je geen budget en geen tijd krijgt, gebeurt het gewoon niet.
Wat ik hier mis is een fatsoenlijke risicoanalyse. Nu is het weer paniek op basis van één score.
Dank, dat verklaart wel het een en ander. De documentatie zegt iets anders, maar de praktijk geeft jou gelijk.
@hierboven: de leverancier noemt een configuratie-optie als tijdelijke mitigatie, maar dat kost je wel functionaliteit.
Voor wie het zoekt: de release notes staan onder het versienummer van vorige week, niet onder de securitypagina. Slordig.
Blijft bijzonder dat we telemetrie normaal zijn gaan vinden. Uitzetten kan meestal wel, maar het staat nooit standaard uit.
Precies dat. Alert fatigue is een onderschat beveiligingsrisico op zichzelf.
Dat is te kort door de bocht. Bij ons werkte dat namelijk alleen als je ook de bijbehorende dienst herstart.
Wij hebben dit vanochtend gepatcht, downtime was ongeveer tien minuten. Prima te doen als je het voorbereidt.
Enig idee of er ook een workaround is zonder te patchen? We zitten midden in een changefreeze.
Iemand een IoC-lijst gezien? De melding zelf bevat weinig concreets waar je in je SIEM iets mee kan.
Ik draai hier al jaren alles in containers met read-only filesystem. Scheelt enorm bij dit soort meldingen.