Как управлять сетью — класс решений Firewall management. Часть 1. Skybox

Не можете разобраться, что происходит в сетевой инфраструктуре? Создание Access Control List (ACL) давно стало рутиной, но по-прежнему отнимает очень много времени? Приходится управлять несколькими межсетевыми экранами разных вендоров одновременно? Скоро придет аудитор, чтобы проверить, насколько написанные вами правила доступа соответствуют требованиям регулятора или отраслевому стандарту? Если вы узнали себя хоть в одном вопросе, этот текст для вас.

В общем, добро пожаловать под кат все ищущие унификации в анализе и контроле настроек межсетевых экранов (МСЭ) и сетевых устройств.

Это первая из трех статей цикла обзоров решений класса Firewall management, в котором мы рассмотрим решения Skybox Security, Tufin orchestration suite и AlgoSec.

В каждой более-менее крупной организации существуют (мне очень хочется в это верить) и даже иногда формализованы процессы управления состоянием сети (изменения на сетевых устройствах, изменения топологии сети, контроль доступности сервисов на уровне сети) и управления уязвимостями.

Однако администраторам ИБ и ИТ всё равно приходится сталкиваться с целым рядом проблем.

Проблема 1

Большое количество устройств и правил/политик

В настоящее время в ИТ-инфраструктуре большинства компаний эксплуатируется достаточно много сетевых устройств и межсетевых экранов. Общее количество правил фильтрации, списков контроля доступа и прочих настроек, связанных с обеспечением безопасности и контроля доступа к элементам инфраструктуры, исчисляется тысячами. Эти правила, списки и прочие объекты в процессе эксплуатации значительно разрастаются, начинают дублировать и перекрывать друг друга.

При этом управление оборудованием выполняется с помощью ряда консолей, что значительно усложняет получение единой наглядной картины эффективности действия правил доступа по всей сети. Поэтому оптимизация и анализ правил и прочих объектов в базах устройств доступа «вручную» совершенно неэффективны: через некоторое время вновь возникнет путаница.

Тут можно возразить, что ряд МСЭ проверяют правила до создания, чтобы найти «дублирующиеся» и «перекрывающие». А так на всех устройствах? А позволяют ли они пометить правило, которое специально создано как «дублирующееся» и «перекрывающее»?

Проблема 2 (тесно связана с проблемой 1)

Необходимо регулярно открывать новые доступы на существующих МСЭ, изменять настройки МСЭ

В целом после внедрения любого МСЭ и до момента его вывода из эксплуатации общий перечень выполняемых с этим МСЭ действий выглядит так:

1. Настройка правил доступа в процессе эксплуатации МСЭ.

2. Администрирование настроек МСЭ.

3. Оценка выполненных настроек и соответствия ACL требованиям отраслевых стандартов, лучшим практикам и рекомендациям вендоров МСЭ.

4. Ресертификация правил доступа (проверка «нужности» правила, продление срока его жизни или удаление).

Каждое действие требует определенного времени на выполнение, а самое главное — времени на трудоёмкий и порой непрозрачный процесс согласования изменений со всеми заинтересованными лицами. Очень часто процесс открытия доступов на сетевом оборудовании (даже если он не задокументирован) ведется в какой-либо внутренней тикет-системе, а это — плюс еще одна «консоль», в которой приходится работать ИТ- и ИБ-администраторам.

Проблема 3

Отсутствие актуальной схемы сети организации

Как бы сетевики ни старались, и как бы ИБэшники ни требовали, очень трудно поддерживать схему сети всей организации актуальной и в едином файле. Логичным выглядит внедрение какой-либо системы, которая сможет подключаться ко всем сетевым устройствам, считывать конфигурации и самостоятельно отрисовывать актуальную схему сети. Но вот найти такое решение, способное поддерживать все наиболее распространённые сетевые устройства, довольно трудно.

Проблема 4

Невозможно адекватно оценить риски изменения каких-либо настроек на сетевом оборудовании (как в правилах доступа, так и в настройках самого сетевого оборудования) ДО момента внесения этих настроек

Например, необходимо открыть доступ по определенному порту (ТСР:443) к определенному серверу (конкретный IP-адрес). Регламенты организации позволяют создавать такое правило, ИТ- и ИБ-администраторы не видят рисков, доступ открывается. Но никто не задумался, что, например, на целевом сервере стоит уязвимый IIS и открытие доступа к серверу по ТСР:443 создает дополнительный вектор для атак.

Проблема 5

Нет возможности проследить весь «путь» трафика

Если, когда нужно открыть доступы, между конечными устройствами (например, между двумя корпоративными серверами) находится больше 3-4 маршрутизирующих устройств, на которых помимо процессов маршрутизации выполняется еще и фильтрация трафика или даже его преобразование (NAT), после создания разрешающего правила требуется проверить, получили ли серверы нужные доступы или нет. И вот если этого доступа они не получили..., сетевых администраторов ждёт головная боль: им придётся пытаться определить, на каком же сетевом устройстве трафик отбрасывается или направляется не в ту сторону.

Суммируя вышесказанное, для решения ежедневных задач ИТ- и ИБ-службам требуется инструмент, который позволит:

• автоматизировать процесс управления политиками сетевого доступа;

• проводить комплексный аудит конфигураций межсетевых экранов и сетевых устройств, в том числе проверять их на соответствие отраслевым стандартам и лучшим практикам информационной безопасности;

• визуализировать и поддерживать в актуальном состоянии логическую карту сети организации (уровня L3 модели OSI);

• и (опционально) аккумулировать информацию по уязвимостям ИТ-инфраструктуры, определять, насколько злоумышленник может использовать те или иные уязвимости ИТ-активов извне или из внутренней сети компании, а также управлять найденными уязвимостями;

• моделировать изменения в существующей сетевой инфраструктуре.

Для решения подобного рода проблем существуют системы класса Firewall Management (FWM, хотя его еще называют Security Posture Management, Security Policy Management и даже Network Security Management).

Важно понимать, что FWM не является ни SIEM, ни NTA, ни Vulnerability scanner, ни чем-либо еще.

Решения этого класса модульные, в них каждый модуль выполняет свою функцию. Далее представлены модули, которые представляют собой основу всех решений направления FWM:

Модуль анализа МСЭ и сетевых устройств — основная неотъемлемая часть решений FWM — предназначена непосредственно для сбора и анализа конфигураций сетевых устройств и устройств безопасности всех основных производителей: Cisco, Check Point, Juniper, Palo Alto, Fortinet, McAfee, Forcepoint, VMware и др.

Сбор конфигураций осуществляется онлайн (информация собирается непосредственно с самих устройств) и/или офлайн (путем загрузки конфигурационных файлов сетевых устройств). При сборе онлайн производится ввод последовательности команд на просмотр (нет-нет, никаких изменений вноситься не будет) и вывод этих команд «забирается» FWM для дальнейшего разбора и анализа.

Также на основании полученных конфигураций строится динамическая карта сети. Эта карта позволяет увидеть, как устроена сеть, проверить доступность хостов между собой с отображением подробной информации, где и какие правила разрешают/запрещают доступ.

Анализ собранных конфигураций МСЭ позволяет:

• Найти затененные и избыточные ACL: правила, которые не могут сработать из-за идентичного или более широкого правила, стоящего выше в ACL. Модуль позволяет обнаружить как простые случаи (широкое правило затеняет узкое), так и менее очевидные, когда оценивается влияние целой совокупности правил.

• Провести анализ ACL МСЭ на соответствие тем или иным параметрам (например, ANY в двух и более полях правила).

• Провести анализ конфигурации устройств на соответствие best practice от производителей.

• Проверить соответствие настроенных правил стандартам и требованиям регуляторов (например, PCI DSS или NIST).

Все эти функции составляют некое «ядро» каждого решения класса FWM.

Модуль управления межсетевыми экранами позволяет автоматизировать процесс изменений на МСЭ на всех его этапах: формирования задачи, ее согласования, проектирования решения, внесения изменения, верификации результата. В итоге получаем тикет-систему, созданную специально для подобных задач. Например, на стадии согласования планируемых изменений сотрудник ИБ может запустить автоматическую проверку того, насколько эти изменения соответствуют настроенной политике ИБ, и на основании этого принимать решение о согласовании или отказе. На этапе проектирования администратор может получать рекомендации от модуля FWM о том, каким способом лучше выполнять изменение: на каком устройстве, какое правило добавить/изменить, и даже могут быть сформированы конкретные команды в терминах конечных устройств. К тому же есть возможность настроить систему и на автоматическое применение согласованных изменений на целевые МСЭ.

Но есть и принципиальные различия в назначении некоторых дополнительных модулей разных вендоров (т.е. эти модули не входят в «ядро» решений FWM, но обладают очень полезным сопутствующим функционалом):

Модуль управления приложениями (опциональный модуль) — предназначен для менеджеров корпоративных приложений. Модуль позволяет абстрагироваться от сетевых устройств и задать сетевые требования для распределенных приложений. Например, можно определить сегмент пользователей приложения, сервер приложения, сервер БД, сервер реплики БД, задать, по каким протоколам эти компоненты между собой общаются, и назвать эту конструкцию «интернет-магазин». Далее одним кликом можно сформировать заявку на предоставление необходимого доступа. В дальнейшем все изменения конфигураций сетевых устройств будут проверяться на предмет нарушения доступности приложения.

Модуль приоритизации уязвимостей (опциональный модуль) — обеспечивает контекстное управление уязвимостями. Этот модуль может «наложить» уязвимости на карту сети и определить, какие из найденных уязвимостей могут быть проэксплуатированы злоумышленником, а какие нет. Таким образом выполнится приоритизация уязвимостей, и администратор ИБ может ставить может ставить четкие задачи и адекватные сроки устранения уязвимостей для системных и сетевых администраторов, а не отправлять им необработанную "портянку" всех найденных в IT-инфраструктуре компании дыр.

В этом классе решений на российском рынке наиболее зрелые решения, по нашему скромному мнению, это AlgoSec, Skybox Security и Tufin. Есть и другие решения (из наиболее известных это FireMon Security Manager, ManageEngine Firewall Analyzer, RedSeal), но большого распространения в СНГ они пока что не получили.

Архитектура каждого из решений предельно проста:

1. коллекторы, выполняющие сбор информации с сетевых устройств и\или систем путем подключения к ним (ssh, telnet, API, подключение напрямую к базе данных и пр.) и выполнения необходимых команд (например, show conf, show routing и пр.). Всю собранную информацию коллекторы парсят и передают на сервер.

2. сервер, выполняющий сбор и аналитику информации от коллекторов, обеспечивающий интерфейс взаимодействия с администратором и выдающий отчетность.

Каждым решением можно управлять, используя браузер, в некоторых случаях потребуется устанавливать "толстый" клиент.

Схема лицензирования у вышеуказанных решений похожа: нужно лицензировать каждый загружаемый в решение актив (сетевое устройство, МСЭ и пр.).

Давайте теперь предметно разберём каждое из FWM-решений, обсудим специфику их работы и какие проблемы они позволяют решить ИТ и ИБ-администраторам.

Skybox Security

И чтобы эта статья не была похожа на мой диплом, полный воды, принесла как можно больше полезного, сразу предлагаю рассмотреть более детально решение Skybox Security.

Страна-производитель - США, но решение родом из Израиля, присутствует на рынке с 2003 года.

Общая архитектурная схема Skybox Security

Skybox имеет сервер-коллекторную архитектуру (сервер может быть только один, колекторов - неограниченно) и клиент-серверную архитектуру для взаимодействия с пользователем (можно подключаться к веб-интерфейсу, но часть операций доступна пока что только из java-консоли. Надо отметить, что толстый клиент на java весит почти 2 (sic!) Гб).

Общая архитектурная схема Skybox Security выглядит примерно так (указаны типовые взаимодействия с оборудованием в сети, при этом характеристики самого сервера Skybox (8 CPU, 32 RAM, 500 HDD) тут указаны минимальные и зависят от объема инсталляции и количества подключаемых устройств - обычно, на каждые 200 сетевых устройств требуется отдельный коллектор с такими же характеристиками):

Skybox может взаимодействовать с большим количеством систем различных типов: межсетевые экраны, IPS, сетевые устройства уровня L3, балансировщики нагрузки, системы патч-менеджмента, системы Threat Intelligence, сканеры уязвимостей и пр. Актуальную информацию о возможных интеграциях Skybox можно найти тут. Обратите внимание, что Skybox умеет интегрироваться и с отечественными решениями: сканером уязвимостей MaxPatrol 8, криптошлюзами Dionix-NX, Континентом 3.9 ЦУС, а с недавних пор (немного похвастаюсь) при нашем содействии еще и с ViPNet Coordinator (for Linux и HW).

Функционал модулей Skybox Security

Network Assurance

Модуль Network Assurance (NA) предназначен для работы с сетевыми устройствами (L3) и может функционировать как самостоятельно, так и в комбинации с другими модулями. Он позволяет выполнять:

• Сбор конфигураций со всех поддерживаемых сетевых устройств (L3) и автоматическое построение карты сети на основе данных из собранных конфигурационных файлов и сведений о маршрутизации (в том числе динамические протоколы!). Про карту сети в Skybox и ее назначение можно говорить долго и написать не одну статью. Если кратко, то каждая уважающая себя организация должна хорошо представлять, что она защищает (активы), а также какие есть уязвимые места в этих активах. Инвентаризация сети обычно выполняется CMDB-системами, информацию об уязвимостях приносят сканеры уязвимостей (например, MaxPatrol 8). Однако, чтобы понимать насколько те или иные уязвимости на конкретных активах ДЕЙСТВИТЕЛЬНО критичны, нужно знать может ли злоумышленник до них «дотянуться». Здесь как раз и может помочь Skybox – собрав всю информацию из CMDB (об активах), из сканеров уязвимостей (об уязвимостях на активах) и сетевого оборудования (маршруты, ACL, IPS-сигнатуры), Skybox может построить карту сети, наложить на нее найденные уязвимости в активах и подсказать какие уязвимости нужно закрыть в первую очередь (до которых потенциально может добраться нарушитель).

  Пример карты сети в Skybox:

• Контроль соответствия конфигураций сетевых устройств заданным стандартам конфигурирования и лучшим практикам производителей, включая локальные принятые правила конфигурирования (например, вы хотите убедиться, что ни на одном устройстве нет локальной учетной записи "administrator", или нужно убедиться, что на всех устройствах Cisco в сети организации установлен определенный NTP и т.д.);

• Вычисление и визуализацию на карте сети возможных путей/маршрутов прохождения заданного типа трафика с демонстрацией разрешающих и запрещающих правил/настроек на всех промежуточных L3 устройствах сети для данного пути/маршрута (построив карту сети, Skybox может вычислить пути прохождения трафика самостоятельно и при соответствующем запросе пользователя может показать этот маршрут. При этом, если трафик где-то блокируется, Skybox укажет где именно трафик блокируется и каким именно ACL);

• Создание политики сетевого доступа (сетевого сегментирования) и автоматический контроль ее исполнения как в масштабах всей модели сети, так и на уровне настроек отдельных устройств (например, у вас в сети есть сетевые зоны APP, DB, DMZ и другие, вам необходимо точно знать, что везде соблюдаются правила "Из DB в другие зоны запрещены исходящие подключения", "Из APP в DB разрешены исходящие подключения, но из APP в DMZ запрещены", "Из DMZ в APP разрешены исходящие подключения, но только по определенным портам" и пр. Можно эти формальные правила переложить в настройки (хоть регулярными выражениями, хоть обычным указанием зон и параметров взаимодействия этих зон) и внести в Skybox и далее он автоматизировано и регулярно будет выполнять проверку соответствия этим правилам). Пример политик на основе PCI DSS:

Firewall Assurance

Модуль Firewall Assurance (FA) предназначен для работы с межсетевыми экранами, и может функционировать как самостоятельно, так и в комбинации с другими модулями. Межсетевыми экранами для Firewall Assurance могут выступать как непосредственно сами МСЭ, так и другие поддерживаемые сетевые устройства, использующие списки доступа (ACL) и сигнатуры IPS. Модуль осуществляет постоянный мониторинг всех МСЭ на соответствие политикам, оптимизирует правила на этих МСЭ, осуществляет непрерывный мониторинг настроек межсетевых экранов. FA позволяет выполнять:

• Автоматический сбор конфигураций МСЭ и непрерывный мониторинг настроек, включая отслеживание всех изменений на МСЭ;

• Оптимизацию списков доступа в МСЭ:

1. Выявление затененных, избыточных, неиспользуемых правил (затененное правило - то, выше которого стоит более "широкое" правило и в итоге затененное правило становится полностью бесполезным. Избыточное - это "широкое" правило, которое стоит ниже более "узкого" и частично дублирует его функционал);

2. Выявление редко используемых правил и объектов (если направить syslog из МСЭ в Skybox, на основе статистики использования тех или иных правил или объектов Skybox может выяснить какие именно объекты не используются на МСЭ. В том числе анализируется hitcount для каждого правила). Пример найденных неиспользуемых объектов;

Пример найденных редко используемых объектов:

3. Формирование рекомендаций по оптимизации правил (на основе собранной информации из hitcount каждого ACL и информации из syslog с МСЭ Skybox может предложить, как оптимизировать объект или правило или указать на то, что не используется вовсе);

• Контроль соответствия конфигураций МСЭ заданным стандартам конфигурирования и лучшим практикам, включая локальные правила конфигурирования, а также указание причины несоответствия вплоть до конкретных правил на конкретных устройствах (аналогично похожему функционалу в модуле Network Assurance, но только для МСЭ);

  1. Выявление правил, содержащих "any" в 2 или 3 полях, в поле «сервис» и т.д.;

  2. Выявление настроек, противоречащих рекомендациям производителей с точки зрения безопасности;

  3. Выявление настроек, разрешающих передачу паролей в открытом виде (подключение к CLI с использованием telnet) и т.д.;

Пример найденного нарушения политики "Any" в двух и более полях (всегда можно провалиться в каждое правило и увидеть его детали):

• Создание политики сетевого доступа (зон безопасности) и автоматический контроль ее исполнения (анализ на соответствия стандартам PCI DSS, NIST встроен по умолчанию) на уровне зон безопасности МСЭ с указанием причины несоответствия вплоть до конкретных правил на конкретных устройствах. Это, можно сказать, "киллер-фича" этого класса решений и Skybox в частности: можно формализовать политику межсетевого экранирования вашей организации, внести ее в Skybox и больше не переживать перед очередным аудитом что у вас что-то не так - Skybox автоматически и регулярно может проверять исполнение этой политики на всех МСЭ вашей организации.;

Пример встроенных политик написания ACL:

Change Manager

Change Manager (CM) является дополнением к модулю Firewall Assurance (FA), при этом количество лицензий CM всегда должно соответствовать FA. CM позволяет контролировать и автоматизировать процесс изменения правил доступа от заведения заявки до ее выполнения и гарантирует то, что все изменения произведены в полном соответствии с принятым регламентом предоставления сетевого доступа (Workflow). CM позволяет выполнять:

• создание Workflow на изменение сетевого доступа за счет встроенной системы заявок или интеграции с внешними тикет-системами с использованием REST или SOAP API (Remedy, OTRS и пр.);

• предоставление или изменение сетевого доступа;

• периодический пересмотр правил сетевого доступа;

• выявление изменений правил и настроек, выполненных без соответствующей заявки или согласования;

• автоматическое выделение устройств, на которых необходимо произвести изменения;

• формирование рекомендаций по вносимым изменениям конфигураций МСЭ при изменении сетевых доступов;

• автоматическое применение планируемых изменений правил МСЭ (не для всех МСЭ, об этом ниже);

• автоматическую оценку влияния планируемых изменений на политику сетевого доступа и безопасного конфигурирования, а также (в случае наличия модуля Vulnerability Control) на защищенность ИТ-активов (серверов, компьютеров, сетевых устройств) с точки зрения появления дополнительных уязвимостей, связанных с изменением.

Проще говоря, СМ позволяет визуализировать, оптимизировать процесс изменения ACL на МСЭ, формализовать процесс внесения изменений на МСЭ с отметками о согласовании всех заинтересованных лиц. Пример тикета в СМ (сверху как раз указан типовой Workflow: Request — Technical details — Risk Assessment — Implementation details — Verification. Таких Workflow может быть несколько — каждый под определенные задачи):

CM поддерживает изменение правил доступа на следующем оборудовании:

Vulnerability Control

Модуль Vulnerability Control (VC) является модулем работы с уязвимостями и лицензируется по числу ИТ-активов (например, серверы, рабочие станции, сетевое оборудование), в отношении которых необходимо производить анализ и расчет векторов атак. Vulnerability Control объединяет данные со всех сканеров, систем патч-менеджмента и систем инвентаризации, информацию о потенциальных уязвимостях и источниках угроз, «накладывает» данные об уязвимостях на карту сети и позволяет визуализировать векторы возможных атак. VC позволяет выполнять:

• Автоматический сбор информации об ИТ-активах (имеющиеся уязвимости, актуальный состав и версии ПО) из сканеров, систем инвентаризации и патч-менеджмента (всю информацию, что выдает сканер в отчетах или все установленные патчи и апдейты, которые может сообщить WSUS или SCCM, обрабатываются Skybox'ом и в дальнейшем используются для моделирования атак).

• Анализ возможных векторов атак с учетом настроек сетевого оборудования, источников угроз (нарушителей, модели которых также можно создать, указав его возможность «skill», изначальные права («root» или «user»), местоположение в сети и пр.), включая активированные сигнатуры IPS. Это и есть моделирование атак, причем не «бумажное», а самое что ни на есть настоящее, только внутри Skybox'а — по его результатам можно понять, что делать дальше и в какой последовательности, чтобы защититься от атак или же минимизировать количество векторов атак.

• Выявление вновь появляющихся уязвимостей в период до/между сканированиями (в модуле есть ежедневно обновляемая собственная база).

• Приоритизация найденных уязвимостей (вместо «портянки» уязвимостей, которую выдает сканер уязвимостей, Skybox проранжирует уязвимости с указанием хостов, на которых они были найдены, в порядке наибольшей критичности. Например, уязвимость может иметь рейтинг 6 по CVSS, но при этом хост, на котором она была найдена, «торчит» в интернете, и доступ к нему на МСЭ открыт. Skybox подсветит это и укажет, что именно эту уязвимость именно на этом хосте необходимо закрыть в первую очередь). При ранжировании уязвимостей учитываются:

1. возможности их реальной эксплуатации в условиях конкретной сети и ее настроек;

2. сбор сведений о частоте эксплуатации каждой конкретной уязвимости (на основе подписок Threat Intelligence Feeds);

3. сбор сведений о ценности ИТ-актива, содержащего конкретную уязвимость;

4. оценка критичности уязвимости;

5. наличие готовых инструментов атак (exploits), направленных на эксплуатацию конкретной уязвимости;

6. сбор информации о фактах атак, в ходе которых зафиксирована эксплуатация конкретной уязвимости.

• Формирование рекомендаций по устранению уязвимостей с возможностью реализации Workflow на базе встроенной системы заявок (или через интеграцию с внешней тикет-системой).

Схема лицензирования

Как упоминалось ранее, Skybox Security имеет сервер-коллекторную архитектуру, при этом:

1. Модуль Firewall Assurance лицензируется по количеству межсетевых экранов (и важно учитывать, что на кластер из двух нод МСЭ нужно две лицензии FA, а если есть виртуальные МСЭ (context, VDOM, VSX и пр.), то нужно пролицензировать каждый виртуальный МСЭ). Минимальная лицензия включает пакет на 10 сетевых устройств.

2. Модуль Change Manager — лицензируется аналогично модулю FA, покупается только совместно с FA (или когда тот уже приобретен ранее). Минимальная лицензия включает пакет на 10 сетевых устройств.

3. Модуль Network Assurance — лицензируется по количеству сетевых L3 устройств, в том числе МСЭ (т.е. все устройства, которые могут выполнять маршрутизацию, должны быть пролицензированы). Минимальная лицензия включает пакет на 10 сетевых устройств.

4. Модуль Vulnerability Control — лицензируется по общему количеству хостов и сетевых L3 устройств в модели (информацию о каком количестве ИТ-активов будет анализировать Skybox). Минимальная лицензия включает пакет на 100 ИТ-активов.

Модули можно комбинировать, и они не зависят друг от друга (с другой стороны, ни к чему покупать VC без закупки FA, но такая возможность все равно есть). Ниже приведен функционал Skybox Security в зависимости от приобретенных лицензий:

Usecases (для решения каких задач и в каких случаях стоит применять решение)

На основе нашего опыта Skybox особенно эффективен для:

• контроля соответствия конфигураций сетевых устройств внутренним и отраслевым стандартам, общим практикам и рекомендациям производителей;

• оптимизации конфигураций;

• контроля действий эксплуатирующей организации;

• моделирования и оценки влияния изменений в сети;

• приоритизации уязвимостей с учетом бизнес-рисков;

• выстраивания процессов управления конфигурациями и уязвимостями (с помощью встроенной тикет-системы или интеграции с существующей в организации тикет-системой);

• моделирования нарушителей в сети и векторов их атак на ИТ-активы организации (решение позволяет моделировать потенциальных нарушителей и формировать возможные векторы атак на активы на основе сведений о сетевой топологии и правил сетевого доступа, учитывая при этом квалификацию нарушителей и их расположения в сети).

Также стоит отметить, что Skybox Security — единственное решение в классе Firewall Management, получившее сертификат соответствия требованиям ФСТЭК России (Требования доверия (6), ТУ. Сертификат 4356).

Заключение

В заключение хотелось бы сказать, что как бы быстро ни развивались технологии, какие бы новые «фичи» не внедрялись в межсетевые экраны, всегда останется неизменным их базовый функционал — фильтрация трафика на L3-L4 уровнях. Сколько бы ни пытались производители межсетевых экранов облегчить работу администраторов, всегда будут рутинные операции по открытию доступов, по аудиту и приведению настроек МСЭ в соответствие требованиям отраслевых стандартов. И поэтому класс решений Firewall Management еще долго будет актуален для многих средних и больших компаний.

В следующих статьях мы расскажем о других решениях Firewall Management — о Tufin и AlgoSec, не пропустите!

Огромное спасибо моим коллегам ValentinaS, Waltherman, Desolation92 за критику и помощь.