Versjon

Dato

Beskrivelse

1.0

28. august 2017

Versjon 1.0 ferdigstilt

1.1

1. november 2018

Versjon 1.1 ferdigstilt

2.0

15. april 2020

Versjon 2.0 ferdigstilt

ID

Beskrivelse

1.1.1

Identifiser virksomhetens strategi og prioriterte mål, samt regelverk, bransjenormer og avtaler som kan ha innvirkning på sikring av informasjonssystemer.

1.1.2

Identifiser virksomhetens strukturer og prosesser for sikkerhetsstyring.  Dette inkluderer normalt a) policyer fra ledelsen, b) ledelsesstruktur med veldefinert ansvar og ansvarslinjer, c) prosesser for risikostyring (se 1.1.3) d) fastsatte toleransegrenser for risiko (se 1.1.4), e) tilføring av tilstrekkelige ressurser og fagkompetanse for å støtte ledelsen i arbeidet. 

f) Etabler strukturer og prosesser for sikkerhetsstyring dersom dette mangler. Sørg for at det tilpasses virksomheten og er en inkludert del av virksomhetsstyringen. Se «Utdypende informasjon» for ytterligere informasjon.

1.1.3

Identifiser virksomhetens prosesser for risikostyring knyttet til IKT. Dette inkluderer normalt a) verdivurdering, b) trusselvurdering, c) kartlegge eksisterende sikkerhetstiltak, d) risikoidentifisering, e) risikovurdering, f) risikorapportering, g) risikohåndtering, h) etablere eller

justere sikkerhetstiltak for å redusere risiko g) verifisere at sikkerhetstiltakene fungerer etter hensikt.

h) Etabler prosesser for risikostyring dersom dette mangler. Sørg for at prosessene tilpasses virksomheten og er en inkludert del av virksomhetsstyringen og sikkerhetsstyringen. Se «Utdypende informasjon» for ytterligere informasjon.

1.1.4

Identifiser virksomhetens toleransegrenser for risiko knyttet til IKT. Ledelsen må fastsette hvilke grenser for risiko virksomheten aksepterer og hva som er uakseptabel risiko. Dette må kommuniseres på tvers i organisasjonen. Det er vanlig å fastsette risikogrenser basert på konsekvens for virksomheten ved tap av konfidensialitet, integritet og tilgjengelighet for informasjon og informasjonssystemer. Se 4.1.1, 4.1.2 og «Utdypende informasjon» for ytterligere informasjon.

1.1.5

Kartlegg virksomhetens leveranser, informasjonssystemer og understøttende IKT-funksjoner.  Kartlegg a) IKT-systemer, data og tjenester, inkludert eierskap, b) kritiske forretningsroller og c) interne og eksterne IKT-avhengigheter. d) Gruppér i henhold til virksomhetens risikoaksept (1.1.4) og bruk resultatet som grunnlag for etablering av en sikker IKT-arkitektur, se prinsipp 2.2 - Etabler en sikker IKT-arkitektur.

1.1.6

Kartlegg informasjonsbehandling og dataflyt i virksomheten. Kartlegg informasjonsflyt mellom arbeidsprosesser, brukere, enheter og tjenester og bruk resultatet som grunnlag for etablering av en sikker IKT-arkitektur, se prinsipp 2.2 - Etabler en sikker IKT-arkitektur.

ID

Beskrivelse

1.2.1

Etabler en prosess for å kartlegge enheter og programvare som er i bruk i virksomheten. Benytt fortrinnsvis automatiserte og sentraliserte verktøy til å oppdage og holde oversikt over enheter og programvare, og vise hvilke programvare som er på hvilke enheter. Oversikten bør også inkludere eierskap, eldre ikke-støttede produkter (bør merkes eksplisitt), samt enheter og programvare som ikke er koblet til virksomhetens nettverk (f.eks. USB-enheter). Dette utdypes i 1.2.3 (enheter) og

1.2.4 (programvare).

1.2.2

Fastsett retningslinjer for godkjente enheter og programvare i virksomheten. a) Virksomheten bør f.eks. avgjøre i) hva slags enheter og programvare som ansatte har behov for, ii) hva som det ikke er tjenstlig behov for men likevel lov, iii) hva som er uønsket og iv) hvordan dette skal håndteres i virksomheten. b) Utarbeid og vedlikehold en oversikt over enheter og programvare godkjent for bruk i virksomheten (inkludert hvis hensiktsmessig versjonsnummer). Vurder behov opp imot anbefalte tiltak i prinsipp 2.1-2.3. c) Kommuniser retningslinjene til ansatte. Beskriv formål og lovlig bruk av enheter og programvare.

1.2.3

Kartlegg enheter i bruk i virksomheten iht. prosess i 1.2.1. a) Kartlegg informasjon etter en hensiktsmessig vurdering, for eksempel nettverksadresse, maskinvareadresse, enhetsnavn, avdelingstilknytning, samt om enhetene er forvaltet av virksomheten. Hver enhet som har en IPadresse på nettverket bør være med i oversikten, inkludert stasjonære og bærbare datamaskiner, servere, nettverksutstyr (rutere, svitsjer, brannmurer, osv.), skrivere, lagringsnettverk, IPtelefoner, IoT-enheter, osv. b) Få oversikt over alle mobile enheter og lagringsmedier som benyttes utenfor virksomhetens nett som inneholder virksomhetsinformasjon. c) Lag en plan for håndtering av enheter som ikke er godkjent for bruk i virksomheten (se 1.2.2). For håndtering se

2.4.1.b. d) Virksomheten bør også ha oversikt over virtuelle enheter (enten de kjører hos virksomheten eller i en leverandørs «sky»). I mange tilfeller bør oversikten da være litt overordnet hvis «levetid» på virtuelle enheter er variabel/dynamisk, f.eks. «stateless» «Virtual Desktops». Oversikt over virtuelle enheter som kjører hos en leverandør er primært kun hensiktsmessig ifm. kjøp av «IaaS».

Ved mest mulig konsekvent bruk av hvitelisting av alle enheter (og/eller alle kablede og trådløse nettverksforbindelser) i virksomhetens nettverk kan kartlegging av enheter bli enklere enn beskrevet over. Se og prinsipp 2.4 - Beskytt virksomhetens nettverk.

1.2.4

Kartlegg programvare i bruk i virksomheten iht. prosess i 1.2.1. a) Kartlegg firmware, operativsystem og applikasjoner (navn, versjonsnummer, produsent, installasjonsdato, om den støttes lengre) som er installert på servere, klienter og nettverksutstyr med mer. b) Lag en plan for håndtering av programvare som skal godkjennes for bruk i virksomheten (se 1.2.2).

Ved mest mulig konsekvent bruk av hvitelisting (spesielt mht. klienter) av alle applikasjoner (alternativt bruk av applikasjonsbutikker) kan kartlegging av programvare gjøres enklere enn beskrevet over.

ID

Beskrivelse

                   Dette prinsippet leses sammen med prinsipp 2.6 - Ha kontroll på identiteter og tilganger

1.3.1

Kartlegg brukere i informasjonssystemene, inkludert: a) brukeridentitet, b) arbeidslokasjon(er) c) tilgangsbehov til IKT-systemer, tjenester/applikasjoner d) spesielle rettighetsbehov, se 1.3.2. Se og prinsipp 2.2 - Etabler en sikker IKT-arkitektur og 2.6 - Ha kontroll på identiteter og tilganger.

1.3.2

Kartlegg og definer de ulike brukerkategoriene som finnes i virksomheten for å definere tilgangsnivåer og behov for oppfølging og kontroll. Eksempler på brukerkategorier kan være:

•       Normale brukere som kun har behov for kontorstøtte.

•       Brukere med spesialbehov, med behov for utvidede rettigheter, f.eks. utviklere.

•       Brukere som drifter virksomhetens systemer.

•       Leverandører og konsulenter. 

       Systembrukere, f.eks. systemprosesser som sikkerhetskopiering og lignende som går i bakgrunnen.

1.3.3

Kartlegg ansvar og roller spesielt knyttet til IKT-sikkerhet. a) Dette gjelder ansvar internt i virksomheten: f.eks. sikkerhetssjef, IT-sjef, applikasjonsansvarlig, plattformansvarlig mm. b) Klargjør hvem som skal kontaktes ved hendelser. Se 4.1.1 og 4.1.3. c) Kartlegg  roller og oppgaver som innehas av eksterne leverandører og partnere.

ID

Beskrivelse

Anskaffelse av IKT-produkter

2.1.1

Integrer sikkerhet i virksomhetens prosess for anskaffelser. Fastsett krav til IKT-sikkerhet ved anskaffelse av alle IKT-produkter og IKT-tjenester, se prinsipp 2.2 - Etabler en sikker IKT-arkitektur.

Inkluder sikkerhet i hele livsløpet fra anskaffelse til avhending.

2.1.2

Kjøp moderne og oppdatert maskin- og programvare slik at nyere sikkerhetsfunksjonalitet er innebygd. Sørg for a) å kun benytte IKT-produkter som støttes og mottar sikkerhetsoppdateringer fra leverandør b) å kun anskaffe IKT-produkter som inneholder nyere sikkerhetsfunksjonalitet og protokoller og c) at eldre IKT-produkter fases ut. d) Der det er hensiktsmessig bør man be leverandør (som kjenner IKT-produktet best) i) å informere om risikoer og sårbarheter produktet kan utsettes for og ii) spesifisere nærmere hvordan IKT-produktet kan sikkerhetsherdes og beskyttes. 

2.1.3

Foretrekk IKT-produkter som er sertifiserte og evaluert av en tiltrodd tredjepart. Et eksempel på et sertifiseringsregime er Common Criteria^[4].      

2.1.4

Reduser risiko for målrettet manipulasjon av IKT-produkter i leverandørkjeden. a) Virksomheter bør vurdere risiko for om de kan bli utsatt for slike målrettede angrep. b) Be nasjonale forhandlere/importører vise diskresjon, og ikke videreformidle for mye kundeinformasjon, f.eks. kundenavn, hvordan produktet skal benyttes, hvem som skal benytte produktet, hvor produktet skal benyttes. c) Beskytt produktintegritet til fysiske produkter (i dialog med nasjonale forhandlere/importører) så tidlig som mulig i leverandørkjeden. Produkter bør inspiseres av alle nasjonale ledd (også hos kunden før produksjonssetting) for brutte forseglinger og oppbevares slik at kun et begrenset sett av personell har fysisk adgang. d) Programvare-produkter bør kun lastes ned fra leverandørens offisielle webside (kun via https). Virksomheten bør oppbevare all installasjonsprogramvare i fil-mapper hvor kun installasjonsansvarlig har skriverettigheter. e)

Leverandørers fysiske adgang ifm. vedlikehold av IKT-produkter bør reguleres og kontrolleres.   

Utvikling og test mht. egen programvareutvikling 

2.1.5

Benytt en metode for sikker utvikling av programvare for å redusere sårbarhetene i programvaren. Dette inkluderer: a) Hensiktsmessig planlegging, inkludert virksomhetens behov, rammebetingelser, IKT-sikkerhets hensyn og behov for opplæring av personell. b) Analyse av brukerbehov, inkludert IKT-sikkerhetskrav. c) Design av programvare basert på fastsatte krav, d)

Utvikling av programvaren, inkludert sikker koding og testing (se 2.1.6 og 2.1.7). e) Implementasjon og idriftsetting av programvaren. f) Sikkerhetsmessig forvaltning av programvaren, bl.a. i) planlegge for gjennomføring og distribusjon av sikkerhetsoppdateringer og ii) planlegge støtte for nyere og mer tidsriktig sikkerhetsfunksjonalitet. 

2.1.6

Benytt separate miljøer for utvikling, test og produksjon slik at operative virksomhetsprosesser og data ikke blir påvirket ved feil i utviklings- og testløp. Vurder også soneinndeling som beskrevet i tiltak 2.2.3. Sensitive produksjonsdata bør bare benyttes på utviklings- og testmiljø som er sikret.

2.1.7

Gjennomfør tilstrekkelig med testing gjennom hele utviklingsprosessen. Gjør dette slik at feil, sårbarheter og mangler rettes opp før idriftsetting. a) Dette inkluderer test av at sikkerhetsfunksjonalitet fra forskjellige berørte IKT-produkter fungerer godt sammen, ref. prinsipp

2.2 - Etabler en sikker IKT-arkitektur, samt enhetstesting, integrasjonstesting, systemtest, akseptansetest, pilottest, inntrengingstest(prinsipp 0) og stresstest. b) Utfør kontroll på at kun tillate handlinger virker samt stikkprøver på at andre handlinger blir avvist. 

2.1.8

Vedlikehold programvarekode som utvikles/benyttes i virksomheten. a) Ha en utviklingsprosess som inneholder metodisk sikkerhetsvurdering av koden. b) Vær spesielt oppmerksom på kode som har spesiell betydning for sikkerheten, f.eks. kode for i) tilgangskontroll, ii) kryptering av trafikk, iii) logging, iv) «parsing» av bruker-input, v) «buffer overflow», med mer. Se [2] og [9].  c) Ved bruk av offentlig tilgjengelig kode («open source») og kommersielle «toolkits» bør virksomheten regelmessig (fortrinnsvis automatisk) sjekke for nye versjoner. d) Ved bruk av DevOps/DevSecOps bør også sikkerhetssjekk av egen kode automatiseres der det er hensiktsmessig. Spesielt sikkerhetsrelevant kode (ref. forrige punkt) bør kvalitetssikres.

Tjenesteutsetting – herunder bruk av skytjenester  

2.1.9

Ta ansvar for virksomhetens sikkerhet også ved tjenesteutsetting. Dette inkluderer å a) ha oversikt og kontroll på hele livsløpet til tjenesten(e) som skal settes ut,

 b) ivareta behovet for bestillerkompetanse (f.eks. forvaltning-, administrasjon- og ITarkitekturkompetanse) gjennom hele livsløpet til tjenesteutsettingen c) gjennomføre gode risikovurderinger som inkluderer IKT og hensyntar hele livsløpet, d) utarbeide et kravdokument for alle faser av tjenesteutsettingen hvor krav kan verifiseres, e) avtaler om tjenesteutsetting av IKT-tjenester og endringer i slike avtaler skal behandles i henhold til virksomhetens fullmaktsstruktur. 

Se også kapittel I - Bruk av tjenesteutsetting og skytjenester og [1]. 

Det understrekes at virksomhetens ansvar for sikkerheten ikke forsvinner selv om man tjenesteutsetter. Virksomheten har et ansvar uavhengig av hvem som utfører de forskjellige oppgavene. 

2.1.10

Undersøk sikkerheten hos tjenesteleverandør ved tjenesteutsetting. Det bør som minimum undersøkes om leverandøren:

a)       har et etablert styringssystem for informasjonssikkerhet og eventuelt sertifisering i henhold til internasjonale standarder, for eksempel ISO/IEC 27001:2017.

b)       gir innsyn i sikkerhetsarkitekturen som benyttes for å levere tjenesten.

c)       har utviklingsplaner for fremtidig sikkerhetsfunksjonalitet i tjenestene i tråd med utvikling i teknologi og trusselbildet over tid.

d)       har en oversikt over hvem som skal ha innsyn i virksomhetens informasjon, hvor og hvordan denne skal behandles og lagres samt grad av mekanismer for segregering fra andre kunder.

e)       har sikkerhetsfunksjonalitet som tilfredsstiller virksomhetens behov.

f)        har sikkerhetsovervåkning for å avdekke sikkerhetshendelser som kan påvirke virksomheten.

g)       har rutiner for hendelseshåndtering og avviks- og sikkerhetsrapportering.

h)       har krise- og beredskapsplaner som skal harmonisere med virksomhetens egne planer.

i)         har godkjenningsprosedyrer for bruk av underleverandører og deres bruk av underleverandører.

j)         har spesifisert hvilke aktiviteter som skal utføres ved terminering av kontrakten, blant annet tilbakeføring/flytting/sletting av virksomhetens informasjon.

Les mer i NSMs rapporter om tjenesteutsetting, se [1].

ID

Beskrivelse 

2.2.1

Etabler og vedlikehold en helhetlig sikkerhetsarkitektur som ivaretar et sikkert og forsvarbart IKT-system. Følgende funksjoner i et IKT-system bør implementeres, sikres og fungere godt sammen sikkerhetsmessig:

a)                   Funksjonalitet for å styre brukere og kontoer

b)                  Funksjonalitet for å ha kontroll og oversikt på enheter (f.eks. klienter)

c)                   Funksjonalitet for å styre tilgang til ressurser og tjenester

d)                  Funksjonalitet for å ha kontroll på programvare (spesielt på klienter)   e) Operativsystemer

f)        Verktøy for drift og virtualisering av hele eller deler av IKT-arkitekturen («on-prem» og «sky»)

g)       Nettverksenheter (svitsjer, rutere, aksesspunkter) og brannmurer

h)       Mekanismer for å håndtere skadevare (antivirus)

i)         Kryptografiske moduler

j)         Digitale sertifikater og Public Key Infrastructure (PKI)

k)       Databaser

l)         Verktøy for systemovervåkning

m)     Verktøy for styring av sikkerhetskonfigurasjoner

n)       Intrusion detection (IDS) og protection (IPS) systemer

o)       Sikkerhetskopiering og gjenoppretting

p)       Maskinvare og fastvare (firmware)

Alle funksjonene nevnt over bør kunne driftes mest mulig sentralisert og mest mulig automatisert der det er hensiktsmessig.

2.2.2

Bygg IKT-systemet med IKT-produkter som fungerer godt sammen sikkerhetsmessig. 

a)                  Produktene bør være modulbaserte (mulighet for å aktivere kun nødvendig funksjonalitet).  

b)                  Produkter bør følge bransjestandarder mest mulig mht. sikkerhetsfunksjoner som tilgangskontroll, logging, drift, kodekontroll, ressursstyring og tilgjengelighetsfunksjoner slik at de fungerer godt med andre sikkerhetsfunksjoner, se 2.2.1. c) Produkter bør (selv om de er fra ulike leverandører) fungere godt sammen sikkerhetsmessig. Spesielt bør IKT-produkter gjenbruke identiteter (til brukere og enheter) hentet fra en felles kilde av virksomhetens identiteter, i stedet for å implementere egne produkt- eller applikasjonsspesifikke identiteter.

2.2.3

Del opp virksomhetens nettverk etter virksomhetens risikoprofil. Etabler oppdeling i soner med ulike behov for kommunikasjon, eksponering, funksjon og roller. Eksempelvis kan man vurdere egne soner for system-administrasjon, applikasjons-servere, virksomhets-driftede klienter, industri-produksjon (f.eks. SCADA og industrielle kontrollsystemer), internett-aksess, trådløse nett, gjeste-klienter og eksternt tilgjengelige tjenester (f.eks. webserver). I datasentre kan servere deles opp i sikkerhetsmessige grupper som data-sone (nytte-trafikk), kontroll-sone (styring av nettverket) og drifts sone (manuell drift). Man kan og vurdere en nettverksarkitektur med enda mer finmasket oppdeling av soner, f.eks. pr. avdeling, eller hver gruppe av enheter. Merk at oppdeling i soner kan skje på flere måter: VLAN-soner, virtualiserte nett, mikrosegmentering, mm. Drift av soner bør skje sentralt, ikke lokalt på hver svitsj. Bruk den valgte soneoppdelingen til å styre dataflyt, se prinsipp 2.5 - Kontroller dataflyt.

2.2.4

Skill fysisk de mest kritiske del-nettverkene. Særskilt sensitive del-nettverk bør vurderes å bli fysisk adskilt fra resten av virksomhetens nettverk («air gap»).

2.2.5

Del opp domenearkitekturen iht. virksomhetens behov. Som minimum bør klienter holdes adskilt fra virksomhetens servere.

2.2.6

Reguler tilgang til tjenester basert på kjennskap til både brukere og enhet. Et eksempel er at en bruker som logger seg på via en ikke-forvaltet enhet (virksomheten stoler på bruker, men kontrollerer ikke enheten) får tilgang til færre tjenester enn en bruker som logger seg på via en virksomhets-forvaltet enhet (virksomheten kjenner både bruker og enhet). 

2.2.7

Etabler en robust og motstandsdyktig IKT-arkitektur som ivaretar tilgjengelighet til kritiske funksjoner og leveranser. a) Gjennomfør risikovurderinger for maskinvare-feil, menneskelige drifts-feil, data-angrep, internett-tilgjengelighet (bl.a. tjenestenekt-angrep), tjenesteleverandørtilgjengelighet, elektrisitet-tilgjengelighet, naturskade og geopolitisk situasjon. b) Ut i fra resultatene fra risikovurdering og kritikalitet kan deler av IT-løsningen gjøres mer robust. Det kan være tiltak som duplisering av internett-forbindelse, duplisert datasenter på alternativ lokasjon, duplisering av domenekontrollere, delvis tjenesteutsetting, robust (midlertidig) strømforsyning, lager av kritiske reservedeler, mm. 

ID

Beskrivelse

Sikkerhetskonfigurasjon er viktig for både maskinvare-enheter og virtuelle enheter («sky»).

2.3.1

Etabler et sentralt styrt regime for sikkerhetsoppdatering. Installer sikkerhetsoppdateringer så fort som mulig. a) Etabler en prioriteringsliste for oppdateringer. Operativsystem og applikasjoner på de ansattes klienter bør prioriteres. Videre bør man oppdatere servere som inneholder standard applikasjoner og operativsystem, programvaren i skrivere, samt enheter som styrer virksomhetens nettverk (svitsjer, rutere). b) Etabler en rutine med klare ansvarsforhold for i) hvor ofte oppdateringer skal utføres (mye bør kunne automatiseres) og ii) ansvarlig rolle for oppfølging hvis en oppdatering ikke kan gjennomføres eller må utsettes. c) Isoler servere og annet som oppleves som vanskelig å holde oppdatert, se 2.5.4. d) Virksomheter bør automatisere og forenkle prosessen for å implementere nye sikkerhetsoppdateringer. 

2.3.2

Konfigurer klienter slik at kun kjent programvare kjører^[5] på dem. a)  På ansattes klienter bør man eksplisitt hviteliste alle programmer som skal kjøre på enheten, fortrinnsvis ved at den tillatte programkoden er signert av en tiltrodd part som gjerne også kvalitetssikrer koden ift.

operativsystemets applikasjonskriterier. I praksis kan denne signeringen f.eks. utføres av applikasjonsbutikken (en «app store») til enhetsleverandøren, evt. også i virksomhetens egen applikasjonsbutikk. Hvis behov, kan utvalget av applikasjoner i en leverandørs applikasjonsbutikk strammes inn i virksomheten ved hvitelisting av kun ønskede applikasjoner (f.eks. med verktøy av typen “Mobile Device Management” - MDM). b) Hvis man ikke knytter applikasjoner til en applikasjonsbutikk bør man benytte applikasjons hvitelisting («application whitelisting»). Benytt filmappe-basert hvitelisting, da hvitelisting av individuelle applikasjoner som regel er for arbeidskrevende. c) Ved behov, kan hvitelistingen finkornes ytterligere ved at applikasjonshvitelistingen også svartelister uønskede leverandør-signerte programmer for gitte brukergrupper, f.eks. kan man eksplisitt blokkere innebygde skriptmotorer («script engines»)^[6] som man ikke ønsker at sluttbrukere skal kunne kjøre (bare administratorer). d) Programkode som følger med dokumenter (f.eks. makroer) utgjør også en stor angrepsflate. For å redusere denne angrepsflaten bør man i) fjerne uønsket programkode fra eksterne dokumenter og eposter før disse når brukerne, f.eks. i brannmuren, ii) deaktivere muligheten for å kjøre slik programkode for de brukerne som ikke trenger det, og iii) eksplisitt hviteliste programkode som brukerne faktisk trenger, f.eks. vha. signering.

2.3.3

Deaktiver unødvendig funksjonalitet. Innebygget funksjonalitet (både i operativsystemer og i applikasjoner) i klienter, servere og nettverksutstyr som ikke er nødvendig for virksomheten bør vurderes deaktivert, for dermed å redusere angrepsflate. Det kan gjelde f.eks. i) eldre eller ubrukte protokoller, ii) innebygd støtte for bl.a. personlige sky-tjenester. iii) andre innebygde tjenester virksomheten ikke kommer til å benytte.  

2.3.4

Etabler og vedlikehold standard sikkerhetskonfigurasjoner, dvs. ideelt sett en standard pr. type enhet i virksomheten. Dette gjelder operativsystemer (klient og server), brannmurer, nettverksutstyr, applikasjoner og maskinvare. a) All drift av sikkerhetskonfigurasjon bør være sentralisert og standardisert pr. type enhet. b) Konfigurasjonen bør gjennomgås og oppdateres med jevne mellomrom for å motstå nyere sårbarheter og angrepsvektorer. c) Endring av konfigurasjoner bør følge virksomhetens prosess for endringshåndtering og styres av autoriserte ansatte. d) Sikkerhetskonfigurasjon skal kun endres av autorisert driftspersonale, og ikke kunne endres av sluttbrukere på sine klienter. 

2.3.5

Verifiser at aktivert sikkerhetskonfigurasjon er i henhold til virksomhetens godkjente sikkerhetskonfigurasjon. a) Sammenlign regelmessig aktivert konfigurasjon på systemkomponenter som nettverksutstyr, brannmurer, klienter og servere mot den

godkjente/vedtatte konfigurasjonen som er definert for hver type enhet i virksomheten. b) Uautorisert endring av konfigurasjonen bør undersøkes, rapporteres og håndteres. c) Den vedtatte/godkjente konfigurasjonen bør integritets-beskyttes. I tillegg bør kun IT- og sikkerhetsansvarlige ha innsyn i konfigurasjonen. d) Automatiser verifikasjonsprosessen mest mulig, og kjør det som er automatiserbart regelmessig, f.eks. hver natt.   

2.3.6

Utfør all konfigurasjon, installasjon, og drift for øvrig på en trygg måte. a) Utfør driftsoppgaver over tiltrodde kanaler. Vurder bl.a. å i) installere betrodde TLS sertifikater, gjerne utstedt internt, på flest mulig administrative grensesnitt, se 2.7.1. og 2.7.2. Og ii) unngå å eksponere

administrative grensesnitt på internett og ut mot servere/klienter som er brukere av tjenesten. b)  Bruk tiltrodde og dedikerte klienter til driftsoppgaver.  c) Reduser interaktiv pålogging direkte på servere og klienter ifm. driftsoppgaver til et minimum. Interaktiv drift øker risiko (angrep som «Pass the hash») og motvirker ønsket om å automatisere/standardisere konfigurasjonen samt verifikasjonen av gyldig konfigurasjon.

2.3.7

Endre alle standardpassord på IKT-produktene før produksjonssetting. Dette inkluderer applikasjoner, operativsystemer, rutere, brannmurer, skrivere og aksesspunkter. I den grad IKTproduktene støtter det, bør man benytte sertifikatbasert autentisering og redusere mulighet for passordbasert autentisering over nettverket.

2.3.8

Ikke deaktiver kodebeskyttelsesfunksjoner. Nyere operativsystemer har aktivert kodebeskyttelsesfunksjoner («exploit protection») som f.eks. DEP, SEHOP og ASLR. Dette vanskeliggjør angripers utnyttelse av sårbarheter selv når det ikke finnes en oppdatering eller oppdateringen utføres for sent. Lag unntaksregler for eldre applikasjoner som ikke fungerer med bra kodebeskyttelse, slik at man slipper å deaktivere beskyttelsen helt. Kontakt så leverandør av slike applikasjoner for fjerning av sårbarhetene.

2.3.9

Etabler sikker tid i virksomheten. Vurder valg av tidskilder med høyere tillit og kontroller at alle enheter benytter tid med ønsket kvalitet. Se [1].  

2.3.10

Reduser risiko med IoT-enheter. a) Lag en plan for innføring av slike enheter som inkluderer sikkerhetsaspekter med risikovurdering, inkl. vurdering av skyen enhetene kobler seg til. b) Kjøp kun enheter som har innebygd sikkerhetsfunksjonalitet dvs. som kan i) sikkerhetsoppdateres (2.3.1), ii) kan bytte alle standard-passord (2.3.7), iii) kan tvinges til å kun benytte nettverk virksomheten har kontroll over. c) Monitorer trafikken fra enhetene (se prinsipp 3.2 - Etabler sikkerhetsovervåkning), d) isoler enhetene i egne nettverkssoner (se prinsipp 2.2 - Etabler en sikker IKT-arkitektur og 2.5 - Kontroller dataflyt) og e) vurder plassering mht. om uvedkommende kan få fysisk tilgang til enhetene.  Se [5] for mer informasjon.

ID

Beskrivelse

Nettverksikkerhet er viktig både for maskinvarebasert enheter og virtualiserte enheter («skybasert»).

2.4.1

Etabler tilgangskontroll på flest mulige nettverksporter. a) Nettverkstrafikk bør kun tillates på virksomhetsgodkjente porter (hviteliste-prinsipp). b) Tillat kun adgang for forvaltede enheter. c) Ikke-forvaltede enheter bør kun ha tilgang til eget gjeste-nett eller lignende.

2.4.2

Krypter alle trådløse og kablede forbindelser. a) Krypter alle trådløse forbindelser. Bruk tidsriktige protokoller som WPA2/WPA3 i «enterprise-modus». b) Krypter alle kablede forbindelser i egne nettverk, som minimum de som ikke er fysisk kontrollert av virksomheten.

2.4.3

Kartlegg fysisk tilgjengelighet for svitsjer og kabler. Virksomheter har ofte manglende oversikt over hvor egne kabler går og om uvedkommende har fysisk adgang. Hvis man ikke autentiserer og krypterer alle forbindelser, bør man kartlegge beliggenhet til kablede nettverk med tanke på om uvedkommende har fysisk adgang (mellom egne bygninger, mellom etasjer i bygning delt med andre virksomheter, mellom forskjellige geografiske lokasjoner, resepsjoner, mm.).   

2.4.4

Aktiver brannmur på alle klienter og servere. Brannmurer er som regel innbygget i operativsystemer og kan brukes til trafikkstyring eller logging. Benytt brannmurer til å a) regulere innkommende/utgående trafikk. b) Logge sikkerhetsrelevante hendelser. Loggingen bør integreres med virksomhetens øvrige løsninger for sikkerhetsovervåkning. c) Integrer klient/server-logging med sentralisert virksomhets-logging.  

ID

Beskrivelse

Kontrollert dataflyt er viktig uansett hvor fysisk eller virtualisert («sky-basert») infrastruktur man har.

2.5.1

Styr dataflyt mellom nettverks-soner. a) Bruk oppdelingen i prinsipp 2.2 - Etabler en sikker IKTarkitektur til å filtrere ønsket (hvitelistet) nettverkstrafikk mellom soner og mot Internett. Filtrering kan være basert på kriterier som IP-adresse, sone-identifikator, protokoll, applikasjon, bruker, mm. b) Reglene (inkl. endringer) for trafikken mellom sonene bør dokumenteres og begrunnes. c) Sjekk regelmessig at den faktiske konfigurasjonen for dataflyt er i tråd med ønsket dataflyt.

2.5.2

Begrens tilgangen til interne tjenester fra eksterne lokasjoner. a) Tillat kun bruk av virksomhetsforvaltede enheter for å nå kritiske interne tjenester. b) Tilgang til interne tjenester fra ikkeforvaltede og private enheter bør kun tillates etter en kritikalitetsvurdering av tjenesten. Det kan for eksempel være behov for tilgang til e-post og timeregistrering. I slike tilfeller bør risikoreduserende tiltak vurderes, for eksempel ved å tilby mindre funksjonalitet, kortere søkehistorikk, ett ekstra lag med autentisering osv.

2.5.3

Sperr all direkte-trafikk mellom klienter. Applikasjoner som har behov for «peer-to-peer» bør i stedet benytte en server-tjeneste. Alternativt reduser direkte trafikk mellom klienter til et absolutt minimum og basert på tjenstlig behov.

2.5.4

Isoler utstyr som er sårbart og har lav tillitt, eksempelvis: a) Utdaterte applikasjoner og gamle servere med ikke-støttede operativsystemer bør isoleres (filtrerings-kriterier som nevnt i 2.5.1.a samt underlegges stram aksesskontroll) slik at kun én godt sikret server/proxy har direkte tilgang. b) Skrivere med svak sikkerhetskonfigurasjon og manglende sikkerhetsoppdatering.  

2.5.5

Styr dataflyten til spesielt eksponerte tjenester. a) Eksponerte tjenester som web og epost med eksternt innhold til brukerne bør kontrolleres spesielt. b) Det bør ikke være mulighet for direkte dataflyt mellom slike eksponerte tjenester og virksomhetens mest kritiske tjenester. 

2.5.6

Beskytt spesielt kritiske tjenester med egen dataflyt. a) Vurder hvilke tjenester som er spesielt kritiske og som bør ha egne regler for dataflyt. Tjenesten for sikkerhetskopiering kan være et eksempel. b) Vurder validering av kritiske tjenester på applikasjonslaget, f.eks. med en applikasjonsbrannmur.    

2.5.7

Ha kontroll på trafikk mellom virksomheten og samarbeidspartnere/ tjenesteleverandører.

Angrep kan treffe virksomheten via systemene til samarbeidspartnere eller tjenesteleverandører.

Trafikken til og fra disse bør styres til kun de relevante delene av virksomhetens system.

2.5.8

Styr all trafikk (ikke bare interne tjenester) til og fra forvaltede mobile klienter via virksomhetens nett, og ikke direkte til internett. Forvaltede mobile klienter bør alltid (uansett hvor de befinner seg) underlegges sikkerhetsfunksjonalitet i virksomhetens systemer, bl.a. for å hindre og detektere datalekkasje fra kompromitterte klienter. 

ID

Beskrivelse

Kontroll på identiteter og tilganger er viktig uansett hvor virtualisert («sky-basert») infrastruktur man velger. 

Denne tabellen bør sees i sammenheng med tabellen i prinsipp 1.3 - Kartlegg brukere og behov for tilgang.  

2.6.1

Etabler retningslinjer for tilgangskontroll.  a) Retningslinjene bør dekke flest mulig av ressursene i virksomheten: brukere, klienter, felles-mapper, server-applikasjoner, servere, nettverksenheter, sikkerhetsenheter og databaser. b) Retningslinjene bør følge minste privilegiums prinsipp; ikke gi sluttbrukere, service-kontoer, utviklere eller driftsbrukere flere privilegier enn nødvendig. Alle trenger ikke tilgang til alt. Og hvis man trenger tilgang så holder det ofte med lese-rettigheter, alle trenger ikke rett til å skrive, slette og kjøre. c) Alle kontoer bør kunne spores til en ansvarlig bruker (også upersonlige kontoer uten personnavn). d) Alle kontoer, tilganger og rettigheter bør spores til en ansvarlig rolle og person som godkjente dette. e) Kontoer, tilganger og rettigheter bør revideres jevnlig. Dette er spesielt kritisk mht. kontoer, tilganger og rettigheter for drift og spesialbrukere. f) Gjenbruk identiteter mest mulig på tvers av systemer, delsystemer og applikasjoner (ideelt «Single sign on»). g) Ansvarliggjør brukere mht. at passord er personlige og hemmelige og aldri skal deles med noen, selv ikke med nære kollegaer eller overordnede. Klienter bør i tillegg låses når de forlates av bruker.

2.6.2

Etabler en formell prosess for administrasjon av kontoer, tilganger og rettigheter. a) Prosessen bør omhandle i) kontoer til brukere, enheter og systemprosesser, ii) tilganger til systemer og applikasjoner, iii) samt rettigheter mht. operativsystemer (f.eks. admin-rettigheter) og virksomhetens felles brukerdatabase. b) Prosessen bør omfatte hele livssyklusen og omfatte opprettelse, vedlikehold og deaktivering. Deaktiver fremfor å slette kontoer og tilganger slik at revisjonsspor bevares, i henhold til gjeldende lover og regelverk. c) Retningslinjer for tilgangskontroll (2.6.1) og prosess for administrasjon av kontoer, tilganger og rettigheter (2.6.2.a) bør dokumenteres og være kjent i virksomheten.

2.6.3

Benytt et sentralisert og automatiserbart verktøy for å styre kontoer, tilganger og rettigheter.  a) Styr kontoer, tilganger og rettigheter til flest mulig av ressurser (ref. 2.6.2.a) i virksomheten med helst ett verktøy for hele virksomheten. b) Bruk verktøyet til å holde oversikt over alle kontoer, tilganger og rettigheter. Verktøyet bør kunne utføre mest mulig av retningslinjene i 2.6.1, c) Ved opprettelse av enkelte kontoer (f.eks. innleide) bør man sette foreløpige utløpsdatoer for deaktivering. d) Detekter og følg opp kontoer som ikke har blitt brukt på lenge dersom de ikke er nødvendige (overvåk unntak som f.eks. en leverandørs vedlikeholdskonto). e) Bruk et sentralt verktøy til å kontrollere passord-kvaliteten opp mot virksomhetens sikkerhetskrav, som et

minimum bør man hindre bruk av vanlige ord og navn på norsk og engelsk, samt årstall og årstider. Se også [1].

2.6.4

Minimer rettigheter til sluttbrukere og spesialbrukere.  a) Ikke tildel administrator-rettigheter til sluttbrukere. b) Håndter spesialbrukere (f.eks. utviklere) som unntaksvis kan ha et faktisk behov for utvidede systemrettigheter, inkl. administrative rettigheter. Oppgavene bør skilles i to kontoer. En for vanlig kontorbruk som e-post og internett-søk og en annen for oppgaver som krever forhøyet («elevated») rettigheter. Disse kontoene bør ha tilstrekkelig sikkerhetsskille og som absolutt minimum ikke ha samme passord.

2.6.5

Minimer rettigheter på drifts-kontoer. a) Etabler ulike kontoer til de ulike drifts-operasjonene (selv om det kanskje er samme person som reelt sett utfører oppgavene), slik at kompromittering av en konto ikke gir fulle rettigheter til hele systemet. Dvs. forskjellige drifts-kontoer for backup, brukeradministrasjon, klientdrift, serverdrift, mm. b) Begrens bruken av kontoer med domeneadmin rettigheter til kun et minimum av virksomhetens drifts-operasjoner. Spesielt bør kontoer med domene-admin rettigheter aldri benyttes interaktivt på klienter og servere (reduserer konsekvensene av «pass the hash» angrep). c) Unngå bruk av upersonlige kontoer

(«backup_arne» er bedre enn bare «backup») slik at man har god sporbarhet og lettere kan deaktivere kontoer når noen slutter. Hvis det er vanskelig å unngå å ha en upersonlig konto bør man først logge seg inn med en personlig bruker for å ivareta sporbarhet. 

2.6.6

Styr tilganger til enheter. a) Identifiser enheter sikkert og unikt med f.eks. sertifikater. Dette er ikke minst viktig for de ansattes klienter. b) Ha klare regler om hvilke nettverks-soner, ressurser og tjenester som enheter skal ha tilgang til.  

2.6.7

Bruk multi-faktor autentisering, som smartkort, sertifikater eller engangspassord, for å autentisere brukere. a) Implementer som et minimum multi-faktor på brukerkontoer som har tilgang til kritiske data eller systemer, samt brukere med driftsoppgaver. Der multi-faktor autentisering ikke støttes, bør brukerkontoer bli pålagt å bruke sterke passord på systemet.  b) Benytt biometri (f.eks. fingeravtrykk) på klienter som benyttes mye i det offentlige rom

(passord-inntasting kan bli observert/filmet). Merk at det kan være personvernsutfordringer mht. biometri, se [3].

ID

Beskrivelse

Data bør beskyttes uansett hvor virtualisert («sky-basert») man velger å ha sin infrastruktur.  

2.7.1

Etabler en strategi for håndtering av kryptografi i virksomheten. Strategien bør inneholde valg av kryptografiske verktøy, håndtering av sertifikater, hvordan utøve sikker nøkkelgenerering, hvordan nøkler/passord oppbevares, sikkerhetskopiering av nøkler, fornyelse av nøkler og hvordan håndtere kompromittering av nøkler. For nøkkelhåndtering bør det skilles på langtidsnøkler og sesjonsnøkler, der langtidsnøkler bør beskyttes særskilt. 

2.7.2

Aktiver kryptering i de tjenestene som tilbyr slik funksjonalitet og sikre at kun anbefalte algoritmer og nøkkellengder benyttes. Se [1].

2.7.3

Krypter lagringsmedier som holder konfidensiell data og som lett kan mistes eller kompromitteres, eksempelvis mobile klienter. Definer hvordan ulike typer data skal beskyttes, eksempelvis med kryptering av enkeltfiler, partisjoner eller hele disker.

2.7.4

Benytt kryptering når konfidensiell informasjon overføres eller når tilliten til

informasjonskanalen er lav. For de ulike kanalene må det bestemmes på hvilket nivå krypteringen gjennomføres, for eksempel i applikasjonen (TLS), på nettverkslaget (IPsec) eller på datalinklaget (MACsec).

2.7.5

Definer krav til sikringsnivå for ulike typer informasjon med ulikt behov for konfidensialitetsbeskyttelse. Definer både for informasjon som lagres på ulike medier og for informasjon som overføres over ulike informasjonskanaler.

ID 

Beskrivelse 

Implementering av dette applikasjonsspesifikke prinsippet anbefales utført etter andre tiltak, se informasjon etter tabellen.  

2.8.1

Verifiser at innkommende e-post er fra en legitim avsender-adresse (avslør «spoofing»). Gjør dette ved bruk av DMARC, DKIM, SPF og DNSSEC. Se [1] og [2] for mer informasjon. 

2.8.2

Aktiver STARTTLS på virksomhetens e-postserver for autentisering og konfidensialitetssikring av all e-post mellom virksomheten og andre samarbeidende virksomheter som har aktivert STARTTLS. Se [1] for mer informasjon. 

2.8.3

Bruk kun støttede e-postklienter, nettlesere og programtillegg («plugins») i virksomheten. Bruk kun siste versjoner med den nyeste sikkerhetsfunksjonaliteten og de siste sikkerhets-

oppdateringene. Avinstaller/deaktiver nettlesere som er inkludert i operativsystemet og som ikke lenger støttes. 

2.8.4

Tillat kun virksomhetsgodkjente programtillegg. For mange virksomheter er nødvendige programtillegg («plugins») kun de som integrerer epostleser og nettleser mot for eksempel saks- og arkivsystemer. Tillegg som ikke er nødvendige for virksomheten kan utgjøre en sårbarhet, og bør derfor ikke tillates. 

ID

Beskrivelse

2.9.1

Legg en plan for regelmessig sikkerhetskopiering av alle virksomhetsdata. En slik plan bør som minimum beskrive: a) Hvilke data som skal sikkerhetskopieres. b) Regelmessighet på sikkerhetskopiering av ulike data, basert på verdi. c) Ansvar for sikkerhetskopiering av ulike data. d) Prosedyrer ved feilet sikkerhetskopiering. e) Oppbevaringsperiode for sikkerhetskopier. f) Logiske og fysiske krav til sikring av sikkerhetskopier. g) Krav til gjenopprettingstid for virksomhetens ulike systemer og data (se prinsipp 4.1 - Forbered virksomheten på håndtering av hendelser). h) Godkjenningsansvarlig(e) for planen.

2.9.2

Inkluder sikkerhetskopier av programvare for å sikre gjenoppretting. Dette inkluderer (som minimum) a) sikkerhetskonfigurasjon ref. prinsipp 2.3 - Ivareta en sikker konfigurasjon og b) maler for virtuelle maskiner og «master-images» av operativsystemer og c) installasjonsprogramvare.  

2.9.3

Test sikkerhetskopier regelmessig ved å utføre gjenopprettingstest for å verifisere at sikkerhetskopien fungerer.

2.9.4

Beskytt sikkerhetskopier mot tilsiktet og utilsiktet sletting, manipulering og avlesning.  

Sikkerhetskopier bør være separert fra virksomhetens produksjonsmiljø. Se bl.a. prinsipp 2.1 - Ivareta sikkerhet i anskaffelses- og utviklingsprosesser. b) Tilgangsrettigheter til sikkerhetskopier bør begrenses til kun ansatte og systemprosesser som skal gjenopprette data. c) Det bør jevnlig tas offline sikkerhetskopier som ikke kan nås via virksomhetens nettverk. Dette for å hindre tilsiktet/utilsiktet sletting eller manipulering. d) Sikkerhetskopier bør beskyttes med kryptering når de lagres eller flyttes over nettverket. Dette inkluderer ekstern sikkerhetskopiering og skytjenester.

ID

Beskrivelse

2.10.1

Integrer sikkerhet i virksomhetens prosess for endringshåndtering. Prosess for endringshåndtering bør inkludere: a) Vurdering av endringsforslag for å identifisere påvirkning på etablerte sikkerhetstiltak, f.eks. tiltakene som er beskrevet i alle tabellene i grunnprinsipper for IKT-sikkerhet.

b) Krav til testing av endringer før og etter idriftsetting, se prinsipp 2.1 - Ivareta sikkerhet i anskaffelses- og utviklingsprosesser. c) Informasjon til og nødvendig involvering av interesseparter som blir påvirket av endringen. d) Dokumentering av vurderinger, anbefalinger, avgjørelser og gjennomganger/tester med relevans for sikkerhetstilstanden. 

2.10.2

Involver nødvendig IKT-sikkerhetspersonell i forbindelse med endringer. Det kan være i forbindelse med overordnede eller tekniske vurderinger og gjennomganger, testing, godkjenning/signering eller varsling. 

2.10.3

Gjennomfør nødvendig endring, konfigurering og testing av påvirkede sikkerhetsfunksjoner før og etter idriftsetting for å opprettholde etablert sikkerhetstilstand.

2.10.4

Integrer sikkerhet i virksomhetens prosess for hasteendringer. Fastsett minimumskrav til involvering av personell, sikkerhetsvurderinger, testing og dokumentasjon både før og etter idriftsetting, se 2.10.1 - 2.10.3.

ID

Beskrivelse

3.1.1

Gjennomfør jevnlig sårbarhetskartlegging i informasjonssystemet ved hjelp av automatiserte verktøy. Kartleggingen bør dekke klienter, servere og nettverk. a) Prioriter funn og verifiser at oppdagede sårbarheter blir håndtert. b) Sørg for at verktøy benyttet til sårbarhetskartlegging jevnlig blir oppdatert med informasjon om alle relevante sikkerhetssårbarheter.

3.1.2

Abonner på tjenester relatert til sårbarhetsetterretning for å være oppdatert på nye og kommende sårbarheter. Bruk denne informasjonen som input til verktøyene for sårbarhetskartlegging.

3.1.3

Benytt automatisert og sentralisert verktøy for å håndtere kjente trusler (som skadevare).  a) Bruk antivirus/antiskadevare, fortrinnsvis en sentralisert styrt løsning, for å oppdage og blokkere kjent skadevare som blant annet utnytter sårbarheter i e-postklienter og dokumentlesere. b) Benytt også IDS/IPS-funksjonalitet på klienter og servere. c) Hendelser fra disse verktøyene bør logges, se prinsipp 3.2 - Etabler sikkerhetsovervåkning.

ID

Beskrivelse

3.2.1

Fastsett virksomhetens strategi og retningslinjer for sikkerhetsovervåkning. Følgende bør beskrives: a) Formål med og bruksområdet til innsamlet data. b) Hvilke data som skal samles inn. c) Sikker oppbevaring av data (også oppbevaring og behandling av data i forbindelse med rettslig prosesser). d) Kapasitetsplanlegging for lagring av innsamlet data. e) Tilgangsstyring til innsamlet data. f) Sammenstilling av logger fra virksomhetens forskjellige enheter og tjenester. g) Sletting av data. h) Revisjonsintervall for strategien (minst en gang i året og ved spesielle hendelser, f. eks. etter en større hendelse som dataangrep).

3.2.2

Følg lover, reguleringer og virksomhetens retningslinjer for sikkerhetsovervåkning. a) Undersøk hvilke lover og regler virksomheten må forholde seg til. b) Ta stilling til hvor lenge innsamlet data skal og kan lagres. c) Informer ansatte om hva som samles inn, hva det skal benyttes til og hvordan data skal behandles.

3.2.3

Avgjør hvilke deler av IKT-systemet som skal overvåkes. Det kan være bl.a. følgende. a) 

Deler av systemet som er mest kritisk eller som inneholder den mest konfidensielle informasjonen

(både operativsystem, database og applikasjon). b) Enheters operativsystemer. c) Interne nøkkelpunkt hvor data flyter gjennom. d) Nøkkelpunkt mellom interne og eksterne systemer, for eksempel ut mot Internett. e) Sikkerhetsprodukter (AVS, IDS, IPS, FW, mm.) i informasjonssystemene.  f) System for sikkerhetskopiering og gjenoppretting.  

3.2.4

Beslutt hvilke data som er sikkerhetsrelevant og bør samles inn. For delene nevnte i 3.2.3 bør man som minimum samle inn a) data relatert til tilgangskontroll (vellykkede og mislykkede pålogginger) på enheter og tjenester og b) administrasjons- og sikkerhetslogger fra enheter og tjenester i IKT-systemene. 

For klienter bør man i tillegg som minimum registrere c) forsøk på kjøring av ukjent programvare (ref. 2.3.2) og d) forsøk på å få forhøyede systemrettigheter («privilege escalation»).

3.2.5

Verifiser at innsamling fungerer etter hensikt. a) Kontroller at logginnstillinger fungerer og at det som skal innhentes blir innhentet. b) Sørg for at alle systemer som jevnlig lagrer sikkerhetsrelevant data har tilstrekkelig lagringsplass slik at nødvendig data ikke går tapt. c) Benytt et standardisert format slik at data enkelt kan leses av tredjeparts logganalyseverktøy.

3.2.6

Påse at innsamlet data ikke kan manipuleres. a) Arkiver og signer loggene digitalt med jevne mellomrom for å sikre loggintegritet. b) Sørg for tilstrekkelig tilgangsstyring på logger og implementer funksjonalitet som oppdager forsøk på manipulering eller sletting av logger. c) Påse at alle komponenter er synkronisert mot en og samme tidskilde. d) Samle relevante data og konsolider dem til en database slik at de er tilgjengelige for analyse (se prinsipp 3.3 - Analyser data fra sikkerhetsovervåkning).

3.2.7

Gjennomgå og konfigurer innhenting av sikkerhetsrelevant data og den sentrale loggdatabasen jevnlig i tråd med strategien slik at det kun innhentes og tas vare på relevante data. Fjern innsamlede data som ikke lenger har noen operasjonell eller sikkerhetsmessig relevans.

ID

Beskrivelse

3.3.1

Lage en plan for analyse av data fra sikkerhetsovervåkning, herunder: 

•       Avgjøre om virksomheten selv skal bygge opp analysekompetanse, eller om dette skal kjøpes. 

•       Prioritet, frekvens og ressursbruk på analysearbeidet.

•       Verktøy, tjenester og mekanismer for søk, prosessering og analyser.

•       Forvaltning og videreutvikling av fagområdet, inkludert: o           signaturbaserte verktøy o       normaltilstanden i informasjonssystemet o             metodikk og automatisert prosessering av innhentet sikkerhetsrelevant data  re-konfigurering av innhenting av sikkerhetsrelevant data o       analyseverktøy, teknologi og algoritmer «anvendt maskinlæring»

•       Rapportering

       Hendelseshåndtering

3.3.2

Etabler og vedlikehold kompetanse om normaltilstanden i virksomhetens informasjonssystemer for å kunne oppdage endringer eller unormaliteter som kan indikere uautoriserte handlinger. Normaltilstanden må forvaltes over tid og gjenspeiles av omstillinger og omorganiseringer, oppkjøp, sammenslåing, nedbemanning og endring av driftskonsept. Kunnskapen om informasjonssystemene bør være så god at det er mulig å identifisere avvik som representerer trusler. Dette kan være:

•              Dataflyt som er i strid med vedtatt dataflyt i henhold til prinsipp 2.5 - Kontroller dataflyt           Data som flyter på unormale tidspunkter og som ikke anses som normal trafikk.

•              Unormalt store datamengder som flyter i nettverket.

3.3.3

Ta i bruk verktøy som muliggjør manuelle og automatiske søk, samt alarmering basert på kriterier, i all innsamlet sikkerhetsrelevant data. Verktøyet bør automatisk kunne sammenstille data fra forskjellige kilder for å lettere kunne avgjøre om hendelsen er reel (ikke falsk positiv) samt omfang og karakter. Benytt kunnskap om normaltilstanden (se 3.3.2) og trusler (se 3.3.4) til å forbedre søk og kriterier for alarmering i verktøyet – som vil bidra til å kunne oppdage tidligere ukjente trusler.

3.3.4

Innhent og bearbeid trusselinformasjon fra relevante kilder slik at denne kan benyttes ved vurdering av potensielle sikkerhetshendelser. Dette kan være data fra tidligere angrep eller trusselinformasjon fra myndigheter, sektor-CERT-er, sammenliknbare virksomheter eller åpne kilder. 

3.3.5

Vurder fortløpende om innhentet data er tilstrekkelig relevant og detaljert. 

3.3.6

Etabler rutine for eskalering av alarmer, hvem det skal rapporteres til, samt hvilke data som skal tilgjengeliggjøres og hvem det skal tilgjengeliggjøres for i forbindelse med hendelseshåndtering.

3.3.7

Benytt analyseverktøy, teknologi og algoritmer (også kalt anvendt maskinlæring) som bidrar til å oppdage og formidle ukjente trusler og unormaliteter i de sikkerhetsrelevante dataene.

ID

Beskrivelse

3.4.1

Planlegg inntrengingstester med tydelig mål og omfang. a) Identifiser viktige deler av informasjonssystemet som bør vektlegges i testingen. b) Identifiser enkeltsystemer eller komponenter som er så kritiske at de må unntas fra testingen. Dette kan være deler av IKTinfrastrukturen som er kritiske for å opprettholde virksomhetskritiske tjenester eller som ikke er i stand til å tåle en inntrengingstest (eksempelvis sentrale industrielle kontrollsystemer).

3.4.2

Involver relevante interesseparter i forkant. Tilpass hva slags informasjon som gis ut og til hvem basert på mål og omfang for testen. Eksempelvis vil det ofte være naturlig å informere ekstern driftsovervåkning i forkant av en test, men ikke nødvendigvis brukere og driftspersonell.

3.4.3

Benytt verktøy for sårbarhetskartlegging og angrepsverktøy. Sårbarhetskartlegging kan benyttes som et utgangspunkt for testen, mens angrepsverktøy benyttes for å utnytte kartlagte sårbarheter.

3.4.4

Gjennomfør jevnlige inntrengingstester (minst årlige) for å identifisere sårbarheter. 

Inntrengingstestingen bør gjennomføres a) fra utsiden av virksomhetens nettverksbarrierer (eksempelvis fra internett eller via trådløs kommunikasjon i nærheten av virksomhetens lokaler) for å simulere eksterne angrep og b) fra innsiden av barrierer (eksempelvis på det interne nettverket) for å simulere interne angrep fra kompromittert klient/server eller utro tjenere.

3.4.5

Test rutiner for deteksjon og beredskap. Hyppigheten vil avhenge av virksomhetens behov, men det bør gjøres minst annethvert år for å opprettholde tilstrekkelige ferdigheter hos involvert personell i virksomheten.

3.4.6

Kommuniser resultater fra inntrengingstester til relevante interesseparter.

a)                  Rapportering fra inntrengingstester og IKT-beredskapsøvelser bør dekke virksomhetens behov. 

b)                  Testene bør dokumenteres med en oppsummering (ledelsesoppsummering), oversikt over funn og forslag til forbedringstiltak.

ID

Beskrivelse

4.1.1

Etabler et planverk for hendelseshåndtering som ivaretar behovet for virksomhetskontinuitet ved beredskap og krise. Dette bør inkludere a) en oversikt over krav til gjenopprettelse av IKTfunksjoner, IKT-tjenester og IKT-systemer basert på en analyse av konsekvenser for virksomheten («BIA – Business Impact Analysis»), b) rolle- og ansvarsbeskrivelser for relevant personell, c) krav til opplæring for relevant personell, d) klassifiseringsregime for hendelser og grenseverdier for å aktivere krisestab, e) krav til testing og øving av planverk og personell. f) Revider og oppdater planverket jevnlig, minst en gang i året og i etterkant av øvelser og større hendelser eller angrep. 

4.1.2

Gjennomfør en analyse av virksomhetskritiske effekter. Denne bør inkludere: a) prioritering av vitale forretningsfunksjoner og krav til sikkerhetsnivå for disse, b) identifiserte avhengigheter til IKT-funksjoner, IKT-tjenester, IKT-systemer, mm., c) krav til gjenopprettelsestid, tap av data og tjenestenivå.

4.1.3

Utarbeid rolle- og ansvarsbeskrivelse for personell som skal involveres i hendelseshåndtering. Dette inkluderer: a) Personell med sentrale oppgaver, for eksempel IT-sjef, applikasjonsansvarlig, plattformansvarlig mm. b) Ledere med beslutningsansvar på ulike nivåer. c) Beredskapsvakter som er tilgjengelig utenom normal arbeidstid og i ferieperioder. d) Sørg for tilstrekkelig opplæring og øving av personell i henhold til beskrivelse i planverk. 

4.1.4

Utarbeid avtaler med relevante tredjeparter slik at disse er klare til å yte støtte dersom det kreves ved en hendelse. Dette kan være sektorvise responsmiljøer, IT-spesialister innen ulike fagfelt, leverandører av utstyr og programvare mm.

4.1.5

Fastsett hvilke kommunikasjonskanaler som skal benyttes i forbindelse med hendelser. a) Distribuer kontaktinformasjon for relevant personell. b) Lag en plan for alternative kommunikasjonskanaler. c) Etabler en plan for intern og ekstern kommunikasjon rundt hendelser.

4.1.6

Test og øv på planer jevnlig slik at disse er godt innøvd. a) Øvelser bør inkludere relevante underleverandører. b) Øvelser bør inkludere testing av rutiner for deteksjon og beredskap, se

3.4.5.

ID

Beskrivelse

4.2.1

Gjennomgå loggdata og samle relevante data om hendelsen for å oppnå et godt

beslutningsgrunnlag. Dette kan innebære innhenting og sammenstilling av data fra flere kilder, gjennomføre tester eller målinger for å verifisere eller avkrefte en hendelse. Metode og omfang vil avhenge av type hendelse som har oppstått.

4.2.2

Avgjør alvorlighetsgrad for hendelsen iht. etablert planverk, se 4.1.1. a) Vurder om hendelsen er en mulig eller bekreftet sikkerhetshendelse eller en falsk alarm. b) Klassifiser hendelsen i henhold til virksomhetens klassifiseringsregimet (4.1.1.d). c) Involver relevante roller (4.1.3). d) Iverksett beredskapsplan dersom hendelsen tilsier dette.

4.2.3

Informer relevante interesseparter. Dette kan være sektorvise responsmiljøer, IT-spesialister innen ulike fagfelt, leverandører av utstyr og programvare, ledelsen, sluttbrukere, media mm. Se

4.1.3-4.1.4.

ID

Beskrivelse

4.3.1

Kartlegg omfang og påvirkning på forretningsprosesser. Kartlegg hendelsens påvirkning på underliggende IKT-funksjoner, IKT-tjenester og IKT-systemer. Se 4.1.2.  

4.3.2

Undersøk om hendelsen er under kontroll og gjennomfør nødvendige reaktive tiltak. Dersom omfanget øker og ser ut til å få alvorlige konsekvenser for virksomhetens forretningsprosesser bør kriseresponsaktiviteter iverksettes ved å eskalere til krisehåndteringsfunksjonen. Eksempler på reaktive tiltak er:

•       Allokering av internt og eksternt personell for å håndtere hendelsen.

•       Innkapsling og blokkering av inntrenger for å hindre spredning.

       Terminering av truende eller kompromitterende aktiviteter i systemer, for eksempel ved å stenge ned kompromitterte, interne servere som kan benyttes for videre angrep.

4.3.3

Loggfør alle aktiviteter, resultater og relevante avgjørelser for senere analyse. a) Etabler en tidslinje for egne og trusselaktørens aktiviteter. b) Oppdater hendelsesdata og situasjonsbilde underveis for best håndtering av hendelsen. c) Sikre elektroniske bevis for skadevareanalyse og eventuelle rettslige prosesser, se også prinsipp 3.2 - Etabler sikkerhetsovervåkning.

4.3.4

Iverksett gjenopprettingsplan i løpet av, eller i etterkant av hendelsen. Tiltakene vil variere avhengig av type hendelse, men kan inkludere:

•       Reaktivere redundante ressurser som ble tapt eller skadet under hendelsesforløpet.

•       Reinstallere maskin- og programvare på rammede komponenter.

•       Gjenopprette konfigurasjonsinnstillinger, med eventuelle tilpasninger.

       Gjenopprette tjenester som ble stoppet under hendelsesforløpet.

IKT-systemene bør bygges opp til en bedre forfatning enn de var i før hendelsen inntraff («build back better»). 

4.3.5

Koordiner og kommuniser med interne og eksterne interessenter underveis i hendelseshåndteringen. Dette kan være intern drift, ledelsen, interne avdelinger og andre virksomheter som kan bli påvirket av hendelsen. Virksomheten bør også ha en klar mediestrategi ved hendelser som kan ha en interesse for medier og allmenheten.

4.3.6

Gjennomfør nødvendige aktiviteter i etterkant av hendelsen. Alvorlighetsgrad av hendelsen og virksomhetens kompetanse og kapasitet vil være styrende for hva som gjennomføres og om det skal gjøres av internt eller eksternt personell. Det kan være aktiviteter som: 

•       Etterforsking for å finne rotårsak til hendelsen, inkludert:  Type skadevare o       Trusselaktør o    Angrepsvektor o Verktøy Hvordan hendelsesforløpet utviklet seg og hvordan trusselaktøren handlet.

•       Oppsummerende rapport som ledelsen kan forstå og ta stilling til.

       Kommunikasjon med relevante parter, inkludert sektorvise responsmiljøer og/eller NSM NCSC.

ID

Beskrivelse

4.4.1

Identifiser erfaringer og læringspunkter («lessons learned») fra hendelser, både det som virket og det som kan forbedres.

4.4.2

Kartlegg og gjennomgå identifiserte, kompromitterte sikkerhetstiltak og oppdater eller forny disse for å hindre at en tilsvarende hendelse gjenoppstår. Vurder om etablerte tiltak er dekkende for virksomheten risikobilde.

4.4.3

Vurdere effektiviteten av prosesser, prosedyrer, rapporteringsformater og organisatoriske strukturer med tanke på å respondere på hendelser. Gjennomgå disse regelmessig, og etter hendelser, og oppdater basert på eventuelle læringspunktene.

4.4.4

Kommuniser og del erfaringsresultatene med (relevante) interessenter og bruk reelle historier fra hendelseshåndtering i opplæring og bevisstgjøring av ansatte.