'Datalek zorgbedrijf VS mogelijk gemaakt via gestolen Citrix-login'

Het datalek bij het Amerikaanse zorgbedrijf Change Healthcare kon plaatsvinden door gestolen inloggegevens voor een Citrix-portaal. Dat zegt Andrew Witty, ceo van moederbedrijf UnitedHealth, in een rechtszaak over het incident.

Change Healthcare verwerkt verzekeringen, facturen en declaraties voor honderdduizenden ziekenhuizen, apotheken en andere zorgorganisaties in de VS. In februari werd het bedrijf het slachtoffer van een ransomwareaanval, met grote gevolgen voor de Amerikaanse gezondheidszorg. UnitedHealth betaalde vervolgens losgeld om te voorkomen dat gestolen patiëntgegevens zouden uitlekken.

Witty vertelt nu in een rechtszaak dat cybercriminelen van de BlackCat-ransomwaregroep al ruim een week in de systemen van Change Healthcare zaten voordat de ransomwareaanval op 21 februari werd uitgevoerd. Aanvallers kregen begin die maand de inloggegevens van een werknemer voor het Citrix-portaal in handen. Dat portaal wordt gebruikt om op afstand te kunnen werken. Op 8 februari detecteerde het threat intelligence-platform dat Change Healthcare gebruikt, dat die inloggegevens via malware gestolen werden, schrijft BleepingComputer.

Witty geeft toe dat het portaal geen tweestapsverificatie vereiste. Met de inloggegevens kon de aanvaller dus binnenkomen. Op 12 februari drong de ransomwaregroep binnen in het Citrix-portaal. Daarna wisten de aanvallers zich door het netwerk heen te bewegen en zowel bedrijfs- als patiëntgegevens te stelen.

Na de aanval werden duizenden laptops vervangen en zijn inloggegevens aangepast. Ook zijn het datacenternetwerk en kerndiensten in een paar weken opnieuw opgebouwd. De aanval heeft UnitedHealth uiteindelijk 872 miljoen dollar gekost.

Reacties (22)

[The GUI]

Witty geeft toe dat het portaal geen tweestapsverificatie vereiste.

Tsja, daar ga je…

[boxlessness]

En dan nog heb je geen garantie dat er ingebroken wordt. 2FA-moeheid is een ding, en door iedere keer weer door die hoepel heen te moeten kan een verkeerde 2FA request toch geauthoriseerd worden omdat de gebruiker even niet op let.

Wat betreft security mindset is het veel beter om er van uit te gaat er er OOIT een keer een voordeur opgebroken gaat worden. De schade kun je dan beperken door je achterliggende verdedigingen en contingency-mechanismen op orde te hebben.

Dit is ook een van de redenen dat ik geen fan ben van Single SignOn (SSO): je koppelt alle authorisatie aan één login. Dus een enkele breach kan meteen grote gevolgen hebben.
Door meerdere logins/systemen te hebben beperk je de impact van een breach. Nadeel is weer dat je je attack-surface vergroot, want al die subsystemen moeten up-to-date gehouden worden en hebben hun eigen exploits.

Helaas is security een balans tussen werkbaarheid/efficientie/menselijke-factor en hoe dichtgetimmerd zit je systeem.

[sapphire]

En een nadeel van geen SSO is waar je zelf mee begon 2FA moeheid

Mijn SSO heeft er op werk een tijdje uit gelegen en 12x moeten inloggen en 2FA's doen voor je kan beginnen is behoorlijk irritant en dat zeg ik als groot fan van MFA.

Sowieso ben ik het met de rest van je post eens hoor, je kan er beter van uit gaan dat het eens mis gaat en naast een goede voordeur + beveiliging én ook rekening houden met als de voordeur ongeautoriseerd opengaat.
En over 2FA moeheid, zelf erg blij met methode die je als gebruiker actief een link laten legen tussen een applicatie die 2FA vraagt en de gebruikte app. Dus Applicatie X geeft een popup met een getal/teken/iets en dat moet je invoeren in bv een authenticator app. dan weet je welke programma toegang vraagt. We hebben een tijde gehad dat je een melding kreeg en moest goedkeuren, hoeveel collega's ik tijdens de koffiepauze een random melding goed heb zien keuren zonder te weten waarvoor het was
En het belang er van op een rustige en nette manier uitleggen scheelt ook enorm veel heb ik gemerkt

[Marve79]

SSO is juist veel veiliger omdat er geen wachtwoord aan te pas komt wat onderweg gestolen kan worden of meegekeken/afgeluisterd. Maar je moet natuurlijk wel je initiele login goed beveiligen. Dat kan met MFA en die moeheid kan worden tegengegaan door een cijfer of symbool weer te geven. Maar met SSO heb je ook minder snel kans op moeheid omdat je maar eenmalig hoeft in te loggen.

En je hebt ook al passwordless authentication met Windows Hello bijv. Dat is al helemaal gemakkelijk. Veel bedrijven hebben nog altijd van die idiote password policies waarbij je elke 2 weken je password moet wijzigen. Dat is totaal onnodig als je MFA goed implementeert.

[Crapple]

Precies, ik hoor vaker dat mensen slecht denken over SSO. Maar het gaat er meer om hoe je SSO implementeert, er zijn in de IAM wereld veel verschillende smaken en varianten.

[SunnieNL]

Sso wilt niet zeggen dat er geen wachtwoorden zijn, maar dat een single token na authenticate door meerdere systemen gebruikt wordt. Initieel kan daar nog steeds een wachtwoord aan te pas komen.

Passwordless aithenticatie is wachtwoordloos via MFA en dat kan gecombineerd worden met Sso.

[Puddi Puddin]

Onderweg naar wat gestolen worden? Pak je het wachtwoord niet dan misbruik je de id en access token wel. Systeem is zo sterk als de zwakste schakel een stukje malware bij een beheerder en je hebt een probleem. Geen SSO is funest voor een gemiddelde gebruiker je creëert een enorme rompslomp met rond slingerende wachtwoorden en een drempel om het systeem te gebruiken. Veel beter is het verplichten van trainingen en het uitvoeren van goed beleid. Denk aan hoe herken ik phishing en hoe ga ik veilig om met gegevens.

[Reactie gewijzigd door Puddi Puddin op 22 juli 2024 21:31]

[Crapple]

Een goede SSO implementatie heeft Authenticatie en Autorisatie gescheiden. Ik denk dat je met een goede SSO implementatie veel veiliger bent in vooral grote organisaties.

In 99% van de gevallen zijn het de gebruikers die niet goed opletten of een fout maken, doormiddel van het scheiden van Authenticatie en Autorisatie kan je veel van dit soort gevallen al opvangen.

SSO implementaties zorgen ook voor één standaard en één gecentraliseerde beveiliging mechanisme, wanneer je gebruikers zelf wachtwoorden laat aanmaken (die je vervolgens ook nog weer om een x aantal weken/maanden moet laten veranderen) ga je ervan uit dat je gebruikers slim genoeg zijn om sterke wachtwoorden te gebruiken, helaas is dit in de praktijk vaak niet het geval.

[Jorah_Newstone]

Met de laatste versie van 2FA kan dat al niet meer, dan moet je een code invoeren. Geen simpel goedkeuring meer.

[deadlock2k]

Voor dit soort portals is het misschien handiger om een PIN-code en een FIDO2 token te gebruiken. Dan voorkom je popups die maar goedgekeurd worden.

Een tweede mogelijkheid is wat de Auth app van MS nu doet bij de standaardconfig en dat is vragen om een cijfer van twee getallen in te voeren; je moet dat dus overnemen. Dan kan je nog zoveel moeheid hebben, dat gaat niet werken als je die persoon niet naast je hebt zitten.

[MiTM]

Aangezien de inloggegevens via malware gestolen zijn kan dat ook een infostealer geweest zijn. Daarbij stelen die vaak ook sessie cookies en dan is tweestapverficatie ook niet meer nodig om in te loggen aangezien je dan al geauthenticeerd bent als dit nog een actieve sessie is. MFA is ook niet alles, maar een extra verdedigingslaag.

[SunnieNL]

Dat vind ik nog niet het ergste.. 8 februari merkt het Security platvorm op dat credentials zijn gestolen door malware en 12 februari zijn die inloggevens nog geldig.. Je hebt dat threat intelligence systeem toch niet voor niets. Handel er naar als het iets opmerkt.

[richardboer]

Nou ja, wat eigenlijk veel erger is, is dit deel:

Op 8 februari detecteerde het threat intelligence-platform dat Change Healthcare gebruikt, dat die inloggegevens via malware gestolen werden, schrijft BleepingComputer.

Waarom is daar niet al iets mee gedaan. Tuurlijk 2FA helpt uiteraard ook, maar als je systeem al ziet dat er credentials uitgelekt zijn, waarom zijn deze dan niet gereset bijvoorbeeld?

[The Zep Man]

Witty geeft toe dat het portaal geen tweestapsverificatie vereiste.
(...)
De aanval heeft UnitedHealth uiteindelijk 872 miljoen dollar gekost.

Dit lijkt veel, maar het is simpelweg "the cost of doing business". Dit bedrag slaat geen deuk in een pak boter.

[watercoolertje]

Wat wil je met die koers precies zeggen? Marktwaarde/koers betekent/zegt niet zo veel over wat een euro waard is voor dat bedrijf, daarvoor moet je naar de reserves en winsten kijken.

Sowieso als ze voor 1 miljoen 2factor konden implementeren hadden ze daar nu dus nog 871 miljoen extra (over) gehad. Niemand laat graag geld liggen, en bijna een miljard euro is ook echt geen wisselgeld ofso.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 21:31]

[amigob2]

Er staat meer op die pagina , bij voorbeeld van 5 miljard winst naar 1.4 miljard verlies

[watercoolertje]

Dank je maar ik had liever dat hij het uitlegt, hij stelt dat er niks aan de hand is ben dus nog steeds benieuwd waarom hij dat denkt en welke cijfers hij daar dan voor gebruikt.

[amigob2]

Ze gaan van een 5 miljard winst ( ieder kwartaal ) naar een 1.4 miljard verlies,
Blijkbaar heeft het toch echt wel iets gedaan, en meer dan die miljard kosten die hier genoemd worden

[JoHnnY-Btm]

dat die inloggegevens via malware gestolen werden, schrijft BleepingComputer.

Witty geeft toe dat het portaal geen tweestapsverificatie vereiste. Met de inloggegevens kon de aanvaller dus binnenkomen

ransomware? eerder een stukje software waar een keylogger in heeft gezeten zonder dat dit is opgemerkt.

als de beveiliging bij dat bedrijf zo slecht is of in dit geval was dan vraag ik mij sterk af of het opnieuw opbouwen van hun structuur uberhaupt zin heeft.

zo een stukje ransomware komt niet zomaar op het systeem. dat heeft aan een individu('s) gelegen intern bij het bedrijf

[Ootje70]

Dan hebben ze nog steeds daarna ransomware geïnstalleerd...

[JoHnnY-Btm]

precies dattem

[Bux666]

De aanval heeft UnitedHealth uiteindelijk 872 miljoen dollar gekost.

Voor een klein deel van dat bedrag hadden ze extreem goede beveiliging kunnen hebben. Echt schandalig dit, want wie gaat dit uiteindelijk betalen? Niet de CEO of de CTO, maar de klanten.