Høring - Standarder for sikring av epost, kommunikasjon med nettsteder og navneoppslag

Transkript

1 Vår dato Deres dato Vår referanse 18/ Deres referanse Saksbehandler: Rune Karlsen Høring - Standarder for sikring av epost, kommunikasjon med nettsteder og navneoppslag På vegne av Kommunal- og moderniseringsdepartementet (KMD) forvalter Direktoratet for forvaltning og IKT (Difi) «Referansekatalogen for anbefalte og obligatoriske IT-standarder i offentlig sektor». Se for informasjon. Denne høringen omfatter fire saksframlegg som omtaler følgende standarder: 1. Revisjon og endring av «Anbefalte standarder for sikker datakommunikasjon» (HTTPS) a. Endring av referanser til de tekniske spesifikasjonene b. Endring fra Anbefalt til Obligatorisk 2. Endring av «Anbefalt standard for transportsikring av e-post» (STARTTLS, DANE) 3. Ny standard: «Anbefalt standard for å motvirke falske avsendere av e-post» (DMARC) 4. Ny Standard: «Anbefalt standard for sikkerhet i domenenavnsystem» (DNSSEC) I denne høringen ber vi om innspill og kommentarer på hvert av de fire saksframleggene. Som et supplement til høringsprosessen gjennomfører Difi en enkel spørreundersøkelse vedrørende de aktuelle standardene. Spørreundersøkelsen er anonym og alle virksomheter oppfordres til å svare. MeJ9PH6QdUNUhWWEZXWDhQWDVFRkpCMTJHU0kxR1NOOC4u Høringsnotatene er vedlagt dette brevet. Høringsuttalelser oversendes postmottak@difi.no innen 13. september 2018 Merk forsendelsen med saksnummer 18/ Send gjerne kopi til standard@difi.no Direktoratet for forvaltning og ikt Besøksadresse Oslo: Besøksadresse Leikanger: Postboks 1382 Vika, 0114 Oslo Grev Wedels plass 9 Skrivarvegen 2 Org.nr: NO postmottak@difi.no 0151 Oslo 6863 Leikanger

2 Difi standardiseringssekretariat og Standardiseringsrådet vil behandle de fire forslagene med høringsuttalelser 25. september De standardene som blir anbefalt i dette møtet vil bli publisert i Referansekatalogen i løpet av Vennlig hilsen for Difi Øyvind Grinde seksjonssjef Håkon Styri seniorrådgiver Dokumentet er godkjent elektronisk og har derfor ingen håndskrevne signaturer. 2

3 VEDLEGG 1 Notat Dato: Saksnr: 18/00643 Til: Rune Karlsen Kopi: Fra: Saksbehandler: Seksjon for informasjonssikkerhet Håkon Styri Saksframlegg til Standardiseringsrådets møte Anbefalte standarder for sikker datakommunikasjon Dette forslaget gjelder endring av en eksisterende anbefaling 1 som ble innført Formålet med standarden Den eksisterende anbefalingen har til formål å oppnå sikker overføring av data til og fra nettsteder som tilhører virksomheter i offentlig sektor eller som brukes til tjenester som leveres av virksomheter i offentlig sektor. Dette omfatter både overføring av data mellom nettleser (sluttbruker) og nettjener, og mellom tjenester (API) som bruker protokollen HTTP. Forslaget til endring opprettholder det beskrevne formålet. Formålet med endringen er å forbedre dette sikkerhetstiltaket og å presisere at sikker overføring av data til og fra nettsteder alltid skal brukes. Hovedbegrunnelsen for forslaget er at endringer i nettlesere fra store leverandører i markedet og endringer i virkemåten til søketjenester representerer nye faktorer når nytteverdien av denne anbefalingen skal vurderes. Kort om de foreslåtte endringene Vi foreslår følgende endringer: 1. Vi foreslår at spesifikasjonen RFC 2817 kan benyttes som et alternativ til spesifikasjonen RFC Dette er en endring som ikke får konsekvenser for dem som allerede bruker RFC 2818, men åpner for muligheten til å velge en alternativ teknisk løsning. Endringen medfører derfor ingen økt kostnad. 1

4 2. For å understøtte at sikker kommunikasjon alltid brukes legges det til anbefalingen at spesifikasjonen RFC 6797 (HTTP Strict Transport Security) benyttes. Avhengig av virksomhetens eksisterende løsning kan denne endringen medføre en engangskostnad ved endring av nettstedet, men denne endringen vil ikke medføre økte driftskostnader. Vi antar at engangskostnaden er lav. 3. For å etablere en standard for hvordan omdirigering av forespørsler som ikke bruker protokollen for sikker overføring av data skal gjøres beskrives dette i anbefalingen. Ønsket standard er at omdirigering fra HTTP til HTTPS gjøres til samme URL for å gjøre det mulig å etablere automatisk testing av etterlevelse. Denne endringen kan medføre at enkelte eksisterende nettsteder må endres. En slik endring vil medføre en engangskostnad, men medfører ingen driftskostnad. Vi antar at engangskostnaden er lav. 4. Difi vurderer å be om at denne anbefalingen gjøres obligatorisk. Dette gjøres for å sikre at denne anbefalingen i større grad blir fulgt av virksomheter i offentlig sektor. Endring av referanser til de tekniske spesifikasjonene Dagens tekst er som følger: «Det anbefales at offentlige kommunikasjonstjenester har støtte for HTTP over TLS [RFC 2818] ved bruk av protokollene HTTP/1.1 [RFC 7230] og TLS 1.2 [RFC 5246].» Difi foreslår å endre denne teksten til: «Det anbefales at offentlige kommunikasjonstjenester har støtte for Upgrading to TLS Within HTTP/1.1 [RFC 2817] eller HTTP over TLS [RFC 2818] ved bruk av protokollene HTTP/1.1 [RFC 7230] og TLS 1.2 [RFC 5246]. Det anbefales at HTTP Strict Transport Security (RFC 6797) blir brukt. Dersom en tjeneste får en forespørsel med bruk at HTTP uten bruk av sikker overføring med bruk av TLS skal tjenesten svare ved omdirigering til samme URL med bruk HTTP over TLS.» Det er viktig å påpeke at virksomhetene også må ha en god veiledning for å bruke standarden riktig. Den eksisterende veiledningen fra NSM er tilstrekkelig, men må oppdateres ved endring av anbefalingen for å bidra til at de over nevnte spesifikasjoner blir brukt på riktig måte. Begrunnelse for endring Endring nummer 1 begrunnes med at det ikke er noen grunn til å utelukke en av de to likeverdige spesifikasjonene RFC 2817 og RFC 2818 når man skal velge teknisk løsning eller leverandør. Da må anbefalingen nevne begge spesifikasjonene. Fordi målet med anbefalingen er at HTTPS alltid skal benyttes er det hensiktsmessig å legge til spesifikasjonen RFC 6797 som vil bidra til å oppfylle dette målet. Mange nettsteder har behov for å bruke HTTPS som et sikkerhetstiltak for deler av nettstedet hvor det utveksles informasjon som medfører krav til konfidensialitet. Det gir i praksis ingen besparelse å bruke HTTPS kun på deler av et nettsted. Side 2 av 4

5 Forslaget til anbefaling omfatter ikke krav til hvilken type sertifikater som bør brukes eller krav til fremstilling av sertifikater (krav til sertifikatleverandør). Krav til sertifikater kan bidra til å redusere risiko ytterligere, men slike krav kan medføre høyere kostnader. Difi anbefaler at krav til sertifikater knyttes til risikovurdering av den enkelte tjeneste. Det er viktig å understreke at bruk av HTTPS vil redusere risikoen for at brukere opplever at innholdet i tjenesten blir endret på veien mellom tilbyder av en tjeneste og brukerens nettleser. Dette gjelder ikke bare forskjellige typer angrep mot brukeren, men også tilfeller der et mellomledd legger reklame eller annen informasjon til den originale tjenesten. Bruk av HTTPS vil derfor medføre en fordel for brukere av tjenesten. Indirekte vil dette bidra til at brukere opprettholder tillit til virksomheter i offentlig sektor. Det er vanskelig å sette noen økonomisk verdi på disse fordelene. Difi ønsker at Standardiseringsrådet skal vurdere om denne standarden bør bli obligatorisk. Begrunnelse for dette følger under. Endringer i forutsetninger Søketjenester vil rangere nettsteder som bruker HTTPS foran nettsteder som ikke bruker HTTPS. Bruk av HTTPS vil derfor være en fordel for synlighet for brukere som søker etter tjenesten, og for disse brukerne vil dette oppleves som bedre tilgjengelighet. Det er vanskelig å sette noen økonomisk verdi på denne fordelen. Tidligere har nettlesere merket nettsteder som bruker HTTPS med en hengelås i adressefelt. Utviklingen går i retning av at nettlesere i stedet merker nettsteder som ikke bruker HTTPS som usikre. Enkelte nettlesere vil gjøre det vanskeligere for brukere å besøke usikre nettsteder. Dette vil i praksis bety dårligere tilgjengelighet til tjenester som bruker usikre nettsteder. Dersom offentlige virksomheter ikke bruker HTTPS er det sannsynlig at dette vil ramme brukernes tillit til tjenestene, og det vil påvirke nettstedenes tilgjengelighet negativt. Det er vanskelig å sette noen økonomisk verdi på denne ulempen. Det er grunn til å anta at nettlesere og søketjenester også tiden fremover vil endre reglene for hvordan nettsteder som bruker sikker datakommunikasjon merkes eller på annen måte fremheves. Denne utviklingen kan medføre et behov for å endre anbefalingen dersom det er ønskelig å påvirke hvordan nettstedene til offentlig sektor fremstår i nettlesere og søketjenester. Konsekvenser dersom eksisterende anbefaling ikke endres Digitale tjenester som ikke bruker HTTPS eller som ikke har etablert HTTPS på en korrekt måte vil merket som usikre i nettlesere. Når tjenestene fremstår som usikre påvirker dette tilliten til tjenesten negativt. Nettlesere kan i tillegg etablere barrierer som gjør det vanskeligere for brukere å bruke tjenesten. Dersom eksisterende anbefaling ikke endres vil det øke risikoen for at slike tjenester er oppleves som utilgjengelige. Det vil ha negative konsekvens dersom eksisterende anbefaling ikke endres. Side 3 av 4

6 Kostnader De foreslåtte endringene kan medføre at virksomheter må gjøre endringer på eksisterende tjenester. Kostnaden for hvert enkelt nettsted vil variere avhengig av teknisk løsning og nettstedets kompleksitet. Det er viktig at virksomhetene regelmessig tester sine tjenester for å verifisere at sikker datakommunikasjon er satt opp korrekt. Feil bruk av standarden kan medføre at nettlesere gir brukere varsel om at tjenesten er usikker, eller at nettleseren oppretter en barriere for bruk av tjenesten som vil påvirke tilgjengeligheten. Regelmessig testing av at denne standarden følges vil være et kostnadselement for drift, men vil ikke utgjøre noen stor del av driftsutgiftene. Når et nettsted går fra å bruke usikret til å bruke sikker overføring av data til og fra brukere vil det kreve økt bruk av CPU-ressurser for kryptering og dekryptering av data, men økningen er i praksis liten. HTTPS medfører også en liten forsinkelse (noen millisekunder) ved oppkobling av hver forbindelse. Dette er faktorer som kan medføre noe høyere driftskostnader. Dersom den tekniske løsningen for nettstedet støtter protokollen HTTP/2 vil bruk av sikker overføring muliggjøre en langt mer effektiv og raskere overføring av data. Dette er en faktor som kan bidra til lavere driftskostnader. Vær oppmerksom på at dette avsnittet omtaler driftsutgifter knyttet til den eksisterende anbefalingen. Kostnader for sertifikater Ett kostnadselement som har vært diskutert ved tidligere behandling av standard for sikker datakommunikasjon er knyttet til sertifikater. Endringer i markedet har ført til at det er flere leverandører som tilbyr en enkleste klasse type sertifikater som det ikke er knyttet avgifter til å utstede eller fornye. For virksomheter vil det være en lav engangskostnad for å etablere rutiner for å bestille og fornye slike sertifikater, men denne typen sertifikater kan redusere kostnadene knyttet til å etablering og drift av sikker datakommunikasjon. Difi vil understreke at det bør gjøres en risikovurdering av hver enkelt tjeneste før man velger hva slags sertifikat som bør brukes. For viktige tjenester bør sertifikat med utvidet validering (EV) benyttes. Begrunnelse for endring til obligatorisk standard Difi vurderer å be om at anbefalingen endres til å bli en obligatorisk standard. Ulempen ved at enkelte tjenester oppleves som utilgjengelige er en vesentlig faktor i denne vurderingen. Det er viktig å opprettholde tillit til tjenester som leveres av virksomheter i offentlig sektor. En obligatorisk standard er også et effektivt et virkemiddel for å unngå at digitale tjenester levert av virksomheter i offentlig sektor merkes som usikre av nettlesere eller av søketjenester. Side 4 av 4

7 VEDLEGG 2 Notat Dato: Saksnr: 18/00643 Til: Rune Karlsen Kopi: Fra: Saksbehandler: Seksjon for informasjonssikkerhet Håkon Styri Saksframlegg til Standardiseringsrådets møte Anbefalt standard for transportsikring av e-post Dette forslaget gjelder endring av en eksisterende anbefaling 1 som ble innført Formålet med forslaget Forslaget medfører ingen endring av formålet med gjeldende anbefaling. Begrunnelsen for endringen er at den eksisterende anbefalingen har en kjent sårbarhet hvor det er laget en ny spesifikasjon som inneholder tiltak mot denne sårbarheten. Difi anser at den nye spesifikasjonen har tilstrekkelig modenhet til at den kan vurderes som ny del av anbefalingen. Endring av eksisterende anbefaling Dagens tekst er som følger: «Det anbefales å benytte SMTP Service Extension for Secure SMTP over Transport Layer Security (RFC 3207) i opportunistisk modus for transportsikring av e-post mellom e-post servere, både ved sending av e-post til offentlige virksomheter og ved sending av e-post til innbyggere og næringsliv. Dette gjelder e-post utveksling som går over Internett (SMTP), og ikke annen meldingsutveksling som skal foregå ved hjelp av løsning for utveksling av meldinger mellom offentlige virksomheter.» 1

8 Difi foreslår å endre ordlyden til følgende: Begrunnelse «Det anbefales å benytte transportsikring av e-post mellom e-post servere, både ved sending av e-post til offentlige virksomheter og ved sending av e-post til innbyggere og næringsliv. Som prioritert løsning anbefales det å benytte SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (RFC 7672). Dersom motpart i utvekslingen av en e-postmelding ikke støtter denne spesifikasjonen skal SMTP Service Extension for Secure SMTP over Transport Layer Security (RFC 3207) i opportunistisk modus brukes. Dette gjelder e-post utveksling som går over Internett (SMTP), og ikke annen meldingsutveksling som skal foregå ved hjelp av løsning for utveksling av meldinger mellom offentlige virksomheter.» Den nåværende anbefalingen som viser til spesifikasjonen RFC 3207 medfører at løsninger som er tatt i bruk kan ha sårbarheter for angrep fra mellommann. IETF publiserte i oktober 2015 spesifikasjonen RFC 7672 som reduserer denne risikoen og som kan benyttes sammen med gjeldende anbefaling i referansekatalogen. En alternativ løsning er foreslått og har vært under arbeid hos IETF siden mars 2016, men er ennå ikke ferdigstilt som IETF-spesifikasjon. Det er uheldig å anbefale sikkerhetstiltak med sårbarheter hvor risikoen er betydelig redusert i nyere løsninger uten i det minste å gi veiledning om dette. Et minimum er å gjøre oppmerksom på den nye løsningen, men den nye løsningen vil ha liten effekt dersom kun noen få virksomheter bruker den. Difi foreslår derfor å anbefale spesifikasjonen RFC 7672 for transportsikring av e-post. Den sikkerhetsmessige gevinsten knyttet til denne endringen er redusert risiko for at sikker transport av e-post kan angripes av en trusselaktør. Kostnader Difi antar at den største kostnaden for å ta i bruk RFC 7672 er knyttet til at standarden krever at DNSSEC (RFC 4033 m.fl.) er etablert, men det er nødvendig å kartlegge hvor mange virksomheter som har leverandører av e-post som ikke tilbyr RFC 7672 og som derfor må vurdere å bytte leverandør. Dette ønsker Difi å få tilbakemelding på når endringsforslaget legges ut til høring. Konsekvens dersom gjeldende anbefaling ikke endres Selv om denne anbefalingen ikke endres så forventes det at virksomhetene har gjort en vurdering om risikoen for at sårbarheten som følger av RFC 3207 er akseptabel. Det er likevel fare for at en uendret anbefaling kan gi et utilsiktet signal om at risikoen knyttet til denne sårbarheten er akseptabel. Side 2 av 2

9 VEDLEGG 3 Notat Dato: Saksnr: 18/00643 Til: Rune Karlsen Kopi: Fra: Saksbehandler: Seksjon for informasjonssikkerhet Håkon Styri Saksframlegg til Standardiseringsrådets møte Anbefalt standard for å motvirke falske avsendere av e-post Det følgende er forslag om en ny anbefalt standard på bruksområdet Grunnleggende datakommunikasjon. Difi ønsker å sende dette forslaget på høring så raskt som praktisk mulig. «Det anbefales å benytte Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) med de underliggende standardene Sender Policy Framework (SPF) og Domain Keys Identified Mail (DKIM) for å sikre utveksling av e-post mellom e-post servere, både ved sending av e-post til offentlige virksomheter og ved sending av e-post til innbyggere og næringsliv. Dette gjelder e-post utveksling som går over Internett (SMTP), og ikke annen meldingsutveksling som skal foregå ved hjelp av løsning for utveksling av meldinger mellom offentlige virksomheter.» Formålet med anbefalingen Formålet med anbefalingen er å etablere bruk av en standard som gir mottager av e-post bedre mulighet til å verifisere om en melding faktisk er sendt fra det domenet avsender har angitt i meldingen. Dette medfører at meldinger som forsøker å bruke en forfalsket avsenderadresse kan identifiseres og stoppes. Det betyr også at mottager kan ha større tillit til angivelsen av avsender når en melding som er korrekt merket skal vurderes opp mot regler for å stoppe uønsket e-post (eller slippe gjennom meldinger fra tiltrodde avsendere). Det må understrekes at avsendere av uønsket e-post (spam) eller meldinger som sendes av en trusselaktør som en del av et angrep (for eksempel phishing) selvsagt kan merkes korrekt ifølge denne standarden. Formålet med standarden er kun å redusere risiko for at avsenderadresse er forfalsket. Standarden gir også mulighet for at avsender kan motta rapporter om at virksomhetens e- postadresse blir forsøkt misbrukt av andre. Slike tilbakemeldinger fra mottagere vil også bidra til at avsender får varsel dersom systemet er satt opp feil.

10 Begrunnelse Det har vært en sterk økning i bruk av e-post med forfalsket avsender både i forbindelse med digitale angrep mot virksomheter og ved utsending av uønsket e-post (spam). Misbruk av virksomheter i offentlig sektor som tilsynelatende avsendere av forfalsket e-post kan bidra til å svekke tilliten til digitaliseringen i offentlig sektor, og det øker risiko for at e-post som er sendt fra virksomhetene blir stoppet i spam-filter. Sikkerhetstiltak som DMARC, SPF og DKIM er tiltak som etableres på virksomhetsnivå og som gir mottager bedre forutsetninger for å avvise e-post med forfalsket avsender. Samtidig reduseres risikoen for at e-post som sendes av en tiltrodd virksomhet blir stoppet i spam-filter hos mottager. Det må understrekes at dette er et teknisk tiltak som ikke reduserer risiko for at en angriper eller bedrager bruker domener med navnelikhet eller bare sender fra en tilfeldig, gyldig adresse. Det er derfor vanskelig å anslå i hvor stor grad bruk av DMARC vil redusere risiko for at forsøk på digitalt angrep lykkes og redusere tidsbruk som følge av uønsket e-post (spam) generelt. Gevinster knyttet til anbefalingen For den enkelte virksomhet vil den direkte gevinsten av å følge anbefalingen være sikrere håndtering av e-post mellom virksomheter i offentlig sektor. Det kan også regnes som en gevinst at risikoen for at e-post som sendes ut fra virksomheten feilaktig blir filtrert ut som uønsket e-post hos mottager reduseres. Det er ikke mulig å anslå en økonomisk verdi av denne typen gevinster. En indirekte gevinst av at virksomheter i offentlig sektor følger anbefalingen er at mottagere får større tillit til e-post som kommer fra en avsender i offentlig sektor. Kostnader knyttet til anbefalingen Kostnaden for å etablere og drifte SPF er meget lav. Kostnaden for å etablere DMARC er også lav, men drift av DMARC gir først verdi når rapportene som genereres følges opp. Kostnaden for å etablere DKIM er noe høyere og kan medføre at enkelte virksomheter må bytte leverandør av e-post som tjeneste. Risikoen for at en leverandør av e-posttjeneste ikke kan levere DMARC vurderes som lav. Flere virksomheter har allerede tatt en eller flere av tiltakene i bruk. DMARC er innført som standard for offentlig sektor i andre land, bl.a. USA og Storbritannia. Et eksempel på en tjeneste som understøtter DMARC er Microsoft Office 365. Det er publisert veiledning for etablering av SPF, DKIM og DMARC i den delen dokumentasjonen 1 som betegnes «cyberthreat protection». DMARC, SPF og DKIM bruker DNS til å distribuereopplysninger. Det vil være en fordel om også DNSSEC (RFC 4033 m.fl.) er etablert, men DNSSEC er ingen forutsetning for å etablere DMARC. 1 Side 2 av 2

11 VEDLEGG 4 Notat Dato: Saksnr: 18/00643 Til: Rune Karlsen Kopi: Fra: Saksbehandler: Seksjon for informasjonssikkerhet Håkon Styri Saksframlegg til Standardiseringsrådets møte Anbefalt standard for sikkerhet i domenenavnsystem (DNSSEC) Det følgende er forslag til en ny standard for å styrke sikkerheten i domenenavnsystemet (DNS), som er en underliggende funksjon som er viktig for de fleste av dagens digitale tjenester. Standarden kan enten plasseres i de eksisterende bruksområdet Grunnleggende datakommunikasjon eller det kan opprettes et nytt bruksområde med navn Digital infrastruktur. «Det anbefales å benytte Domain Name System Security Extensions (DNSSEC) (RFC 4033, RFC 4034 og RFC 4035 med oppdateringer) for alle domenenavn en virksomhet har registrert, og at det kun benyttes resolvere 1 som validerer DNS-oppslag.» Difi ønsker også å vurdere denne standarden som en obligatorisk standard på et senere tidspunkt. Formålet med standarden Standarden skal bidra til bedre sikkerhet i domenenavnsystemet, og vil redusere risiko for at det oppstår sårbarheter knyttet til bruk av DNS i andre sikkerhetstiltak. Begrunnelse for anbefalingen Formålet med anbefalingen er å styrke integriteten i domenenavnsystemet og på den måten redusere risikoen for flere typer angrep mot digitale tjenester. Den tekniske løsningen er moden og andelen norske domenenavn som allerede er sikret med DNSSEC er rundt 58 prosent. DNSSEC bidrar også til å styrke sikkerheten ved bruk av andre tiltak som DMARC, DKIM, SPF og DANE, ettersom de benytter DNS til lagring av informasjon. DNSSEC bidrar til å sikre integriteten til data fra DNS. For DANE er det en forutsetning at DNSSEC benyttes. 1 Resolvere er tekniske komponenter som brukes når digitale tjenester utfører oppslag i domenenavnsystemet.

12 Kostnader Kostnaden for å bruke DNSSEC vurderes som lav, og etableringskostnader vil i hovedsak være knyttet til virksomheter som har etablert og drifter sin egen DNS-infrastruktur. For andre virksomheter vil standarden medføre at man må velge underleverandører som tilbyr DNSSEC eller som kan dokumentere at de har etablert andre sikkerhetstiltak som beskytter mot de trusler og sårbarheter hvor DNSSEC gir redusert risiko. Hvilke utfordringer DNSSEC ikke løser Det er viktig å påpeke at domenenavn også er knyttet til den utfordringen brukere har med å forsikre seg om at et domenenavn faktisk representerer en virksomhet i offentlig sektor. Norge har kun delvis tatt i bruk kategoridomener (f.eks. kommune.no, herad.no, stat.no og dep.no). Noen virksomheter i offentlig sektor bruker flere domenenavn knyttet til forskjellige tjenester. Noen virksomheter i offentlig sektor bruker internasjonale domenenavn i stedet for eller i tillegg til domenenavn i det norske toppdomenet. Det eksisterer heller ingen samlet og fullstendig oversikt over bruken av de forskjellige domenenavnene. Det er nødvendig å etablere en god domenenavnehygiene i offentlig sektor for å understøtte effekten av andre sikkerhetstiltak, for eksempel bruk av DNSSEC og HTTPS. Side 2 av 2

13 Mottakerliste: Norges Bank Postboks 1179 Sentrum 0107 OSLO Politidirektoratet Postboks 8051 Dep Oslo Buskerud fylkeskommune Postboks Drammen Akershus fylkeskommune Postboks 1200 Sentrum 0107 OSLO Hordaland fylkeskommune Postboks BERGEN Møre og Romsdal Fylkeshuset - Postmottak 6404 Molde fylkeskommune Statsministerens kontor Postboks 8001 Dep Oslo Arbeids- og Postboks 8019 Dep Oslo sosialdepartementet Barne-, likestillings- og Postboks 8036 Dep Oslo inkluderingsdepartementet Finansdepartementet Postboks 8008 Dep OSLO Østfold fylkeskommune Postboks Sarpsborg Fylkesmannen i Buskerud Postboks Drammen Fylkesmannen i Finnmark Statens hus, Damsveien Vadsø Fylkesmannen i Hedmark Postboks Hamar Fylkesmannen i Hordaland Postboks Bergen Fylkesmannen i Møre og Fylkeshuset 6404 Molde Romsdal Fylkesmannen i Nordland Statens Hus, Moloveien BODØ Fylkesmannen i Nord- Postboks Steinkjer Trøndelag Fylkesmannen i Oppland Postboks Lillehammer Fylkesmannen i Oslo og Postboks 8111 Dep OSLO Akershus Fylkesmannen i Rogaland Postboks Stavanger Fylkesmannen i Sogn og Njøsavegen Leikanger Fjordane Fylkesmannen i Sør- Postboks 4710, Sluppen 7468 Trondheim Trøndelag Fylkesmannen i Telemark Postboks Skien Fylkesmannen i Troms Postboks Tromsø Fylkesmannen i Vestfold Postboks Tønsberg Fylkesmannen i Østfold Postboks Moss Forsvarsdepartementet Postboks 8126 Dep 0032 Oslo Helse- og Postboks 8011 Dep 0030 Oslo omsorgsdepartementet Justis- og Postboks 8005 Dep 0030 Oslo beredskapsdepartementet Kommunal- og Postboks 8112 Dep 0032 OSLO moderniseringsdepartementet Kulturdepartementet Postboks 8030 Dep 0030 Oslo Kunnskapsdepartementet Postboks 8119 Dep 0032 Oslo Landbruks- og Postboks 8007 Dep 0030 Oslo matdepartementet Klima- og miljødepartementet Postboks 8013 Dep 0030 OSLO Arbeids- og Postboks 5 St. Olavs plass 0130 Oslo velferdsdirektoratet - NAV Nærings- og fiskeridepartementet Postboks 8090 Dep 0032 OSLO

14 Barne-, ungdoms- og Postboks 8113 Dep Oslo familiedirektoratet Olje- og energidepartementet Postboks 8148 Dep 0033 OSLO Samferdselsdepartementet Postboks 8010 Dep 0030 OSLO Brønnøysundregistrene Postboks BRØNNØYSUND Datatilsynet Postboks 8177 Dep Oslo Utenriksdepartementet Postboks 8114 Dep 0032 OSLO Direktoratet for Postboks Tønsberg samfunnssikkerhet og beredskap Departementenes sikkerhets- Postboks 8129 Dep Oslo og serviceorganisasjon Finanstilsynet Postboks 1187 Sentrum 0107 Oslo Finanstilsynet Postboks 1187 Sentrum 0107 Oslo Fiskeridirektoratet Postboks 185 Sentrum 5804 Bergen Helsedirektoratet Postboks 7000 St. Olavs plass 0130 Oslo Justervesenet Postboks Kjeller Konkurransetilsynet Postboks 439 Sentrum 5805 Bergen Kystverket Postboks Ålesund Lotteri- og stiftelsestilsynet Postboks Førde Luftfartstilsynet Postboks Bodø Mattilsynet Felles postmottakpostboks Brumunddal Nasjonal Postboks Lillesand kommunikasjonsmyndighet Sjøfartsdirektoratet Postboks HAUGESUND Skattedirektoratet Postboks 9200 Grønland 0134 Oslo Statens helsetilsyn Postboks 8128 Dep Oslo Statens legemiddelverk Postboks 63 Kalbakken 0901 Oslo Statistisk sentralbyrå Postboks 8131 Dep Oslo Toll- og avgiftsdirektoratet Postboks 8122 Dep Oslo Utlendingsdirektoratet Postboks 8108 Dep Oslo Utdanningsdirektoratet Postboks 9359 Grønland 0135 Oslo Statens strålevern Postboks Østerås Statens vegvesen Postboks 8142 Dep Oslo Vegdirektoratet Drammen kommune Engene DRAMMEN Statens lånekasse for Postboks 191 Økern 0510 OSLO utdanning Oslo kommune RÅDHUSET 0037 OSLO Oslo kommune Sigmund RÅDHUSET 0037 OSLO Evjen Statens pensjonskasse Postboks 5364 Majorstua 0304 OSLO Sopra Steria AS Postboks OSLO Riksrevisjonen Postboks 8130 Dep OSLO Statens innkrevingssentral - Postboks MO I RANA SISMO Direktoratet for Pb 7154 St. Olavs plass 0130 OSLO økonomistyring Avinor AS Postboks GARDERMOEN Statsbygg Postboks 8106 Dep 0032 OSLO Domstoladministrasjonen Postboks 5678 Sluppen 7485

15 TRONDHEIM Forbrukerombudet Sandakerveien OSLO Forsvaret Postboks 800Postmottak 2617 LILLEHAMMER Innovasjon Norge Postboks 448 Sentrum 0104 OSLO Medietilsynet Nygata FREDRIKSTAD Meteorologisk institutt Bostboks 43 Blindern 0313 OSLO Nasjonal sikkerhetsmyndighet - NSM Postboks BÆRUM POSTTERMINAL Norges forskningsråd Postboks LYSAKER Norges geologiske undersøkelse - NGU Postboks 6315 Sluppen 7491 TRONDHEIM Norges vassdrags- og Postboks 5091 Majorstuen 0301 OSLO energidirektorat - NVE Norsk kulturråd Postboks 8052 Dep 0031 OSLO Oljedirektoratet Postboks STAVANGER Regjeringsadvokaten Postboks 8012 Dep 0030 OSLO Samediggi / Sametinget Àvjovâgeaidnu KARASJOK Norges teknisknaturvitenskapelige universitet - NTNU 7491 TRONDHEIM Statens autorisasjonskontor Postboks 8053 Dep 0031 OSLO for helsepersonell - SAK Statens kartverk 3507 HØNEFOSS Utlendingsnemnda - UNE Postboks 8165 Dep 0034 OSLO Kompetanse Norge Postboks 236 Sentrum 0103 OSLO Økokrim Postboks 8193 Dep 0034 OSLO Alta kommune Postboks ALTA Arendal kommune Postboks 780 Stoa 4809 Arendal Asker kommune Postboks Asker Bergen kommune Postboks BERGEN Bærum kommune Rådhustorget SANDVIKA Drangedal kommune Gudbrandsvei Drangedal EVRY AS Postboks 494 Skøyen 0213 OSLO Kantega AS Marit Collin Erling Skakkes gate TRONDHEIM Fredrikstad kommune Postboks Fredrikstad Halden kommune Postboks HALDEN Hamar kommune Postboks Hamar Universitetet i Bergen Postboks BERGEN Karmøy kommune Rådhuset 4250 Kopervik Kongsberg kommune Postboks Kongsberg Kristiansand kommune Postboks 417 Lund 4604 Kristiansand Kristiansund kommune Postboks Kristiansund N Lillesand kommune Postboks Lillesand Lyngdal kommune Postboks Lyngdal International Business Postboks KOLBOTN Machines AS - IBM Samordna opptak - ( SO ) Postboks OSLO

16 UniBridge AS Rosenholmvn TROLLÅSEN Stavanger kommune Postboks Stavanger Nets Norway AS Morten Haavard Martinsens vei OSLO Gjestad Røyken kommune Katrineåsveien Røyken Helse Sør-Øst RHF Postboks HAMAR Strålfors AS Postbox 253 Alnabru 0614 OSLO IKT-Norge Per Oscarsgate OSLO Morten Hoff Nasjonalbiblioteket Postboks 2674 Solli 0203 Oslo Næringslivets Postboks 5250 Majorstuen 0305 OSLO hovedorganisasjon - NHO Patentstyret - Styret for det Postboks 8160 Dep 0033 OSLO industrielle rettsvern Universitetet i Oslo - UiO Postboks 1072 Blindern 0316 OSLO Vernepliktsverket Postboks 800Postmottak 2617 LILLEHAMMER UiT Norges arktiske Postboks 6050 Langnes 9037 TROMSØ universitet Ål kommune Torget Ål Norsk Akkreditering Postboks Kjeller Sandnes kommune Postboks SANDNES Sarpsborg kommune Postboks Sarpsborg Sørum kommune Postboks Sørumsand Tromsø kommune Postboks TROMSØ Trondheim kommune Postboks 2300 Sluppen 7004 TRONDHEIM Tysvær kommune Postboks Aksdal Norsk Regnesentral Lars Postboks 114 Blindern 0314 Oslo Holden Nasjonalt senter for fri FriprogsenteretPostboks TROMSØ programvare Microsoft Norge AS Postboks LYSAKER Den Norske Dataforening Møllergata OSLO Norsk rikskringkasting AS PB 8500 Majorstuen 0340 OSLO Uninett AS Postboks 4769 Sluppen 7465 TRONDHEIM Standard Norge Postboks LYSAKER Arkivverket Pb Ullevål Stadion 0806 OSLO Norsk tipping AS Postboks 4414 Bedriftssenteret 2325 HAMAR Software Innovation AS Postboks Lysaker BankID Norge Odd Postboks 2644 Solli 0253 Oslo Erling Haberget Bedriftsforbundet Akersgt OSLO Abelia PB 5490 Majorstuen 0305 OSLO Miljødirektoratet Postboks 5672 Sluppen 7485 TRONDHEIM Helse Midt-Norge Postboks STJØRDAL Helse Vest RHF Postboks 303 Forus 4066 STAVANGER Helse Nord RHF 8038 BODØ

17 Norsk Industri Postboks 7072 Majorstuen 0306 OSLO Veterinærinstituttet Postboks 750 Sentrum 0106 OSLO Fagforbundet Postboks 7003 St. Olavs plass 0130 OSLO Norsk eiendomsinformasjon PB 2923 Solli 0230 OSLO Sem & Stenersen Prokom AS Postboks 6900 St. Olavs plass 0130 OSLO Atea AS Postboks 6472 Etterstad 0605 OSLO Det juridiske fakultet - UiO Dag Wiese Postboks 6706 St. Olavs plass OSLO Schartum Juristforbundet Kristian Augustsgt OSLO Deltasenteret, Bufdir Åse Kari Postboks 8113 Dep 0032 OSLO Haugeto Senter for IKT i utdanning Postboks TROMSØ Bankenes Hansteens gt OSLO Standardiseringskontor Hjelpemiddelsentralen Oslo Postboks 324 Alnabru 0614 OSLO og Akershus Norges Blindeforbund Postboks 5900 Majorstuen 0308 OSLO Norges Ingeniør- og Postboks 9100 Grønland 0133 OSLO Teknologorganisasjon - NITO Finans Norge (FNO) Postboks 2473 Solli 0202 OSLO SPAMA Postboks 6900 St. Olavs plass 0130 OSLO Sparebankforeningen Postboks 2521 Solli 0202 OSLO Fosen Regionråd 7170 ÅFJORD Funksjonshemmedes Mariboes gate OSLO fellesorganinsasjon SINTEF IKT Postboks 4760 Sluppen 7465 TRONDHEIM LO Stat Møllergata OSLO Advokatforeningen Juristenes HusKristian Augusts gate OSLO Akademikerne Fridtjof Nansens plass OSLO Næringslivets Postboks LYSAKER sikkerhetsorganisasjon - NSO Samarbeidsforumet av Postboks 8953 Youngstorget 0028 OSLO funksjonshemmedes organisasjoner Terra Gruppen AS Postboks 2349 Solli 0201 OSLO Unio - Hovedorganisasjonen Stortingsgata OSLO for universitets- og høyskoleutdannede Yrkesorganisasjonenes Postboks 9232 Grønland 0134 OSLO Sentralforbund Stiftelsen Åpne c/o Stein LierAkershus 0107 OSLO kontorprogram på norsk fylkeskommunesentraladministrasjonenpostboks 1200 Sentrum Nordea Bank Norge ASA Rune Postboks 1166 Sentrum 0107 OSLO Sjøhelle Norwegian Unix User Group Postboks OSLO NorStella foundation Postboks 6086 Etterstad 0601 OSLO NorStella foundation Terje Postboks 6086 Etterstad 0601 OSLO Olsen Elektronisk Forpost Norge - Thomas CSS Postboks 42Middelthunsgate OSLO EFN Gramstad Thales Norway AS Postboks 744 Sentrum 0106 OSLO

18 Landbruksdirektoratet Postboks 8140 Dep 0033 OSLO Direktoratet for e-helse Postboks 6737 St. Olavs plass 0130 OSLO Fylkesmannen i Aust- og Postboks 788 Stoa 4809 ARENDAL Vest-Agder Bane Nor SF Postboks HAMAR Jernbanedirektoratet Postboks 16 Sentrum 0101 OSLO