Jeg heier på dere. Dere har en særdeles viktig rolle i samfunnet, med en klar og tydelig stemme. Takk for jobben dere gjør!

Heisann Datatilsynet!

Mailserveren deres støtter ikke DANE for obligatorisk autentisert kryptering av epost. Mailserveren støtter gammel, utdatert og svak kryptering. IP adressen til mailserveren deres står oppført i et nett tilhørende Move AS , et nett som ikke er sikret med RPKI. Dere overholder ikke krav gitt i Forskrift om IT-standarder i offentlig forvaltning, hvor siste frist for implementering var 1 januar 2025. Det gjaldt bare dersom dere søkte DigDir om inntil 2 års utsettelse fra opprinnelig frist 1 januar 2023, og fikk dette innvilget.

Det sendes store mengder informasjon på epost hver eneste dag, inkludert sensitive personopplysninger. Statens einnsyn viser så absolutt at det går mye interessant kommunikasjon inn og ut av Datatilsynet. Epost kommunikasjon må derfor sikres best mulig, i tråd med etablerte internett standarder, anbefalinger og ikke minst krav fra staten.

La meg forklare manglene som påpekt innledningsvis:

DANE

Denne standarden, publisert i August 2012, tilfører et “syvmilssprang” for epost sikkerhet. Den teknisk “enkle” forklaringen: DANE tar dere fra “opportunistisk kryptering uten autentisering” av epost til “obligatorisk autentisert kryptering”.

All epost kommunikasjon med andre som støtter DANE vil alltid bli kryptert, og det kontrolleres at all epost sendes til riktig mailserver for mottaker gjennom bruk av digitale sertifikater.

Gammel, utdatert og svak kryptering

Mailserveren deres, mx.datatilsynet.no, støtter TLS versjon 1.1, 1.2 og 1.3 for kryptering av kommunikasjon. Jeg har brukt gratistjenesten Dutch Internet Standards Platform (Internet.nl) for å sjekke, testresultat kan ses her.

Nasjonal sikkerhetsmyndighet (NSM) sier at man bare bør støtte versjon 1.2 og nyere. Dette ble presentert blant annet på sikkerhetskonferansen deres våren 2025. Internet “Best Current Practice” BCP 195 refererer blant annet til RFC 8996 fra mars 2021, hvor man offisielt sier at TLS versjon 1.0 & 1.1 ikke lengre bør brukes på internett.

Dere bør altså fjerne støtten for TLS versjon 1.1, da den er offisielt utdatert.

Mailserveren støtter også svak kryptering. Dette er riktignok basert på anbefalinger fra Nederlandske myndigheter. Så langt jeg vet har ikke NSM publisert detaljerte anbefalinger for hvilke cipher suites man bør bruke, eller i hvilken prioritert rekkefølge de bør være. Dette gjelder også Key exchange parameters, hvor nyere og bedre funksjoner anbefales.

Dere bør oppdatere konfigurasjon av mailserveren. Avhengig av produsent og versjon av mailserver kan dette være alt fra enkelt til umulig, uten å måtte oppgradere eller bytte program/maskinvare.

Manglende RPKI for BGP

Enkelt forklart er RPKI bruken av digitale signaturer på rutinginformasjon mellom internett leverandører og andre som bruker BGP for å finne ut hvordan data skal sendes fra A til Z, via E, R og W. Uten RPKI kan en fremmed aktør med mulighet for å publisere rutinginformasjon via BGP gjøre forskjellige angrep:

1) Påstå at de eier/styrer nettet som Datatilsynets mailserver og andre maskiner Datatilsynet / Move har på nett. Alle i verden, ca 48% pr i dag, som ikke verifiserer RPKI informasjon vil gladelig sende trafikk (epost og annet) til den fremmede aktøren. Dette vil igjen gjøre den fremmede aktøren i stand til:

2) Stanse epost fra å nå frem til Datatilsynets mailserver, samt eventuell annen trafikk til andre maskiner hos Datatilsynet og Move, eller:

3) Lagre all datatrafikk, kryptert eller ukryptert, for mulig dekryptering og avlesning på et senere tidspunkt, eller

4) Manipulere trafikken i sanntid inn til Datatilsynet, spesielt ukryptert trafikk.

Jeg vet ikke, og kan ikke fra eksternt hold sjekke om dere kontrollerer RPKI signaturer på BGP rutingdata som dere / Move AS laster ned fortløpende for å kunne sende trafikk korrekt vei på internett frem til mottaker. Det er erfaringsmessig god grunn til å tro at dette ikke gjøres, slik at Datatilsynets router mot internett kan bli lurt til å sende data feil vei via fremmede aktører på vei til destinasjon.

Det oppdages titalls slike angrep verden over daglig, og som rammer alt fra enkelttjenester til større nettverk med potensielt millioner av IP adresser & systemer. Cloudflare Radar har i seksjonen “BGP origin hijacks” en sanntids oversikt over slike angrep på internett.

Dere må:

A) Selv, eller via Move AS, få digitalt signert deres IP prefixer hos RIPE

B) Implementere en løsning for å filtrere bort BGP rutinginformasjon med ugyldig RPKI signaturer, før ruter mot internett får tilført det som er korrekt verifisert rutinginformasjon, samt rutinginformasjon som fortsatt mangler RPKI signering.

Forskrift om IT-standarder i offentlig forvaltning (IPv6)

§12 sier at offentlige virksomheter skal sette krav til støtte av både IPv4 og IPv6 i alt nytt utstyr og programvare. Alle nye og eksisterende, eksternt publiserte tjenester skal være tilgjengelig på både IPv4 og IPv6.

Dette er ingen sikkerhetsfunksjon. Tvert imot, ved å ta i bruk IPv6 øker man sin angrepsflate. Imidlertid er IPv6 fremtidens adresseløsning for internett. Eller fremtid og fremtid, “World IPv6 Launch” var en stor greie 6 juni 2012, men standarden kom mange år før den tid.

Dessverre har svært mange offentlige etater enda ikke fått dette på plass, som denne websiden holder oversikt over. Selv DigDir måtte gi seg selv utsettelse til 1 januar 2025, og enkle kontroller viser at de er fortsatt ikke er i mål. Det bør ikke være noen unnskyldning for at Datatilsynet ikke har sin mailserver tilgjengelig via IPv6.

Det blir for dumt å måtte ta med i egen risikovurdering og rutiner for hendelseshåndtering at det innebærer en unødvendig/uakseptabel risiko å kommunisere og rapportere til Datatilsynet på epost.