| Наименование характеристики |
Значение характеристики |
Единица измерения
характеристики |
Инструкция по заполнению
характеристик в заявке |
| Функциональность |
Должен поддерживаться возможность создания списка отозванных клиентских сертификатов, в том числе:
• локального, загружаемого и обновляемого из файла формата PEM;
• публичного, расположенного на указанном URL и обновляемого Удостоверяющим центром.
• Должна поддерживаться возможность копирования объектов конфигурации:
• профилей трафика;
• IP-адресов для прослушивания;
• настроек веб-приложений;
• пользовательских правил;
• действий в правилах;
• защищаемых серверов;
• IP-адресов для исходящих запросов.
• Должна поддерживаться возможность копирования системных настроек:
• LDAP-подключений;
• OAuth-подключений;
• ICAP-серверов;
• ролей пользователей.
Должна обеспечиваться возможность отслеживания попыток доступа пользователя к ресурсам защищаемого веб приложения, осуществляемых на основании применяемых методов аутентификации с использованием:
• базовой аутентификации;
• аутентификации через веб форму;
Должна поддерживаться возможность обновления (дополнения) списка запрещенных значений пар «логин — пароль».
СЗВП должна содержать правила, направленные на обнаружение использования ботов для автоматического сканирования или получения данных сайта (на основе заголовка User Agent).
Должна поддерживаться возможность обновления (дополнения) списка обнаруживаемых частей заголовка User Agent.
СЗВП должна содержать правила, направленные на обнаружение и контроль автоматизированной активности путем ограничения количества HTTP запросов от одного клиента за установленный период времени. |
|
|
|
Должны поддерживаться следующие параметры:
• маршруты;
• скорость.
СЗВП должна содержать правила, направленные на выявление сканирования веб приложения на уязвимости.
СЗВП должна содержать правила, направленные на модификацию ответов от защищаемого веб приложения путем добавления или замены заголовков:
• Referrer Policy, настраивающего уровень детализации для включения в заголовок Referer при уходе со страницы;
• X Content Type Options, запрещающего браузерам выполнение контента, для которого не установлен правильный MIME тип данных;
• X Frame Options, запрещающего браузеру загружать страницу во Frame/Iframe;
• X XSS Protection для включения фильтрации XSS.
СЗВП должна содержать правила, направленные на возможность задания режима принудительного использования протокола HTTPS веб приложением путем задания заголовка Strict Transport Security с возможностью настройки параметров:
• периода времени использования HTTPS;
• возможности применения правила к поддоменам;
• возможности замены заголовка в ответе защищаемого сервера;
• возможности постоянного принудительного использования HTTPS (без указания времени).
СЗВП должна содержать правила, направленные на модификацию ответов куки (cookie) путем принудительной установки атрибутов безопасности:
• httpOnly;
• secure;
• sameSite.
Должна поддерживаться возможность добавления исключений из правила для куки (cookie), к которым не должны применяться параметры безопасности.
СЗВП должна содержать правила, направленные на обнаружение и блокирование CSRF атак путем проверки заголовков Origin и Referer на наличие запрещенных значений URL с возможностью настройки параметров:
• списка узлов, которым разрешено взаимодействие с веб приложением;
• методов запроса, проверяемых правилом;
• возможности проверки поддоменов доверенных узлов;
• возможности пропускания на защищаемый сервер запросов без заголовков Origin и Referer. |
|
|
|
Должна поддерживаться возможность создания, редактирования и удаления шаблонов политик безопасности.
Должна поддерживаться возможность сброса настроек правила в исходное состояние, соответствующее шаблону политики безопасности.
Должны поддерживаться глобальные (статические или динамические) списки IP адресов с возможностями:
• их применения в качестве параметров правил, политик безопасности, действий и шаблонов политик безопасности;
• их создания, редактирования, скачивания и удаления;
• автоматизированного поиска IP адресов по глобальным спискам;
• хранения пользовательского IP адреса в глобальном динамическом списке в течение заданного периода;
• удаления пользователем IP адресов из всех или отдельных глобальных динамических списков;
• дополнения глобального списка IP адресов при возникновении событий агрегации;
• экспорта глобальных списков.
Настройка политик безопасности должна поддерживаться как для отдельных веб приложений, так и для нескольких веб приложений одновременно (при помощи шаблонов политик).
СЗВП должна поддерживать настройку конфигурации защиты веб приложения, включающую в себя параметры:
• название конфигурации;
• шаблон политики безопасности, на основе которого создана политика;
• профили трафика, применяемые для политики;
• название группы сертификатов TLS, которая используется для обработки защищенного трафика;
• конфигурация TLS соединений с возможностью ее настройки;
• возможность проверки сертификата сервера защищаемого веб-приложения при подключении по HTTPS;
• возможность проверки сертификата клиента при подключении по mTLS с указанием глубины проверки и списком отозванных сертификатов;
• возможность обмена данными с защищаемым веб-приложением по протоколу WebSocket;
• режим защиты веб приложения;
• IP адреса или доменные имена защищаемого веб приложения (опционально);
• путь до защищаемой части веб приложения (опционально);
• наличие балансировщика или прокси сервера перед защищаемым веб приложением в ИТ инфраструктуре Заказчика; |
|
|
|
Должна поддерживаться системная группировка предустановленных правил по решаемой задаче, вектору атаки или технологии (там, где это применимо к набору правил):
? CSRF;
? ImageMagick;
? J2EE;
? SSRF;
? XSS;
? безопасность JWT;
? безопасность XML;
? боты;
? внедрение;
? внедрение SQL кода;
? доступность важных файлов;
? загрузка файлов;
? исполнение вредоносных файлов;
? контроль доступа;
? нарушение HTTP;
? политики браузера;
? предварительная обработка;
? репутация IP адреса;
? сессии;
? эксплуатация уязвимостей из списка CVE;
? безопасность HTML-форм.
Должна поддерживаться возможность группировки системных правил на основе:
• точности;
• типа события безопасности;
• фазы срабатывания правила;
• названий предустановленных групп правил;
• уровня опасности.
• Должна поддерживаться возможность группировки пользовательских правил на основе:
• типа события безопасности;
• фазы срабатывания правила;
• уровня опасности.
Должна поддерживаться возможность поиска правил по их названию и по названию их групп.
Должны поддерживаться системные действия для правил:
• отправить свой ответ при блокировании;
• записать событие в базу данных;
• закрывать соединение без отправки ответа клиенту;
• не проверять событие правилами.
• Должна поддерживаться возможность создания пользовательских действий следующих типов:
• добавление IP адреса клиента в глобальный динамический список;
• запись события в базу данных СЗВП;
• изменение заголовков ответа, защищаемого веб сервера;
• изменение заголовков запроса;
• отправление ответа СЗВП при блокировании клиентского запроса;
• отправление события на syslog сервер.
Должна поддерживаться отправка сообщений syslog в форматах:
• SIEM;
• JSON — для систем, поддерживающих JSON; |
|
|
|
Для системных правил должны быть указаны:
• наименование правила;
• статус активности правила (включено или отключено);
• принадлежность к системному набору правил;
• действия при срабатывании;
• принадлежность к группе правил;
• точность определения атаки правилом (по оценке экспертов);
• фаза срабатывания правила;
• метки (теги), помогающие при сортировке и поиске правила в журналах событий;
• классификация правила согласно отраслевым стандартам (например, CAPEC, WASC, OWASP, CWE, PCI DSS, CVE, MITRE) с указанием года (при наличии);
• тип угрозы безопасности, обнаруживаемой в результате срабатывания правила;
• уровень опасности события безопасности, зарегистрированного в результате срабатывания правила;
• номер ревизии правила;
• конфигурация правила с действиями при срабатывании;
• условия объединения срабатываний правила в событие агрегации с добавлением подозрительного IP адреса в глобальный динамический список (опционально).
• Должна поддерживаться возможность создания, редактирования и удаления пользовательских правил, в том числе должны поддерживаться возможности задания:
• наименования правила;
• описания (опционально);
• меток (тегов), помогающих при сортировке и поиске правила в журналах событий;
• классификации правила (опционально);
• типа события (атака, уязвимость, инцидент, информация);
• уровня опасности события, регистрируемого в результате срабатывания пользовательского правила (отсутствует, низкий, средний, высокий);
• конфигурации правила (включая возможность задания пользовательских параметров и привязки к конкретному параметру, например, глобальному списку, зарегистрированному в СЗВП);
• действий при срабатывании;
условий добавления правила в событие агрегации:
o количества срабатываний правила;
o интервала между срабатываниями правила;
o периода времени, в течение которого IP адрес, для которого сработало правило, будет находиться в глобальном черном списке IP адресов;
o названия глобального динамического списка для хранения IP адресов. |
|
|
|
Должна обеспечиваться возможность настройки IP адресов, на которые будет направляться трафик для его обработки СЗВП, с указанием параметров:
• тип IP адреса;
• назначаемый узел обработки трафика;
• IPv4-адрес пункта назначения в нотации CIDR;
• шлюз для маршрутизации трафика.
Должна обеспечиваться возможность обработки трафика на основании списков IP адресов (далее также — глобальных списков); в том числе должны поддерживаться статические и динамические белые и черные списки (в формате CIDR), устанавливаемые на основе правила.
9. Требования к подсистеме управления
СЗВП должна содержать правила обработки трафика, настроенные на защиту объектов (ресурсов), созданных на базе технологий, указанных в названии набора правил:
• Apache Struts — включает только те правила, которые предназначены для защиты веб приложений, разработанных на фреймворке Apache Struts;
• ASP.NET — включает только те правила, которые предназначены для защиты веб приложений, созданных на платформе ASP.NET;
• Bitrix — включает только те правила, которые предназначены для защиты веб приложений, разработанных на фреймворке Bitrix;
• Java — включает только те правила, которые предназначены для защиты веб приложений, разработанных на языке Java;
• Joomla CMS — включает только те правила, которые предназначены для защиты веб приложений, основанных на системе управления контентом Joomla;
• LAMP (PHP, Apache, MySQL) — включает только те правила, которые предназначены для защиты веб приложений, разработанных при помощи инструментов PHP, Apache или MySQL;
• Microsoft Exchange — включает только те правила, которые предназначены для защиты сервера Microsoft Exchange;
• Node.js — включает только те правила, которые предназначены для защиты веб приложений, созданных на платформе Node.js;
• PHP — включает только те правила, которые предназначены для защиты веб приложений, разработанных на языке PHP;
• Default template (стандартный шаблон) — включает правила всех остальных системных наборов. |
|
|
|
Требования к функциям (задачам), выполняемым СЗВП
СЗВП должна выполнять следующие требования:
8. Требования к подсистеме обработки веб-трафика
Должно поддерживаться определение IP адреса отправителя веб трафика.
Должна поддерживаться возможность задания перечня защищаемых серверов, на которых расположены веб приложения.
Должна поддерживаться возможность создания профилей собираемого (обрабатываемого) трафика веб приложений с возможностью указания:
• IP адресов и портов, которые СЗВП будет использовать для приема клиентских запросов и их проксирования на защищаемое веб приложение;
• протокола для клиентских запросов к серверу с возможностью принудительной замены протокола на защищенный;
• серверов из перечня защищаемых серверов веб приложений с возможностью ограничения доли защищаемого трафика, отправляемого на сервер, и количества попыток установления соединения;
• режима работы серверов веб приложений (активный или запасной);
• характера распределения (балансировки) нагрузки между защищаемыми серверами;
• необходимости отправки имени узла из запроса клиента на защищаемый сервер при установлении TLS соединения (отправлять / не отправлять / отправлять другое);
• времени ожидания неактивного соединения.
• Должны поддерживаться анализ и обработка трафика веб приложений, передаваемого по протоколам:
• HTTP/2 и HTTPS (с поддержкой TLS 1.2 и 1.3);
• WebSocket (ws).
• Должна поддерживаться обработка трафика, защищенного TLS сертификатом с поддержкой ГОСТ 34.12-2015.
• Должна поддерживаться обработка трафика, применяющего алгоритм сжатия Brotli.
• Должна обеспечиваться возможность анализа запросов, передаваемых в нотациях:
• XML (SOAP);
• JSON (REST API);
• AJAX (при наличии технической возможности);
• GraphQL. |
|
|
|
СЗВП должна содержать правила, направленные на добавление идентификатора для текущей сессии пользователя на HTML страницы, связанные с операциями на стороне сервера веб приложения, с возможностью настройки:
• конфигурации идентификатора, в том числе времени его существования;
• режима блокирования запроса при отсутствии идентификатора в запросах со стороны сервера;
• вида HTML содержимого, в ответ на которое будет добавляться идентификатор.
СЗВП должна содержать правила, обеспечивающие проверку HTTP запросов на наличие идентификатора, добавленного для текущей сессии пользователя на HTML страницы, с возможностью редактирования его конфигурации и режима блокирования запроса.
СЗВП должна содержать правила, направленные на обнаружение и блокирование межсайтового выполнения сценариев (XSS) следующих типов:
• XSS в контексте HTML;
• XSS в контексте JavaScript;
• XSS в контексте URL;
• отраженное XSS в контексте HTML.
При поиске межсайтового выполнения сценариев (XSS) должна поддерживаться настройка проверяемых частей HTTP запроса и условий, при которых запросы пропускаются без проверки.
СЗВП должна содержать правила, обеспечивающие проверку подлинности веб-форм защищаемого приложения с помощью постановки подписей скрытых полей HTML-форм и контроля их наличия.
СЗВП должна содержать правила, направленные на контроль эксплуатации уязвимостей из списка CVE:
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с плагином Struts 1 (S2-048);
• удаленное выполнение кода (RCE) в «Битриксе»;
• удаленное выполнение кода (RCE) в «Битриксе» без аутентификации;
• внедрение SQL кода в «Битрикс»;
• удаленное выполнение кода (RCE) в «1С Битрикс: Управление сайтом»;
• удаленное выполнение кода (RCE) в «Битрикс24», связанное с десериализацией PHAR-файлов;
• удаленное выполнение кода (RCE) в «Битрикс24», связанное с добавлением данных в файл;
• удаленное выполнение кода (RCE) в «1С-Битрикс: Управление сайтом» (модуль «Сайты 24»); |
|
|
|
защита от удаленного выполнения PHP-кода в «Битриксе».
• СЗВП должна содержать правила, направленные на обнаружение в трафике различных механизмов загрузки вредоносных файлов:
• попыток загрузки файла с запрещенным расширением;
• запрещенного MIME типа файла в загружаемом файле;
• вредоносного HLS плейлиста в загружаемом файле;
• наличия PHP архива (PHAR) с вредоносными данными, приводящими к выполнению произвольного кода;
• наличия вредоносного сценария в текстовых файлах (в том числе PHP функций);
• наличия в загружаемом ZIP архиве уязвимости Zip Slip;
• наличия в загружаемом PDF-файле вредоносного JavaScript-кода;
Должна поддерживаться возможность указания MIME типов (запрещенных или проверяемых) для конкретных правил.
Должна поддерживаться возможность указания расширений файлов (запрещенных или проверяемых) или их отсутствие для конкретных правил.
СЗВП должна содержать правила, направленные на обнаружение и блокирование SSRF атак, с указанием параметров безвредного запроса, списка разрешенных расширений для локальных файлов и возможностью разрешения внешних URL в HLS плейлисте для конкретных правил.
СЗВП должна содержать правила, направленные на обнаружение и блокирование загрузки веб-шелла, с возможностью настройки следующих параметров:
• порогового значения для вероятности классификации файла как вредоносного;
• процента совпадения содержимого загружаемого файла с частичными хеш суммами, при превышении которого файл считается веб шеллом;
• проверяемого языка для обнаружения веб шелла;
• списка PHP функций, обнаруживаемых правилом;
• возможности проверки неподдерживаемых тегов;
• возможности проверки регулярных выражений на наличие веб шелла в операционных системах Windows, Linux.
• СЗВП должна содержать правила, направленные на контроль структуры HTTP запроса к защищаемому веб серверу, с проверками:
• наличия одинаковых заголовков в запросе;
• наличия содержимого у запросов GET и HEAD;
• наличия запрещенных методов в HTTP запросе (с указанием разрешенных); |
|
|
|
версии HTTP запроса (с указанием допустимых);
• соответствия значения заголовка Accept Encoding требованиям RFC 7231 и списку разрешенных значений (опционально);
• соответствия значения заголовка Content Type в запросах заданных типов требованиям RFC 7231 и списку разрешенных значений с возможностью включения режима строгой проверки;
• кодировок в HTTP запросе на отличие от UTF 8;
• наличия заголовка Content Length или Transfer Encoding в модифицирующем POST запросе;
• наличия IP-адреса из заголовка HOST в списке разрешенных.
Должна поддерживаться возможность указания исключений при поиске одинаковых заголовков в запросе.
СЗВП должна содержать правила, направленные на обнаружение и блокирование атак, связанных с уязвимостями набора программ для чтения и редактирования файлов графических форматов ImageMagick (с возможностью указания пропускаемых без проверки частей запроса):
• удаленное выполнение команд с помощью библиотеки Ghostscript;
• эксплуатацию уязвимости ImageTragick;
• кражу данных с помощью GIF файлов в ImageMagick версии 7.0.6-1 и GraphicsMagick версии 1.3.26;
• кражу данных с помощью XBM файла при обработке таких файлов с помощью ImageMagick версий 7.0.8–9.
СЗВП должна содержать механизмы защиты от следующих атак, направленных на внедрение небезопасного кода (с настройкой параметров защиты):
• некорректно сформированный JSON или XML код в содержимом запроса (с настройкой пропускаемых без проверки частей запроса и расшифровываемых MIME типов файлов);
• внедрение CSS кода (с настройкой проверяемых и пропускаемых частей запроса);
внедрение кода Expression Language (с настройкой проверяемых и пропускаемых частей запроса);
• расщепление HTTP ответов (с настройкой проверяемых и пропускаемых частей запроса);
• небезопасная десериализация объектов Java (с настройкой проверяемых и пропускаемых частей запроса);
• подмена JavaScript прототипа (с настройкой проверяемых и пропускаемых частей запроса); |
|
|
|
Должно обеспечиваться хранение данных СЗВП на базовых узлах кластера Kubernetes, в том числе должны поддерживаться:
• базы данных PostgreSQL — для хранения данных о конфигурации СЗВП;
• базы данных ClickHouse — для хранения данных об инцидентах и уязвимостях, обнаруженных СЗВП;
• базы данных Redis — для хранения данных о метриках, журналах, статусе компонентов системы в оперативной памяти.
• хранилища объектов MinIO — для хранения неструктурированных данных (таких как отчеты и резервные копии СЗВП).
Должна быть обеспечена мультиарендность, позволяющая пользователям СЗВП работать в изолированном пространстве защищаемых приложений, связанных с ними событий безопасности и политик безопасности.
Должна обеспечиваться возможность создания изолированных пространств с указанием учетной записи администратора:
• для базовых и дополнительных узлов;
• внешних агентов.
Должна обеспечиваться возможность приглашения текущего пользователя в создаваемое изолированное пространство.
Должен поддерживаться выбор типа сервера для обработки трафика:
• nginx;
• envoy.
Должна поддерживаться возможность переключения между изолированными пространствами для одной учетной записи.
Должна обеспечиваться возможность управления базовыми и дополнительными узлами СЗВП через консольный интерфейс (SSH).
Должна обеспечиваться возможность управления функциями СЗВП с помощью:
• веб интерфейса;
• REST API.
Возможность управления функциями СЗВП должна предоставляться только авторизованным (уполномоченным) пользователям.
Должна обеспечиваться реализация ролевой модели управления доступом к функциям СЗВП, доступным через веб-интерфейс. В том числе должны обеспечиваться:
• создание, редактирование и удаление пользовательских ролей (с описанием их полномочий при необходимости);
• управление разрешениями, назначаемыми каждой роли. |
|
|
|
Должна обеспечиваться возможность управления (в том числе создание, изменение, удаление) учетными записями пользователей СЗВП:
• логинами и паролями;
• ролями;
• методами аутентификации (локальная база или LDAP-аутентификация).
В графическом веб интерфейсе должна поддерживаться возможность просмотра взаимосвязанных объектов конфигурации.
Должны поддерживаться различные режимы защиты (без мер защиты, обнаружение и изменение содержимого, все меры защиты) и обеспечиваться возможность переключения между ними.
Должна поддерживаться возможность включения и отключения правил в шаблонах политик безопасности.
Должно обеспечиваться отображение сведений о шаблонах политик безопасности:
• перечень веб приложений, которые применяют шаблон;
• общее количество правил в шаблоне;
• количество активных (включенных) правил в шаблоне.
Должна поддерживаться функция быстрого поиска, по ключевым словам, для выбора шаблона политики безопасности в настройках конфигурации веб приложения.
Должна обеспечиваться регистрация событий, связанных с действиями пользователей СЗВП, системными операциями и обновлениями базы знаний (далее также — внутренних событий СЗВП), а также отображение этих событий в табличном виде с возможностью обновления данных об этих событиях.
Должен обеспечиваться просмотр дополнительной информации о каждом зарегистрированном внутреннем событии СЗВП.
Должна обеспечиваться возможность отображения внутренних событий СЗВП за выбранный временной период.
Должна поддерживаться возможность сортировки зарегистрированных событий безопасности, агрегации и внутренних событий СЗВП по атрибутам:
• для событий безопасности:
? дата;
? событие безопасности;
? IP-адрес;
? веб-приложение;
? код ответа;
? метод;
? URI.
• для событий агрегации:
? дата начала;
? дата окончания;
? событие безопасности;
? количество срабатываний;
? IP-адрес;
? истечение TTL IP-адреса;
? веб-приложение.
• для внутренних событий:
? дата;
? уровень важности;
? пользователь;
? IP-адрес;
? объект. |
|
|
|
Должна регистрироваться следующая информация о событиях агрегации:
• дата возникновения первого вошедшего в событие агрегации события безопасности;
• дата возникновения последнего вошедшего в событие агрегации события безопасности;
• название правила, срабатывания которого привели к созданию события агрегации;
• количество срабатываний правила, вошедшего в событие агрегации;
• время, за которое фактически было собрано событие агрегации;
• IP адрес отправителя запросов, вызвавших срабатывания правила и сборку события агрегации;
• дата, до которой IP адрес отправителя будет находиться в черном списке;
• правило, осуществляющее фактическую блокировку адресов, находящихся в списке заблокированных;
• название веб приложения, для которого создано событие агрегации.
Должен обеспечиваться мониторинг состояния СЗВП и предоставление в графическом веб интерфейсе следующих данных о состоянии СЗВП:
• общее состояние системы;
• состояние узлов кластера;
• состояние сервисов;
• загрузка ЦПУ;
• объем используемой памяти;
• нагрузка на базу данных событий безопасности;
Должно обеспечиваться отслеживание статуса применения и даты обновления конфигурации модулей обработки трафика.
Должна обеспечиваться возможность получения справочной информации о СЗВП:
• текущей версии компонентов СЗВП, дате последнего обновления;
• актуального состояния внутренних сервисов СЗВП.
Должна обеспечиваться возможность перехода на портал технической поддержки производителя СЗВП через веба интерфейс.
Должна обеспечиваться возможность увеличения мощностей ресурсов СЗВП для обработки трафика. |
|
|
|
Должна поддерживаться возможность управления заголовками входящих HTTP запросов созданием действий:
• задание переменной вместо текущего значения заголовка;
• добавление переменной к текущему значению заголовка;
• удаление заголовка;
• присвоение значения другого заголовка;
• замена значения заголовка;
• добавление значения к заголовку.
• Должен предоставляться выбор области применения действий:
• любые входящие HTTP запросы;
• запросы из доверенных подсетей;
• запросы из недоверенных подсетей.
10. Требования к видам обеспечения
СЗВП должна обеспечиваться средствами, отвечающими следующим требованиям:
11. Требования к лингвистическому обеспечению СЗВП
Эксплуатационная документация должна быть выполнена на русском языке.
Программное обеспечение, входящее в состав системы, должно поддерживать выбор языка (русский или английский).
12. Требования к программному обеспечению
Программное обеспечение, входящее в состав СЗВП, должно поддерживать развертывание как на физических, так и на виртуальных серверах, процессоры которых поддерживают инструкции SSE4.2, AVX и AVX2.
Программное обеспечение, входящее в состав СЗВП, должно входить в единый реестр российских программ для электронных вычислительных машин и баз данных.
Программное обеспечение, входящее в состав СЗВП, должно устанавливаться без подключения к сети Интернет.
Программное обеспечение, входящее в состав СЗВП, должно устанавливаться из QCOW2-, ISO или OVA-образов.
Программное обеспечение из состава СЗВП должно функционировать под управлением операционной системы Astra Linux Special Edition «Воронеж» 1.7.
Работа пользователя в графическом веб интерфейсе СЗВП должна осуществляться на АРМ пользователя через браузер Google Chrome версии 60 или выше.
13. Требования к техническому обеспечению
СЗВП должна поддерживать конфигурации с использованием как внешних, так и внутренних балансировщиков нагрузки. |
|
|
|
внедрение объектов YAML (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение команд, связанных с электронной почтой;
• внедрение небезопасного объекта JavaScript в запросе к приложению Node.js.
СЗВП должна содержать правила, направленные на блокирование клиентов по IP адресам, находящимся в заданных списках:
• блокирование клиентов по принадлежности IP адреса диапазону адресов национального или регионального провайдера (на базе GeoIP2);
• блокирование клиентов по IP адресу из глобального (статического) списка (с возможностью указания IP адресов вручную без использования списка);
• блокирование клиентов по IP адресу из глобального (динамического) списка.
СЗВП должна содержать правила, проверяющие ответы приложения на наличие признаков выполнения вредоносного сценария (веб шелла).
СЗВП должна содержать правила, направленные на выполнение следующих предварительных проверок и действий с трафиком:
• проверка превышения ограничений для GraphQL (с указанием ограничений атрибутов GraphQL);
• проверка передаваемых в запросе IP-адресов на их наличие в списке разрешенных;
• проверка превышения ограничения для протокола HTTP (с указанием ограничений атрибутов HTTP запросов, куки, заголовков, других частей и параметров исключений из них (при необходимости));
• проверка превышения ограничений для JSON (с указанием ограничений атрибутов JSON);
• проверка HTTP запросов с типом содержимого multipart/form data на соответствие RFC 7231 и 7578;
нормализация параметров PHP и ASP.NET для дальнейшей проверки другими правилами;
• декодирование параметров HTTP трафика (с указанием проверяемых частей HTTP запроса и возможностью включения режима рекурсивного декодирования параметров с указанием его глубины);
Должно поддерживаться рекурсивное декодирование параметров в запросах с возможностью задания глубины рекурсии.
Должно поддерживаться создание исключений из проверок политики безопасности по параметрам HTTP запросов. |
|
|
|
СЗВП должна содержать правила, обеспечивающие следующие механизмы защиты, направленные на предотвращение доступа злоумышленника к важным файлам:
• обнаружение и блокирование запросов самоанализа (интроспекции) GraphQL;
• обнаружение и блокирование попыток чтения автономной адресной книги (OAB) в Microsoft Exchange Server;
• обнаружение и блокирование попыток чтения общих каталогов Windows и внутренних сайтов SharePoint, которые должны быть недоступны извне, под учетной записью пользователя Microsoft Exchange Server (с указанием пути к сервису ActiveSync);
• защита от утечки важных данных в содержании ответа на запрос (с заданием исключений, пропускаемых частей HTTP-запроса и группы шаблонов кода для определения утечки в ответе);
• предотвращение включения в ответ заголовков, которые могут содержать важную информацию в заголовке ответа (с указанием этих заголовков);
• защита от попыток получения прямого доступа к файлам с критически важной информацией (такой, как пароли, ключи API, параметры конфигурации).
СЗВП должна содержать правила, направленные на обнаружение и блокирование следующих случаев компрометации сессии пользователя:
• использование сессионного идентификатора пользователя с разных IP адресов (с указанием пропускаемых частей HTTP запроса (опционально), длительности сессии и списка проверяемых сессионных куки);
• разглашение важной информации о сессии через параметры URL (с указанием пропускаемых частей HTTP запроса (опционально) и проверяемых сессионных куки).
СЗВП должна содержать правила, направленные на обнаружение и блокирование атак типа «внедрение SQL кода» (SQL injection), основанных на:
• ошибках сервера;
• параметрах запроса;
• времени.
• Должна поддерживаться настройка параметров для правил, направленных на внедрение SQL кода:
• частей HTTP запроса, пропускаемых без проверки правилом (опционально);
• частей HTTP запроса, проверяемых правилом (опционально);
• разделителей в коде, которые являются признаком внедрения; |
|
|
|
версий SQL для разных СУБД, которые будут проверяться правилами;
• сообщений об ошибках;
• минимальной задержки ответа защищаемой базы данных, при которой запустится проверка.
СЗВП должна содержать правила, направленные на обнаружение и блокирование атак типа «подделка запросов на стороне сервера» (server side request forgery, SSRF) с настройкой следующих параметров:
• частей HTTP запроса, пропускаемых без проверки правилом (опционально);
• частей HTTP запроса, проверяемых правилом;
• схем, портов, узлов, путей, IP адресов в формате CIDR, недействительных URL, обнаружение которых приведет к блокированию запроса;
• схем, портов, узлов, путей, IP адресов в формате CIDR, которые будут считаться безопасными.
СЗВП должна содержать правила, направленные на обнаружение и блокирование атак на уязвимости при обработке документов XML путем проверки (с указанием проверяемых и пропускаемых (опционально) частей HTTP запроса):
• наличия обращений к внешним сущностям (XML external entities, XXE) в XML документе;
• использования операции определения типа документа (document type definition, DTD) для XML документа из внешнего файла.
Должна поддерживаться возможность настройки исключений из правил (при наличии технической возможности), в том числе с использованием регулярных выражений на языке Lua и возможностей библиотеки HyperScan. Задание исключений должно быть доступно из карточки правила при настройке политики безопасности и из карточки события безопасности после его срабатывания.
Должны предоставляться программные интерфейсы (REST API) для автоматизации задач по управлению системой с помощью внешних программных средств.
Должны предоставляться программные интерфейсы для передачи данных в систему регистрации событий и выявления инцидентов информационной безопасности. |
|
|
|
Должна обеспечиваться возможность отправки записей обращений (access.log) к защищаемому веб приложению в систему регистрации событий и выявления инцидентов информационной безопасности (SIEM) для Систем с веб-сервером nginx.
Должна поддерживаться отправка событий аудита одного или всех изолированных пространств СЗВП на удаленный syslog-сервер.
Должны поддерживаться следующие атрибуты глобального списка:
• тип списка (статический или динамический);
• дата последнего изменения списка;
• статус применимости (доступен/недоступен для использования);
• количество IP адресов в списке;
• составные части схемы конфигурации, где применяется глобальный список.
Должны поддерживаться экспорт и импорт (в асинхронном режиме) конфигураций защиты веб приложений в формате JSON.
Должен поддерживаться контроль соответствия правила шаблону политики безопасности и отображение информации в веб-интерфейсе СЗВП в случае несоответствия.
Должно обеспечиваться ведение перечня ICAP-серверов, используемых СЗВП, с возможностью просмотра и редактирования их конфигураций.
Должна поддерживаться настройка режима автоматического декодирования запросов и ответов:
• для текущего изолированного пространства;
• всех изолированных пространств.
• Должна поддерживаться синхронизация параметров защиты между отдельными экземплярами СЗВП, в том числе:
• автоматизированная — с запуском вручную;
• автоматическая — с настройкой периодичности.
Должно обеспечиваться ведение перечня синхронизированных экземпляров СЗВП с фиксацией даты последнего запуска синхронизации и статуса завершения (Успешно/Не выполнена).
Должен поддерживаться экспорт параметров защиты синхронизированных экземпляров СЗВП.
Должно обеспечиваться ведение перечня экземпляров СЗВП, установленных в разных центрах обработки данных (в случае распределенной инфраструктуры СЗВП). |
|
|
|
Требования к СЗВП и структуре СЗВП в целом
Структура СЗВП должна соответствовать следующим требованиям:
1. Требования к составу СЗВП
В состав СЗВП должны входить следующие подсистемы:
• подсистема управления — предназначена для управления работой Kubernetes, работой СЗВП в целом, обеспечения обмена сообщениями между узлами, хранения данных об инцидентах и уязвимостях и неструктурированных данных (таких как отчеты и резервные копии);
• подсистема обработки веб-трафика — предназначена для обработки веб-трафика защищаемых веб-приложений.
2. Требования к способам и средствам связи для информационного обмена между компонентами СЗВП
К взаимодействию компонентов СЗВП предъявляются следующие требования:
Взаимодействие между компонентами СЗВП должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet.
Данные, передаваемые между компонентами СЗВП, должны быть защищены с использованием протокола TLS (на основе сертификатов).
3. Требования к характеристикам взаимосвязей создаваемой СЗВП со смежными системами
К взаимодействию СЗВП со смежными системами предъявляются следующие требования:
СЗВП должна иметь возможность взаимодействия со следующими системами:
• системой регистрации событий и выявления инцидентов информационной безопасности (системой класса SIEM) — для передачи сведений об обнаруженных угрозах;
• системой мониторинга — для передачи и визуализации собранных статистических данных;
• прочими смежными системами через REST API.
Взаимодействие с системами регистрации событий и выявления инцидентов информационной безопасности (SIEM системами) должно осуществляться по протоколу syslog (RFC 5424). |
|
|
|
Должна обеспечиваться возможность создания, удаления и скачивания резервных копий СЗВП, содержащих сведения о конфигурации системы, в том числе информацию о параметрах:
• контроля доступа;
• безопасности.
Должно обеспечиваться создание резервной копии для конфигурации СЗВП.
Должна обеспечиваться визуализация данных о событиях безопасности в виде таблицы и гистограммы.
Должна обеспечиваться возможность указания временного периода, за который отображаются события безопасности, зафиксированные СЗВП.
Должна обеспечиваться возможность обновления данных о событиях безопасности в автоматическом и автоматизированном режимах.
Должна обеспечиваться возможность менять размер и расположение столбцов таблиц событий, сворачивать и разворачивать таблицы, а также отменять пользовательские изменения нажатием кнопки.
Должен обеспечиваться просмотр общих сведений для всех событий, зафиксированных в журналах, а также просмотр подробных сведений для событий безопасности с возможностью перехода к настройкам параметров конфигурации, по которой зафиксировано событие.
Должна обеспечиваться возможность просмотра, копирования и скачивания исходного содержимого HTTP запроса, вызвавшего событие безопасности, и ответа на него, а также декодированного содержимого, если к HTTP запросу был применен алгоритм сжатия.
Должна обеспечиваться визуализация данных о событиях агрегации в виде таблицы. |
|
|
|
Общие технические требования к СЗВП
СЗВП должна соответствовать техническим требованиям:
1. Требования к защите информации от несанкционированного доступа (НСД)
В СЗВП должны быть реализованы следующие меры по защите информации от НСД:
• идентификация и аутентификация пользователей СЗВП;
• разграничение доступа к функциям СЗВП на основе ролей;
• журналирование действий пользователей СЗВП;
• возможность защиты резервных копий паролем.
• К паролю, используемому при аутентификации пользователей, предъявляются следующие требования:
• должен состоять не менее чем из 8 символов и не более чем из 64 символов;
• должен содержать хотя бы одну прописную букву латинского алфавита (от A до Z);
• должен содержать хотя бы одну строчную букву латинского алфавита (от a до z);
• должен содержать хотя бы одну цифру (от 0 до 9);
• не должен содержать букв других алфавитов кроме латинского;
• должен включать возможность использования спецсимволов.
• Должна поддерживаться безопасность учетных записей, в том числе настройкой:
• парольных политик;
• временной блокировки;
• постоянной блокировки;
• времени жизни пользовательской сессии.
Требования по сохранности информации при авариях
СЗВП должна обеспечивать возможность резервного копирования и восстановления параметров конфигураций основных компонентов СЗВП. |
|
|
|
IP адреса в нотации CIDR или доверенные подсети балансировщика или прокси сервера (при его наличии);
• действия с заголовками входящих HTTP-запросов.
Должна поддерживаться возможность добавления, изменения и удаления, защищаемых СЗВП серверов, а также редактирования их параметров.
СЗВП должна обеспечивать настройку взаимодействия с защищаемыми серверами, включающую в себя параметры:
• IP адрес или доменное имя защищаемого узла;
• номер порта;
• протокол, используемый для соединения с защищаемым сервером (HTTP, HTTPS);
• возможность использования сервера для обработки трафика.
СЗВП должна обеспечивать регистрацию выявленных событий безопасности на основе установленных правил обработки трафика (правил защиты веб приложения).
Должна поддерживаться агрегация повторяющихся событий безопасности, зарегистрированных одним правилом для одного IP адреса в рамках защиты веб приложения. Результаты агрегации должны регистрироваться в виде «событий агрегации».
Должна поддерживаться возможность создания, редактирования и удаления групп TLS сертификатов, предназначенных для обработки трафика HTTPS, а также загрузка групп TLS сертификатов из файлов формата PEM.
Должна поддерживаться возможность создания идентификатора для группы TLS сертификатов с указанием пароля (опционально).
Должна обеспечиваться возможность загрузки в СЗВП ключей TLS для расшифровки HTTPS трафика, отправляемого на защищаемые серверы. |
|
|
|
удаленное выполнение кода (RCE) в Apache Struts 2, связанное с ClassLoader (S2 020);
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с CookieInterceptor (S2-021);
• обход аутентификации в Microsoft Exchange Server;
• внедрение операторов LDAP в Joomla (версии ниже 3.8.0);
• удаленное выполнение кода (RCE) в Microsoft Exchange Server после аутентификации;
• ProxyShell в Microsoft Exchange Server;
• удаленное выполнение кода (RCE) в Microsoft Exchange Server;
• подделка запроса со стороны сервера (SSRF) Microsoft Exchange Server;
• повышение привилегий с помощью объекта PushSubscription в Microsoft Exchange Server;
• удаленное выполнение кода (RCE) в Microsoft Exchange Server, связанное с проверочным ключом;
• утечка информации в Microsoft SharePoint;
• удаленное выполнение кода (RCE) в Microsoft SharePoint Server 2019;
• открытое перенаправление в Apache Struts 2 (S2-017);
• удаленное выполнение кода (RCE) с помощью PHP FPM;
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с заголовком Content Disposition (S2-046);
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с функцией Dynamic Method Invocation (S2-032);
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с парсером Jakarta Multipart (S2-045);
• удаленное выполнение кода (RCE) в Apache Struts 2 (S2-016);
• удаленное выполнение кода (RCE) в vBulletin 5.0.0-5.6.2;
• внедрение произвольных аргументов в модуль PHP CGI;
• обход аутентификации в Backup Enterprise Manager;
• удаленное выполнение кода (RCE) в Confluence Data Center и Confluence Server;
• удаленное выполнение кода (RCE) в Grafana;
• удаленное выполнение кода (RCE) в Microsoft Outlook с помощью COM DLL;
защита от удаленного выполнения кода на серверах на базе React;
• защита от удаленного выполнения кода на сайтах под управлением «1С-Битрикс: Управление сайтом», созданных с использованием решений «Аспро»; |
|
|
|
Должна обеспечиваться возможность фильтрации зарегистрированных событий безопасности СЗВП по заданным условиям. Значение в строке фильтрации должно быть доступно для копирования.
Должна поддерживаться возможность сохранения условия фильтрации как личного пользовательского фильтра с возможностью просмотра, изменения и удаления только под учетной записью создателя.
Должна обеспечиваться возможность фильтрации зарегистрированных событий безопасности по значениям ключевых параметров:
• событие безопасности / правило;
• веб-приложение;
• код ответа;
• размер ответа;
• метод;
• URI;
• уровень опасности;
• фаза срабатывания правила;
• IP-адрес сервера и клиента;
• транзакция;
• ID правила;
• ОС клиента;
• браузер клиента;
• версия браузера клиента.
Должна обеспечиваться возможность фильтрации событий агрегации по критериям:
• IP адрес отправителя запроса;
• защищаемое веб приложение;
• событие безопасности, на котором произошло событие агрегации;
• IP адрес с действующим временем нахождения в глобальном динамическом списке (TTL).
Должна обеспечиваться возможность фильтрации внутренних событий СЗВП по критериям:
• IP-адрес;
• действие;
• незарегистрированный пользователь;
• объект;
• пользователь;
• тип объекта;
• уровень важности.
Должна обеспечиваться возможность поиска компонентов конфигурации системы в соответствующих блоках графического веб-интерфейса.
Должна поддерживаться возможность генерации отчетов о зафиксированных событиях безопасности. Отчеты должны быть доступны для удаления и выгрузки в форматах PDF, CSV. |
|
|
|
внедрение в поисковые запросы JNDI (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение в LDAP запросы (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение локальных файлов (LFI) (с настройкой проверяемых и пропускаемых частей запроса, с настройкой списка шаблонов для обнаружения важных файлов);
• внедрение в Memcached (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение NoSQL кода (с настройкой проверяемых и пропускаемых частей запроса);
• открытое перенаправление (Open Redirect) (с настройкой проверяемых и пропускаемых частей запроса, указанием режима проверки URL, обнаруживаемых типов перенаправления и возможностью перенаправления на поддомены URL адреса);
• внедрение команд ОС (с настройкой проверяемых, пропускаемых частей запроса, типов проверяемых ОС и метода обнаружения внедрения);
• выход за пределы каталога (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение объектов PHP (с настройкой проверяемых, пропускаемых частей запроса и обнаруживаемых PHP-функций);
• удаленное выполнение кода (RCE) в Apache Struts 2, связанное с режимом разработчика;
• удаленное выполнение кода (RCE), связанное с десериализацией параметров (с настройкой пропускаемых частей запроса);
• удаленное выполнение кода (RCE) в Ruby, связанное с десериализацией и цепочкой гаджетов (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение во включения на стороне сервера (SSI) (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение JavaScript кода на стороне сервера (SSJI) (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение в серверный шаблон (SSTI) (с настройкой проверяемых частей запроса, значения минимальной полезной нагрузки шаблона и списка небезопасных шаблонов HTML страниц);
• внедрение XPath кода (с настройкой проверяемых и пропускаемых частей запроса);
• внедрение XSLT на стороне сервера (с настройкой проверяемых и пропускаемых частей запроса); |
|
|
|
4. Требования к режимам функционирования СЗВП
СЗВП должна иметь указанные режимы функционирования:
• штатный — режим функционирования СЗВП, при котором поддерживается выполнение всех заявленных функций;
• технологический — режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модификации СЗВП;
• аварийный — режим функционирования при обнаружении сбоев и отказов в работе СЗВП, ее отдельных подсистем или поддерживающей инфраструктуры.
Функционирование СЗВП в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме.
5. Требования по обеспечению отказоустойчивости
Отказоустойчивость СЗВП должна обеспечиваться посредством использования:
• отказоустойчивых конфигураций (кластеров) ТС Заказчика;
• возможностей системы оркестрации Kubernetes;
• возможности резервирования подключений ТС Заказчика к источникам бесперебойного питания.
СЗВП должна поддерживать возможность работы в режиме отказоустойчивого кластера.
6. Требования по диагностированию СЗВП
Должны предусматриваться механизмы диагностирования неисправностей в процессе установки ПО СЗВП.
СЗВП должна обеспечивать диагностику состояния своих подсистем и предоставлять сведения:
• об общем состоянии СЗВП;
• состоянии СЗВП на каждом узле Заказчика;
• состоянии каждого из сервисов СЗВП.
СЗВП должна оценивать объем потребляемых аппаратно программных ресурсов на каждом узле Заказчика с установленными компонентами СЗВП и предоставлять сведения:
• о загрузке ресурсов ЦПУ;
• объеме используемой оперативной памяти;
• величине средней загрузки СЗВП (определяется как количество вычислительных операций, выполняемых СЗВП за минуту);
• нагрузке на дисковую подсистему узла (определяется как количество прочитанных и записанных данных за секунду);
• нагрузке на сеть.
7. Требования к показателям назначения
Должна обеспечиваться веб трафика с пропускной способностью СЗВП не менее 500 Мбит/с. При этом количество запросов в секунду (RPS) должно составлять не менее 5000. |
|
|
| Класс программ для электронных вычислительных машин и баз данных |
(03.03) Межсетевые экраны |
|
|
| Способ предоставления |
Экземпляр на материальном носителе |
|
|
| Комплектация |
Сертифицированные дистрибутивы ПО.
Комплекты документации в электронном виде по инсталляции и работе с ПО.
Формуляры.
Заверенные копии сертификатов ФСТЭК России. |
|
|
| Вид лицензии |
Простая (неисключительная) |
|
|
| Товарный знак |
Positive Technologies |
|
|
Показать всё
Скрыть
|
Зарегистрироваться
Войти
Все сервисы
