TU Delft en Universiteit Utrecht waarschuwen alumni voor datalek

De persoonsgegevens van 60.000 alumni van de TU Delft zijn gestolen tijdens een ransomwareaanval op crm-systeem Blackbaud. Ook een onbekend aantal alumni van de Universiteit Utrecht zouden slachtoffer zijn geworden.

De ransomware zou de systemen van Blackbaud hebben geïnfecteerd. Dat is een customer relations management-systeem dat de Technische Universiteit Delft en de Universiteit Utrecht onder andere gebruikten om gegevens van alumni bij te houden. De aanval vond plaats tussen 7 februari en 20 mei van dit jaar, maar de TU en UU werden er 16 juli over geïnformeerd nadat Blackbaud daar toen pas over naar buiten trad.

De TU Delft schrijft dat het drie weken duurde voor de onderwijsinstelling over 'voldoende gegevens beschikte', en dat het daarna alumni en 'andere relaties' heeft geïnformeerd. Bij de TU Delft zou het gaan om 60.000 slachtoffers, meldt een woordvoerder. Van de UU is het onbekend hoeveel slachtoffers er zouden zijn.

Tijdens de ransomwareaanval op Blackbaud zouden er ook gegevens zijn gestolen van een zelfgehoste server. Blackbaud zegt dat het de criminelen betaald heeft om de kopieën van die data te vernietigen. Het bedrijf zegt dat het bevestiging heeft gekregen dat de gegevens ook echt vernietigd zijn.

Onder de gestolen data zaten ook back-ups van alumnigegevens van de TU Delft en de Universiteit Utrecht. Het ging om data van alumni tot aan 2017. Wie na dat jaar is afgestudeerd, is in ieder geval niet getroffen. Onder de gegevens zaten naast namen en geboortedatums ook contactgegevens zoals het e-mailadres, postadres en telefoonnummer van de alumni. Ook 'opleidings- en loopbaangegevens' zouden zijn buitgemaakt.

In het geval van de Universiteit Utrecht zouden er ook bankrekeninggegevens en wachtwoorden in de back-up staan. Die zijn 'versleuteld en daardoor niet toegankelijk voor de hackers', al zegt de onderwijsinstelling niet welke soort versleuteling er is gebruikt. De TU Delft schrijft dat die gegevens niet in de back-up stonden.

Reacties (101)

[joost00719]

Noem me sceptisch, maar die data die is niet vernietigd.

[Genosha]

Lijkt mij ook... of mag een universiteit jou data zo lang bewaren? Als je een nieuwe print van je diploma e.d. nodig heb verwijst elke hogeschool of universiteit je toch door naar de DUO, dus waarom zouden ze jou gegevens meer dan 3 jaar bewaren? Zodat studenten die iets met deep-learning (willen) doen data beschikbaar hebben?

[The Zep Man]

dus waarom zouden ze jou gegevens meer dan 3 jaar bewaren?

Omdat het (opzetten en onderhouden van het proces voor het) verwijderen op de jaarrekening meer kost dan de data bewaren.

Uit het artikel:

Blackbaud zegt dat het de criminelen betaald heeft om de kopieën van die data te vernietigen. Het bedrijf zegt dat het bevestiging heeft gekregen dat de gegevens ook echt vernietigd zijn.

Dus je weet niet of de criminelen de data daadwerkelijk hebben, en je weet niet dat als ze het hebben dat het na betaling daadwerkelijk verwijderd is? En toch betalen? Crime pays!

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:37]

[PageFault]

Dat kan, maar dat past niet meer in deze GPDR tijd.... Juridisch kom je daar dus niet meer mee weg.

[Blokker_1999]

Wie zegt dat de Alumni daar nooit toestemming voor hebben gegeven? Het gaat hier om een CRM systeem. Een eenvoudige vraag of ze je na het afstuderen mogen blijven informeren over nieuws en eventuele events voor alumni is voldoende om opgenomen te worden in zo een systeem.

[supersnathan94]

Met bankrekening ja? Ik mag toch aannemen dat je per gegeven bepaalde vragen stelt. Bankrekening bewaren tot 1 jaar na afstuderen is al lang. Laat staan langer dan drie jaar.

[Galapogos]

Veel alumni ondersteunen hun voormalige universiteit financieel. Universiteiten doen mede aan alumnibinding vanwege de fondsen die ze via deze route verwerven. Nergens lees ik dat van alle UU-alumni de bankgegevens aanwezig waren in het bestand. Vermoedelijk betreft het alleen bankgegevens van donateurs, en eventueel van alumni die betaalde diensten afnemen bij de universiteit waar ze hebben gestudeerd.

[The Zep Man]

Dat kan, maar dat past niet meer in deze GPDR tijd.... Juridisch kom je daar dus niet meer mee weg.

Alleen als je 'gepakt' wordt. Handhaving is echter zo slecht dat de pakkans nihil is.

niet significante kans * hoge impact = laag risico

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:37]

[don spike]

Als je een nieuwe print van je diploma e.d. nodig heb verwijst elke hogeschool of universiteit je toch door naar de DUO

Dat is dus niet helemaal waar, ik val zelf net buiten deze boot. Dat is pas vanaf een bepaalde datum, en dacht dat deze datum ook deels varieert per hoge school, vanaf een bepaalde datum geld het voor alle hogescholen, en later ook voor alle Middelbare Beroepsonderwijs (MBO).

Verklaring van mijn diploma's kon ik niet via DUO verkrijgen, en werd doorverwezen naar de onderwijs instelling.

[Polydeukes]

Ik weet het niet 100% zeker maar volgens mij moeten (of althans moesten) onderwijsinstellingen fysieke kopieën van diploma's bewaren voor best een lange periode, ik meen minimaal 40 30 jaar. Veel instellingen zijn dit op een gegeven moment gaan digitaliseren (inscannen) en tegenwoordig staat bijna alles ergens in de cloud. Uiteraard op naam en geboortedatum zodat je snel een kopie van je diploma kunt opvragen als je kunt bewijzen wie je bent. Het is dus zoeken naar balans tussen veiligheid en gebruiksvriendelijkheid, en dat allemaal opgezet en ingericht ruim voor de komst van de GDPR/AVG (ja, de WBP deed feitelijk hetzelfde, maar niemand hield zich daar aan).

Edit: hier een voorbeeld van de RU. Zij hebben voor sommige informatie een bewaartermijn van 360 maanden (30 jaar): https://www.ru.nl/student...enttypes-bewaartermijnen/

[Reactie gewijzigd door Polydeukes op 22 juli 2024 13:37]

[kami124]

Ik ben zelf ook alumni van een hbo en een universiteit en ze sturen beide soms nog wel eens een brief naar me toe voor een enquête, lid te worden van de alumni vereniging of om te doneren aan een goed doel/project. Van mijn mbo hoor ik echter al lang niks meer.

[mae-t.net]

Hoewel van meerdere opleidingen, ben je zelf maar één alumnus.

Ik ben zelf alumnus van de TU Delft, maar hoor er nooit meer wat van. Ook niet van dit lek, dus ik zal er maar van uitgaan dat het te lang geleden was.

[beugeldop]

Ik ben vandaag geïnformeerd door de TU Delft, afgestudeerd in 2013.

[Crisium]

Ik heb nog niets van ze gehoord, terwijl ik ook verwacht binnen de getroffen groep te vallen.

[Galapogos]

Het kan ook zomaar zijn dat de TU Delft niet (meer) over actuele contactgegevens van je beschikt, en je dus niet eens kan informeren.

[mae-t.net]

De gegevens zouden nog moeten kloppen.

[jopiek]

Uni is juist heel streng met anonimiseren van onderzoeksdata, dus dat zal nooit mogen voor deep-learning of zo. Het is wel nodig voor o.a. accreditaties, accreditatiecommissies vragen vaak aan opleidingen om bepaalde informatie incl. thesis en toetsen van aantal jaren terug te laten zien.

[J_van_Ekris]

Lijkt mij ook... of mag een universiteit jou data zo lang bewaren? Als je een nieuwe print van je diploma e.d. nodig heb verwijst elke hogeschool of universiteit je toch door naar de DUO, dus waarom zouden ze jou gegevens meer dan 3 jaar bewaren? Zodat studenten die iets met deep-learning (willen) doen data beschikbaar hebben?

Ze mogen (moeten?) die info bewaren omdat uiteindelijk de "handtekening" van de instelling onder het diploma staat. Je moet dus altijd terug kunnen naar de universiteit, ook al handelt DUO de praktische kant van uitreksels van diploma's af.

Ook is het zo dat universiteiten structureel contact proberen te onderhouden. Deels om te kijken wat er van mensen terecht komt (belangrijk om bij aankomend eerstejaars te kunnen roepen dat 10% van de afstudeerders van opleiding X binnen 3 jaar al een baan heeft gevonden), deels om ook extra diensten te kunnen verpatsen. Sommige universiteiten hebben ook specifieke alumni-evenementen, bijvoorbeeld om aankomende afstudeerders in contact te brengen met werkgevers. En ik vermoed dat dit systeem gebruikt wordt om deze populatie bij te houden.

[CAPSLOCK2000]

Ook is het zo dat universiteiten structureel contact proberen te onderhouden. Deels om te kijken wat er van mensen terecht komt (belangrijk om bij aankomend eerstejaars te kunnen roepen dat 10% van de afstudeerders van opleiding X binnen 3 jaar al een baan heeft gevonden), deels om ook extra diensten te kunnen verpatsen.

Er is nog een reden: fondsenwerving. Universiteiten zijn altijd op zoek naar geld en soms kan je dat ook krijgen van je voormalige studenten die nog een warm hart voor de organisatie hebben en inmiddels een riant salaris verdienen. Voor sommige Amerikaanse is dat de voornaamste bron van inkomsten. Ik heb geen idee hoe succesvol dat model is in Nederland, maar ik ga er van uit dat alle Nederlandse universiteiten hier een programma voor hebben.

[J_van_Ekris]

Er is nog een reden: fondsenwerving. Universiteiten zijn altijd op zoek naar geld

Klopt, er zijn in totaal drie nederlandse universiteiten waar mijn vrouw en ik met enige regelmatig bedelbrieven van krijgen. Geen flauw idee of het echt wat oplevert: ik heb zelf als student in het bestuur van zo'n fonds gezeten, maar als ik kijk naar wat ze nu verwachten, dan krijg ik daar geen warm gevoel van....

[Galapogos]

Ik werk zelf bij een Nederlandse universiteit en zit dicht bij de afdeling die Fondsenwerving onder haar hoede heeft. Alumni zijn inderdaad belangrijk met het oog op fondsenwerving. Ook ik ga er van uit dat dit zeker niet alleen geldt voor de universiteit waar ik zelf werk, maar ook voor de concullega's in het land.

[Jefrey Lijffijt]

Ik heb de UU gewoon toestemming gegeven daarvoor, of specifieker het UFonds. Ik neem eigenlijk aan dat het hier over het UFonds gaat, anders zou ik niet weten waarom er bankrekeningnummers gekend zouden zijn. Die benaderen je zo nu en dan over activiteiten voor alumni en fondsenwerving. Universiteiten in Nederland werken maar beperkt met donaties, maar het groeit wel. In veel landen, zoals de VS, zijn donaties van alumni een essentiële bron van inkomsten en ik vind dat zelf heel legitiem.

[Óglaigh]

Ja, een universiteit mag jouw gegevens bewaren omdat je een klantrelatie met ze bent aangegaan op het moment dat je bent gaan studeren.

[rik012]

Studentgegevens moeten 7 jaar bewaard blijven. Dit is o.a. voor bijvoorbeeld de examencommissie. Wat de achterliggende gedachten hiervan is weet ik zo niet.

[Polydeukes]

O.a. diploma's worden tot wel 30 jaar bewaard. Zie bijvoorbeeld: https://www.ru.nl/student...enttypes-bewaartermijnen/

[vickypollard]

Ik neem aan om bij een vermoeden van fraude de boel te kunnen controleren. Dan schiet het niet op als een uni zegt 'we hebben nog nooit van deze persoon gehoord '

[Reactie gewijzigd door vickypollard op 22 juli 2024 13:37]

[Tozz]

Data mag bewaard worden zolang het nodig is om bepaalde diensten te kunnen leveren.

In geval van de RuG kan dat bv. zijn het versturen van een alumni magazine. Andere universiteiten weet ik niet, maar die hebben vast iets soortgelijks.

Ik kan me ook voorstellen dat mensen toestemming geven om benaderd te worden voor bv. onderzoeken.

Verder kan ik mij voorstellen dat wanneer een student onderzoeken gepubliceerd heeft dat de gegevens van de auteur (de studenten dus) wellicht bekend moeten zijn wanneer er bijvoorbeeld vragen over het onderzoek zijn.

Ik doe daarbij de aanname dat zo'n universiteit dit verder allemaal juridisch op orde heeft, dus dat bv. de studenten ergens een vinkje gezet hebben met 'Bij publicatie van je onderzoek ga je akkoord met x, y, z'.

[J_van_Ekris]

Verder kan ik mij voorstellen dat wanneer een student onderzoeken gepubliceerd heeft dat de gegevens van de auteur (de studenten dus) wellicht bekend moeten zijn wanneer er bijvoorbeeld vragen over het onderzoek zijn.

Is ook nog een reden inderdaad. Bij mijn weten zit er wel een deadline op van vijf jaar, na die tijd wordt het als onredelijk gezien om ruwe onderzoeksdata te bewaren. En tegenwoordig gaat dit overigens steeds vaker via platformen zoals Researchgate, omdat je dan ook gelijk de resultaten in context van het grotere onderzoek kunt zien en het verkassen van onderzoekers niet gelijk tot problemen leidt.

[eric.1]

Wellicht niet nee, maar dan schieten ze zichzelf wel in hun voet. Wie betaalt er ooit nog een ransom als ze de data toch bewaren en/of openbaren?

[Alex3]

Daar ben ik niet zo zeker van. Volgende keer kunnen ze onder een andere naam hacken.

[bussie66]

Precies mijn gedachte!

[Xfade]

Maar ze hebben bevestiging gekregen! /s

[PageFault]

Heb je de belastingdienst al eens een verzoek gestuurd met het recht op vergeet mij?

[The Zep Man]

Ja, en dat wordt niet gehonoreerd omdat de Belastingdienst een gerechtvaardigde reden heeft om de gegevens van alle belastingplichtigen te verwerken.

Nu weer even terug met de voeten op Aarde, medetweakers.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:37]

[PageFault]

Maar het zou leuk zijn wanneer iemand anders dat zou proberen

Voorlopig krijg ik nog hypotheekrente aftrek, dus laat mijn gegevens maar bestaan bij de BD.

[Anoniem: 310408]

En wat heeft dat te maken met de TU Delft?

[Naafkap]

Onvoorstelbaar dat persoonsgegevens nog steeds onversleuteld worden opgeslagen. Zelfs de TU Delft overkomt dit dus blijkbaar. Ongekend

[fietser1997]

Dat is een wat scheve opmerking imo. Als jij volledige disk encryptie gebruikt op wat voor besturingssysteem dan ook. Wanneer iemand toegang krijgt tot een live systeem heeft die volledige versleuteling geen effect. Het gebeurt maar heel weinig dat je een database of schrijf hebt die tijdens runtime nog versleuteld is.

En zelfs dan als jij de data bekijkt kunnen zij op dat moment bij de data omdat het systeem het voor jou leesbaar maakt.

[Reactie gewijzigd door fietser1997 op 22 juli 2024 13:37]

[watercoolertje]

Dat dus, leuk dat het in de database (of op diskniveau) versleutelt is, maar de app of website die die gegevens op vraagt heeft dus de sleutel nodig om iets met die data te doen.

Encrypted opslaan is goed en bied zeker waarde, maar het betekend niet dat uitlekken van decrypted data onmogelijk wordt, in het beste geval is de drempel iets hoger...

Encrypted opslaan en de sleutel weg gooien is een optie, alleen jammer dat je dan zelf ook niks aan die data hebt en het net zo goed niet op kan slaan

[Reactie gewijzigd door watercoolertje op 22 juli 2024 13:37]

[ro8in]

Sterker nog bij live online applicaties heeft het versleuteld opslaan alleen zin voor one way toepassingen, zoals bijvoorbeeld wachtwoorden. Maar versleuteld opslaan van gegevens die je weer moet kunnen uitlezen en tonen binnen dezelfde applicatie is mijn inziens vrij zinloos en echt schijnveiligheid. Dat is een beetje zoiets als de deur op slot doen en de sleutel onder de deurmat leggen. Als ze bij de versleutelde data kunnen, kunnen ze vrijwel zeker ook wel de bij de sleutel om het uit te lezen. Wat wel zin heeft is natuurlijk versleuteld versturen! Maar dat in een CRM naam en adres etc niet versleuteld staan opgeslagen vind ik persoonlijk niet echt een doodzonde ofzo.
Maarja voor veel mensen is encryptie tegenwoordig een soort magisch woord waarmee alles zogenaamd veilig wordt. Dat zie je bijvoorbeeld bij gebruik van VPN. Heel veel mensen denken dat daarmee je internet veilig wordt want dan is je verbinding versleuteld. Terwijl dat natuurlijk nergens op slaat.

[Reactie gewijzigd door ro8in op 22 juli 2024 13:37]

[djwice]

Ben ik het niet helemaal mee eens. Als je de data encrypt kunnen mensen met toegang tot een backup de data nog niet lezen.

Pas als ze ook rechten hebben tot de sleutels kunnen ze dat.

Zo kun je bijvoorbeeld zorgen dat operators wel een database kunnen managen maar de data niet kunnen lezen. En ook dat als iemand een SQL query kan doen op de database ze nog niet de encrypted data kunnen lezen.

Je kunt dan ook monitoring inrichten op het key systeem. Je kunt zelfs een tussenlaag maken die encrypt/decrypt. En die monitoren.

[Naafkap]

Precies. Dat is net het punt. Gevoelige data versleuteld opslaan zorgt bij datalekken (fysiek diefstal of online) dat de gegevens zo goed als onbruikbaar zijn.

[ro8in]

Niet als men gewoon de sleutel heeft welke ook gewoon op je systemen moet staan aangezien je systeem de data moet kunnen decrypten. Het voorbeeld van de backup zou ik eerder de encryptie toepassen tijdens de backup en niet tijdens het live process. Zoals ik zei je draait de deur op slot, maar je legt de sleutel er naast onder de mat. Hoeveel veiliger is dat nou werkelijk.

[Reactie gewijzigd door ro8in op 22 juli 2024 13:37]

[Aaargh!]

Wat is niet snap is hoe de ransomware op zo'n systeem kan komen. Onder normale omstandigheden zou niemand op OS-niveau bij een productie server moeten kunnen zonder eerst door 12 hoepels te springen. Hoe maakt die ransomware dan de sprong van de computer van Truus van de administratie die heel naïef op een link in een 'grappige' email klikt, via de machine van b.v. een systeembeheerder naar een productie machine ?

[fietser1997]

Daar zijn een grote hoeveelheid opties en variabelen. Komt mee in de email en lift mee op het interne email verkeer.
Het vinden van bekende "Exploits" in de besturingssystemen.
Windows SMB is wat dat betreft echt een zwak punt. (maar er zijn nog zoveel meer dingen)
Teveel toegang of rechten voor 1 enkele gebruiker of machine kan hier al funest zijn.
Het is zelfs mogelijk dat de ransomware elk bestand wat geopend wordt zichzelf rechten toekent.

[PizZa_CalZone]

Of soms zie je deze problemen als IT nerd al tijden aankomen, ga je van de hoogste daken schreeuwen dat er wat aan moet gebeuren. Maar dan krijg je management niet overtuigd dat het 't geld waard is om deze investering te doen. Want het "doet" het toch prima?

Wie weet stond de pc van Truus wel in hetzelfde subnet als de server, want dan hoefde truus niet door 30 hoepels heen om veilig met de applicatie te kunnen werken. Gebruikersgemak weegt soms zwaarder dan veiligheid.

[Reactie gewijzigd door PizZa_CalZone op 22 juli 2024 13:37]

[MPAnnihilator]

ik heb nog een verzekeringsbedrijf geweten waar de wifi guest range direct toegang kreeg tot de backend/ad. Want de user geraakten niet wijs uit de SSID's van de IT en de wifi guest was dus door bijna iedereen in het bedrijf in gebruik

[Zwarte_os]

Niet alleen Truus hoor, ook de academici zijn zeer achteloos met data en security. 90% op mijn afdeling kocht Dropbox en niemand die wist dat SURF een prachtig, gratis alternatief biedt. Dan spreken we van 2000 euro weggegooid geld op jaarbasis.

[PizZa_CalZone]

Herkenbaar, ik ben die it-nerd die academici ervan probeert te overtuigen dat ze surf-drive moeten gebruiken. En dan nog niet eens om financiele redenen, maar dropbox wordt door veel onderzoekers gebruikt om data uit te wisselen met collega's van andere universiteiten. En dan vaak nog met de gratis variant. (geen idee hoe het zit met de betaalde versie.) Maar met de gratis versie ben je inweze je belangrijke onderzoeksdata aan het weggeven.

[Reactie gewijzigd door PizZa_CalZone op 22 juli 2024 13:37]

[Zwarte_os]

Ik ga iets te kort door de bocht met de financiële redenen, klopt. Het is meer dat er en achteloos met data omgegaan wordt, en dat ze daar nog geld aan uitgeven ook.

[PizZa_CalZone]

Daarnaast merk ik ook op dat de meeste academici geen kaas hebben gegeten van data-classificatie en het eerder als een obstakel zien. De meeste universiteiten werken met een data-classificatie-matrix waarin vermeldt staat welk type data je op welk medium mag neerzetten. Men vindt deze matrix niet belangrijk (het is niet hun vakgebied) of snapt de redenen niet, wat als gevolg heeft dat deze matrix naast zich neergelegd wordt.

[michelr]

Dat SMB1 nog aanstond is idd niet ondenkbaar. Die universiteisomgevingen staan erom bekend dat studenten ook nog wel eens de grenzen opzoeken qua wat kan, laat staan kwaadwillenden.

[michelr]

Ik roep even het Citrix issue van eind 2019 in herinnering. Waarmee ik niet wil zeggen dat hier Citrix het vehikel was, overigens. Wel qua duiding, timeframe en hoe laks sommige ondernemingen zijn.

[Adaolin]

Jammer genoeg zie je vaak dat de bestuurlijke laag en de onderzoekslaag van een universiteit bar weinig contact hebben.

Anders zou het allemaal wel wat soepeler lopen

[mae-t.net]

Dat is nooit echt goed op orde geweest. De TU heeft zoveel resources die ze voor zichzelf kunnen aanwenden maar ze zoeken altijd (slechtere en duurdere) hulp van buitenaf. Dat was al zo toen de automatisering nog in de kinderschoenen stond (tas, netwerken studentenhuizen, etc). Ook op andere vakgebieden viel dat op, ik neem aan dat er bij o.a. civiel en bouwkunde vergelijkbare klachten speelden of spelen.

[PageFault]

Een universiteit werkt niet anders dan een willekeurig ander bedrijf, dus het verbaast me niks. Dat het slecht is, ja absoluut.

[michelr]

Eh nee. Die gaan bijvoorbeeld anders om met hun mailfiltering (lees: afwezig, want is niet hun taak) en bij een aantal educatieve instellingen kom ik nog wel eens een portscanner tegen (en dat is dan een onschuldige variant van grenzen opzoeken). En dat moet dan allemaal kunnen, want het is geen (commercieel) bedrijf.

[Reactie gewijzigd door michelr op 22 juli 2024 13:37]

[wph]

Het zou wel fijn zijn dat je precies kon checken welke gegevens er zijn buitgemaakt.

In de mail staat het volgende:

- Persoonsgegevens: naam, geslacht, geboortedatum.
- Contactgegevens: mailadres, telefoonnummer, postadres.
- Opleidings- en loopbaangegevens.

Vooral van de opleidings- en loopbaangegevens zou ik graag willen weten wat ze nu precies van me hebben.

[TijsZonderH]

Ze verwijzen in de berichten door naar e-mailadressen waar alumni precies dit kunnen navragen. Zie de links in het bericht, en dan onderaan de pagina's.

[wph]

Ja klopt, ik zie het nu ook. Ik had er vanochtend even overheen gelezen. Ik heb toch maar even een GDPR verzoek verstuurd.

[Kees]

Dat kun je zo opvragen met een GDPR verzoek

[eric.1]

De aanval vond plaats tussen 7 februari en 20 mei van dit jaar, maar de TU en UU werden er 16 juli over geïnformeerd. De TU Delft dat het drie weken duurde voor de onderwijsinstelling over 'voldoende gegevens beschikte', en dat het daarna alumni en 'andere relaties' heeft geïnformeerd.

Dit stuk vind ik nog het ergste van alles.

Het duurt dus eerst dik 2 tot 5 maanden voordat de getroffen instanties (universiteiten) geïnformeerd werden, en daarna duurde het nog 3 weken om de benodigde informatie te verstrekken...

[ACM]

Met die formulering vind ik het aannemelijk dat die leverancier er pas op of na 20 mei achter kwam wat de precieze impact was.

Wat er tussen 20 mei en 16 juli moest allemaal gebeurd is en/of nodig was is hier verder niet gemeld. Het kan zijn dat ze hebben getreuzeld, zoals jij suggereert, het kan ook zijn dat ze best veel werk hebben verzet (en vast ook met hun juristen moesten overleggen) voordat ze TUD en UU konden informeren.

[MikeN]

Maar waarom konden andere partijen, zoals de University of York, dan al op 21 juli een response posten? Zie https://www.york.ac.uk/ne.../2020/blackbaud-response/

Alles geeft mij de indruk dat de UU en TUD hier gewoon hebben zitten treuzelen en niet conform de AVG de betrokkenen onverwijld hebben geïnformeerd.

[ACM]

De formulering in het artikel suggereert dat de TUD en UU drie weken moesten wachten. Waar haal jij vandaan dat ze hebben getreuzeld?

Wellicht hebben ze in overleg met hun DPO's en/of de AP eerst afgewacht van wie de gegevens waren buitgemaakt, ipv het gelijk al naar buiten te brengen.
In het artikel van de University of York kan ik niet zien of ze toen al over die details beschikten of dat zij besloten alvast e.e.a. te melden en af te wachten tot ze meer informatie kregen.

[MikeN]

De TUD geeft zelf aan dat aanlevering 'bijna 3 weken duurde'. Even los van dat ik weinig met zo'n verwerker te maken heb, en dat de TUD als controller dan maar betere afspraken had moeten maken met hun verwerkers, zitten we dan nog steeds op 6 augustus (uitgaande van 3 weken, terwijl het dus minder dan 3 weken was) en niet op 11 augustus.

Daarnaast zou de controller voor zichzelf duidelijk moeten hebben welke gegevens ze naar welke verwerkers sturen. Dat zijn ze ook verplicht onder de AVG en dienen ze in hun verwerkingsregister bij te houden. Reageert zo'n verwerker niet adequaat dan kun je in ieder geval pro-actief je potentieel getroffen gebruikers informeren, en zonodig later bijschaven.

[KoffieAnanas]

Je kunt afspraken maken wat je wil, maar als een leverancier waar je al weg bent backups niet verwijdert, dan wordt het lastig. Het betreft zo te zien data tot 2017, en het is gebruikelijk dat je afspraken maakt met een leverancier om data te verwijderen na einde contract. We kennen de details niet, maar de leverancier lijkt mij sowieso de schuldige partij hier, niet de universiteiten. Hoe kan zo'n leverancier na 3 jaar de data nog steeds niet verwijderd hebben... Laksheid?

In 2017 bestond een dergelijk verwerkersegister nog niet volgens mij.

[Reactie gewijzigd door KoffieAnanas op 22 juli 2024 13:37]

[MikeN]

We kennen de details niet, maar de leverancier lijkt mij sowieso de schuldige partij hier, niet de universiteiten.

We kennen inderdaad de details niet. Onder de AVG is de verwerkingsverantwoordelijke echter gewoon net zo aansprakelijk als de verwerker.

Natuurlijk treft Blackbaud hier een hoop blaam, maar ik kan mij niet aan de indruk onttrekken dat de universiteiten hier alles simpelweg naar Blackbaud proberen te schuiven. Vanuit mijn ervaring zou ik zeker niet durven aannemen dat de universiteiten hier hun zaakjes op orde hadden, en inderdaad hadden afgesproken en geverifieerd dat de data verwijderd was, of dat er uberhaupt een verwerkersovereenkomst opgesteld was.

[KoffieAnanas]

Op basis van dit bericht valt hier helemaal niets over te zeggen. Er staat te weinig informatie in. Ik kan me zelf niet echt voorstellen dat de universiteiten hebben getreuzeld, dat is in niemands belang.

[kodak]

Blackbaud zegt dat het de criminelen betaald heeft om de kopieën van die data te vernietigen. Het bedrijf zegt dat het bevestiging heeft gekregen dat de gegevens ook echt vernietigd zijn.

Dat vraagt om een verduidelijking hoe die bevestiging er uit zag en wat dat bewijst. Het lijkt mij namelijk niet mogelijk om te bewijzen dat alle gegevens werkelijk vernietigd zijn tenzij Blackbaud er persoonlijk voor kan in staan wat er met die gegevens is gedaan vanaf het moment dat ze het lieten lekken. En zo erg lijken ze niet in controle te zijn geweest.

[ealshorachi]

Pff... dus Delft weet mij wel te vinden wanneer het hen uitkomt, maar niet wanneer zoiets kritisch als dit aan bod is? Ze zouden iedereen allang een e-mail gestuurd moeten hebben hierover, dat ik daarachter moet komen via tweakers is ronduit zielig en onprofessioneel.

[Slavy]

Mooi die cloud systemen, laat zien dat on premise toch maar weer beter is als je er zelf goed voor zorgt.

[Polydeukes]

Cloud of on-prem, dat maakt helemaal niks uit. Zo lang de gegevens te benaderen zijn via een netwerk, zijn ze te benaderen voor kwaadwillenden. 100% veiligheid bestaat niet.

[XIU]

De cloud systemen zijn vrij gebleven, het is net gebeurd op een eigen on prem systeem.

[djwice]

LOL

bankrekeninggegevens en wachtwoorden ...
versleuteld en daardoor niet toegankelijk voor de hackers

Jep. Tot de hacker van één IBAN / ter naam stelling zeker weet waar hij in de data staat.
Als voor elk data element dezelfde encryptie gebruikt is, zijn ze met weinig moeite daardoor toch toegankelijk.
Als elk individueel data element aparte oncorreleerde complexe sleutels heeft dan zijn ze inderdaad lastig te achterhalen.
Er zijn niet veel systemen die individuele sleutels gebruiken. Vaak is de sleutel gelijk voor alle elementen in een dataset of is gelijk+een afgeleide van de niet versleutelde delen én is de sleutel vaak ook toegankelijk (in memory of zelfs on disk) als je bij de data kunt.

[Reactie gewijzigd door djwice op 22 juli 2024 13:37]

[OppFox]

Zonder exacte informatie over welke vorm van encryptie er gebruikt is kun je niets met zekerheid zeggen, maar gelukkig werkt zo'n 'known plaintext attack' in de meeste gevallen niet. Zie bijvoorbeeld hier voor AES.

Als de key in memory stond is het een ander verhaal natuurlijk, maar ook dan heb je vergaande toegang nodig en niet genoeg aan alleen een databasedump.

[djwice]

In her antwoord in jou link staat hetzelfde als ik aangeeft:

If you have no known plaintext

Wat ik aangeeft is als de hacker één rekeningnummer (11 proef ook nog :-)) of ter naam stelling weet en waar die zich bevindt.

Dan neemt de complexiteit enorm af. Je hebt dan een attack op een korte known string.

Dankzij crypto currencies is er veel kennis en eventueel ook hardware beschikbaar, zeker ook voor AES. Vergeet niet dat AES een heel sparce ruimte beslaat. Bij bepaalde parameter keuzes kun je door de ruimte op een specifieke manier te inverteren van de complexiteit enorm verkleinen (naar orde grote 32 bits sleutel). Zodanig dat een 128-bit computer een attack snel kan uitvoeren. (Nodig voor het algoritme)

[Reactie gewijzigd door djwice op 22 juli 2024 13:37]

[OppFox]

In her antwoord in jou link staat hetzelfde als ik aangeeft:
[...]

Dat is wel een heel selectieve quote uit mijn link. De volledige tekst:

A known-plaintext attack (i.e. knowing a pair of corresponding plaintext and ciphertext) always allows a brute-force attack on a cipher:

Simply try all keys, decrypt the ciphertext and see if it matches the plaintext.

This always works for every cipher, and will give you the matching key. (For very short plaintext-ciphertext pairs, you might get multiple matching keys. Then you need to try more pairs to eliminate the wrong ones).

If you have no known plaintext, only the ciphertext, you can do it similarly, but you also need a function which says whether what you decrypted is a plausible plaintext.

Het enige wat een known plain text je als voordeel geeft is dat je ook daadwerkelijk weet dat je de juiste key hebt gevonden tijdens het bruteforcen. Dit is een bewuste eigenschap van veel versleutelde bestandsformaten, dus veel schiet je er niet mee op.

Wat ik aangeeft is als de hacker één rekeningnummer (11 proef ook nog :-)) of ter naam stelling weet en waar die zich bevindt.

Dan neemt de complexiteit enorm af. Je hebt dan een attack op een korte known string.

Als je nog een stukje verder leest wordt deze bewering ook ontkracht:

So, the question is, are there any attacks which are faster than brute-force?

For now, there seem to be some attacks which are slightly faster (like needing only 2^125 steps instead of 2^127 for brute-force, a bit better for the 256-bit-key version) and needing either a really large amount of chosen plain- or ciphertexts (and knowing the result), or even larger amounts of known plaintexts. These are still not practically doable in our world.

Met één known plaintext ga je dus helemaal niets opschieten. Ook hier kun je lezen dat de beste bekende aanval het aantal operaties slechts reduceert naar 2^126 (voor AES-128).

Dankzij crypto currencies is er veel kennis en eventueel ook hardware beschikbaar, zeker ook voor AES. Vergeet niet dat AES een heel sparce ruimte beslaat. Bij bepaalde parameter keuzes kun je door de ruimte op een specifieke manier te inverteren van de complexiteit enorm verkleinen (naar orde grote 32 bits sleutel). Zodanig dat een 128-bit computer een attack snel kan uitvoeren. (Nodig voor het algoritme)

De gangbare cryptocurrencies werken niet met AES, maar met hashingsalgoritmen, zoals bijvoorbeeld SHA-256 bij bitcoin. Voor onder andere SHA-256 is er length extension attack die in hele specifieke gevallen de complexiteit flink kan reduceren, misschien dat je daar op doelt. Dit heeft echter helemaal niets met AES of een ander gangbaar encryptiealgoritme te maken.

Als je daadwerkelijk een 128 bit AES sleutel kunt reduceren naar 2^32 mogelijkheden zou ik dat graag zien, want dat zou een enorme doorbraak betekenen (en voor heel veel mensen een extreem slechte dag).

[djwice]

Niet alleen een hele slechte dag. Dat betekent o.a. dat heel veel systemen hun TLS encryptie moeten aanpassen, andere cipher suites etc. en dat is voor veel systemen niet mogelijk op korte termijn.

Klopt ik was kort door de bocht, ik doelde op ECC en dan met name zoals gebruikt in Bitcoin.

Inderdaad totaal andere context.

[Reactie gewijzigd door djwice op 22 juli 2024 13:37]

[DLGandalf]

edit:
onjuiste opmerking

[Reactie gewijzigd door DLGandalf op 22 juli 2024 13:37]

[Wouterie]

Ik ben ook geïnformeerd... Helaas hebben ze mijn oude bankrekeningnummer, wie weet willen de boefjes nog wat storten.