Павел Кириллов
Технический директор Netopia
Средняя
Содержание
Введение
Нет ничего практичней хорошей теории (Восхождение по спирали).
Кому нужна Модель зрелости сетевой безопасности?
Если посмотреть российскую нормативную документацию по ИБ, там есть требования к Межсетевым экранам (ФСТЭК), есть серия Национальных стандартов по сетевой безопасности ГОСТ Р ИСО/МЭК 27033.
Стандарты пропагандируют проектный подход: внедрил — всё отлично! Граница на замке! Но они не отвечают на вопрос как развивать сеть, как приспосабливаться к изменяющимся условиям, как эффективно эксплуатировать сеть.
Почему это сделать непросто?
- Организации добавляют все новые и новые бизнес-приложения, службам эксплуатации сети необходимо обеспечить:
- безопасные каналы связи;
- снизить поверхность атаки;
- при этом сохранить доступность;
- регулярно вносить изменения в сеть.
- Необходимо также применять различные топологии в зависимости от решаемых задач:
- дата-центры;
- публичные и приватные облака;
- распределённые периферийные вычисления;
- удалённый доступ для сотрудников, которые находятся, где угодно (в России).
- При этом сами элементы сетевой инфраструктуры достаточно пёстрые:
- Legacy МЭ.
- NGFW.
- Облачные межсетевые экраны.
- SD-WAN.
В результате, команды сетевой безопасности сталкиваются с значительными трудностями в управлении это сложной, состоящей из большого количества технологий, экосистемой.
Модель зрелости сетевой безопасности
Разные компании имеют разный уровень зрелости сетевой безопасности. Кто‑то только начинает масштабировать свою сеть, у них свои потребности. Другие же компании уже во всю применяют автоматизацию и оркестрацию, конечно, для них актуальны совсем другие проблемы.
Имея модель зрелости сетевой безопасности, организации, могут определить:
- текущие возможности;
- текущие риски;
- что можно улучшить;
- технологии и функционал, необходимые для взросления сетевой безопасности и соответствию нормативным требованиям;
- сложности, которые предстоит преодолеть.
Модель представлена 4 уровнями зрелости:
- Начальный;
- Развивающийся;
- Продвинутый;
- Экспертный.
Начальный уровень
Организация приходит к пониманию, что размер сетевой инфраструктуры становится такой, что настраивать её вручную становится затруднительно. Команды сетевиков и безопасников все время залатывают дыры (пожарная бригада), у них нет чёткого плана действий, создаётся ощущение, что «всё срочно, всё необходимо».
Характерные особенности для данного уровня:
- Использование Excel для описания сети.
- Неструктурированные процессы при изменении сети или сетевых политик.
- Высокая вероятность ошибок и сложности с откатом к исходному состоянию.
- Растущая поверхность атаки.
- Высока вероятность, что злоумышленник сможет горизонтально перемещаться по сети.
- Каждое изменение занимает много времени и создаёт новые риски.
- Ручная проверка соответствия заданным требованиям (compliance).
Вопросы для самопроверки для понимания, что вы на этой стадии:
- Вы видите изменения в конфигурации и не знаете почему они были сделаны и кем?
- Вы смотрите на сетевое правило и не понимаете зачем оно нужно?
- Сетевая команда, внося изменения в сетевые политики, не понимает, зачем они?
- Люди нервничают, когда вносят изменения в существующие правила?
- Новые правила все время добавляются наверх политики?
- На межсетевом экране много правил и он от этого тормозит?
- Вы тратите кучу времени на дополнительные проверки, что изменения действительно применились?
- Многие задачи приходится делать несколько раз?
Шаги по улучшению текущей ситуации
- Определить и задокументировать ключевые активы
Это первый шаг, который необходимо сделать, чтобы начать движение от небезопасной плоской сети к сети, в которой есть зоны безопасности с базовой сегментацией, которая ограничит перемещения злоумышленников по сети.
Кого имеет смысл привлечь к этому процессу:
- Владельцы информационных систем.
- Руководители подразделений.
- Архитекторы ИТ инфраструктуры.
2. Определить политику сетевой безопасности
Когда критичные активы и зоны определены, мы можем сформулировать базовые требования к доступам в сетевые сегменты. Эти базовые требования определяют как приложения взаимодействуют между собой в рамках сети, и кто к ним имеет доступ.
Типовые зоны следующие:
- Внешняя\публичная зона — системы и сервисы, которым нужен доступ в интернет, такие как веб-серверы, почтовые серверы, им нужно максимально ограничить взаимодействие с внешним миром.
- Внутренняя зона — основные внутренние ресурсы для внутренних пользователей, внутренние приложения, файловые серверы, базы данных, которые могут быть доступны только для авторизованных пользователей/устройств.
- Критическая зона — самая критичная информация, например АБС, системы управления, ОКИИ, максимальные ограничения для ограниченного круга пользователей + мониторинг.
Если в организации определены зоны, вам надо быть уверенным, что вы видите потоки данных в разных сегментах для последующего управления и изменения.
3. Определить нормативные требования
Когда компания определила свои критические активы, необходимо определить нормативные требования, которые могут скорректировать корпоративную сетевую политику. Примеры требований:
- ГОСТ 57580.
- ГИС, ПДн, КИИ.
- PCI DSS.
- ISO 27001.
Развивающийся уровень
Когда в сетях появляется структура и начальная автоматизация, можно подумать насчёт улучшения контроля над сетевыми политиками и процессами изменения сетевых политик.
Как можно охарактеризовать компанию на текущем этапе развития:
- Есть базовая политика сетевой безопасности и формируются отчёты.
- Создаётся автоматизация для определённых кейсов, тем не менее остаётся много процессов, которые выполняются вручную.
- Фокус на оптимизацию и груминг правил.
- Взаимодействие между командами работает «со скрипом».
Какие плюсы видит организация:
- Видимость сети.
- Быстрое решение проблем, связанных с доступом и связностью сети.
- Базовая сегментация сети.
- Ручная валидация нормативных требований позволяет избегать штрафов.
- Автоматизация оптимизации политик сетевой безопасности.
- Приоритизация уязвимостей.
Отказавшись от экселя, сетевики и безопасники приобретают новый уровень видимости изменений в сети:
- новые правила;
- модифицированные объекты;
- изменённые правила.
Вопросы для самопроверки для понимания, что вы на этой стадии:
- У вас есть полный контекст происходящего? Знаете ли вы, когда, какие, где и почему делаются запросы на изменение сети?
- Вы все еще колеблетесь, когда удаляете сетевые правила, хотя в целом уверены во вносимых изменениях?
- Ваши возможности по автоматизации оптимизации правил ограничены?
- Вы хотите улучшить процесс изменения правил на межсетевых экранах, потому что тикетинговая система не отображает все необходимые данные?
Шаги по улучшению текущей ситуации
- Стандартизация политик безопасности
На этой стадии, большинство организаций имеет несколько вендоров МЭ на разных площадках. Чтобы управлять всем этим зоопарком, вам нужны стандартные вендор-независимые политики, чтобы:
- отслеживать соблюдение данных требований;
- идентифицировать потенциальные пробелы в безопасности или комплаенс;
- управлять исключениями.
Вендор-независимая политика сетевой безопасности даёт возможность лучше видеть и контролировать трафик и потоки данных, которые могут нарушить зафиксированное состояние.
Организация сможет ответить на вопросы:
- Как должна выглядеть сегментация сети в идеале?
- Как они определяют свою сетевую сегментацию?
- Какой трафик они запрещают и разрешают между сегментами?
Используя вендор-независимые политики, вы создаёте центр управления нарушениями и исключениями в правилах. Формируется центр контроля и автоматизации доступов и обнаружения нарушений в конфигурациях.
Когда критичные активы и зоны определены, мы можем сформулировать базовые требования к доступам в сетевые сегменты. Эти базовые требования определяют как приложения взаимодействуют между собой в рамках сети, и кто к ним имеет доступ.
2. Движение от экселей к трекингу изменений
На этой стадии трекинг изменений на бумаге приводит к большим трудозатратам, и ещё и ошибок можно наделать. Создание трекинговой платформы позволит ответить на вопросы:
- Кто внёс изменения?
- Что это были за изменения?
- Когда эти изменения внесли?
- Почему были внесены эти изменения?
Если в организации определены зоны, вам надо быть уверенным, что вы видите потоки данных в разных сегментах для последующего управления и изменения.
3. Интеграция с другими продуктами по безопасности
Интеграция NSPM с другими продуктами ИБ увеличивает комплексный уровень ИБ и комплаенса. Примеры интеграций:
- IP Address Management (IPAM).
- Security Information and Event Management (SIEM).
- IT Service Management (ITSM).
Обогащение данными по МЭ в дектирующие системы, IRP системы, приводит к снижению среднего времени обнаружения проблемы (MTTD–Mean time to detect) и среднего времени её устранения (MTTR — Mean time to respond), сильно уменьшая финансовые потери от инцидентов ИБ.
Продвинутый уровень
На продвинутом уровне за счёт автоматизации и оркестрации ресурсов можно быстро вносить изменения в сеть, при этом не понижая уровень информационной безопасности.
На данном уровне зрелости организация имеет надёжные процессы, такие как:
- Автоматизация и оркестрация, которые обеспечивают процесс изменения правил, жизненный цикл правил.
- Проактивную проверку комплаенс требований до внесения изменений, чтобы обеспечить автоматизацию непрерывного комплаенса.
- Быстрое детектирование некорректных настроек и траблшутинг по всей сети.
- Увеличение интеграции со смежными инструментами, что позволяет поддерживать больше сценариев эксплуатации.
С предсказуемыми изменениями политик и мониторинга организация получает следующие плюсы:
- Оптимизация правил и политик.
- Уменьшение поверхности атаки и продвинутая чистка правил.
- Связность по сети, анализ маршрутов и траблшутинг.
- Возможность миграции и расширения сети через продукт.
- Беспрерывный аудит и контроль требований комплаенс.
- Выделение минимально необходимых прав при создании правил.
Вопросы для самопроверки для понимания, что вы на этой стадии:
- Хотите ли вы улучшить автоматизацию изменения сетевых правил?
- Создаваемые правила соответствуют требованиям минимальности?
- Вы управляете всеми правилами в рамках всей сети? Или остались какие-то легаси?
Шаги по улучшению текущей ситуации
- Автоматизация декомиссии правил
Декомиссия правил в рамках мультивендорной гибридной сети увеличивает безопасность и производительность. Уменьшает поверхность атаки закрывая доступ к активам, которые больше не нужны или избыточны. К тому же с меньшим количеством правил скорость по сети увеличивается. Для увеличения операционной эффективности и уменьшения человеческого фактора, вы можете внедрить автоматизацию для идентификации, удаления, декомиссии следующих сущностей:
- отключённые правила;
- дублирующиеся сетевые объекты;
- дублирующиеся сервисы;
- пустые группы;
- полностью затенённые правила;
- непривязанные объекты.
2. Применение принципа минимальных привилегий
Когда вносятся изменения в доступы, сетевые администраторы должны применять минимальные, максимально эффективные изменения и ограничивать их до того, что требуется открыть. В рамках этого процесса мы даём только тот доступ, который нужен, ни больше, ни меньше.
Это подразумевает:
- ограничение по источнику/назначению/сервису;
- отказ от any, где это возможно;
- отказ от широких диапазонов, где это возможно.
3. Автоматизация управления жизненным циклом правила
Когда вы автоматизируете управление жизненным циклом правил, вы можете сформировать процесс их сертификации, который документирует и верифицирует цель правила.
Таким образом формируется процесс сертификации правил, который включает:
- сертификационный статус правила;
- дату сертификации;
- дату истечения сертификации.
4. Создание продвинутых интеграций
Создание продвинутых интеграций позволяет повысить надёжность и эффективность применения сложных продуктов по информационной безопасности. С чем можно интегрироваться:
- IT service management (ITSM).
- Vulnerability Management Solutions.
- Governance risk and compliance (GRC).
- Security orchestration, automation, and response (SOAR).
- Secure access service edge (SASE).
Экспертный уровень
На этом уровне организация имеет комплексную автоматизацию, которая обеспечивает скорость, точность выполняемых задач и тесную интеграцию в рамках организации.
Имея такой уровень осведомлённости для идентификации и траблшутинга проблем в реальном времени, компании получают:
- Быстрый таблшутинг.
- Проактивный риск менеджмент с автоматической митигацией.
- Портал для быстрых изменений в рамках сети.
- Комплаенс и риск индикаторы, которые полностью интегрированы в процессы изменений.
- Прозрачная интеграция между подразделениями devops, сетевой безопасности, облачной безопасности, ИБ.
Управление политиками на данном уровне характеризуется:
- Автоматизированный процесс изменения политик с учётом рисков.
- Полный цикл управления правилами.
- Универсальные правила во всех инфраструктуре.
- Возможность для быстрого роста и развития сети.
Вопросы для самопроверки для понимания, что вы на этой стадии:
- Все команды общаются на одном языке при внесении изменений в сетевые политики?
- Можете ли вы решить сетевые проблемы за считанные минуты?
- Готовы ли вы к масштабированию требований по сетевой безопасности при росте сети?
Шаги по улучшению текущей ситуации
- Применение сервис-центричных политик
Используя сетевые политики, привязанные к приложениям, организации могут видеть связи между приложениями и сервисами в рамках сети. Такой подход транслирует цели и задачи владельцев приложений/сервисов, в связи с этим сетевикам и безопасникам не нужно фокусироваться только ip-адресах, они могут понимать бизнес контекст запросов и действовать соответствующим образом. Таким образом закрывается зазор между владельцами системы, не обладающих экспертизой по сетям и сетевыми администраторами.
Плюсы такого подхода:
- Видимость в режиме реальность времени бизнес-приложений, их требований по связности, статусу и необходимых текущих изменений
- Тесное взаимодействие между сетевиками и инфрастуктурщиками.
2. Повышение отказоустойчивости сети
На данному уровне развития организации могут сфокусироваться на отказоустойчивой архитектуре для поддержки непрерывности бизнеса и программ по восстановлению работоспособности. Создавая избыточность, организации предотвращают нарушения в работе инфраструктуры, связанные с едиными точками отказа:
- Репликация данных для предотвращения сбоев сервисов.
- Применение кластеризации.
- Решение проблем без сбоев сервисов.
Выводы
- Были рассмотрены все уровни модели сетевой безопасности.
- Были ранжированы проблемы сетевиков на каждом этапе развития сетевой безопасности в компании.
- Составили дорожную карту, которая позволит вам сделать вашу сеть надёжной и безопасной.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
