Orange waarschuwt klanten na diefstal van persoonsgegevens

Orange België heeft klanten per mail gewaarschuwd dat onbevoegden een testsysteem met daarop klantgegevens zijn binnengedrongen. Ze zouden onder andere toegang hebben gekregen tot identiteitskaart-, rijksregister- en rekeningnummers.

De ongeoorloofde toegang vond plaats in de maand mei, volgens de mail. Onder de gegevens die zijn ontvreemd, zijn de namen, adressen, e-mailadressen, telefoonnummers en nummers van identiteitskaarten, rijksregisternummers en rekeningen. Op de testservers stonden geen creditcardgegevens of facturen.

Orange waarschuwt dat klanten te maken kunnen krijgen met phishingpogingen en identiteitsdiefstal. "We raden je aan heel erg voorzichtig te zijn, vooral in het geval van verdachte verzoeken voor een betaling of voor het meedelen van een wachtwoord of kredietkaartnummer." Tegenover Techzine maakt het bedrijf bekend dat het om gegevens van vijftienduizend klanten gaat. Welke gegevens op straat zijn beland, verschilt van klant tot klant.

Het bedrijf claimt de beveiliging van zijn servers verbeterd te hebben en de Belgische Gegevensbeschermingsautoriteit op de hoogte te hebben gesteld van het datalek.

Reacties (71)

[slm]

Wat ik me vooral afvraag na het lezen van dit bericht is waarom ze rijksregisternummers en nummers van identiteitsbewijzen hebben. Dit kan enkel verantwoord worden door de verplichting ter identificatie van prepaid kaarten. Dan nog rest de vraag waarom deze gegevens op dezelfde (test!)server stonden en of ze dan wel (nog afgezien van het AVG) hebben voldaan aan hun wettelijke verplichting gezien artikel 126 van de WEC. Het niet naleven van deze regels kan strafrechterlijk worden vervolgd.

Op de vraag waarom ze zo lang (2 weken!) hebben gewacht met het inlichten van de gebruikers zelf werd door Orange geantwoord :

Our experts needed the time to investigate and confirm the breach. As soon as we received all details we informed the impacted customers and took all necessary actions.

Sorry, maar twee weken is echt veel te lang. Dit voorval mag niet zomaar onder de mat geschoven worden en slechts een tik op de vingers opleveren.

[KoensSocialL]

Ze hebben nu al GDPR aan hun voeten gevreegd. Volgens HLN zou dit al 2 weken bekend zijn maar zijn de klanten pas gisteren op de hoogte gebracht, veel later dan de 72 uur van europa..

Edit: de link van het bewuste artikel van HLN

[Reactie gewijzigd door KoensSocialL op 25 juli 2024 03:09]

[IStealYourGun]

Die 72 uur is enkel van toepassing op de DPA:

"Indien een inbreuk in verband met persoonsgegevens heeft plaatsgevonden, meldt de verwerkingsverantwoordelijke deze zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur nadat hij er kennis van heeft genomen, aan de overeenkomstig artikel 55 bevoegde toezichthoudende autoriteit, tenzij het niet waarschijnlijk is dat de inbreuk in verband met persoonsgegevens een risico inhoudt voor de rechten en vrijheden van natuurlijke personen. Indien de melding aan de toezichthoudende autoriteit niet binnen 72 uur plaatsvindt, gaat zij vergezeld van een motivering voor de vertraging."

https://eur-lex.europa.eu...CELEX:52018DC0043&from=EN

[Martin.Air]

Onder de gegevens die zijn ontvreemd, zijn de namen, adressen, e-mailadressen, telefoonnummers en nummers van identiteitskaarten, rijksregisternummers en rekeningen.

Dit is zeker in verband met persoonsgegevens, deze gegevens zijn namelijk genoeg om een volledige identiteit over te nemen.

[WouterL]

Ja en nee. Soms is het wenselijk dat de betrokkene zelfs éérder op de hoogte wordt gesteld dan het toezichthoudende orgaan. Hoewel de zinsnede onverwijld inderdaad een rekbaar begrip is, is het voorstelbaar dat het zelfs wenselijk is dat de melding aan de betrokkenen écht onverwijld op de hoogte wordt gesteld.

Denk hierbij aan gegevens die zouden kunnen leiden tot (identiteits-)diefstal.

('' the controller will need to notify the affected individuals
without delay. For example, if there is an immediate threat of identity theft, or if special categories of
personal data18 are disclosed online, the controller should act without undue delay to contain the
breach and to communicate it to the individuals concerned (see section IV). In exceptional
circumstances, this might even take place before notifying the supervisory authority'')


Los van de 72-uur: partijen mogen eerst een kort en gedegen onderzoek instellen om de scope en reikwijdte vast te stellen van de inbreuk, alvorens zij een melding doen aan de Autoriteit. Een organisatie wordt pas 'aware' wanneer zij ook daadwerkelijk weet wat er is gebeurd. Dit kan soms enige tijd in beslag nemen.

[Panini]

Volgens HLN zou dit al 2 weken bekend zijn maar zijn de klanten pas gisteren op de hoogte gebracht, veel later dan de 72 uur van europa..

Je bent wat in de war denk ik. De betreffende klanten hoeven niet binnen 72 uur op de hoogte worden gebracht. Dat moet gebeuren zonder 'onredelijke vertraging' volgens de AVG. Dit is een redelijk rekbaar begrip.

Het datalek moet wel binnen 72 uur gemeld worden bij de betreffende privacytoezichthouder. Of dat werkelijk is gebeurd kan je niet uit het artikel halen. Er staat enkel dat het gemeld is. Ook al gebeurd het niet binnen 72 uur, dan biedt de AVG hier zelf een uitweg voor:

Overweging 85 in de AVG: 'Wanneer die kennisgeving niet binnen 72 uur kan worden gerealiseerd, dient de kennisgeving vergezeld te gaan van een verklaring voor de vertraging en kan de informatie zonder onredelijke verdere vertraging in fasen worden verstrekt.'

Veelal betekent dit dat een initiële melding binnen 72 uur wordt gedaan en dit aan wordt gevuld.

En hoe zie je het voor je? Dat je binnen 72 uur het lek onderzocht hebt met alle verwerkers en subverwerkers die erbij betrokken zijn, daarna dit meldt bij de toezichthouder, rapport hiervan opstelt intern, het langs alle interne organen laat gaan en dan nog even alle 15000 klanten op de hoogte stelt ervan?

Ik hoop dat je inziet dat dit onmogelijk is

Edit: ik zie dat ik spuit 11 ben hierbij

[Reactie gewijzigd door Panini op 25 juli 2024 03:09]

[Androo]

Volgens mij moeten ze het binnen 72u melden aan de autoriteit persoonsgegevens.
En niet binnen 72u naar de klanten..?

[AtlAntA]

Waarom zou een test server gegevens van echte klanten gebruiken? Is het niet veiliger om dummy gegevens te gebruiken?

[Blokker_1999]

Omdat het niet zo eenvoudig is om snel even realistische testdata te genereren voor zoveel records.

[AtlAntA]

Dat zal best maar dan maar wat meer werk om dummy gegevens te creëren toch? Lijkt me dat er wel een script voor te schrijven is, als die niet al bestaan. In mijn optiek is dit onacceptabele laksheid geweest.

[MrAndy9797]

Testserver dient om dingen te testen die later in de productie zullen verschijnen. Waarom dan niet met een kopie van echte data werken? Waarom extra werk steken in het genereren als je het op een dienblad hebt? Ja, er had wat extra aandacht mogen gaan naar de beveiliging. Maar er is niks mis met het gebruik van een kopie van echte live data.

Ik denk dat je wat achtergrondkennis en/of ervaring mist om dit te begrijpen, overigens geen verwijt, ik zal ook over andere dingen te weinig ervaring / kennis hebben waar jij dat wel hebt.

De laksheid zit in de beveiliging, niet in de gebruikte database

[eric.1]

De enige reden is dus gemakzucht

Waarom extra werk steken in het genereren als je het op een dienblad hebt?

.

Dat kan je zo nooit verantwoorden.

[MrAndy9797]

Niet zo zeer weinig heb het hier al 3x ergens gezet: Als het bijvoorbeeld om een server voor datamigratie is, gebruik je best inderdaad een kopie van echte gegevens, omdat dit zo'n moeilijk proces is.

Zo zijn er nog voorbeelden. Verder is het niet doen om uitdagende testdata te genereren. Echte data is (korter bij) de realiteit en brengt het best hedendaagse issues naar boven. Tenslotte gaan de features van de testserver ooit live, waarom dan niet testen met een kopie van de livedata? Het is bedoeld om intern te gebruiken. Dat het aangevallen is, is een andere zaak.

[Tarij]

Waarom zou je deze testomgeving super goed beveiligen als dit niet het doel is van je test. Is dat geen verspilde moeite en geld? Beter geanonimiseerde data gebruiken dan is de beveiliging ook niet meer zo belangrijk lijkt mij. Had hier in ieder geval een hoop gedoe gescheeld dus waarom extra werk in plaats van een dienblad lijkt dit me het perfecte voorbeeld.

Plus de gegevens zijn gewoon van een ander en daar hoor je gewoon voorzichtig mee om te gaan. Dus alleen gebruiken waarvoor het bedoelt is en aan je toevertrouwd is, niet hier en daar een testje op draaien.

[Reactie gewijzigd door Tarij op 25 juli 2024 03:09]

[klakkie.57th]

Ik zou de gdpr regelgeving er nog maar een keer op nalezen.

How GDPR impacts Testing

Production data cannot simply be copied as-is. Amongst the new regulation introduced by GDPR is the right of restriction on the use of personal data information. If production data is sourced for testing, data managers need to use anonymization techniques, applying to all personal identifiable information, and this process must be irreversible. This emphasizes the need for good documentation of data flows, data models, and adequate test data profiling. If there are any existing anonymization techniques in place, organisations need to take stock of their current masking techniques and determine whether additional controls are needed. As GDPR stresses the need to safeguard data that gets transferred to countries outside the EU, organisations must ensure a purge mechanism to erase any requested data from all data sources once the testing is complete

[Reactie gewijzigd door klakkie.57th op 25 juli 2024 03:09]

[KeiFront]

Het genereren van realistische testdata is zeer eenvoudig, helaas is het overtuigen van Management en Application Owners om geen productie data te gebruiken in een test omgeving de grootste struikelblok binnen organisaties .

Orange gaat hier namelijk zwaar in de fout, productie data op test systeem en het test systeem was vermoedelijk door de buitenwereld te benaderen (mailtje van Orange blijft vaag).

[Reactie gewijzigd door KeiFront op 25 juli 2024 03:09]

[ToolkiT]

het hangt natuurlijk ook af van de aard van de applicatie..
Zo heb ik wel test omgevingen gehad met veel historische gegevens van een complexe global payroll applicatie.. dat genereer je niet makkelijk..
Je kan wel de historische data anonymiseren..

[SinergyX]

Er zijn bedrijven die zulke test-sets on the fly kunnen leveren, best mogelijk dat ze bv ook bepaalde tests moeten uitvoeren op bankrekeningnummers (11 proef) of BSN nummers, maar ze hadden genoeg mogelijkheden om data op een testserver aanzienlijk stuk minder bruikbaar te maken.

Random voorbeeld:
http://www.iri.com/blog/test-data/netherlands-social-fiscal/

[!nFerNo]

Je smijt de INSZ weg, plopt er een random nummer in die overeen stemt met een random geboortedatum, dan pak je de adressen, voor en achternamen en gooi je alles door elkaar.

[xTmPizzaMan]

Wat een kant en klare onzin. Het genereren van testdata (rekeningnummers, bsn, persoongegevens) is makkelijk te doen. Zolang je het maar niet met de hand wilt doen. Als je even je best doet heb je in twee dagen je code klaar die genoeg records kan genereren.

[Stoelpoot]

Hoewel het natuurlijk niet hoort, is live data de meest representatieve set data die je ooit zal krijgen. Vaak is testdata een set die bij elke test wordt gegenereerd, waardoor eventuele edge cases na datamigraties e.d. buiten de boot kunnen vallen. Zeker in lang-levende systemen en systemen met meerdere migraties achter de rug is dit een grote zorg.

[RobinJ1995]

Ja. Maar namen, addressen, en al *zeker* identiteitskaartgegevens op zijn minst onbruikbaar maken op de ene of de andere manier is gewoon basis. Dit is niet acceptabel. Testservers horen geen echte klantgegevens te bevatten.

[Blokker_1999]

Maar door de data onbruikbaar te maken bestaat weer de kans dat je de data niet representatief maakt. Om 15k records betrouwbaar aan te maken ben je wel even bezig.

[bussie66]

Data op test- en acceptatie-servers ed. horen geanonimiseerd te zijn!

Met geanonimiseerde data is prima te testen spreek ik uit ervaring.

Om 15 k records betrouwbaar te anonimiseren is geen enkel probleem. Eenmalig hier een programma / script voor maken en klaar is Kees!

[gjmi]

Die registratie nummers omgooien, zou het minste zijn. En het is echt geen rocketscience om bruikbare gebruikers gegevens te maken, helemaal niet als je in de business zit. Alleen is het altijd nog makkelijker om een kopietje te trekken.

[robvanwijk]

Die registratie nummers omgooien, zou het minste zijn.

Helemaal mee eens.

En het is echt geen rocketscience om bruikbare gebruikers gegevens te maken

Om "bruikbaar" te zijn voor tests moeten er alle rariteiten inzitten die je ook in je echte data hebt. Dus rare tekens in namen, postcodes die oorspronkelijk geldig waren maar nu niet meer, wazige constructies in emailadressen, allerlei toevoegingen aan huisnummers, etc., etc., etc. Ja, nummers (of dingen die daar zeer sterk op lijken, zoals ISBNs waarvan het laatste "cijfer" ook een "X" kan zijn) kun je betrouwbaar faken, maar voor alles wat uiteindelijk een string is... nee sorry, daar gaan rare dingen tussen zitten. Of je het acceptabel vindt dat hiervoor echte data wordt gebruikt is iets wat je zelf zult moeten beslissen, maar ik vind het in elk geval begrijpelijk dat deze keuze is gemaakt.

[gjmi]

Ik denk dat ik met een simpel stukje software meer rare namen /nummers/postcodes kan maken dan in werkelijkheid voorkomen.
In een bestand met 15k echte records zullen lang niet alle rare dingen zitten, omdat de meeste namen/adressen geen rare constructies hebben.

[Reactie gewijzigd door gjmi op 25 juli 2024 03:09]

[ToolkiT]

Mijn ervaring is dat 'reality is stranger than fiction' oftewel wat je genereerd is op basis van wat je zelf kan verzinnen, en dan kan je dus scenarios missen..

[gjmi]

Helemaal eens met bepaalde data. Op mijn werk is echte data goud waard vergeleken met de test data die we maken. (Continu gigabytes per seconde interpreteren).
En misschien stel ik me dit ook te simpel voor, een beperkt aantal strings per record. En die met (semi) random string vullen.
Ik kan me vergissen.

[ToolkiT]

Het hangt helemaal van je applicatie af..
Is het een enkele table met data is het simpel.. is het een complexe applicatie met duizenden tables met allerlei verbanden word het veel lastiger om complexe dummy data te maken welke representatief is...

Zeker als je performance testing doet dan is volume en complexiteit van je data belangrijk..
@cracking cloud
Soms is het gewoon niet realistisch om test data te genereren, en is de enige praktische oplossing om 1 omgeving te refreshen van PROD en die data te anonimiseren. Die omgeving moet wel dezelfde beveiligings regels hebben als PROD natuurlijk..

[cracking cloud]

Als je dan in de praktijk rare dingen tegenkomt die nog niet in je testdata zaten dan voeg je dat alsnog toe aan je testdata.

Er is absoluut 0,0 reden om echte data in een testomgeving te gooien.

[robvanwijk]

Als je dan in de praktijk rare dingen tegenkomt die nog niet in je testdata zaten dan voeg je dat alsnog toe aan je testdata.

Misschien zie ik iets over het hoofd, maar dat klinkt alsof je, in plaats van test en productie, het inricht als "eerste, soort-van test" en "tweede, echte test + productie". Met andere woorden, testen in productie...

[Tozz]

Probleem is dat dat stukje software dan geen straatnaam zal genereren voor het postcode veld. En dat is iets dat in het echt wel voor zal komen als een gebruiker data invult in het verkeerde veld. Het issue met gegenereerde data is dat het altijd erg gestructureerd is. De werkelijkheid is niet zo fraai

[Tarij]

Je kunt ook je echte data schudden als een pak kaarten. Gegevens kloppen niet meer en zijn niet meer persoonlijk maar je hebt toch "realistische" data.

[jpsch]

Ligt aan de data. Schudden van medische gegevens kan een bevalling opleveren van een meneer met een verwijderde baarmoeder. Wat je dan test vraag ik me af.

[DigitalExorcist]

Er zullen toch wel een soort Lorem Ipsum generatoren zijn voor databases?

[winkbrace]

Ja, meeste programmeertalen hebben wel een 'Faker' library.

Mijn persoonlijke favoriet is https://github.com/HydrefLab/jedi-faker

Maar bij grotere data sets zou ik gewoon de email adressen vervangen met {userid}@company.com in 1 grote update.

[Stoelpoot]

Ik praat het ook zeker niet goed. Maar er zijn factoren die het gebruik van echte data vele malen nuttiger maken dan gefabriceerde data.

[ToolkiT]

Mee eens, zeker als je data consistentie en verbanden wil testen, als je scrambled kan je dan problemen krijgen..
Maar in principe moet je dat hoog uit in 1 omgeving hebben.. en die omgeving net zo sterk beveiligen als je production..

[Verwijderd]

Anonimiseren. Behoudt de 'echte' data zijn structuur en is dus nog representatief, maar niet te herleiden naar echte personen.

[Stoelpoot]

Dat zou inderdaad de minimale aanpak moeten zijn, ja. Een set van 100 voornamen, achternamen en een paar tussenvoegsels levert al gauw duizenden unieke namen op, die daarna aan een mailadres worden gekoppeld. Adressen is nog makkelijker.

[CyberJack]

Dan nog zijn grote datasets via een geautomatiseerd proces te anonimiseren.

Het zal voor een test namelijk niet uitmaken of "nummers van identiteitskaarten" nu echt zijn, of verzonnen, zolang ze maar door de zelfde validatie gehaald kunnen worden. Het zelfde geld voor namen, adressen, e-mail adressen en telefoonnummers, rijksregisternummers en rekening nummers.

Meestal is het gebruik van live data op een test omgeving puur luiheid. Het opzetten van een proces wat geautomatiseerd data goed kan anonimiseren kost tijd (en dus geld). Even live data pakken is dan veel sneller. Privacy e.d. gaat vaak pas een rol spelen als een test omgeving gehacked of misbruikt wordt (zoals nu dus).

[anboni]

Wat ik minstens zo schokkend vind, is dat een dergelijk test systeem blijkbaar via internet te benaderen is. Dat je echte gegevens gebruikt op een testsysteem is nog enigszins te verdedigen, maar zo'n testsysteem hoort in een geisoleerde omgeving te draaien en zeker niet via internet te benaderen te zijn.

[Primuszoon]

Sommige testsystemen tussen verschillende instanties (bvb nummerportering van providers) kan niet anders dan over het internet verbonden te zijn.

[anboni]

Da's waar, maar dan is het dus weer zaak om test-data in je database te hebben zitten. In deze situatie is de meest capitale fout de combinatie van echte gegevens en gekoppeld aan internet.

[ieperlingetje]

Ik schrik er minder van dat de inbraak via een test systeem gebeurde. Meestal zijn die slechter beveiligd. Als daar dan echter geen geanomiseerde testdata op staat kun je zulke situaties verwachten. Op testservers hoor je geen echte data te bewaren (en al zeker geen gegevens als die van identiteitskaarten), dat is gewoon vragen om problemen.

[MrAndy9797]

Om daarop te antwoorden moet je eigenlijk weten waarvoor de testserver diende. Dat kan namelijk veel antwoorden geven. Als het bijvoorbeeld om een server voor datamigratie is, gebruik je best inderdaad een kopie van echte gegevens, omdat dit zo'n moeilijk proces is.

Zo zijn er nog voorbeelden. Verder is het niet doen om uitdagende testdata te genereren. Echte data is (korter bij) de realiteit en brengt het best hedendaagse issues naar boven

[terror538]

holy fuck.

Een testsysteem met echte data, dit dan niet afdoende beveiligen (encryptie zoals hierboven genoemd)

En dan afdoen met een waarschuwinkje naar de klanten.

Waar is de nazorg indien klanten inderdaad met identiteitsfraude geconfronteerd worden (dat recht zetten is vermoeiend en kostbaar)?

Hier mogen, nee moeten, koppen rollen.

[Verwijderd]

Ecnryptie heeft als nadeel dat er altijd iets is dat het decrypt. Als je daar op inhaakt heb je alsnog toegang tot de data (bug/backdoor/exploit in de software).
Testomgevingen moeten gewoon geen gevoelige data bevatten.

En waarom is een test-systeem trouwens extern benaderbaar?

[noway]

Maakt na deze stunt weinig uit....ID theft geeft mega problemen .

Orange gaat veel problemen krijgen.

[crzyhiphopazn]

Waarom ga je dan ook een test systeem met Live data mixen?

[MrAndy9797]

Waarom ga je dan ook een test systeem met Live data mixen?

Zoals hierboven ook gezegd: Om daarop te antwoorden moet je eigenlijk weten waarvoor de testserver diende. Dat kan namelijk veel antwoorden geven. Als het bijvoorbeeld om een server voor datamigratie is, gebruik je best inderdaad een kopie van echte gegevens, omdat dit zo'n moeilijk proces is.

Zo zijn er nog voorbeelden. Verder is het niet doen om uitdagende testdata te genereren. Echte data is (korter bij) de realiteit en brengt het best hedendaagse issues naar boven

[crzyhiphopazn]

Dus je wilt mij zeggen dat er geen exact kopie van alle systemen gemaakt kan worden met fictieve data??

Het gaat er om dat de data stroming getest worden.

[PvdVen777]

"Op de testservers stonden geen creditcardgegevens"

Tja, een nieuwe creditcard is zo aangevraagd met al die andere gegevens die WEL bemachtigd zijn.

[Blokker_1999]

En dan vraag je een nieuwe kaart aan. Waar denk je dat die kaart zal eindigen? Banken sturen die kaarten en de PIN codes tegenwoordig per post naar de klant. Wil je een nieuwe rekening openen? Toon dan maar je identiteitskaart. Bied je je aan in het bankkantoor waar ik klant ben, wees maar zeker dat ze je account opvragen met foto om na te gaan of je wel bent wie je beweerd te zijn.

[Cyb]

Voor veel creditcardtransacties is een pincode niet eens nodig. Het nummer, vervaldatum en csc nummer is voldoende, welke allen zichtbaar op de pas staan.

[Reactie gewijzigd door Cyb op 25 juli 2024 03:09]

[preske]

"beperkte informatie" is in dit geval "alles behalve creditkaartnr's" Ze hebben wel je naam, adres, email, geboortedatum, rijksregisternr etc etc.

[crazyx]

Inderdaad, ik zou liever gehad hebben dat ze mijn credit card nummer hadden dan mijn rijksregisternummer met geboortedatum en naam. Credit card nummer is namelijk heel gemakkelijk te vervangen. De rest is (praktisch) onmogelijk.

[itsalex]

Het is begrijpelijk dat het een testomgeving is maar doe het dan met fictieve gegevens in plaats van echte gegevens. Hoe moeilijk is het te begrijpen dat een testsysteem, ook een testsysteem is en hoe lastig is het dan dat je weet dat er altijd een kans bestaat op zulke issues en dat het niet voor niets "test". Je test een auto toch met een dummy en niet met een levend persoon?

[MrAndy9797]

Het is begrijpelijk dat het een testomgeving is maar doe het dan met fictieve gegevens in plaats van echte gegevens. Hoe moeilijk is het te begrijpen dat een testsysteem, ook een testsysteem is en hoe lastig is het dan dat je weet dat er altijd een kans bestaat op zulke issues en dat het niet voor niets "test". Je test een auto toch met een dummy en niet met een levend persoon?

Zoals hierboven ook gezegd: Om daarop te antwoorden moet je eigenlijk weten waarvoor de testserver diende. Dat kan namelijk veel antwoorden geven. Als het bijvoorbeeld om een server voor datamigratie is, gebruik je best inderdaad een kopie van echte gegevens, omdat dit zo'n moeilijk proces is.

Zo zijn er nog voorbeelden. Verder is het niet doen om uitdagende testdata te genereren. Echte data is (korter bij) de realiteit en brengt het best hedendaagse issues naar boven.

[[Remmes]]

En hier mag men dan even een flinke boete voor krijgen, gelijk laten weten dat het menens is als het aankomt op de AVG/GDPR. Echte data gebruiken op een test-server die niet voldoende beveiligd is...wat een zooitje.

[burnedhardware]

Anders gezegd: ze horen een berisping (or bescheiden boete) te krijgen met de mededeling dat binnen 6 maanden alle testdata voledig is geanonimiseerd op straffe van een flinke dwangsom.

En klaar is de businesscase.

Doel is niet straffen, maar ervoor zorgen dat de organisatie securityminded is

[Reactie gewijzigd door burnedhardware op 25 juli 2024 03:09]

[SinergyX]

Het bedrijf claimt de beveiliging van zijn servers verbeterd te hebben

Dus die was gewoon kut, als het blijkbaar om een testserver zou gaan.
Oorzaak:

door een menselijke fout van een onderaannemer

En wie heeft er toestemming gegeven dat deze 'onderaannemer' ook toegang had tot deze gegevens?

geen creditcardgegevens of facturen.

Facturen, boeit dat nog als er wel ID nummers, BSN nummers en bankrekeningen zijn buitgemaakt?

Al is het twijfelachtig dat de GBA meteen zo streng zal optreden.

Bullshit, absolute bullshit. Eerste of 100 later, data is data, lek is lek, hoeft van mij geen voorbeeldfunctie te worden, maar we praten hier niet over een database met wat email en hashed/salted wachtwoorden, maar over data waar identiteitsfraude behoorlijk makkelijk mee is.

Maaruh, 2 weken later.. hoort dit niet binnen 2 of 3 dagen maximaal gemeld moeten worden?

[Reactie gewijzigd door SinergyX op 25 juli 2024 03:09]