3. Opprettholde og oppdage

Publisert: 28.08.2017 | Sist endret: 29.08.2017

3.1 Sørg for god endringshåndtering

Opprettholde den sikre tilstanden over tid når virksomheten utsettes for planlagte eller ikke-planlagte endringer.

Hvorfor er dette viktig?

Eksempler på endringer som bør vurderes som fast-track:
- Tiden fra patch til skadevare blir kortere og kortere (ned mot en uke). Virksomheter må automatisere og forenkle prosessen for å implementere nye sikkerhetsoppdateringer..
- Opprettelsen av en ny bruker
Alle endringer bør gå til implementasjonsvurdering der også test må vurderes og sporbarheten må ivaretas.

Over tid vil en virksomhet utsettes for både planlagte og ikke-planlagte endringer av virksomhetsprosesser, organisasjon eller teknologi. Planlagte endringer kan initieres av en rekke rutinemessige hendelser, for eksempel feilretting, maskin- og programvareoppdateringer, kontoadministrasjon eller ytelsesjusteringer. Disse endringene kan kreve en gjennomgang og omdefinering av de implementerte sikringstiltakene, eksempelvis etter installasjon av ny programvare. Ikke-planlagte endringer kan initieres av en rekke dramatiske hendelser, for eksempel angrep, ulykker eller funksjonsfeil. Det er avgjørende for en virksomhet at disse endringene håndteres på en god måte, slik at virksomheten forstår konsekvensen av endringen og implementerer kompenserende tiltak for de eventuelle sårbarhetene selve endringen eller behovet for endring vil medføre. Først da vil IKT-systemet kunne holdes sikkert gjennom hele dets levetid.

Anbefalte tiltak

ID

Beskrivelse

3.1.1

Etabler en formell prosess for å håndtere og dokumentere alle forslag til endringer i virksomheten. Endringer som bør behandles i en felles prosess inkluderer, men er ikke begrenset til, endrede forretningsprosesser, nye oppdateringer, utskifting av utstyr, endring av organisasjon (brukere eller roller), endring av konfigurasjonen til systemkomponenter, og så videre.

3.1.2

Prosessen for endringshåndtering bør som et minimum inkludere følgende tre faser:

  • Teknisk gjennomgang av forslag til endring som resulterer i en teknisk anbefaling.
  • Vurdere de forretningsmessige konsekvenser av foreslåtte endringer og beslutte endring.
  • Planlegg implementering av godkjente endringer. Evaluering av konsekvenser av endringen og risiko må vurderes helhetlig. Dette kan eksempelvis være nedetid på IKT-systemer, behov for opplæring eller håndtering av økt risiko ved at endringen ikke er gjennomført.

3.1.3

Sørg for formelt å godkjenne og dokumenter alle endringer, og ikke bare et utvalg. Virksomheten bør etablere forhåndsgodkjenninger (fast track) av de fleste typer endringer slik at beslutningsleddene i virksomheten fokuserer på de viktigste endringene. Sporbarhet må ivaretas for alle endringer.

3.1.4

Benytt verktøy som automatisk oppdaterer og ruller ut godkjente endringer til virksomhetens systemer med gitte tidsintervaller, eller manuelt ved hendelser. Dette vil gjøre implementeringen enklere for virksomheten, og påse at kritiske endringer rulles ut hurtig nok.

3.2 Beskytt mot skadevare

Kontrollere installasjon, spredning og kjøring av skadelig kode i virksomhetens IKT-miljø og benytt automatiserte verktøy for sårbarhetsovervåkning og oppdatering sikringstiltak.

NSM NorCERT publiserer viktige oppdateringer på NSMs nettsider, se https://nsm.stat.no/norcert/norcertvarsler/
Tilsvarende varsler distribueres også fra kommersielle aktører og leverandører av programvare.

Hvorfor er dette viktig?

Skadelig kode er en integrert og farlig del av cybertrusler og kan utformes for å påvirke systemer, enheter og data. Det kan bevege seg hurtig, endre seg etter behov og komme seg inn gjennom en rekke punkter som sluttbrukerutstyr, e-postvedlegg, nettsider, skytjenester, ved brukerhandlinger og flyttbare medier. Moderne skadevare kan utvikles for å unngå forsvar, eller for å angripe eller deaktivere dem.

En virksomhet må ha oversikt over og beskyttes mot kjente skadevarer og angrepsmetoder. Forsvar mot skadevare må være i stand til å operere i dynamiske miljøer, gjennom storskala automatisering, hurtige oppdateringer, og integrert med prosesser som hendelseshåndtering. Det må også distribueres til et antall mulige angrepspunkter for å detektere, hindre bevegelse eller kontrollere kjøring av skadelig kode.

Anbefalte tiltak

ID

Beskrivelse

3.2.1

Installer sikkerhetsoppdateringer så fort som mulig. Selv de beste produktene har feil og sårbarheter som kan utnyttes av angripere. Etabler et sentralt styrt regime for oppdatering av applikasjoner, operativsystemer og firmware (f. eks. BIOS-kode).

3.2.2

Benytt automatiserte verktøy for kontinuerlig overvåkning av antivirus, antiskadevare, klient-brannmurer og vertsbaserte IPS-funksjonalitet installert på arbeidsstasjoner, serverer og mobile enheter. Alle hendelser relatert til oppdagelse av skadevare bør sendes til virksomhetens verktøy for administrasjon av antiskadevare og loggservere for hendelser.

3.2.3

Kjør automatiserte sårbarhetsskanningsverktøy mot alle systemer på nettverket, ukentlig eller hyppigere, prioriter og håndter de mest kritiske sårbarhetene og verifiser at sårbarhetene blir lukket. Benytt skanningsverktøy som både leter etter kodebaserte sårbarheter (CVE) og konfigurasjonsbaserte sårbarheter (CCE).

3.2.4

Abonner på tjenester relatert til sårbarhetsetterretning for å være oppdatert på nye og kommende sårbarheter og benytt denne informasjonen som input til verktøyene for sårbarhetsskanning. Alternativt sørg for at verktøy benyttet til sårbarhetsskanning jevnlig blir oppdatert med alle relevante sikkerhetssårbarheter.

3.2.5

Etabler en prosess for å risikovurdere sårbarheter basert på utnyttelsesmulighet og potensiell konsekvens. Tildel sikkerhetsrettinger for de mest risikoutsatte sårbarhetene først.

3.3 Verifiser konfigurasjon

Spore, rapportere og korrigere sikkerhetskonfigurasjon av enheter, programvare og tjenester for å hindre angripere i å utnytte sårbare tjenester og innstillinger.

Hvorfor er dette viktig?

IKT-miljøet er under kontinuerlig justering og endring når løsninger først er idriftsatt. Det kan være små og store endringer på enheter, programvare og tjenester, brukere som har behov for tilpasninger i forbindelse med bruk av tjenester, eller endringer i trusler, sårbarheter eller beskyttelsesbehov som gjør at konfigurasjonen må justeres.

Angripere utnytter ofte at sikkerhetskonfigurasjonen på komponenter i nettverket over tid svekkes. Angripere søker etter sårbare standardinnstillinger som ikke har blitt endret og logiske hull i sikkerhetskomponenter som brannmurer, rutere og svitsjer og utnytter dette for å omgå eller komme gjennom sikkerhetsbarrierer. Det er derfor viktig at konfigurasjonen sjekkes ved jevne mellomrom og at avvik registreres, rapporteres og håndteres på en effektiv måte.

Anbefalte tiltak

ID

Beskrivelse

3.3.1

Implementer og test et automatisert system for overvåkning av konfigurasjon som verifiserer alle eksternt testbare elementer for sikkerhetskonfigurasjon, og varsler når uautoriserte endringer forekommer. Dette inkluderer funksjonalitet for å oppdage endringer i brannmurkonfigurasjon (f.eks. åpning av nye porter), nye administrative brukere og nye tjenester som kjører på et system.

3.3.2

Sammenlign konfigurasjonen på systemkomponenter som nettverksutstyr og klienter (gjeldende konfigurasjon) mot en sikker, standard konfigurasjon (gyldig konfigurasjon) som er definert for hver enhet i virksomheten. Sikkerhetskonfigurasjonen for slike enheter bør dokumenteres, gjennomgås og godkjennes av virksomhetens endringskontrollregime. Alle avvik fra standardkonfigurasjon eller oppdateringer til denne skal dokumenteres og godkjennes av endringskontrollsystemet.

3.3.3

Kontroller at kun porter, protokoller og tjenester med godkjent forretningsbehov kjører på hvert system.

3.3.4

Utfør automatiserte portskanner regelmessig mot alle nøkkelservere og sammenlikne resultatet mot godkjent konfigurasjon. Hvis det oppdages en endring som ikke er en del av virksomhetens godkjente konfigurasjon bør det logges, automatisk rapporteres og gjennomgås av relevant personell.

3.3.5

Benytt verktøy for integritetssjekking for å sikre at kritiske systemfiler ikke har blitt endret. Integritetskontrollene bør identifisere mistenkelige systemendringer som endring av eier og tillatelser for filer eller kataloger, bruk av alternative datastrømmer som kan brukes til å skjule ondsinnede aktiviteter; og innføring av ekstra filer til viktige systemområder. Dette kan indikere skadelig nyttelast lagt igjen av angripere eller flere filer feilaktig lagt under batch distribusjon prosesser.

3.4 Gjennomfør inntrengingstester og «red-team»-øvelser.

Teste den totale styrken i virksomhetens forsvarsmekanismer (teknologi, prosesser og personell) ved å simulere mål og handlinger til en angriper.

Hvorfor er dette viktig?

I et komplekst miljø hvor teknologien konstant utvikler seg og nye angrepsmetoder stadig dukker opp, bør virksomheter jevnlig teste egen forsvarsevne for å identifisere gap og vurdere egen beredskap. Angripere utnytter ofte gapet mellom god design og funksjonalitet og gjeldende implementasjon og vedlikehold. Eksempler inkluderer:

  • For langt tidsvindu fra annonsering av en sårbarhet og tilgjengeliggjøring av retting fra leverandør, til faktisk installasjon på hver enkelt komponent.
  • Velmenende retningslinjer, for eksempel relatert til passordkvalitet, men manglende mekanismer for å påtvinge dette til brukere.
  • Mangelfull etablering av sikker konfigurasjon av komponenter i IKT-miljøet eller maskiner som jevnlig kobler seg til og fra nettverket.
  • Manglende evne til å forstå verdikjeder og avhengigheter mellom systemer.

Et vellykket forsvar krever et omfattende program av tekniske forsvar, god styring, gode retningslinjer og riktige handlinger fra personell.

Inntrengingstesting er et kontrollert dataangrep som prøver ut motstandskraften i IKT-systemer gjennom målrettede søk og analyser, og forsøksvis utnyttelse av sårbarheter, feil og mangler som identifiseres. Selv om angrepene tilstreber å simulere en trusselaktør, må virksomheter være bevisst at en inntrengingstest foregår i en begrenset tidsperiode og omfatter ofte kun enkelte, spesifikke mål. Resultatet av en slik test vil gi dypere innsikt, gjennom en faktisk demonstrasjon i hva slags virksomhetsrisiko sårbarheter kan utgjøre. Målet med en slik test vil være å finne de viktigste feilene slik at disse kan utbedres. En inntrengingstest kan demonstrere hvordan man kan få tilgang til virksomhetssensitive data, administrativ kontroll over deler av IKT-infrastrukturen eller kontroll over spesifikke tjenester. Samtidig kan tester benyttes før tjenester går i produksjon eller ved større endringer.

«Red Team»-øvelser tester virksomhetens beredskap for dataangrep gjennom simulering av faktiske angrep. Dette vil være en mer helhetlig tilnærming og vil utfordre virksomhetens retningslinjer, prosesser og sikringstiltak. Uavhengige «Red Team» kan bidra med verdifull og objektive testing av effektiviteten av beredskapsprosesser og personell tilknyttet dette.

Anbefalte tiltak

ID

Beskrivelse

3.4.1

Gjennomfør jevnlige eksterne og interne inntrengingstester for å identifisere sårbarheter og angrepsvektorer som kan bli brukt for å utnytte virksomhetens systemer og ressurser. Inntrengingstestingen bør gjennomføres fra utsiden av virksomhetens nettverksbarrierer (eksempelvis fra internett eller trådløse frekvenser i nærheten av virksomhetens lokaler) samt fra innsiden av barrierer (eksempelvis på det interne nettverket) for å simulere eksterne og interne angrep.

3.4.2

Still krav til at rapporteringen fra en inntrengingstest dekker behovene til hele virksomheten. En inntrengingstest bør dokumenteres med en oppsummering (ledelsesoppsummering), oversikt over detaljerte funn og eventuelt forslag til tiltak og en prioritering av funn.

3.4.3

Brukere eller kontoer som brukes til å utføre inntrengingstesting bør kontrolleres og overvåkes for å sikre at de bare brukes til lovlige formål, og fjernes eller gjenopprettes til normal funksjon etter at testingen er over.

3.4.4

Sørg for å informere relevante aktører i forkant av en inntrengingstest. Graden av informasjon og til hvilke parter avhenger av hva slags type test som skal gjennomføres. Identifiser samtidig miljøer, systemer eller komponenter som skal unntas fra testingen. Dette kan være deler av IKT-infrastrukturen som er kritisk i forhold til opprettholdelse av ulike tjenester eller som i løpet av testperioden ikke er tilstrekkelig konfigurert til å tåle en inntrengingstest.

3.4.5

Utføre periodiske «Red Team»-øvelser for å teste virksomhetens beredskap i forhold til å identifisere, stoppe og respondere hurtig og effektivt på dataangrep.

3.4.6

Planlegg inntrengingstestene med tydelige mål og omfang, gjerne med flere angrepsmåter for å simulere kompleksiteten ved APT-er (Advanced Persistent Threats), eksempelvis med en blanding av sosial manipulering og internett- eller nettverksutnyttelse. Bruk av flere ulike angrepsvektorer og verktøy vil gi et mer realistisk bilde i forhold til et faktisk angrep og vil gi en mer korrekt evaluering av de implementerte sikkerhetsbarrierene og forsvarssystemene i virksomheten.

3.4.7

Benytt verktøy for sårbarhetsskanning i kombinasjon med utnyttelses- og inntrengningsverktøy. Sårbarhetsskanningen kan benyttes som et utgangspunkt for å rettlede og fokusere inntrengingstestingen.

3.5 Overvåk og analyser IKT-systemet

Generere, samle, konsolidere, analysere og varsle på tilstrekkelig monitoreringsdata for å bygge en oppdatert situasjonsforståelse av handlinger og aktiviteter i virksomhetens nettverk.

Hvorfor er dette viktig?

For å overvåke og analysere IKT-systemet må en virksomhet vite hva som er «normaltilstand». Virksomheten må ha en egenevne til å oppdage unormal oppførsel og hendelser, hvor kun personell som forvalter systemene i det daglige har kompetanse til å se avvik fra normalbildet. For å få nok data til å oppdage og analysere unormaliteter og dataangrep er det viktig å ha informasjon fra flere kilder. Mange av kildene vil naturlig inngå i andre deler av dette dokumentet, inkludert:
- Kartlegg enheter og programvare
- Ivareta sikker design av IKT-miljø
- Ivareta en sikker konfigurasjon
- Ha kontroll på kontoer
- Kontroller bruk av administrative privilegier
- Kontroller dataflyt
- Beskytt e-post og nettleser
- Etabler hensiktsmessig logging
- Sørg for god endringshåndtering
- Beskytt mot skadevare
- Verifiser konfigurasjon

Manglende sikkerhetslogging, sammenstilling og analyse av loggdata gjør at angripere kan skjule tilstedeværelse, handlinger og aktiviteter i virksomhetens nettverk og på maskiner som utnyttes. Selv om en virksomhet vet at systemer og maskiner har blitt infiltrert, vil de være blinde for detaljene i angrepet dersom de ikke har tilstrekkelig loggdata og god nok beskyttelse og analyse av disse. For at loggdata skal kunne brukes effektivt må de samles til et sentralt punkt og konsolideres for å kunne oppdages, forstås og gjøre det mulig å reagere riktig på hendelser. Sammenstilling og analyse av loggdata er vesentlig for å kunne oppdage og forstå hendelser på tvers av strukturer og komponenter i nettverket. Loggdataene vil også kunne benyttes i forbindelse med granskning for å finne rotårsaken til hvorfor hendelsen oppsto, og i forbindelse med kriminaletterforskning.

Tidlig oppdagelse av uregelmessigheter og hendelser er vesentlig for å kunne oppdage og håndtere dataangrep. For å få til en hurtig og effektiv prosess rundt analyse og varsling basert på de samlede overvåkningsdataene, må virksomheten ha automatiserte analyseverktøy som kontinuerlig kalibreres basert på satte terskelverdier og kunnskap om «normalnivået» i virksomheten. «Normalnivået» beskriver hva som er et «rent nettverk» og hvilke innstillinger og dataflyt som er vanlig i nettverket under daglig drift. Hvilke enheter skal normalt få lov til å snakke med hverandre, og hvordan? Hvilke data skal flyte mellom hvilke sikkerhetssoner? Hva slags type trafikk kjører normalt i nettverket og til hvilke tider? Dette er spørsmål virksomheten må finne ut av når overvåknings- og analyseverktøy kalibreres.

Som med lokale logger må også sentraliserte loggdatabaser trimmes jevnlig. Dette for å unngå at man benytter unødig mye lagringsplass til loggdata man ikke har bruk for, både med hensyn til plass og personvern. Dette må veies opp mot behovet for å ta vare på data som man potensielt kan få bruk for i fremtidig etterforskning, skadevurdering, trendanalyser og kapasitetsplanlegging. 

Anbefalte tiltak

ID

Beskrivelse

3.5.1

Utarbeid en strategi for logging og fastsett hvor lenge logger skal oppbevares.  Gjennomfør en vurdering i hele virksomheten på hvilke behov som finnes for overvåkningsdata. Denne vurderingen bør gjøres jevnlig (minst en gang i året) og ved spesielle behov (f. eks. etter et en større hendelse eller ved et vellykket dataangrep).

3.5.2

Aktiver logging på relevante komponenter og punkter i IKT-infrastrukturen.. Samle relevante overvåkningsdata og konsolider dette til en stor eller flere sammenkoblede databaser. Eksempler på dette kan være loggdata fra klienter og nettverksenheter.

3.5.3

Automatiser prosessen med å analysere innsamlede data ved benyttelse av analyseverktøy som kalibreres og vedlikeholdes.

3.5.4

Gjennomgå og trim den sentrale loggdatabasen jevnlig i tråd med strategien slik at den kun tar vare på verdifulle loggdata. Dette innebærer å:

  • Fjerne innsamlede loggdata som ikke lenger har noen operasjonell eller sikkerhetsmessig relevans
  • Ta vare på loggdata som potensielt kan benyttes i forbindelse med etterforskning, skadevurdering, trendanalyser og kapasitetsplanlegging.
  • Kombinere flere lav-nivå hendelser til en eller flere systematiske hendelser som viser et høyere tjenestenivå perspektiv, og samtidig fjern lav-nivå hendelser.
  • Overføre loggdata for trendanalyser og kapasitetsplanlegging til mer kompakte presentasjoner som oppsummeringer eller statistikker.

3.5.5

Etabler og vedlikehold en profil for «normaltilstand» i virksomhetens IKT-systemer og opparbeid kompetanse og kapabilitet til å oppdage anomaliteter i systemene ved at systemenes logger sentraliseres, sees i sammenheng og gjennomgås. Fastsett og vedlikehold terskelverdier og generer automatiske alarmer med varsling til en bemannet tjeneste i virksomheten hvor alarmer håndteres. Normaltilstanden bør forvaltes over tid slik at den ivaretar endringer i bruksmønster i forbindelse med omstillinger og omorganiseringer, oppkjøp, sammenslåing, nedbemanning og endring av driftskonsept.

3.5.6

Konfigurer overvåkningssystemer for å undersøke både inngående og utgående trafikk samt trafikken i utsatte soner mot kjente sårbarheter og angrepsmetoder. Overvåkningssystemene som benyttes på nettverkenes perimeter og de som benyttes for å beskytte interne nettverk bør være ulike for å ivareta sikkerhet i dybden.

3.6 Etabler kapabilitet for gjenoppretting av data

Etabler en metode for sikkerhetskopiering og gjenoppretting av kritiske data for å hindre tap.

En plan for sikkerhetskopiering bør som et minimum beskrive:
- Hvilke data som skal sikkerhetskopieres
- Hvilke data som skal ekskluderes fra sikkerhetskopier
- Regelmessighet for sikkerhetskopiering. Ukentlig sikkerhetskopiering anbefales, hyppigere for virksomhetskritiske - systemer eller systemer hvor data endres ofte.
- Hvilke forretningsenheter som er ansvarlig for sikkerhetskopieringen
- Prosedyrer for feilrapporter
- Oppbevaringsperiode
- Gjenopprettingsevne og krav til denne
- Beskyttelse av sikkerhetskopieringsdata

Hvorfor er dette viktig?

Virksomheten må etablere kapasitet for å gjenopprette tapte eller endrede data eller systemkonfigurasjoner. Enkelte dataangrep medfører at kritiske konfigurasjoner, programvare eller informasjon endres eller gjøres utilgjengelig. Dette kan påvirke virksomhetskritiske prosesser. Et eksempel på et slikt angrep er kryptovirus, der informasjon eller hele systemer krypters slik at de blir utilgjengelige for en virksomhet.   

Anbefalte tiltak

ID

Beskrivelse

3.6.1

Sikkerhetskopiering av data bør gjennomføres regelmessig av alle relevant data, basert på en sikkerhetskopieringsplan. En slik plan bør stille krav til gjenopprettingstid fra sikkerhetskopi for virksomhetens ulike systemer basert på en verdivurdering eller behov for tjenestekvalitet. Planen bør også beskrive målet for hva slags data som hentes tilbake (fra hvilket punkt hentes data fra).

3.6.2

Planen for sikkerhetskopiering bør godkjennes av prosesseiere som bruker dataene og ansvarlige for applikasjonen som forvalter de data som skal sikkerhetskopieres.

3.6.3

For å sikre rask gjenoppretting, bør både operativsystemet, programvaren og dataene på en maskin være inkludert i den generelle sikkerhetskopieringsprosedyren. Disse tre komponentene i et system må ikke nødvendigvis inkluderes i den samme sikkerhetskopifilen eller bruke samme sikkerhetskopieringsprogramvare.

3.6.4

Det bør være flere sikkerhetskopieringer over tid, slik at systemet kan gjenopprettes selv om systemet er sikkerhetskopiert etter at en feil eller infeksjon oppstod.

3.6.5

Sikkerhetskopier bør lagres på en alternativ lokasjon enn produksjonsservere. Denne lokasjonen bør tilfredsstille de samme kravene som ellers i virksomheten for å forvalte informasjonen som sikkerhetskopieres.

3.6.6

Test sikkerhetskopier regelmessig ved å utføre en gjenopprettingsprosess for å sikre at sikkerhetskopieringen fungerer tilstrekkelig.

3.6.7

Kontroller at sikkerhetskopier er riktig beskyttet via fysisk sikkerhet eller kryptering når de lagres, samt når de flyttes over nettverket. Dette inkluderer ekstern sikkerhetskopiering og skytjenester.

3.6.8

Som et minimum bør virksomhetskritiske systemer ha minst en sikkerhetskopidestinasjon som ikke kan adresseres kontinuerlig gjennom operativsystemanrop. Dette vil redusere risikoen for angrep som krypteringsvirus. Dissesøker å kryptere eller ødelegge data på alle adresserbare filområder, inkludert lokasjoner for sikkerhetskopier.