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.
Onlangs hebben we een meting toegevoegd waarmee te zien is of een website op zichzelf staat, of dat bezoekers gevolgd worden door bedrijven die ook in de advertentiebusiness zitten.
We zijn deze meting aan het finetunen en afronden met een artikel hierover. Ondertussen zijn we bezig met een vervolg hierop. Dit vervolg wordt in de komende weken/maanden uitgerold en heeft alles te maken met locaties van online diensten.
Het ultieme doel is dat de online-overheid uitsluitend in de EU of Nederland opereert, behalve waar het logisch of redelijk is dat dit niet gebeurd (denk aan een KNMI meetproject in Azië). Dit is in lijn met de GDPR-wet en de bijbehorende trend om alles binnen Nederland of de EU te krijgen.
We gaan controleren op twee verschillende punten: de locatie van servers en de locatie van de inhoud van de voorpagina van websites. Hieruit halen we ip-adressen.
Deze adressen zoeken we op in een database waarin staat welk adres in welk land actief is. Deze database wordt op een complexe manier samengesteld: het is een mix van administratieve gegevens en kennis van hoe het internet op dit moment in elkaar zit. Voor de geïnteresseerden: de technische term is “ip geolocation”.
Een tipje van de sluier:
Op basis van ip-adressen en de locaties hiervan zien we dat er een klein percentage van servers buiten de EU staat. 3% van alle door ons gemeten ip adressen leidt naar de Verenigde Staten en een verwaarloosbaar percentage elders. Van de servers met een locatie anders dan US/EU zijn er een aantal legitiem en een paar ook niet. We zullen hier nog een mailtje over sturen naar de eigenaren van die servers. We hebben nog geen cijfers over de inhoud van websites.
Nieuwe subdomein scanner OWASP amassis toevoegd. Hiermee kan op tientallen manieren naar subdomeinen worden gezocht. Komen we daarmee eindelijk op de 100.000 overheidsdomeinen?
Domeininformatie van het SIDN wordt nu ingelezen. Dit om verlopen / uit handen gegeven domeinen te kunnen herkennen en makkelijk te kunnen verwijderen. Dank aan de SIDN voor het bieden van de who-is api.
Een domein dat van eigenaar is veranderd. Hier zie je dat het domein opnieuw is geregistreerd sinds dat we het monitoren. We kunnen dit domein en alle subdomeinen in 1x verwijderen. Dat maakt het onderhoud van de site behapbaar.
De website ondersteunt nu geolocatie: dus je kan makkelijk vinden welke organisaties in jouw buurt zitten zonder de kaart te hoeven doorzoeken. Geolocatie wordt gebruikt op de voorpagina en op de kaarten-pagina. Mogelijk binnenkort ook nog op andere pagina’s.
Geolocatie op de voorpagina. In Arnhem zie je een gemeenschappelijke regeling, de gemeenten arnhem, rheden, westervoort en lingewaard, daarna meer regelingen en ook bijvoorbeeld het Rijnstate ziekenhuis.Op de gemeentekaart zie je alleen de gemeenten om je heen.
De voortgang-pagina is opgeruimd en heeft nu permanente links. Je kan nu direct zien wat de toename is van security.txt voor bijvoorbeeld gemeenten en provinices.
Op de voortgang pagina is te zien dat het aantal security.txt toepassingen is gestegen van 28 naar 41. Er zijn ook kleine getallen linksonder op de kaart geplaatst waarmee je snel kan zien wat de absolute aantallen zijn.
Aanpassingen in metingen
De bannergrab scanner is bijgewerkt, waardoor bevindingen worden opgeslagen als https/443 als http/443 wordt gevonden. Wij gebruiken “https” als protocol waar nmap vaak “http” ziet omdat de webserver een “http” status pagina geeft waarop staat dat je de site via “https” moet bezoeken.
Idem zijn de protocollen ‘gnutella’, ‘ssl’ en ‘ms-wbt-server’ teruggebracht naar https. De 160.000 endpoints hiervoor zijn verwijderd en de metingen komen terug op https endpoints.
Aanpassingen in django admin
De endpoint pagina is versneld, zoeken op endpoints is versneld.
Er is een bug gefixt waardoor niets meer kon worden opgeslagen van nieuwe scans. Je kan in de onderstaande grafiek zien wanneer die bug was opgelost:
Nieuwe uitzonderingen
We blijven er wel op meten, maar strepen eventuele bevindingen weg op de volgende plaatsen:
Poort 8443 mag open staan voor vpn doeleinden. Dit zien wij onder subdomeinen als ‘thuiswerken’, ‘telewerken’, ‘vpn’, ‘werkplek’ enzovoorts.
Het subdomein ‘sip’ hoeft geen http security headers meer te hebben.
Er zijn weer een aantal updates doorgevoerd aan basisbeveiliging.
Nieuw
Nieuwe metingen over privacy gaan de 17e live april live.
Voortgang pagina. Hierop kan je de resultaten van een bepaalde meting over verschillende maanden zien. Standaard zijn dat 6 maanden, maar je kan jaren terug. Je kan dit nu het meeste voortgang zien rondom de security.txt meting. Hier een link naar de voortgang van provincies.
Handreiking Comply or Explain. Vanwege de vele Comply or Explain mails is er een pagina toegevoegd met een handreiking over welke verklaringen wel en niet worden geaccepteerd. Deze staat hier.
Ondersteuning voor alternatieve namen. We hebben bijnamen, oude namen, Nederlandse namen van Friese gemeenten en carnavalsnamen toegevoegd van gemeenten die een gelijknamig stad of dorp hebben. Ook kan je nu zoeken naar “mooie stad achter de duinen” voor Den Haag, “Torenstad” voor Zutphen, “Moerasdraak” voor Den Bosch.
Wijzigingen
Logins in het login plaza zijn nu voorzien van een versienummer en een link naar de publiek bekende kwetsbaarheden (zgn CVE’s).
Producten in login plaza zijn nu voorzien van informatie over de maker, wat het kan etc. Dit is aangevuld door ChatGPT 3.5, dus kan wat foutjes bevatten. We herkennen meer dan 250 producten van vele leveranciers.
Fixes
G1 overheidscertificaten worden nu correct automatisch verklaard. Meer hierover in het blogpost.
De nieuwe manier waarop microsoft alleen http aanbiedt op autodiscover domeinen wordt nu meegenomen.
In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.
Schunnige subdomeinen bij de overheid?
Dat de overheid veel sites heeft weten we. Een van onze bezoekers wees ons op een mooie website: platformhoutrook.nl. Er werd gewezen op het bestaan van het subdomein “cleavage.platformhoutrook.nl” op onze site en daarna nog wat andere. Mogelijk is dat niet de bedoeling.
Oplossing: Eerst dachten we: misschien heeft iemand bij de overheid gewoon slechte smaak. Hout… houthakken… cleavage… lame. Maar er blijkt iets anders aan de hand te zijn. In de archieven van het domein blijkt dat er talloze subdomeinen zijn aangemaakt: bustywifey, giggles, friendsworld, sniper en honderden anderen. Op de site zelf staan google ads.
Het is duidelijk dat daar iemand met matige bedoelingen bezig is, en gewoon het domein heeft gekocht. Het platform achter deze site is namelijk in rook op opgegaan opgeheven in 2021 en kort daarna begonnen de problemen. We hebben het domein bij ons op verwijderd gezet en alle onderliggende domeinen geofferd aan onze hamsters. Er is ook een mailtje gestuurd aan de maker van de brondata.
Een paar van de vele subdomeinen op het domein dat nu van een ander is.
Er word aan gewerkt!
Soms krijgen we verklaringen binnen waar we graag iets mee willen, maar niets mee kunnen.
Zo kregen we de melding dat men RPKI aan het toevoegen is op een site. Het duurt nog ongeveer vier maanden voordat dit af is. “De doorlooptijd is hoog, maar het staat op de roadmap.”
Oplossing: Supergoed nieuws dat hieraan wordt gewerkt! Dit is namelijk 1 van de paar laatste oranje metingen bij deze organisatie. So close!
De comply or explain functie is bedoeld voor verklaringen waarbij de afwijking iets veilig of veiliger maakt. Het gaat om iets dat “by design” wordt toegepast. Dat is nu niet het geval, daarom kunnen we de bevinding niet wegstrepen.
Een andere reden is dat we geen toezeggingen of beloften willen verwerken in een uitleg. We hebben dit in een ver verleden wel gedaan en daar werd ook goed gebruik van gemaakt. Maar wat je dan ziet is dat het soms niet of verkeerd wordt opgeleverd: dan staat iets ten onrechte als correct op de site. Dit hebben we dus geschrapt.
