Facturen 19.000 T-Mobile-klanten waren toegankelijk op onbeveiligde server

T-Mobile laat aan Tweakers weten dat er tijdens een test facturen van ruim 19.000 klanten toegankelijk waren op een onbeveiligde server van een leverancier. Daarop is later malware aangetroffen voor het minen van bitcoins. Er zou geen bewijs zijn dat de gegevens zijn ingezien.

In communicatie naar getroffen klanten meldt T-Mobile dat het mogelijk is dat dit wel is gebeurd. Het lek deed zich voor bij een van de leveranciers van de provider die verantwoordelijk is voor het op de server plaatsen van de pdf-bestanden. Op die manier zijn de facturen via een app voor klanten inzichtelijk.

T-Mobile wil de naam van de leverancier niet bekendmaken. Het gaat om facturen van 20 januari tot 19 februari van dit jaar, die tijdens een test gedurende 'minimaal de eerste twee weken van juni' op een onbeveiligde server terecht waren gekomen, zo laat een woordvoerder weten aan Tweakers.

Toen bleek dat de server geïnfecteerd was met mining-malware, is deze meteen afgesloten en zijn de getroffen klanten geïnformeerd. Ook is er melding gemaakt bij de Autoriteit Persoonsgegevens. Op de facturen zijn naw- en belgegevens te zien, naast een kostenspecificatie. T-Mobile verwacht niet dat klanten last zullen hebben van het datalek en geeft aan dat er door klanten geen actie ondernomen hoeft te worden. Volgens de woordvoerder ging het niet om een gerichte aanval op de server van T-Mobile.

Reacties (64)

[Q]

Vaak gaat het fout zodra een bedrijf zaken doet met een 3e partij die zelf zijn/haar zaken niet goed op orde heeft.

Daarom is het zo van belang om bij het aangaan van een contract altijd clausules op te nemen die security en controle op security door een 3e partij afdwingen.

Ik zou zelf een audit van de IT van zo'n partij afdwingen voordat ik met ze in zee zou gaan.

[Reactie gewijzigd door Q op 25 juli 2024 09:42]

[Malarky]

Ik zou zelf een audit van de IT van zo'n partij afdwingen voordat ik met ze in zee zou gaan.

Dat gebeurd ook massaal en worden ISAE 3402 genoemd. Ik werk in de IT Audit en ik doe af en toe ISAE3402's voor grote organisaties. En nee, zoveel stelt het niet voor en daarom voorkom je echt dit soort problemen niet.

Het hele probleem van Audit's is sowieso dat het momentopnames zijn. Als een organisatie morgen een (test)server optuigd voor zichzelf of een klant (zoals bij T-Mobile) en daar overmorgen data opzet, zonder dat de server afdoende beveiligd is, dan vind een externe partij dat alleen als die precies die dag in de systemen aan het graven is en de organisatie zelf die systemen ook nog is als in-scope heeft aangemerkt, wat onwaarschijnlijk is.

[latka]

Herkenbaar: ik doe nog wel eens de afnemende kant van ISAE3402. Gewoon niet vertellen waar de problemen zitten. De kans dat de auditor ze vind is nihil dus je zou wel gek zijn ze te gaan wijzen op de gebreken in je organisatie. Als ze dreigen wat te vinden gewoon overheen stappen en de auditor opzadelen met zoveel evidence dat het zoeken wordt naar een speld in een hooiberg. Nee: audits/certificeringen zijn er alleen om managers in te dekken. Niet om problemen te voorkomen voor klanten.

[Rinzwind]

En werk vooorrr de boekhouders/auditors. Het is vaak lachwekkend gesteld. De kennis en tools ontbreken bij de auditor. Vragenlijstje afwerken vinkjes zetten. Zoals eigenlijk vrijwel alle officiele bureaucratische controles. Onderwijscontroleurs? Van te voren aangekondigd en totaal voorbereid.

[Q]

Je hebt helemaal gelijk maar het gaat mij niet eens om perfectie.

Ik werd ooit zelf betaald om 'moeilijke vragen' aan bedrijven te stellen en technische audits te doen (nmap/nessus/etc) en je kreeg snel door welke partijen het gewoon niet snapten, het niet wilden snappen en die het wel begrepen.

Alleen met die laatste groep is er hoop, want inderdaad, het blijft een moment opname.

[CAPSLOCK2000]

Daarom is het zo van belang om bij het aangaan van een contract altijd clausules op te nemen die security en controle op security door een 3e partij afdwingen.

Eigenlijk wil je ook een clausule opnemen wat de 3e partij verantwoordelijk is voor alle schade die door hun nalatigheid wordt veroorzaakt. Het is alleen erg lastig om zo'n contract te krijgen, de meeste bedrijven weigeren dat of maken het onbetaalbaar duur, als puntje bij paaltje komt dan weten de meeste bedrijven best dat hun beveiliging slecht is.
De paar partijen die wel echte garanties durven te bieden zijn meestal te duur. Dat is echter nooit reden om de wensen dan maar naar beneden bij te stellen.

Ik vrees dat er eerst een paar megaboetes moeten worden uitgedeeld voor er genoeg geld en realisme beschikbaar komt om het beter te doen.

[Luno]

De vervolgschade is vrijwel altijd uitgesloten. Ook omdat de aannemende partij niet weet hoeveel dat kan gaan zijn.
Boeteclausule hebben maar een zeer beperkt nut. Stel dat iemand een server/informatiesysteem voor je neerzet met 99.99% uptime garantie en anders boete van 5000€. Op het moment dat de boel in elkaar stort en herstel de leverancie > 5000€ kost, kiets ie er voor 5000€ te betalen. Ben jij 5000 rijker, maar hebt nog steeds geen werkende server/informatiesysteem.

Een goede security audit kost tonnen, en is ook dan nog steeds slechts een momentopname. [opamode] Na de audit is per ongeluk ergens een modem bijgekomen voor thuistoegang, buiten alles om ... dat soort dingen zijn gebeurd en gebeuren nog steeds [/opamode]

[arnovos]

Dat is juridisch bezien onzin. Je hebt een contract voor 99, 99% uptime in jouw voorbeeld en een boeteclausule van €5000 per tijdseenheid/keer waarin die uptime niet wordt gehaald.

Het probleem niet oplossen betekent dat je het aanzienlijke risico neemt om opnieuw €5000 verschuldigd te zijn wanneer de uptime opnieuw niet waargemaakt wordt.

De boete is eenmalig als je daarna het probleem fikst. Laat je het probleem als leverancier zitten, dan trigger je de boeteclausule vanzelf weer een keer. Kost weer €5000 aan boete.

Plus dat je klant daarna gaat zeggen: we ontbinden het contract, want je levert duurzaam de uptime niet die we afspraken. Of hij stelt je aansprakelijk voor de (vervolg)schade.

TL;DR enkel een boete betalen lost je probleem als leverancier niet op. Zolang je als klant tenminste je niet laat afschepen met een smoesje.

[Luno]

Nee die boete is niet per tijdseenheid. Maar eenmalig.
En ontbinden contact is niet mogelijk, door voldoen aan boete voldoet de aannemer aan het contract.
Praktijk voorbeeld uit cursus SLA,

[CAPSLOCK2000]

De vervolgschade is vrijwel altijd uitgesloten. Ook omdat de aannemende partij niet weet hoeveel dat kan gaan zijn.

Het is moeilijk, maar de huidige situatie is ook niet wenselijk. De huidige situatie is dat er vaak geen enkele kwaliteitscontrole is op IT waardoor men keer op keer weg komt met verwaarloosde beveiliging.

Ik weet niet hoe het juridisch geregeld moet worden maar ik weet wel dat het iemand op een of andere manier veel geld moet kosten voor er iets gaat veranderen. Nu worden de problemen zo veel mogelijk genegeerd waarna de gevolgen en de kosten bij de slachtoffers komen. Die hebben echter geen manier om zich te verweren. Gezien de schaal van dit probleem is iedereen in deze slachtoffer, de kosten komen dus bij de maatschappij terecht. Zo betalen we met z'n allen soort belasting voor slechte IT.

Op een of andere manier moeten we zorgen dat die kosten terecht komen bij de directeuren, bedrijfsleiders en aandeelhouders.

[Verwijderd]

Ik vrees dat er eerst een paar megaboetes moeten worden uitgedeeld voor er genoeg geld en realisme beschikbaar komt om het beter te doen.

In ons strafrecht kan je aansprakelijk zijn voor slechte beveiliging (is naar mijn idee nog nooit gebruikt) maar straffen omdat er ergens een fout is gemaakt is bijzonder ingewikkeld. Zeker niet als er geen bewijs is dat er inderdaad schade is (zoals hier). Ik geloof dus niet dat mega boetes mogelijk en/of wenselijk zijn. Zeker niket omdat het betreffende bedrijf zelf al vaak op grote blaren moet zitten.

Maar ook in de privee sfeer, als jouw PC deel van een botnet is en mijn PC infecteerd kan ik je dan aansprakelijk stellen voor de schade? Zeker wel als jij het botnet zelf geinstalleerd hebt maar als je de firewall per ongeluk uit hebt gezet zeker niet.

[CAPSLOCK2000]

Zeker niet omdat het betreffende bedrijf zelf al vaak op grote blaren moet zitten.

Dat betwijfel ik. Volgens mij doet het helemaal niet zo veel pijn en komen de meesten er vrijwel ongeschonden uit. Ze doen een extra persberichtje de deur uit en alle extra aandacht daardoor compenseert wel weer voor de verliezen.
Ik hoor nooit van mensen die een andere leverancier kopen omdat de vorige is gekraagt. Zelfs de hack van Ashley Madison was niet genoeg om klanten dat bedrijf de rug toe te doen keren.

Maar ook in de privee sfeer, als jouw PC deel van een botnet is en mijn PC infecteerd kan ik je dan aansprakelijk stellen voor de schade? Zeker wel als jij het botnet zelf geinstalleerd hebt maar als je de firewall per ongeluk uit hebt gezet zeker niet.

Als mijn auto schade maakt dan ben ik daar voor aansprakelijk. Het maakt niet uit of ik als bestuurder een fout maak of dat een defect aan de auto de oorzaak is. Ik ben verantwoordelijk voor de schade. Als ik goed verzekerd ben dan draaien die hopelijk voor de kosten op en misschien kunnen zij hun geld weer terughalen bij de fabrikant van de auto, maar ik ben aansprakelijk. Als mijn software schade veroorzaakt dan kan, praktisch gezein, ik alle verantwoordelijkheid echter naast me neer leggen.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 09:42]

[Verwijderd]

Eigenlijk wil je ook een clausule opnemen wat de 3e partij verantwoordelijk is voor alle schade die door hun nalatigheid wordt veroorzaakt

Ja, dat wil natuurlijk iedereen wel. Alle schade en ook vervolgschade vergoed hebben. Maar niemand die dat gaat geven natuurlijk. Alles kan gehacked worden. Als er dan ook nog megaboetes gaan worden gegeven, dan zullen veel bedrijven ermee ophouden.

Zal er ook aan liggen wat je betaalt natuurlijk. En voor een full service level agreement met garanties binnen een bepaalde responsetijd haken veel klanten al af als ze de prijs daarvan horen. Als je bijvoorbeeld bij een budgetleverancier van webhosting waarvan bekend is dat er vaak wat uitligt een bedrijfskritische web applicatie gaan hosten voor een paar euro in de maand, dan kan je natuurlijk niet verwachten dat je duizend euro per dag aan gederfde inkomsten vergoed gaat krijgen als er een keer wat misgaat. Maar sowieso staat er in elke voorwaarden die ik zelf onder ogen krijg dat aansprakelijkheid bij vervolgschade nooit gedekt is.

Zoiets was er ook toen jaren geleden KPN er 2 weken uitlag en een paar jaar geleden Vodafone 2 maal 1 werkweek achter elkaar. Toen waren er nog bedrijfjes op het journaal die zeiden dat ze tweeduizend euro per dag schade liepen omdat hun telefoon eruit lag. Nou, wat kregen ze, ik geloof de helft van hun maandgeld terug (da's lache, een tientje op een abo van 20 euro in de maand), of nog niet eens, ik dacht dat er een weekend gratis gebeld mocht worden. Ik had/heb altijd beltegoed over, dus ik had daar helemaal niets aan. Wel was ik 2 weken telefonisch onbereikbaar, maar ik zit daar niet mee, ze kunnen me altijd een mailtje sturen.

[downtime]

Ik heb de indruk dat veel bedrijven dat als een probleem van de leverancier zien zodra ze werk uitbesteden. Ik zie na een datalek wel erg vaak smoesjes van het soort "was niet onze schuld, het was de leverancier".

[Luno]

Yep. We gooien het over de muur en daar zoeken ze het maar uit. Hub pakkie an. Alleen je krijgt het wel vroegâh of later op je bordje.

[Verwijderd]

Ja, komt me bekend voor. Of een website opleveren maar dat ze jaren geen geld willen uitgeven aan onderhoud en security-updates. En als die website dan eindelijk gehacked is, helemaal tekeer gaan tegen je dat het jouw schuld is, omdat jij hem gebouwd hebt en dus de leverancier bent.

Of nog gekker:

Maak je een mooie website voor iemand, neemt hij na een paar jaar contact met je op: "Ik heb een plaatje wat niet van mij was, op mijn website gezet, en nu heb ik een afpersbrief van GettyImages gekregen of ik even 3000 dollar wil betalen. Ik heb ze natuurlijk direct naar jou doorgestuurd, maar ze zeggen dat ze daarop niet in kunnen gaan, omdat ik de eigenaar ben en verantwoordelijk ben, en jij, de bouwer, niet. Kan jij dit even oplossen?"

Ehhh, nee. Op zo'n manier en met zo'n instelling wil ik natuurlijk niets meer met je te maken hebben als leverancier.

[Verwijderd]

Check..
Sanoma steekt hier flink bovenuit met het serveren van malware middels een derde partij, waarvan zij uiteraard vinden geen schuld te hebben.
Eigenlijk zou met name deze club gewoon een online advertentie verbod opgelegd moeten worden. (ja, ik weet dat dat hun héle verdienmodel is)

Dezelfde reden, waarom ZZP'ers zo erg door de politiek werd 'gestimuleerd'. Zijn makkelijk te lozen 3e partijen, zodat je zelf geen verantwoordelijkheid hoeft te nemen.

Met grotere multinationals, waarvan T-Mobile er ook eentje is, is het nooit meer te vertrouwen. In oog van een dubbeltje per jaar meer kunnen ze, waar dan ook, hele stomme dingen doorvoeren.

[Stefandepefan]

In mijn ervaring kan een partij na een audit dusdanig wijzigen dat ze opeens niet meer zouden voldoen aan de audit. Echter zit je dan al met een aantal projecten bij zo'n leverancier als opeens de shit de fan raakt...

[Armin]

Ik zou zelf een audit van de IT van zo'n partij afdwingen voordat ik met ze in zee zou gaan.

Op zich niet oneens, maar dat wringt weer met de 3rd party aanbieder met de laagste prijs kiezen.

En aangezien - zéker in Nederland - telcom nog altijd vooral een concurentie op prijs is, is elke cent die een provider moet uitbesteden een cent die weer in de abbonementsprijzen moet.

[geenstijl]

Dit geeft maar goed aan hoeveel bedrijven nog moeten leren op IT(beveiliging)-gebied.
Als ze juiste procedures zouden hebben (lees: nooit productiedata gebruiken op testomgevingen) dan zou er relatief weinig aan de hand zijn.
Vrij zorgelijk dat zelfs grote bedrijven als T-Mobile dit niet goed op orde hebben.

Ik hoop dat er daar intern redelijk wat mensen een "schop onder hun kont" krijgen, inclusief de leverancier. Als professionele partij zouden zij ook T-Mobile moeten adviseren dat ze geen "productie-data" willen hebben op testomgevingen.

[mashell]

Als ze juiste procedures zouden hebben (lees: nooit productiedata gebruiken op testomgevingen) dan zou er relatief weinig aan de hand zijn.

Je moet juist altijd testen met echte data. Anders kom je in de situatie dat het het wel werkt met je Testgebruiker12345 maar niet niet de echte data van Ölga Änderson.
Echter je test systemen moeten natuurlijk net zo beveiligd zijn als je klant systemen. Overigens denk ik dat de overbodige abstactie in naamgeving zoals "productiedata" (bij elke fabriek is wel een kantoor, die mensen draaien als je het hen vraagt geen productie, maar de ITer beweert wel dat ze productiedata produceren) en "testomgeving" (waar begint en eindigt de omgeving?) ook een deel van het probleem is. Als je bijvoorbeeld spreekt over een testserver dan weet iedereen dat het slechts een server is, spreek je van een testomgeving dan kan dat een server, een gesimuleerd netwerk en soms ook een bepaalde ruimte in een gebouw betekenen.

[Verwijderd]

De tests op echte data doe je echter intern en laat je uitsluitend door interne mensen doen die al authorizatie hier voor hebben. En dat doe je met een kloon van de productieomgeving die je daarna weggooit.

Niet een derde partij die eens even een nieuwe feature van hun ontwikkelaars er mee gaat testen.

Misschien dat mensen van die derde partij mogen aanwezig zijn op die test. Maar het kan niet de bedoeling zijn dat de testers / ontwikkelaars van die derde partij mogen mee kijken in die live data. Dat zijn hun zaken niet.

En als je Unicode wil testen dan zijn er omgevingen zat die voldoende realistische namen kunnen genereren voor je.

[Armin]

De tests op echte data doe je echter intern en laat je uitsluitend door interne mensen doen die al authorizatie hier voor hebben. En dat doe je met een kloon van de productieomgeving die je daarna weggooit.

Probleem is dat providers vrijwel niets zelf doen, maar alles van het mobiele netwerk zelf, tot aan de apps die ze aanbieden uitbesteden. Zelfs sales en klantenservice zijn vaak uitbesteed.

[beerse]

De testen kunnen wel met echte data gebeuren maar dan alleen binnen de eigen labs. Niet bij de leverancier en al helemaal niet op internet.

Voor testen bij leveranciers zou de data op zijn minst geannonimiseerd moeten worden. Daar zijn volgens mij zelfs regels en standaarden voor.

[BadpunK]

Het is een kleine moeite om testdata (lees echte productie) te anonimiseren. Dit mag geen excuus zijn om het niet toe te passen. Verder richt je doorgaans ook een OTAP straat in om te testen. Hierbij is de acceptatieomgeving qua hardware gelijk aan Productie. Omdat je binnen de organisatie het hebt over bepaalde type servers/pakketten is het makkelijk te specificeren. Een keten zoals jij bedoeld is dan een samenvoeging van meerdere servers. De samenhang is dan ook altijd bekend binnen de organisatie bij de mensen die ermee werken.

[geenstijl]

Misschien had ik het duidelijker moeten stellen:
Uiteraard moet je werken met gegevens die zo veel mogelijk productie-like zijn (qua aantallen, differentiatie etc.), echter dien je deze dan wel gewoon te anonimiseren.
De termen test/productie zijn om het verhaal even simpel te houden, uiteraard zijn er verschillen in interpretaties van de termen binnen verschillende bedrijven.
Maar juist dit zou gewoon in de procedures vastgelegd moeten zijn. (wat mag er waar met welke data gebeuren)

[mrwolf]

Procedures is 1, die zullen er ongetwijfeld zijn. Je eraan houden is een tweede. Hoeveel makkelijker en dus verleidelijker is het niet om productiedata te gebruiken voor tests? Anders moet je data gaan scramblen (vaak niet of niet voldoende geregeld), of niet-representatieve testdata gebruiken.

[Barryke]

Hè verdorie. Was er eindelijk een manier om mijn oudere facturen wel in te kunnen zien, hebben ze het gefixt.

Maar serieus, ik vind het echt belachelijk dat enkele bedrijven (kuch T-Mobile kuch) tegenwoordig geen facturen meer versturen, maar slechts een email waarin staat dat je het daar op die site kan vinden. En soms maar een paar maanden. Dat ze zoveel euro rekenen voor een papieren factuur is al gek genoeg, maar dit vind ik erger.
Stuur de factuur dan aub gewoon als bijlage, dan heb ik 'm tenminste. Alsof je een brief krijgt waarin staat "je kan je factuur vinden op de Julianastraat 130b, vergeet je sleutel niet en ga dan links links links rechts links."

[Reactie gewijzigd door Barryke op 25 juli 2024 09:42]

[downtime]

Ze mogen dat niet meer als bijlage versturen. Het is mogelijk privacy gevoelige informatie en email wordt niet als veilig medium gezien (want gewoon door jouw ISP in te zien).

[Barryke]

Maar dan kunnen ze het toch wel aanbieden als opt in?

Maar inderdaad email is niet erg veilig. Maar een beter protocol dat zie ik nog niet zo snel gebeuren.. het is al heel wat dat de grote mail partijen het onderling enigzins veilig overdragen via modernere protocollen maar het zal nog wel even duren voordat de meeste clients die ondersteunen.

[Armin]

KPN stuurde mijn factuur anders tot februari dit jaar gewoon per email?
(Daarna opgezegd, dus weet niet of het inmiddels anders is.)

En KPN had tot maart dit jaar niet eens encryptie op hun inter-SMTP servers

[Abbu-kun]

Ja de facturen van KPN waren gewoon een HTML tabelletje in je mail.

Ik meen dat als je nog je legacy planet.nl adres hebt je nog steeds niet een beveiligde verbinding kan maken voor je mailbox vanuit Thunderbird enz. Paar jaar geleden toen ik wat dingen voor me ouders regelde had ik KPN daar nog over gebeld dat ik het raar vond dat alles onbeschermd werd verstuurd, inclusief het wachtwoord waarmee je inlogt op de server. (Volgensmij was dit de POP3 verbinding en niet SMTP?) Heb het toen express niet ingesteld op mijn ouders hun laptop omdat die op de camping zou verbinden over open WiFi. (En neeeeee KPN webmail was te bout qua UI in die tijd om uit te leggen hoe het werkt.) Moet binnekort maar eens gaan testen of dat nu wel gefixed is en hoe de facturen nu geregeld zijn als ik weer naar hun computer kijk (Pampampaaam )

Maargoed het is niet alleen door je ISP in te zien zoals downtime zegt; ik begreep dat je gewoon niet kan garanderen dat elke hop die je mailtje maakt versleuteld zal zijn, zelfs als je ISP het wel naar jou en derden toe inzet. Het is in princiepe een beetje als je rekeningnummer op een ansichtkaartje zetten? Wordt natuurlijk nog gekker als je andere overheidszaken of medische gegevens zo zou laten versturen. Beveiliging staat helaas vaak haaks op gebruikersgemak?

[SeaFish]

Dit doen al die bedrijven natuurlijk niet voor niks. Het probleem zit hem in de beveiliging van e-mail in zijn geheel. Encryptie is hier niet standaard en het is dus eigenlijk onverantwoord een bijlage met zulke persoonlijke gegevens als een gespecificeerde telefoonrekening te sturen. Door in te loggen wordt de verbinding in ieder geval beveiligd.

Dat je maar een paar maanden terug kan kijken is wel irritant soms, maar als deze gegevens daadwerkelijk verwijderd worden is de impact van een lek natuurlijk wel kleiner. Helaas verwacht eigenlijk niet dat dit soort data ooit gewist wordt.

[dinnuk]

Klopt. Bij mij in de T-Shop kan ik facturen to +- 3 jaar terug voor de klant opvragen, en via klantenservice volgens mij nog verder (moet je wel iets langer wachten).

semi-offtopic: het getekende contract wordt encrypted verstuurd naar de klant vanwege privacy. Als ik zie hoeveel 'gedoetjes' die encrypt-tool geeft voor alleen al de contracten die afgesloten en verstuurd worden denk ik dat het ondoenlijk is om die duizenden facturen tegen fatsoenlijke tarieven te encrypten en versturen...

[PhilipsFan]

Stuur de factuur dan aub gewoon als bijlage, dan heb ik 'm tenminste. Alsof je een brief krijgt waarin staat "je kan je factuur vinden op de Julianastraat 130b, vergeet je sleutel niet en ga dan links links links rechts links."

Ja vervelend is dat. Er is een hele tendens gaande. Krijg ik een mailtje van de belastingdienst of de school van m'n kinderen, dat er een mededeling klaar staat. Moet ik eerst weer inloggen, pardon, username/password opzoeken en waarschijnlijk resetten omdat ik dat al te lang niet meer heb gebruikt. Of ik ben onderweg en krijg de mail op m'n iPhone, waar ik dat password dus niet bijdehand heb.

Ik begrijp de privacybezwaren, maar de meeste dingen zou ik prima per e-mail kunnen ontvangen. Een opt-in zou een prima oplossing zijn.

[Arjan90]

Tijd voor een password manager ;-) Maar eens, eigenlijk zou het beveiligd moeten worden met een wachtwoord zoals bij ons op het werk gebeurt met loonstrookjes.

[Verwijderd]

Inderdaad, vervelend.

Bij het ene bedrijf krijg je je factuur wel netjes bijgesloten als pdf, bij het andere krijg je niets.

Bij sommige bedrijven krijg je ook een mailtje dat je moet inloggen om te betalen met iDeal, of om uberhaupt om iets te kunnen betalen, ook al wil je gewoon zelf overschrijven.

Of van Mijn Overheid: "Er is een bericht in uw berichtenbox. We sturen geen bijlagen meer mee want onveilig." Links naar de berichtenbox op Mijn Overheid staan er dan dus ook niet bij en zelfs lichten ze niet eens een tipje van de sluiter op waar dat bericht dan over gaat. Vanwege fishing en malware e-mails. Nou, zo'n mail kan ook iedereen sturen en als ze er wel een linkje in zetten dan kan je 'aan de haak geslagen worden'. Maar goed. Log je een keer in na zo'n mailtje, krijg je een paar dagen later weer zo'n bericht. Exact dezelfde brief. Aaaaaaarghhh!

[Collen]

raar dat leveranciers toegang moeten hebben tot klant gegevens ?!

helaas is dit soort nieuws meer regel dan uitzondering tegenwoordig.

[Bender]

raar dat leveranciers toegang moeten hebben tot klant gegevens ?!

helaas is dit soort nieuws meer regel dan uitzondering tegenwoordig.

Dat is toch niet raar? Een hoster (de leverancier) heeft in toch ook toegang tot de data van een gehoste webshop?

[PolarBear]

Dat is toch niet raar? Een hoster (de leverancier) heeft in toch ook toegang tot de data van een gehoste webshop?

Dat hoeft natuurlijk helemaal niet.

[Bender]

Hoe zie je het dan voor je, niet laten beheren lijkt me geen optie.

[RGAT]

Beheren =/= toegang, hoster kan prima de klant een eigen account laten gebruiken waarmee de database enz. aangesproken wordt, eventueel met auditing waardoor een systeembeheerder die erin duikt gelijk opgemerkt wordt.
Daar zijn zat standaarden voor die gehaald moeten worden wil een hoster certificeringen behalen.
Verder zou dit meer zijn als de hoster de klantinfo van de website eigenaar aan Cisco (leverancier switches bijv.) geeft zodat Cisco ermee kan spelen, gewoon een hele aparte constructie, die data had op zijn minst geanonimiseerd moeten zijn, niet op internet en ook was een degelijke virusscan niet ongepast geweest...

[Keipi]

Bij een test kunnen dit soort dingen natuurlijk gebeuren, maar waarom waren echte klantgegevens aanwezig bij een test?

Waarom niet random gegenereerde facturen?

[Luno]

De enige goede test is op de productiegegevens.
't vaak meegemaakt dat alles in orde leek op een testset. Maar dat de praktijk extremere gevallen heeft dan je als tester bedenkt.
Maar dan moet je niet de testgegevens via interpret toegankelijk maken.

M'n voorkeur zou zijn: met testgevens ontwikkelen. Totdat het er goed uitziet.
Backup van productie omgeving maken, daarop nieuwe software zetten en testen. Dus accepatie pas test op productieomgeving. Dus OTPA ipv OTAP.

[Ryan_]

Netjes dat T-Mobile hier zelf mee naar Tweakers komt.

[Decipher666]

Dat hebben ze niet zelf gedaan:

Facturen 19.000 T-Mobile-klanten waren toegankelijk op onbeveiligde server

Door Sander van Voorst, woensdag 27 juli 2016 15:30, 5 reacties • Feedback
Submitter: d-snp

Oftewel waarschijnlijk een van de getroffen gebruikers is een Tweaker die het gesubmit heeft.
Overigens wel schandalig dat ze hier zo makkelijk nu mee weg komen. Ik mag hopen dat de AP hier nog iets mee doet.

[duqu]

Was inderdaad een submit waarna wij navraag hebben gedaan.

[d-snp]

Jup

[WhatsappHack]

Denk ook damage control. Immers zijn ze verplicht datalekken te melden bij de AP, dus dan is het beter dat ze zelf contact opnemen met de media dan dat ze het op een andere wijze moeten vernemen.

[Room42]

Ze zijn het sowieso wettelijk verplicht om te melden (Wet Datalekken) en aangezien ze ook al een brief naar hun klanten gestuurd hebben, kunnen ze voor hun gezicht maar beter zelf de media ook opzoeken. Hier zit dus niks 'netjes' bij. Het is pure damage control (en dat is terecht, hoor, daar niet van).

[Reactie gewijzigd door Room42 op 25 juli 2024 09:42]

[TwArbo]

Dat is gewoon damage-control.

[MarkHero]

Mooi, betaal hem ook even voor mij.

[Verwijderd]

T-Mobile verwacht niet dat klanten last zullen hebben van het datalek

Dat is niet waar... er staan naw gegevens op elke PDF inclusief naam, bedrijfsnaam, adres, telefoonnummer, rekeningnummer (zie de acceptgiro maar eens) en toebehoren. Er kan misbruik mee worden gepleegd en stellen dat het niet openbaard is is onzin.

Men weet dat niet, en kan als de hacker slim was geweest elke trace verwijderen die de facturen hebben gedownload.

[Kabouterplop01]

- productie data op test
- testomgeving aan het internet
en besmet met malware

Tsk...

[SunnieNL]

Waarom zou een andere leverancier de facturen moeten hebben van de klanten van T-Mobile?
Ik kan echt totaal niet bedenken waar dat goed voor zou zijn en wat die voor dienst aanbieden waar ze die facturen voor nodig hebben.

[Bender]

Zoals ik het lees is het omdat het gehost wordt.
Het is niet vreemd dat hosting bij een externe leverancier ligt, ieder zijn vakgebied immers.

[SunnieNL]

De facturen worden pas gegenereerd als je ze opvraagt. En zou logisch zijn ze binnen x minuten weer te verwijderen na genereren. In dat geval ligt het probleem niet bij de hoster maar in de software die tmobile gebruikt voor het klantportaal.

[Armin]

En die software is zo goed als zeker ook weer ontwikkeld door een 3rd party

Maar ik kan ook best wat legitieme redenen bedenken om de zaak wat langer te bewaren. Namelijk caching. Mensen die facturen bekijken kijken niet zelden dezelfde factuur een paar keer. Bijvoorbeeld door te wisselen tussen de huidige en vorige maand view.

Het ena grootste probleem is dat de data niet encrypted was. Alhoewel ook dat niet noodzakelijk bescherming gaf, want als de server zelf gecompromeerd is (er zat immers malware op) dan kan het best zijn dat een aanvaller de ecnryptie kan omzeilen afhankelijk van op welke logische laag de ecnryptie zit.

Het grootste probleem dat de server extern toegangkelijk was ipv enkel door/via T Mobile servers. Maar ook dat kan op zich verdedigbaar zijn onder bepaalde omstandigheden ...

We weten eigenlijk helaas de details niet. Dat er een fouten gemaakt zijn is echter evident natuurlijk.