Veileder for etablering

Her finner du formålet med hver av fire sikkerhetsrelaterte forvaltningsstandarder og hvordan de bør iverksettes på systemene hvor de skal brukes.

    De fire forvaltningsstandardene er hentet fra bruksområdet «Grunnleggende datakommunikasjon» i Referansekatalogen for IT-standarder. I denne veilederen har vi gjengitt hoveddelen av anbefalingene. For hver anbefaling i referansekatalogen er det lenker til de relevante tekniske spesifikasjoner fra organisasjonen Internet Engineering Task Force (IETF).

    Vær oppmerksom på at tekniske spesifikasjoner eller standarder gjerne viser til andre spesifikasjoner eller standarder. Referansekatalogen for IT-standarder utgjør bare en delmengde av alle de standarder som er relevante for å styrke sikkerheten. Vi vil derfor i størst mulig grad vise til veiledninger fra Nasjonal sikkerhetsmyndighet (NSM) ettersom disse også omtaler sikkerhetstiltak som ikke er omtalt i referansekatalogen. NSM har publisert slike veiledere på nettsiden «Råd for systemteknisk sikkerhet».

    I teksten som følger er hver forvaltningsstandard fulgt av en punktliste, hvor hvert punkt viser til en teknisk spesifikasjon eller en egenskap som skal testes. Hvordan testing kan utføres er beskrevet i veilederen om testing av etterlevelse.

    For hver forvaltningsstandard er det beskrevet et eksempel på en uønsket hendelse den enkelte standarden reduserer risikoen for. Merk at dette er enkle eksempler og ingen uttømmende liste over hvordan en sårbarhet kan utnyttes. Hva som vil være den alvorligste uønskede hendelsen vil variere fra virksomhet til virksomhet. Det er derfor ikke gitt at eksempelet som er brukt i denne veilederen er den alvorligste uønskede hendelsen som kan følge av sårbarheten. Vi vil også understreke at når to eller flere sårbarheter kan utnyttes i kombinasjon vil dette gi flere muligheter for en trusselaktør.

    Anbefalte standarder for sikker datakommunikasjon

    HTTPS med HSTS

    Det anbefales at offentlige kommunikasjonstjenester har støtte for HTTP over TLS [RFC 2818] ved bruk av protokollene HTTP/1.1 [RFC 7230 til RFC 7235] og TLS 1.3 [RFC 8446].

    Dersom en tjeneste får en forespørsel med bruk av HTTP uten bruk av sikker overføring med bruk av TLS skal tjenesten svare ved omdirigering til samme URI med bruk av HTTP over TLS.

    Det anbefales også at HTTP Strict Transport Security [RFC 6797] blir brukt, men dersom den ansvarlige for nettstedet har behov for å logge omdirigeringer er dette tilstrekkelig begrunnelse for ikke å bruke RFC 6797 i perioden hvor det logges.

    Formål

    Hypertext Transport Protocol Secure (HTTPS) bruker kryptert kommunikasjon mellom nettstedet og brukerens nettleser. Dette reduserer risikoen for at uvedkommende får innsyn i opplysninger som sendes fra nettsted til bruker og fra bruker til nettsted. Det reduserer også risikoen for at uvedkommende kan endre opplysningene under overføringen og risikoen for at brukeren kommuniserer med et forfalsket nettsted.

    Mekanismen HTTP Strict Transport Security (HSTS) skal bidra til at HTTPS alltid brukes i kommunikasjonen med nettstedet.

    Et eksempel på en uønsket hendelse er at en trusselaktør endrer opplysningene som overføres fra nettsted til bruker som et forsøk på å legge inn skadevare på brukerens maskin. For en trusselaktør kan dette være et alternativ til å bruke phishing gjennom e-post for å spre skadevare.

    Risikoen for denne typen angrep er særlig høy når brukeren har trådløs tilknytning til nettet, men etter lekkasjer som omhandler verktøy brukt av flere lands etterretningstjenester de seneste årene er det helt klart en risiko for denne typen angrep uansett hvordan brukeren har koblet seg til Internett.

    Hypertext Transport Protocol Secure (HTTPS)

    HTTPS er en teknisk standard (RFC 2818 fra IETF) hvor protokollen HTTP blir overført kryptert ved bruk av Transport Layer Security (TLS). Vanligvis brukes TCP/IP-port 443 for denne overføringen. HTTP uten kryptering bruker vanligvis port 80. Vi viser til veiledning fra NSM. Se kapittel 2 «Om HTTPS» i «Hypertext Transport Protocol Secure», IT-veiledning for ugraderte systemer nr. 15 (U-15), 2016-10-20, NSM.

    Omdirigering

    Omdirigering gjøres når en nettleser (eller annen type klient) bruker HTTP uten kryptering for å sende en forespørsel til et nettsted. Omdirigeringen skal indikere en permanent flytting av nettsiden (status 301) til en side på samme nettsted med bruk av HTTPS.

    Vær oppmerksom på at «www.example.com» og «example.com» er adresser som i praksis er to forskjellige nettsted. En omdirigering fra HTTP til HTTPS skal ikke gjøres mellom to forskjellige nettsted dersom vi ønsker å teste etterlevelse av standardene.

    HTTPS Strict Transport Security (HSTS)

    HSTS er en teknisk standard som i praksis er et direktiv fra nettstedet som forteller alle klienter (nettlesere eller andre applikasjoner) at nettstedet kun svarer på forespørsler over HTTPS. Vi viser til veiledning fra NSM om HSTS. Se kapittel 3.4 i «Hypertext Transport Protocol Secure», IT-veiledning for ugraderte systemer nr. 15 (U-15), 2016-10-20, NSM.

    Transport Layer Security (TLS)

    TLS er en kryptografisk protokoll som gjør det mulig å sikre overføring av data mellom flere typer applikasjoner, bl.a. mellom nettlesere og nettsteder, og mellom e-post servere. Det er laget flere versjoner av TLS. Standardene i Referansekatalogen for IT-standarder anbefaler kun versjon 1.2 eller nyere. Vi viser til to veiledninger fra NSM om bruk av TLS. Se kapittel 3.2 «Benytt TLS på en sikker måte» i «Hypertext Transport Protocol Secure», IT-veiledning for ugraderte systemer nr. 15 (U-15), 2016-10-20, NSM og «Sikring av kommunikasjon med TLS», IT-veiledning for ugraderte systemer nr 14 (U-14), 2016-09-30, NSM.

    Server Name Indication (SNI)

    Dersom versjon 1.2 av TLS brukes og nettstedet bruker en IP-adresse som har flere navn og dermed kan ha flere sertifikater er det nødvendig å bruke mekanismen Server Name Indication (SNI) slik at TLS får det riktige sertifikatet til nettstedet for å kryptere overføringen av data. SNI er beskrevet i kapittel 3 av den tekniske standarden RFC 6066 far IETF.

    Sertifikat

    For at HTTPS skal virke er det nødvendig at nettstedet har et gyldig digitalt sertifikat som er tilknyttet maskinnavnet. Vi viser til veiledning fra NSM når det gjelder valg av sertifikater. Se kapittel 3.1 i «Hypertext Transport Protocol Secure», IT-veiledning for ugraderte systemer nr. 15 (U-15), 2016-10-20, NSM.

    Anbefalt standard for transportsikring av e-post

    Transportsikring av e-post

    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.

    Det anbefales også at «SMTP TLS Reporting» [RFC 8460] brukes.

    Formål

    Transportsikring av e-post bruker kryptert kommunikasjon for å overføre meldinger mellom e‑post servere. Dette reduserer risikoen for at en uvedkommende får innsyn i e‑post. Det reduserer også risikoen for at en trusselaktør kan endre opplysningene under overføringen.

    Et eksempel på en uønsket hendelse er at en trusselaktør kopierer opplysninger som sendes med e‑post til og fra en eller flere virksomheter eller personer. En trusselaktør kan bruke opplysninger som avdekkes på denne måten til for eksempel å planlegge et digitalt angrep mot en eller flere virksomheter.

    STARTTLS

    Flere kommunikasjonsprotokoller bruker en kommando STARTTLS for å be om at en usikret forbindelse blir oppgradert til en forbindelse sikret med bruk av Transport Layer Security (TLS). Dette kalles for opportunistisk TLS. For protokollen Simple Mail Transfer Protocol (SMTP) er STARTTLS beskrevet i den tekniske standarden RFC 3207 fra IETF. Vi viser til veiledning fra NSM. Se kapittel 3.1 i «Grunnleggende tiltak for sikring av e-post», 2017, NSM.

    Transport Layer Security (TLS)

    TLS er en kryptografisk protokoll som gjør det mulig å sikre overføring av data mellom flere typer applikasjoner, bl.a. mellom nettlesere og nettsteder, og mellom e-post servere. Det er laget flere versjoner av TLS. Standardene i Referansekatalogen for IT-standarder anbefaler kun versjon 1.2 eller nyere. Vi viser til veiledning fra NSM om TLS. Se «Sikring av kommunikasjon med TLS», IT-veiledning for ugraderte systemer nr 14 (U-14), 2016-09-30, NSM.

    Sertifikat

    For å sikre at innkommende e-postmeldinger kan dekrypteres er det nødvendig med et gyldig digitalt sertifikat tilknyttet virksomhetens e-post servere. Vi viser til veiledning fra NSM når det gjelder valg av sertifikater. Se kapittel 3.2 i «Grunnleggende tiltak for sikring av e-post», 2017, NSM.

    DNS-based Authentication of Named Entities (DANE)

    DANE er en protokoll som gjør det mulig å knytte digitale sertifikater som brukes av TLS til domenenavn gjennom bruk av en sikker utvidelse av domenenavnsystemet (DNSSEC). DANE er et sikkerhetstiltak som skal hindre at kommandoen STARTTLS blir fjernet av en mellommann når forbindelsen mellom e-post servere settes opp. Bruk av DANE for Simple Mail Transfer Protocol (SMTP) er beskrevet i den tekniske standarden RFC 7672 fra IETF.

    SMTP TLS Reporting (TLS-RPT)

    TLS-RPT er en mekanisme hvor e-post server som forsøker å sende en e-post kan sende en statusrapport til e-post server som skal motta melding dersom det ikke var mulig å etablere en sikker forbindelse med TLS. Den første delen TLS-RPT er å etablere mekanismen for å motta meldinger med rapporter. Standarden gir to alternativer hvor det ene er å annonsere en e‑postadresse. SMTP TLS Reporting (TLS-RPT) er beskrevet i den tekniske standarden RFC 8460 fra IETF.

    Anbefalte standarder for å motvirke falske avsendere av e-post

    DMARC med SPF og DKIM

    Det anbefales å benytte Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) og minst en av de underliggende standardene Sender Policy Framework (SPF) (RFC 7208) og Domain Keys Identified Mail (DKIM) (RFC 6376) 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.

    Det anbefales at man for domener som ikke benyttes til sending av e-post bruker Sender Policy Framework (SPF) for å angi at det ikke sendes e-post fra domenet.

    Formål

    Formålet med DMARC er å etablere en mekanisme som gjør det enklere for mottaker å avgjøre om en melding faktisk er sendt fra avsenderadressen som er angitt i meldingen. Avsendere kan publisere hvilke mekanismer (SPF og/eller DKIM) som brukes og gi en anbefaling om hva mottager bør gjøre med meldinger som ikke autentiseres.

    Når eieren av et domene bruker DMARC kan mottagere av e-post ha større tillit til at meldinger som angir e‑postadresser på dette domenet er sendt fra en bruker på dette domenet. Det reduserer risikoen for at avsenderadressen er forfalsket, men det er viktig å merke seg eieren av et hvert domene kan etablere DMARC. Derfor vil ikke bruk av DMARC i seg øke tilliten til hva et domene brukes til. DMARC bidrar kun til å redusere risikoen for at en avsenderadresse er forfalsket.

    DMARC etablerer også en mekanisme hvor eier av et domene kan motta rapporter om meldinger som er stoppet med i forsøk på å bruke domenet som falsk avsenderadresse.

    Et eksempel på en uønsket hendelse er at en trusselaktør sender en melding med falsk avsender, for eksempel en offentlig eller privat virksomhet. Mottaker av en slik melding kan ta beslutninger og utføre handlinger på grunnlag av innholdet i slike meldinger. Et eksempel på denne typen melding er en trusselaktør sender ut en falsk pressemelding til avisredaksjoner og angir en offentlig virksomhet som avsender.

    Domain-based Message Authentication, Reporting and Conformance (DMARC)

    DMARC er en protokoll som gir eier av domenenavn mulighet til å beskytte domenenavnet fra uautorisert bruk av fremmede e-post servere. DMARC er beskrevet i det tekniske dokumentet RFC 7489. DMARC bruker to mekanismer for autentisering av e-post: Sender Policy Framework (SPF) og DomainKeys Identified Mail (DKIM). Vi viser til veiledning fra NSM om bruk av DMARC. Se anbefaling 4 «Domain based Message Authentication, Reporting and Conformance (DMARC)» i «Grunnleggende tiltak for sikring av e-post», 2017, NSM.

    Sender Policy Framework (SPF)

    SPF er en mekanisme som angir hvilke e-post servere som er autorisert av den rettmessige eier av domenenavnet til e-postens avsender. Den tekniske mekanismen som brukes er beskrevet i RFC 7208. Vi viser til veiledning fra NSM om bruk av SPF. Se anbefaling 2 «Sender Policy Framework (SPF)» i «Grunnleggende tiltak for sikring av e-post», 2017, NSM.

    DomainKeys Identified Mail (DKIM)

    DKIM er en mekanisme for å autentisere at en e-post er sendt fra en e-post server som er autorisert av rettmessig eier av domenenavnet til e-postens avsender. Den tekniske mekanismen som brukes er en digital signatur. DKIM er beskrevet i den tekniske standarden RFC 6376. Vi viser til veiledning fra NSM om bruk av DKIM. Se anbefaling 3 «DomainKeys Identified Mail (DKIM)» i «Grunnleggende tiltak for sikring av e-post», 2017, NSM.

    Anbefalte standarder for sikker bruk av domenenavnsystemet

    DNSSEC

    Det anbefales å benytte Domain Name System Security Extensions (DNSSEC) [RFC 4033, RFC 4034 og RFC 4035] for alle domenenavn en virksomhet har registrert, og at det kun benyttes resolvere som validerer DNS-oppslag.

    Formål

    Formålet med DNSSEC er å redusere risikoen for brudd på integriteten ved oppslag i domenenavnsystemet (DNS). DNSSEC gjør det mulig å kontrollere at svarene på oppslag i domenenavnsystemet (DNS) kommer fra riktig kilde og ikke er endret underveis. Svar på oppslag i DNS omfatter IP-adresser, navn på e-post servere, sertifikat dersom dersom DNS-Based Authentication of Named Entities (DANE) benyttes, opplysninger knyttet til Sender Policy Framework (SPF), opplysninger knyttet til Domain-based Message Authentication, Reporting and Conformance (DMARC) og eventuelt andre opplysninger knyttet til andre standarder.

    I sammenheng med økende antall rapporter om skadelig aktivitet rettet mot DNS-infrastrukturen har Internet Corporation for Assigned Names and Numbers (ICANN) bedt om at alle tar i bruk DNSSEC, se pressemelding datert 2019-02-22.

    Formålet DNSSEC er å redusere risikoen for brudd på integriteten ved oppslag i domenenavnsystemet (DNS). DNSSEC gjør det mulig å kontrollere at svarene på oppslag i domenenavnsystemet (DNS) kommer fra riktig kilde og ikke er endret underveis. Svar på oppslag i DNS omfatter IP-adresser, navn på e-post servere, sertifikat dersom dersom DNS-Based Authentication of Named Entities (DANE) benyttes, opplysninger knyttet til Sender Policy Framework (SPF), opplysninger knyttet til Domain-based Message Authentication, Reporting and Conformance (DMARC) og eventuelt andre opplysninger knyttet til andre standarder.

    I sammenheng med økende antall rapporter om skadelig aktivitet rettet mot DNS-infrastrukturen har Internet Corporation for Assigned Names and Numbers (ICANN) bedt om at alle tar i bruk DNSSEC, se pressemelding datert 2019-02-22.

    Domain Name System Security Extensions (DNSSEC)

    DNSSEC er en utvidelse av domenenavnssystemet (DNS) som sikrer integriteten når maskinnavn oversettes til en IP-adresse. Referansekatalogen anbefaler at DNSSEC brukes til alle tjenester. Dette betyr at virksomheter må registrere alle sine domenenavn hos en registrar som tilbyr DNSSEC.

    For e-post er det også nødvendig at domenenavnet til e-post server er registrert med bruk av DNSSEC. Når en virksomhet kjøper e-posttjenesten fra en underleverandør, må derfor underleverandøren registrere domenenavn for sine e-post servere med DNSSEC.

    Vi viser til informasjon fra NSM og Norid. Se kapittel 2 «Anbefalte tiltak» i «Grunnleggende tiltak for sikring av e-post», 2017, NSM og «Dette er DNSSEC», 2019, Norid.

    Eksterne referanser

    Kontakt

    Kompetansemiljø for informasjonssikkerhet