0TD02S_Informasjonssikkerhet_K09_Sikkerhetsmodeller - itnett/FTD02H-N GitHub Wiki

Kapittel 9: IAM - Identitets- og tilgangshåndtering

Introduksjon til Sikkerhetsmodeller

Sikkerhetsmodeller er essensielle for å forstå og implementere sikkerhetsarkitektur og -ingeniørkunst. Disse modellene gir et teoretisk rammeverk som hjelper oss å designe systemer som er sikre mot ulike typer trusler. Vi vil utforske flere historiske og moderne sikkerhetsmodeller, inkludert Bell-LaPadula, Biba, Brewer-Nash og Clark-Wilson modeller, samt hvordan de bidrar til IAM.

Bell-LaPadula Modellen

Bell-LaPadula Modellen ble utviklet av Dr. David Bell og Dr. Len LaPadula, og er fokusert på konfidensialitet. Den ble opprinnelig designet for USAs forsvarsdepartement for å håndheve sikkerhetspolicyer som beskytter konfidensialiteten til informasjon. Modellen bruker et gitterbasert system for å kategorisere data og brukere i forskjellige sikkerhetsnivåer.

Kjerneprinsipper:

  • Simple Security Property: En bruker med et bestemt sikkerhetsnivå kan kun lese data på sitt eget nivå eller lavere.
  • Star Property (Write-only): En bruker kan skrive data på sitt eget nivå eller høyere, men ikke lavere.
  • Strong Star Property: En bruker kan lese og skrive kun på sitt eget nivå.

Eksempel: En bruker med "Secret" sikkerhetsklarering kan lese data merket som "Secret" eller lavere, men kan ikke lese "Top Secret" data. Ved skriving kan brukeren kun skrive til "Secret" eller høyere nivåer for å unngå å lekke sensitiv informasjon til lavere sikkerhetsnivåer.

Biba Integritetsmodell

Biba Modellen, utviklet av Ken Biba, fokuserer på dataintegritet i stedet for konfidensialitet. Den sikrer at data ikke blir kompromittert av uautoriserte endringer. Biba-modellen er også gitterbasert og bruker tre operasjonelle moduser:

Kjerneprinsipper:

  • Simple Integrity Property (Read-only): En bruker kan lese data fra sitt nivå eller høyere.
  • Star Integrity Property (Write-only): En bruker kan skrive data til sitt nivå eller lavere.
  • Invocation Property: En bruker kan kun utføre operasjoner på sitt nivå eller lavere.

Eksempel: En bruker med et integritetsnivå som krever presisjon til to desimaler kan lese data fra sitt nivå eller høyere nøyaktighetsnivåer, men kan ikke lese mindre nøyaktige data. Ved skriving kan brukeren skrive til sitt nivå eller lavere for å unngå å kompromittere høyere nøyaktighetsdata.

Andre Sikkerhetsmodeller

Brewer-Nash Modellen (Chinese Wall)

Brewer-Nash Modellen, også kjent som "Chinese Wall", ble utviklet for å beskytte konfidensialiteten i revisjonsfirmaer. Modellen forhindrer interessekonflikter ved å sørge for at en revisor som jobber med en klient ikke kan jobbe med en konkurrent i samme periode.

Kjerneprinsipper:

  • Hindrer lekkasje av sensitiv informasjon mellom konkurrenter.
  • Opprettholder konfidensialitet ved å sette opp barrierer mellom data fra forskjellige klienter.

Clark-Wilson Integritetsmodell

Clark-Wilson Modellen, utviklet av Dr. David Clark og Dr. Dave Wilson, sikrer dataintegritet gjennom tre viktige konsepter: velformede transaksjoner, separasjon av plikter, og tredoblinger.

Kjerneprinsipper:

  • Velformede Transaksjoner: Alle systemer oppdateres konsekvent for å sikre at data er nøyaktige.
  • Separasjon av Plikter: En bruker kan kun få tilgang til et objekt gjennom et program som verifiserer nøyaktigheten av dataene.
  • Tredoblinger: En bruker har en relasjon til et program, og programmet har en relasjon til objektet.

Eksempel: En bruker kan kun endre data gjennom et program som utfører nødvendige sjekker for å sikre at dataene er korrekte før de lagres.

Graham-Denning Modellen

Graham-Denning Modellen setter ut formelle definisjoner av beskyttelsesregler, inkludert primitive rettigheter og reserverte ord. Modellen ble implementert gjennom Harrison-Ruzzo-Ullman (HRU) resultatene.

Kjerneprinsipper:

  • Definerer regler for tildeling og fjerning av rettigheter til brukere.
  • Bruker et sett med primitive operasjoner for å håndheve sikkerhet.

Implementering av IAM med Sikkerhetsmodeller

Web Identity Federation

Web Identity Federation tillater brukere å autentisere seg med AWS ved å bruke sine eksisterende identiteter fra leverandører som Amazon, Google, Facebook, eller OIDC-kompatible leverandører.

Fordeler:

  • Forbedret Sikkerhet: Unngår lagring av langsiktige legitimasjoner i applikasjoner.
  • Forenklet Brukerhåndtering: Ingen behov for å administrere brukeridentiteter innenfor AWS.
  • Utnyttelse av Eksisterende Identiteter: Brukere kan logge inn med sine eksisterende identiteter.

Amazon Cognito

Amazon Cognito hjelper med å legge til brukerregistrering, pålogging, og tilgangskontroll til web- og mobilapplikasjoner. Det anbefales av AWS for web identity federation.

Nøkkelfunksjoner:

  • User Pools: Administrerte kataloger for brukere.
  • Identity Pools: Fødererte identiteter som bytter eksterne legitimasjoner for midlertidige AWS-legitimasjoner.

AWS Directory Services

AWS tilbyr flere katalogtjenester for ulike behov:

  • Managed Microsoft AD: Bruker Microsoft Active Directory-instanser administrert av AWS.
  • AD Connector: Omdirigerer katalogarbeidsbelastninger til en eksisterende lokal Active Directory.
  • Simple AD: Begrensede funksjoner, egnet for småskala distribusjoner eller konseptbevis.

AWS Organizations og Service Control Policies (SCPs)

AWS Organizations muliggjør sentralisert administrasjon av flere AWS-kontoer.

Service Control Policies (SCPs) brukes til å håndheve tillatelser på tvers av en organisasjon. SCPs overstyrer IAM-tillatelser på lavere nivå.

Kjernepunkter:

  • SCPs er kostnadseffektive og kan brukes på alle kontoer, spesifikke kontoer eller organisatoriske enheter.
  • OUs er nyttige for overholdelse og separering av miljøer.

Eksempler og Besvarelse av Oppgaver

Oppgave 1: Forklar hvordan Bell-LaPadula-modellen håndhever konfidensialitet.

Bell-LaPadula-modellen håndhever konfidensialitet gjennom Simple Security Property (lesing kun på eget eller lavere nivå), Star Property (skriving kun på eget eller høyere nivå), og Strong Star Property (lesing og skriving kun på eget nivå).

Oppgave 2: Hvordan sikrer Biba-modellen dataintegritet?

Biba-modellen sikrer dataintegritet ved å tillate lesing av data fra samme nivå eller høyere, og skriving til samme nivå eller lavere. Dette hindrer mindre nøyaktige data i å kontaminere høyere nøyaktighetsdata.

Oppgave 3: Hva er fordelene med Web Identity Federation i AWS?

Web Identity Federation forbedrer sikkerhet ved å unngå lagring av langsiktige legitimasjoner, forenkler brukerhåndtering og tillater brukere å logge inn med eksisterende identiteter.

Referanser og Videre Lesing

Select System Controls

Introduksjon til Sikkerhetsarkitektur og Ingeniørkunst

Sikkerhetsarkitektur og ingeniørkunst kombinerer vitenskap og kunst for å designe sikre systemer. Målet er å møte både nåværende og fremtidige forretningsbehov, men utfordringer som begrenset tid og budsjett krever at vi tilpasser våre løsninger. Arkitektur fokuserer på design, mens ingeniørkunst håndterer implementering og konfigurasjon av valgte løsninger.

Kravinnsamling

For å designe sikre systemer, må vi først forstå kundens behov. Dette krever samarbeid med forretningen for å identifisere sikkerhetskravene. Vi må unngå "scope creep", der prosjektet vokser utover det opprinnelige omfanget, noe som kan føre til overskridelse av budsjett og tid.

Valg av Kontroller

Kontrollene vi velger må baseres på krav, risiko og lover. Noen kontroller kan oppfylles av eksterne systemer, som backup-strøm, og trenger ikke bygges inn i systemdesignet. Det er viktig å finne balanse mellom kostnad, ytelse og pålitelighet når vi velger kontroller.

Baseline og Segmentering

Vi starter med å velge en baseline som representerer minimum akseptabelt sikkerhetsnivå. Deretter segmenterer vi områder som krever høyere sikkerhet enn baselinen. Dette innebærer å kontrollere trafikkflyten mellom segmenterte områder for å sikre at personer i mindre beskyttede områder ikke får tilgang til mer beskyttede områder.

Trusted Computing Base (TCB)

Trusted Computing Base (TCB) representerer området vi er ansvarlige for. I gamle dager var TCB enklere å definere med en klar sikkerhetsperimeter. I dag, med teknologi som USB og trådløse nettverk, er det mer utfordrende å definere sikkerhetsperimeteret.

Trusted Platform Module (TPM)

Trusted Platform Module (TPM) er en chip som utfører sikkerhetsoperasjoner som kryptering. TPM sikrer også attesterte oppstarter, noe som hindrer uautoriserte endringer under systemoppstart. TPM kan også autentisere noder ved å verifisere at riktige enheter er tilkoblet systemet.

Kompenserende Kontroller

Når vi ikke kan implementere ønsket sikkerhet på grunn av tekniske begrensninger, bruker vi kompenserende kontroller. Dette kan være administrative eller tekniske kontroller som adresserer svakheter. For eksempel kan økt revisjon og overvåking være kompenserende kontroller for å møte sikkerhetskrav.

Evaluering av Systemdesign

Vi gjennomfører sikkerhetssystemdesignvurderinger for å sikre at systemet oppfyller kravene til tilgjengelighet, pålitelighet og sikkerhet. Dette inkluderer å identifisere enkeltpunktsfeil og enkeltpunktskompromisser, og implementere lagvis forsvar og forsvar i dybden.

Kilder og Ressurser

For mer informasjon om sikkerhetsarkitektur og ingeniørkunst, kan du se følgende ressurser:

Eksempler og Besvarelse av Oppgaver

Oppgave 1: Hva er Trusted Computing Base (TCB)?

Trusted Computing Base (TCB) er det området av et system som er ansvarlig for å opprettholde sikkerheten. TCB inkluderer maskinvare, programvare og kontroller som håndhever sikkerhetspolicyer.

Oppgave 2: Hva er kompenserende kontroller og gi et eksempel?

Kompenserende kontroller er alternative kontroller som brukes når standard sikkerhetskontroller ikke kan implementeres. For eksempel, hvis et system ikke kan kryptere data, kan økt overvåking av tilgang til dataene fungere som en kompenserende kontroll.

Oppgave 3: Hvorfor er segmentering viktig i sikkerhetsarkitektur?

Segmentering er viktig fordi det hindrer uautorisert tilgang mellom områder med ulik sikkerhetsnivå. Ved å segmentere nettverket kan vi sikre at sensitive data ikke er tilgjengelige for brukere i mindre beskyttede områder.

Sammendrag

Sikkerhetsarkitektur og ingeniørkunst krever en balanse mellom vitenskap og kreativitet for å møte forretningsbehov. Gjennom nøye kravinnsamling, valg av passende kontroller og segmentering kan vi designe systemer som opprettholder sikkerhet og pålitelighet. Det er viktig å kontinuerlig evaluere og forbedre systemdesign for å sikre at de oppfyller sikkerhetskravene og støtter forretningsmålene.

Secure Access

En essensiell del av hvordan vi designer og arkitekterer våre systemer er å sikre at vi håndhever tilgangstillatelser. Vi må sikre tilgang slik at kun autoriserte personer kan utføre autoriserte funksjoner. For å forstå dette, må vi se på forholdet mellom et subjekt (bruker) og et objekt (ressurs) hvor et subjekt ber om tilgang og objektet gir den nødvendige informasjonen eller ressursen avhengig av reglene satt av eieren av objektet.

Referansemonitor

Konseptet med en referansemonitor er sentralt i hvordan vi styrer tilgangskontroll. Selv om vi ikke fysisk har en referansemonitor, er det en abstrakt idé om hvordan vi medierer en forespørsel fra et subjekt til et objekt. For å være effektiv, må en referansemonitor være:

  • Manipuleringssikker: Subjekter skal ikke kunne endre sine egne tillatelser. Kun dataeieren kan gjøre dette gjennom separasjon av plikter.
  • Medierende: Den må håndtere alle tilgangsforespørsler, ikke bare sporadisk.
  • Verifiserbar: Den må være liten nok til å kunne testes for å sikre at tilgangskontrollene fungerer riktig.

Et praktisk eksempel på en referansemonitor kan være en sikkerhetsvakt i en bygning som kontrollerer hvem som får adgang basert på reglene gitt av bygningseieren.

Subjekt og Objekt

  • Subjekt: En entitet som ber om en tjeneste, for eksempel en bruker, prosess eller program. Subjekter har nivåer av privilegier eller tillit, ofte basert på klareringsnivåer som hemmelig eller topphemmelig.
  • Objekt: En passiv enhet som venter på å bli forespurt, som filer, programmer, prosesser eller databaser. Objekter har klassifikasjoner som bestemmes av eieren, og disse klassifikasjonene er indikert ved merkelapper.

Trusted Computing Base (TCB)

Trusted Computing Base (TCB) refererer til det området innenfor sikkerhetsperimeteret som er ansvarlig for sikkerhet. TCB inkluderer fire grunnleggende funksjoner:

  1. Aktivering av prosesser
  2. Veksling mellom domener
  3. Beskyttelse av minne
  4. Kontroll over inn- og utdataoperasjoner

Trusted Platform Module (TPM)

Trusted Platform Module (TPM) er en chip eller programvare som utfører sikkerhetsoperasjoner som kryptering og autentisering av noder. TPM støtter attesterte oppstarter, noe som sikrer at systemet starter pålitelig uten uautoriserte endringer.

Kompenserende Kontroller

Kompenserende kontroller brukes når vi ikke kan implementere ønskede sikkerhetskontroller på grunn av tekniske begrensninger. Disse kontrollene adresserer svakheter og kan være tekniske, administrative eller fysiske. Eksempler inkluderer økt revisjon, lagdelte forsvar og tamper-proof enheter.

Evaluation Criteria

Når vi bygger sikre systemer, må vi bruke sikre komponenter. Evaluasjonskriterier hjelper oss å vurdere sikkerheten til produktene vi kjøper. Noen viktige kriterier inkluderer:

  • Orange Book (TCSEC): Fokusert på konfidensialitet, brukt av US Department of Defense.
  • ITSEC: Kombinerte britiske, franske og tyske kriterier, som evaluerte funksjonaliteten til produkter.
  • Common Criteria (ISO 15408): Internasjonal standard for evaluering av IT-produkter, som gir en felles måte å teste sikkerheten på.

Evaluation Assurance Levels (EAL)

EAL refererer til graden av testing et produkt har gjennomgått:

  • EAL1: Funksjonell testing, lav intensitet.
  • EAL2: Strukturert testing.
  • EAL7: Høyeste nivå av testing, som sikrer at produktet er grundig testet gjennom hele design, utvikling, produksjon og distribusjonsprosessen.

Key Points Review

Vi må adressere sikkerhet i alle komponenter av våre systemer. Evaluasjonskriterier gir en forsikring om at sikkerhetstesting er utført på komponentene. Sikkerhetstesting er avgjørende for å sikre at våre systemer oppfyller sikkerhetskravene og beskytter sensitiv informasjon mot trusler og sårbarheter.

Eksterne Kilder og Ressurser

For mer informasjon om sikkerhetsarkitektur og ingeniørkunst, se følgende ressurser:

Ved å følge disse prinsippene og bruke evaluerte komponenter, kan vi designe og implementere sikre systemer som oppfyller forretningskravene og beskytter mot trusler.

Memory Security

Memory Architecture

Minnesikkerhet er en viktig del av vår sikkerhetsarkitektur. Det finnes to grunnleggende modeller for minnearkitektur: von Neumann-arkitekturen og Harvard-arkitekturen. Von Neumann-arkitekturen brukes i de fleste datamaskiner i dag, mens Harvard-arkitekturen ofte brukes i innebygde systemer og signalbehandlingssystemer.

Buffer Overflow

En vanlig sikkerhetsutfordring er buffer overflow, som oppstår når inndata overstiger den tildelte minnebufferen. For eksempel, hvis et passordfelt er ment å ta imot åtte tegn, men brukeren skriver inn flere tegn, kan dette overskrive tilstøtende minneområder. Dette kan føre til vilkårlig kodekjøring og datakorrupsjon. Buffer overflows har vært årsaken til mange sikkerhetsbrudd opp gjennom årene.

Data Execution Prevention (DEP)

Data Execution Prevention (DEP) ble innført for å redusere risikoen for buffer overflow-angrep. DEP sørger for at dataområder ikke kan inneholde kjørbar kode. Dette betyr at hvis inndata overskriver en dataområde, kan ikke denne dataen kjøres som kode.

Address Space Layout Randomization (ASLR)

Address Space Layout Randomization (ASLR) er en annen teknikk for å håndtere buffer overflow-problemer. ASLR randomiserer plasseringen av minneelementer, slik at det blir vanskeligere for angripere å forutsi hvor de kan injisere skadelig kode. Dette gjør minnebaserte angrep mindre effektive.

Memory Leakage

Memory leakage oppstår når minne ikke frigjøres etter at en oppgave er fullført. Dette kan føre til at systemet sakte bruker opp tilgjengelig minne, noe som resulterer i redusert ytelse og potensielt systemkrasj. Effektiv minnehåndtering, inkludert "garbage collection", er avgjørende for å forhindre memory leakage.

Ring Protection

Ringbeskyttelse gir isolasjon mellom ulike prosessnivåer. Dette konseptet ble introdusert på 1970-tallet med Multics. Det innebærer å plassere kjernen i systemet i den innerste ringen (ring 0), mens mindre privilegerte prosesser plasseres i ytre ringer. For eksempel plasseres brukerapplikasjoner i ring 3, som gir lavere privilegier og dermed reduserer risikoen for at feil i en applikasjon påvirker hele systemet.

Privilege Escalation

Privilegiereskalering er en risiko hvor en applikasjon bruker en driver for å få tilgang til en I/O-enhet og dermed kan oppnå høyere privilegier. Dette kan føre til at skadelig kode får tilgang til kjernenivået i systemet, noe som er svært farlig.

Trojan Horses

Trojanere utnytter ofte privilegiereskalering for å infisere systemet på kjernenivå. Ved å holde applikasjoner i lavere privilegerte ringer, kan vi redusere risikoen for at en trojaner kan kompromittere hele systemet.

Designing Encryption

Encryption in Storage

Kryptering brukes for å beskytte data både når det lagres og når det overføres. Dette gir tre primære fordeler:

  1. Konfidensialitet: Holder informasjon hemmelig.
  2. Integritet: Sikrer at data ikke har blitt endret på en uautorisert måte.
  3. Autentisering: Bekrefter identiteten til personer eller enheter som vi kommuniserer med, for eksempel gjennom digitale signaturer.

Kryptering kan brukes på ulike nivåer:

  • Full disk-kryptering beskytter alle data på en harddisk.
  • Kryptering av individuelle filer sikrer spesifikke filer mot uautorisert tilgang.
  • Kryptering av arkiverte data beskytter data som flyttes til langtidslagring.
  • Kryptering av sikkerhetskopier beskytter sikkerhetskopierte data, spesielt når de lagres eksternt.

Encryption in Transmission

Når data overføres, er kryptering viktig for å beskytte sensitiv informasjon:

  • Intern nettverk: Kryptering beskytter data som overføres innenfor en organisasjon.
  • Ekstern nettverk: Kryptering beskytter data som overføres over internett, som HTTPS for nettsider og IPsec for nettverkslag.

Trusted Platform Module (TPM)

En Trusted Platform Module (TPM) er en chip eller programvare som gir kryptering og autentisering. TPM kan beskytte data ved å inkludere krypteringsnøkler og støtte en attestert oppstartsprosess, noe som sikrer at systemet starter pålitelig uten uautoriserte endringer.

Evaluation Criteria

Common Criteria

Evaluasjonskriterier hjelper oss å sikre at komponentene vi bruker i våre systemer er trygge. Noen viktige kriterier inkluderer:

  • Orange Book (TCSEC): Fokusert på konfidensialitet for US Department of Defense.
  • ITSEC: Evaluerte funksjonaliteten til produkter fra Storbritannia, Frankrike og Tyskland.
  • Common Criteria (ISO 15408): En internasjonal standard for evaluering av IT-produkter, som gir en felles måte å teste sikkerheten på.

Evaluation Assurance Levels (EAL)

EAL refererer til graden av testing et produkt har gjennomgått:

  • EAL1: Funksjonell testing, lav intensitet.
  • EAL2: Strukturert testing.
  • EAL7: Høyeste nivå av testing, som sikrer at produktet er grundig testet gjennom hele design, utvikling, produksjon og distribusjonsprosessen.

Conclusion

Sikker minnehåndtering og riktig implementering av kryptering er essensielle for å beskytte data og opprettholde systemets integritet og tilgjengelighet. Ved å følge disse prinsippene kan vi sikre at våre systemer er robuste mot angrep og sårbarheter. For mer informasjon, se følgende ressurser:

Ved å bruke evaluerte komponenter og implementere sikkerhetstiltak på alle nivåer i systemet, kan vi sikre at våre systemer oppfyller sikkerhetskravene og beskytter mot trusler og sårbarheter.

Assessment of Traditional Security Architectures

Når vi vurderer tradisjonelle sikkerhetsarkitekturer, er det viktig å forstå at arkitektur ofte er utenfor vår direkte kontroll. Den er designet av system- og nettverksdesignere, og det finnes mange ulike typer arkitekturer. Ingen arkitektonisk stil er perfekt, og derfor må vi lære å sikre den arkitekturen vi har. Mange organisasjoner har en blanding av forskjellige arkitekturer som har utviklet seg over tid, men til tross for dette har de fleste samme sikkerhetsbekymringer.

Tradisjonelle IT-systemer

Tradisjonelle IT-systemer fokuserte ofte på en sentralisert modell. For eksempel, mainframe-datamaskiner var et godt eksempel på sentraliserte systemer der alt ble prosessert på ett sted. Brukerne koblet seg til disse systemene gjennom enkle terminaler, og sikkerheten var enklere da det bare var nødvendig med fysisk sikkerhet for å beskytte rommet der systemet befant seg. I dag ser vi en lignende tilnærming i form av skyen, der data prosesseres og lagres sentralt.

Fysiske sikkerhetstiltak

Sikkerheten til sentraliserte systemer er sterkt avhengig av fysisk sikkerhet, som inkluderer oppvarming, ventilasjon, luftkondisjonering, strømforsyning og brannslukking. Adgangskontroll er også kritisk for å sikre at kun autoriserte personer har tilgang til sensitive områder og data.

Infrastruktur

En stabil infrastruktur er nødvendig for å sikre kontinuerlig drift av IT-systemer. Dette inkluderer pålitelig strømforsyning med backup-løsninger som UPS, samt effektiv klimakontroll for å sikre at systemene opererer innenfor trygge temperatur- og fuktighetsnivåer.

Sentralisert vs. Desentralisert tilgangskontroll

Sentralisert tilgangskontroll gir fordeler som konsistent administrasjon og overvåking, samt enklere måling og håndheving av samsvar. Desentralisert tilgangskontroll kan føre til inkonsekvent administrasjon og sikkerhetsproblemer på grunn av manglende standardisering.

Skalerbarhet

En viktig egenskap ved arkitektur er skalerbarhet, evnen til å tilpasse seg endrede krav. Dette innebærer at systemer må kunne håndtere økt eller redusert kapasitet etter behov, og at vi må planlegge for fremtidige behov.

Distribuerte systemer

Distribuerte systemer har en høyere avhengighet av sikkerheten til endepunkt-enheter og nettverket som forbinder dem. Sikkerhet for endepunkter og bruk av virtuelle private nettverk (VPN) er avgjørende for å sikre pålitelige kommunikasjoner mellom servere og klienter.

Nettverkssegmentering

Nettverkssegmentering bidrar til å beskytte mot inntrengere ved å opprette separate nettverkssoner. Dette kan inkludere ekstranett som gir en kontrollert tilgang til eksterne brukere uten å gi dem direkte tilgang til det interne nettverket.

Arkitektoniske sikkerhetsrisikoer

Noen av de vanlige sikkerhetsrisikoene i tradisjonelle IT-systemer inkluderer enkeltpunkter for feil, muligheter for å omgå kontroller, og faren for privilegieeskalering. Det er viktig å sikre at applikasjoner kan kjøre med lavere privilegier enn de som brukes under utvikling.

Edge Computing

Edge computing flytter data og prosessering nærmere brukerne, noe som forbedrer responstiden og reduserer belastningen på sentrale systemer. Dette er spesielt nyttig for distribusjon av innhold og oppdateringer. På den annen side må vi være oppmerksomme på sikkerhet ved synkronisering av data og administrasjon av patches over mange forskjellige steder.

Evaluering av distribuerte systemer

Distribuerte systemer kan introdusere inkonsistenser og redusert kontroll. Det er viktig å sikre at data er riktig synkronisert og at nettverksfeil ikke forårsaker tap av tilgang. Distribusjon av oppdateringer og patches til mange brukere krever god planlegging for å sikre at alle kjører samme versjon.

Oppsummering

Uansett hvilken arkitektur som velges, må sikkerhetsansvarlige gjenkjenne risikoene knyttet til hver arkitektur og implementere passende sikkerhetstiltak. Dette inkluderer å forstå behovene til både dagens og fremtidens systemer, samt å kunne tilpasse sikkerhetstiltak til endrede krav og trusler.

Assessment of Non-traditional Security Architectures

Velkommen til dette kurset om sikkerhetsarkitektur og ingeniørfag: Forstå designprinsippene for CISSP. Her skal vi se på vurdering av ikke-tradisjonelle sikkerhetsarkitekturer. Dette er et interessant emne fordi det representerer en stor endring fra det vi så for 10, 15, 20 år siden. I dag har vi mange enheter tilkoblet organisasjoners nettverk som tradisjonelt sett var utenfor IT-avdelingens kontroll. Disse enhetene utvider omfanget for risiko- og sikkerhetsstyring.

Eksempler på ikke-tradisjonelle arkitekturer

Eksempler på ikke-tradisjonelle IT-arkitekturer inkluderer bygningsstyringssystemer og varme-, ventilasjons- og klimaanlegg (HVAC) som nå er koblet til nettverkene fordi de trenger å kommunisere med leverandøren for vedlikehold. Industrielle kontrollsystemer (ICS) og SCADA-systemer (Supervisory Control and Data Acquisition) er også tilkoblet og utgjør potensielle bakdører til våre nettverk.

Risiko og utfordringer

En av de største utfordringene med disse systemene er at de åpner bakdører eller sideinnganger til nettverkene våre. Et godt eksempel er en termostat i et akvarium på et casino som ble kompromittert og brukt som inngangspunkt for å få tilgang til sensitive data. Slike tilfeller illustrerer hvor viktig det er å sikre disse enhetene, selv om de ikke tradisjonelt har vært en del av IT-avdelingens ansvarsområde.

Sikring av innebygde enheter

Sikkerhet for innebygde enheter starter ofte med nettverkssegmentering. Det er viktig å ha separasjon mellom bygningsstyringssystemer og resten av nettverket. Enhetene bør gjøres manipulasjonssikre, for eksempel ved å ødelegge kryptografiske operasjoner hvis enheten blir åpnet. Fysisk adgangskontroll er også viktig, og enheter bør være bak lås og nøkkel.

Autentisering og kryptering

Bruk av multifaktorautentisering (MFA) for admin-tilgang og nodautentisering gjennom MAC- og IP-adresser eller TPM (Trusted Platform Module) bidrar til å sikre enhetene. Kommunikasjon mellom enhetene bør alltid være kryptert for å forhindre avlytting og spoofing.

Vedlikehold og administrasjon

Riktig vedlikehold av disse enhetene er avgjørende. Dette innebærer å holde oversikt over hvilke enheter som er koblet til nettverket, hvor de befinner seg, og hvem som administrerer dem. Protokoller som SNMP (Simple Network Management Protocol) bør oppgraderes til sikre versjoner, og enhetene må jevnlig få programvareoppdateringer og patcher.

Høyytelsessystemer

Høyytelsessystemer brukes til komplekse beregninger som seismiske kartlegginger, væskedynamikk og finansielle risikomodeller. Disse systemene kan være basert på superdatamaskiner, grid computing eller høyytelses databehandling i skyen. Sikkerhets- og personvernhensyn er kritiske, spesielt ved dataoverføring mellom systemer for å sikre integriteten av dataene.

Sammendrag

Den store mengden nettverkstilkoblede enheter i dag, mange utenfor den tradisjonelle IT-modellen, utgjør en ny risiko for våre IT-systemer og -nettverk. Problemet er at mange av disse enhetene er bygget uten tilstrekkelige sikkerhetskontroller, noe som gjør dem sårbare for kompromittering. Det er viktig å sikre at vi har tilstrekkelig oversikt og kontroll over disse enhetene for å beskytte mot potensielle trusler.

Assessment of Cloud Security Architectures

Definisjon av skybasert databehandling

Skybasert databehandling er definert av NIST Special Publication 800-145 som en modell for å muliggjøre allestedsnærværende, praktisk, behovsbasert nettverkstilgang til en delt pool av konfigurerbare databehandlingsressurser (som nettverk, servere, lagring, applikasjoner og tjenester) som raskt kan leveres og frigjøres med minimal administrasjonsinnsats eller interaksjon med tjenesteleverandør. Skyen består av fem essensielle egenskaper, tre tjenestemodeller og fire distribusjonsmodeller.

Fem essensielle egenskaper

  1. On-demand selvbetjening: Brukere kan automatisk skaffe seg databehandlingskapasitet som servertid og nettverkslagring uten menneskelig interaksjon med hver tjenesteleverandør.
  2. Bred nettverkstilgang: Ressurser er tilgjengelige over nettverket og kan nås via standardiserte mekanismer som fremmer bruk av forskjellige tynn- eller tykkklientplattformer (f.eks. mobiltelefoner, nettbrett, bærbare datamaskiner og arbeidsstasjoner).
  3. Ressurspooling: Leverandørens databehandlingsressurser samles for å tjene flere forbrukere ved hjelp av en flerbrukermodell, med forskjellige fysiske og virtuelle ressurser dynamisk tildelt og omfordelt etter forbrukerens behov.
  4. Rask elastisitet: Ressurser kan leveres elastisk, i noen tilfeller automatisk, for å raskt skalere opp eller ned i henhold til etterspørselen.
  5. Målt tjeneste: Skyssystemer styrer og optimaliserer automatisk ressursbruk ved å bruke en målekapabilitet på et passende nivå av abstraksjon for den typen tjeneste (f.eks. lagring, prosessorkraft, båndbredde og aktive brukerkontoer).

Tjenestemodeller

  1. Software-as-a-Service (SaaS): Programvaren leveres over internett og er tilgjengelig via en nettleser. Eksempler inkluderer Google Workspace og Microsoft Office 365.
  2. Platform-as-a-Service (PaaS): Tilbyr en plattform som lar kunder utvikle, kjøre og administrere applikasjoner uten å håndtere infrastrukturen. Eksempler inkluderer Google App Engine og Microsoft Azure.
  3. Infrastructure-as-a-Service (IaaS): Tilbyr databehandlingsressurser som virtualiserte servere, lagring og nettverk over internett. Eksempler inkluderer Amazon Web Services (AWS) og Google Cloud Platform (GCP).

Distribusjonsmodeller

  1. Private Cloud: Driftet for én enkelt organisasjon, enten administrert internt eller av en tredjepart.
  2. Public Cloud: Tilgjengelig for allmennheten eller en stor industriell gruppe og administreres av en tredjepart.
  3. Community Cloud: Delt infrastruktur mellom flere organisasjoner fra en bestemt samfunn med felles bekymringer.
  4. Hybrid Cloud: En kombinasjon av to eller flere skyer (privat, samfunn eller offentlig) som forblir unike enheter, men er bundet sammen av standardiserte eller proprietære teknologier.

Sikkerhetsansvar

Skyen innebærer et delt sikkerhetsansvar mellom skyforbrukeren og skytilbyderen. Dette krever klare service level agreements (SLAer) og kontrakter for å sikre forståelse av ansvar, omfang og ansvarlighet.

Delt sikkerhetsmodell

  • Data Classification and Accountability: Alltid skyforbrukerens ansvar.
  • Physical Security: Skytilbyderens ansvar.
  • Client and Endpoint Protection: Delt ansvar.
  • Identity and Access Management (IAM): Delt ansvar hvor skyforbrukeren kontrollerer tilgang for sine ansatte, og skytilbyderen styrer tilgang for sine administratorer.
  • Applications and Infrastructure Management: Avhenger av tjenestemodellen (SaaS, PaaS, IaaS).

Nøkkelelementer

  • Service Level Agreements (SLAer): Må spesifisere ansvar og sikkerhetskontroller.
  • Data Location: Hvor dataene behandles og lagres, og hvordan backup håndteres.
  • Compliance: Sørge for at skytilbyderen følger gjeldende lover og reguleringer.
  • Incident Response: Avklare prosedyrer for hendelsesrespons og undersøkelse.

Vurdering av risikofaktorer

Skyimplementasjoner innebærer nye sikkerhetsutfordringer. For å håndtere disse utfordringene effektivt, må sikkerhetsansvar være klart definert, og det må være tilstrekkelige sikkerhetskontroller på plass for å beskytte dataene og systemene mot potensielle trusler. Det er viktig å velge skytilbydere med en solid økonomisk status og etablere klare regler for datahåndtering og tilgangskontroll.

Assessment of Cloud Implementations

Tradisjonelle vs. Moderne Skyarkitekturer

Tradisjonelle monolitiske arkitekturer har blitt erstattet av mikrotjenester. Monolitiske arkitekturer samlet mange tjenester i én applikasjon, noe som gjorde det utfordrende å endre én tjeneste uten å påvirke andre. Mikrotjenester er derimot uavhengige, løst koblede tjenester som kan endres uten å påvirke andre deler av systemet, noe som gir større fleksibilitet og skalerbarhet.

Serverløse Systemer

Serverløse systemer refererer til arkitekturer der applikasjoner kjører på en delt pool av servere, administrert av skyleverandøren. Dette inkluderer patching, ressursallokering og failover, og gir en mer effektiv utnyttelse av ressurser uten behov for dedikerte servere.

Virtualisering

Virtualisering er kjernen i mange skytjenester, og det skiller seg fra tradisjonelle arkitekturer ved å legge til et hypervisor-lag mellom maskinvaren og operativsystemet, noe som muliggjør kjøring av flere virtuelle maskiner (VM-er) på samme maskinvare. Dette gir sikkerhetsfordeler som isolasjon og enkel gjenoppretting, men krever også nøye administrasjon for å unngå VM-hopping og VM-sprawl.

Containere

Containere skiller seg fra VM-er ved at de deler operativsystemkjernen, men hver container inneholder alt som trengs for å kjøre applikasjonen, inkludert biblioteker og konfigurasjonsfiler. Containere er mer ressurseffektive og raskere å spinne opp enn VM-er. Sikkerheten i containere sikres ved korrekt konfigurasjon, signering, og bruk av hvitelister for tillatte prosesser.

Nøkkelpunkter

  • Mikrotjenester gir fleksibilitet og skalerbarhet ved å være uavhengige enheter.
  • Serverløse systemer abstraherer serveradministrasjon og optimaliserer ressursbruk.
  • Virtualisering muliggjør effektiv bruk av maskinvare ved å kjøre flere VM-er, men krever god administrasjon for å unngå sikkerhetsproblemer.
  • Containere gir ressursbesparelser og rask distribusjon, men krever sikkerhetsmekanismer som signering og adferdsanalyse for å opprettholde sikkerheten.

Ved vurdering av skyimplementasjoner må sikkerhetsansvar tydelig defineres mellom skyforbrukeren og skyleverandøren for å unngå sikkerhetsgap og sikre at alle nødvendige kontroller er på plass for å beskytte data og systemer.