Zero Trust förklarat på tio minuter

Inom säkerhetsvärlden har vi tjatat om Zero Trust ett tag och även om det blir mer och mer känd vad konceptet är och vad det bygger på dyker det då och då upp frågor så här är mitt försök att förklara konceptet på fem, kanske tio minuter.

I grunden är zero trust vad det låter som – lita inte på någon eller något som inte verifierats. Utgå alltid från det värsta, till exempel att grannservern i ett nätverk tagits över av cyberkriminella, och sätt upp skyddsåtgärder utifrån den utgångspunkten så att den ägda maskinen inte blir ett bekymmer i grannskapet mer än den oreda som redan ställts till med i den då förhoppningsvis isolerade maskinen.

Zero Trust i nätverk

Klassiskt sett litar man på trafiken inom ett nätverk. Man kan ha delat in system och funktioner i segment och haft brandväggsregler där emellan med det klassiska tänket att ett nätverk med lägre säkerhetsklass alltid litar på ett med högre säkerhetsklass. Segmentet med klienter har generellt alltid befunnit sig på samma nätverk som servrarna alternativt tillåtits kommunicera in till serversegmentet med i bästa fall tighta brandväggsregler emellan. Däremot litar man generellt i regel blint på användare och maskiner inom det egna nätverkssegmentet.

Riskerna med detta är att en maskin på ett nätverkssegment som tagits över av en cyberkriminell kan agera språngbräda till resten av dels det egna nätverket, dels alla nätverk med lägre säkerhetsklass. Det är i regel bara för aktören att ”vänta ut” att ett misstag ska ske så som en missad säkerhetsuppdatering eller att en administratör loggar in, så man får tillgång till mer resurser i nätverken.

Inom Zero Trust-modellen litar man inte på en maskin och en användare utifrån vilket nätverkssegment man råkar befinna sig på utan ställer kravet att den faktiska användaren ska vara såväl autentiserad som auktoriserad, och man då får bara den åtkomst som man verkligen behöver tillgång till. Varje enhet på ett nätverk ska antingen kunna skydda sig själv genom brandvägg med autentisering och gärna auktorisering, alternativt om det inte är möjligt finnas på ett eget nätverkssegment med väldigt specifika brandväggsregler för vilken trafik som tillåts – så kallad mikrosegmentering.

Zero Trust i applikation

När trafik enligt Zero Trust-modellen väl etablerats flyttas kontrollen till högre nivå – det vill säga applikationen eller tjänsten som ska besvara nätverksförfrågan. Klassiskt etableras ofta en session med servertjänsten som svarar på förfrågan och låter användaren komma relativt långt in – kanske till en webbaserad inloggningssida eller i värsta fall direkt in givet att man valt att lita på brandväggsreglerna i nätverket.

Filosofin i Zero Trust-modellen är att nu göra allt man kan för att säkerställa att såväl maskinen som anslutit som människan som använder den aktuella maskinen faktiskt är den man utger sig för att vara och faktiskt har behörighet att göra anslutningen. Innan inloggningssidan visas behöver alltså anslutningen vara verifierad och godkänd, till exempel genom användande av personligt certifikat eller annan behörighetstoken.

De sju grundpelarna i Zero Trust

I modellen Forrester Zero Trust eXtended (ZTX) definieras sju grundpelare som Zero Trust ska kunna vara uppbyggt på fullt implementerat:

1. Datasäkerhet: Utöver att data ska vara klassificerat ska det även hållas krypterat såväl i vila som under överföring.
2. Nätverkssäkerhet: Nätverken ska vara segmenterade, klassificerade, isolerade (från varandra – se nedan) för att säkerställa att system sak kunna prata med varandra utifrån faktiska behov.
3. Personsäkerhet: Här ryms identitets- och behörighetskontroll i syfte att skydda data och teknik, samt skydd av användare i sig från externa hot och risker – så som skadlig kod och social manipulation genom att bl. a. ha kontroll över användningsmönster och dataanvändning.
4. Stacksäkerhet: Någorlunda nytt begrepp (eng: workload security) som bäst kan beskrivas som helheten i platsen där applikationen körs och hanteras – typiskt hela vägen från applikationen i sig, genom operativsystem, virtuella datorer, underliggande container, hypervisor till underliggande dedikerad hårdvara i stacken. All stackintern kommunikation måste fungera enligt ZT-principerna och vara kontrollerade och verifierade.
5. Enhetssäkerhet: Här är ofta den första attackvektorn och därmed en av de viktigaste. Ingen enhet, tjänst, funktion eller applikation får som standard lita på en enhet i sig själv – helt enkelt för att enheterna är för komplexa. Snart sagt var och varannan enhet som krängs har en IP-stack och ska vara ansluten för att fungera som det är tänkt – och detta tillför risker. Enheter måste därför vara isolerade, skyddade, kontrollerade och uppdaterade.
6. Visibilitet och analys: Det är omöjligt att förstå, och än mindre hantera, hot och sårbarheter som du inte känner till. Genom att analysera och skapa visuella bilder över data- och informationsflöden får du också tillgång till en bild över var hot och risker är som störst. Där mest krut behöver läggas.
7. Automation och orkestrering: Manuell handpåläggning och arbetsmoment är förknippade med risker. Även om en människa utför ett moment precis likadant varje gång finns också risken, varje gång, att något missas eller glöms bort. Eller görs på fel sätt – medvetet eller inte. Att automatisera återkommande moment och flöden tar bort en stor del av den riskbilden.

Några viktiga åtgärder i Zero Trust

Modellen är bred och komplex, men nedan listar jag några konkreta viktiga principer att applicera som en del i en Zero Trust-modell. Listan är långt ifrån fullständig utan mer till för att ge en bild över principer och åtgärder som med fördel kan implementeras som en del i en organisations ZT-modell.

• Håll system och applikationer uppdaterade: Sårbarheter i system och applikationer är och förblir risk, och dessutom riskerar sårbarheter sätta viktiga Zero Trust-relaterade säkerhetsåtgärder ur spel. Ha tydliga processer och rutiner för snabb hantering av säkerhetsuppdateringar.
• Utgå från att det inte finns något perimeterskydd i nätverket: Ofta är skyddet i nätverket något som hanteras av ett nätverksteam eller liknande. Mänskliga faktorn är en risk som kan innebära att sådant skydd riskerar fallera. De möjliga sårbarheterna som kan finnas i skyddet är helt enkelt för många, så att ha utgångspunkten att det helt enkelt inte finns något skydd är den bästa.
• Segmentera nätverket så tight det bara är möjligt: Blanda aldrig applikationsnivåer i ett och samma nätverkssegment. Databas för sig, applikationsserver för sig och frontend för sig. Blanda bara servrar i ett segment för att det behövs, inte för att det är praktiskt. Igen – utgå från att en av maskinerna på ett segment kan vara angripen och att det inte ska riskera bli ett större bekymmer än det redan är. Bedöm om mikrosegmentering är en användbar väg framåt.
• Lita inte på nätverkssegment ”som standard”: Det finns ingen poäng med att ett nätverk med servrar (och därmed hög säkerhetsklass) ska kunna prata obehindrat med nätverk innehållande klienter (lägre säkerhetsklass). Se till att ha adekvata brandväggsregler åt båda hållen.
• Använd inbyggda brandväggar där det finns: I de fall ett operativsystem eller annan enhet har stöd för intern brandvägg så bör den vara påslagen och aktiv. Den ska vara inställd på att bara tillåta den trafik som verkligen krävs för att en användare eller ett system ska kunna göra de anrop som verkligen krävs för syftet. Att avaktivera till exempel inbyggd brandvägg i operativsystem för att det är mer praktiskt eller av andra obskyra skäl är fel väg att gå.
• Tillåt inte trafik mot Internet där det inte krävs: Särskilt på servrar finns det inga bra skäl att tillåta generell trafik mot Internet. Inventera behoven och hantera dessa specifikt. Hantera uppdatering genom intern spegel eller uppdateringstjänst.
• Automatisera och orkestrera: De stora säkerhetsriskerna återfinns i när människa ska utföra manuella arbetsmoment, så som att skapa nätverkskonfiguration och sätta upp brandväggsregler. Genom att automatisera och nyttja orkestreringsflöden elimineras de risker som finns kopplat till manuell hantering.
• Använd hårdvaru- eller applikationsbaserad MFA: Engångskoder för multifaktorautentisering som skickas i mail eller SMS har lägre säkerhet än hantering i egna hårdvarutokens eller applikationsbaserad så som TOTP. Det senare behöver dock vara i kombination med skydd av enheten, antingen med PIN-kod eller biometri.

Misstag att undvika

• Rigida autentiseringsmekanismer kan riskera att användare i frustration hittar sätt och vägar för att komma runt säkerhetsåtgärder. Kuriosa i sammanhanget är att jag sett vårdpersonal placera datormusen i en provrörsvagga i syfte att komma runt en alltför hårt satt tid för automatisk låsning av datorn. Att t.ex. kräva återautentisering ofta riskerar paradoxalt nog sänka säkerhetsnivån.