Gegevens van 19.000 Groningse aardbevingsgedupeerden gestolen bij datalek NAM

Gaswinningsmaatschappij NAM is getroffen door een datalek, waarbij criminelen gegevens van 19.000 aardbevingsgedupeerden hebben gestolen. Bij de hack werd al langer kwetsbare software gebruikt van het bedrijf Accellion.

Bij de NAM werd gebruik gemaakt van filesharingsoftware van het bedrijf Accellion. Bij de hack zijn gegevens gestolen van 19.000 Groningers die wachten op schadeafhandeling vanwege aardbevingsschade. Er zijn in elk geval namen en adressen gestolen en van zeker honderd mensen meer gegevens.

De NAM gebruikte op verzoek van Instituut Mijnbouwschade Groningen software van Accellion voor het beveiligd versturen van grote databestanden. Het gaat hier naar alle waarschijnlijkheid om filesharingsdienst FTA, dat al meerdere keren misbruikt werd bij het stelen van gegevens, onder andere in Australië en Nieuw-Zeeland. Filetransfersoftware van Accellion wordt gebruikt door verschillende banken, overheden en zorginstellingen. De kwetsbaarheid in FTA die werd misbruikt is door Accellion gedicht, schrijft het bedrijf in een concluderend artikel op haar website. Het bedrijf roept al sinds begin januari op om de software te updaten.

Op de website schrijft de NAM dat er geen gegevens gestolen zijn uit dossiers die op hun eigen netwerk staan en volgens de NAM zijn de criminelen niet in de systemen van de NAM geweest. Enkel in de filesharingsdienst. De NAM heeft het lek gemeld bij de Autoriteit Persoonsgegevens.

Bij het lek werden persoons- en adresgegevens van alle huiseigenaren gestolen die tussen 2014 en 1 juli 2020 een aanvraag indienden voor de Regeling Waardedaling. Dat is de schaderegeling voor gedupeerden van aardbevingsschade door gaswinning van de NAM. Ook gegevens van alle huiseigenaren die aangesloten zijn bij de Stichting WAG en een rechtelijke procedure hebben lopen tegen de NAM, zijn gestolen. Daarbij gaat het om adressen en woonplaatsen en niet om namen. Ook zijn gegevens buitgemaakt van alle huiseigenaren die individuele rechtszaken tegen de NAM hebben lopen.

De NAM schrijft daarnaast dat er ook mensen zijn die persoonlijk bericht hebben gehad, omdat er van hen mogelijk e-mailadressen, telefoonnummers of bankgegevens gelekt zijn. RTV Noord schrijft dat er van ruim honderd mensen meer informatie is gestolen dan alleen namen en adresgegevens.

Update 11 maart 13.15 uur: in een eerste versie van dit artikel stond dat de kwetsbaarheid die misbruikt is zat in Kiteworks van Accellion. Dat klopte niet. Het gaat op filesharingsdienst FTA. Dit is aangepast hierboven met links naar Accellion's website.

Reacties (107)

[Sunthon]

Ik ben aangesloten bij de Stichting WAG (die de waardedaling-compensatie in gang heeft gezet en die momenteel bij de Rechtbank een proces tegen de NAM voert over de hoogte (in %) van de waardedaling (de compensatie van het Instituut Mijnbouwschade Groningen (IMG) is een lachtertje!!). Mijn gegevens zijn dus blijkbaar ook gelekt.

Via andere media verneem ik, dat gedupeerden op de hoogte zijn gesteld. Dat klopt dus niet, want ik heb geen mail, geen brief en ook geen telefoontje gehad van de NAM. Via de media moet ik vernemen, dat mijn NAW-gegevens en mogelijk e-mail en telefoonnummer zijn gelekt na een hack. Dat is toch wel schandelig als je op die manier moet vernemen dat je gegevens op straat liggen. Wederom een nieuw hoofdstuk in hoe de NAM (en daardoor ook direct en indirect de Nederlandse overheid) omgaat met "Groningen".

Wat natuurlijk in z'n algemeenheid droevig is, is dat een onderneming als de NAM, die toch niet echt zonder geld zit, niet de moeite neemt om z'n software up-to-date te houden. Het gaat om privacy-gevoelige data, dus in deze (internet)tijd weet je dan dat je daar heel goed op moet letten.

[Reactie gewijzigd door Sunthon op 24 juli 2024 18:39]

[Tadango]

NAM heeft alleen zwaar gedupeerde personen op de hoogte gesteld, niet alle 19.000. Deze lek zit niet in een NAM / Shell systeem zelf maar in een systeem wat door hun gebruikt is voor het uitwisselen van bestanden met IMG.

Dit is dus niet de schuld van NAM / Shell wat juist WEL maatregelen neemt om het uitwisselen van gegevens te beveiligen. Diensten zoals dropbox edg zijn dan ook geblokkeerd. Het is droevig dat zo'n beveiligde dienst dan juist een lek heeft.

[GoBieN-Be]

Dit gaat volgens mij over een on-premise dienst. Aangezien de firma's zelf de software moeten updaten.
De vraag is dan wie beheer de on-premise software, NAM of IMG?

[Tadango]

NAM vermoed ik gezien de communicatie vanuit hun komt. Wel gek gezien de update policy vrij streng is........

[tweaker2010]

Het ligt er volgens mij aan welk type persoonsgegevens er zijn gelekt. Adressen (zonder namen) zijn op zich geen spannende data, dat kun je ook vinden in een willekeurige telefoongids.

Logisch dat vanuit de NAM met name de focus ligt op het informeren van personen met de bijzondere persoonsgegevens, ben het wel met je eens dat overige gedupeerden ook netjes geinformeerd hadden moeten worden.

https://autoriteitpersoonsgegevens.nl/nl/over-privacy/persoonsgegevens/wat-zijn-persoonsgegevens

[dabronsg]

Het is misschien niet de schuld van de NAM, maar ze zijn wel verantwoordelijk.

[Tsjipmanz]

Dit artikel op wired geeft wel een stukje meer duiding en laat zien dat Accellion ook niet helemaal vrij te pleiten is in deze:


“Since becoming aware of these attacks, our team has been working around the clock to develop and release patches that resolve each identified FTA vulnerability, and support our customers affected by this incident,” Accellion CEO Jonathan Yaron said in a statement last Monday.

Incident responders say, though, that Accellion was slow to raise the alarm about the potential risk to FTA users.

“The Accellion zero days were particularly damaging because actors were mass-exploiting this vulnerability quickly, and the severity of this wasn't being communicated from Accellion,” says David Kennedy, CEO of the corporate incident response consultancy TrustedSec. “We had a number of customers that were reaching out to Accellion to understand the impact without any response. There was a large time window for active exploitation.”

[BryanD]

Zelfde hier. Ook via WAG aangesloten en momenteel in het proces voor sloop/nieuwbouw, ook geen enkel bericht. Heb het ook via de media moeten vernemen. "Gelukkig" gaat het "alleen maar" om adresgegevens, maar dan nog, het zijn wel gewoon je persoonsgegevens. Als het inderdaad door nalatigheid gaat mbt security updates is dat wel echt slecht. Hopelijk krijgen wij ook nog een signaaltje of officiële melding oid.

[SirRosencrantz]

Ik kreeg ook de indruk dat de NAM alleen contact heeft opgenomen met gedupeerden van wie meer gegevens gelekt zijn dan naw-gegevens. Dat staat namelijk in dat persbericht. Dus dat heb ik dan ook zo ongeveer opgeschreven. De overige 18.900 moeten het blijkbaar doen met een nieuwsberichtje op de site van de NAM?

[Sunthon]

Eerder vandaag stond er op Nu.nl of RTV Noord dat de gedupeerden in kennis waren gesteld (hoe, dat stond er niet bij) en dat 100 mensen telefonisch waren benaderd, omdat van hen meer gegevens waren gelekt.

Hoe dan ook, het was netter geweest als de NAM de Stichting WAG op de hoogte had gesteld (immers, "alle deelnemers van de St. WAG zijn getroffen") en dan had de Stichting WAG mij wel via email in kennis gesteld. Nu wordt er een persbericht de wereld in geslingerd en moeten wij (als deelnemer aan de Stichting) het via de media vernemen. Dat het chiquer gekund en dat was niet eens zoveel moeite geweest. Maar misschien zijn de verhoudingen NAM/ St. WAG dusdanig vertroebeld, dat ze daar niet uit kwamen..

[Lisadr]

Bedrijven als NAM willen bijna uitsluitend mensen uit hun eigen branche en krijgen tunnelvisie. Ze investeren ook veel te weinig in het beveiligen van persoonsgegevens. Kosten vinden ze niet opwegen ten opzichte van risico's. Het is de moeite waard. NAM = Shell + ExxonMobil en het is niet zo dat hun inkomsten afhankelijk zijn van merk epuratie.

[fsfikke]

Als ze inderdaad in die tunnelvisie waren gebleven hadden ze er waarschijnlijk niet voor gekozen om op verzoek van het Instituut Mijnbouwschade Groningen non-standaard software gebruiken ipv hun eigen file-sharing dienst

Waar het artikel niet duidelijk over is, is of in de 2019 hack in Australië en Nieuw-Zeeland die inmiddels gedicht is dezelfde kwetsbaarheid is gebruikt die nu gebruikt is. Dat suggereert het artikel wel met de opmerking 'hadden ze maar moeten updaten', maar ik vraag me af op basis waarvan @SirRosencrantz die conclusie trekt? Dat ze twee jaar geleden een lek gedicht hebben wil natuurlijk niet zeggen dat de software daarna 100% veilig is, was het maar zo makkelijk

[Reactie gewijzigd door fsfikke op 24 juli 2024 18:39]

[SirRosencrantz]

De hacks in Australië en Nieuw-Zeeland waren niet in 2019, maar vorige maand. Ik trek de conclusie dat dezelfde software wordt gebruikt, waarvan in het eerdere artikel te lezen is dat Accellion oproept de software te updaten.

[fsfikke]

Ok, het zou dus interessant zijn of Accellion in dit geval met een vergelijkbaar statement komt dat het hier gebruikte lek al eerder bekend en gedicht was.

[biteMark]

Via andere media verneem ik, dat gedupeerden op de hoogte zijn gesteld. Dat klopt dus niet, want ik heb geen mail, geen brief en ook geen telefoontje gehad van de NAM.

Ik zou het even afwachten. Ja, natuurlijk is het heel vervelend om het nieuws op deze manier te horen maar ik denk dat dat meer een gevolg is van de procedures dan van slechte wil. Ik ben geen kenner maar ik kan me goed voorstellen dat bedrijven verplicht zijn om een bericht naar de media te doen na het melden van een datalek bij de Autoriteit Persoonsgegevens. Waarschijnlijk wordt je met en "ouderwetse" papieren brief officieel op de hoogte gebracht van het datalek maar dat de (internet-)media je sneller bereiken dan een brief moge voor zich spreken. Desondanks is het natuurlijk heel vervelend en moeilijk verteerbaar, zéker als je al op slechte voet staat met de NAM.

Wat natuurlijk in z'n algemeenheid droevig is, is dat een onderneming als de NAM, die toch niet echt zonder geld zit, niet de moeite neemt om z'n software up-to-date te houden.

Klopt. Leer mij (grote) bedrijven in het algemeen kennen. Software updates zijn redelijk taboe bij systeembeheerders want die zijn alleen maar bang dat die de boel in de war schoppen. Daar komt bij dat zulke updates niet zomaar geïnstalleerd gaan worden door de eerste de beste sysadmin die toevallig die update voorbij ziet komen, daar zijn allerlei policies voor en er zijn waarschijnlijk een aantal mensen die daar iets van moeten vinden en er akkoord op moeten geven. Je ziet wel vaker dat zulke bedrijven enorm achterlopen met hun software vanwege de risico's en de (mogelijke) impact.

Geen excuses natuurlijk, ik speel even de advocaat van de duivel maar misschien wel even goed om een ander perspectief te hebben.

[Verwijderd]

Dergelijke lekken zullen wel blijven bestaan. Waar mensen bij betrokken zijn, gaat het altijd wel een keer mensen.

Waar volgens mij juist aan gewerkt moet worden, is dat dergelijke data compleet nutteloos voor de crimineel is. Ja, leuk dat je mijn email, telefoon, adres en evt creditcard hebt, maar hoe kunnen we ervoor zorgen dat ze daar niks mee kunnen? Meeste onbekende mail gaat al automatisch naar spam, phishing filters moeten nog beter moeten worden. En creditcard zou met een betere 2fa ook veilig moeten zijn.

Ook het Nederlandse systeem met BSN zou anders moeten, het moet niet mogelijk zijn dat je met enkel een nummertje zoveel kan.

[mjtdevries]

En hoeveel kan je dan eigenlijk met dat nummertje? Het word wel hard geroepen, maar is dat niet gebaseerd op zwaar verouderde situaties uit het verleden?
Bij de AP is de gevoeligheid van een BSN 2 jaar geleden verlaagd.

[Owen1307]

Hoort het steeds vaker dat persoonsgegevens gejat zijn bij grote bedrijven...

[rbr320]

Inderdaad, als je het nieuws van Tweakers er op na leest zie je dat het bijne elke week wel een keer raak is, soms zelfs meerdere keren. De oorzaak is wat mij betreft simpel aan te wijzen: bij veel bedrijven schort het aan goed update beleid, waardoor software soms vele versies achterloopt met vele bekende kwetsbaarheden daarin. Ik constateer nog te vaak dat software neer wordt gezet en nooit meer naar wordt omgekeken, met het idee "zolang het werkt, niet aankomen". Beheerders zijn in mijn ogen veel te bang dat er bij een update iets om valt. Op die manier bouw je echter een enorme technische achterstand op waardoor het steeds moeilijker wordt om toch je updates uit te voeren, totdat er uiteindelijk dan maar een duur migratietraject wordt gestart naar iets nieuws, waarna hetzelfde gedrag zich gewoon herhaald.

[Owen1307]

Ik zie ook vaak dat gebruikers niet goed geïnformeerd zijn. Een week of twee geleden hebben ze op het bedrijf waar ik werk iemand ingehuurd om mensen te bellen en dan te vragen naar inloggegevens. Hij gebruikte als smoes een verzonnen naam en dat hij nieuw was op de afdeling en door een storing inloggegevens nodig had, zeker 4 mensen hebben deze gegeven op een dag.

Ik werk dan bij een gemeente en kan je voorstellen als dit een serieuze aanval was dat er ook een mega datalek had kunnen zijn, niet normaal dat mensen alsnog hun inloggegevens geven.

[PhilipsFan]

Aan de andere kant, er zijn ook veel instanties waarbij gewoon geen goede procedures zijn voor ondersteuning en probleemoplossing. Waar dus mensen van de helpdesk moeten vragen om credentials van gebruikers. Het helpt natuurlijk niet dat in de ene helft van de maatschappij hard wordt geroepen dat je nooit je inloggegevens moet afstaan, terwijl dat in de andere helft een noodzakelijk kwaad is.

Je kunt je denk ik beter afvragen of een wachtwoord nog wel voldoende beveiliging biedt of dat instanties moeten overstappen op iets beters.

[Owen1307]

Hier is de algemene regel dat we geen wachtwoorden mogen weten, als we echt inloggegevens nodig hebben resetten we het wachtwoord wel in het AD (bij noodgevallen).

Dit is al maanden zo en de gebruikers die gegevens hebben gegeven werkten allemaal al minimaal 6 maanden op de gemeente...

Qua wachtwoordenbeleid zijn er ook GPO's ingesteld voor complexiteit, wanneer je wachtwoorden moet veranderen en 2 factor authenticatie... als dit nou eens een standaard ging worden zou het denk ik al een heel stuk schelen qua inbraken.

Maar goed, het ontneemt niet dat het ook steeds vaker gebeurd dat hackers binnen komen door te bruteforcen van oude servers, hier gebruiken we nog tapes als back-up... like WHAT!!??

[mjtdevries]

Er zijn nog steeds valide redenen om tapes als back-up of archivering te gebruiken.
Dus het hoeft niet perse te betekenen dat je IT verouderd is.

[Reactie gewijzigd door mjtdevries op 24 juli 2024 18:39]

[Owen1307]

Het systeem gebruiken ze nu al 12 jaar, lijkt me wel tijd voor een eigen database of iets in die trend.

[mjtdevries]

En wat is de relatie daarvan met de keus wat voor soort backup je gebruikt?

[Owen1307]

Ik noem een voorbeeld, geen directe oplossing... Naar mijn mening zouden ze tapes al weg moeten hebben uit grootte bedrijven, gemeentes etc etc.
Er zijn nu veel modernere manieren om te back-uppen, maar dit is een topic voor een andere keer. Het ging nu om heel wat anders.

[mjtdevries]

Het ging er om dat je doet alsof ze verouderd bezig zijn omdat ze nog tapes gebruiken. Maar tapes bieden mogelijkheden die geen enkel ander backup systeem biedt. Dus je doet aannames die nergens op gebaseerd zijn.

[Owen1307]

Zoals ik al zei gaat dit nu off-topic. Als je wilt discussiëren hoe goed tapes zijn zoek dan een topic op.

[The Third Man]

Tapes zijn doodnormaal in enterprise omgevingen, is niks achterhaalds aan. LTO tapes van 30 TB kosten een euro of 100 ongeveer, zoek daar maar eens een harde schijf (laat staan een SSD) voor die dat kan opslaan. Sommige bedrijven hanteren zelfs een rolling backup window van een dagelijkse tape voor jarenlang (dus meer dan duizend tapes). Off site bewaren of verplaatsen? Kratje met tapes verplaatsen, niks TB's door de cloud pompen met prachtige bandbreedtekosten achteraf. Tape van 10 jaar terug gebruiken? Geen probleem, tape drive leest t gewoon alsof hij gloednieuw is. Een kind kan een tape in een lezer stoppen (er bestaan zelfs automatische robots die ze wisselen).

Er schaalt simpelweg niks zo goed als tape als het puur gaat om lineaire 'domme' dataopslag.

[Reactie gewijzigd door The Third Man op 24 juli 2024 18:39]

[ikt]

Is dat dan een probleem van de gebruikers/werknemers, of hoe er over het algemeen wordt omgegaan met IT in het bedrijf?

Is er een bereikbaar IT telefoonnummer voor dit soort problemen, of moeten gebruikers dat zelf maar uitzoeken of op een andere minder toegankelijke manier fixen?

Als de standaardoplossing "loop maar naar Jantje van de IT, als je geluk hebt is die aanwezig" is, dan is het niet vreemd dat mensen minder veilige oplossingen gaan zoeken.

[Owen1307]

Er word samen gewerkt met twee andere gemeentes met dezelfde telefoonnummer, volgens mij zijn er 8 personen beschikbaar.
Wat ik weet is het altijd goed gegaan qua bereikbaarheid omdat ik nooit klachten gehoord heb.

Weet wel zo dat mensen niet altijd zoiets melden want van de 4 heeft er maar 1 gebeld dat degene een onderbuikgevoel had over het belletje en de ander had een melding ingeschoten, deze zijn correct en snel afgehandeld. De andere twee hebben geen kwaad gezien en hebben niks gemeld, natuurlijk waren er wel meerdere mensen die hebben aangegeven dat er word rondgebeld, maar de meeste mensen werken thuis dus verspreid het nieuws niet snel dat er een scammer/hacker aan het bellen is en niet de servicedesk.

Wat ik dus als conclusie stel is dat gebruikers niet goed geïnformeerd zijn over deze dingen, het gaat te makkelijk nog helaas en niet alleen op de gemeente.

[Kenhas]

Er wordt hier binnen de gemeente al meer dan een jaar opleiding gegeven over hoe om te gaan met mail en hoe verdachte zaken op te merken. Eigenlijk behoorlijk intensief.
Er wordt 2x per maand een testmail verstuurd en nog altijd loopt meer dan 50% in de val.

Het zal zeker niet altijd het geval zijn maar in vele gevallen zal het probleem toch echt bij de gebruikers liggen. Gewoon geen interesse in zo'n zaken. Komt er een mail toe, klikken maar.

Maar ook is IT soms niet helemaal heilig. Hebben bij een redelijk groot bedrijf een vergelijkbare test gedaan als @Owen1307 van spreekt. Iemand belt naar de IT dienst met de boodschap dat hij, na enkele weken afwezigheid, zijn paswoord niet meer weet. Het paswoord werd gereset en telefonisch doorgegeven (want de persoon kon natuurlijk zijn mail niet meer lezen omdat ie niet kon inloggen). Daar is er toch eens een duchtig woordje gesproken met de IT dienst

[Indentical]

Herkenbaar, goed, de mensen die ik het zou vragen heb ik dan ook daadwerkelijk gezien en gesproken op de werkvloer als ik eens fysiek op de afdeling moet zijn.
In de meeste gevallen, als dat nodig is, kunnen wij het wachtwoord eenvoudig aanpassen zodat we het e.e.a. kunnen testen, wel vragen wij in die gevallen om toestemming met de melding deze daarna dan ook weer te wijzigen. Vaak hoeven wij geen inlog gegevens voor een storing. Wij bellen de gebruiker op en vragen aan de gebruiker of ze in kunnen loggen en verifiëren of het is opgelost.

[PhilipsFan]

Maar dat gedrag is wel begrijpelijk. Er valt namelijk best wel vaak iets om bij een update. Omdat een leverancier weer een of andere fancy feature heeft toegevoegd die achteraf toch niet bij iedereen goed blijkt te werken.

Fabrikanten zouden eigenlijk versies moeten uitbrengen die gewoon niet veranderen, maar alleen beveiligingsupdates krijgen. Bij sommigen gebeurt dat gelukkig al.

[rbr320]

Voor situaties waarin er iets om valt tijdens een update heb je een rollback scenario. Ik wil ook niet zeggen dat het makkelijk is om al je software helemaal 100% up-to-date te houden, alleen dat ik helaas met veel bedrijven te maken (heb gehad) waar er niet eens een poging gedaan wordt om software te updaten. Dat is gewoon nalatig met alle risico's van dien, getuige de vele meldingen van datalekken de laatste tijd.

En inderdaad, veel bedrijven bieden gelukkig al LTS versies van hun software waarin alleen security patches gedaan worden. Echter, die raken ook een keer end-of-life en daar moet een afnemer zich ook op voorbereiden.

[Reactie gewijzigd door rbr320 op 24 juli 2024 18:39]

[mjtdevries]

Voor situaties waarin er iets om valt tijdens een update heb je een rollback scenario

De simplistische tweakers manier van denken weer. "Voor de simpele applicaties waar ik ervaring mee heb is een rollback scenario simpel, dus dat is altijd het geval".

De hoeveelheid situaties die ik tegen ben gekomen waarin een rollback niet mogelijk was, of gigantisch kostbaar en tijdrovend zijn niet te tellen.

Ander probleem is dat een representatieve testomgeving bouwen ook een kostbare zaak is. Iets makkelijker tegenwoordig met virtual machines, maar als je productie servers geen virtual machines zijn heb je daar al meteen een flink risico.

Verder is de gemiddelde IT-er erg slecht in testen. Verder dan het "happy-path" komen ze niet.

[rbr320]

[...]

De simplistische tweakers manier van denken weer. "Voor de simpele applicaties waar ik ervaring mee heb is een rollback scenario simpel, dus dat is altijd het geval".

Fijn dat je 1 regel uit mijn reactie quote om je punt te maken, terwijl ik in de regel er na direct al laat weten dat ik helemaal niet wil zeggen dat het makkelijk is. Het is alleen wel de tijd en moeite om te doen waard en dat is iets waar jij, als domein expert, je leidinggevenden van moet zien te overtuigen.

De hoeveelheid situaties die ik tegen ben gekomen waarin een rollback niet mogelijk was, of gigantisch kostbaar en tijdrovend zijn niet te tellen.

Dan wil ik stellen dat er ergens anders iets fundamenteel verkeerd zit en zal je dus moeten investeren in dat verbeteren. Een applicatie of omgeving die kritiek is, maar waar bij het doen van updates een reële kans is dat het stuk gaat, en die in zo'n geval vrijwel niet meer in de oude werkende staat te krijgen is, is een veel te groot risico voor het bedrijf dat er van afhankelijk is.

Ander probleem is dat een representatieve testomgeving bouwen ook een kostbare zaak is. Iets makkelijker tegenwoordig met virtual machines, maar als je productie servers geen virtual machines zijn heb je daar al meteen een flink risico.

Ik weet er alles van want ik ben daar momenteel mee bezig.

Verder is de gemiddelde IT-er erg slecht in testen. Verder dan het "happy-path" komen ze niet.

Dat is helaas waar, maar toch echt een vaardigheid die we onszelf meester zullen moeten maken.

[mjtdevries]

Dat is helaas waar, maar toch echt een vaardigheid die we onszelf meester zullen moeten maken.

Het is deels te leren en je kunt bv kijken naar ISTQB.
Maar uiteindelijk is het ook iets dat in iemand moet zitten. Het leuk vinden om te kijken op welke manier je iets stuk kunt maken door verkeerde input te geven.

Wat ook goed helpt, is wanneer degene die shit veroorzaakt door niet goed te testen ook zelf de gevolgen ondervind. Dus een lading klagende gebruikers aan zijn/haar buro, of een lading incidenten in zijn/haar support queue.
Aan de andere kant is dat ook waarom ze aarzelend zijn om updates door te voeren.
Dus je moet die mensen zien te stimuleren dat ze issues zien als een mogelijkheid om tests te verbeteren zodat het de volgende manier voorkomen kan worden, ipv een reden om zo'n update zo min mogelijk te doen.

Want hoeveel je ook test, er zullen altijd onverwachte dingen gebeuren. En je kunt nooit zoveel testen dat je alles kunt uitsluiten.
Je kunt wel zodanig testen dat niemand je verwijten maakt dat er niet genoeg getest is. En dan zal die aarzeling om updates uit te voeren ook verdwijnen.

[rbr320]

Zo te zienlezen zijn we het eens.

[Reactie gewijzigd door rbr320 op 24 juli 2024 18:39]

[Blokker_1999]

Wat is veel? Zelfs als het maar om 1 of 2% gaat spreek je in absolute aantallen alsnog over enorm veel bedrijven en organisaties. Maar procentueel is het enorm weinig. De meeste bedrijven en organisaties hebben hun update beleid gelukkig wel in orde.

Daarnaast zijn er nog veel meer lekken die ontstaan door menselijke fouten. Zoals gisteren nog, waarbij de anonimisering niet goed werd uitgevoerd. Of een bestand dat naar de verkeerde persoon werd gestuurd. Er zijn zovele manieren dat data kan uitlekken, en echt niet altijd omdat software niet is bijgewerkt.

[rbr320]

Wat is veel? Zelfs als het maar om 1 of 2% gaat spreek je in absolute aantallen alsnog over enorm veel bedrijven en organisaties. Maar procentueel is het enorm weinig. De meeste bedrijven en organisaties hebben hun update beleid gelukkig wel in orde.

Tsja, waarschijnlijk heb ik er een negatiever beeld van dan veel anderen omdat ik vanuit mijn werk meestal bij bedrijven kom waar het niet op orde is.

Daarnaast zijn er nog veel meer lekken die ontstaan door menselijke fouten. Zoals gisteren nog, waarbij de anonimisering niet goed werd uitgevoerd. Of een bestand dat naar de verkeerde persoon werd gestuurd. Er zijn zovele manieren dat data kan uitlekken, en echt niet altijd omdat software niet is bijgewerkt.

Ik wil ook zeker menselijke fouten niet bagitalliseren, dit komt ook zeer vaak voor want waar mensen werken worden fouten gemaakt.

[PvdVen777]

Het regent letterlijk datelekken de laatste week of twee.

Maar eigenlijk zouden we ons volgens mij eerder moeten verbazen dat dit niet eerder is gebeurd gezien de soms nonchelante manier van omgaan met gegevens.

[PageFault]

Ik vermoed dat dit al eerder heel vaak gebeurde, alleen toen was men nog niet verplicht het te melden. Ik heb geen bewijs en geen statistieken, maar ik kan me niet voorstellen dat met al dat digitale geweld van afgelopen 20-25 jaar er ineens een stapel datalekken zijn en al die jaren ervoor niet.

[Blokker_1999]

Maar de vraag is: gebeurd het vaker, of wordt het nu sneller gemeld doordat het verplicht is door de wetgeving?

[Lisadr]

Dat komt omdat bedrijven te weinig doen aan informatiebeveiliging en omdat het nu verplicht is om een datalek te melden.

[Tadango]

In dit geval is NAM niet de schuldige maar de leverancier van de dienst, welke een lek blijkt te bevatten.

[tweaker2010]

In dit geval is NAM niet de schuldige maar de leverancier van de dienst, welke een lek blijkt te bevatten.

Dat maakt niets uit. De NAM heeft een verwerkersovereenkomst afgesloten met hun leverancier (als het goed is). Deze leverancier zou ook aan een aantal eisen en richtlijnen moeten voldoen conform de AVG.

[Lisadr]

NAM is verantwoordelijk en hoort eisen te stellen aan leveranciers en die periodiek te controleren.

[Weiman]

Lekker is dat, eerst "slopen" ze je huis, daarna lekt je data ook nog eens via hen. De slachtoffers zullen het bloed van de NAM wel kunnen drinken.

Is de NAM hier nog enigzins strafbaar voor, trouwens? Of moet daarvoor eerst nog verder onderzoek gedaan worden?

[Baps]

Voor zover ik weet is er nog nooit iemand vervolgd voor het 'laten lekken van gegevens' of anders gezegd, het treffen van onvoldoende maatregelen om die gegevens te beschermen. Denk eerlijk gezegd ook niet dat je daarvoor bij het strafrecht moet zijn.

Civielrechtelijk zit je natuurlijk vooral met de Autoriteit Persoonsgegevens die een onderzoek kan instellen en de NAM een boete kan opleggen. Daarnaast kun je als gedupeerde mogelijk aanspraak maken op schadevergoeding. Er zijn gevallen bekend in de jurisprudentie waarbij mensen bijvoorbeeld 500 euro schadevergoeding kregen omdat hun gegevens waren gelekt. Daarbij moet ik wel zeggen dat het daar ging om gegevens die door een actieve fout van het bedrijf/de instantie waren gelekt. Schadevergoeding eisen omdat je gegevens zijn gelekt bij een hack, ben ik nog niet van op de hoogte (maar misschien heb ik iets gemist).

[IJsbeer]

In dit geval vind ik wel dat ze grove nalatigheid ten laste gelegd mag worden. Als het een zero day lek is, tja, daar kun je waarschijnlijk weinig aan doen. Maar een lek die in 2019 al is gedicht, betekend dus dat er (doelbewust) al minstens anderhalf jaar geen onderhoud / beveiligingsupdates zijn geïnstalleerd in een systeem dat je gebruikt om veiligheid / essentiële bedrijfsinformatie te delen.

[Lisadr]

De Autoriteit Persoonsgegevens (AP) is bevoegd om sancties op te leggen als een organisatie de privacywetgeving overtreedt. De belangrijkste sancties zijn de boete, de last onder dwangsom, het verwerkingsverbod, de berisping en de waarschuwing. De AP kan organisaties die de AVG overtreden een boete opleggen van maximaal 20 miljoen euro of 4% van de wereldwijde jaaromzet. Deze bevoegdheid heeft de AP sinds 25 mei 2018, de datum dat de AVG van toepassing werd.

NAM als bedrijf kan boetes krijgen. Verantwoordelijke leidinggevende zullen er niets van merken en waarschijnlijk achteraf een bonus krijgen voor hun werkzaamheden tijdens een stressvolle periode. Kijk maar naar de vele mislukte IT projecten bij de overheid. Kost de belastingbetaler miljarden, maar de verantwoordelijke personen gaan van overheidsorganisatie naar overheidsorganisatie en krijgen vaak promotie.

[mjtdevries]

Als je in het bedrijfsleven nalatig bent en het bedrijf veel schade veroorzaakt, dan word je echt niet de hand boven het hoofd gehouden zoals bij ambtenaren steeds gebeurd.

[TD-er]

Lekker is dat, eerst "slopen" ze je huis, daarna lekt je data ook nog eens via hen. De slachtoffers zullen het bloed van de NAM wel kunnen drinken.
[...]

Het is echt niet alleen de NAM die ietwat in onmin is geraakt bij de bevolking hier.

Maar goed, zoals een buurman gisteravond al opmerkte in de app hierover:
"Niet alleen m'n adres is gejat, m'n hele huis is weg"
(als uitleg, we zitten hier met de hele straat al ruim een jaar in de wisselwoningen terwijl de woningen gesloopt en herbouwd worden)

[BleghBlarg]

Ik weet niet of Accellion een nederlandse tak/kantoor heeft maar ik zou (als de aanname dat het om Kiteworks gaat correct is) bijna de NAM aanklagen voor smaad.
Het bericht op hun website is een typisch "het is niet onze schuld" bericht en daar moeten mensen het maar mee doen. Ze vermelden er ook bij dat het lek inmiddels is gedicht, terwijl dit dus al een tijd geleden was. Wederom om de beschuldiging extra duidelijk naar een andere partij te wijzen..
Iets meer dan een jaar niet updaten is daarin echt te kwalijk vooral als het gaat om een update voor veiligheid en niet functionaliteit.

Het handhaven is hierin alleen lastig.. Iemand suggesties? Het risico van een boete zouden veel bedrijven wel nemen. En als die boete dan wordt opgelegd is er natuurlijk weer geen geld om het in betere beveiliging/admins te stoppen.

[fsfikke]

Waaruit trek je de conclusie dat de kwetsbaarheid die in 2019 misbruikt is dezelfde is die nu gebruikt is en het dus een kwestie van niet up-to-date software is? Wat het artikel volgens mij wil zeggen is dat de software in het verleden ook al problemen had. Net zoals bijvoorbeeld Windows. In 2019 heeft Microsoft ook kwetsbaarheden gedicht, maar daarmee is Windows niet meteen 100% waterdicht

[BleghBlarg]

Misschien had ik de aanname van het artikel dat het wellicht om Kiteworks gaat moeten doortrekken naar de aanname dat NAM hun eigen situatie niet op orde hadden.

Verder noemt NAM zelf dat zijn hier eind vorige week achter kwam. In het vroegste geval is dat naar mijn idee donderdag. Het eigen artikel van NAM was dinsdag, 5 dagen. (Waarvan 2 weekend maar laten we 5 volle dagen rekenen als ze een hele sterke storingsdienst hebben)
Dat is voor een bedrijf dat hun software in gebruik heeft bij een redelijk aantal bedrijven en ook zeker moet blijven van de werking een heel erg snel proces als het inderdaad in die tijd is gefixed. Hetzelfde argument kan natuurlijk ook andersom gebruikt worden. Echter heeft recent verleden nog gebleken dat Accellion voor een legacy systeem nog wel binnen 72 uur gepatched hadden maar deden er meerdere weken over om gelijknamige hacks allemaal te dichten, en werden partijen toch verzocht om over te gaan op hun nieuwe systeem, Kiteworks.

Ik geef toe dat ik aannames maak. Maar ik zal zeker niet tekort willen schieten aan het geschetste verhaal als die aannames ook correct blijken te zijn.

[gaskabouter]

Wie had er nou een lek, de NAM of de filesharingsdienst?

[Beilos]

Als ik het goed lees de filesharingsdienst. De NAM is dus niet gehacked. Maar dan had Kiteworks het lek moeten melden denk ik zo.

De titel klopt dan ook niet echt.

"..... volgens de NAM zijn de criminelen niet in de systemen van de NAM geweest. Enkel in de filesharingsdienst."

[Groningerkoek]

Er wordt door de NAM wat taalkundig gegoocheld, er is niet in een NAM systeem ingebroken maar in een systeem wat door de NAM wordt gedraaid

Afdeling PR doet zijn werk goed daar.

[BleghBlarg]

De software werd gedraaid door NAM. Het is gewoon een programma wat je in je lokale netwerk kan draaien (en eventueel openzetten voor buiten) Maar het is zeer zeker gehost door NAM. En dan moeten zij ook de software up-to-date houden.

[Paitor]

Je gaat er van uit dat de filesharingdienst een cloud service is? Zoals het artikel geschreven is, wijst het naar on-premise software en verantwoordelijkheid aan de kant van de NAM. De persvoorlichter van de NAM weet het wel handig te spinnen zodat ze minder verantwoordelijk lijken.

Je kunt de verantwoordelijkheid ook aflezen aan wie de melding bij AP heeft gemaakt, daar ligt het werkelijke probleem.

[mjtdevries]

Het maakt niet uit of het een cloud service is.
NAM is de verwerkingsverantwoordelijke (controller) en de filesharingdienst in de cloud dan de verwerker. De verwerkingsverantwoordelijke moet aangifte doen bij de AP.

Ook al zou de schuld volledig bij de verwerker liggen, dan is het nog steeds de verwerkingsverantwoordelijke die melding moet doen.

[johnkessels87]

De NAM is eigenaar van de gegevens en lijkt mij dus aansprakelijk.

[OxWax]

Disclaimer op hun site

Voor de duidelijkheid: het gaat niet om andere informatie in uw dossier die op ons netwerk (in een afgeschermd gedeelte) bewaard wordt. De hackers zijn niet in de IT-systemen van NAM geweest. Het datalek in de transfer-software is inmiddels hersteld door genoemde leverancier.

https://www.nam.nl/nieuws...persoonsgegevens-nam.html

[Grrrrrene]

Wat is die laatste zin cryptisch zeg. Bedoelen ze nu dat Accellion het lek in 2019 al gedicht heeft (en door de datum / het jaartal niet te noemen proberen ze zichzelf vrij te pleiten?) of dat Accellion bij de NAM langs is geweest en de softwareupdate, die al in 2019 had moeten plaatsvinden, heeft uitgevoerd? Heeft de NAM daarvoor zelf geen ICT'ers in dienst ofzo?

Ik geloof dat Arjen Lubach hier een tijdje een item over had: onze overheid bestaat uit allemaal oude, grijze (vooral) mannen die niks van ICT weten. Dat is een internationaal probleem overigens, maar dat ter zijde. Hoe gaan die senioren ooit op aangeven van hun adviseurs (die ze op dit gebied echt niet begrijpen) goede wetgeving doorvoeren en zorgvuldig met data van burgers werken?

[OxWax]

Vandaar dat ik ze in het zwart zette.
Niet perse oude mannen die niks van IT kennen, maar vooral die niet of amper afgerekend worden op hun prestaties/fouten (en nooit het management.)
https://imgur.com/a/n1dhcpv

https://www.geenstijl.nl/...t-balk-bonnetje-is-kwijt/

[mjtdevries]

Het is toch zonneklaar?

De filesharingdienst had een lek. De NAM werd verplicht die dienst te gebruiken. Uiteindelijk is de NAM daarmee verantwoordelijk en moest het bij de autoriteit persoonsgegevens melden.

Uiteindelijk is het wel een beetje flauw van de NAM om zo duidelijk te melden dat het lek in de filesharingdienst zat, want als ze die dienst niet goed genoeg vonden, dan hadden ze dat meteen bezwaar moeten maken toen ze verplicht werden die dienst te gebruiken.

[OxWax]

De fsd had al een patch in 2019 uitgebracht

[fsfikke]

De Flash player heeft in 2019 ook een security-hotfix gekregen. Is het daarom nu veilig om hem te gebruiken?

[batjes]

Helemaal gezien ze al meer dan een jaar de moeite niet genomen hebben de software te upgraden. Pure nalatigheid. Ik hoop wel dat het AP ze hiervoor stevig op de vingers tikt en ik verwacht eigenlijk dat hier een boete op gaat volgen.

Als je meer dan een jaar lang je software niet update en dan gehacked wordt, zou je 100% aansprakelijk gesteld moeten worden.

[DonChaot]

Het klinkt als iets wat ze zelf draaien aangezien er in 2019 blijkbaar een update voor was. Blijft natuurlijk de vraag waarom er al meer dan een jaar geen update gedaan is...

[OxWax]

Blijft natuurlijk de vraag waarom er al meer dan een jaar geen update gedaan is...

NAM = overheid?

[Paitor]

De NAM is voor de helft eigendom van het Nederlands-Britse Royal Dutch Shell en voor de helft van het Amerikaanse bedrijf ExxonMobil. Zie Wiki

De softwareleverancier had een lek in zijn software. De NAM gebruikte deze nog actief. In deze heeft de NAM de aansprakelijkheid naar eindgebruikers toe. Wellicht kan de NAM dat dan weer verhalen, maar dat is hun probleem.

[TheVivaldi]

In zekere zin is de overheid er wel indirect bij betrokken aangezien onze koning volgens mij aandeelhouder is bij Shell?

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 18:39]

[etrans]

NOS: Koning Willem-Alexander heeft geen aandelen van bedrijven die het predicaat koninklijk voeren

Koning Willem-Alexander heeft geen aandelen van bedrijven die het predicaat koninklijk voeren. Dat staat sinds vandaag op de website van het Koninklijk Huis. Het impliceert dat de koning ook geen aandelen heeft van de Koninklijke Shell, waarover al geruime tijd geruchten de ronde doen.

Volgens een woordvoerder van de Rijksvoorlichtingsdienst is de zin over de aandelen toegevoegd om "tegemoet te komen aan de onduidelijkheid die erover bestond". Zo riep PvdA-Kamerlid Nijboer de koninklijke familie begin dit jaar op om opening van zaken te geven over de eventuele belangen in Shell. Aanleiding voor de oproep was de rol van Shell bij de gaswinning in Groningen.

[Triblade_8472]

"Koning Willem-Alexander heeft geen aandelen van bedrijven die het predicaat koninklijk voeren."

Dus hij heeft wel aandelen Shell die niet het predicaat voeren...?

Wat een raar taalgebruik voor mij als simpele ziel.

[Composed]

Er zijn meerdere aandelen die het predicaat koninklijk mogen voeren. Royal Dutch Shell is er daar eentje van maar de koning heeft van geen enkele dus aandelen.

[mjtdevries]

Nee, die aandelen zijn waarschijnlijk allemaal in handen van Beatrix.

Dat PvdA kamerlid vroeg naar aandelen van de koninklijke familie, maar ze vertellen alleen over Willem-Alexander. Ra ra waarom zou dat toch zijn?

[Triblade_8472]

Ahh ik interpreteer het dus verkeerd. (Leuk he dat je meteen -1 krijgt op een normale vraag..)

Dat ze geen aandelen hebben met het predicaat koninklijk slaat dus op het feit dat ze geen aandelen hebben van alle bedrijven die koninklijk mogen voeren.

Bedankt voor het rechtzetten.

[OxWax]

Even verder gegraven
Omdat Koning Willem III betrokken was bij de oprichting van het bedrijf, is lange tijd aangenomen dat het Nederlands Koninklijk Huis een groot belang had in Koninklijke Olie.

Koningin Wilhelmina had destijds naar verluidt 25% van de aandelen Shell in handen.

De laatste 25 jaar heeft echter niemand van het Koninklijk Huis een belang van meer dan vijf procent gemeld, iets wat verplicht is. De geruchten gaan dat het aandelenbezit over meerdere mensen verspreid is, zodat geen van de personen een groter belang heeft dan 5%.

Omdat het vermogen van de Oranjes over het algemeen in de doofpot wordt gestopt, bestaat hier geen zekerheid over.
https://www.lynx.nl/kennis/artikelen/koninklijke-aandelen/

[The Zep Man]

Niet de overheid, tot zover de koninklijke familie enkel een ceremoniële rol vervult.

Ik weet ook niet of de overheid eigenaar zou willen zijn...

[Reactie gewijzigd door The Zep Man op 24 juli 2024 18:39]

[wankel]

Ik weet ook niet of de overheid eigenaar zou willen zijn...

Als acties uit het verleden een indicatie voor de toekomst zijn, is een schandaaltje meer of minder geen bezwaar voor de NL overheid, als er een slagje uit te slaan valt.

[fsfikke]

Nee, de NAM is een privaat bedrijf (JV), maar 90% van de opbrengsten van het gas gaan naar de staat. Van de overige 10% gaan de kosten van de NAM af waarna er nog een paar procent winst overblijft.

quote: https://www.dvhn.nl/econo...dan-gedacht-23313835.html

De NAM ontving 10% van de opbrengsten van de gaswinning. Van de gasbaten ging 90% naar de Staat.

[Reactie gewijzigd door fsfikke op 24 juli 2024 18:39]

[Blokker_1999]

De software van Accellion bevatte het lek, maar dat was gepatched in 2019. Je moet dan wel je software up to date houden natuurlijk.

[fsfikke]

En we weten dat dit wonderbaarlijke stukje software maar 1 lek bevatte?

(Ook @batjes )

[Reactie gewijzigd door fsfikke op 24 juli 2024 18:39]

[j005t]

Het enige dat we leren van het verleden is dat we niet leren van het verleden.

[Somoghi]

I see what you did there.
And I agree to disagree.

[Tusk]

Ik vraag me steeds vaker af waarom ik nog mijn best doe om mijn privacy te bewaken als overheden of grote bedrijven mijn data al 10x hebben gelekt....

[R4gnax]

Het gaat hier naar alle waarschijnlijkheid om filesharingsdienst Kiteworks, dat al meerdere keren gebruikt werd bij het stelen van gegevens, onder andere in Australië en Nieuw-Zeeland. Kiteworks wordt gebruikt door verschillende banken, overheden en zorginstellingen. Zo gebruikt bijvoorbeeld Rabobank Kiteworks. De kwetsbaarheid in Kiteworks die daarbij misbruikt werd is door Accellion al eind 2019 gedicht, maar dan moeten gebruikers ervan de software wel updaten.

Wired geeft een wat meer compleet beeld van zaken en daaruit blijkt dat het niet Kiteworks, maar de ondertussen 20 jaar oude voorloper FTA (File Transfer Application) is die lek is.

Partijen zoals Rabobank, die van Kiteworks gebruik maken en niet van het oude FTA, zouden hier dus niet in het vizier komen.

[Reactie gewijzigd door R4gnax op 24 juli 2024 18:39]

[Verwijderd]

Weinig goeds uit de diensten die nam daadwerkelijk doed. "Afvalwater" injectie op grootschalige vlak in o.a Twente. Begrijp gewoon niet dat dat bedrijf daar de vergunningen voor krijgt en alle verantwoordelijkheid door zit te schuiven op volgende generaties.