Granskning av brandväggsregler för ISO 27001, NIS2, DORA och GDPR
Klockan är 07:42 en måndagsmorgon. CISO hos en växande SaaS- och FinTech-leverantör stirrar på tre separata meddelanden.
Det första kommer från SOC. En komprometterad utvecklararbetsstation försökte under natten ansluta till ett internt databassubnät. Trafiken blockerades, men analytikern vill få bekräftat att brandväggsregeln är avsiktlig, aktuell och godkänd.
Det andra kommer från en stor företagskund. Kunden vill ha underlag som visar att produktions-, utvecklings-, organisations- och supportmiljöer är segmenterade, att brandväggsregler granskas och att undantag löper ut.
Det tredje kommer från chefen för regelefterlevnad. Organisationen omfattas av NIS2 som viktig digital leverantör, har GDPR-ansvar som personuppgiftsbiträde och har kunder inom finansiella tjänster som efterfrågar DORA-liknande underlag för IKT-risk. Styrelsen vill veta om samma ISO/IEC 27001:2022-underlag kan besvara alla tre.
Därefter kommer efterincidentgranskningen. En utvecklingsserver var nära att exponeras mot internet under en sen ändring. Ingen kunddata gick förlorad, men forensikteamet upptäckte något värre än det ursprungliga misstaget: en fem år gammal brandväggsregel för ”tillfälligt test” tillät fortfarande bred rörelse mellan utveckling och produktion. Om en angripare hade fått åtkomst skulle nätverket ha erbjudit mycket begränsat motstånd.
Det är då många organisationer upptäcker en smärtsam sanning. De kan ha brandväggar, VLAN, säkerhetsgrupper i moln och diagram, men sakna styrning av segmenteringszoner, regelägarskap, tillfällig åtkomst, ändringsgodkännanden, revalidering och revisionsunderlag.
År 2026 är ”vi har en brandvägg” inte ett försvarbart svar. Revisorer, tillsynsmyndigheter, kunder och försäkringsgivare vill se bevis på att nätverk är avsiktligt separerade, att trafik styrs av verksamhetsbehov, att riskfyllda undantag hanteras och att loggar visar att kontrollerna fungerar.
Varför brandväggsstyrning nu är en styrelsefråga
Nätverkssegmentering betraktades tidigare som en teknisk ingenjörsfråga. Infrastrukturteam ägde VLAN, brandväggsadministratörer underhöll regeluppsättningar, molnteam hanterade säkerhetsgrupper och regelefterlevnad såg endast ett diagram under revisioner.
Den driftmodellen fungerar inte längre.
NIS2-direktivet kräver att väsentliga och viktiga enheter inför lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem. Article 21 omfattar policyer för riskanalys, incidenthantering, kontinuitet, säkerhet i leveranskedjan, säkerhet vid anskaffning och underhåll, effektivitetsbedömning, grundläggande cyberhygien, åtkomstkontroll och tillgångshantering. Ledningsorgan ska godkänna och övervaka dessa åtgärder för hantering av cybersäkerhetsrisker.
DORA gäller från den 17 januari 2025 för många finansiella entiteter och gör IKT-riskhantering till en styrd och dokumenterad disciplin. Articles 5, 6 och 8 kräver styrning, ett ramverk för IKT-riskhantering samt identifiering av IKT-stödda verksamhetsfunktioner, informationstillgångar, IKT-tillgångar, beroenden, kritiska tillgångar och sammankopplingar. Articles 9, 10 och 11 behandlar skydd, förebyggande, detektering, respons och återhämtning. Articles 24 till 27 kräver testning av digital operativ motståndskraft, inklusive avancerad testning för vissa entiteter. Det gör segmentering till en motståndskraftsfråga, inte bara en brandväggsfråga.
GDPR lägger till lagret för ansvarsskyldighet inom dataskydd. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken, inklusive konfidentialitet, integritet, tillgänglighet och motståndskraft. Article 5(1)(f) kräver integritet och konfidentialitet, och Article 5(2) kräver ansvarsskyldighet. Om system med personuppgifter kan nås från komprometterade slutpunkter, gästnätverk eller ohanterade tredjepartsvägar kan en tillsynsmyndighet fråga varför dessa vägar fanns.
ISO/IEC 27001:2022 ger den ledningssystemgrund som kopplar samman dessa skyldigheter. Standarden kräver omfattning, krav från intressenter, riskbedömning, riskbehandling, tillämpbarhetsförklaring, operativ planering och styrning, ledningens ansvarsskyldighet, mätbara mål, dokumenterad information och ständig förbättring. Annex A, med stöd av vägledning i ISO/IEC 27002:2022, omfattar de kontrollområden som behövs för leverantörsrisker, molntjänster, loggning, övervakning, säker arkitektur, miljöseparation och ändringshantering.
Poängen är enkel: nätverkssegmentering och granskning av brandväggsregler är numera styrningsunderlag.
Clarysecs driftmönster: 8.20, 8.22 och 8.32
Clarysec behandlar segmentering och brandväggsgranskning som ett gemensamt driftmönster över ISO/IEC 27002:2022-kontroller, inte som isolerade tekniska uppgifter.
De tre primära kontrollerna är:
| ISO/IEC 27002:2022-område | Styrningsfråga | Underlag som revisorer förväntar sig |
|---|---|---|
| 8.20 Nätverkssäkerhet | Är nätverk utformade, hanterade, övervakade och skyddade utifrån risk? | Arkitekturdiagram, brandväggsstandarder, säkra nätverksrutiner, övervakningsloggar, IDS/IPS-underlag, exempel på konfigurationer för VPN och molnnätverk |
| 8.22 Segregering av nätverk | Är zoner separerade utifrån känslighet, funktion och tillitsnivå? | Zonmodell, dataflödesmatris, VLAN- och subnätsdesign, DMZ-gränser, brandväggsregler mellan zoner, resultat från segmenteringstester |
| 8.32 Ändringshantering | Utvärderas, godkänns, testas, loggas och granskas regeländringar? | Ändringsärenden, riskbedömningar, godkännanden, återställningsplaner, efterimplementeringsgranskningar, register över akuta ändringar |
I Zenith Blueprint: en revisors 30-stegsfärdplan [ZB] placerar Clarysec nätverkssäkerhet i fasen Kontroller i praktiken, steg 20: kontroller 8.18 till 8.26. Guiden formulerar den centrala revisionsfrågan tydligt:
”I grunden kräver denna kontroll att organisationer säkerställer att nätverk är säkra genom arkitektur, inte bara genom att lägga till brandväggar eller antivirus i efterhand. Det innebär att tänka strategiskt kring nätverkssegmentering, åtkomstkontroll, kryptering under överföring, övervakning och försvar på djupet. Det börjar med en enkel fråga: Vem och vad kommunicerar, och bör de göra det?”
Frågan ”vem och vad kommunicerar, och bör de göra det?” är den bästa praktiska startpunkten för granskning av brandväggsregler. Den flyttar samtalet från tusentals kryptiska ACL-poster till verksamhetsmotiverade flöden.
Samma Zenith Blueprint instruerar team att bedöma nätverksarkitekturen genom att verifiera att brandväggsregler, IPS/IDS och konfigurationer för fjärråtkomst är aktuella och härdade, och att bekräfta att säkerhetsgrupper i moln, routing och VPC- eller subnätsregler motsvarar den avsedda arkitekturen. Den anger också att revisorer ska förvänta sig ett dokument för nätverkssäkerhetsarkitektur som visar brandväggar, VPN-gateways, DMZ-zoner, VLAN-separation och tillitsgränser.
För ändringshantering placerar Zenith Blueprint ISO/IEC 27002:2022-kontroll 8.32 i fasen Kontroller i praktiken, steg 21: kontroller 8.27 till 8.34, och lyfter fram varför brandväggsstyrning brister när ändringsstyrningen är svag:
”Denna kontroll erkänner en hård sanning inom IT: många incidenter orsakas inte av attacker, utan av felhanterade ändringar. En brandväggsregel som öppnats för brett. En debug-inställning som lämnats aktiverad. Ett bortglömt beroende efter en migrering.”
Det är precis så tillfälliga brandväggsöppningar blir permanenta angreppsvägar.
Hur god nätverkssegmentering ser ut
Ett moget segmenteringsprogram har fyra lager.
För det första finns en zonmodell. Zoner är inte godtyckliga subnät. De är tillitsgränser som anpassas till verksamhetsfunktion och datakänslighet, såsom internetexponerad DMZ, applikationslager i produktion, databaslager i produktion, organisationens användarnätverk, privilegierat administrationsnätverk, utvecklingsmiljö, testmiljö, nätverk för säkerhetskopiering, gäst-Wi‑Fi, OT- eller IoT-zon och zon för tredjepartsåtkomst.
För det andra finns en flödesmatris. För varje zonpar dokumenterar organisationen tillåten källa, destination, protokoll, port, applikation, verksamhetsägare, systemägare, datatyp, motivering och krav på loggning.
För det tredje finns regelägarskap. Varje brandväggsregel, regel för säkerhetsgrupp i moln eller policy för mjukvarudefinierad perimeter har en ägare, ett utgångs- eller revalideringsdatum, ett kopplat ändringsärende och en verksamhetsmässig motivering. ”Any-to-any” ska behandlas som en revisionsiakttagelse om den inte är formellt riskaccepterad, tidsbegränsad och stöds av kompenserande kontroller.
För det fjärde finns återkommande granskning. Granskning betyder mer än att exportera en brandväggsregelbas en gång per år. Den omfattar revalidering av ägare, jämförelse mot observerad trafik, identifiering av oanvända regler, validering av tillfälliga undantag, granskning av internetexponering, segmenteringstestning och avstämning mot tillgångsförteckningen.
Clarysecs Nätverkssäkerhetspolicy [P-NS] anger organisationens förväntan tydligt:
”All trafik mellan zoner ska styras av brandväggar eller mjukvarudefinierade perimeterlösningar, med uttryckliga konfigurationer enligt principen om standardmässigt nekande.”
Från Enterprise Policy, Nätverkssäkerhetspolicy, avsnittet ”Styrningskrav”, klausul 5.2.
Samma policy kopplar brandväggsändringar direkt till ändringshantering:
”Varje ändring av brandväggsregeluppsättningar, routingtabeller eller konfigurationer av säkerhetsgrupper ska följa organisationens ändringshanteringspolicy (P5), inklusive återställningsplaner och revisionsloggning.”
Från Enterprise Policy, Nätverkssäkerhetspolicy, avsnittet ”Styrningskrav”, klausul 5.4.
För små och medelstora företag ger Clarysecs Nätverkssäkerhetspolicy för SME [P-NS-SME] samma princip i operativa termer:
”Regler enligt principen om standardmässigt nekande ska tillämpas för alla inkommande anslutningar om de inte uttryckligen krävs och har godkänts”
Från SME Policy, Nätverkssäkerhetspolicy för SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.1.2.
Och specifikt för segmentering:
”Trafik mellan segment ska filtreras, och åtkomst mellan segment ska följa principen om minsta privilegium”
Från SME Policy, Nätverkssäkerhetspolicy för SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.2.3.
Dessa policyklausuler gör det möjligt för en revisor att följa spåret från risk till kontroll, från kontroll till regel, från regel till godkännande och från godkännande till loggar.
Ett underlagspaket för ISO 27001, NIS2, DORA och GDPR
Misstaget många team gör är att bygga separata underlagspaket: ett för ISO/IEC 27001:2022, ett för NIS2, ett för GDPR, ett för DORA-kunder och ett för cyberförsäkring.
Ett bättre arbetssätt är att bygga ett enda underlagspaket för segmenterings- och brandväggsstyrning som mappas över ramverk.
Zenith Controls: guiden för korsvis efterlevnad [ZC] mappar ISO/IEC 27002:2022-kontroll 8.22 Segregering av nätverk som en förebyggande kontroll som stödjer konfidentialitet, integritet och tillgänglighet, anpassad till cybersäkerhetskonceptet Protect och den operativa förmågan för system- och nätverkssäkerhet. Guiden kopplar 8.22 till 8.20 Nätverkssäkerhet, 8.21 Säkerhet i nätverkstjänster, 8.7 Skydd mot skadlig kod, 8.27 Säker systemarkitektur och tekniska principer samt 8.31 Separation av utvecklings-, test- och produktionsmiljöer.
Guiden förklarar segmenteringens relevans för NIS2 så här:
”Segregering av nätverk är ett direkt svar på dessa skyldigheter, eftersom den minskar angreppsytor och förhindrar lateral förflyttning mellan nätverksanslutna system.”
Den meningen beskriver varför NIS2-program för cyberhygien inte ska behandla segmentering som valfritt. Begränsning av ransomware handlar inte bara om slutpunktsskydd. Det handlar om att begränsa lateral förflyttning när förebyggandet misslyckas.
För GDPR mappar Zenith Controls 8.22 till Article 32 och Recital 49, och noterar att nätverksdiagram och zonindelningspolicyer blir centralt underlag för efterlevnad. För DORA mappar Zenith Controls nätverkssäkerhet och segregering till IKT-riskhantering och incidentbegränsning. Segmenteringstester kan stödja underlag för IKT-motståndskraft, särskilt när de visar att en kompromettering i en zon inte kan röra sig fritt till kritiska finansiella tjänster, personuppgiftsarkiv eller privilegierade administrationssystem.
| Underlagsartefakt | Användning för ISO/IEC 27001:2022 och ISO/IEC 27002:2022 | Användning för NIS2 | Användning för DORA | Användning för GDPR |
|---|---|---|---|---|
| Dokument för nätverkssäkerhetsarkitektur | Stödjer ISMS-omfattning, operativ styrning, 8.20 och 8.22 | Visar tekniska åtgärder för säkerhet i nätverks- och informationssystem | Visar IKT-sammankopplingar och beroenden för kritiska tjänster | Visar skyddsgränser runt system med personuppgifter |
| Zon- och flödesmatris | Visar riskbaserad nätverkssegregering och principen om minsta privilegium | Stödjer cyberhygien och effektivitetsbedömning | Stödjer klassificering av IKT-tillgångar och beroenden | Stödjer tekniska åtgärder enligt Article 32 och ansvarsskyldighet |
| Granskningsposter för brandväggsregler | Underlag för kontrollövervakning och ständig förbättring | Visar att åtgärder granskas och inte är statiska | Stödjer IKT-riskgranskning och resiliensprovning | Visar löpande säkerhet i behandlingen |
| Ändringsärenden för brandväggsregler | Stödjer 8.32 Ändringshantering | Stödjer säkert underhåll och spårbarhet | Stödjer kontrollerad IKT-ändring och motståndskraft | Visar att ändringar som påverkar system med personuppgifter riskbedöms |
| Undantagsregister | Stödjer riskbehandling och acceptans av kvarstående risk | Visar ledningens tillsyn över avvikelser | Stödjer risktolerans och styrning | Visar ansvarsskyldighet för tillfällig exponering |
| Loggar över blockerad och tillåten trafik mellan zoner | Stödjer loggning, övervakning och kontrolleffektivitet | Stödjer detektering och incidentrespons | Stödjer incidentklassificering och rapportering | Stödjer incidentbedömning och bevarande av bevismaterial |
Denna tabell är inte bara en mappning för regelefterlevnad. Den är en färdplan för insamling av underlag.
Granskningen av brandväggsregler som faktiskt fungerar
En granskning av brandväggsregler misslyckas när den bara frågar: ”Behövs denna regel fortfarande?” Regelägare svarar ofta ja eftersom de är rädda att något ska sluta fungera.
En bättre granskning ställer sex frågor:
- Vilken verksamhetstjänst stödjer regeln?
- Vilken tillgångsägare och dataägare godkände flödet?
- Finns destinationen i rätt zon för datat och funktionen?
- Är regeln mer tillåtande än vad observerad trafik kräver?
- Är loggning aktiverad för högriskflöden?
- Har regeln granskningsdatum, utgångsdatum eller undantagspost?
Nätverkssäkerhetspolicy för SME kräver periodisk granskning:
”IT-supportleverantören ska genomföra en årlig granskning av brandväggsregler, nätverksarkitektur och trådlösa konfigurationer”
Från SME Policy, Nätverkssäkerhetspolicy för SME, avsnittet ”Styrningskrav”, klausul 5.6.1.
Årlig granskning är baslinjen, inte taket. Högriskregler behöver revalideras oftare.
| Regelkategori | Exempel | Granskningsfrekvens | Förväntat godkännande |
|---|---|---|---|
| Inkommande internettrafik till produktion | Publikt API till applikationsgateway | Kvartalsvis eller efter större release | Tjänsteägare, säkerhetsfunktion, ändringsgodkännare |
| Databasåtkomst mellan zoner i produktion | Applikationslager till databaslager | Kvartalsvis | Applikationsägare och dataägare |
| Administrativ åtkomst | Hoppvärd till serveradministrationsportar | Månadsvis eller kvartalsvis | Infrastrukturägare och CISO-delegat |
| Tredjepartsåtkomst | Leverantörs-VPN till supportsubnät | Månadsvis eller vid avtalsmilstolpe | Leverantörsansvarig och säkerhetsfunktion |
| Tillfälligt undantag | Akut åtkomst under migrering | Före utgång, högst 90 dagar | ISMS-ansvarig eller CISO |
| Standardregel med låg intern risk | Övervakningsserver till hanterade slutpunkter | Årligen | Tjänsteägare |
Nätverkssäkerhetspolicyn är tydlig om undantag:
”Begäran ska granskas och godkännas av ISMS-ansvarig eller CISO och registreras i ISMS-undantagsregistret, med en maximal godkännandeperiod på 90 dagar, som kan förnyas efter förnyad bedömning.”
Från Enterprise Policy, Nätverkssäkerhetspolicy, avsnittet ”Riskbehandling och undantag”, klausul 7.3.
För små och medelstora företag kräver Nätverkssäkerhetspolicy för SME att undantagsbegäranden innehåller rätt minimifakta:
”Begäran ska omfatta motivering, omfattning, varaktighet och kompenserande kontroller (t.ex. IP-tillåtelselista, loggning)”
Från SME Policy, Nätverkssäkerhetspolicy för SME, avsnittet ”Riskbehandling och undantag”, klausul 7.3.3.
Den klausulen gör undantagshantering till spårbar riskbehandling i stället för informell chatt.
Praktiskt exempel: ta bort en riskfylld regel för produktionsdatabas
Anta att ett företag hittar följande regel under granskning:
| Fält | Nuvarande värde |
|---|---|
| Källa | Organisationens användar-VLAN |
| Destination | Databassubnät i produktion |
| Port | TCP 5432 |
| Åtgärd | Tillåt |
| Kommentar | Tillfällig åtkomst för migrering av rapportering |
| Skapad | 14 månader sedan |
| Ägare | Okänd |
| Loggning | Inaktiverad |
Detta är en klassisk revisionsiakttagelse. Den bryter mot principen om minsta privilegium, saknar tydlig ägare, saknar utgångsdatum, saknar aktuell motivering och saknar loggning. Den skapar även en exponering enligt GDPR Article 32 om produktionsdatabasen innehåller kunders personuppgifter.
Åtgärdsprocessen ska skapa underlag, inte bara ta bort en dålig regel.
| Steg | Åtgärd | Clarysec-referens | Skapat revisionsunderlag |
|---|---|---|---|
| 1. Mappa regeln mot zonmodellen | Bekräfta om organisationsanvändare någonsin ska kunna nå produktionsdatabassubnätet | Zenith Blueprint, Kontroller i praktiken steg 20 | Uppdaterade anteckningar från arkitekturgranskning och zonklassificering |
| 2. Skapa eller uppdatera flödesposten | Dokumentera källa, destination, port, datatyp, ägare, motivering och risk | Zenith Controls, 8.22-mappning | Post i zon- och flödesmatris |
| 3. Öppna ett ändringsärende | Föreslå borttagning eller ersättning med en kontrollerad rapporteringstjänstväg | Nätverkssäkerhetspolicy, klausul 5.4 | Ändringspost med riskanalys, testplan och återställningsplan |
| 4. Besluta om behandling | Ta bort den breda regeln eller ersätt den med skrivskyddad replik, bastion, IP-tillåtelselista och loggning | Nätverkssäkerhetspolicy, klausul 7.3 | Riskbehandlingsbeslut eller tidsbegränsat undantag |
| 5. Aktivera loggning för godkända flöden | Skicka högriskhändelser mellan zoner från brandväggen till övervakning | Loggnings- och övervakningspolicy, klausul 6.1.1.6 | SIEM-poster, larmregler och skärmbilder från övervakning |
| 6. Validera segmentering | Testa att databassubnätet inte kan nås annat än via godkända vägar | Zenith Blueprint, steg 20 | Segmenteringstestresultat och stängning av åtgärd |
Clarysecs Loggnings- och övervakningspolicy [P-LM] inkluderar extern kommunikation och utlösare för brandväggsregler som loggrelevanta händelser:
”Extern kommunikation och utlösare för brandväggsregler”
Från Enterprise Policy, Loggnings- och övervakningspolicy, avsnittet ”Krav för genomförande av policyn”, klausul 6.1.1.6.
För högriskregler mellan zoner bör brandväggsutlösare mata SIEM eller övervakningsplattformen, med larm för ovanliga källvärdar, volymer eller tidsfönster.
SME-policyn kräver också ändringsdisciplin:
”Alla ändringar av nätverkskonfigurationer (brandväggsregler, switch-ACL:er, routingtabeller) ska följa en dokumenterad ändringshanteringsprocess”
Från SME Policy, Nätverkssäkerhetspolicy för SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.9.1.
En enda upprensning av denna regel skapar underlag för ISO/IEC 27001:2022 operativ styrning, ISO/IEC 27002:2022 8.20, 8.22 och 8.32, NIS2-cyberhygien, GDPR Article 32 och DORA-liknande IKT-riskhantering.
Moln, SaaS och hybrida nätverk ska omfattas
Modern segmentering handlar inte bara om VLAN och fysiska brandväggar. Den omfattar AWS-säkerhetsgrupper, Azure-nätverkssäkerhetsgrupper, Kubernetes-nätverkspolicyer, routingtabeller i moln, SaaS-administratörers tillåtelselistor, privata slutpunkter, VPN, SD-WAN, identitetsmedvetna proxyservrar och mjukvarudefinierade perimeterkontroller.
För en SaaS-leverantör eller reglerad digital tjänst bör granskningen av brandväggsregler minst omfatta:
- Internetexponerade lastbalanserare och applikationsgateways
- Säkerhetsgrupper i moln och nätverks-ACL:er
- Routingtabeller för privata subnät
- Peering- och transitgatewayvägar
- VPN och vägar för fjärradministration
- Administrationsgränssnitt och management planes
- Kubernetes-ingress och nätverkspolicyer
- CI/CD-runneråtkomst till produktion
- Loggtäckning för nekade och tillåtna högriskflöden
- Tredjepartssupportåtkomst och break-glass-vägar
Om en säkerhetsgrupp i moln tillåter inkommande databastrafik från ett brett organisationsinternt IP-intervall ska den behandlas som en brandväggsregel. Den behöver ägarskap, motivering, godkännande, granskning, loggning och utgångsdatum.
Det är också här stödjande ISO-standarder stärker berättelsen. ISO/IEC 27017 stödjer tydlighet kring ansvar för molnsäkerhet. ISO/IEC 27033 ger mer fördjupad vägledning om nätverkssäkerhetsarkitektur, DMZ:er, segmenteringszoner, trafikfiltrering och säker kommunikation mellan nätverk. ISO/IEC 27701 förstärker integritetsstyrning där personligt identifierbar information rör sig över nätverk. ISO/IEC 27035 stödjer incidentbegränsning, och ISO/IEC 27005 stödjer valet av segmentering som riskbehandling för obehörig åtkomst, spridning av skadlig kod och lateral förflyttning.
Hur revisorer testar samma kontroll på olika sätt
En av styrkorna med Zenith Controls är att guiden förklarar hur olika revisionsmetoder granskar samma kontroll. Underlaget kan återanvändas, men frågorna skiljer sig åt.
| Revisionsperspektiv | Sannolik fråga | Bästa underlag |
|---|---|---|
| ISO/IEC 27001:2022-revisor | Har segmentering valts, införts och granskats baserat på risk? | Riskbedömning, SoA, nätverkspolicy, diagram, granskningsposter |
| ISO/IEC 27007-liknande revisor | Stämmer implementerade brandväggsregler och VLAN-scheman med dokumenterad policy? | Exempel på brandväggsregler, router-ACL:er, VLAN-design, intervjuer med administratörer |
| Certifieringsrevisionsansats enligt ISO/IEC 27006-1:2024 | Revideras kritiska nätverksgränser med lämplig kompetens och riskbaserad planering? | Revisionsplan, tekniskt urval, underlag för säkerhetsgrupper i moln, testresultat |
| NIST-orienterad revisor | Tillämpas och övervakas gränser och informationsflöden? | Brandväggsregler, ACL:er, segmenteringstester, övervakningsposter |
| COBIT 2019-revisor | Styrs, övervakas och rapporteras nätverkssäkerhet? | Ägarskapsmatris, KPI:er, ledningsrapportering, riskregister |
| ISACA ITAF-revisor | Fungerar generella IT-kontroller konsekvent? | Ändringsärenden, godkännanden av undantag, loggar, urval av regelrevalideringar |
| GDPR-tillsynsmyndighet | Skyddades system med personuppgifter av lämpliga tekniska åtgärder? | Dataflödeskartor, isolering av PII-zoner, åtkomstvägar, brandväggsloggar |
| DORA-fokuserad granskare | Stödjer segmentering IKT-motståndskraft och incidentbegränsning? | Beroendekarta för IKT-tillgångar, flöden för kritiska funktioner, åtgärdsplaner för incidenter, testposter |
En DORA-fokuserad granskare kan fråga om en kompromettering i en betalningsgateway kan röra sig vidare till kunddatabaser. En behörig myndighet enligt NIS2 kan fråga om ransomware på en administrativ arbetsstation kan nå centrala system för tjänsteleverans. En GDPR-myndighet kan fråga vilka nätverksbegränsningar som skyddade system som behandlar personuppgifter. En ISO-revisor kan helt enkelt be om riskbedömningen, SoA, policyn, rutinen och underlaget som visar att granskningar har genomförts.
De bästa programmen besvarar alla dessa frågor med samma artefakter.
Mätetal som gör segmentering synlig för ledningen
Både NIS2 och DORA driver ledningens ansvarsskyldighet. ISO/IEC 27001:2022 kräver ledarskap, mål, roller, resurser, rapportering och ständig förbättring. Det innebär att segmentering behöver mätetal som ledningen kan förstå.
Användbara ledningsmätetal omfattar:
- Andel brandväggsregler med tilldelad ägare
- Andel regler med dokumenterad verksamhetsmässig motivering
- Antal utgångna tillfälliga regler
- Antal regler med ”any” som källa, destination eller tjänst
- Antal internetexponerade tjänster per kritikalitet
- Andel högriskflöden mellan zoner med loggning aktiverad
- Antal akuta brandväggsändringar per kvartal
- Andel granskade regler i urval som matchar godkända ändringsärenden
- Antal misslyckade segmenteringstester
- Genomsnittlig tid för att åtgärda riskfyllda eller oanvända regler
- Antal undantag äldre än 90 dagar
- Antal regler för tredjepartsåtkomst som har granskats och revaliderats
Nätverkssäkerhetspolicyn identifierar ”brandväggsreglers effektivitet” som en aspekt av efterlevnad och tillämpning i avsnittet ”Efterlevnad och tillämpning”, klausul 8.2.2. Den formuleringen är viktig eftersom regelns existens inte räcker. Regler ska vara effektiva, granskade och anpassade till aktuell risk.
Bygg underlagspaketet för segmentering 2026
Ett praktiskt underlagspaket för nätverkssegmentering och granskning av brandväggsregler ska vara klart innan revisorn frågar efter det.
Som minimum ska följande upprätthållas:
- Aktuellt diagram över nätverksarkitekturen, inklusive moln- och hybridzoner
- Standard för zonklassificering, inklusive känslighet och tillitsnivå
- Flödesmatris för kritiska tjänster och system med personuppgifter
- Export av regler för brandväggar och säkerhetsgrupper i moln
- Register över regelägare och revalidering
- Rutin och kalender för brandväggsgranskning
- Ändringsposter för utvalda brandväggsändringar
- Undantagsregister med godkännanden, utgångsdatum och kompenserande kontroller
- Segmenteringstestresultat och åtgärdsposter
- Loggnings- och övervakningsunderlag för högriskflöden
- Incidentåtgärdsplaner som visar begränsning per zon
- Ledningsmätetal och mötesprotokoll
Mappa detta underlag mot ISO/IEC 27001:2022-klausuler och kontrollområden i Annex A. Korsreferera det sedan till NIS2 Article 21, GDPR Article 32, DORA-krav för IKT-riskhantering och testning, NIST CSF 2.0-resultat såsom GOVERN, PROTECT, DETECT och RESPOND samt COBIT-styrningspraxis.
NIST CSF 2.0 är särskilt användbart som kommunikationslager för styrelsen. Funktionen GOVERN fokuserar på rättsliga, regulatoriska och avtalsmässiga krav, riskaptit, roller, policyer och tillsyn. De operativa resultaten behandlar konfigurationshantering, loggning, övervakning, dataskydd, incidentrespons och återhämtning. Detta hjälper ledningen att förstå risk utan att läsa brandväggs-ACL:er.
Vanliga iakttagelser som Clarysec ser i segmenteringsrevisioner
I SaaS, fintech, leverantörer av hanterade tjänster och reglerade små och medelstora företag återkommer samma iakttagelser:
- Platt nätverk mellan användarslutpunkter och produktionstjänster
- Produktionsdatabaser som kan nås från utvecklings- eller organisationsnätverk
- Breda säkerhetsgrupper i moln kopierade från gamla mallar
- Tillfälliga leverantörsregler utan utgångsdatum
- Brandväggsändringar gjorda utanför ändringsprocessen
- Regler utan ägare eller verksamhetsmässig motivering
- Loggning inaktiverad på högrisktillåtelseregler
- Gäst-Wi‑Fi som inte är fullständigt isolerat
- Administrationsgränssnitt som kan nås från generella nätverk
- Diagram som inte motsvarar faktisk routing
- Inget underlag för att regelgranskningar har slutförts
- Ingen segmenteringstestning efter större arkitekturändringar
- Ingen mappning mellan system med personuppgifter och nätverkszoner
- Ingen ledningsrapportering om nätverksexponering
Dessa iakttagelser är inte bara tekniska svagheter. De undergräver organisationens förmåga att visa NIS2-cyberhygien, DORA operativ motståndskraft och ansvarsskyldighet enligt GDPR Article 32.
Från reaktiv upprensning till försvarbar kontroll
Nätverkssegmentering och granskning av brandväggsregler är platsen där säkerhetsarkitektur möter revisionsverklighet. Om du kan visa en riskbaserad zonmodell, kontrollerade flöden mellan zoner, godkända brandväggsändringar, tidsbegränsade undantag, loggningsunderlag och periodisk validering kan du besvara ett brett spann av frågor inom ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST och COBIT med en sammanhållen berättelse.
Clarysec kan hjälpa dig att bygga den berättelsen.
Använd Zenith Blueprint: en revisors 30-stegsfärdplan för att strukturera genomföranderesan, särskilt Kontroller i praktiken steg 20 för nätverkssäkerhet och segmentering samt steg 21 för ändringshantering. Använd Zenith Controls: guiden för korsvis efterlevnad för att mappa ISO/IEC 27002:2022-kontrollerna 8.20, 8.22 och 8.32 mot revisionsförväntningar inom NIS2, DORA, GDPR, NIST och COBIT. Förankra dina operativa regler i Clarysecs Nätverkssäkerhetspolicy, Nätverkssäkerhetspolicy för SME och Loggnings- och övervakningspolicy.
Ditt nästa steg är enkelt och ger högt värde: välj en kritisk tjänst, såsom kundproduktion, betalningshantering eller identitetshantering, och genomför en stickprovsgranskning av 10 regler denna vecka. Bekräfta för varje regel ägare, motivering, källa, destination, port, loggning, ändringsärende och utgångsdatum. Om du inte kan visa dessa sju fakta har du början på din förbättringsplan för segmentering 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
