Radboudumc-datalek kwam door delen van scripts met persoonsgegevens op GitHub

Het Radboudumc zegt verschillende onderzoeken naar het datalek van eerder deze maand te hebben afgerond. Daaruit kwam naar voren dat de gegevens zijn gelekt doordat een voormalig medewerker bestanden op GitHub plaatste. Daar stond ook vertrouwelijke informatie in.

Het Nijmeegse academische ziekenhuis zegt dat een inmiddels oud-medewerker het datalek heeft veroorzaakt door een aantal bestanden te delen op GitHub. Het gaat om bestanden met scripts voor het automatiseren van processen. Daar was echter ook 'vertrouwelijke informatie uit de IT-omgeving van het Radboudumc te vinden', waaronder persoonsgegevens.

Volgens het Radboudumc komt uit de onderzoeken naar voren dat de gelekte bestanden daadwerkelijk zijn gedownload door derden. 'Eén van deze partijen heeft de informatie over de inrichting van het netwerk van het Radboudumc misbruikt om op servers van een onlineomgeving van het Radboudumc cryptovaluta te genereren', schrijft het ziekenhuis.

Er wordt benadrukt dat er geen sprake is geweest van ongeoorloofde toegang tot de bedrijfsapplicaties van het ziekenhuis, zoals elektronische patiëntendossiers of de financiële administratie. Tijdens de eerdere melding gaf het Radboudumc al aan dat het ging om inloggegevens, e-mailadressen en telefoonnummers. Het ziekenhuis heeft na de ontdekking het lek naar eigen zeggen onmiddellijk gedicht, maatregelen genomen om herhaling te voorkomen en het datalek gemeld bij de Autoriteit Persoonsgegevens.

Het ziekenhuis heeft aangifte gedaan tegen de cryptominer. Ook is aangifte gedaan tegen de veroorzaker van het datalek. 'De cyberpolitie Oost-Nederland heeft de zaak nu in behandeling', zegt het universitair medisch centrum.

Reacties (94)

[Rasael]

Zonder er meer over te weten denk ik dat aangifte tegen de voormalig medewerker een te grote zet is.

De voormalige medewerker is een ambtenaar, lees ik. Het is goed mogelijk dat de scripts gewoon zijn werk zijn. En dat hij die scripts voor eigen gebruik gewoon mocht bewaren.

Er is geen indicatie dat hij is ontslagen. Of dat de scripts zijn gepubliceerd om zijn werkgever te schaden.
Het is goed mogelijk dat hij (redelijkerwijs) aannam dat de betrokken credentials zouden zijn geinvalideerd.

Ik denk wel dat er een element van gevaarzetting is. Civielrechtelijk in plaats van strafrechtelijk. Het is namelijk niet bezwaarlijk om de credentials eruit te halen voor je een script op GitHub publiceert. En het is kenbaar dat er een groot risico kan zijn. Maar dat hangt weer samen met de vraag: `Heeft de werkgever hier niet zitten slapen door de credentials actief te laten?`

Maar omdat het dan over civielrecht gaat, is een aangifte niet op zijn plaats.

[Reactie gewijzigd door Rasael op 23 juli 2024 09:29]

[Verwijderd]

Je hebt een punt dat werkgever zelf ook heeft zitten slapen. Werkgever heeft namelijk ook de verantwoordelijkheid te nemen dat inloggegevens van systemen periodiek te veranderen. Zo niet. Minstens na elke beëindiging van een dienstverband bij de IT afdeling die mogelijkerwijs toegang hebben tot kritieke systemen. Dat zou een onderdeel van IT security beleid moeten zijn, wat dus niet aanwezig is of niet is uitgevoerd. Hiermee neemt de organisatie een risico.

[softinc]

Tja, if it ain't broke don't fix it, is toch de uitdrukking, en bij tekort aan mankracht en teveel oude infrastructuur die niet meer te patchen is vraag je om problemen

[MN-Power]

Sorry, maar het laten staan van credentials is ongeveer het domste wat je kan doen in de IT. Zelfs als zijn ze aangepast. Het user deel is hoogstwaarschijnlijk niet aangepast(ik heb ook geen weet van een best practise om zowel user als pw te veranderen) en het geeft wellicht ook iets prijs over de wachtwoord vereisten(lengte/speciale tekens). Om niet te spreken over leesbare wachtwoorden met een nummertje er achter (not done, ik weet het). Als het goed is kunnen ook zeer weinig personen binnen de organisatie ook verifiëren of het wachtwoord daadwerkelijk aangepast is, dus dat is over het algemeen een aanname en (niet alleen in de IT): aannames zijn dodelijk.

Als er dan ook nog eens systeemnamen/ip-adressen in staan heb je echt een handleiding + de benodigde sleutel gepubliceerd en heb je wat mij betreft echt niet nagedacht. Daar is echt geen excuus voor.

[Reactie gewijzigd door MN-Power op 23 juli 2024 09:29]

[Rasael]

Het is zeker niet handig.... Maar fouten worden gemaakt, ook als het over beveiliging gaat. Mensen kunnen ook een single point of failure zijn.

Ik ben het denk ik wel met je eens dat we van deze persoon meer discretie hadden mogen verwachten. Aangezien hij in de IT werkzaam is en behoorlijk wat ervaring lijkt te hebben. Vandaar mijn opmerking over gevaarzetting.

De kernboodschap is echter dat gevaarzetting van een hele andere orde is dan strafrechtelijke vervolging.

[Alxndr]

Tsja, ik lees inderdaad nergens dat er sprake zou zijn van opzet, maar ook niet dat dat niet zo zou zijn. Net als dat je uit de bron niet op kan maken of deze persoon ontslag genomen heeft of ontslagen is.

Punt blijft dat er regels zijn overtreden en daardoor schade is ontstaan. Door aangifte te doen kan de cyberpolitie (die meer/andere bevoegdheden en mogelijkheden heeft) dit nu verder uit gaan zoeken, niets aan de hand toch?

[Rasael]

Je hoeft geen aangifte te doen. De politie mag ambtshalve een onderzoek starten.

Het doen van een aangifte betekent dat je, naar waarheid, meldt dat er een (vermoedelijk) misdrijf is gepleegd.

Punt hier is dat er helemaal geen reden is om aan te nemen dat de ambtenaar een misdrijf heeft gepleegd... Althans niet op basis van de berichtgeving op tweakers.

Als nu blijkt dat dat die ambtenaar slechts een fout heeft gemaakt (menselijk?) dan is nu wel zijn reputatie door de modder gehaald. Terwijl de werkgever misschien veel meer fouten heeft gemaakt qua beveiligingsbeleid. En dat nu lijkt af te wentelen op een voormalig werkgever. Of niet. We weten het niet.

[Reactie gewijzigd door Rasael op 23 juli 2024 09:29]

[Alxndr]

Politie mag zelf onderzoeken starten, maar geloof dat alle takken van de politie al overbelast genoeg zijn.

Persoonlijk lijkt het mij aannnemelijker dat wij informatie missen of informatie in belang van het onderzoek achter gehouden wordt, dan dat wij vanaf achter onze computer kunnen stellen dat er geen goede reden is/zou zijn om wel aangifte te doen? Ik bedoel het Radboudumc is een grote professionele organisatie, met naar ik aanneem ook een juridisch team wat deze stap heeft geadviseerd/genomen?

Reputatie schade voor de werknemer lijkt me nogal mee te vallen, het is nu niet zo dat hij/zij met naam of wat dan ook genoemd wordt. Wie moet er hoe achter komen wie deze persoon is, die al dan niet onterecht beschuldigd is. Bovendien innocent until proven guilty?

Het afwentelen van verantwoordelijkheden lijkt me ook een behoorlijk negatieve aanname als daar verder geen enkele reden of bewijs voor is? (Ik heb geen idee of het Radboudumc een reputatie op dit gebied heeft)

[Verwijderd]

Het is goed mogelijk dat de scripts gewoon zijn werk zijn. En dat hij die scripts voor eigen gebruik gewoon mocht bewaren.

Alles wat je onder werktijd bouwt is eigendom van het bedrijf, niet van jou. Als jij dus iets van het werk wil 'publiceren' zal je daar toestemming van de organisatie voor nodig moeten hebben. Tevens heeft iedere organisatie (neem ik aan) wel een standaard geheimhoudings verklaring dat je juist dit soort dingen niet zomaar doet.

Maar omdat het dan over civielrecht gaat, is een aangifte niet op zijn plaats.
Er is data gelekt dus dan gaat het civiel recht automatisch de deur uit. Aangifte is verplicht bij de juiste (AP) autoriteiten.

Heeft de werkgever hier niet zitten slapen door de credentials actief te laten
Voor zover ik hier lees was de werkgever niet eens op de hoogte van de werknemers intentie. Dus die kun je nergens in kwalijk nemen.

Deze gast heeft gewoon zijn werkgever, zijn collega's en mogelijk andere mensen genaaid door persoonsgegevens en intellectueel eigendom te lekken. Daarbij hebben ongeoorloofden toegang gekregen tot systemen door zijn ongeoorloofde gedrag. We mogen onze handen dichtknijpen dat hij niet meer schade heeft aangericht.

Zijn hoofd op het (strafrechtelijke) hakblok is naar mijn mening dan ook prima. Hij heeft op meerdere niveau's gefaalt.

[Rasael]

Je zegt heel stellig een aantal zaken. Maar dat zijn eigenlijk slechts aannames die je doet.

Het is goed mogelijk dat er contractueel niets over auteursrecht is afgesproken.
Het is ook goed mogelijk dat de werknemer de scripts zelf heeft geschreven en daarna pas in dienst is gekomen bij zijn werkgever. Etc..

Je loopt ook heel makkelijk voorbij de verantwoordelijkheid van de werkgever. De werkgever hoort de regie te voeren. En hoort ook te bewaken dat de IT inrichting veilig is. De werkgever is aansprakelijk voor bv. datalekken. Het is de werkgever die bepaalde certificeringen (ISO) behaalt en zich daarmee in de markt presenteert. En het is de werkgever die naar klanten toe aansprakelijk is voor beveligingsincidenten.

Tenslotte,
Je vult in dat deze persoon mensen heeft genaaid, maar je levert daarvoor geen bewijs. Als je de achternaam van de persoon erbij zou zetten zou dit smaad zijn. En kan je zelf op het strafrechtelijke hakblok worden gelegd. Want je zit een potje te fantaseren. Waarmee je dus expres de betrokken ambtenaar in een kwaad daglicht stelt. Terwijl je weet dat je helemaal niet over alle feiten beschikt, en dat (statistisch) zeker is dat wat je zegt niet in lijn is met waarheid.

[Reactie gewijzigd door Rasael op 23 juli 2024 09:29]

[Verwijderd]

Het is goed mogelijk dat er contractueel niets over auteursrecht is afgesproken.
https://www.auteursrecht.nl/ik-ben-maker/Werkgever-als-maker

Het is ook goed mogelijk dat de werknemer de scripts zelf heeft geschreven en daarna pas in dienst is gekomen bij zijn werkgever. Etc..
Heeft hij die persoonsgegevens ook geschreven toen hij deze lekte?

Je loopt ook heel makkelijk voorbij de verantwoordelijkheid van de werkgever. De werkgever hoort de regie te voeren.
Dat heet micro-management en nee, dat is niet een verantwoordelijkheid van de werkgever. Je verwacht autonomie van de persoon binnen zijn functie. Als ik iemand een hark geef met een locatie dan ga ik niet erbij staan om hem ieder grassprietje aan te wijzen. Je bekijkt enkel het resultaat. Ik ga er inderdaad van uit dat deze man volwassen is en zich zo kan gedragen.

En hoort ook te bewaken dat de IT inrichting veilig is.
Dit heeft niets met data veiligheid te maken. Deze man heeft doelbewust gehandelt. Dit is iemand die bewust onzorgvuldig bestanden heeft deelt. Je moet mensen toegang geven om hun werk te doen. Deze man heeft simpelweg misbruik hiervan gemaakt.

De werkgever is aansprakelijk voor bv. datalekken. Het is de werkgever die bepaalde certificeringen (ISO) behaalt en zich daarmee in de markt presenteert. En het is de werkgever die naar klanten toe aansprakelijk is voor beveligingsincidenten.
Dat klopt, de organisatie is uiteindelijk verantwoordelijk. Dat wil echter niet zeggen dat deze man niet schuldig is en aangeklaagd of ontslagen kan worden.

Want je zit een potje te fantaseren.
Lol, slecht geslapen? Ik loop niets te fantaseren, het is gewoon logische redenering: persoonsgegevens zijn gelekt en de gevolgen waren groot waaronder hacker(s) in ziekenhuissystemen. Deze man heeft onzorgvuldig gehandeld en is terecht ex-werknemer.

[Rasael]

Ik stel voor dat je het stuk nogmaals leest. Want er staat nergens dat deze man is ontslagen. En er staat ook nergens dat deze man misbruik heeft gemaakt van de credentials.

Het gaat om 2 aparte partijen. Een partij heeft ingebroken en crypto gemined. Een andere partij heeft de credentials, al dan niet per ongeluk, gelekt op een publieke website. Er is nergens een indicatie gegeven dat er is samengespannen.

Deze man heeft doelbewust gehandelt.

Dat staat nergens. Dat neem jij aan en blijf je hier nu expres volhouden...

Heeft hij die persoonsgegevens ook geschreven toen hij deze lekte?

Ik denk dat je wel snapt dat het copy-pasten van credentials in een bestaand script dat script niet magisch eigendom maakt van de werkgever. De werkgever verkrijgt slechts een licentie. En de werknemer houdt het volledige recht op het werk.

https://www.auteursrecht.nl/ik-ben-maker/Werkgever-als-maker

Misschien was er in zijn contract juist afgesproken dat alles zijn eigen werk zou zijn? Het punt is: Je weet helemaal niet wat er is afgesproken. En toch doe je aannames en veroordeel je iemand in zeer sterke bewoordingen. Daarom zeg ik: Je zit te fantaseren.

[Reactie gewijzigd door Rasael op 23 juli 2024 09:29]

[Verwijderd]

Ik stel voor dat je het stuk nogmaals leest.
Er valt hier niet veel te lezen... het is nog niet eens een pagina tekst.
Ik weet niet waarom je het zo opneemt voor deze persoon. Er is hier echt niemand anders schuldig dan deze gast tenzij Radboud hier toestemming voor heeft gegeven. Gezien ze hem aanklagen, lijkt mij dit totaal niet de kwestie. Dat zijn ook geen 'aannames'...

Ja, de man heeft doelbewust gehandeld. Hij heeft die bestanden op internet geplaatst. Je logt niet ergens in en upload bestanden onbewust. Je kunt dit niet verdraaien naar een 'Wir haben es nicht gewußt' verhaal.

Misschien was er in zijn contract juist afgesproken dat alles zijn eigen werk zou zijn?
Je beschuldigt mij van 'aannames' en 'fantaseren' terwijl dit duidelijk een normale en zelfs wettelijke verplichte gang van zaken zou zijn. Geen enkel bedrijf zou dit tolereren of speciale afspraken hierover maken. Ik weet niet wat voor bubbel je leeft of wat voor belang jij hebt in deze zaak maar je hebt duidelijk problemen met de normale realiteit (heb je soortgelijke problemen gehad met een werkgever?). Die realiteit is dat deze man persoonsgegevens en vertrouwelijke bedrijfsinformatie op internet heeft geplaatst die duidelijk niet van hem waren. Daardoor is er zelfs 'ingebroken' op systemen van Radboud. Hij zal hiervoor gestraft worden.

Jij kan er prima het verhaal proberen te verdraaien dat dit niet 'zijn' schuld was maar gelukkig leeft de rest van maatschappij niet in die bubbel.

[Rasael]

Aangezien u nu over gaat op persoonlijke aanvallen aanvaard ik dit als uw verklaring van overgave.
Want logica en feitelijkheid zit er verder niet in uw repliek...

[Verwijderd]

Verklaring van overgave. Lol, wat? Was er al een oorlogsverklaring dan? Wie praat zo?
Het gaat hier niet om zijdes maar om feiten. De betreffende man zat gewoon volledig fout en gaat de gevolgen nu ondervinden. Dit staat allemaal letterlijk in het artikel...
Dus, plezier in je wereldvreemde bubbel, de echte wereld gaat gelukkig gewoon verder...

[To_Tall]

Lekker bij de hand.

Ik kan begrijpen dat je als je script hebt gemaakt en denkt daar kan iemand anders ook nog wat aan hebben. Dat je dit deelt.

Maar haal dan wel alle verwijzingen die naar de klant of oud werkgever kunnen leiden er uit. Is dit te ingewikkeld, doe het dan niet. Maar dan zal hij het script ook niet gemaakt hebben.

Zeker ook als er gebruikersnamen en wachtwoorden in staan. Wat ik al helaas niet begrijp in scripts. Maar goed haal die gegevens er uit.

[Reactie gewijzigd door To_Tall op 23 juli 2024 09:29]

[Dennisdn]

De vraag is of je dat mág delen. Als iets in "de tijd van de baas" is gemaakt, is de werkgever over het algemeen eigenaar van het product. Op een universiteit kan dat nog veel complexer zijn met bedrijven en onderzoekers die deel-eigenaar kunnen zijn.

[Reactie gewijzigd door Dennisdn op 23 juli 2024 09:29]

[To_Tall]

Zolang er geen bedrijfs data in staat en het een algemeen script is. Zal een werkgever daar niet heel moeilijk over kunnen doen.

Ik heb zelf een aantal scripts gemaakt, die ik deel met meerdere opdracht gevers. Ik kan ook het script helemaal opnieuw maken. Dan krijg je hetzelfde script. Er staat geen bedrijfs data in die scripts. Ook geen verwijzingen. Gezien deze scripts leven op variabelen.

[True]

Zal een werkgever daar niet heel moeilijk over kunnen doen.

Ja dat geloof ik ook, maar nu komt de aap uit de mouw dat het eigenlijk a) toch niet mocht (goh dat snapt iedereen) en b) dat het ook nog eens verkeerd afloopt omdat deze kluns er bedrijfsdata in laat staan. Volledig begrijpelijk dat er dan actie ondernomen wordt.

[To_Tall]

Ik heb het hier over algemene scriptjes. Get-hotfix -computername “$computername”

Veelal worden scripts van het internet afgeplukt en worden scripts samengevoegd. Zeker als het algemene zaken zijn.

Zeker als ik buiten declaratie als zelfstandige een script maakt van hey dat is nog ff makkelijk om te hebben. Wat meer dan regelmatig gebeurd. Van wie is het script dan?

Dan is punt a toch niet zo zwart wit als je schetst.

[DerDee]

Dat is meer een verschil van kan en mag. Als je normaal in loondienst werkt en niet duidelijk gespecificeerd hebt in je contract dat je activiteiten buiten werktijd niet uitgesloten zijn van rechten van werkgever staat die hier heel sterk.
Het is namelijk zo dat alle rechten automatisch gaan naar degene waarvoor je in dienst bent. Dus zelfs als ik op mijn vrije dag iets programmeer heeft het bedrijf waar ik op dat moment voor werk volgens de regels de copyrights.

Dit is vooral van toepassing als je voor jezelf iets wilt opzetten op je vrije dag (deeltijd). Als je dit goed wilt regelen dien je dit heel duidelijk af te kaderen wanneer je voor jezelf bezig bent. Krijg je dat niet op papier (in mijn geval werkte mijn toenmalige baas niet mee), dan kun je zomaar de inkomsten verliezen uit het project dat je volledig in je eigen tijd hebt opgezet. Gelukkig was ik goed voorgelicht, en heb uiteindelijk het project laten varen. Maar dat op basis van verhalen waarbij dit daadwerkelijk is gebeurd.

[To_Tall]

het copyright verhaal is gelukkig niet zo zwart wit als dat jij aanhaalt.

Als een ontwikkelaar een stuk software schrijft in opdracht van de werkgever. Dan krijgt de werkgever automatisch de rechten over de software. Dat is juist.

Als deze zelfde ontwikkelaar verbeteringen in privé tijd aanbrengt aan de software. Dan ook in deze gevallen zal de werkgever de eigenaar zijn van deze software.

Als de ontwikkelaar nu een hele andere applicatie ontwikkeld in privé tijd, dat niet gelinkt is aan de werkgever en hij kan aantonen dat deze software helemaal niet in opdracht van de werkgever is gemaakt. Dan is de ontwikkelaar eigenaar van de software. De werkgever ziet de software en wil de software inzetten. Dan zal de werkgever een licentie moeten nemen op de software of de rechten van de software moeten overnemen. In dat geval heeft de ontwikkelaar rechten op vergoedingen op de software.

In geval van een zelfstandige heeft een opdracht gever waar deze voor werkt nooit zomaar de rechten van de software. tenzij deze de opdracht krijgt om Product A te ontwikkelen/verbeteren. Zal de rechten van deze altijd bij de opdrachtgever liggen als dit is opgenomen in het contract. In alle andere gevallen liggen de rechten bij de ontwikkelaar.

[DerDee]

Mijn uitspraak alleen voor loondienst, als zelfstandige ben je in theorie gewoon in dienst van je eigen bedrijf. Dus heb je dit hele probleem niet. Maar wat betreft naast loondienst is het vooral het onderscheid lastig te maken wanneer het een "hele andere applicatie" is. Zo heb ik gevallen gehoord die simpelweg in zelfde sector zaten. Webdevelopment was genoeg om vanuit de werkgever te zeggen dat ze (deels) recht hadden op het product en/of inkomsten uit dit product. Specifiek opdracht geven is vanuit opdrachtgever niet nodig. Ik maak op dagelijkse basis stukken software waar niet concreet opdracht voor is geschreven. Zou ik op hetzelfde gebied (applicatie development op dit moment) in mijn eigen tijd ook aan de slag gaan, zou dat heel lastig te bewijzen zijn dat ik dit echt puur in mijn eigen tijd heb gemaakt, en niet in die van mijn baas. Of dat ik geen kennis heb "meegenomen" uit het bedrijf en toegepast heb voor mijn eigen software, wat dus voor een afdracht zorgt van deel inkomsten.

Voordat je aan dit soort dingen begint, zorg voor jezelf altijd dat je baas weet van heeft en voor jezelf dat op papier hebt staan dat de projecten niet gerelateerd zijn aan je baan (in loondienst). Dat maakt het achteraf allemaal makkelijker. Er vanuit gaan dat het verschil groot genoeg, is te subjectief en kun je jezelf aardig mee in de vingers snijden.

[Dennisdn]

Dat ligt weer aan het contract of je een script opnieuw kunt maken en commercieel toepassen. Gebruikelijk is een concurrentiebeding van een jaar of 5. Nu is een beding bij de rechter op zich goed aan te vechten, maar iets als een ontwikkeld script vermarkten lijkt mij aardig in tegenstrijd. De vraag is hoe relevant het script dan nog is na 5 jaar.

[CH4OS]

Sterker nog, in een ziekenhuis heb je niet alleen te maken met persoonsgegevens, maar ook met medische gegevens. Beide gegevens mogen niet zomaar gedeeld worden, op wat voor manier dan ook, zal daar altijd toestemming voor moeten zijn vooraleer een bedrijf of instelling de gegevens mág delen. Het eigenaarschap van een script doet er letterlijk totaal niet toe. Eigenaarschap vs copyright en IP hebben volgens mij in het verleden bedrijven wel in het nadeel gesteld. En geloof je werkelijk dat een oud-medewerker ook maar iets daar om zou geven?

[TheMak]

Bij wetenschappers (wat het geval kan zijn bij Radboudumc) wordt bijna geacht dat je informatie deelt. Soms is het handiger om dat niet te doen. Universiteiten hebben een open bedrijfscultuur. Wat dus bij IT slecht uitpakt, of uit kan pakken.

[wica]

Ik persoonlijk zou het niet doen. Ook al staat er bij veel script bij mijn opdrachtgever GPL licentie in de header. Vind ik het not done.

Ideeën overnemen en hergebruiken als in opnieuw schrijven vind ik weer iets anders.

[YopY]

Was het niet zo dat je met een GPL licentie het juist MOET doen?

[IStealYourGun]

Je moet enkel de broncode delen met de gebruikers. Als de enige gebruiker je werkgever is, dan moet je dat enkel delen met je werkgever.

Stel dat je die applicatie commercialiseert, dan moet je dat enkel delen met je klanten.

Stel je het gratis ter beschikking, dan moet je het delen met iedereen.

[aikebah]

Stel je het gratis ter beschikking, dan moet je het delen met iedereen iedere gebruiker van je software

FTFY.. zelf bij gratis ter beschikking stellen hoef je het alleen met de gebruikers te delen. Dat dat potentieel iedereen is betekent nog niet dat je het aan iedereen ter beschikking moet stellen.

[closefuture]

Als iets in "de tijd van de baas" is gemaakt, is de werkgever over het algemeen eigenaar van het product.

Interessante kanttekening is dat dat voor ZPP'ers niet geld. Bij ZPP'ers moet je expliciet opnemen in het contract dat wat ze maken in "de baas" zijn tijd alsnog van de baas is. Als je dat niet doet is het eigendom van de ZZP'er.

[Dennisdn]

Ik denk dat je dat kunt vergelijken met softwarebedrijven die software in opdracht bouwen. Die houden vaak zelf de licentie tenzij anders afgesproken.

[Reactie gewijzigd door Dennisdn op 23 juli 2024 09:29]

[GeroldM]

Ben het met je eens dat een script nooit gevuld dient te zijn met (hardcoded) gebruikersnamen en/of wachtwoorden.

Maar het vaak wel makkelijker om gauw ff wat in elkaar te "schroeven" om te zien of dat het werkt. En wie weet, misschien was het script al aangepast, maar stonden de namen/wachtwoorden in een uitgecommentarieerd stuk tekst.

[To_Tall]

Dat gebeurd idd erg vaak.

Ik gebruik voor veel scripts service accounts. Watbikndan wel doe is dmv hash wachtwoord encrypten de decryptiebevel sleutel staat op een beveiligde share waar het service account wel bij kan komen.

Het is ook niet het veiligst. Maar wanneer je perongeluk het script deelt met iemand zonder de credetials te verwijderen. Dan hebben ze geen toegang tot de decryptie sleutel en wachtwoord is dan niets waard.

[souplost]

Precies de wachtwoorden hoeven niet weg maar moeten dan wel ge-encrypt zijn.
Wat vaak ook gebeurd op een git repo is dat mensen de vergissing door hebben en vervolgens gaan encrypten of weggooien en daarbij vergeten de history te herschrijven.
Net nog gekeken. Komt regelmatig voor!

[Niemand_Anders]

Wij gebruiken daar gewoon environment variables voor. Zeker als je meerdere scripts heb welke dezelfde configuratie/credentials nodig hebben.

Wij hebben ook diverse scripts en applicaties in onze git repository staan, maar deze wel als private gemarkeerd...

De readme.md bevat in ons geval een beschrijving van welke environment variabelen gezet moeten zijn.

[mcDavid]

Er staat ook niet dat die gegevens hardcoded in scripts stonden. Het kan even goed zijn dat er een datafile (csv, json of iets dergelijks) bij zat, en de oud-medewerker met de bokkenpruik op gewoon alles geupload heeft.

Deze info is echt te weinig om wat te zeggen over de staat van de codebases van het RadboudUMC, daarvoor zou je de betreffende repo zelf gezien moeten hebben.

[CH4OS]

Deze info is echt te weinig om wat te zeggen over de staat van de codebases van het RadboudUMC, daarvoor zou je de betreffende repo zelf gezien moeten hebben.

Daarnaast lijkt het me ook niet dat je aan de hand van 1 script al kan zeggen hoe de staat is van de algemene codebase.

[ctrl-tab]

Wie zegt dat hij dit script wilde delen?
Het is best practice om je scripts in een source code repo te stoppen anno 2021.
Maar doe dit dan wel in een private repo
En uiteraard altijd anonimiseren\parameteriseren.

[Keypunchie]

Zeker ook als er gebruikersnamen en wachtwoorden in staan. Wat ik al helaas niet begrijp in scripts. Maar goed haal die gegevens er uit.

Denk dat dit het meest waarschijnlijke is en mogelijk ook dat ze niet doorhadden dat het publiek was.

En mijn vermoeden is dat deze scripts niet gedeeld werden "voor de leuk", maar dat het onderdeel was van GitOps. Dus dat ze scripts in Git hadden staan omdat die onderdeel waren van een pipeline.

Helaas zie je dit wel vaker.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 09:29]

[Rasael]

Het is zeker niet handig.... Maar fouten worden gemaakt, ook als het over beveiliging gaat. Mensen kunnen ook een single point of failure zijn.

Ik ben het denk ik wel met je eens dat we van deze persoon meer discretie hadden mogen verwachten. Aangezien hij in de IT werkzaam is en behoorlijk wat ervaring lijkt te hebben. Vandaar mijn opmerking over gevaarzetting.

De kernboodschap is echter dat gevaarzetting van een hele andere orde is dan strafrechtelijke vervolging.

[Ramon]

Dus ontslag en aangifte voor het maken van een foutje bij het delen van kennis met anderen op github, een beetje overtrokken?

[wildhagen]

Hoezo ontslag? Het gaat om een voormalig werknemer, die dus al weg was. Die is dus zover bekend niet ontslagen (iig niet om deze kwestie).

Daarnaast heeft hij privé gegevens zonder toestemming verspreid, met alle gevolgen (datalek) vandien. Een aangifte lijkt me dan vrij logisch eerlijk gezegd.

[Reactie gewijzigd door wildhagen op 23 juli 2024 09:29]

[Keypunchie]

Aangifte alleen als men denkt dat het moedwillig is.

Civiele zaak is alleen maar mogelijk als het extreem nalatig is geweest wat de man heeft gedaan, de fout is immers gemaakt onder werktijd destijds. En dat werknemers wel eens fouten maken, ook met gevolgen, is het risico van de werkgever.

Als voorbeeld: stel een verhuizer laat een hele dure vaas vallen. Het zou wat zijn als jij die vervolgens moet betalen. Daar moet je werkgever zich maar tegen verzekeren.

Stel de verhuizer gooit de vaas kapot, met als doel de werkgever dwars te zitten (heeft bvb. een brief gestuurd: geef mij 1000 euro opslag, anders gaat je verzekeringspremie omhoog!), dan kan de werkgever aangifte doen.

Is er bedrijfsbeleid en training geweest dat vazen boven bepaalde waarde altijd in een speciale doos moeten worden vervoerd en onder supervisie geplaatst, maar heeft de medewerker de vaas los meegenomen en is hij ermee aan de wandel gegaan, terwijl hij met zijn andere hand aan het bellen was, dan kan het civiele zaak zijn, vanwege de veel te grote en onredelijke risico's die de medewerker nam in strijd met instructies.

De hamvraag is een beetje:
is logingegevens (en dat is het hier) in publieke scripts laten staan een dusdanig grove nalatigheid, dat het verwijtbaar is?

De vraag die ik dan heb: welke andere mitigaties waren er in plaats om te voorkomen dat je met deze gegevens overal bijkon? Welke hadden er kunnen zijn? Credential-verlies is immers geen ondenkbaar risico voor een IT-omgeving. Sterker nog, dit is waarom zoveel plekken wachtwoord-rotatie verplicht stellen.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 09:29]

[Rasael]

De hamvraag is een beetje:
is logingegevens (en dat is het hier) in publieke scripts laten staan een dusdanig grove nalatigheid, dat het verwijtbaar is?

Ik denk inderdaad van wel. Omdat dit over een ervaren IT werknemer (lijkt) te gaan. De gemiddelde ITer is bekend met het (grote) risico van het publiceren van credentials. Daar hoeven we geen discussie over te hebben. En het is ook niet bijzonder bezwaarlijk om de gegevens uit het script te halen. Ik kan me hoogstens voorstellen dat er een discussie komt over hoe makkelijk die credentials waren te vinden.

Misschien stonden ze op pagina 101 en niet in een soort globale variabele, bijvoorbeeld. In dat geval weet ik eigenlijk niet of ik het gevaarzetting zou vinden.

[dasiro]

er staat nergens wanneer en waarom hij is gestopt om voor hen te werken.

[bytemaster460]

Nee, maar er staat dat een voormalig medewerker de informatie gelekt heeft. Dat impliceert dat de medewerker al weg was voordat hij de info lekte. Als de medewerker vanwege het lek is ontslagen wordt dat nooit zo omschreven.

[dasiro]

niet per sé, het kan zijn dat het ding al lang op github stond toen hij er werkte en het nu pas ontdekt is, net omdat hij er al niet meer werkte en niemand nog omkeek naar de repo of er zelfs maar van af wist

[Cobalt]

Er staat in het artikel van het RadboudUMC word duidelijk genoemd dat er aangifte is gedaan en dat het ging om cryptovaluta te genereren (‘minen’).

[T-men]

Waar staat 'duidelijk' dat ging om cryptovaluta te genereren (‘minen’) ?
Volgens mij staat er alleen dat een derde de gegevens misbruikt heeft on een miner te installeren. Nergens staat dat dat het doel van het lek was.

[Rasael]

Het gaat om 2 partijen. Er staat nergens dat de voormalig ambtenaar de cryptominer is.

Er is aangifte gedaan tegen de cryptominer. En tegen de voormalig ambtenaar.
Nergens staat dat ze elkaar kennen, of dat ze samenspanden. Dat hoeft niet zo te zijn.

[SinergyX]

een inmiddels oud-medewerker

Dat hint toch duidelijk op een 'was medewerker, maar nu niet meer' geval.

[Croga]

Waar haal je vandaan dat deze man ontslagen is voor het delen van deze data? Ik zie alleen staan dat het gaat om een voormalig medewerker, mijn eerste gedachte is dat deze man al niet meer daar werkte.

Daarnaast: Aangifte is verplicht. RadboudUMC heeft hier geen keuze in. En als je dit soort dingen op een publieke Github zet dan mag daar van mij best eens serieus onderzoek naar gedaan worden.

[Verwijderd]

En als je dit soort dingen op een publieke GitHub zet dan mag daar van mij best eens serieus onderzoek naar gedaan worden.

Okay het is nalatig van een werknemer om zijn hardcoded gegevens niet te redact'en, maar of een strafrechtelijk onderzoek op zijn plaats is weet ik niet, een civiele zaak lijkt mij eerlijk gezegd passender.

Ik vind dat de intentie van de medewerker erg belangrijk is;
Als hij het opzettelijk deed, is een strafrechtelijk onderzoek nog niet eens zo gek.
Als het niet intentioneel was, dan vind ik een civiele procedure wenselijker.

[Croga]

Ik vind dat de intentie van de medewerker erg belangrijk is;
Als hij het opzettelijk deed, is een strafrechtelijk onderzoek nog niet eens zo gek.
Als het niet intentioneel was, dan vind ik een civiele procedure wenselijker.

En hoe kom je achter die intentie?.....

En hoe zit dat dan met andere overtredingen? Gaan we daar ook geen strafrechtelijk onderzoek doen als er geen kwaadwil was? Zo werkt het natuurlijk niet.... Als er een strafbaar feit gepleegd is dan volgt er een strafrechtelijk onderzoek.

[Verwijderd]

Dat weet ik niet, maar dat lijkt me de taak van de rechtbank, om daar over te oordelen.
Is het overigens strafbaar om inlog gegevens te lekken?
Als een oude oma haar mobiele bankieren app laat aftroggelen door oplichters, dan heeft ze waarschijnlijk ook inlog gegevens op een of andere manier laten lekken, is ze dan strafbaar?

[Croga]

Dat weet ik niet, maar dat lijkt me de taak van de rechtbank, om daar over te oordelen.

Dan nogmaals: Hoe komt dat bij de rechtbank terecht?....

Het is niet mogelijk om dit soort dingen te achterhalen zonder eerst onderzoek te doen. En dat onderzoek heet in Nederland nou eenmaal "Strafrechtelijk onderzoek".

[Verwijderd]

Dan nogmaals: Hoe komt dat bij de rechtbank terecht?....

Door een civiele procedure te starten of aangifte te doen, daarin heb je gelijk. Maar het doen van aangifte voelt nogal frivool in dit soort gevallen naar mijn mening.

Maar is de oma strafbaar ja of nee? als de bank verneemt dat de oma haar inlog gegevens heeft gelekt, moet de bank haar dan maar aanklagen, zodat ze de geleden financiële schade niet hoeven te vergoeden?

[mjtdevries]

Daarnaast: Aangifte is verplicht. RadboudUMC heeft hier geen keuze in.

Vertel eens welke wet het RadboudUMC verplicht om aangifte te doen, ook als de werknemer per ongeluk data heeft gelekt?

Ik denk dat je in de war bent met de verplichting om een datalek te melden bij de AP.
Maar dat is dus heel wat anders dan aangifte bij de politie.

[Rasael]

Je hoeft geen aangifte te doen. De politie mag ambtshalve een onderzoek starten.

Het doen van een aangifte betekent dat je, naar waarheid, meldt dat er een (vermoedelijk) misdrijf is gepleegd.

Punt hier is dat er helemaal geen reden is om aan te nemen dat de ambtenaar een misdrijf heeft gepleegd... Althans niet op basis van de berichtgeving op tweakers.

Als nu blijkt dat dat die ambtenaar slechts een fout heeft gemaakt (menselijk?) dan is nu wel zijn reputatie door de modder gehaald. Terwijl de werkgever misschien veel meer fouten heeft gemaakt qua beveiligingsbeleid. En dat nu lijkt af te wentelen op een voormalig werkgever. Of niet. We weten het niet.

[The Zep Man]

Het (originele) artikel spreekt over een oud-medewerker. Waren de bestanden geupload toen deze nog een medewerker was, of was die toen al een oud-medewerker? In het eerste geval kan het nog wel eens een (slordig!) ongeluk zijn. In het laatste geval is het natuurlijk dommer dan dom, want je doet niets met spullen van je ex-werkgever zonder expliciete toestemming. Verder zou je dat natuurlijk überhaupt niet (meer) in privébezit moeten hebben.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:29]

[Skit3000]

Behalve als hij/zij in dat laatste geval de eigenaar van de code was en dat gewoon mocht delen. Dan is het niet ontdoen van persoonsgegevens net zo goed een slordig ongeluk.

[The Zep Man]

Behalve als hij/zij in dat laatste geval de eigenaar van de code was en dat gewoon mocht delen.

In praktisch elk standaard arbeidsovereenkomst geeft de werknemer het eigendom/een exclusieve licentie van wat je produceert aan de werkgever.

Verder lijkt het mij niet de bedoeling om kritieke credentials van je werkgever in een script in eigen eigendom te hebben, al zou dat waar zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 09:29]

[BrennuS]

In dit geval betreft het een UMC/universiteit en ik vermoed dat het een aanstelling was (ambtenaar). die hadden tot begin dit jaar geen arbeidsovereenkomst, dus ik weet niet of dit zo opgaat.

bron: https://www.rijksoverheid...-rechtspositie-ambtenaren

en in het geval van een UMC (semi overheid)
https://www.nfu.nl/voor-u...tspositie-ambtenaren-wnra

er zijn natuurlijk uitzonderingen

[markiemannie]

Radboud was hier altijd van uitgezonderd omdat die op katholieke grondslag gesticht is en niet vanuit het Rijk. Iedereen is daar altijd werknemer geweest, de WNRA heeft er geen effect op gehad.

[Skit3000]

En ik zeg dat niemand hier de inhoud van de arbeidsovereenkomst van deze werknemer kent. Het zou zelfs zo kunnen zijn dat het altijd al zijn scripts waren en hij deze in heeft gebracht toen hij er kwam werken. Ik ken in ieder geval genoeg mensen met een uitzondering op deze clausule.

Dat er werkende credentials in stonden is natuurlijk een grote fout van de werkgever. Die dienen bij ontslag natuurlijk direct gerouleerd te worden. Ook had de werkgever er via haar management systeem op toe moeten zien dat data en code separaat worden opgeslagen en de data alleen toegankelijk is voor het service account waaronder het script draait. Hiermee voorkom je dat medewerkers überhaupt (per ongeluk) data kunnen kopiëren.

Tot slot, als deze medewerker zo in en in slecht is dat hij/zij opzettelijk deze gegevens heeft gelekt, dan was dit niet via een op de persoon terug te herleiden Git repository gedaan.

[Verwijderd]

Mja. Dat zou je verwachten. Maar de praktijk is vaak weerbarstiger. Dat de vraag of er nog code is wat afgestaan moet worden bij het vertrek van een medewerker zelden tot nooit gesteld wordt. Dat het contractueel is vastgelegd is naar mijn mening een juridische formaliteit wat afgedicht is. Maar uiteindelijk weinig praktische invulling aan gegeven wordt. Dus uiteindelijk komt het nog steeds neer op de welwillendheid van de medewerker.

[Raymond Deen]

Niet helemaal vergelijkbaar met werken als consultant op projectbasis, maar ik doe het toch: daar heb ik tot nu toe, een paar uitzonderingen daar gelaten, elke keer aan het eind een formele overdracht gedaan waarbij ik in een paar gevallen broncode live van m’n systeem heb verwijderd.
Is niets raars of vervelends aan, gewoon iets dat er óók bij hoort net als inwerken.

[CH4OS]

In praktisch elk standaard arbeidsovereenkomst geeft de werknemer het eigendom/een exclusieve licentie van wat je produceert aan de werkgever.

Nee hoor, ik heb dat in elk geval nooit gehad en toch werk ik in de IT, terwijl ik wel de nodige werkgevers heb gehad de afgelopen jaren (tussen 2015 en nu, dus ook niet eventjes of zo).

[Reactie gewijzigd door CH4OS op 23 juli 2024 09:29]

[Cyberpuppy]

Dat hoeft een werkgever ook niet expliciet te vermelden. Bij wet is je werkgever eigenaar van alles wat je produceert. Als het in een overeenkomst staat dan is dat vaak om het belang van die regel nog eens extra te onderstrepen.

[Iblies]

Dat ligt er ook weer aan ,
heel dit topic wordt giswerk 😄

Zelfs heb ik ouderwetse macro’s in excel die ik zelf maar ook andere gebruiken, staat ook netjes mijn naam in hoekje dat het van mij is en er verder geen rechten aan kunnen worden ontleent 😋

Sorteren en juiste gegevens uithalen gaat dan met wat sneller en specifieke software daarvoor bestaat ook niet.


Dat stukje code heeft niks met mij werk inhoudelijk te maken maar is gewoon handig, maar omgerekend scheelt het wel een minuutje of 10 per dag, x8 collega’s en dan ook nog eens x250 dagen.

Dat stukje code is van mij. Als ik vandaag stop zet ik er een wachtwoord op en kan verder er niemand iets mee.

[GeroldM]

Dat jij er je naam onder zet, dat is leuk voor je. En misschien is je werkgever de beroerdste niet en wil dat iedereen in het bedrijf weet dat jij de auteur bent.

Of je werkgever is de beroerdste wel, en wil dat iedereen weet dat jij de verantwoordelijke bent. Maar als jij een wachtwoord of versleuteling toepast net voordat je je werk opzegt, dan heb je toch echt een probleem.

En kan je legaal gezien echt wel in de problemen komen als je dit stuk code wil hergebruiken bij een andere werkgever. Na de versleuteling kan je voormalig werkgever ook referenties van jouw kunst- en vliegwerk weigeren om te geven, aangezien jij hen nu geld hebt gekost.

Zoals je al aangaf, meerdere collegas maken er gebruik van, dus je bederft hun werkdag. Als jij denkt dat dit niet leidt tot klachten over jouw functionere en/of jouw persoon over een stuk code dat jij hebt geproduceerd met kennis waar je werkgever voor heeft betaald in werktijd...

Veel succes met het versleutelen. Laten we hopen dat het je niet alteveel kost.

[Iblies]

Gelukkig ben ik niet de enigste die er zo over denk 🙂

https://blog.iusmentis.co...-excel-model-aan-ze-geef/

Toch denk ik wel dat de werkgever kan eisen dat hij een kopie krijgt van de tool. Niet perse in eigendom, eerder in licentie dus. Dit omdat de tool wordt ingezet voor het werk, en daarmee een afhankelijkheid ontstaat tussen werkgever en werknemer over de manier waarop het werk wordt uitgevoerd.

Als die het echt nodig heeft kan die er voor betalen, het is wat waard namelijk 🙂 Heb er niet voor niets een ruwe schatting neergezet wat het ongeveer oplevert.
Ik zou ook naar rato 80 minuten extra pauze kunnen nemen per dag 😬

[Cyberpuppy]

Het blog wat jij aanhaalt gaat specifiek over code die al bestaat voordat je werknemer werd. Hier is niks specifieks voor geregeld in de wet.

En dan vraag ik mij af of er nooit meer iets aan de code gewijzigd is in de tijd dat je voor de werkgever aan het werk was, want dan wordt het nog ingewikkelder.

En verder wat Arnoud ook al schrijft in het blog. Je zult er samen met de werkgever uit moeten komen.

[comecme]

Dat hoeft toch helemaal niet in het contract te staan. Standaard is de werkgever eigenaar van de code. Nou staat daar wel bij:

Indien de broncode wordt gemaakt door een werknemer in uitoefening van zijn functie en waartoe hij opdracht heeft gekregen van de werkgever, dan wordt de werkgever geacht eigenaar te zijn.

Dat maakt het interessant. Als je als werknemer op eigen initiatief een script schrijft om iets te automatiseren, wie is daarvan dan de eigenaar?

En als je in een scrumteam code schrijft, in hoeverre is de werkgever dan de opdrachtgever? Het is niet zo dat je baas je expliciet opdracht geeft bepaalde software te schrijven, dat bepaalt de product owner in overleg met het team. Of vertegenwoordigt dan de product owner de "werkgever"?

[Verwijderd]

Dan is de redenering nog steeds vrij simpel. Ook al heeft de werkgever daar geen opdracht toe gegeven, maak je wel de code gedurende werktijd. Dus is de werkgever eigenaar van de code.

[Cyberpuppy]

Er staat niet dat het een "expliciete" opdracht moet zijn. Dus een impliciete opdracht mag hier denk ik ook onder vallen. Oftewel een scriptje maken is onderdeel van je werk als systeembeheerder.

[GeroldM]

Behalve als hij/zij in dat laatste geval de eigenaar van de code was en dat gewoon mocht delen. Dan is het niet ontdoen van persoonsgegevens net zo goed een slordig ongeluk.

In de meeste contracten staat toch dat software die in de tijd van de baas wordt gemaakt, software van de baas is. En meestal staat er ook in dat deze niet zonder instemming van dezelfde baas mag worden gedeeld, of dat er thuis aan verder gewerkt mag worden.

En als het software van de baas is en deze wil dat jij er thuis verder aan kan werken, dan dient deze een veilige omgeving en/of apparatuur aan de maker te verstrekken. Lijken me standaard regels waarmee beide partijen zich lagaal indekken.

Je kan er vrij zeker van zijn dat deze medewerker is ontslagen, nadat de oorzaak in het rapport is benoemd. Het Radbout UMC kan het zich veroorloven om een GitLab instantie op te zetten. Dit soort informatie hoort simpelweg niet thuis op een publieke site als GitHub. En als GitLab je niet aanstaat, er zijn nog een paar van dat soort code-hosting projecten meer. Zowel gratis als betaald.

[Skit3000]

GitHub is een prima oplossing voor bedrijven. Ik kan uit de berichten niet opmaken of de werknemer de code er voor of na ontslag op heeft geplaatst, maar als het voor ontslag was kan ik me legio manieren bedenken waarop dit mis heeft kunnen gaan.

Overigens kan ik uit het eerdere bericht hierover opmaken dat de gelekte data van een Active Directory (achtige) listing gaat, aangezien er alleen namen, telefoonnummers en e-mailadressen van medewerkers zijn gelekt. Deze gegevens zijn sowieso natuurlijk al semi-openbaar en ik denk niet dat dit de privacy van medewerkers raakt zolang het om zakelijke adressen en nummers gaat. Daarnaast kan elke medewerker met een email client waarschijnlijk exact diezelfde lijst opvragen.

Hoe een cryptominer hier uiteindelijk misbruik van heeft gemaakt zonder dat deze in de buurt is geweest van bedrijfsapplicaties is voor mij wel nog een heel groot vraagteken.

[softinc]

Tja, ik denk dat je daar wel een punt hebt. Lijkt mij ook zeer onwaarschijnlijk dat de data die de oud werknemer op Github heeft geplaatst nog actueel was. Ik denk dat we de oorzaak moeten zoeken in het gebrek aan mankracht en te oude apparatuur die niet meer gepatched was of niet meer geupdate kon worden.

[vinkjb]

Wraak? omdat die misschien daarvoor ontslagen is..blijft maar gissen natuurlijk

[Tintel]

Of gewoon vergissing?

En dan wordt hij/zij vervolgens aangeklaagd; shaming and blaming - altijd fijn...

Maar goed - indien wel opzettelijk dan is aanklagen logisch. Echter gezien het om gedeelde scripts ging op github acht ik dat niet zo aannemelijk.

[closefuture]

En dan wordt hij/zij vervolgens aangeklaagd; shaming and blaming - altijd fijn...

Waar haal jij vandaan dat de persoon aangeklaagd word? Er staat dat er melding gedaan is bij de authoriteit persoons gegevens. Iets wat moet bij een dergelijk datalek.

[Groningerkoek]

Er staat ook dat er aangifte is gedaan en dat de politie het nu in behandeling heeft.

[Tintel]

Uit het artikel:

Ook is aangifte gedaan tegen de veroorzaker van het datalek.

[Cobalt]

Staat gewoon in het artikel. In het artikel van het RadboudUMC staat dat het ging om cryptovaluta te genereren (‘minen’) op het netwerk van het RadboudUMC en dat daar aangifte van is gedaan.

[Reactie gewijzigd door Cobalt op 23 juli 2024 09:29]

[T-men]

Nee, je gooit 2 dingen op een hoop:

• Een (oud-)medewerker deelt bestanden
• De gelekte bestanden daadwerkelijk gedownload door derden
• Er is door een derde een cryptominer geïnstalleerd

Nergens in het artikel blijkt de (oud-)medewerker zélf de intentie gehad te hebben dat er een cryptominer geïnstalleerd zou worden.

Ja, het kán wraak zijn en het kán dommigheid zijn, maar dat is speculeren en dat heeft geen zin, want we we kennen niet alle kanten van het verhaal.

[Dutch_CroniC]

Ja dat blijft het altijd, maar wat ik dan weer vreemd vind, is dat er in de laatste zin ineens gesproken wordt over een cryptominer. Dus hij zal n.a.v. zijn actie wel ontslagen zijn denk ik.

[Groningerkoek]

Eerder in het artikel staat duidelijk dat er ook iemand is geweest die de gegevens heeft misbruikt om het Radboud system in te zetten om te minen voor hem.

[aikebah]

Eerder in het artikel staat duidelijk dat er ook iemand is geweest die de gegevens heeft misbruikt om het Radboud system in te zetten om te minen voor hem.

FTFY... beter lezen dus

[Leukhe1]

Och, het blijft gissen. Maar wellicht was die werknemer daar gewoon niet op de juiste plek.

Kwam b.v. uit een open omgeving, maar niet gewend aan een omgeving waar beveiliging veel belangrijker was. En juist in dat staartje een foutje gemaakt. Waar gehakt wordt vallen spaanders. Wil de aangifte tegen de medewerker lukken dan moet je opzet ofzo (!) aantonen. En medewerker had gewoon recht op werken met die gegevens(toch?)

[biteMark]

Er even vanuit gaande dat de our-medewerker die gegevens niet bewust heeft gelekt vind ik het nogal wat om aangifte tegen hem/haar te doen.

[stefanass]

Als met hetgeen openbaar op github is gezet het mogelijk is om op servers van het ziekenhuis te komen en die zelfs - naast de persoonsgegevens die er blijkbaar in stonden - gebruikt kon worden om de servers te misbruiken om crypto te minen dan vind ik aangifte wel terecht. Als je zaken publiceert, zeker als het een ziekenhuis betreft dan moet je gewoon 3x nadenken en controles doen.

[biteMark]

Dat ben ik niet met je eens. Als de processen in het ziekenhuis zodanig zijn ingericht dat één iemand verantwoordelijk is voor het publiceren van gegevens waar mogelijk persoonlijke data in staat, dan is het ziekenhuis op zijn minst medeverantwoordelijk voor eventuele fouten.

Verder vind ik dat zulke fouten intern opgelost moeten worden - al dan niet door sancties of ontslag. Ontslag om een dergelijke reden heeft al een zodanige impact dat ik niet vind dat een rechtszaak dan nog zin heeft, daarmee kan je iemand die al gestraft is echt kapot maken terwijl er geen enkele intentie was.

Nogmaals, er vanuit gaande dat er geen intentie was.