Data van Centric verschijnt op site van ransomwarebende

Op de website van ransomwarebende Clop is data van het Nederlandse ict-bedrijf Centric verschenen. Het bevestigt in een verklaring dat er data is gestolen van een testsysteem via een bug in externe software. Het gaat om 'een zeer beperkt aantal privacygevoelige gegevens'.

De data is te zien op de website van Clop, een ransomwarebende die bekendstaat om het niet meer versleutelen van systemen, maar enkel nog afpersen met datadiefstal. Tweakers berichtte vorig jaar nog over die trend. Een woordvoerder van Centric wil niet verder uitweiden over de aanval en verwijst naar een verklaring op de website. Daarin staat dat Centric is getroffen door een bug in de filetransfersoftware Cleo. Die stond op een testserver.

De Clop-ransomwarebende begon eind vorige maand met het afpersen van bedrijven nadat het via Cleo data had gestolen. Het is niet zeker of Centric destijds al tot deze groep slachtoffers behoorde, maar dat lijkt wel aannemelijk.

Het is ook onduidelijk welke data Clop precies heeft gepubliceerd. Op de website van Clop zijn verschillende datasets van gezamenlijk meerdere gigabytes te downloaden. Centric zegt dat het gaat om 'een zeer beperkt aantal privacygevoelige gegevens, gecompromitteerd van één klant', en dat de kwetsbaarheid 'geen impact heeft op andere systemen of onze dienstverlening'.

Reacties (76)

[berryflash]

Het betreft hier een test omgeving van Centric. Als ik de informatie goed heb ontvangen.

Zie ook: https://centric.eu/nl/nieuws/kwetsbaarheid-in-testserver/

[Reactie gewijzigd door berryflash op 24 januari 2025 14:21]

[oef!]

Ik begrijp alleen niet waarom er geen geanonimiseerde productiedata op een testsysteem staat. Dat is anno 2025 niet erg chique.

[TijsZonderH]

Ik heb eens iets opgevangen over dat als je met overheidsdata werkt, je niet met uitsluitend testdata kan of mag werken. Maar dat is een gevalletje klok en klepel, ben benieuwd of er devs zijn die met overheden werken die hier wat meer duidelijkheid over kunnen geven.

[sOid]

Integendeel. Als CISO bij een uitvoerende overheid hamer ik er altijd op dat er niet wordt getest met productiedata. Zie ook de BIO (ik kan momenteel niet de specifieke controls opzoeken).

Het is helaas niet altijd mogelijk. In dat geval moet data geanonimiseerd/gepseudonimiseerd en geminimaliseerd worden.

Meest idiote dat ik heb meegemaakt is dat leverancier bij een demo zei testdata te gebruiken, maar een collega die net in de organisatie zat productiedata van een vorige werkgever herkende.

[Frame164]

Soms wil je ook met echte de data te de testen om te voorkomen dat je bepaalde combinaties van data mist. Ik heb dat bij migraties vaak genoeg meegemaakt. Dan werkt het allemaal prima in OTA maar faalt het tijdens een echte migratie omdat er altijd wel data is die er eigenlijk niet had kunnen zijn volgens de specificatie.

[sOid]

Dat is inderdaad een van de scenario’s waar ik op doel. In dat geval kunnen er vaak wel maatregelen als minimalisatie (representatieve steekproef van de dataset ipv hele database), anonimisering etc worden toegepast. En het verwijderen van de data na het testen.

Hangt ook af van het risicoprofiel van de dataset en applicatie. Maar feitelijk blijft het in de meeste gevallen onwenselijk.

[blorf]

Je zou zeggen dat ze naar een probleem zaten te zoeken en daarbij echte data gebruikten om een oorzaak uit te sluiten. Handig is het niet zo. Volgens mij is het in zo'n geval alleen maar zaak om die data beter te specificeren. Als test/simulatie-data tekort komt mankeert daar iets aan. Dat had al getest moeten zijn.

[Aalard99]

Op het moment dat je dat doet moet je ook de beveiligingsmaatregelen hanteren alsof het een productie systeem betreft. Ik snap dat je soms die scenario's hebt maar je hebt niet meer de vrijheid om zomaar van alles te testen.

[Floort]

Oei, ik hoop dat het bij je collega's ook doordrong wat het betekent als een leverancier laat zien bereid te zijn om klantdata (incl. persoonsgegevens) voor eigen doeleinden te verwerken, deze gegevens te tonen aan derden en te liegen over hoe ze met klantdata omgaan. Dat lijkt me een lastige vertrouwensbreuk om te repareren.

[sOid]

We zijn ook zeker niet in zee gegaan met deze partij.

[beyazz06]

Als ik het goed heb stelt de BİO (Baseline İnformatiebeveiliging Overheid) dat er geen productie data in OTA gebruikt mag worden.

[Floort]

Helaas, volgens 14.3.1 van BIOv1.0.4zv: "Testgegevens behoren zorgvuldig te worden
gekozen, beschermd en gecontroleerd.". De conceptversie van BIO 2 bevat een vergelijkbaar vage formulering.

Als het gaat om persoonsgegevens kan je je bijvoorbeeld wel afvragen of de verwerking van persoonsgegevens noodzakelijk is voor het testen (art. 5(1)(c) AVG), of het doel van testen past bij het oorspronkelijke doel van de verwerking (5(1)(b)), of de testomgeving voldoende beveiligd is (art. 32 AVG), etc.. Soms is testen met echte (persoons)gegevens noodzakelijk en rechtmatig. Soms wordt er getest met echte gegevens omdat dat makkelijker is.

[djwice]

Wij gebruiken speciale test BSN, test OIN en test adressen in de OTA omgeving bij een overheids systeem.

Van die gegevens is geregistreerd welk doel ze hebben en dat ze niet overlappen voor echte organisaties of burgers, maar wel voldoen aan alle kenmerken.

Geboortedata zijn in een range gedistribueerd gekozen, die overlappen uiteraard wel met echte burgers, maar zijn niet gekozen vanuit die personen. (met wie ze overlappen is ons niet bekend en is willekeurig).

[Reactie gewijzigd door djwice op 24 januari 2025 16:30]

[Floort]

Mijn oprechte complimenten. Ik zie het steeds vaker, maar nog niet genoeg. En uit eigen ervaring weet ik dat het best fijn is om fictieve persoonsgegevens te genereren om mee te testen, waar dat mogelijk is. Helaas is het nog niet overal zo ver ontwikkeld als het zou kunnen zijn. Verspreid de goede voorbeelden vooral. Testdatasets met fictieve persoonsgegevens kan je ook makkelijk delen.

[metalmania_666]

Toen ik 5 jaar geleden nog werkte bij een bedrijf dat veel met overheden te maken had en veel data verwerkte, kregen wij data aangeleverd om te testen. Echter bleek dat ze de data van de volledige gemeente Assen hadden aangeleverd.
Niet geannominiseerd of gepseudoniseerd.

Waar mensen werken, worden fouten gemaakt

[djwice]

Ik ontwerp het systeem zo dat mensen in een technische of functionele beheer rol niet bij de productie data kunnen.

Alleen de data eigenaar en de data consument zien de data die specifiek van of voor hen is.

Elke deel der heeft een aparte sleutel zodat ook als mensen of systemen on te recht data admin rechten verwerven in de toekomst een select all niet ontsleuteld kan worden met een sleutel.

[Reactie gewijzigd door djwice op 25 januari 2025 00:02]

[tweaker2010]

Als ik het goed heb stelt de BİO (Baseline İnformatiebeveiliging Overheid) dat er geen productie data in OTA gebruikt mag worden.

De BIO stelt wel meer, uit eigen ervaring weet ik dat de BIO een wassen neus is en in de praktijk draaien verschillende Acceptatie omgevingen ook met Productie data.

[Aalard99]

Is de BIO dan een wassen neus of is er nog voldoende werk te doen om de informatie security op orde te krijgen? BIO is beleid, dat borgt niet dat het niet gedaan wordt, daarvoor moet je organisatie een volwassen security governance hebben.

[Alexander72]

De BIO is absoluut geen wassen neus. Er zijn in mijn ervaring vrijwel geen overheidsorganisaties te vinden waar dit niet prominent op de agenda staat. Wat nog iets anders is dan dat men overal compliant is. Vanaf dit jaar wordt bij overheidsorganisaties overigens voor het eerst verplicht op werking van de BIO getoetst.

[tweaker2010]

Ik kan het ook op de agenda zetten. Er wordt door directie geroepen dat BIO verplicht is bij ontwikkeling, echter in de praktijk niet haalbaar want BIO trajecten duren vaak te lang.

[Sorcerer8472]

Volgens mij is het eerder andersom: volgens de AVG mag je geen persoonsgegevens gebruiken als het niet absoluut noodzakelijk is.

In sommige gevallen is het wellicht wel noodzakelijk, maar er zijn allerlei manieren om puur met testdata en test-instances te werken.

[TumTum]

Maar we weten dan ook niet of het om persoonsgegevens gaat of dat er andere zaken onder 'privacygevoelige' gegevens vallen.

[CAPSLOCK2000]

Ik heb eens iets opgevangen over dat als je met overheidsdata werkt, je niet met uitsluitend testdata kan of mag werken. Maar dat is een gevalletje klok en klepel, ben benieuwd of er devs zijn die met overheden werken die hier wat meer duidelijkheid over kunnen geven.

Dat klinkt inderdaad als klok-en-klepel.

In de basis ontwikkelen en testen we niet met productiedata. Wel is het zo dat geen enkele test ooit zo compleet is als de werkelijkheid. Je kan eindeloos veel testen maar je weet pas zeker of het werkt als je echte data in het systeem zit. Er komt dus een moment dat je voor het eerst productiedata in je systeem laadt en dan moet gaan controleren of alles naar verwachting werkt. Dat is echter deel van de integratie-/uitrolphase en niet zo zeer van deel van de ontwikkelfase. Niettemin wordt er op dat moment een test gedaan met echte data. Je zou ook niet willen dat de werking niet meer gecontroleerd wordt nadat zo'n systeem in productie is genomen.

Het verhaal wordt misschien een beetje vetroebeld doordat er verschillende vormen van "testen" zijn. Een acceptatietest is iets heel anders dan een programmeur die een nieuw ideetje zit uit te testen en zo zijn er nog wel 10 andere dingen die we "test" noemen.

[Reactie gewijzigd door CAPSLOCK2000 op 24 januari 2025 17:07]

[Floort]

Wel is het zo dat geen enkele test ooit zo compleet is als de werkelijkheid.

Ik snap wat je zegt, maar het tegengestelde is ook waar. Het mooie van fictieve testdata is dat je ook bij elke bug die getriggerd wordt door de data in het systeem je wat voorbeelden kan toevoegen aan de testdata die die bug triggeren, dan heb je meteen een regressietest en de kans om andere delen van het systeem te testen waar je vergelijkbare bugs misschien gemist hebt. Ook kan je afgrijselijk misvormde testdata genereren (trek je namen maar uit de big-list-of-naughty-strings github repo, etc.). Maar wat je zegt klopt: in de praktijk kom je gegarandeerd dingen tegen die je zelfs in je testdata niet had voorzien.

[nicenemo]

Een alternatief voor de big list of naughty Strings is de generators gebruiken van property based testing framework en hiermee test data genereren. Zelf gebruik ik hiervoor jqwik.

[The Zep Man]

Ik heb eens iets opgevangen over dat als je met overheidsdata werkt, je niet met uitsluitend testdata kan of mag werken.

Als dat waar is, dan richt je een acceptatieomgeving in met dezelfde veiligheidsstandaarden en eisen als productie. Daar kan je dan wel met de betreffende data de laatste tests doen voordat iets in productie gaat.

[Reactie gewijzigd door The Zep Man op 25 januari 2025 09:10]

[Buitenaerts]

Dit kan ik me niet voorstellen, dat zou wel erg slecht zijn. Wij hebben op onze dev omgevingen 0.0 klant informatie en data.

[mastair]

Wat is een testomgeving zonder data?

[Yalopa]

Test data met verzonnen namen en gegevens die realistisch zijn..

meest stomme voorbeeld zijn de testdatabases die MSFT geeft (tailwind trailers, contoso etc). maar in specifieke gevallen moet je dat dus zelf genereren..

[Frame164]

Je kunt altijd dingen missen als je data namaakt.

[mastair]

Hij had het over 0,0 klantinformatie en data. Klonk mij dus echt als een volledig lege omgeving.

[Triblade_8472]

Wellicht kan de download (rechtsonder de afbeelding na de link) je hiermee helpen.
https://www.cip-overheid.nl/producten-en-diensten/testen-met-persoonsgegevens

Een mooie quote hieruit: "In alle gevallen is een verwerking van persoonsgegevens alleen toegestaan voor een welbepaald, uitdrukkelijk omschreven en gerechtvaardigd doel. Testen is dat maar zelden."

[mjl]

Als het development omgeving is dan gebruik je nep data, maar een QA omgeving bevat wel degelijk de echte data. In dit geval zal het eerder een dev of sandbox omgeving geweest zijn, een QA omgeving beveilig je net zo goed als de productie omgeving tenslotte.

[.Vii]

Als wij aan het testen zijn op de systemen van het basis registratie persoonsgegevens dan is alles dummy data.

Dit geldt ook voor rdw,l en uwv, dus lijkt me sterk dat dat het geval is.

[elmuerte]

Als dat zo is ben ik niet bekend met die regel, en zelfs dan accepteer ik dat gedachtegoed niet. Onze development en interne test omgevingen zullen alleen gegenereerde data bevatten of zaken die geen enkele gevoeligheid hebben. Waar nodig maken we traces met hetzelfde "gedrag" van productie data.

Over de klant test en acceptatie omgevingen heb ik geen zeggenschap. Dus daar zouden gebruikers productie data kunnen invoeren. Maar dat zijn handmatige kopieer acties.

[Reactie gewijzigd door elmuerte op 24 januari 2025 18:14]

[Dennis]

Een voorbeeld wanneer het wenselijk is met echte data in testomgevingen (of liever sandbox-omgevingen zoals @mjl hieronder/hierboven al schreef) te werken in plaats van geanonimiseerde data is bijvoorbeeld als complexe mutaties moeten worden uitgevoerd in een burgerzakenapplicatie. Het is in die gevallen wenselijk eerst te testen voordat onomkeerbare wijzigingen in de productieomgeving worden uitgevoerd met alle BRP-gevolgen van dien.

[johanneslol]

Ik werk zelf bij de overheid als netwerk engineer. Het gebruiken van productiedata in test omgevingen is NOT DONE. Die moeten altijd strikt gescheiden blijven.

[Pasteis]

Ik heb eens iets opgevangen over dat als je met overheidsdata werkt, je niet met uitsluitend testdata kan of mag werken. Maar dat is een gevalletje klok en klepel, ben benieuwd of er devs zijn die met overheden werken die hier wat meer duidelijkheid over kunnen geven.

Testdata mag geen persoonsgegevens bevatten volgens de AV, tenzij noodzakelijk. Ik heb zelf bij een IT-leverancier gewerkt die ook actief was in de (semi)-publieke sector en die had een anomiseringstool die je testdata kan mengen met random gegevens waardoor het haast onmogelijk was te achterhalen. Dit zou altijd en ten nimmer moeten gebeuren, als je wel met een volle database wilt testen.

[Orangelights23]

Dit is meestal het gevolg van de discussie tussen de IT- en Security baas, waarbij in dit geval de IT baas gewonnen heeft.

[robbvdb]

Ik begrijp dan weer niet waarom cybercharlatan zelfverklaard cybersecurity-expert, superhacker en cyberspion Rian van Rijbroek het niet voorspeld had en oplost

Oh, ik snap het .... https://www.google.com/ur...Vaw0DF7JtuppzqQ0pHySuncVG , ze bleek toch niet capabel en Sanderink zit er ook niet meer.

Nou, sterkte Centric met de situatie zonder deze expert.

[Reactie gewijzigd door robbvdb op 25 januari 2025 22:28]

[Edward Dortland]

Dat klinkt eenvoudig, maar dat is het niet. Ja, je hebt gelijk: het is 2025, en er is inmiddels veel bewustzijn. De AVG verplicht het ook al jaren. Maar dan de praktijk: een gemiddelde enterprise heeft honderden applicaties met databases die variëren van enkele tientallen tot duizenden tabellen.

Welke tabellen bevatten gevoelige informatie? Weet jij het? De meeste leveranciers kunnen dit niet eens uitlijsten.

Stel dat je die lijst hebt, dan is er nog steeds veel onderzoek nodig. Gaan relaties tussen tabellen stuk als we anonimiseren? Als we een geboortedatum aanpassen, moeten we dan rekening houden met de leeftijd? (Is het bijvoorbeeld voor testen van belang dat een kind een kind blijft en niet volwassen wordt, of dat iemand die tussen de 30 en 40 jaar oud was, niet ineens 29 is geworden?) Als we adressen aanpassen, moeten we er dan rekening mee houden dat ze in dezelfde straat of hetzelfde postcodegebied blijven? (Bijvoorbeeld: is het van belang dat de afstanden van routes gelijk blijven?)

Moet eenzelfde persoon na iedere anonimisatieslag steeds dezelfde naam behouden, zodat hij/zij makkelijk teruggevonden kan worden?
Als je een 30 TB EPD hebt, waar anonimiseer je dan? (Storage.) Is er onvoldoende storage, hoe maken we dan een subset? Welke relaties tussen tabellen moeten behouden blijven?
Als je ketentesten moet doen met externe partijen, hoe linken die dan de geanonimiseerde entiteiten aan de records in hun eigen database?

Heel veel bedrijven zouden veel meer willen anonimiseren dan ze nu doen, maar het kost ontzettend veel tijd om dit uit te zoeken. En dan ook nog te onderhouden, want bij upgrades verandert vaak het datamodel.

De praktijk is dus een veelvoud complexer dan je denkt.

Wat erg zou helpen, is als softwareleveranciers zelf een steentje bijdragen. Het zou prachtig zijn als er een beweging start waarbij iedere softwareleverancier standaard functionaliteit inbouwt waarmee je een geanonimiseerde set/subset kunt maken voor acceptatietesten. Zij weten immers als geen ander het beste hoe hun datamodel in elkaar zit en wat de beste manier van anonimiseren is om functionaliteit tijdens testen te kunnen behouden.

Je houdt dan enkel nog de integratieproblemen met de externe wereld. Voor persoonsgegevens zouden we enorm geholpen zijn als de overheid een set testpersonen aanmaakt in de basisadministratie, compleet met BSN’s, die iedere softwareleverancier of IT’er vrij kan gebruiken. Heerlijk lijkt me dat, als dit goed wordt geadopteerd.

[kodak]

Aangezien ontwikkelsystemen en testsystemen al sinds de vorige eeuw vaak slechte(re) beveiliging hebben, zoals gebrekkige eisen, gebrekkig toezicht, gebrekkige handhaving en het daarmee ook te vaak niet serieus nemen van wettelijke grenzen, is dit ernstiger dan 'niet chique'. En zolang een bedrijf niet kan aantonen wel even goede beveiliging toe te hebben gepast als bij gebruik waar die (persoonlijke) gegevens voor verstrekt zijn is dit eerder nog ernstiger dan wanneer het een lek via een productieomgeving met behoorlijke beveiliging zou zijn.

[ZeRoC00L]

Deze link bedoel je denk ik:

https://centric.eu/nl/nieuws/kwetsbaarheid-in-testserver/

[berryflash]

Klopt! Bedankt, gelijk mijn post bijgewerkt

[mr.DJ95]

Waar is Rian als je haar nodig hebt? Oh wacht....

Alle gekheid op een stokje, Centric is binnen nederland wel 1 van de laatste bedrijven die ik graag gehackt zie worden gezien de afhankelijkheid van Centric binnen vele lokale maar ook regionale overheden.

[Steenvoorde]

Die heeft een Rian-te bonus van sugar daddy Sanderink gehad en die is al met pensioen.

Verder heb je gelijk, dit is een van de bedrijven waarvan je hoopt dat ze buiten schot blijven. En het feit dat het toch mis is gegaan geeft mij geen goede hoop over de rest van de essentiële infra in dit land. Binnen het bedrijf waar ik werk hebben we de afgelopen 10 jaar ook een gigantische inhaalslag gemaakt wat betreft security, en da's geen overbodige luxe. Vooral als je ziet hoe snel mensen, zelfs IT'ers, op phishing links klikken.

[Alfa1970]

Hopen dat een bedrijf buiten schot blijft is utopie.
Je moet er gewoon voor zorgen dat niets dat belangrijk is (lees "geheim") online is te benaderen.
Het is te eenvoudig om op afstand in te breken op systemen die online beschikbaar zijn.
Het is ronduit stupide dat, ondanks de legio voorbeelden in het verleden, dit anno 2025 nog steeds niet is doorgedrongen tot bedrijven waaronder zoals nu blijkt Centric.

Je kan wel zeggen dat er heel veel kan met firewalls, antivirus en andere technieken, maar keer op keer blijkt dat al die technieken zelf grote gebreken vertonen en soms ook de bron zijn van de "inbraak".
Daar komt bij dat (, om praktische en logische redenen), bedrijven langzaam zijn met het implementeren van patches, waardoor de periode dat reeds bekende veiligheid problemen kunnen worden misbruikt relatief lang is.

[Triblade_8472]

Nu draait nog veel lokaal. Wacht maar tot ze over een paar jaar alles in de Centric-SaaS hebben draaien. Dan heeft dat ene bedrijf bijna letterlijk alles van iedereen in Nederland.

Van je naam, contactgegevens, belastinggegevens, evnt schulden of inhouding van salaris enz.

[EricBruggema]

Ik begrijp dat Centric dus niet betaald hebben! en dat is ook wel weer een statement.

[kdekker]

Van een club die al slecht functioneerde, is het niet heel raar dat betalen ook niet lekker liep, lijkt me. Op z'n hoogst pech voor - de verwerpelijke praktijken - van een ransomware bende. Hoe dan ook is dat laatste ook al crimineel (wat verder niets zegt over de verplichtingen die je als bedrijf hebt om security op orde te hebben).

Al is security-op-orde en klik maar raak medewerkers een uitdaging. Bepaalde groepen medewerkers in een afgeschermd netwerk zetten ? (geintje, iedereen kan op een foute URL of bijlage klikken).

[Scriptkid]

de betaling is onderschept door een fake mail van een andere hacker groep ,

[Marve79]

Een software/IT bedrijf wat slachtoffer wordt van ransomware is natuurlijk extra pijnlijk. En Centric stond er al niet echt goed op met dat gedoe rondom Sanderink.

[William_H]

Een beetje IT-er wil niet meer in de buurt komen van dit bedrijf...

[bluebug]

Helaas hebben ze software voor een niche in overheidsland en, minstens zo belangrijk, zijn ambtenaren veelal niet heel makkelijk mee te krijgen met veranderingen. Zie dan maar eens een ander pakket neer te zetten...

[Frame164]

Ik denk dat er op dit forum genoeg mensen zitten die bij Centric werken en nu waarschijnlijk heel stil zijn.

[Bleet]

Zie dat we hier nu aan Centric refereren, maar het gaat om 'specifieke informatie van een enkele klant'. Oftewel, deze afnemer heeft tegen beter weten in private data in een testomgeving gegooid?

[Reactie gewijzigd door Bleet op 24 januari 2025 15:14]

[wica]

Nog geen idee, is ongeveer 10Gb aan zip files. Kan van alles tussen zitten.

[Z80]

Maar dan is de vraag, wie heeft de Cleo software geïnstalleerd. En mogelijk niet geüpdatet.
Als er gebruik gemaakt is van CVE-2024-55956 in de Cleo software. Dan is het lek al van 10-12-2024.

Even voor de duidelijkheid.
Cleo software is een filetransfer pakket om data veilig te versturen over een niet veilige verbinding.

[Reactie gewijzigd door Z80 op 24 januari 2025 17:03]

[Tbone101]

De website ransomware.live biedt ook een uitstekend overzicht van de activiteiten van de belangrijkste hackergroepen en is zeker een bezoek waard.

Naast informatie over de hack bij Centric, inclusief enkele details, vind je er ook YARA-regels en andere handige tools en bronnen rondom dit onderwerp. https://www.ransomware.live/search/centric

[wica]

Had het hele onion adres verwijderd, ipv enkel stukje.
Het complete adres was, daarmee letterlijk in 2 sec te vinden.
Tekst uit plaatje kopiëren en googlen.

[TijsZonderH]

Ik twijfelde of ik het überhaupt moest doen, maar de website van Clop (een van de grootste ransomwarebendes anno nu) is op zichzelf door iedereen wel te vinden dus dat is al een beetje een wassen neus.

[wica]

Ik zou het niet doen, daar dat ik meestal een admin edit krijg, als ik een directe link plaat of een indirecte via google search.
Zal je reactie onthouden, als ik weer eens een admin-edit krijg

[Jorah_Newstone]

Wassen neus of niet, als een normale gebruiker het doet krijgt die een tik op de vingers en admin edit
Lead by example.

[muppet99]

Ik zou alleen verwachten dat een testsysteem niet aan het publieke net hangt. Acceptatie kan ik nog eventueel begrijpen. En anders zijn er wel scenario’s te maken waarin je nog steeds geen publieke toegang hoeft te verschaffen. Daarnaast zien ik dat de gebruikte cve al even bekend is. Ik zou dan ook mijn vraagtekens zetten bij de leverancier van de software.

[HakanX]

Inmiddels zijn mijn gegevens al zo vaak uitgelekt, dat alles van mij al op straat ligt en datalekken niet meer interessant zijn. Ik word wel minimaal één keer per week (deze week al op twee) gebeld door een scambedrijf die al mijn gegevens hebben. Ik praat als ik niks te doen heb een beetje om erachter te komen wat ze allemaal over mij weten en waar de data eventueel vandaan komt. Daarnaast neem ik hun tijd in zodat ze minder inkomsten per lead hebben.

Het meest heb ik eentje 45 minuten aan de lijn gehouden door te zeggen dat ik ze verbind met de juiste afdeling en naast de radio te leggen als wachtmuziek. Af en toe de telefoon oppakken en vragen of ze nog even hebben.

[Frame164]

Alles openbaar maken maakt data wel in 1 keer waardeloos. Er is best wel wat voor zo'n aanpak te zeggen. Maar dan moet ook alles openbaar. Als bijvoorbeeld een verzekeraar iemand weigert op basis van openbare gezondheidsgegevens terwijl er een acceptatieplicht is dan moet die verzekeraar ook aangeven hoe ze tot een beslissing zijn gekomen. En dan hebben ze een probleem.

[DrWaltman]

Waarom zou alle informatie dan waardeloos worden? Dan heeft juist iedereen jouw informatie en kan je niemand meer vertrouwen. Daarnaast staat in je dossier precies omschreven wat je sterke en zwakke punten zijn, inclusief medische kwetsbaarheden. Denk je dat niemand hier misbruik van zal van maken?

Dat doen verzekeringen al zoals je zegt, laat staan waartoe criminelen in staat zullen zijn.

[djwice]

Dan krijgen ze naast die data ook mooi een voice clone van je

[HakanX]

Ja daar heb ik over nagedacht 😂 bij telefonisch contact met bedrijven maakt je stem sowieso niet uit, daar hebben ze geen check op. Ik bel zelf vaak namens familie met hun gegevens. Verder kan ik mij weinig bedenken hoe ze icm mijn stem mij grote schade aan kunnen doen zonder dat ik de kans heb om aan de bel te trekken. Mocht er toch iets zijn dan is het een zaak voor de rechter en dat lijkt me wel een interessante casus waarvoor ik mij wil opofferen.

[djwice]

verwijderd (hoeft niet publiek)

[Reactie gewijzigd door djwice op 24 januari 2025 20:21]

[habbekrats]

Volgende keer als ik gegevens kwijt ben stuur ik even een berichtje naar een ransomware club of ik even een backup terug kan krijgen.

[awh84]

Via CCinfo, zijn ook veel Belgische bedrijven zo te zien:
https://www.ccinfo.nl/menu-nieuws-trends/screenshot-darkweb