Номер извещения: 0851200000626005559

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: ЭТП Газпромбанк

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: https://etpgpb.ru/

Размещение осуществляет: Уполномоченное учреждение ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "УПРАВЛЕНИЕ КОНТРАКТНОЙ СИСТЕМЫ"

Наименование объекта закупки: Оказание услуг по предоставлению (передаче) права использования на условиях простой (неисключительной) лицензии программного обеспечения межсетевого экранирования уровня веб-приложений для Территориального фонда обязательного медицинского страхования Новосибирской области

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202602511000008001000027

Контактная информация

Размещение осуществляет: Уполномоченное учреждение

Организация, осуществляющая размещение: ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "УПРАВЛЕНИЕ КОНТРАКТНОЙ СИСТЕМЫ"

Почтовый адрес: 630005, Новосибирская область , Г НОВОСИБИРСК, УЛ ФРУНЗЕ, ЗД. 88, ОФИС 401

Место нахождения: 630005, Новосибирская область , Г НОВОСИБИРСК, УЛ ФРУНЗЕ, ЗД. 88, ОФИС 401

Ответственное должностное лицо: Пасикан А. С.

Адрес электронной почты: uksis@zakaznso.ru

Номер контактного телефона: 8-383-2387272-6075

Дополнительная информация: Информация отсутствует

Регион: Новосибирская обл

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 20.08.2026 11:41 (МСК+4)

Дата и время окончания срока подачи заявок: 28.08.2026 08:00 (МСК+4)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 28.08.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 01.09.2026

Начальная (максимальная) цена контрактов

Начальная (максимальная) цена контракта: 3 471 722,10

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 261540601901954060100100300015829242

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 58.29.50.000 58.29.11.000-00000003 - Программное обеспечение Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (02.08) Средства мониторинга и управления Способ предоставления Копия электронного экземпляра - Штука - 1,00 - 3 471 722,10 - 3 471 722,10

ТЕРРИТОРИАЛЬНЫЙ ФОНД ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ НОВОСИБИРСКОЙ ОБЛАСТИ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Вид лицензии Простая (неисключительная) Класс программ для электронных вычислительных машин и баз данных (02.08) Средства мониторинга и управления Способ предоставления Копия электронного экземпляра Состав ПО ПО состоит из следующих функциональных блоков:- обнаружения и защиты от атак на приложения;- активной перепроверки атак;- пассивного анализа; - активного сканирования внешнего периметра сети (для поиска уязвимостей);- интеграции со сторонними решениями;- облачной аналитики;- расширенных конфигураций;- управления;- защиты от поведенческих атак. Режимы работы ПО ПО обеспечивает работу в следующих режимах:- Режим обратного прокси сервера. ПО может терминировать и пересылать трафик между клиентами и защищаемыми веб-серверами. В зависимости от применяемых политик безопасности трафик может пересылаться без модификаций, либо может быть заблокирован.- Режим анализа зеркалированного трафика. ПО может обнаружить потенциальные угрозы на основе копии входящего http-трафика и информировать о них используемые Заказчиком другие компоненты системы безопасности. Функциональность ПО ПО обладает следующими функциями: - Обнаружение и блокировка атак нулевого дня при помощи алгоритмов машинного обучения. - Фильтрация сетевого трафика при помощи анализа контента на основании анализа содержимого отдельных элементов HTTP-запросов. Помимо стандартного HTTP протокола поддержка и фильтрация трафика современных протоколов, таких как: WebSockets, gRPC, SOAP, GraphQL. - Защита от распространенных уязвимостей и угроз по классификациям OWASP, OWASP API. - Анализ трафика, содержащего XML, JSON, GZIP, BASE64 и другие форматы передачи данных на современных порталах, API, мобильных приложениях, для интерпретации данных согласно бизнес-логике приложений. - Разграничение информации в общем потоке событий по приоритетам на основе идентифицированных особенностей приложений, уязвимостей, отслеживания пользователей и истории атак и хакерских запросов. - Противодействие автоматизированным атакам, включающие защиту от подбора пароля, DDoS-атак уровня приложений и утечек данных. - Защита приложений любого масштаба с учетом спецификации инфраструктуры организации. - Журналирование событий информационной безопасности. - Поиск сервисов и приложений во внешнем сетевом периметре. - Повторная проверка уязвимостей, фиксируемых в трафике. - Наличие белых, серых и черных списков ip-адресов. - Наличие гибкого управления правами пользователей, имеющих доступ к личному кабинету и API. - Преднастроенная ролевая модель доступа с возможностью её изменения. - Поддержка возможности разграничения обработки трафика различных приложений или организаций логически независимых друг от друга (мультитенантость). - Возможность подключения собственного источника данных об IP-адресах. - Проведение тестовых запусков правил основанных на применении регулярных выражений для оценки их работы и потенциального влияния на трафик в безопасном режиме. - Анализ ответов веб-сервера. - Возможность обнаруживать в ответах веб-сервера потенциально уязвимые cookie. Архитектура ПО - ПО должно иметь модульную архитектуру и учитывать существующую инфраструктуру веб¬приложений Заказчика; - Фильтрующие узлы ПО должны находиться строго в инфраструктуре Заказчика; - ПО должно поддерживать развертывание модуля обнаружения и защиты от атак на приложения с использованием преднастроенных образов для систем виртуализации, аппаратных серверных платформ. Интерфейсы управления ПО - ПО должно предоставлять интерфейс управления для централизованной конфигурации и распространения единых политик безопасности на соответствующие компоненты ПО; - ПО должно иметь возможность интеграции с внешними системами, в частности предоставлять универсальный REST API для внешнего управления ПО, который обеспечивает те же функции управления, что и штатный интерфейс управления; - Управление ПО должно осуществляться с автоматизированных рабочих мест персонала Заказчика посредством актуальных версий современных веб-браузеров; - Управление ПО должно быть реализовано с применением механизмов, обеспечивающих возможность централизованного управления всеми компонентами и модулями вне зависимости от места их размещения. Масштабируемость ПО - ПО должно иметь возможность масштабирования, и допускать наращивание производительности за счет увеличения количества или улучшения характеристик используемых в его составе технических средств; - ПО должно обеспечивать возможность обновления мажорных и минорных версий; - ПО должно позволять установку неограниченного количества фильтрующих узлов и централизованное управление решением на всех развернутых узлах в независимости от их версий - Системные требования к ПО - ПО должно быть полностью совместимо и функционировать на операционных системах с открытым исходным кодом; - Для хранения данных в ПО должна использоваться СУБД полностью совместимая с операционной системой с открытым исходным кодом; - ПО должно быть совместимо с операционными системами российских разработчиков (RedOS, Alt Linux, Astra Linux); - ПО должно быть совместимо с российскими веб-серверами (Angie); - ПО должно поддерживать установку в Kubernetes кластерах (Nginx Ingress); - ПО должно иметь возможность быть развернуто на следующих средствах автоматизации: контейнерные среды (Docker, Kubernetes) и инструменты управления конфигурацией, такие как Ansible, Puppet, Terraform или их аналоги. Развертывание должно быть полностью автоматизировано для обеспечения повторяемости и удобства масштабирования; - ПО должно быть совместимо с оркестраторами контейнеров, предоставлять возможность развёртывания с использованием Helm-чартов, YAML- манифестов или других стандартных инструментов Kubernetes. - Защита информации от несанкционированного доступа - При работе с ПО должна использоваться защита от несанкционированного доступа, от попыток изменения и уничтожения информации; - В ПО должна быть реализована ролевая модель доступа, позволяющая разграничить права доступа в ПО в соответствии с назначенной ему ролью; - ПО должно предоставлять поддержку и организацию политик разграничения доступа к интерфейсам управления, а также регистрацию и предотвращение попыток несанкционированного доступа к ним. Аутентификация персонала, при доступе к ПО должна выполняться на основе имени учетной записи и пароля. Дополнительно контроль доступа к ПО должен иметь возможность усиления с использованием двухфакторной аутентификации персонала на базе протокола ОТР. ПО должно предоставлять функцию аудита действий пользователей в соответствии с назначенными им ролями; - В ПО должны быть предусмотрены следующие наборы прав: - доступ ко всем действиям с ПО; - доступ к информации об атаках, инцидентах и уязвимостях, просмотр основных настроек ПО; - доступ к просмотру основных настроек ПО; - доступ для операций развертывания, без доступа к консоли управления. - В ПО должна быть реализована возможность устанавливать гранулированный доступ для пользователей системы к различным разделам и функционалу ПО в соответствии с необходимой моделью доступа разделяя права на изменение, создание, просмотр и удаление сущностей; - В ПО должна быть доступна система логического разделения доступа к приложениям с обеспечением независимых режимов работы, наборов правил, состава сотрудников и их прав доступа (мультитенантность). Требования к блокам ПО ПО должно состоять из нескольких блоков, интегрированных и взаимодействующих между собой, а также обеспечивающих выполнение заданных функций; Требования к блоку обнаружения и защиты атак на приложения: Блок обнаружения и защиты от атак на приложения должен выполнять глубокую инспекцию пакетов HTTP-трафика, поступающего к защищаемым приложениям, принимая решения о необходимости блокирования запроса; Блок в режиме реального времени должен активировать проверку на наличие уязвимостей, доступных для эксплуатации, для запрашиваемого URI; Блок должен позволять идентифицировать 1Р-адрес, браузер и связанную с ними активность для обнаружения программ-роботов и автоматизированных инструментов;Блок должен поддерживать одновременную работу с веб-приложениями разных типов, опубликованные на различных доменах, использующие различные технологии, а также реализованные в виде API; Блок должен поддерживать различные протоколы, технологии и методы кодирования данных:- НТТР/0.9, НТТР/1.0, HTTP/1.1, НТТР/2, НТТР/3, WebSocket, GRPC, GraphQL;- XML, SOAP, JSON; HTMLForm, HTMLMultipartForm, ViewState;- gZIP, Base64, Percent Encoding, URL encoding (включая non-RFC варианты для PHP, Java, Apache, IIS, FastCGI и др.); Поддержка декодирования, нормализации и токенизации для вложенных типов данных, например обнаружение вектора атаки в ЬазебД-данных внутри JSON, использующем Unicode-кодирование, использующем HTMLMultipartForm; Парсинг данных внутри WebSocket соединений с учетом вложенных кодировок (json, gzip, xml) для обнаружения и блокировки атак. Требования к модулю активной перепроверки атак Модуль должен осуществлять поиск уязвимостей веб¬приложений с учётом данных о аномальных запросах, поступающих на модуль мониторинга и фильтрации путём перепроверки атак с использованием модифицированных запросов. В результате обнаружения уязвимостей должны заводиться инциденты и производиться уведомление персонала посредством сообщений электронной почты и средств доставки мгновенных сообщений. Модуль должен обеспечивать такие способы перепроверки как: Обнаружение Blind SQL-инъекций или OOB-DNS;Обнаружение Error Based SQL-инъекций;Обнаружение RCE по времени ответа сервера или OOB-DNS;Выявление ошибок при получении невалидного юникода;Обнаружение уязвимостей типа Path Traversal;Обнаружение ХХЕ с помощью OOB-DNS;Обнаружение уязвимостей типа XSS;Обнаружение уязвимостей типа Stored XSS с помощью OOB-DNS; Обнаружение уязвимостей SSRF. Требования к модулю пассивного детектирования Модуль пассивного сканирования должен проводить анализ ответов, поступающих от защищаемых приложений, с целью выявления попыток эксплуатации уязвимостей, а также обнаружения утечек чувствительной информации. Должен проводиться двусторонний анализ потока информации между клиентом и защищаемым веб-сервером; Модуль должен выполнять сбор статистических данных входящего HTTP-трафика и их первичный анализ. Собранная статистика должна использоваться для выявления атак типа Brute Force и Credential Stuffing. Полученные данных также должны использоваться для профилирования защищаемых приложений и формирования признаков для нахождения аномалий в действиях пользователей и работе приложений. Требования к модулю активного сканирования внешнего периметра сети (для поиска уязвимостей) Модуль должен проводить автоматический анализ состава сетевого периметра инфраструктуры Заказчика, доступной из публичных сетей. На основе полученной информации модуль должен выполнять обнаружение известных уязвимостей сетевых сервисов на основе публичных CVE, а также распознавать ошибки в настройках и конфигурациях, приводящих к раскрытию технической информации, осуществлению неавторизованного доступа, нарушению конфиденциальности, утечкам данных, таких как: Несанкционированный доступ к репозиториям сходных кодов git, bitbucket и subversion; Обнаружение слабых пар логин/пароль для популярных СУБД (MySQL, PostgreSQL); Анонимный доступ к Elasticsearch, Redis, MongoDB; Обнаружение раскрытия технической информации (например веб-панель Adminer, страница apache server status; файлы .bash history; страница списка файлов на URL; веб-панель Grafana; веб-панель Munin; веб-панель pgAdmin; страница phpinfo; приватный RSA ключ; все файлы text/plain или application/octet-stream; веб-панель Zabbix); Перебор стандартных пар логин и пароль для следующих протоколов и приложений: FTP, LDAP, Memcached, MongoDB, MySQL, PostgreSQL, Redis, Xll. Требования к блоку интеграции со сторонними решениями ПО должно иметь интерфейсы интеграции со сторонними решениями посредством REST API, протоколов syslog, snmp, webhook. Для борьбы с DDoS- атаками ПО должно обеспечивать механизмы выгрузки и управления перечнями задействованных в атаке IP-адресов; ПО должно иметь возможности интеграции с e-mail системой и мессенджерами (Slack, Mattermost, Telegram) для осуществления оперативного информирования пользователей ПО о различных системных или иных событиях, а также предоставлять возможность получения периодических отчетов; ПО должно иметь возможность интеграции с имеющимся SIEM-решением, выбранным специалистами Заказчика. Требования к блоку аналитики Блок должен отвечать за дополнительную обработку данных, поступающих от модуля обнаружения и защиты от атак на приложения, агрегацию данных, поступающих со всех устройств ПО, а также производить дополнительный анализ данных в асинхронном режиме для выявления корреляций между отдельными вредоносными запросами, индексацию и подготовку данных для их представления в модуле управления. ПО должно постоянно отслеживать структуру и параметры приложений для обнаружения обычных атак и атак нулевого дня при помощи самообучающихся алгоритмов искусственного интеллекта. Модуль должен выполнять динамическое формирование правил обнаружения атак и подстраивать их под защищаемые приложения, снижая количество ложных срабатываний; Блок должен быть реализован в виде внешней компоненты, размещённой на территории Российской Федерации. Требования к блоку расширенных конфигураций Блок должен обеспечивать выполнение функции виртуального патчинга защищаемого веб-приложения, позволяющего блокировать вредоносные запросы при работе ПО в режиме мониторинга или когда в запросе не обнаружен какой-либо из известных векторов атак; Блок должен поддерживать добавление дополнительных произвольных сигнатур, основанных на регулярных выражениях с учётом вариативностей, обеспечивающих гибкость применения правил, а также задание правил маскирования конфиденциальных данных в сериализованных запросах. Требования к блоку управления Блок управления должен предоставлять интерфейс для доступа к информации об атаках, инцидентах, уязвимостях, правилам политик безопасности, параметрам режима работы компонентов, мониторингу и статистике работы ПО. Требования к модулю защиты от поведенческих атак Модуль должен выполнять функции работы с репутационными списками для защиты от поведенческих атак, а также защита против автоматизированного сбора данных и подбора URL и должен обнаруживать подозрительную активность пользователей или приложений; Модуль должен обеспечивать возможность автоматического и ручного формирования чёрных списков IP-адресов нарушителей политик безопасности с возможностью временной или постоянной блокировки. ПО должно иметь возможность формирования белых списков IP-адресов, для которых будут выполняться исключения в применении политик безопасности. Должна присутствовать возможность формирования серых списков IP-адресов, которым будет разрешен доступ к приложениям, только если в запросах нет признаков атак; Списки должны поддерживать указание отдельных IP- адресов или подсетей в формате CIDR. Должна быть возможность подключения собственного источника данных об IP-адресах; Управление списками должно осуществляться из интерфейса управления, а также посредством интеграции со сторонними средствами с использованием API системы. Дополнительные требования к модулям Мониторинг и фильтрация запросов должны осуществляться для протоколов HTTP и HTTPS, gRPC, WebSocket; ПО должно осуществлять обнаружение следующих классов и типов атак: HTTP-атаки, включая атаки на переполнение буфера; атаки на подбор пароля перебором вариантов (Brute Force); атаки на перебор директорий и файлов (Dirbust); атаки межсайтового выполнения сценариев (Cross Site Scripting); атаки НРР (HTTP Parameter Pollution - смешивание («загрязнение») границ HTTP-параметров); атаки на внешние сущности XML (XML external Entity); атаки, основанные на внедрении в запрос произвольного SQL-кода (SQL Injection); атаки, связанные с манипуляциями с XML файлами (XQuery Injection); атаки на использование локальных системных файлов сервера (LFI - Local File Inclusion); атаки на выполнение удаленного файла (RFI - Remote File Inclusion); атаки, связанные с уязвимостями в HTTP-Verb аутентификации и механизмах контроля доступа (HTTP Verb Tampering); атаки выполнение команд ОС (OS commanding, RCE); атаки обхода каталога (Path Traversal); атаки типа открытое перенаправление (Open redirect); другие атаки различных типов и классов, включая (crlf, nosqli, Idap-inj, ssti, ssi, mailinjection, ssrf, mass assignment, scanner). Дополнительные требования ПО должно поддерживать защиту приложений, выполненных по технологии SPA (Single Page Application) с использованием технологии HTML5; В обычном состоянии ПО должно функционировать в режиме негативной модели безопасности, т. е. пропускать все запросы, кроме распознанных как атаки; Число ложных срабатываний (false positive) по событиям, связанным со всеми атаками на веб-приложения, не должно превышать 1% от общего числа событий срабатывания по всем атакам; ПО должно осуществлять обнаружение сетевых атак посредством сопоставления параметров веб-запросов правилам, а также посредством сопоставления характеристик веб-запросов с характеристиками аналогичных веб-запросов, полученных ранее; Используемый ПО механизм выявления атак должен иметь функции непрерывного профилирования веб-приложения (без необходимости переводить подсистему в особый режим обучения) и корректировки полученной модели администратором ПО; ПО должно предоставлять Оператору возможность определить, по какой причине трафик был классифицирован как вредоносный, а также предоставлять Оператору возможность быстрого исправления ложных срабатываний с обновлением профиля приложения, без ручной перенастройки правил обнаружения и блокировки атак; ПО должно блокировать атаки следующими способами: путем перехвата и блокирования («неотправки») частей трафика к веб-приложению; путем блокирования соединения клиента с веб-приложением; Работа с графическим интерфейсом модуля управления должно осуществляться посредством современных версий веб-браузеров. Дополнительные требования к ПО ПО должно иметь следующие механизмы управления событиями, связанными с атаками: механизм фильтрации событий (по приоритету, типу события); механизм агрегирования (группировка однотипных событий); механизм приоритизации (по приоритету, типу события). ПО должно поддерживать генерацию, рассылку и выгрузку отчетов в открытых форматах (например, *.pdf); ПО должно поддерживать систему управления триггерами, посредством которых можно настроить различные оповещения о появлении инцидентов, уязвимостей, атак. Уведомления по триггерам должны поступать посредством различных каналов связи (email, популярные мессенджеры); Интерфейс ПО должен содержать в себе интерактивные динамические дашборды с информацией об инцидентах, уязвимостях, атаках, картой источников атак, статистические данные о количестве и степени критичности. Требования к показателям назначения ПО Суммарное количество HTTP/HTTPS запросов за месяц не превышает 1,2 млрд.; ПО должно обеспечивать защиту до 10 приложений/доменов. Иные требования к ПО ПО не должно приводить к снижению параметров производительности и нарушению работы защищаемых веб-ресурсов; Интерфейс ПО и формируемые ею отчеты должны быть на русском языке. - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Вид лицензии - Простая (неисключительная) - - Класс программ для электронных вычислительных машин и баз данных - (02.08) Средства мониторинга и управления - - Способ предоставления - Копия электронного экземпляра - - Состав ПО - ПО состоит из следующих функциональных блоков:- обнаружения и защиты от атак на приложения;- активной перепроверки атак;- пассивного анализа; - активного сканирования внешнего периметра сети (для поиска уязвимостей);- интеграции со сторонними решениями;- облачной аналитики;- расширенных конфигураций;- управления;- защиты от поведенческих атак. - - Режимы работы ПО - ПО обеспечивает работу в следующих режимах:- Режим обратного прокси сервера. ПО может терминировать и пересылать трафик между клиентами и защищаемыми веб-серверами. В зависимости от применяемых политик безопасности трафик может пересылаться без модификаций, либо может быть заблокирован.- Режим анализа зеркалированного трафика. ПО может обнаружить потенциальные угрозы на основе копии входящего http-трафика и информировать о них используемые Заказчиком другие компоненты системы безопасности. - - Функциональность ПО - ПО обладает следующими функциями: - Обнаружение и блокировка атак нулевого дня при помощи алгоритмов машинного обучения. - Фильтрация сетевого трафика при помощи анализа контента на основании анализа содержимого отдельных элементов HTTP-запросов. Помимо стандартного HTTP протокола поддержка и фильтрация трафика современных протоколов, таких как: WebSockets, gRPC, SOAP, GraphQL. - Защита от распространенных уязвимостей и угроз по классификациям OWASP, OWASP API. - Анализ трафика, содержащего XML, JSON, GZIP, BASE64 и другие форматы передачи данных на современных порталах, API, мобильных приложениях, для интерпретации данных согласно бизнес-логике приложений. - Разграничение информации в общем потоке событий по приоритетам на основе идентифицированных особенностей приложений, уязвимостей, отслеживания пользователей и истории атак и хакерских запросов. - Противодействие автоматизированным атакам, включающие защиту от подбора пароля, DDoS-атак уровня приложений и утечек данных. - Защита приложений любого масштаба с учетом спецификации инфраструктуры организации. - Журналирование событий информационной безопасности. - Поиск сервисов и приложений во внешнем сетевом периметре. - Повторная проверка уязвимостей, фиксируемых в трафике. - Наличие белых, серых и черных списков ip-адресов. - Наличие гибкого управления правами пользователей, имеющих доступ к личному кабинету и API. - Преднастроенная ролевая модель доступа с возможностью её изменения. - Поддержка возможности разграничения обработки трафика различных приложений или организаций логически независимых друг от друга (мультитенантость). - Возможность подключения собственного источника данных об IP-адресах. - Проведение тестовых запусков правил основанных на применении регулярных выражений для оценки их работы и потенциального влияния на трафик в безопасном режиме. - Анализ ответов веб-сервера. - Возможность обнаруживать в ответах веб-сервера потенциально уязвимые cookie. - - Архитектура ПО - - ПО должно иметь модульную архитектуру и учитывать существующую инфраструктуру веб¬приложений Заказчика; - Фильтрующие узлы ПО должны находиться строго в инфраструктуре Заказчика; - ПО должно поддерживать развертывание модуля обнаружения и защиты от атак на приложения с использованием преднастроенных образов для систем виртуализации, аппаратных серверных платформ. - - Интерфейсы управления ПО - - ПО должно предоставлять интерфейс управления для централизованной конфигурации и распространения единых политик безопасности на соответствующие компоненты ПО; - ПО должно иметь возможность интеграции с внешними системами, в частности предоставлять универсальный REST API для внешнего управления ПО, который обеспечивает те же функции управления, что и штатный интерфейс управления; - Управление ПО должно осуществляться с автоматизированных рабочих мест персонала Заказчика посредством актуальных версий современных веб-браузеров; - Управление ПО должно быть реализовано с применением механизмов, обеспечивающих возможность централизованного управления всеми компонентами и модулями вне зависимости от места их размещения. - - Масштабируемость ПО - - ПО должно иметь возможность масштабирования, и допускать наращивание производительности за счет увеличения количества или улучшения характеристик используемых в его составе технических средств; - ПО должно обеспечивать возможность обновления мажорных и минорных версий; - ПО должно позволять установку неограниченного количества фильтрующих узлов и централизованное управление решением на всех развернутых узлах в независимости от их версий - - - Системные требования к ПО - - ПО должно быть полностью совместимо и функционировать на операционных системах с открытым исходным кодом; - Для хранения данных в ПО должна использоваться СУБД полностью совместимая с операционной системой с открытым исходным кодом; - ПО должно быть совместимо с операционными системами российских разработчиков (RedOS, Alt Linux, Astra Linux); - ПО должно быть совместимо с российскими веб-серверами (Angie); - ПО должно поддерживать установку в Kubernetes кластерах (Nginx Ingress); - ПО должно иметь возможность быть развернуто на следующих средствах автоматизации: контейнерные среды (Docker, Kubernetes) и инструменты управления конфигурацией, такие как Ansible, Puppet, Terraform или их аналоги. Развертывание должно быть полностью автоматизировано для обеспечения повторяемости и удобства масштабирования; - ПО должно быть совместимо с оркестраторами контейнеров, предоставлять возможность развёртывания с использованием Helm-чартов, YAML- манифестов или других стандартных инструментов Kubernetes. - - - Защита информации от несанкционированного доступа - - При работе с ПО должна использоваться защита от несанкционированного доступа, от попыток изменения и уничтожения информации; - В ПО должна быть реализована ролевая модель доступа, позволяющая разграничить права доступа в ПО в соответствии с назначенной ему ролью; - ПО должно предоставлять поддержку и организацию политик разграничения доступа к интерфейсам управления, а также регистрацию и предотвращение попыток несанкционированного доступа к ним. Аутентификация персонала, при доступе к ПО должна выполняться на основе имени учетной записи и пароля. Дополнительно контроль доступа к ПО должен иметь возможность усиления с использованием двухфакторной аутентификации персонала на базе протокола ОТР. ПО должно предоставлять функцию аудита действий пользователей в соответствии с назначенными им ролями; - В ПО должны быть предусмотрены следующие наборы прав: - доступ ко всем действиям с ПО; - доступ к информации об атаках, инцидентах и уязвимостях, просмотр основных настроек ПО; - доступ к просмотру основных настроек ПО; - доступ для операций развертывания, без доступа к консоли управления. - В ПО должна быть реализована возможность устанавливать гранулированный доступ для пользователей системы к различным разделам и функционалу ПО в соответствии с необходимой моделью доступа разделяя права на изменение, создание, просмотр и удаление сущностей; - В ПО должна быть доступна система логического разделения доступа к приложениям с обеспечением независимых режимов работы, наборов правил, состава сотрудников и их прав доступа (мультитенантность). - - Требования к блокам ПО - ПО должно состоять из нескольких блоков, интегрированных и взаимодействующих между собой, а также обеспечивающих выполнение заданных функций; Требования к блоку обнаружения и защиты атак на приложения: Блок обнаружения и защиты от атак на приложения должен выполнять глубокую инспекцию пакетов HTTP-трафика, поступающего к защищаемым приложениям, принимая решения о необходимости блокирования запроса; Блок в режиме реального времени должен активировать проверку на наличие уязвимостей, доступных для эксплуатации, для запрашиваемого URI; Блок должен позволять идентифицировать 1Р-адрес, браузер и связанную с ними активность для обнаружения программ-роботов и автоматизированных инструментов;Блок должен поддерживать одновременную работу с веб-приложениями разных типов, опубликованные на различных доменах, использующие различные технологии, а также реализованные в виде API; Блок должен поддерживать различные протоколы, технологии и методы кодирования данных:- НТТР/0.9, НТТР/1.0, HTTP/1.1, НТТР/2, НТТР/3, WebSocket, GRPC, GraphQL;- XML, SOAP, JSON; HTMLForm, HTMLMultipartForm, ViewState;- gZIP, Base64, Percent Encoding, URL encoding (включая non-RFC варианты для PHP, Java, Apache, IIS, FastCGI и др.); Поддержка декодирования, нормализации и токенизации для вложенных типов данных, например обнаружение вектора атаки в ЬазебД-данных внутри JSON, использующем Unicode-кодирование, использующем HTMLMultipartForm; Парсинг данных внутри WebSocket соединений с учетом вложенных кодировок (json, gzip, xml) для обнаружения и блокировки атак. - - Требования к модулю активной перепроверки атак - Модуль должен осуществлять поиск уязвимостей веб¬приложений с учётом данных о аномальных запросах, поступающих на модуль мониторинга и фильтрации путём перепроверки атак с использованием модифицированных запросов. В результате обнаружения уязвимостей должны заводиться инциденты и производиться уведомление персонала посредством сообщений электронной почты и средств доставки мгновенных сообщений. Модуль должен обеспечивать такие способы перепроверки как: Обнаружение Blind SQL-инъекций или OOB-DNS;Обнаружение Error Based SQL-инъекций;Обнаружение RCE по времени ответа сервера или OOB-DNS;Выявление ошибок при получении невалидного юникода;Обнаружение уязвимостей типа Path Traversal;Обнаружение ХХЕ с помощью OOB-DNS;Обнаружение уязвимостей типа XSS;Обнаружение уязвимостей типа Stored XSS с помощью OOB-DNS; Обнаружение уязвимостей SSRF. - - Требования к модулю пассивного детектирования - Модуль пассивного сканирования должен проводить анализ ответов, поступающих от защищаемых приложений, с целью выявления попыток эксплуатации уязвимостей, а также обнаружения утечек чувствительной информации. Должен проводиться двусторонний анализ потока информации между клиентом и защищаемым веб-сервером; Модуль должен выполнять сбор статистических данных входящего HTTP-трафика и их первичный анализ. Собранная статистика должна использоваться для выявления атак типа Brute Force и Credential Stuffing. Полученные данных также должны использоваться для профилирования защищаемых приложений и формирования признаков для нахождения аномалий в действиях пользователей и работе приложений. - - Требования к модулю активного сканирования внешнего периметра сети (для поиска уязвимостей) - Модуль должен проводить автоматический анализ состава сетевого периметра инфраструктуры Заказчика, доступной из публичных сетей. На основе полученной информации модуль должен выполнять обнаружение известных уязвимостей сетевых сервисов на основе публичных CVE, а также распознавать ошибки в настройках и конфигурациях, приводящих к раскрытию технической информации, осуществлению неавторизованного доступа, нарушению конфиденциальности, утечкам данных, таких как: Несанкционированный доступ к репозиториям сходных кодов git, bitbucket и subversion; Обнаружение слабых пар логин/пароль для популярных СУБД (MySQL, PostgreSQL); Анонимный доступ к Elasticsearch, Redis, MongoDB; Обнаружение раскрытия технической информации (например веб-панель Adminer, страница apache server status; файлы .bash history; страница списка файлов на URL; веб-панель Grafana; веб-панель Munin; веб-панель pgAdmin; страница phpinfo; приватный RSA ключ; все файлы text/plain или application/octet-stream; веб-панель Zabbix); Перебор стандартных пар логин и пароль для следующих протоколов и приложений: FTP, LDAP, Memcached, MongoDB, MySQL, PostgreSQL, Redis, Xll. - - Требования к блоку интеграции со сторонними решениями - ПО должно иметь интерфейсы интеграции со сторонними решениями посредством REST API, протоколов syslog, snmp, webhook. Для борьбы с DDoS- атаками ПО должно обеспечивать механизмы выгрузки и управления перечнями задействованных в атаке IP-адресов; ПО должно иметь возможности интеграции с e-mail системой и мессенджерами (Slack, Mattermost, Telegram) для осуществления оперативного информирования пользователей ПО о различных системных или иных событиях, а также предоставлять возможность получения периодических отчетов; ПО должно иметь возможность интеграции с имеющимся SIEM-решением, выбранным специалистами Заказчика. - - Требования к блоку аналитики - Блок должен отвечать за дополнительную обработку данных, поступающих от модуля обнаружения и защиты от атак на приложения, агрегацию данных, поступающих со всех устройств ПО, а также производить дополнительный анализ данных в асинхронном режиме для выявления корреляций между отдельными вредоносными запросами, индексацию и подготовку данных для их представления в модуле управления. ПО должно постоянно отслеживать структуру и параметры приложений для обнаружения обычных атак и атак нулевого дня при помощи самообучающихся алгоритмов искусственного интеллекта. Модуль должен выполнять динамическое формирование правил обнаружения атак и подстраивать их под защищаемые приложения, снижая количество ложных срабатываний; Блок должен быть реализован в виде внешней компоненты, размещённой на территории Российской Федерации. - - Требования к блоку расширенных конфигураций - Блок должен обеспечивать выполнение функции виртуального патчинга защищаемого веб-приложения, позволяющего блокировать вредоносные запросы при работе ПО в режиме мониторинга или когда в запросе не обнаружен какой-либо из известных векторов атак; Блок должен поддерживать добавление дополнительных произвольных сигнатур, основанных на регулярных выражениях с учётом вариативностей, обеспечивающих гибкость применения правил, а также задание правил маскирования конфиденциальных данных в сериализованных запросах. - - Требования к блоку управления - Блок управления должен предоставлять интерфейс для доступа к информации об атаках, инцидентах, уязвимостях, правилам политик безопасности, параметрам режима работы компонентов, мониторингу и статистике работы ПО. - - Требования к модулю защиты от поведенческих атак - Модуль должен выполнять функции работы с репутационными списками для защиты от поведенческих атак, а также защита против автоматизированного сбора данных и подбора URL и должен обнаруживать подозрительную активность пользователей или приложений; Модуль должен обеспечивать возможность автоматического и ручного формирования чёрных списков IP-адресов нарушителей политик безопасности с возможностью временной или постоянной блокировки. ПО должно иметь возможность формирования белых списков IP-адресов, для которых будут выполняться исключения в применении политик безопасности. Должна присутствовать возможность формирования серых списков IP-адресов, которым будет разрешен доступ к приложениям, только если в запросах нет признаков атак; Списки должны поддерживать указание отдельных IP- адресов или подсетей в формате CIDR. Должна быть возможность подключения собственного источника данных об IP-адресах; Управление списками должно осуществляться из интерфейса управления, а также посредством интеграции со сторонними средствами с использованием API системы. - - Дополнительные требования к модулям - Мониторинг и фильтрация запросов должны осуществляться для протоколов HTTP и HTTPS, gRPC, WebSocket; ПО должно осуществлять обнаружение следующих классов и типов атак: HTTP-атаки, включая атаки на переполнение буфера; атаки на подбор пароля перебором вариантов (Brute Force); атаки на перебор директорий и файлов (Dirbust); атаки межсайтового выполнения сценариев (Cross Site Scripting); атаки НРР (HTTP Parameter Pollution - смешивание («загрязнение») границ HTTP-параметров); атаки на внешние сущности XML (XML external Entity); атаки, основанные на внедрении в запрос произвольного SQL-кода (SQL Injection); атаки, связанные с манипуляциями с XML файлами (XQuery Injection); атаки на использование локальных системных файлов сервера (LFI - Local File Inclusion); атаки на выполнение удаленного файла (RFI - Remote File Inclusion); атаки, связанные с уязвимостями в HTTP-Verb аутентификации и механизмах контроля доступа (HTTP Verb Tampering); атаки выполнение команд ОС (OS commanding, RCE); атаки обхода каталога (Path Traversal); атаки типа открытое перенаправление (Open redirect); другие атаки различных типов и классов, включая (crlf, nosqli, Idap-inj, ssti, ssi, mailinjection, ssrf, mass assignment, scanner). - - Дополнительные требования - ПО должно поддерживать защиту приложений, выполненных по технологии SPA (Single Page Application) с использованием технологии HTML5; В обычном состоянии ПО должно функционировать в режиме негативной модели безопасности, т. е. пропускать все запросы, кроме распознанных как атаки; Число ложных срабатываний (false positive) по событиям, связанным со всеми атаками на веб-приложения, не должно превышать 1% от общего числа событий срабатывания по всем атакам; ПО должно осуществлять обнаружение сетевых атак посредством сопоставления параметров веб-запросов правилам, а также посредством сопоставления характеристик веб-запросов с характеристиками аналогичных веб-запросов, полученных ранее; Используемый ПО механизм выявления атак должен иметь функции непрерывного профилирования веб-приложения (без необходимости переводить подсистему в особый режим обучения) и корректировки полученной модели администратором ПО; ПО должно предоставлять Оператору возможность определить, по какой причине трафик был классифицирован как вредоносный, а также предоставлять Оператору возможность быстрого исправления ложных срабатываний с обновлением профиля приложения, без ручной перенастройки правил обнаружения и блокировки атак; ПО должно блокировать атаки следующими способами: путем перехвата и блокирования («неотправки») частей трафика к веб-приложению; путем блокирования соединения клиента с веб-приложением; Работа с графическим интерфейсом модуля управления должно осуществляться посредством современных версий веб-браузеров. - - Дополнительные требования к ПО - ПО должно иметь следующие механизмы управления событиями, связанными с атаками: механизм фильтрации событий (по приоритету, типу события); механизм агрегирования (группировка однотипных событий); механизм приоритизации (по приоритету, типу события). ПО должно поддерживать генерацию, рассылку и выгрузку отчетов в открытых форматах (например, *.pdf); ПО должно поддерживать систему управления триггерами, посредством которых можно настроить различные оповещения о появлении инцидентов, уязвимостей, атак. Уведомления по триггерам должны поступать посредством различных каналов связи (email, популярные мессенджеры); Интерфейс ПО должен содержать в себе интерактивные динамические дашборды с информацией об инцидентах, уязвимостях, атаках, картой источников атак, статистические данные о количестве и степени критичности. - - Требования к показателям назначения ПО - Суммарное количество HTTP/HTTPS запросов за месяц не превышает 1,2 млрд.; ПО должно обеспечивать защиту до 10 приложений/доменов. - - Иные требования к ПО - ПО не должно приводить к снижению параметров производительности и нарушению работы защищаемых веб-ресурсов; Интерфейс ПО и формируемые ею отчеты должны быть на русском языке. -

Наименование характеристики - Значение характеристики - Единица измерения характеристики

Вид лицензии - Простая (неисключительная) -

Класс программ для электронных вычислительных машин и баз данных - (02.08) Средства мониторинга и управления -

Способ предоставления - Копия электронного экземпляра -

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

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

Функциональность ПО - ПО обладает следующими функциями: - Обнаружение и блокировка атак нулевого дня при помощи алгоритмов машинного обучения. - Фильтрация сетевого трафика при помощи анализа контента на основании анализа содержимого отдельных элементов HTTP-запросов. Помимо стандартного HTTP протокола поддержка и фильтрация трафика современных протоколов, таких как: WebSockets, gRPC, SOAP, GraphQL. - Защита от распространенных уязвимостей и угроз по классификациям OWASP, OWASP API. - Анализ трафика, содержащего XML, JSON, GZIP, BASE64 и другие форматы передачи данных на современных порталах, API, мобильных приложениях, для интерпретации данных согласно бизнес-логике приложений. - Разграничение информации в общем потоке событий по приоритетам на основе идентифицированных особенностей приложений, уязвимостей, отслеживания пользователей и истории атак и хакерских запросов. - Противодействие автоматизированным атакам, включающие защиту от подбора пароля, DDoS-атак уровня приложений и утечек данных. - Защита приложений любого масштаба с учетом спецификации инфраструктуры организации. - Журналирование событий информационной безопасности. - Поиск сервисов и приложений во внешнем сетевом периметре. - Повторная проверка уязвимостей, фиксируемых в трафике. - Наличие белых, серых и черных списков ip-адресов. - Наличие гибкого управления правами пользователей, имеющих доступ к личному кабинету и API. - Преднастроенная ролевая модель доступа с возможностью её изменения. - Поддержка возможности разграничения обработки трафика различных приложений или организаций логически независимых друг от друга (мультитенантость). - Возможность подключения собственного источника данных об IP-адресах. - Проведение тестовых запусков правил основанных на применении регулярных выражений для оценки их работы и потенциального влияния на трафик в безопасном режиме. - Анализ ответов веб-сервера. - Возможность обнаруживать в ответах веб-сервера потенциально уязвимые cookie. -

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

Интерфейсы управления ПО - - ПО должно предоставлять интерфейс управления для централизованной конфигурации и распространения единых политик безопасности на соответствующие компоненты ПО; - ПО должно иметь возможность интеграции с внешними системами, в частности предоставлять универсальный REST API для внешнего управления ПО, который обеспечивает те же функции управления, что и штатный интерфейс управления; - Управление ПО должно осуществляться с автоматизированных рабочих мест персонала Заказчика посредством актуальных версий современных веб-браузеров; - Управление ПО должно быть реализовано с применением механизмов, обеспечивающих возможность централизованного управления всеми компонентами и модулями вне зависимости от места их размещения. -

Масштабируемость ПО - - ПО должно иметь возможность масштабирования, и допускать наращивание производительности за счет увеличения количества или улучшения характеристик используемых в его составе технических средств; - ПО должно обеспечивать возможность обновления мажорных и минорных версий; - ПО должно позволять установку неограниченного количества фильтрующих узлов и централизованное управление решением на всех развернутых узлах в независимости от их версий - -

Системные требования к ПО - - ПО должно быть полностью совместимо и функционировать на операционных системах с открытым исходным кодом; - Для хранения данных в ПО должна использоваться СУБД полностью совместимая с операционной системой с открытым исходным кодом; - ПО должно быть совместимо с операционными системами российских разработчиков (RedOS, Alt Linux, Astra Linux); - ПО должно быть совместимо с российскими веб-серверами (Angie); - ПО должно поддерживать установку в Kubernetes кластерах (Nginx Ingress); - ПО должно иметь возможность быть развернуто на следующих средствах автоматизации: контейнерные среды (Docker, Kubernetes) и инструменты управления конфигурацией, такие как Ansible, Puppet, Terraform или их аналоги. Развертывание должно быть полностью автоматизировано для обеспечения повторяемости и удобства масштабирования; - ПО должно быть совместимо с оркестраторами контейнеров, предоставлять возможность развёртывания с использованием Helm-чартов, YAML- манифестов или других стандартных инструментов Kubernetes. - -

Защита информации от несанкционированного доступа - - При работе с ПО должна использоваться защита от несанкционированного доступа, от попыток изменения и уничтожения информации; - В ПО должна быть реализована ролевая модель доступа, позволяющая разграничить права доступа в ПО в соответствии с назначенной ему ролью; - ПО должно предоставлять поддержку и организацию политик разграничения доступа к интерфейсам управления, а также регистрацию и предотвращение попыток несанкционированного доступа к ним. Аутентификация персонала, при доступе к ПО должна выполняться на основе имени учетной записи и пароля. Дополнительно контроль доступа к ПО должен иметь возможность усиления с использованием двухфакторной аутентификации персонала на базе протокола ОТР. ПО должно предоставлять функцию аудита действий пользователей в соответствии с назначенными им ролями; - В ПО должны быть предусмотрены следующие наборы прав: - доступ ко всем действиям с ПО; - доступ к информации об атаках, инцидентах и уязвимостях, просмотр основных настроек ПО; - доступ к просмотру основных настроек ПО; - доступ для операций развертывания, без доступа к консоли управления. - В ПО должна быть реализована возможность устанавливать гранулированный доступ для пользователей системы к различным разделам и функционалу ПО в соответствии с необходимой моделью доступа разделяя права на изменение, создание, просмотр и удаление сущностей; - В ПО должна быть доступна система логического разделения доступа к приложениям с обеспечением независимых режимов работы, наборов правил, состава сотрудников и их прав доступа (мультитенантность). -

Требования к блокам ПО - ПО должно состоять из нескольких блоков, интегрированных и взаимодействующих между собой, а также обеспечивающих выполнение заданных функций; Требования к блоку обнаружения и защиты атак на приложения: Блок обнаружения и защиты от атак на приложения должен выполнять глубокую инспекцию пакетов HTTP-трафика, поступающего к защищаемым приложениям, принимая решения о необходимости блокирования запроса; Блок в режиме реального времени должен активировать проверку на наличие уязвимостей, доступных для эксплуатации, для запрашиваемого URI; Блок должен позволять идентифицировать 1Р-адрес, браузер и связанную с ними активность для обнаружения программ-роботов и автоматизированных инструментов;Блок должен поддерживать одновременную работу с веб-приложениями разных типов, опубликованные на различных доменах, использующие различные технологии, а также реализованные в виде API; Блок должен поддерживать различные протоколы, технологии и методы кодирования данных:- НТТР/0.9, НТТР/1.0, HTTP/1.1, НТТР/2, НТТР/3, WebSocket, GRPC, GraphQL;- XML, SOAP, JSON; HTMLForm, HTMLMultipartForm, ViewState;- gZIP, Base64, Percent Encoding, URL encoding (включая non-RFC варианты для PHP, Java, Apache, IIS, FastCGI и др.); Поддержка декодирования, нормализации и токенизации для вложенных типов данных, например обнаружение вектора атаки в ЬазебД-данных внутри JSON, использующем Unicode-кодирование, использующем HTMLMultipartForm; Парсинг данных внутри WebSocket соединений с учетом вложенных кодировок (json, gzip, xml) для обнаружения и блокировки атак. -

Требования к модулю активной перепроверки атак - Модуль должен осуществлять поиск уязвимостей веб¬приложений с учётом данных о аномальных запросах, поступающих на модуль мониторинга и фильтрации путём перепроверки атак с использованием модифицированных запросов. В результате обнаружения уязвимостей должны заводиться инциденты и производиться уведомление персонала посредством сообщений электронной почты и средств доставки мгновенных сообщений. Модуль должен обеспечивать такие способы перепроверки как: Обнаружение Blind SQL-инъекций или OOB-DNS;Обнаружение Error Based SQL-инъекций;Обнаружение RCE по времени ответа сервера или OOB-DNS;Выявление ошибок при получении невалидного юникода;Обнаружение уязвимостей типа Path Traversal;Обнаружение ХХЕ с помощью OOB-DNS;Обнаружение уязвимостей типа XSS;Обнаружение уязвимостей типа Stored XSS с помощью OOB-DNS; Обнаружение уязвимостей SSRF. -

Требования к модулю пассивного детектирования - Модуль пассивного сканирования должен проводить анализ ответов, поступающих от защищаемых приложений, с целью выявления попыток эксплуатации уязвимостей, а также обнаружения утечек чувствительной информации. Должен проводиться двусторонний анализ потока информации между клиентом и защищаемым веб-сервером; Модуль должен выполнять сбор статистических данных входящего HTTP-трафика и их первичный анализ. Собранная статистика должна использоваться для выявления атак типа Brute Force и Credential Stuffing. Полученные данных также должны использоваться для профилирования защищаемых приложений и формирования признаков для нахождения аномалий в действиях пользователей и работе приложений. -

Требования к модулю активного сканирования внешнего периметра сети (для поиска уязвимостей) - Модуль должен проводить автоматический анализ состава сетевого периметра инфраструктуры Заказчика, доступной из публичных сетей. На основе полученной информации модуль должен выполнять обнаружение известных уязвимостей сетевых сервисов на основе публичных CVE, а также распознавать ошибки в настройках и конфигурациях, приводящих к раскрытию технической информации, осуществлению неавторизованного доступа, нарушению конфиденциальности, утечкам данных, таких как: Несанкционированный доступ к репозиториям сходных кодов git, bitbucket и subversion; Обнаружение слабых пар логин/пароль для популярных СУБД (MySQL, PostgreSQL); Анонимный доступ к Elasticsearch, Redis, MongoDB; Обнаружение раскрытия технической информации (например веб-панель Adminer, страница apache server status; файлы .bash history; страница списка файлов на URL; веб-панель Grafana; веб-панель Munin; веб-панель pgAdmin; страница phpinfo; приватный RSA ключ; все файлы text/plain или application/octet-stream; веб-панель Zabbix); Перебор стандартных пар логин и пароль для следующих протоколов и приложений: FTP, LDAP, Memcached, MongoDB, MySQL, PostgreSQL, Redis, Xll. -

Требования к блоку интеграции со сторонними решениями - ПО должно иметь интерфейсы интеграции со сторонними решениями посредством REST API, протоколов syslog, snmp, webhook. Для борьбы с DDoS- атаками ПО должно обеспечивать механизмы выгрузки и управления перечнями задействованных в атаке IP-адресов; ПО должно иметь возможности интеграции с e-mail системой и мессенджерами (Slack, Mattermost, Telegram) для осуществления оперативного информирования пользователей ПО о различных системных или иных событиях, а также предоставлять возможность получения периодических отчетов; ПО должно иметь возможность интеграции с имеющимся SIEM-решением, выбранным специалистами Заказчика. -

Требования к блоку аналитики - Блок должен отвечать за дополнительную обработку данных, поступающих от модуля обнаружения и защиты от атак на приложения, агрегацию данных, поступающих со всех устройств ПО, а также производить дополнительный анализ данных в асинхронном режиме для выявления корреляций между отдельными вредоносными запросами, индексацию и подготовку данных для их представления в модуле управления. ПО должно постоянно отслеживать структуру и параметры приложений для обнаружения обычных атак и атак нулевого дня при помощи самообучающихся алгоритмов искусственного интеллекта. Модуль должен выполнять динамическое формирование правил обнаружения атак и подстраивать их под защищаемые приложения, снижая количество ложных срабатываний; Блок должен быть реализован в виде внешней компоненты, размещённой на территории Российской Федерации. -

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

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

Требования к модулю защиты от поведенческих атак - Модуль должен выполнять функции работы с репутационными списками для защиты от поведенческих атак, а также защита против автоматизированного сбора данных и подбора URL и должен обнаруживать подозрительную активность пользователей или приложений; Модуль должен обеспечивать возможность автоматического и ручного формирования чёрных списков IP-адресов нарушителей политик безопасности с возможностью временной или постоянной блокировки. ПО должно иметь возможность формирования белых списков IP-адресов, для которых будут выполняться исключения в применении политик безопасности. Должна присутствовать возможность формирования серых списков IP-адресов, которым будет разрешен доступ к приложениям, только если в запросах нет признаков атак; Списки должны поддерживать указание отдельных IP- адресов или подсетей в формате CIDR. Должна быть возможность подключения собственного источника данных об IP-адресах; Управление списками должно осуществляться из интерфейса управления, а также посредством интеграции со сторонними средствами с использованием API системы. -

Дополнительные требования к модулям - Мониторинг и фильтрация запросов должны осуществляться для протоколов HTTP и HTTPS, gRPC, WebSocket; ПО должно осуществлять обнаружение следующих классов и типов атак: HTTP-атаки, включая атаки на переполнение буфера; атаки на подбор пароля перебором вариантов (Brute Force); атаки на перебор директорий и файлов (Dirbust); атаки межсайтового выполнения сценариев (Cross Site Scripting); атаки НРР (HTTP Parameter Pollution - смешивание («загрязнение») границ HTTP-параметров); атаки на внешние сущности XML (XML external Entity); атаки, основанные на внедрении в запрос произвольного SQL-кода (SQL Injection); атаки, связанные с манипуляциями с XML файлами (XQuery Injection); атаки на использование локальных системных файлов сервера (LFI - Local File Inclusion); атаки на выполнение удаленного файла (RFI - Remote File Inclusion); атаки, связанные с уязвимостями в HTTP-Verb аутентификации и механизмах контроля доступа (HTTP Verb Tampering); атаки выполнение команд ОС (OS commanding, RCE); атаки обхода каталога (Path Traversal); атаки типа открытое перенаправление (Open redirect); другие атаки различных типов и классов, включая (crlf, nosqli, Idap-inj, ssti, ssi, mailinjection, ssrf, mass assignment, scanner). -

Дополнительные требования - ПО должно поддерживать защиту приложений, выполненных по технологии SPA (Single Page Application) с использованием технологии HTML5; В обычном состоянии ПО должно функционировать в режиме негативной модели безопасности, т. е. пропускать все запросы, кроме распознанных как атаки; Число ложных срабатываний (false positive) по событиям, связанным со всеми атаками на веб-приложения, не должно превышать 1% от общего числа событий срабатывания по всем атакам; ПО должно осуществлять обнаружение сетевых атак посредством сопоставления параметров веб-запросов правилам, а также посредством сопоставления характеристик веб-запросов с характеристиками аналогичных веб-запросов, полученных ранее; Используемый ПО механизм выявления атак должен иметь функции непрерывного профилирования веб-приложения (без необходимости переводить подсистему в особый режим обучения) и корректировки полученной модели администратором ПО; ПО должно предоставлять Оператору возможность определить, по какой причине трафик был классифицирован как вредоносный, а также предоставлять Оператору возможность быстрого исправления ложных срабатываний с обновлением профиля приложения, без ручной перенастройки правил обнаружения и блокировки атак; ПО должно блокировать атаки следующими способами: путем перехвата и блокирования («неотправки») частей трафика к веб-приложению; путем блокирования соединения клиента с веб-приложением; Работа с графическим интерфейсом модуля управления должно осуществляться посредством современных версий веб-браузеров. -

Дополнительные требования к ПО - ПО должно иметь следующие механизмы управления событиями, связанными с атаками: механизм фильтрации событий (по приоритету, типу события); механизм агрегирования (группировка однотипных событий); механизм приоритизации (по приоритету, типу события). ПО должно поддерживать генерацию, рассылку и выгрузку отчетов в открытых форматах (например, *.pdf); ПО должно поддерживать систему управления триггерами, посредством которых можно настроить различные оповещения о появлении инцидентов, уязвимостей, атак. Уведомления по триггерам должны поступать посредством различных каналов связи (email, популярные мессенджеры); Интерфейс ПО должен содержать в себе интерактивные динамические дашборды с информацией об инцидентах, уязвимостях, атаках, картой источников атак, статистические данные о количестве и степени критичности. -

Требования к показателям назначения ПО - Суммарное количество HTTP/HTTPS запросов за месяц не превышает 1,2 млрд.; ПО должно обеспечивать защиту до 10 приложений/доменов. -

Иные требования к ПО - ПО не должно приводить к снижению параметров производительности и нарушению работы защищаемых веб-ресурсов; Интерфейс ПО и формируемые ею отчеты должны быть на русском языке. -

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

Преимущества, требования к участникам

Преимущества: Не установлены

Требования к участникам: 1. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ 2. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ: Основанием для установки указания запретов, ограничений закупок товаров, происходящих из иностранных государств, выполняемых работ, оказываемых услуг иностранными лицами, а так же преимуществ в отношении товаров российского происхождения, а также товаров происходящих из стран ЕАЭС, выполняемых работ, оказываемых услуг российскими лицами, а также лицами, зарегистрированными в странах ЕАЭС, является Постановление Правительства Российской Федерации о мерах по предоставлению национального режима от 23.12.2024 № 1875.

Сведения о связи с позицией плана-графика

Сведения о связи с позицией плана-графика: 202602511000008001000027

Начальная (максимальная) цена контракта: 3 471 722,10

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 261540601901954060100100300015829242

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

Дата начала исполнения контракта: 0  календарных дней с даты заключения контракта

Срок исполнения контракта: 43  рабочих дней

Закупка за счет бюджетных средств: Да

Наименование бюджета: бюджет Территориального фонда обязательного медицинского страхования Новосибирской области

Вид бюджета: бюджет территориального государственного внебюджетного фонда

Код территории муниципального образования: 50000009: Муниципальные образования Новосибирской области / Территориальный фонд обязательного медицинского страхования

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 34 717,22 Российский рубль

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Обеспечение заявки предоставляется участником закупки в соответствии со ст.44 Федерального закона от 05.04.2013 №44-ФЗ. Условия независимой гарантии установлены в соответствии со ст. 45 Федерального закона от 05.04.2013 №44-ФЗ.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03272643500000095100, л/c 05515035790, БИК 015004950, СИБИРСКОЕ ГУ БАНКА РОССИИ/УФК по Новосибирской области г. Новосибирск, к/c 40102810445370000043

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО НОВОСИБИРСКОЙ ОБЛАСТИ (ТФОМС НСО) () ИНН: 5406019019 КПП: 540601001 КБК: 39511610005809000140 ОКТМО: 50701000 40102810445370000043 03100643000000015100 015004950

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл. Новосибирская, г.о. город Новосибирск, г. Новосибирск, пр-кт Красный, зд. 42А, Ответственное должностное лицо за приемку Услуг: Пушкарев Александр Борисович, номер контактного телефона 8-383-3549150, доб. тел. 1003

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 347 172,21 Российский рубль (10 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Обеспечение исполнения контракта предоставляется участником закупки в соответствии со ст. 96 Федерального закона от 05.04.2013 №44-ФЗ.Антидемпинговые меры применяются в соответствии со ст. 37 Федерального закона о 05.04.2013 №44-ФЗ.Условия независимой гарантии установлены в соответствии со ст. 45 Федерального закона от 05.04.2013 №44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03272643500000095100, л/c 05515035790, БИК 015004950, СИБИРСКОЕ ГУ БАНКА РОССИИ/УФК по Новосибирской области г. Новосибирск, к/c 40102810445370000043

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок на оказываемые по Контракту Услуги не установлен.

Банковское или казначейское сопровождение контракта не требуется

Информация о сроках исполнения контракта и источниках финансирования

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

Дата начала исполнения контракта: 0  календарных дней с даты заключения контракта

Срок исполнения контракта: 43  рабочих дней

Закупка за счет бюджетных средств: Да

Наименование бюджета: бюджет Территориального фонда обязательного медицинского страхования Новосибирской области

Вид бюджета: бюджет территориального государственного внебюджетного фонда

Код территории муниципального образования: 50000009: Муниципальные образования Новосибирской области / Территориальный фонд обязательного медицинского страхования

Документы

Общая информация

Документы

Журнал событий