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

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

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

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

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РТС-тендер

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

Размещение осуществляет: Заказчик ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ УЧРЕЖДЕНИЕ "МНОГОФУНКЦИОНАЛЬНЫЙ ЦЕНТР ПРЕДОСТАВЛЕНИЯ ГОСУДАРСТВЕННЫХ И МУНИЦИПАЛЬНЫХ УСЛУГ ДОНЕЦКОЙ НАРОДНОЙ РЕСПУБЛИКИ"

Наименование объекта закупки: Система мониторинга анализа и управления событий информационной безопасности, системы управления уязвимостями и контроля соответствия стандартам

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

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

Номер типовых условий контракта: 1400700000520009

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

Размещение осуществляет: Заказчик

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

Почтовый адрес: 283003, ДОНЕЦКАЯ НАРОДНАЯ РЕСПУБЛИКА, г.о. ДОНЕЦК, Г. ДОНЕЦК, ПР-КТ ИЛЬИЧА, Д. 63А

Место нахождения: 283003, ДОНЕЦКАЯ НАРОДНАЯ РЕСПУБЛИКА, г.о. ДОНЕЦК, Г. ДОНЕЦК, ПР-КТ ИЛЬИЧА, Д. 63А

Ответственное должностное лицо: Мазур И. В.

Адрес электронной почты: irina.mazur.1985@mail.ru

Номер контактного телефона: 7-949-3118152

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

Регион: Донецкая Народная Респ

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

Дата и время начала срока подачи заявок: 17.11.2025 13:12 (МСК)

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

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

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

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

Начальная (максимальная) цена контракта: 51 193 636,00

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

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

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

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

Дата начала исполнения контракта: 08.12.2025

Срок исполнения контракта: 24.12.2025

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

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

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

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Требования к компоненту хранения данных К компоненту хранения данных предъявляются следующие требования: ? Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об ИТ-активах, в том числе IP-адреса, доменные имена и другие данные. ? Должна обеспечиваться поддержка хранения данных на внешних системах хранения. ? Должно обеспечиваться хранение сведений о выявленных уязвимостях. ? Должно обеспечиваться хранение данных, используемых при проверке на уязвимости методом черного ящика. ? Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах Класс программ для электронных вычислительных машин и баз данных (03.15) Средства обнаружения угроз и расследования сетевых инцидентов Способ предоставления Экземпляр на материальном носителе - Штука - 1,00 - 9 360 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к компоненту хранения данных К компоненту хранения данных предъявляются следующие требования: ? Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об ИТ-активах, в том числе IP-адреса, доменные имена и другие данные. ? Должна обеспечиваться поддержка хранения данных на внешних системах хранения. ? Должно обеспечиваться хранение сведений о выявленных уязвимостях. ? Должно обеспечиваться хранение данных, используемых при проверке на уязвимости методом черного ящика. ? Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (03.15) Средства обнаружения угроз и расследования сетевых инцидентов Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к компоненту хранения данных - К компоненту хранения данных предъявляются следующие требования: ? Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об ИТ-активах, в том числе IP-адреса, доменные имена и другие данные. ? Должна обеспечиваться поддержка хранения данных на внешних системах хранения. ? Должно обеспечиваться хранение сведений о выявленных уязвимостях. ? Должно обеспечиваться хранение данных, используемых при проверке на уязвимости методом черного ящика. ? Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (03.15) Средства обнаружения угроз и расследования сетевых инцидентов - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Требования к компоненту хранения данных - К компоненту хранения данных предъявляются следующие требования: ? Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об ИТ-активах, в том числе IP-адреса, доменные имена и другие данные. ? Должна обеспечиваться поддержка хранения данных на внешних системах хранения. ? Должно обеспечиваться хранение сведений о выявленных уязвимостях. ? Должно обеспечиваться хранение данных, используемых при проверке на уязвимости методом черного ящика. ? Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах - - Значение характеристики не может изменяться участником закупки

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 62.02.3 62.02.30.000-00000002 - Услуги по технической поддержке информационных технологий Требования к времени реакции на заявку и времени его обработки Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 36 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - Условная единица - 1,00 - 5 689 008,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к времени реакции на заявку и времени его обработки Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 36 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к времени реакции на заявку и времени его обработки - Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 36 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - - Значение характеристики не может изменяться участником закупки

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

Требования к времени реакции на заявку и времени его обработки - Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 36 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Требования к модулю сбора данных №2 1.15. Должна обеспечиваться возможность экспорта и импорта профилей сбора данных в файл. 1.16. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла. 1.17. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об ИТ-активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименования и версии ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.18. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec PCAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP. 1.19. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.20. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.21. Должно поддерживаться подключение к выбранным ИТ-активам: 1.22. по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой Требования к модулю обработки данных №3 2.16. Должно обеспечиваться отображение оценки обнаруженных уязвимостей: • последняя добавленная; • трендовая; • на важном активе; • имеющая известный эксплойт; • доступная для удаленного использования. 2.17. Должна обеспечиваться оценка интегральной уязвимости для ИТ-актива. 2.18. Должно поддерживаться ручное управление карточками уязвимостей. 2.19. Должна обеспечиваться обработка уязвимостей на основе политик и (или) правил: • для контроля устранения уязвимостей: o определение действий по отношению к уязвимостям в результате применения правила; o определение статуса, который получает уязвимость при выполнении правила; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. • для пометки критически важных уязвимостей: o присвоение уникальной метки, по которой легко выявить помеченный актив; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. 2.20. Должен обеспечиваться контроль ключевых показателей процесса управления уязвимостями путем реализации настраиваемых политик и (или) правил, включая: • активацию и (или) деактивацию политики и (или) правила; • добавление и (или) изменение и (или) удаление политики и (или) правила. 2.21. Должны поддерживаться следующие операции над сведениями об уязвимостях: • выделение важных (критических) уязвимостей; • контроль выполнения работ по устранению уязвимостей; • градация уязвимостей, в том числе выявление трендовых уязвимостей, то есть уязвимостей, которые активно используются в атаках злоумышленников в актуальный период времени (при условии постоянных обновлений базы знаний Системы) Требования к модулю обработки данных №2 2.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значение одного из основных атрибутов ИТ-актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.10. Должно обеспечиваться ведение истории изменения карточки ИТ-актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния ИТ-актива на заданный момент времени или за указанный период; • сравнения конфигураций ИТ-актива в два различных момента времени. 2.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об ИТ-активах; • возможность проверки сетевой доступности между ИТ-активами на основе собранной Системой информации об ИТ-активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.12. Должно обеспечиваться представление сведений об уязвимостях в соответствии с таксономией стандартов CVSSv2 и CVSSv3. 2.13. Должен обеспечиваться расчет уровня критичности выявленных уязвимостей в соответствии с методическим документом ФСТЭК России от 28 октября 2022 г. «Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств». 2.14. Должна поддерживаться возможность сортировки программного обеспечения согласно алгоритму принятия решений для процесса управления обновлениями программного обеспечения, установленного Бюллетенем Национального координационного центра по компьютерным инцидентам (НКЦКИ) от 15.04.2022 г. № ALRT-20220415.1. 2.15. Должно обеспечиваться наличие ссылок на публичные базы данных, в которых описаны уязвимости того же типа, что и обнаруженные - Штука - 1,00 - 6 327 360,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к модулю сбора данных №2 1.15. Должна обеспечиваться возможность экспорта и импорта профилей сбора данных в файл. 1.16. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла. 1.17. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об ИТ-активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименования и версии ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.18. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec PCAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP. 1.19. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.20. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.21. Должно поддерживаться подключение к выбранным ИТ-активам: 1.22. по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой Требования к модулю обработки данных №3 2.16. Должно обеспечиваться отображение оценки обнаруженных уязвимостей: • последняя добавленная; • трендовая; • на важном активе; • имеющая известный эксплойт; • доступная для удаленного использования. 2.17. Должна обеспечиваться оценка интегральной уязвимости для ИТ-актива. 2.18. Должно поддерживаться ручное управление карточками уязвимостей. 2.19. Должна обеспечиваться обработка уязвимостей на основе политик и (или) правил: • для контроля устранения уязвимостей: o определение действий по отношению к уязвимостям в результате применения правила; o определение статуса, который получает уязвимость при выполнении правила; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. • для пометки критически важных уязвимостей: o присвоение уникальной метки, по которой легко выявить помеченный актив; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. 2.20. Должен обеспечиваться контроль ключевых показателей процесса управления уязвимостями путем реализации настраиваемых политик и (или) правил, включая: • активацию и (или) деактивацию политики и (или) правила; • добавление и (или) изменение и (или) удаление политики и (или) правила. 2.21. Должны поддерживаться следующие операции над сведениями об уязвимостях: • выделение важных (критических) уязвимостей; • контроль выполнения работ по устранению уязвимостей; • градация уязвимостей, в том числе выявление трендовых уязвимостей, то есть уязвимостей, которые активно используются в атаках злоумышленников в актуальный период времени (при условии постоянных обновлений базы знаний Системы) Требования к модулю обработки данных №2 2.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значение одного из основных атрибутов ИТ-актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.10. Должно обеспечиваться ведение истории изменения карточки ИТ-актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния ИТ-актива на заданный момент времени или за указанный период; • сравнения конфигураций ИТ-актива в два различных момента времени. 2.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об ИТ-активах; • возможность проверки сетевой доступности между ИТ-активами на основе собранной Системой информации об ИТ-активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.12. Должно обеспечиваться представление сведений об уязвимостях в соответствии с таксономией стандартов CVSSv2 и CVSSv3. 2.13. Должен обеспечиваться расчет уровня критичности выявленных уязвимостей в соответствии с методическим документом ФСТЭК России от 28 октября 2022 г. «Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств». 2.14. Должна поддерживаться возможность сортировки программного обеспечения согласно алгоритму принятия решений для процесса управления обновлениями программного обеспечения, установленного Бюллетенем Национального координационного центра по компьютерным инцидентам (НКЦКИ) от 15.04.2022 г. № ALRT-20220415.1. 2.15. Должно обеспечиваться наличие ссылок на публичные базы данных, в которых описаны уязвимости того же типа, что и обнаруженные Количество Активов Требования к Активам Должно поддерживаться не менее 1000 ИТ-активов Значение характеристики не может изменяться участником закупки Требования к модулю сбора данных №1 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных (однократно и по расписанию). 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач на сбор данных. 1.5. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач на сбор данных. 1.6. Должна поддерживаться настройка запрещенного времени для выполнения задач на сбор данных: на указанный интервал времени выполнение задачи должно прерываться. 1.7. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.8. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.9. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи на сбор данных. 1.10. Должна поддерживаться возможность сортировки и поиска задач на сбор данных по их атрибутам. 1.11. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.12. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач на сбор данных. 1.13. Должна поддерживаться возможность поиска профилей сбора данных. 1.14. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных Значение характеристики не может изменяться участником закупки Требования к модулю обработки данных №4 2.22. Должны поддерживаться операции управления обработкой уязвимостей: • поиск и сортировка уязвимостей по их атрибутам; • создание и (или) удаление информации (меток) к уязвимостям; • демонстрация карточек уязвимостей, содержащих справочную информацию в развернутом виде; • изменение статуса уязвимости; • контроль устранения уязвимостей; • проведение массовых операций над уязвимостями. 2.23. Должен поддерживаться поиск по активам и уязвимостям с применением технологии искусственного интеллекта на русском и английском языках. 2.24. Должно обеспечиваться ведение истории изменения уязвимостей с привязкой к конкретному активу, с отображением: • наличия уязвимости; • статуса уязвимости на заданный момент времени Требования к модулю сбора данных №3 1.23. Должен поддерживаться выбор способов (протоколов) подключения к ИТ-активам и определения учетных записей, используемых для аутентификации. 1.24. Должен поддерживаться механизм проверки доступности ИТ-активов для выполнения задач на сбор данных, в том числе должна проверяться учетная запись, используемая при проверке. 1.25. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования ИТ-активов: • идентификационных данных об ИТ-активах (IP-адрес, FQDN и другие); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.26. Должно осуществляться сканирование узлов инфраструктуры (активов) методами белого и черного ящика. 1.27. Должно обеспечиваться автоматическое выявление уязвимостей в соответствии с экспертной базой знаний на ИТ-активах с наличием информации достаточной для расчета уязвимостей. 1.28. Должно обеспечиваться выявление уязвимостей в пакетах программ, вложенных в контейнеры, основанные на ОС семейства Linux, в том числе: • Debian; • Ubuntu. 1.29. Модулями сбора данных, размещенными на технических средствах под управлением ОС семейства Linux, должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач поиска уязвимостей в веб приложениях. 1.30. Должно обеспечиваться отображение сведений об уязвимостях в виде карточки уязвимости, связанной с карточкой ИТ-актива. 1.31. Должно указываться время последнего сканирования ИТ-актива на наличие уязвимостей Требования к модулю обработки данных №1 2.1. Должно обеспечиваться управление списком ИТ-активов, включая: • поиск ИТ-активов по их атрибутам; • группировку ИТ-активов: o в статические группы, членство ИТ-актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об ИТ-активе (IP-адреса, ОС, прочие характеристики). • построение иерархии групп ИТ-активов; • поиск групп ИТ-активов по названию. 2.2. Должен обеспечиваться контроль ключевых показателей процесса управления ИТ-активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики и (или) правила; • добавление, изменение или удаление политики и (или) правила. 2.3. Должны реализовываться следующие политики и (или) правила: • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, в отношении которых действует политика и (или) правило; • присвоение значимости ИТ-активам. 2.4. Должно обеспечиваться выполнение над ИТ-активом действий, описанных в политике и (или) правиле, при активации политики и (или) правила. 2.5. Должно обеспечиваться возвращение состояния ИТ-актива в исходное при деактивации политики и (или) правила. 2.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки ИТ-актива. 2.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об ИТ-активах в результате выполнения задач на сбор данных. 2.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания ИТ-актива) или удаление карточки ИТ-актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости ИТ-актива; • задание статусов (сроков) актуальности данных Класс программ для электронных вычислительных машин и баз данных (03.15) Средства обнаружения угроз и расследования сетевых инцидентов Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к модулю сбора данных №2 - 1.15. Должна обеспечиваться возможность экспорта и импорта профилей сбора данных в файл. 1.16. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла. 1.17. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об ИТ-активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименования и версии ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.18. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec PCAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP. 1.19. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.20. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.21. Должно поддерживаться подключение к выбранным ИТ-активам: 1.22. по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой - - - Требования к модулю обработки данных №3 - 2.16. Должно обеспечиваться отображение оценки обнаруженных уязвимостей: • последняя добавленная; • трендовая; • на важном активе; • имеющая известный эксплойт; • доступная для удаленного использования. 2.17. Должна обеспечиваться оценка интегральной уязвимости для ИТ-актива. 2.18. Должно поддерживаться ручное управление карточками уязвимостей. 2.19. Должна обеспечиваться обработка уязвимостей на основе политик и (или) правил: • для контроля устранения уязвимостей: o определение действий по отношению к уязвимостям в результате применения правила; o определение статуса, который получает уязвимость при выполнении правила; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. • для пометки критически важных уязвимостей: o присвоение уникальной метки, по которой легко выявить помеченный актив; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. 2.20. Должен обеспечиваться контроль ключевых показателей процесса управления уязвимостями путем реализации настраиваемых политик и (или) правил, включая: • активацию и (или) деактивацию политики и (или) правила; • добавление и (или) изменение и (или) удаление политики и (или) правила. 2.21. Должны поддерживаться следующие операции над сведениями об уязвимостях: • выделение важных (критических) уязвимостей; • контроль выполнения работ по устранению уязвимостей; • градация уязвимостей, в том числе выявление трендовых уязвимостей, то есть уязвимостей, которые активно используются в атаках злоумышленников в актуальный период времени (при условии постоянных обновлений базы знаний Системы) - - - Требования к модулю обработки данных №2 - 2.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значение одного из основных атрибутов ИТ-актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.10. Должно обеспечиваться ведение истории изменения карточки ИТ-актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния ИТ-актива на заданный момент времени или за указанный период; • сравнения конфигураций ИТ-актива в два различных момента времени. 2.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об ИТ-активах; • возможность проверки сетевой доступности между ИТ-активами на основе собранной Системой информации об ИТ-активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.12. Должно обеспечиваться представление сведений об уязвимостях в соответствии с таксономией стандартов CVSSv2 и CVSSv3. 2.13. Должен обеспечиваться расчет уровня критичности выявленных уязвимостей в соответствии с методическим документом ФСТЭК России от 28 октября 2022 г. «Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств». 2.14. Должна поддерживаться возможность сортировки программного обеспечения согласно алгоритму принятия решений для процесса управления обновлениями программного обеспечения, установленного Бюллетенем Национального координационного центра по компьютерным инцидентам (НКЦКИ) от 15.04.2022 г. № ALRT-20220415.1. 2.15. Должно обеспечиваться наличие ссылок на публичные базы данных, в которых описаны уязвимости того же типа, что и обнаруженные - - - Количество Активов Требования к Активам - Должно поддерживаться не менее 1000 ИТ-активов - - Значение характеристики не может изменяться участником закупки - Требования к модулю сбора данных №1 - 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных (однократно и по расписанию). 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач на сбор данных. 1.5. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач на сбор данных. 1.6. Должна поддерживаться настройка запрещенного времени для выполнения задач на сбор данных: на указанный интервал времени выполнение задачи должно прерываться. 1.7. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.8. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.9. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи на сбор данных. 1.10. Должна поддерживаться возможность сортировки и поиска задач на сбор данных по их атрибутам. 1.11. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.12. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач на сбор данных. 1.13. Должна поддерживаться возможность поиска профилей сбора данных. 1.14. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных - - Значение характеристики не может изменяться участником закупки - Требования к модулю обработки данных №4 - 2.22. Должны поддерживаться операции управления обработкой уязвимостей: • поиск и сортировка уязвимостей по их атрибутам; • создание и (или) удаление информации (меток) к уязвимостям; • демонстрация карточек уязвимостей, содержащих справочную информацию в развернутом виде; • изменение статуса уязвимости; • контроль устранения уязвимостей; • проведение массовых операций над уязвимостями. 2.23. Должен поддерживаться поиск по активам и уязвимостям с применением технологии искусственного интеллекта на русском и английском языках. 2.24. Должно обеспечиваться ведение истории изменения уязвимостей с привязкой к конкретному активу, с отображением: • наличия уязвимости; • статуса уязвимости на заданный момент времени - - - Требования к модулю сбора данных №3 - 1.23. Должен поддерживаться выбор способов (протоколов) подключения к ИТ-активам и определения учетных записей, используемых для аутентификации. 1.24. Должен поддерживаться механизм проверки доступности ИТ-активов для выполнения задач на сбор данных, в том числе должна проверяться учетная запись, используемая при проверке. 1.25. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования ИТ-активов: • идентификационных данных об ИТ-активах (IP-адрес, FQDN и другие); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.26. Должно осуществляться сканирование узлов инфраструктуры (активов) методами белого и черного ящика. 1.27. Должно обеспечиваться автоматическое выявление уязвимостей в соответствии с экспертной базой знаний на ИТ-активах с наличием информации достаточной для расчета уязвимостей. 1.28. Должно обеспечиваться выявление уязвимостей в пакетах программ, вложенных в контейнеры, основанные на ОС семейства Linux, в том числе: • Debian; • Ubuntu. 1.29. Модулями сбора данных, размещенными на технических средствах под управлением ОС семейства Linux, должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач поиска уязвимостей в веб приложениях. 1.30. Должно обеспечиваться отображение сведений об уязвимостях в виде карточки уязвимости, связанной с карточкой ИТ-актива. 1.31. Должно указываться время последнего сканирования ИТ-актива на наличие уязвимостей - - - Требования к модулю обработки данных №1 - 2.1. Должно обеспечиваться управление списком ИТ-активов, включая: • поиск ИТ-активов по их атрибутам; • группировку ИТ-активов: o в статические группы, членство ИТ-актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об ИТ-активе (IP-адреса, ОС, прочие характеристики). • построение иерархии групп ИТ-активов; • поиск групп ИТ-активов по названию. 2.2. Должен обеспечиваться контроль ключевых показателей процесса управления ИТ-активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики и (или) правила; • добавление, изменение или удаление политики и (или) правила. 2.3. Должны реализовываться следующие политики и (или) правила: • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, в отношении которых действует политика и (или) правило; • присвоение значимости ИТ-активам. 2.4. Должно обеспечиваться выполнение над ИТ-активом действий, описанных в политике и (или) правиле, при активации политики и (или) правила. 2.5. Должно обеспечиваться возвращение состояния ИТ-актива в исходное при деактивации политики и (или) правила. 2.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки ИТ-актива. 2.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об ИТ-активах в результате выполнения задач на сбор данных. 2.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания ИТ-актива) или удаление карточки ИТ-актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости ИТ-актива; • задание статусов (сроков) актуальности данных - - - Класс программ для электронных вычислительных машин и баз данных - (03.15) Средства обнаружения угроз и расследования сетевых инцидентов - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Требования к модулю сбора данных №2 - 1.15. Должна обеспечиваться возможность экспорта и импорта профилей сбора данных в файл. 1.16. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла. 1.17. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об ИТ-активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименования и версии ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.18. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec PCAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP. 1.19. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.20. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.21. Должно поддерживаться подключение к выбранным ИТ-активам: 1.22. по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой - -

Требования к модулю обработки данных №3 - 2.16. Должно обеспечиваться отображение оценки обнаруженных уязвимостей: • последняя добавленная; • трендовая; • на важном активе; • имеющая известный эксплойт; • доступная для удаленного использования. 2.17. Должна обеспечиваться оценка интегральной уязвимости для ИТ-актива. 2.18. Должно поддерживаться ручное управление карточками уязвимостей. 2.19. Должна обеспечиваться обработка уязвимостей на основе политик и (или) правил: • для контроля устранения уязвимостей: o определение действий по отношению к уязвимостям в результате применения правила; o определение статуса, который получает уязвимость при выполнении правила; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. • для пометки критически важных уязвимостей: o присвоение уникальной метки, по которой легко выявить помеченный актив; o определение перечня уязвимостей, в отношении которых действует правило; o определение перечня активов, в отношении которых действует правило. 2.20. Должен обеспечиваться контроль ключевых показателей процесса управления уязвимостями путем реализации настраиваемых политик и (или) правил, включая: • активацию и (или) деактивацию политики и (или) правила; • добавление и (или) изменение и (или) удаление политики и (или) правила. 2.21. Должны поддерживаться следующие операции над сведениями об уязвимостях: • выделение важных (критических) уязвимостей; • контроль выполнения работ по устранению уязвимостей; • градация уязвимостей, в том числе выявление трендовых уязвимостей, то есть уязвимостей, которые активно используются в атаках злоумышленников в актуальный период времени (при условии постоянных обновлений базы знаний Системы) - -

Требования к модулю обработки данных №2 - 2.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значение одного из основных атрибутов ИТ-актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.10. Должно обеспечиваться ведение истории изменения карточки ИТ-актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния ИТ-актива на заданный момент времени или за указанный период; • сравнения конфигураций ИТ-актива в два различных момента времени. 2.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об ИТ-активах; • возможность проверки сетевой доступности между ИТ-активами на основе собранной Системой информации об ИТ-активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 2.12. Должно обеспечиваться представление сведений об уязвимостях в соответствии с таксономией стандартов CVSSv2 и CVSSv3. 2.13. Должен обеспечиваться расчет уровня критичности выявленных уязвимостей в соответствии с методическим документом ФСТЭК России от 28 октября 2022 г. «Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств». 2.14. Должна поддерживаться возможность сортировки программного обеспечения согласно алгоритму принятия решений для процесса управления обновлениями программного обеспечения, установленного Бюллетенем Национального координационного центра по компьютерным инцидентам (НКЦКИ) от 15.04.2022 г. № ALRT-20220415.1. 2.15. Должно обеспечиваться наличие ссылок на публичные базы данных, в которых описаны уязвимости того же типа, что и обнаруженные - -

Количество Активов Требования к Активам - Должно поддерживаться не менее 1000 ИТ-активов - - Значение характеристики не может изменяться участником закупки

Требования к модулю сбора данных №1 - 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных (однократно и по расписанию). 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач на сбор данных. 1.5. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач на сбор данных. 1.6. Должна поддерживаться настройка запрещенного времени для выполнения задач на сбор данных: на указанный интервал времени выполнение задачи должно прерываться. 1.7. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.8. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.9. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи на сбор данных. 1.10. Должна поддерживаться возможность сортировки и поиска задач на сбор данных по их атрибутам. 1.11. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.12. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач на сбор данных. 1.13. Должна поддерживаться возможность поиска профилей сбора данных. 1.14. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных - - Значение характеристики не может изменяться участником закупки

Требования к модулю обработки данных №4 - 2.22. Должны поддерживаться операции управления обработкой уязвимостей: • поиск и сортировка уязвимостей по их атрибутам; • создание и (или) удаление информации (меток) к уязвимостям; • демонстрация карточек уязвимостей, содержащих справочную информацию в развернутом виде; • изменение статуса уязвимости; • контроль устранения уязвимостей; • проведение массовых операций над уязвимостями. 2.23. Должен поддерживаться поиск по активам и уязвимостям с применением технологии искусственного интеллекта на русском и английском языках. 2.24. Должно обеспечиваться ведение истории изменения уязвимостей с привязкой к конкретному активу, с отображением: • наличия уязвимости; • статуса уязвимости на заданный момент времени - -

Требования к модулю сбора данных №3 - 1.23. Должен поддерживаться выбор способов (протоколов) подключения к ИТ-активам и определения учетных записей, используемых для аутентификации. 1.24. Должен поддерживаться механизм проверки доступности ИТ-активов для выполнения задач на сбор данных, в том числе должна проверяться учетная запись, используемая при проверке. 1.25. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования ИТ-активов: • идентификационных данных об ИТ-активах (IP-адрес, FQDN и другие); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.26. Должно осуществляться сканирование узлов инфраструктуры (активов) методами белого и черного ящика. 1.27. Должно обеспечиваться автоматическое выявление уязвимостей в соответствии с экспертной базой знаний на ИТ-активах с наличием информации достаточной для расчета уязвимостей. 1.28. Должно обеспечиваться выявление уязвимостей в пакетах программ, вложенных в контейнеры, основанные на ОС семейства Linux, в том числе: • Debian; • Ubuntu. 1.29. Модулями сбора данных, размещенными на технических средствах под управлением ОС семейства Linux, должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач поиска уязвимостей в веб приложениях. 1.30. Должно обеспечиваться отображение сведений об уязвимостях в виде карточки уязвимости, связанной с карточкой ИТ-актива. 1.31. Должно указываться время последнего сканирования ИТ-актива на наличие уязвимостей - -

Требования к модулю обработки данных №1 - 2.1. Должно обеспечиваться управление списком ИТ-активов, включая: • поиск ИТ-активов по их атрибутам; • группировку ИТ-активов: o в статические группы, членство ИТ-актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об ИТ-активе (IP-адреса, ОС, прочие характеристики). • построение иерархии групп ИТ-активов; • поиск групп ИТ-активов по названию. 2.2. Должен обеспечиваться контроль ключевых показателей процесса управления ИТ-активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики и (или) правила; • добавление, изменение или удаление политики и (или) правила. 2.3. Должны реализовываться следующие политики и (или) правила: • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, в отношении которых действует политика и (или) правило; • присвоение значимости ИТ-активам. 2.4. Должно обеспечиваться выполнение над ИТ-активом действий, описанных в политике и (или) правиле, при активации политики и (или) правила. 2.5. Должно обеспечиваться возвращение состояния ИТ-актива в исходное при деактивации политики и (или) правила. 2.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки ИТ-актива. 2.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об ИТ-активах в результате выполнения задач на сбор данных. 2.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания ИТ-актива) или удаление карточки ИТ-актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости ИТ-актива; • задание статусов (сроков) актуальности данных - -

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 62.02.3 62.02.30.000-00000002 - Услуги по технической поддержке информационных технологий Требования к времени реакции на заявку и времени его обработки Наличие. Требования к времени реакции на заявку и времени его обработки: Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 12 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - Условная единица - 1,00 - 4 048 668,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к времени реакции на заявку и времени его обработки Наличие. Требования к времени реакции на заявку и времени его обработки: Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 12 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к времени реакции на заявку и времени его обработки - Наличие. Требования к времени реакции на заявку и времени его обработки: Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 12 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - - Значение характеристики не может изменяться участником закупки

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

Требования к времени реакции на заявку и времени его обработки - Наличие. Требования к времени реакции на заявку и времени его обработки: Критический (Аварийные сбои, приводящие к невозможности штатной работы продукта (исключая первоначальную установку) либо оказывающие критически значимое влияние на бизнес заказчика) - Время реакции на заявку - до 4 часов Высокий (Сбои, проявляющиеся в любых условиях эксплуатации продукта и оказывающие значительное влияние на бизнес заказчика) - Время реакции на заявку - до 8 часов Средний (Сбои, проявляющиеся в специфических условиях эксплуатации продукта либо не оказывающие значительного влияния на бизнес заказчика) Время реакции на заявку - до 8 часов Низкий (Вопросы информационного характера либо сбои, не влияющие на эксплуатацию продукта) Время реакции на заявку - до 8 часов Указанные часы относятся к рабочему времени (рабочие дни с 9:00 до 18:00 UTC+3) специалистов технической поддержки. Под рабочим днем понимается любой день за исключением субботы, воскресенья и дней, являющихся официальными нерабочими днями в Российской Федерации Техническая поддержка на программное обеспечение оказывается дистанционно, доступна в течение срока действия сертификата, распространяется на заявки, связанные с работой программного обеспечения Срок действия сертификата на техническую поддержку – 12 месяцев. Бумажный носитель, включающий в себя наименование программного продукта и срок действия договора на техническую поддержку - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Требования к архитектуре Системы №3 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СУУ должна иметь указанные режимы функционирования: • - штатный — режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • - технологический — режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модернизации Системы; • - аварийный — режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных компонентов или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки технических средств (далее также — ТС) и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим. 1.7. Требования к возможностям развития и модификации Системы К возможностям развития и модификации Системы предъявляются следующие требования: 1.7.1. Система должна быть построена по модульному принципу, обеспечивающему гибкий процесс масштабирования. 1.7.2. Должна поддерживаться возможность горизонтального масштабирования Системы для обработки больших объемов данных на территориально распределенных площадках. 1.7.3. При проектировании СУУ должна быть учтены возможности ее модификации в целях: • - увеличения количества ИТ-активов в ИТ-инфраструктуре; • - обработки больших объемов данных. 1.7.4. При проектировании Системы должна учитываться возможность повышения производительности Системы за счет увеличения количества компонентов Системы и производительности аппаратных или виртуализованных платформ Требования к функциям (задачам), выполняемым Системой №4 2.3.18. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле); • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до разблокирования учетной записи и сброса количества попыток ввода пароля. 2.3.19. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.20. Должно обеспечиваться журналирование действий пользователей: • с ИТ-активами в интерфейсе Системы; • в части управления сбором данных; • в части управления контентом базы знаний; • в части управления Системой; • во всех случаях авторизации пользователей. 2.3.21. Должен поддерживаться выпуск токенов для авторизации действий пользователей в отношении публичных API. 2.3.22. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач на сбор данных, состояния Системы) с их отправкой на электронную почту или по POST-запросу Требования к функциям (задачам), выполняемым Системой №3 2.3.11. Должно обеспечиваться наличие предустановленных виджетов по ИТ активам, отображающим: • количество активов; • значимость активов; • актуальность данных об ИТ-активах. 2.3.12. Должно обеспечиваться наличие предустановленного виджета с изменениями статусов по уязвимостям повышенного уровня опасности (критический и высокий), произошедшими в течение семи дней. 2.3.13. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). 2.3.14. Должна поддерживаться возможность: • выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • экспорта отчетов в один из следующих форматов: JSON, PDF, CSV, XML, XLSX. 2.3.15. Должно обеспечиваться наличие активных ссылок на внешние источники сведений об уязвимостях при экспорте отчетов в формате XLSX. 2.3.16. Должна поддерживаться возможность генерации паролей пользователей Системы. 2.3.17. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему - Штука - 1,00 - 3 276 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к архитектуре Системы №3 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СУУ должна иметь указанные режимы функционирования: • - штатный — режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • - технологический — режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модернизации Системы; • - аварийный — режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных компонентов или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки технических средств (далее также — ТС) и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим. 1.7. Требования к возможностям развития и модификации Системы К возможностям развития и модификации Системы предъявляются следующие требования: 1.7.1. Система должна быть построена по модульному принципу, обеспечивающему гибкий процесс масштабирования. 1.7.2. Должна поддерживаться возможность горизонтального масштабирования Системы для обработки больших объемов данных на территориально распределенных площадках. 1.7.3. При проектировании СУУ должна быть учтены возможности ее модификации в целях: • - увеличения количества ИТ-активов в ИТ-инфраструктуре; • - обработки больших объемов данных. 1.7.4. При проектировании Системы должна учитываться возможность повышения производительности Системы за счет увеличения количества компонентов Системы и производительности аппаратных или виртуализованных платформ Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №4 2.3.18. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле); • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до разблокирования учетной записи и сброса количества попыток ввода пароля. 2.3.19. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.20. Должно обеспечиваться журналирование действий пользователей: • с ИТ-активами в интерфейсе Системы; • в части управления сбором данных; • в части управления контентом базы знаний; • в части управления Системой; • во всех случаях авторизации пользователей. 2.3.21. Должен поддерживаться выпуск токенов для авторизации действий пользователей в отношении публичных API. 2.3.22. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач на сбор данных, состояния Системы) с их отправкой на электронную почту или по POST-запросу Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №3 2.3.11. Должно обеспечиваться наличие предустановленных виджетов по ИТ активам, отображающим: • количество активов; • значимость активов; • актуальность данных об ИТ-активах. 2.3.12. Должно обеспечиваться наличие предустановленного виджета с изменениями статусов по уязвимостям повышенного уровня опасности (критический и высокий), произошедшими в течение семи дней. 2.3.13. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). 2.3.14. Должна поддерживаться возможность: • выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • экспорта отчетов в один из следующих форматов: JSON, PDF, CSV, XML, XLSX. 2.3.15. Должно обеспечиваться наличие активных ссылок на внешние источники сведений об уязвимостях при экспорте отчетов в формате XLSX. 2.3.16. Должна поддерживаться возможность генерации паролей пользователей Системы. 2.3.17. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему Значение характеристики не может изменяться участником закупки 1. Требования к архитектуре Системы №1 Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы В состав Системы могут входить следующие компоненты: • - компонент сбора и обработки данных — предоставляет возможность сбора и обработки данных, в том числе в рамках процесса управления уязвимостями; • - компонент контроля соответствия стандартам; • - компонент хранения данных; • - компонент управления и визуализации; • - компонент обновления. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между компонентами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между компонентами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, передаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов. 1.3. Требования к характеристикам взаимосвязей создаваемой Системы со смежными системами К взаимодействию Системы со смежными системами предъявляются следующие требования: Значение характеристики не может изменяться участником закупки Требования к архитектуре Системы №2 1.3.1. СУУ должна иметь возможность интеграции: • с LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA — для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • с системами SIEM— для повышения точности оценки защищенности; • с системами электронной почты — для отправки сообщений электронной почты; • с системами разрешения доменных имен — для сбора сведений об узлах, зарегистрированных в Системе; • с системой точного времени Заказчика — для обеспечения единых меток даты и времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с системами разрешения доменных имен должно осуществляться на основе протокола DNS. 1.3.6. Взаимодействие с прочими системами при необходимости должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы. 1.4. Требования к характеристикам взаимосвязей создаваемой Системы с внешними системами К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СУУ должна поддерживать возможность обмена данными с серверами производителей, входящего в нее для получения (загрузки) обновлений. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №5 2.3.23. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета); o настроить выпуск отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почти; o настроить экспорт отчетов в один из следующих форматов: PDF, XLSX. 2.3.24. Должно обеспечиваться отображение очереди построения отчетов. 2.3.25. Должна поддерживаться возможность управления очередью построения отчетов. 2.4. Требования к компоненту обновления Системы К компоненту обновления предъявляются следующие требования: 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения. 2.4.2. Должна поддерживаться пакетная доставка уязвимостей и баз уязвимостей, в том числе при установке со съемных носителей информации Значение характеристики не может изменяться участником закупки Требования к архитектуре Системы №4 1.8. Требования по диагностированию Системы 1.8.1. Система должна обеспечить индикацию собственного состояния и отображение уведомлений о сбоях в работе сервисов Системы в веб-интерфейсе пользователя. 1.8.2. Должно обеспечиваться наличие предустановленных виджетов, отражающих основные показатели работы СУБД, в базе данных которой хранится история изменений каждого актива. 1.8.3. Должно обеспечиваться наличие предустановленных виджетов, позволяющих отслеживать текущую нагрузку на аппаратные средства Системы. 1.9. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: 1.9.1. Должно поддерживаться не менее 1000 ИТ-активов Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №1 2.1. Требования к компоненту сбора и обработки данных К компоненту сбора и обработки данных предъявляются следующие требования: 2.2. Требования к компоненту контроля соответствия стандартам К компоненту контроля соответствия стандартам предъявляются следующие требования: 2.2.1. Должны обеспечиваться проверка соответствия и принятие решений о соответствии текущих параметров программных и программно-технических средств (ИТ активов) требованиям технических стандартов. 2.2.2. Должно обеспечиваться наличие предустановленного набора стандартов 2.2.3. Должна поддерживаться возможность импорта пользовательских стандартов в формате YAML. 2.2.4. Должна поддерживаться возможность импорта пользовательских требований. 2.2.5. Должен поддерживаться механизм валидации импортируемых требований. 2.2.6. Должно обеспечиваться отображение критичности требований в стандарте (по уровню опасности). 2.2.7. Должна поддерживаться возможность установки пользовательских меток на конкретные требования. 2.2.8. Должна поддерживаться возможность указания для каждого импортируемого стандарта следующих параметров: • идентификатор стандарта; • отображаемое имя стандарта; • текстовое описание стандарта; • название регламентирующего документа, на основании которого создан стандарт; • параметры привязки узлов ИТ-актива к требованию; • требования, входящие в стандарт; • новые значения параметров требований (при необходимости). 2.2.9. Должна поддерживаться возможность создания политик и (или) правил проверки соответствия стандартам. 2.2.10. Должна поддерживаться возможность присвоения статусов ИТ-активам, которые не соответствуют стандартам. 2.2.11. Должна поддерживаться возможность создания политик и (или) правил устранения несоответствия ИТ-актива стандарту. 2.2.12. Должна обеспечиваться возможность просмотра оценки соответствия ИТ-актива стандарту (по результатам его проверки правилом проверки соответствия) Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №2 2.3. Требования к компоненту управления и визуализации К компоненту управления и визуализации предъявляются следующие требования: 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.4. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям СУУ на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.5. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.6. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.7. Должно поддерживаться отображение результатов самодиагностики работы компонентов СУУ и оповещение пользователя о неисправностях. 2.3.8. Должна обеспечиваться визуализация статистических данных о результатах функционирования Системы с помощью панелей мониторинга, а также отображение оперативных данных об ИТ-активах и работоспособности Системы в виде графиков, диаграмм и таблиц, закрепляемых за отдельными виджетами. 2.3.9. Должно обеспечиваться наличие предустановленных панелей мониторинга. 2.3.10. Должна обеспечиваться возможность создания пользовательских панелей мониторинга Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (03.15) Средства обнаружения угроз и расследования сетевых инцидентов Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к архитектуре Системы №3 - 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СУУ должна иметь указанные режимы функционирования: • - штатный — режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • - технологический — режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модернизации Системы; • - аварийный — режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных компонентов или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки технических средств (далее также — ТС) и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим. 1.7. Требования к возможностям развития и модификации Системы К возможностям развития и модификации Системы предъявляются следующие требования: 1.7.1. Система должна быть построена по модульному принципу, обеспечивающему гибкий процесс масштабирования. 1.7.2. Должна поддерживаться возможность горизонтального масштабирования Системы для обработки больших объемов данных на территориально распределенных площадках. 1.7.3. При проектировании СУУ должна быть учтены возможности ее модификации в целях: • - увеличения количества ИТ-активов в ИТ-инфраструктуре; • - обработки больших объемов данных. 1.7.4. При проектировании Системы должна учитываться возможность повышения производительности Системы за счет увеличения количества компонентов Системы и производительности аппаратных или виртуализованных платформ - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №4 - 2.3.18. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле); • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до разблокирования учетной записи и сброса количества попыток ввода пароля. 2.3.19. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.20. Должно обеспечиваться журналирование действий пользователей: • с ИТ-активами в интерфейсе Системы; • в части управления сбором данных; • в части управления контентом базы знаний; • в части управления Системой; • во всех случаях авторизации пользователей. 2.3.21. Должен поддерживаться выпуск токенов для авторизации действий пользователей в отношении публичных API. 2.3.22. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач на сбор данных, состояния Системы) с их отправкой на электронную почту или по POST-запросу - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №3 - 2.3.11. Должно обеспечиваться наличие предустановленных виджетов по ИТ активам, отображающим: • количество активов; • значимость активов; • актуальность данных об ИТ-активах. 2.3.12. Должно обеспечиваться наличие предустановленного виджета с изменениями статусов по уязвимостям повышенного уровня опасности (критический и высокий), произошедшими в течение семи дней. 2.3.13. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). 2.3.14. Должна поддерживаться возможность: • выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • экспорта отчетов в один из следующих форматов: JSON, PDF, CSV, XML, XLSX. 2.3.15. Должно обеспечиваться наличие активных ссылок на внешние источники сведений об уязвимостях при экспорте отчетов в формате XLSX. 2.3.16. Должна поддерживаться возможность генерации паролей пользователей Системы. 2.3.17. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему - - Значение характеристики не может изменяться участником закупки - 1. Требования к архитектуре Системы №1 - Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы В состав Системы могут входить следующие компоненты: • - компонент сбора и обработки данных — предоставляет возможность сбора и обработки данных, в том числе в рамках процесса управления уязвимостями; • - компонент контроля соответствия стандартам; • - компонент хранения данных; • - компонент управления и визуализации; • - компонент обновления. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между компонентами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между компонентами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, передаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов. 1.3. Требования к характеристикам взаимосвязей создаваемой Системы со смежными системами К взаимодействию Системы со смежными системами предъявляются следующие требования: - - Значение характеристики не может изменяться участником закупки - Требования к архитектуре Системы №2 - 1.3.1. СУУ должна иметь возможность интеграции: • с LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA — для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • с системами SIEM— для повышения точности оценки защищенности; • с системами электронной почты — для отправки сообщений электронной почты; • с системами разрешения доменных имен — для сбора сведений об узлах, зарегистрированных в Системе; • с системой точного времени Заказчика — для обеспечения единых меток даты и времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с системами разрешения доменных имен должно осуществляться на основе протокола DNS. 1.3.6. Взаимодействие с прочими системами при необходимости должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы. 1.4. Требования к характеристикам взаимосвязей создаваемой Системы с внешними системами К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СУУ должна поддерживать возможность обмена данными с серверами производителей, входящего в нее для получения (загрузки) обновлений. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №5 - 2.3.23. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета); o настроить выпуск отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почти; o настроить экспорт отчетов в один из следующих форматов: PDF, XLSX. 2.3.24. Должно обеспечиваться отображение очереди построения отчетов. 2.3.25. Должна поддерживаться возможность управления очередью построения отчетов. 2.4. Требования к компоненту обновления Системы К компоненту обновления предъявляются следующие требования: 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения. 2.4.2. Должна поддерживаться пакетная доставка уязвимостей и баз уязвимостей, в том числе при установке со съемных носителей информации - - Значение характеристики не может изменяться участником закупки - Требования к архитектуре Системы №4 - 1.8. Требования по диагностированию Системы 1.8.1. Система должна обеспечить индикацию собственного состояния и отображение уведомлений о сбоях в работе сервисов Системы в веб-интерфейсе пользователя. 1.8.2. Должно обеспечиваться наличие предустановленных виджетов, отражающих основные показатели работы СУБД, в базе данных которой хранится история изменений каждого актива. 1.8.3. Должно обеспечиваться наличие предустановленных виджетов, позволяющих отслеживать текущую нагрузку на аппаратные средства Системы. 1.9. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: 1.9.1. Должно поддерживаться не менее 1000 ИТ-активов - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №1 - 2.1. Требования к компоненту сбора и обработки данных К компоненту сбора и обработки данных предъявляются следующие требования: 2.2. Требования к компоненту контроля соответствия стандартам К компоненту контроля соответствия стандартам предъявляются следующие требования: 2.2.1. Должны обеспечиваться проверка соответствия и принятие решений о соответствии текущих параметров программных и программно-технических средств (ИТ активов) требованиям технических стандартов. 2.2.2. Должно обеспечиваться наличие предустановленного набора стандартов 2.2.3. Должна поддерживаться возможность импорта пользовательских стандартов в формате YAML. 2.2.4. Должна поддерживаться возможность импорта пользовательских требований. 2.2.5. Должен поддерживаться механизм валидации импортируемых требований. 2.2.6. Должно обеспечиваться отображение критичности требований в стандарте (по уровню опасности). 2.2.7. Должна поддерживаться возможность установки пользовательских меток на конкретные требования. 2.2.8. Должна поддерживаться возможность указания для каждого импортируемого стандарта следующих параметров: • идентификатор стандарта; • отображаемое имя стандарта; • текстовое описание стандарта; • название регламентирующего документа, на основании которого создан стандарт; • параметры привязки узлов ИТ-актива к требованию; • требования, входящие в стандарт; • новые значения параметров требований (при необходимости). 2.2.9. Должна поддерживаться возможность создания политик и (или) правил проверки соответствия стандартам. 2.2.10. Должна поддерживаться возможность присвоения статусов ИТ-активам, которые не соответствуют стандартам. 2.2.11. Должна поддерживаться возможность создания политик и (или) правил устранения несоответствия ИТ-актива стандарту. 2.2.12. Должна обеспечиваться возможность просмотра оценки соответствия ИТ-актива стандарту (по результатам его проверки правилом проверки соответствия) - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №2 - 2.3. Требования к компоненту управления и визуализации К компоненту управления и визуализации предъявляются следующие требования: 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.4. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям СУУ на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.5. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.6. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.7. Должно поддерживаться отображение результатов самодиагностики работы компонентов СУУ и оповещение пользователя о неисправностях. 2.3.8. Должна обеспечиваться визуализация статистических данных о результатах функционирования Системы с помощью панелей мониторинга, а также отображение оперативных данных об ИТ-активах и работоспособности Системы в виде графиков, диаграмм и таблиц, закрепляемых за отдельными виджетами. 2.3.9. Должно обеспечиваться наличие предустановленных панелей мониторинга. 2.3.10. Должна обеспечиваться возможность создания пользовательских панелей мониторинга - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (03.15) Средства обнаружения угроз и расследования сетевых инцидентов - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Требования к архитектуре Системы №3 - 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СУУ должна иметь указанные режимы функционирования: • - штатный — режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • - технологический — режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модернизации Системы; • - аварийный — режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных компонентов или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки технических средств (далее также — ТС) и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим. 1.7. Требования к возможностям развития и модификации Системы К возможностям развития и модификации Системы предъявляются следующие требования: 1.7.1. Система должна быть построена по модульному принципу, обеспечивающему гибкий процесс масштабирования. 1.7.2. Должна поддерживаться возможность горизонтального масштабирования Системы для обработки больших объемов данных на территориально распределенных площадках. 1.7.3. При проектировании СУУ должна быть учтены возможности ее модификации в целях: • - увеличения количества ИТ-активов в ИТ-инфраструктуре; • - обработки больших объемов данных. 1.7.4. При проектировании Системы должна учитываться возможность повышения производительности Системы за счет увеличения количества компонентов Системы и производительности аппаратных или виртуализованных платформ - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №4 - 2.3.18. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле); • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до разблокирования учетной записи и сброса количества попыток ввода пароля. 2.3.19. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.20. Должно обеспечиваться журналирование действий пользователей: • с ИТ-активами в интерфейсе Системы; • в части управления сбором данных; • в части управления контентом базы знаний; • в части управления Системой; • во всех случаях авторизации пользователей. 2.3.21. Должен поддерживаться выпуск токенов для авторизации действий пользователей в отношении публичных API. 2.3.22. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач на сбор данных, состояния Системы) с их отправкой на электронную почту или по POST-запросу - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №3 - 2.3.11. Должно обеспечиваться наличие предустановленных виджетов по ИТ активам, отображающим: • количество активов; • значимость активов; • актуальность данных об ИТ-активах. 2.3.12. Должно обеспечиваться наличие предустановленного виджета с изменениями статусов по уязвимостям повышенного уровня опасности (критический и высокий), произошедшими в течение семи дней. 2.3.13. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). 2.3.14. Должна поддерживаться возможность: • выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • экспорта отчетов в один из следующих форматов: JSON, PDF, CSV, XML, XLSX. 2.3.15. Должно обеспечиваться наличие активных ссылок на внешние источники сведений об уязвимостях при экспорте отчетов в формате XLSX. 2.3.16. Должна поддерживаться возможность генерации паролей пользователей Системы. 2.3.17. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему - - Значение характеристики не может изменяться участником закупки

1. Требования к архитектуре Системы №1 - Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы В состав Системы могут входить следующие компоненты: • - компонент сбора и обработки данных — предоставляет возможность сбора и обработки данных, в том числе в рамках процесса управления уязвимостями; • - компонент контроля соответствия стандартам; • - компонент хранения данных; • - компонент управления и визуализации; • - компонент обновления. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между компонентами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между компонентами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, передаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов. 1.3. Требования к характеристикам взаимосвязей создаваемой Системы со смежными системами К взаимодействию Системы со смежными системами предъявляются следующие требования: - - Значение характеристики не может изменяться участником закупки

Требования к архитектуре Системы №2 - 1.3.1. СУУ должна иметь возможность интеграции: • с LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA — для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • с системами SIEM— для повышения точности оценки защищенности; • с системами электронной почты — для отправки сообщений электронной почты; • с системами разрешения доменных имен — для сбора сведений об узлах, зарегистрированных в Системе; • с системой точного времени Заказчика — для обеспечения единых меток даты и времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с системами разрешения доменных имен должно осуществляться на основе протокола DNS. 1.3.6. Взаимодействие с прочими системами при необходимости должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы. 1.4. Требования к характеристикам взаимосвязей создаваемой Системы с внешними системами К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СУУ должна поддерживать возможность обмена данными с серверами производителей, входящего в нее для получения (загрузки) обновлений. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №5 - 2.3.23. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета); o настроить выпуск отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почти; o настроить экспорт отчетов в один из следующих форматов: PDF, XLSX. 2.3.24. Должно обеспечиваться отображение очереди построения отчетов. 2.3.25. Должна поддерживаться возможность управления очередью построения отчетов. 2.4. Требования к компоненту обновления Системы К компоненту обновления предъявляются следующие требования: 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения. 2.4.2. Должна поддерживаться пакетная доставка уязвимостей и баз уязвимостей, в том числе при установке со съемных носителей информации - - Значение характеристики не может изменяться участником закупки

Требования к архитектуре Системы №4 - 1.8. Требования по диагностированию Системы 1.8.1. Система должна обеспечить индикацию собственного состояния и отображение уведомлений о сбоях в работе сервисов Системы в веб-интерфейсе пользователя. 1.8.2. Должно обеспечиваться наличие предустановленных виджетов, отражающих основные показатели работы СУБД, в базе данных которой хранится история изменений каждого актива. 1.8.3. Должно обеспечиваться наличие предустановленных виджетов, позволяющих отслеживать текущую нагрузку на аппаратные средства Системы. 1.9. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: 1.9.1. Должно поддерживаться не менее 1000 ИТ-активов - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №1 - 2.1. Требования к компоненту сбора и обработки данных К компоненту сбора и обработки данных предъявляются следующие требования: 2.2. Требования к компоненту контроля соответствия стандартам К компоненту контроля соответствия стандартам предъявляются следующие требования: 2.2.1. Должны обеспечиваться проверка соответствия и принятие решений о соответствии текущих параметров программных и программно-технических средств (ИТ активов) требованиям технических стандартов. 2.2.2. Должно обеспечиваться наличие предустановленного набора стандартов 2.2.3. Должна поддерживаться возможность импорта пользовательских стандартов в формате YAML. 2.2.4. Должна поддерживаться возможность импорта пользовательских требований. 2.2.5. Должен поддерживаться механизм валидации импортируемых требований. 2.2.6. Должно обеспечиваться отображение критичности требований в стандарте (по уровню опасности). 2.2.7. Должна поддерживаться возможность установки пользовательских меток на конкретные требования. 2.2.8. Должна поддерживаться возможность указания для каждого импортируемого стандарта следующих параметров: • идентификатор стандарта; • отображаемое имя стандарта; • текстовое описание стандарта; • название регламентирующего документа, на основании которого создан стандарт; • параметры привязки узлов ИТ-актива к требованию; • требования, входящие в стандарт; • новые значения параметров требований (при необходимости). 2.2.9. Должна поддерживаться возможность создания политик и (или) правил проверки соответствия стандартам. 2.2.10. Должна поддерживаться возможность присвоения статусов ИТ-активам, которые не соответствуют стандартам. 2.2.11. Должна поддерживаться возможность создания политик и (или) правил устранения несоответствия ИТ-актива стандарту. 2.2.12. Должна обеспечиваться возможность просмотра оценки соответствия ИТ-актива стандарту (по результатам его проверки правилом проверки соответствия) - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №2 - 2.3. Требования к компоненту управления и визуализации К компоненту управления и визуализации предъявляются следующие требования: 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.4. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям СУУ на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.5. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.6. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.7. Должно поддерживаться отображение результатов самодиагностики работы компонентов СУУ и оповещение пользователя о неисправностях. 2.3.8. Должна обеспечиваться визуализация статистических данных о результатах функционирования Системы с помощью панелей мониторинга, а также отображение оперативных данных об ИТ-активах и работоспособности Системы в виде графиков, диаграмм и таблиц, закрепляемых за отдельными виджетами. 2.3.9. Должно обеспечиваться наличие предустановленных панелей мониторинга. 2.3.10. Должна обеспечиваться возможность создания пользовательских панелей мониторинга - - Значение характеристики не может изменяться участником закупки

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Требования к архитектуре Системы №1 Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы: В состав Системы могут входить следующие подсистемы: • подсистема сбора данных — предоставляет возможность сбора данных об активах, и данных, поступающих от активов; • подсистема обработки данных — предоставляет возможность обработки данных об активах, и данных, поступающих от активов; • подсистема «База знаний» — обеспечивает хранение пакетов экспертизы (наборов правил нормализации, агрегации, обогащения, локализации, корреляции и табличных списков), и управление ими; • подсистема хранения данных — обеспечивает хранение данных об активах, исходных и обработанных событиях, а также поддержку хранения данных во внешних системах хранения; • подсистема доставки индикаторов компрометации — обеспечивает доставку и управление индикаторами компрометации; • подсистема управления и визуализации — обеспечивает доступ пользователей к функциям Системы и визуализацию результатов работы других подсистем. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между подсистемами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между подсистемами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, предаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS-сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS-сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов Требования к архитектуре Системы №2 1.3. Требования к характеристикам взаимосвязей между создаваемой Системой и смежными Системами К взаимодействию Системы со смежными системами предъявляются следующие требования: 1.3.1. СМСИБ должна иметь возможность интеграции со следующими системами: • LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA – для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • системой управления уязвимостями на базе программного изделия MaxPatrol VM – для получения сведений об инфраструктуре (уязвимостях в инфраструктуре), необходимых для построения возможных сценариев атак; • системой анализа сетевого трафика и выявления атак • аналитическими системами проверки файлов на наличие ВПО (PT Sandbox, PT MultiScanner) – для передачи выделяемых из сетевого трафика файловых объектов на проверку и получения результатов проверки; • системами электронной почты – для отправки сообщений электронной почты; • системами разрешения доменных имен – для сбора сведений об узлах, зарегистрированных в Cистеме; • системой точного времени Заказчика – для обеспечения единых меток даты/времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с прочими системами должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы Требования к архитектуре Системы №3 1.4. Требования к характеристикам взаимосвязей между создаваемой Системой и внешними системами: К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СМСИБ должна иметь возможность поддерживать обмен данными с серверами разработчиков ПО для получения (загрузки) обновлений. 1.4.2. СМСИБ должна поддерживать отправку сообщений во внешние системы c помощью технологии webhook. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных. 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СМСИБ должна иметь указанные режимы функционирования: • штатный – режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • технологический – режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модификации Системы; • аварийный – режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных подсистем или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки ТС и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим - Штука - 1,00 - 3 120 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к архитектуре Системы №1 Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы: В состав Системы могут входить следующие подсистемы: • подсистема сбора данных — предоставляет возможность сбора данных об активах, и данных, поступающих от активов; • подсистема обработки данных — предоставляет возможность обработки данных об активах, и данных, поступающих от активов; • подсистема «База знаний» — обеспечивает хранение пакетов экспертизы (наборов правил нормализации, агрегации, обогащения, локализации, корреляции и табличных списков), и управление ими; • подсистема хранения данных — обеспечивает хранение данных об активах, исходных и обработанных событиях, а также поддержку хранения данных во внешних системах хранения; • подсистема доставки индикаторов компрометации — обеспечивает доставку и управление индикаторами компрометации; • подсистема управления и визуализации — обеспечивает доступ пользователей к функциям Системы и визуализацию результатов работы других подсистем. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между подсистемами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между подсистемами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, предаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS-сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS-сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов Значение характеристики не может изменяться участником закупки Требования к архитектуре Системы №2 1.3. Требования к характеристикам взаимосвязей между создаваемой Системой и смежными Системами К взаимодействию Системы со смежными системами предъявляются следующие требования: 1.3.1. СМСИБ должна иметь возможность интеграции со следующими системами: • LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA – для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • системой управления уязвимостями на базе программного изделия MaxPatrol VM – для получения сведений об инфраструктуре (уязвимостях в инфраструктуре), необходимых для построения возможных сценариев атак; • системой анализа сетевого трафика и выявления атак • аналитическими системами проверки файлов на наличие ВПО (PT Sandbox, PT MultiScanner) – для передачи выделяемых из сетевого трафика файловых объектов на проверку и получения результатов проверки; • системами электронной почты – для отправки сообщений электронной почты; • системами разрешения доменных имен – для сбора сведений об узлах, зарегистрированных в Cистеме; • системой точного времени Заказчика – для обеспечения единых меток даты/времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с прочими системами должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы Значение характеристики не может изменяться участником закупки Требования к архитектуре Системы №3 1.4. Требования к характеристикам взаимосвязей между создаваемой Системой и внешними системами: К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СМСИБ должна иметь возможность поддерживать обмен данными с серверами разработчиков ПО для получения (загрузки) обновлений. 1.4.2. СМСИБ должна поддерживать отправку сообщений во внешние системы c помощью технологии webhook. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных. 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СМСИБ должна иметь указанные режимы функционирования: • штатный – режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • технологический – режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модификации Системы; • аварийный – режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных подсистем или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки ТС и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим Требования к архитектуре Системы №4 1.7. Требования по диагностированию Системы К диагностированию Системы предъявляются следующие требования: 1.7.1. Должна обеспечиваться индикация собственного состояния и отображение уведомлений в интерфейсе пользователя о сбоях в работе СМСИБ. 1.7.2. СМСИБ должна иметь возможность сбора статистики работы с узлов с установленными компонентами СМСИБ для ее передачи в службу технической поддержки. 1.7.3. Должна предоставляться возможность мониторинга обработки активов для оценки нагрузки на подсистемы сбора и обработки событий. 1.7.4. Должна предоставляться возможность отслеживать распределение и обработку потока событий для управления нагрузкой на подсистемы сбора и обработки событий. 1.7.5. Должна обеспечиваться визуализация характеристик входящего потока событий. 1.7.6. Должна поддерживаться передача данных в систему мониторинга Grafana, позволяющая визуализировать ключевые показатели мониторинга хранилищ и баз данных используемых СМСИБ, в том числе: • дисковая активность; • доступное дисковое пространство; • количество открытых файловых дескрипторов; • размер кэша запросов; • количество открытых подключений по протоколам HTTP и TCP; • количество потоков в процессе хранилища данных. 1.8. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: Требования к функциям (задачам), выполняемым Системой №1 К функциям Системы, выполняемым ее подсистемами, предъявляются следующие требования: Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов 2.1. Требования к подсистеме «База знаний» 2.1.1. Должно обеспечиваться хранение базы активных (используемых) и неиспользуемых правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 2.1.2. Должно обеспечиваться хранение табличных списков. 2.1.3. Должно обеспечиваться формирование и хранение макросов (шаблонов фильтров событий, используемых при создании правил корреляции). 2.1.4. Должно обеспечиваться управление (в том числе создание, изменение и удаление) элементами базы знаний: • правилами (формулами) нормализации, агрегации, локализации, обогащения и корреляции; • макросами, используемыми при создании правил корреляции; • табличными списками следующих типов: o с данными об активах, автоматически заполняемыми в результате выполнения задач сбора данных; o со справочными данными, обеспечивающими представление технологической информации в человекочитаемой форме; o с репутационными данными — наборами индикаторов компрометации; o с временными данными — создаваемыми на основе автоматически заполняемых списков и используемыми правилами корреляции и обогащения. 2.1.5. Должно обеспечиваться наличие пакетов экспертных знаний, предназначенных для обнаружения признаков возможных инцидентов (см. Приложение Б). 2.1.6. Должна поддерживаться активация и деактивация табличных списков Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №2 2.1.7. Должно обеспечиваться наличие доступного через веб-интерфейс графического конструктора, предназначенного для создания пользовательских правил корреляции и предоставляющего следующие функциональные возможности: • использование предустановленных и пользовательских макросов; • формирование и редактирование пользовательских правил корреляции с помощью встроенного языка запросов напрямую из конструктора правил; • автоматическое формирование представления правила в формате встроенного языка запросов; • проверка синтаксической корректности разрабатываемых правил (формул) нормализации, агрегации, локализации, обогащения и корреляции. 2.1.8. Должна обеспечиваться валидация пользовательских правил (формул) нормализации, агрегации, локализации, обогащения и корреляции, табличных списков, макросов с проверкой их структуры, синтаксиса, корректности указанных условий и совместимости правил между собой. 2.1.9. Должна поддерживаться группировка материалов базы знаний в отдельные папки по выбору пользователя. 2.1.10. Должна обеспечиваться возможность применения правил из базы знаний, выбранных пользователем, модулем обработки событий. 2.1.11. Должны поддерживаться возможность экспорта и импорта контента базы знаний Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №3 2.2.1. Должна обеспечиваться возможность управления получением индикаторов компрометации из внешних источников. 2.2.2. Должно обеспечиваться периодическое обновление индикаторов компрометации из внешних баз знаний и их представление в виде репутационных списков. 2.2.3. Должна обеспечиваться возможность управления периодичностью получения данных из источников. 2.2.4. Должна обеспечиваться поддержка репутационных списков со следующими типами индикаторов компрометации: • хеш-суммами файлов; • IP-адресами; • URL; • доменными именами. 2.2.5. Должна обеспечиваться возможность настройки времени жизни (срока актуальности) индикаторов компрометации для следующих типов индикаторов: • IP-адрес; • доменное имя; • URL. 2.2.6. Должно обеспечиваться удаление индикаторов компрометации, срок актуальности которых истек Значение характеристики не может изменяться участником закупки Требования к функциям (задачам), выполняемым Системой №8 2.3.35. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач сбора данных, Системы) с их отправкой на электронную почту или по POST-запросу. 2.4. Требования к обновлению Системы 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения, входящего в состав Системы, в том числе со съемных носителей информации. 2.4.2. Должна поддерживаться возможность автоматизированного обновления наборов пакетов экспертизы подсистемы «База знаний» Требования к функциям (задачам), выполняемым Системой №6 2.3.17.2.3.26. Должна поддерживаться возможность сохранения выбранных настроек отображения в виде шаблонов. 2.3.27. Должно поддерживаться управление шаблоном, в том числе: • включением, отключением, изменением шаблона; • составом отображаемых сведений, задаваемым каждым шаблоном; • областью применения конкретного шаблона (для каких событий и пользователей применяется шаблон). 2.3.28. Должна обеспечиваться возможность экспорта информации о событиях, активах и инцидентах в следующих форматах: CSV, XLSX, JSON, XML. 2.3.29. Должна обеспечиваться возможность экспорта информации по инциденту в виде электронного документа в формате PDF. 2.3.30. Должен поддерживаться вывод сведений об отклонениях от нормального поведения, обнаруженных в рамках проведения поведенческого анализа. 2.3.31. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). • возможности выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • возможности экспорта отчетов в один из следующих форматов: JSON, PDF, XML, XLSX. 2.3.32. Должно обеспечиваться отображение очереди построения отчетов. 2.3.33. Должно обеспечиваться управление очередью построения отчетов. 2.3.34. Должно обеспечиваться журналирование действий пользователей: • с карточками активов; • с записями о событиях; • с карточками инцидентов; • в части управления иерархией; • в части управления сбором данных; • в части управления контентом подсистемы «База знаний»; • в части управления Системой; • все случаи авторизации пользователей Требования к функциям (задачам), выполняемым Системой №4 2.3. Требования к подсистеме управления и визуализации 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с данными Системы. 2.3.4. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.5. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям Системы на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.6. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.7. Должна поддерживаться возможность просмотра списка удаленных учетных записей СМСИБ. 2.3.8. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.9. Должна поддерживаться возможность генерации паролей пользователей. 2.3.10. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему Требования к функциям (задачам), выполняемым Системой №5 2.3.11. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле; • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до сброса количества попыток ввода пароля. 2.3.12. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.13. Должен поддерживаться выпуск токенов для авторизации действий пользователей, использующих публичные API, для передачи команд в СМСИБ. 2.3.14. Должно обеспечиваться отображение результатов самодиагностики подсистем СМСИБ и оповещение пользователя о неисправностях. 2.3.15. Должна поддерживаться возможность управления нагрузкой на модули сбора данных, путем управления максимальным количеством одновременно выполняемых задач или подзадач. 2.3.16. Должна поддерживаться возможность установки политик контроля источников данных: • на основе контроля активности источника; • основе контроля потока данных для выбранного пользователем типа событий; • основе контроля задержки между появлением события на источнике и получением его модулем сбора данных Класс программ для электронных вычислительных машин и баз данных (03.02) Средства управления событиями информационной безопасности Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к архитектуре Системы №1 - Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы: В состав Системы могут входить следующие подсистемы: • подсистема сбора данных — предоставляет возможность сбора данных об активах, и данных, поступающих от активов; • подсистема обработки данных — предоставляет возможность обработки данных об активах, и данных, поступающих от активов; • подсистема «База знаний» — обеспечивает хранение пакетов экспертизы (наборов правил нормализации, агрегации, обогащения, локализации, корреляции и табличных списков), и управление ими; • подсистема хранения данных — обеспечивает хранение данных об активах, исходных и обработанных событиях, а также поддержку хранения данных во внешних системах хранения; • подсистема доставки индикаторов компрометации — обеспечивает доставку и управление индикаторами компрометации; • подсистема управления и визуализации — обеспечивает доступ пользователей к функциям Системы и визуализацию результатов работы других подсистем. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между подсистемами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между подсистемами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, предаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS-сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS-сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов - - Значение характеристики не может изменяться участником закупки - Требования к архитектуре Системы №2 - 1.3. Требования к характеристикам взаимосвязей между создаваемой Системой и смежными Системами К взаимодействию Системы со смежными системами предъявляются следующие требования: 1.3.1. СМСИБ должна иметь возможность интеграции со следующими системами: • LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA – для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • системой управления уязвимостями на базе программного изделия MaxPatrol VM – для получения сведений об инфраструктуре (уязвимостях в инфраструктуре), необходимых для построения возможных сценариев атак; • системой анализа сетевого трафика и выявления атак • аналитическими системами проверки файлов на наличие ВПО (PT Sandbox, PT MultiScanner) – для передачи выделяемых из сетевого трафика файловых объектов на проверку и получения результатов проверки; • системами электронной почты – для отправки сообщений электронной почты; • системами разрешения доменных имен – для сбора сведений об узлах, зарегистрированных в Cистеме; • системой точного времени Заказчика – для обеспечения единых меток даты/времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с прочими системами должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы - - Значение характеристики не может изменяться участником закупки - Требования к архитектуре Системы №3 - 1.4. Требования к характеристикам взаимосвязей между создаваемой Системой и внешними системами: К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СМСИБ должна иметь возможность поддерживать обмен данными с серверами разработчиков ПО для получения (загрузки) обновлений. 1.4.2. СМСИБ должна поддерживать отправку сообщений во внешние системы c помощью технологии webhook. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных. 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СМСИБ должна иметь указанные режимы функционирования: • штатный – режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • технологический – режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модификации Системы; • аварийный – режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных подсистем или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки ТС и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим - - - Требования к архитектуре Системы №4 - 1.7. Требования по диагностированию Системы К диагностированию Системы предъявляются следующие требования: 1.7.1. Должна обеспечиваться индикация собственного состояния и отображение уведомлений в интерфейсе пользователя о сбоях в работе СМСИБ. 1.7.2. СМСИБ должна иметь возможность сбора статистики работы с узлов с установленными компонентами СМСИБ для ее передачи в службу технической поддержки. 1.7.3. Должна предоставляться возможность мониторинга обработки активов для оценки нагрузки на подсистемы сбора и обработки событий. 1.7.4. Должна предоставляться возможность отслеживать распределение и обработку потока событий для управления нагрузкой на подсистемы сбора и обработки событий. 1.7.5. Должна обеспечиваться визуализация характеристик входящего потока событий. 1.7.6. Должна поддерживаться передача данных в систему мониторинга Grafana, позволяющая визуализировать ключевые показатели мониторинга хранилищ и баз данных используемых СМСИБ, в том числе: • дисковая активность; • доступное дисковое пространство; • количество открытых файловых дескрипторов; • размер кэша запросов; • количество открытых подключений по протоколам HTTP и TCP; • количество потоков в процессе хранилища данных. 1.8. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: - - - Требования к функциям (задачам), выполняемым Системой №1 - К функциям Системы, выполняемым ее подсистемами, предъявляются следующие требования: Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов 2.1. Требования к подсистеме «База знаний» 2.1.1. Должно обеспечиваться хранение базы активных (используемых) и неиспользуемых правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 2.1.2. Должно обеспечиваться хранение табличных списков. 2.1.3. Должно обеспечиваться формирование и хранение макросов (шаблонов фильтров событий, используемых при создании правил корреляции). 2.1.4. Должно обеспечиваться управление (в том числе создание, изменение и удаление) элементами базы знаний: • правилами (формулами) нормализации, агрегации, локализации, обогащения и корреляции; • макросами, используемыми при создании правил корреляции; • табличными списками следующих типов: o с данными об активах, автоматически заполняемыми в результате выполнения задач сбора данных; o со справочными данными, обеспечивающими представление технологической информации в человекочитаемой форме; o с репутационными данными — наборами индикаторов компрометации; o с временными данными — создаваемыми на основе автоматически заполняемых списков и используемыми правилами корреляции и обогащения. 2.1.5. Должно обеспечиваться наличие пакетов экспертных знаний, предназначенных для обнаружения признаков возможных инцидентов (см. Приложение Б). 2.1.6. Должна поддерживаться активация и деактивация табличных списков - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №2 - 2.1.7. Должно обеспечиваться наличие доступного через веб-интерфейс графического конструктора, предназначенного для создания пользовательских правил корреляции и предоставляющего следующие функциональные возможности: • использование предустановленных и пользовательских макросов; • формирование и редактирование пользовательских правил корреляции с помощью встроенного языка запросов напрямую из конструктора правил; • автоматическое формирование представления правила в формате встроенного языка запросов; • проверка синтаксической корректности разрабатываемых правил (формул) нормализации, агрегации, локализации, обогащения и корреляции. 2.1.8. Должна обеспечиваться валидация пользовательских правил (формул) нормализации, агрегации, локализации, обогащения и корреляции, табличных списков, макросов с проверкой их структуры, синтаксиса, корректности указанных условий и совместимости правил между собой. 2.1.9. Должна поддерживаться группировка материалов базы знаний в отдельные папки по выбору пользователя. 2.1.10. Должна обеспечиваться возможность применения правил из базы знаний, выбранных пользователем, модулем обработки событий. 2.1.11. Должны поддерживаться возможность экспорта и импорта контента базы знаний - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №3 - 2.2.1. Должна обеспечиваться возможность управления получением индикаторов компрометации из внешних источников. 2.2.2. Должно обеспечиваться периодическое обновление индикаторов компрометации из внешних баз знаний и их представление в виде репутационных списков. 2.2.3. Должна обеспечиваться возможность управления периодичностью получения данных из источников. 2.2.4. Должна обеспечиваться поддержка репутационных списков со следующими типами индикаторов компрометации: • хеш-суммами файлов; • IP-адресами; • URL; • доменными именами. 2.2.5. Должна обеспечиваться возможность настройки времени жизни (срока актуальности) индикаторов компрометации для следующих типов индикаторов: • IP-адрес; • доменное имя; • URL. 2.2.6. Должно обеспечиваться удаление индикаторов компрометации, срок актуальности которых истек - - Значение характеристики не может изменяться участником закупки - Требования к функциям (задачам), выполняемым Системой №8 - 2.3.35. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач сбора данных, Системы) с их отправкой на электронную почту или по POST-запросу. 2.4. Требования к обновлению Системы 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения, входящего в состав Системы, в том числе со съемных носителей информации. 2.4.2. Должна поддерживаться возможность автоматизированного обновления наборов пакетов экспертизы подсистемы «База знаний» - - - Требования к функциям (задачам), выполняемым Системой №6 - 2.3.17.2.3.26. Должна поддерживаться возможность сохранения выбранных настроек отображения в виде шаблонов. 2.3.27. Должно поддерживаться управление шаблоном, в том числе: • включением, отключением, изменением шаблона; • составом отображаемых сведений, задаваемым каждым шаблоном; • областью применения конкретного шаблона (для каких событий и пользователей применяется шаблон). 2.3.28. Должна обеспечиваться возможность экспорта информации о событиях, активах и инцидентах в следующих форматах: CSV, XLSX, JSON, XML. 2.3.29. Должна обеспечиваться возможность экспорта информации по инциденту в виде электронного документа в формате PDF. 2.3.30. Должен поддерживаться вывод сведений об отклонениях от нормального поведения, обнаруженных в рамках проведения поведенческого анализа. 2.3.31. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). • возможности выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • возможности экспорта отчетов в один из следующих форматов: JSON, PDF, XML, XLSX. 2.3.32. Должно обеспечиваться отображение очереди построения отчетов. 2.3.33. Должно обеспечиваться управление очередью построения отчетов. 2.3.34. Должно обеспечиваться журналирование действий пользователей: • с карточками активов; • с записями о событиях; • с карточками инцидентов; • в части управления иерархией; • в части управления сбором данных; • в части управления контентом подсистемы «База знаний»; • в части управления Системой; • все случаи авторизации пользователей - - - Требования к функциям (задачам), выполняемым Системой №4 - 2.3. Требования к подсистеме управления и визуализации 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с данными Системы. 2.3.4. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.5. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям Системы на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.6. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.7. Должна поддерживаться возможность просмотра списка удаленных учетных записей СМСИБ. 2.3.8. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.9. Должна поддерживаться возможность генерации паролей пользователей. 2.3.10. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему - - - Требования к функциям (задачам), выполняемым Системой №5 - 2.3.11. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле; • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до сброса количества попыток ввода пароля. 2.3.12. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.13. Должен поддерживаться выпуск токенов для авторизации действий пользователей, использующих публичные API, для передачи команд в СМСИБ. 2.3.14. Должно обеспечиваться отображение результатов самодиагностики подсистем СМСИБ и оповещение пользователя о неисправностях. 2.3.15. Должна поддерживаться возможность управления нагрузкой на модули сбора данных, путем управления максимальным количеством одновременно выполняемых задач или подзадач. 2.3.16. Должна поддерживаться возможность установки политик контроля источников данных: • на основе контроля активности источника; • основе контроля потока данных для выбранного пользователем типа событий; • основе контроля задержки между появлением события на источнике и получением его модулем сбора данных - - - Класс программ для электронных вычислительных машин и баз данных - (03.02) Средства управления событиями информационной безопасности - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Требования к архитектуре Системы №1 - Архитектура Системы должна соответствовать следующим требованиям: 1.1. Требования к составу Системы: В состав Системы могут входить следующие подсистемы: • подсистема сбора данных — предоставляет возможность сбора данных об активах, и данных, поступающих от активов; • подсистема обработки данных — предоставляет возможность обработки данных об активах, и данных, поступающих от активов; • подсистема «База знаний» — обеспечивает хранение пакетов экспертизы (наборов правил нормализации, агрегации, обогащения, локализации, корреляции и табличных списков), и управление ими; • подсистема хранения данных — обеспечивает хранение данных об активах, исходных и обработанных событиях, а также поддержку хранения данных во внешних системах хранения; • подсистема доставки индикаторов компрометации — обеспечивает доставку и управление индикаторами компрометации; • подсистема управления и визуализации — обеспечивает доступ пользователей к функциям Системы и визуализацию результатов работы других подсистем. 1.2. Требования к способам и средствам связи для информационного обмена между компонентами Системы Взаимодействие между подсистемами должно соответствовать следующим требованиям: 1.2.1. Взаимодействие между подсистемами должно осуществляться на основе унифицированного информационного способа взаимодействия с использованием стека протоколов TCP/IP и технологии канального уровня Ethernet. 1.2.2. Данные, предаваемые компонентами на пользовательский интерфейс, должны быть защищены при помощи HTTPS с использованием TLS-сертификата (TLS версии 1.2 или выше). 1.2.3. Должно обеспечиваться наличие встроенных самоподписанных TLS-сертификатов, поставляемых совместно с ПО Системы. 1.2.4. Должна поддерживаться возможность замены встроенных самоподписанных TLS-сертификатов на TLS-сертификаты Заказчика. 1.2.5. Должна обеспечиваться валидация добавляемых сертификатов - - Значение характеристики не может изменяться участником закупки

Требования к архитектуре Системы №2 - 1.3. Требования к характеристикам взаимосвязей между создаваемой Системой и смежными Системами К взаимодействию Системы со смежными системами предъявляются следующие требования: 1.3.1. СМСИБ должна иметь возможность интеграции со следующими системами: • LDAP-серверами на базе Microsoft Active Directory, ALD Pro и FreeIPA – для интеграции с внешними системами аутентификации и бесшовного соотнесения ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA в рамках обеспечения единого входа в Систему (SSO); • системой управления уязвимостями на базе программного изделия MaxPatrol VM – для получения сведений об инфраструктуре (уязвимостях в инфраструктуре), необходимых для построения возможных сценариев атак; • системой анализа сетевого трафика и выявления атак • аналитическими системами проверки файлов на наличие ВПО (PT Sandbox, PT MultiScanner) – для передачи выделяемых из сетевого трафика файловых объектов на проверку и получения результатов проверки; • системами электронной почты – для отправки сообщений электронной почты; • системами разрешения доменных имен – для сбора сведений об узлах, зарегистрированных в Cистеме; • системой точного времени Заказчика – для обеспечения единых меток даты/времени. 1.3.2. Взаимодействие с LDAP-серверами должно осуществляться по протоколам LDAP или LDAPS. 1.3.3. Взаимодействие с системой точного времени в вычислительной сети Заказчика должно осуществляться на основе протокола NTP. 1.3.4. Взаимодействие с системами электронной почты должно осуществляться по протоколу SMTP. 1.3.5. Взаимодействие с прочими системами должно осуществляться через публичные API, предоставляемые компонентами, входящими в состав Системы - - Значение характеристики не может изменяться участником закупки

Требования к архитектуре Системы №3 - 1.4. Требования к характеристикам взаимосвязей между создаваемой Системой и внешними системами: К взаимодействию Системы с внешними системами предъявляются следующие требования: 1.4.1. СМСИБ должна иметь возможность поддерживать обмен данными с серверами разработчиков ПО для получения (загрузки) обновлений. 1.4.2. СМСИБ должна поддерживать отправку сообщений во внешние системы c помощью технологии webhook. 1.5. Требования к взаимодействию с защищаемыми объектами Взаимодействие Системы с защищаемыми системами должно соответствовать следующим требованиям: 1.5.1. Должен поддерживаться сбор данных в выделенных сегментах информационно-телекоммуникационной сети путем размещения модулей сбора данных. 1.6. Требования к режимам функционирования Системы К режимам функционирования Системы предъявляются следующие требования: 1.6.1. СМСИБ должна иметь указанные режимы функционирования: • штатный – режим функционирования Системы, при котором поддерживается выполнение всех заявленных функций; • технологический – режим функционирования для проведения регламентных работ по обслуживанию, реконфигурации и модификации Системы; • аварийный – режим функционирования при обнаружении сбоев и отказов в работе Системы, ее отдельных подсистем или поддерживающей инфраструктуры. 1.6.2. Функционирование в штатном и технологическом режимах должно осуществляться в круглосуточном непрерывном режиме. 1.6.3. Проектная документация на Систему должна содержать сведения о переходе между режимами функционирования, в том числе: • описание режимов работы; • периодичность остановки ТС и перевода Системы в технологический режим для проведения профилактических работ; • комплекс мероприятий по восстановлению работоспособности Системы и устранению причин ее перехода в аварийный режим - -

Требования к архитектуре Системы №4 - 1.7. Требования по диагностированию Системы К диагностированию Системы предъявляются следующие требования: 1.7.1. Должна обеспечиваться индикация собственного состояния и отображение уведомлений в интерфейсе пользователя о сбоях в работе СМСИБ. 1.7.2. СМСИБ должна иметь возможность сбора статистики работы с узлов с установленными компонентами СМСИБ для ее передачи в службу технической поддержки. 1.7.3. Должна предоставляться возможность мониторинга обработки активов для оценки нагрузки на подсистемы сбора и обработки событий. 1.7.4. Должна предоставляться возможность отслеживать распределение и обработку потока событий для управления нагрузкой на подсистемы сбора и обработки событий. 1.7.5. Должна обеспечиваться визуализация характеристик входящего потока событий. 1.7.6. Должна поддерживаться передача данных в систему мониторинга Grafana, позволяющая визуализировать ключевые показатели мониторинга хранилищ и баз данных используемых СМСИБ, в том числе: • дисковая активность; • доступное дисковое пространство; • количество открытых файловых дескрипторов; • размер кэша запросов; • количество открытых подключений по протоколам HTTP и TCP; • количество потоков в процессе хранилища данных. 1.8. Требования к показателям назначения При работе в штатном режиме должно обеспечиваться достижение следующих показателей назначения: - -

Требования к функциям (задачам), выполняемым Системой №1 - К функциям Системы, выполняемым ее подсистемами, предъявляются следующие требования: Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов 2.1. Требования к подсистеме «База знаний» 2.1.1. Должно обеспечиваться хранение базы активных (используемых) и неиспользуемых правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 2.1.2. Должно обеспечиваться хранение табличных списков. 2.1.3. Должно обеспечиваться формирование и хранение макросов (шаблонов фильтров событий, используемых при создании правил корреляции). 2.1.4. Должно обеспечиваться управление (в том числе создание, изменение и удаление) элементами базы знаний: • правилами (формулами) нормализации, агрегации, локализации, обогащения и корреляции; • макросами, используемыми при создании правил корреляции; • табличными списками следующих типов: o с данными об активах, автоматически заполняемыми в результате выполнения задач сбора данных; o со справочными данными, обеспечивающими представление технологической информации в человекочитаемой форме; o с репутационными данными — наборами индикаторов компрометации; o с временными данными — создаваемыми на основе автоматически заполняемых списков и используемыми правилами корреляции и обогащения. 2.1.5. Должно обеспечиваться наличие пакетов экспертных знаний, предназначенных для обнаружения признаков возможных инцидентов (см. Приложение Б). 2.1.6. Должна поддерживаться активация и деактивация табличных списков - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №2 - 2.1.7. Должно обеспечиваться наличие доступного через веб-интерфейс графического конструктора, предназначенного для создания пользовательских правил корреляции и предоставляющего следующие функциональные возможности: • использование предустановленных и пользовательских макросов; • формирование и редактирование пользовательских правил корреляции с помощью встроенного языка запросов напрямую из конструктора правил; • автоматическое формирование представления правила в формате встроенного языка запросов; • проверка синтаксической корректности разрабатываемых правил (формул) нормализации, агрегации, локализации, обогащения и корреляции. 2.1.8. Должна обеспечиваться валидация пользовательских правил (формул) нормализации, агрегации, локализации, обогащения и корреляции, табличных списков, макросов с проверкой их структуры, синтаксиса, корректности указанных условий и совместимости правил между собой. 2.1.9. Должна поддерживаться группировка материалов базы знаний в отдельные папки по выбору пользователя. 2.1.10. Должна обеспечиваться возможность применения правил из базы знаний, выбранных пользователем, модулем обработки событий. 2.1.11. Должны поддерживаться возможность экспорта и импорта контента базы знаний - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №3 - 2.2.1. Должна обеспечиваться возможность управления получением индикаторов компрометации из внешних источников. 2.2.2. Должно обеспечиваться периодическое обновление индикаторов компрометации из внешних баз знаний и их представление в виде репутационных списков. 2.2.3. Должна обеспечиваться возможность управления периодичностью получения данных из источников. 2.2.4. Должна обеспечиваться поддержка репутационных списков со следующими типами индикаторов компрометации: • хеш-суммами файлов; • IP-адресами; • URL; • доменными именами. 2.2.5. Должна обеспечиваться возможность настройки времени жизни (срока актуальности) индикаторов компрометации для следующих типов индикаторов: • IP-адрес; • доменное имя; • URL. 2.2.6. Должно обеспечиваться удаление индикаторов компрометации, срок актуальности которых истек - - Значение характеристики не может изменяться участником закупки

Требования к функциям (задачам), выполняемым Системой №8 - 2.3.35. Должно обеспечиваться уведомление уполномоченных пользователей об изменении статусов основных системных сущностей (активов, задач сбора данных, Системы) с их отправкой на электронную почту или по POST-запросу. 2.4. Требования к обновлению Системы 2.4.1. Должна обеспечиваться возможность автоматизированного (запускаемого в ручном режиме) обновления программного обеспечения, входящего в состав Системы, в том числе со съемных носителей информации. 2.4.2. Должна поддерживаться возможность автоматизированного обновления наборов пакетов экспертизы подсистемы «База знаний» - -

Требования к функциям (задачам), выполняемым Системой №6 - 2.3.17.2.3.26. Должна поддерживаться возможность сохранения выбранных настроек отображения в виде шаблонов. 2.3.27. Должно поддерживаться управление шаблоном, в том числе: • включением, отключением, изменением шаблона; • составом отображаемых сведений, задаваемым каждым шаблоном; • областью применения конкретного шаблона (для каких событий и пользователей применяется шаблон). 2.3.28. Должна обеспечиваться возможность экспорта информации о событиях, активах и инцидентах в следующих форматах: CSV, XLSX, JSON, XML. 2.3.29. Должна обеспечиваться возможность экспорта информации по инциденту в виде электронного документа в формате PDF. 2.3.30. Должен поддерживаться вывод сведений об отклонениях от нормального поведения, обнаруженных в рамках проведения поведенческого анализа. 2.3.31. Должна обеспечиваться возможность настройки, построения, отправки и экспорта отчетов за счет: • наличия предустановленных форм отчетов; • возможности создания пользовательских форм отчетов с помощью конструктора отчетов, позволяющего: o задать последовательность объектов отчета (текста, изображений, актуальной информации из виджетов); o задать тип визуализации данных (диаграммы, графики, гистограммы); o настроить внешний вид отчета (колонтитулы, легенду, подписи к объектам отчета). • возможности выпуска отчетов вручную или по расписанию, в том числе с отправкой на заданный адрес электронной почты; • возможности экспорта отчетов в один из следующих форматов: JSON, PDF, XML, XLSX. 2.3.32. Должно обеспечиваться отображение очереди построения отчетов. 2.3.33. Должно обеспечиваться управление очередью построения отчетов. 2.3.34. Должно обеспечиваться журналирование действий пользователей: • с карточками активов; • с записями о событиях; • с карточками инцидентов; • в части управления иерархией; • в части управления сбором данных; • в части управления контентом подсистемы «База знаний»; • в части управления Системой; • все случаи авторизации пользователей - -

Требования к функциям (задачам), выполняемым Системой №4 - 2.3. Требования к подсистеме управления и визуализации 2.3.1. Должна обеспечиваться реализация ролевой модели управления доступом к компонентам и функциям Системы. 2.3.2. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с перечнем пользователей и назначенными им правами. 2.3.3. Должна существовать роль с минимальными привилегиями (только чтение), позволяющая ознакомиться с данными Системы. 2.3.4. Должна обеспечиваться идентификация и аутентификация пользователей Системы на основе учетных записей. 2.3.5. Должен предоставляться графический веб-интерфейс, обеспечивающий: • доступ к функциям Системы на основе прав пользователей или их ролей; • информирование уполномоченных пользователей о состоянии всех компонентов, входящих в состав Системы, и работоспособности Системы; • отображение результатов работы Системы в виде текстовых и графических данных. 2.3.6. Должна обеспечиваться возможность управления учетными записями пользователей Системы: • созданием, изменением, блокированием или удалением учетных записей; • назначением и изменением логинов и паролей; • назначением ролей; • выбором методов аутентификации (локальная база или LDAP-аутентификация). 2.3.7. Должна поддерживаться возможность просмотра списка удаленных учетных записей СМСИБ. 2.3.8. Должно поддерживаться бесшовное соотнесение ролей пользователей Системы с ролями Microsoft Active Directory, ALD Pro и FreeIPA. 2.3.9. Должна поддерживаться возможность генерации паролей пользователей. 2.3.10. Должна поддерживаться возможность выполнения принудительной смены пароля при первом входе пользователя в Систему - -

Требования к функциям (задачам), выполняемым Системой №5 - 2.3.11. Должна обеспечиваться возможность управления парольной политикой, в том числе: • минимальным сроком действия пароля; • максимальным сроком действия пароля; • уведомлениями о необходимости смены пароля; • уникальностью пароля по отношению к ранее использованным (установкой запрета на использование пользователями определенного числа последних использованных паролей при создании новых паролей); • минимальной сложностью пароля (минимальной длиной пароля, максимальной длиной пароля, минимальным количеством цифр, заглавных букв, строчных букв, спецсимволов, используемых в пароле; • количеством символов, которые должны отличаться между старым паролем и новым паролем при его смене; • контролем использования учетных данных в пароле; • количеством неуспешных попыток ввода пароля; • сроком блокирования учетной записи при превышении числа неуспешных попыток ввода пароля; • временем до сброса количества попыток ввода пароля. 2.3.12. Должна обеспечиваться возможность блокирования неактивных пользователей по истечении срока, установленного уполномоченным пользователем. 2.3.13. Должен поддерживаться выпуск токенов для авторизации действий пользователей, использующих публичные API, для передачи команд в СМСИБ. 2.3.14. Должно обеспечиваться отображение результатов самодиагностики подсистем СМСИБ и оповещение пользователя о неисправностях. 2.3.15. Должна поддерживаться возможность управления нагрузкой на модули сбора данных, путем управления максимальным количеством одновременно выполняемых задач или подзадач. 2.3.16. Должна поддерживаться возможность установки политик контроля источников данных: • на основе контроля активности источника; • основе контроля потока данных для выбранного пользователем типа событий; • основе контроля задержки между появлением события на источнике и получением его модулем сбора данных - -

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Требования к подсистеме хранения данных Требования к подсистеме хранения данных: ?Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об активах, в том числе IP-адреса, доменные имена и другие изменяемые данные. ?Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах. ?Должна обеспечиваться возможность хранения исходных и обработанных событий. ?Должно обеспечиваться хранение корреляционных событий, для которых созданы карточки инцидентов. ?Должна обеспечиваться поддержка хранения данных во внешних системах хранения Класс программ для электронных вычислительных машин и баз данных (03.02) Средства управления событиями информационной безопасности Способ предоставления Экземпляр на материальном носителе - Штука - 1,00 - 6 630 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Требования к подсистеме хранения данных Требования к подсистеме хранения данных: ?Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об активах, в том числе IP-адреса, доменные имена и другие изменяемые данные. ?Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах. ?Должна обеспечиваться возможность хранения исходных и обработанных событий. ?Должно обеспечиваться хранение корреляционных событий, для которых созданы карточки инцидентов. ?Должна обеспечиваться поддержка хранения данных во внешних системах хранения Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (03.02) Средства управления событиями информационной безопасности Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Требования к подсистеме хранения данных - Требования к подсистеме хранения данных: ?Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об активах, в том числе IP-адреса, доменные имена и другие изменяемые данные. ?Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах. ?Должна обеспечиваться возможность хранения исходных и обработанных событий. ?Должно обеспечиваться хранение корреляционных событий, для которых созданы карточки инцидентов. ?Должна обеспечиваться поддержка хранения данных во внешних системах хранения - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (03.02) Средства управления событиями информационной безопасности - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Требования к подсистеме хранения данных - Требования к подсистеме хранения данных: ?Должно обеспечиваться хранение данных, содержащих выявленные в различные моменты времени сведения об активах, в том числе IP-адреса, доменные имена и другие изменяемые данные. ?Должна поддерживаться возможность периодического автоматического удаления промежуточных (неактуальных) данных об активах. ?Должна обеспечиваться возможность хранения исходных и обработанных событий. ?Должно обеспечиваться хранение корреляционных событий, для которых созданы карточки инцидентов. ?Должна обеспечиваться поддержка хранения данных во внешних системах хранения - - Значение характеристики не может изменяться участником закупки

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Общие требования Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов. Подсистема обработки данных должна поддерживать обработку до 6000 событий в секунду (EPS) Требования к подсистеме сбора данных №1 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных. 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач сбора данных. 1.5. Должна поддерживаться возможность использования протокола Kerberos для аутентификации перед сбором данных с ИТ-активов, расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.6. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач сбора данных. 1.7. Должна поддерживаться настройка запрещенного времени для выполнения задач сбора данных: на указанный интервал времени выполнение задачи должно прерываться. 1.8. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.9. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.10. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи сбора данных. 1.11. Должна поддерживаться возможность сортировки и поиска задач сбора данных по их атрибутам Требования к подсистеме сбора данных №2 1.12. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.13. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач сбора данных. 1.14. Должна поддерживаться возможность поиска профилей сбора данных. 1.15. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных. 1.16. Должны обеспечиваться возможности экспорта и импорта профилей сбора данных в файл. 1.17. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла; • обнаружение активов при анализе событий. 1.18. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименований и версий ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.19. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec pcAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP - Штука - 1,00 - 12 742 600,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Общие требования Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов. Подсистема обработки данных должна поддерживать обработку до 6000 событий в секунду (EPS) Требования к подсистеме сбора данных №1 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных. 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач сбора данных. 1.5. Должна поддерживаться возможность использования протокола Kerberos для аутентификации перед сбором данных с ИТ-активов, расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.6. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач сбора данных. 1.7. Должна поддерживаться настройка запрещенного времени для выполнения задач сбора данных: на указанный интервал времени выполнение задачи должно прерываться. 1.8. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.9. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.10. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи сбора данных. 1.11. Должна поддерживаться возможность сортировки и поиска задач сбора данных по их атрибутам Требования к подсистеме сбора данных №2 1.12. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.13. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач сбора данных. 1.14. Должна поддерживаться возможность поиска профилей сбора данных. 1.15. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных. 1.16. Должны обеспечиваться возможности экспорта и импорта профилей сбора данных в файл. 1.17. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла; • обнаружение активов при анализе событий. 1.18. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименований и версий ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.19. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec pcAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP Требования к подсистеме сбора данных №3 1.20. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.21. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.22. Должно поддерживаться подключение к выбранным активам: по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой. 1.23. Должен поддерживаться выбор способов (протоколов) подключения к активам и определения учетных записей, используемых для аутентификации. 1.24. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования рабочих станций: • идентификационных данных об активах (IP-адреса, FQDN и других); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.25. Должна обеспечиваться поддержка сбора событий от источников событий, указанных в приложении А к техническому заданию, в том числе: • пассивный (без подключения к источнику) сбор событий с использованием протоколов syslog, SNMP (Trap), Cisco NetFlow, sFlow. • активный (с подключением и выполнением команд и запросов к источнику) сбор событий с использованием поддерживаемых протоколов и механизмов: DCE/RPC (WMI), CIFS/SMB (RPC), DCOM (RPC), SSH, Telnet, OPSEC LEA, VMware API, ODBC API (MySQL protocol, PostgreSQL protocol, Tibero) Требования к подсистеме обработки данных №1 1.1. Должно обеспечиваться управление списком активов, включая: • поиск активов по их атрибутам; • группировку активов: o в статические группы, членство актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об активе (IP-адресов, ОС и т. п.). • построение иерархии групп активов; • поиск групп активов по названию. 1.2. Должен обеспечиваться контроль ключевых показателей процесса управления активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики (правила); • добавление, изменение или удаление политики (правила). 1.3. Должны реализовываться следующие политики (правила): • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, на которые действует правило; • присвоение значимости активам. 1.4. Должно обеспечиваться выполнение над активом действий, описанных в политике (правиле), при активации политики (правила). 1.5. Должно обеспечиваться возвращение состояния актива в исходное при деактивации политики (правила). 1.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки актива. 1.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об активах в результате выполнения задач сбора данных. 1.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания актива) или удаление карточки актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости актива; • задание статусов (сроков) актуальности данных Требования к подсистеме обработки данных №2 1.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значениях основных атрибутов актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.10. Должно обеспечиваться ведение истории изменения карточки актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния актива на заданный момент времени или за указанный период; • сравнения конфигураций актива в два различных момента времени. 1.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об активах; • возможность проверки сетевой доступности между активами на основе собранной Системой информации об активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.12. Должна обеспечиваться нормализация событий, получаемых от источников событий, на основе правил (формул) нормализации; в том числе должна поддерживаться нормализация событий безопасности с вложенными типами данных, имеющими разный формат (TEXT, TABULAR, JSON, XML) при обработке фрагментов событий. 1.13. Должно обеспечиваться объединение однотипных событий на основе правил агрегации. 1.14. Должно обеспечиваться обогащение событий дополнительной информацией на основе правил обогащения. 1.15. Должна обеспечиваться возможность формирования мультиязычного описания событий на основе правил локализации. 1.16. Должна обеспечиваться корреляция событий для выявления событий ИБ и событий с признаками возможных инцидентов на основе правил корреляции. 1.17. Должно обеспечиваться формирование карточек событий для нормализованных событий и событий ИБ Требования к подсистеме обработки данных №5 1.39. Должна обеспечиваться автоматическая ассоциация событий с активами (привязка). 1.40. Должна поддерживаться возможность обогащения собираемых данных сведениями о географической принадлежности IP-адресов, участвующих в сетевом взаимодействии на основе пользовательской базы данных. 1.41. Должна поддерживаться возможность присвоения корреляционным событиям категорий важности. 1.42. Должно обеспечиваться автоматическое формирование карточек инцидентов по результатам срабатывания правил корреляции (при обнаружении признаков возможного возникновения компьютерных инцидентов) или на основе срабатывания других компонентов Системы. 1.43. Должна обеспечиваться автоматическая привязка событий и активов к событиям, для которых созданы карточки инцидентов. 1.44. Должно поддерживаться управление карточками инцидентов, включая: • возможность просмотра карточки инцидента; • ручное добавление или удаление карточки инцидента или изменение данных карточки; • возможность вручную связать инцидент с событиями и активами; • возможность создания задач для пользователей Системы по расследованию, сбору доказательств и восстановлению работоспособности ИС; • возможность сохранения проведенных мероприятий и их комментирование; • хранение истории изменений карточки инцидента и выполнения поставленных задач. 1.45. Должна обеспечиваться поддержка механизмов фильтрации и сортировки карточек инцидентов, включая: • возможность сортировки и фильтрации по заданному набору атрибутов и их значениям с использованием языка запросов и (или) по группе активов; • быстрое создание фильтров путем одного клика на основных атрибутах корреляционного события в карточке инцидента; • сохранение пользовательских фильтров для быстрого доступа к интересующим карточкам инцидентов Требования к подсистеме обработки данных №4 1.30. Должна обеспечиваться возможность определения пороговых значений нагрузки, создаваемой правилами корреляции. 1.31. Должно обеспечиваться автоматическое отключение правил корреляции на основе заданных пороговых значений расходования вычислительных ресурсов при корреляции. 1.32. Должно обеспечиваться хранение и отображение информации об исходных и обработанных событиях. 1.33. Должна обеспечиваться поддержка следующих механизмов поиска и сортировки обработанных событий: • сортировка и поиск событий по заданному набору атрибутов и их значениям с использованием встроенного языка запросов; • быстрое создание фильтра путем одиночного нажатия на основных атрибутах обработанного события левой клавишей мыши; • сохранение пользовательских фильтров для быстрого доступа к интересующим событиям; • создание фильтра по связанным событиям (по типу объекта в событии; событиям ИБ и событиям с признаками инцидентов, обнаруженных при корреляции; аналогичным событиям; событиям, потенциально связанным в рамках атаки); • отображение наиболее часто используемых фильтров для быстрого поиска. Примечание — При формировании запроса на встроенном языке должна поддерживаться возможность копирования его текста. 1.34. Должна поддерживаться возможность выбора между регистрозависимым и регистронезависимым поиском по содержимому событий. 1.35. Должна обеспечиваться возможность внесения поправки во временные характеристики событий для корректировки разницы часовых поясов через профили сбора данных. 1.36. Должна обеспечиваться автоматическая коррекция времени появления событий при выявлении некорректного времени на источнике. 1.37. Должна обеспечиваться возможность выполнения ретроспективного анализа хранимых событий по новым и (или) обновленным табличным спискам, содержащим репутационные данные. 1.38. Должна обеспечиваться обработка мультиязычных событий Требования к подсистеме обработки данных №3 1.18. Должна обеспечиваться возможность многоуровневой корреляции с передачей результатов работы одного правила корреляции на вход другим правилам корреляции. 1.19. Должно обеспечиваться наличие предустановленных правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 1.20. Должна поддерживаться возможность использования в правилах обогащения и корреляции табличных списков — массивов данных, содержащих информацию следующих типов: • справочных данных о наименовании портов, протоколов и иных типов технологических данных; • данных об активах; • репутационных данных: IP-адресов, доменных имен, хеш-сумм файлов. 1.21. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе корреляции событий для использования в других правилах корреляции. 1.22. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе выполнения правил обогащения. 1.23. Должно поддерживаться ручное наполнение табличных списков пользователем через графический веб-интерфейс. 1.24. Должен поддерживаться экспорт и импорт табличных списков. 1.25. Должно обеспечиваться автоматическое удаление устаревших записей в табличных списках (для автоматически добавленных записей) с возможностью задания настраиваемого времени жизни для записей в списке при его создании. 1.26. Должно обеспечиваться наличие предустановленных табличных списков. 1.27. Должна поддерживаться возможность включения журналирования следующих операций с табличными списками: • добавление записей в табличный список правилом корреляции; • операции с табличным списком, выполняемые оператором. 1.28. Должно обеспечиваться срабатывание правил корреляции и создание события ИБ при возникновении журналируемого события работы с табличными списками. 1.29. Должна обеспечиваться возможность запуска и остановки работы правил обогащения и корреляции Класс программ для электронных вычислительных машин и баз данных (03.02) Средства управления событиями информационной безопасности Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Общие требования - Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов. Подсистема обработки данных должна поддерживать обработку до 6000 событий в секунду (EPS) - - - Требования к подсистеме сбора данных №1 - 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных. 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач сбора данных. 1.5. Должна поддерживаться возможность использования протокола Kerberos для аутентификации перед сбором данных с ИТ-активов, расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.6. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач сбора данных. 1.7. Должна поддерживаться настройка запрещенного времени для выполнения задач сбора данных: на указанный интервал времени выполнение задачи должно прерываться. 1.8. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.9. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.10. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи сбора данных. 1.11. Должна поддерживаться возможность сортировки и поиска задач сбора данных по их атрибутам - - - Требования к подсистеме сбора данных №2 - 1.12. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.13. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач сбора данных. 1.14. Должна поддерживаться возможность поиска профилей сбора данных. 1.15. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных. 1.16. Должны обеспечиваться возможности экспорта и импорта профилей сбора данных в файл. 1.17. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла; • обнаружение активов при анализе событий. 1.18. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименований и версий ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.19. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec pcAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP - - - Требования к подсистеме сбора данных №3 - 1.20. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.21. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.22. Должно поддерживаться подключение к выбранным активам: по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой. 1.23. Должен поддерживаться выбор способов (протоколов) подключения к активам и определения учетных записей, используемых для аутентификации. 1.24. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования рабочих станций: • идентификационных данных об активах (IP-адреса, FQDN и других); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.25. Должна обеспечиваться поддержка сбора событий от источников событий, указанных в приложении А к техническому заданию, в том числе: • пассивный (без подключения к источнику) сбор событий с использованием протоколов syslog, SNMP (Trap), Cisco NetFlow, sFlow. • активный (с подключением и выполнением команд и запросов к источнику) сбор событий с использованием поддерживаемых протоколов и механизмов: DCE/RPC (WMI), CIFS/SMB (RPC), DCOM (RPC), SSH, Telnet, OPSEC LEA, VMware API, ODBC API (MySQL protocol, PostgreSQL protocol, Tibero) - - - Требования к подсистеме обработки данных №1 - 1.1. Должно обеспечиваться управление списком активов, включая: • поиск активов по их атрибутам; • группировку активов: o в статические группы, членство актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об активе (IP-адресов, ОС и т. п.). • построение иерархии групп активов; • поиск групп активов по названию. 1.2. Должен обеспечиваться контроль ключевых показателей процесса управления активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики (правила); • добавление, изменение или удаление политики (правила). 1.3. Должны реализовываться следующие политики (правила): • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, на которые действует правило; • присвоение значимости активам. 1.4. Должно обеспечиваться выполнение над активом действий, описанных в политике (правиле), при активации политики (правила). 1.5. Должно обеспечиваться возвращение состояния актива в исходное при деактивации политики (правила). 1.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки актива. 1.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об активах в результате выполнения задач сбора данных. 1.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания актива) или удаление карточки актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости актива; • задание статусов (сроков) актуальности данных - - - Требования к подсистеме обработки данных №2 - 1.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значениях основных атрибутов актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.10. Должно обеспечиваться ведение истории изменения карточки актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния актива на заданный момент времени или за указанный период; • сравнения конфигураций актива в два различных момента времени. 1.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об активах; • возможность проверки сетевой доступности между активами на основе собранной Системой информации об активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.12. Должна обеспечиваться нормализация событий, получаемых от источников событий, на основе правил (формул) нормализации; в том числе должна поддерживаться нормализация событий безопасности с вложенными типами данных, имеющими разный формат (TEXT, TABULAR, JSON, XML) при обработке фрагментов событий. 1.13. Должно обеспечиваться объединение однотипных событий на основе правил агрегации. 1.14. Должно обеспечиваться обогащение событий дополнительной информацией на основе правил обогащения. 1.15. Должна обеспечиваться возможность формирования мультиязычного описания событий на основе правил локализации. 1.16. Должна обеспечиваться корреляция событий для выявления событий ИБ и событий с признаками возможных инцидентов на основе правил корреляции. 1.17. Должно обеспечиваться формирование карточек событий для нормализованных событий и событий ИБ - - - Требования к подсистеме обработки данных №5 - 1.39. Должна обеспечиваться автоматическая ассоциация событий с активами (привязка). 1.40. Должна поддерживаться возможность обогащения собираемых данных сведениями о географической принадлежности IP-адресов, участвующих в сетевом взаимодействии на основе пользовательской базы данных. 1.41. Должна поддерживаться возможность присвоения корреляционным событиям категорий важности. 1.42. Должно обеспечиваться автоматическое формирование карточек инцидентов по результатам срабатывания правил корреляции (при обнаружении признаков возможного возникновения компьютерных инцидентов) или на основе срабатывания других компонентов Системы. 1.43. Должна обеспечиваться автоматическая привязка событий и активов к событиям, для которых созданы карточки инцидентов. 1.44. Должно поддерживаться управление карточками инцидентов, включая: • возможность просмотра карточки инцидента; • ручное добавление или удаление карточки инцидента или изменение данных карточки; • возможность вручную связать инцидент с событиями и активами; • возможность создания задач для пользователей Системы по расследованию, сбору доказательств и восстановлению работоспособности ИС; • возможность сохранения проведенных мероприятий и их комментирование; • хранение истории изменений карточки инцидента и выполнения поставленных задач. 1.45. Должна обеспечиваться поддержка механизмов фильтрации и сортировки карточек инцидентов, включая: • возможность сортировки и фильтрации по заданному набору атрибутов и их значениям с использованием языка запросов и (или) по группе активов; • быстрое создание фильтров путем одного клика на основных атрибутах корреляционного события в карточке инцидента; • сохранение пользовательских фильтров для быстрого доступа к интересующим карточкам инцидентов - - - Требования к подсистеме обработки данных №4 - 1.30. Должна обеспечиваться возможность определения пороговых значений нагрузки, создаваемой правилами корреляции. 1.31. Должно обеспечиваться автоматическое отключение правил корреляции на основе заданных пороговых значений расходования вычислительных ресурсов при корреляции. 1.32. Должно обеспечиваться хранение и отображение информации об исходных и обработанных событиях. 1.33. Должна обеспечиваться поддержка следующих механизмов поиска и сортировки обработанных событий: • сортировка и поиск событий по заданному набору атрибутов и их значениям с использованием встроенного языка запросов; • быстрое создание фильтра путем одиночного нажатия на основных атрибутах обработанного события левой клавишей мыши; • сохранение пользовательских фильтров для быстрого доступа к интересующим событиям; • создание фильтра по связанным событиям (по типу объекта в событии; событиям ИБ и событиям с признаками инцидентов, обнаруженных при корреляции; аналогичным событиям; событиям, потенциально связанным в рамках атаки); • отображение наиболее часто используемых фильтров для быстрого поиска. Примечание — При формировании запроса на встроенном языке должна поддерживаться возможность копирования его текста. 1.34. Должна поддерживаться возможность выбора между регистрозависимым и регистронезависимым поиском по содержимому событий. 1.35. Должна обеспечиваться возможность внесения поправки во временные характеристики событий для корректировки разницы часовых поясов через профили сбора данных. 1.36. Должна обеспечиваться автоматическая коррекция времени появления событий при выявлении некорректного времени на источнике. 1.37. Должна обеспечиваться возможность выполнения ретроспективного анализа хранимых событий по новым и (или) обновленным табличным спискам, содержащим репутационные данные. 1.38. Должна обеспечиваться обработка мультиязычных событий - - - Требования к подсистеме обработки данных №3 - 1.18. Должна обеспечиваться возможность многоуровневой корреляции с передачей результатов работы одного правила корреляции на вход другим правилам корреляции. 1.19. Должно обеспечиваться наличие предустановленных правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 1.20. Должна поддерживаться возможность использования в правилах обогащения и корреляции табличных списков — массивов данных, содержащих информацию следующих типов: • справочных данных о наименовании портов, протоколов и иных типов технологических данных; • данных об активах; • репутационных данных: IP-адресов, доменных имен, хеш-сумм файлов. 1.21. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе корреляции событий для использования в других правилах корреляции. 1.22. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе выполнения правил обогащения. 1.23. Должно поддерживаться ручное наполнение табличных списков пользователем через графический веб-интерфейс. 1.24. Должен поддерживаться экспорт и импорт табличных списков. 1.25. Должно обеспечиваться автоматическое удаление устаревших записей в табличных списках (для автоматически добавленных записей) с возможностью задания настраиваемого времени жизни для записей в списке при его создании. 1.26. Должно обеспечиваться наличие предустановленных табличных списков. 1.27. Должна поддерживаться возможность включения журналирования следующих операций с табличными списками: • добавление записей в табличный список правилом корреляции; • операции с табличным списком, выполняемые оператором. 1.28. Должно обеспечиваться срабатывание правил корреляции и создание события ИБ при возникновении журналируемого события работы с табличными списками. 1.29. Должна обеспечиваться возможность запуска и остановки работы правил обогащения и корреляции - - - Класс программ для электронных вычислительных машин и баз данных - (03.02) Средства управления событиями информационной безопасности - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

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

Общие требования - Подсистемы сбора и обработки данных должны поддерживать не менее 2000 активов. Подсистема обработки данных должна поддерживать обработку до 6000 событий в секунду (EPS) - -

Требования к подсистеме сбора данных №1 - 1.1. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Linux должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.2. При размещении модуля сбора данных на технических средствах под управлением ОС семейства Windows должен поддерживаться сбор данных с ИТ активов расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.3. Должна обеспечиваться возможность сбора данных на основе задач, использующих шаблоны (профили) сбора данных. 1.4. Должна обеспечиваться возможность создания, изменения, удаления, запуска и приостановки задач сбора данных. 1.5. Должна поддерживаться возможность использования протокола Kerberos для аутентификации перед сбором данных с ИТ-активов, расположенных на технических средствах под управлением ОС семейств Windows и Linux. 1.6. Должен поддерживаться список исключений — перечень сетевых узлов, на которых запрещено выполнение задач сбора данных. 1.7. Должна поддерживаться настройка запрещенного времени для выполнения задач сбора данных: на указанный интервал времени выполнение задачи должно прерываться. 1.8. Должна поддерживаться возможность запуска задач на основе расписания, задаваемого через графический веб-интерфейс или в виде строки Crontab. 1.9. Должна поддерживаться возможность создания задач для нескольких выбранных модулей сбора данных (с автоматическим созданием и распределением подзадач). 1.10. Должна поддерживаться возможность просмотра перечня подзадач для конкретной задачи сбора данных. 1.11. Должна поддерживаться возможность сортировки и поиска задач сбора данных по их атрибутам - -

Требования к подсистеме сбора данных №2 - 1.12. Должна обеспечиваться возможность создавать, изменять, удалять шаблоны (профили) сбора данных, определяющие протоколы и способы сбора данных от источников данных. 1.13. Должна поддерживаться возможность экспорта и импорта результатов выполнения задач сбора данных. 1.14. Должна поддерживаться возможность поиска профилей сбора данных. 1.15. Должна обеспечиваться возможность создания, изменения, удаления учетных записей, необходимых для авторизации на источниках данных. 1.16. Должны обеспечиваться возможности экспорта и импорта профилей сбора данных в файл. 1.17. Должны обеспечиваться следующие методы добавления активов: • сканирование сети с выявлением и идентификацией активов, включенных и подключенных к локальным вычислительным сетям с использованием стека TCP/IP; • добавление активов в ручном режиме; • импорт активов из CSV-файла; • обнаружение активов при анализе событий. 1.18. При сетевом сканировании должен обеспечиваться сбор следующих данных: • сведений об активах (сетевых узлах ИС) в области, заданной пользователем по IP адресам (подсетям), именам или внутрисистемным идентификаторам активов с возможностью ограничения или выбора числа портов и протоколов транспортного уровня, используемых при сканировании; • инвентаризационной информации активов (идентификация доступных сетевых служб и ПО), в том числе: o наименований и версий ОС семейства Microsoft Windows; o сетевых служб, использующих транспортные протоколы TCP и UDP. 1.19. При сетевом сканировании должен поддерживаться сбор сведений об уязвимых учетных данных (слабых парах «логин — пароль»), получаемых путем подбора с использованием справочников по протоколам: • электронной почты — SMTP, POP3; • файловых служб — FTP; • удаленного управления — RDP, SSH, Telnet, SNMP, VNC, Radmin, Symantec pcAnywhere, NetBIOS; • баз данных — Microsoft SQL, Oracle DB, Sybase, DB2, MySQL, PostgreSQL; • бизнес-приложений — SAP DIAG, SAP RFC; • сред виртуализации — VMware vSphere; • IP-телефонии — SIP - -

Требования к подсистеме сбора данных №3 - 1.20. Должны поддерживаться следующие виды справочников для сетевого сканирования: • базовые заполненные справочники с парами «логин — пароль»; • пользовательские справочники для хранения пар «логин — пароль», справочники с логинами, справочники с паролями. 1.21. Должна поддерживаться возможность создания, изменения или удаления пользовательских справочников. 1.22. Должно поддерживаться подключение к выбранным активам: по IP-адресам (подсетям), FQDN-именам или иным идентификаторам активов, используемым Системой. 1.23. Должен поддерживаться выбор способов (протоколов) подключения к активам и определения учетных записей, используемых для аутентификации. 1.24. Должен обеспечиваться сбор инвентаризационной и конфигурационной информации путем сканирования рабочих станций: • идентификационных данных об активах (IP-адреса, FQDN и других); • данных о составе аппаратного обеспечения (материнская плата, центральный процессор, сетевая карта и другие); • данных о составе программного обеспечения (BIOS, ОС, системное ПО и другие); • данных о настройках ОС семейства Windows (локальные и доменные политики); • данных о запущенных службах и задачах планировщика ОС. 1.25. Должна обеспечиваться поддержка сбора событий от источников событий, указанных в приложении А к техническому заданию, в том числе: • пассивный (без подключения к источнику) сбор событий с использованием протоколов syslog, SNMP (Trap), Cisco NetFlow, sFlow. • активный (с подключением и выполнением команд и запросов к источнику) сбор событий с использованием поддерживаемых протоколов и механизмов: DCE/RPC (WMI), CIFS/SMB (RPC), DCOM (RPC), SSH, Telnet, OPSEC LEA, VMware API, ODBC API (MySQL protocol, PostgreSQL protocol, Tibero) - -

Требования к подсистеме обработки данных №1 - 1.1. Должно обеспечиваться управление списком активов, включая: • поиск активов по их атрибутам; • группировку активов: o в статические группы, членство актива в которых определяется пользователем; o динамические группы, членство в которых определяется Системой автоматически на основе информации об активе (IP-адресов, ОС и т. п.). • построение иерархии групп активов; • поиск групп активов по названию. 1.2. Должен обеспечиваться контроль ключевых показателей процесса управления активами путем реализации настраиваемых политик и (или) правил, включая: • активацию или деактивацию политики (правила); • добавление, изменение или удаление политики (правила). 1.3. Должны реализовываться следующие политики (правила): • определение и (или) изменение сроков актуальности и устаревания данных об активе; • определение перечня активов, на которые действует правило; • присвоение значимости активам. 1.4. Должно обеспечиваться выполнение над активом действий, описанных в политике (правиле), при активации политики (правила). 1.5. Должно обеспечиваться возвращение состояния актива в исходное при деактивации политики (правила). 1.6. Должно обеспечиваться отображение собранной конфигурационной информации об активе в виде карточки актива. 1.7. Должно обеспечиваться автоматическое изменение инвентаризационной и конфигурационной информации об активах в результате выполнения задач сбора данных. 1.8. Должно обеспечиваться управление карточками активов, включая: • ручное добавление, изменение (в том числе добавление пользовательских полей описания актива) или удаление карточки актива; • отображение даты и времени последнего обновления информации об активе; • задание уровня значимости актива; • задание статусов (сроков) актуальности данных - -

Требования к подсистеме обработки данных №2 - 1.9. Должна обеспечиваться поддержка следующих механизмов фильтрации и сортировки карточек активов: • сортировка и фильтрация перечня активов по заданному набору атрибутов и их значениям; • быстрое создание группы фильтрации путем одиночного нажатия левой клавиши мыши на значениях основных атрибутов актива; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.10. Должно обеспечиваться ведение истории изменения карточки актива с отображением истории изменения карточек активов с возможностью: • просмотра состояния актива на заданный момент времени или за указанный период; • сравнения конфигураций актива в два различных момента времени. 1.11. Должна обеспечиваться поддержка работы с топологией сети, включая: • построение и визуализацию топологии сети на уровне L3 модели OSI на основе собранной Системой информации об активах; • возможность проверки сетевой доступности между активами на основе собранной Системой информации об активах; • возможность отображения активов, удовлетворяющих условиям заданного фильтра. 1.12. Должна обеспечиваться нормализация событий, получаемых от источников событий, на основе правил (формул) нормализации; в том числе должна поддерживаться нормализация событий безопасности с вложенными типами данных, имеющими разный формат (TEXT, TABULAR, JSON, XML) при обработке фрагментов событий. 1.13. Должно обеспечиваться объединение однотипных событий на основе правил агрегации. 1.14. Должно обеспечиваться обогащение событий дополнительной информацией на основе правил обогащения. 1.15. Должна обеспечиваться возможность формирования мультиязычного описания событий на основе правил локализации. 1.16. Должна обеспечиваться корреляция событий для выявления событий ИБ и событий с признаками возможных инцидентов на основе правил корреляции. 1.17. Должно обеспечиваться формирование карточек событий для нормализованных событий и событий ИБ - -

Требования к подсистеме обработки данных №5 - 1.39. Должна обеспечиваться автоматическая ассоциация событий с активами (привязка). 1.40. Должна поддерживаться возможность обогащения собираемых данных сведениями о географической принадлежности IP-адресов, участвующих в сетевом взаимодействии на основе пользовательской базы данных. 1.41. Должна поддерживаться возможность присвоения корреляционным событиям категорий важности. 1.42. Должно обеспечиваться автоматическое формирование карточек инцидентов по результатам срабатывания правил корреляции (при обнаружении признаков возможного возникновения компьютерных инцидентов) или на основе срабатывания других компонентов Системы. 1.43. Должна обеспечиваться автоматическая привязка событий и активов к событиям, для которых созданы карточки инцидентов. 1.44. Должно поддерживаться управление карточками инцидентов, включая: • возможность просмотра карточки инцидента; • ручное добавление или удаление карточки инцидента или изменение данных карточки; • возможность вручную связать инцидент с событиями и активами; • возможность создания задач для пользователей Системы по расследованию, сбору доказательств и восстановлению работоспособности ИС; • возможность сохранения проведенных мероприятий и их комментирование; • хранение истории изменений карточки инцидента и выполнения поставленных задач. 1.45. Должна обеспечиваться поддержка механизмов фильтрации и сортировки карточек инцидентов, включая: • возможность сортировки и фильтрации по заданному набору атрибутов и их значениям с использованием языка запросов и (или) по группе активов; • быстрое создание фильтров путем одного клика на основных атрибутах корреляционного события в карточке инцидента; • сохранение пользовательских фильтров для быстрого доступа к интересующим карточкам инцидентов - -

Требования к подсистеме обработки данных №4 - 1.30. Должна обеспечиваться возможность определения пороговых значений нагрузки, создаваемой правилами корреляции. 1.31. Должно обеспечиваться автоматическое отключение правил корреляции на основе заданных пороговых значений расходования вычислительных ресурсов при корреляции. 1.32. Должно обеспечиваться хранение и отображение информации об исходных и обработанных событиях. 1.33. Должна обеспечиваться поддержка следующих механизмов поиска и сортировки обработанных событий: • сортировка и поиск событий по заданному набору атрибутов и их значениям с использованием встроенного языка запросов; • быстрое создание фильтра путем одиночного нажатия на основных атрибутах обработанного события левой клавишей мыши; • сохранение пользовательских фильтров для быстрого доступа к интересующим событиям; • создание фильтра по связанным событиям (по типу объекта в событии; событиям ИБ и событиям с признаками инцидентов, обнаруженных при корреляции; аналогичным событиям; событиям, потенциально связанным в рамках атаки); • отображение наиболее часто используемых фильтров для быстрого поиска. Примечание — При формировании запроса на встроенном языке должна поддерживаться возможность копирования его текста. 1.34. Должна поддерживаться возможность выбора между регистрозависимым и регистронезависимым поиском по содержимому событий. 1.35. Должна обеспечиваться возможность внесения поправки во временные характеристики событий для корректировки разницы часовых поясов через профили сбора данных. 1.36. Должна обеспечиваться автоматическая коррекция времени появления событий при выявлении некорректного времени на источнике. 1.37. Должна обеспечиваться возможность выполнения ретроспективного анализа хранимых событий по новым и (или) обновленным табличным спискам, содержащим репутационные данные. 1.38. Должна обеспечиваться обработка мультиязычных событий - -

Требования к подсистеме обработки данных №3 - 1.18. Должна обеспечиваться возможность многоуровневой корреляции с передачей результатов работы одного правила корреляции на вход другим правилам корреляции. 1.19. Должно обеспечиваться наличие предустановленных правил (формул) нормализации, агрегации, обогащения, локализации и корреляции. 1.20. Должна поддерживаться возможность использования в правилах обогащения и корреляции табличных списков — массивов данных, содержащих информацию следующих типов: • справочных данных о наименовании портов, протоколов и иных типов технологических данных; • данных об активах; • репутационных данных: IP-адресов, доменных имен, хеш-сумм файлов. 1.21. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе корреляции событий для использования в других правилах корреляции. 1.22. Должно обеспечиваться автоматическое наполнение табличных списков информацией в ходе выполнения правил обогащения. 1.23. Должно поддерживаться ручное наполнение табличных списков пользователем через графический веб-интерфейс. 1.24. Должен поддерживаться экспорт и импорт табличных списков. 1.25. Должно обеспечиваться автоматическое удаление устаревших записей в табличных списках (для автоматически добавленных записей) с возможностью задания настраиваемого времени жизни для записей в списке при его создании. 1.26. Должно обеспечиваться наличие предустановленных табличных списков. 1.27. Должна поддерживаться возможность включения журналирования следующих операций с табличными списками: • добавление записей в табличный список правилом корреляции; • операции с табличным списком, выполняемые оператором. 1.28. Должно обеспечиваться срабатывание правил корреляции и создание события ИБ при возникновении журналируемого события работы с табличными списками. 1.29. Должна обеспечиваться возможность запуска и остановки работы правил обогащения и корреляции - -

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

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

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Согласно 117 приказа ФСТЭК пункт 23. 23. Структурным подразделением (специалистами) по защите информации должны применяться программные, программно-аппаратные средства, позволяющие обеспечить выполнение возложенных на них обязанностей (функций) по защите информации, в том числе по выявлению угроз безопасности информации, обнаружению и предотвращению вторжений, проведению контроля уровня защищенности информации, содержащейся в информационных системах, мониторингу информационной безопасности информационных систем, выявлению уязвимостей, контролю настроек и конфигураций информационных систем, а также средства и системы, предназначенные для автоматизации и аналитической поддержки деятельности по защите информации.

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

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

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

Обеспечение заявки

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

Размер обеспечения заявки: 511 936,36 РОССИЙСКИЙ РУБЛЬ

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: В случае предоставления обеспечения заявки на участие в закупке в виде денежных средств подача заявки на участие в закупке означает согласие участника закупки на блокирование денежных средств, находящихся на его специальном счете, в размере обеспечения заявки на участие в закупке, в порядке, установленном ст. 44 Федерального закона №44-ФЗ. Предоставление обеспечения заявки на участие в закупке в виде денежных средств участниками закупок, являющимися иностранными лицами, осуществляется с учетом особенностей, предусмотренных постановлением Правительства РФ от 10.04.2023 №579 "Об особенностях порядка предоставления обеспечения заявок на участие в закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд участниками таких закупок, являющимися иностранными лицами". В случае выбора независимой гарантии в качестве способа обеспечения заявки, бенефициаром в данной независимой гарантии должен выступать заказчик, сведения о котором указаны в настоящем извещении об осуществлении закупки. Срок действия независимой гарантии должен составлять не менее месяца с даты окончания срока подачи заявок. Условия независимой гарантии должны соответствовать требованиям ст. 45 Федерального закона №44-ФЗ, а также дополнительным требованиям, установленным постановлением Правительства РФ от 08.11.2013 № 1005. Независимая гарантия, информация о ней и документы, предусмотренные ч.9 ст.45 Федерального закона №44-ФЗ, должны быть включены в реестр независимых гарантий.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03224643210000008201, БИК 042157901

Условия контракта

Номер типовых условий контракта: 1400700000520009

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

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Обеспечение исполнения контракта

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

Размер обеспечения исполнения контракта: 511 936,36 ? (1 %)

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Исполнение контракта может обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Федерального закона от 5 апреля 2013 г. N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд", или внесением денежных средств на указанный Заказчиком счет на сумму, эквивалентную 1% проценту начальной (максимальной) цены контракта (в случае, если участником закупки, с которым заключается контракт, предложена цена контракта, которая на двадцать пять и более процентов ниже начальной (максимальной) цены контракта, размер обеспечения исполнения контракта определяется с учетом требований ст.37 Федерального закона от 5 апреля 2013 г. N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд").В случае, если Поставщиком в качестве способа обеспечения исполнения контракта избрано предоставление независимой гарантии, срок действия независимой гарантии определяются в соответствии с требованиями Федерального закона от 5 апреля 2013 г. N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд" Поставщиком самостоятельно. При этом срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на один месяц, в том числе в случае его изменения в соответствии со статьей 95 Федерального закона от 5 апреля 2013 г. N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд".

Платежные реквизиты для обеспечения исполнения контракта: p/c 03224643210000008201, БИК 042157901

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

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

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

Информация о требованиях к гарантийному обслуживанию товара: Да

Требования к гарантии производителя товара:

Обеспечение гарантийных обязательств

Требуется обеспечение гарантийных обязательств: Да

Размер обеспечения гарантийных обязательств: 511 936,36 Российский рубль

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

Платежные реквизиты для обеспечения гарантийных обязательств: p/c 03224643210000008201, БИК 042157901, УФК по Донецкой Народной Республике

Информация о банковском и (или) казначейском сопровождении контракта

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

Документы

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

Документы

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