Автор: Дмитрий Квашнин, ведущий инженер-эксперт 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 раза в день.

 

 

Тест пройден

Примечание. Доступно ручное обновление. Автоматизация обновлений возможна при помощи скрипта и API. Активация новых сигнатур не требует перезагрузки сервиса NGFW с релиза 1.10.0, который включает в себя функцию централизованного обновления баз экспертизы (сигнатур, приложений, URL категорий и проч.) файлом через СУ.

3.4.              

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

Проверить возможность Системы активации вновь загруженными сигнатура обновлений

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

Тест пройден.

3.5          

Система должна поддерживать формирование белых списков для функций предотвращения/обнаружений вторжений:

- Устройств

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

- Приложений

- Сервисов

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

Система поддерживает создание белых списков объектов.

Тест пройден

 

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

3.6.              

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

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

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

Тест пройден

Примечание. Локальный захват трафика с DPDK интерфейсов реализован с версии 1.10.0

3.7.              

Система должна иметь возможность создания различных профилей защиты для применения к различным элементам системы в рамках единой консоли управления.

Проверить возможность создания в Системе профилей защиты

В Системе реализована возможность создания профилей защиты для определенного трафика

Тест пройден

3.8.              

Система должна поддерживать автоматическую регулярную загрузку черных и белых списков IP-адресов, URL-адресов и DNS-имен как из источников, определяемых производителем, так и из заданных пользователем источников.

Проверить возможность загрузки списков с помощью API.

В Системе реализована возможность загрузки списков с помощью API.

Тест пройден

 

 

3.9.              

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

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

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

Тест пройден

3.10.          

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

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

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

Тест пройден

 

Примечание. IPS профиль применяется к выделенному трафику. Выделение трафика происходит стандартными средствами фильтрации и можно указать помимо зон, адресов источников/назначения пользователя или группу пользователей, приложение. Распознавание ОС, уязвимостей и репутации хоста не входит в перечень основных функций NGFW

3.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.11

4.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 Sandbox

5.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 раза в день.

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

Система поддерживает обновление сигнатур вредоносных программ

Тест пройден

Примечание. Доступно ручное обновление. Автоматизация обновлений возможна при помощи скрипта и API. Активация новых сигнатур не требует перезагрузки сервиса NGFW с релиза 1.10.0, который включает в себя функцию централизованного обновления баз экспертизы (сигнатур, приложений, URL категорий и проч.) файлом через СУ.

6.5.              

Система должна обеспечивать детектирование вредоносной сетевой активности на основе базы репутации IP, URL, DNS адресов, и обнаруживать паттерны взаимодействия ботов с командными центрами.

Проверить возможность Системы обеспечивать детектирование вредоносной сетевой активности на основе URL категорий. Проверить наличие URL категорий, включающих botnet и Command and Control сервера

Система обеспечивает детектирование вредоносной сетевой активности на основе URL категорий. Присутствуют URL категории, включающих botnet и Command and Control сервера

Тест пройден

6.6.              

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

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

Система имеет соответствующие URL категории и позволяет написать правило блокировки взаимодействия с командными центрами бот-сетей.

Тест пройден

6.7.              

Система должна обеспечивать сканирование ссылок внутри тела письма и их анализ по базе репутации.

 

 

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

6.8.              

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

Проверить возможность обновления контента.

Система поддерживает обновление контента

Тест пройден

Примечание. Доступно ручное обновление. Автоматизация обновлений возможна при помощи скрипта и API. Активация новых сигнатур не требует перезагрузки сервиса NGFW с релиза 1.10.0, который включает в себя функцию централизованного обновления баз экспертизы (сигнатур, приложений, URL категорий и проч.) файлом через СУ.

6.9.              

Система должна иметь возможность инспектирования протокола CIFS

 

 

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

 

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 Sandbox

9.                   

Требования к функционалу маршрутизации

9.1.              

Система должна на аппаратном уровне поддерживать протоколы маршрутизации BGP, OSPF

Убедиться в возможности Системы поддержки динамической маршрутизации на основе протоколов OSPF, BGP

Система поддерживает динамическую маршрутизацию

Тест пройден

9.2.              

Система должна на аппаратном уровне поддерживать агрегацию портов (LAG)

Убедиться в возможности Системы поддержки агрегации портов

Система поддерживает агрегацию портов

Тест пройден

9.3.              

Система должна на аппаратном уровне поддерживать количество правил ACL исходя из прогноза их роста за время эксплуатации системы

Убедиться в возможности Системы поддержки большого кол-ва правил

Система поддерживает большое кол-во правил

Тест пройден

10.                

Требования к системе управления

10.1.          

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

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

Система поддерживает реализацию модуля управления на отдельно стоящем сервере

Тест пройден

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

10.2.          

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

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

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

Тест пройден

Примечание. На текущий момент предустановленные роли согласно описанной ролевой модели. Запланировано развитие функционала по ролям. Роль read-only доступна с версии 1.9 Гибкая ролевая модель планируется в будущих релизах

 

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.0

10.24.      

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

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

Подтверждена возможность выполнения контролируемого переключения системы управления на резервную площадку по инициативе оператора (администратора).

Тест пройден

Примечание. Реализовано с версии 1.9.0

10.25.      

Система управления должна регулярно выполнять резервное копирование конфигурации, компонентов и целиком сервиса без перерыва сервиса и без потери производительности сервиса во время исполнения заданий резервного копирования.  Результат выполнения должен отслеживаться self-мониторингом через интерфейсы системы и информировать по результату выполнения операции резервного копирования по NBI.

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

Подтверждена возможность выполнения резервного копирования конфигурации

Тест пройден

Примечание. Все настройки NGFW хранятся на Системе управления (СУ). СУ не стоит на пути прохождения трафика и её полное выключение не влияет на работу МСЭ.
Запуск резервного копирования в ручном режиме через GUI. Регулярные бэкапы можно организовать при помощи API и скрипта. Результаты успешного или неуспешного Backup видны в GUI или могут быть получены через API. Планируется добавление расписаний бэкапов в GUI в будущих релизах

10.26.      

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

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

Подтверждена возможность восстановления конфигурации из резервной копии

Тест пройден

10.27.      

Основная и резервная система управления должны иметь основной функционал FCAPS (включая NBI интерфейсы) с возможностью логирования. Перечислить поддерживаемый функционал и методы реализации.

Проверить наличие в основной и резервной системе управления функционала FCAPS

Подтверждена поддержка NBI-интерфейсов для интеграции с внешними системами и возможность ведения журналов событий

Тест пройден

Примечание. Отправка событий реализована по протоколу Syslog. SNMP реализован с версии 1.10.0

10.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-2015

14.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.11

15.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.

Убедиться, что оборудование соответствует заданным требования

Оборудование соответствует заданным параметрам

Тест пройден