Palomuurisääntöjen katselmointi ISO 27001:n, NIS2:n, DORA:n ja GDPR:n vaatimuksiin

Kello on 07.42 maanantaiaamuna. Kasvavan SaaS- ja FinTech-palveluntarjoajan CISO lukee kolmea erillistä viestiä.

Ensimmäinen on SOC:lta. Vaarantunut kehittäjän työasema yritti yön aikana muodostaa yhteyden sisäiseen tietokanta-aliverkkoon. Liikenne estettiin, mutta analyytikko tarvitsee vahvistuksen siitä, että palomuurisääntö on tarkoituksellinen, ajantasainen ja hyväksytty.

Toinen on suurelta yritysasiakkaalta. Asiakas pyytää todentavaa aineistoa siitä, että tuotanto-, kehitys-, yritys- ja tukipalveluympäristöt on segmentoitu, palomuurisäännöt katselmoidaan ja poikkeuksilla on päättymispäivä.

Kolmas on vaatimustenmukaisuuspäälliköltä. Organisaatiolla on NIS2-altistuma merkittävänä digitaalisena palveluntarjoajana, GDPR-vastuita käsittelijänä sekä finanssialan asiakkaita, jotka pyytävät DORA-tyyppistä ICT-riskinäyttöä. Hallitus haluaa tietää, voidaanko kaikkiin kolmeen vastata samalla ISO/IEC 27001:2022 -todentavalla aineistolla.

Sitten valmistuu poikkeaman jälkiarviointi. Kehityspalvelin oli lähes altistunut internetille myöhäisillan muutoksen yhteydessä. Asiakastietoja ei menetetty, mutta forensiikkatiimi havaitsi alkuperäistä virhettä vakavamman ongelman: viisi vuotta vanha “tilapäinen testi” -palomuurisääntö salli edelleen laajan liikkumisen kehityksen ja tuotannon välillä. Jos hyökkääjä olisi saanut pääsyn, verkko olisi tarjonnut vain vähän vastusta.

Tässä vaiheessa moni organisaatio tunnistaa kivuliaan tosiasian. Niillä voi olla palomuureja, VLAN-verkkoja, pilven tietoturvaryhmiä ja kaavioita, mutta niillä ei ole hallintaa segmentointivyöhykkeille, sääntöjen omistajuudelle, tilapäisille käyttöoikeuksille, muutosten hyväksynnöille, uudelleensertifioinnille eikä auditointinäytölle.

Vuonna 2026 “meillä on palomuuri” ei ole puolustettavissa oleva vastaus. Auditoijat, viranomaiset, asiakkaat ja vakuuttajat haluavat näyttöä siitä, että verkot on erotettu tarkoituksellisesti, liikennettä ohjataan liiketoimintatarpeen perusteella, riskialttiita poikkeuksia hallitaan ja lokit osoittavat kontrollien toimivan.

Miksi palomuurien hallinta on nyt hallitustason asia

Verkon segmentointia pidettiin aiemmin teknisenä suunnittelukysymyksenä. Infrastruktuuritiimit omistivat VLAN-verkot, palomuurien ylläpitäjät ylläpitivät sääntökantoja, pilvitiimit hallitsivat tietoturvaryhmiä ja vaatimustenmukaisuus näki auditoinneissa vain kaavion.

Tämä toimintamalli ei enää riitä.

NIS2-direktiivi edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset ja oikeasuhtaiset tekniset, operatiiviset ja organisatoriset toimenpiteet verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi. 21 artikla sisältää politiikat riskianalyysistä, poikkeamien käsittelystä, liiketoiminnan jatkuvuudesta, toimitusketjun turvallisuudesta, hankinnan ja ylläpidon turvallisuudesta, vaikuttavuuden arvioinnista, perustason kyberhygieniasta, pääsynhallinnasta ja omaisuudenhallinnasta. Johtoelinten on hyväksyttävä nämä kyberturvallisuusriskien hallintatoimenpiteet ja valvottava niitä.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen moniin finanssialan toimijoihin, ja se tekee ICT-riskienhallinnasta hallinnoidun ja dokumentoidun käytännön. 5, 6 ja 8 artikla edellyttävät hallintaa, ICT-riskienhallinnan viitekehystä sekä ICT:n tukemien liiketoimintatoimintojen, tietovarojen, ICT-omaisuuserien, riippuvuuksien, kriittisten omaisuuserien ja yhteyksien tunnistamista. 9, 10 ja 11 artikla käsittelevät suojaamista, ennaltaehkäisyä, havaitsemista, reagointia ja toipumista. 24–27 artikla edellyttävät digitaalisen operatiivisen häiriönsietokyvyn testausta, mukaan lukien edistynyt testaus tietyille toimijoille. Tämä tekee segmentoinnista häiriönsietokykyyn liittyvän kysymyksen, ei pelkästään palomuurikysymystä.

GDPR lisää tietosuojan osoitusvelvollisuuden kerroksen. 32 artikla edellyttää riskitasoon nähden asianmukaisia teknisiä ja organisatorisia toimenpiteitä turvallisuustason varmistamiseksi, mukaan lukien luottamuksellisuus, eheys, saatavuus ja häiriönsietokyky. 5(1)(f) artikla edellyttää eheyttä ja luottamuksellisuutta, ja 5(2) artikla edellyttää osoitusvelvollisuutta. Jos henkilötietojärjestelmiin pääsee vaarantuneilta päätelaitteilta, vierasverkoista tai hallitsemattomien kolmansien osapuolten reittien kautta, valvontaviranomainen voi kysyä, miksi tällaiset reitit olivat olemassa.

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmäperustan, joka yhdistää nämä velvoitteet. Se edellyttää soveltamisalaa, sidosryhmien vaatimuksia, riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa, operatiivista suunnittelua ja ohjausta, johdon vastuuta ja tilivelvollisuutta, mitattavia tavoitteita, dokumentoitua tietoa ja jatkuvaa parantamista. Liite A sisältää ISO/IEC 27002:2022 -ohjeistuksen tukemana ne kontrollialueet, joita tarvitaan toimittajariskeihin, pilvipalveluihin, lokitukseen, seurantaan, turvalliseen arkkitehtuuriin, ympäristöjen erottamiseen ja muutoksenhallintaan.

Ydinviesti on selvä: verkon segmentointi ja palomuurisääntöjen katselmointi ovat nyt hallintanäyttöä.

Clarysecin toimintamalli: 8.20, 8.22 ja 8.32

Clarysec käsittelee segmentointia ja palomuurien katselmointia yhtenä ISO/IEC 27002:2022 -kontrollien toimintamallina, ei erillisinä teknisinä tehtävinä.

Kolme ensisijaista kontrollia ovat:

Zenith Blueprint: auditoijan 30 vaiheen tiekartta [ZB] sijoittaa Clarysecillä verkkoturvallisuuden Kontrollit käytännössä -vaiheeseen, vaiheeseen 20: kontrollit 8.18–8.26. Opas muotoilee keskeisen auditointikysymyksen selkeästi:

“Ytimeltään tämä kontrolli edellyttää, että organisaatiot varmistavat verkkojen olevan turvallisia arkkitehtuurinsa perusteella, eivät vain lisäämällä palomuureja tai virustorjuntaa jälkikäteen. Tämä tarkoittaa strategista ajattelua verkon segmentoinnista, pääsynhallinnasta, siirrettävien tietojen salauksesta, seurannasta ja kerroksellisesta puolustuksesta. Se alkaa yksinkertaisesta kysymyksestä: ketkä ja mitkä kommunikoivat keskenään, ja pitäisikö niiden kommunikoida?”

Tuo kysymys, “ketkä ja mitkä kommunikoivat keskenään, ja pitäisikö niiden kommunikoida?”, on paras käytännön lähtökohta palomuurisääntöjen katselmoinnille. Se siirtää keskustelun tuhansista vaikeaselkoisista ACL-merkinnöistä kohti liiketoiminnallisesti perusteltuja liikennevirtoja.

Sama Zenith Blueprint ohjeistaa tiimejä arvioimaan verkkoarkkitehtuuria varmistamalla, että palomuurisäännöt, IPS/IDS ja etäkäyttömääritykset ovat ajantasaisia ja kovennettuja, sekä vahvistamaan, että pilven tietoturvaryhmät, reititys ja VPC- tai aliverkkosäännöt vastaavat tavoiteltua arkkitehtuuria. Se ohjeistaa myös auditoijia odottamaan verkkoturvallisuusarkkitehtuurin kaaviota, joka näyttää palomuurit, VPN-yhdyskäytävät, DMZ-vyöhykkeet, VLAN-erottelun ja luottamusrajat.

Muutoksenhallinnan osalta Zenith Blueprint sijoittaa ISO/IEC 27002:2022 -kontrollin 8.32 Kontrollit käytännössä -vaiheeseen, vaiheeseen 21: kontrollit 8.27–8.34, ja korostaa, miksi palomuurien hallinta epäonnistuu, kun muutosten hallinta on heikkoa:

“Tämä kontrolli tunnistaa IT:n kovan tosiasian: monet poikkeamat eivät johdu hyökkäyksistä vaan huonosti hallituista muutoksista. Palomuurisääntö avattiin liian laajaksi. Debug-asetus jäi käyttöön. Migraation jälkeen unohtui riippuvuus.”

Juuri näin tilapäisistä palomuurin avauksista tulee pysyviä hyökkäyspolkuja.

Miltä hyvä verkon segmentointi näyttää

Kypsässä segmentointiohjelmassa on neljä kerrosta.

Ensinnäkin sillä on vyöhykemalli. Vyöhykkeet eivät ole mielivaltaisia aliverkkoja. Ne ovat luottamusrajoja, jotka on kohdistettu liiketoimintatoimintoon ja tietojen arkaluonteisuuteen, kuten internetiin avautuva DMZ, tuotannon sovelluskerros, tuotannon tietokantakerros, yrityksen käyttäjäverkko, etuoikeutettu hallintaverkko, kehitysympäristö, testiympäristö, varmuuskopiointiverkko, vieras-Wi-Fi, OT- tai IoT-vyöhyke ja kolmansien osapuolten pääsyvyöhyke.

Toiseksi sillä on virtausmatriisi. Organisaatio dokumentoi jokaiselle vyöhykeparille sallitun lähteen, kohteen, protokollan, portin, sovelluksen, liiketoimintavastaavan, järjestelmäomistajan, tietotyypin, perustelun ja lokitusvaatimuksen.

Kolmanneksi sillä on sääntöjen omistajuus. Jokaisella palomuurisäännöllä, pilven tietoturvaryhmän säännöllä tai ohjelmistomääritellyllä perimeter-politiikalla on omistaja, päättymis- tai uudelleensertifiointipäivä, linkitetty muutostiketti ja liiketoimintaperuste. “Any to any” on käsiteltävä havaintona, ellei sitä ole muodollisesti hyväksytty riskinä, aikarajoitettu ja tuettu kompensoivilla kontrolleilla.

Neljänneksi sillä on toistuva katselmointi. Katselmointi tarkoittaa enemmän kuin palomuurin sääntökannan vientiä kerran vuodessa. Siihen sisältyvät omistajien uudelleensertifiointi, vertailu havaittuun liikenteeseen, käyttämättömien sääntöjen tunnistaminen, tilapäisten poikkeusten validointi, internet-altistuksen katselmointi, segmentointitestaus ja täsmäytys omaisuusluetteloon.

Clarysecin Verkkoturvallisuuspolitiikka [P-NS] asettaa yritystason odotuksen selkeästi:

“Kaikki vyöhykkeiden välinen liikenne on hallittava palomuureilla tai ohjelmistomääritellyillä perimeter-ratkaisuilla käyttäen nimenomaisia oletusarvoisesti estäviä konfiguraatioita.”

Yritystason politiikka, Network Security Policy, kohta “Hallintavaatimukset,” lauseke 5.2.

Sama politiikka yhdistää palomuurimuutokset suoraan muutoksenhallintaan:

“Kaikkien palomuurisääntökantoihin, reititystauluihin tai tietoturvaryhmien konfiguraatioihin tehtävien muutosten on noudatettava organisaation Change Management Policy (P5) -politiikkaa, mukaan lukien palautussuunnitelmat ja auditointilokitus.”

Yritystason politiikka, Network Security Policy, kohta “Hallintavaatimukset,” lauseke 5.4.

Pk-yrityksille Clarysecin Network Security Policy-sme [P-NS-SME] esittää saman periaatteen operatiivisesti:

“Oletusarvoisesti estävät säännöt on toteutettava kaikille saapuville yhteyksille, ellei niitä nimenomaisesti edellytetä ja hyväksytä.”

Pk-yrityspolitiikka, Network Security Policy-sme, kohta “Politiikan toimeenpanovaatimukset,” lauseke 6.1.2.

Ja erityisesti segmentoinnista:

“Segmenttien välinen liikenne on suodatettava, ja segmenttien välisen pääsyn on noudatettava vähimmän oikeuden periaatetta.”

Pk-yrityspolitiikka, Network Security Policy-sme, kohta “Politiikan toimeenpanovaatimukset,” lauseke 6.2.3.

Näiden politiikkalausekkeiden avulla auditoija voi jäljittää riskin kontrolliin, kontrollin sääntöön, säännön hyväksyntään ja hyväksynnän lokeihin.

Yksi näyttökokonaisuus ISO 27001:lle, NIS2:lle, DORA:lle ja GDPR:lle

Moni tiimi tekee virheen rakentamalla erillisiä näyttökokonaisuuksia: yhden ISO/IEC 27001:2022:lle, yhden NIS2:lle, yhden GDPR:lle, yhden DORA-asiakkaille ja yhden kybervakuutusta varten.

Parempi tapa on rakentaa yksi segmentoinnin ja palomuurien hallinnan näyttökokonaisuus, joka kartoitetaan eri viitekehyksiin.

Zenith Controls: vaatimustenmukaisuuksien välinen opas [ZC] kartoittaa ISO/IEC 27002:2022 -kontrollin 8.22 Verkkojen eriyttäminen ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, ja kohdistaa sen Protect-kyberturvallisuuskonseptiin sekä järjestelmä- ja verkkoturvallisuuden operatiiviseen kyvykkyyteen. Se yhdistää 8.22:n kontrolleihin 8.20 Verkkoturvallisuus, 8.21 Verkkopalvelujen turvallisuus, 8.7 Haittaohjelmasuojaus, 8.27 Turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteet sekä 8.31 Kehitys-, testi- ja tuotantoympäristöjen erottaminen.

Opas selittää segmentoinnin NIS2-relevanssin näin:

“Verkkojen eriyttäminen on suora vastaus näihin velvoitteisiin: se pienentää hyökkäyspintaa ja estää lateraalista liikkumista verkotetuissa järjestelmissä.”

Tämä lause kuvaa, miksi NIS2:n kyberhygieniaohjelmien ei tule pitää segmentointia valinnaisena. Kiristyshaittaohjelmien rajaaminen ei perustu vain päätelaitesuojausratkaisuihin. Kyse on lateraalisen liikkumisen rajoittamisesta, kun ennaltaehkäisy pettää.

GDPR:n osalta Zenith Controls kartoittaa 8.22:n 32 artiklaan ja johdanto-osan 49 kappaleeseen ja toteaa, että verkkokaavioista ja vyöhykepolitiikoista tulee keskeistä vaatimustenmukaisuusnäyttöä. DORA:n osalta Zenith Controls kartoittaa verkkoturvallisuuden ja eriyttämisen ICT-riskienhallintaan ja poikkeamien rajaamiseen. Segmentointitestit voivat tukea ICT-häiriönsietokyvyn näyttöä, erityisesti kun ne osoittavat, ettei yhden vyöhykkeen vaarantuminen mahdollista vapaata siirtymistä kriittisiin finanssipalveluihin, henkilötietovarastoihin tai etuoikeutettuihin hallintajärjestelmiin.

Tämä taulukko ei ole vain vaatimustenmukaisuuskartoitus. Se on tiekartta todentavan aineiston keräämiseen.

Palomuurisääntöjen katselmointi, joka todella toimii

Palomuurisääntöjen katselmointi epäonnistuu, jos se kysyy vain: “Tarvitaanko tätä sääntöä edelleen?” Sääntöjen omistajat vastaavat usein kyllä, koska he pelkäävät rikkovansa jotakin.

Parempi katselmointi esittää kuusi kysymystä:

1. Mitä liiketoimintapalvelua tämä sääntö tukee?
2. Mikä omaisuuden omistaja ja tiedon omistaja hyväksyi liikennevirran?
3. Onko kohde tietojen ja toiminnon kannalta oikeassa vyöhykkeessä?
4. Onko sääntö sallivampi kuin havaittu liikenne edellyttää?
5. Onko lokitus käytössä korkean riskin liikennevirroille?
6. Onko säännöllä katselmointipäivä, päättymispäivä tai poikkeuskirjaus?

Network Security Policy-sme edellyttää säännöllistä katselmointia:

“IT-tukipalveluntarjoajan on tehtävä vuosittainen katselmointi palomuurisäännöistä, verkkoarkkitehtuurista ja langattomista konfiguraatioista.”

Pk-yrityspolitiikka, Network Security Policy-sme, kohta “Hallintavaatimukset,” lauseke 5.6.1.

Vuosittainen katselmointi on perustaso, ei yläraja. Korkean riskin säännöt tarvitsevat tiheämpää uudelleensertifiointia.

Network Security Policy on poikkeuksista yksiselitteinen:

“ISMS-päällikön tai CISO:n on katselmoitava ja hyväksyttävä pyyntö, ja se on kirjattava ISMS-poikkeusrekisteriin. Hyväksynnän enimmäiskesto on 90 päivää, ja se voidaan uusia uudelleenarvioinnin perusteella.”

Yritystason politiikka, Network Security Policy, kohta “Riskien käsittely ja poikkeukset,” lauseke 7.3.

Pk-yrityksille Network Security Policy-sme edellyttää, että poikkeuspyynnöt sisältävät oikeat vähimmäistiedot:

“Pyynnön on sisällettävä perustelu, soveltamisala, kesto ja kompensoivat hallintakeinot (esim. IP-sallittulistaus, lokitus).”

Pk-yrityspolitiikka, Network Security Policy-sme, kohta “Riskien käsittely ja poikkeukset,” lauseke 7.3.3.

Tämä lauseke muuttaa poikkeusten käsittelyn epämuodollisesta keskustelusta auditoitavaksi riskien käsittelyksi.

Käytännön esimerkki: riskialttiin tuotantotietokantasäännön poistaminen

Oletetaan, että yritys löytää katselmoinnissa seuraavan säännön:

Tämä on klassinen auditointihavainto. Se rikkoo vähimmän oikeuden periaatetta, sillä ei ole selkeää omistajaa, päättymispäivää, ajantasaista perustelua eikä lokitusta. Se luo myös GDPR:n 32 artiklan mukaisen altistuman, jos tuotantotietokanta sisältää asiakkaiden henkilötietoja.

Korjausprosessin tulee tuottaa todentavaa aineistoa, ei vain poistaa huonoa sääntöä.

Clarysecin Logging and Monitoring Policy [P-LM] sisältää ulkoisen viestinnän ja palomuurisääntöjen herätteet lokitukselle relevantteina tapahtumina:

“Ulkoinen viestintä ja palomuurisääntöjen herätteet.”

Yritystason politiikka, Logging and Monitoring Policy, kohta “Politiikan toimeenpanovaatimukset,” lauseke 6.1.1.6.

Korkean riskin vyöhykkeiden välisissä säännöissä palomuurin herätteiden tulisi syöttää SIEM- tai valvonta-alustaa, ja hälytyksiä tulisi muodostaa poikkeavista lähdeisännistä, volyymeista tai aikaikkunoista.

Pk-yrityspolitiikka edellyttää myös muutosten kurinalaista hallintaa:

“Kaikkien verkon konfiguraatiomuutosten (palomuurisäännöt, kytkimien ACL:t, reititystaulut) on noudatettava dokumentoitua muutoksenhallintaprosessia.”

Pk-yrityspolitiikka, Network Security Policy-sme, kohta “Politiikan toimeenpanovaatimukset,” lauseke 6.9.1.

Tämän yhden säännön siivoaminen tuottaa näyttöä ISO/IEC 27001:2022:n operatiivisesta ohjauksesta, ISO/IEC 27002:2022:n kontrolleista 8.20, 8.22 ja 8.32, NIS2:n kyberhygieniasta, GDPR:n 32 artiklasta sekä DORA-tyyppisestä ICT-riskienhallinnasta.

Pilvi-, SaaS- ja hybridiverkot on sisällytettävä

Nykyaikainen segmentointi ei tarkoita vain VLAN-verkkoja ja fyysisiä palomuureja. Se kattaa AWS-tietoturvaryhmät, Azure-verkon tietoturvaryhmät, Kubernetes-verkkopolitiikat, pilven reititystaulut, SaaS-ylläpidon sallittujen luettelot, yksityiset päätelaitteet, VPN:t, SD-WANin, identiteettitietoiset välityspalvelimet ja ohjelmistomääritellyt perimeter-kontrollit.

SaaS-palveluntarjoajan tai säännellyn digitaalisen palvelun palomuurisääntöjen katselmoinnin tulee kattaa vähintään:

• Internetiin avautuvat kuormantasaimet ja sovellusyhdyskäytävät
• Pilven tietoturvaryhmät ja verkon ACL:t
• Yksityisten aliverkkojen reititystaulut
• Peering- ja transit gateway -reitit
• VPN- ja etähallintareitit
• Ylläpitoliittymät ja hallintatasot
• Kubernetes ingress -määritykset ja verkkopolitiikat
• CI/CD-ajajien pääsy tuotantoon
• Lokituksen kattavuus estetyille ja sallituille korkean riskin liikennevirroille
• Kolmansien osapuolten tukikäyttö ja break-glass-polut

Jos pilven tietoturvaryhmä sallii saapuvan tietokantaliikenteen laajasta yrityksen IP-alueesta, käsittele sitä palomuurisääntönä. Se tarvitsee omistajuuden, perustelun, hyväksynnän, katselmoinnin, lokituksen ja päättymispäivän.

Tässä myös tukevat ISO-standardit vahvistavat kokonaisuutta. ISO/IEC 27017 tukee selkeyttä pilviturvallisuuden vastuista. ISO/IEC 27033 antaa syvempää ohjeistusta verkkoturvallisuusarkkitehtuurista, DMZ-alueista, segmentointivyöhykkeistä, liikenteen suodatuksesta ja turvallisesta verkkojen välisestä viestinnästä. ISO/IEC 27701 vahvistaa tietosuojan hallintaa, kun henkilötiedot liikkuvat verkkojen yli. ISO/IEC 27035 tukee poikkeamien rajaamista, ja ISO/IEC 27005 tukee segmentoinnin valitsemista riskien käsittelyksi luvatonta pääsyä, haittaohjelmien leviämistä ja lateraalista liikkumista vastaan.

Miten auditoijat testaavat samaa kontrollia eri tavoin

Yksi Zenith Controls -oppaan vahvuuksista on, että se selittää, miten eri auditointimenetelmät tutkivat samaa kontrollia. Todentavaa aineistoa voidaan käyttää uudelleen, mutta kysymykset eroavat toisistaan.

DORA-painotteinen arvioija voi kysyä, voiko maksuyhdyskäytävän vaarantuminen mahdollistaa siirtymisen asiakastietokantoihin. NIS2:n toimivaltainen viranomainen voi kysyä, voiko hallinnollisen työaseman kiristyshaittaohjelma päästä ydintason palvelutuotantojärjestelmiin. GDPR-viranomainen voi kysyä, millaiset verkkotason rajoitukset suojasivat henkilötietoja käsitteleviä järjestelmiä. ISO-auditoija voi yksinkertaisesti pyytää riskien arvioinnin, SoA:n, politiikan, menettelyn ja näytön siitä, että katselmoinnit tehtiin.

Parhaat ohjelmat vastaavat kaikkiin näihin samoilla artefakteilla.

Mittarit, jotka tekevät segmentoinnista näkyvää johdolle

Sekä NIS2 että DORA korostavat johdon tilivelvollisuutta. ISO/IEC 27001:2022 edellyttää johtajuutta, tavoitteita, rooleja, resursseja, raportointia ja jatkuvaa parantamista. Tämä tarkoittaa, että segmentointi tarvitsee mittareita, joita johto ymmärtää.

Hyödyllisiä johdon mittareita ovat:

• Niiden palomuurisääntöjen prosenttiosuus, joille on nimetty omistaja
• Niiden sääntöjen prosenttiosuus, joille on dokumentoitu liiketoimintaperuste
• Vanhentuneiden tilapäisten sääntöjen määrä
• Niiden sääntöjen määrä, joissa lähde, kohde tai palvelu on “any”
• Internetiin altistuvien palvelujen määrä kriittisyyden mukaan
• Niiden korkean riskin vyöhykkeiden välisten liikennevirtojen prosenttiosuus, joilla lokitus on käytössä
• Hätäpalomuurimuutosten määrä neljännesvuosittain
• Niiden otokseen valittujen sääntöjen prosenttiosuus, jotka täsmäävät hyväksyttyihin muutostiketteihin
• Segmentointitestien epäonnistumisten määrä
• Keskimääräinen aika riskialttiiden tai käyttämättömien sääntöjen korjaamiseen
• Yli 90 päivää vanhojen poikkeusten määrä
• Katselmoitujen ja uudelleensertifioitujen kolmannen osapuolen pääsysääntöjen määrä

Network Security Policy tunnistaa “palomuurisääntöjen tehokkuuden” vaatimustenmukaisuuden ja soveltamisen näkökohdaksi kohdassa “Soveltaminen ja vaatimustenmukaisuus,” lauseke 8.2.2. Ilmaisulla on merkitystä, koska säännön olemassaolo ei riitä. Sääntöjen on oltava tehokkaita, katselmoituja ja nykyisen riskin mukaisia.

Rakenna vuoden 2026 segmentoinnin näyttökokonaisuus

Käytännöllisen segmentoinnin ja palomuurisääntöjen katselmoinnin näyttökokonaisuuden tulisi olla valmiina ennen kuin auditoija pyytää sitä.

Vähimmäistasolla ylläpidä:

1. Ajantasainen verkkoarkkitehtuurin kaavio, mukaan lukien pilvi- ja hybridivyöhykkeet
2. Vyöhykeluokitusstandardi, mukaan lukien arkaluonteisuus ja luottamustaso
3. Virtausmatriisi kriittisille palveluille ja henkilötietojärjestelmille
4. Palomuurien ja pilven tietoturvaryhmien sääntöjen vienti
5. Sääntöjen omistaja- ja uudelleensertifiointirekisteri
6. Palomuurien katselmointimenettely ja katselmointikalenteri
7. Muutostallenteet otokseen valituista palomuurimuutoksista
8. Poikkeusrekisteri, joka sisältää hyväksynnät, päättymispäivät ja kompensoivat hallintakeinot
9. Segmentointitestien tulokset ja korjaustallenteet
10. Lokitus- ja seurantanäyttö korkean riskin liikennevirroille
11. Poikkeamien pelikirjat, jotka osoittavat vyöhykekohtaisen rajaamisen
12. Johdon raportointimittarit ja kokouspöytäkirjat

Kartoita tämä todentava aineisto ISO/IEC 27001:2022 -lausekkeisiin ja liite A:n kontrollialueisiin. Ristiinviittaa se sitten NIS2:n 21 artiklaan, GDPR:n 32 artiklaan, DORA:n ICT-riskienhallinta- ja testausvaatimuksiin, NIST CSF 2.0 -tuloksiin, kuten GOVERN, PROTECT, DETECT ja RESPOND, sekä COBIT-hallintakäytäntöihin.

NIST CSF 2.0 on erityisen hyödyllinen hallitusviestinnän kerroksena. Sen GOVERN-toiminto keskittyy lakisääteisiin, sääntely- ja sopimusvaatimuksiin, riskinottohalukkuuteen, rooleihin, politiikkoihin ja valvontaan. Sen operatiiviset tulokset käsittelevät konfiguraationhallintaa, lokitusta, seurantaa, tietosuojaa, tietoturvapoikkeamiin reagointia ja toipumista. Tämä auttaa johtoa ymmärtämään riskin ilman palomuurin ACL-sääntöjen lukemista.

Yleiset havainnot, joita Clarysec näkee segmentointiauditoinneissa

SaaS-yrityksissä, fintech-yhtiöissä, hallinnoiduilla palveluntarjoajilla ja säännellyissä pk-yrityksissä samat havainnot toistuvat:

• Segmentoimaton verkko käyttäjäpäätelaitteiden ja tuotantopalvelujen välillä
• Tuotantotietokannat ovat saavutettavissa kehitys- tai yritysverkoista
• Laajat pilven tietoturvaryhmät on kopioitu vanhoista malleista
• Tilapäiset toimittajasäännöt ilman päättymispäivää
• Palomuurimuutokset on tehty muutoksenhallintaprosessin ulkopuolella
• Säännöiltä puuttuu omistaja tai liiketoimintaperuste
• Lokitus on pois käytöstä korkean riskin sallivissa säännöissä
• Vieras-Wi-Fi ei ole täysin eristetty
• Ylläpitoliittymät ovat saavutettavissa yleisistä verkoista
• Kaaviot eivät vastaa todellista reititystä
• Ei näyttöä siitä, että sääntökatselmoinnit olisi tehty
• Ei segmentointitestausta merkittävien arkkitehtuurimuutosten jälkeen
• Ei kartoitusta henkilötietojärjestelmien ja verkkovyöhykkeiden välillä
• Ei johdon raportointia verkkopinnan altistuksesta

Nämä havainnot eivät ole vain teknisiä heikkouksia. Ne heikentävät organisaation kykyä osoittaa NIS2:n kyberhygieniaa, DORA:n operatiivista häiriönsietokykyä ja GDPR:n 32 artiklan osoitusvelvollisuutta.

Reaktiivisesta siivouksesta puolustettavaan kontrolliin

Verkon segmentointi ja palomuurisääntöjen katselmointi ovat kohtia, joissa tietoturva-arkkitehtuuri kohtaa auditointitodellisuuden. Jos pystyt osoittamaan riskiperusteisen vyöhykemallin, hallitut vyöhykkeiden väliset liikennevirrat, hyväksytyt palomuurimuutokset, aikarajoitetut poikkeukset, lokitusnäytön ja säännöllisen validoinnin, voit vastata laajaan joukkoon ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST- ja COBIT-kysymyksiä yhdellä johdonmukaisella kertomuksella.

Clarysec voi auttaa sinua rakentamaan tämän kertomuksen.

Käytä Zenith Blueprint: auditoijan 30 vaiheen tiekartta -opasta toteutuspolun jäsentämiseen, erityisesti Kontrollit käytännössä -vaiheen vaihetta 20 verkkoturvallisuutta ja segmentointia varten sekä vaihetta 21 muutoksenhallintaa varten. Käytä Zenith Controls: vaatimustenmukaisuuksien välinen opas -opasta ISO/IEC 27002:2022 -kontrollien 8.20, 8.22 ja 8.32 kartoittamiseen NIS2:n, DORA:n, GDPR:n, NIST:n ja COBIT:n auditointiodotuksiin. Kiinnitä operatiiviset sääntösi Clarysecin Network Security Policy, Network Security Policy-sme ja Logging and Monitoring Policy -politiikkoihin.

Seuraava askeleesi on yksinkertainen ja arvokas: valitse yksi kriittinen palvelu, kuten asiakastuotanto, maksujen käsittely tai identiteetinhallinta, ja tee tällä viikolla 10 säännön otoskatselmointi. Vahvista jokaiselle säännölle omistaja, perustelu, lähde, kohde, portti, lokitus, muutostiketti ja päättymispäivä. Jos et pysty todentamaan näitä seitsemää asiaa, sinulla on vuoden 2026 segmentoinnin parannussuunnitelman alku.