Medewerker Canadees financieel bedrijf laat data 2,7 miljoen mensen uitlekken

Een medewerker van Desjardins, een Canadese financiële instelling, heeft expres de financiële gegevens van 2,7 miljoen mensen laten uitlekken. De desbetreffende medewerker is inmiddels ontslagen en opgepakt door de politie, maar het motief is nog niet bekend.

In een statement dat is vrijgegeven door een hooggeplaatste medewerker van Desjardins, werd aangegeven dat het uitlekken van de gegevens van 2,7 miljoen klanten werd veroorzaakt door een medewerker die zichzelf toegang had verschaft tot de data, en deze vervolgens expres heeft vrijgegeven. Hierbij ging het onder meer om de naam, adres, geboortedatum en informatie over uitgaven die de klanten hebben gedaan. Wachtwoorden en pin-gegevens zijn echter niet buitgemaakt, aldus Desjardins.

Al in mei kwam Desjardins het lek op het spoor, maar het duurde vervolgens nog enige tijd voor de oorzaak werd opgespoord. In samenwerking met de Canadese politie werd uiteindelijk een verdachte medewerker gevonden, die inmiddels door Desjardins is ontslagen. De voormalig medewerker is tevens opgepakt door de politie, maar het is nog niet duidelijk of zij inmiddels het motief hebben weten te achterhalen.

Het verspreiden van de financiële gegevens van 2,7 miljoen mensen maakt het een van de grootste lekken bij een financiële instelling ooit. De klanten die zijn getroffen, zijn inmiddels door Desjardins op de hoogte gesteld.

Reacties (47)

[TheGhostInc]

Ben benieuwd of zijn manager en de rest van het management ook ontslagen worden. Immers zou het technisch niet mogelijk moeten zijn om alle data zo te ....

Ow, wacht, ze moesten bezuinigen, die ene feature moest live en de bonus moest gehaald worden...

Wat mij betreft legt de CEO per direct het werk neer. Hij is eindverantwoordelijk.
Het zou me niks verbazen als deze ex-medewerker dit al 3x had aangekaart en daarna deze (foute) optie heeft gebruikt.

[5pë©ïàál_Tèkén]

Er is maar zo veel wat je redelijkerwijs kan doen tegen ècht kwaadwillenden van binnenuit. Ja, een eenling zou dit niet 'zomaar' moeten kunnen doen, maar het verhaal verteld niet hoe de verdachte te werk is gegaan. Heeft hij inlog gegevens gestolen/gekopieerd? Een zwakke plek im het systeem uitgebuit? Moet een CEO dan alles dicht timmeren waardoor iedereen meer bezig is met controleren dan werken?

Te veel beveiliging zorgt juist voor onveilige situaties. Collega's gaan login gegevens delen ("verifieer jij mij, dan ik jou"), plakbriefjes met wachtwoorden en admin pasjes 'voor de afdeling'. Het mag niet gebeuren maar gek genoeg willen de meeste werknemers gewoon hun werk doen en niet bezig zijn met protocollen.

Natuurlijk is dit kwalijk, slecht en zou het nooit moeten gebeuren. Maar juist door zo snel te oordelen en meteen straffen/vervolgacties te roepen is er geen ruimte voor afgewogen en doordachte evaluaties/leermomenten. Als de familie van de verdachte werd gegijzeld ligt er een ander probleem ter grondslag dan wanneer de werknemer zojuist een negatieve beoordeling heeft gehad.

[Douweegbertje]

Of we lezen zelf de bron als we diepgaande teksten willen schrijven over hoe of wat; overigens had Tweakers dit zelf ook wel mogen doen:

"There is no one at Desjardins who can turn on their computer in the morning and get access to the information of all our members," said Cormier. "We're a lot more secure than that."

The suspected employee created a scheme to win the trust of his colleagues, he said. The employee allegedly used their access, and his own, to assemble the data trove.

[The Zep Man]

Om op dat stuk van de bron in te gaan:

Als medewerkers credentials kunnen en/of mogen uitwisselen dan is het een onveilige organisatie, en hebben ze niet alles (tot in het redelijke) gedaan om dit te voorkomen.

Verder, op het artikel van T.net:

Het verspreiden van de financiële gegevens van 2,7 miljoen mensen maakt het een van de grootste lekken bij een financiële instelling ooit.

Wat een onzin. Dit is in verhouding helemaal niet zo groot.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:54]

[LordMike]

Heb dit probleem ook, hoe zorg je ervoor dat mensen geen gegevens kunnen uitwisselen? Wachtwoord + username is toch zo door te geven?

[Pietervs]

Username+Wachtwoord is dan ook maar 1 factor. Vraag is: wat gebeurt er met die gegevens? Als je dat kan loggen, is het maar een kleine stap naar wie wanneer waar op in is gelogged: je weet immers al wat er met die gegevens gedaan is.
Daarna is het een simpel spel van ondervragen, en andere verdachte gedragingen bij elkaar optellen...

[Zer0]

Ja, dat zijn allemaal zaken die je achteraf kunt doen, niet direct om te voorkomen.

[The Zep Man]

Heb dit probleem ook, hoe zorg je ervoor dat mensen geen gegevens kunnen uitwisselen? Wachtwoord + username is toch zo door te geven?

Er zijn meer factoren dan wachtwoorden. Zorg ervoor dat er iets in het authenticatieproces zit dat een gebruiker niet wilt of kan weggeven.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:54]

[R4gnax]

Heb dit probleem ook, hoe zorg je ervoor dat mensen geen gegevens kunnen uitwisselen? Wachtwoord + username is toch zo door te geven?

Combineren met iets wat niet eenvoudig door te geven is. Zoals een vingerafdruk-scan, bijvoorbeeld.
Pasjes werkt misschien ook, maar die zijn nog 'uit te lenen' en zijn voor dat doeleinde dus minder geschikt.

[TheekAzzaBreek]

Als medewerkers credentials kunnen en/of mogen uitwisselen dan is het een onveilige organisatie, en hebben ze niet alles (tot in het redelijke) gedaan om dit te voorkomen.
[...]
Dit is in verhouding helemaal niet zo groot.

Als organisatie kan je niet veel meer dan instrueren en blijven herhalen. Tegen echt gewiekste actoren van binnen kan je niet heel veel doen.

Een voorbeeld dat ik langs heb zien komen: X staat op goede voet met Y. X weet de werkvoorraad van Y te beïnvloeden, juist op de dag dat Y's kind haar grote avond op school heeft. Komt goed, joh, ik doe dat overwerk wel voor je, je moet naar je kind. Daar kom je niet achter zonder alles van iedereen te monitoren (en dan maar hopen dat je die speld op tijd vindt). En dan wil niemand meer voor je werken.

offtopic:
Een amerikaans lek: schade x miljoen mensen. Een koreaans lek: schade x miljoen koreanen. Ouch.

[Timoo.vanEsch]

"tot in het redelijke" is hier key.
Want niemand staat te springen om in een Orwelliaanse omgeving te werken, waarbij informatie niet kán worden gedeeld, op straffe van ontslag. Informatie delen is nu juist key tot efficiëntie. Niet de prepared slides for management, maar het samenwerken, het gezamenlijk delen van informatie. Daar wordt iedereen rijker van in hun werk.

En ja, bij kritieke informatie moet er een bepaalde vertrouwensrelatie worden opgebouwd. Dat er dan een rotte appel tussen zit is niet de schuld van management of veiligheidsregels; dat is de fout van de rotte appel.

[MrFax]

Tja, waar een wil is, is een weg.

[MrMonkE]

Misschien is hij wel DBA of sysadmin die de backups beheert.
Gissen is missen.

[frickY]

Die backups zijn beveiligd met encryptie. Althans, zo hoort het.

[DigitalExorcist]

Maar in het geval van een restore moet toch minstens één iemand aan de key kunnen komen...

[Verwijderd]

je zou daar ook een 4 ogen concept op los kunnen laten. 1 iemand moet de backup terug kunnen zetten en een ander iemand moet de data kunnen verifieren. Simpel voorbeeld (ik weet dat snapshots geen backups zijn, dit is puur een voorbeeld) in storage systemen kunnen sysadmins die geen toegang hebben tot servers wel snapshots terug zetten. zo werkt dit ook met backups, als je RBAC op de juiste manier toepast kan een backup administrator werken zonder toegang tot de data. Bovengenoemde methode zou er voor moeten zorgen dat de backup admin niet bij de data kan, maar wel ingeschakeld moet worden door de verificatie persoon om de data van de tape (oid) te krijgen. De verificatie persoon zou dan weer geen rechten moeten hebben om zo'n verzoek in te dienen.

Het probleem van bovenstaande is dan weer dat dat soort processen enorm veel tijd kosten. (elk van die personen heeft bijvoorbeeld een SLA van 4 uur, waardoor vanaf aanvraag tot werkelijke restore zomaar een dag kan zitten omdat de procedures gevolgd moeten worden. Hierdoor ga je vervolgens weer een discussie aan over welke beveiliging waar thuis is, die wij hier op tweakers nooit zullen slechten. Deze security / usabillty balans problemen kom je overal tegen.

[PageFault]

niet per se toch. Een DB admin kan een database zonder key terug zetten. Wanneer de data in de database geencrypt is, kan hij nog nergens bij.

[MartijnHavinga]

Het is heel moeilijk om data voor iedereen ontoegankelijk te maken. Bij de meeste systemen zijn er op zijn minst een paar mensen (system admins, db admins, lead developer) die, als ze willen, bij de gegevens kunnen komen.

[TheGhostInc]

Toch gek dat ik gewoon bedrijven ken die dat zonder heel veel moeite bijna geheel voor elkaar krijgen.
Cloud heeft wel bewezen dat system admins veel minder daadwerkelijk op productiemachines hoeven te zijn. Uitrol e.d. kan volledig autonoom.
Developers zouden per definitie al niet bij productiedata moeten kunnen. Een geanonimiseerde testset is bij een bank een no-brainer.
Dan houdt je alleen de DBA's over. Dat blijft een lastige, maar het 4-ogen principe is dan geen slechte oplossing.
En een query draaien is 1, het resultaat vanuit een 'bunker' zoals een bank krijgen is weer iets anders.

Maar als bij een bank een handjevol mensen echt gevaarlijke dingen kunnen doen, dan is het ook weer simpel om die mensen in de gaten te houden.

[Ed Vertijsment]

Developers zouden per definitie al niet bij productiedataklantgegevens moeten kunnen

Productiedata hangt er helemaal van af wat het is, Bij een cms websites wil je (onder andere) testen of de live content goed gaat. Of bij specifieke bugs een fixtue maken van waar de bug zich voordoet.

[Reactie gewijzigd door Ed Vertijsment op 23 juli 2024 08:54]

[Webgnome]

Productiedata hangt er helemaal van af wat het is, Bij een cms websites wil je (onder andere) testen of de live content goed gaat

je bedoelt waarschijnlijk productiewaardige data. Niet daadwerkelijk productie data. Maar dan nog dat developers niet bij productiedata zouden mogen is natuurlijk onzin en hangt helemaal af van hoe het bedrijf in elkaar steekt. Als je een klein bedrijfje bent waarbij je niet de luxe hebt om aparte rollen te introduceren kunnen developers bij de productiedata.

En waarom zou bijvoorbeeld een DBA dat wel mogen dan? Die maakt maar scripts waar hij zijn werk mee kan uitvoeren zonder daadwerkelijk in het systeem te hoeven neuzen. Zo kunnen we natuurlijk alles tot op het bot afschermen. Maar dat is maar een kant van het verhaal. Je hebt ook nog zoiets als eindgebruikers. En die hebben geen flauw benul van waarom dat er iemand van hogerhand bedacht heeft dat het onhandig is als hij/zij niet bij data x/y kan. Dat is alleen maar lastig en vervelend en men gaat daar omheen werken. Dat is simpelweg in sommige bedrijven een hardnekkige waarheid.

[Dorank]

Cloud heeft wel bewezen dat system admins veel minder daadwerkelijk op productiemachines hoeven te zijn. Uitrol e.d. kan volledig autonoom.

Dat is een goed process, maar hoe ga je voorkomen dat admins backdoors inserten?

Developers zouden per definitie al niet bij productiedata moeten kunnen. Een geanonimiseerde testset is bij een bank een no-brainer.

Zo hoort het in een ontwikkel omgeving te gaan, maar hoe garandeer je dat de devs geen backdoors implementeren zodat ze bij live data kunnen komen?

Dan houdt je alleen de DBA's over. Dat blijft een lastige, maar het 4-ogen principe is dan geen slechte oplossing.

Dus als 2 personen samenwerken is er weer een probleem.

Maar als bij een bank een handjevol mensen echt gevaarlijke dingen kunnen doen, dan is het ook weer simpel om die mensen in de gaten te houden.

Quis custodiet ipsos custodes? MAW het is een probleem van alle tijden.

De uiteindelijke oplossing is dat iedereen altijd bij elke stap alles moet controleren. Succes om nog iets gedaan te krijgen.

[TheGhostInc]

Dat is een goed process, maar hoe ga je voorkomen dat admins backdoors inserten?

Net als bij devs: code reviews & tests.
En zorgen dat je architectuur bestand is tegen 1 of 2 niveau's van falende security.

Een backdoor in de software/os heeft alleen zin als je er bij kunt.
Als er bijvoorbeeld een queue of bus voorzit, dan kun je de machine alweer niet direct benaderen. Als ze netwerktechnisch ook gescheiden zijn, dan zul je dus nog iemand in het complot moeten zien te krijgen.

Meestal zie je bij bedrijven dat security/privacy als laatste erbij komt. En dan wordt het allemaal lastig en duur. Begin je in je ontwerpfase het mee te nemen, dan is het niet spannend. Een contract/api door een bus heen gooien is geen rocket science, 2 VLAN's is peanuts....

[MartijnHavinga]

Ah, en hoe wil je dat doen bij een bedrijf met maar een handjevol ontwikkelaars / IT specialisten? Lang niet ieder bedrijf is dusdanig groot dat ze een dermate groot gelaagd systeem op kunnen zetten.

[R4gnax]

Het is heel moeilijk om data voor iedereen ontoegankelijk te maken. Bij de meeste systemen zijn er op zijn minst een paar mensen (system admins, db admins, lead developer) die, als ze willen, bij de gegevens kunnen komen.

Er zijn systemen die toegang tot gevoelige data vastleggen middels een write-once system, waarbij je files achteraf niet kunt modificeren zonder door de mand te vallen. Da's nou net één van de toepassingen voor block-chain tech, waar het echt goed werkt.

[Mushroomician]

Discipline staat zeker niet in jouw woordenboek.

Ik denk dat we in de toekomst naar een samenleving gaan waar privacy helemaal niet mogelijk is. Niet omdat het verboden is, maar omdat het technisch niet mogelijk zal zijn.

Als iedereen staks het product P en Q van N kan factoriseren, vergaat er al een heleboel. Laatst kwam een artikel langs dat o.a. Google gaat experimenteren met post-kwantum cryptografie, maar of dat in de praktijk waterdicht zal zijn weten we pas zeker over x jaren, of misschien nooit!

Een gedisciplineerde samenleving is dan het enige alternatief. Niet met straffen, maar willen.

Maar wat de CEO betreft, deze verwacht ook een bepaalde discipline van iedereen binnen het bedrijf. Zelfs van de schoonmaker. Dat is gewoon menselijk.

[Reactie gewijzigd door Mushroomician op 23 juli 2024 08:54]

[pe0mot]

Ik denk dat we in de toekomst naar een samenleving gaan waar privacy helemaal niet mogelijk is. Niet omdat het verboden is, maar omdat het technisch niet mogelijk zal zijn

Inderdaaad, en omdat zij die hebben willen het niet en zij die niet hebben kunnen het niet.
Zo is het altijd al geweest, zo werkt de mensheid als organisch geheel.

[nandervv]

Er bestaat gewoon al quantum hardened cryptography. Niet wolf schreeuwen om niets.

Elliptic curve cryptography.

[Thystan]

Niet geheel waar @nandervv .

"Shor's algorithm can be used to break elliptic curve cryptography by computing discrete logarithms on a hypothetical quantum computer. The latest quantum resource estimates for breaking a curve with a 256-bit modulus (128-bit security level) are 2330 qubits and 126 billion Toffoli gates.[41] In comparison, using Shor's algorithm to break the RSA algorithm requires 4098 qubits and 5.2 trillion Toffoli gates for a 2048-bit RSA key, suggesting that ECC is an easier target for quantum computers than RSA. "

Quantum computer kan het wel degelijk breken, alleen is die quantum computer nog niet beschikbaar, of misschien alleen in testfase voor militaire doeleinden.

[nandervv]

Ok, die versie van elliptic curve cryoto niet nee, maar twee klikjes verder op wikipedia en je vindt er een die wel quantum hardened is.

[Thystan]

Ik dacht dat die alleen kon bepalen OF de communicatie is gelezen of niet, niet dat hij de quantum computer buiten de communicatie houd.

[OxWax]

Ow, wacht, ze moesten bezuinigen, die ene feature moest live en de bonus moest gehaald worden...

Waar leest u dat exact in de tekst?

[TheGhostInc]

The suspected employee created a scheme to win the trust of his colleagues, he said. The employee allegedly used their access, and his own, to assemble the data trove.
Waarom zou iemand zijn toegang uitlenen?
Over het algemeen omdat dat tijdwinst oplevert. En tijdwinst is alleen relevant als daar op gestuurd wordt.
Je kunt nog zo'n goede collega zijn, mijn login is mijn login.

[Het.Draakje]

Henk, ik heb een spoedgeval, de klant klaagt en het gaat om een grote betaling.

Joh, ik moet net mijn beoordelingsgeprek in. Kan het niet wachten. Nee, de klant hangt aan de lijn. En is behoorlijk pissig.

Nou mijn wachtwoord is 'Gekke'

Bedankt he, henkie.

NB) De naam en wachtwoord zijn gefingeerd. De rest is meermalen in de praktijk voorgekomen.

[EraYaN]

In dit geval betekend het waarschijnlijk dat de straf voor uitlenen van credentials dus te weinig afschrikkend is. Als men dan meteen op straat had gestaan had men wel wat beter nagedacht. Het komt uiteindelijk allemaal neer op management policy en de controle daarvan.

[Het.Draakje]

Inderdaad, als men er achter komt dat een user-id password misbruikt wordt dan mag je op gesprek met PZ. Een tweede keer is het een exit gesprek.

Papier is geduldig, je kan nog zoveel in je procedure afvangen, maar niemand verwacht dat er precies volgens het boekje gewerkt wordt. Een reden waarom we zo balen als er een stiptheid-actie is. Dat krijg je zelfs op school mee: de administratieve organisatie, als hij al volledig op papier uitgewerkt is, heeft geen enkele relatie met de realiteit. Daarom moet je bij een reorganisatie en business analyse altijd kijken naar de werkelijkheid en niet naar de procedures.

Geen enkele manager vraagt zich af op je houdt aan alle procedures als het werk maar gedaan wordt, en als de klant tevreden is, dan is alles goed. Ook bij financiële instellingen. Het voorbeeld hierboven is juist opgedaan met ruim een kwart eeuw ervaring in de financiële wereld.

[Pietervs]

Zo is het ook in de praktijk voorgekomen dat mensen hun wachtwoord afgaven voor een reep chocola.
Neemt niet weg: als je als bedrijf je procedures op orde hebt denken mensen wel 2x na voor ze hun wachtwoord afgeven.
En zeker van een financiële instelling mogen mensen toch wel verwachten dat die hun procedures op orde hebben.

[pe0mot]

Shit komt van boven, en valt naar beneden op zij die er onder staan.
Of zoals een oudgediende in de beveiliging ooit zei:"als ik zie dat er op de werkvloer gestolen wordt, ga ik er vanuit dat het in de top ook gebeurt"

[EchoWhiskey]

"Het zou me niks verbazen als deze ex-medewerker dit al 3x had aangekaart en daarna deze (foute) optie heeft gebruikt."

Ja lekker... Zelf feiten gaan verzinnen zonder dat je ook maar enig idee hebt wat er is gebeurt.
Het zou mij niks verbazen als Nederland er achter zit en die arme medewerker nu de schuld geeft.
De Nederlandse staat moet namelijk ook bezuinigen.

[_Thanatos_]

Ik denk ongeveer 0 USD. Hij is Canadees...

[Tegniek]

Als de medewerker geen onderdeel was van IT, dan vraag ik me toch echt af hoe hun wachtwoord beleid *was* op hun omgeving. Jezelf rechten toekennen.... bizar.

[_Thanatos_]

Ik ben benieuwd wat de politie precies vindt dat de dader misdaan heeft. Is het de schending van de privacy van 2,7M mensen? Of is het het lekken van IP (voor zover persoonsgegevens dat kunnen zijn)? Of beide?

[PhunkOne]

Zou niet gewoon denken dat de politie de persoon heeft opgepakt voor diefstal?

Een beetje zoeken doet wonderen:
https://laws-lois.justice...tes/2009_28/FullText.html

De rest is aan het OM (wat het dan moge zijn) in Canada.

[Verwijderd]

En zo blijkt toch weer dat de mens altijd de zwaktste schakel zal blijven. Je kunt alles zo goed mogelijk beveiligen met technologie, maar om met data te werken zal iemand er bij moeten kunnen. Die "iemand" is in mijn optiek altijd al het grootste risico geweest. Nu is het een groot datalek, maar in het verleden hebben we al eerder gelezen over sysadmins die een timebomb in systemen aanbrengt om systemen te vernietigen als ze ontslagen worden (voorbeeldje uit 1998).

Wat ik bijzonder vind in dit geval is dat de medewerker meerdere mensen om zich heen zover heeft gekregen om hem zonder hiervan te weten (hoop ik) te helpen. Dat lijkt mij dan toch een aardig staatltje social engineering. Zeker ook omdat in zo'n geval het achterhalen van de sleutel persoon dan nog moeilijker word.

[Bor]

Het nieuwe terrorisme. Financiële schade berokkenen via bv opzettelijke datalekken en zo een bedrijf op gigantische kosten jagen. Imago schade etc kosten erg veel geld en zijn lastig te boven te komen in sommige gevallen