Vanaf December is op Basisbeveiliging te zien of STARTTLS wordt gebruikt bij het ontvangen van e-mail. Deze meting wordt uitgevoerd met behulp van de tools van internet.nl. Andere metingen zoals DMARC, DKIM en SPF worden al enkele jaren gepubliceerd op basisbeveiliging.nl
STARTTLS wordt gebruikt om e-mails te versleutelen. Dat betekent dat iemand die probeert de verzonden e-mail probeert te lezen deze niet kan ontsleutelen, omdat de sleutel hiervoor alleen aanwezig is bij de ontvangende mailserver.
Een andere naam voor STARTTLS is Opportunistic TLS. Meer hierover is te lezen op wikipedia.
In de komende maanden wordt een nieuwe meting toegevoegd aan basisbeveiliging: cookies.
Dit gebeurt in twee fases. De eerste staat gepland op halverwege oktober en de tweede staat op eind november. In dit overzicht staat wat er wordt gemeten en wat er gaat gebeuren.
Fase 1: voorpagina, geen toestemming
Fase 1 gaat over cookies op de voorpagina van de website. Er is bij dit bezoek geen toestemming gegeven voor het plaatsen van cookies. Dat betekent dat alleen analytische en functionele cookies mogen worden geplaatst.
In deze fase ontstaat een initieel zicht op gebruik van cookies: uit welke producten ze komen zijn en waar ze voor nodig zijn. Zo weten we straks het totaal aantal cookies is, van welke partijen ze komen en voor een aantal of het verder gaat dan functioneel en/of analytisch.
We verwachten in de week van 2 oktober al een eerste set conclusies te kunnen delen, maar de publicatie van metingen per organisatie volgt iets later. Een vooraankondiging gebeurt namelijk minimaal een maand voor publicatie. Dit geeft iedereen de ruimte om nog eventuele aanpassingen door te voeren.
Fase 2: hele site met en zonder toestemming
In deze fase wordt de site bezocht tot drie niveaus diep en worden alle mogelijke cookies verzameld over verschillende pagina’s. Er wordt expliciet toestemming gegeven voor het plaatsen van alle soorten cookies.
Hierdoor ontstaat een beeld van welke diensten van derde partijen worden gebruikt op de verschillende websites. Ook wordt het duidelijk of er verschil zit tussen het wel en geen toestemming geven.
Omdat deze meting wat intenser is dan de gebruikelijke metingen van basisbeveiliging zijn er twee belangrijke kenmerken:
De meting wordt minder vaak uitgevoerd. Eens in de zoveel weken.
De bezoeker van de site is duidelijk herkenbaar als basisbeveiliging met een link naar de achtergronden van de meting. Hierdoor kunnen eventuele uitzonderingen worden gemaakt in firewalls. De meting vindt plaats vanaf de gebruikelijke adressen.
Cookie Consent Speed Run: probeer zo snel mogelijk om alle trucs heen te werken die proberen jouw toestemming te krijgen. Je mag geen fouten maken. Ons record: 2 minuten.
Cookie Clicker: een ander spelletje in het thema, maar wat helemaal niets met deze meting te maken heeft.
We krijgen regelmatig de vraag waarom basisbeveiliging Google Analytics negatief beoordeelt bij haar privacymeting. Er wordt dan verklaard dat Analytics is ingericht volgens de handleiding van de Autoriteit Persoonsgegevens.
De Autoriteit geeft bij tweakers aan geen specifiek advies te geven welke tools voldoen. Dat is sinds 11 augustus 2023 waar, omdat de bewuste handleiding (archief) en de per ongeluk impliciete goedkeuring/promotie toen van hun site is gehaald.
De reden dat wij Google Analytics en dergelijke diensten afkeuren is eenvoudig: Google heeft een tweede belang bij het verzamelen van informatie over bezoekers: verkopen. Dat is niet in het belang van de bezoeker of de organisatie die het product toepast. We zien dat de overheid in 23% van de gevallen Analytics verkeerd inricht.
In dit artikel laten we zien waarom diensten als Google Analytics een probleem zijn, waarom dit probleem ontstaat en blijft bestaan en welke mogelijke oplossingen er zijn voor dit probleem.
Inzicht geven in surfgedrag
Het bijhouden van bezoekersstatistieken en wat bezoekers op een site doen is handig. De eigenaar kan zo zien welke informatie populair is en of de site voldoende wordt bezocht. Er zijn honderden bedrijven die hiervoor diensten aanbieden.
Ieder bedrijf zit anders in elkaar. Sommige verlenen slechts één dienst: inzicht geven in bezoekers en hun gedrag. Andere bedrijven leveren meer producten en diensten om de begroting rond te krijgen. Soms zijn deze activiteiten met elkaar verweven, zoals advertenties en bezoekersstatistieken. Specifiek in het laatste scenario is Google de grootste naam.
Google is groot geworden door de combinatie van uitmuntende technologie met gerichte advertenties. Ze verkopen dus beiden, waardoor ze hun technologie goedkoop of zelfs gratis kunnen aanbieden. Google Analytics (GA) is de tool waarmee bezoekersstatistieken worden verzameld. De verzamelde gegevens worden dus ook gebruikt voor gerichte advertenties op deze bezoekers. Die advertenties zijn vaak pas zichtbaar op een andere website.
Analytics wordt gebruikt door ontelbaar veel organisaties. Het kost snel miljarden om een platform als dit te bouwen, terwijl het goedkoop of zelfs gratis is om te gebruiken. Dit wordt betaald met gerichte advertenties. Sceptici zeggen daarom dat de dienst wordt “betaald met privacy”. Wanneer een overheid kiest om zoiets te gebruiken, betalen hun inwoners dit met hun privacy.
Google zegt zelf met versie 4 te voldoen aan alle eisen. Ze zeggen daarna in hetzelfde artikel waarom dit een wassen neus is. Dat gaan we zo uitleggen.
Omvang van Analytics
Diverse Europese landen verbieden het gebruik van Google Analytics (voor de overheid). Dit zijn Denemarken, Italië, Frankrijk, Noorwegen en Oostenrijk. De reikwijdte van dit verbod wisselt per land, maar het is in ieder geval een signaal om het niet te gebruiken.
Een dergelijk verbod zal ondernemers niet tegenhouden om alsnog een bedrijf te beginnen met ongeveer hetzelfde businessmodel. De focus ligt bij Google omdat dit de grootste speler is. Daarom is Analytics een naam voor het onderliggende probleem: verzamelde gegevens voor iets anders inzetten dan uitsluitend het verlenen van de dienst voor de klant. Dit geldt natuurlijk ook voor andere diensten van Google als YouTube en Google Maps.
Wij meten dat Analytics 1774 keer wordt ingezet bij de overheid. 1038 keer bij de centrale overheid, 676 bij gemeenten en 60 keer bij provincies. Het is de grootste in deze markt voor de overheid. Als we alle diensten van advertentiebedrijven meten, dan zien we bijvoorbeeld dat 70% van de gemeenten (242) zoiets toepast. Wij monitoren daarbij vooral Amerikaanse bedrijven omdat Europese bedrijven nog niet op de bekende volg-mij-niet-lijsten staan.
De dans met de regels
De advertentiemarkt is een miljardenindustrie. Het is van onschatbare waarde, vaak ook bedrijfsgeheim, op welke manieren bezoekers worden gevolgd en hoe gegevens worden gecombineerd.
Bedrijven zoals Google houden zich op een subversieve manier aan de wet: de wet wordt perfect en strikt gevolgd en dus wordt de grens altijd opgezocht. Een belangrijk doel van advertentiebedrijven is dat het onderliggende probleem nooit helder wordt of wordt opgelost. Daarvoor worden verschillende strategieën gebruikt. Drie hiervan zijn:
Werken naar halve regelgeving, certificeringen en audits: regulatory capture
Focus op haakjes om gegevens aan op te hangen: zoals een IP adres
Ieder van deze methodes leggen we hieronder uit. Hierdoor zie je dat deze allemaal geen oplossing zijn.
Wij zeggen hier dus niet dat Google ergens misbruik van maakt of ze iets doet dat niet mag. Juist het tegenovergestelde: men houdt zich dus perfect aan de wet.
Strategie 1: Keuzes
Het aanbieden van keuzes is een gouden greep. Het verlegt de verantwoordelijkheid naar de kiezer en kiezen gaat gegarandeerd fout. Iedere keer dat dit fout gaat wordt er geld verdient.
Het maken van keuzes bij Analytics gaat zowel fout bij de aanbieder (de overheid) als bij de gebruiker (de burger):
Bij de aanbieder, de overheid, meten we dat er 419 keer verbinding wordt gelegd met een doubleclick domein van Google Ads, zonder dat er toestemming is gegeven. In 23% van de gevallen is Analytics dus verkeerd ingericht. Blijkbaar is dit te lastig voor professionele organisaties met hoogopgeleide ICT-medewerkers.
De gebruiker, de burger, krijgt dagelijks vele malen de keuze of ze gevolgd wil worden. De vraag is dan “wil je alle functies op deze website gebruiken?”. Toestemming geven is vaak makkelijker dan weigeren. Hier treed moeheid en conditionering op, waardoor men toch op “OK” klikt. De vraag om toestemming is vaak doorspekt met slimmigheden waardoor men eigenlijk geen kans heeft om te weigeren.
Die keuze voorleggen aan de burger is geregeld in de Telecommunicatiewet. De wet richt zich op alle mogelijke technische vormen van volgen. Omdat de meestgebruikte techniek een cookie is, wordt dit onderdeel van de wet vaak de cookiewet genoemd. Dit is dus onvolledig.
Strategie 2: regulatory capture
Het opstellen van regels, certificering en audits is een andere gouden greep. Hierbij snijdt het mes aan twee kanten. Linksom: voor nieuwe organisaties wordt het lastiger om toe te treden tot de markt. Rechtsom: je hebt zelf al de markt en de inkomsten, hierdoor kan je aan de nieuwe regels voldoen ongeacht hoe complex deze zijn.
Het beste is dus om regels te stimuleren waar alleen jouw organisatie aan kan voldoen. Bijvoorbeeld het verbieden van het volgen van gebruikers via een specifieke methode om profielen aan op te hangen (zgn “haakje”) zoals het IP adres. Dat is prima voor Google, omdat ze hiervoor andere haakjes kan aanwenden door schaalgrootte en bereik. Een voorbeeld hiervan staat in methode 3.
Het ontstaan en stimuleren van regulatory capture gebeurt bijna vanzelf. Feit is namelijk dat regelgevers vaak achter de feiten aanlopen: ze moeten leren omgaan met een altijd veranderende realiteit. Dat levert een spanningsveld, want je wil de maatschappij niet lamleggen of tegenhouden. Het opstellen van nieuwe regels, deze goed verwoorden en het probleem begrijpen is een vreselijk lastig en langdurig proces. Hier liggen bijvoorbeeld kansen voor denktanks en lobbyisten om de focus te verleggen naar iets wat logisch lijkt, maar het niet is.
Dit artikel gaat verder na de afbeelding met methode 3.
242 gemeenten gebruiken een dienst van een (Amerikaans) tracking bedrijf. 101 doen dat niet.
Strategie 3: Verbod op een specifiek haakje
Op de privacy-pagina van versie 4 van Google Analytics, staat letterlijk: “IP-address data is used solely for geo-location data derivation before being immediately discarded“.
In plaats van een persoon gaat het nu over een locatie: een adres, gezin, straat, wijk et cetera. Inderdaad niet herleidbaar tot één specifiek persoon: dus geen persoonsgegeven. Dat iets niet herleid tot een persoon wil dus niet zeggen dat deze informatie onschadelijk of betekenisloos is.
Google weet van alle IP adressen ter wereld namelijk de fysieke locatie. Dat komt omdat iedereen dit aan hen verteld. Bijvoorbeeld door het maken van een route in Google Maps of Waze, het zoeken naar informatie over de wijk, het bekijken van je huis op Streetview, het bezoeken van websites in de buurt zoals die van een hobbyclub, sportclub of gemeente (Analytics staat overal). Er is geen partij ter wereld die zo goed een locatie aan een IP adres kan koppelen als Google.
Zelfs als je je best doet om jezelf te beschermen hoeven je buren dat niet te doen. En omdat het IP adres van de buren bijna dezelfde is als die van jou heeft dat impact op je. Een schoolvoorbeeld is dat in armere wijken duurdere goederen verkocht kunnen worden omdat dit een status geeft. Iedereen helpt dus onbewust elkaars profiel op te stellen.
Een regelgever zou het gebruik van fysieke adressen kunnen verbieden, maar dan is er weer een ander haakje om gegevens aan te koppelen. Het is onmogelijk om dit probleem op een technische manier te stoppen, de belangen zijn simpelweg te groot.
Qua handhaving is er ook enorm veel ruimte, maar handhavers krijgen natuurlijk te weinig capaciteit, mandaat en kennis omdat de ernst van het probleem niet breed genoeg wordt onderschreven.
Oplossen van het echte probleem
Een verbod op een specifiek bedrijf of specifieke technologie lost niets op. Daarvoor zijn de belangen te groot. Maar er is wel hoop. Zo op het eerste gezicht zien we drie oplossingen, maar er zijn er vast meer.
A: Betere wetgeving?
Het echte probleem zit in de hoek van doelbinding: dat gegevens op geen enkele andere manier mogen worden ingezet dan het doel. Dus ook niet worden afgeleid, gecombineerd, verkocht en dergelijke.
Waarschijnlijk is dit juridisch ongelofelijk lastig op te schrijven. De cookiewet was hiervoor een eerste poging, maar biedt onvoldoende bescherming. Het leverde een van de subversieve oplossingen: keuzes.
De overheid kan natuurlijk wel voor zichzelf eisen opstellen en e.e.a. verbieden. Dat heeft natuurlijk weinig invloed op het grote geheel, maar het is een goed begin.
Een wettelijke oplossing is in ieder geval niet morgen geregeld, hoewel die behoefte en noodzaak er wel is.
B: Alternatieve bedrijven met betere waarden?
Privacy kan worden vereist bij de toepassing en aankoop van producten en diensten in allerlei markten. Maar ook dat is erg lastig: juist organisaties met een tweede doel zullen vaak aan de eisen voldoen omdat de eisen niet doordacht zijn vastgelegd.
Het is belangrijk om het onderliggende probleem te begrijpen: het beschermen van zoveel mogelijk mensen. Dit kan onder andere door te eisen dat gegevens maximaal voor 1 doel mogen worden ingezet en alle andere gronden te weigeren.
Gelukkig zijn er al tientallen bedrijven die dit al garanderen. Denk bijvoorbeeld aan Piwik Pro, Monsido en dergelijke. Deze bedrijven zijn helaas niet altijd transparant over hun prijzen. Matomo is dat wel. Hier wordt per bezochte pagina betaald. Voor 1 miljoen hits, een behoorlijk populaire site, is dat 160 euro per maand.
Zou Google haar Analytics tak afsplitsen naar een bedrijf met maar één enkel belang, dan is er geen bezwaar om het te blijven gebruiken. Dan moeten ze er wel (meer) geld voor moeten gaan vragen. Wedden dat niemand de daadwerkelijke prijs hiervoor wil betalen?
Wat ook helpt is de wetenschap dat 95% van de verzamelde gegevens in tools als Analytics niet relevant zijn voor dagelijkse sturing. Het verzamelen hiervan is dus overbodig werk.
C: Zelf maar iets draaien?
Zelf een tool draaien is een optie. Tweakers.net heeft onlangs een overzicht gepubliceerd van vier verschillende tools die Analytics kunnen vervangen.
De haken en ogen aan deze aanpak zitten niet in de technologie maar in de organisatie. Wanneer een organisatie zelf iets draait zitten hier verantwoordelijkheden aan. Zo moet er een server worden geregeld, deze moet worden ingericht en onderhouden, de software moet ingericht worden zodat het aan de wet voldoet en moet ook nog regelmatig (en soms acuut) worden bijgewerkt. Ook dan moet er nog steeds betaald worden aan dit soort projecten: anders worden kwetsbaarheden niet opgelost of is draait het op een verouderd (kwetsbaar) systeem. De medewerkers die dit uitvoeren krijgen natuurlijk salaris. Alles bij elkaar gaat het snel over een behoorlijk bedrag.
Zelf iets draaien is dus niet altijd even economisch of duurzaam. Alle haken en ogen kosten al snel meer dan iets afnemen bij een van de vele dienstverleners. Dat is namelijk de business case.
Wat keurt basisbeveiliging?
Basisbeveiliging keurt sinds april 2023 privacy op twee dingen: of een site op zichzelf staat en, wanneer dat niet zo is, of er verkeer wordt gestuurd naar bekende advertentiebedrijven.
De lijst met advertentiebedrijven komt van het Amerikaanse bedrijf Disconnect.Me. Zij verkopen diensten waarmee privacy vergroot kan worden. Hun lijst met bedrijven is openbaar, zodat iedereen dit kan inzien, aanpassen en gebruiken.
Het zal je niet verbazen dat op deze lijst voornamelijk Amerikaanse bedrijven staan. Ook neemt dit diensten mee waarbij Google zegt géén privacygevoelige informatie te verzamelen zoals bij het aanbieden van lettertypen (maar wel alle andere mogelijke data natuurlijk).
Op de techreuzen na opereren de organisaties op de lijst niet in Nederland. In de EU en Nederland zijn er wel bedrijven actief die op die lijst horen. Denk bijvoorbeeld aan Shoppingminds uit Hilversum. Op hun voorpagina pronken ze met de slogan: “Sell it Better”. Er is één overheid die dit gebruikt, maar mogelijk is dit contractueel goed geregeld.
In de toekomst gaat basisbeveiliging dus ook Europese / Nederlandse bedrijven die meerdere belangen hebben bij het vergaren van gebruikersdata afkeuren.
Tot slot
Gebruik dus geen diensten van bedrijven die bezoekersgegevens voor andere doelen inzetten dan de door jouw de gevraagde dienst. En doe dit natuurlijk zelf ook niet.
De meting “overbodige dienstverlening” kijkt naar of een dienst wordt aangeboden aan de juiste doelgroep. Hiermee bedoelen we dat een dienst via het internet bereikbaar is door iedereen ter wereld, terwijl dit waarschijnlijk niet de bedoeling is.
Wat meten we nu al en waarom?
Over het algemeen draaien websites op standaard poorten: 80 en 443, deze hoef je niet in de browser in te vullen omdat de browser dit al weet. Sommige websites draaien op alternatieve poorten zoals 8443 en 8080. Hier staat vaak een functionaliteit die bedoeld is voor een kleine groep gebruikers/beheerders. Dit toch aanbieden aan de hele wereld heeft een groot risico: Een lek in deze software of onderliggende infrastructuur kan door iedereen ter wereld worden uitgebuit. Daarom is het belangrijk om zo min mogelijk diensten aan te bieden via het publieke internet. Bijvoorbeeld door ze af te schermen middels filtering en/of alleen aan te bieden via een beveiligd netwerk zoals een VPN.
Specifiek voor websites maken we al wel uitzonderingen. Een voorbeeld is dat VPN software VMWare poort 8443 gebruikt, juist om de boel af te schermen. Dit afschermen van gegevens wordt natuurlijk niet negatief beoordeeld.
Wat wordt er straks extra gemeten
Er wordt gekeken naar diensten die specifiek bedoeld zijn voor het uitwisselen van gegevens in bulk. Bijvoorbeeld bestandsoverdracht en databases. Wij verwachten dat er geen denkbaar scenario is waarbij een dergelijke dienst publiek benaderbaar moet zijn.
De uitzondering op de regel is het File Transfer Protocol (FTP, waar ook TLS wordt ondersteund!) dat van oudsher bedoeld is om bestanden te delen met de buitenwereld en ooit zat ingebakken in alle browsers. Omdat FTP ooit integraal onderdeel was van het publieke internet wordt deze uitzondering behouden. We meten de aanwezigheid van FTP en of hier versleuteling op wordt toegepast sinds 2018.
Met deze uitbreiding wordt er gekeken naar de beschikbaarheid van de volgende vormen van bestandsoverdracht:
Bestandsdeling voor kantooromgevingen: Windows File Sharing (Netbios/Samba)
Populaire databases: Oracle, MySQL, Postgres, Mongo en dergelijke
De meting wordt een combinatie van een poortscan (veelal onbetrouwbaar ivm firewalls die willekeurige resultaten geven) en verbindingstest met een programma dat het protocol spreekt om er zeker van te zijn dat er geen sprake is van een false positive. Er wordt niet gekeken of er versleuteling wordt toegepast, of er authenticatie nodig is, er worden geen pogingen gedaan om in te loggen en er wordt ook niet gekeken of en welke data te vinden is.
Beoordeling
Voor zover er geen redelijk scenario is om deze diensten publiek aan te bieden, wordt dit altijd negatief beoordeeld. Dit zal als oranje worden beoordeeld.
Is dit nieuw nieuws?
Nee: deze metingen worden al decennia gepubliceerd op vele online scanplatforms. Het zoeken naar “online portscan” levert honderden diensten die poorten meten en publiceren. Dit zijn ook grote merken als Shodan en Censys. Alle securitybedrijven in Nederland kunnen deze dienst verlenen of bieden dit aan in standaardpakketten. Er zijn ook honderden tools die deze metingen kunnen verrichten. De bekendste hiervan is nmap.
Het is ook al lang juridisch uitgekauwd hoe het zit met portscans. Dat mag afhankelijk van de motivatie. In dit geval is de motivatie duidelijk: het veilig maken van Nederland.
Nieuw is dat deze situatie wordt beoordeeld en inzichtelijk wordt gemaakt voor een specifieke doelgroep.
Meting toegevoegd over de locatie van dienstverlening (in de EU+GDPR zone)
Er wordt gekeken waarvandaan online diensten worden verleend: van de server, e-mail server(s) en waar de inhoud van de website vandaan komt. 10% van de mailservers staat buiten de EU+GDPR zone. Het risico wordt tijdens de proefperiode als ‘laag’ ingeschat. Lees alle resultaten en achtergronden in dit artikel.
Nieuwe documentatie
Er zijn twee stukken documentatie online gezet:
het Meetbeleid: achtergrondinformatie over alle metingen op één logische plaats. Hier staat wat wordt gemeten, welke impact het maximaal heeft, met welke tool dit gebeurt en waar je deze meting zelf kan doen en documentatie erover kan vinden.
een handleiding: “Binnenkort op Basisbeveiliging, wat nu?” met hierin uitleg wat Basisbeveiliging is en handvatten naar alle belangrijke informatie zoals het meetbeleid, publicatiebeleid, de motivatie, de stichting en meer. Organisaties die nieuw op de kaart komen te staan sturen we ook deze link toe.
Bevindingen verrijkt met OpenCRE nummer
Waar mogelijk zijn bevindingen verrijkt met een OpenCRE nummer.
Dit nummer dient als “gateway” tot alle referenties naar alle verschillende beveiligingsstandaarden waarin deze specifieke beveiligingseis wordt genoemd of overduidelijk onderdeel van is.
Bijvoorbeeld is de toepassing van HSTS te vinden onder CRE: 036-147. Dit is onder andere verplicht volgens ASVS V14.4.5, CWE 523, CAPEC 3.9: 102, SAMM: O-EM-A, NIST SSDF : PW 5.1, AIS-06, NIST 800-53, OWASP Top 10 2021 A05 enzovoort.
Nog niet alle standaarden en raamwerken worden hierin genoemd, bijvoorbeeld NEN7510 en de bio (maar wel het achterliggende ISO27002). Omdat CRE een gemeenschappelijk project is hebben wij hoop dat er iemand ook deze standaarden daar toevoegt.
Ook zien we nog niet specifiek punten over security.txt, DNSSEC, DMARC en DKIM, maar wel oudere gangbare technische eisen. Ook hier geldt weer dat we verwachten dat de security-gemeenschap dit zal aanvullen.
Overigens is het wel leuk om te wijzen naar een bekende illustratie van de website XKCD. Alle security-raamwerken die worden vrijgegevens zijn grofweg re-hashes van andere raamwerken. OpenCRE is daar dan weer het toppunt van, met opnieuw eigen aanduidingen die veel omvatten en toch weer net niet. Dit gaat ongetwijfeld weer voor verwarring zorgen waardoor er binnenkort weer een nieuw raamwerk wordt gepresenteerd.
Verplicht plaatje als het gaat over standaarden. Bron: https://xkcd.com/927/
Vernieuwde HSTS meting
De HSTS header meting is opgefrist. Er wordt nu in de hele ketting van een bezoek gekeken of de header aanwezig is. Het bewijs van de meting is nu ook volledig in te zien, waardoor je ook alle tussenliggende doorverwijzingen kan zien en dus waar iets ontbreekt.
Wij verwachten per host waar https wordt gebruikt dat er ten minste 1x een HSTS header wordt ingezet. Daardoor wordt die host veilig(er). In het voorbeeld hieronder zie je dat dit in stap 3 niet gebeurt. Heel veel scanners kijken alleen naar stap 4, en slaan dus de controle over op stap 1, 2 en 3.
Een voorbeeld van een bezoek aan example.com:
Een verzoek wordt gestuurd aan http://example.com.
Antwoord: doorsturen naar https://example.com. Op http antwoorden is geen HSTS header nodig.
Een verzoek wordt gestuurd aan https://example.com.
Antwoord: doorsturen naar https://belangrijkeorganisatie.com. In dit antwoord zit een HSTS header.
Een verzoek wordt gestuurd aan https://belangrijkeorganisatie.com
Antwoord: doorsturen naar rijksoverheid.nl. In dit antwoord zit geen HSTS header, hier ontbreekt HSTS dus in de ketting.
Een verzoek wordt gestuurd aan https://rijksoverheid.nl
Antwoord: een webpagina. In dit antwoord zit een HSTS header.
G1 overheidscertificaat toegevoegd
Het onderliggende G1 Service certificaat wordt nu ook vertrouwd.
Bugfixes
Een van de rapporten was onleesbaar geworden, waardoor kaarten niet meer verschenen en geen nieuwe rapporten werden gemaakt. Er wordt nu rekening mee gehouden dat rapporten onleesbaar kunnen zijn. Hierdoor wordt deze fout automatisch hersteld.
Diverse kwetsbaarheden in de software die we gebruiken zijn gepatched.
Het veld voor bewijsvoering is nu vergroot tot nagenoeg oneindig. Bij sommige metingen komt nogal veel data terug. Deze is nu volledig in te zien op de site. Bijvoorbeeld bij de HSTS header meting.
Plus
Het is mogelijk zelf gebruikers aan te maken onder een account. Je kan tot 10 gebruikers aanmaken. De gebruikersnaam moet minimaal 10 karakters lang zijn (zonder speciale tekens).
Ook delen 419 overheidsdomeinen data met Google Ads.
Vanaf 9 augustus is op basisbeveiliging.nl te zien vanuit welk land de overheid online diensten verleent. We controleren of dit gebeurt vanuit de EU+GDPR regio. Deze meting is in mei aangekondigd.
In dit artikel wordt gekeken waar de overheid, gemeenten en provincies haar online dienstverlening heeft staan.
Samenvatting
3% van de overheidsdomeinen (1076) komt uit in de Verenigde staten.
10% van de mailservers (407) van de overheid staan in de Verenigde Staten.
Overige niet EU+GDPR landen zijn nauwelijks vertegenwoordig en vaak logisch verklaarbaar.
Overheidssites gebruiken 42.745 externe bronnen, 62% hiervan staat in de States. Hier is Google verreweg de populairste dienstverlener (analytics, maps, youtube, fonts, tagmanager)
419 overheidsdomeinen delen data doubleclick.net (Google Ads).
Er zijn meer dan 300 bedrijven die domeinen van de overheid hosten.
Er zijn meer dan 146 bedrijven die e-mail diensten leveren voor de overheid.
Er wordt data gehaald van 1637 verschillende externe sites.
Diverse logische uitzonderingen worden in de komende maanden vastgesteld. Verreweg het merendeel van de bevindingen in dit artikel (>99%) valt niet onder deze uitzonderingen.
Wij vragen de Nederlandse overheid om alle online dienstverlening, waar het logisch is, aan te bieden vanaf servers in de EU+GDPR zone.Dit betekent dat honderden domeinen en e-mail diensten moeten worden verplaatst.
Waarom meten we dit?
Omdat we gegevens willen beschermen. Dit zijn niet alleen persoonsgegevens van burgers maar alle mogelijk denkbare gegevens van Nederland.
Als we alleen kijken naar persoonsgegevens mogen deze verwerkt worden in veel landen. Dit is geregeld in de Algemene Verordening Gegevensbescherming, de AVG ofwel GDPR. Deze wet is van toepassing op alle landen in de Europese Unie en de Economische Zone (dus ook Noorwegen, IJsland en Liechtenstein).
De wet geldt ook (nog) in het Verenigd Koninkrijk. Daarnaast heeft de Europese Commissie nog een serie landen aangewezen met vergelijkbare bescherming. Dit zijn o.a. Israël, Japan, Korea en onder voorwaarden de Verenigde Staten en Canada.
Dat iets mag wil nog niet zeggen dat het slim is. In andere landen gelden andere wetten. Overeenkomstige wetten worden misschien niet of anders gehandhaafd. Mogelijk gaan de gegevens die worden opgeslagen over een situatie die elders verboden is (een fictief voorbeeld is het opslaan van informatie over homohuwelijken in Korea). Verder hebben inlichtingendiensten toegang tot de gegevens, direct of op langere termijn. De gegevens moeten vaak letterlijk door een oceaan wat nadelig is voor de beschikbaarheid. Als grenzen worden opgezocht komt ook de geopolitiek om de hoek kijken: de situatie kan zomaar veranderen.
Het opzoeken van de grenzen waar e.e.a. mag staan is ingewikkeld en bijna jaarlijks onderhevig aan (plotselinge) juridische wijzigingen. Het is voor een leek onmogelijk om bij te houden wat wel en niet mag. Er is geen overduidelijk groot voordeel aan het plaatsen van diensten in verre landen. Mogelijk zijn dit kosten, maar gezien de grote en goedkope Amerikaanse dienstverleners nu ook diensten verlenen op servers binnen de EU valt dat argument weg.
Het opslaan van gegevens die niet onder de GDPR vallen is weer een ander hoofdstuk. Met andere gegevens bedoelen we concurrentiegevoelige gegevens, intellectueel eigendom, statistieken, vertrouwelijke stukken enzovoort. Per gegeven zijn er weer andere regels. Regels rondom versleuteling zijn dan mogelijk niet verplicht.
Een groot deel van dit wespennest kan worden voorkomen door gegevens binnen de landsgrenzen of de EU te houden. Dit is ook makkelijk te begrijpen voor personeelsleden en bedrijven die de gegevens verwerken.
Wat keuren we wel en niet goed?
We kijken of een dienst in de EU+GDPR zone valt. Deze zone bevat alle landen op het Europese continent die de GDPR of gelijkwaardige wetgeving toepast. Met deze meting zijn we dus mogelijk iets strenger dan de eisen van de wet, maar wel met een serie argumenten en overwegingen die dat verklaart.
De EU+GDPR zone zijn alle landen in de Europese Economische Zone en landen met gelijkwaardige wetgeving zoals Zwitserland, het Verenigd Koninkrijk en Andorra. Expliciet buiten de boot vallen dus 17 landen die wel (deels) op het Europese continent liggen maar andere wetten hebben, zoals Albanië, Oekraïne en Turkije. De wetgeving van de bijzondere gemeenten (Bonaire, Sint Eustatius, Saba) en de andere landen in het Koninkrijk der Nederlanden (Aruba, Curaçao, Sint-Maarten) is ons (nog) niet geheel duidelijk, dus dit keuren we nu goed.
Alles wat buiten de EU+GDPR zone valt keuren we af tenzij het volstrekt logisch is dat deze dienst er buiten valt. Denk bijvoorbeeld aan een NBSO in Brazilië of een meetproject van het KNMI in Indonesië. Dit wordt per casus bekeken en is nog niet afgerond.
Er wordt op drie plekken gekeken naar locaties: het domein, de e-mail server(s) en de adressen waarop verbinding wordt gemaakt bij het bezoeken van een website. Ieder van deze plekken wordt op de volgende manier beoordeeld:
Meting
Binnen EU+GDPR
Buiten EU+GDPR
Domein
Goed: OK / Groen
Proefperiode: Laag / Groen Vanaf december: Midden / Oranje Vanaf Okt 2024: Oranje of Rood
E-Mail Server(s)
Goed: OK / Groen
Proefperiode: Laag / Groen Vanaf december: Midden / Oranje Vanaf Okt 2024: Oranje of Rood
Inhoud van website
Goed: OK / Groen
Laag / Groen
Meetbeleid op locatiemetingen over tijd
Bij de beoordeling is er sprake van een proefperiode. In deze periode wordt gekeken naar hoe betrouwbaar deze metingen zijn. Mochten de metingen niet betrouwbaar voldoende blijken, dan worden ze niet op oranje gezet en wordt gekeken of deze in de toekomst nog worden gepubliceerd.
Hoe werken de metingen
Voor deze meting wordt een computeradres omgezet naar een fysieke locatie.
Bijvoorbeeld het domein “zutphen.nl”. Hiervan bekijken we naar welk land het internetverkeer wordt gestuurd als we de website bezoeken, als we er een e-mail naar toe sturen en met welke landen informatie wordt gedeeld bij het bezoeken van de site zelf.
Deze drie metingen zien er bijvoorbeeld zo uit:
Meting
Voorbeeld
Locatie
Locatie van Domein
zutphen.nl
Nederland (Tilaa)
Locatie van E-mail server(s)
zutphen.nl wijst naar mail.zutphen.nl
Nederland (KPN)
Locatie van de inhoud van de website
zutphen.nl haal informatie op bij google-analytics.com
Noord Amerika (Google)
Voorbeeld van metingen
Natuurlijk is dit voorbeeld wat versimpeld. In werkelijkheid zijn er meerdere e-mail servers als achtervang en heeft ieder domein twee adressen: een IPv4 en IPv6 adres. Technisch is er nog veel meer mogelijk, maar ondoorgrondelijkheid en het ontbreken van transparantie is op zichzelf al een veiligheidsrisico.
De locatiegegevens komen uit de database van Maxmind. Dit is een commercieel bedrijf dat wekelijks de database bijwerkt en geld vraagt voor deze data. Deze metingen worden aangevuld met correcties uit de RIPE database (waar Maxmind niet bij mag). Van beiden hebben we toestemming om gegevens op te vragen en te publiceren.
Uit de metingen blijkt dat de fysieke locatie van IPv4 en IPv6 adressen vaak uit elkaar ligt. Hoewel het technisch mogelijk is, is er logisch gezien geen argument om dit te doen. Het lijkt dat IPv6 geolocatie kwalitatief lager is dan IPv4. Daarom hebben we IPv6 niet meegenomen in de beoordelingen.
Hoewel beide organisaties hun best doen om correcte informatie te leveren is er geen garantie. Het internet is namelijk constant in beweging. Daarom hebben wij ook een disclaimer voor alle metingen.
Wanneer we niet weten waar een dienst staat wordt dit niet negatief beoordeeld: er is geen verplichting om transparant te zijn over de fysieke locatie van dienstverlening. Dat is echter wel wenselijk en mogelijk op lange termijn toch een reden om een negatieve beoordeling hieraan toe te kennen.
Bevindingen op domeinen
Domeinen: 1087 adressen buiten de EU+GDPR Zone
In totaal zijn er 38.364 (sub)domeinen. Hiervan staan er 36.994 in de EU+GDPR zone, 1076 in de Verenigde Staten en 283 op een onbekende locatie.
De verdeling per continent van domeinen buiten de EU+GDPR zone is de volgende. Hier is te zien dat vooral domeinen in de States problemen veroorzaken. De domeinen op andere continenten zijn nagenoeg allemaal logisch verklaarbaar en dus geen probleem.
Locatie buiten EU+GDPR
Overheid
Gemeente
Provincie
Totaal
Afrika
3
3
Azië
2
4
6
Noord Amerika (Verenigde Staten)
566
460
50
1076
Zuid Amerika
2
2
Totaal
573
464
50
1087
Domeinen verdeeld over continenten buiten de EU+GDPR zone.
Er is ook sprake van twee continenten binnen de EU+GDPR zone, dit vanwege de bijzondere gemeenten en de andere landen in het Koninkrijk der Nederlanden. Je ziet dat verreweg de meeste domeinen in Europa staan.
Locatie binnen EU+GDPR
Overheid
Gemeente
Provincie
Totaal
Europa
20.482
15.716
775
36.973
Noord Amerika (Aruba, Curaçao, Sint Maarten, Bonaire, Sint Eustatius, Saba)
21
21
Totaal
20.503
15.716
775
36.994
Domeinen verdeeld over continenten. De meeste domeinen staan verreweg in Europa.
Domeinen: verdeling over landen
Verreweg de meeste domeinen komen uit in Nederland. Het enige land buiten de EU+GDPR zone dat hele procenten van de bezoeken ontvangt is de Verenigde Staten. De enkele sites in Zuid Afrika en dergelijke zijn logisch te verklaren en duiden niet op een probleem.
Overheid
Gemeente
Provincie
Procent
Land / Totaal
21.297
16.240
827
100%
Nederland
18.871
13.846
677
87.05%
Duitsland
841
611
25
3.85%
Ierland
357
802
33
3.11%
Verenigde Staten
566
460
50
2.80%
België
193
255
14
1.20%
Onbekend
223
62
2
0.75%
Verenigd Koninkrijk
121
89
15
0.59%
Frankrijk
31
37
2
0.18%
Zweden
17
50
3
0.18%
Oostenrijk
14
16
0.08%
Finland
12
6
0.05%
BES-Eilanden
17
0.04%
Italie
7
0.02%
Tsjechië
6
0.02%
Denemarken
6
0.02%
Polen
2
4
0.02%
Aruba
4
0.01%
China
1
2
0.01%
Zuid Afrika
3
0.01%
Brazilie
2
0.01%
Zwitserland
2
0.01%
Estland
2
0.01%
Japan
2
0.01%
Luxemburg
2
0.01%
Singapore
1
0.00%
Verdeling van domeinen verspreid over landen
Domeinen: verdeling van leveranciers in Europa
Dit is de top 25 van de 311 verschillende organisaties die diensten van de overheid aanbieden. Dit wordt geteld per domein. Er wordt niet gekeken welke dienst op deze domeinen staat. We hebben de vele onderzoeksdomeinen van TNO eruit gelaten omdat deze de resultaten met duizenden vertekenen terwijl er weinig op lijkt te draaien.
Overzicht aantal mailservers bij dienstverleners uit de Verenigde Staten.
E-mail: Verdeling servers in EU+GDPR landen
De 3547 servers in Europa zijn verdeeld over allerlei landen en dienstverleners.
Europees Land
Overheid
Gemeenten
Provincies
Totaal
Nederland
1922
990
27
2939
Ierland
167
134
4
305
Duitsland
55
42
5
102
Oostenrijk
59
34
3
96
Verenigd Koninkrijk
17
18
1
36
België
33
1
34
Frankrijk
21
3
24
Finland
2
4
6
Tsjechië
3
3
Polen
2
2
Overzicht verdeling van aantallen mailservers per Europees land
E-mail: Aantal mailservers per dienstverlener
Er zijn 146 dienstverleners gevonden. Dit is de top 20, hierdoor zijn 843 servers op allerlei domeinen niet zichtbaar. Sommige bedrijven zoals Amazon bieden servers in zowel de EU als de US. In het geval van Amazon zagen we al dat er 27 servers buiten de EU staan, de rest van de 105 staan dus wel goed. Domeinen van KNAW zijn achterwege gelaten ivm een wildcard waarop een mailserver staat.
Ministerie van Verkeer en Waterstaat/Rijkswatersta
40
40
Dienst Uitvoering Onderwijs
39
39
Verdeling van leveranciers van e-mailservers
Bevindingen over Websites
Bronnen buiten de EU+GDPR zone
Tenslotte is er ook gekeken uit welke landen informatie op een website komt. Het gaat dus niet over het domein, maar het bezoek van een site. Bij het bezoeken worden plaatjes, scripts, lettertypen en dergelijke soms van een andere locatie opgehaald. Dit zien we 23.468 keer gebeuren.
Wat opvalt is dat er ongelofelijk veel verbindingen naar Amerikaanse dienstverleners worden gelegd. Bijna exclusief naar Google en een beetje Microsoft. Dit bevat ook 419 keer doubleclick.net. Dit is een onderdeel van Google Ads, wat aangeeft dat Analytics niet goed is ingericht. De meeste Microsoft vermeldingen hebben te maken met Office 365.
Hier is de top 20 meest gebruikte externe bronnen naar buiten de EU+GDPR zone, deze zitten allemaal in de Verenigde Staten:
De top 20 populairste domeinen waar de overheid bronnen ophaalt om haar sites te maken
Bronnen binnen de EU+GDPR zone
Wat staat er dan eigenlijk wel in de EU regio? We tellen daar nu 14.095 verwijzingen, een stuk minder dan naar de States. Enkel West-Europese landen, namelijk enkel Nederland, Duitsland en Ierland. De andere landen zijn amper vertegenwoordigd met 264 verwijzingen in totaal.
Vanaf 1 Juli 2023 is het toepassen van HTTPS verplicht voor de overheid. Dat betekent dat communicatie met alle websites en webapplicaties versleuteld moet gebeuren. Hierdoor worden bezoekers van deze applicaties beschermd tegen een aantal bekende kwetsbaarheden zoals afluisteren van het internetverkeer.
Trends en onduidelijkheden
Met de verplichting van HTTPS op websites en web-applicaties komt er nog geen einde aan onversleutelde gegevensuitwisseling. Dat heeft twee redenen.
Ten eerste is het volgens de aanwijzing nog steeds toegestaan om onversleutelde HTTP diensten aan te bieden (punt 2b), zolang een bezoek wordt geupgrade naar HTTPS.
Deze uitzondering heeft een beperkte houdbaarheid. Dit komt doordat 93.34% van de gebruikte browsers in Nederland standaard als eerste proberen te verbinden met HTTPS. Dat zijn chrome, safari, samsung en edge. Dat gebeurd sinds medio 2021. Twee minder populaire browsers, Firefox en Opera (5.32% marktaandeel), bieden het als optie: dat gebruikt dus niemand. Firefox doet dit dan wel weer standaard bij Safe Browsing. Maar: mocht er niet gereageerd worden op HTTPS, dan wordt nog teruggevallen op HTTP. Daarover straks meer.
Direct met HTTPS verbinden is dus de standaard, en dat is goed nieuws. Punt 2b is er dus voor de achterblijvers. Die groep wordt gelukkig met de dag kleiner. Dat komt omdat versleuteling tijdsafhankelijk is: wat vandaag veilig is, is dat morgen niet meer. Zo kan je met een computer uit 2011 geen bankzaken meer regelen. Hierdoor staat er een borging rondom veilige communcatie: browsers en computers moeten bij de tijd zijn.
Het doorsturen van gebruikers gaat hierdoor een stille en natuurlijke dood sterven, waardoor de onversleutelde alternatieven niet meer nodig zijn en punt 2b kan worden geschrapt. Maar dat is niet zo voor organisaties! Die kunnen nog steeds onversleuteld HTTP toepassen. Althans…
En dit is het tweede punt: interpretatie. Als je de aanwijzing scherp leest valt onversleutelde dienstverlening zoals ftp en e-mail buiten de boot. Hierdoor is het nog mogelijk om onversleuteld e-mail te verwerken of bestanden onversleuteld uit te wisselen. Men kan zelfs kiezen om HTTPS aan te zetten, maar toch te blijven werken via HTTP. Dan lijkt in eerste oogopslag alles in orde, maar dat is het niet. Dat is niet meetbaar.
Is er eigenlijk wel een goed argument om niet versleuteld te werken? In alle jaren Basisbeveiliging zijn wij zijn pas 1 legitieme casus tegengekomen. Ironisch genoeg is die uitzondering onderdeel van het HTTPS-versleutelingssysteem. Daarom hanteren we een uitzondering voor het ontbreken van HTTPS op subdomeinen als “pki”, “ocsp” en “crl” (en varianten).
In conclusie: De stap om HTTPS (deels) te verplichten is er een in de goede richting. Het is ook logisch om niet ineens alles te verplichten wat op de Pas toe of Leg uit lijst staat, maar dit stapje voor stapje te doen.
Deze eerste verplichting beschermt internetters en zorgt ervoor dat mensen met de tijd mee gaan wat betreft veilige browsers en computers. Voor organisaties lijkt er nog veel ruimte om onversleutelde diensten te blijven gebruiken.
Altijd via HTTPS? Helaas nog niet altijd…
Veel sites voldoen dus niet, waaronder ook hoofdsites van ministeries zoals Economische Zaken of Landbouw, Natuur en Voedselkwaliteit. Hoe komt dat? Dat komt omdat browser terugvallen naar onversleutelde sites, en daar moet tegen worden beschermd. Deze bescherming wordt deels geboden met een instelling genaamd HSTS (punt 2c). Deze instelling ontbreekt op die sites nog.
Maar sommige sites zoals securityheaders.com zeggen dat het wel in orde is. Wat is het verschil? Dit komt omdat deze test-tool standaardaard kijkt naar de site waarnaar iemand doorgestuurd wordt. Wanneer je doorsturen niet toestaat, dan scoort te site onvoldoende. Als je het wel toestaat dan wordt de site rijksoverheid.nl gemeten, en niet minezk.nl. Dus wat is nou juist?
Het antwoord is dat HSTS ook bij doorsturen nodig is. Dat staat ook bij de veelgestelde vragen op de site van de digitale overheid.
Wat HSTS oplost is dat het eerste bezoek (en dat is het onveilige bezoek) pas opnieuw wordt gedaan als de site een jaar niet bezocht is. Zonder HSTS bij doorsturen krijgt een aanvaller de kans om bij ieder bezoek aan deze website de inhoud te manipuleren, dus niet alleen het eerste bezoek.
Bij het bezoeken van de site van het ministerie worden namelijk eigenlijk drie verzoeken gestuurd. Die zie je hieronder in de tabel. Het eerste verzoek is dus onversleuteld en kwetsbaar, de verzoeken daarna niet meer. Bij bezoek 2 ontbreekt de HSTS instelling in het antwoord, en daarom is het niet goed.
Verzoek
Ontvangen antwoord
1: door gebruiker http://minezk.nl
“Ik stuur je door naar de veilige https variant”: HTTP/1.0 302 Moved Temporarily Location: https://minezk.nl/ Connection: Keep-Alive Content-Length: 0
2: automatisch doorgestuurd https://minezk.nl
“Ik stuur je door naar een andere website”: HTTP/1.0 302 Moved Temporarily Location: https://www.rijksoverheid.nl/ministeries/ministerie-van-economische-zaken-en-klimaat Connection: Keep-Alive Content-Length: 0
Deze trace is na te bootsen met “wget -q -S -O – http://minezk.nl:80 2>&1”
De beperking van HSTS is dat je eerst de site moet bezoeken over een versleutelde verbinding voordat de instelling geldig is. Als je de site dus voor de eerste keer bezoekt is er dus nog altijd een risico!
Een lapmiddel hiervoor is HSTS preloading. Dit is een lijst van websites die wordt ingebakken in moderne browsers: alle sites op de lijst kan je alleen via HTTPS bezoeken. De standaard-lijst is nu 13 megabyte groot en bevat op het eerste oog geen Nederlandse rijks-sites.
Preloading is op dit moment een van de twee aanpakken die in alle scenario’s iets afdwingt. Je ziet dat de Amerikaanse overheid een aantal van hun sites verplicht op deze lijst zet. Dat is nodig totdat browsers uitsluitend via HTTPS communiceren en niet terugvallen naar de onversleutelde site. Deze “safe default” instelling laat nog wel even opzich wachten.
De andere aanpak is het uitschakelen van de onversleutelde verbinding. Daarvoor is het nog te vroeg. Browsers van voor 2021 zijn nog veel in gebruik, waardoor er bij eindgebruikers verwarring ontstaat over het niet kunnen bereiken van een website.
De Cijfers
Onjuiste toepassing van HTTPS op hoofddomeinen
Wanneer HTTPS wordt toegepast moet dat ook aan een aantal eisen (2a) voldoen. Deze eisen worden gepubliceerd door het NCSC, hier.
Op dit moment zijn er nog erg veel overheidssites die nog niet aan deze eisen voldoen. Het gebrek hieraan is dermate groot dat meer dan 33% van alle hoofdsites van overheden niet voldoen. Het is vandaag (29 juni) nog bijna gebruikelijk dat men niet voldoet. Wij gebruiken hiervoor de metingen van internet.nl, die de eisen van het NCSC implementeert.
De landelijke overheid, gemeenten en provinicies houden zich nog niet aan de wet. Om dit in perspectief te zetten, de zorg doet het dramatisch veel slechter en voor hen geldt deze wet niet.
Overheidslaag
Volgens aanwijzing
Wijkt af
Totaal
Landelijke overheid
850
515 (38%)
1365
Gemeenten
296
118 (29%)
414
Provincies
8
5 (39%)
13
TOTAAL
1154
638 (35.60%)
1792
Bonus: Ziekenhuizen/GGD
162
836 (83.76%)
998
Per ministerie zijn er ook duidelijke verschillen te zien in de kwaliteit van toepassing van HTTPS. De getallen wijken heel iets af met de “centrale overheidskaart” omdat deze niet 100% overlappen en er soms een domein op meerdere kaarten staan.
De getallen per ministerie:
Ministerie
Volgens Aanwijzing
Afwijkend
Infrastructuur en Waterstaat
99
166 (62.64%)
Landbouw, Natuur en Voedselkwaliteit
74
68 (47.89%)
Onderwijs Cultuur en Wetenschap
61
48 (44.04%)
Justitie
111
78 (41.27%)
Economische Zaken
95
65 (40.63%)
Financiën
28
10 (26.32%)
Binnenlandse Zaken
149
44 (22.80%)
Volksgezondheid Welzijn en Sport
187
52 (21.76%)
Buitenlandse Zaken
49
12 (19.67%)
Sociale Zaken en Werkgelegenheid
47
8 (14.55%)
Algemene Zaken
18
3 (14.29%)
Defensie
10
1 (9.09%)
TOTAAL
928
555 (37.42%)
Het gaat hier om 1483 domeinen. Dit verschilt net iets met het websiteregister rijksoverheid waar 1363 unieke domeinen in staan. Dit komt zowel door dubbelingen (sommige sites op meer ministeries) maar ook dat we misschien net een site meer of minder hebben. Ook daar zie je dezelfde resultaten wbt toepassing van HTTPS volgens de internet.nl metingen.
Ontbrekende versleuteling op 56 adressen
Er zijn 56 adressen waarop HTTPS volledig ontbreekt. Dit is een niet significant aandeel van alle overheidssites. In de meeste gevallen gaat het dan ook nog om testpagina’s, placeholders, vergeten projecten of andere weinig spannende doeleinden. Er zijn maar twee sites die echt informatief zijn: geluidregisterspoor en een afspraken site.
We hebben de uitzondering op ‘pki’/’ocsp’/’crl’ subdomeinen niet meegenomen. Dat zijn er vele tientallen.
Omdat HTTPS een nieuw soort verplichting is, is het nog niet helemaal duidelijk hoe dit wordt gehandhaafd. Onze verwachting is dat het snel duidelijk wordt hoe en wat.
Binnenkort is op basisbeveiliging.nl te zien welke (hoofd-)domeinen voldoen aan de TLS richtlijnen van het NCSC. Bij deze meting wordt onder andere verwacht dat er een doorverwijzing van http naar HTTPS wordt gebruikt, dat HTTPS aanwezig is op hetzelfde adres als waar HTTP en dat HSTS is ingericht.
Als je zelf al wil meten dan kan dat op internet.nl.
Dit artikel is gebaseerd op de metingen van 29 juni. Er is een hermeting gebeurd op 2 juli. Het verschil is te klein om het artikel erop aan te passen.
Toepassing van de eisen bij de landelijke overheid. Oranje is onvoldoende, groen is goed en bij grijs is er nog geen meetwaarde.Zo ziet er er bij gemeenten uit. Bij oranje wordt e.e.a. niet goed gedaan. Bij groen is het goed en bij grijs is er nog geen meetwaarde.
We zijn meer kennis rondom de stichting aan het uitschrijven: wat doen we, hoe doen we dat en wat betekent dit. De eerste stukken hiervan staan nu online:
De uitzonderingen op het meetbeleid zijn nu opgesomd en centraal publiek inzichtelijk. Dit wordt gebaseerd op de stroom aan comply or explain berichten die we wekelijks krijgen.
Een disclaimer rondom de inhoud van de site en expliciet de metingen.
Privacy-scan aangezet op alle subdomeinen en completere resultaten
Alle subdomeinen worden nu meegenomen in de privacy scan. Dat betekent dat er behoorlijk veel meetpunten zijn bijgekomen.
Daarnaast is de meting voorzien van extra informatie over welke aanvragen er worden gedaan naar externen. Voorheen waren alleen de links te zien, nu kan je zien waar de aanvraag vandaan komt: afbeeldingen, scripts, fetch, xhr, fonts etcetera. Je ziet ook wat wordt meegestuurd. Soms wordt er namelijk alleen een extra (POST) verzoek gedaan om zo te kunnen tracken zonder cookies.
Nieuwe uitgebreide meetgegevens in de privacymeting
Goedgekeurde versie-informatie
Het SSH protocol vereist dat er staat welke versie wordt gebruikt, zodat er bepaald kan worden welke features worden ondersteund. Dat is ergens te begrijpen. Omdat het onderdeel van het protocol is, moeten we het nu goedkeuren. Echter is er ook ruimte om “comments” mee te geven in de identificatie. Alle gevallen met comments keuren we niet goed, omdat dit geen onderdeel is van de negotiation en dus volledig optioneel is. Je kan deze comments uitzetten.
Dat de versie wordt goedgekeurd zegt niets over of de versie veilig is. Zo op het eerste gezicht vinden we het vanuit een security-standpunt onverklaarbaar waarom er informatie over de host gedeeld moet worden voor negotiation, maar daar is vast goed over nagedacht.
De SIDN api gaf ook antwoord op domeinen buiten het bereik. Als je daar zoekt naar apple.com krijg je de resultaten van apple.nl. Deze fout is rechtgezet aan onze kant: er wordt alleen nog op .nl domeinen WHOIS informatie opgevraagd.
Security.txt metingen hebben nu meetgegevens
Het is nu in te zien waarom security.txt metingen falen. Dat omdat de meting recentelijk is gewijzigd: het bestand moet op een nieuwe regel eindigen anders is het ongeldig.
Details over security.txt
Op de site
Filtering in rapporten
Het is nu mogelijk om op bevinding te filteren in rapporten. Dit is nog een redelijk basaal filter wat niet alle domeinen zonder resultaten weghaalt. Dat komt in een volgende versie. Het helpt in ieder geval om snel de juiste metingen te vinden omdat de rest onzichtbaar wordt.
Comply or explain bug opgelost
Sommige verklaringen werden nog niet meegenomen in de statistieken en rapporten. Daardoor week de kleur van de kaart en de statistieken af van de inhoud van het rapport. Deze lopen, na een paar dagen lang puzzelen, helemaal gelijk. Hiermee is een lang uitstaande bug opgelost (en zijn er vast weer twee nieuwe bijgekomen, want zo werkt dat met software).
Overig
Bij het importeren van organisaties worden nu arbitraire velden ondersteund. Dit is handig om op een later moment te kunnen filteren.
Er is meer logging toegevoegd aan de ‘ontbrekende tls’ meting. Deze geeft af en toe false positives en daar willen we vanaf. Dit is een traag proces en we verwachten dat het heel even duurt voordat alles weg is.
Het toevoegen en verwijderen van endpoints wordt nu gelogd en omgezet naar grafieken, hierdoor kunnen we grote verschuivingen detecteren en bepalen of er iets mis is met de internetverbinding of de meting.
HSTS meting bevatte een bug waardoor de meting qua bewijsvoering ‘klapperde’.
IT dienstverlening van de overheid hoort binnen Europa (en liefst Nederland) te gebeuren. Hiervoor hebben we een meting toegevoegd die later deze maand openbaar wordt. We zijn het beleid aan het opstellen en aan het experimenteren met hoe we dit gaan weergeven. Zie voor meer hierover de blogpost.
Uitzonderingen op basis van inhoud van de website
We kunnen vanaf nu uitzonderingen maken op basis van de inhoud van een website. Dit passen we nu toe voor Cloudflare, die als grote leverancier standaard een aantal onnodige poorten openzet.
We vragen gebruikers van Cloudflare dit issue met hen op te nemen, zodat ze kunnen voldoen aan diverse IT standaarden die vereisen dat alleen noodzakelijke poorten openstaan. Dit is door diverse mensen onder de aandacht gebracht de afgelopen maand.
Inhoud van diverse pagina’s. Dit wordt doorzocht bij security policies.
Risicoopsommingstabel is opgedeeld
De tabel met risico’s is nu opgedeeld in categorien. Hierdoor kan je in 1x alle e-mail metingen zien zonder alle extra waardes / lege regels enzo. Dat leest net iets makkelijker. Het eerste tabblad bevat het oude vertrouwde (grote) overzicht.
Herschreven privacyscanner
De privacyscanner is herschreven. Dit heeft een factor 1000 snellere scans opgeleverd die ook nog eens betrouwbaarder en vollediger zijn.
Bedankt / “wordt aan gewerkt” knop
Metingen zijn nu voorzien van een “bedankt”/”wordt opgelost” knop. Hiermee kan je makkelijk waardering sturen naar de stichting, zo weten we een beetje wie de site gebruikt en hoe het wordt ontvangen. De eerste stapel bedankjes zitten al in de mailbox, waarvoor ook bedankt!
Update websiteregister rijksoverheid
De nieuwe namen van overheidsorganisaties van het Websiteregister Rijksoverheid zijn toegevoegd. Ook is een 10 tal nieuwe organisaties toegevoegd.
Voortgang bevat ook de kaart van vandaag
Hier zie je de voortgang van Security.txt, met daarop de voortgang van de adoptie. De kaart wordt langzaam groener, of toch niet…
Dagelijkse mails worden weer verstuurd, naast de gebruikelijke instant alert mails. Alert E-Mails bevatten nu ook de meetdata als JSON attachment. Dit is direct aan een SIEM te koppelen, of anders automatisch te verwerken.
Er worden geen meldingen meer gemaakt van metingen waar een verklaring op zit. Omdat automatische verklaringen soms later worden toegevoegd kan het zijn dat er weleens wat overbodigs wordt meegestuurd.
Overig
De herscan knop is gefixt, herscans worden weer ingepland.
Vandaag introduceren we Full Scope Tests voor deelnemers van de Internet Cleanup Foundation. Deelnemers kunnen hiermee volledige security scans uitvoeren met bekende security tools.
Resultaten van deze tests kunnen ernstige kwetsbaarheden aan het licht brengen. Ook zijn deze tests intensiever dan de normale tests die we uitvoeren op basisbeveiliging.nl. Dit heeft gevolgen voor wanneer zo’n test gestart kan worden en hoe de rapportage is in te zien. In deze post wordt dat allemaal uitgelegd.
6000 metingen, versleuteld…
De eerste Full Scope Test kan worden gedaan met de tool ‘Nuclei’. Op dit moment is dit een van de populairste security-scanners. We gebruiken deze tool al sinds maart 2023 voor Login Plaza, maar het het kan nog veel meer. Het heeft ongeveer 6000 checks aan boord. Waaronder meer dan 1500 checks op algemeen bekende kwetsbaarheden (CVE’s).
Het verwerken van kritieke kwetsbaarheden vraagt om een nieuwe aanpak. We zijn gewend dat alle informatie rondom metingen publiek is, dus er waren geen maatregelen nodig om informatie te beschermen tegen uitlekken. Bij full scope tests ligt dat anders.
Resultaten van full scope tests worden versleuteld opgeslagen. De enige die de data kan lezen is diegeen met de sleutel. Het is voor ons, noch anderen onmogelijk om resultaten in te zien zonder de sleutel. Zelfs als de database morgen op straat ligt is er dus niets aan de hand. Dat haalt een boel last van ieders schouders. Deze versleuteling gebeurt met NaCl Box.
Wanneer de database uitlekt kan niemand de rapporten bekijken.
Niemand van de Internet Cleanup Foundation kan de rapporten bekijken.
Je kan zien dat de rapportage van ons komt door de publieke sleutel (ieder rapport heeft een eigen publieke sleutel, de prive-sleutel gooien we weg).
Hoe kan je deze rapporten dan toch inzien? Je moet hiervoor het rapport ontsleutelen met een eigen prive-sleutel. Dat kan op je eigen computer maar ook in de browser.
Praktijkvoorbeeld van A tot Z
Stap 1: vrijwaring
Omdat Full Scope Tests intensiever zijn dan de normale tests op basisbeveiliging is het noodzakelijk om de Internet Cleanup Foundation een vrijwaring te geven voor deze tests. De vrijwaring is hier te vinden en wordt opgestuurd naar info@internetcleanup.foundation. Na ondertekening wordt het mogelijk om Full Scope Tests uit te voeren.
Stap 2: instellen publieke sleutel
Om de resultaten veilig op te slaan is het noodakelijk om een publieke sleutel te maken. Dat doe je op deze pagina. Het is op die pagina ook mogelijk om een prive-sleutel te maken. Je kan dat ook op je eigen computer doen op of op een andere website. We geven daar een voorbeeld van op die pagina.
Stap 3: Full Scope Test inplannen
Vanaf nu is het mogelijk om een Full Scope Test in te plannen. Dit gebeurd vanuit het portfolio.
Overzicht van het portfolio met daarop de knop “Plan Full Scope Test”, met de kever.
Na de klikken op de knop wordt het volgende venster getoond. Hierop is in te stellen welke Full Scope Test moet worden uitgevoerd en wordt er gecontroleerd of de juiste voorzorgsmaatregelen zijn genomen. Na het beantwoorden van de alle vragen wordt de “Let’s go!” knop actief.
Stap 4: Wachten tijdens de test
De test is nu aangevraagd en wordt zo snel mogelijk opgepakt. Dit kan, afhankelijk van de drukte, eventjes duren. Meestal zal dit toch binnen een half uur zijn.
Om dit barre half uur door te komen hebben we wat tips om te kijken op YouTube. In willekeurige volgorde een paar leuke filmpjes:
Maar je kan natuurlijk ook iets nuttigs doen met je tijd…
Stap 5: Testresultaten inzien
Het rapport is in te zien op de Sensitive Reports pagina. Hier zie je de meting die we net hebben gestart. Door op de knop “Show Details” te klikken zie je de versleutelde gegevens en de optie om deze te downloaden of te ontsleutelen.
Het downloaden levert dezelfde informatie die je ziet in het “versleutelde gegevens” veld. Je kan dit ook kopieren en plakken en ergens anders ontsleutelen. Let wel op dat je onze publieke sleutel nodig hebt, die staat naast “Ours” en wisselt per rapport.
Stap 6: Testresultaten ontsleutelen (online)
Door het invullen van je prive-sleutel wordt het rapport volledig in de browser ontsleuteld. Het invullen van je prive-sleutel betekent dat je je browser vertrouwt, de plugins in je browser en onze webapplicatie. Als je geen vertrouwen hebt hierin dan kan je naar stap 7 of 8. We raden in ieder geval aan regelmatig de set met sleutels te vervangen.
Door op “ontsleutelen in browser” te klikken wordt het rapport zichtbaar. Het rapport van Nuclei Full Scope Tests heeft een overzicht in een tabel en als kaartenbak.
Kaartenbakweergave:
Bevindingen in kaartenbakweergave
Tabelweergave, doorzoekbaar:
Bevindingen in tabelweergave
Je in bovenstaande screenshots dat er allerlei risico’s zijn gevonden. In dit voorbeeld zijn ze allemaal inschat op het risiconiveau “info”. Iedere tool heeft een eigen gradatie in risico’s. Deze wijken af van elkaar, en wijken af van basisbeveiliging.nl omdat de scope anders (intensiever) is. Wij raden sterk aan om alle bevinden door te nemen, omdat soms vele lage risico’s soms samen een groot risico vormen.
Stap 7: Testresultaten ontsleutelen (elders)
Als je de gegevens in de browser wil ontsleutelen, dan is het mogelijk deze te kopieren of te downloaden en elders te ontsleutelen.
Iedere implementatie van NaCl (zoals Libsodium) kan worden gebruikt om het bestand te ontsleutelen. Hieronder zie je twee voorbeelden. De eerste is de interface van TweetNaCl. Daaronder zie je een python script wat je kan gebruiken om e.e.a. te ontsleutelen.
Ontsleuteling van het rapport in de test-interface van TweetNaCl
Stap 8: Testresultaten ontsleutelen (lokaal)
Met het volgende python3 script en het installeren van PyNacl kan je het rapport ontsleutelen. Er zijn ook gebruikersinterfaces die hetzelfde doen. Je kan er naar zoeken. De toverwoorden zijn: NaCl, LibSodium en xsalsa20.
# Decrypts a file
# python3 decrypt.py --their_public_key="3pFkpZ8X1NKWCwZB3uEPhhZvmejrySVPWozBgLrUjzw=" --my_private_key="..." file
import argparse
import nacl.encoding
from nacl.public import Box, PrivateKey, PublicKey
parser = argparse.ArgumentParser(
prog='decrypt.py', description='Decrypt NaCl files, show output in console', epilog='Internet Cleanup Foundation'
)
parser.add_argument('--their_public_key')
parser.add_argument('--my_private_key')
parser.add_argument('filename')
args = parser.parse_args()
def decrypt(their_public_key, my_private_key, file):
their_public_key = PublicKey(bytes(their_public_key, 'utf-8'), encoder=nacl.encoding.Base64Encoder)
my_private_key = PrivateKey(bytes(my_private_key, 'utf-8'), encoder=nacl.encoding.Base64Encoder)
with open(file, 'rb') as f:
file_data = f.read()
try:
the_box = Box(my_private_key, their_public_key)
encrypted_data = the_box.decrypt(file_data)
except nacl.exceptions.CryptoError as e:
print(f"Could not decrypt file. Are the keys correct? Error received: {e}.")
raise nacl.exceptions.CryptoError from e
print("Decrypted file. Content is displayed below:")
print("--------- Begin decrypted content")
print(encrypted_data.decode('utf-8'))
print("--------- End decrypted content")
if __name__ == '__main__':
decrypt(args.their_public_key, args.my_private_key, args.filename)
Alleen voor deelnemers
Deelnemers van de Internet Cleanup Foundation hebben toegang tot Basisbeveiliging+. Zo weten we dat alleen de juiste omgevingen worden getest onder de juiste voorwaarden. Wil je deelnemer worden? Kijk dan voor meer informatie op de deelnemerschap pagina.
