Kapittel 14. Sikkerhet

Et informasjonssystem kan ha varierende viktighet avhengig av omgivelsene. Noen ganger kan det være livsviktig for bedriftens overlevelse, og må derfor beskyttes mot forskjellige former for risiko. Prosessen med å evaluere disse risikoene, definere og implementere beskyttelsesmekanismer, kalles med et fellesord «sikkerhetsprosessen».

14.1. Å definere et sikkerhetsopplegg

Ordet «sikkerhet» dekker et vidt spekter av konsepter, verktøy, og prosedyrer; ingen av dem dekker alle aspekter. Å velge mellom dem krever en presis idé om hvilke mål man vil oppnå. Å sikre et system starter med å svare på noen få spørsmål. Raser man avgårde, og implementerer et vilkårlig sett av tiltak, risikerer man å fokusere på feil ting.

Den absolutt første tingen å avgjøre er derfor målet. En god tilnærming til å hjelpe til med denne avgjørelsen er å starte med disse spørsmålene:

Hva prøver man å beskytte? Sikkerhetsopplegget vil være forskjellig avhengig av om man vil beskytte maskiner eller data. I sistnevnte tilfelle må vi også vite hvilke data.
Hva prøver vi å beskytte mot? Er det lekkasje av sensitive data? Tap av data? Tap av inntekt som følge av forstyrrelser i tjenesten?
Dessuten, hvem prøver vi å beskytte oss mot? Sikkerhetstiltakene vil variere stort mellom det å beskytte mot skrivefeil fra brukeren av systemet, og angrep fra motiverte grupper utenfra.

Ordet «risiko», i sikkerhetsøyemed, brukes gjerne som samlebegrep for disse tre faktorene: Hva som må beskyttes, hva som må hindres fra å skje, og hvem som det må beskyttes mot. Å modellere risikoen krever svar på disse tre spørsmålene. Utfra en slik risikomodell kan et sikkerhetsopplegg konstrueres, og dette kan implementeres gjennom konkrete tiltak.

MERK Løpende vurdering

Bruce Schneier, en verdenskjent sikkerhetsekspert (ikke bare på datasikkerhet), prøver å avlive en av de største mytene innen sikkerhet ved å si: «Sikkerhet er en prosess, ikke et produkt». Verdier som må beskyttes endrer seg over tid; det samme gjør truslene og tilgjengelige ressurser for mulige angripere. Selv om et sikkerhetsopplegg opprinnelig er perfekt konstruert og implementert, kan man ikke hvile på sine laurbær. Risikomomentene endrer seg, og da må tiltakene henge med.

Andre begrensninger er også verdt å tenke på, ettersom de kan sette grenser for tilgjengelige sikkerhetsopplegg. Hvor langt er man villig til å gå for å sikre systemet? Dette spørsmålet har store konsekvenser for hva som skal implementeres. Det besvares altfor ofte kun utfra økonomi, selv om andre kriterier også bør tas i betraktning, som ulemper som påføres brukeren, og tap av ytelse.

Først når risikoen er kartlagt, kan man begynne å tenke på å lage et konkret sikkerhetsopplegg.

MERK Ekstreme tiltak

Det er tilfeller hvor valget av tiltak som kreves for å sikre et system, er ekstremt enkle.

For eksempel, hvis systemet som skal sikres, bare består av en gammel brukt maskin som kun anvendes til å legge sammen noen tall på slutten av dagen, ville det antakelig være helt legitimt å ikke gjøre noen ting. Verdien som ligger i systemet er lav, og det er ingen verdi i dataene, ettersom de ikke lagres på maskinen. En potensiell angriper ville bare få tilgang til en uhåndterlig kalkulator. Kostnaden ved å sikre et slikt system ville sannsynligvis overstige kostnaden ved et eventuelt tap/brudd.

I motsatt ende av spekteret, hvis konfidensialitet av hemmelige data trumfer alle andre hensyn, vil en riktig respons kunne være å destruere dataene så grundig som mulig (overskriving, sletting av dataene mange ganger, for så å løse harddisken opp i syrebad, osv). Hvis det i tillegg kreves at dataene skal oppbevares for framtidig bruk (ikke nødvendigvis på kort varsel), og kostnad fortsatt ikke er en faktor, vil et hensiktsmessig startpunkt være å lagre dataene på plater av en iridium-platinum-legering i bombesikre bunkere under forskjellige fjell omkring i verden, alle selvsagt både hemmelige og bevoktede med hver sin hær …

Selv så ekstreme disse eksemplene fremstår samsvarer de likevel som respons for sine definerte risikoer, i den grad de er produktet av en tankeprosess som har tatt hensyn til målene man ønsker å oppnå, og begrensningene som må oppfylles. Gitt opphav i en velinformert rasjonell beslutning, er intet sikkerhetsopplegg mindre respektabelt enn et annet.

I de fleste tilfeller kan informasjonssystemet segmenteres i konsistente og stort sett uavhengige subsett. Hvert subsystem vil ha sine egne krav og begrensninger, så risikovurderingen og utformingen av sikkerhetsopplegget bør gjøres separat for hvert subsystem. Et godt prinsipp å huske på er at en kort og veldefinert forsvarslinje er enklere å forsvare enn en lang og buktende en. Nettverksorganisasjonen bør også utformes tilsvarende; sensitive tjenester bør konsentreres på et lite antall maskiner, og disse maskinene bør bare være tilgjengelige via et minimalt antall innfallsporter; beskytting av disse innfallsportene vil være enklere enn å beskytte alle de sensitive maskinene mot den store utenomverdenen. Det er her nettverksfiltrering (inkludert brannmurer) kommer inn. Denne filtreringen kan implementeres med dedikert maskinvare, men en mulig enklere og mer fleksibel løsning er å bruke en programvarebrannmur, som den som er integrert i Linux-kjernen.