Neste generasjons brannmuradministrasjon: Fra regelkaos til zero-trust mikrosegmentering
Tilbake til bloggen

Neste generasjons brannmuradministrasjon: Fra regelkaos til zero-trust mikrosegmentering

Forestill deg dette: sikkerhetsteamet ditt sitter og vurderer en brannmur-endringsforespørsel kl. 23 på en fredagskveld. De skal åpne port 443 mellom to interne subnett. I utgangspunktet enkelt, helt til dere henter opp regelsettet og stirrer på 14 000 regler som har samlet seg opp gjennom et tiår med oppkjøp, migreringer og raske midlertidige løsninger. Ingen vet hvilke regler som fortsatt er nødvendige. Ingen vet hvem som skrev regel 7 843. Og et sted i denne jungelen av allow/deny-regler er det tre motstridende policies som stille undergraver hverandre. Dette er ikke en hypotese. Dette er en vanlig tirsdag for de fleste sikkerhetsteam i store virksomheter, og akkurat derfor har brannmuradministrasjon blitt en av de mest undervurderte utfordringene i moderne cybersikkerhet.

Problemet med eksplosiv regelvekst

Brannmurer ble designet for å håndheve enkel nettverkssegmentering: tillat dette, nekt det, logg alt. I teorien skal en godt vedlikeholdt brannmurpolicy være ren, minimal og enkel å revidere. I praksis vokser bedriftsbrannmurer organisk over år og blir til slutt helt umulige å administrere.

Tallene er bekymringsverdige. Virksomheter med mer enn 1 000 ansatte opererer typisk med brannmurer som har mellom 5 000 og 50 000 regler. Store konsern med komplekse, flersitede miljøer kan ha over 100 000 regler på tvers av brannmurporteføljen. Forskning viser jevnlig at 30–40 prosent av reglene enten er ubrukte, overflødige eller direkte i konflikt med andre regler i samme regelsett.

Hvordan skjer dette? Flere faktorer bidrar til regelveksten:

  • Prosjektbasert regelopprettelse: Nye applikasjoner, integrasjoner og sky-migreringer genererer endringsforespørsler. Regler legges til for prosjektet, men fjerning av regler når prosjektet er ferdig prioriteres sjelden.
  • Frykt for å ødelegge noe: Ingen vil være ansvarlig for et avbrudd fordi en regel ble fjernet. Når i tvil – la den stå. Denne defensive holdningen gjør at regler hoper seg opp i det uendelige.
  • Oppkjøp og fusjoner: Når man tar inn et annet selskaps nettverk, får man også med deres brannmurpolicyer – ofte med helt andre navnekonvensjoner, IP-oppsett og dokumentasjonsstandarder.
  • Skyggeregler: Regler som legges til utenfor formelle endringsprosesser, gjerne av velmenende ingeniører som jobber rundt langsomme godkjenningsflyter, skaper udokumenterte avhengigheter som gjør opprydding enda vanskeligere.
  • Dokumentasjonsgjeld: Regler uten kommentarer eller sakshenvisninger blir til arkeologiske gåter. Ble regel 4 521 lagt til for lønnssystemet som ble utfaset i 2019, eller er den fortsatt kritisk for noe som aldri ble dokumentert?

Den operative kostnaden ved denne kompleksiteten er stor. Sikkerhetsteam bruker timer på å analysere konsekvenser av selv enkle endringer. Revisjoner blir smertefulle øvelser i å rekonstruere hensikt fra policy. Og sikkerhetsposisjonen forverres faktisk fordi motstridende regler åpner utilsiktede veier gjennom nettverket.

Hvorfor tradisjonelle brannmurer ikke lenger er nok

Selv en perfekt vedlikeholdt tradisjonell brannmurpolicy er ikke lenger tilstrekkelig for å beskytte et moderne bedriftsnettverk. Trussellandskapet har endret seg fundamentalt, og perimeter-baserte sikkerhetsmodeller har ikke holdt tritt.

Den største svakheten er lateral bevegelse. Tradisjonelle brannmurarkitekturer håndhever strenge north-south-kontroller – trafikk inn og ut av nettverket, men har ofte minimale restriksjoner på east-west-trafikk mellom systemer i samme tillitsone. Angripere har lært å utnytte dette. Når de først har fått et fotfeste gjennom phishing, kompromitterte legitimasjoner eller en sårbar internett-tilgjengelig applikasjon, beveger de seg sidelengs gjennom det interne nettverket med minimal motstand. SolarWinds-angrepet i 2020, Colonial Pipeline-hendelsen i 2021 og en rekke store ransomware-kampanjer fulgte alle dette mønsteret: begrenset initial tilgang, omfattende lateral bevegelse, katastrofal skade.

Kryptert trafikk utgjør en annen fundamental utfordring. I dag er mer enn 90 prosent av internettrafikken kryptert med TLS. Tradisjonelle brannmurer inspiserer pakkedatahoder og porter, men kan ikke se inn i krypterte sesjoner. Skadevare-kommunikasjon, dataeksfiltrering og lateral bevegelse bruker i økende grad krypterte kanaler nettopp for å unngå deteksjon.

Applikasjonslagsangrep omgår også portbaserte kontroller. Å tillate HTTPS-trafikk på port 443 betyr å tillate et enormt spekter av applikasjoner, noen legitime, andre potensielt ondsinnede, som alle bruker samme port. Tradisjonelle stateful brannmurer har ingen måte å skille godkjente SaaS-applikasjoner fra ondsinnede verktøy som tunnelerer trafikk over vanlige porter.

Disse faktorene tilsier at perimeter-brannmurer fortsatt er nødvendige, men ikke lenger tilstrekkelige som hovedforsvar. De må suppleres med neste generasjons funksjonalitet og i økende grad med zero-trust-arkitekturprinsipper.

Neste generasjons brannmur (NGFW) – hva leverer de egentlig?

Neste generasjons brannmurer utvider tradisjonell pakkefiltrering med avansert inspeksjon som løser mange av begrensningene i eldre løsninger. Forstå hva NGFW faktisk tilfører, og hvor grensene ligger, er viktig for gode arkitekturvalg.

Applikasjonsbevissthet og kontroll

Tradisjonelle brannmurer jobber primært med porter og protokoller. NGFW bruker deep packet inspection (DPI) og applikasjonssignaturer til å identifisere trafikk basert på applikasjon, uavhengig av port eller protokoll. Dette gjør det mulig å tillate Microsoft Teams videosamtaler samtidig som man blokkerer uautoriserte skjermdelingsverktøy, selv om begge bruker port 443. Resultatet er langt mer presise og effektive policies enn portbaserte regler klarer.

Integrert IPS og IDS

Integrerte Intrusion Prevention (IPS) og Intrusion Detection Systems (IDS) fjerner behovet for separate appliances. Plattformene kombinerer signaturbasert deteksjon med adferdsanalyse og mates kontinuerlig med oppdaterte trusselinformasjonsfeeds. Sikkerhetshendelser korreleres direkte med brannmurpolicyer i samme konsoll, noe som reduserer alert fatigue og forkorter utredningstiden betydelig.

SSL,TLS inspeksjon

SSL,TLS inspeksjon (dekryptering) lar brannmuren inspisere kryptert trafikk for trusler, skadevare og C2 kommunikasjon. Dette er kritisk siden over 90 prosent av all internettrafikk i dag er kryptert. Inspeksjonen krever god sertifikathåndtering, ytelsesberegning og unntak for personvernfølsom trafikk.

Brukerbaserte policies

Gjennom integrasjon med Active Directory, LDAP og RADIUS kan policies håndheves basert på brukeridentitet i stedet for kun IP adresse. Dette er en forutsetning for zero trust og gir fleksibel tilgangskontroll i dynamiske miljøer uten å måtte bruke VLAN segmentering.

Overgangen til zero-trust mikrosegmentering

Zero-trust micro-segmentation: from flat perimeter to intent-based policy From flat perimeter with 6,000 rules to intent-based micro-segmentation
<!-- Resten av SVG-en er uendret -->
<g font-family="system-ui" font-size="10" fill="#e8edf5" text-anchor="middle">
  <text x="170" y="58" font-weight="700" font-size="11" fill="#ff6b6b">Legacy perimeter</text>
  <rect x="40" y="70" width="260" height="240" rx="12" fill="none" stroke="#ff6b6b" stroke-width="1.5" stroke-dasharray="5 4"></rect>
  <rect x="60" y="95" width="220" height="50" rx="8" fill="rgba(255,107,107,0.06)" stroke="rgba(255,107,107,0.35)" stroke-width="1"></rect>
  <text x="170" y="115" font-weight="700" fill="#e8edf5">Internal network</text>
  <text x="170" y="132" font-size="9" fill="rgba(255,255,255,0.55)">users + servers + printers + OT</text>
  <g transform="translate(60,160)"><rect width="220" height="16" rx="3" fill="rgba(255,107,107,0.12)" stroke="rgba(255,107,107,0.3)" stroke-width="0.6"></rect><text x="110" y="12" font-size="9" fill="rgba(255,255,255,0.55)">any → any : allow established</text></g>
  <g transform="translate(60,180)"><rect width="220" height="16" rx="3" fill="rgba(255,107,107,0.12)" stroke="rgba(255,107,107,0.3)" stroke-width="0.6"></rect><text x="110" y="12" font-size="9" fill="rgba(255,255,255,0.55)">internal → internet : allow</text></g>
  <g transform="translate(60,200)"><rect width="220" height="16" rx="3" fill="rgba(255,107,107,0.12)" stroke="rgba(255,107,107,0.3)" stroke-width="0.6"></rect><text x="110" y="12" font-size="9" fill="rgba(255,255,255,0.55)">rule #4127 : temp contractor 2019</text></g>
  <g transform="translate(60,220)"><rect width="220" height="16" rx="3" fill="rgba(255,107,107,0.12)" stroke="rgba(255,107,107,0.3)" stroke-width="0.6"></rect><text x="110" y="12" font-size="9" fill="rgba(255,255,255,0.55)">rule #5882 : owner unknown</text></g>
  <g transform="translate(60,240)"><rect width="220" height="16" rx="3" fill="rgba(255,107,107,0.18)" stroke="rgba(255,107,107,0.5)" stroke-width="0.6"></rect><text x="110" y="12" font-size="9" fill="#ff6b6b" font-weight="700">+ 5,996 rules...</text></g>
  <g transform="translate(170,283)"><text y="0" font-weight="700" font-size="16" fill="#ff6b6b">6,000+ rules</text><text y="15" font-size="9" fill="rgba(255,255,255,0.55)">40% stale, 12% shadowed, no owner tracking</text></g>
</g>

<g transform="translate(360,180)">
  <path d="M -18 0 L 18 0" stroke="url(#fw-grad)" stroke-width="2" marker-end="url(#fw-arr)"></path>
</g>
<defs>
  <marker id="fw-arr" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="8" markerHeight="8" orient="auto">
    <path d="M0,0 L10,5 L0,10 z" fill="#00ff87"></path>
  </marker>
</defs>

<g font-family="system-ui" font-size="10" fill="#e8edf5" text-anchor="middle">
  <text x="560" y="58" font-weight="700" font-size="11" fill="#00ff87">Zero-trust micro-segments</text>
  <rect x="400" y="70" width="280" height="240" rx="12" fill="none" stroke="#00ff87" stroke-width="1.5"></rect>
  <!-- Alle de andre rektanglene og tekstene er uendret -->
  <g><rect x="418" y="92" width="80" height="44" rx="6" fill="rgba(0,255,135,0.08)" stroke="#00ff87" stroke-width="1"></rect><text x="458" y="110" font-weight="700" font-size="10">Users</text><text x="458" y="124" font-size="8" fill="rgba(255,255,255,0.6)">identity + device</text></g>
  <g><rect x="510" y="92" width="80" height="44" rx="6" fill="rgba(0,212,255,0.08)" stroke="#00d4ff" stroke-width="1"></rect><text x="550" y="110" font-weight="700" font-size="10">Apps</text><text x="550" y="124" font-size="8" fill="rgba(255,255,255,0.6)">by workload tag</text></g>
  <g><rect x="602" y="92" width="72" height="44" rx="6" fill="rgba(196,167,255,0.08)" stroke="#c4a7ff" stroke-width="1"></rect><text x="638" y="110" font-weight="700" font-size="10">SaaS</text><text x="638" y="124" font-size="8" fill="rgba(255,255,255,0.6)">sanctioned list</text></g>
  <g><rect x="418" y="148" width="80" height="44" rx="6" fill="rgba(255,179,71,0.08)" stroke="#ffb347" stroke-width="1"></rect><text x="458" y="166" font-weight="700" font-size="10">OT / ICS</text><text x="458" y="180" font-size="8" fill="rgba(255,255,255,0.6)">Purdue L2/L3</text></g>
  <g><rect x="510" y="148" width="80" height="44" rx="6" fill="rgba(0,212,255,0.08)" stroke="#00d4ff" stroke-width="1"></rect><text x="550" y="166" font-weight="700" font-size="10">Servers</text><text x="550" y="180" font-size="8" fill="rgba(255,255,255,0.6)">role-based</text></g>
  <g><rect x="602" y="148" width="72" height="44" rx="6" fill="rgba(255,107,107,0.08)" stroke="#ff6b6b" stroke-width="1"></rect><text x="638" y="166" font-weight="700" font-size="10">IoT</text><text x="638" y="180" font-size="8" fill="rgba(255,255,255,0.6)">isolated VLAN</text></g>
  <g transform="translate(418,210)"><rect width="256" height="42" rx="6" fill="rgba(0,255,135,0.08)" stroke="#00ff87" stroke-width="1"></rect><text x="128" y="14" font-size="9" fill="rgba(255,255,255,0.5)" font-weight="700" letter-spacing="0.08em">INTENT-BASED POLICY</text><text x="128" y="30" font-size="10" font-weight="700" fill="#00ff87">allow: Users/finance → Apps/ERP : HTTPS</text></g>
  <g transform="translate(540,283)"><text y="0" font-weight="700" font-size="16" fill="#00ff87">~120 intents</text><text y="15" font-size="9" fill="rgba(255,255,255,0.55)">every rule owned, AI-reviewed quarterly, audit trail</text></g>
</g>

<rect x="40" y="325" width="640" height="34" rx="8" fill="rgba(255,255,255,0.03)" stroke="rgba(255,255,255,0.08)" stroke-width="1"></rect>
<g font-family="system-ui" font-size="11">
  <text x="60" y="345" fill="#e8edf5" font-weight="700">East-West inspection:</text>
  <text x="180" y="345" fill="rgba(255,255,255,0.55)" font-size="10">TLS decryption + app-ID + user-ID on every segment boundary</text>
  <text x="660" y="345" fill="#00ff87" font-weight="700" text-anchor="end">blast radius: one segment</text>
</g>
En typisk eldre brannmurportefølje bærer på tusenvis av akkumulerte regler uten eierskap og med betydelig eksponering for shadow rules. Zero-trust mikrosegmentering erstatter dette med et lite antall intensjonsbaserte policies som refererer til identitet, workload og app-ID i stedet for IP-adresser. Hver grense blir et inspeksjonspunkt. Et kompromiss begrenses til ett segment i stedet for hele det interne nettverket.

Zero-trust-arkitektur er ikke en produktkategori – det er en designtilnærming. Hovedprinsippet er enkelt: aldri stol, alltid verifiser. Ingen bruker, enhet eller workload skal få implisitt tillit basert på nettverksplassering. Hver tilgangsforespørsel må autentiseres, autoriseres og kontinuerlig valideres.

Fra nettverkssoner til workload-identitet

I et mikrosegmentert miljø har hver workload, enten det er en virtuell maskin, container, serverless-funksjon eller fysisk server, en kryptografisk verifisert identitet. Sikkerhetspolicies defineres ut fra workload-identiteter og tillatte kommunikasjonsmønstre, ikke IP-adresser og nettverkssegmenter.

Software-Defined Perimeter (SDP)

Software-Defined Perimeter (SDP) tar zero-trust-prinsippene et skritt videre ved å gjøre nettverksressurser usynlige for uautoriserte brukere. I et tradisjonelt nettverk kan en angriper som har fått tilgang til det interne nettverket, oppdage servere, skanne etter tjenester og forsøke tilkoblinger lenge før de utnytter en sårbarhet. SDP fjerner denne rekognoseringsmuligheten ved å kreve autentisering før noen nettverkstilkobling etableres. Brukere og enheter autentiserer seg mot en controller, som deretter dynamisk åpner kun de nødvendige nettverksbanene for autoriserte sesjoner.

SDP er spesielt verdifullt for eksterne tilgangsscenarier. Den erstatter tradisjonelle VPN-løsninger med en modell der man verifiserer enhetens tilstand (device posture), brukeridentitet og kontekstuelle faktorer – som tidspunkt, lokasjon og adferdsavvik – før tilgang gis til spesifikke applikasjoner, i stedet for bred nettverkstilgang.

Mikrosegmentering i datasentre og sky

Implementering av mikrosegmentering i datasentre og sky krever ulike tilnærminger avhengig av infrastruktur. I virtualiserte miljøer håndhever distribuert brannmur på hypervisor nivå east,west policies uten at trafikken må sendes gjennom fysiske appliances. I Kubernetes miljøer sørger nettverkspolicies og service meshes for kontroll på workload nivå. I offentlige skyer gir security groups, network ACLs og cloud native verktøy workload identitetsbaserte kontroller integrert med IAM.

Utfordringen med administrasjon er reell. Å opprettholde konsistente policies på tvers av heterogene miljøer krever sentralisert policy orkestrering som abstraherer bort infrastrukturspesifikke detaljer. Dette er et aktivt utviklingsområde, og det dukker stadig opp plattformer som tilbyr enhetlig policyadministrasjon på tvers av fysisk, virtuelt og skybasert infrastruktur.

AI-drevet policyoptimalisering

Å løse problemet med regelvekst krever mer enn gode intensjoner og sporadiske opprydningsprosjekter. På skalaen med tusenvis av regler på tvers av dusinvis av brannmurer er manuell analyse ikke mulig. AI og maskinlæringsbaserte verktøy for policyoptimalisering gjør nå en betydelig forskjell.

Automatisert regelanalyse og opprydding

Moderne brannmuradministrasjonsplattformer analyserer regelsett for å identifisere:

  • Ubrukte regler: Regler som ikke har matchet trafikk i en konfigurert observasjonsperiode. Disse er kandidater for fjerning, men krever validering for å sikre at manglende trafikk ikke skyldes en ødelagt avhengighet.
  • Skyggeregler: Regler som aldri treffer fordi en bredere regel over dem allerede fanger opp samme trafikk. Disse har ingen effekt og bør alltid fjernes.
  • Overflødige regler: Regler som dupliserer effekten av andre regler og dermed øker kompleksiteten uten å tilføre sikkerhetsverdi.
  • For åpne regler: Regler med unødvendig bredt omfang, for eksempel any til any eller alle tjenester, som kan strammes inn uten å påvirke legitim trafikk.
  • Motstridende regler: Regler som står i konflikt med hverandre og skaper uønsket eller uforutsigbar oppførsel.

AI-drevet analyse går lenger enn statisk regelgjennomgang. Ved å sammenligne faktiske trafikkstrømmer mot regelsettet foreslår verktøyene optimaliseringer basert på reell bruk, noe som reduserer risikoen for at opprydding bryter legitime trafikkmønstre.

Risikoscoring og prioritering

Ikke alle brannmurregler har lik risiko. AI-baserte risikoscoremodeller vurderer regler ut fra faktorer som sensitiviteten til ressursene de eksponerer, hvor bred tilgangen er, regelens alder, manglende dokumentasjon og trusselinformasjon om kjente angrepsmønstre. Dette gjør at sikkerhetsteam kan prioritere gjennomgang og opprydding på de reglene som betyr mest.

Endringskonsekvensanalyse

Før en brannmurendring iverksettes, kan AI-plattformer modellere effekten mot observerte trafikkmønstre. Verktøyene forutsier om endringen vil bryte legitime flyter og identifiserer utilsiktede konsekvenser. Dette reduserer risikoen for nedetid dramatisk og gir teamene trygghet til å gjennomføre nødvendige opprydninger som tidligere ble ansett som for risikable.

Beste praksis for brannmuradministrasjon

Teknologi alene løser ikke problemet. God brannmuradministrasjon krever disiplinerte prosesser og forpliktelse fra organisasjonen.

Streng endringshåndtering

Enhver endring av brannmurregler, enten opprettelse, endring eller sletting, bør følge en dokumentert prosess som fanger opp forretningsbegrunnelse, ansvarlig team og applikasjon, forventet trafikkmønster, godkjenningsflyt, implementeringslogg og en definert revisjonsdato. Denne metadataen er grunnlaget for fremtidig opprydding.

Automatiserte verktøy integreres med ITSM plattformer for å håndheve prosessen, kreve sakshenvisninger og automatisk knytte regler til opprinnelig endringsforespørsel. Dette skaper en revisjonsspor som gjør compliance rapportering mye enklere.

Regelmessige policygjennomganger

Brannmurpolicyer bør gjennomgås formelt etter en fast plan, minimum årlig og kvartalsvis for kritiske segmenter. Gjennomgangene bør inkludere identifisering og fjerning av ubrukte regler, recertifisering av regler av applikasjonseiere, compliance kartlegging, risikovurdering mot gjeldende trusselbilde og oppdatering av dokumentasjon.

Dokumentasjonsstandarder

Hver regel bør minst inneholde: beskrivende navn, ITSM sakshenvisning, hvilken applikasjon eller tjeneste den støtter, regelansvarlig, opprettelsesdato og siste revisjonsdato. Disse standardene bør håndheves gjennom endringsprosessen.

Sentralisert brannmuradministrasjon i stor skala

Administrasjon av brannmurpolicy på tvers av titalls eller hundrevis av enheter krever sentraliserte plattformer som gir ett enkelt administrasjonsgrensesnitt for policyopprettelse, distribusjon, overvåking og rapportering.

Enterprise løsninger tilbyr enhetlige policybiblioteker, sentralisert objektadministrasjon og rollebasert tilgangskontroll. I multi vendor miljøer, som er vanlig etter oppkjøp, er det ekstra utfordrende å holde policyintensjonen konsistent. Vendor uavhengige orkestreringsverktøy løser mye av dette, men krever grundig evaluering og investering.

ZeroSubnet Managed Firewall Service: Vi skaper orden i brannmuren din

Hos ZeroSubnet har vi bygget vår managed firewall tjeneste rundt utfordringene beskrevet i denne artikkelen. Vi bistår norske virksomheter innen finans, helsevesen, industri, retail og offentlig sektor med å ta det operative ansvaret for brannmuradministrasjon, samtidig som vi leverer målbare forbedringer i sikkerhetsposisjon og policykvalitet.

Tjenesten dekker hele livssyklusen. Vi starter alltid med en grundig policyrevisjon der vi analyserer eksisterende regelsett, identifiserer ubrukte, overflødige og for åpne regler, og leverer en prioritert tiltaksplan. Vi etablerer eller styrker endringsprosesser med integrasjon mot deres ITSM plattform, driver 24/7 overvåking og håndterer endringer innenfor avtalte SLAer.

Der det er hensiktsmessig veileder vi kundene gjennom overgangen fra tradisjonell perimeterbeskyttelse til zero trust mikrosegmentering. Dette er en strategisk utvikling som reduserer risiko for lateral bevegelse betydelig og forbereder virksomheten på skybasert og hybrid arbeidsvirkelighet.

Neste steg: Ta kontakt med ZeroSubnet for å booke en brannmur policyvurdering. Vi analyserer ditt nåværende regelsett og leverer en konkret rapport med tilstandsoversikt, identifiserte risikoer og anbefalte tiltak. For virksomheter som er klare for en managed tjeneste, utarbeider vi gjerne et skreddersydd forslag.

Meld deg på nyhetsbrevet

Hold deg oppdatert på hva vi driver med
  • Takk, sjekk eposten din

    Takk for at du meldte deg på, vi har sendt deg en epost med en link du må trykke på for å bekrefte medlemskapet

©2026 ZeroSubnet AS  ·  Org. nr. 923 669 442
Leif Tronstads plass 6, 1337 Sandvika