Преглед на правилата на защитната стена за ISO 27001, NIS2, DORA и GDPR
Понеделник сутрин е, 07:42 ч. CISO на разрастващ се доставчик на SaaS и финтех услуги преглежда три отделни съобщения.
Първото е от SOC. Компрометирана работна станция на разработчик е направила опит през нощта да се свърже с вътрешна подмрежа за бази данни. Трафикът е блокиран, но анализаторът иска потвърждение, че правилото на защитната стена е умишлено въведено, актуално и одобрено.
Второто е от голям корпоративен клиент. Той иска доказателства, че продукционната, развойната, корпоративната и поддържащата среда са сегментирани, че правилата на защитната стена се преглеждат и че изключенията имат срок на валидност.
Третото е от мениджъра по съответствие. Организацията попада в обхвата на NIS2 като важен цифров доставчик, има отговорности по GDPR като обработващ лични данни и обслужва клиенти от сектора на финансовите услуги, които изискват доказателства за ИКТ риска в стила на DORA. Управителният орган иска да знае дали едни и същи доказателства по ISO/IEC 27001:2022 могат да покрият и трите групи изисквания.
След това пристига прегледът след инцидент. Развоен сървър почти е бил изложен към интернет по време на промяна късно през нощта. Няма загубени клиентски данни, но форензичният екип открива нещо по-сериозно от първоначалната грешка: петгодишно „временно тестово“ правило на защитната стена все още е позволявало широко движение между развойната и продукционната среда. Ако нападател беше получил достъп, мрежата щеше да окаже минимална съпротива.
Това е моментът, в който много организации откриват болезнена истина. Те може да имат защитни стени, VLAN, облачни групи за сигурност и диаграми, но нямат управление на зоните за сегментация, собствеността върху правилата, временния достъп, одобренията на промени, повторното сертифициране и одитните доказателства.
През 2026 г. „имаме защитна стена“ не е защитим отговор. Одиторите, регулаторите, клиентите и застрахователите искат доказателства, че мрежите са разделени целенасочено, трафикът се контролира според служебната необходимост, рисковите изключения се управляват, а журналите показват, че контролите функционират.
Защо управлението на защитните стени вече е въпрос на управленско ниво
Мрежовата сегментация дълго време се разглеждаше като техническа инженерна тема. Инфраструктурните екипи отговаряха за VLAN, администраторите на защитни стени поддържаха наборите от правила, облачните екипи управляваха групите за сигурност, а екипите по съответствие виждаха само диаграма по време на одити.
Този оперативен модел вече не работи.
Директивата NIS2 изисква съществените и важните субекти да прилагат подходящи и пропорционални технически, оперативни и организационни мерки за управление на рисковете за мрежовите и информационните системи. Article 21 включва политики за анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурност при придобиване и поддръжка, оценка на ефективността, базова киберхигиена, контрол на достъпа и управление на активите. Органите на управление трябва да одобряват и наблюдават тези мерки за управление на риска за киберсигурността.
DORA се прилага от 17 януари 2025 г. за много финансови субекти и превръща управлението на ИКТ риска в управлявана и документирана дисциплина. Articles 5, 6 и 8 изискват управление, рамка за управление на ИКТ риска и идентифициране на бизнес функции, поддържани от ИКТ, информационни активи, ИКТ активи, зависимости, критични активи и взаимовръзки. Articles 9, 10 и 11 обхващат защита, предотвратяване, откриване, реагиране и възстановяване. Articles 24 to 27 изискват тестване на цифровата оперативна устойчивост, включително усъвършенствано тестване за определени субекти. Това прави сегментацията въпрос на устойчивост, а не само въпрос на защитна стена.
GDPR добавя слоя на отчетност при защитата на личните данни. Article 32 изисква подходящи технически и организационни мерки за осигуряване на ниво на сигурност, съобразено с риска, включително поверителност, цялостност, наличност и устойчивост. Article 5(1)(f) изисква цялостност и поверителност, а Article 5(2) изисква отчетност. Ако системи с лични данни са достижими от компрометирани крайни точки, мрежи за гости или неуправлявани пътища на трети страни, надзорен орган може да попита защо тези пътища са съществували.
ISO/IEC 27001:2022 предоставя основата на системата за управление, която свързва тези задължения. Стандартът изисква обхват, изисквания на заинтересованите страни, оценка на риска, третиране на риска, Декларация за приложимост, оперативно планиране и контрол, отчетност на ръководството, измерими цели, документирана информация и непрекъснато подобрение. Annex A, подкрепено от указанията на ISO/IEC 27002:2022, включва областите на контрол, необходими за риска, свързан с доставчици, облачни услуги, регистриране, мониторинг, сигурна архитектура, разделяне на средите и управление на промените.
Изводът е прост: мрежовата сегментация и прегледът на правилата на защитната стена вече са доказателства за управление.
Оперативният модел на Clarysec: 8.20, 8.22 и 8.32
Clarysec разглежда сегментацията и прегледа на защитните стени като единен оперативен модел в рамките на контролите от ISO/IEC 27002:2022, а не като изолирани технически задачи.
Трите основни контрола са:
| Област по ISO/IEC 27002:2022 | Управленски въпрос | Доказателства, които одиторите очакват |
|---|---|---|
| 8.20 Мрежова сигурност | Проектирани, управлявани, наблюдавани и защитени ли са мрежите според риска? | Архитектурни диаграми, стандарти за защитни стени, процедури за сигурна мрежова среда, журнали от мониторинг, доказателства от IDS/IPS, примерни конфигурации на VPN и облачна мрежа |
| 8.22 Разделяне на мрежите | Разделени ли са зоните според чувствителност, функция и ниво на доверие? | Модел на зониране, матрица на потоците от данни, дизайн на VLAN и подмрежи, граници на DMZ, правила на защитната стена между зони, резултати от тестове на сегментацията |
| 8.32 Управление на промените | Оценяват ли се, одобряват ли се, тестват ли се, регистрират ли се и преглеждат ли се промените в правилата? | Заявки за промяна, оценки на риска, одобрения, планове за връщане към предишно състояние, прегледи след внедряване, записи за аварийни промени |
В Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] Clarysec поставя мрежовата сигурност във фазата „Контроли в действие“, Стъпка 20: Контроли 8.18 до 8.26. Ръководството формулира ясно основния одитен въпрос:
„В основата си този контрол изисква организациите да гарантират, че мрежите са сигурни по архитектура, а не само чрез добавяне на защитни стени или антивирусен софтуер впоследствие. Това означава стратегическо мислене за мрежова сегментация, контрол на достъпа, шифроване при пренос, мониторинг и многостепенна защита. Всичко започва с прост въпрос: Кой и какво комуникира и трябва ли да комуникира?“
Този въпрос — „кой и какво комуникира и трябва ли да комуникира?“ — е най-добрата практическа отправна точка за преглед на правилата на защитната стена. Той измества разговора от хиляди неясни записи в ACL към потоци, обосновани със служебна необходимост.
Същият Zenith Blueprint указва на екипите да оценяват мрежовата архитектура, като проверяват дали правилата на защитната стена, IPS/IDS и конфигурациите за отдалечен достъп са актуални и укрепени, както и да потвърждават, че облачните групи за сигурност, маршрутизацията и правилата за VPC или подмрежи съответстват на планираната архитектура. Ръководството също така указва на одиторите да очакват диаграма на архитектурата на мрежовата сигурност, която показва защитни стени, VPN шлюзове, DMZ зони, разделяне чрез VLAN и граници на доверие.
За управлението на промените Zenith Blueprint поставя контрол 8.32 от ISO/IEC 27002:2022 във фазата „Контроли в действие“, Стъпка 21: Контроли 8.27 до 8.34, и подчертава защо управлението на защитните стени се проваля, когато контролът на промените е слаб:
„Този контрол признава една трудна истина в ИТ: много инциденти не са причинени от атаки, а от неправилно управлявани промени. Правило на защитната стена, отворено твърде широко. Оставена включена настройка за отстраняване на грешки. Забравена зависимост след миграция.“
Точно така временните отваряния на защитната стена се превръщат в постоянни пътища за атака.
Как изглежда добрата мрежова сегментация
Зрялата програма за сегментация има четири слоя.
Първо, тя има модел на зониране. Зоните не са произволни подмрежи. Те са граници на доверие, съгласувани с бизнес функцията и чувствителността на данните, като публично достъпна през интернет DMZ, продукционен приложен слой, продукционен слой за бази данни, корпоративна потребителска мрежа, привилегирована управленска мрежа, развойна среда, тестова среда, мрежа за резервни копия, Wi‑Fi за гости, OT или IoT зона и зона за достъп на трети страни.
Второ, тя има матрица на потоците. За всяка двойка зони организацията документира разрешения източник, дестинация, протокол, порт, приложение, бизнес собственик, собственик на система, тип данни, обосновка и изискване за регистриране.
Трето, тя има собственост върху правилата. Всяко правило на защитната стена, правило на облачна група за сигурност или политика за софтуерно дефиниран периметър има собственик, дата на изтичане или повторно сертифициране, свързана заявка за промяна и бизнес обосновка. „Any to any“ трябва да се третира като констатация, освен ако рискът не е формално приет, ограничен във времето и подкрепен от компенсиращи контроли.
Четвърто, тя има периодичен преглед. Прегледът означава повече от експортиране на базата с правила на защитната стена веднъж годишно. Той включва повторно сертифициране от собствениците, сравнение с наблюдавания трафик, откриване на неизползвани правила, валидиране на временни изключения, преглед на интернет експозицията, тестване на сегментацията и съгласуване с инвентара на активите.
Политика за мрежова сигурност [P-NS] на Clarysec задава ясно очакването за корпоративната среда:
„Целият трафик между зони трябва да се контролира чрез защитни стени или решения за софтуерно дефиниран периметър, с изрични конфигурации за забрана по подразбиране.“
От корпоративната политика, Политика за мрежова сигурност, раздел „Изисквания за управление“, клауза 5.2.
Същата политика свързва промените по защитната стена директно с управлението на промените:
„Всяка промяна в наборите от правила на защитната стена, таблиците за маршрутизация или конфигурациите на групи за сигурност трябва да следва Политиката за управление на промените (P5) на организацията, включително планове за връщане към предишно състояние и журналиране за одит.“
От корпоративната политика, Политика за мрежова сигурност, раздел „Изисквания за управление“, клауза 5.4.
За МСП Network Security Policy-sme [P-NS-SME] на Clarysec предоставя същия принцип в оперативни термини:
„Правилата за забрана по подразбиране трябва да се прилагат за всички входящи връзки, освен ако те не са изрично необходими и одобрени“
От политиката за МСП, Network Security Policy-sme, раздел „Изисквания за прилагане на политиката“, клауза 6.1.2.
И конкретно за сегментацията:
„Трафикът между сегментите трябва да се филтрира, а достъпът между сегменти трябва да следва принципа на минималните привилегии“
От политиката за МСП, Network Security Policy-sme, раздел „Изисквания за прилагане на политиката“, клауза 6.2.3.
Тези клаузи от политиките позволяват на одитор да проследи връзката от риска към контрола, от контрола към правилото, от правилото към одобрението и от одобрението към журналите.
Един пакет доказателства за ISO 27001, NIS2, DORA и GDPR
Грешката, която много екипи допускат, е да изграждат отделни пакети доказателства: един за ISO/IEC 27001:2022, един за NIS2, един за GDPR, един за клиенти с изисквания по DORA и един за киберзастраховане.
По-добрият подход е да се изгради единен пакет доказателства за управление на сегментацията и защитните стени, който се картографира към различни рамки.
Zenith Controls: The Cross-Compliance Guide [ZC] картографира контрол 8.22 Разделяне на мрежите от ISO/IEC 27002:2022 като превантивен контрол, който подкрепя поверителността, целостта и наличността, съгласуван с концепцията Protect за киберсигурност и с оперативната способност за системна и мрежова сигурност. Ръководството свързва 8.22 с 8.20 Мрежова сигурност, 8.21 Сигурност на мрежовите услуги, 8.7 Защита срещу зловреден софтуер, 8.27 Принципи за сигурна системна архитектура и инженеринг и 8.31 Разделяне на средите за разработка, тестване и продукционна експлоатация.
Ръководството обяснява значението на сегментацията за NIS2 така:
„Разделянето на мрежите е пряк отговор на тези задължения, като намалява повърхността за атака и предотвратява странично придвижване през мрежово свързани системи.“
Това изречение обяснява защо програмите за киберхигиена по NIS2 не трябва да третират сегментацията като незадължителна. Ограничаването на ransomware не е само въпрос на защита на крайните точки. То е въпрос на ограничаване на страничното придвижване, когато превенцията се провали.
За GDPR Zenith Controls картографира 8.22 към Article 32 и Recital 49, като отбелязва, че мрежовите диаграми и политиките за зониране се превръщат в ключови доказателства за съответствие. За DORA Zenith Controls картографира мрежовата сигурност и разделянето към управлението на ИКТ риска и ограничаването на инциденти. Тестовете на сегментацията могат да подкрепят доказателства за ИКТ устойчивост, особено когато доказват, че компрометиране в една зона не може свободно да премине към критични финансови услуги, хранилища с лични данни или привилегировани управленски системи.
| Доказателствен артефакт | Употреба за ISO/IEC 27001:2022 и ISO/IEC 27002:2022 | Употреба за NIS2 | Употреба за DORA | Употреба за GDPR |
|---|---|---|---|---|
| Диаграма на архитектурата на мрежовата сигурност | Подкрепя обхвата на СУИС, оперативния контрол, 8.20 и 8.22 | Показва технически мерки за сигурност на мрежовите и информационните системи | Показва ИКТ взаимовръзки и зависимости на критични услуги | Показва защитни граници около системи с лични данни |
| Матрица на зони и потоци | Доказва риск-базирано разделяне и минимални привилегии | Подкрепя киберхигиената и оценката на ефективността | Подкрепя класификацията на ИКТ активи и зависимости | Подкрепя техническите мерки и отчетността по Article 32 |
| Записи от преглед на правилата на защитната стена | Доказателство за мониторинг на контролите и непрекъснато подобрение | Показва, че мерките се преглеждат и не са статични | Подкрепя прегледа на ИКТ риска и тестването на устойчивостта | Доказва текуща сигурност на обработването |
| Заявки за промяна за правила на защитната стена | Подкрепя 8.32 Управление на промените | Подкрепя сигурната поддръжка и проследимостта | Подкрепя контролираната ИКТ промяна и устойчивостта | Показва, че промените, засягащи системи с лични данни, са оценени спрямо риска |
| Регистър на изключенията | Подкрепя третиране на риска и приемане на остатъчния риск | Показва надзор от ръководството върху отклоненията | Подкрепя толеранса към риск и управлението | Показва отчетност за временна експозиция |
| Журнали за блокиран и разрешен трафик между зони | Подкрепя регистриране, мониторинг и ефективност на контролите | Подкрепя откриване и реагиране при инциденти | Подкрепя класификацията и докладването на инциденти | Подкрепя оценка на нарушения и запазване на доказателства |
Тази таблица не е само картографиране на съответствието. Тя е пътна карта за събиране на доказателства.
Прегледът на правилата на защитната стена, който действително работи
Прегледът на правилата на защитната стена се проваля, когато задава само въпроса: „Това правило все още ли е необходимо?“ Собствениците на правила често отговарят с „да“, защото се страхуват да не нарушат работата на системите.
По-добрият преглед задава шест въпроса:
- Коя бизнес услуга поддържа това правило?
- Кой собственик на актив и кой собственик на данни са одобрили потока?
- Дестинацията намира ли се в правилната зона за съответните данни и функция?
- По-разрешително ли е правилото, отколкото изисква наблюдаваният трафик?
- Активирано ли е регистриране за високорискови потоци?
- Има ли правилото дата за преглед, дата на изтичане или запис за изключение?
Network Security Policy-sme изисква периодичен преглед:
„Доставчикът на ИТ поддръжка трябва да извършва годишен преглед на правилата на защитната стена, мрежовата архитектура и безжичните конфигурации“
От политиката за МСП, Network Security Policy-sme, раздел „Изисквания за управление“, клауза 5.6.1.
Годишният преглед е базовото изискване, не горната граница. Високорисковите правила се нуждаят от по-често повторно сертифициране.
| Категория правило | Пример | Честота на преглед | Очакване за одобрение |
|---|---|---|---|
| Входящ интернет трафик към продукционна среда | Публичен API към приложен шлюз | На тримесечие или след съществено издание | Собственик на услугата, сигурност, одобряващ промяната |
| Достъп между зони до продукционна база данни | Приложен слой към слой за бази данни | На тримесечие | Собственик на приложение и собственик на данни |
| Административен достъп | Бастионен сървър към портове за управление на сървъри | Месечно или тримесечно | Собственик на инфраструктурата и делегат на CISO |
| Достъп на трети страни | VPN на доставчик към подмрежа за поддръжка | Месечно или при договорен ключов етап | Собственик на доставчика и сигурност |
| Временно изключение | Аварийен достъп по време на миграция | Преди изтичане, максимум 90 дни | Мениджър на СУИС или CISO |
| Стандартно нискорисково вътрешно правило | Сървър за мониторинг към управлявани крайни точки | Годишно | Собственик на услугата |
Политика за мрежова сигурност е изрична относно изключенията:
„Заявката трябва да бъде прегледана и одобрена от Мениджъра на ISMS или от CISO и записана в Регистъра на изключенията в СУИС, с максимален срок на одобрение от 90 дни, подновяем след повторна оценка.“
От корпоративната политика, Политика за мрежова сигурност, раздел „Третиране на риска и изключения“, клауза 7.3.
За МСП Network Security Policy-sme изисква заявките за изключение да включват правилните минимални факти:
„Заявката трябва да включва обосновката, обхвата, срока и компенсиращите контроли (напр. списъци с разрешени по IP адреси, регистриране)“
От политиката за МСП, Network Security Policy-sme, раздел „Третиране на риска и изключения“, клауза 7.3.3.
Тази клауза превръща обработката на изключения от неформален чат в одитируемо третиране на риска.
Практически пример: премахване на рисково правило за продукционна база данни
Да приемем, че при преглед дружество открива следното правило:
| Поле | Текуща стойност |
|---|---|
| Източник | Корпоративен потребителски VLAN |
| Дестинация | Продукционна подмрежа за бази данни |
| Порт | TCP 5432 |
| Действие | Разреши |
| Коментар | Временен достъп за миграция на отчетността |
| Създадено | Преди 14 месеца |
| Собственик | Неизвестен |
| Регистриране | Деактивирано |
Това е класическа одитна констатация. Нарушава принципа на минималните привилегии, няма ясен собственик, няма срок на изтичане, няма актуална обосновка и няма регистриране. Освен това създава експозиция по Article 32 от GDPR, ако продукционната база данни съдържа лични данни на клиенти.
Процесът по отстраняване трябва да създава доказателства, а не просто да премахва лошо правило.
| Стъпка | Действие | Референция на Clarysec | Създадени одитни доказателства |
|---|---|---|---|
| 1. Картографиране на правилото към модела на зониране | Потвърдете дали корпоративните потребители изобщо трябва да достигат продукционната подмрежа за бази данни | Zenith Blueprint, Контроли в действие, Стъпка 20 | Актуализирани бележки от прегледа на архитектурата и класификация по зони |
| 2. Създаване или актуализиране на записа за поток | Документирайте източник, дестинация, порт, тип данни, собственик, обосновка и риск | Zenith Controls, картографиране към 8.22 | Запис в матрицата на зони и потоци |
| 3. Откриване на заявка за промяна | Предложете премахване или замяна с контролиран път през услуга за отчетност | Политика за мрежова сигурност, клауза 5.4 | Запис за промяна с анализ на риска, план за тестове и план за връщане към предишно състояние |
| 4. Решение за третиране | Премахнете широкото правило или го заменете с реплика само за четене, бастион, списъци с разрешени по IP адреси и регистриране | Политика за мрежова сигурност, клауза 7.3 | Решение за третиране на риска или времево ограничено изключение |
| 5. Активиране на регистриране за одобрените потоци | Изпращайте високорисковите събития от защитната стена между зони към мониторинг | Политика за регистриране и мониторинг, клауза 6.1.1.6 | Записи в SIEM, правила за предупреждения и екранни снимки от мониторинга |
| 6. Валидиране на сегментацията | Тествайте дали подмрежата за бази данни е недостижима освен през одобрените пътища | Zenith Blueprint, Стъпка 20 | Резултат от тест на сегментацията и приключване на отстраняването |
Политика за регистриране и мониторинг [P-LM] на Clarysec включва външните комуникации и задействанията на правила на защитната стена като събития, релевантни за регистриране:
„Външни комуникации и тригери на правила на защитната стена“
От корпоративната политика, Политика за регистриране и мониторинг, раздел „Изисквания за прилагане на политиката“, клауза 6.1.1.6.
За високорискови правила между зони задействанията на защитната стена трябва да подават данни към SIEM или платформата за мониторинг, с предупреждения за необичайни хостове източници, обеми или времеви прозорци.
Политиката за МСП също изисква дисциплина при промените:
„Всички промени в мрежовите конфигурации (правила на защитната стена, ACL на комутатори, таблици за маршрутизация) трябва да следват документиран процес за управление на промените“
От политиката за МСП, Network Security Policy-sme, раздел „Изисквания за прилагане на политиката“, клауза 6.9.1.
Еднократното почистване на това правило създава доказателства за оперативен контрол по ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 и 8.32, киберхигиена по NIS2, Article 32 от GDPR и управление на ИКТ риска в стила на DORA.
Облакът, SaaS и хибридните мрежи трябва да бъдат включени
Съвременната сегментация не се изчерпва с VLAN и физически защитни стени. Тя включва групи за сигурност в AWS, групи за мрежова сигурност в Azure, мрежови политики на Kubernetes, облачни таблици за маршрутизация, административни списъци с разрешени адреси за SaaS, частни крайни точки, VPN, SD-WAN, проксита с отчитане на идентичността и контроли за софтуерно дефиниран периметър.
За доставчик на SaaS или регулирана цифрова услуга прегледът на правилата на защитната стена трябва да включва най-малко:
- Публично достъпни през интернет load balancer-и и приложни шлюзове
- Облачни групи за сигурност и мрежови ACL
- Таблици за маршрутизация на частни подмрежи
- Peering връзки и пътища през transit gateway
- VPN и пътища за отдалечено администриране
- Административни интерфейси и управленски равнини
- Kubernetes ingress и мрежови политики
- Достъп на CI/CD runner-и до продукционна среда
- Покритие на регистрирането за отказани и разрешени високорискови потоци
- Достъп за поддръжка от трети страни и пътища „break glass“
Ако облачна група за сигурност позволява входящ трафик към база данни от широк корпоративен IP диапазон, третирайте я като правило на защитна стена. Тя се нуждае от собственост, обосновка, одобрение, преглед, регистриране и срок на изтичане.
Тук допълващите ISO стандарти също укрепват аргументацията. ISO/IEC 27017 подпомага яснотата относно отговорностите за сигурността в облака. ISO/IEC 27033 предоставя по-задълбочени указания за архитектура на мрежовата сигурност, DMZ, зони за сегментация, филтриране на трафика и сигурни комуникации между мрежи. ISO/IEC 27701 засилва управлението на поверителността, когато лично идентифицираща информация (PII) се движи през мрежи. ISO/IEC 27035 подкрепя ограничаването на инциденти, а ISO/IEC 27005 подкрепя избора на сегментация като третиране на риска за неоторизиран достъп, разпространение на зловреден софтуер и странично придвижване.
Как одиторите тестват един и същ контрол по различен начин
Една от силните страни на Zenith Controls е, че обяснява как различни одитни методологии разглеждат един и същ контрол. Доказателствата могат да се използват повторно, но въпросите се различават.
| Одитна перспектива | Вероятен въпрос | Най-добри доказателства |
|---|---|---|
| Одитор по ISO/IEC 27001:2022 | Избрана, внедрена и преглеждана ли е сегментацията въз основа на риска? | Оценка на риска, SoA, мрежова политика, диаграми, записи от прегледи |
| Одитор в стила на ISO/IEC 27007 | Съответстват ли внедрените правила на защитната стена и схемите на VLAN на документираната политика? | Извадки от правила на защитната стена, ACL на маршрутизатори, дизайн на VLAN, интервюта с администратори |
| Подход за сертификационен одит по ISO/IEC 27006-1:2024 | Одитират ли се критичните мрежови граници с подходяща компетентност и планиране, основано на риска? | План за одит, техническа извадка, доказателства за облачни групи за сигурност, резултати от тестове |
| Одитор, ориентиран към NIST | Прилагат ли се и наблюдават ли се границите и информационните потоци? | Правила на защитната стена, ACL, тестове на сегментацията, записи от мониторинг |
| Одитор по COBIT 2019 | Управлява ли се, наблюдава ли се и докладва ли се мрежовата сигурност? | Матрица на собствеността, KPI, управленски отчети, регистър на риска |
| Одитор по ISACA ITAF | Работят ли ИТ общите контроли последователно? | Заявки за промяна, одобрения на изключения, журнали, извадки от повторно сертифициране на правила |
| Надзорен орган по GDPR | Бяха ли системите с лични данни защитени чрез подходящи технически мерки? | Карти на потоците от данни, изолация на PII зони, пътища за достъп, журнали на защитната стена |
| Оценител с фокус върху DORA | Подкрепя ли сегментацията ИКТ устойчивостта и ограничаването на инциденти? | Карта на зависимостите на ИКТ активите, потоци на критични функции, наръчници за инциденти, записи от тестване |
Оценител с фокус върху DORA може да попита дали компрометиране на платежен шлюз може да се прехвърли към клиентски бази данни. Компетентен орган по NIS2 може да попита дали ransomware на административна работна станция може да достигне основни системи за предоставяне на услуги. Орган по GDPR може да попита какви ограничения на мрежово ниво са защитавали системите, обработващи лични данни. ISO одитор може просто да поиска оценката на риска, SoA, политиката, процедурата и доказателствата, че прегледите са извършени.
Най-добрите програми отговарят на всички тези въпроси с едни и същи артефакти.
Показатели, които правят сегментацията видима за ръководството
NIS2 и DORA поставят силен акцент върху отчетността на ръководството. ISO/IEC 27001:2022 изисква лидерство, цели, роли, ресурси, докладване и непрекъснато подобрение. Това означава, че сегментацията се нуждае от показатели, които ръководството може да разбере.
Полезни управленски показатели включват:
- Процент правила на защитната стена с определен собственик
- Процент правила с документирана бизнес обосновка
- Брой изтекли временни правила
- Брой правила с „any“ като източник, дестинация или услуга
- Брой услуги, изложени към интернет, по критичност
- Процент високорискови потоци между зони с активирано регистриране
- Брой аварийни промени по защитната стена на тримесечие
- Процент извадково проверени правила, съпоставени с одобрени заявки за промяна
- Брой неуспешни тестове на сегментацията
- Средно време за отстраняване на рискови или неизползвани правила
- Брой изключения, по-стари от 90 дни
- Брой прегледани и повторно сертифицирани правила за достъп на трети страни
Политика за мрежова сигурност определя „ефективност на правилата на защитната стена“ като съображение за съответствие и прилагане в раздел „Прилагане и съответствие“, клауза 8.2.2. Тази формулировка е важна, защото самото съществуване на правила не е достатъчно. Правилата трябва да бъдат ефективни, преглеждани и съгласувани с текущия риск.
Изградете пакета доказателства за сегментация за 2026 г.
Практическият пакет доказателства за мрежова сегментация и преглед на правилата на защитната стена трябва да бъде готов преди одиторът да го поиска.
Като минимум поддържайте:
- Актуална диаграма на мрежовата архитектура, включително облачни и хибридни зони
- Стандарт за класификация на зони, включително чувствителност и ниво на доверие
- Матрица на потоците за критични услуги и системи с лични данни
- Експорт на правила от защитната стена и облачните групи за сигурност
- Регистър на собствениците на правила и повторното сертифициране
- Процедура за преглед на защитната стена и календар за прегледи
- Записи за промени при извадково проверени модификации на защитната стена
- Регистър на изключенията с одобрения, срокове на изтичане и компенсиращи контроли
- Резултати от тестове на сегментацията и записи за отстраняване
- Доказателства от регистриране и мониторинг за високорискови потоци
- Наръчници за инциденти, показващи ограничаване по зони
- Управленски показатели за докладване и протоколи от срещи
Картографирайте тези доказателства към клаузите на ISO/IEC 27001:2022 и областите на контрол в Annex A. След това ги съпоставете с NIS2 Article 21, GDPR Article 32, изискванията на DORA за управление на ИКТ риска и тестване, резултатите от NIST CSF 2.0 като GOVERN, PROTECT, DETECT и RESPOND, както и практиките за управление по COBIT.
NIST CSF 2.0 е особено полезен като комуникационен слой към управителния орган. Неговата функция GOVERN се фокусира върху правни, регулаторни и договорни изисквания, апетит за риск, роли, политики и надзор. Оперативните му резултати обхващат управление на конфигурацията, регистриране, мониторинг, защита на данните, реагиране при инциденти и възстановяване. Това помага на ръководството да разбере риска, без да чете ACL на защитната стена.
Чести констатации, които Clarysec вижда при одити на сегментацията
В SaaS, финтех, доставчици на управлявани услуги и регулирани МСП едни и същи констатации се появяват многократно:
- Плоска мрежа между потребителски крайни точки и продукционни услуги
- Продукционни бази данни, достижими от развойни или корпоративни мрежи
- Широки облачни групи за сигурност, копирани от стари шаблони
- Временни правила за доставчици без срок на изтичане
- Промени по защитната стена, извършени извън процеса за управление на промените
- Правила без собственик или бизнес обосновка
- Деактивирано регистриране при високорискови разрешаващи правила
- Wi‑Fi за гости, който не е напълно изолиран
- Административни интерфейси, достижими от общи мрежи
- Диаграми, които не съответстват на реалната маршрутизация
- Липса на доказателства, че прегледите на правилата са завършени
- Липса на тестване на сегментацията след съществени архитектурни промени
- Липса на съпоставяне между системи с лични данни и мрежови зони
- Липса на управленско докладване за мрежовата експозиция
Тези констатации не са само технически слабости. Те подкопават способността на организацията да докаже киберхигиена по NIS2, оперативна устойчивост по DORA и отчетност по Article 32 от GDPR.
От реактивно почистване към защитим контрол
Мрежовата сегментация и прегледът на правилата на защитната стена са мястото, където архитектурата на сигурността среща одитната реалност. Ако можете да покажете риск-базиран модел на зониране, контролирани потоци между зони, одобрени промени по защитната стена, времево ограничени изключения, доказателства от регистриране и периодична валидация, можете да отговорите на широк кръг въпроси по ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST и COBIT с една последователна история.
Clarysec може да ви помогне да изградите тази история.
Използвайте Zenith Blueprint: An Auditor’s 30-Step Roadmap, за да структурирате пътя на внедряване, особено „Контроли в действие“ Стъпка 20 за мрежова сигурност и сегментация и Стъпка 21 за управление на промените. Използвайте Zenith Controls: The Cross-Compliance Guide, за да картографирате контролите 8.20, 8.22 и 8.32 от ISO/IEC 27002:2022 към одитните очаквания по NIS2, DORA, GDPR, NIST и COBIT. Закрепете оперативните си правила в Политика за мрежова сигурност, Network Security Policy-sme и Политика за регистриране и мониторинг на Clarysec.
Следващата ви стъпка е проста и с висока стойност: изберете една критична услуга, например клиентска продукционна среда, обработване на плащания или управление на идентичности, и извършете извадков преглед на 10 правила тази седмица. За всяко правило потвърдете собственик, обосновка, източник, дестинация, порт, регистриране, заявка за промяна и срок на изтичане. Ако не можете да докажете тези седем факта, имате началото на своя план за подобрение на сегментацията за 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
