Website ov-chipkaart bevat sinds januari privacyprobleem

De website van de ov-chipkaart bevat ten minste sinds januari een beveiligingsprobleem waardoor gebruikers soms gegevens van andere reizigers kunnen zien. De technische dienst van het bedrijf achter de ov-chipkaart werd echter niet eerder op de hoogte gesteld.

Trans Link Systems werd eind januari al op de hoogte gesteld van het privacyprobleem. Daardoor waren per toeval de naam, het adres, het reisoverzicht en het saldo van een ander in te zien, zo meldt NU.nl. De meldingen over het probleem bleken echter niet doorgestuurd te zijn naar de technische dienst, waardoor de organisatie pas vorige week actie ondernam.

Het lek is waarschijnlijk pas dinsdag verholpen, waardoor het nog steeds mogelijk is dat mensen die inloggen op ov-chipkaart.nl informatie van anderen krijgen te zien. Het is niet bekend in hoeveel gevallen dat daadwerkelijk gebeurt. TLS laat weten dat de site niet offline zal worden gehaald totdat het probleem is opgelost. Daarvoor wordt de website te veel gebruikt, zo zegt het bedrijf.

Reacties (66)

[BoringDay]

Probleem sinds januari bekend?
- Kortom er was sprake van een meldplicht aan de overheid;
Website niet offline?
- Dat gaat tegen de wet van privacy in eveneens de privacy overeenkomst;

Ik denk niet dat ze een andere keuze hebben de site offline te halen totdat het probleem werkelijk is opgelost. Ze voldoen nu niet aan de veiligheidseisen om met prive gegevens om te gaan.

[RVervuurt]

Volgens een eerder bericht hebben ze een ethische hacker in dienst die het probleem niet kon reproduceren (en dus "misbruiken"), wat de reden is geweest voor het niet offline halen van de website.

Zie mijn reactie voor de bron.

[BoringDay]

Dat iemand het niet kan reproduceren betekent niet dat het probleem zich niet voordoet (of ze nu een ethische hacker in dienst hebben of niet is niet relevant). Kwestie van debuggen en kijken wat er allemaal gebeurd bij het aanmaken van gebruikers en ophalen van gegevens.

[461943]

Een "ethisch hacker" zegt niet zo veel. Ik heb ook wel eens op school data bekeken van andere mensen en vervolgens doorgegeven hoe dat kon. Ben ik dan ook een ethisch hacker of zit ik gewoon een beetje rond te klikken? (Hint: dat laatste.) Ik zou graag eens een naam horen van wie die vent eigenlijk was en zijn trackrecord qua hacks zien.

[lezzmeister]

Gewoon een student webdesign die een beetje rondklooit met metasploit en niets voor elkaar krijgt. Ik zie het niet voor me dat ze een echte hacker in dienst hebben.

[RVervuurt]

In een artikel van 9 augustus vermeldt nu.nl het volgende:

In de tussentijd is er volgens TLS geen reden tot paniek omdat het lek niet reproduceerbaar blijkt. Het bedrijf heeft een 'ethische hacker' in dienst die het lek heeft proberen te misbruiken, maar die kreeg het niet voor elkaar. De website is dan ook nog steeds in de lucht.

Bron

Hier wordt in het door Tweakers.net-gelinkte bericht niet over gesproken, dus ik weet niet in hoeverre dit nu waar is. Wat de reden is dat ze 'm in de lucht houden is dus ook onbekend voor mij.

Door deze gemengde berichten ben ik wel erg benieuwd hoe het nou eigenlijk echt zit. Het verhaal van de "ethische hacker" klinkt in ieder geval wel veel spannender.

[dashorst248]

Volgens de website van OV-Chipkaart is het lek gevonden en opgelost, en wordt deze morgen (12 augustus) gedicht.

https://www.ov-chipkaart....ivacy_transactieoverzicht

Ook staat in dat stuk vermeldt dat er op basis van de melding eerder in het jaar geen actie ondernomen kon worden omdat er onvoldoende gegevens beschikbaar waren. Gezien de problematiek en de drukte van de website is het lastig om dit soort zaken gericht te vinden vanuit je logs, zeker omdat het slechts een enkele keer kennelijk voorkwam.

Met de hoeveelheid requests en sessies die op die servers afgevuurd worden kan het behoorlijk lastig zijn om te achterhalen waarom dit plaats vindt, zeker omdat het niet bij elk request gebeurt. Met name de verklaring van OdessE hierboven lijkt mij de juiste richting te zijn. En dit hoeft dan niet altijd te gebeuren, maar kan dankzij een exception die eens in de 1000,000 requests plaats vindt een ThreadLocal vervuilen.

[ikt]

Ik heb bij het aanmaken van mijn OV-chipkaart in juli 2012(!) dit al gehad en ik heb het ook gemeld, maar blijkbaar heeft Translink er weinig aan gedaan.

Bij deze dus het bewijs dat het eigenlijk nooit goed is geweest: http://gathering.tweakers.net/forum/list_messages/1507786

[Reactie gewijzigd door ikt op 23 juli 2024 02:25]

[Cave_Boy]

Stuur de mail naar de pers met dit verhaal erbij. Misschien krijgen we nog kamervragen

[Soldaatje]

Ik heb het ook gemeld hier op het forum, dat topic werd gesloten...

[CMD-Snake]

Maar is het dan als je inlogt dat je ineens van een willekeurige andere persoon zijn gegevens ziet? Of moet je wat extra's ervoor doen? Het kan natuurlijk lelijk misbruikt gaan worden zo'n lek.

Ik geloof dat ze overigens al eerder een gat in het systeem hadden waardoor je iemands reisgeschiedenis kon bekijken als je diens kaartnummer wist.

[Douweegbertje]

Het is 'random' dat je opeens dus gegevens van iemand anders ziet. Niet zomaar een digit in de URL veranderen dus. Hoe iemand dat als programmeur voor elkaar krijgt is vrij bijzonder. Als ik een manier mag bedenken hoe dat kan ontstaan is een één of andere verknipte manier...

Het lijkt net alsof ze een soort data object opslaan (van de user) in bijvoorbeeld een soort cache, en vervolgens het laatste ID ophalen zoals dat simpel kan met SQL (http://php.net/manual/en/pdo.lastinsertid.php) Vervolgens ga je verder met dat data object.
Stel dat je nu toevallig tegelijk gaat inloggen, kan het misschien voorkomen dat je wel het laatste ID hebt gepakt, maar dat die van iemand anders was.

De kans dat dit gebeurt is vrij klein. Het moet dan zo zijn dat men vrijwel simultaan inlogged waarbij de één net wat vertraging heeft en voila. Je hebt een andere 'sessie'. Het feit dat het ook maar af en toe gebeurt doet me wel vermoeden dat het ongeveer zo'n probleem is. Waar het dan nou precies fout gaat (cache, sessie, database..) weet ik natuurlijk niet.

In zekere zin simpel te testen door even een scriptje te draaien die gelijkertijd 10 man gaat inloggen. Als mijn verhaaltje klopt loggen er een paar niet in en de rest heeft een verkeerde sessie..

[Reactie gewijzigd door Douweegbertje op 23 juli 2024 02:25]

[m4ikel]

Volgens de MySQL documentatie zou dit onmogelijk moeten zijn linkje.

Ik denk eerder aan een falende Master -> Slave omgeving, of gewoon session management wat fout loopt door een vage fout.

[Douweegbertje]

Het gaat om het principe. Misschien was sql last id een verkeerd voorbeeld, maar op het moment dat zo'n soort gelijke functie wordt gebrouwen kun je dit soort dingen krijgen. Naar mijn mening is het ook de enige logische verklaring waardoor je sporadisch iemand anders zijn 'meuk' kan krijgen.

[mmjjb]

Ik denk niet dat TransLink een programeer taal als PHP gebruikt en een MySQL database. Verder is jou reden wel heel onlogisch, het zal eerder fout gaan met falende Master -> Slave omgeving, of een buffer die de requests uitvoerd maar niet goed terugkoppeld soms, of iets dergelijks

Kan me meer vinden in @m4ikel

[Douweegbertje]

Leuk, maar lezen is ook een vak. Ik geef nergens iets aan, in wat jij opnoemt
Het gaat om "zoals" last id, om een simpel voorbeeld te geven wat de meeste wel begrijpen. Of dit nu een ID van cache / buffer / db / code w/e is maakt dan niet uit.

[orDian]

Het is wel mogelijk wanneer er een persistent connection wordt gebruikt.
Een oplossing is transactions gebruiken.

[m4ikel]

Thanks orDian! Als ik daarop verder borduur met behulp van Google:

Yes, there is a risk not only with last_insert_id but with transactions and other things. mysql_pconnect isn't right thing for use it on production because many php instances will have access to a single connection

[OddesE]

Of er blijft informatie achter op een thread, en als je dan uit de threadpool die thread krijgt toegewezen dan treedt dit probleem op.

Als je met Java een servlet bouwt en je geeft die een veldje waarin je gegevens gaat bijhouden, dan krijg je al snel dit soort gedrag, Omdat je te maken hebt met een threadpool met daarin (bijv.) 50 threads is dit erg lastig te reproduceren voor een ontwikkelaar. Je moet maar net de verkeerde thread krijgen...

[ilaurensnl]

Als dit soort verhalen mogelijk is, is het niet alleen een privacy probleem. Maar het kan ook zijn dat iemand een reis maakt voor een bedrag, maar door deze probleem moet iemand anders het betalen. Ik vind het raar dat dit mogelijk is, en dit had nooit mogen gebeurd. Erg stom!

[Niemand_Anders]

lastinsertid is een actie bij het aanmaken van een persoon. Hoewel het verkrijgen van een verkeerde autonummeringid een codesmell is dat men geen transacties gebruikt.

Het gaat om het zien van gegevens van een totaal andere persoon na het inloggen. Ik vind het eigenlijk zelfs wel een beetje knap om na een login actie de gegevens van een andere te tonen.

Het zal inderdaad wel een soort van race condition danwel concurrency probleem zijn, want een query (ook als deze verkeerd geschreven zou zijn) geeft altijd consequent dezelfde resultaten terug. De enige reden die ik kan verzinnen is dat er verschillende sessie servers zijn welke onafhankelijk een sequence bijhouden waardoor sessie-id's dubbel wordt aangemaakt. Mocht de loadbalancer de betreffende server uit de pool halen, dat wordt je doorgestuurd naar een andere server en daar zou dan een andere sessie kunnen bestaan met hetzelfde id.

Eigenlijk vind ik persoonlijk dat bij dit soort belangrijke overheids diensten dat de broncode gewoon openbaar moet zijn. Want het is niet de eerste keer dat een overheids website lek is..

Net als dat we tijdens het WK 16 miljoen bondscoaches hebben, is iedere developer ook gewoon export. Laat de code maar door een publieke (peer) review heen komen..

Als iemand een universiteit artikel plaats na aanleiding van een onderzoek moet deze ook een peer review ondergaan. Een dergelijke review procedure moet ook ingesteld worden voor publieke overheids websites.

Salt keys, connectionstrings en andere magic numbers horen per definitie al niet in de code thuis (daar heb je configuratie voor), dus dat is ook geen argument.

[barbarbar]

De systemen voor het afhandelen van de ov-chipkaart zijn gedistribueerde systemen. Uit voorgaande nieuwsgeving is al bekend dat deze systemen zodanig zijn ontworpen dat ze onafhankelijk van elkaar kunnen werken, en uiteindelijk alles synchroniseren.

Een dergelijke opzet bevat heel wat mogelijkheden tot fouten, voornamelijk wanneer dingen gelijktijdig gebeuren. Dit wordt vaak opgelost door volgnummers en nummerseries te gebruiken, waarbij overlap kan ontstaan met als gevolg dit soort fouten. Ook een oplossing voor zulke systemen is door alles met hele preciese tijdmetingen te volgen en synchroniseren, een afwijking in de tijdmeting heeft dan zulke fouten tot gevolg. Nog een andere oplossing is het gebruik van theoretisch wereldwijd unieke nummers (guids), hierbij ben je zeker van unieke nummering voor je transacties/gegevens zonder iets van de andere systemen te weten. Hierbij kan door een slechte implementatie echter soms hetzelfde nummer gebruikt worden op meerdere onafhankelijke systemen, waarbij dergelijke fouten ontstaan tijdens synchroniseren. Deze fouten zitten dan vaak in het gebruikte platform (Ruby, Java, .Net etc). Gezien het zeer zelden voorkomt gok ik zelf dat het laatste het geval is, dat lijkt aardig te passen bij het probleem.

Net zoals de overige reacties over de oorzaak van dit probleem is ook mijn idee puur speculatie, ongehinderd door enige kennis van het daadwerkelijk systeem. Realiseer je echter dat het ov-chip systeem niet één pc/server is die alles afhandeld, maar duizenden onafhankelijke systemen die aan het einde van de dag hun gegevens synchroon proberen te krijgen. Dan krijg je zulk soort aandachtspunten.

Dit soort fouten kunnen heel lastig zijn om te achterhalen en zijn ongeacht het gekozen ontwerp van de systemen aanwezig.

[Reactie gewijzigd door barbarbar op 23 juli 2024 02:25]

[Anoniem: 120693]

Maar is het dan als je inlogt dat je ineens van een willekeurige andere persoon zijn gegevens ziet? Of moet je wat extra's ervoor doen? Het kan natuurlijk lelijk misbruikt gaan worden zo'n lek.

Als je bij toeval en random de informatie van iemand anders te zien krijgt is de kans op misbruik naar mijn idee niet erg groot. Je weet dan dat iemand die je niet kent uit Purmerend elke dag naar Amsterdam gaat.

[klaw]

Over het algemeen gaat het niet willekeurig je hebt ergens iets verkeerd ingevuld dan krijg je zoiets... een beetje hacker kan er zo een scriptje eromheen schrijven en dan data beginnen te trekken...

[Anoniem: 120693]

Over het algemeen gaat het niet willekeurig je hebt ergens iets verkeerd ingevuld dan krijg je zoiets... een beetje hacker kan er zo een scriptje eromheen schrijven en dan data beginnen te trekken...

Maar dat was volgens de informatie die we nu hebben niet het geval. Gewoon een stomme fout (session management?) dus en niet de volgende schreeuwende kop waarin onze gegevens door de eerste de beste scriptkid te verkopen zijn.

Wil je een echt interessant verhaal over hackers? http://motherboard.vice.c...ranoid-is-paranoid-enough

[Blokker_1999]

Probleem is dat als er toch een systematiek inzit en je krijgt deze gevonden, dan is het in principe mogelijk om met een screenscraper een hoop private informatie te gaan verzamelen. Dan gaat het niet langer om het zien van informatie van 1 willekeurige persoon maar zit je met een echt probleem.

[Solstice]

Ze nemen de klant niet serieus. Zowel niet bij het melden van de lek door enkelen, als in de laconieke response erop.

[oef!]

Translink valt niet serieus te nemen. Eerst het hele drama rondom de invoering met als klapper de hack van de OV kaart en nu dit. Ze wisten al van de website hack in maart en nu ondernemen ze maar eens actie. Tijd om het vertrouwen in die club op te zeggen.

[RoestVrijStaal]

TLS weet was haar positie in de markt is en maakt er gretig gebruik van. Het is een monopolie van 1 markt, 1 bedrijf met zero aan concurrentie. Als Den Haag of Brussel daar nou iets aan doet.

Het is jammer het niet kan zoals bij ProRail, die via aandelen en een aparte BV eigendom is van de Nederlandse Staat, de verantwoordelijke minister de directie bij dit soort incidenten op het matje kan roepen.

[Armin]

De OV chipkaart was vanaf het begin dan ook niet gemaakt met de klant centraal. Het was vooral opgesteld met de belangen van overheid (meer statistiek) en vervoerders (einde complex onderling verrekenen) voorop. Dat wil niet zeggen dat er geen (potentiele) voordelen zijn voor de klant, maar dat waren expliciet secundaire aspecten.

[airell]

vervoerders (einde complex onderling verrekenen)

Dat weten maar al te weinig mensen helaas... maar vanuit dat punt is het een stuk eerlijker vind ik:

Oude manier: Buschauffeurs die op gezette tijden (haltes) achterom kijken en het aantal reizigers tellen (gokken als het druk is)... dan gaan de vervoerders zelf de aantallen in uit één van de beschikbare rekenmethodes zetten (zg. reizigers kilometers berekenen) en de gunstigste uitkomst doorsturen, waarna deze onderlinge verhoudingen worden toegepast op de verzamelde eurootjes van de verkopen van strippenkaarten bij de sigarenboeren, kaartjes automaten, losse verkoop in de bus, abonnementen etc, etc, etc...

Nieuwe manier: Check in, check uit; TLS zegt: u krijgt zoveel...

[Reactie gewijzigd door airell op 23 juli 2024 02:25]

[Tarabass]

Ja, leuk. En ken het systeem want oom en tante zijn buschauffeur. Maar dan nog is het nergens voor nodig. Ze hadden net zo goed censors kunnen inbouwen bij de deuren die tellen hoeveel reizigers erin en eruit gaan. Daar is geen pasje voor nodig, daar is geen interactie voor nodig met de reiziger, daar is geen opslag van persoonsgegevens voor nodig, daar is geen minimaal tegoed van 20 euro voor nodig, daar is geen extra toeslag van 1 euro voor nodig en daar is geen extra starttarief per vervoerder voor nodig. Er zou dan voor de reiziger helemaal niets veranderen.

[airell]

Het ging mij ook maar om één van de door @Armin aangegeven belangen, een eerlijkere manier van de omslachtige en door de vervoeder 'zelf te kiezen' (oneerlijke) reizigers kilometers formule. Dit is heel vaak onduidelijk is bij het gewone publiek die zich vaak alleen blind staart op dat de vervoerder alleen wil weten waar je geweest bent (de plus tweeers voor jouw reactie waarschijnlijk).

Er zijn ook voordelen te benoemen, misschien niet zo snel voor het publiek en ja, het is voorlopig nog een 'minder prettig' uitgevoerd systeem.

Als auto rijder zou ik graag nog ouderwets stripjes in de bus kopen voor die paar keer, maar als forens strippen stempelen... dat is middeleeuwen in mijn ogen.

[Reactie gewijzigd door airell op 23 juli 2024 02:25]

[Tarabass]

Ik zal je toch echt willen meegeven dat het allerbelangrijkste aan de chipkaart is het willen weten waar de reiziger zich bevindt. Dat is ook de reden waarom men alle tekortkomingen die nu aan het systeem kleven voor lief neemt. Normaliter zou een bedrijf die zo omgaat per persoonsgegevens echt een probleem hebben. Nu is het wegslikken en weer doorgaan.

Een ander goed voorbeeld waarin iedereen maar als schapen achter elkaar aanloopt, zeker in de politiek, is de wietpas. Een pas waarmee je kon aantonen dat je uit Nederland komt. Dit zou de koop van softdrugs door buitenlanders tegen moeten gaan, en daarmee het drugstoerisme. Ten eerste is het discriminatie, maar daarnaast is dit wietpas compleet onnodig. We hebben daar namelijk al een identiteitskaart voor. Daarmee kan elke Nederlander aantonen dat hij en boven de achttien is en Nederlander is. Sterker nog, het is verplicht je te legitimeren in coffeeshops. Toch liep iedereen met het idee mee dat er een wietpas moest komen. Ik heb geen politicus horen zeggen dat men zich al kon legitimeren dmv een ID-kaart.

Het gaat puur om registreren. En de laatste keer dat men zich grootschalig moest registreren is 75 jaar geleden. Uit principe zou je dus tegen elke vorm van nutteloze registratie moeten zijn. Zeker als je met een prepaidkaartje ook uit de voeten zou kunnen, als het perse met een chipkaartje moet..

[airell]

Prima, fijn dat je me dat wil meegeven, nogmaals, het ging mij maar om één van de door @Armin aangegeven belangen, einde aan de complex onderling verrekeningen. Een achter de schermen voordeel.

[461943]

Ik zie eigenlijk weinig voordelen. Je word makkelijker gevolgd, het is duur om aan te vragen en er moet een minimum saldo op, je kan vergeten uit te checken, je kan niet meer op stations zonder het ding, je kan hem kwijt raken, en als je er geen hebt dan moet je een euro extra betalen om een losse te halen. Wat mij betreft hadden ze gewoon treinkaartje geldig gemaakt voor bussen; dan had je gewoon één kaartje gehad om met zowel bus als trein te rijden. Zonder ingewikkelde en klantonvriendelijke dingen, zonder de kosten van het invoeren van een heel nieuw systeem.

Het sleutelwoord hier is communicatie: tussen vervoersbedrijven. Als dat nu eens wat meer gebeurde, hoe lastig dat ook te realiseren is.

[Titan_Fox]

Ik reis principieel niet met het openbaar vervoer en zeker niet nu ze die ellendige chipkaart hebben ingevoerd. Reguliere treinkaartjes (nu met chip) zijn ook direct een stuk duurder geworden. Dan zit je in overvolle treinen bij mensen die het begrip "stiltecoupe" niet begrijpen, er een vuilnisbelt van maken of zich ongegeneerd zitten te rukken in de eerste klas (NSFW).

http://www.geenstijl.nl/m...minaret_op_geenstijl.html
http://www.geenstijl.nl/m...infapperts_zijn_zelf.html

Sowieso lekker hygiënisch, in de herfst / winter / lente opgesloten zitten bij snotterende en hoestende mensen terwijl je probeert om zelf niet ziek te worden uit angst voor het verliezen van je baan.

Nee dank je, ik leen de auto van mijn ouders wel als ik perse ergens naar toe zou moeten. De meeste spullen krijg ik gewoon hier in de stad (lekker met de fiets) en al het overige spul koop ik online.

[Reactie gewijzigd door Titan_Fox op 23 juli 2024 02:25]

[lezzmeister]

Niet alleen rukkers, in de Amsterdamse metro liep er op mijn vaste route naar school altijd zo'n junk rond die stonk naar de stront, en die rookte van een zilverpapiertje. Dan de mensen die in de stiltecoupe de schoenen uitdoen en de teennagels vliegen je links en rechts om de oren, conducteurs die verward de trein rondlopen en alledrie willen ze je kaart zien en dan mag je uitleggen waarom je kaart al geknipt is, de zwerver die bij Naarden-Bussum altijd opstapt en muntjes wil, boomlange gekleurde meneer die lukraak iemand in elkaar gaat timmeren op het perron bij Gouda, etc.

Dit kan gewoon niet zo. Openbaar vervoer zal ik vermijden wanneer ik kan, maar helaas kan dat niet altijd.

[Titan_Fox]

Precies. Als mensen zonodig Ebola willen krijgen moeten ze vooral met het OV blijven reizen. Er zou straks maar eens iemand in de bus of trein moeten zitten die net terug is gekomen uit een van die risicolanden en vervolgens in jouw richting zit te hoesten. Nee dank je, ik ga liever op een normale manier dood.

[Anoniem: 120539]

Vooralsnog gaan we er van uit dat overdracht van ebola tussen mensen alleen gebeurt als je in aanraking komt met lichaamssappen zoals bloed of uitscheidingen als braak of ontlasting.

Overdracht via de lucht (aërogeen) is bij de mensen nooit aangetoond.

Normaal sociaal contact (dat is niet verplegend, niet seksueel contact) levert geen risico op.

Ik weet niet wat jij allemaal in het OV van plan bent, maar normaal gesproken is het risico op Ebola nihil.

Meer on-topic:
Bizar om te constateren dat een dergelijke kwetsbaarheid zo lang 'verborgen' kan blijven in een systeem dat toch dagelijks door een groot aantal mensen wordt gebruikt.

[Titan_Fox]

Ik vind het wel geslaagd. Als je maar lang genoeg aan het hoesten bent komt er op een begeven moment vanzelf bloed mee. Alsof Ebola de enige ziekte is die uit zulke landen is komen overwaaien die je in een volgepropte trein of bus kunt oplopen. Zulke warme plekken zijn ideale broedplaatsen voor bacteriën en virussen, die dankzij mutatie steeds resistenter worden tegen antibiotica en antivirale middelen.

https://m.youtube.com/watch?v=3lioXpMxIpg

Ga jij maar lekker met het OV, maar mij niet gezien.

[Reactie gewijzigd door Titan_Fox op 23 juli 2024 02:25]

[Breezers]

Privacy is bij bedrijven niet echt belangrijk, geld verdienen wel.

[_JGC_]

Als klant heb je geen alternatief, dus het boeit ze daar geen zak, kost toch geen klanten.
Misschien dat CPB een dikke boete op kan leggwn...

[OddesE]

Al aangetoond kan worden dat het bedrijf maandenlang van dit probleem wist en er niets (heel weinig) mee gedaan heeft dan is een dikke boete wat mij betreft idd op zijn plaats.

Beveiliging is moeilijk... dat maakt het duur. Je moet eerst goede (dus dure) mensen inhuren die weten wat ze aan het doen zijn en niet zomaar wat scripten... Daarna moet je die mensen de tijd geven om in alle rust een veilig systeem te bouwen (dus niet de deadline voor de veiligheid laten gaan)... Daarna moet je externe partijen inhuren om het te auditen... Vervolgens de problemen die zij vinden weer fixen etc etc.

Alles bij elkaar maakt beveiliging serieus nemen je project veel duurder dan gewoon lekker wat aankloten en eens te gaan kijken als het al mis is... Het is dus belangrijk dat de overheid en of de markt zelf er voor zorgt dat als het misgaat, dat dit dan ineens zo duur is dat de kostenbesparing van het niet serieus nemen van beveiliging ineens teniet wordt gedaan. Op dezelfd emanier waarop de boete op zwart rijden dermate hoog moet zijn dat als je structureel zwart rijdt je er toch op achteruit gaat omdat als je gepakt wordt je ineens alle winst kwijt bent.

Het probleem is dat het CBP nogal een tandeloze organisatie is. De NMA (tegenwoordig ACM) heeft een pietsie meer macht, maar ook dat stelt bijzonder weinig voor helaas...

Wat er moet gebeuren is dat de minister lastige vragen krijgt van journalisten en/of parlementariers... Dat hij of zij politiek in het nauw komt. Dan komt er misschien wat navolging. Maar ja dat gebeurt helaas maar nauwelijks.

[Anoniem: 120693]

Al aangetoond kan worden dat het bedrijf maandenlang van dit probleem wist en er niets (heel weinig) mee gedaan heeft dan is een dikke boete wat mij betreft idd op zijn plaats.

Beveiliging is moeilijk... dat maakt het duur. Je moet eerst goede (dus dure) mensen inhuren die weten wat ze aan het doen zijn en niet zomaar wat scripten... Daarna moet je die mensen de tijd geven om in alle rust een veilig systeem te bouwen (dus niet de deadline voor de veiligheid laten gaan)... Daarna moet je externe partijen inhuren om het te auditen... Vervolgens de problemen die zij vinden weer fixen etc etc.

Okay, en dat dus allemaal van overheidsgeld. Dus als je die een dikke boete oplegt betaal jij en ik die. En dat voor een fout die naar bekend geen schade heeft opgelevert en die zeer waarschijnlijk niet te misbruiken was.

Ik wil daar liever niet voor betalen, jij blijkbaar wel. Dat is vreemd.

[lezzmeister]

En dat voor een fout die naar bekend geen schade heeft opgelevert en die zeer waarschijnlijk niet te misbruiken was.


Hoe weet jij dat? En het feit dat ze die fout laten zitten zegt me dat ze erg laks zijn met dit soort zaken. De eerstvolgende keer dat er iets aan de hand, alleen dan is het wel een fout die makkelijk gebruikt kan worden, en dan doen ze hetzelfde: laat maar zitten, er zitten toch geen gevolgen aan.

Boete opleggen, ze hetzelfde laten doen met minder budget. Prijsverhogingen niet toegestaan, dat gebruiken ze toch voor de boete. Is dit niet mogelijk volgens hen? Onstla de verantwoordelijke managers en de boete vervalt. Het is zo eenvoudig.

[OddesE]

Ik wil die dikke boete aan iedereen opleggen die over de schreef gaat, niet alleen aan (semi-)overheids organisaties, maar ook aan commerciele bedrijven.

In het geval van commerciele bedrijven gaat dit ten koste van hun winst terwijl de baten (de boete zelf) naar de staat gaan, dus goedkoper voor ons belastingbetalers.

In het geval van (semi-)overheden gaat de boete ten laste van de ene overheidsorganisatie, maar komen de baten weer terecht bij een andere overheidsorganisatie... Netto dus neutraal voor belastingbetalers.

Ik zie dus niet het probleem. Verder moeten wij (het volk) altijd betalen als het mis gaat, of doordat onze informatie op straat ligt, of doordat de producten duurder worden, of doordat de belastingen omhoog gaan enz enz. Iets zegt me dat dat wel goed komt. Uiteindelijk heb ik liever dat ze zuinig zijn met mijn privé gegevens.

[Anoniem: 16328]

Bij de overheid ook niet het gaat erom dat mensen zo uitgebreid mogelijk gevolgd worden. Zoveel mogelijk datagraaien daar gaat het om.

[stresstak]

Toch moet dat mij niet gebeuren; ik word er ernstig pissig van. Echt, als ik het had gemeld en men had er vervolgens niks aan gedaan dan was er vervolgens een melding gegaan naar eenieder die het weten wil. Tot en met de verantwoordelijke minister aan toe.

[djiwie]

De minister is niet verantwoordelijk voor TLS, het is een privaat bedrijf waarvan de aandelen eigendom zijn van een aantal vervoersbedrijven.

[Alex)]

Waarvan de grootste aandeelhouder (NS) wel weer in handen is van de overheid. Weliswaar als privaat bedrijf, maar als een minister naar de directeur van NS belt en zegt "Jullie moeten er iets aan gaan doen" gooit dat wel wat gewicht in de strijd...

[arjankoole]

Waarvan de grootste aandeelhouder (NS) wel weer in handen is van de overheid. Weliswaar als privaat bedrijf, maar als een minister naar de directeur van NS belt en zegt "Jullie moeten er iets aan gaan doen" gooit dat wel wat gewicht in de strijd...

Werkelijk? Volgens mij krijgen ze alleen maar boetes, en gebeurt er niets. De dramatische achteruitgang van de kwaliteit van het spoor is voor mij de reden om op mijn 37e alsnog mijn rijbewijs te gaan halen,

[stresstak]

Dat maakt niet uit. Het moet bekend zijn. De Telegraaf is ook niet verantwoordelijk en die meld ik het ook. TLS, OV-chip en schandpaal. Ze horen bij elkaar.

[gimbal]

Dus het echte probleem: de interne issue handling/registratie binnen dat bedrijf is intens triest. Als er een issue doorheen glipt dat kan, maar dit is een high priority issue waar als je dat hoort je meteen aan de alarm bel trekt en je een hotfix release ASAP er doorheen gaat drukken. Tenzij intens triest probleem nummer 2 bestaat: er niemand aangewezen is om dat te doen.

Ik vraag me af of ze tenminste een issue tracker hebben of dat ze alles nog via email / excel sheets doen.

[BoringDay]

Volgens mij zit het probleem in de database blijkbaar wordt de ID van de gebruiker verkeerd gekoppeld met klant gegevens (vrij ernstige zaak lijkt me) maar dat toont tevens dat de opzet van de database technisch niet in orde is aangezien bij de juiste opzet dit niet mogelijk is.

[Reactie gewijzigd door BoringDay op 23 juli 2024 02:25]

[WhizzKid-Eddy]

We zitten inmiddels in augustus en het is nog niet opgelost... Waarom verbaast me dat nou weer niks?

[RVervuurt]

Omdat de juiste afdeling pas afgelopen week bericht hierover heeft gekregen. Het is heel slecht aangepakt, maar je kan de technische afdeling (dit dit soort dingen oplost) niets kwalijk nemen, gezien die pas vorige week bericht kregen hierover.