Autoriteit Persoonsgegevens krijgt 75 meldingen Exchange-datalekken

De Autoriteit Persoonsgegevens heeft de voorbije weken 75 meldingen gekregen van datalekken bij organisaties die Microsoft Exchange-servers gebruiken voor hun mailverkeer. De AP vreest dat veel datalekken nog niet zijn opgemerkt.

Aleid Wolfsen, voorzitter van de AP, vreest dat dit nog maar het topje van de ijsberg is. “Omdat we tot nu toe 75 meldingen hebben ontvangen, vrezen we dat veel andere inbraken nog niet zijn opgemerkt. We verwachten daarom nog meer datalekmeldingen en een golf van ransomware-gevallen”, aldus Wolfsen.

Volgens Wolfsen zijn persoonsgegevens ook nu weer het doelwit van de kwaadwilligen. ‘Wij zien aan de binnengekomen meldingen dat criminelen vaak alle e-mailcommunicatie en adressenlijsten hebben kunnen inzien, kopiëren en verzenden naar een extern adres voor verder misbruik. Datadiefstal is afgelopen jaar met dertig procent toegenomen. Dat persoonsgegevens steeds vaker het doelwit zijn van criminelen, is zeer verontrustend”, stelt Wolfsen.

Eerder deze week stelde het Nationaal Cyber Security Centrum dat er minstens 1200 Nederlandse Microsoft Exchange-servers ‘vrijwel zeker geïnfecteerd zijn’. Bijna negentig procent van alle Nederlandse Exchange-servers zou volgens het NCSC wel al geüpdatet zijn met de patches die Microsoft begin deze maand uitbracht. Het centrum raadt organisaties die zo’n server hebben aan om deze zo snel mogelijk te updaten en waakzaam te blijven. Kwaadwilligen zouden immers al achterdeurtjes kunnen hebben geïnstalleerd.

Begin deze maand dichtte Microsoft vier actief misbruikte zeroday-kwetsbaarheden die hackers toegang gaven tot data van lokale Exchange-servers van bedrijven en organisaties. Door deze kwetsbaarheden zouden begin maart wereldwijd naar schatting honderdduizend systemen misbruikt zijn door Chinese hackers. Enkele dagen geleden kwam Microsoft met een bijkomende tool die de kwetsbaarheden in enkele klikken tijdelijk zou dichten. Deze tool richt zich op kleine bedrijven zonder eigen IT-beheer en die niet bekend zijn met het updateproces van hun Microsoft Exchange-servers.

Door Jay Stout

Redacteur

19-03-2021 • 19:59

42

Reacties (42)

Sorteer op:

Weergave:

. Deze tool richt zich op kleine bedrijven zonder eigen IT-beheer en die niet bekend zijn met het updateproces van hun Microsoft Exchange-servers.
Waarom gaat dit gewoon automatisch?
Euh, nou, wel automatisch maar niet vanzelf hoor. Iemand moet dat ding wel opstarten ...
Ik ben zelf o.a. Exchange admin, en heb thuis Kopano draaien(dat komt er zo ongeveer het dichtste de buurt).
Nu moet je beseffen dat Kopano zoals ik die thuis heb, iets heel anders is dan een Exchange cluster met vele afhankelijkheden(denk aan loadbalancers, active directory - Exchange doet vaak schema updates, enz, enz) . Bij Kopano zou je dat ook kunnen en moeten doen bij grotere installaties, dus b.v. LDAP server, centrale geclusterde database servers, enz.
Nu mijn punt, als jij denkt dat omdat je een simpel webservertje of database servertje - set and forget - met een automatische apt update in de nacht up tot date kunt houden, dan heb je gelijk. Máár helaas is dat steeds minder goed mogelijk naarmate je gaat clusteren, dingen (ivm bepaalde eisen en wensen of om technische beperkingen op te lossen) ingewikkeld hebt moeten maken.
Dus nee, je kan/wil geen Exchange clusters geautomatiseerd laten opdaten en dan de volgende morgen kijken of het bedrijf plat ligt. Maar dat kan ook niet bij de Linux alternatieven.
Als Exchange zo groot en monolitisch is geworden dat is allemaal niet meer kan dan is dat een probleem van Exchange, en niet een probleem van software-updates in het algemeen.
microsoft bouwt producten voor een heel divers publiek en dan heb je uiteindelijk een heel complex product, dat is voor exchange niet anders, maar het is technisch een veel ingewikkelder product dan wat de doorsnee IT'er kan beheren.
Ik vergelijk het vaak met een excel-sheet waarin je een volledige dubbele boekhouding kan doen, inclusief alle aftrekposten optimaliseren, maar dat je gemiddelde excel-gebruiker geen flauw idee heeft dat dit kan, laat staan kan schrijven is wel duidelijk.
Het onderhoud van die omgeving (lees excel-sheet) is dan ook van een veel hoger niveau, dan de gebruikers en mensen met zo'n niveau vind je niet overal, laat staan dat je ze permanent in dienst hebt of on call
Dat laatste is sowieso ook het geval. Probleem is dat bij een update 'alles' wordt geupdate incl databases(gebruikersdata), enz.
Je kan niet alleen alleen bepaalde webcomponten updaten en verwachten dat alles nog werkt. Zeker bij organisaties die hybrid draaien met Office365 is het soms complex en je wil een supported config hebben.
Uiteindelijk komt het er gewoon op neer: je pakt een exchange server, knalt de update eroverheen, restart, klaar, volgende. Maar als het mis gaat, dan is kennis van zaken gewenst. Dat laatste is er vaak niet, en daarom duren dingen lang. Deze issue is natuurlijk wel redelijk uitzonderlijk (zero day die direct misbruikt werd), dus iedereen kon al op dag 1 de sjaak zijn
Mee eens, maar het probleem begint al veel eerder. In het hybrid exchange geval is het securitydesign al zo goed als afwezig. Je kunt gewoonweg niet alles dichttimmeren omdat je dan een niet meer gesupport product hebt.

In dit geval gaf microsoft ook nog eens patches uit voor enkel de laatste releases. Dus als je een oudere subversie (bijv. Exchange 2016 CU12) dan moet je die eerst updaten. En dat is niet zomaar even een update, bijna een volledige installatie.

En dan is de informatie die verstrekt wordt ook nog eens onduidelijk. Eerst stond er een klein regeltje dat je deze patches los moest installeren. Daarna verschijnt er een ieniemienie regeltje dat het ook via Windows update kan, maar toen was het dus al te laat.

En dan heb ik het nog niet gehad over het feit dat die fijne Windows 10 updates het complete printverkeer hebben lamgelegd. Dus daar ben je ook nog eens door afgeleid. Al met al weer een enorme clusterfuck.
Ik vraag me dan af hoe het gaat als je office365 hebt dan draait de gehele exchange omgeving bj microsoft. gaat het updaten dan in afspraak met de klant en geeft dat na een update dan ook heel veel problemen, immers exchange in een locaal domein updaten geeft dat volgens jou wel. want you doet dat niet even zomaar. Kennelijk is het meer de angst van de beheerder dat het fout gaat. dan dat het een goed idee is om de server geupdate te houden. overigens de meeste bedrijven met een exchange server zonder beheerder met support van een extern bedrijfje die de IT beheerd. Zijn nu meestal geen omgevingen waar een cluster staat. Maar gewoon een of twee servertjes bestaat die de mail en de agenda verzorgen.
Is niet de angst, maar 20+ jaar ervaring. Dus ja, het kan mis gaan. Zeker bij updates die feitelijk gewoon een nieuwe installatie zijn. En dat ongepland, want 0-day exploit.
Ja en dan moet je kiezen, gehacked worden of je 20 jaar ervaring gebruiken om een installatie uit te voeren.
Ook bij Linuxservers moeten reboots gebeuren, en de meeste serversoftware kan ook niet worden bijgewerkt zonder downtime. Linux kan de kernel vervangen terwijl de server draait in sommige gevallen, maar ook niet alle patches kunnen op die manier worden verwerkt.

Midden in de dag vijf minuten down gaan kan voldoende zijn om een contract te verliezen als de verkeerde klant op het verkeerde moment écht dat ene mailtje nodig heeft.

Daarom heb je natuurlijk regelmatig gepland onderhoud met een procedure voor noodreboots met exploits als deze. Automatisch rebooten is uit den boze tenzij je een complex systeem van automatische fallbacks enzo, die een normaal bedrijf met een enkele exchangeserver en anderhalve FTE aan IT-beheer echt niet heeft.

Reboots zijn gewoon nodig op servers, en je kunt ze met allerlei trucjes wel uitstellen maar de echte reden van dit soort problemen is niet dat het OS vijf minuten bezig is met herstarten, maar (het gebrek aan) procedures, complexe IT-configuraties die een reboot mogelijk niet overleven en onredelijke uptime-eisen.
Onderhoud kan prima overdag: als je klanten weglopen om een mailtje dat een paar minuten later komt ben je groot genoeg om een cluster Exchangeservers te draaien en kun je gewoon failoveren zonder ook maar een pingetje te verliezen.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 17:14]

Je krijgt bonus downtime wanneer linux bedenkt dat de filesystem check meer dan 6 maanden niet is geweest. Voor grote organisaties met digitale archieven duurt zo'n check een dagdeel.
Wat een onzin.
Je kunt gewoon een bsmtp voor inkomende mail inrichten, en je kunt prima meer postfix servers de zelde shared disk laten serveren aan hun imap/pop clients.
Dan kun je zonder issues nodes updaten, en rebooten mocht dat nodig zijn.

Hoe dan ook, dat was niet het punt van mn reactie. Mn punt was dat er genoeg updates (mits gelimiteerd tot puur security updates) prima automatisch kunnen worden uitgevoerd, en *dat* niet geregeld is.
Het kan inderdaad, maar is niet echt relevant voor de meeste bedrijven. Zelfs dan moet je de storage server op een gegeven moment rebooten om kernelupdates door te voeren, en dan heeft je complexe postfix/dovecot/exim setup niks om te serveren. Je zult altijd ergens een korte downtime hebben, en in de context van self-hosted exchange staat er een doos ergens in de hoek van een serverruimte Windows Server 2008 te draaien, aangesloten met een 100mbit hub omdat de directeur geen nut ziet in het vervangen van het ding zolang het nog werkt.

Desondanks is het alsnog dom om zomaar automatische updates te draaien. We hebben het hier over Windows update, die bij de meeste updates gewoon kan updaten maar soms spontaan bluescreens laat verschijnen als de verkeerde printer is verschenen. Applicaties die draaien wil je sowieso niet zomaar onderuit gooien, in elk geval niet tijdens kantooruren. Ik heb meer dan genoeg downtime meegemaakt omdat ICT besloot "nog even snel" een server te updaten in de vrijdagmiddag, om vervolgens vier uur bezig te zijn met Windows vertellen hoe zijn domein er ook alweer uitziet.

Het bedrijf waar ik werk heeft een klant met daarop een Windows-server die 24/7 draait. Als de applicatie die daarop draait uit gaat tijdens kantooruren, kost dat het bedrijf tienduizenden euro's. Niet heel fijn om de ballon van de Java-updater in je RDP-sessie te zien in zo'n situatie. Met software als dat ga je geen autoupdaters draaien. De klant betaalt overigens extra voor de vage setup die ze hebben opgedragen, normaal gaat zoiets natuurlijk in een (redundant) cluster.

Automatische updates doe je in superredundante setups met fallbacks, backups en monitoring. Bij bedrijven waar dat mogelijk is, is Windows update niet echt een groot probleem. Het zijn juist de bedrijven met de incompetente IT- of managementafdelingen waar het misgaat, en daar wordt het ook niet beter van als je auto-updates voor die mensen gaat aanzetten.
Wacht! We je smtp en mailstore servers redundant uitvoeren maar niet je storageoplossingen?

Ik zou zeggen dat je met virtualisation nu juist de mogelijkheid krijgt om zaken zonder overdreven hardwareinvestering toch redundant uit te voeren
Pakketten als freenas kunnen daarbij wellicht een grote rol spelen door hun eenvoud failover-setup

Dan gaat je downtime van minuten naar seconden
Bedrijven die zelf geen systeembeheerder hebben gaan wel zonder meer lopen tierenlantijnen met Linux en mailservers? .... in welke droomwereld gebeurd dit?

(Ok, dat is al net zo waarschijnlijk als Microsoft die denkt dat bedrijven zónder eigen systeembeheer wél lokaal een Exchange server hebben draaien....)
Hell yes

Dan wordt er eenmalig een bedrag van +_ 15k neergelegd en verwachten ze hooguit 1x per jaar een checkup

En er zijn genoeg hobbyisten die daar een kvknummertje voor nemen en lekker gaan lopen beunen met met een howtoguide
Als het bij linux kan, is er geen excuus dat de zelfde security-functionaliteit niet ook op MS servers beschikbaar zou kunnen zijn.
Dan kun je droomwereld roepen, maar dat heeft er geen zier mee te maken.

Er draaien helaas hele drommen bedrijven lokaal wel exchange servers, zonder dat daar actief beheerders op zitten, getuige het aantal geïnfecteerde servers.
Natuurlijk kan dat ook bij de Windows updates voor Windows (Server).

Maar net als bij Linux servers willen de meeste beheerders van Windows servers zelf beslissen wanneer er wat wordt geupdate en wanneer eventueel een server herstart wordt...
Heeft niets met windows fanboys te maken. Bij ons is het echt een nogo om Linux automatisch te patchen. Voorsat het in productie gaat (tijdens maintenance windows) wordt het het eerst in de test- en staging-omgeving getest. Op basis van die resultaten wordt besloten om het in productie te deployen. Je moet toch eerst weten of het in je eigen specifieke omgeving geen impact heeft. Automatisch patchen is leuk voor consumenten en kleine, niet kritidche systemen, maar niet voor bedrijfskritische systemen en toepassingen.
En dat geeft nooit problemen, nou echt wel !! Dus eerst in een test straat en dan pas in het echt.
In grote omgevingen is dit niet zo simpel als je denkt.

Heeft niets met windows fan-boys te maken!
De eerste zin van je post is gevoelsmatig terecht. De rest is volkomen overbodig en komt betweterig over (afdoende de vele -1s denk ik)

Ik denk inderdaad dat als een bedrijf geen eigen beheerpersoneel heeft dat de betreffende diensten inderdaad beter sneller extreemkritische updates sneller automatisch moet updaten. Ik ben zelf geen Windows man (Ben een Linux engineer bij een financiële organisatie) en weet dus niet of dit in te richten is onder Windows server.

Mijn privé Windows desktop doet dit wel, dus gevoelsmatig moet het ook voor Windows Server en andere Microsoft producten mogelijk moeten zijn.

Misschien dat er hier een ‘Microsoft-man/vrouw) is die een valide reden kan bedenken waarom je dit niet bij een kleinzakelijke omgeving moet willen met dit product?

Ik kan me overigens ook voorstellen dat er her en der ongebruikte Exchange servers draaien. Dus dat de Exchange server is gemigreerd naar de cloud, maar dat diezelfde Windows server ook andere dingen doet, maar dat Exchange software nooit is uitgezet.
Wat is de vraag?
En op de mogelijke vraag antwoordt te geven. Nee de exchange update gaat niet altijd vanzelf.
Bij de oudere versies moet deze geregeld met de hand geüpdatet worden. Wat ook nog wel eens een uitdaging geeft mbt de rechten op verschillende mappen.
Verwijderd @Z8019 maart 2021 20:42
Valt wel mee, cumulative updates dien je handmatig te draaien. Dit staat effectief gelijk aan een volledige herinstallatie van Exchange. Daarom kun je met een CU ook volledige nieuwe installaties uitvoeren.

De normale (security) updates kun je gewoon draaien via Windows Update of WSUS. Daar hoef je geen bijzondere verrichtingen voor uit te voeren.

Wanneer er problemen zijn met rechten dan is de installatie (of een eerdere CU) niet correct uitgevoerd. Ik zou hier dan iemand naar laten kijken.
Er gebeurt niets automatisch. Deze tool is ook niets anders dan een powershell script dat wijzigen maakt zodat je niet meer direct kwetsbaar bent voor aanvallen. Het is echter slechts een noodstop oplossing want je moet daarna nog gewoon patchen.

Veel organisaties zijn erg voorzichtig met patchen gezien de Exchange omgeving erg belangrijk is (sluit alleen de agenda van een organisatie maar eens af). Bijna iedere e-mail binnen een organisatie loopt vaak ook door dit systeem heen. Alle facturen (inkomend en uitgaand), offertes, bestellingen, etc zijn vaak afhankelijk van Exchange. Dan is het fijn dat er mitigerende oplossingen zijn zodat je het patchen even uit kunt stellen.
Precies DÉ reden waarom MS nooit had mogen adverteren met mailservers voor iedereen zoals ze jarenlang hebben gedaan

Of beter gezegd vaak zie je dat kleine en middelgrote bedrijven maar wat aanmodderen terwijl ze wel jouw en mijn gegevens verwerken
En of dat nu gaat over gezondheidsgegevens bij huisarts tandarts of fysio

Of je naw + betaalgegevens bij dozenschuiver & co

Ze horen hun (en daarmee jouw) data veilig te verwerken
Misschien moet er voor ICT-ers ook een register komen zoals het BIG register voor zorgpersoneel. ICT is belangrijk genoeg, en zo'n register kan helpen om ICT te professionaliseren.
Dat zou zeker een goede zaak zijn.

Maar veel situaties komen doordat directie / management keuzes maakt, tegen het advies in van de ICT-organisatie. Keuzes die niet eens door hen gemaakt zouden moeten worden.

Persoonlijk denk ik dat daarom gevangenisstraf voor C-level executives het beste werkt.
Tot op zekere hoogte mee eens. Maar belangrijker nog dat leveranciers eens fatsoenlijke producten gaan leveren en verantwoordelijk gehouden gaan worden voor de schade. Vergelijk het met auto's en de bekende terugroepacties als er iets mis is. Als beheerder ben je hedentendage 90% van je tijd bezig met het verzinnen van oplossingen voor allerlei bugs en brak security design. Maar als het in de basis al mis is, dan kun je als beheerder maar beperkt iets doen. Zeker als je geen ongelimiteerde budgetten, resources en apparatuur hebt.

Voorbeeldje.
Per de documentatie van Microsoft zelf (document lijkt inmiddels aangepast) moet een hybrid exchange poort 80 en 443 inkomend open hebben staan voor alle IP adressen. Poort 25 SMTP mag je eventueel limiteren tot een aantal IP adressen van Microsoft.

Op vervolgens de vraag of je dan de verbinding tussen AD en Exchange mag dichttimmeren, is het antwoord nee. Die verbinding moet volledig open staan.

Oftewel. We kunnen nu heel erg focussen op de beheerders die het niet goed doen, maar een dergelijk design zou in de huidige tijd gewoon niet meer mogen bestaan.
Misschien moet de toezichthouder dan ook eens meer gaan doen dan wachten tot er heel concrete aanwijzingen zijn dat bedrijven een lek hebben, in plaats van alleen maar te blijven opmerken dat iets opvalt. Dit lijkt niet alleen van budget en tijd af te hangen als je zo duidelijk hebt dat er veel meer lekken zijn dan meldingen. Wat is een toezichthouder waard als die alleen maar wat opmerkt en er verder niets aan doet?
De gevolgen gaan de organisaties die niet hebben ge-update vanzelf wel ondervinden. In een vorm dat het voorbestaan van de organisatie kan bedreigen.

Over je toezicht houder opmerking: er zijn nog geen gegevens gelekt bij deze organisaties. Totdat er een overtreding plaats vindt kan deze natuurlijk niets doen.

Wat vraag je eigenlijk? Dat de toezichthouder maar gaat inbreken op kwetsbare systemen om te achterhalen van wie deze is?
Als er kennelijk duidelijkheid is dat welke en hoeveel exchange servers er niet beschermd zijn en kennelijk zelfs al lek dan kan een toezichthouder die gegevens opvragen of zelfs opeisen om te onderzoeken om welke bedrijven dat gaat en daar te eisen dat ze duidelijkheid geven of een ongewenst persoon geen controle had of heeft over de email-gegevens en persoonsgegevens die via die exchange services gecommunideerd hebben. We hebben het hier niet over een lek met kleine gevolgen, maar een probleem dat miljoenen mensen aan gaat. Voorkomen dat het te ver gaat is ook de taak van de toezichthouder.

De gevolgen gaan de organisaties niet vanzelf ondervinden. De wetgeving was niet voor niets al aangescherpt dat bedrijven verplicht moeten gaan melden en de toezichthouder meer kan, omdat bedrijven er vaak mee weg kwamen door te weinig kennis, te weinig controle, te weinig behoefte om onderzoek te doen, te weinig te melden dat er een lek is. En ondertussen was er vaak niet duidelijk waar de gegevens vandaan kwamen, omdat er te veel opties zijn om iemand als verantwoordelijke aan te wijzen. Nu is die mogelijkheid er kennelijk om verantwoordelijken op te sporen, dan horen ze dat ook te gaan doen als het zulke ernstige gevolgen kan hebben. Dan ga je niet wachten tot het te laat is en er misschien later wel iets kan gebeuren naar die bedrijven die een ernstig lek waar persoonsgegevens bij verwerkt worden niet worden gedicht.
Ik snap je punt denk ik wel maar ik denk dat je overschat wat een toezichthouder kan en mag.
Zeker op het binnendringen van systemen staat erg strenge regelgeving (waaronder toestemming van een rechter). Dat doe je niet even voor 1200 mogelijke organisaties. En wie weet zitten hier wel 'gevoelige' buitenlandse servers tussen.. Dan staan ze mooi even in de internationale schijnwerpers. Daarentegen mogen ze inderdaad wel wat 'agressiever' optreden. Voorkomen is beter dan genezen.

Ik denk dat ze een soort middenweg moeten nemen. Sluit bijvoorbeeld de internet verbinding af van de kwetsbare servers. Dat kan namelijk op een privacy vriendelijke manier (door het bijvoorbeeld door de provider uit te laten voeren). Dit wordt ook al door vele internet providers gedaan als er een virus bij de klant wordt gesignaleerd (zie xs4all).

De wetgeving was niet voor niets al aangescherpt dat bedrijven verplicht moeten gaan melden
Niet alle datalekken hoeven te gemeld te worden. Gezien niet alle organisaties hun Active Directory vullen met de volledige informatie van hun werknemers (laat staan BSN, seksuele geaardheid of andere hoog risico persoonsgegevens) is het ook niet direct duidelijk welke data er mogelijk gelekt kan worden.
Als eerste een disclaimer: met dit soort situaties heb je bijna altijd uitzonderingen, maar wat ik nu zeg gaat op voor het merendeel van de 1200 getroffen servers zoals ik het inschat.

Het uitvinden welke servers kwetsbaar zijn en van wie ze zijn kan de AP zonder problemen met de huidige bevoegdheden. Zo kan de AP bij verschillende partijen informatie vorderen en zonder in te breken kan er ook via het internet onderzoek gedaan worden.

Van elk van die servers is het niet perse van belang of er een kwetsbaarheid is geweest of dat er gegevens "gelekt" zijn. Wat van belang is voor de meldplicht is of er een inbreuk is geweest in de beveiliging (volgens NCSS bij vrijwel allemaal) en wat de risico's zijn voor de rechten en vrijheden van betrokkenen. Het kan dus goed zijn dat er een inbreuk is geweest, maar dat er niet genoeg logging is om met zekerheid te stellen wat de gevolgen zijn geweest en dat er dus gemeld had moeten worden. Dan moet de eigenaar van de server of de hoster natuurlijk wel op de hoogte zijn geweest, maar ook dat lijkt me waarschijnlijk en bewijsbaar omdat een aantal organisaties individuele waarschuwingen hebben lopen uitsturen.

Al met al zie ik kleine nuances die in individuele gevallen lastig kunnen zijn voor de AP qua handhaving voor ongemelde inbreuken. Maar in grote lijnen is dit een van de makkelijkste zaken die de AP kan hebben als ze ervoor kiezen om te handhaven. Het lijkt mij een enorm risico voor de AP om hier niet te handhaven, maar ik durf niet te voorspellen of ze dat ook gaan doen en zo ja, hoe ze het zullen aanpakken.
Ik snap je punt denk ik wel maar ik denk dat je overschat wat een toezichthouder kan en mag.
Als de toezichthouder ziet dat :" er minstens 1200 Nederlandse Microsoft Exchange-servers ‘vrijwel zeker geïnfecteerd zijn’." moeten ze dat als feit zien en moeten niet asl een speer de beheerders van die servers op hun lazer geven?

Voor zover ik de wet snap (en toegegeven, dat is ingewikkeld, verbeter me als ik het fout heb), is dat zeker mogelijk. Ik stel het sterker, als ze het niet doen en weten dat er een probleem is lijkt het me de taak van een toezichthouder om toezicht te houden.

Nogmaals als jij kan aantonen dat de toezichthouder de kwestbare servers niet mag aanspreken buig ik voor je kennis. Maar dit gaat over grote problemen. Feiten spreken. Meningen niet.
Feiten spreken. Meningen niet.
Feit is dat de toezichthouder pas in kan grijpen als er een daadwerkelijk lek van persoonsgegevens plaats vind.
Maar als jij kan aantonen dat de toezichthouder meer rechten heeft buig ik voor je kennis.
Onder art. 58 lid 1.b, e en f van de AVG (en onder Nederlands recht ook nog onder de Awb) heeft de AP bevoegdheden om onderzoek te doen naar de naleving van de AVG. Daar valt ook onder dat de AP kan onderzoeken of er werkelijk een inbreuk is geweest (bijv. Sporenonderzoek in de server) en of de verantwoordelijke of leverancier er vanaf wist (bijvoorbeeld toegang tot mailboxen vorderen). Dat is het onderzoek, maar wat ingrijpen betreft kan ik je aanraden om heel artikel 58 eens door te lezen want daar staat veel meer in.

Edit: ook zonder inbreuk kan de AP natuurlijk ook een onderzoek starten naar overtredingen van artikel 32 (is de beveiliging voldoende?).

[Reactie gewijzigd door Floort op 23 juli 2024 17:14]

Deze getroffen bedrijven hebben een meldplicht van datalekken volgens de AVG, daar kan niet automatisch een boete of wat dan ook tegenover staan, dat moet eerst uitgezocht worden of doelbewust wanbeleid is geweest van de getroffenen.
Nee, zo werkt die wet niet. Als je een probleem hebt met deze materie moet je aantonen dat je er niets aan hebt kunnen doen. De aanklager hoeft ABSOLUUT niet aan te tonen dat er doelbewust wanbeleid was. Onbewust wanbeleid is strafbaar. Geen beleid dat problemen geeft is strafbaar.

Als mensen de wet niet kennen is het wellicht beter als ze GEEN commentaar geven.

Op dit item kan niet meer gereageerd worden.