Zero Trust: – Du kan ikke basere deg bare på én leverandør for å løse det

«Zero Trust», eller «Zero Trust Networking» (ZTN) er et begrep og en tilnærming til IT-sikkerhet som har fått økt oppmerksomhet de siste årene, selv om det egentlig ikke er noe helt nytt konsept.

Begrepet Zero Trust og de grunnleggende konseptene i dette, skal ha blitt etablert av den tidligere Forrester-analytikeren John Kindervag i 2010, men som vi snart kommer tilbake til, startet diskusjonene allerede flere år før dette.

Google er kanskje den aktøren som har fått størst oppmerksomhet for sin implementering av Zero Trust. Dette skjedde som et resultat av «Operation Aurora», det kinesiske cyberangrepet som rammet blant annet Google i slutten av 2009.

Googles implementering kalles for BeyondCorp. Hensikten var fra starten av å gjøre det mulig for alle Google-ansatte å kunne jobbe fra usikre nett uten å bruke VPN (Virtual Private Network).

GitLab

Et annet selskap som har valgt å implementere Zero Trust, er GitLab. Selskapet omtaler seg selv som leverandør av en åpen kildekode-basert, ende-til-ende DevOps-plattform for programvareutvikling. Selskapet ble etablert i 2011 og er en konkurrent til Microsoft-eide GitHub. GitLab-plattformen har millioner av brukere, hvorav mer enn 800.000 betaler for tjenestene.

GitLab hadde i begynnelsen av februar 1175 ansatte fordelt på 66 ulike land, inkludert én utvikler i Norge. IT-systemene til GitLab befinner seg i nettskyen, og selskapet omtaler seg selv som et 100 prosent fjernarbeid-selskap. Det har ingen kontorer.

Mark Loveless er senior sikkerhetsforsker i GitLab. Han har bakgrunn som hacker med ulike farger på hatten, har dyp innsikt i GitLab Zero Trust-arbeid og har både skrevet og holdt foredrag om dette emnet.

Mange ulike tolkninger

I et e-postintervju med digi.no forteller Loveless om erfaringene GitLab har gjort så langt under denne prosessen, som på ingen måte er fullført. Vi innledet intervjuet med å be ham komme med sin tolkning av hva Zero Trust Networking er. Loveless har nemlig tidligere uttalt at alle leverandører som tilbyr ZTN-løsninger, har sin egen tolkning.

– Min tolkning er sentrert rundt det følgende: bekreft at brukerne er den de sier at de er, bekreft at enheten som brukeren benytter ikke bare er en kjent (bedrifts-)enhet, men at den er skikkelig sikret og trygt konfigurert. Identifiser dataene brukeren og enheten forsøker å aksessere, kontroller om aksessen er tillatt, legg til ethvert krav spesifikt for dataene som aksesseres (sted, tidspunkt, etc.), tillat tilgang til dataene kun dersom samtlige krav er tilfredsstilt. Det er det hele, forteller Loveless.

– For noen er dette en ganske vid tolkning, men virkeligheten er den mer kompleks enn den ser ut til å være, uten å oppgi åpenbare ting som yttergrense, brannmurer, klarert nettverk og VPN. Jeg nevnte heller ikke autentisering. Dette er implisitt siden jeg må kunne bekrefte brukerens identitet, men noe av aksessen til data skjer etter den første autentiseringen, så ZTN må ta hensyn til dette, skriver Loveless.

Hvilke problemer er det meningen ZTN skal løse?

– Hovedproblemet som det skal løse, er å gi tilgang i situasjoner hvor du ikke kan stole på nettverket som brukeren kommer inn med, eller at du bare har en vag anelse om hvor brukeren er, men behøver å gi tilgang. Dette problemet ble diskutert i akademiske kretser og under konferanser så tidlig som i 2002, og jeg deltok aktivt i noen av disse diskusjonene. Yttergrensestrukturen til brannmurer, med VPN, løste ikke problemet. Faktisk ga det et slags falskt håp, siden administratorer trodde at de sikret omgivelsene sine, men fortsatt opplevde sikkerhetsbrudd.

Er det noen forventninger til ZTN som det ikke kan innfri?

– Dette er ingen løsning hvor du gjør ting én gang og så er du ferdig. Du kan ikke implementere den og deretter bare glemme den. Løsningen er nødt til å være en del av en løpende prosess.

Hvem bør, og hvem (om noen) bør ikke vurdere å implementere ZTN?

– Dersom du har et frakoblet («air-gapped») nettverk uten forbindelser til den ytre verdenen, med fullstendig tillit til alle som har tilgang til nettverket, er det ikke behov for ZTN. Men dersom du har et miljø hvor du har mobile brukere eller tillater tilgang til og fra utsiden via en eller annen kanal (web, e-post, etc.), bør du vurdere ZTN.

Ingen ferdig pakkeløsning

Mark Loveless har under foredrag sagt at uansett hva leverandørene forteller deg, så er det ingen som har en komplett ZTN-løsning.

Betyr dette at man som organisasjon må lage sin egen pakke, tilpasset egne behov?

– Det betyr at du ikke kan basere deg bare på én leverandør for å løse ZTN-spørsmålet. Det er ikke slik at du kan kjøpe en løsning fra én enkelt leverandør, og så vil den dekke alle og alt. Selv i Googles BeyondCorp-løsninger har ikke Google implementert det hele, og de er nødt til å bygge deler av det, skriver Loveless.

– Vi ser på løsninger som kan dekke et stort territorium og som kan snakke med andre løsninger, eller i det minste at vi kan få alle loggene i samme format og på samme sted. Det er åpenbart hull, og vi regner med å knytte sammen noen av de løse endene med selvutviklede løsninger. Dette er ikke uvanlig for mange IT-organisasjoner. Det å fylle hullene med skreddersydd kode er noe som skjer, og en bør forvente at ZTN ikke er fremmed for denne prosessen.

Andre fordeler

Det fleste vil vurdere ZTN av sikkerhetsårsaker, men er det også økonomiske fordeler?

– Det trolig beste eksemplet jeg kan gi, inkluderer provisjonering/deprovisjonering. Vi bruker Okta og har knyttet dette til vårt HR-system og mange andre SaaS-tjenester. Personellavdelingen kan opprette en ny bruker og tildele den en tittel. Dette importeres inn i Okta, som kan provisjonere brukere inn i bokstavelig talt dusinvis av SaaS-systemer via API-er. En prosess som tidligere tok to-tre uker å fullføre, tar nå et par minutter, forteller Loveless.

– Det samme gjelder i forbindelse med deprovisjonering. Vi kan fjerne en brukers profil i løpet av minutter på tvers av systemene når denne ansatte forlater selskapet. Dette anses som en sidegevinst, sett fra vårt ZTN-standpunkt, men med innsparingen i arbeid og forbedret produktivitet vil denne typen implementering alene bidra betydelig til bunnlinjen.

– Etter hvert som man jobber seg videre med ZTN, åpner det for mer kontroll over dataene og tilgangene, noe som ofte er kjernen i etterlevelse av regelverk («compliance»). Som selskap kan vi se på hvilke krav et marked har fra et revisjons- eller compliance-perspektiv, og enklere implementere policyer som gi oss mulighet til å gå inn i disse markedene. For å gjør det enkelt, kan vi velge de strengeste kravene og ta i bruk disse policyene globalt. I mange tilfeller innfrir vi enkelt revisjons- og compliance-kravene til nye bransjer eller markeder. Tilgangskontroll gjort riktig, gjør dette mulig, og ZTN har en sterk tilgangskontrollkomponent.

Er ZTN som tilnærming kompatibel med de fleste nettskytjenester?

– Fullstendig. Vi er 100 prosent nettsky, og vi er i stand til å implementere ting uten problemer.

Kategorisering av data

Er ZTN kompatibel med «Bring Your Own Device» (BYOD – personlig eide enheter)?

– Det avhenger av policyene dine. Hos GitLab er det deler av organisasjonen vår som er fullstendig åpne, inkludert kjerneprogramvaren vår og håndboken vår. Siden disse dataene er offentlige, tillater vi tilgang til disse dataene uten begrensninger, og oppmuntrer til BYOD i dette området. Denne arenaen er ikke bare for ansatte. Den er for alle på internett som ønsker å bidra, forteller Loveless.

– Dataene våre er kategorisert fra RØDT (det mest sensitive), via ORANSJE og GULT, til GRØNT (offentlig). Vi mener at det er områder hvor vi kan avtale at ansatte med BYOD-enheter får tilgang til noen deler av dataene våre, og vi forsøker å jobbe på måter som imøtekommer disse behovene. Til vanlig er det ikke noe problem at BYOD-enheter får tilgang til GRØNNE data, og sannsynligvis også noen GULE data. Mobiltelefoner er et spesielt interessant hinder å bestige, legger han til.

– ORANSJE og spesielt RØDE data bør kun aksesseres med tiltrodde enheter, så der er BYOD utelukket. Vi jobber fortsatt med å håndtere BYOD – det gjør alle virksomheter – men fordi det er dette bedriftskulturen vår startet med, forsøker vi å bygge videre på det, i stedet for å rive ned eksisterende metoder. Det er en interessant linje vi følger, hvor vi forsøker å møte behovene til brukere, kunder, revisorer og ledelsen. Vi har noen ideer om hvor vi potensielt kan bruke BYOD, og til og med vil foretrekke det, men dette er et arbeid som fortsatt pågår, skriver Loveless.

Utfordringer

Basert på din erfaring, hva mener du er de vanligste og viktigste utfordringene under planleggings- og implementeringsfasene?

– Den største utfordringen er kommunikasjon. I noen tilfeller innebærer dette store endringer for sluttbrukerne, og en sikkerhetsperson som uttaler seg med sikkerhetsbegreper, gir lite til ingen mening for dem i salgsavdelingen, for eksempel. Alt må være på et språk som alle kan forstå. Vi fant ut at det å involvere sluttbrukerne, er avgjørende for å lykkes, forteller Loveless.

Ved GitLab har dere jobbet med implementeringen av ZTN en stund. Hvor langt har dere kommet, og vil dere noen gang kunne si at implementeringsfasen er over?

– For hver nye implementering av teknologi, må du integrere gammelt med nytt. Implementering er en utvidet prosess. Akkurat nå har vi gjort unna det meste av brukerautentiseringen, dataklassifiseringen er i stor grad utarbeidet, og vi ser ut til å ha grep om provisjonering og deprovisjonering. Sikkerheten til de ulike systemene var allerede temmelig god – det handlet bare om å integrere det inn i en mer formell ZTN-prosess.

Vanskelig problem

– Vårt neste store hinder er å behandle automatiserte prosesser akkurat som brukere, ved at de krever et eller annet autorisasjonsnivå før kjøring, skriver Loveless.

Han omtaler dette som ett av de virkelig vanskelige problemene, spesielt dersom man har en bruker som oppretter en prosess som kjøres periodisk og som krever autentisering og nøkler.

– Hva om brukeren får nye oppgaver eller til og med ny arbeidsgiver? Skal den automatiske prosessen stoppes? Flytter du den til en annen bruker? Hva om den er kritisk? Dette er store spørsmål, spesielt dersom du forsøker å knytte delene sammen, slik som i vårt tilfelle med Okta-autentisering, dataklassifisering og nå denne automatisert kode-delen.

– Dette alene gjør at jeg ikke kan se for meg at vi noen gang blir ferdige. Vi endrer oss konstant uansett, så jeg vil forvente at enhver ZTN-løsning vil være en kontinuerlig prosess, skriver Loveless.

Kan ZTN skape nye utfordringer eller problemer for den daglige driften, som vil være enklere å løse uten ZTN?

– Dersom vi noen gang støter på slike ting, blir de ikke implementert. Vi forsøker veldig hardt på å unngå dette under planleggingsprosessen.

Betydning for brukerne

Hva med brukerne oppi alt dette? Hvordan påvirkes brukernes mulighet til å gjøre sine daglige oppgaver av ZTN?

– Målet med enhver ZTN-implementering, eller enhver annen sikkerhetsløsning for den sakens skyld, bør være å gjøre livet til brukerne enklere. Dette skjer på to måter – de bør være tryggere, og ting bør være enklere for dem. Det siste er kritisk, fordi dersom du gjør ting for komplekst, vil brukerne gjøre alt de kan for å omgå dette. Dersom du gjør det enklere for sluttbrukeren, vil de innrette seg. Dersom du kan demonstrere at noe har fordeler som kan øke produktiviteten, selv om det innebærer et ekstra trinn, er det gull verdt for dem, avslutter Loveless.