Gerucht: datalek NMBS kwam door medewerker die op 'verkeerde knop' drukte

Het datalek op de site van de Belgische vervoerder NMBS zou zijn veroorzaakt door een menselijke fout, zo schrijft een Waalse krant. Een medewerker zou op een zeker moment op de 'verkeerde knop' hebben gedrukt. Vrijdag presenteert de NMBS zijn bevindingen.

Bij het datalek op de website van de NMBS waren volgens intern onderzoek van de vervoerder, waaruit de krant La Libre Belgique zijn informatie haalt, gegevens van ongeveer 700.000 reizigers publiekelijk toegankelijk. NBMS legt de resultaten vrijdag voor aan de Privacycommissie, een Belgische overheidsinstantie. Het is onduidelijk of de resultaten daarna publiek gemaakt worden.

De oorzaak van het datalek is volgens het interne onderzoek waarop La Libre Belgique zich zegt te baseren een 'menselijke fout'. Een medewerker zou 'op het verkeerde moment op de verkeerde knop' hebben gedrukt, waardoor alle gegevens publiek toegankelijk bleken. Waarom dit niemand binnen de organisatie is opgevallen, is onduidelijk.

Het lek in de website van de vervoerder kwam in december naar voren. In de uitgelekte data zaten de namen, adressen, e-mailadressen en telefoonnummers van klanten van de vervoerder.

Reacties (53)

[Anoniem: 65297]

Ik werkte enkele jaren geleden als extern medewerker op die dienst en heb toen gemerkt dat er veel bestanden met privacy gevoelige informatie doodeenvoudig in de publieke root folder stonden van de website. Dit in hoofdzaak om bestanden te delen met medewerkers, dus ja je moest de URL weliswaar kennen om er aan te geraken, maar zeer professioneel was het wel allemaal niet. Naast documenten die daar om die reden geplaatst werden was er ook een specifieke toepassing die de ingestuurde data in een tekstbestand in de publieke map had staan.

Ik denk dan ook eerder dat het probleem eerder zo iets is dan "op een verkeerde knop gedrukt". Wat ik beschrijf is weliswaar 6 jaar geleden, dus toegegeven ik weet niet hoe ze tegenwoordig werken natuurlijk. En toen werden er wel stappen genomen om de dienst en de processen te professionaliseren, maar ik sluit niet uit dat er sommige zaken nog steeds verlopen zoals toen en er is natuurlijk ook kans op een berg legacy. Toen was het een homebrewn "CMS" dat gebruikt werd dat statische (PHP) pagina's publiceerde en daarnaast kon je dus gewoon bestanden via FTP in productie plaatsen. Toen ik er wegging waren ze wel bezig met bestaande CMS toepassingen te bekijken, dus het is zeer goed mogelijk dat wat ik hier beschrijf niet meer van toepassing is en dat men inderdaad enkel nog via het CMS data kan publiceren en dat er dus misschien wel sprake is van "op een verkeerde knop drukken".
Al lijkt het me voor dit soort export data wel niet overdreven om deze te exporteren in geëncrypteerde bestanden om ook dit soort gehannes te voorkomen.

edit: Nog eens de huidige sites bekeken en ze zijn toch al serieus veranderd tegenover toen. Aan de ingrijpende wijziging te zien ga ik er van uit dat ze wel degelijk een ander CMS gebruiken nu (en dus vermoedelijk ook een andere methode) aangezien het homebrewn CMS alleszins niet toestond om binnen redelijke termijn de layout te wijzigen. Daarnaast lijken de URL's nu allemaal .aspx te zijn, waar dit voorheen een /directory/index.php structuur was. Dus waarschijnlijk is de website van team geshift naar het .NET team (dat toen alleszins pakken beter werkte: professioneel was). Voorgaande ging over de site voor nationaal reizigersverkeer.

Extra: Het datalek kwam van bij het internationaal reizigersverkeer en daar werden 6 jaar geleden heel zeker (zelf gezien) bestanden uitgewisseld via de publieke site. Al hadden de PDF bestanden toen wel een wachtwoord toen ik ze uitprobeerde. Dus ik ben nog steeds niet zeker of het een ongeluk is dan wel een bestand dat er voor die reden online gezet is.

Beide websites lijken ondertussen trouwens niet meer te werken op het CMS van zes jaar geleden, dus dat is alvast de oorzaak niet, maar het "menselijk proces" van data via FTP te delen via de publieke site is daarom natuurlijk nog niet noodzakelijk veranderd.

Edit 2: Nog verder door de site gebladerd, er zitten nog steeds legacy toepassingen in die niet in het nieuwe CMS zitten. Het lijkt er ook op dat beide sites nog half naast elkaar draaien. Dus het kan goed zijn dan dat mijn post wel relevant is. De nieuwe en oude site draaien op verschillende domeinen.

Edit 3: Eerder genoemde toepassing met bestanden die in de publieke map staan lijkt ook nog bereikbaar te zijn.

Kan nog vanalles uitkomen dus. Mijn voorstel aan de NMBS zou alvast zijn van zo snel mogelijk de oude site volledig offline te halen. Die toepassingen die nog nodig zijn en waarnaar gelinkt worden zijn wat de kant van de buitenwereld betreft niet zo complex, ic. formulieren. Ik heb er zelf fixes op gedaan toen dus weet waar ik over spreek. Lijkt me een goed idee om alvast de publieke zijde - de formulieren - met de hoogste prioriteit te herwerken en desnoods intern te proxyen naar de oude server die dan enkel intern toegankelijk is. Op die manier kunnen ze alvast de oude server (?) offline halen en potentieel toekomstige lekken (hoe gedateerd ook) voorkomen.

[Reactie gewijzigd door Anoniem: 65297 op 24 juli 2024 21:20]

[david.n4s]

Om te checken of dat je gegevens mee opgenomen zijn, vraagt de NMBS, het bedrijf dat je gegevens lekte, om nog meer gegevens: namelijk een kopie van je id-kaart

http://www.b-europe.com/Reizen/Praktisch/Klantendatabase

*ironie*?

[rjeggens]

Als 'de verkeerde knop' indrukken dit als gevolg kan hebben, moet je je serieus gaan afvragen of je je security wel goed op orde hebt.... eigenlijk hoef je dat niet eens af te vragen... Dit lijkt op het rechtpraten van een security blunder door een nog knulliger blunder aan te dragen als oorzaak...

[biglia]

Ik denk niet dat je het letterlijk moet nemen. "Op de verkeerde knop drukken" is een taal van niet IT'ers wat gewoon wil zeggen dat die persoon een verkeerde handeling heeft uitgevoerd. Het wil eigenlijk niets zeggen...

[? ?]

Precies, het zal zoiets wel geweest zijn:

ITer van de ene vestiging belt naar de ITer van een andere vestiging/firma en vraagt om het klantenbestand te exporteren en door te sturen.

Via e-mail is dat te groot, dus zet men het op FTP of gewoon op de site. Tenzij je de exacte link hebt is er niks aan de hand. Maar blijkbaar is die link geindexeerd geraakt of gelekt.

[Blokker_1999]

Als je daarna die "geheime" url per ongeluk in je zoekmachine plaatst ipv de url balk is het kwaad geschied. Gegeven de benaming van het bestand blijkt dat het bestand bedoeld was voor een externe firma die dienstverlening via SaaS aanbied voor klantgerichte mailings. Het lijkt me dan ook dat dit een manier was om het klantenbestand uit te wissellen, weliswaar een domme manier.

[Wulfklaue]

En dit geeft weeral het "evil" aan van de nodige bedrijven. Je verwacht als je gegevens ergens in een bestand/databank staan, dat deze ENKEL voor die specifieke dienst gebruikt mogen worden.

Je draait je rug om, en men zit daarna je gegevens met 3de partijen te delen, waar je geen weet van hebt. En die 3de partijen ... wat is hun security. Gaan zij ook gegevens delen met andere partijen? En je hebt dan een uitlopend effect.

In een ideale wereld, zou iedere partij, je TOESTEMMING moeten krijgen, voor men zoiets doet. En dan liefste zonder chantage. Ik heb al vormen gezien van: "De EULA is aangepast, als u deze niet aanvaard, dan kunnen we u niet de correcte dienstverlening geven". Natuurlijk iets anders geschreven, dan hoe ik het weergeef. Maar je snapt het doel.

Een regel dat veel mensen miserie zou vermijden, zou gewoon zijn: Beperk je gegevens. Sites dat detail gegevens vragen zoals je naam, adres, terwijl je weet dat ze die gegevens niet nodig hebben.Vul dan gewoon rommel in zoals "Privacy 100".

Voorbeeld van een site dat zo is: De Tijd ( Financiële website ) in België. Als je een "demo" account aanmaakt, om de site te "proberen", dan vragen ze details zoals je naam, je adres, je beroep enz. Log je in, blijven ze zeuren achter bepaalde details waar ze gewoon geen recht toe hebben, voor de diensten dat ze aanbieden. Zoek een beetje verder, en dan vind je informatie, dat men die gegevens kan delen met 3de partijen.

Zo zijn er nog heel wat meer sites, dat overdrijven met hun informatie geilheid. Moest je een abonnement nemen, ja, dan zijn bepaalde gegevens nodig. Zeker als je een physiek product wilt verkrijgen. Maar wat heeft een site, te weten wat beroep je doet, hoeveel inkomsten je hebt, enz enz ... Men durft tegenwoordig enorm ver gaan.

En waar eindigen die gegevens weeral!

[brommer]

Ik vrees dat er in dit geval meer aan de hand is. Ik heb het eens opgezocht in mijn e-mails. Op 18 december krijgen zowel mijn vriendin als ik, dus waarschijnlijk ook een heleboel andere mensen, volgend bericht van inschrijving op de nieuwsbrief:

Beste XXXX,

Hartelijk dank voor uw inschrijving.

Via onze NMBS Europe nieuwsbrief blijft u op de hoogte van ons speciale aanbiedingen en ontvangt u allerlei informatie en weetjes over onze bestemmingen en treinen. Zo kunnen wij u beter van dienst zijn en kan u ons nog beter leren kennen!

Bent u nog niet geregistreerd via MyTrain?
Schrijf u dan nu in (zonder aankoopverplichting)! Dankzij deze persoonlijke en beveiligde webspace, beheert u zelf uw persoonlijke gegevens en treinreizen. Met de extra's van MyTrain verlopen uw boekingen nog makkelijker!

Veel leesplezier,

Het NMBS Europe team

Kort daarna ontvangen we een bericht dat het om een fout gaat:

Beste klant,

Naar aanleiding van een technische fout in onze e-mailsystemen, ontving u zopas een e-mail met de bevestiging dat u zich voor onze nieuwsbrief had ingeschreven.

Wij bieden u onze verontschuldigingen voor deze fout en wij wensen te benadrukken dat u NIET bent ingeschreven voor onze nieuwsbrief. U zal bijgevolg geen e-mails meer ontvangen.

Onze oprechte excuses voor het misverstand.

Het NMBS Europe team

Op de website van die Frederic Jacobs vond ik inderdaad mijn gegevens terug. Ik vrees dat die e-mails en het lek aan elkaar gelinkt zijn.

Conclusie: wat een stelletje prutsers!

[Reactie gewijzigd door brommer op 23 juli 2024 01:25]

[Mr_gadget]

Ben met je eens dat de datadeling wel wat minder zou mogen. Maar hier wordt natuurlijk ook aanverdiend.
Beperken van je gegevens is vaak echter geen optie. Omdat je met de voorwaarden accoord moet gaan waarin vaak staat dat je gegevens correct hebt ingevoerd. En bij een vervoerder wordt er vaak dingen naar je huisadres gestuurd dus dan kan je geen bogus adres invoeren...

[Vayra]

Geen enkel bedrijf heeft meer nodig dan je naam, geboortedatum en het adres waar je volgens het GBA ingeschreven staat. Bij automatische incasso hoort daar nog een rekeningnummer bij.

Al het andere is informatie die eenmaal gegeven feitelijk op straat ligt, en informatie die een bedrijf niet nodig heeft om diensten te verlenen.

[bvanaerde]

Ik heb me al veel geërgerd aan mensen die het verschil niet kennen tussen de adresbalk & het zoekveld. Een URl invullen in het zoekveld & dan op het eerste zoekresultaat klikken om naar deze URL te gaan, hoe meer omwegen kan een mens maken

Ik vraag me eigenlijk af of browsers gelijk Google Chrome - waar de 2 velden zijn samengevoegd in 1 - alles wat je invult (dus ook URLs), in de achtergrond meteen ook als zoekterm doorsturen naar de zoekmachine. 't Is in mijn ogen niet echt een veiligheidskwestie, maar als gebruiker moet je er misschien wel rekening mee houden.

[Ventieldopje]

Als je dit niet uit zet in de instellingen dan doen ze dat zeker ja, iets waar veel mensen geen erg in hebben maar bedrijven denk ik wel

[OddesE]

Van dat url invullen in zoekveld een omweg is ben ik niet met je eens. Veel mensen hebben google als startpagina en dan is het een kwestie van of de eno of de andere balk kiezen. Nadeel zoekbalk: een extra click (+ 15 ms voor ophalen resultaatpagina). Nadeel adresbalk: niet tolerant voor spelfouten, strenger met dingen als wel/niet www ervoor, strenger met extensie (tweakers.com?). Veel mensen vinden de hulp van Google opwegen tegen de extra klik.

* OddesE typed rechtstreeks in de adresbalk

[Vayra]

Linksom of rechtsom, als de beveiliging van persoonsgegevens zo makkelijk op straat komt te liggen, is er sprake van een wanprestatie van een medewerker en/of een wanbeleid binnen het bedrijf. En vaak is het beide, en nog vaker is het zo dat wanbeleid de wanprestaties van medewerkers veroorzaakt.

Hoe dan ook ligt de bal in deze heel zwaar bij NMBS. En het excuus dat nu is gegeven is natuurlijk bij lange na niet voldoende.

Bij wijze van voorbeeldfunctie zou er een flinke boete overwogen moeten worden op het moment dat prive gegevens te grabbel wordt gegooid. Misschien dat dat bedrijven wat meer stimuleert om ook zelf wat meer aandacht aan IT security te besteden.

[Reactie gewijzigd door Vayra op 24 juli 2024 21:20]

[Jack77]

Geen idee wat het waarheidsgehalte is. Nu, met zo'n reden blijft het beleid en de verantwoordelijken ook buiten schot. Terecht?

[Blokker_1999]

Want het beleid moet voorkomen dat mensen fouten maken? Als een upload naar een foutieve directory gebeurd zijn er maar weinig controlemechanismen die dat gaan opmerken.

[CumpsD]

Om zaken op de productie site te zetten kan er alvast een beperking zijn in het aantal personen die dat mogen kunnen, verkleint al direct het risico op ongelukken tot de groep gelukkigen met permissies.

En dan ligt het aan "het beleid" om te zorgen dat die groep competent is, en desnoods security opleiding krijgt, zodat ze bij een request om 1.5 miljoen gegevens op de publieke webserver te zetten, er toch ergens in hun achterhoofd iets begint af te vragen "hmmmm, moeten we hier niets speciaals voor doen?"

Nu, dat zal wel te moeilijk zijn voor een overheidsinstelling...

[Jack77]

SirQ geft het al voor en stuk aan.

Waar ik naartoe wou is dat de "menselijke fout" ook een excuus ZOU kunnen zijn. Om te verzwijgen dat er geen, of geen afdoende beleid is. Of dat leidinggevenden zelfs expliciet opdrachten geven die ingaan tegen beveiligingslogica.

[rolandverh]

De simpelste fout, die het minst opvalt;
In de grafische filemanager van de webserver de eigenschappen van een folder veranderen met leesrechten voor 'iedereen'. Een dergelijke vergissing valt (in een GUI) meestal niet echt op. Vaak worden die fouten veroorzaakt door beheerders die snel ergens bij moeten kunnen, op een hogen niveau iets aanpassen en vervolgens vergeten om het terug te zetten.
Een menselijke fout is snel gemaakt en valt niet op.
De tweede fout; geen regelmatige controle van rechten. Dat soort fouten kun je met goede compliance / security procedures voorkomen. Veel bedrijven denken hier niet over na en vertrouwen te veel op de beheerder die de fout maakt.

[rjeggens]

Dat weet ik... maar deze rechtpraat actie maakt het nu alleen nog maar knulliger... wat ze nu aangeven was dat het echt HEEL makkelijk was om de hele database zomaar op straat te zetten... zo makkelijk dat het per ongeluk kon...

[Vaevictis_]

Dit is natuurlijk nooit een user error.

Blijkbaar hebben ze nog niet gehoord van Secure by Design, http://en.wikipedia.org/wiki/Secure_by_design

Blijkbaar is de software op dit aspect dan ook niet goed getest!

[Keypunchie]

Secure by design verdedigd tegen fouten van gebruikers/exploits en maar in heel beperkte mate tegen fouten van beheerders. Dus gebruikserror is altijd mogelijk.

Praktijkvoorbeeld: hier op tweakers hebben ze (nog geen jaar geleden) ook wel eens een < vergeten te zetten bij het plaatsen van een nieuwe php-config:

plan: Server- & netwerkstatusmeldingen XII

Tjsa, dan liggen wel al je wachtwoorden op straat. Hoe secure je systeem dan verder ook is.

De respons van Tweakers op die fout was natuurlijk wel beter dan bij NMBS, maar het is niet zo alsof een goed security-beleid al je problemen altijd voor is. Dat is geen kwestie van voldoende testen, dat is een kwestie van mensenwerk.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 21:20]

[Zyppora]

Spijt me zeer, maar ook het vergeten van een < is, in een productie omgeving, onacceptabel. Waarom? Omdat dit op een test/acceptatie omgeving opgemerkt moet worden. Zeker een website als T.net, maar ook die van NMBS, moet een zgn. OTAP straat hebben, of in ieder geval twee delen daarvan.

Voor zover ik het NMBS verhaal begrijp, gaat het hier om het beschikbaar stellen van gegevens naar een derde partij. Erg lekker om te weten dat:
- NMBS zoveel privacy-gevoelige gegevens van haar klanten heeft
- deze gegevens zonder medeweten van die klanten met derden deelt
- dit op een technisch dusdanige manier wil doen dat deze gegevens zonder verdere controle geraadpleegd kunnen worden door die derde partijen
- als klapper deze gegevens vrolijk volledig publiek maakt

Op het verkeerde moment de verkeerde knop? Hadden ze echt geen betere smoes kunnen verzinnen? Wat was dan wel het juiste moment geweest voor die knop?

Graag wens ik NMBS zich aan haar eigen stelling te houden, haar schuldig te bevinden aan het onrechtmatig publiceren van een gigantisch aantal privegegevens en haar hiervoor zwaar te beboeten. Tevens zie ik graag de resultaten tegemoet van een door een externe, professionele partij uit te voeren onderzoek naar de databeveiliging en het beleid daaromtrent bij NMBS, waarbij de kosten voor dit onderzoek uiteraard op NMBS verhaald zullen worden.

[biglia]

Hopelijk duwen ze bij de spoorwissels wel op de juiste knop... Ik maak me geen zorgen omtrent de veiligheid op het spoor. Dat zijn twee afzonderlijke zaken.

Voor wat ik gehoord heb, worden de IT diensten van de NMBS (wat nog eens verschillende holdings heeft) verzorgd door een komen en gaan van consultants van verschillende IT bedrijven over heel België en de taalbarrières (Frans-Nederlands) spelen zeker niet in het voordeel. Maar dat is uiteraard overal zo...

[Reactie gewijzigd door biglia op 24 juli 2024 21:20]

[Blokker_1999]

IT diensten. Dat was 10 jaar geleden heel simpel. Toen had je gewoon de mannen van de IT dienst. Bij de splitsing is dat H-ICT geworden en viel de verantwoordelijkheid onder de holding. H-ICT heeft zich ondertussen hernoemd naar Ictra .

Tussendoor werd er bij de NMBS ook en dochteronderneming opgericht. Syntigo. Het is bij en via Syntigo dat er veel externen in dienst komen. De baas van Syntigo is trouwens ook afdelingsleider van Ictra. Op deze manier is de privatisering van de ICT dienst ingezet binnen de NMBS.

Na de opsplitsingen wou de NMBS natuurlijk niet achterblijven en ondertussen heeft ook de NMBS een eigen dochteronderneming Ypto . Ypto heeft dan weer een belangrijke rol gespeeld in de uitrol van SAP binnen de spoorwegen en is diegene die vele externe consulenten heeft aangebracht. Een deel van die consulenten begint trouwens ondertussen ook al aan projecten mee te werken (beLEAN) die niets meer met SAP of zelfs ICT te maken hebben.

En ik vermoed dat ook Infrabel ondertussen al wel zijn eigen ICT dienst heeft. Al doen zij het nog zonder dochteronderneming voor zover ik weet.

Over ICT binnen de NMBS kan je ondertussen ook al een blunderboek volschrijven. Toch zijn er wel degelijk ook een hoop dingen die goed in orde zijn.

[Anoniem: 65297]

Even hierop inspringen n.a.v. mijn eerder bericht.

Ik heb de veranderingen tot aan ICTRA ook gezien. Wat je zegt van dat blunderboek klopt zeker, maar tegelijk waren er toen (en nu uiteraard nog) ook mensen op verschillende niveaus die capabel waren en wisten wat er moest wijzigen en hoe. Wat ik dus in mijn eerder bericht schreef is zeker geen afbranden van de NMBS (al haar entiteiten), maar eerder een vaststelling van de situatie toen en een mogelijke correlatie met hoe dit kunnen gebeuren is.
Het is een grote, logge organisatie en veranderingen nemen er helaas veel tijd in beslag. Ik zie dat ze al veel ten goede veranderd hebben, maar dit lek zouden ze eerder als een laatste kans moeten zien om eens een grondige audit te doen van hun publieke websites en wat er mogelijk kan foutlopen, inclusief menselijke fouten. Hun persbericht lijkt me een zwakke damage control en gaan dreigen met juridische acties tegen sites zoals die van Frederic Jacobs lijkt me weinig constructief. Ze zouden zelf zoiets moeten organiseren als ze het serieus nemen en de mensen die geïmpacteerd zijn aanschrijven met excuses.

[Parasietje]

Het kan mij niet veel schelen wat de oorzaak is. Het belangrijkste is dat het niet opnieuw gebeurt.
Ongevallen in de luchtvaart worden soms ook toegeschreven aan 'menselijke fout'. Daar wordt echter alles in het werk gesteld om te zorgen dat het niet opnieuw gebeurt: checklists aanpassen, extra veiligheidsvoorzieningen, etc.

[Blokker_1999]

Wanneer jij eens een bestand in een foutieve map plaatst. Welke procedures pas jij dan aan om herhaling te voorkomen?

[Anoniem: 65297]

Een dergelijk bestand zou doodeenvoudig niet via een publieke site mogen uitgewisseld worden. En als het al niet anders kan/kon dan zou het bestand minstens versleuteld moeten geweest zijn.
Dergelijke bestanden dien je op andere directe, beveiligde manieren uit te wisselen.

Dit ganse debacle gaat m.i. niet over technische fouten, of menselijke acties die fout gelopen zijn, maar over een algeheel cultuurprobleem dat overigens bij veel bedrijven heerst.
Er is veel te veel nonchalance over klantendata. Slechts een beperkte groep mensen zou aan dergelijke grote hoeveelheden data mogen kunnen. Daarnaast zouden dergelijke exports, als ze al nodig zijn, van aan de bron beveiligd moeten zijn zodat onbedoelde bestemmelingen (inclusief interne medewerkers) hier niets mee aan kunnen vangen.

Als het proces per se via een database dump dient te gebeuren zou het als volgt moeten lopen:

* Data exporteren op server
* Data encrypteren
* Geëncrypteerd bestand doorspelen aan het extern bedrijf
* Extern bedrijf ontsleutelt het bestand aan de hand van hun key (uiteraard beschermd door een degelijke passphrase)

Dat dit allemaal niet gebeurt is omdat men denkt dat dergelijke processen te kostelijk/te lastig is voor data die naar hun mening triviaal is. Dit lek toont helaas pijnlijk aan dat dergelijke data niet triviaal is.

[Reactie gewijzigd door Anoniem: 65297 op 24 juli 2024 21:20]

[Anoniem: 35352]

Het databestand was bedoeld voor de dienstenfirma die voor de NMBS een nieuwsbrief verstuurt naar klanten van NMBS Europe. Je kan dus zelfs zeggen dat er in die database hopen onnodige info stond voor het beoogde doel (naam & email zouden voldoende geweest moeten zijn, eventueel geslacht als je Mr./Mevr. wil toevoegen, maar huisadres, geboortedatum, e.d. waren absoluut onnodig), en dat lijkt me op zich ook ongewenst.

[Anoniem: 129146]

een knop is één ding. Er moet ook logica geschreven zijn achter die knop anders mag je er zoveel op drukken als je wil. Vraag mij wel af waarom er iemand daar übehaubt logica zo implementeren die met 1 druk op een knop alle profielen van gebruikers publiek zet...

Seriously?! Komaaaaaan!

[cyboria]

Misschien was het ooit een debug functionaliteit die één of andere ontwikkelaar ooit in zijn programma had staan om eenvoudiger aan de gegevens te kunnen en is deze nooit verwijderd geweest.

[michelr]

Makkelijk excuus altijd, een (fictieve) medewerker de schuld geven ..

[biglia]

Volgens La Libre Belgique zou een werknemer ondertussen geïdentificeerd zijn die, zonder kwade bedoelingen, "op het verkeerde moment op een verkeerde knop" zou gedrukt hebben.(Belga/EE)

Ik heb al rare dingen meegemaakt bij het onderzoeken van zulke fouten. Bijvoorbeeld een mail naar iedereen met de melding: als je zelf aangeeft dat je een fout heb begaan, dan laten we dit zo, maar als niemand toegeeft en we het moeten onderzoeken dan wordt de schuldige(n) ontslagen.

[Dutchmega]

Je moet ook geen "Gegevens lekken"-knop maken...

[Cameleon73]

"Verkeerde knop"? Wat voor knop is dat dan eigenlijk? "Zet alle klantgegevens openbaar" ?

Is dit nu een gevalletje slechte user interface of simpelweg schadebeperking? Ik ben in ieder geval benieuwd naar de bevindingen!

[Anoniem: 178824]

De "AAN" knop. Als gewoon niemand die server aanzet lekt er ook niets, druk je wel op die "AAN" knop dan lekt de boel..... ofwel: het is de schuld van de knop.

[Douweegbertje]

Laten we allemaal conclusies trekken over een verkapt statement die letterlijk nul komma nul zegt over de inhoud...

Wacht nou maar eerst even af of er uberhaubt iets naar buiten komt behalve nietszeggende verklaringen. We kunnen allemaal wel gaan lopen raden en doen, puntje bij paaltje was het gewoon een grote fout en de kans dat je het technisch aspect ervan te weten komt is vrij klein. NMBS loopt nu gewoon op zn teentjes, moet wat verantwoording afleggen en gooit wat excuses en verklaringen.