Тестирование PT NGFW 1.10.3: 156 функциональных проверок. Часть 2

Innostage2 часа назадКраткое содержание статьи

Тестирование PT NGFW 1.10.3: 156 функциональных проверок. Часть 2

Время на прочтение56 минОхват и читатели2.7KБлог компании InnostageИнформационная безопасность*Сетевое оборудованиеАвтор: Дмитрий Квашнин, ведущий инженер-эксперт Innostage

Привет, Хабр!

В первой части статьи мы проверили производительность PT NGFW версии 1.10.3. Измерили скорость установления TCP-соединений, количество одновременных сессий и пропускную способность на профиле EMIX при разных наборах включённых функций.

Но производительность — только одна сторона оценки межсетевого экрана. Даже если устройство выдерживает заданную нагрузку, перед внедрением важно понять, насколько его функциональность соответствуют требованиям конкретной инфраструктуры.

Поэтому вторым этапом мы провели функциональное тестирование той же версии PT NGFW. Мы проверили возможности межсетевого экрана и системы управления: от фильтрации трафика и обнаружения атак до журналирования, разграничения доступа, резервирования и интеграций с другими системами.

Зачем понадобилась вторая часть испытаний

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

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

Что проверяли

Всего в протокол вошло 156 пунктов, разбитых по группам (см. Приложение 1). Мы оценивали базовые технические возможности и отказоустойчивость, межсетевое экранирование, IDS/IPS, веб-фильтрацию и идентификацию приложений, защиту от вредоносного кода, журналирование и управление, маршрутизацию, развёртывание, криптографическую защиту и разграничение доступа.

Общий результат

По итогам проверки 136 пункта получили статус «Тест пройден», ещё 7 — «Тест пройден с замечаниями», а по 13 пунктам соответствие заданным критериям не было подтверждено.

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

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

Что показали проверки

Базовые технические возможности, межсетевое экранирование и IDS/IPS

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

В общих технических требованиях успешно прошли проверку создание кластеров отказоустойчивости PT NGFW и серверов управления PT-MNGT, централизованное управление межсетевыми экранами, сохранение управляемости компонентов при высокой нагрузке, работа в режиме маршрутизатора и виртуальное соединение vWire. Также подтверждена возможность интеграции со сторонними системами обеспечения безопасности по Syslog.

В части межсетевого экранирования проверили создание правил фильтрации на разных уровнях модели OSI, включая прикладной, использование учётных записей Active Directory в правилах, настройку ограничений по времени, трансляцию сетевых адресов (NAT). В протоколе также подтверждены VPN-соединения Site-to-Site и работа счётчиков срабатывания правил.

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

Веб-фильтрация, приложения и защита от вредоносного кода

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

Проверки подтвердили возможность фильтрации веб-трафика с использованием URL-категорий и пользовательских списков адресов, настройки правил фильтрации и расшифрования HTTPS-трафика с помощью TLS-прокси.

Также подтверждена идентификация приложений. Согласно протоколу, система поддерживает более 3500 приложений; при необходимости добавления приложений предусмотрена возможность обращения в техническую поддержку. Отдельно проверялась категоризация URL: в примечании к результатам указано около 190 миллионов URL-адресов.

В рамках контентной фильтрации подтверждена возможность использования учётных записей Active Directory для создания персональных или групповых правил. Также пройдена проверка фильтрации трафика по определённым приложениям.

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

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

Система управления: администрирование, аудит и автоматизация

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

Проверки подтвердили возможность развёртывания системы управления на отдельном сервере и в виртуальной инфраструктуре, синхронизации политик между устройствами, ведения журнала действий администратора и подсчёта срабатываний по политикам безопасности.

Также успешно прошли проверку резервное копирование, восстановление и перенос конфигурации системы управления.

Подтверждены механизмы поиска свойств сетевых объектов при создании правил и массовой выгрузки и загрузки объектов и правил через API. Проверена возможность интеграции через NBI-интерфейсы, а также регистрации действий администратора

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

Не пройдена проверка централизованного распространения и применения новых версий программного обеспечения для шлюзов.

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

Проверка мультидоменного управления также завершилась с замечаниями.

Ещё два примера — ролевая модель и организация совместной работы администраторов. В протоколе отмечены ограничения гибкой настройки ролей и отдельные недоработки сценариев параллельного изменения политик. При этом наличие предопределённых ролей и возможность работы с политиками подтверждены соответствующими проверками.

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

Как читать результаты протокола

Статус каждой проверки показывает, подтверждено ли выполнение конкретного требования в рамках заданного критерия и условий испытания.

«Тест пройден» означает, что соответствие критерию подтверждено. «Тест пройден с замечаниями» означает, что результат получен с оговорками или выявлены особенности реализации. «Тест не пройден» означает, что соответствие заданному критерию не подтверждено.

Последний статус сам по себе не позволяет однозначно установить причину результата. Она может быть связана с отсутствием требуемой возможности, отличиями фактического поведения от критерия проверки или условиями проведения испытания. Для вывода о причинах необходимо рассматривать конкретный пункт протокола, его критерий и примечания

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

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

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

Выводы

Функциональное тестирование дополнило результаты нагрузочных испытаний PT NGFW 1.10.3. Если первая часть исследования была посвящена производительности межсетевого экрана под нагрузкой, то во второй мы проверили выполнение конкретных функциональных требований.

Из 156 пунктов протокола 136 получили статус «Тест пройден», 7 — «Тест пройден с замечаниями», а по 13 пунктам соответствие заданным критериям не было подтверждено. Результаты показали, какие возможности удалось проверить в рамках испытаний, а какие особенности и ограничения требуют отдельного внимания.

При оценке NGFW важно учитывать не только производительность, но и подтверждённые функциональные возможности, особенности их реализации и требования конкретной инфраструктуры. Совместно результаты нагрузочного и функционального тестирования дают более предметную основу для оценки применимости решения, но окончательное решение должно учитывать требования проекта и результаты анализа отдельных пунктов протокола.

Приложение 1

Тест пройден – 136

Тест пройден с замечаниями – 7

Тест не пройден – 13

№

п.п.Наименование проверкиВыполняемые действияКритерии выполнения требованийРезультат тестирования1. Общие технические требования1.1. Оборудование должно иметь сертификат соответствия ФСТЭКУбедиться в наличии сертификата ФСТЭК на СистемуСертификат №4877 ФСТЭК на Систему присутствуетТест пройден1.2. Архитектура Системы должна быть отказоустойчивой и обеспечивать непрерывность сервиса без потерь производительности.Убедиться в возможности создания в Системе кластера отказоустойчивости PT NGFW, кластера Серверов Управления PT-MNGTВ Системе присутствует возможность создания кластера отказоустойчивости PT NGFW и кластера Серверов Управления PT-MNGTТест пройден1.3. Все технические компоненты и модули Системы должны управляться централизованно из единой консоли.Убедиться в возможности Системы централизованного управления межсетевыми экранами.В Системе имеется возможность централизованного управления межсетевыми экранами присутствуетТест пройден1.4. Система должна обладать механизмами сохранения управляемости и доступности компонентов в условиях высокой нагрузки.Убедится в возможности Системы работоспособность механизмов сохранения управляемости и доступности компонентов в условиях высокой нагрузки.В условиях высокой нагрузки Система функционирует с сохранением управления и доступности всех компонентов.Тест пройден1.5. Система должна иметь возможность гибкой настройки прав доступа для разграничения доступа между различными ролями в Системе.Проверить возможность добавления ролей учетным записям. Проверить разграничение прав ролевой модели СистемыИмеется функция добавления учетных записей. Ролевая модель позволяет разграничивать полномочия согласно описанной в документации ролевой моделиТест пройден с замечаниями Примечание: На текущий момент предустановленные роли согласно описанной ролевой модели. Запланировано развитие функционала по ролям. Роль read-only доступна с версии 1.9 Развитие функциональности RBAC планируется в будущих релизах .1.6. Система должна позволять выводить уровень оптического сигнала на физических интерфейсах. Тест не пройден

Примечание. Наиболее достоверные данные обычно получаются с использованием специализированного диагностического оборудования для оптических линий связи. Или можно получать эти данные со стороны коммутатора.1.7. Архитектура Системы должна в максимальной степени учитывать существующую организационную и техническую структуру Компании.Проверить возможность работы Системы в режиме маршрутизатора.Система имеет возможность работы в режиме маршрутизатора.Тест пройден1.8. Система должна иметь возможности по встраиванию в текущую структуру сети без нарушения топологии и связности сетиПроверить возможность Системы в режиме виртуального соединения (vWire)Система имеет возможность работы в режиме виртуального соединения (vWire)Тест пройден1.9. Система должна иметь возможности по интеграции со сторонними системами: управления событиями ИБ, мониторинга и корреляции событий ИБ, предотвращения утечек конфиденциальной информации.Проверить возможность по интеграции Системы со сторонними системами обеспечения безопасности по протоколу syslogВ Системе реализована возможность интеграции со сторонними системами обеспечения безопасности по протоколу syslogТест пройден Примечание: Разработкой PT NGFW не установлено ограничение на число Syslog серверов, на которые могут отправляться события. 2. Требования к функциям межсетевого экранирования2.1. Система должна иметь возможность гибкой настройки фильтрации трафика на разных уровнях модели OSI, включая уровень приложений.Проверить возможность создания правил фильтрации трафика, на разных уровнях модели OSI, включая уровень приложенийСистема поддерживает создание правил безопасности на различных уровнях модели OSI, включая уровень приложенийТест пройден2.2. Система должна иметь возможность использования идентификации пользователей из службы каталогов AD для создания персональных или групповых правил фильтрации на основе объектов AD с авторизацией их по TACACS.Проверить возможность системы использования пользователей из службы каталогов AD для правил фильтрацииСистема имеет возможность использования пользователей из службы каталогов AD для правил фильтрацииТест пройден

Примечание. Поддержка TACACS для авторизации администраторов планируется в будущих релизах. RADIUS заявлен в версии 1.11 (реализовано LDAPs)2.3. Система должна поддерживать фильтрацию трафика по не менее, чем 150 предустановленным сервисам/протоколам.Проверить возможность создания сервисов/протоколов для фильтрации трафикаСистема поддерживает создание сервисов/протоколов для фильтрации трафикаТест пройден Примечание. Начиная с версии 1.7.1 предустановленные сервисы и протоколы в количестве 113шт2.4. Система должна иметь возможность задания ограничений функционирования правил доступа по времени суток и периоду действия.Проверить возможность создания правил с периодом или сроком действияСистема имеет функцию установки периода работы правил безопасностиТест пройден2.5. Система должна обеспечивать:

- функции трансляции адресов (NAT)

- виртуальных частных сетей (VPN)

- пакетной фильтрации трафика.Проверить возможность создания правил с функцией трансляции адресов (NAT), пакетной фильтрации трафика, а также организации VPN-соединений типа Site-to-Site.Система имеет возможность трансляции адресов (NAT), пакетной фильтрации трафика и поддерживает создание VPN-соединений типа Site-to-Site.Тест пройден2.6. Система должна иметь счетчик срабатывания правил фильтрации трафика в консоли управления.Проверить возможность отображения срабатывания по политикам информационной безопасностиСистема ведет учет количества срабатываний по политикам информационной безопасностиТест пройден3. Требования к функциям обнаружения и предотвращения вторжений3.1. Система должна иметь возможность работы как в режиме автоматического предотвращения сетевых атак (IPS), так и в режиме обнаружения сетевых атак (IDS).Проверить возможность работы Системы как в режиме автоматического предотвращения сетевых атак (IPS), так и в режиме обнаружения сетевых атак (IDS)Система поддерживает работу как в режиме автоматического предотвращения сетевых атак (IPS), так и в режиме обнаружения сетевых атак (IDS)Тест пройден3.2. Система должна выявлять сетевые атаки как сигнатурным методом, так и на основе аномалий в сетевом трафике.Проверить возможность Системы выявлять сетевые атаки как сигнатурным методом, так и на основе аномалий, например, блокировкой HTTP Malformed трафикаСистема имеет возможность выявлять сетевые атаки как сигнатурным, так и на основе аномалий, что было показано на примере блокировки HTTP Malformed трафикаТест пройден3.3. Система должна обеспечивать обновление сигнатур для актуальных типов угроз не реже 1 раза в день. Тест пройден

- Устройств

- Операционных систем

- Приложений

- СервисовПроверить возможность формирования белых списков объектов.Система поддерживает создание белых списков объектов.Тест пройден

Примечание. Можно создавать кастомные профили сигнатур или добавлять определённые сигнатуры в исключение. Возможно производить фильтрацию, по ключевым словам, в описании сигнатур, номерам CVE и проч. Это позволяет быстро отфильтровать и одним кликом выделить соответствующие сигнатуры (например, можно выделить сигнатуры только Windows, SQL, Linux, iOS, Microsoft, Apple и т.д.) и добавить их при создании кастомного профиля или наоборот, добавить отфильтрованный блок сигнатур в исключения.3.6. Система должна обеспечивать возможность гибкой настройки правил обнаружения/предотвращения сетевых атак и правил исключения (правила срабатывания, действие при срабатывании, уведомления, дамп трафика, настройка исключений на основе источника, назначения, сервиса и их комбинации).Проверить возможность гибкой настройки правил обнаружения и предотвращения сетевых атак, захвата трафикаСистема позволяет производить гибкую настройку правил обнаружения и предотвращения сетевых атак, производить захват трафикаТест пройден

Примечание. Локальный захват трафика с DPDK интерфейсов реализован с версии 1.10.03.7. Система должна иметь возможность создания различных профилей защиты для применения к различным элементам системы в рамках единой консоли управления.Проверить возможность создания в Системе профилей защитыВ Системе реализована возможность создания профилей защиты для определенного трафикаТест пройден3.8. Система должна поддерживать автоматическую регулярную загрузку черных и белых списков IP-адресов, URL-адресов и DNS-имен как из источников, определяемых производителем, так и из заданных пользователем источников.Проверить возможность загрузки списков с помощью API.В Системе реализована возможность загрузки списков с помощью API.Тест пройден

3.9. Система должна поддерживать настройку сетевых исключений на основе источника, адресата, службы или комбинации из этих параметров.Проверить возможность настройки сетевых исключений на основе источника, адресата, службы или комбинации из этих параметров.В Системе реализована возможность настройки сетевых исключений на основе источника, адресата, службы или комбинации из этих параметров.Тест пройден3.10. Система должна обеспечивать анализ трафика и обнаружение сетевых атак на разных уровнях модели OSI, включая уровень приложений, с учетом контекста (приложений, пользователей, устройств, операционных систем, уязвимостей, репутации).Проверить возможность создания правил обнаружения сетевых атак на разных уровнях модели OSI.Система поддерживает создание правил обнаружения сетевых атак на разных уровнях модели OSI.Тест пройден

Примечание. IPS профиль применяется к выделенному трафику. Выделение трафика происходит стандартными средствами фильтрации и можно указать помимо зон, адресов источников/назначения пользователя или группу пользователей, приложение. Распознавание ОС, уязвимостей и репутации хоста не входит в перечень основных функций NGFW3.11. Система должна поддерживать обработку трафика дополнительным механизмом проверки по хешам вредоносных файловПроверить возможность обработки трафика механизмом защиты от вредоносных файлов по хешам.Система поддерживает механизм защиты от вредоносных файлов по хешам.Тест пройден3.12. Система должна поддерживать антиспуфинг на сетевых интерфейсахПроверить возможность системы поддержки функции антиспуфинг.Система поддерживает функцию антиспуфинг.Тест пройден

Примечание. Функционал антиспуфинга всегда включен по умолчанию, отключение не предусмотрено. На текущий момент события не логируются.3.13. Система должна поддерживать использование паттернов сканирования для обнаружения аномалий трафика и защиты от flood атакПроверить наличие IPS сигнатур для обнаружения аномалий трафика и защиты от DDOS атакВ Системе присутствуют IPS сигнатуры для обнаружения аномалий трафика и защиты от DDOS атакТест пройден

Примечание. Расширение функционала AntiDDos/Antiscan и др. типов flood атак планируется в будущих релизах4. Требования к функциям фильтрации веб-трафика4.1. Система должна обеспечивать выявление, блокирование или ограничение доступа пользователей к определенным веб-ресурсам: по предопределенным категориям, по заданным спискам URL, веб-приложениям.Проверить возможность Системы фильтрации трафика по предопределенным URL категориямВ Системе реализована возможность фильтрации трафика по предопределенным URL категориямТест пройден4.2. Система должна иметь предустановленные категории URL в правилах Web/FTP фильтрацииПроверить Систему на наличие предустановленных категорий URL Система имеет предустановленные категории URL.Тест пройден4.3. Система должна иметь возможность создания собственных категорий, списков URL и веб приложений, в том числе с использованием регулярных выражений, для применения их в правилах доступа.Проверить возможность Системы создания пользовательских списков URL.Система имеет функцию добавления пользовательских списков URL.Тест пройден

Примечание. Есть поддержка собственных категорий. Написание wildcard URL заявлено в версии 1.114.4. Система должна обеспечивать прозрачное проксирование веб-трафика по протоколам HTTP, HTTPS.Проверить возможность Системы расшифровки трафика с использованием прямого прозрачного TLS-проксиСистема реализует расшифрование трафика с использованием прямого прозрачного TLS-прокси.Тест пройден4.5. Система должна обеспечивать прозрачную аутентификацию пользователей с использованием службы каталогов AD.Проверить возможность Системы по обеспечению синхронизации межсетевого экрана с AD.Система имеет возможность синхронизации межсетевого экрана с ADТест пройден4.6. Система должна обеспечивать периодическое обновление контента по категориям веб-ресурсов не реже 1 раза в день.Проверить возможность обновления контентаСистема поддерживает обновление контентаТест пройден

Примечание. Доступно ручное обновление. Автоматизация обновлений возможна при помощи скрипта и API. Активация новых сигнатур не требует перезагрузки сервиса NGFW с релиза 1.10.0, который включает в себя функцию централизованного обновления баз экспертизы (сигнатур, приложений, URL категорий и проч.) файлом через СУ.4.7. Система должна поддерживать технологию инспектирования SSL/TLS трафика для применения правил фильтрации к зашифрованному трафику пользователей.Проверить возможность Системы расшифровки HTTPS трафикаСистема имеет возможность расшифровки HTTPS трафикаТест пройден4.8. Система должна иметь возможность использования идентификации пользователей из службы каталогов AD для создания персональных или групповых правил фильтрации веб-трафика на основе объектов AD.Проверить возможность Система использования идентификации пользователей из службы каталогов ADСистема имеет возможность использования идентификации пользователей из службы каталогов ADТест пройден4.9. Система должна иметь возможность настройки гостевого доступа к сети Интернет для пользователей, не имеющих учетной записи в службе каталогов AD, с применением отдельного набора правил фильтрации веб-трафика.Проверить возможность Системы перенаправлять неизвестных пользователей на портал авторизации (Captive portal)Система имеет возможность перенаправления неизвестных пользователей на портал авторизации (Captive portal)Тест пройден4.10. Система должна обеспечивать возможность гибкой настройки правил фильтрации веб-трафика (независимые от предопределенных категорий черные и белые списки URL, контроль трафика веб-приложений).Проверить возможность Системы гибкой настройки правил фильтрации веб-трафика.Система имеет возможность гибкой настройки правил фильтрации веб-трафика.Тест пройден4.11. Система должна иметь возможность создания кастомизированной страницы для уведомления пользователей о блокировке веб-ресурса Тест не пройден4.12. Система должна поддерживать географическую принадлежность IP адресов отправителя и получателя в качестве критерия для пакетной фильтрацииУбедиться в возможности Системы поддерживать географическую принадлежность IP адресовСистема поддерживает географическую принадлежность IP адресовТест пройден4.13. Система должна категорировать URL-страницы и WEB-приложения по факторам рискаПроверить возможность Системы категорировать URL-страницы и WEB-приложения к категории, повышенного риска информационной безопасности безопасностиСистема имеет возможность категорировать URL-страницы и WEB-приложения к категории, повышенного риска информационной безопасности безопасностиТест пройден

Примечания. Системой не предусмотрены значения риска

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

Примечания. На текущий момент возможен выбор только самих приложений. Группирование приложений по категориям планируется в будущих релизах5.2. Система должна реализовывать функционал блокировки получения пользователями в электронных письмах вложений с расширениями: ADE, ADP, APK, APPX, APPXBUNDLE, BAT, CAB, CHM, CMD, COM, CPL, DLL, DMG, EX, EX_, EXE, HTA, INS, ISP, ISO, JAR, JS, JSE, LIB, LNK, MDE, MSK, MSI, MSIX, MSIXBUNDLE, MSP, MST, NSH, PIF, PS1, SCR, SCT, SHB, SYS, VB, VBE, VBS, VHD, VXD, WSC, WSF, WSH Тест не пройден.

Примечание. Функционал ICAP для проверки HTTP-трафика доступен с версии 1.8. Возможность интеграции предоставляется PT NGFW. Сам функционал реализуется отдельной системой PT Sandbox5.3. Система должна поддерживать классификацию приложений по уровню риска и по уровню соответствия заданным требованиям. Тест не пройден

Примечание. Доработка в части классификации приложений планируется в будущих релизах.5.4. Система должна обеспечивать идентификацию инкапсулированного трафика с возможностью определения протокола инкапсулированного трафика (в том числе трафика в туннелях GRE, AH, IPSec) для дальнейшей обработки. Тест не пройден

5.5. Система должна иметь возможность использования идентификации пользователей из службы каталогов AD для создания персональных или групповых правил контентной фильтрации на основе объектов AD.Проверить возможность Системы использования учетных записей службы каталогов AD.Система имеет возможность использования учетных записей службы каталогов AD.Тест пройден5.6. Система должна поддерживать закрепление статических IP адресов для объектов типа доменное имя (FQDN)Проверить возможность Системы использования объектов типа FQDN.Система поддерживает объекты типа FQDNТест пройден6. Требования к функциям защиты от вредоносного кода6.1. Система должна обеспечивать анализ потоков данных на наличие активности вредоносных программ в сетевом трафике (вирусы, трояны, черви, бекдоры, загрузчики).Проверить возможность Системы обеспечивать анализ потоков данных на наличие активности вредоносных программ в сетевом трафикеСистема обеспечивает анализ потоков данных на наличие активности вредоносных программ.Тест пройден6.2. Система должна выявлять вредоносный код как сигнатурным методом, так и на основе аномалий в сетевом трафике.Проверить возможность Системы выявлять сетевые атаки как сигнатурным методом, так и на основе аномалий, например, блокировкой HTTP Malformed трафикаСистема имеет возможность выявлять сетевые атаки как сигнатурным, так и на основе аномалий, что было показано на примере блокировки HTTP Malformed трафикаТест пройден6.3. Система должна иметь возможность использования различных антивирусных движков для сигнатурного метода выявления вредоносного кода.Проверить наличие в Системы модуля антивируса для сигнатурного метода выявления вредоносного кодаСистема имеет модуль антивирусаТест пройден

Примечание. Применяется встроенный модуль Антивируса. Анализ различными методами антивируса может быть реализован отдельной системой PT Sandbox при интегации по ICAP (доступно с версии 1.8).6.4. Система должна обеспечивать автоматическое обновление сигнатур для актуальных образцов вредоносных программ не реже 1 раза в день.Проверить возможность обновления сигнатур вредоносных программ.Система поддерживает обновление сигнатур вредоносных программТест пройден

7. Требования к регистрации событий, отчетности, автоматическим уведомлениям7.1. Система должна обеспечивать видимость всех событий безопасности в единой консоли, с возможностью задания фильтров отображения по множественным параметрам и возможностью поиска свободным текстомУбедиться в возможности Системы видимости событий с помощью фильтров по множественным параметрам со свободным поискомСистема поддерживается поиск событий в журнале по указанным фильтрамТест пройден7.2. Система должна обеспечивать регистрацию событий и формирование отчетности на основе информации:

- Тип события;

- IP-адрес источника;

- IP-адрес назначения;

- Протокол взаимодействия;

- Порт источника;

- Порт назначения;

- Имя пользователя;

- Имя компьютера пользователя;

- Примененные политики и правила;

- Примененное действие Убедиться в возможности Системы регистрации событий с основной информацией.Система регистрирует события с основной информациейТест пройден

Примечание. Формирование отчета планируется в будущих релизах.

7.3. Система должна обладать возможностью ассоциации пользователя, имя машины и IP адреса в каждой записи событияУбедиться в возможности Системы наличия ассоциации пользователя, имя машины и IP адреса в каждой записи событияСистема имеет возможность ассоциации пользователя, имя машины и IP адреса в каждой записи событияТест пройден7.4. Система должна иметь возможности по формированию отчетов:

- Из предустановленных шаблонов (по пользователям, IP-адресам, объему трафика, категориям сайтов, заблокированным ресурсам, обнаруженным атакам, обнаруженной вредоносной активности и т.д.);

- На основе собственных настраиваемых отчетов с различной степенью детализации;

- Автоматически на основе заданного шаблона по расписанию;

- Содержащих графики и таблицы;

- С последующим экспортом данных отчета (в одном из общепринятых форматов – pdf, xlsx, xml и т.д.) Тест не пройден

Примечание. Формирование отчетов планируется в будущих релизах.

7.5. Система должна обеспечивать возможность автоматического уведомления администраторов/офицеров безопасности по электронной почте для заданных случаев срабатывания правил фильтрации/блокировок/обнаруженияУбедиться в возможности Системы отправки журналов в сторонние системы по syslog.Системы имеет возможность отправки всех журналов в сторонние системы по syslogТест пройден

Примечание. Уведомление администраторов реализуется сторонними системами7.6. Система должна обеспечивать возможность предоставить интегрированное решение для управления рисками и соответствия требованиям регуляторов и лучших практик (PCI-DSS,HiPPA,SOX...)Убедиться в возможности Системы присутствии API для интеграции с другими системамиВ Системе присутствует API для интеграции с другими системамиТест пройден7.7. Система должна обеспечивать автоматическое уведомления администраторов/офицеров безопасности по электронной почте для заданных случаев нарушения настроек, не соответствующих заданным стандартам или лучшим практикам. Равнозначно с тем, когда подобные события логируются или передаются в SIEMУбедиться в возможности Системы отправки журналов в сторонние системы по syslog.Системы имеет возможность отправки всех журналов в сторонние системы по syslogТест пройден

Примечание. Уведомление администраторов реализуется сторонними системами7.8. В системе должна быть реализована защита от возможного изменения/модификации журналов событийУбедиться в невозможности Системы вносить изменения/модификации записей журнала событий через доступный пользователю графический интерфейс СУ (системы управления)Система не имеет возможности изменения записей событий через доступный пользователю графический интерфейс СУ (системы управления)Тест пройден7.9. События изменения параметров журналирования должны регистрироватьсяУбедиться, что при изменении параметров логирования в правиле безопасности на вкладке логирования (Аудит) появляется соответствующее лог сообщениеСистема имеет возможность журналирования изменений параметров логирования правил безопасностиТест пройден7.10. Не допускается изменение/модификация ранее зарегистрированных в журнале событий. В журнале событий должна фиксироваться финальная версия событий. В случае, когда в журнале нужно отразить информацию о завершении ранее выполненного действия, должно фиксироваться отдельное событиеУбедиться в невозможности Системы изменения/модификации записей журнала событий через доступный пользователю графический интерфейс СУ (системы управления)Система не имеет возможности изменения записей событий через доступный пользователю графический интерфейс СУ (системы управления)Тест пройден7.11. Система должна обеспечивать журналирование событий всех функциональных модулей в едином формате.Убедиться в возможности Системы обеспечения журналирования всех событий в едином представлении GUI системы управленияСистема имеет возможность журналирования всех событий в едином представлении GUI системы управленияТест пройден7.12. Система должна иметь функционал расшифровки трафика и передачи расшифрованной копии трафика в DLP Заказчика по протоколу ICAPУбедиться в возможности Системы отправки расшифрованного трафика (Decryption Mirroring)Система имеет возможность отправки расшифрованного трафика (Decryption Mirroring)Тест пройден Примечание. Зеркалирование всего расшифрованного трафика выполняется с помощью Decryption Mirroring. Передача по ICAP доступно с версии 1.8.7.13. Система должна иметь возможность интеграции с решением SIEM от Positive Technology и KUMA от KasperskyУбедиться в возможности Системы интеграции с существующими SIEM системами через отправку логов на внешние системыСистема имеет возможность интеграции с SIEM системами посредством отправки логов на внешние системыТест пройден7.14. Система должна иметь возможность интеграции по протоколам syslog, win event log, win wmi log, netflow, snmp trap, odbc, ssh file logУбедиться в возможности Системы интеграции по протоколам syslog, ssh, snmp trapСистема имеет возможность интеграции по протоколам syslog, ssh, snmp trapТест пройден

Примечание. SNMP реализован с версии 1.10.0. Остальные на текущий момент не запланированы к реализации8. Требования к функциям распознавания и предотвращения угроз8.1. Сегмент Системы в части Threat Detection & Prevention должен поддерживать распознавание веб-приложений и виджетов социальных сетейУбедиться, что в Системе присутствует возможность распознавания приложенийСистема поддерживает распознавание приложенийТест пройден Примечание.Поддерживается более 3500 приложений. Если необходимо добавление приложений, то это возможно через запрос в техподдержку. Отдельно виджеты социальных сетей не выделяются.8.2. Сегмент Системы в части Threat Detection & Prevention должен поддерживать категоризацию URL адресовУбедиться, что в Система поддерживает категорирование URLСистема поддерживает категорирование URLТест пройден Примечание. Порядка 190 миллионов URL адресов.8.3. Система должна иметь возможность интеграции с почтовым релеем, либо выступать в такой роли для обеспечения установки в разрыв почтового трафика Тест не пройден

Примечание. Реализуется отдельной системой PT Sandbox9. Требования к функционалу маршрутизации9.1. Система должна на аппаратном уровне поддерживать протоколы маршрутизации BGP, OSPFУбедиться в возможности Системы поддержки динамической маршрутизации на основе протоколов OSPF, BGPСистема поддерживает динамическую маршрутизациюТест пройден9.2. Система должна на аппаратном уровне поддерживать агрегацию портов (LAG)Убедиться в возможности Системы поддержки агрегации портовСистема поддерживает агрегацию портовТест пройден9.3. Система должна на аппаратном уровне поддерживать количество правил ACL исходя из прогноза их роста за время эксплуатации системыУбедиться в возможности Системы поддержки большого кол-ва правилСистема поддерживает большое кол-во правилТест пройден10. Требования к системе управления10.1. Наличие возможности развертывания модуля управления как на шлюзе информационной безопасности, так и вынесение его на отдельно стоящий сервер.Проверить возможность вынесения модуля управления на отдельно стоящий сервер.Система поддерживает реализацию модуля управления на отдельно стоящем сервереТест пройден

Примечание. Модуль управления не может быть развернут на шлюзе информационной безопасности.10.2. Модуль управления должен поддерживать разделение ролей между администраторами системы. Например, роль управления политикой брандмауэра или роль просмотра журнала логов.Проверить возможность добавления ролей учетным записям.Имеется функция добавления учетных записей.Тест пройден

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

Примечание. Доработка многопользовательского интерфейса:

1) блокирование одновременного внесения изменений администраторами – планируется в будущих релизах

2) одновременная работа с последующим решением конфликтов в конфигурациях – планируется в будущих релизах10.5. Модуль должен иметь возможность использования внешних центров сертификатов, которые поддерживают PKCS#12, CAPI или другие доверенные стандарты.Проверить возможность загрузки доверенного сертификатаСистема имеет возможность загрузки доверенного сертификатаТест пройден10.6. Модуль управления должен обладать способностью подсчета количества срабатывания по политикам информационной безопасности.Проверить возможность отображения срабатывания по политикам информационной безопасностиСистема ведет учет количества срабатываний по политикам информационной безопасностиТест пройден10.7. Модуль управления должен содержать опцию поиска, чтобы можно было легко запросить какой сетевой объект содержит конкретный IP и т.д.Проверить возможность запроса при добавлении правила фильтрации, какой объект содержит конкретный IP адрес и иные свойстваСистема обладает опцией поиска свойств конкретного объекта при добавлении правил фильтрацииТест пройден10.8. Модуль управления должен обладать возможностью группировки политик, используя теги и заголовки для удобства работы администраторов системы.Проверить возможность группировки политик по Pre и Post правиламВ Системе реализована возможность группировки политик с использованием Pre и Post правил.Тест пройден с замечаниями

Примечание. Планируется доработка функционала группировка по папкам. Функционал прорабатывается. Представлен концепт решения https://t.me/PTNGFW/5587 Так же прорабатывается добавление тегов.10.9. Модуль управления должен обеспечивать опцию для сохранения всей политики или определенной части политики.Проверить возможность создания резервных копий, восстановление и перенос конфигурации Системы управления.Системы управления обладает возможностью создания резервных копий, восстановление и возможностями по переносу конфигурацииТест пройден Примечание. В текущем виде полного бэкапа СУ требование выполняется. Есть возможность ручного экспорта и импорта бэкапа, а также автоматическое создание бэкапов и отправка на удаленный сервер10.10. Модуль управления должен обладать механизмом верификации политики безопасности до ее внедрения.Проверить в Системе наличие механизма верификации политики безопасности до ее внедрения.Система обладает механизмом верификации политики безопасности до ее внедрения.Тест пройден10.11. Модуль управления должен обладать механизмом контроля изменений политики безопасности.Проверить наличие механизма логирования действий администратораСистема обладает механизмом логирования действий администратораТест пройден10.12. Модуль управления должен обладать возможностью синхронизации политик на различных устройствах, а также обновления политик путем их синхронизации и распространения с одного управляемого устройства на остальные.Проверить возможность синхронизации политик на различных устройствах.Система обладает возможностью синхронизации политик на различных устройствах.Тест пройден Примечание. Текущая реализация позволяет в СУ привязать несколько NGFW к одной группе устройств они получают единый набор политик. Требование закрывается указанным способом.10.13. Модуль управления должен включать возможность централизованного распространения и применения новых версий программного обеспечения для шлюзов.Проверить возможность Системы централизованно распространять и применять новые версии программного обеспечения для шлюзов.Система обладает возможностью централизованно распространять и применять новые версии программного обеспечения для шлюзов.Тест не пройден

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

Примечание. На данный момент нет проверки лицензионных ограничений.10.15. Модуль управления должен содержать подробную историю для каждого правила, включая тех пользователей что вносили изменения в них.Проверить наличие функции истории изменения политик безопасностиСистема обладает функцией ведения подробного журнала аудита со сведениями о каждом правиле.Тест пройден с замечаниями.

Примечание. Требуется доработка функционала в "человекочитаемый" вид (имена вместо идентификаторов, при удалении правила указывать не только ID, но и все правило). Замечания переданы в разработку10.16. Модуль должен иметь API, либо иные инструменты для массовой выгрузки/загрузки объектов и правил, Возможность автоматической миграции существующих правил на новый ngfwПроверить возможность массовой выгрузки/загрузки объектов и правил с помощью API.Система имеет возможность массовой выгрузки/загрузки объектов и правил.Тест пройден10.17. Модуль должен содержать встроенный центр генерации сертификатов (х. 509) позволяющий выдавать сертификаты пользователям и шлюзам информационной безопасности при построении VPN-тоннелей. Тест не пройден

10.18. Модуль управления должен иметь возможности для мультидоменного управления и поддержки концепции глобальной политики безопасности через домены.Проверить возможность для управления и поддержки концепции глобальной политики безопасности путем создания «Виртуальных контекстов» и «Групп устройств».Система имеет функцию создания «Виртуальных контекстов» и «Групп устройств».Тест пройден с замечаниями

Примечание.

Система не поддерживает мультидоменное управление10.19. Система управления должна быть развернута на виртуальной инфраструктуре Заказчика (VMWare, VMWare VIO).Проверить возможность Систему установки на виртуальной инфраструктуреСистема управления может быть развернута на виртуальной инфраструктуре (VMware, VMware VIO).Тест пройден10.20. Система управления должна быть развернута на поддерживаемой Заказчиком гостевой операционной системе (не лицензируемая ОС, запросить актуальный перечень поддерживаемых ОС. Предоставить перечень поддерживаемых ОС. ОС должна быть включена в Государственный реестр сертифицированных средств защиты информации: https://reestr.fstec.ru/reg3Проверить возможность развертывания системы управления на поддерживаемой операционной системе, а также предоставить перечень поддерживаемых операционных системСистема может быть развернута под управлением на ОС Astra Linux Special Edition. Указанная операционная система включена в Государственный реестр сертифицированных средств защиты информации.Тест пройден10.21. Поставщик обеспечивает поставку и поддержку полного объема программного обеспечения (включая лицензии, ОС и third-party software component) входящего в состав системы управления в течении срока действия договора. В случае наступления EoS для ПО, поставщик предоставляет функциональную альтернативу сохраняя прежнюю архитектуру решения без дополнительных затрат со стороны заказчика. Предоставить перечень и версии всего ПО входящего в решение. Данное ПО должно соответствовать требованиям законодательства РФ и включено в реестр российского программного обеспечения и(или) реестр евразийского программного обеспечения: https://reestr.digital.gov.ru/ https://eac-reestr.digital.gov.ru/Предоставить перечень и версии всего программного обеспечения, входящего в состав решения, а также подтвердить его включение в реестр российского программного обеспечения и (или) реестр евразийского программного обеспечения.Предоставлен перечень и версии ПО. Подтверждена поддержка поставщиком в течение срока действия договора, наличие процедуры замены компонентов при EoS, а также соответствие ПО требованиям законодательства РФ и его наличие в соответствующих реестрахТест пройден10.22. Система управления (NMS) должна соответствовать требованиям предъявляемым к данному типу ПАК в соответствии с законодательством РФ, включая, но не ограничиваясь, требованиям указа Президента РФ № 166 от 30.03.2022 "О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации", указа Президента №250 от 01.05.2022 "О дополнительных мерах по обеспечению информационной безопасности Российской Федерации", Постановление Правительства РФ от 14.11.2023 N 1912 "О порядке перехода субъектов критической информационной инфраструктуры Российской Федерации на преимущественное применение доверенных программно-аппаратных комплексов на принадлежащих им значимых объектах критической информационной инфраструктуры Российской Федерации". АО и ПО должно содержаться в соответствующих реестрах: https://gisp.gov.ru/pp719v2/pub/prod/rep/ https://reestr.digital.gov.ru/ https://eac-reestr.digital.gov.ru/ https://reestr.fstec.ru/reg3Проверить соответствие системы управления (NMS) требованиям законодательства Российской Федерации, предъявляемым к программно-аппаратным комплексам данного типа, включая требования Указа Президента РФ № 166 от 30.03.2022, Указа Президента РФ № 250 от 01.05.2022 и Постановления Правительства РФ № 1912 от 14.11.2023. Проверить наличие аппаратных и программных компонентов решения в соответствующих государственных реестрах.Предоставлены документы, подтверждающие соответствие системы управления (NMS) требованиям законодательства Российской Федерации. Подтверждено наличие программных и аппаратных компонентов решения в соответствующих государственных реестрах.Тест пройден10.23. Система управления должна иметь георезерв в режимах active-active и/или active-standby. Основная и резервная cистемы управления должны находиться в разных IP-сетях (территориально разделенные ЦОД) без возможности организации общего для них виртуального IP.Проверить возможность организации резервирования системы управления Active-Standby. Проверить возможность размещения основной и резервной систем управления в различных IP-сетях без использования общего виртуального IP-адреса.Подтверждена возможность организации резервирования системы управления в режиме Active-Standby. Основная и резервная системы управления могут быть развернуты в различных IP-сетяхТест пройден Примечание. Реализовано с версии 1.9.010.24. Процесс перехода на резерв должен быть контролируемым со стороны оператора\администратора и время перехода до готовности всего функционала резервной системы должно быть не более 15 минут.Проверить возможность контролируемого перевода системы управления на резервную площадку по инициативе оператора (администратора), а также проверить время перехода до полной готовности функционала резервной системыПодтверждена возможность выполнения контролируемого переключения системы управления на резервную площадку по инициативе оператора (администратора).Тест пройден Примечание. Реализовано с версии 1.9.010.25. Система управления должна регулярно выполнять резервное копирование конфигурации, компонентов и целиком сервиса без перерыва сервиса и без потери производительности сервиса во время исполнения заданий резервного копирования. Результат выполнения должен отслеживаться self-мониторингом через интерфейсы системы и информировать по результату выполнения операции резервного копирования по NBI.Проверить возможность регулярного выполнения резервного копирования конфигурации, отдельных компонентов и системы управления в целом без прерывания работы сервиса и без снижения его производительности.Подтверждена возможность выполнения резервного копирования конфигурацииТест пройден

Примечание. Все настройки NGFW хранятся на Системе управления (СУ). СУ не стоит на пути прохождения трафика и её полное выключение не влияет на работу МСЭ. Запуск резервного копирования в ручном режиме через GUI. Регулярные бэкапы можно организовать при помощи API и скрипта. Результаты успешного или неуспешного Backup видны в GUI или могут быть получены через API. Планируется добавление расписаний бэкапов в GUI в будущих релизах10.26. Система управления должна поддерживать возможность восстановления конфигурации, компонентов системы и целиком сервиса из резервной копии не более чем за 4 часа (включая запуск сервисов).Проверить возможность восстановления конфигурации, отдельных компонентов системы управления и системы в целом из резервной копии.Подтверждена возможность восстановления конфигурации из резервной копииТест пройден10.27. Основная и резервная система управления должны иметь основной функционал FCAPS (включая NBI интерфейсы) с возможностью логирования. Перечислить поддерживаемый функционал и методы реализации.Проверить наличие в основной и резервной системе управления функционала FCAPSПодтверждена поддержка NBI-интерфейсов для интеграции с внешними системами и возможность ведения журналов событийТест пройден Примечание. Отправка событий реализована по протоколу Syslog. SNMP реализован с версии 1.10.010.28. Система управления (NMS) должна поддерживать интеграцию с Microsoft Active Directory по защищенному протоклу, поддерживать имена и пароли длинной не менее 12 символов, содержащие буквы верхнего и нижнего регистра(a-z,A-Z), специальные символы и цифры.Проверить возможность интеграции системы управления (NMS) с Microsoft Active Directory по защищенному протоколу. Проверить поддержку политик аутентификацииПодтверждена поддержка централизованной аутентификации пользователей через Active Directory. Система поддерживает настройку политик сложности паролей, включая минимальную длину не менее 12 символовТест пройден10.29. В случае, если отсутствует поддержка Web GUI (по протоколу HTTPS), необходима поддержка запуска клиентского ПО из многопользовательского Citrix-окружения и доставки ПО через Microsoft APPv.Проверить наличие Web GUI с доступом по протоколу HTTPSПодтверждено наличие Web GUI с доступом по протоколу HTTPSТест пройден10.30. Система управления должна иметь self-мониторинг состояния компонент системы, использования виртуальных ресурсов, обеспечивающих работу системы управления (дисковое пространство, CPU, оперативная память, т.д.) с возможностью настройки порогов trashhold alarm и передачей их по NBI.Проверить наличие в системе управления функций self-мониторинга состояния компонентов системы и используемых виртуальных ресурсовПодтверждено наличие в системе управления функций self-мониторинга состояния компонентов системы и используемых виртуальных ресурсов, включая загрузку процессора, использование оперативной памяти, дискового пространства и иных системных ресурсовТест пройден

10.31. Добавление и удаление NE из системы управления должны быть реализованы в интерфейсе системы. Функционал должен быть доступен для добавления в ролевой модели доступа (РМД). Действия должны выполняться без перерыва сервиса (рестарта сервисов).Проверить возможность добавления и удаления сетевых элементов (NE) через интерфейс системы управления.Подтверждена возможность добавления и удаления сетевых элементов (NE) через интерфейс системы управления.Тест пройден Примечание. На текущий момент предустановленные роли согласно описанной ролевой модели. Запланировано развитие функционала по ролям. Роль read-only доступна с версии 1.9 Гибкая ролевая модель планируется в будущих релизах.10.32. Возможность отслеживания состояния NE (connect/disconnect) и формирование аварийных сообщений и отправки их через FM во внешние системы. Наличие механизма проверки e2e сервиса: формирование Test Alarm с заданной периодичностью на NE и отправки их через FM во внешние системы.Проверить возможность мониторинга состояния сетевых элементовПодтверждена возможность мониторинга состояния сетевых элементовТест пройден10.33. Система управления должна обеспечивать наличие детальных логов всех операций, выполняемых пользователями через систему управления. Трансляции логов в верхнеуровневые системы (посредством SFTP, Syslog и т.д.).Проверить наличие детального журналирования действий пользователей в системе управления, включая регистрацию выполняемых операций, времени выполнения и учетных записей пользователей. Проверить возможность передачи журналов событий во внешние системы посредством стандартных протоколов и механизмов интеграции (Syslog, SFTP и др.).Подтверждено наличие детального журналирования действий пользователей в системе управления. В журналах регистрируются сведения о выполняемых операциях, времени их выполнения, инициировавшем пользователе и результате выполнения действия. Подтверждена возможность экспорта и передачи журналов событий во внешние системы мониторингаТест пройден10.34. В Системе управления должна быть обеспечена поддержка управления доступом для учётных данных в системе на основе ролевой модели доступовПроверить наличие в системе управления механизма управления доступом на основе ролевой моделиПодтверждено наличие в системе управления механизма управления доступом на основе ролевой моделиТест пройден.

Примечание. На текущий момент предустановленные роли согласно описанной ролевой модели. Запланировано развитие функционала по ролям. Роль read-only доступна с версии 1.9 Гибкая ролевая модель планируется в будущих релизах.10.35. Система управления должна удовлетворять требованиям ФСТЭК России от 25 декабря 2017 года № 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»Убедиться в наличии сертификата ФСТЭК на СистемуСертификат №4877 ФСТЭК на Систему присутствуетТест пройден10.36. Система управления должна иметь механизмы защиты информации. Средства должны быть включены в реестр: https://reestr.fstec.ru/reg3Проверить, что используемые средства защиты информации включены в реестр сертифицированных средств защиты информации ФСТЭК России.Сертификат №4877 ФСТЭК на Систему присутствуетТест пройден10.37. Поставщик обеспечивает выпуск актуальных патчей безопасности для решения системы управления не реже чем раз в кварталПроверить наличие у поставщика процесса выпуска актуальных патчей безопасности для системы управления с периодичностью не реже одного раза в квартал.Подтверждено, что поставщик обеспечивает выпуск актуальных патчей безопасности для системы управления на регулярной основе с периодичностью не реже одного раза в квартал. Обновления безопасности предоставляются в рамках жизненного цикла продукта и включают исправления выявленных уязвимостей и повышение уровня защищенности системы.Тест пройден10.38. Система управления должна работать с SSL-сертификатами, выпущенными центром сертификации Заказчика.Проверить возможность работы системы управления с SSL-сертификатами, выпущенными центром сертификацииПодтверждена возможность использования системой управления SSL-сертификатов, выпущенных центром сертификацииТест пройден11. Общие нефункциональные требования11.1. Система должна быть единой и централизованнойПроверить возможность централизованного управления межсетевыми экранами.Возможность централизованного управления межсетевыми экранами присутствуетТест пройден11.2. Система должна позволять вводить в строй новые версии Системы (с расширенной функциональностью) без необходимости одновременного изменения кода систем-потребителей интерфейсов

Убедиться, что в Системе реализована возможность обновления версий аппаратного ПО до актуальных версийРеализована возможность обновления ПОТест пройден

Примечание. Сейчас обновление ПО может быть произведено локально на NGFW. Централизованное обновление файлом через СУ планируется в будущих релизах.12. Требования к развертыванию и средам12.1. В случае поставки решения на основе виртуальной инфраструктуры оно должно включать средства автоматического развертывания и изменения конфигурации СистемыУбедиться в возможности Системы автоматического развертывания и изменения конфигурации системыСистема имеет возможность автоматического развертывания Тест пройден12.2. Масштабирование числа, мощности и функциональных возможностей сред тестирования не должно увеличивать затраты Заказчика на лицензии, поддержку и т.п.Проверить, что масштабирование числа, производительности и функциональных возможностей сред тестирования не приводит к увеличению затратПодтверждено, что масштабирование числа, производительности и функциональных возможностей сред тестирования осуществляется в рамках существующей лицензионной модели Тест пройден12.3. Исполнитель должен предоставить автоматические или автоматизированные механизмы переноса обновлений программных модулей и настроек Системы

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

Примечание. При обновлении ПО сохраняется текущая конфигурация13. Общие требования по информационной безопасности13.1. Для доступа в Систему, пользователь должен пройти процедуру идентификации и аутентификации, которая должна выполняться средствами централизованной Системы Заказчика (Active Directory), либо аналогПроверить, что доступ к Системе осуществляется после прохождения процедуры идентификации и аутентификации пользователей с использованием централизованной системыПодтверждено, что доступ к системе предоставляется только после прохождения процедуры идентификации и аутентификации пользователей. Поддерживается интеграция с централизованной системой управления учетными записями (Microsoft Active Directory)Тест пройден

13.2. Каждому пользователю должна соответствовать индивидуальная учетная запись в СистемеПроверить возможность Системы создания учетных записей.Система имеет возможность создания учетных записейТест пройден13.3. Наличие в Системе стандартных (создаваемых по умолчанию) и технологических учетных записей пользователей должно быть обосновано и описано в эксплуатационной документации на СистемуПроверить наличие эксплуатационной документации к СистемеЭксплуатационная документация к Системе присутствуетТест пройден13.4. Продолжительность непрерывной сессии пользователя должна быть настраиваемойОставить неактивную сессию на времяРеализовано прерывание сессии пользователя в случае простояТест пройден с замечаниями

Примечание. Сейчас уже есть Logout timout неактивности администратора - - задан статично и не меняется. Cоставляет 60 минут по умолчанию.13.5. Механизм разграничения прав доступа должен быть реализован на основе ролейПроверить возможность добавления ролей учетным записям.Имеется функция добавления учетных записей. Тест пройден13.6. Авторизация пользователей должна выполняться с использованием службы Active Directory. Определение прав доступа пользователей должно выполняться в соответствии с ролевой матрицей Системы на основе сведений о членстве пользователя в доменных группах Active DirectoryПроверить, что авторизация пользователей в системе выполняется с использованием службы Microsoft Active Directory. Проверить, что определение прав доступа осуществляется в соответствии с ролевой моделью системы на основе членства пользователей в доменных группах Active Directory.Подтверждено, что авторизация пользователей в системе выполняется с использованием службы Microsoft Active Directory.Тест пройден с замечаниями

Примечание.Реализована авторизация администраторов через LDAP и предустановленные согласно требованиям ФСТЭК роли, развитие с использованием RADIUS – заявлен в версии 1.11, TACACS - планируется в будущих релизах.13.7. Каждая роль должна иметь возможность настройки прав Тест не пройден

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

Примечание. На текущий момент ролевая модель с предопределёнными ролями согласно требованиям ФСТЭК.13.9. В информационной системе как минимум подлежат регистрации следующие события:

- вход (выход) субъектов доступа (в т.ч. обладающих привилегированной учетной записью) в/из ИС, а также попытки входа загрузки (остановки) операционной системы, изменений политик аудита;

- подключение машинных носителей информации и вывод информации на носители информации;

- запуск (завершение) программ и процессов (заданий, задач), связанных с обработкой защищаемой информации;

- попытки доступа программных средств к определяемым оператором защищаемым объектам доступа (техническим средствам, узлам сети, линиям (каналам) связи, внешним устройствам, программам, томам, каталогам, файлам, записям, полям записей) и иным объектам доступа;

- попытки удаленного доступа;

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

Система обеспечивает регистрацию событий, связанных с изменением настройки системы

Тест пройден

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

Не реализовано:

— Подключение машинных носителей информации и вывод информации на носители информации;

— Попытки доступа программных средств к определяемым оператором защищаемым объектам доступа (техническим средствам, узлам сети, линиям (каналам) связи, внешним устройствам, программам, томам, каталогам, файлам, записям, полям записей) и иным объектам доступа;

— Попытки удаленного доступа

— Запуск и остановка функции (сервисов) аудита.

— Сервис аудита включён всегда"13.10. Состав и содержание информации о событиях безопасности, включаемой в записи регистрации о событиях безопасности, должны, как минимум, обеспечить возможность идентификации типа события безопасности, даты и времени события безопасности, идентификационной информации источника события безопасности, результат события безопасности (успешно или неуспешно), субъект доступа (пользователь и (или) процесс), связанный с данным событием безопасности. Убедиться, что состав и содержание информации о событиях безопасности обеспечивают возможность идентификации типа события безопасности, даты и времени события безопасности, идентификационной информации источника события безопасности, результат события безопасности (успешно или неуспешно), субъект доступа (пользователь и (или) процесс), связанный с данным событием безопасностиСистема предоставляет информацию о событиях безопасностиТест пройден.

Примечание. Требуется доработка функционала в «человекочитаемый» вид (имена вместо идентификаторов, при удалении правила указывать не только ID, но и все правило). Замечания переданы в разработку.13.11. Каждое зарегистрированное событие должно однозначно сопоставляться с учетной записью пользователя, который был инициатором этого события с фиксацией времени события и определением, по возможности, адреса (например, сетевого).Убедиться, что события безопасности сопоставляются с учетными записями пользователей с фиксацией времениСистема обеспечивает сопоставление событий безопасности с учетными записями пользователей с фиксацией времениТест пройден13.12. Должно быть реализовано разграничение и обеспечен контроль доступа к журналам регистрации, предотвращающие несанкционированное удаление и/или изменение записей журнала (файла регистрации событий). Факты удаления событий (очистки журналов регистрации) должны регистрироваться.Убедиться в разграничении доступа к журналам аудита пользователей с разными ролями доступа согласно ролевой моделиСистема обеспечивает разграничение доступа к журналам аудита пользователей с разными ролями доступа согласно ролевой моделиТест пройден.

Примечание: Удаление и изменение журнальных записей специально запрещено.13.13. Должна быть реализована возможность централизованного сбора и хранения журналов регистрации событий, либо поддерживаться интерфейс с корпоративными решениями по сбору и хранению журналов (внедренными у Заказчика) с использованием стандартизированных протоколов и форматов (таких, как Syslog, Windows Event log, Windows File log, Windows WMI log, NetFlow, ODBC Log, SSH File Log, SNMP Traps, ....).Убедиться в возможности централизованно собирать и хранить журналы регистрации событийВ Системе присутствует возможность централизованно собирать и хранить журналы регистрации событийТест пройден Примечание. Журналирование событий осуществляется на сервер системы управления. С версии 1.9 добавлена возможность выделения подсистемы журналирования на отдельный сервер. Реализованы syslog, ssh, SNMP.13.14. При проектировании, разработке и тестировании ИС должны применяться техники и методики безопасной разработки для защиты от возникновения типичных уязвимостей приложений, перечисленных в каталогах OWASP Top 10, OWASP Mobile Top 10, SEI-CERT (и других каталогах, применяемых согласно предназначению ИС по согласованию с Заказчиком)Убедиться в наличии сертификата на безопасную разработкуСертификат на безопасную разработку присутствуетТест пройден13.15. ИС в своём слое представления (интерфейсов к клиентским приложениям или системам) должна обеспечивать (желательно за счёт централизованных механизмов):

- проверку вводимых данных (формат, ограничения) на предмет ошибок, некорректных данных (в том числе умышленно введенных), данных приводящих к избыточному использованию ресурсов ИС;

- проверку входных данных на соответствие контексту авторизованной сессии или использовать только данные аутентификационного контекста при формировании запросов к компонентам ИС или другим системам BSS Заказчика;

- квотирование и валидацию вводимой и выводимой информации для предотвращения уязвимостей к атакам XSS, SQL Injection и других видов инъекций;

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

Примечание. В журналах аудита отсутствует информация о блокировке пользователя после неуспешных попыток входа (более 3-х раз, согласно требованиям ФСТЭК). Будет исправлено в рамках приведения логов в ""человекочитаемый"" вид. Замечания переданы в разработку.

13.16. При развёртывании ИС в продуктивную среду (контур Заказчика) должны быть гарантировано удалены все системные скрипты, тестовые компоненты, отладчики, профилировщики, средства разработки и т.п. (исключения для средств, необходимых для функционирования ИС в коммерческой эксплуатации и удовлетворения Требований Эксплуатации, должны быть согласованы с Заказчиком)Убедиться, что в Системе отсутствуют тестовые компоненты, средства разработки и т.п.В Системе отсутствуют тестовые компоненты, средства разработки и т.п.Тест пройден14. Криптографическая защита14.1. Применение средств криптографической защиты информации обязательно передаче конфиденциальной информации по открытым (незащищенным) каналам передачи данных.Убедиться, что при подключении к системе управления используется защищённое соединениеПри подключении к системе управления используется защищённое соединениеТест пройден14.2. Должны использоваться стойкие криптографические алгоритмы и протоколы. Рекомендуется использовать следующие промышленные, прошедшие тестирование, криптографические протоколы и алгоритмы: 3DES, AES, RSA, ГОСТ 28147-89, ГОСТ Р 34.11-2012, ГОСТ 34.10-2012, ГОСТ 34.10-2018, ГОСТ Р 34.12-2015.Проверить используемые криптографические алгоритмы и протоколы для подключения к Системе управленияСистема использует один или несколько криптографических алгоритмов из приведённого спискаТест пройден Примечание.Не реализован:ГОСТ Р 34.11-2012, ГОСТ 34.10-2012, ГОСТ 34.10-2018, ГОСТ Р 34.12-201514.3. В ИС, использующих криптографические системы с открытым ключом, необходима поддержка интеграции с инфраструктурой открытых ключей Заказчика.Убедиться в возможности интеграции с существующей инфраструктурой открытых ключей ИС поддерживает интеграцию с существующей инфраструктурой открытых ключейТест пройден14.4. В ИС, использующих СКЗИ, должны быть реализованы функции резервного копирования и восстановления ключей шифрования, а также другие функции, связанные с жизненным циклом использования ключевой информации.Убедиться в наличии функции резервного копирования и восстановления ключей шифрования и иных функций, связанных с жизненным циклом использования ключевой информацииВ ИС реализованы функции резервного копирования и восстановления ключей шифрования и иных функций, связанных с жизненным циклом использования ключевой информацииТест пройден14.5. Все каналы передачи данных, используемые компонентами Системы для передачи данных, должны быть защищены и использовать безопасные протоколы (HTTPS (TLS >=1.2), SSH, SFTP/FTPS, SNMP v3, SMTP over TLS и т.п.)Убедиться, что в МСЭ каналы передачи данных используют безопасные протоколыПроверка протоколов передачи данныхТест пройден15. Требования к отказоустойчивости компонентов, надежности и производительности15.1. Система должна обеспечить показатель доступности сервиса на уровне 99,9%Убедиться, что Система может иметь резервирование компонентов, поддерживать обновление компонентов, восстановление компонентов из резервной копииСистема имеет возможность резервирование компонентов, поддержку обновление компонентов, восстановление компонентов из резервной копииТест пройден15.2. Должно быть обеспечено отсутствие единой точки отказа и резервирование всех компонентов СистемыУбедиться, что Система может быть объединена в отказоустойчивый кластерСистема имеет возможность кластерной конфигурацииТест пройден

15.3. Шлюзы безопасности, используемые в качестве компонентов Системы, должны быть настроены как отказоустойчивые кластеры в режиме active/standby, при котором выход из строя одного из шлюзов не приводит к остановке сервиса пользователям или потере производительностиУбедиться в возможности Системы объединения в отказоустойчивый кластерСистема имеет возможность объединения в отказоустойчивый кластерТест пройден15.4. Шлюзы безопасности, используемые в качестве компонентов Системы, должны иметь возможность использования двух внешних каналов с балансировкой нагрузки и автоматическим переключением между каналамиУбедиться в возможности настройки BGP для балансировки маршрутов между внешними каналами связиПрисутствует возможность настройки BGP для балансировки маршрутов между внешними каналами связиТест пройден

Примечание. Реализуется при помощи протоколов динамической маршрутизации. Реализована функция плавающих статических маршрутов (floating static). Дополнительный функционал ECMP и IP SLA (reachability check) заявлен в версии 1.1115.5. Шлюзы безопасности, используемые в качестве компонентов Системы, должны поддерживать выделенный сетевой порт управления для сохранения управляемости и доступности устройства при высоких нагрузках или сбояхУбедиться в возможности Системы выделенного сетевого порта для управленияСистема имеет выделенный сетевой порт для управленияТест пройден15.6. Шлюзы безопасности, используемые в качестве компонентов Системы, должны быть оснащены резервными блоками питания для обеспечения отказоустойчивостиУбедиться в возможности Системы резервирования блоков питанияСистема имеет возможность резервирования блоков питанияТест пройден15.7. Система должна обеспечивать возможность масштабирования и развития технического решения при возрастании нагрузки на компоненты Системы или при необходимости внедрения решения в новых структурных подразделениях КомпанииУбедиться, что Система имеет возможность подключения дополнительных кластеров и шлюзов МСЭСистема имеет возможность подключения дополнительных кластеров и шлюзов МСЭТест пройден15.8. Система должна иметь возможность дооснащения технического решения виртуальными шлюзами безопасности на платформе виртуализации для внедрения в удаленных офисах с плохими каналами связиУбедиться, что Система имеет возможность виртуального исполнения Система имеет возможность виртуального исполненияТест пройден16. Требования к ролям и правам доступа16.1. Система должна иметь механизм управления доступом и привилегиями пользователей, создания типовых ролей, объединения пользователей в группы

Проверить возможность добавления ролей учетным записям.

Проверить разграничение прав ролевой модели Системы, описанной в документацииИмеется функция добавления учетных записей.

Ролевая модель позволяет позволяет назначать заранее определенные роли администраторам системыТест пройден

Примечание. Реализована авторизация администраторов через LDAP, развитие с использованием RADIUS заявлена в версии 1.11

16.2. Система должна обеспечить возможность использования следующего минимального набора типовых ролей:

- администратор Системы - роль с правами на конфигурирование и настройку Системы и ее компонентов, управления правами Пользователей;

- менеджер/супервайзер - роль с правами на управление справочниками и нормативной информацией, использующейся при настройке сценариев подбора предложений, и правами на создание и редактирование сценариев подбора предложений;

- пользователь - роль с правами на создание и редактирование сценариев подбора предложений. Доступ к некоторым сценариям может быть ограничен АдминистраторомПроверить возможность добавления ролей учетным записям.

Проверить разграничение прав ролевой модели СистемыИмеется функция добавления учетных записей.

Ролевая модель позволяет разграничивать полномочия согласно описанной в документации ролевой моделиТест пройден

Примечание. На текущий момент ролевая модель с предопределёнными ролями согласно требованиям ФСТЭК.16.3. Система должна иметь возможность логирования действий Пользователей с указанием даты, времени, логина Пользователя, внесшего изменения и содержание измененийУбедиться в возможности Системы логирования действий пользователей.Система имеет возможность логировать действия пользователейТест пройден16.4. Система должна иметь возможность разграничения прав доступа по различным подразделениям (филиалам, кластерам) Тест не пройден

17. Требования к аппаратной части17.1. Модель оборудования Производитель CPU используемый в изделии Частота CPU Объем ROM Объем RAM Тип Ethernet-чипа Размер устройства не более 1 RU минимум 2 порта LAN 1/10GE Рабочая температура: от 0˚ до 40˚C. Температура хранения: от -20˚ до 70˚C. Относительная влажность: до 80% при 25 ˚C. Возможность крепления в стойку 19" Два блока питания 48В, 220В с возможностью горячей замены Поддержка модулей SFP сторонних производителейУбедиться, что оборудование соответствует заданным требованияОборудование соответствует заданным параметрамТест пройден17.2. Электромагнитная совместимость: CE, а также см. приказ Министерства информационных технологий от 24.08.2006 №112.Убедиться, что оборудование соответствует заданным требованияОборудование соответствует заданным параметрамТест пройден17.3. Оборудование должно иметь сертификат Минкомсвязи, позволяющий его эксплуатацию на территории РФУбедиться, что оборудование соответствует заданным требованияОборудование соответствует заданным параметрамТест пройден17.4. Декларация соответствия Правилам применения оборудования проводных и оптических систем передачи абонентского доступа, утв. приказом Миннформсвязи России от 24.08.2006.Убедиться, что оборудование соответствует заданным требованияОборудование соответствует заданным параметрамТест пройденТеги:• pt ngfw
• межсетевой экран
• функциональное тестирование
• информационная безопасность
• сетевая безопасность
• Тестирование NGFW
• Системы защиты сетиХабы:• Блог компании Innostage
• Информационная безопасность
• Сетевое оборудование

Получайте больше инсайтов о систематизации бизнеса

Подписывайтесь на Telegram-канал Business Operations — ежедневные материалы о бизнес-процессах, операционном управлении и повышении эффективности

💬 Подписаться на канал

Источник: Habr
→ Оригинальная статья