Ik denk niet de IT cultuur, maar de managementcultuur die niet genoeg personeel heeft aangenomen
om ook dit soort dingen in de gaten te houden. Brandjes blussen en doorgaan.

In principe zouden dergelijke systemen gewoon zelf critical updates moeten downloaden en uitvoeren, om te voorkomen dat
beheerders en managers het uitstellen of helemaal niet doen. Je hebt zo'n systeem met een vet updatecontract eraan
en dan moet je nog zelf de boel updaten, dat werkt gewoon niet.

Ik noem dit "het Equifax syndroom". Er is sprake van een lek dat aanvankelijk door de producent, leverancier en partijen als het Nederlandse NCSC nog niet als "kritiek" wordt bestempeld, wellicht met de intentie om geen kwaadwillenden wakker te schudden. Gevolg: binnen organisaties krijgt een systeembeheerder onderaan de keten de opdracht om nog een paar dagen aan te zien of de patch bij anderen geen problemen oplevert, en dan te patchen. Die man of vrouw is al overbelast (wordt voortdurend gebeld voor allerlei andere issues) of wordt ziek of neemt een vrije dag - en vergeet de patch uit te voeren.

Dit is m.i. NIET de schuld van die individuele beheerder, maar van leidinggevenden (en uiteindelijk de bedrijfsleiding) die geen systeem hebben opgezet om die risico's van dit soort kwetsbaarbaarheden goed in te schatten en op te blijven volgen totdat het risico voldoende is gemitigeerd. En als dat niet kan, voldoende verantwoordelijkheidsgevoel, lef en mandaat hebben om een dienst uit te zetten tot een fix is gerealiseerd - natuurlijk iets dat je niet aan die beheerder kunt en mag overlaten.

Aanvulling: het kan ook zijn dat "handige Harry", buiten het asset-management om, zelf iets heeft "geregeld" en ondertussen een andere baan heeft gevonden. N.a.v. een recent artikel van Xavier Mertens in https://isc.sans.edu/forums/diary/Huge+Amount+of+remotewebaccesscom+Sites+Found+in+Certificate+Transparency+Logs/25352/ heb ik even gegoogled en vond binnen de kortste keren een webtoegang voor een iDRAC controller die kwetsbaar lijkt voor CVE-2019-3705 (CVSS: 10.0). Het zou hierbij natuurlijk om een honeypot kunnen gaan...

Grotendeels eens met @Erik van Straten, het zijn echter de individuele beheerders die afgerekend worden op een high prio incident.

In dit specifieke geval:
Vaak ontbreekt het aan een test infrastructuur om juist dit soort essentiële verbindingen te kunnen testen. Op applicatie niveau is er vaak wel een acceptatie omgeving maar juist een test/acceptatie infrastructuur ontbreekt meestal. Het tenslotte maar infra ;)

Alleen patchen gaat niet werken, want het overzicht waar het aan schoort ontbreekt vaak. Vanwege een gebrek aan tijd en inzicht. Het onderliggende probleem is ook, denk ik, dat door de Nederlandse traditie van eindeloos overleggen en voorlichten de NCSC is opgetuigd als een papieren tijger. Dat gaat niet werken, zeker niet in een geglobaliseerde netwerkwereld, waarin Chinese staatshackers zo even bij je kritieke netwerken naar binnen kunnen wandelen.

Zo verdedig je geen land.

Citaat uit het aangehaalde Volkskrant artikel:


Dat moet die wettelijke bevoegheid er dus maar komen. Verzaken om de nodige acties tijdig en adequaat te ondernemen, gegeven een middels CVEs gepubliceerde kritieke kwetsbaarheid, zou voor de individuele directieleden van mission critical ICT infrastructuur in de gehele EU strafbaar gesteld moeten worden. Veel incapabele baantjesjagers in ICT directies komen nu nog te vaak makkelijk weg met achterstallig onderhoud of met een verkeerde aanpak van zaken.

Ook critical updates kunnen een pc om zeep helpen en moeten in een bedrijf eerst getest worden. Wel vind ik dat ICT managers zich wat critical updates betreft niet aan een maandelijks patch schema moeten houden zoals ze van Microsoft geleerd hebben maar tussendoor critical updates testen en uitrollen.

Dit gaat niet over een PC, dit gaat over een VPN concentrator.
(ok fysiek zal het best een PC zijn maar het is dus niet een standaard PC met tientallen applicaties waar je iedere hotfix
moet testen op compatibiliteit met de lokale situatie)

Zo'n VPN concentrator draait gewoon een standaard set software met configuratie erop die wellicht wat kan wisselen,
maar toch in een bepaald stramien zit wat overal grotendeels gelijk is.
De kans dat er iets om zeep geholpen wordt door een hotfix van de fabrikant die een security probleem oplost is klein.

De kans op problemen wordt wellicht wat groter als je al lang niet geupdate hebt en de fabrikant de software alleen in
de current version fixed, waardoor je nu ineens een flinke update sprong moet maken.
Dat soort problemen wordt nou juist verkomen als dit soort devices zichzelf updaten.

Voor wie de diepte in wil:

https://youtu.be/mKGq8z17Kd4

Zou de overheid dit soort bedrijven niet moeten verplichten om, hun kritische infra, op een gesloten netwerk aan te sluiten?

Vaak is het probleem complexer dan het lijkt, jullie kijken er met een security bril naar en zien alleen security issues. Een normale systeembeheerder is (hoop ik) op de hoogte van dat patchen noodzakkelijk.

Hebben jullie je weleens afgevraagd wat er in een productie omgeving misgaan bij het patchen?
Argumenten die mensen hier opnoemen over dat de ICT staff van grote bedrijven onkundig zouden dan wel onderbezet..., waarop baseren jullie dit?

Daar staat "Een woordvoerder zegt dat de kwetsbaarheid ‘bij ons geruime tijd bekend’ is. ‘De bijbehorende risico’s zijn in kaart gebracht en er zijn passende maatregelen genomen.’ Waaruit die maatregelen bestaan, wil de woordvoerder niet toelichten."

Er is blijkbaar een risicoanalyse gedaan en men vond het niet nodig om de patch te installeren? Wie zal het zeggen? Mogelijk is het risico met die andere, passende maatregelen uitgesloten of geminimaliseerd. Bij een infrastructuur die dermate log is dat het eenvoudige installeren van een patch al teveel is moet je je afvragen of je wel op de goede manier bezig bent. IMHO.

Dat is damage control, vooral naar buiten brengen dat je maatregelen getroffen hebt die door niemand te controleren zijn.

Naar verluidt is ncsc.nl mogelijk al eerder (voor of eveneens op 24 augustus) door een andere partij gewaarschuwd. Uit https://badpackets.net/over-14500-pulse-secure-vpn-endpoints-vulnerable-to-cve-2019-11510/:

Exploit is al ongeveer 1 maand publiek beschikbaar, zonder dat je daar het darknet voor op hoeft: https://github.com/projectzeroindia/CVE-2019-11510/blob/master/README.md, en PoC sinds 22 augustus: https://github.com/imjdl/CVE-2019-11510-poc/blob/master/poc.py.

Uitvoerige beschrijving van de kwetsbaarheden: https://devco.re/blog/2019/09/02/attacking-ssl-vpn-part-3-the-golden-Pulse-Secure-ssl-vpn-rce-chain-with-Twitter-as-case-study/.

Al een maand geleden bekend https://www.security.nl/posting/622758/Nederlandse+bedrijven+kwetsbaar+door+ongepatchte+vpn-software

"Hacken door staatshackers", dit is het niveau van het discours in wat dan een kwaliteitskrant heet te zijn. Overigens net zo goed in het wereldje zelf, met meer (en ingewikkeldere) bangmaaktermen er nog extra bij. Wat het niet minder tot een probleem maakt.

Hoe dan ook, patchen is werk, zeker omdat software op de gekste plekken zit tegenwoordig en daar vaak helemaal niet open over is, het de aanpassingen doorvoeren blijft toch een soort roeren in koffiedik, en je kan er zomaar ineens je "mission critical"-systemen mee om zeep helpen. "Damned if you do, damned if you don't." Allicht dat het geen favoriete bezigheid is, zelfs al heb je er verstand van. Wat de meeste beslissers (middle management) niet hebben.

Nu, als huiswerk: Vergelijk deze manier van naar patchen kijken met hoe dat zich verhoudt tot de "algemene wijsheid" dat patchen "gewoon moet". Beide manieren proberen practisch te zijn, beide manieren hebben zo hun makkes. Welke? Compare and contrast.

Op ervaring.

We hebben het over een VPN met server - router verbindingen, juist omdat het geheel van een keten met afhankelijkheden bestaat is er de angst dat als je wat doet van alles omvalt. Beleid van hogerhand … geen veranderingen ook geen patches.

Het hele idee van een "patch", oftewel een pleister, is dat de release zelf hetzelfde blijft. Dat je dus zeker bent dat er niet ineens van alles ook gewijzigd is.

Een patch corrigeert een klein foutje. En laat de rest precies zoals het was.

Met een update, of een geheel nieuwe release mag je hopen dat alle wijzigingen en bugfixes netjes in de update- of release notes staan. Want anders kun je tegen onverwachte verrassingen aanlopen.

Ik denk dat software makers soms niet meer goed weten wat een patch is (en het dus maar een stoere naam geven), en menig systeembezweerder, ook bij de KLM en de Shell, het verschil nog minder kent.

Een patch is gewoon een bugfix pleister, die je kunt plakken, testen, maar ook gewoon weer weg kunt halen. En dan heb je je originele software weer zonder dat je backups moet gaan zoeken.

Dan heb je dus slechte ervaringen, dat is mogelijkm, maar dat wil niet zetten dat dit overal is. Ik namelijk ook het tegenovergestelde langs komen.
Onderbezetting is wel altijd een lastige. dat moet ik toegeven. .

Dat er een kwetsbaarheid aan ons bekend is wil niet zeggen dat het ook bekend is bij de juiste persoon in de getroffen organisaties. De hoeveelheid advisories die op je af komt is fenomenaal. En dan publiceren sommige bedrijven (zoals bv HP/Aruba) niet eens security advisories, of maken ze niet publiekelijk beschikbaar. Dan moet je ook nog weten dat je de getroffen spullen in je bedrijf hebt zitten. En zeker bij grote toko's is dit niet mogelijk.

Overigens vind ik de opstelling van NCSC wat beperkt. Het is alsof de douane tegen bedrijven zegt "Wij zien hier geplagieerde spullen het land binnenkomen, we hebben het gemeld, bedrijf zoek je het zelf even uit". Of de politie: "We zien hier deze inbrekerd, bedrijf let op dat je je goed beveiligd hebt!". Integendeel, deze instanties nemen wel zelf actie om de bedrijven te beschermen.

Opnieuw nog meer slecht nieuws van het VPN-front, en ook ditmaal is dit bijzonder schokkend:


https://nos.nl/artikel/2303866-opnieuw-groot-risico-door-beveiligingslek-bij-thuiswerksysteem.html

Onderstaand, de bewuste Reporter Radio uitzending (zondag 19:00 - 20:00 uur) door presentator Niels Heithuis, in samenwerking met Dave Maasland van IT-beveiligingsbedrijf ESET Nederland over het lek in de Fortigate-VPN.

De afgelopen weken wordt de kwetsbaarheid bij de Fortigate-VPN wereldwijd op grote schaal misbruikt, zo valt volgens Reporter Radio op te maken uit gemonitorde activiteit op internet.

https://www.nporadio1.nl/reporter-radio/onderwerpen/514775-lek-thuiswerk-inlog-duurt-voort-bij-andere-aanbieder

De doelgroep die door het NCSC.nl wordt gewaarschuwd (na de melding van Reporter Radio bij het NCSC) is de Rijksoverheid en ICT-intensive organisaties in de zogenoemde vitale infrastructuur van Nederland.

Volgens Maasland zijn overigens ook MKB bedrijven (die veel voorkomen in de lijst) extra kwetsbaar, "omdat uit de praktijk blijkt dat deze bedrijven hun ICT-beveiliging helemaal niet goed op orde hebben".

Ik wou dat ik wat helderder van geest was om deze berichten dagelijks te kunnen volgen. Er is veel aan de hand in de ICT cybersec wereld en het wordt allemaal nog veel relevanter met de geopolitieke toestanden. Er moet meer getest worden (iemand zei al fuzers, linters, debugging in een ander topic) en ook betere regelgeving.

Veiligheidsproblemen los je op door betere ICT oplossingen. Maar half Nederland staart naar een mobieltje en heeft 's avonds nog het blauwe licht aan en slaapt daardoor niet goed met alle schade van dien de volgende dag. Niet meer bij de les zijn. Soms bedenk je de beste oplossingen ergens in de natuur ver van alles af. En dan ga je pas naar je lab als je alles op een rijtje hebt. Verre van een ideale situatie. Er is al veel goeds geregeld maar het kan nog beter. Niet iedereen ziet het. De problemen sluipen meestal als eerste binnen op de consumentenmarkt, via de gadgets afdeling, of IP cams.

De opstelling is beperkt omdat hun taak beperkt is. Politie en douane zijn handhavers, het NCSC is een kenniscentrum. Ze mogen domweg het soort dingen niet dat politie en douane wel mogen, en ze hebben hun organisatie natuurlijk niet ingericht voor taken die ze niet mogen uitvoeren.

Het probleem is vaak dat zo'n fabrikant in de loop der tijd steeds nieuwe versies uitbrengt, met nieuwe functionaliteiten
en soms ook met verwijderen van oude functionaliteiten, en dat het bedrijf daar wellicht niet mee in de pas is blijven
lopen. M.a.w. men draait nog op een oude versie, 5 stappen terug in wat nu de huidige versie is.
Als je pech hebt (ik weet niet hoe het in dit geval zit) brengt de fabrikant geen patches uit voor al die oude versies, maar
alleen voor de huidige versie of de laatste N versies.
Om de patch aan te brengen moet je dan eerst upgraden, en dat introduceert wellicht problemen.

Dat zou een issue kunnen zijn, maar ik kan me niet voorstellen dat dat bij al die honderden bedrijven het probleem is.
De meesten hebben ongetwijfeld niks gedaan uit laksheid ("het waait wel over") of tijd/deskundigheid gebrek.

Dat laatste daar kan de fabrikant ook weer een oorzaak van zijn, want als de betreffende apparatuur geen simpele
actie voor het aanbrengen van patches en het terug gaan naar de vorige situatie heeft, dan maakt dat de beheerders
angstig en/of kost het hen een hoop tijd om er allemaal weer in te duiken.
Het beste is als de apparatuur een setting kent om critical patches automatisch aan te brengen of anders tenminste
toch om te kunnen patchen met een simpel command of klik in de webinterface.
Er lopen hier ongetwijfeld veel wereldvreemde gasten rond die dat allemaal maar overbodig vinden en die vinden dat
de beheerder alles moet weten en voor altijd onthouden, maar de praktijk is weerbarstiger.


Dat zou moeten, maar wellicht heeft niet ieder apparaat wat firmware gebruikt de feature van meerdere versies waar
je op terug kunt vallen of patches die je kunt verwijderen.
Dit is wel een goed leermoment voor zo iets: let daar op als je wat koopt.
- hoe is het onderhoud van de software geregeld
- kun je iets installeren en dan snel terugdraaien bij problemen
- krijg je patches zelf aangeleverd (dan wel kun je ze downloaden) of zit daar een moeilijk mechanisme omheen met
supportcontracten, accounts die je daar voor moet hebben en die zoek kunnen raken, etc.

Het lukraak installeren van ongeteste patches levert in de praktijk meer problemen op dan dat niet doen. Zeker bij dit soort grote partijen horen beheerders ze gewoon netjes bij te houden.

@Anoniem gisteren 20190929 21:44: dank voor het melden! Inderdaad zijn ca. gelijkertijd (maart/april 2019) ook kwetsbaarheden gepatched in Fortinet's SSL-VPN server.

Voor degenen die stellen dat je altijd meteen zou moeten patchen (of sterker, dat dit onmiddelijk automatisch zou moeten gebeuren), zie de discussie vanaf https://tweakers.net/nieuws/157932/ook-lek-in-fortigate-vpn-maakt-netwerken-nederlandse-bedrijven-kwetsbaar.html?showReaction=13485046#r_13485046.

In dezelfde periode zijn ook patches voor kwetsbaarheden in Palo Alto VPN software verschenen; het zou mij verbazen als de situatie bij gebruikers van VPN's dat merk er veel rooskleuriger uit zou zien.

Nb. In zijn blog hierover (https://blog.cyberwar.nl/2019/09/dutch-kwetsbare-pulse-connect-secure-ssl-vpn-in-nederlandse-ip-adresruimte-bevindingen-en-gedachten/) waarschuwt Matthijs Koot: en voegt een link toe met meer info.

Ik hoop dat de AP (Autoriteit Persoonsgegevens) de informatie opvraagt welke organisaties het betreft, en verder gaat dan slechts waarschuwen als blijkt dat er persoonsgegevens zijn gelekt.

Feitelijk denk ik dat de AP over een soort "cyberpolitie" zou moeten beschikken, die al handhaaft als organisaties die beschikken over persoonsgegevens beschikken, risicovol omspringen met potentiëel onbevoegde toegang tot die informatie (het spreekwoord "voorkomen is beter dan genezen" gaat hier niet eens op, want op internet gelekte gegevens zijn ongeneeslijk).

Er zijn ongetwijfeld ook organisaties die niet of nauwelijks over persoonsgevoelige informatie beschikken, maar wel van landsbelang zijn (kritische infrastructuren bijvoorbeeld) en die via publieke netwerken te bereiken zijn. Die "cyberpolitie" zou daarom wellicht niet voor 100% onder de AP moeten vallen.

Tenzij ze hiervoor juridisch mandaat krijgen. Maar dat moet de politiek regelen.

Datalekken gaat over meer dan enkel persoonsgegevens. Gaat ook om intellectueel eigendom van bedrijven, en commerciele belangen. Ik denk niet dat persoonsgegevens bijvoorbeeld het belangrijkste doelwit zijn, indien bedrijven als Shell worden aangevallen. Verder moeten die bedrijven ook nadenken over hun eigen belang, en de risico's die ze nemen.

Wanneer er persoonsgegevens van derden in het spel zijn, heb je natuurlijk volstrekt gelijk.

Dat argument mag in de doos waarin ook "ethernet poorten moet je op fixed speed en duplexmode zetten want
autonegotiate dat werkt niet altijd goed" gedaan worden.
(afserveren noemt een andere poster hier dat geloof ik)

Waar het o.a. mis gaat:
1) Het aantal patches dat uitkomt voor de in gebruik zijnde software/firmware een gemiddeld bedrijf is enorm.
2) Software wordt standaard met bugs uitgeleverd omdat uitgebreid testen hierop kostbaar is. Gebruikers zijn hierdoor de testers geworden en bugs worden pas achteraf gerepareerd.
3) Het is nog altijd problematisch om software updates zonder herstarten of andere interrupties te installeren.

Dat is een feit en geen excuus om het defecte slot van de personeelsingang niet te repareren (de VPN-software bedoel ik).

Ofwel je hebt jouw infrastructuur te complex laten worden (alles dat met "V" begint heeft dit probleem bij velen enorm vergroot), ofwel je hebt onvoldoende kundig personeel om die infrastructuur verantwoord te kunnen managen.

Ofwel je hebt "goedkope" software gekocht die, zoals je zelf aangeeft, onvoldoende is getest, ofwel je hebt prijzige software gekocht en hebt geen boeteclausule bedongen voor na levering gevonden bugs en/of kwetsbaarheden (die jou kennelijk voor een onmogelijke opgave stellen als deze optreden, zoals je aangeeft in punt 3).

Laat de leveranciers-/personeelsingang dan maar 24/7 open laten staan en hopen/bidden dat insluipers niet te veel schade aanrichten?

Recente voorbeelden van schade waarvan ik niet uitsluit dat deze via ongepatchte VPN-software kon ontstaan:
1) Imagoschade voor Asics: https://www.nu.nl/opmerkelijk/6000525/tv-schermen-in-nieuw-zeelandse-sportwinkel-tonen-urenlang-porno.html
2) Miljoenenschade voor Rheinmetall: https://www.bleepingcomputer.com/news/security/cyber-attacks-hit-defense-contractors-in-europe-and-north-america/

Automatisch installeren op Schiphol bv? Je komt net terug van je vakantie met Thomas Cook, de piloot heeft de landing ingezet, en net op dat moment gaat het systeem van de verkeersleiding 'even' rebooten? Diegene die zulke ideeen heeft hoort niet thuis in dit vak. OT is geen IT, ga gewoon achter je PC thuis zitten. Hemeltje.

Liever automatisch installeren met een minuutje downtime dan dat het na een half jaar nog steeds niet gepatched is en
open staat voor iedere hacker die er maar in wil!
"we moeten het eerst testen", leuk kletsverhaaltje als dat dan vervolgens helemaal niet gebeurt.
En die verkeersleider zit vast niet via een VPN ingelogd.

Een minuutje downtime? Hoeveel seconden passen er bij jou in een minuut. Good gruts, wat een totaal gebrek aan ervaring met dit onderwerp. Bovendien gaat het niet enkel om de reboot, applicaties moeten ook weer herstarten mogelijk Ja ik weet dat zou niet perse nodig hoeven te zijn, maar...

Het woord dat je zoekt is fantaseren, want jouw voorbeeld is uit de lucht gegrepen. In tegenstelling tot patches die problemen veroorzaken. Wie het nieuws ook maar oppervlakkig volgt weet dat dat regelmatig voorkomt.

https://lmgtfy.com/?q=patch+breaks+windows

Kwaliteits software... Windows... Iemand?

Maar goed... patches zijn hoe dan ook ellende. Automatisch is een enorm risico - komt de boel weer op? En hoe goed vertrouw ik de server van mijn leverancier (en het pad daarheen)? 'Paar dagen wachten' is niet zo'n verkeerde strategie.
De kern van het probleem is dat alles tegenwoordig maar aan internet moet hangen. Want dat is zo makkelijk.

Het systeem van een luchtverkeersleiding hoort helemaal niet aan internet te hangen. Ook niet via een VPN. Probleem (in elk geval dit probleem...) opgelost. Maar ja, het was zo makkelijk...

Toch bijzonder... Dat we hier enorme [performance problemen mee gehad hebben.

Nadat we juist dit geconfigureerd hadden, was alles opgelost. Dus soms moet je toch echt een doos openmaken om te kijken wat er in zit

Beide is zo fout als het maar kan.

Je moet (security) implementeren, maar wel gecontroleerd.

Hou toch op over Windows mensen! Dit GAAT helemaal niet over Windows! Dit is een VPN concentrator.

+1 maar ook PO's stoppen patching niet op hun backlog want geld verdienen > geld verliezen door schade en schande
Daarnaast zie ik ook weinig gebeuren op auto patching gebied..probeer zo veel mogelijk weg te automatiseren, genoeg mooie tools voor.