2. Beskytte

Publisert: 28.08.2017 | Sist endret: 29.08.2017

2.1 Ivareta sikkerhet i anskaffelse- og utviklingsprosesser

Etablere prosesser for anskaffelse og utvikling slik at varer og tjenester som innføres og integreres i virksomheten kan stoles på og ikke inneholder kjente sårbarheter og sikkerhetshull.

Hvorfor er dette viktig?

Publiserte sårbarhetsvarsler viser at mange sårbarheter i programvare skyldes dårlig kvalitetskontroll av produktet. Dette kan skyldes mangel på forståelse og kunnskap om hvordan programvare kan misbrukes.
Standardinnstillinger som er designet for det godes hensikt kan i neste nu misbrukes av en angriper – dette er det ikke tenkt på. Problemene er ofte knyttet til mangel på autorisering, autentisering og integritetssikring.

Dersom en virksomhet anskaffer eller utvikler komponenter og systemer som ikke tilfredsstiller kvalitetskrav eller ikke er godt integrert i virksomhetens øvrige sikkerhetsarkitektur, kan dette føre til innføring av sårbarheter og sikkerhetshull. En angriper benytter som oftest enkleste vei inn og hvis det finnes sikringstiltak som enkelt kan omgås vil en angriper lete etter, og utnytte, dette. Tilsvarende må tjenester som skal anskaffes og integreres i virksomhetens øvrige IKT-infrastruktur ivareta virksomhetens krav til sikkerhet, både når det gjelder selve tjenesten og integrasjonen.

Sårbarheter kan innføres på bakgrunn av at kvaliteten på fremskaffelsesprosessen ikke er god nok og virksomheten innfører komponenter eller tjenester med manglende sikkerhetsfunksjonalitet, manglende sikkerhetsrettinger eller konfigurerer komponenter feil. Disse sårbarhetene kan enten skyldes feil på produktet som en angriper kan utnytte, eller plantede sårbarheter fra en trusselaktør. Sårbarheter kan også innføres i etterkant av anskaffelsen gjennom oppdateringer eller vedlikehold.

Hvis virksomheten i tillegg mangler gode prosesser for test, verifisering og implementering av produkter eller tjenester, vil sannsynligheten være stor for at sårbarhetene ikke blir oppdaget eller at virksomhetsprosesser stopper opp. Kostnaden ved å rette opp i dette i etterkant er ofte høyre enn kostnaden ved å implementere gode prosedyrer for test og idriftsetting.

Det kan for virksomheter være utfordrende å planlegge når materiell bør skiftes ut. Kostnader vil ofte påløpe, og mange virksomheter definerer utdatert som «at produktet ikke virker lenger» eller at det ikke kan løse det funksjonelle behovet.
Materiell bør vurderes skiftet ut når produktet ikke lenger understøtter adekvat og tidsmessig sikkerhet. 

Anbefalte tiltak 

ID

Beskrivelse

 

Anskaffelse og utvikling

2.1.1

Integrer sikkerhet i virksomhetens prosess for anskaffelse og utvikling, fra kravanalyse, prekvalifisering og design, til testing og idriftsetting. Fastsett krav til informasjonssikkerhet basert på anerkjente standarder og rammeverk slik at nødvendige aspekter relatert til konfidensialitet, integritet og tilgjengelighet adresseres i forbindelse med anskaffelse og utvikling. I tillegg til sikkerhetskrav for selve produktet eller tjenesten, bør det også stilles krav til funksjonalitet, analysekapasitet, overvåkbarhet, styring og integrasjon, herunder samsvar med virksomhetens sikkerhetsarkitektur. Kravene bør inkluderes i kontrakt for måling av etterlevelse.

2.1.2

Velg en leverandør av god kvalitet der virksomheten kan stole på leverandørkjeden og de tjenestene som leveres gjennom hele livsløpet til produktet eller tjenesten. Behovet for vedlikehold gjør at en vesentlig del av utfordringen vil ligge i livsløpet til komponenten. Leverandørens tilgang til IKT-systemet og oppgraderinger bør derfor reguleres og kontrolleres og ideelt sett unngås.

2.1.3

Kjøp moderne og oppdatert maskin- og programvare slik at den nyeste og mest tidsaktuelle sikkerhetsfunksjonaliteten følger med og nødvendige sikringstiltak kan benyttes.

2.1.4

Planlegg livsløpet til materiellet ved anskaffelse og legg en plan for når materiell skal skiftes ut før det blir utdatert. Dette må derfor inkluderes i budsjettprosessen.

2.1.5

Foretrekk sertifiserte og evaluerte produkter gjennomført av en tiltrodd tredjepart. Dette øker sannsynligheten for at produktet oppfører seg som tiltenkt og ikke inneholder ukjente feil eller mangler. Et eksempel på et slikt regime er Common Criteria. I tillegg bør produktene integreres i eksisterende IKT-miljø slik at kvalitet og tillit til sikkerhetskomponenter opprettholdes.

 

Test og idriftsetting:

2.1.6

Benytt separate miljøer for utvikling, test og produksjon slik at operative virksomhetsprosesser og produksjonsdata ikke blir påvirket ved feil i utvikling- og testløp.

2.1.7

Beskytt integritet og konfidensialitet til testdata slik at sikkerhetstester blir gjennomført så reelt som mulig og sensitiv informasjon ikke kommer på avveie. For å redusere risiko kan konstruerte eller anonymiserte/ubrukelige datasett fra produksjon benyttes så sant det er innenfor rammene av en fortsatt valid test.

2.1.8

Gjennomfør tilstrekkelig med testing gjennom hele anskaffelses- og utviklingsløpet slik at feil og mangler rettes opp før idriftsetting. Dette inkluderer blant annet enhetstesting, integrasjonstesting, systemtest, akseptansetest, pilottest, inntrengingstest og stresstest.

2.2 Ivareta sikker design av IKT-miljø

Designe en helhetlig og enhetlig sikkerhetsarkitektur som ivaretar ønsket sikkerhetsnivå gjennom gode sikkerhetsfunksjoner, sikkerhetsstrukturer og behov for etterprøvbarhet.

Hvorfor er dette viktig?

Sentrale elementer og funksjoner i et IKT-miljø som må implementeres og sikres, og fungere sammen.
- Operativsystem
- Database
- Nettverksenheter
- Konfigurasjonsstyringsverktøy
- Katalogtjenester
- Kryptografiske moduler
- Digitale sertifikater og Public Key Infrastructure (PKI)
- Brannmur
- Antivirus/anti-skadevare
- Verktøy for systemovervåkning
- Verktøy for sikkerhetskonfigurasjoner
- Intrusion detection (IDS) og  protection (IPS) systems
- Funksjonalitet for sikkerhetskopiering og gjenoppretting

En angriper vil til en hver tid gå minste motstands vei for å angripe et IKT-system. I hjemmet hjelper det lite med den tykkeste utgangsdøren med den beste låsen hvis vinduet i andre etasje står åpent. På samme måte som vi sikrer et hus må også et IKT-system designes og bygges på en sikker måte. Vindu- og dørlås, alarmsystem og vaktselskap er alle sikkerhetsfunksjoner man kan benytte for å sikre hjemmet tilstrekkelig. Et IKT-system er bygd opp av tilsvarende sikkerhetsfunksjoner, som kryptografiske moduler, katalogtjenester og brannmurer. Hver av disse funksjonene, som kan ses på som enkeltmoduler i systemet, må konfigureres på en sikker måte.

Gjenbruk av sikkerhetsfunksjoner, som brukerdatabaser, forvaltningsverktøy og systemovervåkning er viktig for å oppnå en helhetlig sikkerhetstilnærming. Den motsatte tilnærmingen, det vil si å utvikle hver node og server som en unik og skreddersydd løsning er både kostbar og arbeidskrevende, og reduserer ressursene fra viktige sikkerhetsproblemer. Målet må være å kunne gjenbruke mekanismer slik at de konfigureres færrest mulig steder og at sikkerhetsmekanismer ikke har mer funksjonalitet eller kompleksitet enn nødvendig. Ethvert produkt, uavhengig av sine overlegne individuelle kvaliteter, vil introdusere sårbarheter i et system hvis det ikke integreres på en god måte. Samtidig bør systemet baseres på prinsippet «sikkerhet i dybden», der ulike sikkerhetsfunksjoner overlapper i funksjonalitet.

Anbefalte tiltak

ID

Beskrivelse

2.2.1

Etabler og vedlikehold en helhetlig sikkerhetsarkitektur som ivaretar en sikker og forsvarbar IKT-infrastruktur og gjenspeiler krav til leveranser. Påse at alle nødvendige og grunnleggende sikkerhetsteknologier omfattes med hensyn til valg av maskinvare, operativsystem, nettverksenheter, databaser og brannmurer.

2.2.2

Påse at systemkomponenter håndhever alle komponentspesifikke sikkerhetsfunksjoner som trengs av den aktuelle komponenten, for eksempel at komponentens pålogging, tilgangskontroll, logging, administrasjon, kodekontroll, ressursstyring og tilgjengelighetsfunksjoner ivaretas.

2.2.3

Bygg IKT-systemet fra systemkomponenter som er modulbaserte og standardiserte slik at de gjenbrukes når det er mulig, særlig når det gjelder nettverkssegregering og roller. Påse at sikkerhetsfunksjonaliteten til systemet integrerer og samarbeider godt, for eksempel ved at komponentene gjenbruker brukeridentifikasjonene som er definert av katalogtjenesten, i stedet for å implementere sine egne komponent- eller applikasjonsspesifikke brukeridentiteter (unngå multiple masterdatabaser for identiteter).

2.2.4

Del IKT-systemet i veldefinerte logiske ressursrom som primært er definert av katalogtjenesten for å binde sammen brukere og ressurser. Katalogtjenesten bør ta høyde for både prosessbaserte (prosjekt) og organisatoriske skiller.

2.2.5

Segreger IKT-infrastrukturen i sikkerhetssoner for å separere informasjon med ulik verdi og behov for brukertilgang, eksponerings- og kommunikasjonsbehov, funksjon og rolle, samt for å isolere utstyr med ulike sårbarheter og ulik tillit. Som et minimum bør det etableres egne soner for virksomhetens kontrollerte klienter, utstyr uten tillit og virksomhetens tjenester, eksempelvis egne servere. Tjenester eksponert på internett eller fra nettverk med lav tillit bør separeres fra øvrige tjenester. Eksempler på enheter med lav tillit er virksomhetens nettserver, BYOD-enheter og gjestebrukere. I tillegg bør systemadministrasjon utføres fra egne soner.

2.2.6

Reguler tilgang til tjenester basert på behovet for autentisering. Et eksempel er en bruker som logger seg på via en BYOD-enhet (virksomheten kjenner bare bruker og ikke enhet), vil gi tilgang til færre tjenester enn en bruker som logger seg på via en forvaltet enhet (virksomheten kjenner både klient og bruker).

2.2.7

Design et robust og motstandsdyktig IKT-miljø for å ivareta tilgjengelighet til kritiske funksjoner og leveranser.

2.3 Ivareta en sikker konfigurasjon (av maskin- og programvare)

Konfigurer og tilpass maskin- og programvare slik at det tilfredsstiller virksomhetens behov for drift og sikkerhet.

Utvikle og distribuere konfigurasjonsinnstillinger med god sikkerhetsfunksjonalitet er en kompleks oppgave, langt utenfor den enkelte brukers evne. For å ta gode valg må potensielt flere tusen innstillinger vurderes, bestemmes og implementeres på alle deler av IKT-infrastrukturen. Å etablere en sikker konfigurasjon vil kreve teknisk kompetanse på de komponentene som skal herdes, som vil medføre at mange virksomheter må støtte seg på eksterne aktører.
NSM utarbeider profiler for herding av enkelte sentrale systemkomponenter. Profiler er også tilgjengelige fra andre myndigheter og organisasjoner, eksempelvis Center for Internet Security. Benchmarks Division. Tilsvarende profiler distribueres også av enkelte programvare- og operativsystemleverandører.
Se mer på: https://www.nsm.stat.no/publikasjoner/regelverk/veiledninger/veiledninger-for -systemteknisk-sikkerhet

Hvorfor er dette viktig?

De fleste systemkomponenter leveres med en standardkonfigurasjon utviklet av enten produsent eller forhandler. Disse konfigurasjonene er vanligvis utviklet for å forenkle installasjon eller bruk, ikke for å tilby god sikkerhet. Standardinnstillinger, åpne tjenester og porter, standardkontoer eller passord, eldre (og ofte sårbare) protokoller og forhåndsinstallert programvare kan gi en angriper en rekke muligheter til å oppnå uautorisert tilgang. Systemer som ikke er tilstrekkelig konfigurert har større sannsynlighet for å introdusere sårbarheter som en angriper kan utnytte, for eksempel ved kjøring av utdaterte tjenester eller programmer som det ikke er funksjonelt behov for. Virksomheter må derfor herde systemkomponenter, eksempelvis ved å minimere funksjonalitet og fjerne standardinnstillinger og passord.

Manglende herding av systemkomponenter er ofte en viktig medvirkende årsak til at angripere får fotfeste i IKT-infrastrukturen, og er en viktig del av den totale informasjonssikkerheten. Operativsystemet på klientmaskinen, brukerdatabasen, brannmuren, skytjenesten, e-postklienten og nettverkssvitsjen er eksempler på systemkomponenter som må herdes. Disse komponentene må installeres og konfigureres på en sikker måte slik at ønsket funksjonalitet er aktivert og uønsket eller usikker funksjonalitet er deaktivert.

Selv om en sikker konfigurasjon er utviklet og installert, må den også kontinuerlig forvaltes for å forhindre at sikkerheten svekkes over tid. Virksomheten må håndtere at maskin- og programvare oppgraderes eller oppdateres, nye sikkerhetsproblemer rapporteres, konfigurasjonen endres for å tillate nye komponenter eller systemet må understøtte nye operasjonelle krav.

Anbefalte tiltak

ID

Beskrivelse

2.3.1

Installer og konfigurer systemet med kun nødvendig funksjonalitet for å understøtte virksomhetens forretningsprosesser. Kun autorisert programvare bør kjøre på virksomhetens enheter.

2.3.2

Etabler standard sikkerhetskonfigurasjoner av operativsystemer og programmer som kan installeres på virksomhetens enheter. Konfigurasjonen bør gjennomgås og oppdateres med jevne mellomrom for at den skal være oppdatert i forhold til de nyeste sårbarheter og angrepsvektorer. Konfigurasjonene bør kun kunne endres av autoriserte brukere.

2.3.3

Den sikre konfigurasjonen bør anses som en verdi og beskyttes deretter. Integriteten til konfigurasjonene bør sjekkes jevnlig og automatisk. Planlagte endringer bør følge virksomhetens prosess for endringshåndtering. Endringer i komponentens konfigurasjon avdekket gjennom automatiserte kontroll, og som ikke finnes å ha rot i en logget eller sentralstyrt endring, bør inngå som grunnlagsdata i sikkerhetsovervåkning og analyse.

2.3.4

Utfør all installasjon og fjernadministrasjon av servere, arbeidsstasjoner, nettverksenheter og lignende utstyr over tiltrodde kanaler.

2.3.5

Endre alle standardpassord på systemer før produksjonssetting. Dette inkluderer applikasjoner, operativsystemer, rutere, brannmurer og aksesspunkter.

2.3.6

Sørg for god konfigurasjonsstyring av den sikre konfigurasjonen slik at alle systemkomponenter, og nye systemer som produksjonsettes, innehar gyldige sikkerhetskonfigurasjon.

2.3.7

Implementer et verktøy for konfigurasjonsstyring som automatisk vil påtvinge og overskrive konfigurasjonsinnstillinger til systemer ved regelmessige intervaller. Verktøy bør melde fra dersom konfigurasjonen på enheter ikke samsvarer med gyldig konfigurasjon.

2.3.8

Blokker kjøring av ikke-autoriserte programmer («hvitelisting»). Bruk verktøy som Windows AppLocker for å kontrollere at sluttbrukere kun får kjøre godkjente applikasjoner. Blokker spesielt programmer utenfor godkjente mapper og på flyttbare media, som for eksempel på CD-er og minnepinner.

2.3.9

Bruk klientbrannmur regulerer innkommende trafikk og logger sikkerhetsrelevante hendelser. Inspiser loggfilene regelmessig.

2.3.10

Bruk antivirus/antiskadevare. Antivirus oppdager og blokkerer kjent skadevare som blant annet utnytter sårbarheter i e-postklienter og dokumentlesere. Fortrinnsvis bør man bruke et produkt som kan styres sentralt.

2.3.11

Aktiver kodebeskyttelse mot ukjente sårbarheter. Benytt kodebeskyttelsesfunksjoner som DEP (Data Execution Prevention), SEHOP (Structured Exception Handler Overwrite Protection), ASLR (Address Space Layout Randomization) og EMET (Enhanced Mitigation Experience Toolkit) som styrker systemet mot sårbarheter i applikasjoner og operativsystemet selv når det ikke finnes en oppdatering.

2.4 Ha kontroll på IKT-infrastruktur

Kontrollere og beskytte virksomhetens IKT-infrastruktur mot interne og eksterne trusler.

Hvorfor er dette viktig?

Tilkobling av virksomhetens IKT-infrastruktur til internett eller andre nettverk utenfor virksomhetens kontroll eksponerer systemene og teknologier for nye angrepsflater. Virksomhetens nettverk strekker seg ofte ut over kontorlokalet, og gjør det utfordrende å definere den fysiske utbredelsen. En virksomhet kan ha flere lokasjoner, tjenester kan være satt ut til leverandører eller de ansatte har behov for mobile enheter eller å kunne arbeide hjemmefra eller på reise.

Virksomheter må planlegge for at klienter overtas av angripere. I tillegg til utro tjenere, kan leverandører med aksess til IKT-infrastrukturen eller manglende fysisk sikring medføre at en angriper får tilgang til IKT-systemet. Er nettverkene feil konfigurert kan selv et nettverkspunkt i en usikker sone som kantinen være nok til å gi en angriper tilgang.

Virksomhetens IKT-infrastruktur må derfor sikres mot både interne og eksterne trusler. Hensikten med sikringen er å hindre en angriper tilgang og redusere skaden skulle en angriper få fotfeste i nettverket. En virksomhet må ha kontroll på nettverkenes utstrekning og IKT-infrastrukturen må beskyttes i henhold til eksponering og virksomhetens risikoprofil. Inndeling i sikkerhetssoner oppnås ved å segregere og/eller segmentere IKT-infrastrukturen. Med segregering menes fysisk adskillelse og segmentere menes logisk adskillelse.

Anbefalte tiltak

ID

Beskrivelse

2.4.1

Segreger og segmenter virksomhetens IKT-infrastruktur inn i nettverk og soner som gjenspeiler virksomhetens risikoprofil og sikkerhetssoner. Trafikk for å administrere IKT-infrastrukturen bør skilles fra øvrig virksomhetsnettverk og autoriseres og autentiseres.

2.4.2

Kommunikasjon mellom segmenter bør reguleres ved å filtrere nettverkstrafikken slik at det representer virksomhetens sikkerhetssoner og behov for dataflyt.

2.4.3

Beskytt trådløse nettverk med sterke sikkerhetsmekanismer for å autentisere og autorisere brukere, samt beskytte informasjonen som bæres av nettverket.

2.4.4

Benyttes virksomhetsstyrte klienter bør disse segregeres til eget nett der også klienten autentiseres.

2.4.5

Minimer antall nettverkstilkoblinger ved å deaktivere og fysisk koble fra nettverkskabler fra ubrukte nettverksporter, nettverkskort, nettverksprotokoller eller nettverksapplikasjoner.

2.4.6

Benytt krypterte forbindelser, eksempelvis VPN, for kommunikasjon utenfor egne nettverk slik at virksomhetens sikkerhetsmekanismer kan utnyttes.

2.4.7

Ansatte som skal ha tilgang til virksomhetens tjenester fra en ekstern lokasjon bør benytte forvaltede enheter eller forvaltet programvare.

2.5 Ha kontroll på kontoer

Aktivt administrere livssyklusen til system- og applikasjonskontoer for å redusere muligheten for at angripere utnytter dem. Dette gjøres gjennom å ha kontroll på kontoers opprettelse, bruk, dvale og deaktivering/sletting.

Hvorfor er dette viktig?

NSM erfarer ofte at virksomheter ikke har full kontroll på ulike kontoer i virksomheten. Selv i de tilfeller der Microsoft AD eller tilsvarende implementert på en god måte, finnes det brukere som ikke forvaltes av katalogtjenesten og kan benyttes til angrep. Katalogtjenester ivaretar bare deler av de kontoene som eksisterer i en virksomhet. I flere tilfeller har NSM sett at administrator- eller testkontoer til enten databaser eller underliggende operativsystemer på databaseserveren kan utnyttes av angripere for å få tilgang til verdifull informasjon eller kritiske systemer.

Angripere har ofte som hensikt å få tilgang til en legitim bruker. Med denne ønsker angriperen å elevere rettigheter eller ta over andre kontoer med utvidede rettigheter.. Dette gjør det vanskelig for nettverksovervåkere å skille mellom legitime brukere og faktiske angripere basert på brukerens oppførsel i nettverket. Kontoer til terminerte leverandører og ansatte, hvor kontoen har blitt satt inaktiv og hvor rettigheter ikke har blitt fjernet, har ofte blitt utnyttet på denne måten. Enkelte ondsinnede innsidere eller tidligere ansatte har i tillegg aksessert etterlatte kontoer lenge etter utløp av kontrakter og fått uautorisert tilgang til virksomhetens IKT-systemer og sensitive data.

Anbefalte tiltak

ID

Beskrivelse

2.5.1

Sørg for at alle kontoer er personlige og har en utløpsdato. Oppretthold en god dialog med bruker av konto med hva som overvåkes og logges relatert til kontoen.

2.5.2

Etabler og etterlev en prosess for å fjerne systemtilgang ved å deaktivere kontoer umiddelbart etter at en ansatt (fast eller midlertidig) slutter. Deaktiver fremfor å slette kontoer slik at revisjonsspor bevares. Dette må gjøres i henhold til gjeldende lover og regelverk.

2.5.3

Overvåk kontobruk for å detektere bruk av sovende kontoer, og varsle brukerens leder. Deaktiver slike kontoer hvis de ikke er nødvendige, eller dokumenter og overvåk unntak (f.eks. en leverandørs vedlikeholdskonto som brukes for å gjenopprette et system eller opprettholde kontinuitet). Eventuelt aktiver slike kontoer kun i det tidsrommet de er nødvendige. Koble aktive medarbeidere mot hver konto og deaktiver kontoer som ikke er tilordnet en gyldig ansatt.

2.5.4

Konfigurer tilgang for alle kontoer gjennom et sentralisert punkt for autentisering, for eksempel Active Directory eller LDAP. Virksomheter bør ha et spesielt fokus på de kontoer driftsmiljøet trenger for å forvalte IKT-infrastrukturen, slik at prinsippene for autentisering også gjelder for nettverks- og sikkerhetsenheter, databaser og servere.

2.5.5

Bruk multi-faktor autentisering for å autentisere brukere. Som et minimum bør det implementeres på brukerkontoer som har tilgang til sensitive data eller systemer, samt brukere med administrative rettigheter. Multi-faktor autentisering kan eksempelvis oppnås ved hjelp av smartkort, sertifikater eller engangspassord (OTP). Der multi-faktor autentisering ikke støttes, bør brukerkontoer bli pålagt å bruke lange, sterke passord på systemet.

2.5.6

Gjennomgå alle systemkontoer og deaktivere kontoer som ikke kan knyttes til en forretningsprosess og ikke har en eier.

2.6 Kontroller bruk av administrative privilegier

Kontrollere, korrigere, og spore tildeling, bruk og konfigurering av administrative rettigheter for å hindre misbruk av datamaskiner, nettverk og applikasjoner.

Hvorfor er dette viktig?

En av primærmetodene angripere benytter for å spre seg og få kontroll i en virksomhets nettverk er ved misbruk av administrative privilegier. To svært vanlige angrepsteknikker utnytter ukontrollert bruk av administrative privilegier. Den første metoden går ut på å lure en privilegert bruker til å åpne et e-postvedlegg, laste ned en fil fra en ondsinnet nettside eller gå inn på en nettside som inneholder skadevare som automatisk kan utnytte nettlesere. Filen eller utnyttelsen inneholder kjørbar kode som kjøres på offerets maskin, enten automatisk eller ved å lure brukeren til å godta kjøring av den. Hvis offerets klient innehar en sårbarhet som kan utnyttes for rettighetseskalering, eller dens brukerkonto har tilstrekkelige privilegier, kan angriperen ta fullstendig kontroll over maskinen og installere tastetrykklogging, sniffere og programvare for fjernaksess for å finne administrative passord og annen sensitiv data.

Den andre vanlige metoden brukt av angripere er eskalering av privilegier ved å gjette eller knekke passordet til en administratorbruker. Hvis administrative tilganger er distribuert ut løst og bredt i virksomheten, eller hvis administratorpassord er identiske til dem som benyttes på mindre kritiske systemer, vil det være enklere for en angriper å oppnå administrative privilegier. Det vil da være flere kontoer kan benyttes som inngangsport for en angriper som ønsker å få kontroll over et system.

Anbefalte tiltak

ID

Beskrivelse

2.6.1

Personer med administrative privilegier (operatører) bør bruke separate kontoer når de utfører systemadministrasjon.

2.6.2

Minimer bruken av administrative rettigheter og bruk administrative kontoer kun når det er påkrevet. Fokuser revisjon på bruk av administrative privilegerte funksjoner og monitorer systemene for avvikende atferd og eskalering av rettighetsnivå. I de tilfeller sluttbruker har behov for administrative privilegier, bør dette håndteres særskilt og kompenserende tiltak vurderes.

2.6.3

Administratorer bør påkreves å logge på systemer med en personlig, ikke-administrativ konto. Deretter bør transisjonen til administrative privilegier utføres.

2.6.4

Etabler ulike administratorkontoer til de ulike delene av IKT-infrastrukturen som skal forvaltes slik at kompromittering av en administratorkonto ikke gir fulle rettigheter til å endre hele infrastrukturen.

2.6.5

Administratorer bør benytte dedikerte maskiner for alle administrative oppgaver, eller oppgaver som krever forhøyede tilganger. Maskinen bør isoleres fra virksomhetens primære nettverk. Maskinen bør ikke benyttes til å lese privat e-post, utarbeide dokumenter eller ha mulighet til å surfe på internett.

2.6.6

Bruk multi-faktor autentisering for å autentisere administrative brukere.

2.6.7

Utfør all fjernadministrasjon av servere, arbeidsstasjoner, nettverksenheter, og lignende utstyr over sikre kanaler. Protokoller som telnet, VNC, RDP, eller andre som ikke aktivt støtter sterk kryptering bør bare brukes hvis de er utført over en sekundær, kryptert kanal, for eksempel TLS eller IPsec.

2.7 Kontroller dataflyt

Kontrollere informasjonsflyten inn til og ut av virksomhetens nettverk og mellom sikkerhetssoner slik at systemer ikke fritt kan kommunisere med hverandre.

Hvorfor er dette viktig?

Angripere fokuserer på å utnytte systemer de kan nå gjennom internett, ikke bare via eksponerte tjenester og servere, men også arbeidsstasjoner, bærbare og mobile enheter som ligger innenfor virksomhetens barrierer. De utnytter svakheter i konfigurasjon og sikkerhetsarkitektur funnet i systemer, nettverkskomponenter eller klienter med tilgang til internett for å få tilgang til virksomheten. Angripere søker etter nettverk tilgjengelige utenfra med sårbare eksponerte tjenester. Kjente eksempler er feilaktig konfigurerte nett- og e-postservere, fil- og printtjenester og andre tjenester konfigurert med standardinnstillinger. Aktører søker da etter disse tjenestene, benytter standard brukernavn og passord eller prøver kjente og ukjente sårbarheter. Deretter, med den tilgangen dette gir, beveger angriperen seg i virksomhetens nettverk for å etablere fotfeste og få tilgang til virksomhetens verdier. I tillegg treffer flere angrep virksomheten via nettverkene til samarbeidspartnere, ved at angripere hopper fra en virksomhet til en annen gjennom tillatte åpninger i en virksomhets perimetersikring.

Mange angrep gjennomføres gjennom nettverk som internett, mens andre er basert på tyveri eller kopiering av enheter som bærer informasjonen, eksempelvis klienter eller minnepinner. Felles for de fleste av disse, er at informasjonseieren ikke er kjent med at informasjonen kompromitteres siden virksomheter ikke overvåker dataflyten.  En virksomhet bør ha kontroll på data som flyter gjennom virksomhetens perimetre og mellom sikkerhetssoner, både fysisk og elektronisk.

Virksomhetens sikring av ytre perimetre eksponert mot internett, og mellom sikkerhetssoner bør bygges etter prinsippet «sikkerhet i dybden» og baseres på brannmurer, proxyer, DMZ-soner og nettverksbaserte deteksjons- (IDS) og beskyttelsessystemer (IPS). Dette for å kontrollere trafikken gjennom nettverksperimetere og mellom sikkerhetssoner ved å kontrollere innholdet for angrep og se etter kompromitterte enheter.

Anbefalte tiltak

ID

Beskrivelse

2.7.1

Benytt brannmurer med logging for å filtrere og kontrollere trafikken mellom de ulike sikkerhetssonene og mot internett ved kun å tillate ønsket trafikk mellom sonene. Brannmurregler bør ha en ansvarlig og beskrivelse av begrunnelse for åpning og bør revideres jevnlig.

2.7.2

Bruk applikasjonsbrannmurer foran alle kritiske servere for å validere trafikken som går til serverne. Uautorisert trafikk bør blokkeres og generere en alarm.

2.7.3

Vurder bruk av proxy-tjenester for å styre visse typer trafikk gjennom virksomhetens overvåkningsverktøy. Eksempelvis bør virksomhetens mobile tjenester rutes via virksomhetens nettverk for å kunne benytte de sikkerhetsmekanismene som eksisterer i de interne nettverkene.

2.7.4

Kommunikasjon til kjente, ondsinnede IP-adresser bør hindres eller begrenses (svartelisting), alternativt bør tilgang begrenses til nettsider man stoler på (hvitelisting).

2.8 Beskytt data i ro og i transitt

Beskytte virksomhetens data i ro på ulike lagringsmedium og når den formidles over ulike informasjonskanaler.

Hvorfor er dette viktig?

Kryptering er en forutsetning for sikring av dagens IKT-systemer. En virksomhet forvalter informasjon av ulik verdi som vil ha ulikt behov for beskyttelse. Denne informasjonen lagres på og overføres over ulike medium med ulik tillit, og på lokasjoner der virksomheten har varierende kontroll. Alle ansatte bør ha kjennskap til de regler som gjelder for informasjonsbeskyttelse i virksomheten. Den økte digitaliseringen og bruk av tredjepartsleverandører og mobile enheter gjør at informasjonen ofte flyter utenfor virksomhetens IKT-infrastruktur. Enkelte virksomheter opplever at ansatte benytter private tjenester til behandling av virksomhetsinformasjon av bekvemmelighetshensyn, eksempelvis private e-post eller skylagringstjenester. En virksomhet må derfor sikre at informasjonen til en hver tid behandles innenfor en akseptabel risiko.

Ved å benytte kryptografiske mekanismer, både i transitt og i ro, reduseres risikoen for kompromittering av sensitiv data. Kryptering av data medfører at virksomheten kan ha tillit til at informasjonen ikke kan avleses uten betydelige ressurser, selv om mediet som bærer informasjonen enten er avlyttet eller mistet. Dette er tilfelle hvis implementasjonen av de kryptografiske prosessene og de teknologiske mekanismene er implementert på en forsvarlig måte. Et eksempel er forvaltningen av kryptografiske nøkler som benyttes av ulike kryptografiske algoritmer for å beskytte data. En virksomhet må derfor utarbeide retningslinjer for hvordan informasjonen beskyttes. Informasjonen må beskyttes mot angrep på både konfidensialitet og integritet.

Når kryptering skal benyttes mellom virksomheter må de også ivareta behovet for å kunne oppdage «ondsinnet» trafikk som eventuelt går ut og inn av virksomheten. Tilliten som kryptering tilbyr må således opprettes mellom entitetene og ikke sluttbrukere. En egen tillit mellom brukere vil ofte måtte opprettes i tillegg.

Anbefalte tiltak

ID

Beskrivelse

2.8.1

Skru på kryptering i de tjenester som tilbyr slik funksjonalitet og sikre at kun anbefalte algoritmer og nøkkellengder benyttes.

2.8.2

Implementer kryptering av medier som holder sensitive data eller som lett kan mistes eller kompromitteres, eksempelvis mobile enheter. Definer hvordan ulike typer data skal krypteres, eksempelvis med kryptering av enkeltfiler, partisjoner eller hele disker.

2.8.3

Når sensitiv informasjon overføres, bør informasjonskanalen krypteres. Flyter informasjon fra virksomheten over informasjonskanaler med lav tillit, bør informasjonen krypteres. 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.8.4

Ende-til-endekryptering anbefales der det er mulig mellom entiteter som har behov for å sikre konfidensialitet og integritet ved overføring av data. Virksomheter bør definere hva som er deres entiteter, og de bør defineres så nært sluttbruker og tjeneste som mulig.

2.8.5

Utarbeid en håndteringsmatrise som viser hvilke sikringstiltak som gjelder for beskyttelse av informasjon med ulik sensitivitet når informasjon lagres på de ulike medier og overføres over de ulike informasjonskanalene. Det er den juridiske enhetens (virksomheten) behov for å sikre eget IKT-system som må gå foran den enkelte ansattes behov for integritet og konfidensialitet.

2.8.6

Utarbeid et konsept for hvordan kryptografi benyttes i virksomheten. Dette bør inneholde valg av kryptografiske mekanismer, håndtering av sertifikater, hvordan utøve sikker nøkkelgenerering, hvordan nøkler lagres i bruk, sikkerhetskopiering av nøkler, regenerering av nøkler (når) og hvordan håndtere tap av nøkkel. For nøkkelhåndtering bør det skilles på langtidsnøkler og sesjonsnøkler, der langtidsnøkler bør beskyttes særskilt, fortrinnsvis i maskinvare.

 

Eksempel på en håndteringsmatrise av virksomhetens informasjon i ro på ulike plattformer.

2.9 Beskytt e-post og nettleser

Minimere angrepsflaten og angriperes mulighet til å manipulere menneskelig oppførsel i forbindelse med bruk av e-postklienter og nettlesere.

Hvorfor er dette viktig?

Virkemidler for å redusere forfalsket e-post («SPOOFING»):
SPF (Sender Policy Framework) forteller omverdenen hvilke maskiner/systemer som har lov til å sende e-post fra ditt domene.
DKIM (DomainKeys Identified Mail) lar avsenders eposttjeneste signere en e-post kryptografisk. E-posttjenesten til mottaker kan verifisere at e-posten kommer fra noen som har kontroll over domenenavnet, og at innholdet i e-posten er uendret.
DMARC («Domain-based Message Authentication, Reporting and Conformance») bygger på både SPF og DKIM, og gir en anbefaling om hva mottakers e-postkonto bør gjøre dersom en e-post som har kommet inn feiler en av disse to sjekkene.
Både SPF, DKIM og DMARC baserer seg på at mottaker slår opp informasjon tilknyttet et domenenavn i DNS. Når et domene er sikret med DNSSEC (Domain Name System Security Extensions), vil det være mulig å kontrollere både at svaret kommer fra riktig kilde og at det ikke er endret underveis. 

Sikker konfigurasjon av tjenester, enheter og programvare er viktig for at angripere ikke skal få boltre seg fritt i en virksomhet og utnytte virksomhetens verdier og ressurser. Enkelte funksjoner og applikasjoner er likevel ekstra utsatt grunnet utstrakt kommunikasjon og interaksjon både internt i egen virksomhet og eksternt mot andre systemer. E-post og nettsider infisert med skadevare (virus, trojanere, osv.) er vanlige inngangsportaler for angrep, grunnet direkte interaksjon med brukere, andre systemer og nettsider. Innhold kan skreddersys for å lure brukere til å foreta handlinger som øker risiko for innføring av skadelig kode, tap av verdifulle data eller andre angrep.  Hensikten er å hindre at skadevare blir levert sluttbruker eller får kjøre på maskinen den blir levert til.

E-post er en av de viktigste tjenestene som benyttes i dag på intranett og internett. Vedlegg i e-post er en av de vanligste inngangsveiene for å distribuere datavirus, ormer og annen type skadevare. Vedleggene utnytter ofte sårbarheter i andre applikasjoner, som Excel, eller at filtypen som vises i e-postklienter (.jpg, .exe, .zip, osv.) ikke alltid samsvarer med den faktiske filtypen. Vedlegg i innkommende e-post bør derfor alltid behandles med varsomhet, spesielt hvis de er uventet eller hvis avsender ikke er kjent. Virksomheten bør sikre e-post slik at ingen uvedkommende får tilgang til eller kan manipulere innholdet, at avsender verifiseres og at e-post ikke benyttes som leveranse av skadevare.            

Nettleserteknologi har utviklet seg i et raskt tempo. Den har beveget seg fra den opprinnelige formen med å laste og vise tekst og bilder fra internett, til å bli et universelt «front-end» for nettverksbaserte applikasjoner. Nettlesere kan sees på som egne operativsystemer og kan håndtere et bredt spekter av forskjellige medieformater og fungerer også som en plattform for kjøring av fullverdige applikasjoner. Bruk av nettlesere kan føre til en rekke sikkerhetsproblemer grunnet feil bruk, feilkonfigurering eller programmeringsfeil. Mengden valg og funksjoner innebærer kompleks konfigurering og potensiale for sikkerhetsproblemer.

Anbefalte tiltak

ID

Beskrivelse

2.9.1

Sørg for at kun fullt støttede e-postklienter og nettlesere tillates å kjøre i virksomheten. Kun siste versjon av nettlesere bør benyttes slik at de siste sikkerhetsrettingene og den nyeste sikkerhetsfunksjonaliteten tas i bruk.

2.9.2

Skann alle e-postvedlegg som ankommer virksomhetens e-posttjeneste og blokker vedleggene dersom de inneholder skadelig kode, mistenkelig innhold (spam eller mistenkelige URL-er) eller filtyper som ikke er godkjent for bruk i virksomheten. For å oppdage ondsinnet kode i vedlegg bør vedlegg kjøres og aktiveres i egne sandkasse-miljøer.

2.9.3

Konfigurer nettleser sikkert slik at skadelig kode i størst mulig grad hindres å kjøre. Dette kan blant annet gjøres ved å ta i bruk «Beskyttet modus» som standardinnstilling for nettsurfing. Dersom virksomheten har ulike behov i forhold til funksjonalitet i nettleser, eksempelvis for å kunne skille privat og virksomhetsspesifikk data, kan virksomheten benytte to ulike nettlesere med ulike sikkerhetsinnstillinger.

2.9.4

Verifiser at innkommende e-post er fra en legitim virksomhet for å forhindre «spoofing».

2.9.5

Avinstaller eller deaktiver unødvendig eller uautoriserte plugins eller tilleggsprogrammer til e-postklient eller nettleser. Hver plugin bør benytte applikasjons- og URL-hvitlisting og kun tillate kjøring av programmer fra forhåndsgodkjente domener.

2.9.6

Konfigurer klienter slik at de ikke kjører aktivt innhold når innkommende HTML-formaterte e-poster vises. 

2.9.7

Begrens bruken av unødvendige skriptspråk i alle e-postklienter og nettlesere. Dette inkluderer bruk av språk som ActiveX og Javascript på alle systemer hvor det ikke er behov for støtte.

2.9.8

Sørg for at filer som lastes ned ikke automatisk kjører på maskinen siden disse kan inneholde skadevare.

2.9.9

E-post klienter eller nettlesere bør ikke tillates på annet enn sluttbrukerutstyr (eksempelvis bør det ikke benyttes på servere).

2.10 Etabler hensiktsmessig logging

Samle og administrere logger for hendelser som kan bidra til å oppdage, forstå, eller gjenopprette etter et angrep.

Hvorfor er dette viktig?

Hendelser bør registreres slik at sikkerhetsbrudd kan detekteres så tidlig som mulig, om ikke forhindres. Ved sikkerhetsbrudd kan logger bidra til at skadens karakter og omfang kan identifiseres og skaden utbedres. Manglende eller feilaktig konfigurering av logger og logganalyse vil kunne medføre at angripere uoppdaget kan skjule sin tilstedeværelse, skadevare og aktiviteter i virksomhetens IKT-systemer. Logger vil også bidra til å kartlegge skadeomfanget av et angrep, tidslinje for angrepet, og vil danne grunnlag for eventuelle rettslige forfølgelser.

Uønsket aktivitet i eget nettverk vil være utfordrende å oppdage, og dersom en angriper får fotfeste i virksomheten vil det meste av trafikken internt i eget nettverk maskeres som legitim trafikk. Logger må derfor benyttes for å etablere en oversikt over normaltilstand, slik at avvik kan oppdages. Dette, kombinert med mer bruk av ende-til-ende-kryptering, gjør at logging på endepunkter og mellom sikkerhetssoner bør prioriteres fremfor logging av generell nettverkstrafikk.

Logger er viktige for hendelseshåndtering og rasjonell drift av IKT-systemer, men de må også benyttes med varsomhet og således beskyttes godt. Logger kan inneholde sensitiv informasjon om den enkelte medarbeider og behovet for lagring av slik informasjon må til enhver tid veies opp mot behovet for personvern.

Anbefalte tiltak

ID

Beskrivelse

2.10.1

Logging må gjennomføres på en måte som sikrer ansvarlighet, tilgjengelighet og integritet. Logger må innsamles og håndteres på en måte som inngir tillit til det som står i loggen, at det som skal logges blir logget og at loggingen ikke er blitt stoppet, innholdet endret eller slettet. Logger skal kun benyttes til å ivareta sikkerheten i IKT-systemer og bør lagres i lang nok tid til at man kan oppdage og kartlegge uønsket aktivitet og bevegelse i etterkant av en hendelse.

2.10.2

Behovet for logging av metadata og/eller innhold bør veies mot brukerens og virksomhetens behov for konfidensialitetsbeskyttelse og bør beskrives.

2.10.3

Gjennomfør en intern vurdering for å avgjøre hvilke systemer og komponenter det er viktigst å generere logger for. Ta hensyn til følgende i vurderingen:

  • Hvor ligger virksomhetens mest sensitive data?
  • Hvilke systemer er virksomheten avhengig av for å understøtte leveranser og forretningsprosesser?
  • Hvilke brukere har størst privilegier i virksomheten?
  • Gjennom hvilke nøkkelpunkt flyter data?
  • Hvilke «gateway-er» finnes mellom interne og eksterne systemer?

2.10.4

Logging bør slås på i den konfigurasjonen som gir det beste datagrunnlaget for hendelseshåndtering. Generer logger for alle relevante systemer og komponenter med hovedfokus på endepunkter og trafikk mellom sikkerhetssoner.

2.10.5

Verifiser at loggingen fungerer etter hensikt og beskyttes mot manipulering.

  • Synkroniser logger mot minst to referansetidskilder slik at aktiviteter er tilordnet et korrekt tidsstempel og kan leses av kronologisk.
  • Valider at logginnstillinger fungerer og at det som skal logges blir logget. Sørg for at alle systemer som jevnlig lagrer logger har tilstrekkelig lagringsplass slik at loggfiler ikke fylles opp mellom rotasjonsintervallene.
  • Arkiver og signer loggene digitalt med jevne mellomrom for å sikre loggintegritet.
  • Samle logger i et sentralt lager slik at loggen er tilgjengelig når det er behov for dem. Benytt et standardisert format for logger slik at de enkelt kan leses av tredjeparts logganalyseverktøy.
  • Sørg for tilstrekkelig tilgangsstyring på logger og implementer funksjonalitet som oppdager forsøk på manipulering eller sletting av logger.