HiØ 13.01 2003 Datasikkerhet vår 2002 Forelesning 2 Forelesning 2.

HiØ Datasikkerhet vår 2002 Forelesning 2 Forelesning 2

Grunnleggende sikkerhetsegenskaper og trusler
HiØ Grunnleggende sikkerhetsegenskaper og trusler Egenskaper Konfidensialitet Integritet Tilgjengelighet Trusler (stammespråk) Avsløring Manipulasjon Tjenestehindring, Denial of Service, brudd,... Forretningsmessig vinkel Tape ansikt Tape inntekter Ikke være i stand til å utføre arbeid/levere tjeneste HiØ Forelesning 2 Forelesning 2

Systemtekniske sikkerhetstjenester
HiØ Systemtekniske sikkerhetstjenester Identifikasjon og autentisering Aksesskontroll Konfidensialitet Integritet Vedkjenning Logging og revisjon Det er seks systemtekniske sikkerhetstjenester - autentiserings-tjenesten, aksesskontrolltjenesten, konfidensialitetstjenesten, integritetstjenesten, vedkjenningstjenesten og teknisk revisjons-tjenesten. De seks tjenestene skal sammen, eller hver for seg representere mottiltak som HINDRER og OPPDAGER angrep på EDB systemer. Inndelingen i seks tjenester er en anerkjent måte å dele opp arbeidet med systemteknisk sikring. Inndelingen hjelper oss med å fokusere på hvilke sikkerhetsmessige mål vi må sette oss. Hvilke behov har vi under forskjellige forhold. Tjenestene definerer målene mens sikkerhets-mekanismene er midlene som setter oss i stand til å nå de oppsatte mål. Inndelingen i seks tjenester kan også benyttes som en sjekkliste. Stilt overfor et system med behov for sikring kan man ta hver enkelt tjeneste, og se på om tjenesten er aktuell for data som ligger lagret eller er under overføring i systemet det gjelder. Kryptering, digital signatur, sikkerhetsmerker og ruting kontroll er eksempler på mekanismer. Enkelte mekanismer, f.eks kryptering, benyttes i forbindelse med flere tjenester. Mekanismene vil bli beskrevet sammen med den tjenesten som er "mest avhengig" av eller sterkest assosiert med mekanismen. HiØ Forelesning 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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 2 Forelesning 2

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

Konfidensialitetstjenesten
HiØ Konfidensialitetstjenesten Skjule informasjon for uautoriserte på et lagringsmedium (diskett, disk, RAM,.) under overføring Konfidensialitet er å holde informasjon hemmelig for uautoriserte. Egenskapen konfidensialitet kan være ønskelig for alle slags ressurser - maskinvare, programvare og data. I denne sammenheng er det konfidensialitet for informasjon som er relevant. Informasjon er noe som avledes av data. En konfidensialitetstjeneste vil derfor være noe som beskytter data mot uautorisert avsløring. Informasjon kan også avledes av eksistensen av data. Selv om informasjonsinnholdet i data ikke kan avsløres direkte av uautoriserte, kan informasjon avledes av at det finnes data på et gitt sted til et gitt tidspunkt: En fil med et bestemt navn er opprettet. En melding er sendt til en bestemt adressat. Tjenesten kan gi beskyttelse mot at informasjon blir tilgjengelig for uautoristerte ved at de tilfeldigvis eller overlagt får tilgang til denne informasjon. Dette kan oppnås med aksesskontroll eller ved at informasjon ikke kan leses ut av de tilgjengelige data (f.eks. ved kryptering). Beskyttelse mot at informasjon kan avledes av eksistensen av data kan oppnås med aksesskontroll eller ved at det er umulig å holde forskjellig slags data fra hverandre. HiØ Forelesning 2 Forelesning 2

Trusler om avsløring Passive angrep
HiØ Trusler om avsløring Passive angrep Avlytting Lese filer Trafikkanalyse Analyse av meldinger Kryptoanalyse Informasjon kan bli avslørt ved en tilfeldighet eller avsløres ved et bevisst angrep. Mekanismer som beskytter mot den siste trusselen, beskytter også mot den første. Målet med angrepene er å avsløre konfidensialitetsbeskyttede data, delvis avsløre informasjonsflyt eller helt avsløre informasjonsflyt. Angrep på egenskapen konfidensialitet kan være passive eller aktive. Et passivt angrep endrer ikke noe ved systemet for å oppnå sine mål. Aktive angrep forandrer eller forutsetter et aktivt inngrep i systemet som angripes. Passive angrep Avlytting er å passivt samle inn data som overføres på et samband. Avlytting er en forutsetning for å utføre de analyser som beskrives nedenfor. Lese filer. Filene endres ikke, men konfidensiell informasjon på filene er kompromittert. Trafikkanalyse. Å avlede informasjon fra eksistensen eller fraværet av informasjon på et samband er trafikkanalyse. I militære sammenhenger kan trafikkanalyse benyttes til å forutse angrep og hvor angrepet vil komme. Trafikkmengden i det militære nettet vil være størst mellom hovedkvarteret og den eller de avdelinger som skal i angrep. Analyse av kontrollinformasjon. Rutinginformasjon og kvalitets-parametre (QoS) kan i enkelte sammenhenger inneholde informasjon av verdi. Analyse av data. Informasjon kan i større eller mindre grad leses direkte ut av data. Dokumenter kan leses direkte, mens formatterte data krever større innsikt eller grundigere analyse. Kryptoanalyse. Når lagrede eller kommuniserte data er kryptert, må angriperen utføre en kryptoanalyse for å kunne finne ut meningsinnholdet. HiØ Forelesning 2 Forelesning 2

Trusler om avsløring Aktive angrep
HiØ Trusler om avsløring Aktive angrep Trojanske hester Skjulte informasjonskanaler Mot mekanismer som støtter konf.mek. autentiseringsmekanismer aksesskontrollmekanismer nøkkeldistribusjon Trojanske hester er skjulte funksjoner i en ellers presumptivt fornuftig programvare. Trojanske hester kan skjules i all slags programvare, men innloggingsprosedyrer er særlig sårbare for denne slags angrep. Den Trojanske hesten kan enten etterlikne den egentlige innloggingsrutinen, samle navn og passord, for deretter å gå i dekning. Kunnskapen kan senere benyttes til et angrep der angriperen maskerer seg som en lovlig bruker ved å benytte dennes navn og passord. Skjulte informasjonskanaler er uautoriserte måter å lekke informasjon ved hjelp av funksjoner bygget inn i programvaren. Man kan eksempelvis formatere utskrifter på en slik måte at ekstra informasjon kan leses ut av denne. Opprettelse og fjerning av filer er en annen måte å signalisere på. Bryte igjennom mekanismer som støtter konfidensialitet. Aktuelle mekanismer som kan utsettes for angrep er: autentiseringsmekanismer, aksesskontrollmekanismer og nøkkeldistribusjon. HiØ Forelesning 2 Forelesning 2

Konfidensialitetsmekanismer
HiØ Konfidensialitetsmekanismer Omforming Fyllkalk Kryptografi Spredt spektrum (Rutingkontroll) (Aksesskontroll) Omforming av informasjon.Omformingen skal gjøre det vanskelig (umulig) å hente informasjon ut av de omformede data for andre enn dem som kjenner til de essensielle elementer i omformingsteknikken. Slike teknikker omfatter Kryptering Fyllkalk Spredt spektrum Ruting kontroll Aksesskontroll. Skal forhindre aksess til beskyttet informasjon. Dette kan anvendes som beskyttelse av filer i et filsystem. Det omfatter også den fysiske beskyttelse av en kommunikasjonskanal. Forskjellige mekanismer kan benyttes sammen, og vi skal se på hvordan kryptering, fyllekalk og ruting kontroll virker. Spredt spektrum er en teknologi som særlig benyttes i militære sammenhenger og i satellittkommunikasjon. Med spredt spektrum sender man lite informasjon i forhold til båndbredden som anvendes, men man er lite sårbar for støy og avlytting. HiØ Forelesning 2 Forelesning 2

Rutingkontroll E A G C F B D H 13.01.2003 HiØ Forelesning 2 HiØ
Rutingkontroll E A G C F Slike mekanismer regulerer den veien meldinger tar fra avsender til mottaker via et nettverk. Mekanismene kan bl.a. benyttes for å forhindre bruk av ikke tillitsverdige kommunikasjonslinker, fordele trafikk i nettverket slik at ikke gjennomstrømningen blir lav pga. opphopning på enkelte linker eller forhindre at falske meldinger belegger kommunikasjonsressurser. På figuren skal nodene A og E kommunisere. Informasjonen de skal utveksle er av en slik art at den trenger beskyttelse mot avlytting av fremmede makter. Det er derfor uheldig om linken mellom C og F benyttes fordi dette er en radiolinje. Informasjon fra radiolinjer kan avlyttes fra satellitter i verdensrommet. På tross av at veien A-C-F-E er den korteste må veien A-B-D-F-E velges. En slik kontroll kan utføres i hver node. Trafikk merkes med sensitivitetsnivå og det samme gjøres med hver link. Informasjonen fra eksemplet kan merkes som mer sensitiv enn linken C-F kan transportere. En annen rute må derfor benyttes på tross av at tabellverket i noden slår fast at C-F er den korteste vei til målet. Informasjon om ruter kan også sendes med informasjonen i protokoll kontrollinformasjon. Man kan sende med en eksplisitt rute som skal benyttes for en samtale. B D H HiØ Forelesning 2 Forelesning 2

Drift og vedlikehold Nøkkelproduksjon og distribusjon
HiØ Drift og vedlikehold Nøkkelproduksjon og distribusjon D&V av rutingtabeller (D&V av aksesskontroll) Drift og vedlikehold av konfidensialitetsmekanismer vil omfatte forskjellige D&V funksjoner avhengig av den aktuelle mekanisme. Kryptering forutsetter et apparat for nøkkelfordeling. Fyllekalk forutsetter at de to ender i en kommunikasjon kan skille mellom fyllekalk og data. D&V funksjoner vil være som for nøkkelfordeling. Spredt spektrum forutsetter også nøkkeldistribusjon. Ruting kontroll forutsetter kontroll med og oppdatering av av rutingtabeller. Aksesskontroll mekanismer vil ha D&V funksjoner slik de er beskrevet i kapitlet om aksesskontroll. Fysiske aksesskontroll mekanismer vil ha sine egne D&V rutiner. HiØ Forelesning 2 Drift Forelesning 2

Integritet = (Data)kvalitet
HiØ Integritet = (Data)kvalitet Angår Programvare Data Maskinvare Kun autoriserte skal kunne Kreere Endre Slette Og kun på en autorisert måte Integritet er en av de grunnleggende egenskapene som er ønsket for de ressurser man råder over (maskinvare, programvare og data). Integritet er ikke noe man har eller ikke har, men noe man kan ha mer eller mindre av. Gyldendals fremmedordbok oversetter integritet med uskaddhet. I mellommenneskelige relasjoner tenker man på personer med høy integritet som personer man kan stole på. Fra indianerbøkene husker vi karakteristikken "å tale med enkel eller dobbel tunge". I vår sammenheng skal integritet være synonymt med datakvalitet. Dette utelukker integritet for maskinvare, men dette er et område som ikke skal berøres i dette kurset. Integritet for maskinvare involverer slike ting som parallelle og feiltolerante systemer og er som nevnt ikke et tema for dette kurset. Integritet og datakvalitet gjelder i fullt monn for programvare. Programvare er å oppfatte som data når den lagres eller overføres. Virus er uautorisert endring av programvare som senker programvarens integritet. Integritet i programvare rører også ved kravene til kvalitet. Dette hører inn under sertifisering med de tilhørende krav til utviklings-metode og dokumentasjon. Dette er temaer som tas opp i kurset. Integritetstjenesten skal medvirke til at data har høy kvalitet. Dette søkes oppnådd ved at kun autoriserte får anledning til å lage/endre/slette data og at endringer skjer på en autorisert måte. Valget av mekanismer avgjør tjenestens effektivitet. Integritetstjenesten kan oppdage uautoriserte endringer på data som er lagret eller under overføring, hindre at uautoriserte funksjoner og meldinger får noen effekt og gjenopprette integritetsnivået etter at et vellykket angrep er oppdaget. HiØ Forelesning 2 Forelesning 2

Trusler Uautorisert Avspilling Duplisering Endring Sletting Innsetting
HiØ Trusler Uautorisert Avspilling Duplisering Endring Sletting Innsetting Avspilling er å kopiere meldinger som går i et kommunikasjonssystem for så å sende dem på nytt. En avspillingseffekt kan man bl.a. få som følge av feil. Dersom en bekreftelse på utført operasjon blir borte, kan operasjonen bli utført på nytt. Bevisst avspilling forutsetter at utstyr kobles til kommunikasjonsmediet på en slik måte at angriperen kan kopiere data mens trafikken går uforstyrret. Angriperen må så ha mulighet for selv å sende de kopierte data inn i kommunikasjonsmediet. Duplisering er i prinsippet det samme som avspilling, men for data som ligger lagret. I likhet med avspilling kan også duplisering skje ubevisst som følge av feil i maskin- eller programvare. Fjerning er å ta vekk informasjon. Dette kan gjøres subtilt ved at kun utvalgte data fjernes eller mer grovkornet ved at alle data fjernes. Data kan slettes fra lagrings-media, og meldinger kan fjernes fra kom-munikasjonskanaler. Det siste forutsetter kontroll med meldingene på kommunikasjonskanalen - hvis man da ikke fjerner hele kommunika-sjonskanalen (klipper den over). I den avanserte varianten kan angriperen kopiere meldingene som kommuniseres, analysere dem og avgjøre hvilke meldinger som skal videre og hvilke ikke. Lovlig utstyr, slik som broer, portnere og rutere har allerede et slikt ansvar. Utstyret kan også benyttes i ond hensikt for å fjerne meldinger eller sende meldingen i feil retning. På lagringsmedia kan filer slettes - bevisst eller ubevisst. Fjerning forekommer oftest som en følge av feil eller uhell. Samband bryter sammen og disker slutter å virke. Endring og innsetting er å aktivt gå inn å endre eller legge til data på disk eller under overføring. Virus spres ved at programmer endres - som regel får et tillegg som er virusprosedyren. Endring kan utføres når data ikke er integritetsbeskyttet i det hele tatt, eller man er kjent med og kan etterape beskyttelsesmekanismene også. Endring av meldinger i et kommunikasjonssystem forutsetter full kontroll med ommunikasjons-mediet - slik portnere, rutere og broer har det. Endring kan også skje ubevisst som følge av støy i en kommunikasjonskanal eller ved feil eller uhell. Andre trusler mot integritet er slike som går mot mekanismer som integritetstjensten benytter seg av. Trusler mot aksesskontroll-mekanismer der disse benyttes som integritetsbeskyttelse eller trusler mot de spesifikke integritetsmekanismer er også trusler mot integriteten i et system. HiØ Forelesning 2 Forelesning 2

Trusler Flere eksempler
HiØ Trusler Flere eksempler Bakdør Trojanske hester Logiske bomber Virus Bakterier Ormer Programmeringsfeil BAKDØR (Trap door) En skjult inngang til operativsystem, kommunikasjonssystem eller applikasjoner som omgår vanlige sikkerhetsmekanismer. Bakdører er ofte laget for test eller service formål. TROJANSKE HESTER En uautorisert del av et program med autoriserte funksjoner. Kan også forekomme i operativsystem og kommunikasjonssystem. VIRUS En type Trojansk hest. Viruset skjuler seg blant koden til det infiserte programmet som igjen kan infisere andre programmer. Virus kan spres gjennom nettverk. LOGISKE BOMBER. Kode inneholdt i et legitimt program som er satt til å ”eksplodere” når gitte betingelser er tilfredsstilt - tidspunkt, eksistens av fil(er), en spesiell bruker er aktiv. I et dokumentert tilfelle gikk bomben av når konstruktørens ID ikke var tilstede i to på hverandre følgende lønnskjøringer. BAKTERIER Selvstendige programmer som reproduserer seg selv, men ikke over nettverk. Skiller seg fra virus ved at det er et selvstendig program. Skal i prinsippet ikke gjøre noen annen skade enn evt. å oppta plass - impliserer tjenestehindring. ORMER. Bakterier som forflytter seg i nettverk - gjerne via nettverkets driftssystem eller posttjeneste. Kan f.eks. benytte epostsystem, RPC eller andre muligheter for fjerneksekvering, fjernpålogging - for å kopiere seg selv til et nytt system. PROGRAMMERINGSFEIL. Programvare laget av amatører, dårlige eller mangelfulle metoder, dårlig kontroll under utvikling og test, ..... HiØ Forelesning 2 Forelesning 2

Policy Identifiser subjekter Identifiser objekter Fastslå regler
HiØ Policy Identifiser subjekter Identifiser objekter Fastslå regler Hvem skal kunne slette egne filer, systemfiler, ... Hvem skal kunne endre egne filer, systemfiler, . Hvem skal kunne kreere Beskyttelses/håndteringskrav ved kommunikasjon HiØ Forelesning 2 Forelesning 2

Modell for integritet Passiv beskyttelse Data Integritets beskyttelse
HiØ Modell for integritet Data Fjern beskyttelse Beskytt Sjekk Integritets beskyttelse Kontroll funksjon Initiator Data Lage Endre Slette Resultat De lærde strides om hvordan en modell for integritet skal se ut. Vi skal ikke gjennomgå debatten her, men ta utgangspunkt i et par tilnærminger som kan synes egnet for vårt formål: ISO arbeid med et rammeverk for integritet innenfor rammen av åpne systemer. Clark og Wilson modell fra 1987. Vår modell inneholder følgende elementer: Initiator er det element som tar initiativ til å lage/endre/slette data. Elementet kan være en bruker, en prosess som handler på vegne av en bruker, en fysisk enhet (et nettelement) eller en prosess som handler på vegne av et fysisk element. Ubeskyttede data er data som ikke er integritetsbeskyttet. Beskyttede data er data som har en aktiv eller passiv integritetsbeskyttelse. Å beskytte er å omgjøre ubeskyttede data til beskyttede data. Beskyttelsen kan være passiv eller aktiv: Passiv beskyttelse er knyttet direkte til data som f.eks sjekksummer. Passiv beskyttelse hjelper til med å avsløre uautorisert manipulasjon av data. Denne metode vil ikke hindre manipulasjon - bare oppdage. Man kan ikke forhindre data i å bli korumpert når de kommuniseres, men man kan la være å benytte data man har fått kjennskap til er ødelagt. Noe tilsvarende gjelder for lagrede data - man får ikke hindret manipulasjon, men kunnskap om angrep, hva som er gjort og hvordan det er utført kan benyttes for å bringe data tilbake til en tilstand av høy integritet. Fjerne beskyttelse er å gjøre beskyttede data om til ubeskyttede. I noen sammen-henger er det nødvendig å fjerne beskyttelsen før man kan utføre de ønskede operasjoner, for deretter å beskytte data igjen. Kontrollfunksjon realiserer den aktive eller passive beskyttelsen. Ved aktiv beskyttelse er det funksjonen selv som utfører operasjoner på data. Ved passiv beskyttelse utfører funksjonen periodiske kontroller. Det er ved disse kontroller uregelmessigheter kan oppdages og eventuelt rettes opp. Passiv beskyttelse HiØ Forelesning 2 Forelesning 2

Modell for integritet Aktiv beskyttelse Kontroll funksjon Data
HiØ Modell for integritet Operasjon Kontroll funksjon Lagre Endre Slette Data Initiator Aktiv beskyttelse er å skjule data bak et sett med definerte og lovlige funksjoner. Initiatoren slipper altså ikke til data selv. Definerte funksjoner utfører operasjonene på vegne av initiatoren og kan kontrollere initator såvel som de operasjoner initiatoren ønsker å utføre - objektorientert prinsipp?? Aktiv beskyttelse HiØ Forelesning 2 Forelesning 2

Integritetsbeskyttende mekanismer
HiØ Integritetsbeskyttende mekanismer Aksesskontroll (endring, fjerning, produksjon) Digital signatur (produksjon) Sekvensering * (fjerning, produksjon) Sjekksum (endring) Hashing (endring) Message Authentication Code (MAC) * (endring) Cipher Block Chaining * (endring, fjerning, produksjon) Tidsstempling (replay) Kvittering (fjerning, produksjon) Redundans (fjerning) Det er behov for mekanismer som oppdager angrep og/eller hindrer at angrepet blir vellykket. Data som er angrepet må gjenoppbygges. Eksisterende mekanismer kan i større eller mindre utstrekning klare en eller flere av disse oppgaver. Nå vil de forskjellige egenskaper (oppdage, hindre og gjenskape) også være gjensidig avhengige. Vanligvis vil man ikke kunne hindre et angrep eller gjenoppbygge data etter et angrep hvis man ikke først har oppdaget angrepet. Enkelte angrep er ikke mulig å hindre som f.eks å hindre fjerning eller produksjon av meldinger i et kommunikasjonsnett. Man kan imidlertid oppdage at meldinger er fjernet eller produsert slik at nødvendige tiltak kan iverksettes. På transparenten er nevnt eksempler på mekanismer som kan benyttes for å ivareta integritet (helt eller delvis). Vi skal her se litt nærmere på tre av disse mekanismene (merket med *). Av de andre mekanismene er aksesskontroll omtalt som en del av aksesskontroll tjenesten. Digital signatur skal behandles under unngå fornektingstjenesten. HiØ Forelesning 2 Forelesning 2

Integritetsbeskyttelse Oppd./hindre uautoris. endringer
Integritetsbeskyttelse Oppd./hindre uautoris. endringer Fysisk adgangskontroll Logisk aksesskontroll Sjekksum Hashfunksjon Message Authentication Code (MAC) Enveisfunksjon Cipher Block Chaining (CBC) Kommunikasjonsprotokoller har alltid hatt som oppgave å bevare integritet i data som overføres. Mekanismene som benyttes er imidlertid innrettet på å takle feil og ikke bevisste handlinger. Man benytter seg av sekvensnummerering, sjekksummer og redundant informasjon. Alle mekanismene er, og skal være, kjent av mange. Den eller de som manipulerer samband vil kjenne og følge de protokoller som gjelder for sambandet. Vi skal her se på måter å bevare integritet som også kan takle bevisste angrep. Mekanismene skal hver for seg eller sammen imøtegå trusler som uautorisert endring, fjerning og produksjon. Oppdage/hindre uautoriserte endringer Fysisk aksesskontroll kan benyttes for å oppdage angrep og hindre tilgangen til kommunikasjonsmedia og datamaskiner som inneholder data med behov for integritetsbeskyttelse. Kommunikasjonsmedia kan holdes innenfor fysisk kontrollerte områder med jevnlig kontroll av tilknytningspunkter, eller være av en art der til-koplinger vil bli oppdaget. Det er vanskelig å kople seg til fiberkabel. Kabler kan være pakket inn slik at brudd på kabelen eller kabelhylse vil generere en alarm. Disker og maskiner som inneholder eller har adgang til disse disker kan oppbevares og benyttes i lokaliteter der kun autoriserte har adgang. Logisk aksesskontroll er omtalt andre steder i kurset. Slik kontroll kan benyttes for å regulere hvem som har tilgang til data som ligger lagret og hva brukeren har mulighet for /lov til å foreta seg. Man forbinder ofte aksesskontroll med den tjenesten operativ-systemet tilbyr. Da fungerer kontrollen med en grov oppløsning. Adgangen til hele filer eller hele databaser etc. reguleres. Det er imidlertid ingen ting i veien for å implemen-tere aksesskontroll på funksjoner i applikasjoner eller felt i en database. HiØ Forelesning 2 Forelesning 2

Skal være blank 13.01.2003 HiØ Forelesning 2 HiØ 13.01 2003
Sjekksummer kan benyttes for å oppdage endringer. Det finnes forskjellige slags sjekksummer. En-veis funksjoner, hash funksjoner og Message Authentication Code (MAC) er eksempler. Sjekksummer kan benyttes både for lagrede data og data som er under overføring. Sjekksummen må enten fremkomme (benytte en algoritme) på en måte som kun de autoriserte deltagere som kommuniserer kjenner til, eller så må sjekksummen beskyttes krytografisk. En-veis funksjon er en matematisk prosess som medfører transformasjon av data, vanligvis med bruk av kryptografirelaterte rutiner, til verdier som ikke kan benyttes for å få tilbake data verdien er en funksjon av. Passord i Unix beskyttes på denne måten. Passordfilen er tilgjengelig, men representasjonen av passordene som ligger lagret der er slik at klartekst passordet ikke kan avledes av representasjonen på filen. Passord må derfor alltid sammenliknes i kryptert form. Hash funksjoner avbilder verdier fra en stor mengde verdier på en vesentlig mindre mengde verdier. Funksjonen kan benyttes for beskyttelse av meldinger som kommuniseres eller data som ligger lagret. Feil vil oppdages, men kan ikke rettes. MAC er resultatet av en kryptografisk funksjon som er laget spesielt for bruk på meldinger som kommuniseres i et nettverk. MAC verdien kommuniseres sammen med meldingen den beskytter. Aksesskontroll og sjekksummer kan benyttes for å oppdage angrep. De kan også avverge (hindre) angrepene forutsatt mekanismer som analyserer operasjoner og deres lovlighet før de utføres. HiØ Forelesning 2 Forelesning 2

Integritetsbeskyttelse Oppd./hindre uautoris. fjerning
Integritetsbeskyttelse Oppd./hindre uautoris. fjerning Beskyttelse Fysisk og logisk aksesskontroll Kvittering Sekvensering Cipher Block Chaining (CBC) Redundans Fysisk og logisk aksesskontroll kan også benyttes for å hindre at noen eller noe fjerner data under overføring eller som er lagret. Kvittering er en metode godt kjent fra forbindelsesorienterte kommunikasjons-protokoller. Mottakeren sender en kvittering til avsenderen på at melding er mottatt. Hvis kvitteringen mangler, vil avsender oppdage at meldingen er fjernet og kan foreta seg noe (retransmittere). Effekten av fjerning kan reduseres ved at data kan retransmitteres. Metoden er ikke egnet for data som er lagret. Sekvensering gjør det mulig for mottakeren å oppdage fjerning. Sekvensnummeret vil gjøre et hopp der meldingen(-e) er fjernet. Effekten av fjerningen kan da minskes ved at mottakeren gjør avsender oppmerksom på forholdet slik at meldingen(e) kan sendes på nytt. Metoden er spesielt anvendelig for kommunikasjon, men kan også i enkelte tilfeller anvendes på informasjon som ligger lagret. Transaksjoner som ligger lagret på en flat fil kan numereres. Fjerning av en transaksjon vil medføre et hopp i sekvensnummere. Cipher Block Chaining (CBC) er en kryptografisk kjeding av informasjon som skal overføres vis et kommunikasjonssystem. Meldinger som overføres krypteres. Kryptering av en melding gjøres avhengig av resultatet av krypteringen av forrige melding. Mekanismen vil oppdage fjerning/endring/produksjon fordi falske meldinger ikke vil la seg dekryptere. Mekanismen vil ikke hindre fjerning/endring og produksjon, men meldingene kan ikke benyttes. Dermed kan evt. konsekvenser av hindres. Redundans kan motvirke effekten av fjerning ved at det finnes nok informasjon til å gjenskape eller finne frem til den ønskede informasjon ved hjelp av den informasjon man sitter igjen med. Det opplagte eksempel på redundans er sikkerhetskopier. HiØ Forelesning 2 Forelesning 2

Integritetsbeskyttelse Oppd./hindre uautorisert produksjon
Integritetsbeskyttelse Oppd./hindre uautorisert produksjon Beskyttelse Aksesskontroll Digital signatur Sekvensering Kvittering Aksesskontroll kan benyttes også for å hindre uautorisert produksjon eller om man vil - fabrikasjon. Felles for bruken av aksesskontroll som middel for å bevare integritet er at man må ha tillit til at kontrollen virker. Det må f.eks. ikke være mulig å manipulere data på disk ved å editere direkte i sektorene på disken. Produkter som "Norton Utilities" inneholder slike manipulerende funksjoner. Digital signatur er en mekanisme skal øke tilliten til at data har integritet ved at kun autoriserte kan produsere en korrekt signatur. Signaturen kan benyttes i forbindelse med aksesskontroll for å hindre fabrikerte meldinger i å nå sine mål. Den kan også kontrolleres i etterhånd der. Sekvensering, kvittering og CBC vil fungere som for fjerning. Ved produksjon vil det komme meldinger utenfor sekvens. Slike meldinger kan avvises eller oppdages i etterhånd. HiØ Forelesning 2 Forelesning 2

Drift og vedlikehold D&V av akseskontroll Synkronisering
HiØ Drift og vedlikehold D&V av akseskontroll Synkronisering Sekvensering Tidsstempling Kvittering Nøkkelfordeling Signatur Sjekksum Hashing CBC Det er ikke mulig å skissere en modell for drift og vedlikehold av intergritets-mekanismer. Forskjellige mekanismer har forskjellige behov. Det skiller seg imidlertid ut tre hovedgrupper D&V funksjoner: - for aksesskontroll, - for synkronisering og - for nøkkelfordeling. D&V av aksesskontroll mekanismer. D&V rutinene vil være som tidligere omtalt under kapitlet om aksesskontroll. Synkronisering. Sekvensering forutsetter at de kommuniserende parter er enige om - hva første sekvensnummerer er (0 eller 1 eller noe annet), - når man skal begynne sekvensnummerering fra starten og når man fortsetter fra et nummer man har fra tidligere og - når sekvenstelleren går rundt. Tidsstempling forutsetter at de kommuniserende parter har synkronisert sine klokker med en tilfredsstillende nøyaktighet. Det kan også være nødvendig med noe kunnskap om tiden det tar å overføre meldinger gjennom et nettverk. Dette tidsforløpet avgjør i stor utstrekning hvor nøyaktig klokkene hos de kommuniserende parter kan justeres. Kvittering forutsetter avtaler om når kvittering skal eller må sendes. Ofte vil kvittering benyttes i sammenheng med sekvensnummerering - evt. sendes kvittering for hver blokk eller melding. Nøkkelfordeling. Alle mekanismer som benytter kryptering vil trenge nøkkelfordeling. Nøkkelfordeling vil bli tatt opp spesielt. I denne sammenheng nøyer vi oss med å slå fast at mekanismene signatur og sjekksum ofte har behov for nøkler i sammenheng med kryptering. HiØ Forelesning 2 Forelesning 2

Unngå fornekting (vedkjenning)
HiØ Unngå fornekting (vedkjenning) Skal gi bevis for mottak ved å hindre mottaker i urettmessig å påstå at data ikke er mottatt, ved å hindre mottaker i urettmessig å påstå at data er mottatt, Skal gi bevis for sending ved å hindre avsender i urettmessig å påstå at data ikke er sendt og avsender i urettmessig å påstå at data er sendt. Dommer/Notarie som konfliktløser Unngå fornektingstjenesten skal bistå ved konflikter mellom kom-muniserende parter. Tjenesten skal ikke oppdage eller hindre "angrep" i det øyeblikket meldinger utveksles, men avgjøre og bilegge konflikter på et senere stadium hvor partene er uenige om hva som egentlig har forgått. Tjenesten tilbyr bevis for sending og mottak av data. Beviset kan benyttes for å hindre a) mottaker i urettmessig å påstå at data ikke er mottatt, b) mottaker i urettmessig å påstå at data er mottatt, c) avsender i urettmessig å påstå at data ikke er sendt og d) avsender i urettmessig å påstå at data er sendt. Tjenesten tilbyr en løsning der en utenforstående (dommer) avgjør hvem som har rett. En slik løsning forutsetter at det samles tilstrekkelig informasjon (bevis) om meldingsutvekslinger til at uenighet kan finnes ut av og en rettferdig avgjørelse kan tas. Det forutsettes at tredjepart er forskjellig fra de uenige parter. Det er viktige at begge parter godkjenner den tredje part som "uhildet" og med myndighet til å ta avgjørelser. HiØ Forelesning 2 Forelesning 2

Trusler A B Benekte mottak 13.01.2003 HiØ Forelesning 2 HiØ 13.01 2003
På transparenten vises to kommuniserende parter A og B. A er mottaker og B er avsender. Benekte mottak. B overfører en bestilling til A, kursen går ned og A ønsker å unngå tapet. A og B er to banker. B overfører penger til A, men A påstår senere at pengene ikke er mottatt. A B HiØ Forelesning 2 Forelesning 2

Trusler A B Benekte sending 13.01.2003 HiØ Forelesning 2 HiØ
Trusler Benekte sending Benekte sending. A sender en melding til B, men benekter senere å ha gjort dette. Denne type problemer kan man tenke seg å møte f.eks. der priser endres raskt - valuta, aksjer, gull etc. Man forventer en gitt utvikling, legger inn en bestilling og så skjer det motsatte av hva man forventet. Kursen gikk ned istedenfor opp med en mulig konkurs som resultat. Da hadde det vært kjekt å kunne annullere bestillingen. A B HiØ Forelesning 2 Forelesning 2

Trusler A B Påstå sending 13.01.2003 HiØ Forelesning 2 HiØ 13.01 2003
Påstå sending. B sender ikke en melding til A, men påstår å ha gjort det. Følger vi eksemplet ovenfor kan man tenke seg at kursen gikk opp, uten at A hadde lagt inn en bestiling. En stor potensiell gevinst gikk tapt. A B HiØ Forelesning 2 Forelesning 2

Trusler A B Påstå mottak 13.01.2003 HiØ Forelesning 2 HiØ 13.01 2003
Påstå mottak. B påstår å ha mottatt en bestilling som gjør at B kan kvitte seg med valuta som har gått ned i kurs. På denne måten ønsker B å redusere eget kurstap. A B HiØ Forelesning 2 Forelesning 2

Modell Betrodd Notarius Dommer Avsender Mottaker Vedkjenningsdata Data
HiØ Modell Betrodd Notarius Dommer Vedkjenningsdata Data Elementene som inngår ved denne tjenesen er avsender, mottaker, betrodd samt data som overføres og spesielle vedkjenningsdata. Avsender er den instans som tar initiativ for å sende en melding som trenger vedkjennings beskyttelse. Mottaker er den instans som skal motta meldingen. Betrodd er en eller flere instanser som samler sammen informasjon som på et senere tidspunkt kan benyttes som bevis (Notarie) bistår som dommer ved konflikter Data er det som overføres - grunnen til overføringen. Vedkjenningsdata er det som overføres som kan benyttes som bevis ved evt. fremtidige konflikter. Vedkjennings prosessen går i tre faser. Først må partene tilkjennegi sin eksistens og utveksle hemmeligheter med notarie. Under dataoverføringsfasen må partene utveksle, og evt. lagre hos notarie, informasjon som kan benyttes som bevis ved eventuelle senere konflikter. Ved konflikter må bevisene hentes frem og ved hjelp av en betrodd (dommer) avgjøres hvem som har rett. Avsender Mottaker HiØ Forelesning 2 Forelesning 2

Første fase: Nøkkelinitialisering og registering
HiØ Første fase: Nøkkelinitialisering og registering NøkkelA NøkkelB HiØ Forelesning 2 Forelesning 2

Dataoverføringsfase A B Hent info om B Info om B
HiØ Dataoverføringsfase A B Hent info om B Info om B Forespørsel signert med NøkkelA Hent info om A Info om A Bruk UML. Verifiser As signatur Kvittering signert med NøkkelB Verifiser Bs signatur HiØ Forelesning 2 Forelesning 2

Vedkjenningsfase A B Appell Appell og fremlegger signert kvittering
HiØ Vedkjenningsfase A B Appell Appell og fremlegger signert kvittering som bevis og fremlegger signert forespørsel som bevis HiØ Forelesning 2 Forelesning 2

Bevis for sending Tjenesten skal hindre avsender i å benekte sending
Bevis for sending Tjenesten skal hindre avsender i å benekte sending Kan også benyttes mot feilaktig påstått mottak feilaktig påstått sending Kopi Tjenesten skal hindre avsender i å benekte sending. I dette tilfelle kan det være tilstrekkelig at notarius logger meldinger som passerer mellom avsender og mottager. Avsender signerer meldingen ved hjelp av kryptografiske teknikker på en slik måte at mottager og notarius senere kan fastslå at meldingen virkelig kom fra en spesiell avsender og ingen annen. I og med at ingen andre enn den korrekte avsenderen skal kunne produsere signaturen som kan benyttes som bevis, skal heller ikke mottageren kunne forfalske denne. Tjenesten vil dermed også hindre mottageren i feilaktig å påstå å ha mottatt en melding. Notarius vil logge det nødvendige bevismateriale. Dersom senderen ingenting sender, vil notarius ingen ting logge. Tjenesten kan dermed også benyttes for å hindre avsender i feilaktig å påstå å ha sendt en melding. Avsender Mottaker HiØ Forelesning 2 Forelesning 2

HiØ Bevis for avlevering Tjenesten skal hindre mottageren i å benekte mottak Protokolleksempel: A sender melding til notarie Notarie beskytter meldingen og sender videre til B B bekrefter mottak av meldingen Notarie sender nøkkel til B Tjenesten skal hindre mottageren i å benekte mottak. For at tjenesten skal være effektiv, må den starte før meldingen sendes. Hvis ikke kan mottaker undersøke meldingen og avgjøre hvorvidt det er ønskelig å prosessere data slik avsender ønsker. Dette kan mottaker gjøre uten å bli stillet til ansvar for de handlinger, eller mangel på handlinger, som utføres på vegne av avsenderen. En vedkjenningstjeneste med bevis for avlevering skal implementeres ved hjelp av en betrodd tredjepart. Det er imidlertid ikke tilstrekkelig for notarius å logge meldingene som passerer forbi siden mottakeren fortsatt kan la være å sende bekreftelse på mottak. Mottakeren kan isteden påstå at kommunikasjonskanalen ikke var tilgjengelig på det aktuelle tidspunkt. Det finnes ingen metode for å skille mellom en kommunikasjonskanal som er brutt og et system som handler som om kanalen er brutt. Pålitelig kommunikasjon med en notarie avhenger av en fungerende kommunikasjonstjeneste. Først må man etablere kontakt og mottakeren må angi sin intensjon om å motta melding. Deretter sendes meldingen av senderen selv eller av betrodd tredjepart på vegne av senderen. Man har nå ihvertfall et bevis fra første del av meldings-utvekslingen - men mottaker kan forsatt benekte å ha mottat selve meldingen. Dette må i så fall skyldes kommunikasjonsproblemer og da må dette logges. Notarius eller avsender bør så forsøke å reetablere forbindelsen for så å sende meldingen. Transparenten viser et eksempel på en protokoll. A sender en signert melding til Notarius. Notarius logger relevante data og gir meldingen en egen beskyttelse. B er ikke i stand til å dekode meldingen pga. denne beskyttelsen. B gir Notarius en bekreftelse på mottak (som logges). Notarius sender (og logger at så gjøres) koden som setter B istand til å åpne "konvolutten". Med en annen protokoll vil B gis bruddstykker av informasjonen. Etter hvert som B mottar mer og mer informasjon, har B mindre og mindre muligheter for å benekte mottaket. HiØ Forelesning 2 Forelesning 2

Mekanismer Betrodd tredjepart (notarie/dommer) Digital signatur
HiØ Mekanismer Betrodd tredjepart (notarie/dommer) Digital signatur Kryptering Mekanismer som kan anvendes av vedkjenningstjenesten er - digital signatur, - kryptering og - betrodd tredjepart (notarie/dommer). Betrodd tredjepart skal alltid benyttes. De andre mekanismene benyttes av og i tillegg til betrodd tredjepart. Den betrodde tredjepart kan ha litt forskjellige roller eller funksjoner - notarius som samler bevis og megler ved disputter - autoritet som sørger for at data benyttet ved bevisproduksjon er ekte - tidsstemplingstjeneste HiØ Forelesning 2 Forelesning 2

Drift og vedlikehold Tredjepart Nøkkelhåndtering
HiØ Drift og vedlikehold Tredjepart regulere funksjon for logging av bevis arkivfunksjon for loggede bevis Nøkkelhåndtering Nøkkelproduksjon (opprettholde tiltro til nøkkelmateriale) Nøkkeldistribusjon Drift og vedlikeholdsfunksjonene vil variere med valg av mekanismer for å implementere unngå fornektings tjenesten. Krypto baserte mekanismer vil ha behov for nøkkelfordelingsfunksjoner. D&V av integritetstjenester ble beskrevet eller referert i forbindelse med integritetstjenesten. Integritetstjenesten vil også ofte være basert på kryptografiske mekanismer - og derav behov for nøkkeldistribusjon. HiØ Forelesning 2 Forelesning 2

Revisjonstjenesten Skal oppdage sikkerhetsbrudd
HiØ Revisjonstjenesten Skal oppdage sikkerhetsbrudd Skal kontrollere kontrollmekanismer Skal bekrefte etterlevelse av policy Skal bidra til å finne frem til forbedringer Skal muliggjøre analyse av angrep Skal virke preventivt Med revisjon (eng. audit) menes her innsamling og inspeksjon av data om sikkerhetsrelevante aktiviteter i et system. Autentisering, aksess-kontroll, konfidensialitet og integritet skal imøtegå trusler mot de grunnleggende egenskaper tilgjengelighet, konfidensialitet og integritet. Revisjonstjenesten er neste nivå beskyttelse - det som skal oppdage problemer/angrep man evt. ikke har klart å hindre. Mer detaljert er hensikten med revisjon å kontrollere kontrollmekanismenes effektivitet bekrefte at eksisterende sikkerhetspolicy etterleves finne frem til endringer/forbedringer i eksisterende sikkerhets-mekanismer, policy og prosedyrer være til hjelp ved analyse av angrep, og derigjennom anbefale prosedyrer som kan redusere skadene I tillegg skal revisjonstjenesten ha en preventiv effekt. Vissheten om at systemet overvåkes skal medvirke til at antallet angrep blir færre. Teknisk revisjon forutsetter at sikkerhetsrelevante hendelser logges. Revisjonstjenesten skal analysere loggen. Enkelte hendelser, eller samling hendelser bør medføre alarmer i tillegg til logging. Revisjonstjenesten er selv avhengig av de andre sikkerhetstjenestene. Integritetstjenesten er spesielt viktig for å bevare tilliten til revisjons-informasjonen. Revisjonsinformasjonen kan også inneholde informasjon som må beskyttes mot innsyn. HiØ Forelesning 2 Forelesning 2

Trusler mot revisjonstjenesten
HiØ Trusler mot revisjonstjenesten Mot tilgjengelighet lagrings-, kommunikasjons-, prosesseringskapasitet Mot konfidensialitet direkte og indirekte Mot integritet manipulasjon, sletting, fabrikasjon av rev. data Driftsansvarlige skal overvåkes spesielt Hvem skal overvåke overvåkerne ? Trusler mot revisjon omfatter trusler mot tilgjengelighet, konfidensialitet og integritet. Redusert tilgjengelighet omfatter manglende lagringskapasitet for potensielt store mengder revisjonsdata, manglende kommunikasjons-kapasitet for overføring av revisjonsdata og manglende prosessor-kapasitet for behandling og analyse av revisjonsdata. Manglende konfidensialitet omfatter avsløring av hva som overvåkes slik at angrep settes inn der overvåking ikke foregår og indirekte avsløring av konfidensiell informasjon revisjonstjenesten har tilgang til - f.eks passord. Manglende integritet omfatter manipulasjon av revisjonsdata for å skjule angrep, sletting av revisjonsdata for å skjule angrep og produksjon av revisjonsdata for å diskreditere annen part. Det må nevnes at revisjonstjenesten i høy grad omfatter revisjon av driftsansvarlige arbeidsoppgaver. Driftsansvarlige har vanligvis vide fullmakter og kan derfor i enkelte tilfeller gjøre mye skade. I noen organisasjoner vil det finnes spesielle datasikkerhetsansvarlige. Denne ansvarsfordelingen, med tilsvarende fordeling av myndighet, skal sikre en revisjon også av driftsansvarliges arbeidsoppgaver. Vi tenker her særlig på arbeidsoppgaver som har med sikkerhetsmekanismer å gjøre: endre passord, bestemme kriterier for revisjonslogging, implementasjon av autentiseringspolicy, implementasjon av aksesskontroll policy etc. Hvem skal så overvåke overvåkerne ? Til slutt er man nødt til å basere seg på tillit til enkeltmennesker. HiØ Forelesning 2 Forelesning 2

Revisjonspolicy Entydig identifiserbarhet
HiØ Revisjonspolicy Entydig identifiserbarhet Holdes ansvarlig for sine handlinger Sikres mot urettmessige anklager I policyen for de enkelte sikkerhetstjenester må det finnes utsagn om hva som er sikkerhetsrelevante hendelser som skal underlegges revisjon. Revisjonspolicyen selv vil derfor begrenses til overordnede krav. Policy for revisjon. Den enkelte bruker er ansvarlig for sine handlinger. Handlinger skal kunne føres tilbake til den ansvarlige slik at ingen urettmessig skal kunne holdes ansvarlig for handlinger vedkommende ikke har utført. Dette forutsetter at: - alle involverte parter er entydig identifiserbare - utstyr og programvare inneholder revisjonsfunksjoner - utstyr og programvare tar i bruk sine revisjonsfunksjoner slik at kravene til revisjon fra de enkelte sikkerhetstjenester kan oppfylles Revisjonstjenesten skal - lokalt analysere og lagre lokal revisjonsinformasjon, - gi lokal alarm på nærmere definerte hendelser, - overføre revisjonsinformasjonen til en sentral instans etter komprimering, - foreta en sentral analyse av innsamlet revisjonsinformasjon og - plassere revisjonsinformasjon i arkiv etter komprimering. All revisjonsinformasjon skal være på et standardisert format og inneholde - type hendelse, - årsak, - tidspunkt, - hva som oppdaget hendelsen, - hvem som forårsaket hendelsen, - ble angrepet avvist eller ikke. HiØ Forelesning 2 Forelesning 2

Revisjonsmodell Alarm Hendelse Revisjons melding Analyse av meldinger
HiØ Revisjonsmodell Hendelse Revisjons melding Deteksjon og analyse av sikkerhetsrelevante hendelser Analyse av meldinger Post til rev.logg Alarm Revisjons logg Ved revisjon ser man for seg subjekter som utfører handlinger (lese, skrive, endre, ..) og objekter som handlingene utføres på. Enkelte handlinger, eller resultatene av dem, er av en slik art at de har sikkerhetsmessig relevans. Dette vil vi kalle hendelser, sikkerhets-relevante hendelser eller aller helst reviderbare hendelser. Hendelsene er utgangspunktet for revisjonsaktiviteter. Revisjon vil foregå i flere nivåer. Noe utstyr er ikke selv i stand til å lagre revisjonsinformasjon ei heller utføre tilfredsstillende analyse. Revisjonsinformasjon kan derfor bli overført og analysert i flere trinn - lokalt og sentralt. Revisjonsmodellen består av følgende elementer og prosesser: Hendelser. Hendelser er noe som "skjer" som for eksempel at en person logger seg på, at en prosess sender en melding, at en melding mottas etc. Reviderbare hendelser er enten slike som er definert relevante (pålogging) eller slike som bryter med vedtatt sikkerhets-policy. Bruk av feil passord er en slik hendelse. Ofte vil feil passord skyldes feiltasting, men det kan også være et angrepsforsøk. Policyene bestemmer vilke hendelser som er reviderbare og som derfor skal føre til oppmerksomhet fra revisjonstjenesten. Alarm. Hendelser som er av en slik art at de trenger rask inngripen skal resultere i en alarm. Gjentatte forsøk på innlogging med galt passord er en slik hendelse. Analyse av logg og arkiv Revisjons arkiv HiØ Forelesning 2 Forelesning 2

Skal være blank 13.01.2003 HiØ Forelesning 2 HiØ 13.01 2003
Deteksjon og analyse. Avgjøre om en hendelse har relevans for deretter å - forkaste, - generere sikkerhetsalarm, - generere revisjonsmelding eller - generere begge deler Revisjonslogg. Et lager for revisjonsmeldinger. Revisjonsarkiv. Et lang tids lager for revisjonsmeldinger. Revisjonsmelding. Melding som inneholder den nødvendige informasjon om en reviderbar hendelse. Revisjonspost. Dette er en post i en database som oppbevarer innholdet i en mottatt revisjonsmelding. Slike meldinger mottas av revisjonssystemet som avgjør om det skal resultere i en alarm umiddelbart. En alarm kan da være alt fra klokker som ringer til melding til revisor via meldingssystemet. Vi kan kalle dette analyse på første trinn. Hver revisjonsmelding analyseres separat. Meldingen sendes videre til neste analysetrinn. Her skal man kunne oppdage mer avanserte angrep, som f.eks. samordnet angrep mot flere objekter. Den mottatte revisjonsmeldingen analyseres sammen med meldinger som er mottatt over en tid. Gjentatte forsøk på innlogging med feil passord er et eksempel på slike angrep. Nå er det egentlig et dårlig eksempel fordi login rutinen selv beskytter mot denne type angrep. I prinsippet kan det være revisjonsmekanismer - og det er det når angrepene spres over tid. I tillegg er det naturlig her å foreta jevnlig analyser av loggen. Det er sannsynlig at denne funksjonen ligger lokalt. Neste og siste nivå er den sentrale arkivfunksjonen- med de kvartalsvise og årlige store revisjoner med produksjon av revisjonsrapporter. HiØ Forelesning 2 Forelesning 2

Om revisjon Inspisere subjekter og objekter Gjenkjenne bruksmønstre
HiØ Om revisjon Inspisere subjekter og objekter Gjenkjenne bruksmønstre Analysere aksess til objekter Analysere bruk av mekanismer Oppdage forsøk på omgåelse Oppdage ulovlig bruk av rettigheter Avskrekke - informasjon til brukere Hovedmålsettingen for revisjonstjenesten er å sørge for at den enkelte bruker kan holdes ansvarlig for brudd på vedtatt sikkerhetspolicy. Revisjonstjenesten må derfor være tilgjengelig i alle maskiner systemer. Revisjonstjenesten har fem delmålsettinger avledet av hovedmål-settingen 1. Tjenesten må gjøre det mulig å inspisere både subjekter (enkeltindivider) og objekter (filer, nettelementer, ..). gjenkjenne bruksmønstre ved aksess. Dette gjelder både hvordan brukere aksesserer systemet og hvordan objekter blir aksessert. analysere hvordan objekter har blitt aksessert og hvilken atferd brukere har hatt. analysere bruken av spesielle beskyttelsesmekanismer og deres effektivitet. 2. Man må kunne oppdage brukeres og utenforståendes gjentatte forsøk på omgå beskyttelsesmekanismer. 3. Man må kunne oppdage (forsøk på) bruk av rettigheter som er mer omfattende enn de vedkommende har. 4. Revisjonstjenesten skal ha en avskrekkende effekt. Dette betyr at brukerne må være oppmerksom på tilstedeværelsen av en revisjonstjeneste. 5. Brukerne skal ha en forsikring om at forsøk på å omgå beskyttelses-mekanismer blir logget og oppdaget. Dette skal øke tilliten til systemet. HiØ Forelesning 2 Forelesning 2

Revisjonsinformasjon
HiØ Revisjonsinformasjon Dato, tidspunkt Hvem ble handlingen utført for Hvorfra kom forespørselen i utgangspunktet Type. Hvilken type hendelse var det Rapportør. Hva/hvem opdaget hendelsen Vellykket eller ikke Navn på berørte objekter Revisjonsinformasjonen bør inneholde følgende elementer: Tidspunkt. Dato og nøyaktig tidspunkt. Graden av nøyaktighet er avhengig av hvor nøyaktig man klarer å synkronisere de forskjellige elementer som inngår i revisjonen. Hvem. En entydig identifikasjon av hvem handlingen ble utført på vegne av. Hvorfra. Hvor kom forespørselen fra i utgangspunktet ? En forespørsel kan ha passert gjennom mange "hender" på veien mot sitt mål. Slik kan angriperen å skjule sine spor. Adressen kan f.eks. være en terminalid. Når det er vanskelig å nøyaktig identifisere angriperen, f.eks. fordi vedkommende er maskert som en lovlig bruker, kan adressen være en hjelp til å finne angriperen. I det minste sier den noe om hvor man har et sikkerhetsproblem. Type. Hva slags hendelse er det? Her kan det være nødvendig å klassifisere hendelser. Er det brudd på autentiseringspolicy, aksess-kontroll policy osv. Man må finne frem til hvor finkornet det er nødvendig å klassifisere hendelsene. Rapportør. Hvor, hvordan og av hva ble hendelsen oppdaget og logget. Vellykket / ikke vellykket. Var angrepet vellykket - i betydningen klarte man å trenge igjennom forsvarsmekanismene. Et misslykket angrep (klarte ikke å trenge gjennom forsvaret) indikerer at forsvars-mekanismene fungerer for denne type angrep. Et vellykket angrep betyr dels at man må foreta seg noe for å redusere skadene av angrepet (gjenoppbygging) dels at man må se på hensiktsmessigheten av eksisterende forsvarsmekanismer. Man må forsøke å tette igjen hullet. Navn på objekter. Navn på objekter som ble introdusert, endret eller fjernet er nødvendig bl.a. for å kunne gjennomføre en oppryddings-aksjon. Ved modifikasjon kan det for eksempel være virus som blir plantet inn i programvare. Hvis man kjenner til vilken programvare som ble smittet, kan denne behandles med "antivirus middel" eller fjernes. I tillegg skal modifikasjoner utført av systemansvarlige på bruker eller sikkerhetsdatabaser beskrives. HiØ Forelesning 2 Forelesning 2

Reviderbare hendelser Autentisering
HiØ Reviderbare hendelser Autentisering Vellykket Pålogging Avlogging Mislykket Drift og vedlikehold av autentiserings-mekanismer Pålogging. All annen revisjon er basert på kunnskap om identiteten til vedkommende som utførte en gitt handling. Identiteten er revisjons-informasjon. Passord eller liknende skal ikke logges. Noen ganger oppgis ved en feiltagelse passordet som identitet (navn). Ved å logge den oppgitte identiteten kan man komme i fare for å logge et passord noe som øker risikoen for kompromittering av dette passordet. Ved feil i påloggingsprosedyren er det ikke anbefalelsesverdig å logge identiteten. Kun hendelsen, uten identitet, logges. I systemer der sannsynligheten for å gjøre en slik feil er liten, kan den oppgitte identiteten logges. Dette kan være en hjelp for å avsløre vedkommende som forsøker et innbrudd. Autentisering med engangspassord er et eksempel på system der man gjerne kan logge identiteten. Den vanlige UNIX innloggingsprosedyren er et eksempel på det motsatte. Brukere kan selv kontrollere lister over når de skal ha vært pålogget for å avsløre om noen benytter deres identitet i en maskerade. Gjentatte mislykkede forsøk på pålogging skal resultere i en alarm. Bruk av passordgenerator som er meldt savnet skal resultere i en alarm. Avlogging. Avlogging er en reviderbar hendelse. Det er flere årsaker til det. Tidspunkt for avlogging kan frikjenne brukere for ansvar for handlinger utført når de ikke var pålogget. Arbeidsformer som kan være en sikkerhetsrisiko kan avsløres. En arbeidsstasjon som er pålogget hele dagen vil i lengre perioder kunne stå uten tilsyn. Slike forhold må undersøkes og evt. påtales. Drift og vedlikehold av autentiseringsmekanismer. Skifte av passord er en reviderbar hendelse. Revisjonsmekanismen kan varsle om passord som skiftes for sjelden, om passord som er for enkle og om passord som benyttes på nytt etter passordskifte. D&V rutinene til de enkelte autentiseringsmekanismer vil håndtere og rapportere slike hendelser. I tillegg kan revisjonstjenesten overvåke bruken av D&V rutinene. Slik kan man avsløre brukere som systematisk skifter passord for å få tilbake sitt yndlingspassord. (Det finnes eksempler på folk som har skiftet passord 20 ganger på rad for å oppnå dette.) HiØ Forelesning 2 Forelesning 2

Reviderbare hendelser Aksesskontroll
HiØ Reviderbare hendelser Aksesskontroll Operativsystemet Ikke-autorisert aksess til objekter, Endring av aksessrettigheter, Aksess til konfigurasjonsdata, Aksess til objekter (regulerbart), System-, datasikkerhets- og revisjonsansvarlige Kommunikasjonssystemet Ikkeautorisert forsøk på oppkobling, Opp- og nedkoblinger Applikasjoner Uautorisert bruk av funksjoner, Bruk av funksjoner (regulerbart), Uautorisert aksess til data, * Aksess til data (regulerbart) Operativsystemet utfører aksesskontroll på objekter med en oppløsning på hele filer. Det skal kunne levere revisjonsinformasjon med en tilsvarende nøyaktighet. Kommunikasjonssystemet kan regulere utgående og innkommende oppkoblinger. Applikasjoner kan regulere tilgang med oppløsning i funksjoner og ned på datafelt. I operativsystemet. Det skal være mulig å logge spesielle subjekter og deres bruk av objekter, spesielle objekter og hvem det er som bruker dem, og fokusere på spesielle subjekters bruk av spesielle objekter. Man kan se på alle typer aksess - kreere, slette, lese, skrive, endre og eksekvere. Følgende hendelser er reviderbare: Subjekters operasjoner på objekter de ikke er autoristert for å håndtere. Ta et system opp/ned. Endring av aksessrettigheter. Aksess til konfigurasjonsdata, herunder passordfil, gruppefil etc. Handlinger utført av systemansvarlige, datasikkerhets-ansvarlige og revisor skal overvåkes spesielt. I kommunikasjonssystemet. Kommunikasjonssystemet er representert ved protokollstakkene (OSI eller TCP/IP) og de fysiske transmisjonslinjer. Følgende hendelser er reviderbare: Utgående og innkommende opp- og ned-koblinger (regulerbart). Forsøk på ulovlige oppkoblinger. Opp- og ned-koblinger er reviderbare hendelser fordi slik informasjon er nødvendig for å spore handlinger i et komplekst nettverk. En angriper kan forsøke å skjule sine spor ved å utføre sine handlinger via mellomliggende systemer. Informasjon om lovlige oppkoblinger gir mulighet for å spore slike angrep. Stadige viderekoblinger er i seg selv grunnlag for mistanke. Forsøk på ulovlige oppkoblinger kan være feil (opplæring eller rekonfigurering er påkrevet) eller angrepsforsøk. I applikasjoner. Følgende hendelser er reviderbare: Bruk av funksjoner (regulerbart). Uautorisert bruk av funksjoner. Aksess til data (regulerbart). Uautorisert aksess til data. Oppløsningen vurderes i forbindelse med hver enkelt applikasjon. HiØ Forelesning 2 Forelesning 2

Reviderbare hendelser Konfidensialitet
HiØ Reviderbare hendelser Konfidensialitet Operativsystem Håndtert av aksesskontroll Kommunikasjonssystem Brudd på kommunikasjon Applikasjoner Komplekse søkebegrep I operativsystemet. Ingen reviderbare hendelser definert enda. I kommunikasjonssystemet. Reviderbare hendelser er : Brudd på kommunikasjon Brudd på kommunikasjon kan være hendelige feil, men det kan også f.eks. skyldes innbrudd på transmisjonsmediet for tapping av informasjon (når mediet er en kabel). I applikasjoner. Reviderbare hendelser er : Søking i databaser (regulerbart). Søking i database med komplekse søkebegreper eller "fra forskjellige vinkler", kan være forsøk på å avlede informasjon som ellers er konfidensialitetsbeskyttet. HiØ Forelesning 2 Forelesning 2

Reviderbare hendelser Integritet
HiØ Reviderbare hendelser Integritet Operativsystem Fjerning og introduksjon av filer Endring i innhold på filer Kommunikasjonssystem Endringer i rutingtabeller Endringer i konfigurasjonstabeller Applikasjoner Udefinert I systemer der man ikke kan ha full tillit til at operativsystemet har kontroll med alle aktiviteter, er integritetsrevisjon særlig viktig. En del PC brukere kjenner programvare som Norton Commander og Norton Utilities. Disse tillater manipulering av data direkte på disken. I operativsystemet. Integritetsmekanismene er foreløpig dårlig spesifiserte. Man kan imidlertid tenke seg følgende hendelser som reviderbare: Endringer i programvare, Endringer i data, Ny programvare, Nye data, Fjernet programvare, Fjernede data Alle disse hendelser gjelder hele filer. Det kan på alle filer legges kryptografiske sjekksummer. I tillegg kan man vedlikeholde en komplett oversikt over alle filer som eksisterer på et gitt tidspunkt. Introduksjon og fjerning av filer skal oppdages ved den ukentlige lokale revisjon. Samtidig skal man kontrollere sjekksummene på alle filer. På den måten kan man oppdage endringer i filer. Alle endringer, introduksjoner og fjerninger kan så holdes opp mot revisjonsinformasjon omtalt under aksesskontroll. Det skal da være mulig å fastslå hvem som har gjort endringer, om endringene er autoriserte og om de er utført slik sikkerhetspolicy krever. I kommunikasjonssystemet. Følgende endringer er reviderbare: Endringer i rutingtabeller, Endringer i konfigurasjonstabelle. Oppdagede endringer sammenholdes med revisjonsinformasjon fra aksesskontrollen. I applikasjoner. Foreløpig udefinert, men endring og sletting av poster i en database er eksempler på hendelser som er aktuelle. Dette må vurderes for den enkelte applikasjon. Reviderbare hendelser - unngå fornekting. Foreløpig udefinert Reviderbare hendelser - revisjon. Revisjonstjenesten stiller spesielt strenge krav til tilgjengelighet, konfidensialitet og integritet. De reviderbare hendelsene i forbindelse med revisjon er ikke anderledes enn de som til nå er beskrevet, men de skal alltid behandles og logges. HiØ Forelesning 2 Forelesning 2

Drift og vedlikehold av revisjon
HiØ Drift og vedlikehold av revisjon Slå av/på produksjon av revisjonsmeldinger Slå av og på produksjonen av revisjonsposter Slå av og på produksjon av alarmer Igangsette arkivering eller sikkerhetskopiering Regulere analysemekanismer Igangsette analyse Komprimering Revisjonstjenesten blir av driftspersonale og brukere ofte oppfattet som noe plagsomt, unyttig og ressursødende. Tjenesten forbruker prosseseringstid, båndbredde i kommunikasjonssystemet og ikke minst lagringsplass. For at driftspersonale og brukere skal bli medspillere er det derfor viktig at revisjonstjenesten er dynamisk. Det skal være mulig å overvåke såvel subjekter som objekter og spesielle kombinasjoner av begge, men tjenesten må være dynamisk. Over tid må det være mulig å gjøre store endringer med hensyn på hva og hvem som overvåkes og hvor intensivt og finmasket overvåkingen skal være. Det er nødvendig med følgende funksjoner (listen er ikke nødvendigvis uttømmende): 1. Slå av og på produksjonen av revisjonsmeldinger 2. Slå av og på produksjonen av revisjonsposter 3. Slå av og på produksjon av alarmer 4. Igangsette arkivering eller sikkerhetskopiering 5. Regulere analysemekanismer 6. Igangsette analyse 7. Komprimering HiØ Forelesning 2 Forelesning 2

HiØ 13.01 2003 Datasikkerhet vår 2002 Forelesning 2 Forelesning 2.

Liknende presentasjoner

Presentasjon om: "HiØ 13.01 2003 Datasikkerhet vår 2002 Forelesning 2 Forelesning 2."— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding

Logg inn

Logg deg på via sosiale nettverk:

HiØ 13.01 2003 Datasikkerhet vår 2002 Forelesning 2 Forelesning 2.

Liknende presentasjoner

Presentasjon om: "HiØ 13.01 2003 Datasikkerhet vår 2002 Forelesning 2 Forelesning 2."— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding