Profiel van tmuxer
Laatste reacties van tmuxer
Blijft bijzonder dat we telemetrie normaal zijn gaan vinden. Uitzetten kan meestal wel, maar het staat nooit standaard uit. Maar goed, dat terzijde.
Wij hebben dit vanochtend gepatcht, downtime was ongeveer tien minuten. Prima te doen als je het voorbereidt. Wordt vast vervolgd.
Ik heb de betreffende dienst maar uitgezet. Functionaliteit die je niet gebruikt is functionaliteit die je niet hoeft te patchen.
CVSS 9.8 en dan geen automatische update. Dat is in 2026 echt niet meer uit te leggen aan je klanten.
Ik hou mijn hart vast voor al die kleine bedrijven zonder ict-afdeling. Die lezen dit soort berichten nooit.
Dank, dat verklaart wel het een en ander. Bij ons werkte dat namelijk alleen als je ook de bijbehorende dienst herstart.
Kan iemand uitleggen waarom hier authenticatie ontbreekt? Dat is toch geen ontwerpfout van gisteren.
Ik hou mijn hart vast voor al die kleine bedrijven zonder ict-afdeling. Die lezen dit soort berichten nooit.
Melden bij de toezichthouder is verplicht, maar in de praktijk zie je dat organisaties eerst hun juristen bellen.
90 dagen bewaartermijn voor logs is echt het minimum. Bij een gemiddelde inbraak zit je daar zo overheen.
Changelog lezen blijft nuttig, er zit vaak meer in dan de aankondiging zegt.
Ik zou toch echt eerst willen weten of er data is weggesluisd voordat ik zeg dat het meevalt.
Weer een dinsdag, weer een patchronde. Bij ons gaat dit gelukkig automatisch.
Zit hier al een uur naar te kijken. De kern is een ontbrekende inputvalidatie, de rest is ruis.
Dank, dat verklaart wel het een en ander. Zolang het budget bij een andere afdeling ligt, verandert er niets aan.
Fijn dat de details pas later komen, dat geeft beheerders even lucht.
Dank, dat verklaart wel het een en ander. Daar zit hem nu net de crux: wie is er eigenaar van dat systeem?
Een mislukte netwerkwijziging. Dat is bijna altijd het antwoord.
Weer een update die je binnen 24 uur uitgerold moet hebben. Bij ons draait de patchcyclus op maandag, dus dat wordt handmatig ingrijpen.
Het is te makkelijk om de beheerder de schuld te geven. Als je geen budget en geen tijd krijgt, gebeurt het gewoon niet.
Er is een verschil tussen 'geen bewijs van misbruik' en 'geen misbruik'. Dat wordt structureel door elkaar gehaald.
Zolang leveranciers geen SBOM meeleveren blijft dit dweilen met de kraan open. Je weet gewoon niet wat er in dat ding zit.
Vraag me af of de AVG hier ook een rol speelt. Er zijn duidelijk persoonsgegevens mee gemoeid.
Changelog lezen blijft nuttig, er zit vaak meer in dan de aankondiging zegt.
Geen MFA op een account met die rechten. Daar begint het altijd.
Netjes dat ze gewacht hebben met publiceren tot er een fix was.
Mooi voorbeeld waarom open source niet automatisch veiliger is, maar wel controleerbaarder.
Nog steeds geen verplichte meldplicht met sancties voor dit soort trage patches. Zonder pijn verandert er niets.
Eens, met een kanttekening: Daar zit hem nu net de crux: wie is er eigenaar van dat systeem?
Dit is precies waarom segmentatie zo belangrijk is. Eén lek betekent dan niet meteen het hele netwerk.
Automatisch aanbieden is prima, zolang je maar kunt terugrollen.
Een mislukte netwerkwijziging. Dat is bijna altijd het antwoord.
Dat is te kort door de bocht. Het hangt sterk af van je configuratie. Standaard staat die optie namelijk uit.
Eens, met een kanttekening: Daar zit hem nu net de crux: wie is er eigenaar van dat systeem?
Precies dit. Formeel klopt het, praktisch schiet je er weinig mee op.
Eerder gewaarschuwd en toch doorgegaan. Dan is dit terecht.
Interessant dat het lek al maanden bekend was bij de leverancier. Responsible disclosure werkt alleen als de andere kant ook meewerkt.
Ondertussen wel weer een prima reden om je logging op orde te hebben. Achteraf reconstrueren zonder logs is onbegonnen werk.
Apparatuur die nog prima werkt maar geen updates meer krijgt, is gewoon elektronisch afval maken.
Tegen de tijd dat de gemiddelde organisatie dit heeft opgepakt, is er alweer een nieuwe versie met een nieuw lek.