Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 53, views: 21.642 •
Submitter: webinn

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)

Dit is gewoon een bull uitleg om wat mensen te sussen. Waarschijnlijk gaat er nog iemand een berisping krijgen of zo en dan is de kous af.
Die berisping zal nadien wegens procedure fouten ongedaan gemaakt worden maar tegen dan kraait er geen haan meer om.
Zo werkt het politiek benoemde belgische landschap nu helemaal ;-) En wij maar belastingen betalen om die competente mensen aan het werk te houden.
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.
Wanneer jij eens een bestand in een foutieve map plaatst. Welke procedures pas jij dan aan om herhaling te voorkomen?
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 dis.pater op 4 januari 2013 12:48]

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.
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 dis.pater op 4 januari 2013 12:26]

Welke knop? "enter"?
De welbekende "Uitlek" knop is niet bedoeld voor het het openen van de kraan. :+
Best handig zo'n 'verkeerde knop'. Zit die knop standaard in Windows ingebouwd?
Geen CMS kan uitlsuiten dat artikelen onder embargo toch te vroeg gepubliceerd worden wanneer een gebruiker geen tijdsafhankelijke metadata meegeeft aan een artikel. Zo ook kan een publicatie die eigenlijk achter een afgesloten gedeelte van een site moet zitten toch in een publiek deel terecht komen wanneer de gebruiker besluit om het daar te plaatsen.

De 'verkeerde knop' theorie kan inderdaad waar zijn. Wat mij verbaast is dat er dus een mechanisme is gebouwd om data uit een database te halen wat zich laat publiceren in een publieke directory.
Dus wss binnenkort weer een staking omdat de vakbond mss vindt dat het de fout is van management en men geen medewerkers mag beschuldigen.
Waarop het management simpel tegen de medewerkers kan reageren met "Jullie zeggen toch altijd dat wij niks doen? Dus moet 1 van jullie het wel hebben gedaan". ;-)
En die knop voegt in de firewall any any allow to neem ik dan aan ? :+

Op dit item kan niet meer gereageerd worden.



Populair: Tablets Nokia Samsung Smartphones Google Apple Sony Games Consoles Politiek en recht

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013