Assumed Breach: Hvorfor moderne cybersikkerhet må bygges for å tåle angrep

I årevis ble cybersikkerhet behandlet som et lag man la til etter at systemene var bygget. En brannmur her, en endpoint-agent der, compliance dokumentert i ettertid. Den modellen har stille og rolig kollapset.

Dagens virkelighet er en annen. Angripere beveger seg i løpet av minutter, ikke dager. Infrastrukturen er spredt på tvers av sky, lokale miljøer og operasjonell teknologi. Brukere og enheter kobler seg til fra alle kanter. I dette landskapet er det gamle spørsmålet – «hvordan holder vi angriperne ute?» – ikke lenger det rette.

Det rette spørsmålet er: når en angriper først kommer inn, hvor stor skade kan de egentlig gjøre?

Dette er kjernen i Assumed Breach-tankesettet. Det betyr ikke at man gir opp forebygging. Det betyr at man designer systemer, prosesser og responsplaner ut fra forventningen om at forebygging av og til vil svikte – og sikrer at når det skjer, forblir konsekvensene begrenset.

Assumed Breach er ikke lenger en nisjefilosofi for modne sikkerhetsmiljøer. Det er i ferd med å bli standardposisjon for enhver virksomhet som tar digital risiko på alvor, og endrer gradvis hvordan Secure by Design praktiseres i Norge.

Hvorfor den gamle sikkerhetsmodellen ikke lenger holder

Tradisjonell perimetersikkerhet var bygget på en enkel idé: det som er innenfor nettverket, er til å stole på – alt utenfor er ikke det. Den antakelsen brast for lenge siden, men mange virksomheter opererer fremdeles som om den står ved lag.

Tre utviklinger har gjort den gamle modellen uholdbar:

1. Perimeteret har løst seg opp. Hjemmekontor, SaaS, multi-cloud og OT-tilkobling har gjort at det ikke lenger finnes en klar «innside» å forsvare.
2. Angripere er raskere og mer automatiserte. Tiden fra en sårbarhet blir kjent til den utnyttes, er krympet fra uker til timer – i økende grad med hjelp av AI-drevet rekognosering og automatiserte verktøy.
3. Konsekvensene er større. Løsepengevirus, bøter under digitalsikkerhetsloven, og driftsstans i kritiske sektorer som kraft og helse har gjort at selv kortvarige hendelser koster dyrt.

I denne virkeligheten er antakelsen om at et sterkt perimeter er nok, ikke bare utdatert – den er en aktiv risiko.

Zero Trust: grunnmuren i en Assumed Breach-arkitektur

I bunnen av Assumed Breach ligger Zero Trust. Prinsippet er rett fram: ingen bruker, enhet eller system har tillit som utgangspunkt. Hvert tilgangsforsøk verifiseres, hver gang.

«Det handler ikke om å stole på at en bruker har logget på riktig,» sier Henrik Lund, Team Lead Fortinet i NetNordic. «Det handler om å kontinuerlig verifisere at det er riktig bruker, på riktig enhet, som får tilgang til riktige ressurser.»

I praksis betyr det å bekrefte:

• Hvem brukeren er (sterk autentisering, ikke bare passord)
• Hvilken enhet de bruker (er den forvaltet, oppdatert, frisk?)
• Hvorfor de trenger tilgang (er forespørselen rimelig for rollen, tidspunktet, ressursen?)

Selv gyldige påloggingsopplysninger på en kompromittert enhet skal ikke gi tilgang. Og tilgang, når den først gis, skal begrenses til nøyaktig det brukeren trenger for å løse oppgaven – ikke mer. Dette kalles minste privilegium, og er en av endringene som gir størst effekt per krone investert.

Les mer om SOC og Aktiv Sikkerhetsovervåking

Den vanligste feilen vi ser, er at virksomheter behandler Zero Trust som et produkt – ikke som en arkitektur. De tar i bruk nye verktøy, men tilgangsmodellen forblir den samme. Det er der risikoen ligger.

Henrik Lund, Tech Lead Fortinet – Senior Nettverkskonsulent

Å begrense skadeomfanget: hva Assumed Breach ser ut som i praksis

Når man aksepterer at et brudd før eller siden vil skje, endres designspørsmålet. Det handler ikke lenger om «hvordan stopper vi alle angrep?», men om «hvordan sikrer vi at når ett kommer gjennom, kan det ikke spre seg?»

Det har praktiske konsekvenser:

• En kompromittert laptop skal ikke gi tilgang til produksjonsservere
• En phishet administratorkonto skal ikke eksponere hele identitetskatalogen
• En sårbarhet i én SaaS-integrasjon skal ikke kunne forplante seg gjennom forretningssystemene

Skadebegrensning er en arkitekturegenskap. Den bygges inn gjennom nettverkssegmentering, identitetsgrenser, rettighetsskille og eksplisitte tillitsforhold mellom komponenter. Når disse grensene er sterke, blir et brudd en kontrollert hendelse i stedet for en krise.

Mikrosegmentering: fra brede soner til kontrollert tilgang

Mange norske virksomheter baserer seg fremdeles på tradisjonell nettverkssegmentering – systemene deles inn i noen få store soner (produksjon, kontor, gjest, OT). Det er enkelt å forvalte, men så snart en angriper er inne i en sone, er lateral bevegelse ofte triviell.

Mikrosegmentering tar en fundamentalt annen tilnærming. I stedet for noen få store soner styres tilgang på et mye finere nivå – ofte helt ned til enkeltarbeidsmengder, applikasjoner eller tjenester. Hver interaksjon verifiseres. Hvert system isoleres så langt det lar seg gjøre.

Logikken er enkel: mindre tilgang betyr mindre risiko.

Men mikrosegmentering har sin pris. Det er mer komplekst å implementere, krever god innsikt i applikasjonsavhengigheter, og forutsetter kompetanse for å unngå å bryte legitime arbeidsflyter. Gjort dårlig frustrerer det brukerne og driver frem skygge-IT. Gjort godt, reduserer det skadeomfanget av et enkelt brudd dramatisk.

Dette er et av områdene hvor designkompetanse og erfaring virkelig teller – og hvor et feiltrinn tidlig koster år å rette opp.

Automatisk patching og eksponeringsvinduet

Selv med streng tilgangsstyring består sårbarheter. Programvare skrives av mennesker, og mennesker gjør feil. Leverandører slipper patcher, men utrulling skjer sjelden umiddelbart.

Denne forsinkelsen gir angripere det de leter etter: et eksponeringsvindu – tiden mellom en sårbarhet blir kjent og til systemene dine er beskyttet. Med automatiserte skanne- og utnyttelsesverktøy måles det vinduet ofte i timer.

Å lukke det krever to ting:

1. Automatisk patching, slik at oppdateringer rulles ut så raskt driften tillater
2. En arkitektur som støtter patching uten nedetid – redundans, rullende oppdateringer, kanariedistribusjon

Automatisering alene er ikke nok. Den må være bygget inn. Igjen kommer svaret tilbake til hvordan systemene er bygget fra starten.

Anbefalt lesning: Hvorfor menneskelige feil innen cybersikkerhet fortsatt utgjør den største risikoen

Virtuell patching for OT og eldre systemer i kritisk infrastruktur

Ikke alle systemer kan patches. Operasjonell teknologi i kraftverk, vannbehandling, produksjon og transport kjører ofte på plattformer som er tiår gamle, sertifisert for spesifikke forhold, eller for kritiske til å tas ned for oppdatering. Eldre applikasjoner i helse, finans og offentlig forvaltning møter tilsvarende begrensninger.

For norsk kraftsektor er dette ikke et teoretisk problem. IT/OT-konvergens er en realitet: SCADA- og styringssystemer som tidligere var luftgappet, er nå integrert med kontornettverk, skybasert overvåking og fjerndriftssentre. Angrepsflaten har utvidet seg raskere enn evnen til å modernisere den underliggende teknologien.

Her blir virtuell patching avgjørende. I stedet for å endre det sårbare systemet selv, plasseres beskyttende kontroller rundt det:

• Nettverkstrafikk inspiseres og filtreres
• Kjente angrepsmønstre blokkeres før de når systemet
• Mistenkelig atferd utløser varsler og inneslutning

Det er ingen erstatning for patching der patching er mulig. Men for kritiske systemer som ikke kan endres, holder det vinduet lukket til modernisering lar seg gjennomføre – ofte over et flerårig løp.

For operatører av kritisk infrastruktur er denne tilnærmingen ikke lenger valgfri. Den er grunnlaget for en forsvarlig sikkerhetsposisjon under digitalsikkerhetsloven og sektorregulering.

Assumed Breach og digitalsikkerhetsloven: compliance by design

Digitalsikkerhetsloven – Norges gjennomføring av NIS2 – gir formell tyngde til det sikkerhetsmiljøene har sagt i årevis: motstandsdyktighet må bygges inn, ikke skrus på i ettertid.

Å bolte compliance fast på en eksisterende arkitektur er dyrt, tregt og som oftest ufullstendig. Virksomhetene som håndterer digitalsikkerhetsloven best, er de som behandler den som et arkitekturkrav fra starten:

• Risikoevaluering informerer designvalg, ikke bare dokumentasjon
• Logging, overvåking og hendelsesrapportering bygges inn, ikke legges til i ettertid
• Leverandør- og tredjepartsrisiko er en del av arkitekturen, ikke en sideøvelse

Gjort riktig blir compliance en konsekvens av god design – og ikke et parallelt prosjekt. Og – avgjørende for styre og toppledelse – det blir forsvarlig når det settes på prøve.

Hendelseshåndtering: å øve på det som kommer

Selv det best designede systemet vil oppleve hendelser. Assumed Breach forutsetter det og forbereder for det.

Den forberedelsen er mer enn en plan som ligger i en SharePoint-mappe. Modne virksomheter kjører i dag jevnlige simuleringer – table top-øvelser, red team-oppdrag, fullskala «war games» – der hendelseshåndtering testes under realistisk press.

Grunnen er enkel: når en reell hendelse inntreffer, er det ikke tid til å lære. Roller må være klare. Beslutninger må være forhåndsautorisert. Eskaleringsveier må være forstått. Den første timen av en alvorlig hendelse setter retning for de neste tre månedene.

På tvers av Zero Trust, automatisering, segmentering, compliance og respons gjentar ett mønster seg: sikkerhet som designes inn, holder. Sikkerhet som legges på, gjør det ikke.

Fra prinsipp til praksis: slik hjelper NetNordic

Assumed Breach er et tankesett, men å oversette det til arkitektur, drift og styring er der de fleste sliter. Her gjør riktig partner en forskjell.

NetNordic jobber med norske virksomheter i kraft, offentlig sektor, finans og næringsliv med å oversette disse prinsippene til praktiske, motstandsdyktige arkitekturer. Det inkluderer:

• Cyber Advisory – strategi, arkitekturgjennomganger, digitalsikkerhetsloven-modenhet og Zero Trust-veikart
• Offensiv sikkerhet – penetrasjonstesting, Red Team og Assumed Breach-øvelser som validerer forsvaret mot reell angripervirksomhet
• Managed SOC – deteksjon og respons 24/7, bygget på antakelsen om at noe før eller siden vil slippe gjennom
• Sikker infrastruktur og nettverkstjenester – designet med segmentering, automatisering og motstandsdyktighet som utgangspunkt

Målet er ikke perfekt forebygging. Det er designet motstandsdyktighet: systemer som rommer trusler, en drift som responderer effektivt, og en virksomhet som holder hjulene i gang.

Ofte stilte spørsmål

• Hva er Assumed Breach? Assumed Breach er en tilnærming til cybersikkerhet som bygger på forventningen om at forebygging av og til vil svikte. I stedet for å basere seg utelukkende på å holde angripere ute, fokuserer den på å designe systemer, prosesser og responsevne som begrenser konsekvensene når et brudd inntreffer.
• Hva er forskjellen på Assumed Breach og Zero Trust? Zero Trust er arkitekturprinsippet – aldri stol på noen, verifiser alltid. Assumed Breach er det bredere operasjonelle tankesettet som Zero Trust ofte er en del av. Zero Trust svarer på hvordan du designer tilgang; Assumed Breach svarer på hvorfor – fordi du designer for øyeblikket noe kommer gjennom.
• Er Assumed Breach relevant for små og mellomstore virksomheter? Ja. Små virksomheter har faktisk ofte mer å vinne, fordi de har mindre kapasitet til å tåle en alvorlig hendelse. Prinsippene – minste privilegium, segmentering, testet respons – skalerer både opp og ned.
• Hvordan henger Assumed Breach sammen med digitalsikkerhetsloven? Digitalsikkerhetsloven krever eksplisitt risikostyring, hendelseshåndtering og leverandørkjedesikkerhet. En Assumed Breach-arkitektur dekker disse kravene gjennom design, i stedet for som en separat compliance-øvelse.
• Hvor bør man begynne? De fleste får høyest effekt av tre ting: en nåtidsvurdering av identitet og tilgang, en gjennomgang av nettverkssegmentering (særlig mellom IT og OT), og en testet hendelsesplan. De tre alene lukker størstedelen av gapet.

Klar for det som kommer?

Hvis du bygger virksomhetens forsvar for den virkeligheten vi står i nå, starter det med å forstå hvor dere står i dag.

Book samtale om Assumed Breach-modenhet en uforpliktende samtale med en av våre sikkerhetsspesialister som går gjennom dagens posisjon og peker ut hvor designendringer vil ha størst effekt.