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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответственное должностное лицо: Лобова Т. Е.

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

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

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

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

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

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

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

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

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

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

Начальная (максимальная) цена контракта: 25 726 633,00

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

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

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

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

- 58.29.50.000 58.29.11.000-00000003 - Программное обеспечение Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) - Штука - 1,00 - 13 226 240,00 - 13 226 240,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "ЦЕНТР ЗАЩИТЫ ИНФОРМАЦИИ НОВОСИБИРСКОЙ ОБЛАСТИ" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) Назначение Программное обеспечение для автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности Функционал Требования к учету активов: Учет материальных и нематериальных активов и их взаимосвязей (бизнес-процессы, информация, сети, оборудование, помещения, персонал, подразделения, группы ИТ-активов, пользовательские активы). Нормализация и дедупликация данных об оборудовании при интеграции с несколькими внешними источниками. Ведение карточек активов, включающих общие сведения об активе, список ответственных лиц и связанные активы, а также связанные инциденты и дополнительную информацию. Возможность связывания актива с другими объектами системы (вручную или автоматически): • активами других типов («бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «пользовательские активы» и иными типами активов, настроенными в системе); • задачами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «пользовательские активы»); • инцидентами (для активов типа «бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «ПО»); • документами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «помещения», «информация», «ПО», «сети», «персонал», «пользовательские активы»). Возможность вести каждый тип активов в отдельной вкладке («оборудование», «персонал», «программное обеспечение», «помещения» и т. д.). Требования к системе для автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности (далее – система). Право на получение обновлений ПО в течение 12 месяцев. Требования по диагностированию системы: Диагностирование Системы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Система должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа: К управлению Системой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Система реагирования на инциденты должна включать в себя: Блок управления активами - проведение инвентаризации и обогащение информации по активам из различных источников, управление взаимосвязями активов и управление жизненным циклом активов; Блок управления инцидентами - централизованный сбор, хранение и обогащение информации по инцидентам ИБ из различных источников, автоматизация процесса реагирования на инциденты; Блок управления задачами – управление задачами пользователей системы; Блок управления документами - централизованный учет, управление различными документами и их связями с активами. Показатели назначения: Количество объектов ИТ-инфраструктуры, сведения по которым обрабатывает Система (учет и техническое реагирование) – не менее 8000. Требования к блоку управления активами Требования к функционалу инвентаризации: Возможность инвентаризации узлов с ОС Windows с использованием протокола WinRM. Возможность инвентаризации узлов с ОС Linux посредством подключения по SSH, по протоколу SNMP или с использованием bash-скриптов, выполняемых на конечных узлах. Возможность инвентаризации сетевого оборудования посредством подключения через SSH или по протоколу SNMP (инвентаризируется оборудование, поддерживающее OID MIB-II). Сбор базовой инвентаризационной информации, включая технические параметры оборудования и параметры безопасности. Возможность формирования политик инвентаризации с настройкой периодичности инвентаризации объектов, включающих следующий функционал: • Сканирование произвольных диапазонов IP адресов/сетей/имен устройств; • Сканирование хостов и Групп ИТ-активов по именам устройств; • Исключение из сканирования IP адресов/сетей/имен устройств; • Возможность задать область сканирования - все оборудование или только новые объекты; • Возможность задать перечень учетных записей для каждой политики; • Режим “Обнаружение” для сканирования без учетной записи; • Возможность настройки параметров сканирования; • Просмотр истории и статуса сканирования в интерфейсе. • Сбор информации об открытых портах по заданному диапазону TCP/UDP портов. Требования к интеграции с внешними системами: Наличие интеграции с VMware vSphere - сбор данных обо всех виртуальных хостах со всех гипервизоров, находящихся под управлением VMware vCenter. Наличие интеграции с Kaspersky Security Center (инвентаризационная информация об узлах и их технических параметрах, данных о наличии и статусе работы агентов антивируса, пользователях), возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность фильтрации оборудования по заданным критериям включения и исключения. В систему должны добавляться только узлы, которые соответствуют итоговым условиям фильтрации. Наличие интеграции с системой MaxPatrol 8. Импорт сведений по активам. Наличие интеграции с MaxPatrol SIEM. Импорт сведений по активам, возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность импортировать данные об установленном ПО, а также информацию о пользователях, проходивших аутентификацию на хостах с указанием даты последнего визита. Наличие интеграции с СЗИ НСД Secret Net/Secret Net Studio (импорт сведений по активам и статусу агента защиты). Наличие интеграции с Active Directory. Импорт сведений о пользователях, зарегистрированных в AD, оборудованию, сведений о структурных элементах – о бизнес-подразделениях из профиля пользователя, а также импорт дополнительных атрибутов оборудования или пользователей в систему. Аутентификация и авторизация пользователей Системы. Поддержка импорта имени домена из интеграции с Active Directory в формате FQDN. Возможность задания расписания интеграции с внешними системами. Возможности работы со списком активов: • поиск по таблицам со списками оборудования и персонала; • сортировка списка по любому полю для каждого типа актива; • фильтрация списка по одному или нескольким полям для каждого типа актива; • сохранение пользователем фильтра списка; • настройка выводимых полей для списка активов; • создание нескольких режимов отображения активов по заданному фильтру и возможность быстрого переключения между ними (для каждого локального пользователя Системы); • вывод списков активов (подразделения, помещения, бизнес-процессы, группы ИТ-активов, ПО, сети) как в виде линейного списка, так и в виде иерархической структуры с возможностью быстрой идентификации родительских и дочерних активов; • групповое удаление активов. Возможность создавать собственные (пользовательские) типы активов с индивидуальными полями карточек и выбирать для таких активов иконку отображения. Возможность устанавливать связи пользовательских активов между собой и с другими типами активов. Возможность автоматизированного учета оборудования в сетях с одинаковой адресацией. Возможность создания требуемого количества адресных пространств и распределения по ним всех дублирующихся сетей. Автоматическое определение типа узла с помощью настраиваемых правил. Автоматическая привязка сетей к группам ИТ-активов, в которые входят узлы из этой группы. Возможность автоматического включения ПО в группы по настроенным правилам. Возможность настройки исключений для групп ПО. ПО должно группироваться по наименованию, должна быть возможность редактирования нескольких элементов одной группы. Отображение степени критичности активов в виде цветовой схемы. Возможность управления категоризацией групп ИТ-активов с заполнением соответствующих полей описания (АСУТП, ГИС, КИИ, ИСПДн и пр.). Возможность создавать собственные категории групп ИТ-активов с индивидуальным набором полей. Ведение истории по действиям с активами (добавление, изменение, удаление) в пользовательском интерфейсе независимо от источника изменений (пользователь, интеграции). Возможность уведомлений пользователей по электронной почте или во всплывающем окне на панели уведомлений о зафиксированных изменениях в активах (нахождение нового оборудования, нахождение нового открытого порта оборудования, нового ПО или пользователя, новых сетей, уведомление об исчезновении оборудования (удаление оборудования), обнаружение новой группы ИТ-активов, создание/изменение/удаление пользовательского актива, изменение статуса инвентаризации узла). Возможность ручного импорта данных по сетям, оборудованию, группам ИТ-активов, подразделениям, помещениям, персоналу, бизнес-процессам и пользовательским активам из файлов формата excel по шаблону. Должна осуществляться проверка системой заполненности обязательных полей при импорте активов из файла. Возможность экспорта в таблицу .xlsx данных по активам с учетом текущей настройки столбцов, примененных фильтров и сортировок. Требования к полям и карточкам активов: Возможность конструировать карточки активов для каждого типа актива отдельно с возможностью добавления следующих типов полей: выпадающий список, дата, несколько текстовых строк, текстовое поле, чек-бокс, числовое поле, числовое поле с денежным символом, выбор пользователя (возможность выбора пользователя из списка пользователей системы), IP-адрес/адрес сети. Конструктор должен позволять настраивать набор и порядок следования полей в карточке для заданного типа актива. Возможность настроить валидацию по регулярному выражению для текстовых полей и полей типа IP-адрес/адрес сети. Возможность контролировать истечение даты любых полей типа «Дата» с индикацией в интерфейсе и отправкой уведомлений: как почтовых, так и в панель уведомлений. Возможность группового редактирования полей активов. Наличие в карточке оборудования поля, отображающего статус инвентаризации и содержащего описание ошибки инвентаризации или статус ее успешного прохождения. Наличие поля в карточке актива для указания локации с возможностью привязки актива к населенному пункту или объекту из справочника локаций, применяемого для вывода информации по активам и связанным с ними инцидентами на географическую карту. Требования к жизненному циклу: Возможность реализации статусной модели актива в соответствии с заданными в организации процедурами. Возможность автоматически помечать и удалять из системы оборудование и активы типа «персонал», сведения по которым не обновлялись в течение заданного периода времени. Визуализация в виде диаграмм количества активов типа «оборудование» или персонал, сведения по которым не обновлялись определенный период времени. Требования к автоматизации: Возможность создания правил, по которым осуществляется автозаполнение полей активов. Возможность выполнения скриптов автоматизации на проинвентаризированных системой хостах. Наличие не менее 50 готовых различных скриптов автоматизации, сгруппированных по типу. Возможность добавления собственных скриптов автоматизации, написанных на python, java, powershell, bash. Требования к блоку управления инцидентами Требования к интеграции с внешними системами: Наличие интеграции с MaxPatrol SIEM с обратной синхронизацией статуса. Создание инцидентов из сообщений электронной почты с возможностью автоматического заполнения заданных полей. Создание инцидентов через интерфейс API: - Возможность заполнения заданных полей инцидента выбранными данными из внешней системы; - Возможность двухстороннего обмена данными – синхронизация статуса инцидента. - Возможность задания расписания интеграции с внешними системами. Система должна обеспечивать возможность выгрузки электронной формы инцидента в формате JSON. Возможность отправки информации по инцидентам по электронной почте (протоколы IMAP, SMTP). Возможность передачи данных инцидентов через REST API в произвольные внешние системы. Требования к учету инцидентов: Сбор, регистрация, обогащение и агрегация информации по всем инцидентам ИБ из различных источников в единой системе. Ведение карточек инцидентов, содержащих сведения по инцидентам, прикрепленные файлы и дополнительную информацию. Возможность создавать инцидент как автоматически из внешних источников, так и вручную (в том числе с использованием предзаполненных шаблонов). Классификация инцидентов по категориям и типам с возможностью изменения категорий и типов любых инцидентов. Возможность назначения на инцидент уровня критичности в соответствии с настраиваемым справочником уровней критичности. Автоматическая фиксация даты и времени создания инцидента. Возможность прикрепления к инциденту файлов (с автоматическим расчетом контрольной суммы этих файлов (MD5, SHA-1)) и добавления метаданных к ним, возможность скачивания всех файлов по инциденту в виде архива. Возможность связывания инцидента с другими объектами системы (вручную или автоматически): • активами (бизнес-процессы, информация, группы ИТ-активов, оборудование, бизнес-подразделения, персонал, пользовательские активы и иными типами активов, настроенными в системе); • задачами; • другими инцидентами. Работа с индикаторами компрометации: • Добавление в инцидент информации о связанных индикаторах компрометации; • Возможность обогащения индикаторов из произвольных внешних систем с использованием REST API. Контроль времени работы над инцидентом: • Добавление в карточку инцидента конфигурируемых счетчиков времени; • Назначение для счетчика лимита времени; • Индикация превышения лимита времени; • Управление счетчиком на уровне сценариев реагирования: остановка, запуск, назначение лимита; • Возможность вывода сводной информации по настроенным в инцидентах счетчикам времени на графиках в дашбордах. Возможность работы со списком инцидентов: • поиск по списку инцидентов; • сортировка и фильтрация списка инцидентов по одному или нескольким полям; • Фильтр списка инцидентов должен иметь возможность сохранения пользователем и повторного использования; • Возможность настроить выводимые поля инцидента при выводе инцидентов в виде списка; • Возможность создания нескольких режимов отображения инцидентов по заданному фильтру и быстрого переключения между ними. Изменения, вносимые в карточку инцидента, должны журналироваться, независимо от источника изменений (пользователь, сценарий) и интерфейса, через который они внесены (UI, API). Возможность экспорта/импорта данных об инцидентах в файл в формате *.xlsx. Возможность выбора полей при экспорте данных по инцидентам. Возможность уведомления пользователей при изменении в инцидентах, попадающих под заданные критерии. Возможность уведомления пользователя при добавлении в инцидент нового комментария. Возможность присвоения категории и типа инцидента по почтовому адресу отправителя письма при интеграции с почтовой системой. Возможность учета уровня ущерба от реализации инцидентов информационной безопасности. Требования к полям и карточкам инцидентов: Возможность производить индивидуальную настройку карточки инцидента для каждой категории (типа) инцидентов. Добавления в карточку настраиваемых полей следующих типов: числовое поле, текстовое поле, многострочное текстовое поле, выпадающий список, числовое поле с денежным символом, дата и время, счетчик времени, чек-бокс, выбор пользователя, массив полей. Добавление в карточку таблиц, где колонками выступают поля перечисленных выше типов. Создание и редактирование собственных справочников для полей типа "выпадающий список". Настройка валидации для вводимых в текстовые поля значений. Возможность использования для валидации регулярных выражений, заранее преднастроенных и вынесенных в отдельный справочник. Настройка предустановленных значений для полей. Настройка подсказок для полей. Отображение текстовых полей в виде гиперссылок с настраиваемым адресом ссылки и выводимым тестом. Возможность добавления в карточку инцидента кнопки для запуска выбранного сценария. Наличие конструктора представлений карточки инцидента, поддерживающего следующий функционал: • Возможность настроить разное отображение карточки инцидента в зависимости от критериев, заданных в отношении значений произвольных полей, роли пользователя или сочетания данных критериев; • Настройка полей: скрыть, показать, запретить редактирование, скрыть пустое, сделать поле обязательным для заполнения, задать предустановленное значение, настроить справочник для полей типа "выпадающий список", сделав заданные значения полей недоступными для выбора. • Возможность объединения полей в именованные группы для логической организации полей инцидента, должно поддерживаться управление отображением группы по умолчанию - в свернутом или развернутом виде. • Возможность скрыть или показать разделы карточки инцидента; • Возможность назначить представление по умолчанию, которое будет применяться к карточке, если не было назначено никакое другое представление. • Возможность настроить зависимости внутри представлений, позволяющие отображать значение одного поля в зависимости от значения другого. Возможность создать представление облегченной страницы Системы для отправки сообщений об инцидентах для определенных ролей пользователей без доступа ко всем вкладкам в интерфейсе продукта. Требования к жизненному циклу инцидента: Возможность реализации статусной модели инцидента в соответствии с заданными в организации процедурами. Гибкая настройка жизненного цикла инцидента: • Добавление в жизненный цикл произвольных статусов; • Настройки произвольных переходов между статусами жизненного цикла; • Настройка прав на осуществление перехода для отдельных пользователей и групп пользователей; • Настройка полей инцидента, заполнение которых в пользовательском интерфейсе является обязательным для осуществления перехода из одного статуса в другой; • Настройка разных жизненных циклов для разных категорий инцидентов. Требования к функционалу совместной работы над инцидентами: Разграничение доступа к инцидентам на основании: • ролевой модели; • дискреционных прав доступа; • значений полей инцидента. Возможность настраивать отдельные права на создание, удаление, чтение и изменение инцидентов. Возможность задавать ограничение категорий (типов) инцидентов, которые может создавать пользователь. Назначение на инцидент ответственного пользователя: • Настройка автоматического назначения ответственного на основании критериев, заданных в полях инцидента; • Настройка автоматического назначения ответственного из заданной группы локальных пользователей на основании текущей загрузки. Возможность вести коммуникацию по каждому инциденту в отдельном встроенном чате: • Возможность упоминания в текстовом сообщении пользователя системы с его последующим уведомлением; • Отображение статуса работы пользователя в системе в системе реального времени: «активен», «не активен». Возможность вести почтовую переписку по инциденту в карточке, в рамках которой пользователи системы должны иметь возможность отправлять сообщения по электронной почте и получать ответы, при этом все письма должны храниться в системе и быть доступными для просмотра из карточки инцидента. Требования к макрокорреляции и группировке: Группировка инцидентов: • Объединение инцидентов в группы, где один инцидент является родительским, а остальные - дочерними; • Возможность как добавления инцидента в существующую группу, так и вывода инцидента из группы; • Вывод группы инцидентов в пользовательский интерфейс с возможностью свернуть/развернуть список инцидентов, входящих в группу; • Создание именованных типов групп. Настраиваемое для типа группы наследование полей внутри группы от родительского инцидента к дочернему и заполнение полей родительского из полей дочерних. Поиск похожих инцидентов по критерию совпадения значений полей. Возможность связывания найденных инцидентов с текущим и объединения их в группу. Функциональные требования к автоматизации: Наличие возможности добавлять конфигурируемые сценарии (плейбуки), применяемые к инциденту. Сценарий должен состоять из действий, запускаемых в заданном порядке. Сценарий должен иметь возможность "ветвления" (параллельное выполнение разных последовательностей действий) и слияния "веток" (выполнение действия после завершения двух или более веток - всех или любой) в том числе в зависимости от действий пользователей, результатов предыдущих действий или значения переменных (значение поля в карточке инцидента). В сценарии должна присутствовать возможность использования условных операторов вида "if-else" и "case". Из одного сценария можно инициировать запуск другого сценария. Для действий в сценарии должна присутствовать возможность отложенного запуска. Действия в сценарии должны работать со значениями полей инцидента на момент запуска действия (то есть в режиме реального времени). Поставляемые в составе системы действия должны обеспечивать возможность: • автоматической отправки сообщений электронной почты с настраиваемым содержимым, в том числе с использованием значений из полей инцидента: o с возможностью ожидания ответа и сохранения его содержимого; o с возможностью автоматически сгенерировать и приложить к письму отчет по инциденту; o с возможностью сохранять все отправленные и полученные в рамках инцидента письма в соответствующем разделе карточки; o с возможностью настраивать условия автоматического завершения действия - после отправки письма или после получения ответа от получателя; o перед отправкой сообщения производится проверка статуса учетной записи пользователя в системе; • автоматического создания в системе задачи с заданным содержимым с возможностью указывать в качестве исполнителей задач по инцидентам пользователей, ответственных за инцидент; • автоматического назначения или изменения ответственного и назначение дискреционных прав доступа по инциденту; • автоматической модификации полей инцидента (в том числе с возможностью записи в текстовые поля содержимого других полей); • запуска сканирования связанного с инцидентом оборудования; • запуска скриптов и коннекторов к внешним системам, сконструированных пользователем (см. функциональные требования к механизмам оркестрации), в том числе с возможностью запуска в цикле до достижения заданного критерия остановки; Запуск сценария вручную. Запуск сценария автоматически при создании или изменении инцидента при совпадении критериев, заданных в отношении значений произвольных полей инцидента. Запуск сценария и выполнение действий в рамках него должны журналироваться. Должна присутствовать возможность приостановить выполнения сценария. После приостановки сценария должна присутствовать возможность его возобновления. Должна присутствовать возможность прервать выполнение как единичного действия в сценарии, так и сценария целиком. Для сценария должна настраиваться возможность его применения к инциденту - однократное применение, либо многократное. Возможность запуска вручную для инцидента без привязки к сценарию действий по отправке уведомления по email (в том числе с возможностью ожидания ответа), запуску скриптов и коннекторов, сканированию связанного оборудования непосредственно из карточки инцидента без необходимости создания для этого сценария. Возможность создавать переменные, значение которых будет содержать информацию из полей инцидента или пользовательскую информацию в текстовом формате, и использовать их в действиях по реагированию, в том числе в коннекторах. Функциональные требования к механизмам оркестрации: Возможность в графическом режиме конструировать коннекторы для взаимодействия с произвольными внешними системами. Возможность установки и запуска новых коннекторов без остановки Системы. Коннекторы должны поддерживать технологии: • Powershell и cmd.exe; • SSH; • REST API; • LDAP; • MS SQL; • MySQL; • Oracle; • PostgreSQL; • SNMP; • SOAP. Возможность использования значения полей инцидента в теле коннектора. Возможность проверки подключения к внешней системе на этапе настройки коннектора. Возможность отладки коннектора в процессе его настройки с отправкой запроса и выводом его результата. Возможность копирования существующего коннектора в рамках работы с конструктором коннекторов. Возможность просмотра связанных объектов (сценариев и других коннекторов), на которые может повлиять изменение коннектора. Возможность работы REST-коннекторов через прокси-серверы. Возможность направления во внешние системы бинарных файлов через коннектор REST API. Возможность настройки выполнения коннектора на отдельно вынесенном коллекторе. Возможность настроить повторное выполнение действия "Запуск коннектора" с заданным тайм-аутом, приостановить или прервать выполнение сценария, если при первичном выполнении возникла ошибка. Возможность обработки результатов работы коннектора с использованием регулярных выражений и записи результатов обработки в одно или несколько полей инцидента. Возможность проверки подлинности SSL-сертификата для коннекторов типа REST и SOAP. Требования к работе со сценариями в пользовательском интерфейсе: Сценарии должны создаваться и редактироваться в графическом режиме. Сценарии, запущенные на инциденте, должны отображаться в графическом виде с возможностью просмотра как всех сценариев сразу, так и выбранного сценария. Сценарии, запущенные на инциденте, должны отображаться в виде таймлайна с привязкой к временным меткам их запуска. При запуске одного сценария из другого должна присутствовать возможность просмотра действий "вложенного" сценария и обратная возможность свернуть их в компактный блок. При отображении сценариев должна производится индикация действий: выполненных, выполняющихся в данный момент, запланированных и действий, выполнившихся с ошибкой, для которых должна быть возможность просмотреть текст ошибки, которая привела к его некорректному завершению. Возможность сохранить диаграмму выполнившихся на инциденте сценариев как изображение. Требования к блоку управления задачами Требования к возможностям пользовательской настройки: Наличие возможности настраивать состав и порядок полей для разных типов задач. Возможность настройки полей, обязательных для создания задачи, а также полей, обязательных для заполнения при переходе из одного статуса в другой Требования к работе с задачами Возможность работы с реестром задач: • Возможность настройки столбцов, отображаемых пользователю при работе с реестром задач; • Возможность сортировки и фильтрации списка задач по одному или нескольким полям; • Возможность сохранения пользователем и повторного использования заданного условия фильтрации реестра; • Возможность создания вкладок с заданным условием фильтрации. Наличие связи задач с активами, инцидентами, документами. Возможность просмотреть существующие связи между этими сущностями и создать новые. Возможность перехода из карточки задачи к связанным с ней сущностям (активы, инциденты). Контроль сроков исполнения задач. Возможность настроить уведомления по задачам с истекающим сроком исполнения и по задачам, срок исполнения которых истек. Визуализация состояния задач, индикация важности (критичности) задач, а также задач с просроченным сроком исполнения. Учет и просмотр истории выполнения задач. Хранение и учет документов, связанных как с постановкой задачи, так и с результатами её исполнения. Возможность заведения подзадач вручную с привязкой к основной задаче, которые будут автоматически влиять на её статус. Возможность создания задач вручную из карточек различных объектов системы (пользовательские активы, документы, инциденты) Возможность создать задачу по нескольким активам типа ПО или по нескольким пользовательским активам из контекстного меню при групповом выделении активов. Возможность импорта задач из файлов в формате Microsoft Excel. Возможность экспорта сведений по задачам в файл в формате Microsoft Excel. Возможность отображения иерархии и пользовательских полей для задач, связанных с инцидентом. Требования к интеграции с внешними системами: Наличие интеграции с системой Naumen SD (синхронизация полей в задачах, импорт сведений из Naumen по созданным задачам и подзадачам, двусторонний обмен комментариями). Требования к совместной работе: Отображение задач в зависимости от роли пользователя. Наличие чата для обмена сообщениями между участниками группы пользователей, привлеченных к задаче. Требования к блоку управления документами Требования к возможностям пользовательской настройки: Возможность создания различных типов документов (приказы, инструкции, политики и пр.) и индивидуальной настройки состава полей для каждого типа документа. Требования к учету документов Возможность ведения документации по информационной безопасности в едином хранилище. Возможности работы со списком документов: • настройка столбцов, отображаемых пользователю при работе со списком документов; • поиск по списку документов; • сортировка и фильтрация списка по одному или нескольким полям; • сохранение пользователем для повторного использования заданного условия фильтрации списка; • создание вкладок с заданным условием фильтрации. Возможность создания документов вручную или с помощью импорта из excel. Возможность загрузки вложений в любом формате к карточке документа. Возможность скачивать вложения из карточки документа. Возможность управления жизненным циклом документа. Указание срока действия документа, а также возможность автоматического уведомления ответственных пользователей при наступлении установленной даты пересмотра документа. Возможность привязки документов к активам разных типов («группы ИТ-активов», «информация», «бизнес-процессы», «подразделения»). Возможность прикрепления документов из общей базы к активам, инцидентам, задачам. Возможность группового редактирования связей документа(ов) с активами. Возможность просмотра истории ранее внесенных изменений в карточку документа. Требования к совместной работе с документами Возможность настройки рабочей группы пользователей, ответственных за документ. Для каждого участника должна быть обеспечена возможность настройки уровня доступа (чтение, изменение). Возможность быстрого предоставления доступа к документу на чтение всем сотрудникам организации. Комплектация Сертифицированный комплект дистрибутива ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Заверенная копия сертификата ФСТЭК России. Товарный знак R-Vision - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Способ предоставления - Экземпляр на материальном носителе - - Класс программ для электронных вычислительных машин и баз данных - (03.17) Средства автоматизации процессов информационной безопасности - - Вид лицензии - Простая (неисключительная) - - Назначение - Программное обеспечение для автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности - - Функционал - Требования к учету активов: Учет материальных и нематериальных активов и их взаимосвязей (бизнес-процессы, информация, сети, оборудование, помещения, персонал, подразделения, группы ИТ-активов, пользовательские активы). Нормализация и дедупликация данных об оборудовании при интеграции с несколькими внешними источниками. Ведение карточек активов, включающих общие сведения об активе, список ответственных лиц и связанные активы, а также связанные инциденты и дополнительную информацию. Возможность связывания актива с другими объектами системы (вручную или автоматически): • активами других типов («бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «пользовательские активы» и иными типами активов, настроенными в системе); • задачами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «пользовательские активы»); • инцидентами (для активов типа «бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «ПО»); • документами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «помещения», «информация», «ПО», «сети», «персонал», «пользовательские активы»). Возможность вести каждый тип активов в отдельной вкладке («оборудование», «персонал», «программное обеспечение», «помещения» и т. д.). - - Требования к системе для автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности (далее – система). Право на получение обновлений ПО в течение 12 месяцев. Требования по диагностированию системы: Диагностирование Системы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Система должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа: К управлению Системой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Система реагирования на инциденты должна включать в себя: Блок управления активами - проведение инвентаризации и обогащение информации по активам из различных источников, управление взаимосвязями активов и управление жизненным циклом активов; Блок управления инцидентами - централизованный сбор, хранение и обогащение информации по инцидентам ИБ из различных источников, автоматизация процесса реагирования на инциденты; Блок управления задачами – управление задачами пользователей системы; Блок управления документами - централизованный учет, управление различными документами и их связями с активами. - Показатели назначения: Количество объектов ИТ-инфраструктуры, сведения по которым обрабатывает Система (учет и техническое реагирование) – не менее 8000. Требования к блоку управления активами Требования к функционалу инвентаризации: Возможность инвентаризации узлов с ОС Windows с использованием протокола WinRM. Возможность инвентаризации узлов с ОС Linux посредством подключения по SSH, по протоколу SNMP или с использованием bash-скриптов, выполняемых на конечных узлах. Возможность инвентаризации сетевого оборудования посредством подключения через SSH или по протоколу SNMP (инвентаризируется оборудование, поддерживающее OID MIB-II). Сбор базовой инвентаризационной информации, включая технические параметры оборудования и параметры безопасности. Возможность формирования политик инвентаризации с настройкой периодичности инвентаризации объектов, включающих следующий функционал: • Сканирование произвольных диапазонов IP адресов/сетей/имен устройств; • Сканирование хостов и Групп ИТ-активов по именам устройств; • Исключение из сканирования IP адресов/сетей/имен устройств; • Возможность задать область сканирования - все оборудование или только новые объекты; • Возможность задать перечень учетных записей для каждой политики; • Режим “Обнаружение” для сканирования без учетной записи; • Возможность настройки параметров сканирования; • Просмотр истории и статуса сканирования в интерфейсе. • Сбор информации об открытых портах по заданному диапазону TCP/UDP портов. - Требования к интеграции с внешними системами: Наличие интеграции с VMware vSphere - сбор данных обо всех виртуальных хостах со всех гипервизоров, находящихся под управлением VMware vCenter. Наличие интеграции с Kaspersky Security Center (инвентаризационная информация об узлах и их технических параметрах, данных о наличии и статусе работы агентов антивируса, пользователях), возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность фильтрации оборудования по заданным критериям включения и исключения. В систему должны добавляться только узлы, которые соответствуют итоговым условиям фильтрации. Наличие интеграции с системой MaxPatrol 8. Импорт сведений по активам. Наличие интеграции с MaxPatrol SIEM. Импорт сведений по активам, возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность импортировать данные об установленном ПО, а также информацию о пользователях, проходивших аутентификацию на хостах с указанием даты последнего визита. Наличие интеграции с СЗИ НСД Secret Net/Secret Net Studio (импорт сведений по активам и статусу агента защиты). Наличие интеграции с Active Directory. Импорт сведений о пользователях, зарегистрированных в AD, оборудованию, сведений о структурных элементах – о бизнес-подразделениях из профиля пользователя, а также импорт дополнительных атрибутов оборудования или пользователей в систему. Аутентификация и авторизация пользователей Системы. Поддержка импорта имени домена из интеграции с Active Directory в формате FQDN. Возможность задания расписания интеграции с внешними системами. - Возможности работы со списком активов: • поиск по таблицам со списками оборудования и персонала; • сортировка списка по любому полю для каждого типа актива; • фильтрация списка по одному или нескольким полям для каждого типа актива; • сохранение пользователем фильтра списка; • настройка выводимых полей для списка активов; • создание нескольких режимов отображения активов по заданному фильтру и возможность быстрого переключения между ними (для каждого локального пользователя Системы); • вывод списков активов (подразделения, помещения, бизнес-процессы, группы ИТ-активов, ПО, сети) как в виде линейного списка, так и в виде иерархической структуры с возможностью быстрой идентификации родительских и дочерних активов; • групповое удаление активов. Возможность создавать собственные (пользовательские) типы активов с индивидуальными полями карточек и выбирать для таких активов иконку отображения. Возможность устанавливать связи пользовательских активов между собой и с другими типами активов. Возможность автоматизированного учета оборудования в сетях с одинаковой адресацией. Возможность создания требуемого количества адресных пространств и распределения по ним всех дублирующихся сетей. Автоматическое определение типа узла с помощью настраиваемых правил. Автоматическая привязка сетей к группам ИТ-активов, в которые входят узлы из этой группы. Возможность автоматического включения ПО в группы по настроенным правилам. Возможность настройки исключений для групп ПО. ПО должно группироваться по наименованию, должна быть возможность редактирования нескольких элементов одной группы. Отображение степени критичности активов в виде цветовой схемы. Возможность управления категоризацией групп ИТ-активов с заполнением соответствующих полей описания (АСУТП, ГИС, КИИ, ИСПДн и пр.). Возможность создавать собственные категории групп ИТ-активов с индивидуальным набором полей. - Ведение истории по действиям с активами (добавление, изменение, удаление) в пользовательском интерфейсе независимо от источника изменений (пользователь, интеграции). Возможность уведомлений пользователей по электронной почте или во всплывающем окне на панели уведомлений о зафиксированных изменениях в активах (нахождение нового оборудования, нахождение нового открытого порта оборудования, нового ПО или пользователя, новых сетей, уведомление об исчезновении оборудования (удаление оборудования), обнаружение новой группы ИТ-активов, создание/изменение/удаление пользовательского актива, изменение статуса инвентаризации узла). Возможность ручного импорта данных по сетям, оборудованию, группам ИТ-активов, подразделениям, помещениям, персоналу, бизнес-процессам и пользовательским активам из файлов формата excel по шаблону. Должна осуществляться проверка системой заполненности обязательных полей при импорте активов из файла. Возможность экспорта в таблицу .xlsx данных по активам с учетом текущей настройки столбцов, примененных фильтров и сортировок. Требования к полям и карточкам активов: Возможность конструировать карточки активов для каждого типа актива отдельно с возможностью добавления следующих типов полей: выпадающий список, дата, несколько текстовых строк, текстовое поле, чек-бокс, числовое поле, числовое поле с денежным символом, выбор пользователя (возможность выбора пользователя из списка пользователей системы), IP-адрес/адрес сети. Конструктор должен позволять настраивать набор и порядок следования полей в карточке для заданного типа актива. Возможность настроить валидацию по регулярному выражению для текстовых полей и полей типа IP-адрес/адрес сети. Возможность контролировать истечение даты любых полей типа «Дата» с индикацией в интерфейсе и отправкой уведомлений: как почтовых, так и в панель уведомлений. Возможность группового редактирования полей активов. - Наличие в карточке оборудования поля, отображающего статус инвентаризации и содержащего описание ошибки инвентаризации или статус ее успешного прохождения. Наличие поля в карточке актива для указания локации с возможностью привязки актива к населенному пункту или объекту из справочника локаций, применяемого для вывода информации по активам и связанным с ними инцидентами на географическую карту. Требования к жизненному циклу: Возможность реализации статусной модели актива в соответствии с заданными в организации процедурами. Возможность автоматически помечать и удалять из системы оборудование и активы типа «персонал», сведения по которым не обновлялись в течение заданного периода времени. Визуализация в виде диаграмм количества активов типа «оборудование» или персонал, сведения по которым не обновлялись определенный период времени. Требования к автоматизации: Возможность создания правил, по которым осуществляется автозаполнение полей активов. Возможность выполнения скриптов автоматизации на проинвентаризированных системой хостах. Наличие не менее 50 готовых различных скриптов автоматизации, сгруппированных по типу. Возможность добавления собственных скриптов автоматизации, написанных на python, java, powershell, bash. - Требования к блоку управления инцидентами Требования к интеграции с внешними системами: Наличие интеграции с MaxPatrol SIEM с обратной синхронизацией статуса. Создание инцидентов из сообщений электронной почты с возможностью автоматического заполнения заданных полей. Создание инцидентов через интерфейс API: - Возможность заполнения заданных полей инцидента выбранными данными из внешней системы; - Возможность двухстороннего обмена данными – синхронизация статуса инцидента. - Возможность задания расписания интеграции с внешними системами. Система должна обеспечивать возможность выгрузки электронной формы инцидента в формате JSON. Возможность отправки информации по инцидентам по электронной почте (протоколы IMAP, SMTP). Возможность передачи данных инцидентов через REST API в произвольные внешние системы. Требования к учету инцидентов: Сбор, регистрация, обогащение и агрегация информации по всем инцидентам ИБ из различных источников в единой системе. Ведение карточек инцидентов, содержащих сведения по инцидентам, прикрепленные файлы и дополнительную информацию. Возможность создавать инцидент как автоматически из внешних источников, так и вручную (в том числе с использованием предзаполненных шаблонов). Классификация инцидентов по категориям и типам с возможностью изменения категорий и типов любых инцидентов. Возможность назначения на инцидент уровня критичности в соответствии с настраиваемым справочником уровней критичности. Автоматическая фиксация даты и времени создания инцидента. Возможность прикрепления к инциденту файлов (с автоматическим расчетом контрольной суммы этих файлов (MD5, SHA-1)) и добавления метаданных к ним, возможность скачивания всех файлов по инциденту в виде архива. - Возможность связывания инцидента с другими объектами системы (вручную или автоматически): • активами (бизнес-процессы, информация, группы ИТ-активов, оборудование, бизнес-подразделения, персонал, пользовательские активы и иными типами активов, настроенными в системе); • задачами; • другими инцидентами. Работа с индикаторами компрометации: • Добавление в инцидент информации о связанных индикаторах компрометации; • Возможность обогащения индикаторов из произвольных внешних систем с использованием REST API. Контроль времени работы над инцидентом: • Добавление в карточку инцидента конфигурируемых счетчиков времени; • Назначение для счетчика лимита времени; • Индикация превышения лимита времени; • Управление счетчиком на уровне сценариев реагирования: остановка, запуск, назначение лимита; • Возможность вывода сводной информации по настроенным в инцидентах счетчикам времени на графиках в дашбордах. Возможность работы со списком инцидентов: • поиск по списку инцидентов; • сортировка и фильтрация списка инцидентов по одному или нескольким полям; • Фильтр списка инцидентов должен иметь возможность сохранения пользователем и повторного использования; • Возможность настроить выводимые поля инцидента при выводе инцидентов в виде списка; • Возможность создания нескольких режимов отображения инцидентов по заданному фильтру и быстрого переключения между ними. - Изменения, вносимые в карточку инцидента, должны журналироваться, независимо от источника изменений (пользователь, сценарий) и интерфейса, через который они внесены (UI, API). Возможность экспорта/импорта данных об инцидентах в файл в формате *.xlsx. Возможность выбора полей при экспорте данных по инцидентам. Возможность уведомления пользователей при изменении в инцидентах, попадающих под заданные критерии. Возможность уведомления пользователя при добавлении в инцидент нового комментария. Возможность присвоения категории и типа инцидента по почтовому адресу отправителя письма при интеграции с почтовой системой. Возможность учета уровня ущерба от реализации инцидентов информационной безопасности. Требования к полям и карточкам инцидентов: Возможность производить индивидуальную настройку карточки инцидента для каждой категории (типа) инцидентов. Добавления в карточку настраиваемых полей следующих типов: числовое поле, текстовое поле, многострочное текстовое поле, выпадающий список, числовое поле с денежным символом, дата и время, счетчик времени, чек-бокс, выбор пользователя, массив полей. Добавление в карточку таблиц, где колонками выступают поля перечисленных выше типов. Создание и редактирование собственных справочников для полей типа "выпадающий список". Настройка валидации для вводимых в текстовые поля значений. Возможность использования для валидации регулярных выражений, заранее преднастроенных и вынесенных в отдельный справочник. Настройка предустановленных значений для полей. Настройка подсказок для полей. Отображение текстовых полей в виде гиперссылок с настраиваемым адресом ссылки и выводимым тестом. Возможность добавления в карточку инцидента кнопки для запуска выбранного сценария. - Наличие конструктора представлений карточки инцидента, поддерживающего следующий функционал: • Возможность настроить разное отображение карточки инцидента в зависимости от критериев, заданных в отношении значений произвольных полей, роли пользователя или сочетания данных критериев; • Настройка полей: скрыть, показать, запретить редактирование, скрыть пустое, сделать поле обязательным для заполнения, задать предустановленное значение, настроить справочник для полей типа "выпадающий список", сделав заданные значения полей недоступными для выбора. • Возможность объединения полей в именованные группы для логической организации полей инцидента, должно поддерживаться управление отображением группы по умолчанию - в свернутом или развернутом виде. • Возможность скрыть или показать разделы карточки инцидента; • Возможность назначить представление по умолчанию, которое будет применяться к карточке, если не было назначено никакое другое представление. • Возможность настроить зависимости внутри представлений, позволяющие отображать значение одного поля в зависимости от значения другого. Возможность создать представление облегченной страницы Системы для отправки сообщений об инцидентах для определенных ролей пользователей без доступа ко всем вкладкам в интерфейсе продукта. Требования к жизненному циклу инцидента: Возможность реализации статусной модели инцидента в соответствии с заданными в организации процедурами. Гибкая настройка жизненного цикла инцидента: • Добавление в жизненный цикл произвольных статусов; • Настройки произвольных переходов между статусами жизненного цикла; • Настройка прав на осуществление перехода для отдельных пользователей и групп пользователей; • Настройка полей инцидента, заполнение которых в пользовательском интерфейсе является обязательным для осуществления перехода из одного статуса в другой; • Настройка разных жизненных циклов для разных категорий инцидентов. - Требования к функционалу совместной работы над инцидентами: Разграничение доступа к инцидентам на основании: • ролевой модели; • дискреционных прав доступа; • значений полей инцидента. Возможность настраивать отдельные права на создание, удаление, чтение и изменение инцидентов. Возможность задавать ограничение категорий (типов) инцидентов, которые может создавать пользователь. Назначение на инцидент ответственного пользователя: • Настройка автоматического назначения ответственного на основании критериев, заданных в полях инцидента; • Настройка автоматического назначения ответственного из заданной группы локальных пользователей на основании текущей загрузки. Возможность вести коммуникацию по каждому инциденту в отдельном встроенном чате: • Возможность упоминания в текстовом сообщении пользователя системы с его последующим уведомлением; • Отображение статуса работы пользователя в системе в системе реального времени: «активен», «не активен». Возможность вести почтовую переписку по инциденту в карточке, в рамках которой пользователи системы должны иметь возможность отправлять сообщения по электронной почте и получать ответы, при этом все письма должны храниться в системе и быть доступными для просмотра из карточки инцидента. Требования к макрокорреляции и группировке: Группировка инцидентов: • Объединение инцидентов в группы, где один инцидент является родительским, а остальные - дочерними; • Возможность как добавления инцидента в существующую группу, так и вывода инцидента из группы; • Вывод группы инцидентов в пользовательский интерфейс с возможностью свернуть/развернуть список инцидентов, входящих в группу; • Создание именованных типов групп. Настраиваемое для типа группы наследование полей внутри группы от родительского инцидента к дочернему и заполнение полей родительского из полей дочерних. Поиск похожих инцидентов по критерию совпадения значений полей. Возможность связывания найденных инцидентов с текущим и объединения их в группу. - Функциональные требования к автоматизации: Наличие возможности добавлять конфигурируемые сценарии (плейбуки), применяемые к инциденту. Сценарий должен состоять из действий, запускаемых в заданном порядке. Сценарий должен иметь возможность "ветвления" (параллельное выполнение разных последовательностей действий) и слияния "веток" (выполнение действия после завершения двух или более веток - всех или любой) в том числе в зависимости от действий пользователей, результатов предыдущих действий или значения переменных (значение поля в карточке инцидента). В сценарии должна присутствовать возможность использования условных операторов вида "if-else" и "case". Из одного сценария можно инициировать запуск другого сценария. Для действий в сценарии должна присутствовать возможность отложенного запуска. Действия в сценарии должны работать со значениями полей инцидента на момент запуска действия (то есть в режиме реального времени). - Поставляемые в составе системы действия должны обеспечивать возможность: • автоматической отправки сообщений электронной почты с настраиваемым содержимым, в том числе с использованием значений из полей инцидента: o с возможностью ожидания ответа и сохранения его содержимого; o с возможностью автоматически сгенерировать и приложить к письму отчет по инциденту; o с возможностью сохранять все отправленные и полученные в рамках инцидента письма в соответствующем разделе карточки; o с возможностью настраивать условия автоматического завершения действия - после отправки письма или после получения ответа от получателя; o перед отправкой сообщения производится проверка статуса учетной записи пользователя в системе; • автоматического создания в системе задачи с заданным содержимым с возможностью указывать в качестве исполнителей задач по инцидентам пользователей, ответственных за инцидент; • автоматического назначения или изменения ответственного и назначение дискреционных прав доступа по инциденту; • автоматической модификации полей инцидента (в том числе с возможностью записи в текстовые поля содержимого других полей); • запуска сканирования связанного с инцидентом оборудования; • запуска скриптов и коннекторов к внешним системам, сконструированных пользователем (см. функциональные требования к механизмам оркестрации), в том числе с возможностью запуска в цикле до достижения заданного критерия остановки; Запуск сценария вручную. Запуск сценария автоматически при создании или изменении инцидента при совпадении критериев, заданных в отношении значений произвольных полей инцидента. Запуск сценария и выполнение действий в рамках него должны журналироваться. Должна присутствовать возможность приостановить выполнения сценария. После приостановки сценария должна присутствовать возможность его возобновления. Должна присутствовать возможность прервать выполнение как единичного действия в сценарии, так и сценария целиком. - Для сценария должна настраиваться возможность его применения к инциденту - однократное применение, либо многократное. Возможность запуска вручную для инцидента без привязки к сценарию действий по отправке уведомления по email (в том числе с возможностью ожидания ответа), запуску скриптов и коннекторов, сканированию связанного оборудования непосредственно из карточки инцидента без необходимости создания для этого сценария. Возможность создавать переменные, значение которых будет содержать информацию из полей инцидента или пользовательскую информацию в текстовом формате, и использовать их в действиях по реагированию, в том числе в коннекторах. Функциональные требования к механизмам оркестрации: Возможность в графическом режиме конструировать коннекторы для взаимодействия с произвольными внешними системами. Возможность установки и запуска новых коннекторов без остановки Системы. Коннекторы должны поддерживать технологии: • Powershell и cmd.exe; • SSH; • REST API; • LDAP; • MS SQL; • MySQL; • Oracle; • PostgreSQL; • SNMP; • SOAP. Возможность использования значения полей инцидента в теле коннектора. Возможность проверки подключения к внешней системе на этапе настройки коннектора. Возможность отладки коннектора в процессе его настройки с отправкой запроса и выводом его результата. Возможность копирования существующего коннектора в рамках работы с конструктором коннекторов. Возможность просмотра связанных объектов (сценариев и других коннекторов), на которые может повлиять изменение коннектора. Возможность работы REST-коннекторов через прокси-серверы. Возможность направления во внешние системы бинарных файлов через коннектор REST API. Возможность настройки выполнения коннектора на отдельно вынесенном коллекторе. Возможность настроить повторное выполнение действия "Запуск коннектора" с заданным тайм-аутом, приостановить или прервать выполнение сценария, если при первичном выполнении возникла ошибка. - Возможность обработки результатов работы коннектора с использованием регулярных выражений и записи результатов обработки в одно или несколько полей инцидента. Возможность проверки подлинности SSL-сертификата для коннекторов типа REST и SOAP. Требования к работе со сценариями в пользовательском интерфейсе: Сценарии должны создаваться и редактироваться в графическом режиме. Сценарии, запущенные на инциденте, должны отображаться в графическом виде с возможностью просмотра как всех сценариев сразу, так и выбранного сценария. Сценарии, запущенные на инциденте, должны отображаться в виде таймлайна с привязкой к временным меткам их запуска. При запуске одного сценария из другого должна присутствовать возможность просмотра действий "вложенного" сценария и обратная возможность свернуть их в компактный блок. При отображении сценариев должна производится индикация действий: выполненных, выполняющихся в данный момент, запланированных и действий, выполнившихся с ошибкой, для которых должна быть возможность просмотреть текст ошибки, которая привела к его некорректному завершению. Возможность сохранить диаграмму выполнившихся на инциденте сценариев как изображение. Требования к блоку управления задачами Требования к возможностям пользовательской настройки: Наличие возможности настраивать состав и порядок полей для разных типов задач. Возможность настройки полей, обязательных для создания задачи, а также полей, обязательных для заполнения при переходе из одного статуса в другой Требования к работе с задачами Возможность работы с реестром задач: • Возможность настройки столбцов, отображаемых пользователю при работе с реестром задач; • Возможность сортировки и фильтрации списка задач по одному или нескольким полям; • Возможность сохранения пользователем и повторного использования заданного условия фильтрации реестра; • Возможность создания вкладок с заданным условием фильтрации. - Наличие связи задач с активами, инцидентами, документами. Возможность просмотреть существующие связи между этими сущностями и создать новые. Возможность перехода из карточки задачи к связанным с ней сущностям (активы, инциденты). Контроль сроков исполнения задач. Возможность настроить уведомления по задачам с истекающим сроком исполнения и по задачам, срок исполнения которых истек. Визуализация состояния задач, индикация важности (критичности) задач, а также задач с просроченным сроком исполнения. Учет и просмотр истории выполнения задач. Хранение и учет документов, связанных как с постановкой задачи, так и с результатами её исполнения. Возможность заведения подзадач вручную с привязкой к основной задаче, которые будут автоматически влиять на её статус. Возможность создания задач вручную из карточек различных объектов системы (пользовательские активы, документы, инциденты) Возможность создать задачу по нескольким активам типа ПО или по нескольким пользовательским активам из контекстного меню при групповом выделении активов. Возможность импорта задач из файлов в формате Microsoft Excel. Возможность экспорта сведений по задачам в файл в формате Microsoft Excel. Возможность отображения иерархии и пользовательских полей для задач, связанных с инцидентом. Требования к интеграции с внешними системами: Наличие интеграции с системой Naumen SD (синхронизация полей в задачах, импорт сведений из Naumen по созданным задачам и подзадачам, двусторонний обмен комментариями). Требования к совместной работе: Отображение задач в зависимости от роли пользователя. Наличие чата для обмена сообщениями между участниками группы пользователей, привлеченных к задаче. Требования к блоку управления документами Требования к возможностям пользовательской настройки: Возможность создания различных типов документов (приказы, инструкции, политики и пр.) и индивидуальной настройки состава полей для каждого типа документа. - Требования к учету документов Возможность ведения документации по информационной безопасности в едином хранилище. Возможности работы со списком документов: • настройка столбцов, отображаемых пользователю при работе со списком документов; • поиск по списку документов; • сортировка и фильтрация списка по одному или нескольким полям; • сохранение пользователем для повторного использования заданного условия фильтрации списка; • создание вкладок с заданным условием фильтрации. Возможность создания документов вручную или с помощью импорта из excel. Возможность загрузки вложений в любом формате к карточке документа. Возможность скачивать вложения из карточки документа. Возможность управления жизненным циклом документа. Указание срока действия документа, а также возможность автоматического уведомления ответственных пользователей при наступлении установленной даты пересмотра документа. Возможность привязки документов к активам разных типов («группы ИТ-активов», «информация», «бизнес-процессы», «подразделения»). Возможность прикрепления документов из общей базы к активам, инцидентам, задачам. Возможность группового редактирования связей документа(ов) с активами. Возможность просмотра истории ранее внесенных изменений в карточку документа. Требования к совместной работе с документами Возможность настройки рабочей группы пользователей, ответственных за документ. Для каждого участника должна быть обеспечена возможность настройки уровня доступа (чтение, изменение). Возможность быстрого предоставления доступа к документу на чтение всем сотрудникам организации. - Комплектация - Сертифицированный комплект дистрибутива ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Заверенная копия сертификата ФСТЭК России. - - Товарный знак - R-Vision -

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

Способ предоставления - Экземпляр на материальном носителе -

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

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

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

Функционал - Требования к учету активов: Учет материальных и нематериальных активов и их взаимосвязей (бизнес-процессы, информация, сети, оборудование, помещения, персонал, подразделения, группы ИТ-активов, пользовательские активы). Нормализация и дедупликация данных об оборудовании при интеграции с несколькими внешними источниками. Ведение карточек активов, включающих общие сведения об активе, список ответственных лиц и связанные активы, а также связанные инциденты и дополнительную информацию. Возможность связывания актива с другими объектами системы (вручную или автоматически): • активами других типов («бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «пользовательские активы» и иными типами активов, настроенными в системе); • задачами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «пользовательские активы»); • инцидентами (для активов типа «бизнес-процессы», «информация», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «персонал», «ПО»); • документами (для активов типа «бизнес-процессы», «группы ИТ-активов», «оборудование», «бизнес-подразделения», «помещения», «информация», «ПО», «сети», «персонал», «пользовательские активы»). Возможность вести каждый тип активов в отдельной вкладке («оборудование», «персонал», «программное обеспечение», «помещения» и т. д.). -

Требования к системе для автоматизации деятельности по мониторингу, регистрации и реагированию на инциденты информационной безопасности (далее – система). Право на получение обновлений ПО в течение 12 месяцев. Требования по диагностированию системы: Диагностирование Системы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Система должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа: К управлению Системой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Система реагирования на инциденты должна включать в себя: Блок управления активами - проведение инвентаризации и обогащение информации по активам из различных источников, управление взаимосвязями активов и управление жизненным циклом активов; Блок управления инцидентами - централизованный сбор, хранение и обогащение информации по инцидентам ИБ из различных источников, автоматизация процесса реагирования на инциденты; Блок управления задачами – управление задачами пользователей системы; Блок управления документами - централизованный учет, управление различными документами и их связями с активами.

Показатели назначения: Количество объектов ИТ-инфраструктуры, сведения по которым обрабатывает Система (учет и техническое реагирование) – не менее 8000. Требования к блоку управления активами Требования к функционалу инвентаризации: Возможность инвентаризации узлов с ОС Windows с использованием протокола WinRM. Возможность инвентаризации узлов с ОС Linux посредством подключения по SSH, по протоколу SNMP или с использованием bash-скриптов, выполняемых на конечных узлах. Возможность инвентаризации сетевого оборудования посредством подключения через SSH или по протоколу SNMP (инвентаризируется оборудование, поддерживающее OID MIB-II). Сбор базовой инвентаризационной информации, включая технические параметры оборудования и параметры безопасности. Возможность формирования политик инвентаризации с настройкой периодичности инвентаризации объектов, включающих следующий функционал: • Сканирование произвольных диапазонов IP адресов/сетей/имен устройств; • Сканирование хостов и Групп ИТ-активов по именам устройств; • Исключение из сканирования IP адресов/сетей/имен устройств; • Возможность задать область сканирования - все оборудование или только новые объекты; • Возможность задать перечень учетных записей для каждой политики; • Режим “Обнаружение” для сканирования без учетной записи; • Возможность настройки параметров сканирования; • Просмотр истории и статуса сканирования в интерфейсе. • Сбор информации об открытых портах по заданному диапазону TCP/UDP портов.

Требования к интеграции с внешними системами: Наличие интеграции с VMware vSphere - сбор данных обо всех виртуальных хостах со всех гипервизоров, находящихся под управлением VMware vCenter. Наличие интеграции с Kaspersky Security Center (инвентаризационная информация об узлах и их технических параметрах, данных о наличии и статусе работы агентов антивируса, пользователях), возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность фильтрации оборудования по заданным критериям включения и исключения. В систему должны добавляться только узлы, которые соответствуют итоговым условиям фильтрации. Наличие интеграции с системой MaxPatrol 8. Импорт сведений по активам. Наличие интеграции с MaxPatrol SIEM. Импорт сведений по активам, возможность импорта дополнительных данных об установленных обновлениях ОС Windows. Возможность импортировать данные об установленном ПО, а также информацию о пользователях, проходивших аутентификацию на хостах с указанием даты последнего визита. Наличие интеграции с СЗИ НСД Secret Net/Secret Net Studio (импорт сведений по активам и статусу агента защиты). Наличие интеграции с Active Directory. Импорт сведений о пользователях, зарегистрированных в AD, оборудованию, сведений о структурных элементах – о бизнес-подразделениях из профиля пользователя, а также импорт дополнительных атрибутов оборудования или пользователей в систему. Аутентификация и авторизация пользователей Системы. Поддержка импорта имени домена из интеграции с Active Directory в формате FQDN. Возможность задания расписания интеграции с внешними системами.

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

Ведение истории по действиям с активами (добавление, изменение, удаление) в пользовательском интерфейсе независимо от источника изменений (пользователь, интеграции). Возможность уведомлений пользователей по электронной почте или во всплывающем окне на панели уведомлений о зафиксированных изменениях в активах (нахождение нового оборудования, нахождение нового открытого порта оборудования, нового ПО или пользователя, новых сетей, уведомление об исчезновении оборудования (удаление оборудования), обнаружение новой группы ИТ-активов, создание/изменение/удаление пользовательского актива, изменение статуса инвентаризации узла). Возможность ручного импорта данных по сетям, оборудованию, группам ИТ-активов, подразделениям, помещениям, персоналу, бизнес-процессам и пользовательским активам из файлов формата excel по шаблону. Должна осуществляться проверка системой заполненности обязательных полей при импорте активов из файла. Возможность экспорта в таблицу .xlsx данных по активам с учетом текущей настройки столбцов, примененных фильтров и сортировок. Требования к полям и карточкам активов: Возможность конструировать карточки активов для каждого типа актива отдельно с возможностью добавления следующих типов полей: выпадающий список, дата, несколько текстовых строк, текстовое поле, чек-бокс, числовое поле, числовое поле с денежным символом, выбор пользователя (возможность выбора пользователя из списка пользователей системы), IP-адрес/адрес сети. Конструктор должен позволять настраивать набор и порядок следования полей в карточке для заданного типа актива. Возможность настроить валидацию по регулярному выражению для текстовых полей и полей типа IP-адрес/адрес сети. Возможность контролировать истечение даты любых полей типа «Дата» с индикацией в интерфейсе и отправкой уведомлений: как почтовых, так и в панель уведомлений. Возможность группового редактирования полей активов.

Наличие в карточке оборудования поля, отображающего статус инвентаризации и содержащего описание ошибки инвентаризации или статус ее успешного прохождения. Наличие поля в карточке актива для указания локации с возможностью привязки актива к населенному пункту или объекту из справочника локаций, применяемого для вывода информации по активам и связанным с ними инцидентами на географическую карту. Требования к жизненному циклу: Возможность реализации статусной модели актива в соответствии с заданными в организации процедурами. Возможность автоматически помечать и удалять из системы оборудование и активы типа «персонал», сведения по которым не обновлялись в течение заданного периода времени. Визуализация в виде диаграмм количества активов типа «оборудование» или персонал, сведения по которым не обновлялись определенный период времени. Требования к автоматизации: Возможность создания правил, по которым осуществляется автозаполнение полей активов. Возможность выполнения скриптов автоматизации на проинвентаризированных системой хостах. Наличие не менее 50 готовых различных скриптов автоматизации, сгруппированных по типу. Возможность добавления собственных скриптов автоматизации, написанных на python, java, powershell, bash.

Требования к блоку управления инцидентами Требования к интеграции с внешними системами: Наличие интеграции с MaxPatrol SIEM с обратной синхронизацией статуса. Создание инцидентов из сообщений электронной почты с возможностью автоматического заполнения заданных полей. Создание инцидентов через интерфейс API: - Возможность заполнения заданных полей инцидента выбранными данными из внешней системы; - Возможность двухстороннего обмена данными – синхронизация статуса инцидента. - Возможность задания расписания интеграции с внешними системами. Система должна обеспечивать возможность выгрузки электронной формы инцидента в формате JSON. Возможность отправки информации по инцидентам по электронной почте (протоколы IMAP, SMTP). Возможность передачи данных инцидентов через REST API в произвольные внешние системы. Требования к учету инцидентов: Сбор, регистрация, обогащение и агрегация информации по всем инцидентам ИБ из различных источников в единой системе. Ведение карточек инцидентов, содержащих сведения по инцидентам, прикрепленные файлы и дополнительную информацию. Возможность создавать инцидент как автоматически из внешних источников, так и вручную (в том числе с использованием предзаполненных шаблонов). Классификация инцидентов по категориям и типам с возможностью изменения категорий и типов любых инцидентов. Возможность назначения на инцидент уровня критичности в соответствии с настраиваемым справочником уровней критичности. Автоматическая фиксация даты и времени создания инцидента. Возможность прикрепления к инциденту файлов (с автоматическим расчетом контрольной суммы этих файлов (MD5, SHA-1)) и добавления метаданных к ним, возможность скачивания всех файлов по инциденту в виде архива.

Возможность связывания инцидента с другими объектами системы (вручную или автоматически): • активами (бизнес-процессы, информация, группы ИТ-активов, оборудование, бизнес-подразделения, персонал, пользовательские активы и иными типами активов, настроенными в системе); • задачами; • другими инцидентами. Работа с индикаторами компрометации: • Добавление в инцидент информации о связанных индикаторах компрометации; • Возможность обогащения индикаторов из произвольных внешних систем с использованием REST API. Контроль времени работы над инцидентом: • Добавление в карточку инцидента конфигурируемых счетчиков времени; • Назначение для счетчика лимита времени; • Индикация превышения лимита времени; • Управление счетчиком на уровне сценариев реагирования: остановка, запуск, назначение лимита; • Возможность вывода сводной информации по настроенным в инцидентах счетчикам времени на графиках в дашбордах. Возможность работы со списком инцидентов: • поиск по списку инцидентов; • сортировка и фильтрация списка инцидентов по одному или нескольким полям; • Фильтр списка инцидентов должен иметь возможность сохранения пользователем и повторного использования; • Возможность настроить выводимые поля инцидента при выводе инцидентов в виде списка; • Возможность создания нескольких режимов отображения инцидентов по заданному фильтру и быстрого переключения между ними.

Изменения, вносимые в карточку инцидента, должны журналироваться, независимо от источника изменений (пользователь, сценарий) и интерфейса, через который они внесены (UI, API). Возможность экспорта/импорта данных об инцидентах в файл в формате *.xlsx. Возможность выбора полей при экспорте данных по инцидентам. Возможность уведомления пользователей при изменении в инцидентах, попадающих под заданные критерии. Возможность уведомления пользователя при добавлении в инцидент нового комментария. Возможность присвоения категории и типа инцидента по почтовому адресу отправителя письма при интеграции с почтовой системой. Возможность учета уровня ущерба от реализации инцидентов информационной безопасности. Требования к полям и карточкам инцидентов: Возможность производить индивидуальную настройку карточки инцидента для каждой категории (типа) инцидентов. Добавления в карточку настраиваемых полей следующих типов: числовое поле, текстовое поле, многострочное текстовое поле, выпадающий список, числовое поле с денежным символом, дата и время, счетчик времени, чек-бокс, выбор пользователя, массив полей. Добавление в карточку таблиц, где колонками выступают поля перечисленных выше типов. Создание и редактирование собственных справочников для полей типа "выпадающий список". Настройка валидации для вводимых в текстовые поля значений. Возможность использования для валидации регулярных выражений, заранее преднастроенных и вынесенных в отдельный справочник. Настройка предустановленных значений для полей. Настройка подсказок для полей. Отображение текстовых полей в виде гиперссылок с настраиваемым адресом ссылки и выводимым тестом. Возможность добавления в карточку инцидента кнопки для запуска выбранного сценария.

Наличие конструктора представлений карточки инцидента, поддерживающего следующий функционал: • Возможность настроить разное отображение карточки инцидента в зависимости от критериев, заданных в отношении значений произвольных полей, роли пользователя или сочетания данных критериев; • Настройка полей: скрыть, показать, запретить редактирование, скрыть пустое, сделать поле обязательным для заполнения, задать предустановленное значение, настроить справочник для полей типа "выпадающий список", сделав заданные значения полей недоступными для выбора. • Возможность объединения полей в именованные группы для логической организации полей инцидента, должно поддерживаться управление отображением группы по умолчанию - в свернутом или развернутом виде. • Возможность скрыть или показать разделы карточки инцидента; • Возможность назначить представление по умолчанию, которое будет применяться к карточке, если не было назначено никакое другое представление. • Возможность настроить зависимости внутри представлений, позволяющие отображать значение одного поля в зависимости от значения другого. Возможность создать представление облегченной страницы Системы для отправки сообщений об инцидентах для определенных ролей пользователей без доступа ко всем вкладкам в интерфейсе продукта. Требования к жизненному циклу инцидента: Возможность реализации статусной модели инцидента в соответствии с заданными в организации процедурами. Гибкая настройка жизненного цикла инцидента: • Добавление в жизненный цикл произвольных статусов; • Настройки произвольных переходов между статусами жизненного цикла; • Настройка прав на осуществление перехода для отдельных пользователей и групп пользователей; • Настройка полей инцидента, заполнение которых в пользовательском интерфейсе является обязательным для осуществления перехода из одного статуса в другой; • Настройка разных жизненных циклов для разных категорий инцидентов.

Требования к функционалу совместной работы над инцидентами: Разграничение доступа к инцидентам на основании: • ролевой модели; • дискреционных прав доступа; • значений полей инцидента. Возможность настраивать отдельные права на создание, удаление, чтение и изменение инцидентов. Возможность задавать ограничение категорий (типов) инцидентов, которые может создавать пользователь. Назначение на инцидент ответственного пользователя: • Настройка автоматического назначения ответственного на основании критериев, заданных в полях инцидента; • Настройка автоматического назначения ответственного из заданной группы локальных пользователей на основании текущей загрузки. Возможность вести коммуникацию по каждому инциденту в отдельном встроенном чате: • Возможность упоминания в текстовом сообщении пользователя системы с его последующим уведомлением; • Отображение статуса работы пользователя в системе в системе реального времени: «активен», «не активен». Возможность вести почтовую переписку по инциденту в карточке, в рамках которой пользователи системы должны иметь возможность отправлять сообщения по электронной почте и получать ответы, при этом все письма должны храниться в системе и быть доступными для просмотра из карточки инцидента. Требования к макрокорреляции и группировке: Группировка инцидентов: • Объединение инцидентов в группы, где один инцидент является родительским, а остальные - дочерними; • Возможность как добавления инцидента в существующую группу, так и вывода инцидента из группы; • Вывод группы инцидентов в пользовательский интерфейс с возможностью свернуть/развернуть список инцидентов, входящих в группу; • Создание именованных типов групп. Настраиваемое для типа группы наследование полей внутри группы от родительского инцидента к дочернему и заполнение полей родительского из полей дочерних. Поиск похожих инцидентов по критерию совпадения значений полей. Возможность связывания найденных инцидентов с текущим и объединения их в группу.

Функциональные требования к автоматизации: Наличие возможности добавлять конфигурируемые сценарии (плейбуки), применяемые к инциденту. Сценарий должен состоять из действий, запускаемых в заданном порядке. Сценарий должен иметь возможность "ветвления" (параллельное выполнение разных последовательностей действий) и слияния "веток" (выполнение действия после завершения двух или более веток - всех или любой) в том числе в зависимости от действий пользователей, результатов предыдущих действий или значения переменных (значение поля в карточке инцидента). В сценарии должна присутствовать возможность использования условных операторов вида "if-else" и "case". Из одного сценария можно инициировать запуск другого сценария. Для действий в сценарии должна присутствовать возможность отложенного запуска. Действия в сценарии должны работать со значениями полей инцидента на момент запуска действия (то есть в режиме реального времени).

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

Для сценария должна настраиваться возможность его применения к инциденту - однократное применение, либо многократное. Возможность запуска вручную для инцидента без привязки к сценарию действий по отправке уведомления по email (в том числе с возможностью ожидания ответа), запуску скриптов и коннекторов, сканированию связанного оборудования непосредственно из карточки инцидента без необходимости создания для этого сценария. Возможность создавать переменные, значение которых будет содержать информацию из полей инцидента или пользовательскую информацию в текстовом формате, и использовать их в действиях по реагированию, в том числе в коннекторах. Функциональные требования к механизмам оркестрации: Возможность в графическом режиме конструировать коннекторы для взаимодействия с произвольными внешними системами. Возможность установки и запуска новых коннекторов без остановки Системы. Коннекторы должны поддерживать технологии: • Powershell и cmd.exe; • SSH; • REST API; • LDAP; • MS SQL; • MySQL; • Oracle; • PostgreSQL; • SNMP; • SOAP. Возможность использования значения полей инцидента в теле коннектора. Возможность проверки подключения к внешней системе на этапе настройки коннектора. Возможность отладки коннектора в процессе его настройки с отправкой запроса и выводом его результата. Возможность копирования существующего коннектора в рамках работы с конструктором коннекторов. Возможность просмотра связанных объектов (сценариев и других коннекторов), на которые может повлиять изменение коннектора. Возможность работы REST-коннекторов через прокси-серверы. Возможность направления во внешние системы бинарных файлов через коннектор REST API. Возможность настройки выполнения коннектора на отдельно вынесенном коллекторе. Возможность настроить повторное выполнение действия "Запуск коннектора" с заданным тайм-аутом, приостановить или прервать выполнение сценария, если при первичном выполнении возникла ошибка.

Возможность обработки результатов работы коннектора с использованием регулярных выражений и записи результатов обработки в одно или несколько полей инцидента. Возможность проверки подлинности SSL-сертификата для коннекторов типа REST и SOAP. Требования к работе со сценариями в пользовательском интерфейсе: Сценарии должны создаваться и редактироваться в графическом режиме. Сценарии, запущенные на инциденте, должны отображаться в графическом виде с возможностью просмотра как всех сценариев сразу, так и выбранного сценария. Сценарии, запущенные на инциденте, должны отображаться в виде таймлайна с привязкой к временным меткам их запуска. При запуске одного сценария из другого должна присутствовать возможность просмотра действий "вложенного" сценария и обратная возможность свернуть их в компактный блок. При отображении сценариев должна производится индикация действий: выполненных, выполняющихся в данный момент, запланированных и действий, выполнившихся с ошибкой, для которых должна быть возможность просмотреть текст ошибки, которая привела к его некорректному завершению. Возможность сохранить диаграмму выполнившихся на инциденте сценариев как изображение. Требования к блоку управления задачами Требования к возможностям пользовательской настройки: Наличие возможности настраивать состав и порядок полей для разных типов задач. Возможность настройки полей, обязательных для создания задачи, а также полей, обязательных для заполнения при переходе из одного статуса в другой Требования к работе с задачами Возможность работы с реестром задач: • Возможность настройки столбцов, отображаемых пользователю при работе с реестром задач; • Возможность сортировки и фильтрации списка задач по одному или нескольким полям; • Возможность сохранения пользователем и повторного использования заданного условия фильтрации реестра; • Возможность создания вкладок с заданным условием фильтрации.

Наличие связи задач с активами, инцидентами, документами. Возможность просмотреть существующие связи между этими сущностями и создать новые. Возможность перехода из карточки задачи к связанным с ней сущностям (активы, инциденты). Контроль сроков исполнения задач. Возможность настроить уведомления по задачам с истекающим сроком исполнения и по задачам, срок исполнения которых истек. Визуализация состояния задач, индикация важности (критичности) задач, а также задач с просроченным сроком исполнения. Учет и просмотр истории выполнения задач. Хранение и учет документов, связанных как с постановкой задачи, так и с результатами её исполнения. Возможность заведения подзадач вручную с привязкой к основной задаче, которые будут автоматически влиять на её статус. Возможность создания задач вручную из карточек различных объектов системы (пользовательские активы, документы, инциденты) Возможность создать задачу по нескольким активам типа ПО или по нескольким пользовательским активам из контекстного меню при групповом выделении активов. Возможность импорта задач из файлов в формате Microsoft Excel. Возможность экспорта сведений по задачам в файл в формате Microsoft Excel. Возможность отображения иерархии и пользовательских полей для задач, связанных с инцидентом. Требования к интеграции с внешними системами: Наличие интеграции с системой Naumen SD (синхронизация полей в задачах, импорт сведений из Naumen по созданным задачам и подзадачам, двусторонний обмен комментариями). Требования к совместной работе: Отображение задач в зависимости от роли пользователя. Наличие чата для обмена сообщениями между участниками группы пользователей, привлеченных к задаче. Требования к блоку управления документами Требования к возможностям пользовательской настройки: Возможность создания различных типов документов (приказы, инструкции, политики и пр.) и индивидуальной настройки состава полей для каждого типа документа.

Требования к учету документов Возможность ведения документации по информационной безопасности в едином хранилище. Возможности работы со списком документов: • настройка столбцов, отображаемых пользователю при работе со списком документов; • поиск по списку документов; • сортировка и фильтрация списка по одному или нескольким полям; • сохранение пользователем для повторного использования заданного условия фильтрации списка; • создание вкладок с заданным условием фильтрации. Возможность создания документов вручную или с помощью импорта из excel. Возможность загрузки вложений в любом формате к карточке документа. Возможность скачивать вложения из карточки документа. Возможность управления жизненным циклом документа. Указание срока действия документа, а также возможность автоматического уведомления ответственных пользователей при наступлении установленной даты пересмотра документа. Возможность привязки документов к активам разных типов («группы ИТ-активов», «информация», «бизнес-процессы», «подразделения»). Возможность прикрепления документов из общей базы к активам, инцидентам, задачам. Возможность группового редактирования связей документа(ов) с активами. Возможность просмотра истории ранее внесенных изменений в карточку документа. Требования к совместной работе с документами Возможность настройки рабочей группы пользователей, ответственных за документ. Для каждого участника должна быть обеспечена возможность настройки уровня доступа (чтение, изменение). Возможность быстрого предоставления доступа к документу на чтение всем сотрудникам организации.

Комплектация - Сертифицированный комплект дистрибутива ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Заверенная копия сертификата ФСТЭК России. -

Товарный знак - R-Vision -

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

- 58.29.50.000 58.29.11.000-00000003 - Программное обеспечение Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.07) Средства выявления и предотвращения целевых атак Вид лицензии Простая (неисключительная) - Штука - 1,00 - 4 132 865,00 - 4 132 865,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "ЦЕНТР ЗАЩИТЫ ИНФОРМАЦИИ НОВОСИБИРСКОЙ ОБЛАСТИ" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.07) Средства выявления и предотвращения целевых атак Вид лицензии Простая (неисключительная) Назначение Программное обеспечение платформы анализа информации об угрозах Функционал Право на получение обновлений ПО в течение 12 месяцев. Технические требования к платформе анализа информации об угрозах: Требования по диагностированию платформы. Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа. К управлению платформой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Показатели назначения: Количество поставщиков данных TI: не менее 4. Количество сенсоров для взаимодействия с SIEM: 1. Требования к работе с поставщиками данных TI. Возможность настройки интеграции Системы не менее чем с 4 поставщиками данных киберразведки (Threat Intelligence), предоставляющими индикаторы компрометации и дополнительный контекст, из следующего списка: • R-Vision Threat Intelligence feed; • Kaspersky Threat Intelligence Services; • BiZone; • PT feed; • IBM X-Force; • AT&T OTX; • Group-IB Threat Exchange; • MISP; • ФинЦЕРТ: АСОИ; • Open source фиды в форматах TXT, CSV; • RST Cloud; • ESET; • Shadow; • National vulnerability database (NVD). Возможность при удалении поставщиков данных или каналов удалять вместе с ними и индикаторы компрометации, которые от них поступили. Требования к функционалу обнаружения индикаторов Возможность поиска IoC (в том числе ретроспективного с момента начала использования SIEM-сенсора) в событиях безопасности с использованием одного SIEM-сенсора системы. Возможность настраивать ротацию данных ноды, позволяющую при поступлении новых данных автоматически удалять события, у которых истек срок хранения. Возможность уведомления пользователей об обнаруженных Системой индикаторах компрометации. Возможность просмотра карточки обнаруженного индикатора с дополнительными сведениями по обнаруженному индикатору и информацией о взаимосвязях. Возможность работы со списком обнаруженных индикаторов: Возможность поиска индикаторов компрометации в общем списке обнаружений. Возможность фильтрации списка индикаторов по одному или нескольким полям. Возможность настройки перечня выводимых в общий список полей событий обнаружений. Требования к работе с угрозами Агрегация, нормализация, дедупликация и отображение сведений TI об отчетах (структурированных документах, содержащих описание угрозы с различной степенью детализации), вредоносном ПО, кампаниях, жертвах, субъектах угроз, личностях и уязвимостях в автоматическом режиме из различных источников, в том числе свободно распространяемых. Возможность добавления к угрозам типа отчеты, вредоносное ПО, уязвимости пользовательских тегов для маркировки, фильтрации и поиска в системе. Создание, редактирование и удаление угроз типа пользовательские отчеты, вредоносное ПО и кампании. Использование как минимум двух статусов для отчетов – «черновик» или «опубликован». Возможность учета информации о взаимосвязях между сущностями TI, если таковые имеются, включая схематичное отображение в виде графа связей с возможностью фильтрации данных на графе, кластеризации (объединения объектов на карте по типам или поставщикам), а также экспорта графа в виде .png файла. Возможность работы со списком угроз: • Возможность поиска в общем списке; Возможность установки разной частоты обновлений для каналов внутри выбранного поставщика. Возможность добавления пользовательского поставщика данных для передачи информации об индикаторах компрометации из внешних систем по API. Возможность устанавливать рейтинг для таких индикаторов компрометации. Наличие конструктора синтаксического анализа данных, поступающих в формате csv от open source фидов. Требования к интеграции с сервисами обогащения Наличие интеграций для обогащения данных IoC со следующими внешними сервисами: • GeoIP: ipgeolocaton.io • OPSWAT Metadefender • Risk IQ • Shodan • VirusTotal • AlienLabs OTX Reputation • Alien Labs OTX • DomCop Top 10m • Cisco Umbrella • Majectic Million • ThreatMiner • ThreatCrowd • Whois Требования к экспорту индикаторов Возможность экспорта индикаторов компрометации в файл в форматах XLSX, CSV, JSON с настройкой экспортируемой информации. Требования к интеграции с системами лог менеджмента Интеграция с системой MaxPatrol SIEM для обнаружения индикаторов компрометации (с поддержкой протокола TLS при подключении к RabbitMQ). Требования к интеграции с системами реагирования на инциденты ИБ и с почтовым сервером Наличие интеграции с Системой R-Vision SOAR для обеспечения возможности оперативного создания нового инцидента по факту новых обнаружений IoC на SIEM сенсорах или по факту обновления индикаторов компрометации. Возможность группировки событий обнаружения при отправке в R-Vision SOAR по следующим критериям: • По пороговому значению событий; • По временному интервалу; • По правилу обнаружения и значению IoC. Наличие коннектора для подключения к SMTP серверу для настройки оповещений. Требования к блоку взаимодействия c системой через API Система должна предоставлять возможность работать со своим функционалом через API. Система должна поддерживать GET и POST методы запросов. Система должна использовать токены для авторизации в API. Система должна поддерживать возможность запрета использования API заблокированным пользователям. Система должна поддерживать возможность запроса данных об индикаторах компрометации (IoC) из внешних систем по API. Требования к функциональному блоку обработки данных threat intelligence Агрегация, нормализация, дедупликация и отображение сведений TI в автоматическом режиме из различных источников, в том числе свободно распространяемых. Создание индикаторов компрометации вручную, а также возможность удаления таких индикаторов. Редактирование (в том числе массовое) как созданных вручную, так и полученных от поставщиков индикаторов, в том числе связывание с другими индикаторами, отчетами, вредоносным ПО и уязвимостями. Возможность добавления к индикаторам компрометации пользовательских тегов для маркировки, фильтрации и поиска в системе. Возможность вести в базе индикаторы, чья вредоносность еще не подтверждена, в качестве объектов наблюдения. Возможность редактирования, связывания объектов наблюдения с индикаторами компрометации и смены вида сущности с «объект наблюдения» на «индикатор компрометации» и обратно. Отображение следующих типов индикаторов компрометации: IP-адрес, domain, sha1, sha256, md5, e-mail, file, url, mask, ipv6, account, bank_card. Наличие графов взаимосвязей между данными TI – графическое отображение связей между индикаторами компрометации, отчетами, сведениями о вредоносном ПО, сведениями об уязвимостях, о вредоносных кампаниях, их жертвах, субъектах угроз, личностях с группировкой по сущностям (индикаторы компрометации, отчёты, уязвимости, вредоносное ПО, поставщики данных) с возможностью фильтрации данных на графе, а также экспорта графа в виде .png файла. Учет статуса индикатора компрометации (активный или неактивный). Требования к ранжированию индикаторов компрометации Наличие встроенной модели расчета рейтинга индикаторов компрометации, которая отражает степень достоверности данных. Возможность учета следующих метрик во встроенной модели расчета данных: • Обширность; • Оперативность; • Полнота. Возможность настройки времени и скорости затухания индикаторов компрометации. Использование списка исключений MISP Warninglists для автоматического снижения рейтинга входящих в список индикаторов компрометации до условно безопасного. Возможность выбора частоты обновления данного списка. Наличие возможности настройки политики устаревания для индикаторов компрометации, полученных от следующих поставщиков данных: • IBM X-Force; • AT&T Cybersecurity; • MISP; • ФинЦЕРТ: АСОИ; • RST Cloud; • Open source фиды. Возможность выбрать политику устаревания индикаторов компрометации из следующего списка: • Автоматический механизм; • Пользовательская настройка (с возможностью определения от какой даты будет отсчитываться время до устаревания индикатора 0 от даты создания или изменения, а также указать период устаревания). Учет встроенного механизма устаревания и информации об устаревании в правилах автоматизации для индикаторов компрометации, полученных от следующих поставщиков данных: • Kaspersky Threat Intelligence Services; • Group-IB Threat Exchange; • BiZone. Требования к функционалу сервиса обогащения Возможность обогащения индикаторов компрометации из поддерживаемых внешних систем дополнительной информацией как в ручном, так и в автоматическом режиме. Возможность обогащения индикаторов компрометации как из внешних, так и из локальных сервисов. Возможность автоматического создания новых объектов наблюдения в результате обогащения информации из VirusTotal о текущем индикаторе компрометации. Возможность задать время жизни данных обогащения в днях, часах или минутах, по истечении которого данные сервисов обогащения будут запрашиваться повторно. Возможность задать лимит запросов к сервису обогащения и период действия лимита. • Возможность поиска уязвимостей по нескольким значениям CVE, а также по точному совпадению; • Дополнительная возможность сортировки списка уязвимостей по CVE, CVSS, наличию патча; • Возможность сортировки списка угроз по имени, тегам, датам; • Возможность фильтрации списка угроз по одному или нескольким полям; • Возможность настройки перечня выводимых в общий список полей угроз. Наличие карточки угрозы для отчетов, вредоносного ПО, уязвимостей, кампаний, в которой отображается детальная информация об угрозе и ее взаимосвязях с другими сущностями системы. Требования к блоку автоматизации Возможность задавать правила автоматического обогащения индикаторов компрометации в соответствии с установленными критериями, а также устанавливать периодичность обогащения. Возможность задавать правила автоматического обнаружения индикаторов компрометации в соответствии с установленными критериями. Возможность задавать правила автоматического экспорта индикаторов компрометации в соответствии с установленными критериями в файл. Возможность задавать правила интеграции для автоматического создания инцидентов в системе R-Vision SOAR при возникновении событий обнаружения или изменения индикаторов компрометации, а также использование группировки событий по значению или по заданному правилу. Возможность использования пользовательских тегов в правилах обнаружения, обогащения, экспорта. Возможность отключения настроенных правил автоматизации. Требования к блоку аналитики Возможность создания аналитических отчетов, обобщенных количественных и качественных данных по поставщикам индикаторов компрометации и событиям обнаружений, как вручную, так и в автоматическом режиме по расписанию. Возможность экспорта отчетов в формате PDF. Возможность рассылки отчетов на указанный почтовый адрес, в том числе автоматически по расписанию. Возможность создания следующего списка аналитических отчетов: • Возраст индикаторов компрометации; • Жизненный цикл индикаторов компрометации; • Сводный отчет об источнике данных; • Сравнение источников данных. Требования к блоку визуализации Возможность добавления настраиваемых панелей визуализации: • создание и изменение произвольного числа индивидуальных дашбордов для каждого пользователя; • возможность развернуть дашборд на весь экран; • наличие виджетов для индикаторов компрометации, отчетов и уязвимостей; • возможность добавления произвольного числа преднастроенных виджетов на один дашборд, изменения их размеров и их перетаскивания по панели визуализации; • возможность отображать данные ноды SIEM-сенсора, а также статус ноды и статус сенсора; • автоматическое обновление данных для каждого виджета. Возможность отображения следующих виджетов: • Списки новых импортированных в систему отчетов, индикаторов и уязвимостей; • Обнаружения IoC; • Статистика по правилу автоматизации; • Индикаторы компрометации по странам; • Статистика SIEM; • Наиболее активные. Отображает 10 наиболее активных объектов, которые есть в системе. Наиболее активные — те, что обновлялись наибольшее количество раз за последние 24 часа + те, у которых наибольшее количество взаимосвязей (суммарно); • TOP-10 уязвимых вендоров за настраиваемый промежуток времени;ме • Текущая скорость обработки объектов в секунду; • Индикаторы компрометации по типам; • Количество индикаторов компрометации; • Обогащенные индикаторы за настраиваемый промежуток времени; • Новые IoC за сутки; • Обработанные объекты за последние 24 часа; • Индикаторы компрометации по отраслям; Отображает список новых индикаторов компрометации, уязвимостей или отчетов. Комплектация Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Товарный знак R-Vision - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Способ предоставления - Экземпляр на материальном носителе - - Класс программ для электронных вычислительных машин и баз данных - (03.07) Средства выявления и предотвращения целевых атак - - Вид лицензии - Простая (неисключительная) - - Назначение - Программное обеспечение платформы анализа информации об угрозах - - Функционал - Право на получение обновлений ПО в течение 12 месяцев. Технические требования к платформе анализа информации об угрозах: Требования по диагностированию платформы. Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа. К управлению платформой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Показатели назначения: Количество поставщиков данных TI: не менее 4. Количество сенсоров для взаимодействия с SIEM: 1. Требования к работе с поставщиками данных TI. Возможность настройки интеграции Системы не менее чем с 4 поставщиками данных киберразведки (Threat Intelligence), предоставляющими индикаторы компрометации и дополнительный контекст, из следующего списка: • R-Vision Threat Intelligence feed; • Kaspersky Threat Intelligence Services; • BiZone; • PT feed; • IBM X-Force; • AT&T OTX; • Group-IB Threat Exchange; • MISP; • ФинЦЕРТ: АСОИ; • Open source фиды в форматах TXT, CSV; • RST Cloud; • ESET; • Shadow; • National vulnerability database (NVD). Возможность при удалении поставщиков данных или каналов удалять вместе с ними и индикаторы компрометации, которые от них поступили. - - Требования к функционалу обнаружения индикаторов Возможность поиска IoC (в том числе ретроспективного с момента начала использования SIEM-сенсора) в событиях безопасности с использованием одного SIEM-сенсора системы. Возможность настраивать ротацию данных ноды, позволяющую при поступлении новых данных автоматически удалять события, у которых истек срок хранения. Возможность уведомления пользователей об обнаруженных Системой индикаторах компрометации. Возможность просмотра карточки обнаруженного индикатора с дополнительными сведениями по обнаруженному индикатору и информацией о взаимосвязях. Возможность работы со списком обнаруженных индикаторов: Возможность поиска индикаторов компрометации в общем списке обнаружений. Возможность фильтрации списка индикаторов по одному или нескольким полям. Возможность настройки перечня выводимых в общий список полей событий обнаружений. Требования к работе с угрозами Агрегация, нормализация, дедупликация и отображение сведений TI об отчетах (структурированных документах, содержащих описание угрозы с различной степенью детализации), вредоносном ПО, кампаниях, жертвах, субъектах угроз, личностях и уязвимостях в автоматическом режиме из различных источников, в том числе свободно распространяемых. Возможность добавления к угрозам типа отчеты, вредоносное ПО, уязвимости пользовательских тегов для маркировки, фильтрации и поиска в системе. Создание, редактирование и удаление угроз типа пользовательские отчеты, вредоносное ПО и кампании. Использование как минимум двух статусов для отчетов – «черновик» или «опубликован». Возможность учета информации о взаимосвязях между сущностями TI, если таковые имеются, включая схематичное отображение в виде графа связей с возможностью фильтрации данных на графе, кластеризации (объединения объектов на карте по типам или поставщикам), а также экспорта графа в виде .png файла. Возможность работы со списком угроз: • Возможность поиска в общем списке; - Возможность установки разной частоты обновлений для каналов внутри выбранного поставщика. Возможность добавления пользовательского поставщика данных для передачи информации об индикаторах компрометации из внешних систем по API. Возможность устанавливать рейтинг для таких индикаторов компрометации. Наличие конструктора синтаксического анализа данных, поступающих в формате csv от open source фидов. Требования к интеграции с сервисами обогащения Наличие интеграций для обогащения данных IoC со следующими внешними сервисами: • GeoIP: ipgeolocaton.io • OPSWAT Metadefender • Risk IQ • Shodan • VirusTotal • AlienLabs OTX Reputation • Alien Labs OTX • DomCop Top 10m • Cisco Umbrella • Majectic Million • ThreatMiner • ThreatCrowd • Whois Требования к экспорту индикаторов Возможность экспорта индикаторов компрометации в файл в форматах XLSX, CSV, JSON с настройкой экспортируемой информации. Требования к интеграции с системами лог менеджмента Интеграция с системой MaxPatrol SIEM для обнаружения индикаторов компрометации (с поддержкой протокола TLS при подключении к RabbitMQ). Требования к интеграции с системами реагирования на инциденты ИБ и с почтовым сервером Наличие интеграции с Системой R-Vision SOAR для обеспечения возможности оперативного создания нового инцидента по факту новых обнаружений IoC на SIEM сенсорах или по факту обновления индикаторов компрометации. Возможность группировки событий обнаружения при отправке в R-Vision SOAR по следующим критериям: • По пороговому значению событий; • По временному интервалу; • По правилу обнаружения и значению IoC. Наличие коннектора для подключения к SMTP серверу для настройки оповещений. Требования к блоку взаимодействия c системой через API Система должна предоставлять возможность работать со своим функционалом через API. Система должна поддерживать GET и POST методы запросов. Система должна использовать токены для авторизации в API. - Система должна поддерживать возможность запрета использования API заблокированным пользователям. Система должна поддерживать возможность запроса данных об индикаторах компрометации (IoC) из внешних систем по API. Требования к функциональному блоку обработки данных threat intelligence Агрегация, нормализация, дедупликация и отображение сведений TI в автоматическом режиме из различных источников, в том числе свободно распространяемых. Создание индикаторов компрометации вручную, а также возможность удаления таких индикаторов. Редактирование (в том числе массовое) как созданных вручную, так и полученных от поставщиков индикаторов, в том числе связывание с другими индикаторами, отчетами, вредоносным ПО и уязвимостями. Возможность добавления к индикаторам компрометации пользовательских тегов для маркировки, фильтрации и поиска в системе. Возможность вести в базе индикаторы, чья вредоносность еще не подтверждена, в качестве объектов наблюдения. Возможность редактирования, связывания объектов наблюдения с индикаторами компрометации и смены вида сущности с «объект наблюдения» на «индикатор компрометации» и обратно. Отображение следующих типов индикаторов компрометации: IP-адрес, domain, sha1, sha256, md5, e-mail, file, url, mask, ipv6, account, bank_card. Наличие графов взаимосвязей между данными TI – графическое отображение связей между индикаторами компрометации, отчетами, сведениями о вредоносном ПО, сведениями об уязвимостях, о вредоносных кампаниях, их жертвах, субъектах угроз, личностях с группировкой по сущностям (индикаторы компрометации, отчёты, уязвимости, вредоносное ПО, поставщики данных) с возможностью фильтрации данных на графе, а также экспорта графа в виде .png файла. Учет статуса индикатора компрометации (активный или неактивный). Требования к ранжированию индикаторов компрометации Наличие встроенной модели расчета рейтинга индикаторов компрометации, которая отражает степень достоверности данных. - Возможность учета следующих метрик во встроенной модели расчета данных: • Обширность; • Оперативность; • Полнота. Возможность настройки времени и скорости затухания индикаторов компрометации. Использование списка исключений MISP Warninglists для автоматического снижения рейтинга входящих в список индикаторов компрометации до условно безопасного. Возможность выбора частоты обновления данного списка. Наличие возможности настройки политики устаревания для индикаторов компрометации, полученных от следующих поставщиков данных: • IBM X-Force; • AT&T Cybersecurity; • MISP; • ФинЦЕРТ: АСОИ; • RST Cloud; • Open source фиды. Возможность выбрать политику устаревания индикаторов компрометации из следующего списка: • Автоматический механизм; • Пользовательская настройка (с возможностью определения от какой даты будет отсчитываться время до устаревания индикатора 0 от даты создания или изменения, а также указать период устаревания). Учет встроенного механизма устаревания и информации об устаревании в правилах автоматизации для индикаторов компрометации, полученных от следующих поставщиков данных: • Kaspersky Threat Intelligence Services; • Group-IB Threat Exchange; • BiZone. Требования к функционалу сервиса обогащения Возможность обогащения индикаторов компрометации из поддерживаемых внешних систем дополнительной информацией как в ручном, так и в автоматическом режиме. Возможность обогащения индикаторов компрометации как из внешних, так и из локальных сервисов. Возможность автоматического создания новых объектов наблюдения в результате обогащения информации из VirusTotal о текущем индикаторе компрометации. Возможность задать время жизни данных обогащения в днях, часах или минутах, по истечении которого данные сервисов обогащения будут запрашиваться повторно. Возможность задать лимит запросов к сервису обогащения и период действия лимита. - • Возможность поиска уязвимостей по нескольким значениям CVE, а также по точному совпадению; • Дополнительная возможность сортировки списка уязвимостей по CVE, CVSS, наличию патча; • Возможность сортировки списка угроз по имени, тегам, датам; • Возможность фильтрации списка угроз по одному или нескольким полям; • Возможность настройки перечня выводимых в общий список полей угроз. Наличие карточки угрозы для отчетов, вредоносного ПО, уязвимостей, кампаний, в которой отображается детальная информация об угрозе и ее взаимосвязях с другими сущностями системы. Требования к блоку автоматизации Возможность задавать правила автоматического обогащения индикаторов компрометации в соответствии с установленными критериями, а также устанавливать периодичность обогащения. Возможность задавать правила автоматического обнаружения индикаторов компрометации в соответствии с установленными критериями. Возможность задавать правила автоматического экспорта индикаторов компрометации в соответствии с установленными критериями в файл. Возможность задавать правила интеграции для автоматического создания инцидентов в системе R-Vision SOAR при возникновении событий обнаружения или изменения индикаторов компрометации, а также использование группировки событий по значению или по заданному правилу. Возможность использования пользовательских тегов в правилах обнаружения, обогащения, экспорта. Возможность отключения настроенных правил автоматизации. Требования к блоку аналитики Возможность создания аналитических отчетов, обобщенных количественных и качественных данных по поставщикам индикаторов компрометации и событиям обнаружений, как вручную, так и в автоматическом режиме по расписанию. Возможность экспорта отчетов в формате PDF. Возможность рассылки отчетов на указанный почтовый адрес, в том числе автоматически по расписанию. Возможность создания следующего списка аналитических отчетов: • Возраст индикаторов компрометации; • Жизненный цикл индикаторов компрометации; - • Сводный отчет об источнике данных; • Сравнение источников данных. Требования к блоку визуализации Возможность добавления настраиваемых панелей визуализации: • создание и изменение произвольного числа индивидуальных дашбордов для каждого пользователя; • возможность развернуть дашборд на весь экран; • наличие виджетов для индикаторов компрометации, отчетов и уязвимостей; • возможность добавления произвольного числа преднастроенных виджетов на один дашборд, изменения их размеров и их перетаскивания по панели визуализации; • возможность отображать данные ноды SIEM-сенсора, а также статус ноды и статус сенсора; • автоматическое обновление данных для каждого виджета. Возможность отображения следующих виджетов: • Списки новых импортированных в систему отчетов, индикаторов и уязвимостей; • Обнаружения IoC; • Статистика по правилу автоматизации; • Индикаторы компрометации по странам; • Статистика SIEM; • Наиболее активные. Отображает 10 наиболее активных объектов, которые есть в системе. Наиболее активные — те, что обновлялись наибольшее количество раз за последние 24 часа + те, у которых наибольшее количество взаимосвязей (суммарно); • TOP-10 уязвимых вендоров за настраиваемый промежуток времени;ме • Текущая скорость обработки объектов в секунду; • Индикаторы компрометации по типам; • Количество индикаторов компрометации; • Обогащенные индикаторы за настраиваемый промежуток времени; • Новые IoC за сутки; • Обработанные объекты за последние 24 часа; • Индикаторы компрометации по отраслям; Отображает список новых индикаторов компрометации, уязвимостей или отчетов. - Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. - - Товарный знак - R-Vision -

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

Способ предоставления - Экземпляр на материальном носителе -

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

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

Назначение - Программное обеспечение платформы анализа информации об угрозах -

Функционал - Право на получение обновлений ПО в течение 12 месяцев. Технические требования к платформе анализа информации об угрозах: Требования по диагностированию платформы. Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа. К управлению платформой должен быть допущен строго ограниченный круг лиц. Информация об инцидентах, собранная Системой в ходе работы, должна храниться в зашифрованном виде. Система должна поддерживать возможность разграничения прав доступа к средствам администрирования и обработке возникающих инцидентов. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Показатели назначения: Количество поставщиков данных TI: не менее 4. Количество сенсоров для взаимодействия с SIEM: 1. Требования к работе с поставщиками данных TI. Возможность настройки интеграции Системы не менее чем с 4 поставщиками данных киберразведки (Threat Intelligence), предоставляющими индикаторы компрометации и дополнительный контекст, из следующего списка: • R-Vision Threat Intelligence feed; • Kaspersky Threat Intelligence Services; • BiZone; • PT feed; • IBM X-Force; • AT&T OTX; • Group-IB Threat Exchange; • MISP; • ФинЦЕРТ: АСОИ; • Open source фиды в форматах TXT, CSV; • RST Cloud; • ESET; • Shadow; • National vulnerability database (NVD). Возможность при удалении поставщиков данных или каналов удалять вместе с ними и индикаторы компрометации, которые от них поступили. -

Требования к функционалу обнаружения индикаторов Возможность поиска IoC (в том числе ретроспективного с момента начала использования SIEM-сенсора) в событиях безопасности с использованием одного SIEM-сенсора системы. Возможность настраивать ротацию данных ноды, позволяющую при поступлении новых данных автоматически удалять события, у которых истек срок хранения. Возможность уведомления пользователей об обнаруженных Системой индикаторах компрометации. Возможность просмотра карточки обнаруженного индикатора с дополнительными сведениями по обнаруженному индикатору и информацией о взаимосвязях. Возможность работы со списком обнаруженных индикаторов: Возможность поиска индикаторов компрометации в общем списке обнаружений. Возможность фильтрации списка индикаторов по одному или нескольким полям. Возможность настройки перечня выводимых в общий список полей событий обнаружений. Требования к работе с угрозами Агрегация, нормализация, дедупликация и отображение сведений TI об отчетах (структурированных документах, содержащих описание угрозы с различной степенью детализации), вредоносном ПО, кампаниях, жертвах, субъектах угроз, личностях и уязвимостях в автоматическом режиме из различных источников, в том числе свободно распространяемых. Возможность добавления к угрозам типа отчеты, вредоносное ПО, уязвимости пользовательских тегов для маркировки, фильтрации и поиска в системе. Создание, редактирование и удаление угроз типа пользовательские отчеты, вредоносное ПО и кампании. Использование как минимум двух статусов для отчетов – «черновик» или «опубликован». Возможность учета информации о взаимосвязях между сущностями TI, если таковые имеются, включая схематичное отображение в виде графа связей с возможностью фильтрации данных на графе, кластеризации (объединения объектов на карте по типам или поставщикам), а также экспорта графа в виде .png файла. Возможность работы со списком угроз: • Возможность поиска в общем списке;

Возможность установки разной частоты обновлений для каналов внутри выбранного поставщика. Возможность добавления пользовательского поставщика данных для передачи информации об индикаторах компрометации из внешних систем по API. Возможность устанавливать рейтинг для таких индикаторов компрометации. Наличие конструктора синтаксического анализа данных, поступающих в формате csv от open source фидов. Требования к интеграции с сервисами обогащения Наличие интеграций для обогащения данных IoC со следующими внешними сервисами: • GeoIP: ipgeolocaton.io • OPSWAT Metadefender • Risk IQ • Shodan • VirusTotal • AlienLabs OTX Reputation • Alien Labs OTX • DomCop Top 10m • Cisco Umbrella • Majectic Million • ThreatMiner • ThreatCrowd • Whois Требования к экспорту индикаторов Возможность экспорта индикаторов компрометации в файл в форматах XLSX, CSV, JSON с настройкой экспортируемой информации. Требования к интеграции с системами лог менеджмента Интеграция с системой MaxPatrol SIEM для обнаружения индикаторов компрометации (с поддержкой протокола TLS при подключении к RabbitMQ). Требования к интеграции с системами реагирования на инциденты ИБ и с почтовым сервером Наличие интеграции с Системой R-Vision SOAR для обеспечения возможности оперативного создания нового инцидента по факту новых обнаружений IoC на SIEM сенсорах или по факту обновления индикаторов компрометации. Возможность группировки событий обнаружения при отправке в R-Vision SOAR по следующим критериям: • По пороговому значению событий; • По временному интервалу; • По правилу обнаружения и значению IoC. Наличие коннектора для подключения к SMTP серверу для настройки оповещений. Требования к блоку взаимодействия c системой через API Система должна предоставлять возможность работать со своим функционалом через API. Система должна поддерживать GET и POST методы запросов. Система должна использовать токены для авторизации в API.

Система должна поддерживать возможность запрета использования API заблокированным пользователям. Система должна поддерживать возможность запроса данных об индикаторах компрометации (IoC) из внешних систем по API. Требования к функциональному блоку обработки данных threat intelligence Агрегация, нормализация, дедупликация и отображение сведений TI в автоматическом режиме из различных источников, в том числе свободно распространяемых. Создание индикаторов компрометации вручную, а также возможность удаления таких индикаторов. Редактирование (в том числе массовое) как созданных вручную, так и полученных от поставщиков индикаторов, в том числе связывание с другими индикаторами, отчетами, вредоносным ПО и уязвимостями. Возможность добавления к индикаторам компрометации пользовательских тегов для маркировки, фильтрации и поиска в системе. Возможность вести в базе индикаторы, чья вредоносность еще не подтверждена, в качестве объектов наблюдения. Возможность редактирования, связывания объектов наблюдения с индикаторами компрометации и смены вида сущности с «объект наблюдения» на «индикатор компрометации» и обратно. Отображение следующих типов индикаторов компрометации: IP-адрес, domain, sha1, sha256, md5, e-mail, file, url, mask, ipv6, account, bank_card. Наличие графов взаимосвязей между данными TI – графическое отображение связей между индикаторами компрометации, отчетами, сведениями о вредоносном ПО, сведениями об уязвимостях, о вредоносных кампаниях, их жертвах, субъектах угроз, личностях с группировкой по сущностям (индикаторы компрометации, отчёты, уязвимости, вредоносное ПО, поставщики данных) с возможностью фильтрации данных на графе, а также экспорта графа в виде .png файла. Учет статуса индикатора компрометации (активный или неактивный). Требования к ранжированию индикаторов компрометации Наличие встроенной модели расчета рейтинга индикаторов компрометации, которая отражает степень достоверности данных.

Возможность учета следующих метрик во встроенной модели расчета данных: • Обширность; • Оперативность; • Полнота. Возможность настройки времени и скорости затухания индикаторов компрометации. Использование списка исключений MISP Warninglists для автоматического снижения рейтинга входящих в список индикаторов компрометации до условно безопасного. Возможность выбора частоты обновления данного списка. Наличие возможности настройки политики устаревания для индикаторов компрометации, полученных от следующих поставщиков данных: • IBM X-Force; • AT&T Cybersecurity; • MISP; • ФинЦЕРТ: АСОИ; • RST Cloud; • Open source фиды. Возможность выбрать политику устаревания индикаторов компрометации из следующего списка: • Автоматический механизм; • Пользовательская настройка (с возможностью определения от какой даты будет отсчитываться время до устаревания индикатора 0 от даты создания или изменения, а также указать период устаревания). Учет встроенного механизма устаревания и информации об устаревании в правилах автоматизации для индикаторов компрометации, полученных от следующих поставщиков данных: • Kaspersky Threat Intelligence Services; • Group-IB Threat Exchange; • BiZone. Требования к функционалу сервиса обогащения Возможность обогащения индикаторов компрометации из поддерживаемых внешних систем дополнительной информацией как в ручном, так и в автоматическом режиме. Возможность обогащения индикаторов компрометации как из внешних, так и из локальных сервисов. Возможность автоматического создания новых объектов наблюдения в результате обогащения информации из VirusTotal о текущем индикаторе компрометации. Возможность задать время жизни данных обогащения в днях, часах или минутах, по истечении которого данные сервисов обогащения будут запрашиваться повторно. Возможность задать лимит запросов к сервису обогащения и период действия лимита.

• Возможность поиска уязвимостей по нескольким значениям CVE, а также по точному совпадению; • Дополнительная возможность сортировки списка уязвимостей по CVE, CVSS, наличию патча; • Возможность сортировки списка угроз по имени, тегам, датам; • Возможность фильтрации списка угроз по одному или нескольким полям; • Возможность настройки перечня выводимых в общий список полей угроз. Наличие карточки угрозы для отчетов, вредоносного ПО, уязвимостей, кампаний, в которой отображается детальная информация об угрозе и ее взаимосвязях с другими сущностями системы. Требования к блоку автоматизации Возможность задавать правила автоматического обогащения индикаторов компрометации в соответствии с установленными критериями, а также устанавливать периодичность обогащения. Возможность задавать правила автоматического обнаружения индикаторов компрометации в соответствии с установленными критериями. Возможность задавать правила автоматического экспорта индикаторов компрометации в соответствии с установленными критериями в файл. Возможность задавать правила интеграции для автоматического создания инцидентов в системе R-Vision SOAR при возникновении событий обнаружения или изменения индикаторов компрометации, а также использование группировки событий по значению или по заданному правилу. Возможность использования пользовательских тегов в правилах обнаружения, обогащения, экспорта. Возможность отключения настроенных правил автоматизации. Требования к блоку аналитики Возможность создания аналитических отчетов, обобщенных количественных и качественных данных по поставщикам индикаторов компрометации и событиям обнаружений, как вручную, так и в автоматическом режиме по расписанию. Возможность экспорта отчетов в формате PDF. Возможность рассылки отчетов на указанный почтовый адрес, в том числе автоматически по расписанию. Возможность создания следующего списка аналитических отчетов: • Возраст индикаторов компрометации; • Жизненный цикл индикаторов компрометации;

• Сводный отчет об источнике данных; • Сравнение источников данных. Требования к блоку визуализации Возможность добавления настраиваемых панелей визуализации: • создание и изменение произвольного числа индивидуальных дашбордов для каждого пользователя; • возможность развернуть дашборд на весь экран; • наличие виджетов для индикаторов компрометации, отчетов и уязвимостей; • возможность добавления произвольного числа преднастроенных виджетов на один дашборд, изменения их размеров и их перетаскивания по панели визуализации; • возможность отображать данные ноды SIEM-сенсора, а также статус ноды и статус сенсора; • автоматическое обновление данных для каждого виджета. Возможность отображения следующих виджетов: • Списки новых импортированных в систему отчетов, индикаторов и уязвимостей; • Обнаружения IoC; • Статистика по правилу автоматизации; • Индикаторы компрометации по странам; • Статистика SIEM; • Наиболее активные. Отображает 10 наиболее активных объектов, которые есть в системе. Наиболее активные — те, что обновлялись наибольшее количество раз за последние 24 часа + те, у которых наибольшее количество взаимосвязей (суммарно); • TOP-10 уязвимых вендоров за настраиваемый промежуток времени;ме • Текущая скорость обработки объектов в секунду; • Индикаторы компрометации по типам; • Количество индикаторов компрометации; • Обогащенные индикаторы за настраиваемый промежуток времени; • Новые IoC за сутки; • Обработанные объекты за последние 24 часа; • Индикаторы компрометации по отраслям; Отображает список новых индикаторов компрометации, уязвимостей или отчетов.

Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. -

Товарный знак - R-Vision -

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

- 58.29.50.000 58.29.11.000-00000003 - Программное обеспечение Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) - Штука - 1,00 - 2 320 578,00 - 2 320 578,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "ЦЕНТР ЗАЩИТЫ ИНФОРМАЦИИ НОВОСИБИРСКОЙ ОБЛАСТИ" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) Назначение Программное обеспечение информационного взаимодействия с НКЦКИ Функционал Право на получение обновлений ПО в течение 12 месяцев. Требования к информационному взаимодействию с НКЦКИ: - Возможность экспорта сведений об инциденте для отправки уведомлений в систему ГосСОПКА из карточки инцидента как в ручном, так и в полуавтоматическом режиме; - Возможность автоматизированного заполнения карточки ГосСОПКА значениями полей карточки инцидента; - Возможность получать и обрабатывать в системе инциденты типа "Сообщения от НКЦКИ", автоматически полученные из ГосСОПКА, возможность скачивания/просмотра свидетельств по сообщению, возможность изменения значений полей "Статус" и "Результат принятого решения" и их отправка в ЛК ГосСОПКА; - Возможность приложить файлы свидетельств по инциденту к карточке экспорта; - Возможность вести переписку между пользователем и оператором НКЦКИ в карточке инцидента как по отправленным, так и по полученным инцидентам. Комплектация Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Товарный знак R-Vision - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Способ предоставления - Экземпляр на материальном носителе - - Класс программ для электронных вычислительных машин и баз данных - (03.17) Средства автоматизации процессов информационной безопасности - - Вид лицензии - Простая (неисключительная) - - Назначение - Программное обеспечение информационного взаимодействия с НКЦКИ - - Функционал - Право на получение обновлений ПО в течение 12 месяцев. Требования к информационному взаимодействию с НКЦКИ: - Возможность экспорта сведений об инциденте для отправки уведомлений в систему ГосСОПКА из карточки инцидента как в ручном, так и в полуавтоматическом режиме; - Возможность автоматизированного заполнения карточки ГосСОПКА значениями полей карточки инцидента; - Возможность получать и обрабатывать в системе инциденты типа "Сообщения от НКЦКИ", автоматически полученные из ГосСОПКА, возможность скачивания/просмотра свидетельств по сообщению, возможность изменения значений полей "Статус" и "Результат принятого решения" и их отправка в ЛК ГосСОПКА; - Возможность приложить файлы свидетельств по инциденту к карточке экспорта; - Возможность вести переписку между пользователем и оператором НКЦКИ в карточке инцидента как по отправленным, так и по полученным инцидентам. - - Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. - - Товарный знак - R-Vision -

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

Способ предоставления - Экземпляр на материальном носителе -

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

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

Назначение - Программное обеспечение информационного взаимодействия с НКЦКИ -

Функционал - Право на получение обновлений ПО в течение 12 месяцев. Требования к информационному взаимодействию с НКЦКИ: - Возможность экспорта сведений об инциденте для отправки уведомлений в систему ГосСОПКА из карточки инцидента как в ручном, так и в полуавтоматическом режиме; - Возможность автоматизированного заполнения карточки ГосСОПКА значениями полей карточки инцидента; - Возможность получать и обрабатывать в системе инциденты типа "Сообщения от НКЦКИ", автоматически полученные из ГосСОПКА, возможность скачивания/просмотра свидетельств по сообщению, возможность изменения значений полей "Статус" и "Результат принятого решения" и их отправка в ЛК ГосСОПКА; - Возможность приложить файлы свидетельств по инциденту к карточке экспорта; - Возможность вести переписку между пользователем и оператором НКЦКИ в карточке инцидента как по отправленным, так и по полученным инцидентам. -

Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. -

Товарный знак - R-Vision -

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

- 58.29.50.000 58.29.11.000-00000003 - Программное обеспечение Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) - Штука - 1,00 - 6 046 950,00 - 6 046 950,00

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ НОВОСИБИРСКОЙ ОБЛАСТИ "ЦЕНТР ЗАЩИТЫ ИНФОРМАЦИИ НОВОСИБИРСКОЙ ОБЛАСТИ" - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Способ предоставления Экземпляр на материальном носителе Класс программ для электронных вычислительных машин и баз данных (03.17) Средства автоматизации процессов информационной безопасности Вид лицензии Простая (неисключительная) Назначение Программное обеспечения платформы для управления объектами ложной инфраструктуры Функционал Возможность автоматической генерации наполнения ловушек: • для логинов - в соответствии со словарями значений ФИО по заданному паттерну, а также с возможностью использования нескольких словарей с определением процентного соотношения использования. Словари славянских, тюркских и кавказских имен должны быть загружены в систему, а также должна поддерживаться возможность добавления собственных словарей; • для паролей - в соответствии с базой популярных паролей или в соответствии с заданными вручную критериями генерации; • для имен серверов - в соответствии со словарем (встроенным или пользовательским); • для FTP баннеров - в соответствии со словарем (встроенным или пользовательским). Наличие карточки ловушки, отображение в карточке следующей информации: • Информация о ловушке: название, статус, тип, IP-адрес, сеть, сервер управления ловушками, даты создания и обновления, технические параметры, список УЗ. • Связанные приманки: список приманок с указанием типа, статуса, связанных хостов, конфигурации, а также с возможностью фильтрации приманок по типу и сортировки списка по названию и дате создания; • События: список событий взаимодействия с ловушкой в виде таймлайна с возможностью фильтрации по периоду и критичности события. Возможность изменения статуса ловушек из интерфейса системы: включение или выключение, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Возможность учета сетей, в которых могут быть размещены ловушки. Использование динамических или статических диапазонов адресных пространств. Учет количества активных ловушек в сети, а также количества свободных IP адресов для размещения ловушек. Возможность просмотра карточки сети с отображением более подробной информации, в том числе диапазона доступных IP адресов для ловушек. Возможность указания сетевого адреса оборудования, сетевые пакеты с которого будут игнорироваться (blackhole). Технические требования к платформе для управления объектами ложной инфраструктуры Право на получение обновлений ПО в течение 12 месяцев Требования по диагностированию платформы Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа К управлению платформой должен быть допущен строго ограниченный круг лиц. Показатели назначения: Количество ловушек – не менее 64. Количество серверов управления ловушками – 2. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Требования к функциям создания и управления ловушками Возможность создания ловушек вручную через интерфейс Системы. Возможность автоматического создания заданного количества ловушек любых типов на выбранном сервере управления через интерфейс Системы. Возможность задать график размещения ловушек для равномерного создания объектов в рабочее время указанного временного интервала. Возможность размещения ловушек на любом подключённом сервере управления ловушками и в любой сети, подключенной к выбранному серверу (за исключением сети управления Системой). Каждая из создаваемых ловушек должна однозначно определяться по уникальным IP-адресу и физическому сетевому (MAC) адресу в рамках одного сервера ловушек. Система должна позволять задавать префикс MAC-адреса при создании ловушки. Создаваемые ловушки должны имитировать сервисы в инфраструктуре заказчика с разными уровнями интерактивности. Требования к функциям управления приманками: Возможность создания приманок вручную для выбранных ловушек через интерфейс Системы. Возможность автоматического создания заданного количества приманок выбранных типов для созданных ловушек через интерфейс Системы. Учет всех приманок в едином окне Системы с отображением общего количества приманок в системе. Наличие возможности создания приманок следующих типов: • HOSTS; • PuTTY-реестр; • PuTTY-ярлык; • WinSCP-реестр; • WinSCP-ярлык; • FileZilla; • Windows Remote Desktop – реестр; • Credential Manager-windows; • Credential Manager-generic; • Browser saved credentials; • Текстовый файл; • Windows Remote Desktop - файл сессии; • SMB диск-ярлык; • SMB диск; • История команд терминала. Возможность выбора операционной системы, для которой создается приманка: • Windows (для приманок типа HOSTS, PuTTY-реестр, PuTTY-ярлык, WinSCP-реестр, WinSCP-ярлык, FileZilla, Windows Remote Desktop, Credential Manager, Browser saved credentials, Текстовый файл, Windows Remote Desktop - файл сессии, SMB диск-ярлык, SMB диск-ярлык); • Linux (для приманок типа HOSTS, История команд терминала); • MacOS (для приманок типа HOSTS). Возможность выбора типа ловушки для которой создается приманка. Наличие функции размещения приманок на узлах сети, работающих на операционных системах Windows, Linux, MacOS. Поддержка распространения приманок через агенты конечных устройств. Возможность проверки установленного на АРМ ПО для автоматического выбора устанавливаемой приманки. Возможности работы со списком приманок: • Сортировка списка по названию, дате создания; • Фильтрация списка по типу приманки; • Групповое удаление приманок из системы; • Групповое удаление приманок с хостов. Наличие карточки приманки, отображение в карточке следующей информации: • Информация о приманке: название, статус, тип, даты создания и обновления, связанные хосты и связанные ловушки, а также конфигурация приманки. Возможности работы со списком событий: • Наличие функции поиска по событиям; • Наличие фильтров по дате события, критичности события, типу ловушки. Возможность просмотра событий по конкретной ловушке в виде таймлайна в разделе «События». Возможность добавлять комментарии к событиям. Возможность экспорта в формат CSV как всех событий, так и отфильтрованного списка событий. Возможность добавления источников событий в исключения. Требования к функциям визуализации Наличие панели визуализации с автоматическим обновлением данных по каждому виджету: • Наличие виджета, отображающего количество событий за сутки в Системе; • Наличие виджета, отображающего количество ловушек в Системе; • Наличие виджета, отображающего время (в секундах, минутах, часах, днях, неделях, месяцах) без происшествий в Системе; • Наличие виджета, отображающего процентное отношение событий по типу ловушки; • Наличие виджета, отображающего процентное отношение событий по критичности событий; • Наличие виджета, отображающего Топ-5 целей (ловушек) с указанием IP-адреса ловушки и количеством событий; • Наличие виджета, отображающего график с количеством событий за последние 24 часа; • Наличие виджета, отображающего последние 5 событий. Учет всех ловушек в едином окне с отображением общего количества ловушек в Системе. Возможность настройки правил исключения для доверенных систем (сканер безопасности и др.). Наличие возможности создания ловушек следующих типов с указанием учетных данных (логин и пароль) для аутентификации: • FTP: FTP-сервер; • ОС Windows: Имитация рабочего места пользователя/сервера с возможностью подключения по паре логин/пароль через rdp-соединение; • ОС Linux: Имитация Linux Debian или CentOS; • SMB / SMB FS: SMB-сервер или доступ к его файловой системе; • SSH: SSH-сервер; • HTTP(S): имитация страницы ввода логина и пароля с авторизацией по введенной паре; • PostgreSQL: имитация СУБД на базе PostgreSQL версии 15; • MySQL: имитация СУБД на базе MySQL версии 8; • Deceptive Ports: имитация открытых TCP/UDP портов. Возможности для ловушек типа FTP: • Подключение к созданной ловушке по протоколу «FTP» с использованием параметров, указанных при создании; • Определение порта подключения; • Определение диапазона портов пассивного режима от 1024 до 65535; • Добавление текста баннера; • Разрешение анонимного входа на ловушку. Возможности для ловушек типа ОС Windows: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Windows по протоколу «RDP». Возможности для ловушек типа ОС Linux: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Linux по протоколу «SSH». Возможности для ловушек типа SMB / SMB FS: • Выбор ОС (Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows XP, Windows 2000, Windows Server 2016, Windows Server 2012, Windows Server 2008, Linux Samba); • Подключение к созданной ловушке типа «SMB» по протоколу «SMB» с использованием параметров, указанных при создании. Возможности для ловушек типа SSH: • Подключение к созданной ловушке типа «SSH» по протоколу «SSH» с использованием параметров, указанных при создании; • Выбор ОС (Ubuntu 16.04 64bit, Ubuntu 18.04 64bit, CentOS 7 64bit, CentOS 8 64bit, Debian 9 64bit, Debian 10 64bit); • Функция случайной аутентификации на ловушке с определением диапазона количества попыток до успешной случайной аутентификации, а также количества кэшируемых комбинаций учетных данных успешной случайной аутентификации. Возможности для ловушек типа HTTP(S) и HTTP(S) v2: • Подключение к созданной ловушке типа «HTTP(S)» по протоколу HTTP(S) с использованием параметров, указанных при создании; • Определение порта подключения; • Выбор шаблона страницы; • Выбор следующего типа сервера (Apache, Nginx, Microsoft-IIS, Cloudflare, SmartXFilter, Apache-Coyote, AkamiGHost) – только для HTTP(S); • Использование сертификатов для режима HTTPS. Возможности для ловушек типа PostgreSQL: • Подключение к созданной ловушке типа PostgreSQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа MySQL: • Подключение к созданной ловушке типа MySQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа DeceptivePorts: • Подключение к созданной ловушке типа DeceptivePorts; • Определение портов TCP/UDP для подключения. Возможности работы со списком ловушек: • Сортировка списка по названию, датам создания и обновления; • Фильтрация списка по статусу ловушки; • Групповая модификация статусов ловушек; • Групповое удаление ловушек. • Связанные хосты: список хостов, на которых размещена приманка с функционалом сквозного поиска и фильтрацией по типу ОС. Возможность размещения приманок встроенными средствами Системы как одной, так и группы приманок. Возможность размещения как всех выбранных приманок, так и случайный набор из выбранных. При размещении приманок случайным образом система должна размещать от 70 до 90 % случайно выбранных приманок, подходящих для хоста. Автоматическое формирование отчета по факту размещения с возможностью загрузки в Систему для учета размещенных в инфраструктуре приманок. Отображение статуса ловушек в интерфейсе системы: включена, выключена, обслуживание, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Учет узлов сети - перечня устройств, на которых размещены приманки с возможностью поиска и фильтрации по типам ОС устройств. Требования к функциям создания и управления ложными учетными записями Возможность создания специально подготовленных ложных учетных записей в Active Directory. Возможность задавать параметры для создания ложных учетных записей, включая выбор домена, OU, возможность задать процент ложных учетных записей от общего количества или количество таких записей, возможность задать эталонную УЗ, в соответствии с которой будут формироваться ложные УЗ. Возможность размещения ложных учетных записей в доменах организации. Учет всех ложных УЗ в едином окне с отображением общего количества записей. Возможности работы со списком ложных УЗ: • Сортировка списка по названию, статусу, OU, дате создания; • Фильтрация списка по статусу, OU, датам создания и размещения; • Групповое редактирование ложных УЗ; • Групповое удаление ложных УЗ. Экспорт созданных записей в виде списка для загрузки в SIEM с целью контроля созданных учетных записей. Требования к учету событий Учет событий, связанных с регистрацией действий на ловушке с отображением общего количества событий. Комплектация Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. Товарный знак R-Vision - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Способ предоставления - Экземпляр на материальном носителе - - Класс программ для электронных вычислительных машин и баз данных - (03.17) Средства автоматизации процессов информационной безопасности - - Вид лицензии - Простая (неисключительная) - - Назначение - Программное обеспечения платформы для управления объектами ложной инфраструктуры - - Функционал - Возможность автоматической генерации наполнения ловушек: • для логинов - в соответствии со словарями значений ФИО по заданному паттерну, а также с возможностью использования нескольких словарей с определением процентного соотношения использования. Словари славянских, тюркских и кавказских имен должны быть загружены в систему, а также должна поддерживаться возможность добавления собственных словарей; • для паролей - в соответствии с базой популярных паролей или в соответствии с заданными вручную критериями генерации; • для имен серверов - в соответствии со словарем (встроенным или пользовательским); • для FTP баннеров - в соответствии со словарем (встроенным или пользовательским). Наличие карточки ловушки, отображение в карточке следующей информации: • Информация о ловушке: название, статус, тип, IP-адрес, сеть, сервер управления ловушками, даты создания и обновления, технические параметры, список УЗ. • Связанные приманки: список приманок с указанием типа, статуса, связанных хостов, конфигурации, а также с возможностью фильтрации приманок по типу и сортировки списка по названию и дате создания; • События: список событий взаимодействия с ловушкой в виде таймлайна с возможностью фильтрации по периоду и критичности события. Возможность изменения статуса ловушек из интерфейса системы: включение или выключение, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Возможность учета сетей, в которых могут быть размещены ловушки. Использование динамических или статических диапазонов адресных пространств. Учет количества активных ловушек в сети, а также количества свободных IP адресов для размещения ловушек. Возможность просмотра карточки сети с отображением более подробной информации, в том числе диапазона доступных IP адресов для ловушек. Возможность указания сетевого адреса оборудования, сетевые пакеты с которого будут игнорироваться (blackhole). - - Технические требования к платформе для управления объектами ложной инфраструктуры Право на получение обновлений ПО в течение 12 месяцев Требования по диагностированию платформы Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа К управлению платформой должен быть допущен строго ограниченный круг лиц. Показатели назначения: Количество ловушек – не менее 64. Количество серверов управления ловушками – 2. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Требования к функциям создания и управления ловушками Возможность создания ловушек вручную через интерфейс Системы. Возможность автоматического создания заданного количества ловушек любых типов на выбранном сервере управления через интерфейс Системы. Возможность задать график размещения ловушек для равномерного создания объектов в рабочее время указанного временного интервала. Возможность размещения ловушек на любом подключённом сервере управления ловушками и в любой сети, подключенной к выбранному серверу (за исключением сети управления Системой). Каждая из создаваемых ловушек должна однозначно определяться по уникальным IP-адресу и физическому сетевому (MAC) адресу в рамках одного сервера ловушек. Система должна позволять задавать префикс MAC-адреса при создании ловушки. Создаваемые ловушки должны имитировать сервисы в инфраструктуре заказчика с разными уровнями интерактивности. - Требования к функциям управления приманками: Возможность создания приманок вручную для выбранных ловушек через интерфейс Системы. Возможность автоматического создания заданного количества приманок выбранных типов для созданных ловушек через интерфейс Системы. Учет всех приманок в едином окне Системы с отображением общего количества приманок в системе. Наличие возможности создания приманок следующих типов: • HOSTS; • PuTTY-реестр; • PuTTY-ярлык; • WinSCP-реестр; • WinSCP-ярлык; • FileZilla; • Windows Remote Desktop – реестр; • Credential Manager-windows; • Credential Manager-generic; • Browser saved credentials; • Текстовый файл; • Windows Remote Desktop - файл сессии; • SMB диск-ярлык; • SMB диск; • История команд терминала. Возможность выбора операционной системы, для которой создается приманка: • Windows (для приманок типа HOSTS, PuTTY-реестр, PuTTY-ярлык, WinSCP-реестр, WinSCP-ярлык, FileZilla, Windows Remote Desktop, Credential Manager, Browser saved credentials, Текстовый файл, Windows Remote Desktop - файл сессии, SMB диск-ярлык, SMB диск-ярлык); • Linux (для приманок типа HOSTS, История команд терминала); • MacOS (для приманок типа HOSTS). Возможность выбора типа ловушки для которой создается приманка. Наличие функции размещения приманок на узлах сети, работающих на операционных системах Windows, Linux, MacOS. Поддержка распространения приманок через агенты конечных устройств. Возможность проверки установленного на АРМ ПО для автоматического выбора устанавливаемой приманки. Возможности работы со списком приманок: • Сортировка списка по названию, дате создания; • Фильтрация списка по типу приманки; • Групповое удаление приманок из системы; • Групповое удаление приманок с хостов. Наличие карточки приманки, отображение в карточке следующей информации: • Информация о приманке: название, статус, тип, даты создания и обновления, связанные хосты и связанные ловушки, а также конфигурация приманки. - Возможности работы со списком событий: • Наличие функции поиска по событиям; • Наличие фильтров по дате события, критичности события, типу ловушки. Возможность просмотра событий по конкретной ловушке в виде таймлайна в разделе «События». Возможность добавлять комментарии к событиям. Возможность экспорта в формат CSV как всех событий, так и отфильтрованного списка событий. Возможность добавления источников событий в исключения. Требования к функциям визуализации Наличие панели визуализации с автоматическим обновлением данных по каждому виджету: • Наличие виджета, отображающего количество событий за сутки в Системе; • Наличие виджета, отображающего количество ловушек в Системе; • Наличие виджета, отображающего время (в секундах, минутах, часах, днях, неделях, месяцах) без происшествий в Системе; • Наличие виджета, отображающего процентное отношение событий по типу ловушки; • Наличие виджета, отображающего процентное отношение событий по критичности событий; • Наличие виджета, отображающего Топ-5 целей (ловушек) с указанием IP-адреса ловушки и количеством событий; • Наличие виджета, отображающего график с количеством событий за последние 24 часа; • Наличие виджета, отображающего последние 5 событий. - Учет всех ловушек в едином окне с отображением общего количества ловушек в Системе. Возможность настройки правил исключения для доверенных систем (сканер безопасности и др.). Наличие возможности создания ловушек следующих типов с указанием учетных данных (логин и пароль) для аутентификации: • FTP: FTP-сервер; • ОС Windows: Имитация рабочего места пользователя/сервера с возможностью подключения по паре логин/пароль через rdp-соединение; • ОС Linux: Имитация Linux Debian или CentOS; • SMB / SMB FS: SMB-сервер или доступ к его файловой системе; • SSH: SSH-сервер; • HTTP(S): имитация страницы ввода логина и пароля с авторизацией по введенной паре; • PostgreSQL: имитация СУБД на базе PostgreSQL версии 15; • MySQL: имитация СУБД на базе MySQL версии 8; • Deceptive Ports: имитация открытых TCP/UDP портов. Возможности для ловушек типа FTP: • Подключение к созданной ловушке по протоколу «FTP» с использованием параметров, указанных при создании; • Определение порта подключения; • Определение диапазона портов пассивного режима от 1024 до 65535; • Добавление текста баннера; • Разрешение анонимного входа на ловушку. Возможности для ловушек типа ОС Windows: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Windows по протоколу «RDP». Возможности для ловушек типа ОС Linux: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Linux по протоколу «SSH». Возможности для ловушек типа SMB / SMB FS: • Выбор ОС (Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows XP, Windows 2000, Windows Server 2016, Windows Server 2012, Windows Server 2008, Linux Samba); • Подключение к созданной ловушке типа «SMB» по протоколу «SMB» с использованием параметров, указанных при создании. - Возможности для ловушек типа SSH: • Подключение к созданной ловушке типа «SSH» по протоколу «SSH» с использованием параметров, указанных при создании; • Выбор ОС (Ubuntu 16.04 64bit, Ubuntu 18.04 64bit, CentOS 7 64bit, CentOS 8 64bit, Debian 9 64bit, Debian 10 64bit); • Функция случайной аутентификации на ловушке с определением диапазона количества попыток до успешной случайной аутентификации, а также количества кэшируемых комбинаций учетных данных успешной случайной аутентификации. Возможности для ловушек типа HTTP(S) и HTTP(S) v2: • Подключение к созданной ловушке типа «HTTP(S)» по протоколу HTTP(S) с использованием параметров, указанных при создании; • Определение порта подключения; • Выбор шаблона страницы; • Выбор следующего типа сервера (Apache, Nginx, Microsoft-IIS, Cloudflare, SmartXFilter, Apache-Coyote, AkamiGHost) – только для HTTP(S); • Использование сертификатов для режима HTTPS. Возможности для ловушек типа PostgreSQL: • Подключение к созданной ловушке типа PostgreSQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа MySQL: • Подключение к созданной ловушке типа MySQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа DeceptivePorts: • Подключение к созданной ловушке типа DeceptivePorts; • Определение портов TCP/UDP для подключения. Возможности работы со списком ловушек: • Сортировка списка по названию, датам создания и обновления; • Фильтрация списка по статусу ловушки; • Групповая модификация статусов ловушек; • Групповое удаление ловушек. - • Связанные хосты: список хостов, на которых размещена приманка с функционалом сквозного поиска и фильтрацией по типу ОС. Возможность размещения приманок встроенными средствами Системы как одной, так и группы приманок. Возможность размещения как всех выбранных приманок, так и случайный набор из выбранных. При размещении приманок случайным образом система должна размещать от 70 до 90 % случайно выбранных приманок, подходящих для хоста. Автоматическое формирование отчета по факту размещения с возможностью загрузки в Систему для учета размещенных в инфраструктуре приманок. Отображение статуса ловушек в интерфейсе системы: включена, выключена, обслуживание, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Учет узлов сети - перечня устройств, на которых размещены приманки с возможностью поиска и фильтрации по типам ОС устройств. Требования к функциям создания и управления ложными учетными записями Возможность создания специально подготовленных ложных учетных записей в Active Directory. Возможность задавать параметры для создания ложных учетных записей, включая выбор домена, OU, возможность задать процент ложных учетных записей от общего количества или количество таких записей, возможность задать эталонную УЗ, в соответствии с которой будут формироваться ложные УЗ. Возможность размещения ложных учетных записей в доменах организации. Учет всех ложных УЗ в едином окне с отображением общего количества записей. Возможности работы со списком ложных УЗ: • Сортировка списка по названию, статусу, OU, дате создания; • Фильтрация списка по статусу, OU, датам создания и размещения; • Групповое редактирование ложных УЗ; • Групповое удаление ложных УЗ. Экспорт созданных записей в виде списка для загрузки в SIEM с целью контроля созданных учетных записей. Требования к учету событий Учет событий, связанных с регистрацией действий на ловушке с отображением общего количества событий. - Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. - - Товарный знак - R-Vision -

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

Способ предоставления - Экземпляр на материальном носителе -

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

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

Назначение - Программное обеспечения платформы для управления объектами ложной инфраструктуры -

Функционал - Возможность автоматической генерации наполнения ловушек: • для логинов - в соответствии со словарями значений ФИО по заданному паттерну, а также с возможностью использования нескольких словарей с определением процентного соотношения использования. Словари славянских, тюркских и кавказских имен должны быть загружены в систему, а также должна поддерживаться возможность добавления собственных словарей; • для паролей - в соответствии с базой популярных паролей или в соответствии с заданными вручную критериями генерации; • для имен серверов - в соответствии со словарем (встроенным или пользовательским); • для FTP баннеров - в соответствии со словарем (встроенным или пользовательским). Наличие карточки ловушки, отображение в карточке следующей информации: • Информация о ловушке: название, статус, тип, IP-адрес, сеть, сервер управления ловушками, даты создания и обновления, технические параметры, список УЗ. • Связанные приманки: список приманок с указанием типа, статуса, связанных хостов, конфигурации, а также с возможностью фильтрации приманок по типу и сортировки списка по названию и дате создания; • События: список событий взаимодействия с ловушкой в виде таймлайна с возможностью фильтрации по периоду и критичности события. Возможность изменения статуса ловушек из интерфейса системы: включение или выключение, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Возможность учета сетей, в которых могут быть размещены ловушки. Использование динамических или статических диапазонов адресных пространств. Учет количества активных ловушек в сети, а также количества свободных IP адресов для размещения ловушек. Возможность просмотра карточки сети с отображением более подробной информации, в том числе диапазона доступных IP адресов для ловушек. Возможность указания сетевого адреса оборудования, сетевые пакеты с которого будут игнорироваться (blackhole). -

Технические требования к платформе для управления объектами ложной инфраструктуры Право на получение обновлений ПО в течение 12 месяцев Требования по диагностированию платформы Диагностирование платформы должно выполняться посредством записей в журналы аудита информации по служебным событиям и сбоям. Записи в журналах должны содержать информацию, достаточную для установления причины неисправности. Должна поддерживаться возможность отправки журналов системы по протоколу syslog на сервер мониторинга. Платформа должна содержать встроенные средства регистрации ключевых параметров производительности, отображаемых графически и численно. Требования к защите информации от несанкционированного доступа К управлению платформой должен быть допущен строго ограниченный круг лиц. Показатели назначения: Количество ловушек – не менее 64. Количество серверов управления ловушками – 2. Требования к составу системы: Система должна представлять собой программное решение, поддерживающее развертывание как на физическом оборудовании, так и на виртуальном оборудовании. Требования к функциям создания и управления ловушками Возможность создания ловушек вручную через интерфейс Системы. Возможность автоматического создания заданного количества ловушек любых типов на выбранном сервере управления через интерфейс Системы. Возможность задать график размещения ловушек для равномерного создания объектов в рабочее время указанного временного интервала. Возможность размещения ловушек на любом подключённом сервере управления ловушками и в любой сети, подключенной к выбранному серверу (за исключением сети управления Системой). Каждая из создаваемых ловушек должна однозначно определяться по уникальным IP-адресу и физическому сетевому (MAC) адресу в рамках одного сервера ловушек. Система должна позволять задавать префикс MAC-адреса при создании ловушки. Создаваемые ловушки должны имитировать сервисы в инфраструктуре заказчика с разными уровнями интерактивности.

Требования к функциям управления приманками: Возможность создания приманок вручную для выбранных ловушек через интерфейс Системы. Возможность автоматического создания заданного количества приманок выбранных типов для созданных ловушек через интерфейс Системы. Учет всех приманок в едином окне Системы с отображением общего количества приманок в системе. Наличие возможности создания приманок следующих типов: • HOSTS; • PuTTY-реестр; • PuTTY-ярлык; • WinSCP-реестр; • WinSCP-ярлык; • FileZilla; • Windows Remote Desktop – реестр; • Credential Manager-windows; • Credential Manager-generic; • Browser saved credentials; • Текстовый файл; • Windows Remote Desktop - файл сессии; • SMB диск-ярлык; • SMB диск; • История команд терминала. Возможность выбора операционной системы, для которой создается приманка: • Windows (для приманок типа HOSTS, PuTTY-реестр, PuTTY-ярлык, WinSCP-реестр, WinSCP-ярлык, FileZilla, Windows Remote Desktop, Credential Manager, Browser saved credentials, Текстовый файл, Windows Remote Desktop - файл сессии, SMB диск-ярлык, SMB диск-ярлык); • Linux (для приманок типа HOSTS, История команд терминала); • MacOS (для приманок типа HOSTS). Возможность выбора типа ловушки для которой создается приманка. Наличие функции размещения приманок на узлах сети, работающих на операционных системах Windows, Linux, MacOS. Поддержка распространения приманок через агенты конечных устройств. Возможность проверки установленного на АРМ ПО для автоматического выбора устанавливаемой приманки. Возможности работы со списком приманок: • Сортировка списка по названию, дате создания; • Фильтрация списка по типу приманки; • Групповое удаление приманок из системы; • Групповое удаление приманок с хостов. Наличие карточки приманки, отображение в карточке следующей информации: • Информация о приманке: название, статус, тип, даты создания и обновления, связанные хосты и связанные ловушки, а также конфигурация приманки.

Возможности работы со списком событий: • Наличие функции поиска по событиям; • Наличие фильтров по дате события, критичности события, типу ловушки. Возможность просмотра событий по конкретной ловушке в виде таймлайна в разделе «События». Возможность добавлять комментарии к событиям. Возможность экспорта в формат CSV как всех событий, так и отфильтрованного списка событий. Возможность добавления источников событий в исключения. Требования к функциям визуализации Наличие панели визуализации с автоматическим обновлением данных по каждому виджету: • Наличие виджета, отображающего количество событий за сутки в Системе; • Наличие виджета, отображающего количество ловушек в Системе; • Наличие виджета, отображающего время (в секундах, минутах, часах, днях, неделях, месяцах) без происшествий в Системе; • Наличие виджета, отображающего процентное отношение событий по типу ловушки; • Наличие виджета, отображающего процентное отношение событий по критичности событий; • Наличие виджета, отображающего Топ-5 целей (ловушек) с указанием IP-адреса ловушки и количеством событий; • Наличие виджета, отображающего график с количеством событий за последние 24 часа; • Наличие виджета, отображающего последние 5 событий.

Учет всех ловушек в едином окне с отображением общего количества ловушек в Системе. Возможность настройки правил исключения для доверенных систем (сканер безопасности и др.). Наличие возможности создания ловушек следующих типов с указанием учетных данных (логин и пароль) для аутентификации: • FTP: FTP-сервер; • ОС Windows: Имитация рабочего места пользователя/сервера с возможностью подключения по паре логин/пароль через rdp-соединение; • ОС Linux: Имитация Linux Debian или CentOS; • SMB / SMB FS: SMB-сервер или доступ к его файловой системе; • SSH: SSH-сервер; • HTTP(S): имитация страницы ввода логина и пароля с авторизацией по введенной паре; • PostgreSQL: имитация СУБД на базе PostgreSQL версии 15; • MySQL: имитация СУБД на базе MySQL версии 8; • Deceptive Ports: имитация открытых TCP/UDP портов. Возможности для ловушек типа FTP: • Подключение к созданной ловушке по протоколу «FTP» с использованием параметров, указанных при создании; • Определение порта подключения; • Определение диапазона портов пассивного режима от 1024 до 65535; • Добавление текста баннера; • Разрешение анонимного входа на ловушку. Возможности для ловушек типа ОС Windows: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Windows по протоколу «RDP». Возможности для ловушек типа ОС Linux: • Выбор образа системы, а также определение технических характеристик объекта (ОС, размер ОЗУ, количество ядер); • Подключение к созданной ловушке типа ОС Linux по протоколу «SSH». Возможности для ловушек типа SMB / SMB FS: • Выбор ОС (Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows XP, Windows 2000, Windows Server 2016, Windows Server 2012, Windows Server 2008, Linux Samba); • Подключение к созданной ловушке типа «SMB» по протоколу «SMB» с использованием параметров, указанных при создании.

Возможности для ловушек типа SSH: • Подключение к созданной ловушке типа «SSH» по протоколу «SSH» с использованием параметров, указанных при создании; • Выбор ОС (Ubuntu 16.04 64bit, Ubuntu 18.04 64bit, CentOS 7 64bit, CentOS 8 64bit, Debian 9 64bit, Debian 10 64bit); • Функция случайной аутентификации на ловушке с определением диапазона количества попыток до успешной случайной аутентификации, а также количества кэшируемых комбинаций учетных данных успешной случайной аутентификации. Возможности для ловушек типа HTTP(S) и HTTP(S) v2: • Подключение к созданной ловушке типа «HTTP(S)» по протоколу HTTP(S) с использованием параметров, указанных при создании; • Определение порта подключения; • Выбор шаблона страницы; • Выбор следующего типа сервера (Apache, Nginx, Microsoft-IIS, Cloudflare, SmartXFilter, Apache-Coyote, AkamiGHost) – только для HTTP(S); • Использование сертификатов для режима HTTPS. Возможности для ловушек типа PostgreSQL: • Подключение к созданной ловушке типа PostgreSQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа MySQL: • Подключение к созданной ловушке типа MySQL; • Определение порта подключения; • Генерация логина и пароля в ручном и автоматическом режиме. Возможности для ловушек типа DeceptivePorts: • Подключение к созданной ловушке типа DeceptivePorts; • Определение портов TCP/UDP для подключения. Возможности работы со списком ловушек: • Сортировка списка по названию, датам создания и обновления; • Фильтрация списка по статусу ловушки; • Групповая модификация статусов ловушек; • Групповое удаление ловушек.

• Связанные хосты: список хостов, на которых размещена приманка с функционалом сквозного поиска и фильтрацией по типу ОС. Возможность размещения приманок встроенными средствами Системы как одной, так и группы приманок. Возможность размещения как всех выбранных приманок, так и случайный набор из выбранных. При размещении приманок случайным образом система должна размещать от 70 до 90 % случайно выбранных приманок, подходящих для хоста. Автоматическое формирование отчета по факту размещения с возможностью загрузки в Систему для учета размещенных в инфраструктуре приманок. Отображение статуса ловушек в интерфейсе системы: включена, выключена, обслуживание, а также отображение значка загрузки при смене статуса. Отображение статуса "ошибка" при невозможности получить статус от сервера управления ловушками. Учет узлов сети - перечня устройств, на которых размещены приманки с возможностью поиска и фильтрации по типам ОС устройств. Требования к функциям создания и управления ложными учетными записями Возможность создания специально подготовленных ложных учетных записей в Active Directory. Возможность задавать параметры для создания ложных учетных записей, включая выбор домена, OU, возможность задать процент ложных учетных записей от общего количества или количество таких записей, возможность задать эталонную УЗ, в соответствии с которой будут формироваться ложные УЗ. Возможность размещения ложных учетных записей в доменах организации. Учет всех ложных УЗ в едином окне с отображением общего количества записей. Возможности работы со списком ложных УЗ: • Сортировка списка по названию, статусу, OU, дате создания; • Фильтрация списка по статусу, OU, датам создания и размещения; • Групповое редактирование ложных УЗ; • Групповое удаление ложных УЗ. Экспорт созданных записей в виде списка для загрузки в SIEM с целью контроля созданных учетных записей. Требования к учету событий Учет событий, связанных с регистрацией действий на ловушке с отображением общего количества событий.

Комплектация - Дистрибутив ПО. Комплект документации в электронном виде по инсталляции и работе с ПО. Формуляр. -

Товарный знак - R-Vision -

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

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

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

Требования к участникам: 1. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ 2. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 3. Требования к участникам закупок в соответствии с ч. 2.1 ст. 31 Закона № 44-ФЗ 3.1? Требования в соответствии c пунктом 4 ПП РФ от 29.12.2021 №2571 Дополнительные требования Наличие у участника закупки опыта исполнения (с учетом правопреемства) в течение трех лет до даты подачи заявки на участие в закупке контракта или договора, заключенного в соответствии с Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не менее двадцати процентов начальной (максимальной) цены контракта. Информация и документы, подтверждающие соответствие участника закупки дополнительному требованию, установленному в соответствии с частью 2.1 ст. 31 Закона о контрактной системе, являются информация и документы, предусмотренные хотя бы одним из следующих подпунктов: а) номер реестровой записи в предусмотренном Законом о контрактной системе реестре контрактов, заключенных заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной системы в информационно-телекоммуникационной сети "Интернет"); б) выписка из предусмотренного Законом о контрактной системе реестра контрактов, содержащего сведения, составляющие государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в установленном порядке в такой реестр); в) исполненный контракт, заключенный в соответствии с Законом о контрактной системе, или договор, заключенный в соответствии с Федеральным законом "О закупках товаров, работ, услуг отдельными видами юридических лиц", а также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену поставленных товаров, выполненных работ, оказанных услуг.

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

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

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

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

Начальная (максимальная) цена контракта: 25 726 633,00

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

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

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

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

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

Закупка за счет собственных средств организации: Да

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

Размер обеспечения заявки: 257 266,33 Российский рубль

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

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

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

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл. Новосибирская, г.о. город Новосибирск, г. Новосибирск, пр-кт Димитрова, д. 16

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

Размер обеспечения исполнения контракта: 5 145 326,60 Российский рубль (20 %)

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

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

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

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

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

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

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

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

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

Закупка за счет собственных средств организации: Да

Документы

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

Документы

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