Datalek Capgemini bood toegang tot gegevens recruitmentbedrijf Michael Page

Bij it-dienstverlener Capgemini is een datalek geconstateerd. Een derde partij heeft een lading voor- en achternamen, e-mailadressen en versleutelde wachtwoorden gekopieerd. Het zou echter gaan om ethische hackers en de kopieën zijn weer verwijderd.

Michael Page is een Brits recruitmentbedrijf dat internationaal actief is. Het bedrijf laat zijn it-zaken afhandelen door het van origine Franse Capgemini. Beide bedrijven hebben vestigingen in Nederland. Michael Page stelde afgelopen week zijn contacten, waaronder ook een groep Nederlanders, op de hoogte via een e-mail. Daarin stelt het dat het zou gaan om een van de ontwikkelingsservers die Capgemini gebruikt om Michael Page-websites te testen. Inmiddels zou het lek gedicht zijn. Hoe sterk de versleuteling op de wachtwoorden is, meldt het bedrijf niet.

Hoewel Michael Page er zelf niet over spreekt, lijkt de 'onbevoegde derde partij' een anonieme bron van securityonderzoeker Troy Hunt te zijn. Nadat hij Michael Page en Capgemini op de hoogte heeft gesteld van de gaten in de beveiliging van Capgemini, publiceerde hij het verhaal op zijn blog. Opvallend is dat in die post gesproken wordt over veel meer velden dan alleen namen, e-mailadressen en wachtwoorden. Daar worden ook telefoonnummers, functies, motivatiebrieven en locaties genoemd. Ook op een faq-pagina van Michael Page komen deze gegevens terug. Mogelijk zijn Nederlanders van wie gegevens in de Capgemini-database staan dus ook minder uitgebreid. Volgens Hunt zou ook niet bij iedereen evenveel velden ingevuld zijn, maar het zou in ieder geval gaan om in totaal 780.000 verschillende e-mailadressen. Het gehele gedownloade databasebestand zou naar schatting 30GB groot kunnen zijn.

Volgens Hunt had Capgemini elementaire fouten gemaakt bij het opzetten van de Michael Page-websites. "Openbare website, directory listing ingeschakeld, .sql-bestanden open en bloot." Hunt zegt dat alle ongeautoriseerde kopieën van de database vernietigd zijn. Echter, als een andere partij ook doorhad dat de website lek was, dan kunnen de gegevens alsnog uitlekken. Het is niet bekend hoe lang het lek aanwezig is geweest.

Reacties (65)

[Croga]

Hoe kan het dat een bedrijf als CapGemini, die prat gaat op hun procedures, live data op een ontwikkelserver heeft staan? En dan ook nog privacy gevoelige data!

Het eerste wat men in de IT leert is dat ontwikkel- en/of test servers NOOIT live data mogen bevatten! Zelfs als het een staging omgeving is met zoveel mogelijk overeenkomst met Live kun je de data altijd nog annonimiseren. Stap 1 van je kwaliteits plan!

[oezie]

Volgens mij heb ik die les gemist. Waarom kan een development- en of test server geen live data bevatten? Ik denk dat dat sterk afhangt van de omgeving waarin deze servers staan, het soort applicatie en of dit openbaar is of niet.

[djwice]

Persoonsgegevens mogen bij wet (NL maar ook EU) alleen gebruikt worden voor het doel waarvoor ze zijn afgegeven.
En er mogen alleen daarvoor noodzakelijke gegevens gevraagd en verwerkt worden.

Vaak is dat doel bijvoorbeeld het aan de klant kunnen leveren van een product of dienst.

Een ontwikkelaar, analist, tester, marketeer, beheerder etc. is, op het moment dat hij zijn werk uitvoerd, geen onderdeel van die keten. De levering kan plaats vinden, zonder hen.

Daarom mogen deze personen nooit die persoonsgegevens kúnnen in zien.


Zo komen ze ook niet, als persoon, in de verleiding de gegevens voor andere doeleinden te gebruiken (buurman, vriend, familie die klant is, ... gegevens inzien, wijzigen of ander gedrag naar aanleiding van wat je daardoor weet)

[Reactie gewijzigd door djwice op 22 juli 2024 22:33]

[Prx]

Ik meende me te herinneren dat ik hier, in het kader van de WBP, ooit wat over heb gelezen bij Arnoud Engelfriet. Hij plaatste eerder dit jaar het volgende op zijn blog:

Dat verhaal over toestemming en boetes wijst erop dat de klant denkt aan een overtreding van de Wet bescherming persoonsgegevens (Wbp). Natuurlijk staat daar nergens letterlijk in dat het verboden is om te testen met productiegegevens. Die wet zegt alleen dat je de gegevens mag gebruiken voor het doel waarvoor je ze hebt verkregen, en voor doelen die in duidelijk direct verband daarmee staan (art. 8 en 9 Wbp).

Het testen van de omgeving waarbinnen je persoonsgegevens wilt gaan gebruiken, lijkt mij zonder meer voldoende verband te hebben met het daadwerkelijk (productie) gebruik van die omgeving. Als er dus toestemming is voor het productiegebruik, dan ook voor validatie en acceptatie van de software die dat gaat doen.

Bron: http://blog.iusmentis.com...tiedata-persoonsgegevens/

Daarna zegt hij het volgende, en ik maak het even bold omdat ik deze wel heel mooi vind:

Tegelijkertijd kun je je afvragen of het echt wel nódig is om te testen met productiegegevens.

Het is natuurlijk de mening van een jurist, geen uitspraak van een rechter. Maar het gebruik van de gegevens zou dus wel kunnen, als je maar jezelf maar goed hebt afgevraagd of dat echt met die gegevens moet en hoe je die dan beveiligd. Dat laatste lijkt hier dus niet helemaal goed te zijn gegaan daar in de UK, op zijn zachtst gezegd.

[Rutix]

Behalve dan het hier wel beslaat om een derde partij waar geen toestemming aangegeven is. Mensen hebben Michael Page toestemming gegeven om hun persoonsgegevens te gebruiken voor het doel van de website. Ze hebben geen toestemming gegeven om die door te geven aan capgemni om te gebruiken in de test omgeving (die hoogstwaarschijnlijk ook nog eens bij capgemni ofzo staat).

[Prx]

Die toestemming om Capgemini persoonsgegevens te laten verwerken die Michael Page heeft verzameld wordt vastgelegd in een bewerkerovereenkomst tussen Capgemini en Michael Page. Dat is ook de hele intentie van Capgemini dan als bewerker zien. Jij als eindgebruiker zult dat dus nooit echt hoeven goedkeuren.

Bron: http://www.justitia.nl/privacy/bewerkersovereenkomst.html

Het feit dat een testomgeving ergens anders staat hoeft nog niet automatisch te betekenen dat die partij dan ook een bewerker is. Ook hier heeft Arnoud eerder dit jaar al iets over geschreven op Security.nl. In dit specifieke geval lijkt dat wel zo te zijn, maar aangezien die overeenkomst niet voor eindgebruikers inzichtelijk is, kunnen we daar weinig over zeggen. Wel is het dus zo dat een partij als Michael Page deze gegevens wel degelijk mag overhandigen aan Capgemini (voor o.a. test doeleinden), mits daar de juiste afspraken voor gelden.

Bron: https://www.security.nl/p...r+in+de+zin+van+de+Wbp%3F

De vraag of deze gegevens dus verwerkt hadden mogen worden is dan wel beantwoord. Maar wederom blijft het zo dat hier grove beveiligingsfouten zijn gemaakt en die gaan wel degelijk in tegen de afgesproken regels lijkt me.

[Reactie gewijzigd door Prx op 22 juli 2024 22:33]

[Rutix]

Bewerkersovereenkomsten worden wel meestal afgesloten als je een service afneemt ofzo. Het gevaarlijke van persoongegevens in de test omgeving beschikbaar te hebben is dat een ontwikkelaar data kan inzien waar die gewoon niks heeft te zoeken en het is gewoon tempting voor die mensen en dat wil je gewoon niet. Ik heb aan systemen gewerkt waar bijvoorbeeld BSNs enzo worden opgeslagen en ik had dus gewoon de data van mijn familie ofzo kunnen opzoeken. Dat is not done natuurlijk maar waarom mensen tempten?

[djwice]

Precies, voor hun werk is het niet noodzakelijk dat ze jouw persoonsgegevens zien.

Dat is m.i. essenieel onderscheidt met het noodzakelijk voor het leveren van een product of dienst aan jou.

Bij voldoende kennis van eigen systemen, is productie data niet nodig in een test omgeving die in te zien is door personeel dat zelf geen handmatige verwerking doet van die gegevens voor het leveren van het product of dienst.

Er zijn voldoende (open source) mok-data generatoren die, als je voldoende kennis van de mogelijke invoer (data formaat) hebt, een goede en reptesentative data set kunnen maken.

Ik ben het dus niet eens met de aannames van Arnoud in deze. (geboorte) datum, leeftikd, e-mail, BSN, wachtwoord, adres, telefoonnummer, iban, postcode, euro's, voornaam, achternaam, tussenvoegsel, allemaal velden waarvan je de structuur van de invoer redelijkerwijs echt wel moet weten. Voor al die velden mag je dus geen productie data, en ook geen afgeleide productie data gebruiken in een (software) test- of ontwikkelproces.

Er is simpelweg in geen enkele situatie noodzaak.

Er zijn vast veel systemen en processen waar productie data wordt misbruikt en persoonsgegevens door onbevoegden zijn in te zien.

Wellicht moeten we stellen dat 5 jaar na de invoering van de wet op privacy, dit niet meer geaccepteerd wordt en dat dit gebruik dus als een datalek zal worden geklassificeerd.

Waarbij het zwaar zal wegen als het bekend is en niet verholpen is.

[Reactie gewijzigd door djwice op 22 juli 2024 22:33]

[kakanox]

Mijn ontwikkel-, test- en acceptatie-omgeving bevatten gewoon de live gegevens. Teveel werk om die maandelijks te gaan anonimiseren.

Tegelijkertijd staat alleen de live-webservice open naar servers in DMZ, en daar is de beveiliging wel op orde.

Enige wat ik nog moet doen is alle externen ook laten tekenen voor geheimhouding, en een verbod opleggen voor het kopiëren van die data.

Vreemd genoeg heb ik het daarmee heel heel heel veel beter voor elkaar dan eigenlijk bijna alle softwareleveranciers waar ik mee te maken heb gehad.

[R4gnax]

Het is natuurlijk de mening van een jurist, geen uitspraak van een rechter. Maar het gebruik van de gegevens zou dus wel kunnen

IANAL, maar Engelfriet slaat daar mijns inziens de plank grof mis.
Jij geeft als consument toestemming om jouw gegevens voor een bepaald proces te verwerken. Dat staat compleet los van via welke implementatie dat proces loopt -- Dat zal jou als consument echt niets uitmaken en ook niets uit moeten of hoeven maken. -- en staat dus ook in geen verband met het testen van die implementatie.

[Prx]

Klopt, maar als consument wil je wel dat er goed met je gegevens omgesprongen wordt. Dat betekent dat jij dus ook verwacht dat software op een adequate wijze getest wordt. Als de IT leverancier dit dan wil doen met live data dan is daar wettelijk niets op tegen, kijkende naar de bronnen die ik heb gevonden hiervoor.

[R4gnax]

Klopt, maar als consument wil je wel dat er goed met je gegevens omgesprongen wordt. Dat betekent dat jij dus ook verwacht dat software op een adequate wijze getest wordt.

Volgens wet moeten de doeleinden waarvoor persoonsgegevens verwerkt worden ook in duidelijke, door leken begrijpbare, termen gesteld worden.

Vziw is het ook zo bij dit soort doeleinden waar een gewezen verband bestaat dat het bestaan van dit verband voor dezelfde consument duidelijk moet kunnen zijn.

Je kunt mijns inziens per definitie al niet er vanuit gaan dat mensen wel zullen begrijpen dat hun gegevens ook in interne procedures voor het testen van de verwerkingssoftware gebruikt gaan worden, want dat gaat uit van vakkennis.

[Reactie gewijzigd door R4gnax op 22 juli 2024 22:33]

[Prx]

Je kunt er wel vanuit gaan dat mensen verwachten dat er op de juiste manier met hun gegevens wordt omgesprongen, en dat betekent dus ook dat men verwacht dat systemen op een goede manier zijn getest, dat is daar inherent aan.

Wij verwachten toch ook dat de MRI/CT scanners in ziekenhuizen goed getest worden, en de apparatuur die gebruikt wordt om te opereren. Toch is dat ook niet iets waar ik om vraag, maar wel iets wat nodig is om mij de juiste dienstverlening te kunnen leveren. Of de auto's die we allemaal rijden. Iedereen zegt toch al heel snel "waarom is dat niet goed getest?".

Volgens mij gaat het dus wel hand in hand, en niet zozeer iets wat vakkennis nodig heeft.

[R4gnax]

Wij verwachten toch ook dat de MRI/CT scanners in ziekenhuizen goed getest worden, en de apparatuur die gebruikt wordt om te opereren.

Leuk voorbeeld. Ik heb er bijv. nog nooit van gehoord dat iemand gevraagd wordt om even in de scanner te springen voor een testrondje...

Of de auto's die we allemaal rijden. Iedereen zegt toch al heel snel "waarom is dat niet goed getest?".

En bij het testen van auto's gebruiken we voor een heleboel van de tests die geen menselijke bestuurder vereisen, crash-test dummies.

Dus zo 'normaal' is het niet dat echte personen of de gegevens van die personen terloops ook maar gevraagd of gebruikt worden om zaken te testen, heh...

[latka]

Zucht. Bij de slager om de hoek mag het wel. Bij financiële of persoonsgegevens mag het niet. Tenzij je dezelfde maatregelen als productie er voor wilt inzetten (en nee: dat wil je niet want je wil pielen en klooien).

[tERRiON]

In de omgevingen waar ik tot nu toe gewerkt heb, werd vaak genoeg "gepield en geklooid" met actuele data. Die testomgevingen hadden echter als groot verschil dat ze niet publiek toegankelijk waren.

[BugBoy]

Dat laatste is juist het probleem. Een lek vpn maakt een testomgeving al gauw "openbaar" en zo zijn er nog wel situaties denkbaar.

[tERRiON]

Klopt. Maar of het nou een VPN naar de productieomgeving is dat lekt of een VPN dat naar de testomgeving leidt dat lek is, maakt dan ook niet veel meer uit. Voor beide verbindingen zou de maximale veiligheid moeten gelden.

Dat is althans hoe ik met dergelijke verbindingen om ga.

[Reactie gewijzigd door tERRiON op 22 juli 2024 22:33]

[klakkie.57th]

Dit is gewoon best practice. Ontwikkelomgevingen zijn defacto minder veilig omdat je ontwikkelt en mogelijk steeds nieuwe en andere fouten introduceert.

Daarom heb je ook een code-freeze als je overgaat van Dev naar Prod en wordt deze code en omgeving uitvoerig getest door een third party (iemand anders dan de developer). Dit scenario herhaalt zich bij iedere update !!

[sympa]

Omdat op een testserver veel meer mensen inloggen en veel meer analyses gedaan worden om te kijken wat er mis kan zijn.
Op een productieserver heb je regels voor beheerders: niet in de records kijken, niet de mailtjes van de mailserver lezen. Op een testmachine doe je dat vaak juist wel. Als je dat teveel werk vindt, kies je beter een ander vak of je gaat zo een diepe smak maken "kijk hij maakt dit van de records" op pastebin of zo gekwakt of in een mailtje naar iemand die geen NDA heeft getekend.
Overigens gaat dit natuurlijk op voor vertrouwelijke data. Als het gaat om een testserver van het KNMI, waar de weersverwachting ter test wordt uitgerekend, wordt natuurlijk met productiedata gewerkt.

[oezie]

Dat is niet altijd het geval, zo hebben wij een test server bij een klant waar alleen het management en ons developmentteam kan inloggen, daarnaast wordt er in de applicatie met rechten gewerkt, of dit nou een test is of niet er wordt altijd gekeken naar deze rechten. Ook heeft iedereen die met gevoelige informatie van die klant te maken heeft een geheimhoudingsverklaring van de klant ondertekend. Het gaat hier overigens om een citrix omgeving waar men alleen in kan met een geldig account met TFA. Niet een websiteje welk publiekelijk beschikbaar is.

[Wim-Bart]

Volgens mij heb ik die les gemist. Waarom kan een development- en of test server geen live data bevatten? Ik denk dat dat sterk afhangt van de omgeving waarin deze servers staan, het soort applicatie en of dit openbaar is of niet.

De les op privacy. Sowieso is een test omgeving met "echte" data "not done" in geen enkele omgeving. Een test omgeving kan prima werken met geanonimiseerde data, zolang bepaalde constraints maar kloppen die nodig zijn om functioneel te testen. Alleen anonimiseren van data kost tijd en geld. En dat hebben veel bedrijven er niet voor over. Daarom zijn de boetes voor dit soort zaken ook veels te laag. In theorie moet de boete dermate zijn dat iedereen die er verantwoordelijk voor is dat dit kan gebeuren direct de arbeidsmarkt op moet om te solliciteren.

[Verwijderd]

Het hebben van live data op je testomgeving is heel normaal om alle uitzonderingen van "de echte wereld" te kunnen reproduceren. Dit is dus helemaal niet zo gek.

Als je dan toch Captain Hindsight wil uithangen had dan iets geroepen over hoe je je test omgeving niet publiekelijk toegankelijk moet maken.

[Rutix]

Ik weet niet waar jij vandaan haalt dat het heel normaal is maar dat is het zeker niet. Je gebruikt of test sets of je pakt live data en anonimiseerd deze. Je kunt me niet wijs maken dat echte live emails nodig zijn om uitzonderingen te testen. In elk software project dat ik werk is het uit den boze om echte live data te gebruiken en als een bedrijf wel live data gebruikt (welke nieteens van hun is want de data is eigenlijk van Michael Page) dan moeten ze echt hard achter de oren krabben waar de fuck zij mee bezig zijn.

[BugBoy]

Ondanks dat het absoluut not-done is, zie je het heel veel gebeuren. Het kost gewoon veel tijd (en dus geld) om een database goed te anoniemiseren. Dat is lang niet altijd even triviaal. Als je vrije tekstvelden hebt (bijv. een electronisch patienten dossier) dan is dit lastiger dan je denkt.

Wachtwoorden daarentegen zijn heel eenvoudig goed te managen in een testomgeving. Ook is er geen excuus om geen gedegen salted-hashed passwords op te slaan. Toch zie je dat ook nog wel eens fout gaan...

[Reactie gewijzigd door BugBoy op 22 juli 2024 22:33]

[Rutix]

Natuurlijk is niet alles makkelijk te anonimiseren maar de triviale velden die hier werden gebruikt waren dat makkelijk. Daarnaast ging het mij meer om dat mensen het "normaal" noemen. Het is nooit normaal en het moet altijd een uitzondering zijn en goed overwogen worden voordat je die beslissing neemt.

[latka]

Het kost ook tijd en geld om je productieomgeving te beveiligen. Als het een serieus bedrijf is gebeurt dit niet. Als je weggelachen wordt als je zegt dat dit echt niet zo kan is het tijd om met professionals te gaan werken (en cap Gemini valt daar zeker niet onder)

[metalmania_666]

Banken en verzekeraars maken vaak ook gebruik van live bestanden om te testen.
Gaat dan ook vaak om grote bestanden, en dan is het niet te doen om dat allemaal te anonimiseren.
Belangrijk is wél dat je de gegevens goed afschermt

[nicenemo]

Hoezo? Is op zich simpel om een random dataset te genereren? je pakt een lijst met voor en achternamen, de lijst met officiele voorvoegsels, en je pikt random namen uit die lijsten. Eenvoudig in .NET of Java te programmeren. In .NET met LINQ en in Java 8 met Streams. In Java 7 met een backport. Simpel arrays waaruit je per random index iets plukt. Maak een random character generator en gebruik die 4x voor de cijfers van een postcode met de set 0-9. Vervolgens A-Z 2x voor de letters. vervolgens een huisnummer tussen de 1 en 6 cijfers. Dan nog wel of geen toevoeging en wel of geen aanduiding. Straatnamen generator is ook eenvoudig te maken met woordenlijsten/namen lijsten en achtervoegsels als laan/straat/weg of geen achtervoegsel. BSN generator kun je ook eerst dom maken door 9 cijfers te pakken en kijken of ze 11 proof zijn. Geboortedatum generator er bij is ook eenvoudig. Met wat nadenken kan het slimmer. Hetzelfde voor banknummers, is ook een 11 proof maar dan anders. Met een middagje heb je de basis voor elkaar. Met nog een halve dag heb je voor adres plus bsn plus bank gegevens de set compleet. Geslachtsaanduiding en code naamgebruik maken het geheel compleet. Ik heb dit voor C# als Java gedaan als een vorm van poor mans property based testing. Voor Functionele talen kun je dit met property based testing nog mooier maken door er echte generators van te maken voor QuickCheck, Scala Check, FsCheck (Haskell, Scala, F#).

Zelf doen?
Stap 1 In .NET maak een Enumerable die een oneindige lijst van integers ophoest tussen de 0..n.
Stap 1 In Java kun je hetzelfde doen maar de jdk 1.8 Random levert al een integer stream op.

Stap 2 maak een functie die een eindige enumerable gebruikt als bron voor random waarden gebruik de generator uit stap 1. Genereer een oneindige lijst van integers in de range 0.. length-1 van de gegeven eindige enumerable.
In .NET doe een LINQ select om de waarde uit de eindige lijst te produceren.
In Java gebruik de stream map functies.

Stap 3 Maak varianten van de bovengenoemde functies voor variable aantal argumenten. zodat je iets kunt doen als generate("man","vrouw","onbekend","iets anders"). Dit kan zowel in C#, Java als in VB.NET.

Stap 4 Maak waar nodig overloads voor longs en andere primitieve typen.

Stap 5
Voeg in ieder geval een toe:
Een generator die gegeven een string een random enumerable/stream van characters ophoest.
In Java is het handig om een hulp functie te hebben die een array naar een stream omzet.

Stap 6: Met bovenstaande basis uit stap 1...6 kun je meer specifieke generators maken zoals postcode en bsn generators.

In .NET maak je gebruik van LINQ in Java gebruik je de LINQ evenknie streams.

[Reactie gewijzigd door nicenemo op 22 juli 2024 22:33]

[kakanox]

Snap niet waarom jij naar nul gemod wordt. Best boeiend, ontopic, en nuttig.

Thanks voor de tip.

[martijn_tje]

Ik weet dat mijn werkgever een gehusselde set data gebruikt voor test omgevingen. voorletters, namen adressen geboortedata enz. alles gehusseld (BSN's, telefoon nummers en geboorte data nieuw ramdom gegenereerd).

[sympa]

Ik kan me een geval herinneren waarin met productiedata werd gewerkt in test. Omdat men de data niet snapte en niet capabel was om dit uit te pluizen.
Ook dan had men wel een 1-1 mapping kunnen toepassen op alle data om alles consistent maar toch gehusseld te maken natuurlijk.

[Verwijderd]

Okey,

Je heb je database vol gestopt met voornamen en achternamen. In een voornaam of achternaam komt normaal geen "?" in voor, dus laat je dat niet genereren in je testomgeving.

Nu komt er op Live een klant en die vult TOCH een ? bij zijn naam in. Hierdoor crashed het interne systeem wat bestanden genereert op basis van naam, en wat je ook doet, het werkt gewoon op de TEST, maar op PRODUCTIE crashed het!

[nicenemo]

In de test database voor b.v. de Nederlandse BRP zitten die wel. Natuurlijk stop ik die er in. Testen met y umlaut(255) en letters met andere accenten, Griekse karakters, Chinees, spaties, tabs, cijfers, ASCII BEL, ASCII 0, null, byte order marks doe ik ook. Iets vergeten? O ja lege string en meer dan 2k voor een naam(urls...)

Aardig wat software crashed op y umlaut of een ASCII 0. Mijn eerste test is altijd Bädkūįpenræçę1! O.i.d.

[Reactie gewijzigd door nicenemo op 22 juli 2024 22:33]

[Rutix]

Dat is niet altijd zo hoor. Wij hebben projecten gedaan voor verzekeraars en banken en daar hadden ze gewoon een grote test set. Die was wel afgeleid van de live data maar wel geanonimiseerd. Als je een beetje tijd en effort erin steekt dan kun je prima goede geanonimiseerde data generen of afleiden.

[Verwijderd]

Ook Bol.com doet dit.
Live Data open en bloot gebruiken voor testen, analyses en voor het testen van nieuwe website updates.

[Rutix]

Ik weet niet waar je dit vandaan hebt maar zover ik weet gebruikt bol.com niet de persoons gegevens in de test omgeving. Als ze dat wel doen dan zijn ze al fout bezig. Bij wet is namelijk verboden om persoonsgegevens te gebruiken voor iets anders dan het doel waarvoor ze zijn afgegeven. En daar komt bij dat het toch wel een andere situatie is dan in deze. Bol.com is namelijk de ontwikkelpartij EN eigenaar/beheerder van de productie database. Dat is hier niet zo, Michael Page is namelijk de eigenaar/beheerder en capgemni is de ontwikkelaar. Daar zit namelijk een groot verschil in.

[Reactie gewijzigd door Rutix op 22 juli 2024 22:33]

[Brawler1986]

Ik denk dat AsunaRR AB-testen bedoeld. Een gedeelte van een website in verschillende variaties laten tonen aan gebruikers en deze analyseren. Het is live data, maar niet privacy gevoelige data. Deze data word vaak opgeslagen in een data-warehouse en puur gebruikt voor analyseren van gedrag op websites. Ook hier, geen privacy gevoelige informatie. Hetzelfde als auto's tellen op de weg om te kijken of het druk is, of mensen hard rijden, of als er file staat. Dit is digitale wereld niet anders.

[Reactie gewijzigd door Brawler1986 op 22 juli 2024 22:33]

[Rutix]

Precies. Daarnaast gebeurt AB-testen op de productie omgeving en niet op de test omgeving .

[Brawler1986]

Tenzij je natuurlijk een AB-test test

[Rutix]

Maar daar heb je weer niet de productie persoongegevens voor nodig

[sympa]

Die AB-testen zijn twee productie-omgevingen naast elkaar. Een rode webshop en een blauwe webshop, en dan kijken wat de klanten doen. Dat is niet hetzelfde als een testomgeving.

[doom71]

Wanneer het gaat om privacy gevoelige info, dan is het formeel niet toegestaan. Je gaat namelijk mensen (lees: testers, ontwikkelaars) data ter beschikking stellen waarvoor zij niet gemachtigd zijn deze in te zien. Je zult dus zelf test data moeten maken wat qua opbouw overeenkomt met productie data.

[Erwin1967]

Er is altijd nog een verschil tussen theorie en praktijk. Dergelijke grote bedrijven werken vaak met jonge onervaren mensen om de kosten te minimaliseren. Ze werken echter onder verantwoordelijkheid van het bedrijf en de verantwoordelijke manager zal moeten gaan uitleggen waarom hij dit soort zaken niet onder controle had. Dit soort zaken zijn al reden voor ontslag op staande voet...

[CMD-Snake]

Dergelijke grote bedrijven werken vaak met jonge onervaren mensen om de kosten te minimaliseren.

Ze werken ook veel met goedkope krachten uit lage lonen landen. Bedrijven als Capgemini laten vrijwel al het beheer- en ontwikkelwerk uitvoeren in landen als India. De opleidingsinstituten daar produceren "IT'ers" bij bosjes die allemaal voor een grijpstuiver willen werken. Het gebrek aan kwalitatief personeel wordt ruimschoots goedgemaakt voor door kwantiteit en goedkoopte, althans, vanuit het perspectief van dit soort grote software huizen.

Het zal wel een combinatie zijn van gebrek aan kennis en gemakzucht. Ik snap eigenlijk waarom een ontwikkelomgeving is verbonden met het internet. Daar zou geen reden voor moeten zijn. Die zou enkel op je interne netwerk bereikbaar moeten zijn.

[sympa]

Een ontwikkelomgeving moet vaak wel verbonden zijn met "internet" omdat je externe partijen toegang wil geven. Op zijn minst via een VPN.
Als je denkt alles zelf te kunnen, of de mensen maar te laten invliegen, dan word je ingehaald door de concurrentie. En ik zou dan ook maar geen email of post meer gebruiken maar de brieven zelf langsbrengen.

[Wim-Bart]

[...]


Ze werken ook veel met goedkope krachten uit lage lonen landen. Bedrijven als Capgemini laten vrijwel al het beheer- en ontwikkelwerk uitvoeren in landen als India. De opleidingsinstituten daar produceren "IT'ers" bij bosjes die allemaal voor een grijpstuiver willen werken. Het gebrek aan kwalitatief personeel wordt ruimschoots goedgemaakt voor door kwantiteit en goedkoopte, althans, vanuit het perspectief van dit soort grote software huizen.

Het zal wel een combinatie zijn van gebrek aan kennis en gemakzucht. Ik snap eigenlijk waarom een ontwikkelomgeving is verbonden met het internet. Daar zou geen reden voor moeten zijn. Die zou enkel op je interne netwerk bereikbaar moeten zijn.

Daarom zou ik ook nooit zaken doen met een bedrijf als Cap. Ze missen namelijk de letter "R" in de naam "Cap Gemini"..... "cRap Gemini".

[Verwijderd]

Eerste wat men in de de IT doet is aan de slag gaan.

[valvy]

Wat ik niet helemaal snap is dat de wachtwoorden versleuteld zijn en niet gehashed zijn met een salt erover heen hebben.

Capgemini moet zich diep en diep schamen hiervoor

[diyoo]

En die hbo/wo-er heeft de bevoegdheid om prioriteiten binnen een project vast te stellen? Uit eigen ervaring kan ik je vertellen dat bijna nooit zo werkt. De ontwikkel teams en software architecten hebben over het algemeen prima voor ogen waar de beveiliging schort, waar de performance bottlenecks zitten, e.d.. In veel gevallen wordt dit ook constant herhaald naar management, en soms zelfs de board of directors. Maar toch staat het korte termijn belang van de organisatie (nieuwe features/klanten) vaak haaks op het oplossen van beveiligingsproblemen, performance bottlenecks, e.a. zaken die niet direct geld opleveren. In mijn ervaring worden belangrijke zaken als beveiling en performance door een organisatie pas als prioriteit gesteld als grote klanten gaan klagen (beveiligingsaudit eisen bv), of als er een (bijna) hack heeft plaatsgevonden.

Begrijp me niet verkeerd, ik vind ook dat je als team van ontwikkelaars (ongeacht opleidingsniveau) moet strijden om de zaken goed op orde te krijgen. Maar de praktijk leert dat je vaak niet veel meer kan doen dan dat; of je moet ontslag indienen. Uiteindelijk zijn het de eigenaren, board of directors, e.d., die de beslissingen nemen, en die zien beveiliging van gegevens van derden helaas maar al te vaak niet als belangrijkste investering op de korte termijn.

Persoonlijk probeer ik dit soort organisaties zoveel mogelijk te vermijden. Jammer genoeg loop je in de industrie maar al te vaak tegen een muur van onwil aan, omdat "we" toch liever die klant die een paar miljoen oplevert binnen te hengelen.

[Reactie gewijzigd door diyoo op 22 juli 2024 22:33]

[BugBoy]

Het is vaak geen kwestie van intelligentie, maar een kwestie van tijdsdruk, gemakzucht, kosten, ...

[RagingPenguin]

Maar meer mensen kost meer geld en dat is vaak het probleem. Op een of andere manier zijn het altijd de grote jongens die geen geld hebben voor fatsoenlijk personeel.

[R4gnax]

Het is degelijk wel intelegentie.

Het is wel degelijk intelligentie, maar niet van de ITers.

De beslissing om met kopieën van live data te werken ipv mock data en de beslissing om deze al dan niet te anonimiseren worden niet genomen op niveau van ontwikkelaars of onderhoudspersoneel.

Dat zijn beslissingen die genomen worden door veel te duur betaalde 'managers', die een kans zien om wat uren te besparen die niet makkelijk gefactureerd kunnen worden of die niet passen binnen de beraming van een fixed-price project.

Niet echte managers met het verstand om beslissingen uit te besteden aan hun personeel en dus enkel te managen ipv te leiden, maar het soort van omhoog gevallen mislukkeling met een BA en een vlotte babbel dat om de een of andere reden altijd veel te makkelijk via recruiters die er vage half-bakken zweverige sollicatie-procedures op na houden, een voet binnen de deur weet te krijgen bij grote bedrijven.

[Reactie gewijzigd door R4gnax op 22 juli 2024 22:33]

[ViNyL]

Dat is niets nieuws. Er is een hele Zembla aflevering over.

http://www.npo.nl/zembla/02-09-2015/VARA_101375763

[JoepW]

Fijn hoor mijn zakelijke e-mail adres op straat

[WouterT13]

Volgens het artikel gaat het om ethische hackers en dus hoef je je als het goed is geen zorgen te maken.

[klakkie.57th]

Maar we weten niet hoelang het lek al bestond. Er kunnen tientallen on-ethische hackers hun voorgegaan zijn.

[WouterT13]

Dat is natuurlijk waar, maar voor nog niet bekende lekken geldt hetzelfde. Ik durf te stellen dat elk systeem wel zo'n lek heeft. Dit praat natuurlijk niet goed dat er een lek was dat gevonden kon worden.

[JoepW]

Gelukkig

[Erwin1967]

Michael Page is hiervoor verantwoordelijk. Zij hebben besloten om Cap Gemini in te huren met alle gevolgen van dien.

[JoepW]

Ja en? Wat is de toegevoegde waarde van die constatering als reactie op het feit dat ik er vreselijk van baal dat mijn zakelijke mail adres nu op straat ligt.

[Prx]

Also, as with the Red Cross the individual who reported the leak has deleted the data he obtained and every trace of the backup I had is also gone. Of course, these are the instances of the data we know of but the commitment is the same as the last time: all known copies of the data have been removed.

Bron: https://www.troyhunt.com/...y-facing-database-backup/

Deze partij heeft dus niets openbaar gemaakt en dit direct kenbaar gemaakt bij de betrokken partijen. De kans lijkt me dus erg klein dat jouw zakelijke e-mailadres nu op het grote boze internet terecht is gekomen.

[Rutix]

De vraag is natuurlijk wel welke mensen hebben nog meer gebruik gemaakt van die lek zonder het te melden? Als die lek al een hele tijd open staat is de kans helemaal niet zo klein dat zijn zakelijke e-mailadres op het grote boze internet is gekomen.