Ugniasienių taisyklių peržiūra ISO 27001, NIS2, DORA ir GDPR kontekste

Pirmadienio rytas, 07:42. Augančio SaaS ir fintech paslaugų teikėjo CISO žiūri į tris atskirus pranešimus.

Pirmasis gautas iš SOC. Kompromituota kūrėjo darbo stotis naktį bandė prisijungti prie vidinio duomenų bazės potinklio. Srautas buvo užblokuotas, tačiau analitikui reikia patvirtinimo, kad ugniasienės taisyklė yra tikslinga, aktuali ir patvirtinta.

Antrasis pranešimas gautas iš didelio verslo kliento. Jis prašo įrodymų, kad produkcinės, kūrimo, įmonės ir palaikymo aplinkos yra segmentuotos, ugniasienių taisyklės peržiūrimos, o išimtys turi galiojimo pabaigos datą.

Trečiasis pranešimas gautas iš atitikties vadovo. Organizacija patenka į NIS2 taikymo sritį kaip svarbus skaitmeninių paslaugų teikėjas, turi GDPR pareigas kaip duomenų tvarkytojas, o finansinių paslaugų klientai prašo DORA pobūdžio IRT rizikos įrodymų. Valdyba nori žinoti, ar tie patys ISO/IEC 27001:2022 įrodymai gali atsakyti į visus tris klausimų rinkinius.

Tada gaunama peržiūra po incidento. Kūrimo serveris beveik buvo atvertas internetui per vėlyvą vakarinį pakeitimą. Klientų duomenys nebuvo prarasti, tačiau skaitmeninės kriminalistikos komanda nustatė kai ką blogesnio nei pirminė klaida: penkerių metų senumo „laikino testavimo“ ugniasienės taisyklė vis dar leido platų judėjimą tarp kūrimo ir produkcinės aplinkos. Jei užpuolikas būtų gavęs prieigą, tinklas būtų sudaręs labai mažai pasipriešinimo.

Būtent tada daugelis organizacijų pamato nemalonią tiesą. Jos gali turėti ugniasienes, VLAN, debesijos saugumo grupes ir diagramas, tačiau neturi segmentavimo zonų, taisyklių savininkystės, laikinos prieigos, pakeitimų tvirtinimo, pakartotinio sertifikavimo ir audito įrodymų valdysenos.

2026 m. atsakymas „turime ugniasienę“ nebėra pakankamas. Auditoriai, reguliuotojai, klientai ir draudikai nori įrodymų, kad tinklai atskirti sąmoningai, srautas kontroliuojamas pagal verslo poreikį, rizikingos išimtys valdomos, o žurnalai rodo, kad kontrolės priemonės veikia.

Kodėl ugniasienių valdysena tapo valdybos lygmens klausimu

Tinklo segmentavimas anksčiau buvo laikomas techninės inžinerijos tema. Infrastruktūros komandos valdė VLAN, ugniasienių administratoriai prižiūrėjo taisyklių rinkinius, debesijos komandos tvarkė saugumo grupes, o atitikties funkcija audito metu dažnai matydavo tik diagramą.

Toks veiklos modelis nebeveikia.

NIS2 direktyva reikalauja, kad esminiai ir svarbūs subjektai įgyvendintų tinkamas ir proporcingas technines, operacines ir organizacines priemones tinklų ir informacinių sistemų rizikai valdyti. Article 21 apima rizikos analizės, incidentų valdymo, veiklos tęstinumo, tiekimo grandinės saugumo, saugumo įsigyjant, kuriant ir prižiūrint sistemas, veiksmingumo vertinimo, bazinės kibernetinės higienos, prieigos kontrolės ir turto valdymo politikas. Valdymo organai turi patvirtinti ir prižiūrėti šias kibernetinio saugumo rizikos valdymo priemones.

DORA nuo 2025 m. sausio 17 d. taikomas daugeliui finansų subjektų ir paverčia IRT rizikos valdymą valdoma, dokumentuota disciplina. Articles 5, 6 ir 8 reikalauja valdysenos, IRT rizikos valdymo sistemos ir IRT palaikomų verslo funkcijų, informacijos išteklių, IRT turto, priklausomybių, kritinio turto ir tarpusavio jungčių identifikavimo. Articles 9, 10 ir 11 apima apsaugą, prevenciją, aptikimą, reagavimą ir atkūrimą. Articles 24 to 27 reikalauja skaitmeninio operacinio atsparumo testavimo, įskaitant pažangų testavimą tam tikriems subjektams. Todėl segmentavimas yra atsparumo klausimas, o ne vien ugniasienės klausimas.

GDPR prideda privatumo atskaitomybės sluoksnį. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių, kad būtų užtikrintas riziką atitinkantis saugumo lygis, įskaitant konfidencialumą, vientisumą, prieinamumą ir atsparumą. Article 5(1)(f) reikalauja vientisumo ir konfidencialumo, o Article 5(2) – atskaitomybės. Jei asmens duomenų sistemos pasiekiamos iš kompromituotų galinių įrenginių, svečių tinklų arba nevaldomų trečiųjų šalių kelių, priežiūros institucija gali paklausti, kodėl tokie keliai apskritai egzistavo.

ISO/IEC 27001:2022 suteikia valdymo sistemos pagrindą, sujungiantį šiuos įpareigojimus. Standartas reikalauja taikymo srities, suinteresuotųjų šalių reikalavimų, rizikos vertinimo, rizikos tvarkymo, Taikomumo pareiškimo, operacinio planavimo ir kontrolės, vadovybės atskaitomybės, išmatuojamų tikslų, dokumentuotos informacijos ir nuolatinio tobulinimo. Annex A, papildytas ISO/IEC 27002:2022 gairėmis, apima kontrolės sritis, reikalingas tiekėjų rizikai, debesijos paslaugoms, žurnalavimui, stebėsenai, saugiai architektūrai, aplinkų atskyrimui ir pakeitimų valdymui.

Esmė paprasta: tinklo segmentavimas ir ugniasienių taisyklių peržiūra dabar yra valdysenos įrodymai.

Clarysec veiklos modelis: 8.20, 8.22 ir 8.32

Clarysec segmentavimą ir ugniasienių peržiūrą vertina kaip vieną veiklos modelį ISO/IEC 27002:2022 kontrolės priemonių kontekste, o ne kaip izoliuotas technines užduotis.

Trys pagrindinės kontrolės priemonės yra:

Dokumente Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas [ZB] Clarysec priskiria tinklų saugumą etapui „Kontrolės priemonės praktikoje“, 20 žingsniui: kontrolės priemonės 8.18 to 8.26. Gairėse pagrindinis audito klausimas suformuluotas aiškiai:

„Iš esmės ši kontrolės priemonė reikalauja, kad organizacijos užtikrintų, jog tinklai būtų saugūs pagal architektūrą, o ne tik vėliau pridėjus ugniasienes ar antivirusinę programinę įrangą. Tai reiškia strateginį mąstymą apie tinklo segmentavimą, prieigos kontrolę, perduodamų duomenų šifravimą, stebėseną ir daugiasluoksnę gynybą. Viskas prasideda nuo paprasto klausimo: kas ir su kuo komunikuoja, ir ar tai turėtų vykti?“

Šis klausimas – „kas ir su kuo komunikuoja, ir ar tai turėtų vykti?“ – yra geriausias praktinis atspirties taškas ugniasienės taisyklių peržiūrai. Jis nukreipia pokalbį nuo tūkstančių neaiškių ACL įrašų prie verslo poreikiu pagrįstų srautų.

Tas pats Zenith Blueprint nurodo komandoms vertinti tinklo architektūrą tikrinant, ar ugniasienių taisyklės, IPS/IDS ir nuotolinės prieigos konfigūracijos yra aktualios ir sustiprintos, taip pat patvirtinti, kad debesijos saugumo grupės, maršrutizavimas ir VPC arba potinklių taisyklės atitinka numatytą architektūrą. Jame auditoriams taip pat nurodoma tikėtis tinklo saugumo architektūros diagramos, kurioje pateikiamos ugniasienės, VPN šliuzai, DMZ zonos, VLAN atskyrimas ir pasitikėjimo ribos.

Pakeitimų valdymo srityje Zenith Blueprint priskiria ISO/IEC 27002:2022 kontrolės priemonę 8.32 etapui „Kontrolės priemonės praktikoje“, 21 žingsniui: kontrolės priemonės 8.27 to 8.34, ir pabrėžia, kodėl ugniasienių valdysena žlunga, kai pakeitimų kontrolė silpna:

„Ši kontrolės priemonė pripažįsta sudėtingą IT tiesą: daugelį incidentų sukelia ne atakos, o netinkamai valdomi pakeitimai. Per plačiai atverta ugniasienės taisyklė. Paliktas įjungtas derinimo nustatymas. Po migracijos pamiršta priklausomybė.“

Būtent taip laikini ugniasienių atvėrimai tampa nuolatiniais atakų keliais.

Kaip atrodo geras tinklo segmentavimas

Brandžią segmentavimo programą sudaro keturi sluoksniai.

Pirma, ji turi zonų modelį. Zonos nėra savavališki potinkliai. Tai pasitikėjimo ribos, suderintos su verslo funkcija ir duomenų jautrumu, pvz., į internetą nukreipta DMZ, produkcinės taikomosios programos sluoksnis, produkcinės duomenų bazės sluoksnis, įmonės naudotojų tinklas, privilegijuoto administravimo tinklas, kūrimo aplinka, testavimo aplinka, atsarginių kopijų tinklas, svečių Wi‑Fi, OT arba IoT zona ir trečiųjų šalių prieigos zona.

Antra, ji turi srautų matricą. Kiekvienai zonų porai organizacija dokumentuoja leidžiamą šaltinį, paskirties vietą, protokolą, prievadą, taikomąją programą, verslo savininką, sistemos savininką, duomenų tipą, pagrindimą ir žurnalavimo reikalavimą.

Trečia, ji turi taisyklių savininkystę. Kiekviena ugniasienės taisyklė, debesijos saugumo grupės taisyklė arba programiškai apibrėžto perimetro politika turi savininką, galiojimo pabaigos arba pakartotinio sertifikavimo datą, susietą pakeitimo užklausą ir verslo pagrindimą. „Bet kas į bet ką“ turi būti laikoma audito išvada, nebent ši rizika formaliai priimta, apribota laiku ir paremta kompensuojančiomis kontrolės priemonėmis.

Ketvirta, ji turi periodinę peržiūrą. Peržiūra reiškia daugiau nei kartą per metus eksportuoti ugniasienės taisyklių bazę. Ji apima savininko pakartotinį patvirtinimą, palyginimą su stebimu srautu, nenaudojamų taisyklių aptikimą, laikinų išimčių validavimą, interneto pasiekiamumo peržiūrą, segmentavimo testavimą ir suderinimą su turto apskaita.

Clarysec Tinklo saugumo politika [P-NS] aiškiai nustato organizacijos reikalavimą:

„Visas tarpzoninis srautas turi būti valdomas ugniasienėmis arba programiškai apibrėžto perimetro sprendimais, taikant aiškias „numatytai draudžiama“ konfigūracijas.“

Iš įmonės politikos „Tinklo saugumo politika“, skyriaus „Valdysenos reikalavimai“, 5.2 punkto.

Ta pati politika tiesiogiai susieja ugniasienės pakeitimus su pakeitimų valdymu:

„Bet koks ugniasienės taisyklių rinkinių, maršruto lentelių arba saugumo grupių konfigūracijų pakeitimas turi atitikti organizacijos Pakeitimų valdymo politiką (P5), įskaitant grąžinimo į ankstesnę būseną planus ir audito žurnalavimą.“

Iš įmonės politikos „Tinklo saugumo politika“, skyriaus „Valdysenos reikalavimai“, 5.4 punkto.

MVĮ atveju Clarysec Network Security Policy-sme [P-NS-SME] pateikia tą patį principą operacine kalba:

„Visoms įeinančioms jungtims turi būti taikomos „numatytai draudžiama“ taisyklės, nebent jos aiškiai reikalingos ir patvirtintos“

Iš MVĮ politikos „Network Security Policy-sme“, skyriaus „Politikos įgyvendinimo reikalavimai“, 6.1.2 punkto.

Konkrečiai segmentavimui:

„Srautas tarp segmentų turi būti filtruojamas, o tarpsegmentinė prieiga turi atitikti mažiausių privilegijų principą“

Iš MVĮ politikos „Network Security Policy-sme“, skyriaus „Politikos įgyvendinimo reikalavimai“, 6.2.3 punkto.

Šios politikos nuostatos leidžia auditoriui atsekti kelią nuo rizikos iki kontrolės priemonės, nuo kontrolės priemonės iki taisyklės, nuo taisyklės iki patvirtinimo ir nuo patvirtinimo iki žurnalų.

Vienas įrodymų paketas ISO 27001, NIS2, DORA ir GDPR

Dažna komandų klaida – kurti atskirus įrodymų paketus: vieną ISO/IEC 27001:2022, vieną NIS2, vieną GDPR, vieną DORA klientams ir vieną kibernetiniam draudimui.

Geresnis būdas – sukurti vieną segmentavimo ir ugniasienių valdysenos įrodymų paketą, kuris susiejamas tarp skirtingų sistemų.

Zenith Controls: kryžminės atitikties vadovas [ZC] susieja ISO/IEC 27002:2022 kontrolės priemonę 8.22 Tinklų atskyrimas kaip prevencinę kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą, suderintą su kibernetinio saugumo koncepcija Protect ir sistemų bei tinklų saugumo operaciniu pajėgumu. Jis susieja 8.22 su 8.20 Tinklų saugumas, 8.21 Tinklo paslaugų saugumas, 8.7 Apsauga nuo kenkimo programinės įrangos, 8.27 Saugios sistemų architektūros ir inžinerijos principai ir 8.31 Kūrimo, testavimo ir produkcinės aplinkų atskyrimas.

Gairėse NIS2 segmentavimo svarba paaiškinama taip:

„Tinklų atskyrimas yra tiesioginis atsakas į šiuos įpareigojimus, mažinantis atakos paviršių ir užkertantis kelią šoniniam judėjimui per tinklines sistemas.“

Šis sakinys paaiškina, kodėl NIS2 kibernetinės higienos programos neturėtų laikyti segmentavimo neprivalomu. Išpirkos reikalaujančios programinės įrangos lokalizavimas nėra vien galinių įrenginių apsaugos klausimas. Tai yra šoninio judėjimo ribojimas, kai prevencija nesuveikia.

GDPR kontekste Zenith Controls susieja 8.22 su Article 32 ir Recital 49, pažymėdamas, kad tinklo diagramos ir zonų politikos tampa pagrindiniais atitikties įrodymais. DORA kontekste Zenith Controls susieja tinklų saugumą ir atskyrimą su IRT rizikos valdymu ir incidentų lokalizavimu. Segmentavimo testai gali pagrįsti IRT atsparumo įrodymus, ypač kai jie parodo, kad kompromitavimas vienoje zonoje negali laisvai persikelti į kritines finansines paslaugas, asmens duomenų saugyklas ar privilegijuoto administravimo sistemas.

Ši lentelė yra ne tik atitikties susiejimas. Tai įrodymų rinkimo veiksmų planas.

Ugniasienės taisyklių peržiūra, kuri iš tikrųjų veikia

Ugniasienės taisyklių peržiūra žlunga, kai užduodamas tik klausimas: „Ar ši taisyklė vis dar reikalinga?“ Taisyklių savininkai dažnai atsako „taip“, nes bijo ką nors sutrikdyti.

Geresnė peržiūra užduoda šešis klausimus:

1. Kokią verslo paslaugą palaiko ši taisyklė?
2. Kuris turto savininkas ir duomenų savininkas patvirtino srautą?
3. Ar paskirties vieta yra tinkamoje zonoje pagal duomenis ir funkciją?
4. Ar taisyklė nėra platesnė, nei reikalauja stebimas srautas?
5. Ar didelės rizikos srautams įjungtas žurnalavimas?
6. Ar taisyklė turi peržiūros datą, galiojimo pabaigos datą arba išimties įrašą?

Network Security Policy-sme reikalauja periodinės peržiūros:

„IT pagalbos paslaugų teikėjas turi atlikti kasmetinę ugniasienės taisyklių, tinklo architektūros ir belaidžio ryšio konfigūracijų peržiūrą“

Iš MVĮ politikos „Network Security Policy-sme“, skyriaus „Valdysenos reikalavimai“, 5.6.1 punkto.

Kasmetinė peržiūra yra bazinis lygis, o ne viršutinė riba. Didelės rizikos taisyklėms reikia dažnesnio pakartotinio sertifikavimo.

Tinklo saugumo politika aiškiai apibrėžia išimtis:

„Prašymą turi peržiūrėti ir patvirtinti ISVS vadovas arba CISO, o jis turi būti įrašytas į ISVS išimčių registrą, taikant ne ilgesnį kaip 90 dienų patvirtinimo laikotarpį, kuris gali būti pratęstas po pakartotinio vertinimo.“

Iš įmonės politikos „Tinklo saugumo politika“, skyriaus „Rizikos tvarkymas ir išimtys“, 7.3 punkto.

MVĮ atveju Network Security Policy-sme reikalauja, kad išimčių prašymuose būtų nurodyti būtini minimalūs faktai:

„Prašyme turi būti nurodytas pagrindimas, taikymo sritis, trukmė ir kompensuojančios kontrolės priemonės (pvz., IP leidžiamieji sąrašai, žurnalavimas)“

Iš MVĮ politikos „Network Security Policy-sme“, skyriaus „Rizikos tvarkymas ir išimtys“, 7.3.3 punkto.

Ši nuostata paverčia išimčių tvarkymą iš neformalaus pokalbio į audituojamą rizikos tvarkymą.

Praktinis pavyzdys: rizikingos produkcinės duomenų bazės taisyklės pašalinimas

Tarkime, per peržiūrą įmonė randa šią taisyklę:

Tai klasikinė audito išvada. Ji pažeidžia mažiausių privilegijų principą, neturi aiškaus savininko, galiojimo pabaigos, aktualaus pagrindimo ir žurnalavimo. Ji taip pat sukuria GDPR Article 32 rizikos ekspoziciją, jei produkcinėje duomenų bazėje yra klientų asmens duomenų.

Taisymo procesas turi sukurti įrodymus, o ne tik pašalinti blogą taisyklę.

Clarysec Žurnalų valdymo ir stebėsenos politika [P-LM] išorinę komunikaciją ir ugniasienės taisyklių suveikimus įtraukia kaip žurnalavimui svarbius įvykius:

„Išorinė komunikacija ir ugniasienės taisyklių suveikimai“

Iš įmonės politikos „Žurnalų valdymo ir stebėsenos politika“, skyriaus „Politikos įgyvendinimo reikalavimai“, 6.1.1.6 punkto.

Didelės rizikos tarpzoninėms taisyklėms ugniasienės suveikimai turi būti perduodami į SIEM arba stebėsenos platformą, taikant įspėjimus dėl neįprastų šaltinio kompiuterių, apimčių arba laiko intervalų.

MVĮ politika taip pat reikalauja pakeitimų disciplinos:

„Visi tinklo konfigūracijų pakeitimai (ugniasienės taisyklės, komutatorių ACL, maršruto lentelės) turi atitikti dokumentuotą pakeitimų valdymo procesą“

Iš MVĮ politikos „Network Security Policy-sme“, skyriaus „Politikos įgyvendinimo reikalavimai“, 6.9.1 punkto.

Vien tik šios taisyklės sutvarkymas sukuria įrodymus ISO/IEC 27001:2022 operacinei kontrolei, ISO/IEC 27002:2022 8.20, 8.22 ir 8.32, NIS2 kibernetinei higienai, GDPR Article 32 ir DORA pobūdžio IRT rizikos valdymui.

Debesija, SaaS ir hibridiniai tinklai turi būti įtraukti

Šiuolaikinis segmentavimas nėra vien VLAN ir fizinės ugniasienės. Jis apima AWS saugumo grupes, Azure tinklo saugumo grupes, Kubernetes tinklo politikas, debesijos maršruto lenteles, SaaS administratorių leidžiamuosius sąrašus, privačius galinius taškus, VPN, SD-WAN, tapatybės kontekstą naudojančius tarpinius serverius ir programiškai apibrėžto perimetro kontrolės priemones.

SaaS teikėjui arba reguliuojamai skaitmeninei paslaugai ugniasienės taisyklių peržiūra turi apimti bent:

• Į internetą nukreiptus apkrovos balansavimo įrenginius ir taikomųjų programų šliuzus
• Debesijos saugumo grupes ir tinklo ACL
• Privačių potinklių maršruto lenteles
• Peering ir tranzitinių šliuzų kelius
• VPN ir nuotolinio administravimo kelius
• Administravimo sąsajas ir valdymo plokštumas
• Kubernetes įeinančio srauto ir tinklo politikas
• CI/CD vykdyklių prieigą į produkcinę aplinką
• Žurnalavimo aprėptį atmestiems ir leistiems didelės rizikos srautams
• Trečiųjų šalių palaikymo prieigą ir „break glass“ kelius

Jei debesijos saugumo grupė leidžia įeinantį duomenų bazės srautą iš plataus įmonės IP intervalo, vertinkite ją kaip ugniasienės taisyklę. Jai reikia savininkystės, pagrindimo, patvirtinimo, peržiūros, žurnalavimo ir galiojimo pabaigos.

Čia pasakojimą sustiprina ir pagalbiniai ISO standartai. ISO/IEC 27017 padeda aiškiai apibrėžti debesijos saugumo atsakomybes. ISO/IEC 27033 pateikia išsamesnes gaires dėl tinklo saugumo architektūros, DMZ, segmentavimo zonų, srauto filtravimo ir saugios tarptinklinės komunikacijos. ISO/IEC 27701 sustiprina privatumo valdyseną, kai asmenį identifikuojanti informacija juda tinklais. ISO/IEC 27035 palaiko incidentų lokalizavimą, o ISO/IEC 27005 padeda pasirinkti segmentavimą kaip rizikos tvarkymo priemonę dėl neteisėtos prieigos, kenkimo programinės įrangos plitimo ir šoninio judėjimo.

Kaip auditoriai tą pačią kontrolės priemonę testuoja skirtingai

Vienas iš Zenith Controls privalumų yra tai, kad jis paaiškina, kaip skirtingos audito metodikos nagrinėja tą pačią kontrolės priemonę. Įrodymai gali būti naudojami pakartotinai, tačiau klausimai skiriasi.

DORA orientuotas vertintojas gali klausti, ar kompromitavimas mokėjimų šliuze gali persikelti į klientų duomenų bazes. NIS2 kompetentinga institucija gali klausti, ar išpirkos reikalaujanti programinė įranga administracinėje darbo stotyje gali pasiekti pagrindines paslaugų teikimo sistemas. GDPR institucija gali klausti, kokie tinklo lygmens apribojimai saugojo sistemas, tvarkančias asmens duomenis. ISO auditorius gali tiesiog paprašyti rizikos vertinimo, SoA, politikos, procedūros ir įrodymų, kad peržiūros įvyko.

Geriausios programos į visus šiuos klausimus atsako tais pačiais artefaktais.

Rodikliai, padarantys segmentavimą matomą vadovybei

NIS2 ir DORA abu didina vadovybės atskaitomybę. ISO/IEC 27001:2022 reikalauja lyderystės, tikslų, vaidmenų, išteklių, ataskaitų teikimo ir nuolatinio tobulinimo. Tai reiškia, kad segmentavimui reikia vadovybei suprantamų rodiklių.

Naudingi valdymo rodikliai:

• Ugniasienės taisyklių, turinčių priskirtą savininką, procentinė dalis
• Taisyklių, turinčių dokumentuotą verslo pagrindimą, procentinė dalis
• Pasibaigusių laikinų taisyklių skaičius
• Taisyklių su „any“ šaltiniu, paskirties vieta arba paslauga skaičius
• Į internetą nukreiptų paslaugų skaičius pagal kritiškumą
• Didelės rizikos tarpzoninių srautų, kuriems įjungtas žurnalavimas, procentinė dalis
• Neatidėliotinų ugniasienės pakeitimų skaičius per ketvirtį
• Atrinktų taisyklių, susietų su patvirtintomis pakeitimų užklausomis, procentinė dalis
• Segmentavimo testavimo nesėkmių skaičius
• Vidutinis rizikingų arba nenaudojamų taisyklių ištaisymo laikas
• Išimčių, senesnių nei 90 dienų, skaičius
• Peržiūrėtų ir pakartotinai sertifikuotų trečiųjų šalių prieigos taisyklių skaičius

Tinklo saugumo politika skyriaus „Įgyvendinimas ir atitiktis“ 8.2.2 punkte nurodo „ugniasienės taisyklių veiksmingumą“ kaip atitikties ir politikos taikymo aspektą. Ši formuluotė svarbi, nes vien taisyklių buvimo nepakanka. Taisyklės turi būti veiksmingos, peržiūrimos ir suderintos su aktualia rizika.

Sukurkite 2026 m. segmentavimo įrodymų paketą

Praktinis segmentavimo ir ugniasienės taisyklių peržiūros įrodymų paketas turi būti parengtas prieš auditoriui jo paprašant.

Mažiausiai palaikykite:

1. Aktualią tinklo architektūros diagramą, įskaitant debesijos ir hibridines zonas
2. Zonų klasifikavimo standartą, įskaitant jautrumą ir pasitikėjimo lygį
3. Kritinių paslaugų ir asmens duomenų sistemų srautų matricą
4. Ugniasienės ir debesijos saugumo grupių taisyklių eksportą
5. Taisyklių savininkų ir pakartotinio sertifikavimo registrą
6. Ugniasienės peržiūros procedūrą ir peržiūrų kalendorių
7. Atrinktų ugniasienės pakeitimų įrašus
8. Išimčių registrą su patvirtinimais, galiojimo pabaiga ir kompensuojančiomis kontrolės priemonėmis
9. Segmentavimo testavimo rezultatus ir taisomųjų veiksmų įrašus
10. Žurnalų valdymo ir stebėsenos įrodymus didelės rizikos srautams
11. Incidentų veiksmų planus, rodančius lokalizavimą pagal zonas
12. Vadovybei teikiamų ataskaitų rodiklius ir posėdžių protokolus

Susiekite šiuos įrodymus su ISO/IEC 27001:2022 skyriais ir Annex A kontrolės sritimis. Tada atlikite kryžminį susiejimą su NIS2 Article 21, GDPR Article 32, DORA IRT rizikos valdymo ir testavimo reikalavimais, NIST CSF 2.0 rezultatais, pvz., GOVERN, PROTECT, DETECT ir RESPOND, bei COBIT valdysenos praktikomis.

NIST CSF 2.0 ypač naudingas kaip komunikacijos su valdyba sluoksnis. Jo GOVERN funkcija orientuota į teisės, reglamentavimo ir sutartinius reikalavimus, rizikos apetitą, vaidmenis, politikas ir priežiūrą. Operaciniai rezultatai apima konfigūracijų valdymą, žurnalavimą, stebėseną, duomenų apsaugą, reagavimą į incidentus ir atkūrimą. Tai padeda vadovybei suprasti riziką neskaitant ugniasienės ACL.

Dažnos Clarysec nustatomos segmentavimo auditų išvados

SaaS, fintech, valdomų paslaugų teikėjų ir reguliuojamų MVĮ aplinkose kartojasi tos pačios išvados:

• Plokščias tinklas tarp naudotojų galinių įrenginių ir produkcinių paslaugų
• Produkcinės duomenų bazės pasiekiamos iš kūrimo arba įmonės tinklų
• Plačios debesijos saugumo grupės, nukopijuotos iš senų šablonų
• Laikinos tiekėjų taisyklės be galiojimo pabaigos
• Ugniasienės pakeitimai atliekami ne pagal pakeitimų procesą
• Taisyklės be savininko arba verslo pagrindimo
• Žurnalavimas išjungtas didelės rizikos leidžiančiose taisyklėse
• Svečių Wi‑Fi nėra visiškai izoliuotas
• Administravimo sąsajos pasiekiamos iš bendrųjų tinklų
• Diagramos neatitinka faktinio maršrutizavimo
• Nėra įrodymų, kad taisyklių peržiūros buvo užbaigtos
• Po reikšmingų architektūros pakeitimų neatliktas segmentavimo testavimas
• Nėra susiejimo tarp asmens duomenų sistemų ir tinklo zonų
• Nėra vadovybei teikiamų ataskaitų apie tinklo pasiekiamumą

Šios išvados nėra vien techniniai trūkumai. Jos mažina organizacijos galimybę įrodyti NIS2 kibernetinę higieną, DORA operacinį atsparumą ir GDPR Article 32 atskaitomybę.

Nuo reaktyvaus tvarkymo prie pagrįstos kontrolės

Tinklo segmentavimas ir ugniasienių taisyklių peržiūra yra vieta, kur saugumo architektūra susitinka su audito realybe. Jei galite parodyti rizika grindžiamą zonų modelį, kontroliuojamus tarpzoninius srautus, patvirtintus ugniasienės pakeitimus, terminuotas išimtis, žurnalavimo įrodymus ir periodinį validavimą, galite į platų ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST ir COBIT klausimų spektrą atsakyti viena nuoseklia istorija.

Clarysec gali padėti jums tą istoriją sukurti.

Naudokite Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą, kad struktūruotumėte įgyvendinimo kelią, ypač „Kontrolės priemonės praktikoje“ 20 žingsnį tinklo saugumui ir segmentavimui bei 21 žingsnį pakeitimų valdymui. Naudokite Zenith Controls: kryžminės atitikties vadovą, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones 8.20, 8.22 ir 8.32 su NIS2, DORA, GDPR, NIST ir COBIT audito lūkesčiais. Įtvirtinkite veiklos taisykles Clarysec Tinklo saugumo politikoje, Network Security Policy-sme ir Žurnalų valdymo ir stebėsenos politikoje.

Kitas jūsų žingsnis paprastas ir didelės vertės: šią savaitę pasirinkite vieną kritinę paslaugą, pvz., klientų produkcinę aplinką, mokėjimų apdorojimą arba tapatybės valdymą, ir atlikite 10 taisyklių imties peržiūrą. Kiekvienai taisyklei patvirtinkite savininką, pagrindimą, šaltinį, paskirties vietą, prievadą, žurnalavimą, pakeitimo užklausą ir galiojimo pabaigą. Jei negalite pagrįsti šių septynių faktų, turite savo 2026 m. segmentavimo tobulinimo plano pradžią.