Pregled pravil požarnega zidu za ISO 27001, NIS2, DORA in GDPR

Ponedeljek je, 07:42. CISO hitro rastočega ponudnika SaaS in FinTech pregleduje tri ločena sporočila.

Prvo je iz SOC. Kompromitirana razvijalska delovna postaja je ponoči poskušala vzpostaviti povezavo z notranjim podomrežjem podatkovne baze. Promet je bil blokiran, analitik pa želi potrditev, da je pravilo požarnega zidu namerno, aktualno in odobreno.

Drugo je od velikega korporativnega naročnika. Zahteva dokazila, da so produkcijsko, razvojno, korporativno in podporno okolje segmentirana, da se pravila požarnega zidu redno pregledujejo in da imajo izjeme določen rok veljavnosti.

Tretje je od vodje skladnosti. Organizacija spada med pomembne digitalne ponudnike po NIS2, ima obveznosti obdelovalca po GDPR, stranke iz finančnega sektorja pa zahtevajo dokazila o upravljanju tveganj IKT v slogu DORA. Upravni odbor želi vedeti, ali lahko ista dokazila ISO/IEC 27001:2022 odgovorijo na vse tri sklope zahtev.

Nato prispe poročilo pregleda po incidentu. Razvojni strežnik je bil med pozno nočno spremembo skoraj izpostavljen internetu. Podatki strank niso bili izgubljeni, forenzična skupina pa je odkrila nekaj hujšega od prvotne napake: pet let staro pravilo požarnega zidu za »začasni test« je še vedno dovoljevalo obsežno komunikacijo med razvojnim in produkcijskim okoljem. Če bi napadalec pridobil dostop, bi mu omrežje nudilo zelo malo odpora.

To je trenutek, ko številne organizacije odkrijejo neprijetno resnico. Morda imajo požarne zidove, VLAN-e, varnostne skupine v oblaku in diagrame, nimajo pa upravljanja segmentacijskih con, lastništva pravil, začasnega dostopa, odobritev sprememb, ponovne certifikacije in presojnih dokazil.

V letu 2026 izjava »imamo požarni zid« ni več zagovorljiv odgovor. Presojevalci, regulatorji, stranke in zavarovalnice zahtevajo dokaz, da so omrežja namensko ločena, da je promet nadzorovan glede na poslovno potrebo, da so tvegane izjeme upravljane in da dnevniki potrjujejo delovanje kontrol.

Zakaj je upravljanje požarnih zidov zdaj vprašanje na ravni upravnega odbora

Segmentacija omrežja je bila nekoč obravnavana kot tehnična inženirska tema. Infrastrukturne ekipe so upravljale VLAN-e, skrbniki požarnih zidov so vzdrževali nabore pravil, ekipe za oblak so upravljale varnostne skupine, funkcija skladnosti pa je med presojo videla le diagram.

Takšen operativni model ne deluje več.

Direktiva NIS2 zahteva, da bistveni in pomembni subjekti izvajajo ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj za omrežne in informacijske sisteme. Člen 21 vključuje politike za analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varnost pri nabavi in vzdrževanju, ocenjevanje učinkovitosti, osnovno kibernetsko higieno, nadzor dostopa in upravljanje sredstev. Organi upravljanja morajo odobriti in nadzirati te ukrepe za obvladovanje kibernetskih tveganj.

DORA se za številne finančne subjekte uporablja od 17. januarja 2025 in upravljanje tveganj IKT postavlja kot upravljano in dokumentirano disciplino. Členi 5, 6 in 8 zahtevajo upravljanje, okvir upravljanja tveganj IKT ter identifikacijo poslovnih funkcij, podprtih z IKT, informacijskih sredstev, sredstev IKT, odvisnosti, kritičnih sredstev in medsebojnih povezav. Členi 9, 10 in 11 obravnavajo zaščito, preprečevanje, zaznavanje, odziv in obnovitev. Členi 24 do 27 zahtevajo testiranje digitalne operativne odpornosti, vključno z naprednim testiranjem za določene subjekte. Zato segmentacija ni le vprašanje požarnega zidu, temveč vprašanje odpornosti.

GDPR dodaja plast odgovornosti za zasebnost. Člen 32 zahteva ustrezne tehnične in organizacijske ukrepe za zagotavljanje ravni varnosti, ustrezne tveganju, vključno z zaupnostjo, celovitostjo, razpoložljivostjo in odpornostjo. Člen 5(1)(f) zahteva celovitost in zaupnost, člen 5(2) pa odgovornost. Če so sistemi z osebnimi podatki dosegljivi iz kompromitiranih končnih točk, omrežij za goste ali neupravljanih poti tretjih oseb, lahko nadzorni organ vpraša, zakaj so te poti obstajale.

ISO/IEC 27001:2022 zagotavlja temelje sistema upravljanja, ki povezujejo te obveznosti. Zahteva določitev obsega, zahtev zainteresiranih strani, oceno tveganj, obravnavo tveganj, izjavo o uporabnosti, operativno načrtovanje in nadzor, odgovornost vodstva, merljive cilje, dokumentirane informacije in nenehno izboljševanje. Priloga A, podprta s smernicami ISO/IEC 27002:2022, vključuje področja kontrol, potrebna za tveganje dobaviteljev, storitve v oblaku, beleženje, spremljanje, varno arhitekturo, ločevanje okolij in upravljanje sprememb.

Bistvo je preprosto: segmentacija omrežja in pregled pravil požarnega zidu sta zdaj dokazili upravljanja.

Operativni vzorec Clarysec: 8.20, 8.22 in 8.32

Clarysec segmentacijo in pregled požarnih zidov obravnava kot enoten operativni vzorec po kontrolah ISO/IEC 27002:2022, ne kot izolirane tehnične naloge.

Tri primarne kontrole so:

V Zenith Blueprint: 30-koračni načrt presojevalca [ZB] Clarysec varnost omrežja umešča v fazo Controls in Action, korak 20: kontrole 8.18 do 8.26. Vodnik jasno oblikuje temeljno presojno vprašanje:

»V jedru ta kontrola od organizacij zahteva, da zagotovijo, da so omrežja varna že po arhitekturi, ne le z naknadnim dodajanjem požarnih zidov ali protivirusne programske opreme. To pomeni strateško razmišljanje o segmentaciji omrežja, nadzoru dostopa, šifriranju med prenosom, spremljanju in večplastni obrambi. Začne se s preprostim vprašanjem: kdo in kaj komunicira ter ali bi sploh smelo?«

To vprašanje, »kdo in kaj komunicira ter ali bi sploh smelo?«, je najboljše praktično izhodišče za pregled pravil požarnega zidu. Razpravo premakne od tisočev nejasnih vnosov ACL k poslovno utemeljenim tokovom.

Isti Zenith Blueprint ekipam nalaga presojo omrežne arhitekture s preverjanjem, ali so pravila požarnega zidu, IPS/IDS in konfiguracije oddaljenega dostopa aktualne in utrjene, ter potrditev, da varnostne skupine v oblaku, usmerjanje in pravila VPC ali podomrežij ustrezajo predvideni arhitekturi. Presojevalcem prav tako pove, naj pričakujejo diagram varnostne arhitekture omrežja, ki prikazuje požarne zidove, prehode VPN, cone DMZ, ločevanje VLAN-ov in meje zaupanja.

Za upravljanje sprememb Zenith Blueprint umešča kontrolo ISO/IEC 27002:2022 8.32 v fazo Controls in Action, korak 21: kontrole 8.27 do 8.34, in poudari, zakaj upravljanje požarnih zidov odpove, kadar je nadzor sprememb šibek:

»Ta kontrola priznava trdo resnico v IT: številnih incidentov ne povzročijo napadi, temveč slabo upravljane spremembe. Preširoko odprto pravilo požarnega zidu. Omogočena nastavitev za odpravljanje napak. Pozabljena odvisnost po migraciji.«

Prav tako začasna odprtja požarnega zidu postanejo trajne napadalne poti.

Kako je videti dobra segmentacija omrežja

Zrel program segmentacije ima štiri ravni.

Prvič, ima model coniranja. Cone niso poljubna podomrežja. So meje zaupanja, usklajene s poslovno funkcijo in občutljivostjo podatkov, na primer DMZ, izpostavljen internetu, produkcijska aplikacijska raven, produkcijska raven podatkovnih baz, korporativno uporabniško omrežje, omrežje za privilegirano upravljanje, razvojno okolje, testno okolje, omrežje za varnostno kopiranje, Wi‑Fi za goste, cona OT ali IoT in cona za dostop tretjih oseb.

Drugič, ima matriko tokov. Za vsak par con organizacija dokumentira dovoljeni vir, cilj, protokol, vrata, aplikacijo, poslovnega lastnika, lastnika sistema, vrsto podatkov, utemeljitev in zahtevo glede beleženja.

Tretjič, ima lastništvo pravil. Vsako pravilo požarnega zidu, pravilo varnostne skupine v oblaku ali politika programsko opredeljene omrežne meje ima lastnika, datum poteka ali ponovne certifikacije, povezan zahtevek za spremembo in poslovno utemeljitev. »Any to any« je treba obravnavati kot ugotovitev, razen če gre za formalno sprejeto tveganje, ki je časovno omejeno in podprto s kompenzacijskimi kontrolami.

Četrtič, ima ponavljajoče se preglede. Pregled pomeni več kot enkrat letno izvoziti bazo pravil požarnega zidu. Vključuje ponovno certifikacijo lastnikov, primerjavo z opazovanim prometom, zaznavanje neuporabljenih pravil, preverjanje začasnih izjem, pregled izpostavljenosti internetu, testiranje segmentacije in uskladitev z evidenco sredstev.

Clarysecova Politika varnosti omrežja [P-NS] jasno določa pričakovanje za podjetje:

»Ves promet med conami mora biti nadzorovan s požarnimi zidovi ali programsko opredeljenimi rešitvami omrežne meje, z izrecnimi konfiguracijami privzetega zavračanja.«

Iz Enterprise Policy, Network Security Policy, razdelek »Zahteve upravljanja«, klavzula 5.2.

Ista politika spremembe požarnega zidu neposredno povezuje z upravljanjem sprememb:

»Vsaka sprememba naborov pravil požarnega zidu, usmerjevalnih tabel ali konfiguracij varnostnih skupin mora slediti organizacijski Politiki upravljanja sprememb (P5), vključno z načrti povrnitve in presojnim beleženjem.«

Iz Enterprise Policy, Network Security Policy, razdelek »Zahteve upravljanja«, klavzula 5.4.

Za MSP ter mala in srednja podjetja Clarysecova Politika varnosti omrežja za MSP [P-NS-SME] zagotavlja isto načelo v operativni obliki:

»Pravila privzetega zavračanja morajo biti uveljavljena za vse vhodne povezave, razen če so izrecno zahtevane in odobrene«

Iz SME Policy, Network Security Policy-sme, razdelek »Zahteve za izvajanje politike«, klavzula 6.1.2.

In posebej za segmentacijo:

»Promet med segmenti mora biti filtriran, dostop med segmenti pa mora slediti načelu najmanjših privilegijev«

Iz SME Policy, Network Security Policy-sme, razdelek »Zahteve za izvajanje politike«, klavzula 6.2.3.

Te klavzule politike presojevalcu omogočajo sledljivost od tveganja do kontrole, od kontrole do pravila, od pravila do odobritve in od odobritve do dnevnikov.

En paket dokazil za ISO 27001, NIS2, DORA in GDPR

Napaka, ki jo naredijo številne ekipe, je priprava ločenih paketov dokazil: enega za ISO/IEC 27001:2022, enega za NIS2, enega za GDPR, enega za stranke z zahtevami DORA in enega za kibernetsko zavarovanje.

Boljši pristop je vzpostaviti enoten paket dokazil za segmentacijo in upravljanje požarnih zidov, ki se preslika čez več okvirov.

Zenith Controls: vodnik za navzkrižno skladnost [ZC] preslika kontrolo ISO/IEC 27002:2022 8.22 Ločevanje omrežij kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost, je usklajena s konceptom kibernetske varnosti Protect ter operativno zmožnostjo varnosti sistemov in omrežij. 8.22 povezuje z 8.20 Varnost omrežja, 8.21 Varnost omrežnih storitev, 8.7 Zaščita pred zlonamerno programsko opremo, 8.27 Načela varne sistemske arhitekture in inženiringa ter 8.31 Ločevanje razvojnih, testnih in produkcijskih okolij.

Vodnik relevantnost segmentacije za NIS2 pojasni tako:

»Ločevanje omrežij je neposreden odgovor na te obveznosti, saj zmanjšuje napadalno površino in preprečuje lateralno gibanje med omrežno povezanimi sistemi.«

Ta stavek pojasnjuje, zakaj programi kibernetske higiene NIS2 segmentacije ne smejo obravnavati kot izbirne. Zajezitev izsiljevalske programske opreme ni povezana le z zaščito končnih točk. Gre za omejevanje lateralnega gibanja, ko preprečevanje odpove.

Za GDPR Zenith Controls preslika 8.22 na člen 32 in uvodno izjavo 49 ter poudarja, da omrežni diagrami in politike coniranja postanejo ključna dokazila o skladnosti. Za DORA Zenith Controls preslika varnost omrežja in ločevanje na upravljanje tveganj IKT in zajezitev incidentov. Testi segmentacije lahko podprejo dokazila o odpornosti IKT, zlasti kadar dokazujejo, da se kompromitacija v eni coni ne more prosto premakniti v kritične finančne storitve, repozitorije osebnih podatkov ali sisteme za privilegirano upravljanje.

Ta tabela ni le preslikava skladnosti. Je načrt za zbiranje dokazil.

Pregled pravil požarnega zidu, ki dejansko deluje

Pregled pravil požarnega zidu odpove, kadar postavi le vprašanje: »Ali je to pravilo še vedno potrebno?« Lastniki pravil pogosto odgovorijo pritrdilno, ker se bojijo, da bi kaj prekinili.

Boljši pregled postavi šest vprašanj:

1. Katero poslovno storitev to pravilo podpira?
2. Kateri lastnik sredstva in lastnik podatkov sta odobrila tok?
3. Ali je cilj v pravilni coni glede na podatke in funkcijo?
4. Ali je pravilo bolj permisivno, kot zahteva opazovani promet?
5. Ali je za tokove z visokim tveganjem omogočeno beleženje?
6. Ali ima pravilo datum pregleda, datum poteka ali zapis o izjemi?

Politika varnosti omrežja za MSP zahteva periodični pregled:

»Ponudnik IT-podpore mora izvesti letni pregled pravil požarnega zidu, omrežne arhitekture in brezžičnih konfiguracij«

Iz SME Policy, Network Security Policy-sme, razdelek »Zahteve upravljanja«, klavzula 5.6.1.

Letni pregled je izhodišče, ne zgornja meja. Pravila z visokim tveganjem potrebujejo pogostejšo ponovno certifikacijo.

Politika varnosti omrežja je glede izjem izrecna:

»Zahtevo morata pregledati in odobriti vodja ISMS ali CISO ter jo evidentirati v registru izjem ISMS, z najdaljšim obdobjem odobritve 90 dni, ki se lahko podaljša po ponovni oceni.«

Iz Enterprise Policy, Network Security Policy, razdelek »Obravnava tveganja in izjeme«, klavzula 7.3.

Za MSP ter mala in srednja podjetja Politika varnosti omrežja za MSP zahteva, da zahtevki za izjeme vsebujejo ustrezna minimalna dejstva:

»Zahteva mora vključevati utemeljitev, obseg, trajanje in kompenzacijske kontrole (npr. uvrstitev IP-naslovov na seznam dovoljenih, beleženje)«

Iz SME Policy, Network Security Policy-sme, razdelek »Obravnava tveganja in izjeme«, klavzula 7.3.3.

Ta klavzula obravnavo izjem iz neformalnega pogovora spremeni v preverljivo obravnavo tveganja.

Praktičen primer: odstranitev tveganega pravila za produkcijsko podatkovno bazo

Predpostavimo, da podjetje med pregledom najde naslednje pravilo:

To je klasična presojna ugotovitev. Krši načelo najmanjših privilegijev, nima jasnega lastnika, datuma poteka, aktualne utemeljitve in beleženja. Če produkcijska podatkovna baza vsebuje osebne podatke strank, ustvarja tudi izpostavljenost po členu 32 GDPR.

Postopek odprave mora ustvariti dokazila, ne le odstraniti slabega pravila.

Clarysecova Politika beleženja in spremljanja [P-LM] zunanje komunikacije in sprožilce pravil požarnega zidu vključuje med dogodke, relevantne za beleženje:

»Zunanje komunikacije in sprožilci pravil požarnega zidu«

Iz Enterprise Policy, Logging and Monitoring Policy, razdelek »Zahteve za izvajanje politike«, klavzula 6.1.1.6.

Pri pravilih med conami z visokim tveganjem morajo sprožilci požarnega zidu napajati SIEM ali platformo za spremljanje, z opozorili za neobičajne izvorne gostitelje, obsege ali časovna okna.

Politika za MSP ter mala in srednja podjetja zahteva tudi disciplino sprememb:

»Vse spremembe omrežnih konfiguracij (pravila požarnega zidu, seznami ACL na stikalih, usmerjevalne tabele) morajo slediti dokumentiranemu procesu upravljanja sprememb«

Iz SME Policy, Network Security Policy-sme, razdelek »Zahteve za izvajanje politike«, klavzula 6.9.1.

Ena sama odprava tega pravila ustvari dokazila za operativni nadzor ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 in 8.32, kibernetsko higieno NIS2, člen 32 GDPR in upravljanje tveganj IKT v slogu DORA.

Vključiti je treba oblak, SaaS in hibridna omrežja

Sodobna segmentacija niso le VLAN-i in fizični požarni zidovi. Vključuje varnostne skupine AWS, omrežne varnostne skupine Azure, omrežne politike Kubernetes, usmerjevalne tabele v oblaku, skrbniške sezname dovoljenih v SaaS, zasebne končne točke, VPN-je, SD-WAN, posrednike, ki upoštevajo identiteto, in programsko opredeljene kontrole omrežne meje.

Za ponudnika SaaS ali regulirano digitalno storitev mora pregled pravil požarnega zidu vključevati najmanj:

• iz interneta dostopne izravnalnike obremenitve in aplikacijske prehode;
• varnostne skupine v oblaku in omrežne sezname ACL;
• usmerjevalne tabele zasebnih podomrežij;
• povezave peering in poti prek prehodov transit gateway;
• poti VPN in oddaljenega upravljanja;
• skrbniške vmesnike in upravljavske ravni;
• vhodni promet Kubernetes in omrežne politike;
• dostop izvajalnikov CI/CD v produkcijo;
• pokritost beleženja za zavrnjene in dovoljene tokove z visokim tveganjem;
• dostop podpore tretjih oseb in poti »break glass«.

Če varnostna skupina v oblaku dovoljuje vhodni promet do podatkovne baze iz širokega korporativnega razpona IP-naslovov, jo obravnavajte kot pravilo požarnega zidu. Potrebuje lastništvo, utemeljitev, odobritev, pregled, beleženje in rok poteka.

Tu podporni standardi ISO dodatno okrepijo zgodbo. ISO/IEC 27017 podpira jasnost glede odgovornosti za varnost v oblaku. ISO/IEC 27033 zagotavlja podrobnejše smernice o varnostni arhitekturi omrežja, DMZ-jih, segmentacijskih conah, filtriranju prometa in varnih komunikacijah med omrežji. ISO/IEC 27701 krepi upravljanje zasebnosti, kadar se osebno določljivi podatki premikajo po omrežjih. ISO/IEC 27035 podpira zajezitev incidentov, ISO/IEC 27005 pa izbiro segmentacije kot obravnave tveganja za nepooblaščen dostop, širjenje zlonamerne programske opreme in lateralno gibanje.

Kako presojevalci isto kontrolo testirajo različno

Ena od prednosti Zenith Controls je, da pojasni, kako različne metodologije presoje preverjajo isto kontrolo. Dokazila je mogoče ponovno uporabiti, vprašanja pa se razlikujejo.

Ocenjevalec, usmerjen v DORA, lahko vpraša, ali se lahko kompromitacija plačilnega prehoda razširi v podatkovne baze strank. Pristojni organ NIS2 lahko vpraša, ali lahko izsiljevalska programska oprema na skrbniški delovni postaji doseže ključne sisteme za izvajanje storitev. Organ za GDPR lahko vpraša, katere omejitve na omrežni ravni so varovale sisteme, ki obdelujejo osebne podatke. Presojevalec ISO lahko preprosto zahteva oceno tveganja, SoA, politiko, postopek in dokazila, da so bili pregledi izvedeni.

Najboljši programi na vsa ta vprašanja odgovorijo z istimi artefakti.

Metrike, s katerimi segmentacija postane vidna vodstvu

NIS2 in DORA krepita odgovornost vodstva. ISO/IEC 27001:2022 zahteva voditeljstvo, cilje, vloge, vire, poročanje in nenehno izboljševanje. To pomeni, da segmentacija potrebuje metrike, ki jih vodstvo razume.

Uporabne metrike za vodstvo vključujejo:

• odstotek pravil požarnega zidu z dodeljenim lastnikom;
• odstotek pravil z dokumentirano poslovno utemeljitvijo;
• število poteklih začasnih pravil;
• število pravil z virom, ciljem ali storitvijo »any«;
• število storitev, izpostavljenih internetu, po kritičnosti;
• odstotek tokov z visokim tveganjem med conami z omogočenim beleženjem;
• število nujnih sprememb požarnega zidu na četrtletje;
• odstotek vzorčenih pravil, usklajenih z odobrenimi zahtevki za spremembe;
• število neuspešnih testov segmentacije;
• povprečni čas odprave tveganih ali neuporabljenih pravil;
• število izjem, starejših od 90 dni;
• število pregledanih in ponovno certificiranih pravil za dostop tretjih oseb.

Politika varnosti omrežja v razdelku »Uveljavljanje in skladnost«, klavzula 8.2.2, opredeljuje »učinkovitost pravil požarnega zidu« kot vidik skladnosti in uveljavljanja. Ta izraz je pomemben, ker obstoj pravil ne zadostuje. Pravila morajo biti učinkovita, pregledana in usklajena s trenutnim tveganjem.

Zgradite paket dokazil o segmentaciji za leto 2026

Praktičen paket dokazil za segmentacijo in pregled pravil požarnega zidu mora biti pripravljen, preden ga zahteva presojevalec.

Najmanj vzdržujte:

1. aktualni diagram omrežne arhitekture, vključno z oblaki in hibridnimi conami;
2. standard klasifikacije con, vključno z občutljivostjo in ravnijo zaupanja;
3. matriko tokov za kritične storitve in sisteme z osebnimi podatki;
4. izvoz pravil požarnega zidu in varnostnih skupin v oblaku;
5. register lastnikov pravil in ponovne certifikacije;
6. postopek pregleda požarnega zidu in koledar pregledov;
7. zapise o spremembah za vzorčene spremembe požarnega zidu;
8. register izjem z odobritvami, roki poteka in kompenzacijskimi kontrolami;
9. rezultate testiranja segmentacije in zapise o odpravi;
10. dokazila o beleženju in spremljanju za tokove z visokim tveganjem;
11. odzivne priročnike za incidente, ki prikazujejo zajezitev po conah;
12. metrike poročanja vodstvu in zapisnike sestankov.

Ta dokazila preslikajte na klavzule ISO/IEC 27001:2022 in področja kontrol iz Priloge A. Nato jih navzkrižno povežite s členom 21 NIS2, členom 32 GDPR, zahtevami DORA za upravljanje tveganj IKT in testiranje, rezultati NIST CSF 2.0, kot so GOVERN, PROTECT, DETECT in RESPOND, ter praksami upravljanja COBIT.

NIST CSF 2.0 je še posebej uporaben kot komunikacijska plast za upravni odbor. Njegova funkcija GOVERN se osredotoča na zakonske, regulativne in pogodbene zahteve, apetit po tveganju, vloge, politike in nadzor. Operativni rezultati obravnavajo upravljanje konfiguracije, beleženje, spremljanje, varstvo podatkov, odziv na incidente in obnovitev. To vodstvu pomaga razumeti tveganje, ne da bi bralo ACL-je požarnega zidu.

Pogoste ugotovitve, ki jih Clarysec vidi pri presojah segmentacije

Pri SaaS, fintech podjetjih, ponudnikih upravljanih storitev ter reguliranih malih in srednjih podjetjih se ponavljajo iste ugotovitve:

• ravno omrežje med uporabniškimi končnimi točkami in produkcijskimi storitvami;
• produkcijske podatkovne baze, dosegljive iz razvojnih ali korporativnih omrežij;
• široke varnostne skupine v oblaku, kopirane iz starih predlog;
• začasna pravila dobaviteljev brez roka poteka;
• spremembe požarnega zidu, izvedene zunaj procesa sprememb;
• pravila brez lastnika ali poslovne utemeljitve;
• onemogočeno beleženje pri dovolilnih pravilih z visokim tveganjem;
• Wi‑Fi za goste ni popolnoma izoliran;
• skrbniški vmesniki so dosegljivi iz splošnih omrežij;
• diagrami se ne ujemajo z dejanskim usmerjanjem;
• ni dokazil, da so bili pregledi pravil zaključeni;
• po večjih arhitekturnih spremembah ni testiranja segmentacije;
• ni preslikave med sistemi z osebnimi podatki in omrežnimi conami;
• ni poročanja vodstvu o izpostavljenosti omrežja.

Te ugotovitve niso le tehnične slabosti. Spodkopavajo zmožnost organizacije, da dokaže kibernetsko higieno NIS2, operativno odpornost DORA in odgovornost po členu 32 GDPR.

Od reaktivnega čiščenja do zagovorljive kontrole

Segmentacija omrežja in pregled pravil požarnega zidu sta točka, kjer se varnostna arhitektura sreča s presojno realnostjo. Če lahko pokažete model coniranja na podlagi tveganj, nadzorovane tokove med conami, odobrene spremembe požarnega zidu, časovno omejene izjeme, dokazila o beleženju in periodično preverjanje, lahko na širok nabor vprašanj ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST in COBIT odgovorite z eno koherentno zgodbo.

Clarysec vam lahko pomaga zgraditi to zgodbo.

Uporabite Zenith Blueprint: 30-koračni načrt presojevalca za strukturiranje poti implementacije, zlasti Controls in Action, korak 20 za varnost omrežja in segmentacijo ter korak 21 za upravljanje sprememb. Uporabite Zenith Controls: vodnik za navzkrižno skladnost za preslikavo kontrol ISO/IEC 27002:2022 8.20, 8.22 in 8.32 čez pričakovanja presoj NIS2, DORA, GDPR, NIST in COBIT. Svoja operativna pravila zasidrajte v Clarysecovih Politiki varnosti omrežja, Politiki varnosti omrežja za MSP in Politiki beleženja in spremljanja.

Vaš naslednji korak je preprost in zelo koristen: izberite eno kritično storitev, na primer produkcijsko okolje za stranke, obdelavo plačil ali upravljanje identitet, in ta teden izvedite vzorčni pregled 10 pravil. Za vsako pravilo potrdite lastnika, utemeljitev, vir, cilj, vrata, beleženje, zahtevek za spremembo in rok poteka. Če teh sedmih dejstev ne morete dokazati, imate začetek načrta izboljšanja segmentacije za leto 2026.