Assumed Breach: Varför modern cybersäkerhet måste utformas för att klara av attacker

I åratal betraktades cybersäkerhet som ett lager som lades till efter att systemen hade byggts. En brandvägg här, en agent på slutpunkterna där, och efterföljande dokumentation av efterlevnad. Den modellen har i tysthet fallit samman.

Idag ser verkligheten annorlunda ut. Angripare agerar inom några minuter, inte dagar. Infrastrukturen är fördelad mellan molnet, lokala system och driftsteknik. Användare och enheter ansluter sig varifrån som helst. I denna miljö är den gamla frågan – ”Hur håller vi angripare borta?” – är inte längre den rätta.

Den rätta frågan är: När en angripare tar sig in, hur stor skada kan hen egentligen åstadkomma?

Detta är kärnan i tankesättet Assumed Breach. Det innebär inte att man ska ge upp förebyggande åtgärder. Det innebär att man utformar system, processer och beredskapsplaner utifrån förväntningen att förebyggande åtgärder ibland misslyckas – och att man ser till att konsekvenserna begränsas när så sker.

”Assumed Breach” är inte en nischfilosofi för erfarna säkerhetsteam. Det håller på att bli standardinställningen för alla organisationer som tar digitala risker på allvar, och det förändrar i tysthet hur ”Secure by Design” tillämpas i Norden.

Varför den gamla säkerhetsmodellen inte längre fungerar

Den traditionella perimetriska säkerheten byggde på en enkel idé: det som finns inom nätverket är betrott, det som finns utanför är det inte. Denna förutsättning har sedan länge visat sig vara felaktig, men många organisationer arbetar fortfarande som om den fortfarande gällde.

Tre förändringar har gjort den gamla modellen ohållbar:

1. Gränserna har upplösts. Distansarbete, SaaS, multicloud och OT-anslutning innebär att det inte längre finns någon tydlig ”insida” att försvara.
2. Angriparna är snabbare och använder sig i högre grad av automatisering. Tidsramarna för utnyttjande av sårbarheter har krympt från veckor till timmar, i allt högre grad med hjälp av AI-driven rekognosering och automatiserade verktyg.
3. Konsekvenserna blir större. Ransomware, böter enligt NIS2 och driftstopp inom kritiska sektorer som energisektorn och hälso- och sjukvården har gjort att även korta säkerhetsöverträdelser kan bli mycket kostsamma.

I dagens verklighet är antagandet att en stark yttre säkerhet räcker inte bara föråldrat – det är en säkerhetsrisk.

Zero Trust: Grunden för en arkitektur som utgår från att intrång redan har skett

Kärnan i Assumed Breach är Zero Trust. Principen är enkel: ingen användare, enhet eller system betraktas som pålitlig som standard. Varje åtkomstförfrågan verifieras, varje gång.

”Det handlar inte om att lita på att en användare har loggat in korrekt”, säger Henrik Lund, teamledare på NetNordic. ”Det handlar om att kontinuerligt kontrollera att det är rätt användare, på rätt enhet, som får åtkomst till rätt resurser.”

I praktiken innebär det att man måste kontrollera:

• Vem användaren är (stark autentisering, inte bara ett lösenord)
• Vad vilken enhet de använder (är den hanterad, uppdaterad, i gott skick?)
• Varför de behöver tillgång (är denna begäran lämplig med tanke på deras roll, denna tid på dygnet och denna resurs?)

Även giltiga inloggningsuppgifter på en komprometterad enhet bör inte ge åtkomst. Och när åtkomst beviljas bör den begränsas till exakt det som användaren behöver för den aktuella uppgiften – ingenting mer. Detta är åtkomst med minsta möjliga behörighet, och det är en av de åtgärder som ger störst effekt som en organisation kan vidta.

Att begränsa skadeomfattningen: hur ”Assumed Breach” fungerar i praktiken

Om man utgår från att ett intrång så småningom kommer att inträffa, förändras utformningsfrågan. Det handlar inte längre om ”Hur kan vi förhindra alla attacker?” but ”Hur ser vi till att smittan inte sprids när någon smittas?”

Denna omformulering får praktiska konsekvenser:

• En komprometterad bärbar dator bör inte ge åtkomst till produktionsservrar
• Ett administratörskonto som utsatts för nätfiske bör inte avslöja hela identitetskatalogen
• En sårbarhet i en SaaS-integration bör inte sprida sig till andra affärssystem

Inneslutning är en arkitektonisk egenskap. Den uppnås genom nätverkssegmentering, identitetsgränser, åtskillnad av behörigheter och uttryckliga förtroenderelationer mellan komponenter. När dessa gränser är starka blir ett intrång en avgränsad incident snarare än en kris.

Mikrosegmentering: från breda zoner till kontrollerad åtkomst

Många nordiska organisationer förlitar sig fortfarande på traditionell nätverkssegmentering – där systemen delas upp i ett fåtal stora zoner (produktion, kontor, gäst, OT). Det är enkelt att hantera, men så snart en angripare har tagit sig in i någon av zonerna är det ofta mycket enkelt för denne att röra sig vidare i nätverket.

Mikrosegmentering har en helt annan strategi. Istället för ett fåtal stora zoner styrs åtkomsten på en mycket mer detaljerad nivå – ofta ända ner till enskilda arbetsbelastningar, applikationer eller tjänster. Varje interaktion kräver verifiering. Varje system isoleras i så stor utsträckning som möjligt.

Logiken är enkel: Mindre åtkomst innebär mindre risk.

Men mikrosegmentering innebär vissa nackdelar. Den är mer komplicerad att implementera, kräver god insyn i applikationernas beroenden och förutsätter expertkunskap för att undvika att legitima arbetsflöden störs. Om den genomförs på fel sätt leder det till frustrerade användare och främjar skugg-IT. Om den genomförs på rätt sätt minskar den dramatiskt omfattningen av eventuella säkerhetsincidenter.

Detta är ett av de områden där designkompetens och erfarenhet verkligen spelar roll – och där ett felsteg i början tar år att rätta till.

Automatiserad uppdatering och exponeringstiden

Även med sträng åtkomstkontroll finns det fortfarande sårbarheter. Programvara skrivs av människor, och människor gör misstag. Leverantörerna släpper uppdateringar, men det går sällan att installera dem omedelbart.

Den fördröjningen skapar just det som angripare är ute efter: en exponeringsperiod – tiden från det att en sårbarhet upptäcks till dess att era system är skyddade. Med automatiserade skannings- och utnyttjandeverktyg räknas det tidsfönstret ofta i timmar.

För att stänga den krävs två saker:

1. Automatisk uppdatering, så att uppdateringarna genomförs så snart driften tillåter det
2. Arkitektur som möjliggör uppdateringar utan driftstopp – redundans, löpande uppdateringar, kanarieförsök

Automatisering i sig räcker inte. Den måste byggas in redan från början. Återigen handlar det om hur systemen konstrueras från första början.

Virtuell patchning för driftstekniska system och äldre system i kritisk infrastruktur

Det går inte att uppdatera alla system. Driftstekniken inom kraftverk, vattenrening, tillverkning och transport körs ofta på plattformar som är flera decennier gamla, certifierade för specifika förhållanden eller alltför kritiska för att kunna stängas av för en uppdatering. Äldre applikationer inom hälso- och sjukvård, finanssektorn och offentlig förvaltning står inför liknande begränsningar.

Särskilt för den nordiska energisektorn är detta inte ett teoretiskt problem. Konvergensen mellan IT och OT är ett faktum: SCADA-system och styrsystem som tidigare var helt isolerade är nu integrerade med företagsnätverk, molnbaserad övervakning och fjärrstyrningscentraler. Angreppsytan har vuxit snabbare än förmågan att modernisera den underliggande tekniken.

Det är här virtuell patchning blir avgörande. I stället för att ändra det sårbara systemet i sig införs skyddsåtgärder runt det:

• Nätverkstrafiken kontrolleras och filtreras
• Kända säkerhetsluckor blockeras innan de når systemet
• Misstänkt beteende utlöser varningar och begränsningsåtgärder

Det ersätter inte uppdateringar där sådana är möjliga. Men för kritiska system som inte kan ändras håller det säkerhetsrisken under kontroll tills en modernisering kan genomföras – ofta under en period på flera år.

För operatörer av kritisk infrastruktur är denna strategi inte längre något valfritt. Den utgör grunden för en försvarbar säkerhetsstrategi enligt NIS2 och sektorsspecifik lagstiftning.

Assumed Breach och NIS2: inbyggd efterlevnad

NIS2 och dess nationella genomföranden (inklusive lagen om digital säkerhet i Norge) ger officiell tyngd åt det som säkerhetsteam har sagt i åratal: motståndskraft måste byggas in från början, inte läggas till i efterhand.

Att försöka lägga till efterlevnad i en befintlig arkitektur är kostsamt, tidskrävande och blir oftast ofullständigt. De organisationer som lyckas hantera NIS2 är de som från början betraktar det som ett arkitektoniskt krav:

• Riskbedömningen ligger till grund för konstruktionsbesluten, inte bara för dokumentationen
• Loggnings-, övervaknings- och incidentrapporteringsfunktionerna är inbyggda, inte tillagda i efterhand
• Risker kopplade till leverantörer och tredje part är en del av arkitekturen, inte en separat åtgärd

Om det görs på rätt sätt blir regelefterlevnad ett resultat av god design snarare än ett separat projekt. Och – vilket är avgörande för styrelser och ledning – det går att försvara vid en granskning.

Händelsehantering: öva inför det oundvikliga

Även de bäst utformade systemen drabbas av incidenter. Assumed Breach utgår från detta och förbereder sig för det.

Denna förberedelse är mer än bara en dokumenterad plan som ligger i en SharePoint-mapp. Välfungerande organisationer genomför numera regelbundna simuleringar – bordssimuleringar, övningar med ”red team” och fullskaliga ”krigsspel” – där incidenthanteringen testas under realistiska förhållanden.

Anledningen är enkel: när en verklig incident inträffar finns det ingen tid att lära sig. Rollerna måste vara tydliga. Besluten måste vara förhandsgodkända. Eskaleringsvägarna måste vara kända. Den första timmen av en allvarlig incident avgör hur de kommande tre månaderna kommer att se ut.

Oavsett om det gäller Zero Trust, automatisering, segmentering, regelefterlevnad eller incidenthantering, finns det ett mönster som återkommer: Säkerhetslösningar som är inbyggda håller. Säkerhetslösningar som läggs till i efterhand gör det inte.

Från teori till praktik: så här hjälper NetNordic till

”Assumed Breach” är ett tankesätt, men det är just när det gäller att omsätta detta i arkitektur, drift och styrning som de flesta organisationer stöter på svårigheter. Det är här det är viktigt att ha rätt partner.

NetNordic samarbetar med nordiska organisationer inom energisektorn, den offentliga sektorn, finansbranschen och näringslivet för att omsätta dessa principer i praktiska och motståndskraftiga arkitekturer. Det innefattar:

• Cybersäkerhetsråd – strategi, arkitekturgranskningar, NIS2-förberedelser och färdplaner för Zero Trust
• Offensiv säkerhet – penetrationstester, Red Team-övningar och övningar med scenarion för Assumed Breach, för att testa hur väl skyddsåtgärderna står sig mot verkliga angripares beteende
• Hanterad säkerhetsoperationscentral – Övervakning och insats dygnet runt, utifrån antagandet att något så småningom kommer att ta sig igenom
• Säker infrastruktur och nätverkstjänster – utformad med segmentering, automatisering och stabilitet som standard

Målet är inte att helt förhindra hot. Det handlar om att bygga upp motståndskraft: system som håller hoten i schack, verksamheter som reagerar effektivt och en verksamhet som fortsätter att fungera.

Vanliga frågor

Vad innebär tankesättet ”Assumed Breach”? ”Assumed Breach” är en strategi inom cybersäkerhet som bygger på antagandet att förebyggande åtgärder ibland misslyckas. Istället för att enbart förlita sig på att hålla angripare borta, fokuserar strategin på att utforma system, processer och insatskapacitet som begränsar skadeverkningarna när ett intrång inträffar.

Hur skiljer sig ”Assumed Breach” från Zero Trust? Zero Trust är en arkitektonisk princip – lita aldrig på, verifiera alltid. ”Assumed Breach” är det bredare operativa tankesättet som Zero Trust ofta ingår i. Zero Trust svarar hur Du utformar åtkomsten; Svar på antagna intrång varför – eftersom du utformar för det ögonblick då något slår igenom.

Är begreppet ”presumerad avtalsbrott” relevant för små och medelstora företag? Ja. Faktum är att mindre organisationer ofta har större nytta av detta, eftersom de har mindre kapacitet att hantera en allvarlig incident. Principerna – minsta möjliga behörighet, segmentering och beprövade åtgärder – fungerar lika bra i mindre som i större sammanhang.

Hur stämmer Assumed Breach överens med NIS2? NIS2 ställer uttryckliga krav på riskhantering, incidenthantering och säkerhet i leverantörskedjan. En arkitektur som utgår från antagandet om intrång uppfyller dessa krav redan i sin utformning, snarare än som en separat åtgärd för att uppfylla kraven.

Var bör en organisation börja? De flesta organisationer får störst effekt av tre saker: en kartläggning av nuläget när det gäller identitet och åtkomst, en översyn av nätverkssegmenteringen (särskilt mellan IT och OT) samt en beprövad plan för incidenthantering. Enbart dessa tre åtgärder täcker in merparten av säkerhetsluckorna.

Är du redo för nästa steg?

Om ni vill stärka er organisations försvar inför verkligheten år 2026 och framåt, är utgångspunkten att förstå var ni står idag.