Nasjonal sikkerhetsmyndighet

Transkript

1 Nasjonal sikkerhetsmyndighet Veiledning Sist oppdatert: Veiledning i grunnleggende sikkerhetsarkitektur og -funksjonalitet for FELLESNIVÅ operasjonsmåte Dette dokumentet veileder om krav som Forskrift om informasjonssikkerhet stiller til systemteknisk sikkerhet i fellesnivå datasystemer uten tilknytning til andre systemer. Kravene adresserer sikkerhet i operativsystemer og basistjenester.

2 Nasjonal sikkerhetsmyndighet Nasjonal sikkerhetsmyndighet er tverrsektoriell fag- og tilsynsmyndighet innenfor forebyggende sikkerhetstjeneste i Norge og forvalter lov om forebyggende sikkerhet av 20 mars Hensikten med forebyggende sikkerhet er å motvirke trusler mot rikets selvstendighet og sikkerhet og andre vitale nasjonale sikkerhetsinteresser, primært spionasje, sabotasje og terrorhandlinger. Forebyggende sikkerhetstiltak skal ikke være mer inngripende enn strengt nødvendig, og skal bidra til et robust og sikkert samfunn. Hensikt med veiledning NSM sin veiledningsvirksomhet skal bygge kompetanse og øke sikkerhetsnivået i virksomhetene, gjennom økt motivasjon, evne og vilje til å gjennomføre sikkerhetstiltak. NSM gir jevnlig ut veiledninger til hjelp for implementering av de krav sikkerhetsloven stiller. NSM publiserer også veiledninger innen andre fagområder relatert til forebyggende sikkerhetsarbeid. Postadresse Sivil telefon/telefax Militær telefon/telefaks Internettadresse Postboks / / BÆRUM E-postadresse POSTTERMINAL post@nsm.stat.no Side 2 av 16

3 Innhold 1 Generelt Bakgrunn Målgruppe Formål Innhold Introduksjon Systemteknisk sikkerhet Systemtekniske sikkerhetsmekanismer Fellesnivå operasjonsmåte Systemutvidelser System og brukerområder Skitne applikasjoner Fysisk tilgang til datautstyr Sikkerhetsdokumentasjon KSS Del 1 Systemteknisk sikkerhetskonsept KSS Del 2 Systemtekniske sikkerhetskrav KSS Del 3 Systemtekniske sikkerhetstiltak KSS Del 4 Systemtekniske sikkerhetstester KSS Del 5 Systemteknisk risikovurdering Brukerinstruks systemteknisk sikkerhet Driftsinstruks systemteknisk sikkerhet Sikkerhetskonsept Operasjonsmåte Eksterne forbindelser Designprinsipper Sikkerhetskrav Systemdesign Autentisitet Konfidensialitet Integritet Tilgjengelighet Ansvarlighet Dokumenthistorie... 9 Side 3 av 16

4 1 Generelt Dette dokumentet veileder om krav som Forskrift om informasjonssikkerhet stiller til systemteknisk sikkerhet i fellesnivå datasystemer uten tilknytning til andre systemer. Kravene adresserer sikkerhet i operativsystemer og basistjenester. For andre operasjonsmåter henvises til Veiledning i valg av operasjonsmåte og Veiledning i grunnleggende sikkerhetsarkitektur og -funksjonalitet for partisjonert operasjonsmåte (V-PA-01). 1.1 Bakgrunn Dagens datasystemer består i hovedsak av kommersiell hyllevare. Stadig mer hyllevare leveres med sikkerhetsfunksjonalitet for fellesnivå operasjonsmåte. Endel er til og med evaluert og sertifisert. NTCSEC [ab] beskriver NATOs og Norges krav til C2 sikkerhetsfunksjonalitet og tillit. 1 C2 sikkerhetsfunksjonalitet er en nødvendig, men ikke tilstrekkelig forutsetning for å få systemer godkjent for fellesnivå operasjonsmåte. Fordi NTCSEC gir generelle retningslinjer som i hovedsak retter seg mot operativsystemer, sier dokumentet lite eller ingenting om systemintegrasjon eller hvordan den påkrevde sikkerhetsfunksjonaliteten skal konfigureres og brukes. Systemeiers utfordring blir i hovedsak derfor å sette sammen hyllevaren til et helhetlig og konsistent system, og å konfigurere og bruke systemet på en sikker måte. Erfaring viser at dårlig systemintegrasjon eller tilsynelatende små feil i konfigurasjon og bruk alvorlig kan svekke sikkerheten. En slik situasjon kan være verre enn ikke å ha såkalt «sikker» programvare: Den «sikre» programvaren gir liten eller ingen bedring av sikkerheten, men inngir likevel en falsk trygghetsfølelse som reduserer aktsomheten. 1.2 Målgruppe Målgruppen for dette vedlegget er systemeiere, systemadministratorer, datasikkerhetsledere og annet personell som planlegger, utvikler, administrerer eller godkjenner graderte datasystemer. 1.3 Formål Dokumentet veileder om krav som Forskrift om informasjonssikkerhet stiller til systemteknisk sikkerhet i fellesnivå datasystemer uten tilknytning til andre systemer. Kravene adresserer sikkerhet i operativsystemer og basistjenester, og skal bidra til: Valg av produkter som satt sammen på riktig måte gir datasystemer med en helhetlig og konsistent sikkerhetsarkitektur/sikkerhetsfunksjonalitet Sikker konfigurasjon og bruk av slike datasystemer Eksterne tilknytninger og tilleggskomponenter, f eks, brannmurer, meldingstjeneste/gruppevare, web og databaser, dekkes ikke av dette dokumentet, men må dekkes av egne retningslinjer som adresserer særtrekk ved disse utvidelsene; utvidelser av denne type kan dessuten medføre skjerpede retningslinjer for operativsystem og basistjenester. 1.4 Innhold Kapittel 2 gir en kort introduksjon til noen sentrale begreper som omtales senere i dokumentet. Kapittel 3 beskriver påkrevd systemteknisk sikkerhetsdokumentasjon. Kapittel 4 gir retningslinjer for systemteknisk sikkerhetskonsept. Kapittel 5 beskriver tilhørende systemtekniske sikkerhetskrav. 1 Også produkter som følger ITSEC [aj] og CC [an] kan benyttes som alternativer til NTCSEC, men da med profiler som tilsvarer C2. Side 4 av 16

5 2 Introduksjon Denne seksjonen gir en kort introduksjon til noen sentrale begreper som omhandles senere i dokumentet. 2.1 Systemteknisk sikkerhet Ved databehandling i fellesnivå operasjonsmåte er det særlig fem aspekter ved sikkerheten som skal ivaretas: Autentisitet (ekthet) Konfidensialitet Integritet Tilgjengelighet Ansvarlighet Systemteknisk sikkerhet er, kort sagt, hvordan disse aspektene ivaretas av datasystemets programog maskinvare. 2.2 Systemtekniske sikkerhetsmekanismer Autentisitet ivaretas i hovedsak av innloggingsmekanismen som knytter prosesser til brukere; tilsvarende finnes det mekanismer som knytter nettverksforbindelser til prosesser. Konfidensialitet, integritet og tilgjengelighet ivaretas i hovedsak av tilgangskontrollmekanismer som regulerer brukernes tilgang til data. Andre mekanismer som ivaretar konfidensialitet, integritet og tilgjengelighet er bl a kryptering, kryptografiske sjekksummer og kvoter. Ansvarlighet ivaretas i hovedsak av loggemekanismen, som knytter sikkerhetsrelevante hendelser til individuelle brukere. 2.3 Fellesnivå operasjonsmåte Fellesnivå operasjonsmåte kjennetegnes ved at: Brukerne har klarering og autorisasjon for høyeste gradering som behandles Tilgang til data reguleres iht brukernes tjenestelige behov Systemet, inkludert applikasjoner, beskyttes mot endringer og manipulasjon fra brukere uten administrative rettigheter Sikkerhetsrelevante hendelser registreres slik at evt sikkerhetsbrudd kan avsløres og skadeomfang og individuelt ansvar kan beregnes Fokus er på individet: Brukere får tilgang iht individuelle tjenestelige behov og står individuelt ansvarlig for sin bruk av systemet. Dette utelukker anonym tilgang og felles brukerkonti. 2.4 Systemutvidelser Operativsystemets evaluerte og sertifiserte sikkerhetsfunksjonalitet danner en pålitelig basis for sikkerheten i et datasystem. Men brukere trenger også applikasjoner og verktøy, og noen av disse inneholder komponenter som utvider operativsystemets sikkerhetsfunksjonalitet. To typer utvidelser er vanlige: Privilegerte prosesser Programvare med egne sikkerhetsfunksjoner En privilegert prosess er ikke underlagt operativsystemets sikkerhetsfunksjonalitet. En privilegert prosess kan f eks være en antivirusagent, en enhetsdriver som lastes i OS-kjernen eller en demon/service med utvidete rettigheter. Systemsikkerheten er avhengig av at den privilegerte prosessen bare utfører sin tiltenkte funksjon, og at den kan håndtere feil og ikke lar seg manipulere. Side 5 av 16

6 Store og systemnære programmer implementerer gjerne egne sikkerhetsfunksjoner som overlapper med eller utfyller sikkerhetsfunksjonaliteten til operativsystemet. Dette kan f eks være et databaseeller meldingssystem som implementerer egne funksjoner for innlogging, tilgangskontroll og logging. Som med privilegerte prosesser er systemsikkerheten avhengig av at utvidelsen bare utfører sin tiltenkte funksjon, og at den kan håndtere feil og ikke lar seg manipulere. Komponenter som utvider sikkerhetsfunksjonaliteten skal i utgangspunktet evalueres og sertifiseres tilsvarende som operativsystemer. Særlig gjelder dette store privilegerte prosesser og komponenter med dårlig integrert egendefinert sikkerhetsfunksjonalitet. Programvare med sikkerhetsfunksjonalitet som baserer seg på og er tett integrert med operativsystemet kan evt unntas fra evaluering og sertifisering, avhengig av godkjenningsmyndighetens vurdering. Tett integrert programvare leveres gjerne av samme produsent som laget operativsystemet. 2.5 System og brukerområder Datasystemet kan deles inn i to typer områder: Systemområder Brukerområder Systemområdene omfatter operativsystemet og installerte applikasjoner. Brukerområdene omfatter brukerdata, f eks fellesområder og hjemmeområder, inkludert brukernes personlige oppsett for bruk av systemet. 2.6 Skitne applikasjoner Applikasjoner som er utviklet for personlige datamaskiner (PC) fungerer ofte dårlig på flerbrukermaskiner (arbeidsstasjoner). En viktig årsak til dette er at de ikke skiller mellom systemområder og brukerområder. «Skitne» applikasjoner kjennetegnes ved at de: Initierer brukeroppsettet ifm installasjon fremfor ifm førstegangs bruk. Bare brukeren som installerer applikasjonen får korrekt oppsett. Lagrer data på systemområder (som i utgangspunktet er skrivebeskyttet) fremfor på brukerens hjemmeområde. Skitne applikasjoner som installerer felleskomponenter bryr seg sjeldent om versjonskontroll: komponenter kan like gjerne nedgraderes som oppgraderes. 2.7 Fysisk tilgang til datautstyr Fysisk tilgang til datautstyr gir brukere gode muligheter for å omgå systemtekniske sikkerhetstiltak. Brukere med fysisk kontroll over maskinens harddisk kan enkelt manipulere harddisken fra et operativsystem hvor brukeren har administrative privilegier. Dette operativsystemet kan medbringes på eget media som kobles til den aktuelle maskinen, eller brukeren kan koble den aktuelle harddisken til et annet system. Arbeidsstasjoner uten harddisk kan ikke kompromitteres på denne måten. Låsbare kabinett og fastlåste (uttakbare) harddisker reduserer muligheten for denne type angrep. Brukere kan også relativt enkelt registrere andre brukeres tastetrykk (f eks passord) ved å montere falske tastaturkabler/-overganger med eget minne. Oversiktlig montering av utstyret øker muligheten for å oppdage slike angrep. 3 Sikkerhetsdokumentasjon Evaluerte og sertifiserte operativsystemer leveres med generelle retningslinjer for sikker installasjon og bruk. Retningslinjene adresserer et generisk operativt miljø som tradisjonelt har bestått av et lokalnett/intranett med servere og arbeidsstasjoner. Eksterne tilknytninger og applikasjoner har typisk ikke vært inkludert. Systemeier må selv, basert på retningslinjene for operativsystemet og retningslinjer fra godkjenningsmyndigheten, integrere ønsket programvare med operativsystems sikkerhetsfunksjonalitet i en helhet- Side 6 av 16

7 lig og konsistent sikkerhetsløsning; systemeier må også etablere prosedyrer for sikker konfigurasjon og bruk av systemet i systemeiers spesifikke operative miljø. Både den systemtekniske løsningen og prosedyrene skal dokumenteres i form av en KSS og systemtekniske instrukser for brukere og driftspersonell. Den systemtekniske beskrivelsen som inngår i en KSS har fem deler (vedlegg): én del for hver fase i godkjenningsprosessen. Delene 2 4 bør så langt som mulig ha identisk struktur, noe som gjør det enklere å spore utviklingen av sikkerhetsløsningen fra krav, via design- og implementasjon, til testing. Strukturen til skal fremheve sikkerhetsaspektene ved systemet fremfor de funksjonelle aspektene. NSM har som målsetting å utarbeide retningslinjer/eksempler/maler/sjekklister for systemteknisk sikkerhetsdokumentasjon for de mest ettersøkte løsningstypene. Disse vil gjøres tilgjengelig på NSM sine hjemmesider etter hvert som de ferdigstilles. Systemeier utarbeider sine systemspesifikke dokumenter på grunnlag av gitte retningslinjer og lokale behov. Det er vanligvis tilstrekkelig å bare beskrive avvik fra retningslinjene. Systemeiere oppmuntres til å etablerer standardløsninger som kan «typegodkjennes» og gjenbrukes i flere installasjoner/systemer. Bare referanseinstallasjonen vil da måtte gjenomgå en full systemteknisk sikkerhetsgodkjenning. Standardisering og bruk av «typegodkjente» løsninger kan bidra til å vesentlig redusere systemeiers og godkjenningsmyndighetens innsats ifm en sikkerhetsgodkjenning. 3.1 KSS Del 1 Systemteknisk sikkerhetskonsept «KSS Del 1 Systemteknisk sikkerhetskonsept» skal beskrive det systemtekniske sikkerhetskonseptet som ligger bak løsningen. Kapittel 4 i dette dokumentet gir retningslinjer for innholdet. 3.2 KSS Del 2 Systemtekniske sikkerhetskrav «KSS Del 2 Systemtekniske sikkerhetskrav» skal beskrive de systemtekniske sikkerhetskravene som stilles til datasystemet. Kapittel 5 i dette dokumentet gir retningslinjer for innholdet. 3.3 KSS Del 3 Systemtekniske sikkerhetstiltak «KSS Del 3 Systemtekniske sikkerhetstiltak» skal beskrive hvordan sikkerhetskonseptet og - kravene implementeres i datasystemet. Produktspesifikk sikkerhetsdokumentasjon, retningslinjer fra godkjenningsmyndighet/nsm og KSS er fra liknende løsninger danner utgangspunkt for innholdet. 3.4 KSS Del 4 Systemtekniske sikkerhetstester «KSS Del 4 Systemtekniske sikkerhetstester» skal beskrive hvordan de implementerte sikkerhetstiltakene testes. Dokumentet skal bl a inneholde testmetodikk, testmiljø og testprosedyrer (inkl forventet resultat). Testene skal dokumenteres slik at de skal kunne gjentas av en uavhengig tredjepart. Hver testgjennomføring skal resultere i et anneks med en testrapport som bl a inneholder testresultater og en oppsummering. 3.5 KSS Del 5 Systemteknisk risikovurdering Ingen systemer oppfyller alle krav og passerer alle sikkerhetstester. «KSS Del 5 Systemteknisk risikovurdering» skal håndtere avvikene som blir identifisert ifm det foregående arbeidet med konsept, krav, tiltak og tester. De sikkerhetsmessige konsekvensene av hvert avvik skal beskrives og vurderes; kompenserende tiltak skal iverksettes inntil den gjenværende risiko er akseptabel. 3.6 Brukerinstruks systemteknisk sikkerhet «Brukerinstruks systemteknisk sikkerhet» skal beskrive de systemtekniske sikkerhetsmekanismer som brukerne benytter, f eks innlogging og tilgangskontroll. Dokumentet skal inneholde prosedyrer for daglig bruk av systemet. Dokumentet kan være del av en større brukerinstruks. 3.7 Driftsinstruks systemteknisk sikkerhet «Driftsinstruks systemteknisk sikkerhet» skal beskrive de sikkerhetsmekanismene som systemadministratoren og annet driftspersonell får befatning med (eller referere til slik dokumentasjon). Dokumentet skal inneholde prosedyrer for hvordan systemet skal installeres, konfigureres og driftes i samsvar med sikkerhetskravene. Dokumentet kan være del av en større driftsinstruks. Side 7 av 16

8 4 Sikkerhetskonsept Det systemtekniske sikkerhetskonseptet setter rammer for og skisserer de viktigste trekkene ved den ønskede systemtekniske sikkerhetsløsningen. Unntak fra konseptet skal dokumenteres i systemets systemtekniske KSS og inngå i systemets risikovurdering. Kompenserende tiltak kan være påkrevd for å bringe risiko for sikkerhetsbrudd ned på et akseptabelt nivå. 4.1 Operasjonsmåte Systemet skal ha fellesnivå operasjonsmåte. 4.2 Eksterne forbindelser Systemet skal ikke ha eksterne forbindelser. 4.3 Designprinsipper Ved design av systemet skal det tas hensyn til følgende prinsipper: a. Minimale privilegier b. Minimal kompleksitet/funksjonalitet c. Forsvar i dybden d. Redundans i kritisk komponenter e. Balansert implementasjon f. Sentralisering Med redundans i kritisk komponenter menes at man søker å unngå at enkeltfeil får kritisk betydning for sikkerheten; med balansert implementasjon menes at man søker å unngå bakdører ved å ha jevn styrke og utbredelse av implementerte sikkerhetstiltak; med sentralisering menes at sikkerhetsfunksjoner er underlagt sentral styring og kontroll evt delegering skjer innenfor klart fastsatte og obligatoriske rammer. 5 Sikkerhetskrav Erfaring viser at dårlig utnyttet eller dårlig konfigurert sikkerhetsfunksjonalitet kan føre til sikkerhetsbrudd. Selv små og tilsynelatende uskyldige svakheter i oppsettet kan være nok til at rutinerte og dyktige inntrengere får en fot innenfor. I store organisasjoner er det også viktig at den valgte sikkerhetspolitikken er enhetlig og konsistent implementert. Brukerne klarer bedre å ivareta sikkerheten når de har enkle og forståelige retningslinjer å forholde seg til. Unntak fra kravene skal dokumenteres i systemets systemtekniske KSS og inngå i systemets risikovurdering. Kompenserende tiltak kan være påkrevd for å bringe risiko for sikkerhetsbrudd ned på et akseptabelt nivå. 5.1 Systemdesign Anskaffelse, distribusjon og oppdatering av programvare a. Systemets programvare skal anskaffes fra anerkjente og tiltrodde kilder. b. Programvarens autentisitet og integritet skal sikres under distribusjon. c. Leverandører av viktige sikkerhetskomponenter skal ha et opplegg for å tette sikkerhetshull i produktene sine kort tid etter at de oppdages. Side 8 av 16

9 5.1.2 Evaluerte og sertifiserte komponenter a. Evaluerte og sertifiserte produkter skal foretrekkes. b. Sertifiserte produkter skal, såfremt praktisk mulig, installeres, konfigureres og driftes iht produktenes sikkerhetsdokumentasjon. Vesentlige unntak skal dokumenteres i konseptfasen og er avhengig av godkjenningsmyndighetens aksept Systemutvidelser med integrert sikkerhet a. Systemutvidelser som introduserer ny sikkerhetsfunksjonalitet skal være baserte på og tett integrerte med operativsystemets sikkerhetsfunksjonalitet, f eks slik at brukere bare behøver å logge inn én gang per sesjon. b. Sikkerhetsfunksjonalitet skal implementeres i systemkomponenter, ikke i programmer som kjører i brukerens sikkerhetskontekst Applikasjoner a. Flerbrukerapplikasjoner («rene» applikasjoner) skal foretrekkes og PC-applikasjoner («skitne» applikasjoner) skal bare unntaksvis benyttes. b. Logoapplikasjoner skal foretrekkes der det eksisterer et (leverandørstøttet) sertifiseringsprogram for programvare for det valgte operativsystemet Kryptografiske mekanismer Kryptografiske mekanismer skal godkjennes av NSM Nettverkstopologi I systemer med et WAN som knytter sammen flere LAN skal: a. Hvert LAN være en sikkerhetssone beskyttet av en sikkerhetsbarriere. b. Fellestjenester (dvs tjenester som benyttes av mer enn ett LAN) skal plasseres på egne LAN uten sluttbrukere slik at LAN med lokale sluttbrukere ikke behøver å tilby tjenester til sluttbrukere i andre LAN Brukerkategorier Omfanget av en kompromittering begrenses ved å begrense brukernes privilegier og virkeområde. a. Brukerkonti skal inndeles i kategorier med ulike rettighetsnivåer: Sluttbrukere uten administrative privilegier «Tunge» sluttbrukere som kan administrere lokale tilleggsapplikasjoner Administratorer av arbeidsstasjoner Administratorer av servere (med evt underkategorier) b. Sluttbrukerkonti skal ha minimal tilgang til servere og normalt ikke ha noen administrative privilegier. c. Tunge sluttbrukerkonti med behov for spesiell programvare skal tildeles akkurat nok privilegier til at de selv kan installere og vedlikeholde denne programvaren lokalt på sin personlige arbeidsstasjon. Dette skal bare skje unntaksvis. d. Konti for administrasjon av arbeidsstasjoner skal ha minimale serverrettigheter (omtrent som sluttbrukerkonti) e. Konti for administrasjon av servere skal ikke brukes til å administrere arbeidsstasjoner (selv om de kan ha nødvendige administrative privilegier). f. I store systemer med spesialiserte driftsroller skal rollen som serveradministrator deles inn i underkategorier med begrensede privilegier og virkeområde: Operatør på servere (f eks administrasjon av konti, skrivere eller sikkerhetskopiering) Side 9 av 16

10 Administrator for en spesiell servertype (f eks katalog, web, MTA eller database) Administrator for alle servere Administrative arbeidsstasjoner a. Arbeidsstasjoner som brukes til administrasjon, f eks av konti, skal sikres systemteknisk tilsvarende som servere og skal ikke kunne nås av sluttbrukere. b. Arbeidsstasjoner som benyttes til administrasjon av arbeidsstasjoner skal ikke kunne benyttes til administrasjon av servere Sentralisert lagring av brukerdata Brukerdata (inkludert brukerprofiler) skal lagres på servere; bare temporære data kan evt lagres lokalt på arbeidsstasjoner. 5.2 Autentisitet Personlige brukerkonti Alle brukere skal tildeles en personlige 2 brukerkonto og et hemmelig passord (eller annen type autentiseringsdata godkjent av NSM) Autentiseringsdata Autentiseringsdata skal beskyttes vha kryptografiske mekanismer eller maskinvare godkjent av NSM (f eks smartkort) Utdeling av passord til brukere a. Nye brukerkonti skal tildeles passord før eller ifm aktivering. b. Hvis datasikkerhetsleder gir en bruker et nytt passord skal det være unikt og systemet skal kreve et nytt passord ifm neste innlogging Fornying av passord a. Passord skal utgå etter 90 dager. b. Systemet skal varsle om fornyelse av passord minst to uker før det utgår. c. Brukere med utgåtte passord skal avkreves et nytt passord ifm neste innlogging; alternativt skal konti sperres samme dag som passordet utgår. d. Brukere skal ikke kunne skifte passord som er yngre enn ett døgn Styrken til passord Før et passord tas i bruk skal systemet kontrollere at passordet har minimum 14 tegn 3 består av store og små bokstaver samt tall eller spesialtegn 2 At en brukerkonto er personlig utelukker ikke at den kan være rollebasert, f eks knyttet til en fast stilling/funksjon i organisasjonen. Organisasjonen må da vedlikeholde en (manuell) logg som angir hvilke personer som besatte hvilke stillinger i hvilke perioder. Loggen må sikres og oppbevares som andre loggdata. 3 Passordlengen kan reduseres hvis den passordbaserte autentiseringen suppleres av smartkortbasert innlogging med privat sertifikat (PKI). Side 10 av 16

11 er ulikt brukerens tidligere passord Tidspunkt for innlogging og bruk Brukerens mulighet for innlogging og bruk av datasystemet skal begrenses til rimelige tidspunkter i forhold til brukerens arbeidstid Innloggingsrettigheter a. Bare «eier» og administratorer skal kunne logge inn på en personlig arbeidsstasjon. b. Bare brukere med et faktisk tjenestelig behov og administratorer skal kunne logge inn på en felles arbeidsstasjon. c. Sluttbrukere skal ikke kunne logge inn på en administrativ arbeidsstasjon. d. Sluttbrukere og administratorer av arbeidsstasjoner skal ha minimale innloggingsrettigheter på servere Sperring for innlogging a. Ved tre påfølgende mislykkede forsøk på innlogging i løpet av en periode på inntil fem minutter skal berørte brukerkonto sperres for innlogging i minst 10 sekunder. 4 b. Denne typen sperring skal ikke hindre administratorer i å logge seg inn på maskinens konsoll Skjermsparer med reautentisering En obligatorisk skjermsparer med reautentisering skal automatisk aktiveres etter en gitt periode med inaktivitet på terminalen eller når autentiseringsdata (f eks smartkort) fjernes. I kontorlandskaper skal skjermspareren aktiveres etter maksimum 15 minutters inaktivitet; på låsbare kontorer skal den aktiveres etter maksimum 150 minutters inaktivitet Autentisering av nettverkstrafikk Nettverkstrafikk skal autentiseres mht både avsender- og mottaker (dvs toveis) på a. Nettverkslaget (f eks IP) b. Applikasjonslaget (f eks klient-server applikasjoner for fil, print, web og e-post) 5.3 Konfidensialitet Tilgang til systemområder Brukere skal ikke kunne lese sensitive data i systemområder, f eks autentiseringsdata og loggdata Tilgang til fellesområder Bare brukergruppen og administrator skal kunne lese data i et fellesområde Tilgang til hjemmeområder Bare bruker og administrator skal kunne lese data i et hjemmeområde. 4 Her må systemeier avveie fordelene med lengre sperring opp mot økt sårbarhet for angrep som kan fremprovosere systematisk og uønsket sperring av alle brukerkonti. En sperring på sekunder bør være tilstrekkelig for de fleste forhold. Den økte passordlengen gir økt beskyttelse mot automatiserte innloggingsforsøk og tilrettelegger for kortere sperring. Side 11 av 16

12 5.3.4 Kryptering av data a. Systemet skal ikke dele utstyr som behandler klartekstdata med andre systemer. b. Systemet skal ikke dele nøkkelmateriell med andre systemer. c. Data skal ikke (dobbel)krypteres slik at de blir utilgjengelig for administrator eller sanntids sikkerhetskontroller, f eks søk etter virus. d. Sensitive nettverkstrafikk ifm fjernadministrasjon skal (dobbel)krypteres hvis linjen deles med sluttbrukere. 5.4 Integritet Fysisk tilgang til datautstyret Brukere av felles arbeidsstasjoner skal ikke kunne kompromittere systemets integritet gjennom fysisk manipulasjon av datautstyret, f eks lokal harddisk Kontrollert oppstart a. Arbeidsstasjoner skal bare kunne laste godkjent system. Brukerne skal f eks ikke kunne starte maskinen fra en diskettstasjon eller fra en ikke-autorisert harddisk som kobles til maskinen. b. Mekanismen som styrer oppstart skal være passordbeskyttet (eller tilsvarende) Systemklokke a. Alle maskinene i nettverket skal ha automatisk synkroniserte systemklokker. b. Bare administrator skal kunne endre systemklokker Tilgang til systemområder Bare administrator skal kunne opprette modifisere (og slette) eie kontrollere tilgang til systemobjekter Tilgang til fellesområder a. Bare administrator skal kunne opprette fellesområder og tilhørende brukergrupper. b. Bare administrator skal kunne kontrollere tilgang til fellesområder. c. Bare brukergruppen og administrator skal kunne opprette data i fellesområdet. d. Bare utsteder skal kunne eie nye data i fellesområdet. e. Bare utsteder og administrator skal i utgangspunktet kunne kontrollere tilgang til nye data i fellesområdet. f. Bare utsteder og administrator skal i utgangspunktet kunne modifisere nye data i fellesområdet. g. Brukere skal bare kunne gi tilgang til sine data til andre medlemmer av brukergruppen (dvs en bruker skal ikke kunne gi brukere som ikke er med i brukergruppen tilgang til fellesområdet). Side 12 av 16

13 5.4.6 Tilgang til hjemmeområder a. Bare administrator skal kunne opprette hjemmeområder. b. Bare administrator skal kunne kontrollere tilgang til hjemmeområder. c. Bare bruker og administrator skal kunne opprette data i hjemmeområdet. d. Bare utsteder skal kunne eie nye data i hjemmeområdet. e. Bare utsteder og administrator skal kunne modifisere nye data i hjemmeområdet. f. Bruker skal ikke kunne gi andre brukere tilgang til data i hjemmeområdet Tilgang til skrivere a. Bare administrator skal kunne opprette skrivere og utskriftskøer samt kontrollere tilgang til disse. b. Brukere skal bare kunne modifisere egne jobber i utskriftskøen (evt også kunne slette andres jobber) Viruskontroll a. Data som importeres skal automatisk kontrolleres for virus. b. Sluttbrukere skal ikke gis tilgang til virusinfiserte data. c. Virussignaturer skal oppdateres regelmessig Integritetssikring av nettverkstrafikk Nettverkstrafikk skal integritetssikres på a. Nettverkslaget (f eks IP) b. Applikasjonslaget (f eks klient-server applikasjoner for fil, print, web og e-post) Integritetssikring av sikkerhetsfunksjonalitet a. Systemet skal ha verktøy som beregner kryptografiske sjekksummer for programkoden til viktige sikkerhetskomponenter iht en konfigurerbar profil. b. Systemet skal kunne detektere og rapportere avvik fra profilen både i sanntid og ifm inspeksjoner. c. Referansedata (dvs sjekksummene) og inspeksjonsverktøyet skal kunne lagres fysisk adskilt fra datasystemet og være skrivebeskyttet under kontrollen, f eks på en CDROM eller en skrivebeskyttet diskett Integritetssikring av sikkerhetskonfigurasjon a. Systemet skal ha verktøy som registrerer oppsettet til viktige sikkerhetskomponenter iht en konfigurerbar profil. b. Systemet skal kunne detektere og rapportere avvik fra profilen både i sanntid og ifm inspeksjoner. c. Referansedata (dvs den godkjente sikkerhetskonfigurasjonen) og inspeksjonsverktøyet skal kunne lagres fysisk atskilt fra datasystemet og være skrivebeskyttet under kontrollen, f eks på en CDROM eller på en skrivebeskyttet diskett Automatisering av rutineoppgaver Systemet skal ha verktøy som automatiserer tunge rutineoppgaver, inkludert: a. Brukeradministrasjon (oppretting/sletting av brukere og -grupper) b. Installasjon/konfigurasjon/fjerning av programvare på arbeidsstasjoner c. Oppdatering av virussignaturer på arbeidsstasjoner. d. Konfigurasjonskontroll av systemets program- og maskinvare e. Kontroll av integritet til sikkerhetsfunksjonalitet og -konfigurasjon Side 13 av 16

14 f. Sikkerhetskopiering av brukerdata g. Revisjon av loggdata Disse oppgavene inneholder komplekse og arbeidskrevende operasjoner som hvis utført mange ganger manuelt gir høy sannsynlighet for feil. Sletting av en brukerkonto involverer f eks følgende operasjoner: brukerens konto sperres for innlogging brukeren meldes ut av alle brukergrupper brukerens data sikkerhetskopieres brukerens data på hjemme- og fellesområder slettes eller overføres til andre brukere brukeren fjernes fra alle tilgangskontrollister brukeren fjernes fra brukerdatabasen Ved å basere arbeidet på automatiserte verktøy reduseres antall feil og den daglige driften effektiviseres. 5.5 Tilgjengelighet Organisering av filsystemer På servere skal operativsystem og lokale applikasjoner nettverksapplikasjoner (f eks en MTA) loggdata brukerdata plasseres på ulike partisjoner Størrelse på loggpartisjoner og loggfiler På servere skal loggpartisjoner være på minst 500MB og loggfiler kunne holde minst 50MB. På arbeidsstasjoner skal partisjonen som holder loggdata ha minst 300MB ledig kapasitet etter ferdig installasjon og loggfiler skal kunne holde minst 100MB Kvoter Systemet skal kunne begrense brukeres forbruk av kritiske systemressurser, f eks: a. Prosesser b. Internminne c. Lagringsplass (disk, meldingslager, etc) d. Båndbredde i nettverk Redundans a. Servere skal kunne miste en harddisk uten tap av data b. Intranett skal kunne miste en linje uten tap av dekning Vedlikehold Servere skal kunne bytte defekt maskinvare uten at systemet må stoppes, f eks: a. Harddisker Side 14 av 16

15 b. Minnebrikker c. Prosessorer d. Innstikkskort (f eks nettverkskort) Overvåking Systemet skal ha et verktøy for å analysere aktivitets-/ytelsesdata som kan: a. Sammenholde data på tvers av nettverk og kilder b. Produsere rapporter på grunnlag av dynamiske spørringer c. Generere sanntids alarmer på grunnlag av dynamiske spørringer 5.6 Ansvarlighet Innloggingsmelding Ved innlogging skal brukere informeres om: systemets navn krav til brukernes klarering og autorisasjon navn og telefonnummer til datasikkerhetsleder og administrator at systemet monitoreres Loggbare hendelser Følgende hendelser skal alltid logges: a. Start og stopp av systemet b. Inn og utlogging av brukere c. Endring av systemobjekter ifm normal drift (dvs ikke ifm installasjon og oppgradering) d. All mislykket tilgang e. Endringer i systemets sikkerhetspolitikk f. Endringer i brukerdatabasen g. Sikkerhetskopiering h. Import og eksport av data (f eks utskrift til skrivere eller kopiering av filer til/fra disketter merk at data, dvs innholdet, som importeres/eksporteres ikke alltid må logges) Import og eksport av data Systemet skal kunne logge data, dvs innholdet, som importeres og eksporteres Systemstopp ved avbrutt logging a. Systemet skal stoppe normal drift hvis logging stopper, f eks ved fulle loggfiler. b. Systemadministratoren skal varsles i rimelig tid før loggfiler blir fulle Revisjonsverktøy for loggdata Systemet skal ha et verktøy for å konsolidere/revidere loggdata som kan: a. Sammenholde utvalgte loggdata på tvers av nettverk og kilder i sanntid og ifm inspeksjoner b. Produsere rapporter på grunnlag av dynamiske spørringer c. Generere sanntids alarmer på grunnlag av dynamiske spørringer Side 15 av 16

16 5.6.6 Rapport om tidligere brukeraktiviteter Brukere skal regelmessig informeres om viktige sikkerhetsrelevante hendelser som har involvert deres brukerkonti, bl a skal det informeres om tidligere innlogginger mht sted (terminal), tidspunkt, status og evt varighet Sikkerhetskopiering og lagring av loggdata Etter revisjon skal følgende loggdata sikkerhetskopieres til off-line media og lagres i minimum fem år: a. Originale server loggdata, uavkortet og i originalformat b. Konsoliderte loggdata på sentrale loggservere Originale loggfiler på arbeidsstasjoner kan overskrives sirkulært og behøver ikke lagres. 5 6 Dokumenthistorie La på ny dokumentmal. 5 Det forutsettes her at utvalgte loggdata fra arbeidsstasjoner i sanntid konsolideres på sentrale loggservere. Tentativt vil dette være a, b, e, f og evt h. Side 16 av 16