Assumed Breach: Hvorfor moderne cybersikkerhed skal være bygget til at modstå angreb

I årevis blev cybersikkerhed betragtet som et lag, der blev tilføjet, efter at systemerne var opbygget. En firewall her, en endpoint-agent der, og overholdelse af reglerne blev dokumenteret bagefter. Den model er stille og roligt brudt sammen.

Virkeligheden ser anderledes ud i dag. Angribere handler på få minutter, ikke dage. Infrastrukturen er spredt ud over cloud, lokale systemer og driftsteknologi. Brugere og enheder opretter forbindelse fra alle mulige steder. I dette miljø er det gamle spørgsmål – “Hvordan holder vi angribere ude?” – ikke længere det rigtige spørgsmål.

Det rigtige spørgsmål er: Når en hacker får adgang, hvor stor skade kan vedkommende så egentlig forvolde?

Dette er kernen i Assumed Breach tankegang. Det betyder ikke, at man skal opgive forebyggelsen. Det betyder, at man skal udforme systemer, processer og beredskabsplaner ud fra den forventning, at forebyggelsen nogle gange vil slå fejl – og sikre, at konsekvenserne holdes under kontrol, når det sker.

“Assumed Breach” er ikke længere en nichefilosofi for erfarne sikkerhedsteams. Den er ved at blive standardtilgangen for enhver organisation, der tager digitale risici alvorligt, og den er stille og roligt ved at ændre den måde, hvorpå “Secure by Design” praktiseres i hele Norden.

Hvorfor den gamle sikkerhedsmodel ikke længere fungerer

Traditionel perimeterbaseret sikkerhed byggede på en enkel tanke: Det, der ligger inden for netværket, er pålideligt, det udenfor er ikke. Den antagelse brød sammen for længe siden, men mange organisationer arbejder stadig, som om den stadig holder.

Tre ændringer har gjort den gamle model uholdbar:

1. Perimeter‑tænkningen holder ikke længere. Fjernarbejde, SaaS, multi-cloud og OT-forbindelser betyder, at der ikke længere er et klart »indre« område, der skal forsvares.
2. Hackerne er hurtigere og mere automatiserede. Tidsrammerne for udnyttelse af sårbarheder er blevet reduceret fra uger til timer, i stigende grad understøttet af AI-drevet rekognoscering og automatiserede værktøjer.
3. Konsekvenserne er større. Ransomware, bøder i henhold til NIS2 og driftsafbrydelser i kritiske sektorer som energisektoren og sundhedssektoren har gjort selv korte sikkerhedsbrud til en reel økonomisk byrde.

I den virkelighed er antagelsen om, at en stærk ydre sikkerhedsbarriere er tilstrækkelig, ikke blot forældet – den udgør en risiko.

Zero Trust: Grundstenen i en Assumed Breach-arkitektur

Kernen i Assumed Breach er Zero Trust. Princippet er enkelt: Ingen bruger, enhed eller system betragtes som pålidelig som udgangspunkt. Hver eneste adgangsforespørgsel kontrolleres, hver gang.

“Det handler ikke om at stole på, at en bruger har logget ind korrekt,” siger Henrik Lund, teamleder for Fortinet hos NetNordic. “Det handler om løbende at kontrollere, at det er den rigtige bruger på den rigtige enhed, der får adgang til de rigtige ressourcer.”

I praksis betyder det, at man skal bekræfte:

• Hvem brugeren er (stærk autentificering, ikke blot en adgangskode)
• Hvad den enhed, de bruger (er den administreret, opdateret, i god stand?)
• Hvorfor de har brug for adgang (er denne anmodning passende i forhold til deres rolle, på dette tidspunkt af dagen og i forhold til denne ressource?)

Selv gyldige loginoplysninger på en kompromitteret enhed bør ikke give adgang. Og når der gives adgang, bør den være begrænset til præcis det, brugeren har brug for til den aktuelle opgave – ikke mere. Dette er adgang med mindst mulig rettigheder, og det er en af de ændringer, der har størst gennemslagskraft, en organisation kan gennemføre.

Når bruddet er en realitet: Assumed Breach i praksis

Hvis man accepterer, at der før eller siden vil ske et sikkerhedsbrud, ændrer designudfordringen sig. Det handler ikke længere om “Hvordan forhindrer vi alle angreb?” men “Hvordan sikrer vi, at smitten ikke kan sprede sig, når den først er kommet ind?”

Denne omformulering har praktiske konsekvenser:

• En kompromitteret bærbar computer bør ikke give adgang til produktionsserverne
• En administratorkonto, der er blevet udsat for phishing, bør ikke afsløre hele identitetsdatabasen
• En sårbarhed i en SaaS-integration bør ikke sprede sig til andre forretningssystemer

Inddæmning er en arkitektonisk egenskab. Den opnås gennem netværkssegmentering, identitetsgrænser, adskillelse af privilegier og eksplicitte tillidsforhold mellem komponenter. Når disse grænser er solide, bliver et sikkerhedsbrud en inddæmmet hændelse snarere end en krise.

Mikrosegmentering: fra brede zoner til kontrolleret adgang

Mange nordiske organisationer benytter stadig traditionel netværkssegmentering – hvor systemerne opdeles i en håndfuld store zoner (produktion, kontor, gæst, OT). Det er nemt at administrere, men når en hacker først er kommet ind i en af zonerne, er det ofte meget let at bevæge sig videre.

Mikrosegmentering anvender en helt anderledes tilgang. I stedet for nogle få store zoner styres adgangen på et langt mere detaljeret niveau – ofte helt ned på det enkelte arbejdsforløb, den enkelte applikation eller den enkelte tjeneste. Hver eneste interaktion kræver verifikation. Hvert system isoleres i videst muligt omfang.

Logikken er enkel: Mindre adgang betyder mindre risiko.

Men mikrosegmentering har sine ulemper. Den er mere kompleks at implementere, kræver et grundigt overblik over applikationernes afhængigheder og kræver ekspertise for at undgå at forstyrre legitime arbejdsgange. Gøres det forkert, skaber det frustration hos brugerne og fremmer skygge-IT. Gøres det rigtigt, reducerer det drastisk omfanget af skaderne ved et enkelt sikkerhedsbrud.

Dette er et af de områder, hvor designkompetence og erfaring virkelig gør en forskel – og hvor en forkert beslutning i den indledende fase kan tage år at rette op på.

Automatisk patching og eksponeringsvinduet

Selv med en effektiv adgangskontrol er der stadig sårbarheder. Software udvikles af mennesker, og mennesker begår fejl. Leverandørerne udsender opdateringer, men det tager sjældent kun et øjeblik at installere dem.

Den forsinkelse skaber netop det, angribere er på udkig efter: en eksponeringsvindue – tiden fra en sårbarhed bliver kendt, til dine systemer er beskyttet. Med automatiserede scannings- og udnyttelsesværktøjer måles dette tidsrum ofte i timer.

For at lukke den skal to ting være opfyldt:

1. Automatisk opdatering, så opdateringerne implementeres så hurtigt, som driften tillader det
2. Arkitektur, der understøtter opdateringer uden nedetid – redundans, løbende opdateringer, canary-implementeringer

Automatisering alene er ikke nok. Den skal være indbygget i systemet. Igen handler det om, hvordan systemerne er opbygget fra starten.

Virtuel patching til OT-systemer og ældre systemer i kritisk infrastruktur

Ikke alle systemer kan opdateres. Driftsteknologi i kraftværker, vandrensningsanlæg, produktionsvirksomheder og transportsektoren kører ofte på platforme, der er flere årtier gamle, certificeret til specifikke forhold eller for kritiske til at kunne tages ud af drift for at blive opdateret. Ældre applikationer inden for sundhedssektoren, finanssektoren og den offentlige forvaltning står over for lignende begrænsninger.

Især for den nordiske energisektor er dette ikke et teoretisk problem. Konvergensen mellem IT og OT er en realitet: SCADA- og styresystemer, der tidligere var isoleret fra omverdenen, er nu integreret med virksomhedens netværk, cloud-overvågning og fjernbetjeningscentre. Angrebsfladen er vokset hurtigere end evnen til at modernisere den underliggende teknologi.

Det er her, hvor virtuel patching bliver afgørende. I stedet for at ændre det sårbare system selv, indføres der beskyttende foranstaltninger omkring det:

• Netværkstrafikken kontrolleres og filtreres
• Kendte angrebsmønstre blokeres, inden de når frem til systemet
• Mistænkelig adfærd udløser alarmer og inddæmning

Det er ikke en erstatning for opdateringer, hvor det er muligt at installere opdateringer. Men for kritiske systemer, der ikke kan ændres, holder det sikkerhedshullet lukket, indtil en modernisering kan gennemføres – ofte over en periode på flere år.

For operatører af kritisk infrastruktur er denne tilgang ikke længere valgfri. Den udgør grundlaget for en forsvarlig sikkerhedsstrategi i henhold til NIS2 og sektorspecifik lovgivning.

Assumed Breach og NIS2: indbygget compliance fra start

NIS2 og de nationale gennemførelser heraf (herunder loven om digital sikkerhed i Norge) underbygger det, som sikkerhedsteams har sagt i årevis: Robusthed skal indbygges fra starten, ikke eftermonteres.

At forsøge at påtvinge overholdelse af reglerne på en eksisterende arkitektur er dyrt, tidskrævende og som regel ufuldstændigt. De organisationer, der klarer sig godt med NIS2, er dem, der fra starten betragter det som et arkitektonisk krav:

• Risikovurderingen danner grundlag for designbeslutningerne, ikke kun for dokumentationen
• Logning, overvågning og hændelsesrapportering er indbygget i systemet og ikke tilføjet efterfølgende
• Risici forbundet med leverandører og tredjeparter er en integreret del af arkitekturen, ikke en separat proces

Når det gøres rigtigt, bliver overholdelse af reglerne et resultat af godt design snarere end et sideløbende projekt. Og – hvilket er afgørende for bestyrelser og ledelsen – det kan forsvares, når det bliver gransket.

Håndtering af sikkerhedshændelser: forberedelse på det uundgåelige

Selv de bedst udformede systemer vil opleve sikkerhedshændelser. Assumed Breach tager højde for dette og forbereder sig på det.

Denne forberedelse er mere end blot en dokumenteret plan, der ligger i en SharePoint-mappe. Modne organisationer gennemfører nu regelmæssigt simuleringer – bordøvelser, red team-øvelser og “krigsspil” i fuld skala – hvor håndteringen af sikkerhedshændelser afprøves under realistiske presforhold.

Årsagen er enkel: Når en reel hændelse indtræffer, er der ikke tid til at lære. Roller skal være klare. Beslutninger skal være forhåndsgodkendt. Eskaleringsprocedurerne skal være kendt. Den første time af en alvorlig hændelse lægger kursen for de næste tre måneder.

På tværs af Zero Trust, automatisering, segmentering, compliance og respons går der et mønster igen: Sikkerhed, der er indbygget fra starten, holder. Sikkerhed, der er tilføjet efterfølgende, gør ikke.

Fra teori til praksis: Sådan hjælper NetNordic

“Assumed Breach” er en tankegang, men det er netop i forbindelse med at omsætte den til arkitektur, drift og styring, at de fleste organisationer har svært ved det. Det er her, det er afgørende at have den rette partner.

NetNordic samarbejder med nordiske organisationer inden for energisektoren, den offentlige sektor, finanssektoren og erhvervslivet om at omsætte disse principper til praktiske og robuste arkitekturer. Det omfatter:

• Cyberadvarsel – strategi, arkitekturvurderinger, NIS2-parathed og Zero Trust-køreplaner
• Offensiv sikkerhed – penetrationstest, Red Team-øvelser og øvelser baseret på antaget indtrængen for at teste forsvaret mod virkelige angriberes adfærd
• Administreret SOC – Overvågning og reaktion døgnet rundt, baseret på den antagelse, at der før eller senere vil slippe noget igennem
• Sikre infrastruktur- og netværkstjenester – udviklet med segmentering, automatisering og robusthed som standard

Målet er ikke fuldstændig forebyggelse. Det handler om at skabe modstandsdygtighed: systemer, der holder trusler i skak, driftsprocesser, der reagerer effektivt, og en virksomhed, der fortsætter med at køre.

Ofte stillede spørgsmål

Hvad er tankegangen bag »Assumed Breach«? “Assumed Breach” er en tilgang til cybersikkerhed, der bygger på den antagelse, at forebyggelse nogle gange vil slå fejl. I stedet for udelukkende at satse på at holde angribere ude, fokuserer den på at udvikle systemer, processer og beredskab, der kan begrænse skaderne, når et sikkerhedsbrud opstår.

Hvordan adskiller »Assumed Breach« sig fra Zero Trust? Zero Trust er det arkitektoniske princip – stol aldrig på noget, men kontroller altid. »Assumed Breach« er den bredere operationelle tankegang, som Zero Trust ofte indgår i. Zero Trust svarer på hvordan Du designer adgangen; Svar på antagede sikkerhedsbrud hvorfor – fordi du designer med henblik på det øjeblik, hvor noget går igennem.

Er begrebet »formodet misligholdelse« relevant for små og mellemstore virksomheder? Ja. Faktisk har mindre organisationer ofte større gavn af det, fordi de har mindre kapacitet til at håndtere en større hændelse. Principperne – mindst mulig adgang, segmentering og gennemtestede beredskabsplaner – fungerer lige så godt i mindre organisationer som i større.

Hvordan passer »Assumed Breach« ind i NIS2?NIS2 stiller udtrykkeligt krav om risikostyring, håndtering af sikkerhedshændelser og sikkerhed i forsyningskæden. En »Assumed Breach«-arkitektur imødekommer disse krav som en integreret del af designet, snarere end som en separat overholdelsesproces.

Hvor skal en organisation begynde? De fleste organisationer opnår den største effekt ved at fokusere på tre ting: en vurdering af den aktuelle situation inden for identitet og adgang, en gennemgang af netværkssegmenteringen (især mellem IT og OT) samt en gennemtestet beredskabsplan. Alene disse tre tiltag udfylder størstedelen af hullet.

Klar til det, der venter forude?

Hvis I er i gang med at opbygge jeres organisations forsvar mod de udfordringer, der venter i 2026 og fremover, er udgangspunktet at få et overblik over, hvor I står i dag.