Ransomware bij salarisverwerker legt mogelijk betalingen salaris plat

Het Canadese bedrijf UKG heeft last van ransomware bij zijn salarisverwerkingssoftware Kronos Private Cloud. Daardoor kunnen veel bedrijven en organisaties wellicht geen salarissen uitbetalen. De ransomware heeft ook een datacenter in Amsterdam getroffen.

De getroffen datacenters van UKG staan in de VS, in de Duitse stad Frankfurt en in Amsterdam. UKG zegt het datalek te hebben gemeld bij de Gegevensbeschermingsautoriteit in België. Het bedrijf vermoedt dat er geen link is met de Log4Shell-kwetsbaarheid, maar weet dat niet zeker.

Het is onbekend van hoeveel mensen het salaris niet kan worden gestort. Volgens The Verge zijn onder meer Tesla, Gamestop en Honda klant van UKG. UKG maakt software voor urenregistratie en salarisbetalingen. Klanten kunnen afhankelijk zijn van de servers van UKG, waardoor de ransomware misschien dus ook klanten van UKG treft. Het is onbekend of en hoeveel gebruikers in de Benelux getroffen zijn. Het gaat onder meer om de toepassingen Workplace Central en Telestaff.

Door Arnoud Wokke

Redacteur

16-12-2021 • 10:08

80 Linkedin

Submitter: myfmv

Reacties (80)

Wijzig sortering
Uit ervaring -hoe raar het ook klinkt- is voor salarisverwerkers beveiliging nooit een top prioriteit, omdat ze daar geen geld mee verdienen. Ik heb eerder dit jaar bij een Nederlandse salarissoftware een lek ontdekt waarmee je van al je collega's alle data kon ophalen (loonstroken, bsn, adresgegevens, etc.). Lek was gelukkig binnen een dag opgelost, maar 0 communicatie naar hun klanten toe.
Daar is men wettelijk (AVG) meldingsplichtig aan de AP en alle betrokkenen. Je doet er verstandig aan dit te melden bij de AP, omdat dit een heel serieus datalek is en men het blijkbaar niet gemeld heeft (als betrokkene hadden ze het jou moeten vertellen!)....

[Reactie gewijzigd door J_van_Ekris op 16 december 2021 10:38]

Hoe zit dit precies? Toen wij bezig waren met de hypotheek, maakte de intermediair gebruik van een cloud-oplossing waarin alle document werden geüpload, zowel door ons als klant, als door de financieel adviseur. Ik heb hier destijds ook een lek in ontdekt; wanneer je inlogt, staat er een gebruikersnummer. Ik kon het nummer aanpassen en ik had ineens toegang tot de gegevens van iemand anders. Ik kon alle documenten inzien én downloaden, waaronder hypotheekaktes, paspoorten, bankafschriften, werkgeversverklaringen, loonstrookjes etc. alle benodigde papieren die nodig zijn voor een hypotheekaanvraag.

Ik heb het softwarebedrijf dat de software maakt gebeld en dit uitgelegd. Ze hebben het direct offline gehaald en het lek gedicht, maar ook hier was er 0 communicatie richting klanten. Ik heb hierna vervolgens nog gevraagd hoe het nou is opgelost, en ik kreeg onderstaande reactie (bedrijfsnaam weggelaten):

Geachte heer X,

Excuses dat u niet eerder bericht heeft ontvangen inzake de door u gedane melding.

Op 24 juli hebben wij er inderdaad voor gekozen om [dienst] offline te halen en het probleem op te lossen en deze is dan ook dezelfde dag nog verholpen.

Na het oplossen van het probleem hebben wij navraag gedaan of er misbruik is gemaakt van eventuele gegevens, dit bleek niet het geval te zijn.

Omdat het een klein incident betrof waar verder geen gegevens verloren zijn gegaan is het niet nodig een melding te maken bij de Autoriteit persoonsgegevens.

Ik hoop u hiermee voldoende te hebben geïnformeerd.

Mochten er nog vragen zijn kunt u mij bereiken op nummer: [tel.nummer]

[afzender]

Ik had toen al wel het gevoel dat ze zich er een beetje makkelijk vanaf maakten. Ik weet namelijk niet of er misbruik van is gemaakt, ik heb zelf namelijk meerdere accounts kunnen bekijken (gewoon om te kijken i.v.m. het lek, niet vanwege de gegevens). Ik heb bewust geen enkel document gedownload of er screenshots van gemaakt. Maarja...

[Reactie gewijzigd door 1992Mark op 16 december 2021 10:50]

Na het oplossen van het probleem hebben wij navraag gedaan of er misbruik is gemaakt van eventuele gegevens, dit bleek niet het geval te zijn.

Omdat het een klein incident betrof waar verder geen gegevens verloren zijn gegaan is het niet nodig een melding te maken bij de Autoriteit persoonsgegevens.
Ieder incident hoe klein ook moet gemeld worden binnen de 72u, zie https://autoriteitpersoon...ing/meldplicht-datalekken

"Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie, zonder dat dit de bedoeling is van deze organisatie."

Staat ook mooi gelijkaardig voorbeeld in volgend document: https://autoriteitpersoon...et_melden_datalek_def.pdf

"Een als gegevensverwerker optredend hostingbedrijf constateert een fout in de code voor de autorisatie van gebruikers. Het gevolg van de fout is dat elke gebruiker toegang kan krijgen tot de accountgegevens van elke andere gebruiker."

Kortom iemand jij had onrechtmatige toegang tot persoonsgegevens zonder dat dit de bedoeling was. Als ik jouw was zou ik zelf nog het datalek melden inclusief de email waarin ze met een smoesje er onderuit proberen te komen men overtreed hier gewoon de wet.

[Reactie gewijzigd door KeiFront op 16 december 2021 11:09]

Ieder incident hoe klein ook moet gemeld worden binnen de 72u, zie
Nee, dat is niet waar.
Als eerste gaat de AP alleen over datalekken waarbij persoonsgegevens betrokken zijn. (Dus als er beursgevoelige informatie van een bedrijf gelekt is, dan is dat geen zaak voor de AP)

Verder ben je alleen verplicht bij de AP te melden als de kans aanzienlijk is dat de betrokkenen er schade van ondervinden.

Die termijn van 72 uur klopt wel. En dat is inclusief avonden en weekenden.

[Reactie gewijzigd door mjtdevries op 16 december 2021 13:00]

Verder ben je alleen verplicht bij de AP te melden als de kans aanzienlijk is dat de betrokkenen er schade van ondervinden.
Dit klinkt heel subjectief, dan hoeft het bovenstaande bedrijf inderdaad niet te melden.
Het is inderdaad subjectief. Maar als je als bedrijf een afweging maakt waar de AP het achteraf niet mee eens is, dan kun je een hele dikke boete tegemoet zien. Dus zijn de meeste bedrijven daar best voorzichtig mee. (er zijn zelfs gemeentes die voor de zekerheid maar alles melden, ook als is er totaal geen sprake van schade voor de betrokkenen)

En als betrokkenen wel schade hebben ondervonden, dan gaan ze dat uiteraard bij de AP aankaarten. Dus het is niet zo dat de AP er nooit achter komt als je niks meld.

Daarnaast ben je wel wettelijk verplicht ELK datalek in je eigen register te documenteren. Hoe klein ook.
Dan snappen ze het duidelijk niet. Het gaat er helemaal niet om of er gegevens verloren zijn gegaan, het gaat erom of er gegevens zijn gelekt. De vraag is hoe ze erachter komen of gegevens wel of niet zijn gelekt, hebben ze logs wel goed geanalyseerd? Hebben ze wel goede logs, of loggen ze bijv. alleen requests zonder gebruikersnaam erbij (en kun je dus niet zien of een bepaald document wel/niet opgevraagd had mogen worden door die gebruiker)?

Ik zou sowieso melding maken. Dit voelt echt alsof ze het in de doofpot proberen te stoppen.
Dit klopt niet, dit zou zeker gemeld moeten worden. Als ik in jouw situatie zou zitten, zou ik het zelf melden.
Dat is niet correct van ze. Ik heb zelf ook al eens een melding moeten doen toen ik vorig jaar een server migreerde en de beveiliging voor het web-based adressenboek niet werkte. Gevolg: na 1 dag was het adressenboek geindexeerd door Google...

Onmiddellijk volgend op de eerste melding heb ik het probleem verholpen (10 minuten) en een re-index bij Google aangevraagd die na 24u het gewenste gevolg had geressorteerd. Toen met een bang hart een notificatie gedaan bij de BE Autoriteit Persoonsgegevens, en niets meer van gehoord. Het hielp vermoedelijk wel dat ik een exacte tijdslijn kon voorleggen, en dat het niet om zogenaamde 'gevoelige persoonsgegevens' ging.
Hoe zit dit precies?
Als je kijkt naar https://autoriteitpersoon...ing/meldplicht-datalekken dan zie je dat men zaken bij de AP en de betrokkenen moet melden als het een hoog risico is voor de betrokkenen. Als je in de geldende guideline kijkt (zie https://autoriteitpersoon...meldplicht_datalekken.pdf), dan zie je dat je bij een Ransomware aanval maar ook bij "het ontvangen van een rekeningoverzicht van een ander" gewoon een meldingsplicht is.

De AP meldt in die richtlijn over het moeten melden aan betrokkenen bij "De persoon heeft een maandoverzicht van iemand anders ontvangen." het volgende
De inbreuk wordt alleen meegedeeld aan de getroffen personen als er een hoog risico is en het duidelijk is dat anderen niet zijn getroffen.
Nu zijn de gegevens die een salarisverwerker verwerkt behoorlijk gevoelig. Salaris is dan je minste probleem omdat het ook gaat over je volledige namen, BSN, geboortedatum etc..En dat zijn zaken waarmee je voor veel serieuze diensten je geidentificeerd wordt. Dus je zit al heel snel in de hoog-risico categorie.

En er is op basis van jouw beschrijving geen reden om aan te nemen dat een URL-rewrite of iets vergelijkbaars niet eerder door een ander is misbruikt om even al deze data van alle collega's op te halen. Maar de DPO zal wel in een goede bui zijn geweest....
kijkt (zie https://autoriteitpersoon...meldplicht_datalekken.pdf), dan zie je dat je bij een Ransomware aanval maar ook bij "het ontvangen van een rekeningoverzicht van een ander" gewoon een meldingsplicht is.
Dat is te kort door de bocht
In dat voorbeeld gaat het niet over één enkel rekeningoverzicht van een ander ontvangen. Het vervolgt met: de verwerkingsverantwoordelijke onderzoekt het en vermoed een systeemstoring. In dat geval kan het dus voor veel meer mensen mis gaan.
En als het over veel meer mensen gaat dan is dat een reden om het wel bij de AP te melden. En als je geen idee hebt over hoeveel, dan moet je natuurlijk van het ergste uit gaan.

Dan terug naar de zaak van 1992Mark en wat de AP hier gaan geeft.
In zijn situatie is het duidelijk dat niet 1 klant getroffen is, maar in principe alle klanten. Dat is een reden om aan de AP te melden.
Als zij in hun logs achter vast kunnen stellen dat de anderen niet getroffen zijn en kunnen vaststellen dat alleen 1992Mark zoiets heeft gedaan, dan zou het niet gemeld hoeven te woren. Of dat vast te stellen is kun je aan twijfelen.
Bij dat voorbeeld van de AP staat dat je de inbreuk aan de getroffenen moet melden als er een hoog risico is voor die betroffenen.
1992Mark heeft geen documenten gedownload. De vraag is of hij de inhoud op zijn scherm kon zien.
Als hij afbeelding van het scherm kon zien, dan kon hij een screenshot maken zonder te downloaden. Dan is er wel degelijk een hoog risico voor die betroffen.
Als hij alleen documenten met de naam paspoortx.jpg kon zien maar niet heeft gedownload of geopend dan is het risico uiteraard veel lager.
Hangt wederom af of ze zo nauwkeurig hebben gelogd wat mensen deden.

[Reactie gewijzigd door mjtdevries op 16 december 2021 13:31]

Ik kon ieder bestand openen, lezen en downloaden. Ik kon bankafschriften zien, met saldo's. Ik kon hypotheekaanvragen zien met bedragen, ik kon paspoorten zien met BSN-nummers. Ik kon loonstroken zien met salarissen, alles was inzichtelijk.

Maar zoals ik al zei, ik heb geen downloads uitgevoerd en geen screenshots gemaakt. die data interesseert mij niet. Het interesseert mij alleen wel dat wanneer iemand anders toegang heeft gehad, iemand fraude zou kunnen plegen met mijn gegevens. Gezien de gevoeligheid van de data, had ik wel verwacht dat er een melding gedaan zou moeten worden door de software-partij. Echter hebben zij dit niet gedaan, zoals in de mail is te lezen.

Dit gaat btw over juli 2020, niet over dit jaar. Ik weet niet of dit nu überhaupt nog gemeld kan worden? Ik zou het vervelend vinden als iemand (of ik) uiteindelijk de dupe wordt van het lek in deze software.
Het punt wat betreft de screenshots is dat je dat niet objectief kunt vaststellen. (lijkt me sterk dat jouw desktop/laptop daarop gemonitoord word)
En logs laten vaak een download wel zien, maar je moet al heel gedetailleerde logs hebben wil het ook melden of iets op het scherm is getoond.
En dan is het dus veel lastiger vast te stellen of naast jijzelf iemand anders ook dingen op het scherm getoond heeft gekregen.
Maar nogmaals, dat is afhankelijk van de software.
Het kan zijn dat de software partij het te makkelijk neemt en het had moeten melden. Maar je moet al precies weten wat ze hebben nagezocht en wat ze konden nazoeken om daar echt een uitspraak over te kunnen doen. In de reacties word al te makkelijk aangenomen dat een bedrijf daarin nalatig is.
Het klinkt misschien een beetje voorbarig, maar een fout in de software waardoor je je user-ID kunt wijzigen en direct toegang kunt krijgen tot andermans gegevens, is zo ver ik weet toch wel ''basic'' als in dat je borgt dat zoiets eenvoudigs als dit niet mogelijk is.

Daarnaast betwijfel ik of de partij überhaupt de gebruikers die ik heb kunnen inzien hebben geïnformeerd dat hun gegevens inzichtelijk zijn geweest.
Dit gaat btw over juli 2020, niet over dit jaar. Ik weet niet of dit nu überhaupt nog gemeld kan worden? Ik zou het vervelend vinden als iemand (of ik) uiteindelijk de dupe wordt van het lek in deze software.
Ik zou het melden, met wel de expliciete mededeling dat je dit in Juli 2020 hebt geconstateerd. Kan zijn dat ze het al hebben opgelost, maar dit soort zaken verjaren niet...
Maar zoals ik al zei, ik heb geen downloads uitgevoerd
Wat bedoel je? Als jouw browser een bestand heeft opgehaald om in de browser te tonen, dan heeft je computer het gedownload.

Als je een lijst met bestanden kon zien maar je hebt niet geprobeerd of je ze daadwerkelijk kon downloaden/inzien, dan zou het kunnen dat dat je ook niet gelukt zou zijn. Wellicht dat de call voor daadwerkelijk downloaden wél controleert of jij het bestand mag inzien.
Ik kon ze downloaden. Als je het bestand aanklikte werd het in-cloud geopend, daarbij kon ik het bestand downloaden als ik zou willen.
De AP meldt in die richtlijn over het moeten melden aan betrokkenen bij "De persoon heeft een maandoverzicht van iemand anders ontvangen." het volgende

"De inbreuk wordt alleen meegedeeld aan de getroffen personen als er een hoog risico is en het duidelijk is dat anderen niet zijn getroffen."
Huh? Alleen meedelen als anderen niet zijn getroffen? Dus als er ook anderen zijn getroffen hoef je het niet te melden?

[Reactie gewijzigd door comecme op 16 december 2021 20:15]

Huh? Alleen meedelen als anderen niet zijn getroffen? Dus als er ook anderen zijn getroffen hoef je het niet te melden?
Dit is Juriditalk. Alleen als het duidelijk is dat anderen niet zijn getroffen kun je volstaan met het informeren van de individuele personen. Als het niet duidelijk is, dan moet je iedereen informeren.
Simpele regel: Altijd zelf melden bij de AP.
- Is er een meldingsplicht, en het bedrijf doet het niet, dan lopen ze een keer tegen de lamp.
- Dossier opbouw. De rotte appels gaan veel meldingen krijgen en dat gaat bij de AP hopelijk opvallen.
Een beetje kort door de bocht om te stellen dat het een wettelijke plicht is om alle betrokkenen te informeren. Dat moet alleen wanneer het - eveneens kort door de bocht - waarschijnlijk ongunstige gevolgen voor hen heeft. Het is prima denkbaar dat deze situatie niet opgaat, bijvoorbeeld wanneer het lek niet heeft geleid tot het daadwerkelijk ophalen van data van betrokkenen.
mr94 zegt net zelf al data van zijn collegas te hebben bekeken...
En dus? De maatstaf voor het moeten informeren van betrokkenen is of betrokkenen er ongunstige gevolgen van ondervinden. Als mr94 de enige is die dit heeft ingezien zal dit waarschijnlijk geen ongunstige gevolgen hebben voor de betreffende collega's. Er zal dan waarschijnlijk ook geen meldingsplicht aan betrokkenen zijn.
Dat is wel erg kort dor de bocht. Het feit dat iemand melding maakt van een lek, wil niet zeggen dat anderen dat lek niet ook hebben ontdekt. Voor hetzelfde geld wordt zich nu ergens op het dark web een database aangeboden met alle gejatte gegevens. Het is om die reden dat de meldplicht bestaat.
Nog afgezien van het feit dat deze lakse manier van omgaan met een lek én ermee wegkomen, er ook voor zorgt dat veel bedrijven het nog steeds niet erg serieus nemen. Lekker goedkoop en lak aan de consequenties. Niet goed!
Je doet allerlei aannames die nergens op gebaseerd gaan.
Mr94 meldt dat hij ontdekte dat hij onbeperkt toegang had tot de gegevens van zijn collegas.
Als bedrijf ga je dan natuurlijk na hoeveel mensen die toegang nog meer hadden en of ze ook daadwerkelijk hebben gekeken.
Als je goede logging hebt, dan kom je wellicht tot de conclusie komen dat Mr94 de enige was die dat ontdekt heeft en dat de impact van het lek dus zeer beperkt is gebleven.

Als je echter totaal niet vast kun stellen in hoeverre mensen toegang hebben gehad en gebruikt, dan moet je het melden.

Het is dus compleet afhankelijk van wat het interne onderzoek heeft opgeleverd. Dat hoeven ze niet aan Mr94 te vertellen.
Het is dus compleet afhankelijk van wat het interne onderzoek heeft opgeleverd. Dat hoeven ze niet aan Mr94 te vertellen.
Mr94 heeft hier een dubbele rol die je vergeet: hij is niet alleen ontdekker maar zelf ook betrokkkene waarvan op vergelijkbare wijze zijn gegevens ingezien kunnen zijn. Voor dit soort zaken is de bewijslast ook omgedraaid: je moet kunnen aantonen dat er niets heeft kunnen gebeuren (want logging en alarmering) en anders MOET je aanemen dat je lek oneindig groot is (en krijg je een boete van de AP dat je logging onvoldoende is). Omdat je als betrokkene een datalek meldt waar je zelf ook mogelijk slachtoffer van kunt zijn mag je redelijkerwijs ook wel een geruststellende mail verwachten dat uit intern onderzoek bla bla bla. Immers als betrokkene moet je jouw risico's kunnen inschatten.
Mr94 zegt helemaal niet dat hem zelf niks verteld is.
Hij zegt dat de klanten niet geinformeerd zijn. Dat zijn twee totaal verschillende dingen.
Ik lees niet dat er wel iets gemeld is aan de AP, en dat is waar het om draait. Die verplichting bestaat. De simpele aanname dat niemand anders er iets mee heeft kunnen doen, volstaat niet.
Het is gewoon wel handig als een onafhankelijke autoriteit (en niet alleen betrokken partijen) kan bepalen of er vervolgacties gewenst zijn. Al was het maar om identieke situaties naast elkaar te kunnen zetten in plaats van dat iedereen z'n eigen toko probeert schoon te vegen.
Nogmaals "die verplichting bestaat" is onzin. Zoals in heel veel andere reacties al uitgelegd zit daar heel veel nuance in, en de informatie die we nu hebben is absoluut onvoldoende om enige uitspraak te doen of dit bedrijf het had moeten melden aan de AP of niet.

Dat je het niet eens bent met de wet of de AP is jammer voor jou, maar zo liggen de feiten nu eenmaal.
Je leest niet goed en weerlegt een volstrekt andere casus dan ik schetste. Ik zeg letterlijk: "Als mr94 de enige is die dit heeft ingezien ...". Hoe je daaruit concludeert dat ik zou hebben beweerd dat "Het feit dat iemand melding maakt van een lek" betekent dat "dat anderen dat lek niet ook hebben ontdekt" is mij echt een volstrekt raadsel.
"Je doet er verstandig aan dit te melden bij de AP"
Houdt er wel rekening mee dat je dan je baan kwijtraakt en ook niet snel meer een baan kan vinden, klokkenluiders worden niet gewaardeerd door een aantal.
Sorry, dit is onzin. Het afbreuk risico is enorm als er data uitlekt van klanten of als er door slechte beveiliging problemen ontstaan met betalen, loonaangifte.
Ik werk bij een internationale salarisverwerker (niet ADP) en beveiliging is echt top prio en integraal onderdeel van alles wat er ontwikkeld wordt, training, beheer, monitoring, pen tests.

Geen idee of dat bij een gemiddelde NL salarisverwerker ook zo streng is maar het is te algemeen zoals je het nu stelt.
Huh? Bedrijven zijn al zo'n beetje 3 jaar verplicht klanten te informeren bij lekken van persoonsgegevens.
Dit ligt iets genuanceerder.

https://autoriteitpersoon...e-betrokken-personen-7333

Hoeft dus niet altijd.
Maar hij geeft zelf al aan dat het hier om NAW-gegevens gaan, dan is 100% duidelijk dat dit aan de klant verteld moet worden.

Nuance is hier dus niet van toepassing.

[Reactie gewijzigd door MrFax op 16 december 2021 11:21]

Ga eens beter lezen op de site van de AP.
Nuance is altijd van toepassing.
De belangrijkste afweging is of het waarschijnlijk is dat het schade veroorzaakt aan betrokkenen.
NAW gegevens betekenen niet per definitie dat er schade is voor betrokkenen.
De belangrijkste afweging is of het waarschijnlijk is dat het schade veroorzaakt aan betrokkenen.
NAW gegevens betekenen niet per definitie dat er schade is voor betrokkenen.
BSN (want salarisadministratie) is bijna per definitie meldingsplichtig door haar extreem bijzondere juridische positie.

En de "waarschijnlijkheid van schade" slaat bij mijn weten op de gegevenssoort, dus of het waarschijnlijk is dat jij schade bij een lek van dat gegevenselement oploopt, en niet op de vraag of de hacker in kwestie er waarschijnlijk wat mee van plan is.

[Reactie gewijzigd door J_van_Ekris op 16 december 2021 14:12]

Waarschijnlijkheid van schade voor de betrokkenen in de breedste zin is de primaire afweging die de AP aangeeft voor het melden bij de AP.

Het soort data heeft daar uiteraard invloed op. Maar de hoeveelheid data heeft daar ook impact op. En of het gelekt is naar je eigen werknemers of naar een hacker heeft er uiteraard ook impact op.

zie de vraag: hoe beoordeel ik de risico's van een datalek op de volgende pagina:
https://autoriteitpersoon...meldplicht-datalekken#faq

[Reactie gewijzigd door mjtdevries op 16 december 2021 15:07]

Het soort data heeft daar uiteraard invloed op. Maar de hoeveelheid data heeft daar ook impact op. En of het gelekt is naar je eigen werknemers of naar een hacker heeft er uiteraard ook impact op.
Je beseft dat in de casus "Barbie" het ging om tientallen onterechte inzages van het EPD door medici die welliswaar wel geautoriseerd waren, maar geen aantoonbare directe behandelrelatie hadden (zie nieuws: Rechter verlaagt AVG-boete HagaZiekenhuis tot 350.000 euro)? Dus dat argument van "het zijn eigen medewerkers, die zijn te vertrouwen" ging in dit geval zeker niet op.
Binnen ICT kan je vrijwel altijd stellen dat zodra data openbaar beschikbaar was, je ervanuit kan gaan dat deze data gestolen en/of gelezen is door derde partijen die niet al beschikte over deze data. Dan is per definitie schade opgelopen en moeten klanten geinformeerd worden.

Het niet hoeven melden gaat eigenlijk alleen maar als het bijv. om gehashte emailadressen gaat, of wachtwoorden. Niet als iemand zijn of haar NAW-gegevens publiekelijk in te lezen waren door derden. Of als persoonsgegevens na een controle ingelezen zijn door een medewerker van bijv. een ziekenhuis die dat niet had mogen doen. Daar moet wel melding van gedaan worden, maar of de klant dat hoeft te weten?

[Reactie gewijzigd door MrFax op 16 december 2021 15:37]

Daar moet wel melding van gedaan worden, maar of de klant dat hoeft te weten?
Als jouw gegevens bij derden liggen dan ben je als verwerkingsverantwoordelijke dat verplicht te melden bij de betrokkene. Je komt niet weg met "We hebben je gehele werknemersdossier naar alle collega's gestuurd, inclusief de schoonmakers, maar we gaan er vanuit dat al je collega's te vertrouwen zijn en dus hoeven we het jou niet te vertellen waarom iedereen zo gniffelend om je heen loopt".
Wettelijk verplicht en en er daadwerkelijk op handelen zijn natuurlijk verschillende dingen.

Ik vraag me eigenlijk ook af hoeveel bedrijven er uberhaupt niet bewust van zijn dat er een meldplicht is. Veel bedrijven hebben al moeite met ICT, dus die zullen ook niet precies op de hoogte zijn wat alle regels omtrent ICT zijn of de juiste procedures ervoor opgesteld hebben.
Dan is het in mijn opzicht de sociale verantwoordelijkheid aan degene die het lek aan het bedrijf gemeld heeft, dit te melden aan de AP.
Misschien O.T., ik heb low level gratis software geïnstalleerd (Ransomwhere) die dit soort aanvallen moet voorkomen.
zo'n lek niet meegemaakt. Maar ik weet dat de api's van een aantal grote partijen van nederlandse pakketten in elk geval niet zijn gebouwd met privacy by design. Kon bv bij 1 pakket tot 10 jaar terug gegevens van mensen opvragen die al lang en breed uit dienst waren. Dat terwijl er geen overeenkomst was voor die periode om die gegevens in te zien...
Stel je voor dat ADP getroffen wordt, dan zit gelijk half NL zonder salaris. Je hoort er eigenlijk niemand over wat voor en of ze failsafes hebben voor dit soort situaties.
Ik vermoed (hoop) dat zij naar aanleiding van dit voorval nu ook wel direct inventariseren waar er eventueel verbeteringen doorgevoerd kunnen worden.
Je hoort er eigenlijk niemand over wat voor en of ze failsafes hebben voor dit soort situaties.
Ik heb altijd geroepen de salarisbetalingen van vorige maand te herhalen, en daarna op je gemak te gaan uitzoeken wat de echte schade is. Moet je natuurlijk wel bijhouden wat de salarisbetalingen van de vorige maand waren...
Loonzakjes gaan niet werken....
  • Je moet weten hoeveel salaris je in elk zakje moet stoppen
  • Hoeveel bonus
  • Wat doen de verlofsaldi ?
  • Je moet je boeken afsluiten voor het nieuwe jaar...
Ik vrees dat deze criminele hun ransom wel uitbetaald gaan krijgen. :'(
Salaris wat vorige maand betaald is nu ook uitbetalen. Verrekeningen komen later wel, maar dan zitten mensen niet meer op hete kolen en kan er rustig naar een manier gezocht worden om het probleem op te lossen.
Dan moet je wel bij je systemen kunnen om te zien wat er vorige maand uitbetaald is.
Je kunt nog altijd inloggen bij de bank, exportje draaien van die maand.
Ik snap je punt maar veel salarisverwerkers sturen bank file naar de klant die dan de betaling doet na goedkeuring.
Als verwerker kan je natuurlijk ook zelf betaling doen maar dan ben je weer afhankelijk van funding van de klant.
En andere optie is Treasury waar je alles naar een derde partij stuurt en die vervolgens betaling doen aan medewerkers na funding.

Dus even bank file exporteren is natuurlijk niet zo makkelijk. En bij grote partijen heb je natuurlijk disaster recovery & business continuity processen voor dit soort zaken aangezien het je core business is.

Zie ook bijv. dit over een payroll provider met on-site spul: https://en.wikipedia.org/...oil_storage_terminal_fire
On Sunday, 11 December 2005, a major explosion and fire at the Buncefield oil depot immediately adjacent to the NIS building, effectively destroyed the Hemel Hempstead Head office complex. The two managed services staff manning the Data Centre escaped unharmed. Other Hemel Hempstead based staff were told to report to offices in Oxford and Peterborough the following week. The share price dipped on the first trading day afterwards, but recovered by lunchtime. The company had a well-practised disaster recovery programme, and the company moved its Managed Services customer system backups (which were stored off-site) to run on systems based at a site in Hounslow, where a number of Northgate staff ran these during the next few months. This included a full managed network for hospitals in East Anglia. Despite this taking place in December, when payrolls are usually run earlier than normal, every payroll for all Northgate's customers was run on time. The company became known as one that had successfully passed through a major physical disaster, and CEO Chris Stone was invited to speak at various venues on commercial disaster recovery.
Natuurlijk iets anders dan ransomware...
Dit is pijnlijk, mede omdat werkgevers primair verantwoordelijk blijven voor het uitbetalen van salaris en er in veel landen strenge regels zijn m.b.t. niet op tijd uitbetalen van loon.

Disgruntled employees hebben hiermee een goede pijl op hun boog.
Dat is zeker zo, maar die wetten kunnen wel redelijk ruim zijn.
Als we naar Nederland kijken.
In het geval van een maandloon moet een werkgever wettelijk binnen een kwartaal na de periode uitbetaald hebben, dus dan zouden ze nog wel even hebben. (het moet sowieso in een arbeidsovereenkomst staan)

bron:
https://www.rijksoverheid...j-een-arbeidsovereenkomst
Uw werkgever moet uw loon op tijd betalen. De arbeidsovereenkomst regelt wanneer. Bij weekloon mag uitbetaling nooit langer duren dan een maand. Bij maandloon ligt de grens bij een kwartaal.
Uiteraard zie je dat dit is opgenomen in (collectieve) arbeidsovereenkomsten en dat je meestal rondom het begin van de laatste week of op een bepaalde dag van de betreffende maand krijgt uitbetaald.

Ik geloof ook direct dat er regelingen zijn dat bij overmacht een werkgever uitstel kan krijgen?
Ik geloof ook direct dat er regelingen zijn dat bij overmacht een werkgever uitstel kan krijgen?
Ik weet niet of uitbesteding van het werk aan een falende externe partij gezien kan worden als overmacht, omdat de verantwoording en aansprakelijkheid blijft liggen bij de werkgever. Het is natuurlijk wat anders als de werkgever zelf geraakt wordt door ransonware, en ook dan kan gekeken worden of de werkgever het redelijke en billijke heeft gedaan om het te voorkomen. Zo niet, dan is het nalatigheid en kan er niet gesproken worden van overmacht.

[Reactie gewijzigd door The Zep Man op 16 december 2021 16:45]

Ik weet niet of uitbesteding van het werk aan een falende externe partij gezien kan worden als overmacht....
Dat is denk ik inderdaad mogelijk een goede vraag in deze context.

Het betreffende bedrijf bestaat pas pakkembeet ruim anderhalf jaar, maar is wel een fusiebedrijf van twee zeer ervaren financiële dienstverleners. Het heeft 12.000 werknemers. Het is dus niet een één of ander zolderkamerbedrijfje waar je je HR-zaken door laat regelen.

Maar, uiteraard heeft de werkgever een directe verantwoordelijkheid voor alles wat zij doen, maar ik denk dat als een bedrijf duidelijk zeer zorgvuldig haar toeleveranciers en dienstverleners kiest, met een historisch goede namen (geen garantie voor de toekomst, maar je moet je keuzes ergens op baseren), voor fundamentele zaken, dat bij een incident van die toeleveranciers dat je dat wel onder overmacht kan schalen, maar allicht dat onze wetgever(s) daar anders over denken.

Ik kan me voorstellen dat als de werkgever de HR-taken had uitbesteed aan "HR-cheap-are-us" met 3 werknemers in de garage van ome Jan, dat, dat dan anders is....
Dat kwartaal slaat op de standaard uitbetaling, je krijgt wel elke maand je loon, alleen met een vertraging. Het is niet zo dat als na 2 maanden is afgesproken, het ineens een keer 3 maanden mag worden (om welke reden dan ook). Als er dan vertraging is, dan komt de 5%/dag regeling in werking die iets verderop in de tekst uit de link staat. De werkgever heeft bij problemen met uitbetalen dus 4 dagen de tijd om iets te regelen voordat de boeteteller gaat lopen, in 4 dagen moet wel iets handmatig te regelen zijn.
De timing is perfect, vlak voor de uitbetaling van de salarissen voor kerst, inclusief eindejaarsbonussen enzo. Dat zal de bereidwilligheid tot betalen waarschijnlijk wel vergroten, hoewel ik natuurlijk hoop dat ze dat niet doen :X
Dit treft het management in de portemonnee en die zijn daar heel gevoelig voor. Super goed gepland inderdaad!
Nu doe je alsof dit soort dingen alleen voor management gelden, maar zeker in de VS is een beloning krijgen afhankelijk van je prestaties een stuk normaler. Dat gejammer op 'management boeit alleen wat management raakt en verder mag iedereen verhongeren', als dat echt de cultuur bij je bedrijf is zou ik zeggen: ga daar weg en ga naar de duizenden bedrijven die die cultuur niet hebben (in NL tenminste, in de VS is de werkcultuur een stuk meer verrot)
Ik zeg nergens dat dit alleen management treft. Dat vul je zelf in.

Maar gezien de rest van je reactie gok ik (en nu ga ik invullen) dat je manager bent (geweest?) en dat dit verwijt soms/vaak voorbij kwam en dus gevoelig ligt? Ik bedoelde het niet zo in ieder geval.
En uitbetalen is natuurlijk hun core business :+
Timing is inderdaad goed. Je kan echter natuurlijk wel werken met voorschotten op basis van salarissen van de maand ervoor. Maar goed eindejaars bonussen e.d. zijn inderdaad wat de timing goed maakt.
Maar zo eenvoudig is het natuurlijk niet. Alles hangt aan elkaar vandaag de dag. De berekening gebeurd door de systemen die, na goedkeuring, ook de opdrachten genereren aan de banken om de bedragen door te storten. Je kan dus niet zomaar zeggen: geef iedereen 75% van wat ze vorige maand hebben gehad als voorschot. Zo een opdracht kan je niet zomaar geven en zelfs als je het doet moet je het achteraf ook weer allemaal verwerkt krijgen in al je systemen. Bijkomend bestaat er dan geen paper trail voor die betalingen (geen loonstrookjes) dus betaal je mogelijks in het zwart uit.
Je kan dus niet zomaar zeggen: geef iedereen 75% van wat ze vorige maand hebben gehad als voorschot. Zo een opdracht kan je niet zomaar geven en zelfs als je het doet moet je het achteraf ook weer allemaal verwerkt krijgen in al je systemen
Hoezo zou dat niet kunnen? Ik heb wel eens twee keer mijn salaris gehad, bankopdracht ging verkeerd (dubbel), salarisstrook gaf echt geen dubbele salaris aan ofzo. Dat was een flink gedoe voor de salarisadministratie (elke medewerker werd dubbel betaald), echter tja, ach, gebeurd niet elke maand ofzo.
Bijkomend bestaat er dan geen paper trail voor die betalingen (geen loonstrookjes) dus betaal je mogelijks in het zwart uit.
Als je dat overmaakt via een rekening dan heb je juist wel een overzicht hiervan. Als bedrijf neem je wel een behoorlijk risico, terughalen van teveel betaalde bedragen (salaris) is bij sommige banken niet makkelijk. Verder zijn er altijd veranderingen, je zal waarschijnlijk een aantal personen betalen die het bedrijf verlaten hebben.

Toch, doe je dit niet dan zullen een gigantische hoeveelheid medewerkers in de problemen komen. Achteraf heb je qua administratie een flink zooitje. Tegelijk heb je als bedrijf een zorgplicht. Dat gaat voor wat eenmalige administratieve problemen.

PS: Verder is het bij cyberproblemen het redelijk gangbaar om bij problemen met financiële systemen (tussen bedrijven) een redelijke hoeveelheid geld over te maken en later de details te fixen. Dit vereist wel enorm veel vertrouwen tussen beide bedrijven (lange samenwerking).

[Reactie gewijzigd door bkor op 16 december 2021 11:11]

Disclaimer: onderstaande is niet als rant of aanval bedoeld.

Alhoewel ik snap wat je zegt, begrijp je de essentie van Blokker_1999's bericht denk ik verkeerd.
De opmerking over zwart uitbetalen zie ik niet zo, want als je iets uitbetaald staat het zoals je zegt op het bankafschrift van het bedrijf, maar dan nog moet het wel als negatief voorschot in een volgende salarisstrook verwerkt worden.

Alles kan, zelfs het uitbetalen van je medewerkers door gewoon een bedrag in telebankieren in te rammelen.

Maar als je 5 medewerkers hebt die loon moeten ontvangen is het nog te overzien, niet als je een flink veelvoud daarvan hebt. Daarnaast, moet het inderdaad ook nog achteraf helemaal gecorrigeerd worden. Dus per persoon in het salarispakket ingeven dat er een voorschot ingehouden moet worden bijvoorbeeld.

Jouw opmerkingen gelezen hebbende krijg ik het gevoel dat je toch iets te simplistisch denkt m.b.t. wat dat voor consequenties heeft.

'echter tja, ach, gebeurd niet elke maand ofzo'. Nogmaals, zijn er 5 weknemers, dan is dat vervelend maar inderdaad, soit. Heb je er echter 100 of meer, dan kan een bedrijf wel uren/dagdelen bezig moeten zijn om alles te doen (per persoon voorschot direct in de bank rammelen, die op het bankafschrift juist in de boekhouding laten verwerken, daarna het voorschot bij al die personen in een volgende salarisstrook verwerken, etc. etc.) en dan moeten er ook geen fouten gemaakt worden. Er zijn meerdere personen bij betrokken om dit allemaal te doen.

Ik heb dit meerdere malen meegemaakt en 'even een voorschot overmaken' lijkt weinig tijd te kosten, maar als het om veel personeelsleden gaat kan het veel tijd kosten én dus veel kosten opleveren.

[Reactie gewijzigd door Zonnetje83 op 16 december 2021 13:23]

Je kan dus niet zomaar zeggen: geef iedereen 75% van wat ze vorige maand hebben gehad als voorschot.
Sure, het is handmatig werk. Je zal in je bank afschriften moeten kijken welk loon (dat is dus het netto loon) iedereen de maand ervoor gehad heeft en dat moet je opnieuw overmaken. Daarnaast moet je kijken wie er uit dienst gegaan is deze maand zodat je dat loon niet overmaakt. En dan heb je een voorschot. Dus ja, het is werk maar ook weer geen rocketscience.
Bijkomend bestaat er dan geen paper trail voor die betalingen (geen loonstrookjes) dus betaal je mogelijks in het zwart uit.
Een voorschot is uiteraard op basis van het netto salaris van een voorgaande maand. De belasting die betaald moet worden is iets wat gewoon uitgerekend en afgedragen word nadat je de daadwerkeleijk loonstrook kunt maken waarna je ook een finale afrekening doet met het voorschot.

Als je geld overmaakt als werkgever met als betalings omschrijving: "Voorschot Salaris periode 12 - 2021" dan bestaat daar echt geen twijfel over. Ook niet voor een rechter.

Ik ben al een keer betrokken geweest bij zoiets toen er problemen bij de salaris verwerker waren. Zo spannend is het allemaal niet.
De timing is perfect, vlak voor de uitbetaling van de salarissen voor kerst, inclusief eindejaarsbonussen enzo.
Je zou haast denken dat ze het er om doen (is waarschijnlijk ook zo). De aanpak van "pak de OLA-tape van vorige maand maar en doe die nog maar een keer" zal op die schaal wel niet lukken denk ik....
Hoezo niet? Uitbetalen is hun vak :p
Is dit waar het "Cyber Polygon" voor "waarschuwde" zie dit nu continu in de headlines.
Waar het de laatste dagen veel over gaat is de Log4j kwetsbaarheid. Maar het bericht van Tweakers geeft aan dat men het vermoeden heeft dat het niet met de log4j lek te maken heeft. Vaak is het zo dat men al maanden bezig is met dit soort inbraken en bij log4j ziet men pas aanvallen vanaf 2 december.
Ook de Action gebruikt Kronos, Pon, abbvie. Ik weet dat bij de Action in Nederland in ieder geval de verlof en urenregistratie eruit ligt.
Je kunt dit zien als een andere manier van 'supply chain' attack. In plaats dat hier de supply chain van een groep software wordt aangevallen wordt de supply chain aangevallen van een reeks bedrijven.
Ik zie dit niet alleen als een aanval van criminelen maar ook als een aanval van een natiestaat. (Zoals Rusland of China). Feitelijk raak je met deze aanval een hele hoop bedrijven en hun werknemers. Dit kan leiden tot onvrede en maatschappelijke problemen. Er zijn immers mensen die wat letterlijk afhankelijk zijn van hun maandelijkse salaris omdat ze gewoon geen spaargeld hebben.

Welkom bij koude oorlog 2.0.eentje die wat al enige tijd bezig is.
Alleen de vergelijking met de koude oorlog klopt niet helemaal, het idee daarvan was namelijk juist dat er niks gebeurde (vandaar de naam koud, die had niet te maken met het klimaat ;) ). Volgens mij is er niks vredigs aan gericht aanvallen uitvoeren op bedrijven.
Onze workforceready cloud omgeving lijkt (nog) niet getroffen te zijn. Wij gebruiken het voor toegang en aanwezigheidsregistratie. Voordeel is dat het systeem synchroniseert met de taglezers on-premise zodat het ook offline kan werken.
Deze soort criminelen zijn niet alleen hackers, dit zijn terroristen, Daar is maar 1 antwoord op als ze gepakt kunnen worden.

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.



Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee