HiØ 6.01 2003 Datasikkerhet vår 2003 Forelesning 1 Forelesning 1.

Presentasjon om: "HiØ 6.01 2003 Datasikkerhet vår 2003 Forelesning 1 Forelesning 1."— Utskrift av presentasjonen:

1 HiØ Datasikkerhet vår 2003 Forelesning 1 Forelesning 1

2 Generell introduksjon
Om foreleser: Cand Real Ole-Arnt Johnsen, fra UiO Ansatt hos moreCom Om kurset 14 forelesninger á 3 timer, 10 gruppeundervisninger á 2 timer Obligatoriske oppgaver En del notater vil stilles til rådighet, kryptert. Forutsetter innsending av nøkler. Hjelpelærere: Victor Usjanov Pensum Network Security Essentials, William Stallings, ISBN Hele boka inntil annet blir bestemt. . Forelesningsnotater HiØ Forelesning 1

3 Generell intro forts. Informasjonsutveksling Krav til studentene
epost www ref hjemmeside (hiof - kurs - datasikkerhet - faglærers side) news ref hjemmeside Krav til studentene Hold mobiltelefoner avslått Still spørsmål - gode spørsmål og dumme spørsmål 3 vekttall er mer enn en full arbeidsdag per uke. Målsetning Bygge opp et begrepsapparat - uten ord kan man ikke tenke. Generell introduksjon - med harelabb .... HiØ Forelesning 1

4 Oversikt over forelesningene
1, 2. Introduksjon til datasikkerhet Kapittel 1 (15 sider). Forelesningsnotater fra ISO Security Frameworks. 3, 4. Kryptografi Kap. 2, 3 (60 sider). 5-9. Network Security Kap. 4-8 (190 sider) 10. Maskinvare og operativsystemer Forelesningsnotater 11, 12. System Security Kap. 9, 10 (60 sider) 13 Risikoanalyser 14 Oppsummering HiØ Forelesning 1

5 Angrepet fra Gøsta Gøstas Internett maskin Telia Ruter Tjener Tjener
HiØ Angrepet fra Gøsta Internett Gøstas maskin Telia Uninett Ruter Tjener Buddy Tjener Gandalf HiØ Forelesning 1 Forelesning 1

6 Angrepet Gøsta logger seg på Buddy med ftp
id= guest pwd= anonymous Gøsta kopierer en ”sniffer” til Buddy Gøsta eksekverer Sniffer på Buddy Sniffer leser all trafikk på nettet, plukker ut brukerid og passord (som går i klartekst) fra datastrømmen, skriver id og passord til fil. Gøsta henter loggefil - inneholder en dag rotid og rotpassord til Gandalf. Gøsta logger seg på Gandalf som rotbruker kopierer ny ls (ls’), ps (ps’) og login (login’) - tre Trojanske hester. ls viser filtreet, ls’ viser filtreet minus Gøsta sine filer ps viser aktive prosesser, ps’ viser aktive prosesser minus Gøsta sine prosesser login krever bukerid og passord ved pålogging til Gandalf, login’ logger disse til skjult loggefil Gøsta logger seg på som rot og legger inn bakdører som gir ham rottilgang selv om rotpassord skiftes Gøsta kopierer loggefiler jevnlig Disker på Gandalf går fulle fordi loggefiler blir store - men ls tyder på at det skal være plass? Loggefil finnes - inneholder også informasjon om Gøsta ”Noen” besøker/henter Gøsta HiØ Forelesning 1

7 Hva skjedde? Gøsta avslørte passord (Konfidensialitetsbrudd)
Gøsta manipulerte programmer (Integritetsbrudd) Gøsta hindret lovlig bruk av Gandalf (Tapt tilgjengelighet) Tre sikkerhetsmessige egenskaper Konfidensialitet - Evne til å holde hemmeligheter hemmelig, informasjon skal kun være tilgjengelig for autoriserte. Integritet - Evne til å bevare informasjon og funksjoner korrekte, at de gjør det man forventer at de skal gjøre, at de beskriver ”virkeligheten”. Tilgjengelighet - Evne til å sørge for at autoriserte får tilgang til informasjon og funksjoner når de trenger det. HiØ Forelesning 1

8 Trusler Trusler – fra en forretningsmessig synsvinkel
Miste anseelse; Miste inntekter ; Være forhindret fra å gjøre jobb. Fra en samfunnsmessig synsvinkel Miste grunnleggende tjenester – kraft og telekommunikasjon, militære angrep, terrorisme osv. Fra en personlig synsvinkel Tap av privatlivets fred, tape penger/bli svindlet HiØ Forelesning 1

9 Definisjoner Trussel Angrep
En mulighet for brudd på sikkerhet. Potensiell hendelse, ondsinnet eller uhell, som kan ha en uønsket effekt på verdier og ressurser knyttet til et IT eller kommunikasjonssystem-system Noe som kan skje, og som man bør være oppmerksom på. Angrep En manifestert trussel – en trussel som har blitt til virkelighet. Her, en bevisst handling som skal medføre tap av konfidensialitet, integritet eller tilgjengelighet. HiØ Forelesning 1

10 Angrep Passive angrep Avsløring av meldingsinnhold gjennom avlytting.
Trafikkanalyse f.eks. Avsender og mottakeradresse. Passive angrep vanskelig å oppdage fordi ikke noe blir borte eller endres. Vanskelig å reetablere. Mottiltak - hindre avsløring, ofte gjennom bruk av kryptografi. HiØ Forelesning 1

11 Angrep Aktive angrep Modifikasjon av data (eller funksjoner) eller fabrikasjon av falske data Maskerade, Avspilling (replay), Modifikasjon, Tjenestehindring (Denial of Service - DOS) Vanskelig/umulig å hindre alle aktive angrep, men de kan oppdages og det er meningsfylt å reetablere etter dem. HiØ Forelesning 1

12 OSI sikkerhetsarkitektur
ITU-T Recommendation X.800. Fokus på Klassifisering av angrepsformer Tjenester som skal kunne motvirke angrep Mekanismer som skal kunne oppdage, hindre eller reetablere etter angrep. En eller flere mekansimer implementerer en tjeneste. HiØ Forelesning 1

13 Stammespråk – del 1 Egenskaper Trusler Konfidensialitet Avsløring
Evne til å holde hemmeligheter skjult for uvedkommende. Avsløring Integritet Evne til å bevare informasjon og funksjoner korrekte. Manipulasjon Tilgjengelighet Evne til å gi autoriserte tilgang til funksjoner og informasjon – når de trenger det. Tjenestesvikt DOS – Denial of Service HiØ Forelesning 1

14 Stammespråk – del 2 Ressurser Egenskaper Trusler Risiko- kontroll Data
Konfi- densialitet Avsløring Unngå Forebygge Programvare Integritet Manipula- sjon Redusere Maskinvare Til- gjengelighet Tjenestesv., Denial of S. Overføre HiØ Forelesning 1

15 Stammespråk – del 3 ......... Risiko- kontroll Tiltak Sikkerhets
tjenester Sikkerhets mekanismer Autentisering Kryptografi Unngå Aksesskontroll Hindre Passord Forebygge Konfidens.tj. Logging Oppdage Integritetstj. Redusere Vedkjenning Reetablere Overføre Revisjon HiØ Forelesning 1

16 Trusler, eksempler Mot maskinvare Mot programvare Data
Avbrudd, ødeleggelse, tyveri, overbelastning Mot programvare Sletting, Endring (logiske bomber, trojanske hester, virus), forhindring, bruk på en uventet/uhensiktsmessig måte Data Tap, avsløring, endring, fabrikering (data kan ha verdi innenfor en avgrenset periode, og trenger beskyttelse i den samme perioden) HiØ Forelesning 1

17 Risikokontroll Unngå Forebygge Redusere Overføre
Ikke utsette seg for fare Forebygge Iverksette tiltak som gjør det vanskelig/mindre sannsynlig at angrep skal lykkes herunder også øke sannsynligheten for/evnen til å oppdage (reduserer lysten til å angripe) Redusere Minske konsekvenser av angrep - oppdage raskt hva som har skjedd, reetablere, bedredskap, prosedyrer, sikkerhetskopier Overføre La andre overta risiko (mot betaling) gjennom forsikring, avtaler,.. HiØ Forelesning 1

18 Kursets hovedtemaer Identifisere trusler, deres årsaker og konsekvenser Tiltak som forebygger/reduserer sannsynligheten Tiltak som reduserer konsekvensene Tilsammen - Risikostyring HiØ Forelesning 1

19 Risikostyring Å balansere kostnadene i forkant av en mulig uønsket hendelse mot kostnadene i etterkant når hendelsen er et faktum (kostnader i vid forstand) Sannsynlighet Uakseptabel risiko Akseptabel risiko Konsekvens HiØ Forelesning 1

20 Risikoanalyse Vil komme en forelesning mot slutten av kurset
Hvilke ressurser har vi (datamaskiner, kommunikasjonssystemer, programvare, data) Hva er konsekvensene av at data avsløres, blir utilgjengelig eller manipulert funksjoner stanser, utfører feil, Hva kan årsakene være - hva er truslene Hvem: Velmenende personer i organisasjonen, upålitelige personer i organisasjonen, personer utenfor (hackere, crackere, etterretning, konkurrenter, ...) Hvor: På maskin, i lokalnett, på WAN, i rutere hos operatører, .... Når: mens data prosesseres, under overføring, under lagring, ... Hvorfor: Etterretning, industrispionasje, sabotasje, hendelig uhell, for moro skyld, prestisje, økonomisk vinning, ... Hva: Brann, eksplosjon, lynnedslag, kraft-svikt/spiker, ekstreme værforhold, ... Hva er sannsynligheten for vellykket angrep/ hva er motstands-dyktigheten mot angrep - Lav motstandsdyktighet, høy sannsynlighet for at angrep kommer og lykkes HiØ Forelesning 1

21 Valg av mottiltak Mottiltak må settes inn der de er mest effektive/økonomiske, slik at man får et jevnt sikkerhetsnivå. Mottiltak kan være Fysiske Organisatoriske Systemtekniske (som er vårt tema) HiØ Forelesning 1

22 Kompetanse Tidsbehov Utstyr Hjelp av andre
HiØ Mottiltakene eller barrierene - hvor motstandsdyktige er de? Hvor mye skal til for å kunne gjennomføre angrepet? Metode fra ITSEM - IT Security Evaluation Manual. Kompetanse Mannen i gata, bruker, ekspert Tidsbehov minutter, dager, måneder Utstyr uten utstyr, hyllevare, spesialkonstruert Hjelp av andre ingen hjelp, hjelp av innsider, hjelp av systemadministrator/sikkerhetsadm. HiØ Forelesning 1 Forelesning 1

23 Sikkerhetstjenester Autentisering (bekrefte påstått identitet)
Aksesskontroll (regulere tilgang til ressurser) Konfidensialitetstjeneste (holde informasjon skjult) Integritetstjeneste (bevare ekthet av data, korrekthet i funksjon) Vedkjenning (bevise sending og/eller mottak) Revisjon (analysere data om bruk av funksjoner og data) HiØ Forelesning 1

24 Autentisering Skal skaffe bekreftelse for en påstått identitet
HiØ Autentisering Skal skaffe bekreftelse for en påstått identitet brukeridentitet utstyrsidentitet applikasjonsidentitet Skal primært hindre: Maskerade - at en entitet gir seg ut for å være en annen entitet. Skal skaffe bevis ved senere uenighet Autentisering “har ingen varighet” Autentisering er å få bekreftet en påstått identitet. De eller det som trenger en slik bekreftelse kan være personer (brukere) utstyr applikasjoner Autentiseringstjenesten i et system benyttes for å bekrefte en identitet. En slik bekreftelse må forefinnes før det kan avgjøres om tilgang til en ressurs er lovlig. å skaffe bevis som kan benyttes ved en eventuell senere uenighet. Hver og en av oss disponerer over et antall bevis på hvem vi er og hva vi er. Vi har skolebevis, bankkort, sertifikat, pass, fødselsattest, vigselsattest og sikkert flere til. Ikke alle "bevis" har vi like stor tillit til. Vi stoler mer på et bevis med påmontert bilde, og vi stoler mer på bevis der informasjonen inklusive bildet er støpt inn enn på bevis der bildet er stiftet på med stiftemaskin. Aller mest stoler vi på bevis av typen fingeravtrykk. Fingeravtrykk er en entydig identifisering av en person. Prinsippet er velkjent og benyttet i lang tid av domstolene. Alt dette er brukerautentisering. NB! Autentisering er noe som skjer i øyeblikket. Effekten av en autentisering har ingen utstrekning i tid. En person kan logge seg inn på et system, autentiseres og deretter fjerne seg fra arbeidsplassen og en annen kan benytte anledningen. Fra systemets side har man ingen garanti for at brukeren er den autentiserte brukeren mer enn akkurat i autentiserings-øyeblikket. HiØ Forelesning 1 Forelesning 1

25 Autentiseringsprosessen
HiØ Autentiseringsprosessen Verifikator Pretendent Autentiserings- informasjon Pass Autentiseringsprosessen omfatter noe eller noen (en bruker) som trenger å få sin identitet bekreftet (pretendenten), informasjon som benyttes i bevisføringen (autentiseringsinformasjonenen) og den eller det som verifiserer at identiteten er ekte (verifikatoren). En pretendent er en som gir seg ut for å være noe. I dette tilfelle kan noe f.eks. være en datamaskin, en applikasjon eller en kommunikasjons-partner i et OSI kommunikasjonslag (peer entity). Ved brukerautentisering er det personen/brukeren som må få bekreftet overfor systemet at han eller hun er den han/hun gir seg ut for å være. Autentiseringsinformasjonen er det som benyttes i forbindelse med bevisføringen. Autentiseringsinformasjon kan anta tre former: informasjon som oppbevares og benyttes av pretendenten (den eller det som skal autentiseres). informasjon som overføres mellom den/det som skal ha sin identitet bekreftet og den/det som skal avgjøre om identiteten kan bekreftes eller ikke informasjon som oppbevares og benyttes av verifikator (den som skal utføre verifikasjonen). Dersom passord benyttes vil ofte informasjonen være den samme i a), b) og c). Dersom man benytter en asymmetrisk krypteringsalgoritme, kan a) være en privat nøkkel, b) en melding kryptert med de den private nøkkelen (signatur) og c) den offentlige nøkkelen som må benyttes for å dekryptere meldingen i b) (vi kommer straks tilbake til mekanismene). Verifikator. Noe eller noen som skal verifisere at identiteten er ekte. Verifikator er i denne sammenheng alltid EDB basert. HiØ Forelesning 1 Forelesning 1

26 Trusler mot autentisitet
HiØ Trusler mot autentisitet Maskerade Avspilling Bakdør Avlytting Dårlig eller manglende autentisering Inntrengere, maskerade, avspilling, bakdør, Trojanske hester, virus, logiske bomber, bakterier, ormer, dårlig systemkonfigurasjon, dårlig eller manglende passordbruk, operatør eller bruker feil, program-meringsfeil, logiske feil i spesifikasjoner, manglende sikkerhets-opplæring og manglende revisjon er alle direkte eller indirekte trusler mot autentisitet. Vi skal se på enkelte av disse trusler. Maskerade. En bruker kan gi seg ut for å være en annen bruker ved pålogging. Eventuelt kan en annen bruker ta over etter den autentisert bruker etter at denne har forlatt terminalen. Et utstyr kan gi seg ut for å være et annet utstyr. Dette benytter man seg av f.eks. ved testing av kommunikasjonsprotokoller. I forbrytersk hensikt kan utstyr kobles til en kommunikasjonslinje og gi seg ut for å være et kjent ustyr. Man kan f.eks. gi seg ut for å være en sentral som produserer store mengder feilrapporter som forhindrer det lovlige utstyr å gjøre viktigere arbeid. En applikasjon kan gi seg ut for å være en annen applikasjon. Avspilling. Utveksling av passord mellom bruker og innloggings-prosedyre kan avspilles slik at inntrengeren kan maskere seg som en lovlig bruker. Meldinger som utveksles mellom en bruker og en applikasjon kan avspilles. Applikasjonen, og operativsystemet vil tro at meldingene kommer fra den autentiserte brukeren. Bakdør. Applikasjoner, eller sågar operativsystem og kommunikasjons-systemer, kan inneholde skjulte mekanismer som slipper inn dem som kjenner til denne mekanisme. Systemutviklere kan legge inn dette som en del av et testsystem - senere kan det benyttes i ondsinnet hensikt. Avlytting. Avlytting kan gjennomføres på kommunikasjonslinjer, på grensesnittet mellom bruker og login-systemet, i interne meldingsutvekslingssystem. I tillegg kommer spionkamera, kikke over skulderen osv. Dårlig eller manglende autentisering. Enkle passord eller mangelfull oppbevaring av dem er den alvorligste trusselen mot autentiserings-tjenesten. Det benyttes passord som er for korte (2-4 bokstaver) eller for enkle å gjette (navn på ektefelle eller barn). Enkelte skriver opp passordet eller passordene på lapper som festes til terminalen. HiØ Forelesning 1 Forelesning 1

27 Brukerautentisering 5 prinsipper
HiØ Brukerautentisering 5 prinsipper Noe kjent (passord) Noe eiet (magnetkort) En uforfalskelig egenskap (Biometri - fingeravtrykk) Tillit til 3dje instans (jeg kjenner og går god for..) Kontekst (tid og sted) Ved autentisering av brukere er det brukeren selv som er pretendenten - den som gir seg ut for å være (forhåpentligvis) seg selv. Brukere kan forsøke å bevise sin identitet på forskjellig vis. I dag kan autentisering av brukere bygge på autentiseringsprinsipper fra en eller flere av de følgende kategorier: Noe kjent, f.eks. passord. Noe eiet, f.eks. magnetkort. En uforfalskelig egenskap f.eks. fingeravtrykk. Betrodd tredjepart. Man aksepterer at en betrodd tredjepart allerede har utført en tilfredsstillende autentisering. Kontekst, f.eks adresse eller klokkeslett. Sammenlikne mekanismer: Fordeler og ulemper. Kriterier: Kostnader, D&V, enkelhet i bruk, styrke. Noe kjent. Det mest benyttede autentiseringsprinsipp ved brukerautentisering er basert på "noe kjent", nemlig passord. Dette prinsipp er enkelt og billig å implementere. Passord er imidlertid beheftet med flere kjente svakheter: De kan være enkle å gjette hvis ikke form og utskiftingshyppighet blir pålagt brukerene fra systemet. De kan avsløres på grunn av utilfredsstillende oppbevaring. De kan avlyttes på en kommunikasjonslinje dersom de ikke skjules under overføring. De to første svakhetene peker tilbake på brukerne og deres håndtering av passord. Enkelte brukere kan være nødt til å håndtere passord. Med krav til passordets lengde og utskiftingshyppighet kan det være vanskelig å finne frem til en sikkerhets-messig forsvarlig måte å behandle passord. HiØ Forelesning 1 Forelesning 1

28 Autentiseringsprinsipper Noe eiet:
HiØ Autentiseringsprinsipper Noe eiet: Krever spesielt leseutstyr Magnetkort Smartcard USB-dings i-button osv. Krever ikke spesielt leseutstyr Passordgenerator Det er gjenstanden og ikke eieren som autentiseres Dette prinsippet er særlig utbredt som adgangskontroll systemer i bygninger. ØDH innførte et slikt system i For brukerautentisering i EDB systemer er det ikke like utbredt. Vi vil skille mellom enheter som forutsetter spesielt leseutstyr og enheter som ikke krever dette: Kort med magnetstripe er den mest populære varianten foreløpig. Det finnes annen teknologi (Wiegand, Barium Ferrite, Proximity, infrarød, strekkode, enheter som kan leses via USB-porten, i-button) som har liknende funksjonalitet. Husk også brikken som benyttes i bomringen. Idéen er å legge informasjon i et kort/en ”dings” som gir en unik identifikasjon av kortet/dingsen. De forskjellige varianter er lettere eller vanskeligere å forfalske, mer eller mindre kostbare og enklere eller vanskeligere i bruk. De trenger alle en eller annen form for leser ved hver aktuell arbeidsplass eller sted der det er aktuelt å bli autentisert (f.eks. bankautomat). Passordgenerator som på forespørsel lager et passord. Passordet er forskjellig hver gang. Passordgeneratoren selv ser ut som en liten kalkulator. De finnes i to varianter. En variant forutsetter at brukeren taster inn et nummer som passordgeneratoren bruker for å lage det nye passordet. Nummeret får man fra systemet man skal logge seg på. Den andre varianten krever ingen innsats fra brukeren. Nye passord genereres på basis av synkronisert tid (generator og sentralt system har en felles oppfattelse av hva klokka er) eller nytt passord lages på bakgrunn av tidligere brukte passord. En anen variant som benyttes av mange banker er kodekort. Banken oppgir hvilket passord på kodekortet som skal benyttes. Hvert passord benyttes en gang. Det er viktig å legge merke til at ved bruk av kort eller passord-generatorer er det kortet eller passordgeneratoren man autentiserer. Enhetene må derfor oppbevares med omtanke. Det er vanlig å benytte dette prinsipp sammen med prinsippet "noe kjent". Da må brukeren først autentiseres overfor kortet før kortet "går god for" brukeren. HiØ Forelesning 1 Forelesning 1

29 Autentiseringsprinsipper Uforfalskelig egenskap - Biometri
HiØ Autentiseringsprinsipper Uforfalskelig egenskap - Biometri Fingeravtrykk Håndgeometri Blodåremønster på Retina (i øyet) Talegjenkjenning Signaturgjenkjenning Skriverytme Dette kan kalles "Biometrisk autentisering". Det finnes i øyeblikket fem biometri-teknologier på markedet. Disse er basert på - fingeravtrykk - håndgeometri - blodåremønster på Retina (i øyet) - talegjenkjenning - signaturgjenkjenning I tillegg arbeides det med å kunne identifisere brukere gjennom deres bruk av tastaturet. Vi har tidligere slått fast at autentisering er av kort varighet. Dersom analyse av tastaturbruk lykkes, vil man ha funnet frem til en metode med mulighet for en kontinuerlig autentisering. Foreløpig vurderes imidlertid slike mekanismer som for ressurskrevende. Har vært lite omtalt i den senere tid. Prinsippene som benyttes i de forskjellige teknologier er sikkerhets-messig svært interessante, men det stilles foreløpig spørsmålstegn ved teknologienes pålitelighet. Kostnadene vil vanligvis være for høye for utplassering ved mange arbeidsplasser. De blir derfor fortsatt sett på som morgendagens autentiseringsprinsipper, selv om morgendagen nærmer seg raskt. Det leveres i dag PCer med fingeravtrykk-gjenkjenning. HiØ Forelesning 1 Forelesning 1

30 Autentiseringsprinsipper Tredjeinstans og Kontekst
HiØ Autentiseringsprinsipper Tredjeinstans og Kontekst Tredjepart har allerede fastslått identitet autentiseringstjener Kontekst adresse Tredjeinstans I dagliglivet vil dette fungere på samme måte som når noen vi kjenner og stoler på presenterer en ukjent person for oss. Man vil kunne definere forskjellige sikkerhetsdomener. Man kunne tenke seg å la hver domene få ansvar for autentisering av brukere innenfor sitt domene. Når disse brukere så knytter seg opp mot andre sikkerhetsdomener, kan den lokale sikkerhetstjenesten bekrefte brukerens identitet overfor den fjerne domene. Kontekst Med kontekst menes vanligvis tidspunkt og adresse. Kontekst benyttes sjelden alene, men i kombinasjon med andre prinsipper. Dersom autentiseringstjenesten knyttes sammen med fysiske adgangskontroll rutiner, vil bruk av en gitt terminal fungere som god nok autentisering. Den aktuelle bruker er alene, eller en av få som har fysisk adgang til en gitt terminal på et gitt tidspunkt. HiØ Forelesning 1 Forelesning 1

31 Utstyrs- og applikasjonsautentisering
HiØ Utstyrs- og applikasjonsautentisering Applikasjonsautentisering Applikasjon Applikasjon Lag 7 Lag 7 Lag 6 Lag 6 Lag 5 Lag 5 Lag 4 Lag 4 TCP Lag 3 Lag 3 Utstyrsautentisering Autentisering av utstyr forbindes med kommunikasjon. Tjenesten er ønskelig når utstyr skal kommunisere over linjer som ikke er fysisk sikret. Med utstyrsautentisering menes at den ene eller begge parter i en kommunikasjon autentiseres overfor den andre part (eng. peer entity authentication) at det sammen med data sendes informasjon som setter mottaker i stand til å få avsendersystemets identitet bekreftet (eng. data origin authentication). Utstyrsautentiseringen vil vi kople til lagene 1-4 i OSI kommunikasjons-arkitektur. Applikasjonsautentisering Applikasjonsautentiseringen hører hjemme på lag 6 eller 7 i OSI modellen - eventuelt i applikasjonen selv. Dette kan være en måte å holde kontroll med versjoner og varianter av applikasjoner i et stort og komplisert nett. Tjenesten kan også være ett middel til å hindre ukjent og mulig ondsinnet programvare inn i nettet. Applikasjonsautentisering omfattes av de samme begreper som utstyrsautentisering: ende-til-ende autentisering (eng. peer entity authentication) og data opphavs autentisering (eng. data origin autentisering). Ende til ende autentisering, både for utstyrsautentisering og applikasjons-autentisering, er knyttet til forbindelsesorientert kommunikasjon. Tjenesten kan benyttes ved opprettelsen av en forbindelse for å skaffe trygghet for at den applikasjon eller det utstyr det kommuniseres med er det riktige. Data opphavs autentisering er mest knyttet til forbindelsesløs kommunikasjon. Tjenesten skal gi bevis for at informasjon har den påståtte avsender. Tjenesten kan også benyttes ved forbindelses-orientert kommunikasjon for å gi tilsvarende bevis i dataoverførings-fasen. Autentisering er som nevnt en øyeblikkshendelse. Tilliten til en autentisert identitet kan dermed avta over tid. Data opphavs autentisering kan gi ny tillit til samtalepartnerens identitet. Lag 2 Lag 2 PAP CHAP Lag 1 Lag 1 Utstyrsautentisering HiØ Forelesning 1 F.eks. PGP Forelesning 1

32 Utstyrsautentisering (på lag 3/4 eller lavere)
HiØ Utstyrsautentisering (på lag 3/4 eller lavere) Rask og uten plunder for bruker Grovkornet Hensiktsmessig ved sjeldne/få endringer CHAP, PAP, IPSEC er eksempler Linjeautentisering (Calling Party No.) Gir ingen sikkerhet mot ondsinnede/ukjent programvare uautoriserte personer på innsiden HiØ Forelesning 1 Forelesning 1

33 PAP Password Authentication Procedure
HiØ PAP Password Authentication Procedure Benyttes av PPP servere for å validere forespørsler om oppkobling 1. Initiator sender passord og Id til server 2. Server validerer forespørselen og svarer med bekreftelse, eller avviser forsøket, eller gir adgang til nytt forsøk Passord sendes uten beskyttelse, og originator kan sende så mange ganger han vil. PAP er beskrevet i RFC 1334. HiØ Forelesning 1 Forelesning 1

34 CHAP Challenge-Handshake Authentication Protocol
HiØ CHAP Challenge-Handshake Authentication Protocol 1. Etter at link er opprettet, sender server en ”utfordring” til initiator. Initiator svarer med en verdi som finnes ved å utføre en en-veis hash funksjon. 2. Server kontrollerer mot egen beregning 3. Hvis match, aksepteres autentiseringen, ellers termineres forbindelsen. Reautentisering kan kreves når som helst. HiØ Forelesning 1 Forelesning 1

35 Linjeautentisering Operatør går god for tilknytning
HiØ Linjeautentisering Operatør går god for tilknytning A-nummer Lukket brukergruppe Ingen fullgod garanti mot tyvkobling Vet ikke hvilket utstyr som henger på Kjenner ikke programvare eller bruker. HiØ Forelesning 1 Forelesning 1

36 Applikasjonsautentisering
HiØ Applikasjonsautentisering Lisenskontroll Distribusjonskontroll (sikre mot introduksjon av ondsinnet programvare) Påse at man kommuniserer med rett system. HiØ Forelesning 1 Forelesning 1

37 Drift og vedlikehold av autentiseringssystem
HiØ Drift og vedlikehold av autentiseringssystem Installere autentiseringsinformasjon Endre AI Distribuere AI Midlertidig fjerne AI Gjeninstallere AI Fjerne AI Rundt ethvert system for autentisering må det finnes rutiner for drift og vedlikehold. Det må være mulig å håndtere at nye personer kommer til, at eksisterende personer skifter arbeidsoppgaver og derav også rettigheter i systemet og endelig at folk slutter.Tilsvarende rutiner vil det være for utstyrs- og applikasjonsautentisering. De viktigste rutiner i et drift og vedlikeholdssystem for autentiserings-mekanismer vil være: Installere. Autentiseringsinformasjon må installeres både hos pretendenten og verifikatoren når en person skal gis rettigheter i systemet for første gang. Brukeren (pretendenten) får et nytt passord. Passordfila blir oppdatert med det nye krypterte passordet (slik er det i Unix). Tilsvarende gjelder ny programvare og maskinvare. Endre. Autentiseringsinformasjon skal kunne endres som følge av nye eller endrede arbeidsoppgaver, mistanke om ufin oppførsel i systemet eller andre forhold som avgjøres av systemets sikkerhetsansvarlige. Distribuere. Det må være mulig å hente autentiseringsinformasjon som kan benyttes for verifikasjon. Det må f.eks. være mulig for en verifikator å hente kryptert passord fra passordfila for å sammmenlike med et mottatt kryptert passord. Særlig relevant når autentiseringssystemet er fysisk spredd ut over flere maskiner i et nettverk. Fjerne. Autentiseringsinformasjon må kunne fjernes. Dette er bl.a. aktuelt når personer slutter, eller utstyr skrotes. I tillegg kan det være ønskelig å kunne fjerne autentiseringsinformasjon midlertidig. Eksempelvis kan man ønske å utelukke folk i deres ferier eller ved andre lengre fravær. HiØ Forelesning 1 Forelesning 1

38 Aksesskontrolltjenesten
HiØ Aksesskontrolltjenesten Forhindre uautorisert bruk av ressurser Aksesskontroll i i operativsystemet komm.system applikasjoner databaser (DBMSer) Forskjellig grad av ”oppløsning” Førerkort og vognkort takk I EDB systemer utøves aksesskontroll på forskjellige nivåer. Best kjent er den aksess-kontroll som utøves av operativsystemet. Operativ-systemets aksesskontroll-tjenester vokter de sentrale ressurser i en datamaskin - filer i filsystemet, fordeling av RAM til kode og data, I/O og prosessorkapasitet. Andre aksesskontrolltjenester vil ofte bygge på operativsystemets tjenester. Kommunikasjonssystemet kan utøve innkommende eller utgående aksesskontroll. Begge deler vil vanligvis være basert på adresse-informasjon. Sikkerhetsmerker eller kryptering kan benyttes i tillegg til eller til erstatning for adresseinformasjon. Skal man oppnå en høyere grad av oppløsning i aksesskontroll-tjenestene vil det være nødvendig med aksesskontroll inne i applikasjoner. I en applikasjon kan man f.eks. regulere tilgangen til funksjoner. I databaser kan man regulere tilgangen til felt og poster. Maskinvare: Den fysiske maskin, terminal, skriver, diskplass, porter for ymse bruk som skrivere eller kommunikasjon, hukommelse (RAM) Programvare: Som ligger på disk (filbeskyttelse), som eksekverer og kommuniserer via meldinger, programmers data som ligger i RAM og kan (kanskje) leses av i RAM mens de brukes (ref. mine bakdører) Data: Som ligger på disk (filbeskyttelse), poster og felt i databaser. Komm.systemer: Mulighet for å komme ut på nettverket (utgående aksesskontroll), komme gjennom rutere eller broer eller portnere eller releer av andre slag, mulighet for å komme inn i den aktuelle maskin (innkommende aksesskontroll). HiØ Forelesning 1 Forelesning 1

39 Forholdet til andre sikkerhetstjenester
HiØ Forholdet til andre sikkerhetstjenester Forutsetter ofte autentisering Kan implementere konfidensialitet på lagrede data Kan implementere integritet på lagrede data Autentiseringstjenesten skal frembringe de bevis som skal til for å bekrefte en identitet og benyttes derfor forut for aksesskontrolltjenesten. Resultatet av autentiseringen, en bekreftet identitet, benyttes av aksesskontrolltjenesten for å avgjøre om aksess kan tillates eller ikke. Aksesskontrolltjenesten kan i noen tilfeller erstatte eller benyttes som mekanisme for å implementere en integritetstjeneste og konfidensialitetstjeneste på lagrede data. Dette er avhengig av tilliten til aksesskontrolltjenesten og kravene til integritet og konfidensialitet. HiØ Forelesning 1 Forelesning 1

40 Trusler Aksesskontroll skal hindre Uautorisert bruk Avsløring Endring
Trusler Aksesskontroll skal hindre Uautorisert bruk Avsløring Endring Ødeleggelse/sletting Nekte bruk av tjeneste (Denial of Service) Trusler som skal møtes av aksesskontrolltjenester deles ofte inn i følgende fem klasser - uautorisert bruk, avsløring, endring, ødeleggelse og nekte bruk av tjeneste. Uautorisert bruk. En ressurs brukes av noen eller noe som ikke er autorisert for dette eller på en måte som ikke er autorisert. Avsløring. Data blir bevisst eller ubevisst gjort tilgjengelig for noen som ikke er autorisert for slike data. Endring. Data endres av uautoriserte. Ødeleggelse/Sletting. Data ødelegges/slettes eller fjernes på tross av at de er av fremtidig verdi. Nekte bruk av tjeneste. Bruk av EDB ressurser er ofte en kamp om ressurser. Uautorisertes bruk eller uautorisert bruk spiser av de begrensede ressurser slik at autoriserte med autoriserte oppgaver hindres i å utføre disse. I enkelte tilfeller vil et angrep bestå i å belegge alle ressurser slik at ingen lovlig aktivitet blir mulig. Internet ormen fra 1988 er et eksempel på dette. HiØ Forelesning 1 Forelesning 1

41 HiØ Sikkerhetspolicy Policy = politikk, prinsipper, retningslinjer, overordnede regler. Policyeksempel fra butikk - levere tilbake gave. Asylpolicy - sendes tilbake til forrige land med samme transportør På driftsnivå : Betingelser som må være oppfylt for at brukere av et system skal kunne aksessere informasjon og andre ressurser. På systemnivå: Betingelser som må oppfylles for at prosessers aksessforsøk skal formidles av funksjoner i systemets ”reference monitor” Betingelser: Vanligvis et sett med regler som definerer forutsetninger. En policy må kunne håndheves Ved hjelp av egnede mekanismer HiØ Forelesning 1 Forelesning 1

42 Aksesskontrollpolicy elementer
HiØ Aksesskontrollpolicy elementer Subjekter Aktive ”ting” (entiteter) som bruker eller gjør noe med ”ressurser” (objekter). Kan være prosesser/programmer eller personer. I mange sammenhenger utfører prosesser handlinger på vegne av personer (er agenter) Relevant info om subjekter er identitet, kreeringstidspunkt, sikkerhetsattributter Objekter Passive entiteter som ”inneholder” informasjon - filer, kataloger, kommunikasjopnskanaler, RAM (Egentlig litt for snever definisjon. Kan ha kjeder av prosesser - prosess i det ene øyeblikk og objekt i det neste. Relevant informasjon om objekter er eier, størrelse, kreeringstidspunkt, type Regler betingelser for å tillate, for å nekte. En aksesskontroll policy skal identifisere - systemets brukere (subjekter) - systemets ressurser (objekter) og fastsette de regler som avgjør hvorvidt en gitt bruker skal tillates aksess til en gitt ressurs. Subjekter (brukere og brukergrupper): Objekter (maskiner, programvare, komm.ressurser): Regler: Hvem kan gjøre hva med hva og når ? HiØ Forelesning 1 Forelesning 1

43 Aksesskontrollprosessen
HiØ Aksesskontrollprosessen Også kalt reference monitor Initiator Den som skal ha noe gjort Forespørsel Det som ønskes gjort Kontrollør Den/det som avgjør om aksess tillates Målressurs Den instans fore-spørselen gjelder Mål- ressurs Initiator Kontrollør Initiators ACI Målressursens ACI Kontroll funksjon Policy Først skal vi se på en enkel modell som viser hvilke elementer som inngår i en aksesskontroll prosess - initiator, forespørsel, kontrollør, kontrollfunksjon og målressurs. Initiatoren. Initiatoren er det aktive element som tar initiativ til en aksess. Initiatoren kan være en person (bruker). Som regel vil det være en prosess som handler på vegne av en person. Initiatoren kan også være et fysisk utstyr eller programvare i form av applikasjoner, proto-kollelementer i et kommunikasjonssystem etc. Initiatoren må være autentisert forut for aksessforsøket. Forespørselen. Aksessen tar form av en forespørsel. Forespørselen må inneholde en beskrivelse av hvilken ressurs det ønskes tilgang til, samt hvem/hva initiatoren er og eventuelt hvilke rettigheter initiatoren har. For det tilfelle at ressursen er tilknyttet samme maskin og beskyttes av operativsystemet der, vil forspørselen håndteres av operativ-systemet. I andre tilfeller må forespørselen sendes via kommunika-sjonssystemet til det stedet der ressursen befinner seg. Kontrolløren.Kontrolløren mottar forespørsler og skal påse at alle aksjoner på ressursen kun utføres etter at de er bekreftet lovlige. Avgjørelsen kan fattes av en spesiell aksesskontroll funksjon. Beslutning om hvorvidt en aksess er lovlig eller ikke fattes bl.a. på bakgrunn av - informasjon om brukeren (identifikasjonsdata, "billetter", roller, ..) - informasjon om ressursen (behandlingsregler, gradering, ..) - kontekstinformasjon (alarm, øvelse, adresse, dato/klokkeslett, ..) - aksesskontroll policy (regler som binder alt sammen) Kontrolløren og aksesskontroll funksjonen kan være en del av operativsystemet, men det kan også være programvare spesielt for dette formål utenfor operativsystemet. Ressursen. Ressursen er det passive element ved en aksess. Ressursen kan være alle typer objekter så som filer (dokument, programmer), intern eller ekstern hukommelse, prosessortid, poster i en database eller kommunikasjonskanaler. Tilknyttet ressursen finnes behandlingsregler, gradering eller annen aksesskontroll informasjon. Kontekst HiØ Forelesning 1 Forelesning 1

44 Aksesskontrollinformasjon ACI
HiØ Aksesskontrollinformasjon ACI Brukerens Identifikasjon Billetter Roller Klarering Kommuniseres Sensitivitetsmerker Integritetsmerker Bekreftet brukerid. Målressursens Ressursid. Lovlige brukerid.er Klassifisering Kontekst Dato og tidspunkt Rute Adresse Aksesskontroll informasjon kan grupperes etter hvor den befinner seg og hvem som benytter eller har tilgang til den. Det er brukerens, det som overføres, målressursens og kontekst aksesskontroll informasjon. Brukerens aksesskontroll informasjon. Denne informasjon kan f.eks. omfatte en individuell aksesskontroll identitet, gruppeidentitet, rolle, sensitivitetsklasse, integritetsklasse eller sikkerhetsmerker med angivelse av målressurs og tillatte aksjoner på denne. Aksesskontroll informasjon som overføres. Dette kan f.eks. være sensitivitetsmerker avledet av initiatorens sensitivitetsklasse, tilsvarende for integritetsmerker og initiatorens bekreftede (autentiserte) identitet. Ressursens aksesskontroll informasjon. Eksempler på slik informasjon er ressursens egen identitet, initiator identiteter med fortegnelse over lovlige og ulovlige aksjoner for hver, tilsvarende for grupper av initiatorer, tilsvarende for roller, sensitivitetsmerker og integritetsmerker. Kontekst aksesskontroll informasjon. Her kan man tenke seg tidsperioder (aksess er tillatt kun innenfor visse definerte kortere eller lengre tidsperioder), rute (aksess kun tillatt dersom forespørselen har kommet en vei som tilfredsstiller gitte krav - ikke over fiendtlig territorium) eller lokasjon (visse aksesser er kun tillatt fra spesifikke arbeidsplasser). HiØ Forelesning 1 Forelesning 1

45 HiØ Håndhevelse av policy Forutsetter at det er mulig å fatte beslutninger på bakgrunn av foreliggende opplysninger Reglene eller problemene (gjerne boolske uttrykk) må være løsbare Foreliggende opplysninger må være korrekte (vil ikke alltid være tilfelle) Sikkerhetsbrudd/brudd med policy Må kunne håndtere risikoer i denne forbindelse Oppdage hva som skjer/har skjedd Sette seg i stand til å ”redde stumpene” Vurdere å forsterke beskyttelsesmekanismen(e) HiØ Forelesning 1 Forelesning 1

46 Aksesskontroll mekanismer
HiØ Aksesskontroll mekanismer Aksesskontroll matriser Aksesskontroll lister Adgangskort (capabilities) Sikkerhetsmerker Kontekst Aksesskontroll tjenesten kan implementeres ved hjelp av forskjellig slags aksesskontroll mekanismer. En konkret tjeneste kan benytte en eller flere mekanismer for å tilfredsstille oppsatte krav. Vi vil skille mellom fem slags mekanismer: Aksesskontroll lister Aksesskontroll matriser Adgangskort Sikkerhetsmerker Kontekst Vi skal gå igjennom de forskjellige mekanismer, se på hva de krever, hvilke policyer de kan implementere og i hvilke sammenhenger de er mer eller mindre egnet. HiØ Forelesning 1 Forelesning 1

47 Aksesskontroll matrise
HiØ Aksesskontroll matrise Det er lett å modifisere uavhengig av om det skjer endringer med subjektet eller objektet. Tar urimelig stor plass iom. alle de tomme feltene. Man kan redusere antallet subjekter ved å benytte roller (lærer, adm, drift, student, ..) med da blir oppløsningen dårlig. HiØ Forelesning 1 Forelesning 1

48 Aksesskontroll-lister
HiØ Aksesskontroll-lister Aksesskontroll utføres ved at det til ressursen, f.eks. et dokumentet, blir knyttet en liste over hvem som har tilgang til dokumentet og hva slags tilgang de har. Når en bruker ønsker å lese en gitt fil, må han/hun på egnet vis henvende seg til "kontrolløren" med sitt ønske om å lese filen. Brukeren må opplyse om hvem vedkommende er og evt, hvilke rettigheter han er i besittelse av. Forespørselen vil aksepteres eller avvises - vedkommende kan f.eks. være utilfredsstillende autentisert. Man kan også tenke seg å la aksesskontrollisten inneholde gruppe- og rollebetegnelser. Uansett om brukeren er en person, gruppemedlem eller rolleinnehaver, så må kontrolløren gis tilstrekkelig trygghet for at vedkommende er den han gir seg ut for å være. Dette kan oppnås ved at kontrolløren får informasjon om brukerens autentiserte identitet, enten direkte ved at brukeren må gjennomgå autentiseringsprosessen på nytt, eller ved at resultatet av tidligere autentisering gjøres tilgjengelig brukeren lokalt hos seg mottar et "sertifikat" som han kan vise for seg. Det forutsettes at kontrolløren har tillit til den instans som utferdiget sertifikatet. Aksesskontrollister er velegnet når det er ønske om å kunne skille nøye mellom enkeltpersoners bruk av hver enkelt ressurs, det er få brukere eller grupper av brukere. Det er enkelt å fjerne enkeltpersoners rettigheter til en ressurs når denne mekanisme benyttes. På den annen side er mekanismen lite egnet når antallet brukere er stort og skifter ofte. Når en person slutter, endrer arbeidsoppgaver og ansvarsområder, må vedkommendes rettigheter oppdateres alle/mange steder. Det vil være nødvendig med en lenket liste gjennom alle forekomster av vedkommende i aksesskontrollister. Når dokumentene (ressursene) skifter ofte er mekanismen effektiv. Rettighetene forsvinner eller endres sammen med ressursen. Liste per objekt (kolonnevis) over subjekter og deres rettigheter. HiØ Forelesning 1 Forelesning 1

49 Adgangskort/Capabilities
HiØ Adgangskort/Capabilities Liste per subjekt (radvis) over hvilke objekter og rettigheter til disse Innehaver av dette kort er autorisert for å Lese/skrive Bibliog Lese Help.txt Ole-Arnt Johnsen sign. Et adgangskort er noe en bruker skaffer seg for å få tilgang til en ressurs. I sin enkleste form kan det være som en kinobillett. Kinobilletten kan inneholde informasjon om hvilken kino, sal, forestilling og setenummer brukeren (kinogjengeren) har skaffet seg adgang til. Aksesskontrollen som utføres av (billett-) kontrolløren går ut på å kontrollere billettens innhold samt se om kinogjengeren er gammel nok. Tilsvarende må kontrolløren i et EDB system kontrollere innholdet på adgangskortet mot de operasjoner og de ressurser brukeren forsøker å få tilgang til. Brukeren må altså skaffe seg et "adgangskort" som inneholder opplysninger om hvilke identifiserte ressurser (f.eks. dokumenter) brukeren har adgang til, koblet sammen med de rettigheter brukeren har til hver enkelt ressurs. (Kinogjengeren må kjøpe billett på et dertil egnet sted). Adgangskortet inneholder altså to hovedkomponenter: navnet på ressursen eller gruppen av ressurser hvilke autorisasjoner brukeren er gitt med hensyn på denne ressurs Adgangskortet utstedes av en instans som fortrinnsvis er nær brukeren (i samme maskin/lokalnett). Kontrolløren må i dette tilfellet verifisere at den instans som utstedte adgangskortet er kjent og er autorisert for å utstede adgangskort med de påførte autorisasjoner. Alle instanser med autorisasjon for å utstede adgangskort, må vedlikeholde en database over brukere, rettigheter og formater på adgangskort. Det er sannsynlig at kontrolløren(e) og de utstedende instanser jevnlig må utveksle informasjon om endringer som vedrører brukere, rettigheter og kontrollinformasjon (f.eks. i forbindelse med skifte av kryptonøkler). Med mange brukere og mange målressurser kan dette bli en stor database å vedlikeholde. Adgangskort er spesielt anvendelig når antallet brukere eller grupper av brukere er stort og antallet dokumenter er lite. Det er enkelt å endre enkeltbrukeres rettigheter, men det er komplisert å endre rettigheter for alle brukere av en ressurs. HiØ Forelesning 1 Forelesning 1

50 Merking Merking av informasjon (klassifisering)
HiØ Merking Merking av informasjon (klassifisering) Merking av kanaler (autorisering) Autorisering / klarering av personer Vil se på merking i detalj senere Sikkerhetsmerker er "noe" man kan knytte til ressurser som f.eks. dokumenter eller annen lagret informasjon, knyttet til informasjon når den er under overføring, samt knyttet til kommunikasjonskanaler som benyttes for overføringer. Sikkerhetsmerker er et viktig element for implementasjon av de såkalte flernivåsikre operativsystemer. Obligatorisk, eller om man vil mandatorisk eller systempålagt aksesskontroll, benytter sikkerhets-merker. Ofte vil da sikkerhetsmerket angi ressursens sikkerhetsnivå (UKLASSIFISERT, BEGRENSET, HEMMELIG, STRENGT HEMMELIG) for informasjon klassifisert etter sikkerhetsinstruksen. Kontrolløren, eller dennes aksesskontrollfunksjon, må være kjent med hvilke regler som gjelder for ressurser merket med et gitt ikkerhetsnivå. Den lokale kontrolløren der en ressurs befinner seg utfører de nødvendige kontroller ved forespørsler om bruk av en sikkerhetsmerket ressurs. Ved overføring av informasjon kan informasjonen merkes. På mottagerstedet vil man da kunne vedlikeholde den samme aksess-kontroll policy - forutsatt at mottagerstedet er til å stole på. Under overføring kan man benytte kommunikasjonskanaler som er merket for bruk av merket informasjon. F.eks. kan man ved en utgående aksesskontroll sørge for at HEMMELIG informasjon følger en rute som er klassifisert for HEMMELIG (ikke benytte ukryptert radiolinje eller Sovjetiske kommunikasjonssatellitter). Ved innkommende aksess-kontroll kan man avvise informasjon som har kommet langs usikrede ruter. Denne måten å gjøre aksesskontroll på er svært anvendelig når både antallet brukere og antallet dokumenter (ressurser) er stort - forutsatt at man er tilfreds med en relativt grovkornet kontroll. Ved kontroll ned på felt og evt. sammenheng mellom felt i en database, er metoden mindre egnet. Metoden kan også benyttes for å regulere informasjonsflyten internt i et område (domene). Den kan også benyttes for aksesskontroll mellom domener. Det er tre slags regler som avgjør bruken av sikkerhetsmerker Regler for tilgang til merkede ressurser. Hva er lov å gjøre og hvem har lov til å gjøre det. Regler for kreering av merkede ressurser. Hva må bestemmes for en ny ressurs (fil) før den kan gjøres tilgjengelig for bruk. Regler for merkede ressurser inneholdt i merkede ressurer. Må en ressurs som er inneholdt i en annen ressurs alltid overholde den omsluttende ressursens regler ? HiØ Forelesning 1 Forelesning 1

51 Kontekstbasert aksesskontroll
HiØ Kontekstbasert aksesskontroll Tidsbestemt Aksess tillates kun i arbeidstiden Adressebestemt Aksess godtas kun fra avsendere med adresse på definert liste Kun anrop fra leide linjer skal gis aksess til Applikasjonen Ved kontekstbasert aksesskontroll er all aksesskontroll informasjon knyttet til målressursen.Aksesskontroll regler som kan anvendes omfatter når (til hvilke tidspunkter) aksess er lovlig hvorfra (fra hvilke maskiner eller nett) aksess er lovlig via hvilke kommunikasjonskanaler aksess kan tillates. Et eksempel på en kontekst basert aksesskontroll policy kan da være Alle endringer skal utføres i arbeidstiden. Alle endringer skal utføres ved terminaler allokert for dette formål. Fordelen med kontekstbasert aksesskontroll er at den er enkel å gjennomføre. Den forutsetter at de samme regler gjelder for alle. OK når aksessrettigheter kan avgjøres ved målet. HiØ Forelesning 1 Forelesning 1

52 Policy 1: Brukerbestemt aksesskontroll
HiØ Policy 1: Brukerbestemt aksesskontroll Alle filer (ressurser) skal ha en eier Den som oppretter en fil (ressurs) er den eier Eieren bestemmer selv hvilke andre brukere som skal kunne lese, og/eller endre eller eksekvere filen Kari Per Ola Brev Brevkopi Eier: Kari Gruppe: PerogKari Beskyttelse: rw r-- Eier: Per Gruppe: gruppen Beskyttelse: rw r r -- Brukerbestemt aksesskontroll kan defineres som følger: En bruker av systemet kan opprette filer som vedkommende vil eie, og vedkommende bestemmer selv hvilke andre brukere som skal kunne lese og/eller endre filene. Når filen er et program, vil det være aktuelt også å avgjøre hvem som kan kjøre det. Sagt på en annen måte; Alle filer skal ha en eier - den som oppretter filen. Eieren har selv kontroll over filbeskyttelsen på sine filer. Med denne aksesskontroll policyen er det ikke mulig å si noe om hvordan informasjon flyter i systemet. Det er en svakhet. På figuren ser vi tre brukere. Kari og Per er i en gruppe sammen. Policyen vil ikke forhindre at et dokument opprettet av Kari, kopieres av Per (som er gitt tilgang til dokumentet av Kari) som i sin tur gjør dokumentet tilgjengelig for Ola. I enkelte sammenhenger er dette OK. I andre sammenhenger er det et brudd på tilliten Kari har til Per. Denne formen for aksesskontroll policy er den vanlige i UNIX miljøer. Vi skal senere komme tilbake til sertifisering av operativsystemer. SECAN benytter et sett kriterier, opprinnelig definert av det amerikanske forsvarsdepartementet, for klassifisering av operativsystemer. Et klasse C1 operativsystem er tilstrekkelig for å implementere en brukerbestemt aksesskontroll policy. HiØ Forelesning 1 Forelesning 1

53 Flernivå aksesskontroll Informasjonsflyt kun oppover
HiØ Flernivå aksesskontroll Informasjonsflyt kun oppover Beskyttelsesverdig Ugradert Flernivå aksesskontroll representerer standardfortolkningen av Bell-LaPadula. Bell og LaPadula er to amerikanske forskere som utformet det som senere har blitt kalt Bell-LaPadula eller flernivå aksesskontroll policy. De deler informasjon inn i sikkerhetsklasser. Dette kan brukes til å gradere informasjon etter en gitt skala (f.eks. UGRADERT, FORTROLIG, STRENGT FORTROLIG). Brukere gis autorisasjon, dvs. tillatelse til operere på informasjon innenfor et av nivåene. Det er så veldefinerte regler for hvordan informasjon kan flyte. En flernivå aksesskontroll policy kan formuleres som følger: En bruker kan bare utføre lesefunksjoner dersom vedkommende er autorisert for informasjon på dette nivå eller høyere. En bruker skal bare kunne utføre skrivefunksjoner dersom ved-kommende er autorisert for informasjon på et nivå lavere enn eller lik det nivået informasjonen skal skrives til nivå. Informasjon skal med andre ord bare kunne flyte en vei - oppover. En gitt fysisk person kan være autorisert for flere nivåer, men kun ett nivå av gangen. Dette for å hindre at informasjon flyter ukontrollert mellom subjekter (brukere) i systemet. Man kan imidlertid ikke hindre en person i å gjøre notater eller memorere informasjon gitt under en kategori for deretter å formidle denne informasjon videre på et annet nivå. Dette vil imidlertid bryte med vedtatt sikkerhetspolicy. Kort fortalt kan dette bety at brukere som er autorisert for BESKYT-TELSESVERDIG informasjon, kan lese såvel UGRADERT som BESKYTTELSESVERDIG informasjon. Brukeren kan kun skrive BESKYTTELSESVERDIG informasjon. Brukere som kun er autorisert for UGRADERT informasjon, kan skrive såvel UGRADERT som BESKYTTELSESVERDIG informasjon, men kan kun lese UGRADERT informasjon. B1 operativsystemer inneholder mekanismer for flernivå aksesskontroll. En bruker kan lese kun dersom vedkommende er autorisert for informasjon på dette nivå eller høyere. En bruker kan skrive dersom vedkommende er autorisert for informasjon på et nivå lavere eller lik det nivået informasjonen skal skrives til. HiØ Forelesning 1 Forelesning 1

54 Sikkerhetsmerker (labels)
HiØ Sikkerhetsmerker (labels) Består av sikkerhetsnivåer Militær gradering: Cosmic Top Secret, Strengt hemmelig, Hemmelig, Konfidensielt, Begrenset, Ugradert Bedrifters gradering: Bedrift hemmelig, bedrift konfidensielt, ugradert Angir grad av følsomhet Anvendes for papirbasert informasjon, kan også anvendes for maskinlesbar HiØ Forelesning 1 Forelesning 1

55 Nivåer forts. Egenskaper Hierarkiske
Nivåer forts. Egenskaper Hierarkiske Enkle matematiske relasjoner : >, , , < Et antall nivåer er fullstendig ordnet, det er entydig hvorvidt et nivå er høyere - likt - lavere enn et annet HiØ Forelesning 1 Forelesning 1

56 Anvendt på objekter og subjekter
HiØ Anvendt på objekter og subjekter Gradering er å tilordne sikkerhetsmerke til objekt Klarering er å tilordne sikkerhetsmerke til subjekt HiØ Forelesning 1 Forelesning 1

57 Drift- og vedlikeholdsfunksjoner
Gi, endre eller fjerne rettigheter Tilordne gradering Tilordne klasse ved klassifisering Utstede billetter osv. HiØ Forelesning 1

58 Kryptografi Obligatorisk oppgave 1. Generere nøkkelsett i PGP
HiØ Kryptografi Obligatorisk oppgave 1. Generere nøkkelsett i PGP Sende sin offentlige (public) nøkkel som vedlegg til epost, til Håkon Adresse: Filnavn off. nøkkel: <fullt navn>.pgp Man skal signere egen nøkkel med fullt navn og epostadresse Bruk av PGP vil gjennomgås på første gruppeundervisning. Forelesningsnotater vil legges ut kryptert på kursets hjemmeside, tilgjengelig for alle som har gjennomført/fått godkjent oppg. 1. Frist for innlevering vil bekjentgjøres på kursets hjemmeside. HiØ Forelesning 1 Forelesning 1