Den sikre sonen, mest kjent som den sikre soveputen, betyr at man segregerer nettverket sitt med brannmurer, segregerer med forskjellige fysiske nettverk eller segregerer med virtuelle nettverk. Tanken bak soneinndelinger er at noen ressurser som behandler sensitive data, trenger ikke være tilgjengelig fra internett eller de er så virksomhetskritiske at de krever ekstra sikkerhet. Man splitter da nettverk opp i soner.
De vanligste sonene er DMZ, Administrasjon/Intern sone og Sikker Sone (ofte også kalt Produksjonssone). Det er mange forskjellige navn i bruk hos de forskjellige virksomheter, men å ha tre soner er ikke uvanlig. Èn for ressurser som skal være tilgjengelige fra internett (åpne data), en sone for ressurser som ikke er offentlige, men som ikke trenger ekstra beskyttelse (interne data) og en Sikker Sone som har virksomhetskritiske ressurser (sensitive data). Slike soner har tradisjonelt vært delt med brannmurer som sier hvem og hva som får reise inn og ut fra de forskjellige sonene. Dette har tradisjonelt sett betydd at alt som kjøres i en sone stoler på hverandre. Ergo; hvis en trusselagent klarer å komme seg forbi brannmuren har trusselagenten tilgang til det meste i den respektive sonen.
Utfordringer med sikre soner
Problemene kommer når flere og flere tjenester blir lagt til slik at det plutselig er mange som trenger å svippe en tur innom den sikre sonen, og det ender med at den sikre sonen som beskytter ditt helligste av det hellige minner mer om en sveitserost enn et trygt perimeter. Jo flere kanaler inn, jo flere angrepsvektorer.
Et annet kjent problem er at applikasjoner som kjører på innsiden av den sikre sonen ikke har tilstrekkelig med innebygde sikkerhetsmekanismer. Verre blir det hvis løsningene ikke har tilstrekkelig logging og monitorering. Da hjelper det lite om man har bestemt at alle flyttinger av data skal initieres fra innsiden, ettersom det er nettopp der angriperen sitter. Verre blir det når infrastrukturen i den sikre sonen ikke benytter TLS og virksomheten har uoversiktlig tilgangskontroll på sine menneskelige brukere og service kontoer, og ikke minst sine brannmuroppsett.
Guide: Slik utfører du sikkerhetstesting gjennom utviklingsløpet
Vil du lære mer om sikkerhet og sikkerhetstesting? I denne guiden gjennomgår sikkerhetsekspert Even Lysen hvordan du kan utføre sikkerhetstesting gjennom hele utviklingsløpet.
Hva er det Zero Trust gjør for oss?
Den snur trusselmodellen. Vi sier ikke lenger at bak her er det en sone vi stoler på. Tvert imot. Vi stoler ikke på noen ting og alle kald skal autentiseres og autoriseres. All kommunikasjon skal være kryptert og forventet. Rett og slett en whitelist strategi på alle kald mellom ressurser. For å få til dette må man bygge et distribuert system for håndheving av regler, i stedet for å ha sentrale punkter som styrer hva som er lov ute ved porten.
Zero Trust nettverk støtter opp under flere sikkerhetsprinsipper, slik som at sikkerhetsmekanismene ikke skal gjøre ressurser mer kompliserte å bruke og at mekanismene i seg selv skal være enkle å forvalte (noen har muligens noen innsigelser rundt denne vedrørende nøkkelhåndtering, men det kommer vi tilbake til).
Et eksempel på at zero trust forenkler er VPN. Hvilken rolle har VPN i en virksomhet som benytter Zero Trust arkitektur? Du trenger det ikke lenger. Alt er autentisert og autorisert allerede. Dette betyr at virksomheten din har forenklet tilgang til sine ressurser, økt sikkerheten, men også økt skaleringsmulighetene. Så det er bare gull og grønne skoger og vi er ferdig til fredag? Nei. For å komme i mål med en Zero Trust strategi så kreves det en god investering i starten. Både i form av kompetanse og penger, og tid er jo alltid en faktor som er avhenger av virksomhetens størrelse, kompleksitet, gammal moro og evne til å ta beslutninger. Nøkkelord for å lande et slikt prosjekt er automatisering og infrastructure-as-code.
Men hvis vi lander automatisering og infrastruktur som kode, da er det plankekjøring? Njaei.
Det er for øyeblikket svært få kommersielle produkter på markedet, og selv om det hadde fantes produkter rett fra hylla ville det krevd en god del konfigurering for å passe nettopp din infrastruktur og applikasjonsportefølje. De fleste i dag ruller derfor sine egne implementerte løsninger. Det positive når man først har dette er at sikkerhetsavdelingen har mye mer kontroll enn noen gang.
For eksempel ved sikkerhetshendelser. Det vil være enklere å ha oversikt over hvor hendelser inntreffer, og du vil ha en betydelig styrket mulighet til å respondere og låse ned. Utfordringen er hvor mange virksomheter er det som har så god oversikt over nettverket sitt og kompetanse til å implementere en så granulert arkitektur i hus at de faktisk kan få dette på plass? Alternativet er å hente inn noen konsulenter, men de skal jo ikke være der for alltid. Og det vil fortsatt være en forvaltningsjobb å gjøre når de reiser.
Zero-trust krever en kulturendring
En Zero-trust modell vil kreve en moden infrastruktur. Evnen til å definere og implementere policies, og ikke minst vekte de. Tilgangsstyring for eksterne, interne og tjenestebrukere. Dette vil påvirke hvordan man driver applikasjonsutvikling og forvaltning.
Zero-trust er langt ifra bare en teknisk løsning som koster litt tid og penger ved oppstart og så er det “lyckliga gatan” deretter. Dette er rett og slett snakk om en kulturendring og for mange vil det være et paradigmeskifte i hvordan man jobber.
Huff, dette høres dyrt, komplisert og tidkrevende ut, vil mange tenke. De tankene er riktig. Men hvis du tror du kommer unna dette så tar du feil. Du vil bli tvunget i denne retningen før eller siden uansett, og husk at det blir aldri billigere enn å begynne i dag. Dette må tas stegvis, og scopes til minileveranser. Det er ikke bare bare å få på plass zero trust når man har ti-tjue år gamle løsninger som sitter som støpt i klassisk infrastrukturmodell. Er man så heldig at man starter greenfield så er det enklere. Spesielt hvis man kjører kontainere på orkestreringsverktøy. Da finnes det faktisk noen gode hyllevareprodukter også.
Hvordan implementerer vi det her?
Zero-Trust bygger på følgende prinsipper:
- Nettverket er alltid fiendtlig
- Både interne og eksterne trusselaktører antas å være på nettverket hele tiden
- Nettverksinformasjon alene er ikke nok for å etablere tillit
- Hver eneste bruker (menneskelig, tjeneste), enhet, og nettverkskobling skal være autentisert og autorisert
- Kvantifiserbare sikkerhetspolicyer skal være dynamiske og komme fra så mange kilder som mulig for å kunne etablere sterkest mulig tillit.
Med disse prinsippene til å guide oss kartlegger vi (scoper) området vi ønsker å beskytte med en zero-trust modell. Som nevnt, innføringen må gå stegvis. Uansett hvilket område man velger og scoper vil det ha en eller flere av de følgende ressursene:
| Område | Tiltak |
| Data | Kryptering, Logisk/Fysisk separasjon, sporing, Integritet, tilgangsstyring |
| Applikasjoner | IAM / tilgangsstyring, input validering, output enkoding, sikkerhetsarkitektur, risikodrevet testing, ende-til-ende krypterte løsninger, logging |
| Enheter | Enhetshåndtering, AV/Anti-Malware, OS, kryptering, to-veis TLS |
| Nettverk | TLS, Proxier, Gateways, NAC, IDS, IPS, Logging og monitorering |
| Perimeter | Brannmur, DLP, Load Balancer, sertifikater, dedikerte linjer |
| Fysisk | Adgangskort, fysiske låser, overvåkningskameraer, murer |
| Policyer og Prosedyrer | Kode QA, DAST, sikkerhetskultur |
Områdene har en rekke forskjellige sikkerhetsmekanismer som støtter opp under både en zero-trust model og defence-in-depth prinsippet. Tiltakene på siden er eksempler og ikke en komplett liste. Vi har prinsippene for zero-trust og områdene vi skal innføre det på, og nå må vi kartlegge elementer som må være tilstede for at vi i det hele tatt kan starte et zero-trust arbeid. Følgende må være på plass:
- Least-privilege tilgangsstyring på alle ressurser som scope inkluderer
- Automatisering av autentisering og autorisasjon for både brukere og enheter
- Alle endepunkter skal valideres
- Logging og monitorering av data, applikasjoner, enheter og nettverk
- nivået på denne er helt avhengig av scope man setter og de tekniske mulighetene man har, men målet er å ha full logging og overvåkning på alle 7 OSI lagene
Når alt dette er på plass er det tid for å utvikle xero-trust policyene. En metode ofte brukt til dette kalles Kipling metoden. For hver datapakke (packet) vil vi vite:
- Hvem – Hvem skal ha tilgang til ressursen
- Hvilken – Hvilken applikasjon brukes for tilgang til ressursen
- Hvor – Hvor er pakken destinasjonen
- Hvorfor – Hvorfor prøver denne pakken å få tilgang til denne ressursen
- Hvordan – Hvordan får pakken tilgang til ressursen via applikasjonen
- Når – Når blir ressursen kontaktet
Men hva med skyen da?
Den gjør vel at jeg slipper det her? Skyen er jo sølvkula som gjør at jeg kan hoppe bukk over sikre soner og zero-trust? Du vet jo allerede at svaret er nei. Å flytte til skyen er ingen liten affære. Det er ikke bare å migrere over applikasjoner skrevet for èn type infrastruktur og putte de i en annen. I hvert fall ikke de applikasjonene man skrev for den sikre sonen som ikke hadde behov for egne sikkerhetsmekanismer. De nye applikasjonene som utvikles for skyen får det enklere, men bare fordi du kan legge til sikkerhetsmekanismene fra start, ikke at du kan ignorere de. Hva med brukerne? Migrere over en tjue år gammel AD struktur til Azure AD blir bare teknisk gjeld videreført til ny plattform. Men la oss si at alt er på plass. Happy path. Må man likevel se på zero trust og ta stilling til soner? Ja det må vi. Roller, autentisering, autorisering, logging og monitorering er et must i skyen. Tjenestene skal jo nettopp være tilgjengelig fra hvor som helst, og det kan hende man ønsker å kjøre sine mest sensitive ressurser på dedikert hardware (fysisk separert fra andre kunder), mens mer vanilla ressurser på bare logisk separert infrastruktur. Og der har vi to soner med to forskjellige angrepsflater og angrepsvektorer igjen. Fordelen med skyen er at du har de fleste verktøyene du trenger for å sette opp zero-trust klare til disposisjon uansett hvordan du legger opp arkitekturen din.
Kilder: