Universiteit Leiden meldt ransomwareaanval op intern bedrijf JobMotion

Het salarisverwerkingssysteem van JobMotion van de Universiteit Leiden is getroffen door een ransomwareaanval. Daarbij zijn mogelijk 'gevoelige gegevens' buitgemaakt. De universiteit heeft het incident gemeld bij de Autoriteit Persoonsgegevens.

Iedereen die via JobMotion bij de Universiteit Leiden in dienst is kan slachtoffer zijn geworden van de aanval, aldus de onderwijsinstelling. Het is niet bekend hoeveel mensen er getroffen zijn en wat voor gegevens er precies buitgemaakt zijn; een 'gespecialiseerd cybercrimebedrijf' doet momenteel nog onderzoek naar het incident. Slachtoffers worden na het afronden van dit onderzoek ingelicht middels een e-mail. Wel laat het instituut weten dat er op basis van de voorlopige onderzoeksresultaten aanleiding is voor 'voorzichtig optimisme'.

Volgens de universiteit zijn er bij JobMotion zeer gevoelige gegevens bekend van alle werknemers. Onder meer bsn's en financiële gegevens zijn via het salarisverwerkingssysteem beschikbaar. Ook namen, woonplaatsen, telefoonnummers en factuurgegevens zijn mogelijk buitgemaakt bij de aanval. Het is niet duidelijk of er ook daadwerkelijk gegevens zijn buitgemaakt en of het bedrijf of de onderwijsinstelling losgeld heeft betaald aan de cybercriminelen.

JobMotion is het interne detacheringbureau van de betreffende universiteit. Tijdelijke arbeidskrachten werken voor dit aparte bedrijf en worden vervolgens gedetacheerd aan de Universiteit Leiden. Voor zover bekend is het daadwerkelijke betalingsverkeer niet door de cyberaanval gehinderd.

Door Yannick Spinner

Redacteur

19-12-2022 • 20:04

53

Submitter: Sir_Lion

Reacties (53)

Sorteer op:

Weergave:

Ik ben student aan Leiden univ en ben en paar keer bij een vak assistent geweest. Ik ben ook slachtoffer, en de e-mail die ik ontvangen heb is de volgende:

19 december 2022

Beste werknemer,

Op donderdag 8 december is JobMotion geïnformeerd door haar leverancier UBplus dat het salarisverwerkingssysteem mogelijk doelwit is geworden van een ransomware-aanval.

Doordat JobMotion hierdoor geen toegang had tot haar automatiseringssysteem, was het niet mogelijk om je te informeren met een persoonlijke mail. Om deze reden is er een bericht geplaatst op de website van de Universiteit Leiden en op de website van JobMotion. Gelukkig heeft de leverancier inmiddels het automatiseringssysteem weer vrijgegeven. Hierdoor kunnen wij je nu pas persoonlijk informeren en willen wij je een update geven.

Melding Autoriteit Persoonsgegevens

Het incident is door JobMotion gemeld als datalek bij de Autoriteit Persoonsgegevens. Direct na het ontdekken van het incident heeft de leverancier van het salarisverwerkingssysteem een gespecialiseerd cybercrimebedrijf ingehuurd. Zij zijn direct gestart met onderzoeks- en herstelwerkzaamheden.

Wat is er mogelijk gelekt?

Het salarissysteem bevat persoonsgegevens van iedereen die via JobMotion werkzaam is voor de Universiteit Leiden. Naast meer algemene (contact)gegevens bevat het ook gevoelige informatie zoals BSN en financiële gegevens.

Overzicht van mogelijk gelekte gegevens van flexwerkers:

Naam, adres, woonplaats, telefoonnummer, e-mailadres, administratienummer, geslacht, functie, geboortedatum en geboorteplaats, Burgerservicenummer, nationaliteit, verblijfsvergunning en werkvergunning, correspondentie met uitzendkrachten, uitzendovereenkomst (met verschillende bijlagen en addenda) inclusief fase indeling, financiële gegevens, bankrekeningnummer, salaris-afspraken, inhoudingen daarop en vergoedingen, loonafrekeningen, jaaropgaves, loonheffingsformulieren, handtekening, gegevens ziekmeldingen, burgerlijke staat, verlofgegevens, inloggegevens.

Huidige status

Op dit moment is de leverancier van JobMotion in een afrondende fase van het onderzoek. Het eindrapport wordt in de loop van volgende week verwacht. De informatie die we tot nu toe van de leverancier ontvangen hebben, geeft aanleiding tot voorzichtig optimisme. Maar de leverancier geeft ook aan dat het onderzoek nog niet definitief is. Op dit moment kunnen we dus nog niet uitsluiten dat data beschikbaar is gekomen voor derden. Daarom vragen wij je om alert te blijven op identiteitsfraude.

Uitbetaling salaris

Dankzij het meedenken van onze leverancier hebben wij deze week de salarissen op tijd en correct kunnen verwerken. Komende week zal er wederom een weekverloning plaatsvinden evenals de maandverloning. JobMotion is blij dat de ransomeware-aanval geen invloed heeft gehad op de loonuitbetaling.

Achterstand bij verwerken van nieuwe arbeidscontracten

Het systeem is meerdere dagen niet operationeel geweest. Op deze dagen is het niet mogelijk geweest om aanmeldingen met opdrachten van de Universiteit Leiden te verwerken en om nieuwe arbeidsovereenkomsten te maken. Dit betekent dat JobMotion een achterstand heeft opgelopen. Het hele team van JobMotion doet zijn uiterste best om de achterstand zo snel mogelijk in te halen.

Wat kun je zelf doen?

Lees hoe je identiteitsfraude kunt voorkomen en wat je moet doen als je er slachtoffer van bent geworden.

informatie van de politie over identiteitsfraude
informatie van de Rijksoverheid over identiteitsfraude

Verdere informatie

JobMotion staat in nauw contact met de leverancier en de Universiteit Leiden over de verdere afwikkeling en de uitkomsten van het onderzoek. Zodra het onderzoek is afgerond brengt JobMotion je per mail op de hoogte over de uitkomst hiervan.

Mocht je nog vragen hebben, dan kun je terecht bij de helpdesk van de Universiteit Leiden. Zij zijn bereikbaar via 071 - 527 88 88 (optie 4) of via helpdesk@issc.leidenuniv.nl.

Met hartelijke groet,
Team JobMotion
Update! Geen gegevens gelekt! 🎉

Nieuwe mail:

Beste werknemer,

In december maakten we bekend dat het salarisverwerkingssysteem van JobMotion mogelijk doelwit was geworden van een ransomware-aanval.

Uit forensisch onderzoek, dat direct na ontdekking van het incident werd uitgevoerd, blijkt dat daarbij geen persoonsgegevens zijn ontvreemd of ingezien.

Om een nieuwe aanval te voorkomen zijn er inmiddels extra preventieve maatregelen getroffen en er volgen meer beveiligingmaatregelen in de komende periode.

Edit: op de website van de uni een artikel dat er nog iets verder op ingaat:
https://www.student.unive...cd=ethics-and-politics-ma

[Reactie gewijzigd door t0mt0mg00 op 22 juli 2024 15:55]

Ik roep het nog maar een keer:
1 Waarom moet een leverancier/bedrijf al deze info hebben? Dat zou toch mooi met een eID koppeling opgelost kunnen worden?
2 Waarom moet je BSN een geheim zijn? Wanneer men met een private & public key systeem zou werken zou bij een lek de public key ingetrokken kunnen worden, maar blijft je private key geheim om je mee te identificeren voor de Belastingdienst etc. Vervolgens wordt er een nieuwe public key gegenereerd die gekoppeld is aan je private key.
3 Mensen waarvan oa het BSN is gelekt, zouden kosteloos geholpen moeten worden om hun gegevens te beschermen, oa door nieuwe paspoort/ID te verzorgen.

[Reactie gewijzigd door William_H op 22 juli 2024 15:55]

Ik roep het nog maar een keer:
1 Waarom moet een leverancier/bedrijf al deze info hebben? Dat zou toch mooi met een eID koppeling opgelost kunnen worden?
Die zaken moeten op een salarisstrook staan, dus heeft de leverancier die nodig.
De vraag is of dat echt nodig is. Vroeger hoefde dat ook niet om betaald te krijgen. Je zou geïdentificeerd kunnen worden met je banknummer (waarvoor je identiteit al bevestigd is door de bank, hoge graad van beveiliging) en nogmaals via iDIN / eID via je bank. Voor het afsluiten van abonnementen kan dit ook. Waarom niet voor een salarisbetaling.
En daarnaast, waarom heeft men bijv je geboortedatum nodig?

P.s.: ik stel deze vragen niet omdat ik er geen antwoord op kan verzinnen. Maar om te laten zien dat er totaal niet nagedacht / zuinig omgegaan wordt met het verzamelen van kwetsbare data.
De werkgever is verplicht je nationaliteit en identiteit te controleren, controleren of jij in Nederland mag werken. Verder een volledige kopie van je paspoort te hebben. En gegeven te hebben voor je salaris administratie / belasting aangift. En daar worden ze ook op gecontroleerd en voor verantwoordelijk gehouden.
Klopt maar dat is dan toch onzin? De belastingdienst weet welke bankrekening bij welke persoon hoort. ze weten zelf op 1 januari hoeveel geld er op staat hoeveel digitaal cash en je totaal bezit.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:55]

Alleen de meeste Nederlandse banken geven deze gegevens 1 keer per jaar door. Als je toevallig een bank uit een ander land uit de SEPA-regio hebt, wat tegenwoordig prima mogelijk is, worden deze gegevens niet doorgegeven.
Alleen de meeste Nederlandse banken geven deze gegevens 1 keer per jaar door. Als je toevallig een bank uit een ander land uit de SEPA-regio hebt, wat tegenwoordig prima mogelijk is, worden deze gegevens niet doorgegeven.
Dan privé toch maar eens naar een buitenlandse bank kijken.

[Reactie gewijzigd door xbeam op 22 juli 2024 15:55]

Nogmaals, men moet zich misschien eens afvragen of al die data wel nodig is. Lees mijn reactie hieronder over dataminimalisatie en of je wel zoveel gevoelige data moet willen opslaan.
En daarnaast, waarom heeft men bijv je geboortedatum nodig?
Omdat iemand van 16 niet full time mag werken, oudere werknemers meer vacantie hebben, wil je nog meer redenen?
Mathijs22 schreef:
Omdat iemand van 16 niet full time mag werken, oudere werknemers meer vacantie hebben, wil je nog meer redenen?
Zodra iemand 16 is of ouder kun je het boolean veld "isOuderDan16" op true zetten en de geboortedatum leegmaken.

Dat heet dataminimalisatie en wordt veel te weinig toegepast.
En op welke manier bewijs je dan dat dat veldje ook daadwerkelijk op "isOuderDan16" mag staan?

Dat kopie van je paspoort moeten ze nu eenmaal wel ergens opslaan. Maar je kunt wel kijken of je die in een aparte plek kunt opslaan waar minder mensen bij kunnen.
Wellicht is dat hier ook wel gedaan, maar als een hacker een admin account buitmaakt dat overal bij kan, dan helpt dat je ook niet. (bv account dat voor backups word gebruikt heeft meestal heel veel toegang)
mjtdevries schreef:
En op welke manier bewijs je dan dat dat veldje ook daadwerkelijk op "isOuderDan16" mag staan?
Want in een veld met een geboortedatum kan niet gelogen worden?

mjtdevries schreef:
Dat kopie van je paspoort moeten ze nu eenmaal wel ergens opslaan.
Mijn advies is om de verplichte (voor de werkgever) kopie van het paspoort bij aantreding (mag ondertussen verlopen zijn) op papier in een kluis te bewaren.

Ik hoef die kopie niet te kunnen zien in mijn cloud-account met loonstroken en dergelijke (ik pak het origineel wel als ik wil weten hoe het eruit ziet).

Ook de medewerkers van personeelszaken hoeven hier niet dagelijks naar te kijken.

Het verplaatsen van zoveel mogelijk vertrouwelijke gegevens die je niet dagelijks onmiddelijk echt nodig hebt (dus geen automatisch gegenereerde mails met "gefeliciteerd met jouw verjaardag, 45 lentes jong alweer!") naar lastiger toegankelijke of geheel offline storage kan flink helpen.

Als je online een lijst hebt met identifiers (bijv. recordnummers) van records die op een bepaalde datum aandacht vereisen (n jaar in dienst, pensionering) dan kun je volstaan met tijdelijk die records "naar boven" te halen. Als je dat goed dichttimmert valt er voor cybercriminelen veel minder te halen en kan de bedrijfsschade door ransomware worden beperkt.

Ten slotte is het m.i. onzin en zelfs hartstikke ongewenst dat admins overal bij zouden moeten kunnen.

Ik kan me herinneren (het was vóór 2004) dat collega's een Novell mailserver beheerden waarvan zij zeiden dat zij zelf niet in mails van ontvangers konden kijken (dat was voor mij als root op Unix en Linux geen probleem, maar uit principe deed ik dat niet).
Ga er maar gewoon vanuit dat er altijd een account is dat bij de data kan.
Een backup kan niet werken zonder dat de software bij je data kan om die backup te maken.

De enige bescherming daartegen is de data encrypten met een key die je alleen zelf hebt.
Maar dan kan ook niemand je helpen als je bv je key verliest.
Ik begrijp uit de reacties hier dat veel mensen het begrip eID en/of iDin niet snappen/geen kennis van hebben.
Zoals @Verwijderd aangeeft gaat mijn punt over dataminimalisatie. Niet over hoe veilig je iets opslaat.
eID kan de oplossing geven voor het feit dat er nu op veel plekken dezelfde (gevoelige) data opgeslagen is. Dit kun je minimaliseren door dataminimalisatie middels eID. Het eID geeft alleen toestemming aan verzoeken, checkt of de data klopt (dus bijv is deze persoon ouder dan 16), en voorkomt dat je een geboortedatum hoeft door te geven. Het eID is een vertrouwde partij (net als we hier op het internet met certificaten werken), en zorgt voor een trustnetwerk waardoor bedrijven en instellingen gewaarborgde en geverifieerde info krijgt met een hoge waarde. Let op, dit is niet het zelfde als een sociaal puntenstelsel, maar meer als een blockchain of certificatensysteem. Dataverzoeken worden gecheckt en gevalideerd. Maar er wordt geen tot veel minder data verzonden en opgeslagen.
Beetje vergelijkbaar als de scanners bij de kassa die checkt of iemand oud genoeg is om drank te kopen. ID kaart wordt door lezer gehaald, die checkt geboortedatum maar verzend of geeft verder niks aan qua gevoelige data, maar geeft alleen Ja of Nee aan.

[Reactie gewijzigd door William_H op 22 juli 2024 15:55]

Of iets echt nodig is in het midden gelaten. Centraal geregistreerde informatie levert een situatie op waar enorm veel mensen bang voor zijn. Sinds corona heb je bergen mensen die bang zijn voor het sociale punten systeem.

Dus ja, los van alle nadelen van een public vs. Private key lijkt het me ook sociaal onwenselijk. En ja, liever 1 partij met privé gegevens ipv tientallen maar het vertrouwen in de overheid is niet zo hoog. Zowel in het opzetten van dit soort dingen alswel het niet misbruiken vd informatie
Er is nu juist enorm veel gevoelige data op meerdere plekken. Meer kans dat er een keer gelekt wordt. In mijn idee, liever 1 plek waar die dingen liggen met goed beveiliging / rules, dan op meerdere waar ik geen controle over heb (iets wat met eID / iDIN model wel kan)

Wat voor nadelen zie jij in een systeem van public vs private keys? Ik hoef zelf die private key niet te weten / hebben, als de Belastingdienst die maar naar voren kan toverenvoor hun administratie. Mij gaat het om die public key. Nu kan het BSN niet gewijzigd worden omdat je identiteit eraan vasthangt en er zoveel moet gebeuren om dat allemaal recht te breien mocht je dat wel willen dat het haast ondoenlijk is.
Grotendeels eens.

Ze mogen best wat data hebben, want ik wil ook mijn gegevens kunnen spreiden. Ik wil mijn adres en e-mail adres zelf overal kunnen opgeven en veranderen waar ik maar wil.

Maar mijn bankgevens en BSN kunnen best bij de uitgever blijven.

Beide kunnen een uniek ID krijgen per uitgever/gebruiker combi.

Jij noemt het eID, maar een electronic ID vindt ik veel te ver gaan. Ik wil alleen een unique pair hebben, die de aanbieder bijhoud. Dus mijn ene bank en ik hebben mijn bankrekeningnr. Ik geeft deze eenmalig in bij mijn werkgever ter controle. Vervolgens maken zij bij de bank een uniek ID aan die ze voortaan gebruiken en gooien m'n rekeningnr weg. Mocht er ooit misbruik zijn, of een lek, hoeft alleen dat ene ID bij de bank gelocked te worden.

Datzelfde geld voor een BSN bij de overheid ook.

En dat hoeft zeker niet centraal in een eID! Sterker nog, liever niet om meerdere redenen.
Of net zo al een tijdelijke mail. Creëren voor keer dat je nodig hebt met de DigiD app een unieke string waarvan de belastingdienst weet dat aan jouw vanuit jouw BSN gecreëerd is die je dan opgeeft en dus bij een lek ook direct ongeldig gemaakt kan worden zonder dat impact op andere diensten / koppeling heeft.
Ik denk dat je het eID verward met het elektronisch paspoort. Feitelijk is DigiD de NL implementatie van eID. Gaat over elektronisch identificeren middels een token (paspoort/ID/DigiD), en niet over het recente voorstel van elektronische paspoorten.
Omdat NL al het DigiD had, kent men helaas het begrip eID slecht tot niet, en nu is er ook nog dat verwarrende andere voorstel wat sterk lijkt op het sociaal puntenstelsel uit China, maar die twee hebben dus niks nada met elkaar te maken. De één bestaat al en maken we al gebruik van (alleen nog niet op de beste manier) en het ander moet je inderdaad niet willen.
William_H schreef onder meer:
2 Waarom moet je BSN een geheim zijn?
Een BSN zou zo geheim mogelijk moeten zijn als het (vergelijkbaarbaar met een wachtwoord) als betrouwbaar authenticatiemiddel zou kunnen worden gebruikt. Maar dat kan helemaal niet om twee redenen:
a) Veel te veel organisaties moeten jouw BSN gebruiken en slaan het plain-text op;
b) De entropie ervan is véél te laag om het, middels een cryptografische hash of zelfs KDF (Key Derivation Function) veilig op te slaan.

De lage entropie maakt BSN's ook ongeschikt als basis voor pseudoniemen (die de privacy van betrokkenen ten goede zou kunnen komen).

Een BSN is niets meer en niets minder dan een (in NL) unieke identifier. Het kennen van een BSN (of het kunnen opsturen van een scan van een identiteitsbewijs) is géén betrouwbare authenticatie; dit is zeer fraudegevoelig. Helaas wordt dit wel gebruikt in de praktijk.
Wanneer men met een private & public key systeem zou werken zou bij een lek de public key ingetrokken kunnen worden, maar blijft je private key geheim om je mee te identificeren voor de Belastingdienst etc. Vervolgens wordt er een nieuwe public key gegenereerd die gekoppeld is aan je private key.
Ik sluit niet uit dat er bijzondere asymmetrische cryptografie bestaat waarbij je een private key kunt behouden en een nieuwe bijpassende public key kunt genereren (heel zinvol lijkt mij dat overigens niet, mede omdat "intrekken" in de praktijk vaak onbetrouwbaar is).

Bij de gangbare asymmetrische cryptografie is echter sprake van sleutelparen, waarbij je niet één van de sleutels eenvoudig kunt vervangen (misschien heb je iets aan deze uitleg in het kader van passkeys).

Identificatie en authenticatie zijn totaal verschillende zaken. Om te voorkomen dat een ander onzin bralt op jouw tweakers.net account is het in jouw eigen belang (i.v.m. jouw reputatie) dat je zorgt dat anderen niet eenvoudig als jou kunnen authenticeren (inloggen).

Op deze site ben jij de enige met identifier (niets geheims aan) William_H; daaraan herkennen (her in de zin van opnieuw) andere tweakers jou, zonder dat zij bijv. jouw e-mailadres kennen.

Dat jouw andere identificerende gegevens geheim kunnen blijven (zoals jouw e-mailadres) heeft niets met authenticatie te maken, maar met privacy.

Bij privacy zijn de eisen t.a.v. geheimhouding meestal veel lager dan bij authenticatie (online, op afstand, is dat effectief een "shared secret" of asymmetrische cryptografie zoals middels een passkey).

Een BSN is dus vergelijkbaar met een e-mailadres én met William_H op tweakers.net, met het verschil dat een BSN je hele leven aan jou gekoppeld blijft. De privacygevoeligheid van William_H en een losse BSN zijn minimaal, totdat daar aanvullende identificerende gegevens aan gekoppeld kunnen worden.

Als bij het lek bij JobMotion/UBplus persoonsgegevens in handen van cybercriminelen zijn gevallen, betekent dat zeker een privacyrisico voor de betrokkenen, maar ook kun je identiteitsfraude niet uitsluiten - omdat nog veel te veel organisaties identificatie met authenticatie verwarren.
Zelfs een geboortedatum wordt nog als identificatie gezien 8)7
Misschien moeten we inderdaad eens beter nadenken hoe we mensen veiliger identificeren in NL en daarbuiten.
Ik denk dat we om te beginnen moeten accepteren dat je online (op afstand) authenticatie nooit zo betrouwbaar krijgt als live (face to face) authenticatie - en dat is al niet waterdicht.

Naast dat probleem zie ik centraliseren en concentreren van veel persoonsgegevens ook niet als oplossing, want dat zijn honeypots voor cybercriminelen (van hoe meer personen er gegevens zijn opgeslagen en hoe actueler en in meer gevallen die gegevens correct zijn, hoe onevenredig veel meer die gegevens in potentie waard zijn op de zwarte markt).
Dat zou toch mooi met een eID koppeling opgelost kunnen worden?
Om vervolgens die gegevens bij de aanbieder van eID te hebben staan.. :+
Nee, die beheer je zelf.
Die aanbieder van de eID hoeft die gegevens helemaal niet te hebben. eID is namelijk hetzelfde systeem als wat men in NL kent als DigiD. Is er ooit een lek geweest bij de Belastingdienst / DigiD waardoor BSN nummers op straat lagen?
Maar wel op tientallen plekken moet jij die gegevens afgeven, en de overheid verwacht dat je het BSN geheim houdt. Hoe is dat mogelijk als de overheid ondertussen eist dat je die gegevens deelt...
Dat gaat dus niet samen.
3) Niet kostenloos, op kosten van het lekkende bedrijf, diens verzekering of als het te achterhalen is, de 'hacker.
Het lijkt de afgelopen tijd wel het ene na het andere incident. Ik vraag me af of de frequentie van de aanvallen inderdaad is toegenomen, of dat men sneller meldt nu men ziet dat anderen dat ook doen. Men zou eigenlijk net denken dat dit soort dingen afneemt door alle awareness van de laatste maanden.
Awareness is een eerste stap, maar op zich geen oplossing. Je kan mensen er elke dag op wijzen wat hun verantwoordelijkheden zijn en waar ze voor moeten oppassen, maar ook dat is geen garantie op succes.
Ransomware tools worden steeds meer toegankelijker dat leekjes dit nu ook kunnen doen, 'hacken' wordt steeds makkelijker voor de normale persoon en dus neemt de aan gerelateerde cyber criminaliteit ook toe. De algemene cyber criminaal van vandaag kan geen code in html schrijven, maar 'hacken' doet die wel. Alle voorgeschreven tools worden of verkocht en of kan men gewoon vinden op bepaalde fora (denk aan breached forum).
Awareness is training voor mensen. Die zijn en blijven de zwakste schakel in elk netwerk… ja het kan helpen, maar het is je allerlaatste linie van verdediging. Zorg ervoor dat alles vóór de gebruiker al op orde is. Microsegmentatie, role-based toegang, een incident responseplan, immutable backups, dat soort.

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 15:55]

[conspiracy]
de crypto-industrie moet z'n geld ergens vandaan blijven halen om al die arme investeerders te kunnen blijven terugbetalen }>
[/conspiracy]

Criminele organisaties hebben ingezien dat het een werkend businessmodel is (door publicaties van andere groepen), dus het zal waarschijnlijk meer gebeuren en als het gebeurt wordt er ook eerder over bericht, daarom dat je er exponentieel meer berichten over ziet.
Is vaak zo vlak voor de kerst, al veel mensen op vakantie dus men (malware gebruikers) hopen op verslapping/minder personeel aanwezig op IT afdelingen.
Ik kan helaas mijn bronnen niet vrijgeven. Maar ik zie zelf dat er een hoop bedrijven die nu getroffen worden maaaanden geleden al IOC's, indicators of compromise, hadden. Het lijkt er dus op dat de hackers bezig zijn om nog even snel uit te cashen op dit moment.

Ik wil niet gelijk iemand een belerend vingertje geven. Maar we zijn inmiddels de tijd voorbij dat een simpele firewall en anti-virus voldoende was. Tegenwoordig is een NGF, Next Generation Firewall, en SIEM/XDR on ontbeerlijk. Daarmee houd je meer buiten de deur. En mocht je gecomprimiteerd raken, dan weet je dat sneller. Waardoor je in veel gevallen de schade kunt beperken.
Helaas is iemand in mijn familie ook getroffen. De gegevens stonden blijkbaar 8 jaar na dienstverband nog steeds in het systeem.
Even opgezocht: bewaartermijn is 7 jaar na beëindiging dienstverband. Bron: https://autoriteitpersoon...kering/personeelsdossiers
Als dat écht klopt (van die 8 jaar) is dat dus een datalek wat ontdekt is door dit datalek.

(en ja, voor degene die dit niet wisten: te lang bewaren van gegevens heet ook een datalek)

[Reactie gewijzigd door Triblade_8472 op 22 juli 2024 15:55]

Ja plus de 7j die ik noemde, is niet voor alle gegevens. 7 jaar geldt alleen voor "gegevens uit de salarisadministratie die fiscaal van belang zijn."

Voor andere documenten is een andere bewaartermijn: "Loonbelastingverklaringen en een kopie van het identiteitsbewijs van de medewerker moet u 5 jaar na het einde van het dienstverband bewaren."

En bijvoorbeeld functioneringsgesprekken etc maximaal 2 jaar.
De meeste van die termijnen zijn minimale bewaartermijnen. Er zijn zelden maximale bewaartermijnen en bij persoonsgegevens geldt meestal dat je een valide reden moet kunnen geven om ze een bepaalde termijn te bewaren, maar staan er zelden exacte maximale termijnen in wet en regelgeving.

Bv wat jij beweert: functioneringsgespreken max 2 jaar klopt simpelweg niet.
Wat de AP aangeeft is dat het "over het algemeen" 2 jaar is. Maar dat is dus heel wat anders dan een wet die zegt dat het altijd max 2 jaar is.

Voor de salarisadministratie staat daar dat het minimaal 7 jaar bewaard moet worden. Dat betekent dus niet dat het ook automatisch maximaal 7 jaar is.

Voordat je mensen van te lang bewaren van data wilt beschuldigen moet je zelf eerst veel nauwkeuriger bekijken wat de regels precies zijn.
Nu ik de tekst opnieuw lees en met jouw blik probeer te bekijken, kun je het inderdaad ook zo interpreteren. Het staat er dan echter niet duidelijk beschreven.

Zo staat er bijvoorbeeld "Hoe lang MAG ik als werkgever de gegevens in een personeelsdossier bewaren?" en "Voor die gegevens geldt over het algemeen een bewaartermijn van 2 jaar nadat het dienstverband is beëindigd. Zijn de gegevens al eerder niet meer nodig? Dan moet u de gegevens direct verwijderen."

Beide impliceren dus, in mijn ogen, dat het wel degelijk om een maximum gaat.
Voordat je mensen van te lang bewaren van data wilt beschuldigen moet je zelf eerst veel nauwkeuriger bekijken wat de regels precies zijn.
Ten eerste beschuldig ik niemand. Ik zocht dit op uit nieuwsgierigheid en om er zelf wat van op te steken. Als ik het vervolgens verkeerd heb, word ik graag gecorrigeerd.

Ten tweede: doe eens aardig. Zo'n zure reactie naar mij is echt niet nodig.
Zeker wel, maar het is niet met een getal afgedekt, maar door woorden.

De seconde dat een minimaal termijn verloopt moet er een verdomd goede reden zijn om het nog te mogen bewaren. Anders moet het per direct worden verwijderd.

Een daarvan zou kunnen zijn: de beheerder van de gegevens heeft een begrafenis, de gegevens worden een paar dagen later verwijderd. Prima dan. Of er loopt een juridisch onderzoek naar deze persoon en we zijn door justitie gevraagd het allemaal te bewaren.

Maar bewaren omdat je geen idee hebt waar alles staat of simpelweg omdat je niet weet dat het weg moet is keifout.
Inderdaad door woorden afgedekt.
De woorden: Als het niet meer nodig is, dan moet het worden verwijderd.
Heel mooi principe, maar in de praktijk levert het allerlei discussies op wanneer iets echt niet meer nodig is en alleen nog nice-to-have. Dat is meestal niet zo zwart-wit.

En er zijn talloze redenen te bedenken waarom het ipv exact na 7 jaren bijna na 8 verwijderd word.
Het kan bv logisch zijn om het op het eind van het boekjaar te verwijderen ipv middenin een boekjaar, omdat er anders allerlei rapportages verziekt worden.
Of misschien staat het nog in je kwartaal en jaar-backups. Ook die tellen mee.

In de praktijk heeft de meeste software helemaal geen opties om in te stellen dat data exact 7 jaar na aanmaken van de data overal verwijderd word.
En dat vereist de AP ook niet, maar je moet er op een serieuze manier mee om gaan.

Dat data ergens nog na 8 jaar staat geef mij niet meteen een aanleiding om te denken dat er een datalek is vanwege te lang bewaren van data. Dat is veel te kort door de bocht.
Na 15 jaar is wat anders.
Wat ik heb gehoord van een student die daar (voor een enkele open dag) werkzaam was, is dat alle informatie is gelekt van de mensen die daar in welke hoedanigheid dan ook werkzaam zijn geweest. Van BSN tot adres en bankgegevens.

Maargoed, dat is van horen zeggen.
Het is niet duidelijk of er ook daadwerkelijk gegevens zijn buitgemaakt en of het bedrijf of de onderwijsinstelling losgeld heeft betaald aan de cybercriminelen.
Als ik het goed begrijp zijn de systemen van UBplus getroffen door ransomware, dus noch de universiteit of jobmotion zou het losgeld moeten betalen als er al sprake van is. Dit zou voor de rekening van UBplus moeten zijn. Wellicht kunnen ze nog om een bijdrage vragen?
Ja, leuk al die systemen tegenwoordig… en overheden willen encryptie maar omlaag brengen..

Lijkt steeds normaler te worden een datalek/databreach

Soms verlang ik toch echt weer naar de papieren tijd

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:55]

Bij ons is juist 2fa uitgerold. (Semi overheid) Super handig als je achter een barrière werkt en je dus geen mobiel of 2de aperaten bij je mag hebben vanwege ziekte insleep en hygiëne. :X

Daar hadden ze vanuit de hoofdvestiging niet aangedacht. Was overigens wel gelijk te zien wie er digibeet was. Want die hadden de waarschuwingsemails genegeerd en 2fa niet aangezet. En moesten de IT er dus bij halen 😅🙈🤣
Ik denk dat je raar op zou kijken als we terug gaan naar de papieren tijd. Dan kan je 1 keer in de maand het tweakers tijdschrift kopen, en kan je een brief schrijven om je mening te laten weten. Verder hebben we helemaal niet meer genoeg mensen om alles op papier te doen. We hebben nu al te weinig mensen om al het werk te doen. Als een groot deel daarvan ook nog papieren administratie moeten gaan doen loopt het helemaal vast.

Wij als ICTers moeten ervoor zorgen dat we de criminelen te slim af zijn. Dat is een veel realistischere optie.
Ik denk dat je raar op zou kijken als we terug gaan naar de papieren tijd.
Zeker omdat veel tweakers het bestaan van een telefoonboek niet meer lijken te kennen. Een dik boek met daarin de volledige naam, telefoonnummer and adres van vrijwel iedereen. En dat kreeg iedereen gratis thuis!
Aan de andere kant kunnen we wel beter een boek lezen dan kattenfilmpjes kijken. Beter voor je ontwikkeling en rust, lager energieverbruik, en minder kans op ransomware ;)
ransomware is meestal random geadresseerd.... Ze zoeken de hele dag af naar iets dat zinvol is. En als blijkt dat er toch gevoelige gegevens bij zitten nou win win.
Ik denk dat dit ook een verdienmodel is voor beide kanten.
Voor de ''hackers'' als voor de gedupeerde. Die krijgen dan opeens wel een stapel met geld om het te beveiligen.

De hackers die op grootschalige manier binnenkomen, zijn toch wel vaak de hackers die niks buit maken als je betaald hebt.

Op dit item kan niet meer gereageerd worden.