Datasikkerhet

``Once more unto the bridge, dear friends''

Tenk deg en øy som er tilknyttet omverdenen ved et antall broer. Bak broene ligger alt som vi bryr oss om, hele formuen vår, alle investeringer. På den andre siden av broen ligger alle de som har noe å tjene på å stjele fra oss, skade oss eller få oss til å miste ansikt. Kanskje ønsker vi å reise et sted, med en del av godene. Å ferde ut i verden kan være farlig. Vi kan bli angrepet, ranet, til og med drept.

De fleste sikkerhets scenarioer kan oppfattes slik. Uansett om det gjelder en miltaær aksjon mot en ekte øy, eller om øya er en datamaskin og broene er nettverk koblinger---prinsippene er de samme. Reisen kunne vært å sende informasjon via nettet. Sikkerhets prinsipper av noen lunde de sammen, unansett om de gjelder datasystemer eller ei. For å opprettholde trygghet, sikkerhet, og ikke minst vår formue, er vi nødt til å ofre bekvemmeligheten vi har med ubgrenset reise til og fra øya, fordi dette også tillater ubegrenset reise for potensielle fiender. Hvis vi kommer inn i en konflikt, risikerer vi tap eller skade. Et av målene våre er å minimere risikoen for slikt tap. Obs: sikkerhet dreier seg ikke nødvendigvis om hemmeligheter, eller noe vi ikke vil dele med andre: en del av formuen vår kan også være basert på friheten til å selge informasjon til kunder, eller utføre tjenster for dem. Dersom noen forhindrer oss i å gjøre dette, må det betraktes som tyveri av formuen eller virksomhet. Friheten til å handle er også en verdisak.

Sikkerhet dreier seg om velvære (integritet) og det å beskytte eindom mot innbrudd, tyveri eller avlytting (som angriper friheten til å holde noe hemmelig). For å oppnå dette i et fiendtlig miljø, må vi begrense tilgang til eindommen vår, dvs vi tillater adgang til noen få som vi kan stole på: vi slipper gjennom kun de som har gylig legitimasjon (autentisering).

Sikkerhet er altså basert på følgende emner:

• Privacy/Fortrolighet - mulighten til å holde ting hemmelig.
• Trust/Tillit - stoler vi på data fra et individ eller en maskin? Kunne dataene brukes imot oss?
• Autentisitet - ser vi en gyldig legitimasjon? Snakker vi med den vi tror vi snakker med, privat eller ei?
• Integritet - er systemet kompromittert/sabotert allerede?

Miljøer kan være fiendtlige på grunn av:

• Fysisk trussel - vær, naturkatastrofer, bomber, stømstans, osv.
• Menneskelig trussel - tyveri, bedrageri, bestikkelse, spionasje, sabotasje, ulykker.
• Software trussel - virus, Trojanske hester, logikkbomber, denial of service.

Hva er vi redde for?

• Miste muligheten til å bruke systemet
• Miste viktige data eller filer
• Miste ansikt/rykte
• Miste penger
• Spre private opplysninger om mennesker

I systemadminsitrasjonskurset vurderte vi disse ut fra system admins perspektivet, og vi diskuterte mulig forsvar. Der påsto vi det fundamentale kravet slik at sikkert kan eskistere:

For å kunne sikre et system må vi har muligheten til å begrense tilgang eller privilegier til systemet.

Dersom vi skal forstå sikkerhet også fra andre perspektiver, blir vi nødt til åpne opp en del sorte bokser, som vi bare har nevnt i farten tidiligere i system administrasjon, og kikke inn. Vi skal foreta en reise som berører emner fra nesten hvert eneste fag vi har vært gjennom siden skolestarten i første klassen!

I løpet av dette kurset kommer vi til å dekke mange sider av sikkerhet i forbindelse datasystemer. I systemadministrasjon kurset vurderte vi bare praktiske sider ved emnet på et overfladisk nivå. Her kommer vi til å se mer på teorien. Dette introduserer flere nye emner som vi ikke tok for oss tidligere. For eksempel: mange datasystemer brukes i såkallte mission-critical (kritisk oppgave) systemer, slik som flykontrollsystemer og tunge maskiner der menneskeliv står på spill. Påligtelighet og trygghet er derfor også viktige betraktninger. (Dette er også en slags integritet, nemlig av funskjon.) Real-time systems er navnet som gis til datasystemer som garanterer å svare på brukerkrav umiddelbart. Slike systemer må alltid være raske nok til å kunne håndtere et hvilket som helst krav som måtte stilles til dem. Real-time systemer brukes hvor menneskeliv eller store summer penger står på spill. F.eks., det ville være uakseptabelt for piloten i et passasjerfly å gi kommandoen: "Hjelp, vi skal kræsje, flaps nå!" og få svar fra datasystemet: "Processing, please wait...".

Vi må altså bruke fantasien litt når vi tenker på sikkerhet, og stille spørsmålet: hva er egentig viktig for oss? Hva prøver vi å beskytte?

Et sist punkt: når vi begrenser tilgangen i et miljø hvor det fins en tynn strek mellom tillit og mistillit, er det viktig å holde regnskap over hvem som gjør hva (accountability). Vi kan bokføre alt som foregår på systemet ved å bruke logger. Dette er vitkig i mange organisasjoner, fordi det betyr at de har forsikret seg muligheten til å beskylde noen for deres tap.

Sikkerhetens dilemma

Problemet som vi ikke kommer utenom i datasikkerhet er dette: vi kan ikke ha skikkelig sikkerhet med mindre alle brukerne forstår hva sikkerhet er, og sier seg villig til å samarbeide i å opprettholder sikerhetsrutinen.

Sikkerhet er et sosialt problem, fordi sikkerhet gir ikke mening før et mennesker definerer hva det betyr for seg.

Dersom vi gjør ting for vanskelig for brukere, ved å innføre for mange begrensninger, har de en tendens til å jobber rundt disse begrensningene. Folk er i bunn og grunn late.

De fleste brukere har lite peiling på hva sikkerhet betyr. Dette er vårt største sikkerhetshull.

Betydningen av sikkerhet ligger i tillit

Noe som jeg kommer til å gjenta mange ganger i dette kurset er følgende:

Alle sikkerhetsproblemer kan kokes ned til spørmsål om tillit. Hvem eller hva stoler vi på?

Vi introduserer sikkerhetsbegrepet som beskyttelse mot partier som vi ikke stoler på. Men hvordan løser vi problemet? Vanligvis introduserer vi en form for teknologi som flytter tillit fra noe risikabelt til noe tryggere. For eskempel, dersom du stoler på at naboene dine ikke vil stjele dine eindeler, går det an å sette en lås på døra. Nå trenger du ikke å stole naboene lenger, men du må stole på at låsen gjør jobben som den skal. Hvis du ikke helt stoler på låsen, kunne du investere i et alarmsystem som ringer politiet dersom det blir innbrudd. Nå stoler du litt på låsen, litt på alarm systemet, og ganske mye på politiet. Hvem sier jo at politiet ikke kommer til å stjele eiendelene? I noen deler av verden, er ikke dette en absurd ide.

Hver dag stoler vi på banker, minibankterminaler, eksamenssensorer, politiet, myndigheter, restauranter (kommer de til å forgifte meg idag?) og hundrevis av andre ting. Vi stiller aldri spørsmål til denne tilliten, for den blir sjeldent misbrukt. Men det er ikke alltid tilfellet...

Når du lærer å kjøre en maskin så farlig som en bil, setter du andres liv i fare. De fleste regjerninger krever at du må bestå en prøve for å vise at du kan bruke utstyret på et trygt vis. Datasystemer kan også gjøre stor skade -- kanskje ikke ofte til individer, men heller til samfunn og næring.Vi er så avhengige av datamaskiner at det fort blir kaos når noe går galt. Allikevel, har vi ikke noen førekort for datasystemer, og heller ikke noen EU-kontroll på operativsystemer, som viser at de er trygge i bruk. Vår tillit til datasystemer er ofte malplassert. Og det er her at problemene oppstår.

Minimale behov: Orange Book

Den eneste risikoskilden datamaskiner kommer i kontakt med er brukere på konsoll og på nett. Med tanke på å minimere virkningen av brukere, innfører vi sikkerhetsmekanismer. The Trusted Computer Security Evaluation Criteria (TSEC) Orange book var det første forsøket på å spesifisere en sikkerhetsstandard in USA i 1967. Selv om den fokuserte mest på nasjonalsikkerhet, kom den med anbefalinger som gjalt mer generelt. Når Windows NT ble sluppet, spillte Microsoft på det at NT hadde en Orange Book C2 sikkerhetsklassifisering (det gjaldt egentlig bare en maskin som var frakoblet nettet, uten diskette stasjon). Unix systemer har alltid vært C2 nesten sikre (Se Gollmann kapittel 9). C2 sikkerhet betyr at man har muligheten til å sette rettigheter på filer, såkallte Discretionary Access Controls (DAC). Dette krever at brukere skal ha brukernavn og er nødt til å bruke passord for å logge seg på. C2 systemer må også kunne logge aktivitene på systemet, slik at det føres et regnskap over hvem som gjorde hva. De er få systemer som gidder å innføre logging på denne måten, slik at C2 er ikke så interessant i praksis. Men login navn er tilgangskontroll er klart en viktige start.

Implementasjon av sikkerhet: skalaer

Når vi skal forstå en veldig komplisert sak, må vi gjøre det hvert nivå for seg eller hver skala for seg. Det er merkverdig hvor ofte dette enkle prinsippet glemmes og så gjenoppdages. Dersom vi ser på et datasystem, for eksempel, ser vi mange nivåer som kan skilles fra hverandre:

• Grensesnittet mellom program og bruker
• Funksjonaliteten programmet tilbyr
• Algoritmene som implementerer funksjonaliteten
• Kommunikasjon med andre systemer
• Undersystemer (systemkall) som programmet er avhengig av
• Hardwaren som softwaren kjører på
• Implisitte tillitsforhold mellom programmet og andre programmer/systemer

Ved toppen av listen har vi høynivå saker som vi oftest kan styre selv. Nærmere bunnen kommer vi bort i lavnivå ting som er vanligvis utenfor vår kontroll. Sikkerhet kan være sterk eller svak på hvert av disse nivåene, med ulike konsekvenser i hvert tilfelle.

For eksempel, innbill deg et program som har flere knapper og menyer. Anta at programmet styrer et viktig datasystem som håndterer hundrevis av transaksjoner per sekund på børsen. Hvis dette programmet stopper, betyr det at penger kommer til å gå tapt. Av og til er det nødvendig å kjøpe eller selge på børsen. La oss innbille oss av knappene er plassert slik:

  |--------------------------------------------------|
  |  Newsflash Buy  Sell  Quit                       |
  |--------------------------------------------------|
  |                                                  |
  |                                                  |
  |                 DISPLAY                          |
  |                                                  |
  |                                                  |
  |                                                  |
  |--------------------------------------------------|

Dette er et usikkert brukergrensesnitt, fordi ved en håndfeil eller musglipp er det mulig å velge Quit i stedenfor Sell. Det er mye å tape på å gjøre en slik feil. Newsflash funksjonen kringkaster nyhetsbulletin om kjøp og salg samt dagens passord til alle i selksapet som står på en liste. Denne informasjonen er ikke kryptert, slik at det kan fanges opp ved å avlytte nettet (sniffing). Denne funksjonen i programet er usikkert ved design. Algoritmene programmet bruker for å regne ut prognoser bruker midlertidige filer som skrives i et offentlig directory. En annen bruker kunne lure programmet til å regne feil, ved å modifisere de midlertidige filene mens programmet holder på. Dette er en sikkerhetsfeil i kodingen.

Vi kunne fortsette på denne måten ved å ramse opp en litani med dårlige løsninger i programmet. Det holder å si at på hvert nivå finnes det potensielt skadelige feil i programmets design. Vi begynner å ane et mønster i disse feilene som vi kan forsikre oss mot...

Betrakninger ved design

Det fins mange designbetrakninger som kan føre til sikrere systemer. Vi kommer tilbake til disse i løpet av kurset. For eksempel:

• Spesielle protokoller
• Begrense funksjonalitet
• Standarder for brukergrensesnitt

Så er det en rekke spørsmål vi må stille:

1. Bør beskyttelsesmekanismer fokusere på data, funskjonalitet, eller brukere?
2. På hvilket nivå/lag bør sikkerhetsmekanismer plasseres?
3. Foretrekker vi et enkelt (lett å sikre) system eller et som er rikt med fuksjoner (vanskelig å sikre)?
4. Bør sikkerhet håndteres av en sentral enhet, eller bør det overlates til de individuelle komponentene i systemet?
5. Hvordan hindrer vi en som angriper i å få tilgang til et nivå under sikkerhetsmekanismene, slik at han/hun kan komme rundt eller disable dem.

Her er en kort oppsummering av prinsippene, som omfatter datasikkerhet, fra kurset Nettverk og Systemadministration. Du bør tenke mer på disse i lyset av denne forelesningen:

• Samfunnsprinsippet: Det som ett medlem av et samfunn gjør kan påvirke alle andre, og omvendt. Hvert medlem har derfor et ansvar for andres velferd i samfunnet.
• Policy: en klar beskrivelse av mål og reaksjoner forebygger fremtidige problemer, og dokumenterer hensikt og prosedyre.
• Enklest er best: enkle regler gjør et system lett å forstå. Brukere tolererer regler hvis de forstår dem.
• Sikkerhet: muligheten til å begrense tilgang til data og privilegier er fundamental for sikkerhet.
• Data "trygghet" (redundans): Hensikten med backup kopi er å få et ekstra eksemplar av noe, som sannsynligvis ikke vil ødelegges av samme årsak som originalen.

I løpet av de neste ukene kommer vi til å se nærmere på disse sakene og betrakte dem i detalj. Vi skal også prøve å måle den politiske temperaturen i sikkerhetsdiskusjonen, og følger noen av utviklingene som dominerer datanyhetene for tiden.