Rechter: IT-bedrijf is niet verantwoordelijk voor cyberaanval Hof van Twente

De rechtbank Overijssel heeft geoordeeld dat IT-bedrijf Switch niet de schadevergoeding van 4 miljoen hoeft te betalen die Hof van Twente geëist heeft in verband met de ransomwareaanval in 2020. Dat las ik bij Tweakers. Weer eentje in de categorie zorgplicht, maar in dit geval had Switch het prima geregeld – en dat het RDP-wachtwoord ‘Welkom2020’ was, was toch echt de keuze van de gemeente zelf.

In december 2020 voerde een ransomwarebende via een bruteforceaanval een gijzeling uit op de systemen van de gemeente, en eiste 750.000 euro losgeld. De gemeente betaalde niet, maar moest dus alles opnieuw bouwen. Dat was niet gebeurd als de IT-leverancier “haar kasteel (netwerk) had voorzien van een slotgracht, muren en bewakers zodat het niet kon worden binnengevallen.” Aldus de beeldspraak van de advocaat van de gemeente. Even nuchter vat de rechtbank het samen met

De rechtbank is van oordeel dat [Switch], gelet op haar contractuele verplichtingen en zorgplicht, wel heeft gezorgd voor de slotgracht, muren en bewakers, maar dat de gemeente een door haar beheerde achterdeur die toegang gaf tot het kasteel heeft opengezet door de brug neer te laten (de RDP-poort open te zetten) en een makkelijk te raden code (wachtwoord) voor het openen van de deur in te stellen, waardoor de bewakers niet ingrepen.
Altijd leuk die analogieën, maar wat was er nu echt gebeurd? Daarvoor pakken we het zeer gedegen onderzoeksrapport van het NFIR erbij. De korte maar recht voor z’n raap samenvatting is dit:
De aanvallers hebben toegang verkregen tot het netwerk van de gemeente via het Remote Desktop Protocol (RDP). Via RDP kan een server op afstand, via het internet, beheerd worden.  De server FTP-server was voor iedereen op het internet via RDP benaderbaar. Het eerste moment van ongeautoriseerde toegang heeft plaatsgevonden met het account “testadmin”. Het wachtwoord van het “testadmin”-account was op 15 oktober 2020 gewijzigd naar “Welkom2020”.
(Dat geluid op de achtergrond is de collectieve facepalm van alle meelezende securitymensen.) Dit is in juridische taal een niet echt adequate beveiliging, en dat is relevant want als we het gaan hebben over zorgplichten niet nakomen dan is dat wel zo’n beetje de standaard. En voor juristen zonder technische kennis is dit dus de brug die open staat en letterlijk het woord waarmee de wacht je doorlaat.

Wie valt deze tekortkoming te verwijten? Er was natuurlijk een héél pak papier want dit was een aanbesteedde ict-opdracht. De rechter begint met opmerken dat je die stukken zo moet lezen dat de bewoordingen leidend zijn (en dus niet de bedoeling, dit is de cao-norm en niet de Haviltex-norm). Inderdaad zoals bij die verzekeraar van laatst. Vervolgens volgt een trits eisen, waarbij voor mij eruit springt dat

• de informatieveiligheid van de data en de opslagdienst in het algemeen dient geborgd te zijn, zodanig dat voldaan wordt aan de eisen die vanuit het informatiebeveiligingsbeleid van de gemeente hieraan worden gesteld, welk beleid is gebaseerd op de Baseline Informatie-beveiliging Nederlandse Gemeenten (BIG);
Hoewel een algemene monitoringplicht deel was van de afspraken, was er geen expliciete securitymonitoring overeengekomen. Switch hoefde dus pas aan de bel te trekken als uit algemene monitoring een securityincident zou blijken. Wel hoorde bij haar taken het verzorgen van adequate backups. Switch had dat ook serieus onderzocht, en onder meer de back-up server en NAS te isoleren en de back-up server buiten het Active Directory domein te plaatsen. Daar had de gemeente nee op gezegd.

Wat security betreft, waren er dus enkele specifieke afspraken maar zeker geen overkoepelende verplichtingen. Althans, niet in de overeenkomst zelf. Als je de onderliggende algemene inkoopvoorwaarden (de GIBIT) erbij pakte en klantvriendelijk las, dan had je vrij snel een stevige en brede algemene securityplicht gevonden – onder meer die Baseline Informatiebeveiliging Nederlandse Gemeente (BIG) was deel van de overeenkomst. Maar de rechter vindt niet dat je zó makkelijk een zwik verplichtingen kunt importeren:

Ten slotte geldt dat de informatiebeveiliging een kernverplichting van [bedrijf 1] betreft in het kader van de overeenkomst: aan een dergelijke kernverplichting kan niet via algemene voorwaarden zoals de GIBIT-voorwaarden een andere en veel ruimere strekking worden gegeven dan specifiek overeengekomen. Dat zou zich ook niet verdragen met het hiervoor genoemde transparantiebeginsel.
Switch moest het netwerk kwalitatief monitoren, en de gemeente wilde de mogelijkheid hebben om bepaalde acties zelf uit te kunnen voeren zonder “gezeur van de IT” (noem ik het maar even). En dat kregen ze. Daar achteraf dan van maken “jij had de security moeten monitoren en moeten piepen als wij iets geks deden” is niet echt de bedoeling. Dit is waar rechters voor zijn: die kunnen geen RDP configuratiebestanden lezen, maar wel bepalen dat iemand achteraf zit te draaien om een ander de schuld te geven van z’n eigen fouten. Dit soort dingen:
[bedrijf 1] heeft de gemeente er medio 2020 nog op gewezen dat het gelet op de veiligheid beter was leveranciers alleen via de Kaseya-tool toegang te geven, maar voor de gemeente is dat geen aanleiding geweest gebruik te gaan maken van die tools op haar eigen account.
Een RDP poort open zetten heeft an sich geen directe impact op de kwaliteit van de IT-dienstverlening, dus dat is ook niet iets waar Switch wat van had moeten zeggen. En als er vervolgens een zwak wachtwoord wordt ingesteld dat tegelijkertijd wél aan de wachtwoordeisen voldeed, dan is er ook vanuit dat oogpunt weinig te detecteren.
Wat er ook zij van de discussie of deze door [bedrijf 1] voorgestelde maatregelen voldoende zouden zijn geweest om de cyberaanval te voorkomen of de gevolgen ervan te beperken (NFIR meende eerst van ‘wel’ en later van ‘niet’), is, bezien in het licht van het gegeven dat het gehackte account door de gemeente werd beheerd, daaraan de hoogste rechten waren verbonden en een zwak wachtwoord was ingesteld, een feit dat de gemeente (kennelijk uit kostenoverwegingen) niet is ingegaan op [bedrijf 1] voorstel. Daardoor heeft zij [bedrijf 1] de mogelijkheid onthouden om de veiligheid van de back-up te verbeteren, hetgeen voor haar rekening en risico komt.
Je zorgplicht als ict-leverancier houdt dus op als je het expliciet op tafel hebt gelegd, de risico’s hebt aangegeven en je dan een duidelijk “nee, gaan we niet doen” krijgen. Hier, deze mag u uitprinten en inlijsten:
De zorgplicht van een ICT-beheerder gaat niet zover dat waar functionele monitoring is overeengekomen, security monitoring daar (kennelijk gratis) onderdeel van uitmaakt.
Er is géén eis dat je dan hoger escaleert bij de klant, zoals de gemeente had gesuggereerd: jij onderhandelt met iemand, als die partij zegt “nee, gaan we niet doen” dan is dat de einduitkomst en dat de CISO van de gemeente of de wethouder IT-zaken wellicht anders had besloten, is niet jouw probleem. Zuur voor de gemeente, maar juridisch gezien was het toch echt haar eigen schuld.

Arnoud

Eén reactie

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.