Ivareta en sikker konfigurasjon

Forrige Neste

Målet med prinsippet: Virksomheten konfigurerer og tilpasser maskin- og programvare slik at det tilfredsstiller virksomhetens behov for sikkerhet. Det er etablert rutiner for sporing, rapportering og korrigering av sikkerhetskonfigurasjon på enheter, programvare og tjenester for å hindre angripere i å utnytte disse.

Hvorfor er dette viktig?

De fleste IKT-produkter leveres med en standardkonfigurasjon utviklet av produsent eller forhandler. Disse konfigurasjonene er vanligvis utviklet for å forenkle installasjon eller bruk, ikke for å tilby god sikkerhet. Åpne tjenester og porter, standardkontoer og 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 eksplisitt konfigurert har mest sannsynlig sårbarheter som en angriper kan utnytte. Virksomheter må derfor herde IKT-produktene, eksempelvis ved å ta bort funksjonalitet det ikke er tjenstlig behov for samt fjerne standard-innstillinger og passord.

Anbefalte tiltak: Ivareta en sikker konfigurasjon

Anbefalte tiltak: Ivareta en sikker konfigurasjon
ID	Beskrivelse
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 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») 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.
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.

Utdypende informasjon

Herding er en viktig del av den totale informasjonssikkerheten. Manglende herding av systemkomponenter er ofte en årsak til at angripere får fotfeste i virksomheten. Operativsystemer på klientmaskiner og servere, databaser, brannmurer, skytjenester, e-postklienter og nettverksutstyr er eksempler på IKT-produkter som bør herdes. Disse produktene bør installeres og konfigureres slik at kun ønsket funksjonalitet er aktivert. Unødvendig funksjonalitet bør fjernes eller deaktiveres, slik at man får mindre angrepsflate, færre sårbarheter og mindre arbeid med sikkerhetsoppdatering.

IKT-systemet er under kontinuerlig endring når løsninger først er idriftsatt. Eksempler er oppgradering av enheter og programvare, tilgang til data og tjenester basert på nye brukerbehov, endringer i trusselbildet, nyoppdagede sårbarheter med mer. Angripere utnytter ofte at sikkerhetskonfigurasjonen på komponenter i nettverket svekkes over tid. Angripere søker etter uendrede, sårbare standardinnstillinger og logiske hull i klienter, servere, brannmurer, rutere og svitsjer og utnytter dette for å omgå eller komme gjennom sikkerhetsbarrierer. Det er derfor viktig at konfigurasjonen oppdateres og verifiseres ved jevne mellomrom og at avvik registreres, rapporteres og håndteres på en effektiv måte.

Utvikling av konfigurasjons-innstillinger med god sikkerhetsfunksjonalitet er en kompleks oppgave. For å ta gode valg må potensielt flere tusen innstillinger vurderes, besluttes og implementeres på alle deler av IKT-systemet. Å etablere en sikker konfigurasjon krever teknisk kompetanse på komponentene som skal herdes. Man bør derfor støtte seg på eksterne aktører. Ofte er første skritt å henvende seg til leverandøren av IKT-produktet. Leverandøren vil ofte ha en anbefalt «best practice» for sikrere bruk av produktet, og kanskje også en nedlastbar samling av sikkerhets-innstillinger for de som har behov for sikkerhet ut over det som er standard. I tillegg kan andre nasjoners sikkerhetsmyndigheter ofte ha gode anbefalinger på detaljert herding.