Duits ziekenhuis raakte via Citrix-lek besmet met ransomware

De ransomware die de systemen van het Duitse ziekenhuis in Dusseldorf vorige week trof, kon binnenkomen via het Citrix-lek dat eind vorig jaar ontdekt werd. Het ziekenhuis stelt de patch op de dag van de publicatie, in januari, doorgevoerd te hebben.

Volgens het Bundesamt für Sicherheit in der Informationstechnik, of BSI, zijn er meer incidenten waarbij Citrix-systemen al voor de installatie van de beveiligingsupdates in januari 2020 werden gecompromitteerd. De dienst van het Duitse ministerie van Binnenlandse Zaken zegt het niet met zoveel woorden, maar insinueert dat dit aan de hand was bij het Universitair Ziekenhuis Düsseldorf, dat vorige week getroffen werd door ransomware. Als gevolg daarvan moest een in levensgevaar verkerende patiënte uitwijken naar een ander ziekenhuis, waar ze overleed. De Duitse politie onderzoekt de zaak en de invloed van de vertraging van de behandeling.

Het ziekenhuis stelt in december vorig jaar, toen het Citrix-lek aan het licht kwam, de aanwijzingen van de BSI opgevolgd te hebben en de patch op de dag van verschijning geïnstalleerd te hebben. Volgens de BSI kan het dus zijn dat voor die tijd de besmetting plaats vond. Als gevolg daarvan konden aanvallers nog steeds toegang krijgen tot het systeem en de netwerken, zelfs nadat het beveiligingsprobleem verholpen was. "Deze mogelijkheid wordt momenteel in toenemende mate benut om aanvallen op getroffen organisaties te lanceren", aldus de veiligheidsdienst.

De BSI adviseert gebruikers van Citrix Gateway, voorheen NetScalerGateway, en Citrix Application Delivery Controller om hun netwerkinfrastructuur en systemen te controleren op mogelijke afwijkingen en hun beveiligingsmaatregelen daarop af te stemmen. Het ziekenhuis in Dusseldorf meldt dat het afgelopen jaar twee gespecialiseerde bedrijven opdracht had gegeven om het systeem te controleren, maar dat dit geen risico's aan het licht bracht. In de zomer van 2020 was bovendien een externe penetratietest gehouden, waar ook niets uit naar voren kwam. Het lijkt er op dat de criminelen achter de ransomware het op de Heinrich Heine Universiteit in Düsseldorf en niet op het ziekenhuis gemunt hadden.

Reacties (53)

[iDennis3D]

Gaat het hier om het installeren van de patch of het doorvoeren van de workaround. De workaround(21-12) was n.l. al weken voor de uiteindelijk patch(24-01) bekend. (En onderdeel van de Security advisory eind December).

Volgens mij is het algemeen bekend dat wanneer je op 9-1 de workaround nog niet had geïnstalleerd, je er van uit moest gaan dat je systemen gecompromitteerd waren.

Als Citrix echt de oorzaak is, dan hebben de beveiligingsonderzoekers niet naar de filehashes en aanwezige processen op de Citrix appliance gekeken.

[kodak]

Als Citrix echt de oorzaak is, dan hebben de beveiligingsonderzoekers niet naar de filehashes en aanwezige processen op de Citrix appliance gekeken.

Waarom denk je dat?

[SunnieNL]

Omdat anders was ontdekt dat de hackers al binnen waren geweest en er dus andere maatregelen getroffen moesten worden.
Citrix heeft, zoals aangegeven, in december een workaround gegeven. In januari is de patch geleverd met de mededeling dat als je in december de workaround niet had geconfigureerd de patch niet ging helpen en de kans groot was dat de hackers al binnen waren.
Om dat te controleren werd zeer sterk aangeraden om bepaalde scripts te draaien die onderzoeken of de hashes ok waren en er geen vreemde processen draaien.

[kodak]

@iDennis3D heeft het over beveiligingsonderzoekers die iets niet gedaan zouden hebben. Ik lees niet of er wel beveiligingsonderzoekers bij betrokken waren toen een patch of workaround werd toegepast. Hoe kan je ze dan de schuld geven? Maar laten we aannemen dat het wel zo was dan kan je nog niet zomaar zeggen dat die dus niet (of niet goed genoeg) naar filehashes en processen gekeken hebben. Het is niet alsof een crimineel die het hele apparaat onder controle heeft dus geen sporen kan wissen en op die citrix omgeving blijven als het wel erg logisch lijkt dat iemand het zal gaan onderzoeken en er ergens anders in het netwerk ook iets te halen is.

Als het zou gaan om beveiligingsonderzoek nadat het ziekenhuis met ransomware besmet raakte dan is het ook een vreemde conclusie. Die beveiligingsonderzoekers hoeven na maanden niet nog iets aan hashes of processen kunnen vinden op de citrix omgeving als die vorig jaar al het startpunt van verdere besmetting is geweest. Er kan in de tussentijd veel gebeuren.

Het lijkt me dat je je eerst afvraagt wat er wel gedaan is en wat er dan aan de hand was in plaats van maar wat aan te nemen en te beweren.

In die scripts heb ik alleen vertrouwen voor wat ze doen: helpen in een bepaalde situatie, niet alle mogelijke situaties. Handig als ze dus iets vinden maar als ze niets aangeven wil dat niet zeggen dat er niets aan de hand was.

[iDennis3D]

Er staat:

“ Het ziekenhuis in Dusseldorf meldt dat het afgelopen jaar twee gespecialiseerde bedrijven opdracht had gegeven om het systeem te controleren”

Als je de Citrix systemen kent, dan weet je dat je op basis van filehashes ALLE aanpassen kunt controleren en daarnaast niet oorspronkelijke scripts kunt achterhalen. Een filehash is uniek.

Daarmee bedoel ik dat ze geen 100% controle hebben gedaan op aanpassingen. (als Citrix daadwerkelijk de oorzaak is)

[kodak]

Als de crimineel de bestanden kan aanpassen dan kan die waarschijnlijk ook de juiste bestanden weer terug zetten die de juiste filehashes opleveren. Dat is een bekende manier om sporen te proberen te wissen. Die filehashes zeggen dus alleen iets over de onderzochte bestanden op het moment van controleren. Ze zeggen niet of er in de tussentijd de bestanden aangepast zijn geweest en daarna weer vervangen door de juiste bestanden. Als je wil weten wat er in de tussentijd is gebeurt is en of er fouten bij onderzoek zijn gemaakt is het dus echt niet voldoende om alleen maar iets aan te nemen over filehashes of processen.

[Reactie gewijzigd door kodak op 29 juli 2024 12:18]

[narimantos]

Wiens schuld is het in dit geval? De partij die het netwerk onderhoudt van het ziekenhuis?
Of Citrix? Of het ziekenhuis zelf met hun IT personeel? Of het gespecialiseerde bedrijf die niks had gevonden?

[Reactie gewijzigd door narimantos op 29 juli 2024 12:18]

[mjtdevries]

Voor je naar schuld kunt kijken zul je eerst moeten weten wat er gebeurd is.
Dat is hier helemaal niet bekend.

BSI stelt dat ze een aantal keer hebben gezien dat malware actief is geworden lange tijd na de infectie ten tijde van de Citrix kwetsbaarheid.

Maar dat betekent uiteraard niet dat bij elk bedrijf dat Citrix gebruikt en waarbij nu malware vastgesteld die malware er toen op gekomen is. Het kan ook een andere nieuwe kwetsbaarheid zijn in een totaal ander gedeelte van de IT omgeving.
Dat pers bericht van BSI is daardoor ook erg vreemd en ook niet realistisch.

Elke maand komen er patches voor vulnerabilities beschikbaar.
Moet elk bedrijf dan elke maand er vanuit gaan dat ze besmet zijn geraakt voordat ze de patch konden installeren en dure externe bureaus inhuren om te bekijken of er ergens malware geïnstalleerd is?

Zulke grondige onderzoeken doe je alleen als je een grondige reden hebt om te vermoeden dat er malware is binnen geslopen.

[Cergorach]

Zulke grondige onderzoeken doe je alleen als je een grondige reden hebt om te vermoeden dat er malware is binnen geslopen.

Er waren serieuze aanwijzingen dat dit het geval was bij verschillende organisaties, afhankelijk van wat voor type organisatie je bent, dien je vervolgens grondige stappen te ondernemen. Een schildersbedrijf kan het risico nemen, een ziekenhuis absoluut niet!

[mjtdevries]

Waren die aanwijzingen er bij dit ziekenhuis? Ik zie daar helemaal niets over staan.

[Brahiewahiewa]

Als ze, zoals in het artikel staat, de patch op 24 januari 2020 geïnstalleerd hebben dan waren er sterke aanwijzingen dat ze al gehackt waren. Daar is toen ruimschoots voor gewaarschuwd.
En er staat niet in het artikel dat ze toen aanvullende onderzoeken hebben gedaan. Als ik dat ziekenhuis was, had ik dat zeker nadrukkelijk gemeld

[mjtdevries]

Het ziekenhuis in Dusseldorf meldt dat het afgelopen jaar twee gespecialiseerde bedrijven opdracht had gegeven om het systeem te controleren, maar dat dit geen risico's aan het licht bracht.

[harakiri576]

het ict systeem van een ziekenhuis is een mission critical systeem. behandel het zo dus.

[mjtdevries]

Dit is niet hoe je een mission critical systeem behandeld.
Sterker nog, het is onmogelijk om een mission critical systeem zo te behandelen.

Ga nou eens serieus nadenken over wat de consequenties zijn van wat ik heb aangegeven.
Het is absoluut onmogelijk om dat te doen bij elke kritische patch die uit komt!

[mjtdevries]

Je hebt duidelijk totaal niet begrepen wat ik schreef.

maak gebruik van systemen waar er geen kritische lekken zijn dus

Na zo'n antwoord zou ik je eigenlijk moeten negeren.
Als je echt een senior software engineer bent dan ben je gewoon aan het trollen.
ELK systeem heeft kritische lekken. Nu was het Citrix, morgen is het de software systeem die jij gebruikt. (of wellicht die jij geschreven hebt)
Tuurlijk zijn er bedrijven die een slechtere track record hebben, maar ook als je alleen software gebruikt van bedrijven met een goede track record, dan heb je nog steeds regelmatig met kritische lekken te maken.
Uiteraard fix je die zo snel mogelijk, maar JUIST met kritische systemen moet je die goed testen en dat betekent dat er ALTIJD tijd zal zitten tussen het moment dat het lek ontdekt word, het moment dat een patch uit komt en het moment dat je een fix kunt toepassen.

Het is onmogelijk om er dan altijd vanuit te gaan dat je bij elke patch al besmet bent zonder dat je het gemerkt hebt. En dan al je systemen door te gaan op zoek naar mogelijke malware die zich uitstekend kan verbergen.

Hij had jij in gedachten dat je dat ooit kan doen?

Neem daarbij mee dat je al die systemen volledig down moet brengen om een kans te hebben de best verborgen malware te vinden.

Je denkt er veel te makkelijk over.

[harakiri576]

Tja, ik zit heel dichtbij het kampvuur qua software development en security, geloof mij.
En ik zie dat er weinig tot geen aandacht is gegeven aan security, secure programming, of zelfs nadenken of een feature eigenlijk veilig is zoals gedesign'd.

Agile, SCRUM leert om features zo snel mogelijk uit te persen.
Dat is het kompleet tegenoverstelde van secure programming.

DAAROM schrijf ik wat ik schrijf. Het is wel mogelijk om specifiek voor mission critical doeleinden systemen opleveren waarbij security #1 prioriteit is, zelfs over features. Alleen management snapt het niet, users snappen het niet, eigenlijk niemand zou het begrijpen waarom het zo belangrijk is.

Totdat iemand dood gaat vanwege security gatjes!... Totdat een ziekenhuis kompleet shutdown moet gaan omdat er een ransomware is binnengedrongen, en dan natuurlijk betaalt management -ook als het illegaal is- het geld naar deze digitale terroristen.

Zonde...

[Reactie gewijzigd door harakiri576 op 29 juli 2024 12:18]

[Johan Wessels]

Hoofdschuldigen zouden m.i. de criminelen achter de ransomware moeten zijn.
Verder zou er mogelijk nalatigheid kunnen zijn bij IT beheerders / bedrijven, maar zover ik het lees lijkt dat niet het geval.

[junkchaser]

Tja, het is altijd makkelijk om de ITer met de vinger te wijzen, zij voeren uit wat het management beslist heeft: namelijk werken met een technologie die al langer dan vandaag zware veiligheidsrisico's heeft.

[K-aroq]

Het is net zo altijd te makkelijk om altijd het management de schuld te geven. Blijkbaar is de IT afdeling niet capabel genoeg om het belang voor de organisatie aan te tonen. De grootste valkuil is dat veel IT-ers niet kunnen uitleggen aan niet-techneuten wat het probleem is. Je moet gewoon zorgen dat je op managementniveau de impact kunt uitleggen. Je kunt niet verwachten van management dat ze van alle gebieden in de organisatie verstand hebben. Vraag een techneut om een probleem in 3 bullets uit te leggen (wat is er aan de hand, wat is de impact en hoe lost je het op) en er komt meestal een heel wollig verhaal met details die helemaal niet interessant zijn voor de casus. En was het niet Einstein die zei dat als je iets niet simpel kunt uitleggen je de materie niet snapt? Het lijkt me trouwens ook een goed onderwerp voor HBO's en universiteiten om studenten hier op te trainen.

[Reactie gewijzigd door K-aroq op 29 juli 2024 12:18]

[junkchaser]

Het uitleggen doet de IT *manager*, niet de ontwikkelaars. En als je in een Agile omgeving zit zal het team (ook niet it-ers die zich mengen in het project) zich moeten verantwoorden, maar als er niemand een deftige uitleg kan geven, moet men ook even kijken naar het HR management dat er niet veel van bakt om de juiste mensen aan te nemen. Dus nee, ITers kunnen onmogelijk 100% verantwoordelijk gesteld worden voor het geklungel van een bedrijf...

[Reactie gewijzigd door junkchaser op 29 juli 2024 12:18]

[Douweegbertje]

Het enige verschil is dat een IT beheerder nooit die verantwoording kan dragen omdat hij/zij het mandaat daarvoor mist. Dus derhalve is het wel degelijk makkelijk om het bij management te plaatsen. Immers is o.a. het management daarvoor. Net zo goed om dus capabele beheerders aan te nemen / op te leiden / ondersteunen / begeleiden - of op zijn minst zorgdragen dat dit kan/gebeurd.
Het is een mooie pré m.b.t. "Je moet gewoon zorgen dat je op managementniveau de impact kunt uitleggen." maar ik sta er toch wel degelijk zo in dat management zelf moet zorgen dat die impact bekend wordt als het gaat om verantwoordelijkheden.

Uiteindelijk zou het natuurlijk de perfecte wereld zijn als die synergie (ja, pak je bingo-kaart er maar bij) vanzelfsprekend is. Echter als dat niet zo is, dan is het dus wel degelijk aan management om daar verandering in te brengen.

Ik heb ooit bij een werkgever zo'n "grap" gehad. Even tussen neus en lippen door "dan was ik wel verantwoordelijk voor de gehele hosting/infra kant" met bijbehorende garanties richting onze klanten. Ik heb toen gezegd dat dit niet ging gebeuren zonder budget X en mandaat Y en vrijheid Z (om het even kort te houden).

[ajolla]

Als je als IT manager door een IT-er uitgelegd moet krijgen dat als je op datum y een patch uitvoert voor een exploit dat op datum y-1 is gepubliceerd voor een product dat op datum x (met x << y) is uitgebracht, dat er dan y-x tijd is geweest om het systeem te infecteren, ben je niet veel waard.

Als dát kleine beetje wiskunde te moeilijk is moet je geen manager worden.

Deze feiten hadden trouwens ook bij de onderzoekers bekend moeten zijn geweest.

Hebben die soms geen checklists met bekende ransomware en de karakteristieken daarvan?

[Reactie gewijzigd door ajolla op 29 juli 2024 12:18]

[Iconlast]

Het ligt aan de communicatie. Als dat voor mekaar is niets aan de hand, maar goed het is wat je zegt de valkuil ligt bij het uitleggen van verschillende situaties.

[Verwijderd]

Vraag een techneut om een probleem in 3 bullets uit te leggen (wat is er aan de hand, wat is de impact en hoe lost je het op) en er komt meestal een heel wollig verhaal met details die helemaal niet interessant zijn voor de casus.

Andere techneuten snappen het zogenaamde wollige verhaal wel. Aan wie ligt het? De techneut? Of de IT-manager die de situatie als bulletlijst aangeleverd wil krijgen en meenemen, de uitleg niet snapt en vaak ook niet wenst, (laat staan de bulletlijst later uitleggen) maar dat wel aan de directie moet verkopen?

[Cergorach]

BS! Je dient als ITer ook verantwoordelijkheid in je werk te nemen en niet altijd met dat slappe handje richting 'management' wuiven. Ik ga niet zeggen dat je bergen kan verschuiven, maar tenminste zal je zodra de Polizei aan de deur klopt direct in de documentatie en het mailverkeer terug moeten kunnen vinden dat er serieuze adviezen zijn genegeerd en er niets is gedaan met escalaties. Maar een hoop ITers hebben gewoon dergelijk inzicht niet, missen de communicatie vaardigheden of zijn zelf zo laks als de pest!

[junkchaser]

Sorry, maar als je een project als Citrix onder je beheer hebt, dan gaan er al vele alarmbellen af voor er nog maar een release is. Als er dan toch nog iets onvoorzien fout gaat, moet het management zijn verantwoordelijkheid nemen, daar worden ze voor betaald!

[R4gnax]

Verder zou er mogelijk nalatigheid kunnen zijn bij IT beheerders / bedrijven, maar zover ik het lees lijkt dat niet het geval.

Inderdaad; dat lijkt hier niet het geval. Je kunt lezen dat de IT afdeling alles gedaan heeft wat kon om de integriteit van hun systemen te laten valideren. Het is nou niet echt alsof je op de grote rode knop kunt duwen en alles kunt leeggooien en opnieuw kunt beginnen. De dag-tot-dag operatie van het ziekenhuis heeft die systemen gewoon nodig. Je kunt ze gewoon niet langdurig platgooien om alles opnieuw op te gaan bouwen of tot in het extreme uit gaan kammen.

Zoiets zou je alleen kunnen doen als je een omgeving hebt die daar compleet op ingespeeld is met virtualisatie en remote beheer. En dat zal voor veel systemen niet het geval zijn.

[groene henk]

De architecten zou ik zeggen. Vanuit de hele wereld de mogelijkheid hebben om via Netscaler of een ander device naar een netwerk te verbinden, geeft de mogelijkheid als een en patch/work around niet snel wordt aangebracht toegang te krijgen tot het netwerk.

Zero trust concepten maken dit onmogelijk, maar veel bedrijven blijven aan de oude vertrouwde VPN hangen. En daarbij is het niet of dit ooit gehackt wordt, maar wanneer. Zie oa ook de Pulse secure hacks etc.

De meeste bedrijven houden nog aan hun geweldige firewall/muur/perimeter vast maar die heeft veel minder nut bij een cloud first strategy. Daar moet je over nadenken en dat zou een goede architect moeten doen.

[ajolla]

Mijn compliment voor het eerste voorstel dat ik hier zie om dit structureel aan te pakken.
Ondertussen had dit concept ook tot in de IT-opleidingen moeten zijn doorgedrongen.

[En0]

In dit geval is het ziekenhuis de controller van de persoonlijke, of zelfs speciale data aangezien het over een categorie gaat die in art 9 AVG wordt vermeld. Dat betekent dat zij, als eindverantwoordelijke, verantwoordelijk zijn voor het verwerken van de data, en derhalve het lek dat in Citrix zit hen aangerekend wordt. De contractuele aansprakelijkheid tussen het ziekenhuis en Citrix is in dit geval geen zorg voor het data-subject.

[caipirinha]

We moeten eens stoppen met een schuldige ITer of gebruiker te zoeken.
Er is maar één schuldige en dat is de hacker in kwestie.
In plaats van onevenredig veel tijd te steken in beveiliging zou er wat meer aandacht moeten komen voor methodes om deze ratten uit te roken en te arresteren. In aanvulling op een nette beveiliging en back-up routine uiteraard.
Begin maar eens om de eigenaar van de bitcoin wallet op te sporen en langdurig achter de tralies te zetten. Ja dat is lastig maar gezien de schade is dat wel een investering waard.

[junkchaser]

Naar de getroffen partijen die als klant kunnen beschouwd worden lijkt het me logisch dat het ziekenhuis verantwoordelijk is, zij hebben de keuze gemaakt wat zij intern gebruiken om hun winkel draaiende te houden. Het ziekenhuis is op zijn beurt natuurlijk een klant van Citrix, die oplossingen verkoopt waar garanties aan te pas komen. Indien het ziekenhuis aanspraak op deze garanties kan maken en kan aantonen dat er nalatigheid in het spel was, kan deze de claim doorschuiven.
Nu, we weten allemaal wat voor zeef Citrix is en wat voor een slechte trackrecord het heeft ... Keuzes worden meestal niet gemaakt door het IT personeel.

[ALittleTooLate]

zij hebben de keuze gemaakt wat zij intern gebruiken om hun winkel draaiende te houden.

Het is meestal organisch gegroeit. Er wordt doorgebouwd op wat er al is. Dat een lek in citrix het ziekenhuis plat kan leggen was waarschijnlijk nog niet aan de orde toen ze met citrix in zee zijn gegaan vele jaren terug. Achteraf is het makkelijk praten.

Het is ook niet zo dat je zomaar even van citrix naar iets anders overstapt. Daar zit een prijskaartje aan.

[junkchaser]

Dat begrijp ik, maar zoals ik zei, de trackrecord heeft al wel wat negatieve punten. Na het zoveelste probleem moet je ook als management wel het teken aan de wand zien en opnieuw tenderen voor een betere partij, ongeacht het prijskaartje. Dit voorval is de nachtmerrie van elk ziekenhuis... dit is nalatigheid van het ziekenhuis management, maar ook dat van citrix.

[Reactie gewijzigd door junkchaser op 29 juli 2024 12:18]

[ALittleTooLate]

Hoe was het trackrecord in van citrix in 1998 dan? Je kunt nu wel zeggen dat citrix zo lek als een mandje is, maar ook toen ze er mee in zee zijn gegaan?

ongeacht het prijskaartje.

lol. Ze laten hele IC afdelingen met onderbezetting draaien om geld te besparen.

[kodak]

Zelfs als het trackrecord van een product of service in het verleden goed was of goed leek wil dat natuurlijk niet zeggen dat je dat maar als uitgangspunt moet blijven nemen.

Aan de andere kant lees ik niemand duidelijk aangeven waar dan de grens voor een ander zou moeten liggen omdat we als tweakers een mening hebben of een product of service wel of niet aan onze eigen eisen voldoet. En dan zijn die eisen ook niet eens duidelijk gemaakt. Zo is het natuurlijk niet moeilijk om het met elkaar of een ander oneens te zijn.

Maar misschien is de vraag wie verantwoordelijk is simpeler te beantwoorden door eerst eens te beantwoorden over wat voor soort verantwoordelijkheid we het hebben? Maar of je dan tot een antwoord kan komen terwijl er zo weinig bekend is vraag ik me af.

[Kaoh]

Beetje vreemde blame game, waarom vind de BSI dat ze moeten claimen dat het ervoor is gebeurd? Nu klinkt het net alsof het ziekenhuis de schuld krijgt en de ziekenhuis zich moet verdedigen. Kan toch ook via andere ingangen zijn binnen gekomen?

[TheDragonNL]

<offtopic>
Misschien is BSI deels in handen van China?
VS bashen?
</offtopic>

Zonder zekerheid te hebben wat de ingang is geweest kan je dat zeker niet zeggen.
Misschien heeft het te maken met de verzekering en dat het ziekenhuis gedaan heeft wat het moest doen.
Dus dat de verzekering niet kan wijzen met 'je was niet up-to-date'

Wat ik verontrustender vind is dat meerdere externe partijen die ingang niet hebben gezien.
Dit suggereert/impliceert dat deze partijen hun werk niet serieus nemen of onvoldoende kennis in huis hebben

[GoBieN-Be]

Een penetration test zoek nieuwe mogelijkheden om binnen te geraken. Het onderzoekt niet of er reeds bestaande backdoors geplaatst zijn. Die security onderzoeken mogelijks wel.

[Kaoh]

Of het een niet bekende tooling is gebruikt die netjes zich heeft verstopt tot een trigger moment.

[drdelta]

Als je het Duitse artikel leest gaat het voornamelijk hier om:

Systemen die in januari 2020 zijn gepatcht, kunnen echter ook door de exploitatie worden beïnvloed. Deze kunnen al vóór de installatie van de Citrix-beveiligingsupdates zijn gecompromitteerd, waardoor aanvallers nog steeds toegang hebben tot interne netwerken en andere activiteiten kunnen uitvoeren, zoals het extraheren of versleutelen van gevoelige gegevens of het manipuleren of afsluiten van systemen, bedrijfsprocessen en bedrijfsprocedures.

Systemen kunnen wel gepatched worden, maar de "infectie" kan gewoon actief blijven, je moet je hele netwerk doorlichten.

Interessante quote uit het Duitse artikel:

Dit is een van de redenen waarom de Duitse regering in het ontwerp van de Ziekenhuiswet voor de toekomst heeft bepaald dat ten minste 15 procent van de aangevraagde financiering moet worden gebruikt voor maatregelen ter verbetering van de informatiebeveiliging.

Ik raad trouwens DeepL aan om het artikel moeiteloos naar goed leesbaar Nederlands te vertalen.

[kodak]

Of gebruik jij misschien het gebrek aan informatie nu als makkelijk argument om er op los te speculeren wat de bedoelingen van de BSI zouden zijn? De informatie die je wel hebt is niet naar je zin dus ga je meteen maar afgeven op de BSI zonder zelf met genoeg bewijs te komen?

[Aaargh!]

het Universitair Ziekenhuis Düsseldorf, dat vorige week getroffen werd door ransomware. Als gevolg daarvan moest een in levensgevaar verkerende patiënte uitwijken naar een ander ziekenhuis, waar ze overleed.

Ik snap even niet waarom deze patiënte moest uitwijken naar een ander ziekenhuis vanwege een ransomware aanval op het netwerk. Ik neem aan dat kritieke medische apparatuur niet zomaar aan het 'desktop' netwerk hangt en dus gewoon heeft gewerkt. Of anders gezegd: als het functioneren van het netwerk essentieel is voor de werking van apparatuur die nodig is voor het uitvoeren van kritieke medische handelingen, dan zou je verwachten dat het gehele netwerk aan dezelfde zeer strenge eisen moet voldoen als de apparatuur zelf.

Moest deze mevrouw dus uitwijken omdat het echt fysiek onmogelijk was haar te helpen, of omdat het door de storing niet mogelijk was de administratie bij te houden en dus de behandeling te kunnen factureren ?

[nextware]

Vermoedelijk is de ambulance uitgeweken omdat de medische gegevens van deze patiënt niet geraadpleegd konden worden. Als het ZIS van een ziekenhuis niet werkt, kunnen de historische gegevens niet geraadpleegd worden en kan de patiënt niet behandeld worden. Je weet namelijk dan niks van de patiënt en dat kan levensgevaarlijk zijn (allergieën, etc..)

Let op: mijn EIGEN vermoedens

[Reactie gewijzigd door nextware op 29 juli 2024 12:18]

[Verwijderd]

Het is standaard procedure om het ziekenhuis is lockdown te zetten wanneer er een core netwerk onderdeel uitvalt als VDI’s, file servers, EPD systemen of simpelweg telefonie. Alle inkomende noodgevallen worden dan onmiddellijk door gerouteerd naar een ander ziekenhuis tot de impact van de storing bepaald is en men weet wanneer men weer online is.

Het klinkt hard maar in een ziekenhuis worden geen risico’s gelopen. Daar krijg je alleen maar rechtszaken van.

Maar goed, de mensen die daar werken doen er ook alles aan om te voorkomen dat dat gebeurd

[JonPalle]

Beetje rare post. Je mag aannemen dat het ziekenhuis professioneel werkt en dat niet ter meerdere eer en glorie van het halen van een dagbladartikel een dergelijke actie wordt ondernomen. Wat het ook was, er was een reden voor. Blijft wel dat het probleem van ransomware steeds groter wordt en langzaam doordringt in de haarvaten van de maatschappij.

[Aaargh!]

Je mag aannemen dat het ziekenhuis professioneel werkt

Blijkbaar niet, want anders waren ze nooit slachtoffer geworden van een ransomware aanval.

Het is sowieso dubieus dat zoiets een heel netwerk plat kan leggen. Een normale user zou niet dusdanig vergaande toegang tot systemen mogen hebben dat ransomware zich buiten z'n eigen machine kan verspreiden. Het handjevol mensen dat wel deze rechten heeft zou beter moeten weten, en sowieso nauwelijks gebruik moeten maken van zulke vergaande toegang.

[Armselig]

Ik klik het net weg op Nos: https://nos.nl/artikel/23...aanval-op-ziekenhuis.html

[Opteronx4]

Blijft bezopen dat men kritieke systemen op internet aansluiten