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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почтовый адрес: Российская Федерация, 640003, Курганская обл, Курган г, УЛ Р. ЗОРГЕ, ДОМ 20, ОФ.1

Место нахождения: Российская Федерация, 640003, Курганская обл, Курган г, УЛ РИХАРДА ЗОРГЕ, ОФИС 1, ДОМ 20

Ответственное должностное лицо: Носова Я. В.

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

Номер контактного телефона: 7-3522-429307

Факс: 7-3522-429305

Дополнительная информация: Администрация города Кургана. Место нахождения: Российская Федерация, 640002, Курганская обл, Курган г, имени В.И. Ленина пл, имени В.И. Ленина пл, Д. 1. Почтовый адрес:Российская Федерация, 640002, Курганская обл, Курган г, имени В.И. Ленина пл, Д. 1. Телефон: 8-3522-428803. Адрес электронной почты: mail@kurgan-city.ru Ответственное лицо: Валуев Павел Александрович,Адрес электронной почты организации заказчика: shamshova@kurgan-city.ru, Телефон организации заказчика: 7-35222-428805

Регион: Курганская обл

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

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

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

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

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

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

Начальная (максимальная) цена контракта: 2 281 400,00

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

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

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

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

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

АДМИНИСТРАЦИЯ ГОРОДА КУРГАНА - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Класс программ для электронных вычислительных машин и баз данных (03.02) Средства управления событиями информационной безопасности Значение характеристики не может изменяться участником закупки Способ предоставления Копия электронного экземпляра Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Общие требования к системе СУС ИБ СУС ИБ должна строиться как единая система с иерархической функциональной структурой и централизованным пунктом управления и являться составной частью информационно-телекоммуникационной системы Заказчика. Значение характеристики не может изменяться участником закупки СУС ИБ должна иметь микросервисную архитектуру, обеспечивающую перенос части функции СУС ИБ на отдельные сервера, выполняющие функции: - приема событий; - нормализации событий; - корреляции событий; - хранения событий. СУС ИБ должна обеспечивать решение следующих общих задач: - сбор, обработка, отображение и долгосрочное хранение информации о событиях и подозрениях на инциденты информационной безопасности, выявляемых в инфраструктуре Заказчика; - предоставление инструментов для анализа событий и расследования инцидентов информационной безопасности, в том числе, масштабных инцидентов ИБ, затрагивающие несколько территориальных подразделений; - предоставление исходной информации для определения влияния события или подозрения на инцидент ИБ на ИТ-сервисы. СУС ИБ должна удовлетворять следующим общим требованиям: - масштабируемость – способность справляться с увеличением рабочей нагрузки на СУС ИБ путем наращивания числа функциональных блоков, выполняющих одни и те же задачи (горизонтальное масштабирование); - вертикальная масштабируемость – возможность увеличения ресурсов на выделенных серверах. - работоспособность – состояние системы, при котором она способна выполнять заданные функции с параметрами, установленными требованиями технической документации. - отказоустойчивость – свойство системы непрерывно сохранять работоспособность в течение некоторого времени. СУС ИБ должна поставляться в отказоустойчивой конфигурации (кластере) для обеспечения функционирования в случае сбоев оборудования или ПО. - унификация – использование типовых проектных решений, обеспечение возможности использования таких решений. - информационная безопасность – обеспечение конфиденциальности, целостности и доступности хранящейся и обрабатываемой СУС ИБ информации. СУС ИБ должна обеспечивать функционирование в следующих режимах: - штатный режим – режим функционирования СУС ИБ, при котором обеспечивается выполнение функциональных возможностей системы в объеме, соответствующем текущему этапу реализации; - автономный режим – режим, характеризующийся ограничением возможностей контроля. В этом случае сохраняется основной функционал СУС ИБ за исключением функции консолидации информации; - аварийный режим – режим функционирования системы в случае сбоя (ев)/отказа(ов) одного или нескольких компонентов СУС ИБ. В аварийном режиме должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ; - сервисный режим – режим функционирования системы при проведении работ по обслуживанию инфраструктуры СУС ИБ (виртуальной или аппаратной) и обновлению ее компонентов. Сервисный режим должен обеспечивать реализацию основных функций СУС ИБ, за исключением работ, требующих временной приостановки работы компонента(ов) СУС ИБ. Нарушение штатной работы, включая перерывы и выход за установленные пределы параметров электропитания на время не более 30 минут не должны приводить к: - появлению ложных сигналов управления; - потере информации, важной для работы системы управления. В СУС ИБ должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ путем резервного копирования и восстановления данных и программного обеспечения. Для этого информационные ресурсы СУС ИБ должны включаться в контур существующих систем резервного копирования. Все серверные компоненты СУС ИБ должна строится на базе Linux подобных систем и не требовать приобретения дополнительных лицензий. По окончании действия услуг технической поддержки СУС ИБ система должна сохранять полную работоспособность. Мониторинг и анализ событий информационной безопасности от контролируемых ресурсов ИТС не должен оказывать отрицательного воздействия с точки зрения скорости исполнения обычных процессов функциональной деятельности подразделений Заказчика. Требования к структуре СУС ИБ В СУС ИБ должны быть реализованы следующие функциональные подсистемы: - Подсистема сбора и обработки событий ИБ; - Подсистема хранения событий ИБ; - Подсистема корреляции событий ИБ; - Подсистема поиска событий и подозрений на инциденты ИБ; - Подсистема регистрации инцидентов; - Подсистема обеспечение информационной безопасности самой системы; - Подсистемы управления. Значение характеристики не может изменяться участником закупки Требования к функционированию СУС ИБ СУС ИБ должна обеспечить выполнение следующих функций: - консолидация и хранение информации о инцидентах ИБ, регистрируемых Системой с целью выявления подозрений на инциденты ИБ; - анализ информации о подозрениях на инциденты ИБ с целью их подтверждения и назначения для последующего реагирования; - сбор и систематизация данных для проведения специалистами по ИБ последующего анализа причин и источников инцидентов информационной безопасности для определения корректирующих действий по снижению вероятности наступления аналогичных инцидентов информационной безопасности в будущем; - обобщенное представление информации о выявленных в ИТС подозрениях на инциденты ИБ на единой консоли СУС ИБ; - уведомление ответственных сотрудников ИБ об обнаружении инцидентов/подозрений на инцидент; - администрирование компонентов СУС ИБ; - мониторинг состояния, устранение сбоев и отказов компонентов СУС ИБ; - поддержка иерархической структуры с назначением головной и подчиненных площадок СУС ИБ. Значение характеристики не может изменяться участником закупки Требования к функциональным подсистемам Реализация функциональных подсистем должна учитывать иерархическую структуру СУС ИБ в целом. Проектные решения по созданию СУС ИБ должны предусматривать возможность поэтапного внедрения и интегрирования функциональных подсистем. Решения по обеспечению информационного взаимодействия между функциональными уровнями и подсистемами СУС ИБ, а также с объектами контроля не должны предусматривать создания дублирующих по отношению к уже созданным сетевых и телекоммуникационных инфраструктур. Значение характеристики не может изменяться участником закупки Подсистема корреляции событий ИБ должна обеспечивать реализацию следующего набора типовых действий: - создание корреляций по историческим данным (хранящимся в системе) с использованием всех доступных функций корреляции; - историческая корреляция должна иметь функционал ручного и автоматического запуска; - создание и корректировка правил корреляции событий ИБ в графическом конструкторе без знания языков программирования; - установка приоритета инцидента, регистрируемого в результате срабатывания правила корреляции; - установки зоны видимости инцидента на основе ролевой модели применительно к каждому правилу корреляции; - возможность использования в правилах корреляции изменяемых пользователем статических списков; - возможность использования в правилах корреляции динамических списков; - возможность использования в правилах корреляции динамических таблиц; - установка временных ограничительных параметров срабатывания правила корреляции; - приоритезация выявленных подозрений на инциденты ИБ с учетом критичности событий ИБ, вызвавших данный инцидент и критичности ресурсов, затронутых им; - автоматические механизмы поиска событий и подозрений на инциденты ИБ по заданным критериям и значениям полей событий без создания правил корреляции для каждого конкретного типа инцидентов; Подсистема регистрации инцидентов безопасности СУС ИБ должна быть выполнена в виде единого решения с остальными подсистемами в единой консоли управления. Информация об источнике события должна быть представлена в формате IPv4 и IPv6-адресации, либо в формате DNS-hostname. Информация о внешних IP адресах должна быть также представлена в виде геопозиционных меток (страна, город, координаты местонахождения). Дополнительные поля таксономии могут содержать информацию о протоколах прикладного уровня, MAC-адресах, DNS-адресах, файловых доступах, различные переменные и т.д. Должна допускаться возможность расширения схемы полей таксономии администраторами СУС ИБ. Подсистема корреляции событий ИБ должна обеспечивать корреляцию: - по отдельным событиям; - по количеству событий за интервал времени; - по количеству уникальных значений за интервал времени; - по последовательности действий. Подсистема сбора и обработки событий ИБ должна обеспечивать реализацию следующего набора типовых действий: 1. сбор и обработка не менее 2000 событий в секунду; 2. автоматизированный сбор и нормализация событий ИБ, включая: 2.1. присвоение событиям категорий в соответствии с типом зарегистрированного события; 2.2. присвоение событию степени критичности, управляемой администраторами СУС ИБ; 2.3. приведение событий ИБ к единому формату СУС ИБ; 2.4. обогащение событий из активов, статических и динамических таблиц (запись пользовательских значений в любое поле события) на основании пользовательских правил; 2.5. сохранение исходного события и нормализованного. 2.6. нормализация объединенного потока событий от различных источников; 3. передача информации о событиях ИБ в подсистему управления инцидентами ИБ, подсистему хранения событий ИБ; 4. поддержка передачи событий в другие системы; 5. возможность передачи событий в нормализованном и сыром формате, в том числе по заданному условию; 6. события должны содержать как минимум следующую информацию: 6.1. дата и время возникновения события; 6.2. источник (IP-адрес или сетевое имя); 6.3. уникальный идентификатор события; 6.3. тип (категория) события; 6.4. описание события; 6.7. критичность (приоритет) события; 6.8. время получения события от источника; 6.9. дополнительные поля. Подсистема сбора должна иметь унифицированные транспорты для сбора событий и допускать подключение новых источников администраторами СУС ИБ без привлечения сторонних организаций и разработчиков. Подсистема должна обеспечивать мониторинг syslog источников. Подсистема должна обеспечивать возможность разработки правил нормализации событий для существующих полей таксономии с использованием встроенного инструментария и не требовать привлечения разработчиков. Подсистема сбора должна автоматически применять соответствующие формулы нормализации, без необходимости настройки типа источника или вендора в СУС ИБ. Подсистема должна гарантировать кэширование событий на агенте, при потере связи с центральным компонентом СУС ИБ. Подсистема должна обеспечивать автоматическую однопоточную и многопоточную архивацию и шифрование событий при передаче их с агента СУС ИБ. При сборе событий с использованием агента СУС ИБ должна иметь возможность настраивать модули по умолчанию, автоматически подключаемые настройки сбора для всех новых агентов. В рамках иерархической структуры СУС ИБ должны быть реализованы следующие варианты хранения и передачи событий: - хранение событий на подчиненных площадках; - передача всех событий с подчиненных площадок на головную. Подсистема хранения событий ИБ должна быть реализована в виде единого распределенного хранилища и обеспечивать реализацию следующего набора типовых действий: - выделение отдельного сервера управления, при необходимости, для оптимизации нагрузки; - выделения отдельного сервера индексирования, при необходимости, для оптимизации нагрузки; - долгосрочное хранение событий ИБ как в нормализованном, так и в исходном виде; - хранение событий ИБ в сжатом виде для экономии объема требуемого места в хранилище; - возможность хранения событий как на локальных, так и на внешних (сетевых) хранилищах; - адаптация системы хранения событий ИБ под разные часовые пояса (отображение всех событий в едином временном пространстве); - распределенное хранение событий без консолидации в единое хранилище с возможностью оперативного доступа ко всем событиям из единой консоли; - возможность распределенного поиска по всем событиям в едином запросе без передачи события в единое хранилище; - долгосрочное хранение событий с оперативным доступом к любым событиям на всем интервале хранения; - сокращение объемов хранения за счет автоматической очистки несущественных и информационных данных на основе заданной и управляемой администраторами СУС ИБ критичности событий; - автоматическая очистка хранилища от неинформативных событий; - возможность установки глубины хранения пользователем для всех типов событий; - автоматическое восстановление базы данных после сбоев. Хранилище системы СУС ИБ должно обеспечивать хранение оперативной информации за период не менее 3 последних месяцев. Должна быть обеспечена возможность последующего увеличения емкости хранилищ без изменения всей архитектуры решения (горизонтальное масштабирование). Подсистема должна обеспечивать использование «Горячих серверов хранения» обеспечивающей хранение событий, к которым необходим оперативный доступ и «Холодных серверов хранения» для хранения событий, доступ к которым постоянно не требуется. Подсистема хранения должна иметь возможность горизонтального масштабирования путем ввода новых серверов хранения событий, без привлечения сторонних организаций и разработчиков. Подсистема хранения должна включать в себя модуль архивации, обладающий следующим функционалом: 1) Модуль должен обеспечивать возможность автоматической однопоточной и многопоточной архивации событий с выгрузкой их в отдельные файлы на сетевом хранилище. 2) Модуль должен обеспечивать возможность настройки глубины хранения событий в системе – события старше указанного срока должны автоматически выгружаться в архив 3) Модуль должен обеспечивать возможность просмотра имеющихся архивов, возможность временного подключения архива к системе для оперативной работы с ним, возможность отключения архива от системы после его использования. 4) Модуль должен обеспечивать возможность нескольких видов архивации событий – режим быстрой архивации с минимальной степенью сжатия и медленной архивации с большей степенью сжатия – не менее 7 раз от размера событий в системе. 5) Модуль должен обеспечивать возможность автоматического мониторинга состояния подключенного сетевого хранилища с предупреждением в интерфейсе в случае его недоступности. Подсистема хранения должна включать в себя модуль агрегации событий, обладающий следующим функционалом: 1) Модуль должен уменьшать объема хранилища событий; 2) Модуль должен обеспечивать прекращение хранения однотипных и неважных событий; 3) Модуль должен хранить первое и последнее события, содержащие временные метки всех подобных событий. Подсистема хранения должна включать в себя модуль фильтрации приходящих событий: 1) Модуль должен обеспечивать фильтрацию событий по созданным правилам фильтрации; 2) Модуль должен осуществлять экспорт и импорт правил фильтрации; 3) Модуль должен обеспечивать копирование правил фильтрации на подчиненные ноды при режиме Multitenancy. Подсистема корреляции событий ИБ должна обеспечивать реализацию выявления подозрений на инциденты ИБ посредством корреляции событий ИБ по заданным в СУС ИБ правилам. Должны выявляться подозрения на следующие инциденты, включая, но не ограничиваясь: - превышение числа указанного количества попыток неуспешного доступа; - успешных вход под учетной записью после многочисленных неуспешных попыток; - попытки подбора пароля к сервисам удаленного управления серверов и сетевого оборудования, а также для критичных учетных записей; - блокирование учетной записи после многочисленных неуспешных попыток; - блокирование критичной/сервисной учетной записи по превышению лимита неудачных входов; - интерактивный вход под служебной/сервисной учетной записью; - попытки входа под несуществующей учетной записью; - попытки входа под заблокированной учетной записью; - удаленный/интерактивный вход на критичные ресурсы под учетными записями, не перечисленными в указанном списке; - изменение или создание учетных записей пользователями, не входящими в доверенную группу; - изменение учетных записей и групп вне рабочего времени; - изменение сервисных учетных записей; - вход с использованием привилегированных или сервисных учетных записей, в том числе в нерабочие часы; - массовое изменение учетных записей и групп; - включение опции Password Never Expires; - очистка журналов событий; - превышение допустимого числа запрещенных межсетевым экраном соединений; - превышение допустимого числа сброшенных соединений; - превышение допустимого числа неустановленных соединений; - многочисленные ошибки доступа к источнику (нет прав доступа). Подсистема корреляции событий ИБ должна обеспечивать реализацию следующего набора типовых действий: - формирование пользовательского события в результате срабатывания правила корреляции; - проактивные сценарии при срабатывании правила корреляции; - передача в проактивные сценарии одиночных значений или массивов имен пользователей, исходных IP адресов, прочих переменных, фигурирующих в инциденте; - отправка уведомления о регистрации инцидента по электронной почте сотрудникам, не имеющих доступа к системе; - отправка уведомления о регистрации инцидента в Telegram сотрудникам, не имеющим доступа к системе; - отправка уведомлений в telegram для переоткрытых инцидентов; - групповое управление настройками переоткрытия инцидентов. Подсистема корреляции должна обеспечивать выполнение следующих функций: - возможность использования категории события для дальнейшего использования в правилах корреляции, вместо перечисления id конкретных событий. - возможность использования уровня критичности события; - использование операций равенства "Значения"; - использование операций больше "Значения"; - использование операций больше или равно "Значения"; - использование операций меньше "Значения"; - использование операций меньше или равно "Значения"; - использование операция строкового равенства "Значения"; - использование операция строкового неравенства "Значения"; - сравнение (равенство) не зависимо от регистра значений в поле; - сравнение (неравенство) не зависимо от регистра значений в поле; - поиск неполного значения; - сравнение поля (значения) за временной диапазон. Фиксация изменений; Подсистема корреляции должна обеспечивать выполнение следующих функций: - Значение в поле начинается с определенного значения; - проверка наличия значения в поле (поле не пустое); - проверка отсутствия значения в поле (пустое поле); - значение из поля входит в указанный список или списки, как в статические, так и динамические - значение из поля не входит в указанный список или списки; - значение в поле входит в список заблокированных ресурсов Роскомнадзором; - проверка наличия определённого поля в событии; - проверка отсутствия определённого поля в событии; - проверка наличия инцидентов по значению в указанном поле; - использования отрицания к определенному условию или группе условий; - проверка доменных имен на вредоносность; - поиск в списках не зависимо от регистра значений; - сравнение (равенство) значения и поля; - сравнение (неравенство) значения и поля; - поиск подстроки по значениям статических списков; - копирование списков на подчиненные ноды при режиме Multitenancy; - постраничный поиск значений статического списка; - сортировка значений таблиц; - массовое удаление значений таблиц; - вывод правил со статическими списками. Подсистема должна обеспечивать агрегацию инцидентов. Агрегация должна осуществляться при совпадении значений любых заданных администратором полей событий. При регистрации большого количества однотипных событий, превышающего количественные значения правила корреляции, должен быть создан только один инцидент. Подсистема должна обеспечивать возможность добавления информации в динамические списки и удаления информации из них. Подсистема должна обеспечивать хранение событий вызвавший инцидент в отдельной базе данных. Подсистема должна иметь функционал проверки наличия IP или доменов, указанных заказчиком в списке Роскомнадзора. Администраторы СУС ИБ должны иметь возможность: - включения и отключения отдельных правил корреляции; - копирования правила корреляции с созданием нового без повторного написания условия; - добавление категории инцидентов к правилу корреляции; - изменения пользовательского правила корреляции с уточнением его условия; - экспортировать в форматах json, yaml и импортировать правила корреляции; - привязка событий к инцидентам, созданным вручную; - экспортировать содержимое статических и динамических таблиц; - импортировать данные из файлов в статические и динамические таблицы. Условие правила корреляции должно трактоваться однозначно, быть интуитивно понятным. Подсистема должна иметь возможность использовать любые поля событий из таксономии. В рамках иерархической структуры СУС ИБ должна быть обеспечена следующая логика работы подсистемы корреляции событий ИБ: - в случае работы подсистемы корреляции на стороне головной площадки корреляция должна осуществляться независимо по каждой из подчиненных площадок; - в случае работы подсистемы корреляции на стороне подчиненной площадки должна быть обеспечена возможность передачи правил корреляции с головной площадки на подчиненные с возможностью выбора пользователем площадок, на которые необходимо передать правила. Подсистема поиска событий и подозрений на инциденты ИБ должна обеспечивать реализацию следующего набора типовых действий: - формирование графических представлений и визуализаций данных в событиях; - сортировка и группировка событий; - отображение нормализованных событий с выводом указанной последовательности и набора полей; - изменение очередности и количества выводимых полей при детальном просмотре событий; - группировка по указанному пользователем полю; - создание сохраненных фильтров просмотра событий пользователями и администраторами; - использование составных поисковых запросов; - поиск событий без знания текста события, по категориям и критериям; - возможность использования логических операторов; - выгрузка событий по фильтрам с указанными полями и их очередностью; - гибкое формирование отчетов по событиям на базе поисковых запросов; - поиск событий ИБ, связанных с конкретным подозрением на инцидент ИБ; - сортировка событий по каждому из возможных полей; - полнотекстовый поиск по сырым событиям; - перемещение по событиям клавишами ? и ?; - группировка поля события, при детальном его просмотре. - отображение порядка групп полей в соответствии с уровнем важности; - визуальное построение взаимосвязей между событиями по произвольным полям; - запоминание последнего фильтра, введенного во взаимосвязях; - поиск по всем подключенным средствам хранения событий; - полнотекстовый поиск по событиям, с возможностью использования логических операторов, а также преобразования результатов в диаграммы на лету без необходимости создания отчетов или инструментальных панелей. В рамках иерархической структуры СУС ИБ подсистема поиска событий должна обеспечивать возможность распределенного поиска событий по всех подчиненным площадкам из интерфейса управления головной площадки. В рамках иерархической структуры СУС ИБ должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к событиям каждой из подчиненных площадок. Подсистема регистрации инцидентов должна обеспечивать реализацию следующих типовых действий: - ведение процессов инцидент-менеджмента согласно стандарту ITIL; - создание инцидента вручную; - регистрация инцидентов в результате срабатывания по правилам корреляции; - ролевое разделение доступа к инцидентам; - разделение доступа по группам и пользователям системы на основе условий, задаваемых в правилах корреляции; - постановка задач сотрудникам и группам в рамках инцидентов; - оповещение посредством электронной почты о назначенных инцидентах; - оповещение посредством электронной почты о поставленных задачах в рамках инцидентов; - звуковое оповещение о новом инциденте; - уведомления для инцидентов, созданных вручную; - постановка задач сотрудникам, не имеющим доступа к инциденту с изменением зоны видимости инцидента; - эскалация инцидентов с изменением зоны видимости инцидентов; - поиск и навигация по событиям, попавшим под инцидент; - повторное открытие ранее закрытого инцидента при его повторном возникновении; - навигация по закрытым инцидентам; - просмотр решения инцидентов; - просмотр истории инцидента; - возможность массового изменения статуса инцидентов; - возможность автоматической подстановки значений переменных в название и описание инцидентов, генерируемых правилами корреляции; Подсистема регистрации инцидентов должна обеспечивать реализацию следующих типовых действий: - должен обеспечиваться функционал добавления информации в инцидент при ведении расследования; - отображение событий, вызвавших инцидент и обеспечение поиска, сортировки и группировки полей событий в карточке инцидента; - привязка событий к инцидентам, созданным вручную; - удаление определённых инцидентов из системы и всех инцидентов с удалением всей информации об инцидент и событий, связанных с ними, без удаления событий из централизованного хранилища; - массовое удаление инцидентов, сгруппированных по тенанту (при включенном режиме Multitenancy), по наименованию или по категории; - в рамках иерархической структуры СУС ИБ: o должна осуществляться автоматическая передача карточек инцидентов с подчиненных площадок на головную; o должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к карточкам инцидентов каждой из подчиненных площадок. - возможность создавать, отслеживать, назначать, удалять задачи по инцидентам; - отображение идентификатора инцидента; - закрытие инцидента из головной ноды (при режиме Multitenancy); - экспорт инцидентов в формате json; - сохранение фильтра при переходе из события инцидента в раздел «События». Функционал удаления инцидентов должен иметь возможность ограничения определенными ролей пользователей или отключения данного функционала для всех пользователей СУС ИБ. Инциденты информационной безопасности, равно как и связанные с ними события должны храниться в системе не менее 1 года, не зависимо от срока хранения обычных сырых и нормализованных событий в системе. Подсистема информационной безопасности СУС ИБ должна обеспечивать реализацию следующих действий: - аутентификация пользователей посредством встроенных механизмов, интеграции с LDAP и гибридной аутентификации; - разграничение доступа к функциям и информации, обрабатываемой в СУС ИБ посредством ролевой модели; - логирование входов и действий обслуживающего персонала СУС ИБ; - логирование парольной политики; - защита от несанкционированного доступа к информации, находящейся в СУС ИБ; - регистрация и предотвращение попыток несанкционированного доступа к средствам контроля и контролируемой информации; - ограничение количества неуспешных попыток входа в СУС ИБ; - настройка парольных политик пользователей СУС ИБ; - ограничение количества параллельных сеансов доступа в СУС ИБ; - контроль целостность компонентов СУС ИБ и уведомление пользователя в случае нарушения целостности. Управление СУС ИБ осуществляется посредством графического веб-интерфейса, адаптированного под использование с различных веб-браузеров и мобильных устройств. Интерфейс должен отображать текущее состояние всех компонентов системы и текущую нагрузку на ресурсы системы СУС ИБ, такие как CPU, память, диск. Интерфейс должен позволять пользователям создавать и формировать отчеты с возможностью визуализации данных с помощью таблиц и диаграмм. Интерфейс должен позволять отображать текущее количество инцидентов, графики по возникновению инцидентов с разведкой по времени и обеспечивать формирование отчетов по инцидентам с возможностью выбора полей инцидентов. Подсистема управления должна обеспечивать возможность управления настройками и правилами корреляции на всех серверах СУС ИБ из единой консоли. Подсистема должна обеспечивать управление обновлением системы, в случае доступности обновления, подсистема должна отображать список изменений в версии. Обновление системы должно обеспечиваться автоматически, без необходимости остановки системы или отдельных ее компонентов. Обновление компонентов СУС ИБ может включать исправление работы СУС ИБ, новый функционал, обновление правил корреляции и нормализации. Все новые правила корреляции и нормализации, полученные в рамках обновлении системы, должны быть активны по умолчанию, без необходимости взаимодействия с пользователем. Подсистема управления должна: - обеспечивать отображение состояния системы хранения и текущую ее загрузку. В случае использования кластерной сборки системы хранения, подсистема должна обеспечивать отображение состояния каждой ноды в отдельности. - обеспечивать централизованное хранение всех лицензий компонентов СУС ИБ (нод) в едином интерфейсе. - обеспечивать отображение на головной ноде статуса лицензий на подчиненных нодах. - обеспечивать хранение актуальных списков ресурсов (IP адреса и домены), заблокированных Роскомнадзором, и обеспечивать по ним поиск. - обеспечивать функционал множественной активации и деактивации правил корреляции и нормализации событий. - обеспечивать отображение статуса активации и деактивации правил, а также отображать статус наличия ошибок корреляции и нормализации. - иметь функционал передачи парсеров на подчинённые компоненты сбора событий. В рамках иерархической структуры СУС ИБ подсистема управления должна - иметь функционал передачи пользовательских парсеров на подчинённые площадки. - иметь функционал экспорта парсеров в форматах json, yaml. - обеспечивать хранение и отображение списков в системе. Обеспечивать поиск по значениям в списке. В случае удаления из системы списка, используемого в корреляциях, система должна ограничивать удаление данного списка с отображением списка корреляция, где он используется. - обеспечивать функционал автоматического удаления записей из списков по истечению времени или отсутствую обновлений данных в списке (TTL). - обеспечивать возможность отображения состояния подсистемы Хранения событий в веб интерфейсе. - обеспечивать возможность диагностики правил нормализации с возможностью выявления событий, влияющую на производительность системы. - обеспечивать возможность сбора статистики по правилам корреляции, включая время выполнения правил корреляции, и количество инцидентов, сгенерированных правилами и созданными вручную. - обеспечивать возможность сбора статистики по парсерам, включая количество прошедших событий, процессорное время и общее время выполнения по каждому парсеру. - обеспечивать массовое удаление агентов, экспорт списка агентов и модулей, групповое управление агентами, шаблоны настроек модулей агентов. - обеспечивать управление локальной базой агента. Требования к интеграции СУС ИБ Технические решения по интеграции функциональных подсистем должны быть унифицированы и обеспечивать масштабируемость, наращиваемость и дальнейшее совершенствование СУС ИБ при развитии ИТС. Агент СУС ИБ должен включать в себя компонент сбора низкоуровневых событий с ядра ОС. Данный компонент должен включаться/выключаться для каждой установки агента СУС ИБ через центральный интерфейс СУС ИБ. Значение характеристики не может изменяться участником закупки Источники событий должны интегрироваться с платформой СУС ИБ одним из следующих способов: - сбор событий по протоколу syslog, netflow, snmp; - Сбор событий с компонента, собирающего информацию о низкоуровневых событиях ядра ОС. - сбор событий, хранящихся в лог-файлах локально и на сетевых ресурсах (SMB, FTP); - сбор событий, хранящихся в журналах hpe Event Log; - сбор событий, хранящихся в БД MS SQL, Oracle, MySQL, PostgreSQL; - сбор информации об установленном ПО и патчах на ОС Windows; - сбор информации по произвольным WMI запросам; - сбор событий посредством проприетарных протоколов, используемых соответствующими источниками: Cisco SDEE, Checkpoint OPSEC, Amazon Web Services; - сбор результатов выполнения команд на удаленном хосте по протоколу SSH; - сбор результатов выполнения команд на удаленном хосте по протоколу Telnet; - сбор событий посредством REST API (также возможность получения EPS и информации о лицензии по Rest API-запросу). СУС БД должна иметь функционал отделяемых компонентов, обеспечивающий сбор и нормализацию событий не более 500 событий в секунду без необходимости приобретения дополнительных лицензий. При передаче событий должна обеспечиваться их целостность и гарантированная доставка в хранилище. Должно быть предусмотрено временное хранилище при невозможности передачи событий, собранных с источников. При этом, должна обеспечиваться целостность и неизменность событий. В случае превышения лицензионных ограничений система не должна прерывать процесс сбора событий с источников данных без ограничения сроков, прошедших с момента выявления этих ограничений системой. В случае избыточной нагрузки, система должна уметь буферизовать поступающий поток во избежание потерь событий и распределения оптимальной нагрузки. СУС ИБ должна содержать инструментарий подключения новых источников событий через поддерживаемые транспорты, доступные через интерфейс пользователя. СУС ИБ должна обеспечивать функционал импорта данных в списки, используемые в системе из командной строки или с использованием RestAPI. СУС ИБ должна обеспечиваться возможность передачи инцидентов и событий инцидентов во внешние системы с использование RestAPI. Должна быть обеспечена интеграция с IRP системой R-Vision с поддержкой следующего функционала: - передача в инциденте информации об активах в рамках инцидента; - возможность указать группу R-Vision по умолчанию, куда будут добавляться инциденты СУС ИБ. СУС ИБ должна иметь компонент интеграции с личным кабинетом ФИНЦЕРТ, позволяющий автоматически по расписанию загружать индикаторы компрометации из личного кабинета в списки, используемые в корреляциях. СУС ИБ должна иметь компонент интеграции с личным кабинетом ГосСОПКА, с поддержкой следующего функционала: - Получение уведомлений о компьютерных инцидентах и уязвимостей из личного кабинета ГосСОПКА - Получение сообщений из личного кабинета ГосСОПКА - Получение бюллетеней из личного кабинета ГосСОПКА Передачу инцидентов в ГосСОПКА Срок действия лицензии Бессрочная Значение характеристики не может изменяться участником закупки Требования к сертификации ПО должно иметь действующий сертификат ФСТЭК России, подтверждающий соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» по четвертому уровню доверия. Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Класс программ для электронных вычислительных машин и баз данных - (03.02) Средства управления событиями информационной безопасности - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Копия электронного экземпляра - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Общие требования к системе СУС ИБ - СУС ИБ должна строиться как единая система с иерархической функциональной структурой и централизованным пунктом управления и являться составной частью информационно-телекоммуникационной системы Заказчика. - - Значение характеристики не может изменяться участником закупки - СУС ИБ должна иметь микросервисную архитектуру, обеспечивающую перенос части функции СУС ИБ на отдельные сервера, выполняющие функции: - приема событий; - нормализации событий; - корреляции событий; - хранения событий. - СУС ИБ должна обеспечивать решение следующих общих задач: - сбор, обработка, отображение и долгосрочное хранение информации о событиях и подозрениях на инциденты информационной безопасности, выявляемых в инфраструктуре Заказчика; - предоставление инструментов для анализа событий и расследования инцидентов информационной безопасности, в том числе, масштабных инцидентов ИБ, затрагивающие несколько территориальных подразделений; - предоставление исходной информации для определения влияния события или подозрения на инцидент ИБ на ИТ-сервисы. - СУС ИБ должна удовлетворять следующим общим требованиям: - масштабируемость – способность справляться с увеличением рабочей нагрузки на СУС ИБ путем наращивания числа функциональных блоков, выполняющих одни и те же задачи (горизонтальное масштабирование); - вертикальная масштабируемость – возможность увеличения ресурсов на выделенных серверах. - работоспособность – состояние системы, при котором она способна выполнять заданные функции с параметрами, установленными требованиями технической документации. - отказоустойчивость – свойство системы непрерывно сохранять работоспособность в течение некоторого времени. СУС ИБ должна поставляться в отказоустойчивой конфигурации (кластере) для обеспечения функционирования в случае сбоев оборудования или ПО. - унификация – использование типовых проектных решений, обеспечение возможности использования таких решений. - информационная безопасность – обеспечение конфиденциальности, целостности и доступности хранящейся и обрабатываемой СУС ИБ информации. - СУС ИБ должна обеспечивать функционирование в следующих режимах: - штатный режим – режим функционирования СУС ИБ, при котором обеспечивается выполнение функциональных возможностей системы в объеме, соответствующем текущему этапу реализации; - автономный режим – режим, характеризующийся ограничением возможностей контроля. В этом случае сохраняется основной функционал СУС ИБ за исключением функции консолидации информации; - аварийный режим – режим функционирования системы в случае сбоя (ев)/отказа(ов) одного или нескольких компонентов СУС ИБ. В аварийном режиме должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ; - сервисный режим – режим функционирования системы при проведении работ по обслуживанию инфраструктуры СУС ИБ (виртуальной или аппаратной) и обновлению ее компонентов. Сервисный режим должен обеспечивать реализацию основных функций СУС ИБ, за исключением работ, требующих временной приостановки работы компонента(ов) СУС ИБ. Нарушение штатной работы, включая перерывы и выход за установленные пределы параметров электропитания на время не более 30 минут не должны приводить к: - появлению ложных сигналов управления; - потере информации, важной для работы системы управления. - В СУС ИБ должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ путем резервного копирования и восстановления данных и программного обеспечения. Для этого информационные ресурсы СУС ИБ должны включаться в контур существующих систем резервного копирования. Все серверные компоненты СУС ИБ должна строится на базе Linux подобных систем и не требовать приобретения дополнительных лицензий. По окончании действия услуг технической поддержки СУС ИБ система должна сохранять полную работоспособность. Мониторинг и анализ событий информационной безопасности от контролируемых ресурсов ИТС не должен оказывать отрицательного воздействия с точки зрения скорости исполнения обычных процессов функциональной деятельности подразделений Заказчика. - Требования к структуре СУС ИБ - В СУС ИБ должны быть реализованы следующие функциональные подсистемы: - Подсистема сбора и обработки событий ИБ; - Подсистема хранения событий ИБ; - Подсистема корреляции событий ИБ; - Подсистема поиска событий и подозрений на инциденты ИБ; - Подсистема регистрации инцидентов; - Подсистема обеспечение информационной безопасности самой системы; - Подсистемы управления. - - Значение характеристики не может изменяться участником закупки - Требования к функционированию СУС ИБ - СУС ИБ должна обеспечить выполнение следующих функций: - консолидация и хранение информации о инцидентах ИБ, регистрируемых Системой с целью выявления подозрений на инциденты ИБ; - анализ информации о подозрениях на инциденты ИБ с целью их подтверждения и назначения для последующего реагирования; - сбор и систематизация данных для проведения специалистами по ИБ последующего анализа причин и источников инцидентов информационной безопасности для определения корректирующих действий по снижению вероятности наступления аналогичных инцидентов информационной безопасности в будущем; - обобщенное представление информации о выявленных в ИТС подозрениях на инциденты ИБ на единой консоли СУС ИБ; - уведомление ответственных сотрудников ИБ об обнаружении инцидентов/подозрений на инцидент; - администрирование компонентов СУС ИБ; - мониторинг состояния, устранение сбоев и отказов компонентов СУС ИБ; - поддержка иерархической структуры с назначением головной и подчиненных площадок СУС ИБ. - - Значение характеристики не может изменяться участником закупки - Требования к функциональным подсистемам - Реализация функциональных подсистем должна учитывать иерархическую структуру СУС ИБ в целом. Проектные решения по созданию СУС ИБ должны предусматривать возможность поэтапного внедрения и интегрирования функциональных подсистем. Решения по обеспечению информационного взаимодействия между функциональными уровнями и подсистемами СУС ИБ, а также с объектами контроля не должны предусматривать создания дублирующих по отношению к уже созданным сетевых и телекоммуникационных инфраструктур. - - Значение характеристики не может изменяться участником закупки - Подсистема корреляции событий ИБ должна обеспечивать реализацию следующего набора типовых действий: - создание корреляций по историческим данным (хранящимся в системе) с использованием всех доступных функций корреляции; - историческая корреляция должна иметь функционал ручного и автоматического запуска; - создание и корректировка правил корреляции событий ИБ в графическом конструкторе без знания языков программирования; - установка приоритета инцидента, регистрируемого в результате срабатывания правила корреляции; - установки зоны видимости инцидента на основе ролевой модели применительно к каждому правилу корреляции; - возможность использования в правилах корреляции изменяемых пользователем статических списков; - возможность использования в правилах корреляции динамических списков; - возможность использования в правилах корреляции динамических таблиц; - установка временных ограничительных параметров срабатывания правила корреляции; - приоритезация выявленных подозрений на инциденты ИБ с учетом критичности событий ИБ, вызвавших данный инцидент и критичности ресурсов, затронутых им; - автоматические механизмы поиска событий и подозрений на инциденты ИБ по заданным критериям и значениям полей событий без создания правил корреляции для каждого конкретного типа инцидентов; - Подсистема регистрации инцидентов безопасности СУС ИБ должна быть выполнена в виде единого решения с остальными подсистемами в единой консоли управления. - Информация об источнике события должна быть представлена в формате IPv4 и IPv6-адресации, либо в формате DNS-hostname. Информация о внешних IP адресах должна быть также представлена в виде геопозиционных меток (страна, город, координаты местонахождения). Дополнительные поля таксономии могут содержать информацию о протоколах прикладного уровня, MAC-адресах, DNS-адресах, файловых доступах, различные переменные и т.д. Должна допускаться возможность расширения схемы полей таксономии администраторами СУС ИБ. - Подсистема корреляции событий ИБ должна обеспечивать корреляцию: - по отдельным событиям; - по количеству событий за интервал времени; - по количеству уникальных значений за интервал времени; - по последовательности действий. - Подсистема сбора и обработки событий ИБ должна обеспечивать реализацию следующего набора типовых действий: 1. сбор и обработка не менее 2000 событий в секунду; 2. автоматизированный сбор и нормализация событий ИБ, включая: 2.1. присвоение событиям категорий в соответствии с типом зарегистрированного события; 2.2. присвоение событию степени критичности, управляемой администраторами СУС ИБ; 2.3. приведение событий ИБ к единому формату СУС ИБ; 2.4. обогащение событий из активов, статических и динамических таблиц (запись пользовательских значений в любое поле события) на основании пользовательских правил; 2.5. сохранение исходного события и нормализованного. 2.6. нормализация объединенного потока событий от различных источников; 3. передача информации о событиях ИБ в подсистему управления инцидентами ИБ, подсистему хранения событий ИБ; 4. поддержка передачи событий в другие системы; 5. возможность передачи событий в нормализованном и сыром формате, в том числе по заданному условию; 6. события должны содержать как минимум следующую информацию: 6.1. дата и время возникновения события; 6.2. источник (IP-адрес или сетевое имя); 6.3. уникальный идентификатор события; 6.3. тип (категория) события; 6.4. описание события; 6.7. критичность (приоритет) события; 6.8. время получения события от источника; 6.9. дополнительные поля. - Подсистема сбора должна иметь унифицированные транспорты для сбора событий и допускать подключение новых источников администраторами СУС ИБ без привлечения сторонних организаций и разработчиков. Подсистема должна обеспечивать мониторинг syslog источников. Подсистема должна обеспечивать возможность разработки правил нормализации событий для существующих полей таксономии с использованием встроенного инструментария и не требовать привлечения разработчиков. Подсистема сбора должна автоматически применять соответствующие формулы нормализации, без необходимости настройки типа источника или вендора в СУС ИБ. Подсистема должна гарантировать кэширование событий на агенте, при потере связи с центральным компонентом СУС ИБ. Подсистема должна обеспечивать автоматическую однопоточную и многопоточную архивацию и шифрование событий при передаче их с агента СУС ИБ. - При сборе событий с использованием агента СУС ИБ должна иметь возможность настраивать модули по умолчанию, автоматически подключаемые настройки сбора для всех новых агентов. В рамках иерархической структуры СУС ИБ должны быть реализованы следующие варианты хранения и передачи событий: - хранение событий на подчиненных площадках; - передача всех событий с подчиненных площадок на головную. - Подсистема хранения событий ИБ должна быть реализована в виде единого распределенного хранилища и обеспечивать реализацию следующего набора типовых действий: - выделение отдельного сервера управления, при необходимости, для оптимизации нагрузки; - выделения отдельного сервера индексирования, при необходимости, для оптимизации нагрузки; - долгосрочное хранение событий ИБ как в нормализованном, так и в исходном виде; - хранение событий ИБ в сжатом виде для экономии объема требуемого места в хранилище; - возможность хранения событий как на локальных, так и на внешних (сетевых) хранилищах; - адаптация системы хранения событий ИБ под разные часовые пояса (отображение всех событий в едином временном пространстве); - распределенное хранение событий без консолидации в единое хранилище с возможностью оперативного доступа ко всем событиям из единой консоли; - возможность распределенного поиска по всем событиям в едином запросе без передачи события в единое хранилище; - долгосрочное хранение событий с оперативным доступом к любым событиям на всем интервале хранения; - сокращение объемов хранения за счет автоматической очистки несущественных и информационных данных на основе заданной и управляемой администраторами СУС ИБ критичности событий; - автоматическая очистка хранилища от неинформативных событий; - возможность установки глубины хранения пользователем для всех типов событий; - автоматическое восстановление базы данных после сбоев. - Хранилище системы СУС ИБ должно обеспечивать хранение оперативной информации за период не менее 3 последних месяцев. Должна быть обеспечена возможность последующего увеличения емкости хранилищ без изменения всей архитектуры решения (горизонтальное масштабирование). Подсистема должна обеспечивать использование «Горячих серверов хранения» обеспечивающей хранение событий, к которым необходим оперативный доступ и «Холодных серверов хранения» для хранения событий, доступ к которым постоянно не требуется. Подсистема хранения должна иметь возможность горизонтального масштабирования путем ввода новых серверов хранения событий, без привлечения сторонних организаций и разработчиков. - Подсистема хранения должна включать в себя модуль архивации, обладающий следующим функционалом: 1) Модуль должен обеспечивать возможность автоматической однопоточной и многопоточной архивации событий с выгрузкой их в отдельные файлы на сетевом хранилище. 2) Модуль должен обеспечивать возможность настройки глубины хранения событий в системе – события старше указанного срока должны автоматически выгружаться в архив 3) Модуль должен обеспечивать возможность просмотра имеющихся архивов, возможность временного подключения архива к системе для оперативной работы с ним, возможность отключения архива от системы после его использования. 4) Модуль должен обеспечивать возможность нескольких видов архивации событий – режим быстрой архивации с минимальной степенью сжатия и медленной архивации с большей степенью сжатия – не менее 7 раз от размера событий в системе. 5) Модуль должен обеспечивать возможность автоматического мониторинга состояния подключенного сетевого хранилища с предупреждением в интерфейсе в случае его недоступности. - Подсистема хранения должна включать в себя модуль агрегации событий, обладающий следующим функционалом: 1) Модуль должен уменьшать объема хранилища событий; 2) Модуль должен обеспечивать прекращение хранения однотипных и неважных событий; 3) Модуль должен хранить первое и последнее события, содержащие временные метки всех подобных событий. - Подсистема хранения должна включать в себя модуль фильтрации приходящих событий: 1) Модуль должен обеспечивать фильтрацию событий по созданным правилам фильтрации; 2) Модуль должен осуществлять экспорт и импорт правил фильтрации; 3) Модуль должен обеспечивать копирование правил фильтрации на подчиненные ноды при режиме Multitenancy. - Подсистема корреляции событий ИБ должна обеспечивать реализацию выявления подозрений на инциденты ИБ посредством корреляции событий ИБ по заданным в СУС ИБ правилам. Должны выявляться подозрения на следующие инциденты, включая, но не ограничиваясь: - превышение числа указанного количества попыток неуспешного доступа; - успешных вход под учетной записью после многочисленных неуспешных попыток; - попытки подбора пароля к сервисам удаленного управления серверов и сетевого оборудования, а также для критичных учетных записей; - блокирование учетной записи после многочисленных неуспешных попыток; - блокирование критичной/сервисной учетной записи по превышению лимита неудачных входов; - интерактивный вход под служебной/сервисной учетной записью; - попытки входа под несуществующей учетной записью; - попытки входа под заблокированной учетной записью; - удаленный/интерактивный вход на критичные ресурсы под учетными записями, не перечисленными в указанном списке; - изменение или создание учетных записей пользователями, не входящими в доверенную группу; - изменение учетных записей и групп вне рабочего времени; - изменение сервисных учетных записей; - вход с использованием привилегированных или сервисных учетных записей, в том числе в нерабочие часы; - массовое изменение учетных записей и групп; - включение опции Password Never Expires; - очистка журналов событий; - превышение допустимого числа запрещенных межсетевым экраном соединений; - превышение допустимого числа сброшенных соединений; - превышение допустимого числа неустановленных соединений; - многочисленные ошибки доступа к источнику (нет прав доступа). - Подсистема корреляции событий ИБ должна обеспечивать реализацию следующего набора типовых действий: - формирование пользовательского события в результате срабатывания правила корреляции; - проактивные сценарии при срабатывании правила корреляции; - передача в проактивные сценарии одиночных значений или массивов имен пользователей, исходных IP адресов, прочих переменных, фигурирующих в инциденте; - отправка уведомления о регистрации инцидента по электронной почте сотрудникам, не имеющих доступа к системе; - отправка уведомления о регистрации инцидента в Telegram сотрудникам, не имеющим доступа к системе; - отправка уведомлений в telegram для переоткрытых инцидентов; - групповое управление настройками переоткрытия инцидентов. - Подсистема корреляции должна обеспечивать выполнение следующих функций: - возможность использования категории события для дальнейшего использования в правилах корреляции, вместо перечисления id конкретных событий. - возможность использования уровня критичности события; - использование операций равенства "Значения"; - использование операций больше "Значения"; - использование операций больше или равно "Значения"; - использование операций меньше "Значения"; - использование операций меньше или равно "Значения"; - использование операция строкового равенства "Значения"; - использование операция строкового неравенства "Значения"; - сравнение (равенство) не зависимо от регистра значений в поле; - сравнение (неравенство) не зависимо от регистра значений в поле; - поиск неполного значения; - сравнение поля (значения) за временной диапазон. Фиксация изменений; - Подсистема корреляции должна обеспечивать выполнение следующих функций: - Значение в поле начинается с определенного значения; - проверка наличия значения в поле (поле не пустое); - проверка отсутствия значения в поле (пустое поле); - значение из поля входит в указанный список или списки, как в статические, так и динамические - значение из поля не входит в указанный список или списки; - значение в поле входит в список заблокированных ресурсов Роскомнадзором; - проверка наличия определённого поля в событии; - проверка отсутствия определённого поля в событии; - проверка наличия инцидентов по значению в указанном поле; - использования отрицания к определенному условию или группе условий; - проверка доменных имен на вредоносность; - поиск в списках не зависимо от регистра значений; - сравнение (равенство) значения и поля; - сравнение (неравенство) значения и поля; - поиск подстроки по значениям статических списков; - копирование списков на подчиненные ноды при режиме Multitenancy; - постраничный поиск значений статического списка; - сортировка значений таблиц; - массовое удаление значений таблиц; - вывод правил со статическими списками. - Подсистема должна обеспечивать агрегацию инцидентов. Агрегация должна осуществляться при совпадении значений любых заданных администратором полей событий. При регистрации большого количества однотипных событий, превышающего количественные значения правила корреляции, должен быть создан только один инцидент. Подсистема должна обеспечивать возможность добавления информации в динамические списки и удаления информации из них. Подсистема должна обеспечивать хранение событий вызвавший инцидент в отдельной базе данных. Подсистема должна иметь функционал проверки наличия IP или доменов, указанных заказчиком в списке Роскомнадзора. - Администраторы СУС ИБ должны иметь возможность: - включения и отключения отдельных правил корреляции; - копирования правила корреляции с созданием нового без повторного написания условия; - добавление категории инцидентов к правилу корреляции; - изменения пользовательского правила корреляции с уточнением его условия; - экспортировать в форматах json, yaml и импортировать правила корреляции; - привязка событий к инцидентам, созданным вручную; - экспортировать содержимое статических и динамических таблиц; - импортировать данные из файлов в статические и динамические таблицы. Условие правила корреляции должно трактоваться однозначно, быть интуитивно понятным. - Подсистема должна иметь возможность использовать любые поля событий из таксономии. В рамках иерархической структуры СУС ИБ должна быть обеспечена следующая логика работы подсистемы корреляции событий ИБ: - в случае работы подсистемы корреляции на стороне головной площадки корреляция должна осуществляться независимо по каждой из подчиненных площадок; - в случае работы подсистемы корреляции на стороне подчиненной площадки должна быть обеспечена возможность передачи правил корреляции с головной площадки на подчиненные с возможностью выбора пользователем площадок, на которые необходимо передать правила. - Подсистема поиска событий и подозрений на инциденты ИБ должна обеспечивать реализацию следующего набора типовых действий: - формирование графических представлений и визуализаций данных в событиях; - сортировка и группировка событий; - отображение нормализованных событий с выводом указанной последовательности и набора полей; - изменение очередности и количества выводимых полей при детальном просмотре событий; - группировка по указанному пользователем полю; - создание сохраненных фильтров просмотра событий пользователями и администраторами; - использование составных поисковых запросов; - поиск событий без знания текста события, по категориям и критериям; - возможность использования логических операторов; - выгрузка событий по фильтрам с указанными полями и их очередностью; - гибкое формирование отчетов по событиям на базе поисковых запросов; - поиск событий ИБ, связанных с конкретным подозрением на инцидент ИБ; - сортировка событий по каждому из возможных полей; - полнотекстовый поиск по сырым событиям; - перемещение по событиям клавишами ? и ?; - группировка поля события, при детальном его просмотре. - отображение порядка групп полей в соответствии с уровнем важности; - визуальное построение взаимосвязей между событиями по произвольным полям; - запоминание последнего фильтра, введенного во взаимосвязях; - поиск по всем подключенным средствам хранения событий; - полнотекстовый поиск по событиям, с возможностью использования логических операторов, а также преобразования результатов в диаграммы на лету без необходимости создания отчетов или инструментальных панелей. - В рамках иерархической структуры СУС ИБ подсистема поиска событий должна обеспечивать возможность распределенного поиска событий по всех подчиненным площадкам из интерфейса управления головной площадки. В рамках иерархической структуры СУС ИБ должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к событиям каждой из подчиненных площадок. - Подсистема регистрации инцидентов должна обеспечивать реализацию следующих типовых действий: - ведение процессов инцидент-менеджмента согласно стандарту ITIL; - создание инцидента вручную; - регистрация инцидентов в результате срабатывания по правилам корреляции; - ролевое разделение доступа к инцидентам; - разделение доступа по группам и пользователям системы на основе условий, задаваемых в правилах корреляции; - постановка задач сотрудникам и группам в рамках инцидентов; - оповещение посредством электронной почты о назначенных инцидентах; - оповещение посредством электронной почты о поставленных задачах в рамках инцидентов; - звуковое оповещение о новом инциденте; - уведомления для инцидентов, созданных вручную; - постановка задач сотрудникам, не имеющим доступа к инциденту с изменением зоны видимости инцидента; - эскалация инцидентов с изменением зоны видимости инцидентов; - поиск и навигация по событиям, попавшим под инцидент; - повторное открытие ранее закрытого инцидента при его повторном возникновении; - навигация по закрытым инцидентам; - просмотр решения инцидентов; - просмотр истории инцидента; - возможность массового изменения статуса инцидентов; - возможность автоматической подстановки значений переменных в название и описание инцидентов, генерируемых правилами корреляции; - Подсистема регистрации инцидентов должна обеспечивать реализацию следующих типовых действий: - должен обеспечиваться функционал добавления информации в инцидент при ведении расследования; - отображение событий, вызвавших инцидент и обеспечение поиска, сортировки и группировки полей событий в карточке инцидента; - привязка событий к инцидентам, созданным вручную; - удаление определённых инцидентов из системы и всех инцидентов с удалением всей информации об инцидент и событий, связанных с ними, без удаления событий из централизованного хранилища; - массовое удаление инцидентов, сгруппированных по тенанту (при включенном режиме Multitenancy), по наименованию или по категории; - в рамках иерархической структуры СУС ИБ: o должна осуществляться автоматическая передача карточек инцидентов с подчиненных площадок на головную; o должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к карточкам инцидентов каждой из подчиненных площадок. - возможность создавать, отслеживать, назначать, удалять задачи по инцидентам; - отображение идентификатора инцидента; - закрытие инцидента из головной ноды (при режиме Multitenancy); - экспорт инцидентов в формате json; - сохранение фильтра при переходе из события инцидента в раздел «События». Функционал удаления инцидентов должен иметь возможность ограничения определенными ролей пользователей или отключения данного функционала для всех пользователей СУС ИБ. Инциденты информационной безопасности, равно как и связанные с ними события должны храниться в системе не менее 1 года, не зависимо от срока хранения обычных сырых и нормализованных событий в системе. - Подсистема информационной безопасности СУС ИБ должна обеспечивать реализацию следующих действий: - аутентификация пользователей посредством встроенных механизмов, интеграции с LDAP и гибридной аутентификации; - разграничение доступа к функциям и информации, обрабатываемой в СУС ИБ посредством ролевой модели; - логирование входов и действий обслуживающего персонала СУС ИБ; - логирование парольной политики; - защита от несанкционированного доступа к информации, находящейся в СУС ИБ; - регистрация и предотвращение попыток несанкционированного доступа к средствам контроля и контролируемой информации; - ограничение количества неуспешных попыток входа в СУС ИБ; - настройка парольных политик пользователей СУС ИБ; - ограничение количества параллельных сеансов доступа в СУС ИБ; - контроль целостность компонентов СУС ИБ и уведомление пользователя в случае нарушения целостности. - Управление СУС ИБ осуществляется посредством графического веб-интерфейса, адаптированного под использование с различных веб-браузеров и мобильных устройств. Интерфейс должен отображать текущее состояние всех компонентов системы и текущую нагрузку на ресурсы системы СУС ИБ, такие как CPU, память, диск. Интерфейс должен позволять пользователям создавать и формировать отчеты с возможностью визуализации данных с помощью таблиц и диаграмм. Интерфейс должен позволять отображать текущее количество инцидентов, графики по возникновению инцидентов с разведкой по времени и обеспечивать формирование отчетов по инцидентам с возможностью выбора полей инцидентов. Подсистема управления должна обеспечивать возможность управления настройками и правилами корреляции на всех серверах СУС ИБ из единой консоли. Подсистема должна обеспечивать управление обновлением системы, в случае доступности обновления, подсистема должна отображать список изменений в версии. Обновление системы должно обеспечиваться автоматически, без необходимости остановки системы или отдельных ее компонентов. Обновление компонентов СУС ИБ может включать исправление работы СУС ИБ, новый функционал, обновление правил корреляции и нормализации. Все новые правила корреляции и нормализации, полученные в рамках обновлении системы, должны быть активны по умолчанию, без необходимости взаимодействия с пользователем. - Подсистема управления должна: - обеспечивать отображение состояния системы хранения и текущую ее загрузку. В случае использования кластерной сборки системы хранения, подсистема должна обеспечивать отображение состояния каждой ноды в отдельности. - обеспечивать централизованное хранение всех лицензий компонентов СУС ИБ (нод) в едином интерфейсе. - обеспечивать отображение на головной ноде статуса лицензий на подчиненных нодах. - обеспечивать хранение актуальных списков ресурсов (IP адреса и домены), заблокированных Роскомнадзором, и обеспечивать по ним поиск. - обеспечивать функционал множественной активации и деактивации правил корреляции и нормализации событий. - обеспечивать отображение статуса активации и деактивации правил, а также отображать статус наличия ошибок корреляции и нормализации. - иметь функционал передачи парсеров на подчинённые компоненты сбора событий. - В рамках иерархической структуры СУС ИБ подсистема управления должна - иметь функционал передачи пользовательских парсеров на подчинённые площадки. - иметь функционал экспорта парсеров в форматах json, yaml. - обеспечивать хранение и отображение списков в системе. Обеспечивать поиск по значениям в списке. В случае удаления из системы списка, используемого в корреляциях, система должна ограничивать удаление данного списка с отображением списка корреляция, где он используется. - обеспечивать функционал автоматического удаления записей из списков по истечению времени или отсутствую обновлений данных в списке (TTL). - обеспечивать возможность отображения состояния подсистемы Хранения событий в веб интерфейсе. - обеспечивать возможность диагностики правил нормализации с возможностью выявления событий, влияющую на производительность системы. - обеспечивать возможность сбора статистики по правилам корреляции, включая время выполнения правил корреляции, и количество инцидентов, сгенерированных правилами и созданными вручную. - обеспечивать возможность сбора статистики по парсерам, включая количество прошедших событий, процессорное время и общее время выполнения по каждому парсеру. - обеспечивать массовое удаление агентов, экспорт списка агентов и модулей, групповое управление агентами, шаблоны настроек модулей агентов. - обеспечивать управление локальной базой агента. - Требования к интеграции СУС ИБ - Технические решения по интеграции функциональных подсистем должны быть унифицированы и обеспечивать масштабируемость, наращиваемость и дальнейшее совершенствование СУС ИБ при развитии ИТС. Агент СУС ИБ должен включать в себя компонент сбора низкоуровневых событий с ядра ОС. Данный компонент должен включаться/выключаться для каждой установки агента СУС ИБ через центральный интерфейс СУС ИБ. - - Значение характеристики не может изменяться участником закупки - Источники событий должны интегрироваться с платформой СУС ИБ одним из следующих способов: - сбор событий по протоколу syslog, netflow, snmp; - Сбор событий с компонента, собирающего информацию о низкоуровневых событиях ядра ОС. - сбор событий, хранящихся в лог-файлах локально и на сетевых ресурсах (SMB, FTP); - сбор событий, хранящихся в журналах hpe Event Log; - сбор событий, хранящихся в БД MS SQL, Oracle, MySQL, PostgreSQL; - сбор информации об установленном ПО и патчах на ОС Windows; - сбор информации по произвольным WMI запросам; - сбор событий посредством проприетарных протоколов, используемых соответствующими источниками: Cisco SDEE, Checkpoint OPSEC, Amazon Web Services; - сбор результатов выполнения команд на удаленном хосте по протоколу SSH; - сбор результатов выполнения команд на удаленном хосте по протоколу Telnet; - сбор событий посредством REST API (также возможность получения EPS и информации о лицензии по Rest API-запросу). - СУС БД должна иметь функционал отделяемых компонентов, обеспечивающий сбор и нормализацию событий не более 500 событий в секунду без необходимости приобретения дополнительных лицензий. При передаче событий должна обеспечиваться их целостность и гарантированная доставка в хранилище. Должно быть предусмотрено временное хранилище при невозможности передачи событий, собранных с источников. При этом, должна обеспечиваться целостность и неизменность событий. В случае превышения лицензионных ограничений система не должна прерывать процесс сбора событий с источников данных без ограничения сроков, прошедших с момента выявления этих ограничений системой. В случае избыточной нагрузки, система должна уметь буферизовать поступающий поток во избежание потерь событий и распределения оптимальной нагрузки. СУС ИБ должна содержать инструментарий подключения новых источников событий через поддерживаемые транспорты, доступные через интерфейс пользователя. СУС ИБ должна обеспечивать функционал импорта данных в списки, используемые в системе из командной строки или с использованием RestAPI. СУС ИБ должна обеспечиваться возможность передачи инцидентов и событий инцидентов во внешние системы с использование RestAPI. - Должна быть обеспечена интеграция с IRP системой R-Vision с поддержкой следующего функционала: - передача в инциденте информации об активах в рамках инцидента; - возможность указать группу R-Vision по умолчанию, куда будут добавляться инциденты СУС ИБ. СУС ИБ должна иметь компонент интеграции с личным кабинетом ФИНЦЕРТ, позволяющий автоматически по расписанию загружать индикаторы компрометации из личного кабинета в списки, используемые в корреляциях. СУС ИБ должна иметь компонент интеграции с личным кабинетом ГосСОПКА, с поддержкой следующего функционала: - Получение уведомлений о компьютерных инцидентах и уязвимостей из личного кабинета ГосСОПКА - Получение сообщений из личного кабинета ГосСОПКА - Получение бюллетеней из личного кабинета ГосСОПКА Передачу инцидентов в ГосСОПКА - Срок действия лицензии - Бессрочная - - Значение характеристики не может изменяться участником закупки - Требования к сертификации - ПО должно иметь действующий сертификат ФСТЭК России, подтверждающий соответствие «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» по четвертому уровню доверия. - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

СУС ИБ должна иметь микросервисную архитектуру, обеспечивающую перенос части функции СУС ИБ на отдельные сервера, выполняющие функции: - приема событий; - нормализации событий; - корреляции событий; - хранения событий.

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

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

СУС ИБ должна обеспечивать функционирование в следующих режимах: - штатный режим – режим функционирования СУС ИБ, при котором обеспечивается выполнение функциональных возможностей системы в объеме, соответствующем текущему этапу реализации; - автономный режим – режим, характеризующийся ограничением возможностей контроля. В этом случае сохраняется основной функционал СУС ИБ за исключением функции консолидации информации; - аварийный режим – режим функционирования системы в случае сбоя (ев)/отказа(ов) одного или нескольких компонентов СУС ИБ. В аварийном режиме должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ; - сервисный режим – режим функционирования системы при проведении работ по обслуживанию инфраструктуры СУС ИБ (виртуальной или аппаратной) и обновлению ее компонентов. Сервисный режим должен обеспечивать реализацию основных функций СУС ИБ, за исключением работ, требующих временной приостановки работы компонента(ов) СУС ИБ. Нарушение штатной работы, включая перерывы и выход за установленные пределы параметров электропитания на время не более 30 минут не должны приводить к: - появлению ложных сигналов управления; - потере информации, важной для работы системы управления.

В СУС ИБ должна обеспечиваться сохранность данных при возникновении аварийной ситуации с программно-техническими комплексами СУС ИБ путем резервного копирования и восстановления данных и программного обеспечения. Для этого информационные ресурсы СУС ИБ должны включаться в контур существующих систем резервного копирования. Все серверные компоненты СУС ИБ должна строится на базе Linux подобных систем и не требовать приобретения дополнительных лицензий. По окончании действия услуг технической поддержки СУС ИБ система должна сохранять полную работоспособность. Мониторинг и анализ событий информационной безопасности от контролируемых ресурсов ИТС не должен оказывать отрицательного воздействия с точки зрения скорости исполнения обычных процессов функциональной деятельности подразделений Заказчика.

Требования к структуре СУС ИБ - В СУС ИБ должны быть реализованы следующие функциональные подсистемы: - Подсистема сбора и обработки событий ИБ; - Подсистема хранения событий ИБ; - Подсистема корреляции событий ИБ; - Подсистема поиска событий и подозрений на инциденты ИБ; - Подсистема регистрации инцидентов; - Подсистема обеспечение информационной безопасности самой системы; - Подсистемы управления. - - Значение характеристики не может изменяться участником закупки

Требования к функционированию СУС ИБ - СУС ИБ должна обеспечить выполнение следующих функций: - консолидация и хранение информации о инцидентах ИБ, регистрируемых Системой с целью выявления подозрений на инциденты ИБ; - анализ информации о подозрениях на инциденты ИБ с целью их подтверждения и назначения для последующего реагирования; - сбор и систематизация данных для проведения специалистами по ИБ последующего анализа причин и источников инцидентов информационной безопасности для определения корректирующих действий по снижению вероятности наступления аналогичных инцидентов информационной безопасности в будущем; - обобщенное представление информации о выявленных в ИТС подозрениях на инциденты ИБ на единой консоли СУС ИБ; - уведомление ответственных сотрудников ИБ об обнаружении инцидентов/подозрений на инцидент; - администрирование компонентов СУС ИБ; - мониторинг состояния, устранение сбоев и отказов компонентов СУС ИБ; - поддержка иерархической структуры с назначением головной и подчиненных площадок СУС ИБ. - - Значение характеристики не может изменяться участником закупки

Требования к функциональным подсистемам - Реализация функциональных подсистем должна учитывать иерархическую структуру СУС ИБ в целом. Проектные решения по созданию СУС ИБ должны предусматривать возможность поэтапного внедрения и интегрирования функциональных подсистем. Решения по обеспечению информационного взаимодействия между функциональными уровнями и подсистемами СУС ИБ, а также с объектами контроля не должны предусматривать создания дублирующих по отношению к уже созданным сетевых и телекоммуникационных инфраструктур. - - Значение характеристики не может изменяться участником закупки

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

Подсистема регистрации инцидентов безопасности СУС ИБ должна быть выполнена в виде единого решения с остальными подсистемами в единой консоли управления.

Информация об источнике события должна быть представлена в формате IPv4 и IPv6-адресации, либо в формате DNS-hostname. Информация о внешних IP адресах должна быть также представлена в виде геопозиционных меток (страна, город, координаты местонахождения). Дополнительные поля таксономии могут содержать информацию о протоколах прикладного уровня, MAC-адресах, DNS-адресах, файловых доступах, различные переменные и т.д. Должна допускаться возможность расширения схемы полей таксономии администраторами СУС ИБ.

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

Подсистема сбора и обработки событий ИБ должна обеспечивать реализацию следующего набора типовых действий: 1. сбор и обработка не менее 2000 событий в секунду; 2. автоматизированный сбор и нормализация событий ИБ, включая: 2.1. присвоение событиям категорий в соответствии с типом зарегистрированного события; 2.2. присвоение событию степени критичности, управляемой администраторами СУС ИБ; 2.3. приведение событий ИБ к единому формату СУС ИБ; 2.4. обогащение событий из активов, статических и динамических таблиц (запись пользовательских значений в любое поле события) на основании пользовательских правил; 2.5. сохранение исходного события и нормализованного. 2.6. нормализация объединенного потока событий от различных источников; 3. передача информации о событиях ИБ в подсистему управления инцидентами ИБ, подсистему хранения событий ИБ; 4. поддержка передачи событий в другие системы; 5. возможность передачи событий в нормализованном и сыром формате, в том числе по заданному условию; 6. события должны содержать как минимум следующую информацию: 6.1. дата и время возникновения события; 6.2. источник (IP-адрес или сетевое имя); 6.3. уникальный идентификатор события; 6.3. тип (категория) события; 6.4. описание события; 6.7. критичность (приоритет) события; 6.8. время получения события от источника; 6.9. дополнительные поля.

Подсистема сбора должна иметь унифицированные транспорты для сбора событий и допускать подключение новых источников администраторами СУС ИБ без привлечения сторонних организаций и разработчиков. Подсистема должна обеспечивать мониторинг syslog источников. Подсистема должна обеспечивать возможность разработки правил нормализации событий для существующих полей таксономии с использованием встроенного инструментария и не требовать привлечения разработчиков. Подсистема сбора должна автоматически применять соответствующие формулы нормализации, без необходимости настройки типа источника или вендора в СУС ИБ. Подсистема должна гарантировать кэширование событий на агенте, при потере связи с центральным компонентом СУС ИБ. Подсистема должна обеспечивать автоматическую однопоточную и многопоточную архивацию и шифрование событий при передаче их с агента СУС ИБ.

При сборе событий с использованием агента СУС ИБ должна иметь возможность настраивать модули по умолчанию, автоматически подключаемые настройки сбора для всех новых агентов. В рамках иерархической структуры СУС ИБ должны быть реализованы следующие варианты хранения и передачи событий: - хранение событий на подчиненных площадках; - передача всех событий с подчиненных площадок на головную.

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

Хранилище системы СУС ИБ должно обеспечивать хранение оперативной информации за период не менее 3 последних месяцев. Должна быть обеспечена возможность последующего увеличения емкости хранилищ без изменения всей архитектуры решения (горизонтальное масштабирование). Подсистема должна обеспечивать использование «Горячих серверов хранения» обеспечивающей хранение событий, к которым необходим оперативный доступ и «Холодных серверов хранения» для хранения событий, доступ к которым постоянно не требуется. Подсистема хранения должна иметь возможность горизонтального масштабирования путем ввода новых серверов хранения событий, без привлечения сторонних организаций и разработчиков.

Подсистема хранения должна включать в себя модуль архивации, обладающий следующим функционалом: 1) Модуль должен обеспечивать возможность автоматической однопоточной и многопоточной архивации событий с выгрузкой их в отдельные файлы на сетевом хранилище. 2) Модуль должен обеспечивать возможность настройки глубины хранения событий в системе – события старше указанного срока должны автоматически выгружаться в архив 3) Модуль должен обеспечивать возможность просмотра имеющихся архивов, возможность временного подключения архива к системе для оперативной работы с ним, возможность отключения архива от системы после его использования. 4) Модуль должен обеспечивать возможность нескольких видов архивации событий – режим быстрой архивации с минимальной степенью сжатия и медленной архивации с большей степенью сжатия – не менее 7 раз от размера событий в системе. 5) Модуль должен обеспечивать возможность автоматического мониторинга состояния подключенного сетевого хранилища с предупреждением в интерфейсе в случае его недоступности.

Подсистема хранения должна включать в себя модуль агрегации событий, обладающий следующим функционалом: 1) Модуль должен уменьшать объема хранилища событий; 2) Модуль должен обеспечивать прекращение хранения однотипных и неважных событий; 3) Модуль должен хранить первое и последнее события, содержащие временные метки всех подобных событий.

Подсистема хранения должна включать в себя модуль фильтрации приходящих событий: 1) Модуль должен обеспечивать фильтрацию событий по созданным правилам фильтрации; 2) Модуль должен осуществлять экспорт и импорт правил фильтрации; 3) Модуль должен обеспечивать копирование правил фильтрации на подчиненные ноды при режиме Multitenancy.

Подсистема корреляции событий ИБ должна обеспечивать реализацию выявления подозрений на инциденты ИБ посредством корреляции событий ИБ по заданным в СУС ИБ правилам. Должны выявляться подозрения на следующие инциденты, включая, но не ограничиваясь: - превышение числа указанного количества попыток неуспешного доступа; - успешных вход под учетной записью после многочисленных неуспешных попыток; - попытки подбора пароля к сервисам удаленного управления серверов и сетевого оборудования, а также для критичных учетных записей; - блокирование учетной записи после многочисленных неуспешных попыток; - блокирование критичной/сервисной учетной записи по превышению лимита неудачных входов; - интерактивный вход под служебной/сервисной учетной записью; - попытки входа под несуществующей учетной записью; - попытки входа под заблокированной учетной записью; - удаленный/интерактивный вход на критичные ресурсы под учетными записями, не перечисленными в указанном списке; - изменение или создание учетных записей пользователями, не входящими в доверенную группу; - изменение учетных записей и групп вне рабочего времени; - изменение сервисных учетных записей; - вход с использованием привилегированных или сервисных учетных записей, в том числе в нерабочие часы; - массовое изменение учетных записей и групп; - включение опции Password Never Expires; - очистка журналов событий; - превышение допустимого числа запрещенных межсетевым экраном соединений; - превышение допустимого числа сброшенных соединений; - превышение допустимого числа неустановленных соединений; - многочисленные ошибки доступа к источнику (нет прав доступа).

Подсистема корреляции событий ИБ должна обеспечивать реализацию следующего набора типовых действий: - формирование пользовательского события в результате срабатывания правила корреляции; - проактивные сценарии при срабатывании правила корреляции; - передача в проактивные сценарии одиночных значений или массивов имен пользователей, исходных IP адресов, прочих переменных, фигурирующих в инциденте; - отправка уведомления о регистрации инцидента по электронной почте сотрудникам, не имеющих доступа к системе; - отправка уведомления о регистрации инцидента в Telegram сотрудникам, не имеющим доступа к системе; - отправка уведомлений в telegram для переоткрытых инцидентов; - групповое управление настройками переоткрытия инцидентов.

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

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

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

Администраторы СУС ИБ должны иметь возможность: - включения и отключения отдельных правил корреляции; - копирования правила корреляции с созданием нового без повторного написания условия; - добавление категории инцидентов к правилу корреляции; - изменения пользовательского правила корреляции с уточнением его условия; - экспортировать в форматах json, yaml и импортировать правила корреляции; - привязка событий к инцидентам, созданным вручную; - экспортировать содержимое статических и динамических таблиц; - импортировать данные из файлов в статические и динамические таблицы. Условие правила корреляции должно трактоваться однозначно, быть интуитивно понятным.

Подсистема должна иметь возможность использовать любые поля событий из таксономии. В рамках иерархической структуры СУС ИБ должна быть обеспечена следующая логика работы подсистемы корреляции событий ИБ: - в случае работы подсистемы корреляции на стороне головной площадки корреляция должна осуществляться независимо по каждой из подчиненных площадок; - в случае работы подсистемы корреляции на стороне подчиненной площадки должна быть обеспечена возможность передачи правил корреляции с головной площадки на подчиненные с возможностью выбора пользователем площадок, на которые необходимо передать правила.

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

В рамках иерархической структуры СУС ИБ подсистема поиска событий должна обеспечивать возможность распределенного поиска событий по всех подчиненным площадкам из интерфейса управления головной площадки. В рамках иерархической структуры СУС ИБ должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к событиям каждой из подчиненных площадок.

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

Подсистема регистрации инцидентов должна обеспечивать реализацию следующих типовых действий: - должен обеспечиваться функционал добавления информации в инцидент при ведении расследования; - отображение событий, вызвавших инцидент и обеспечение поиска, сортировки и группировки полей событий в карточке инцидента; - привязка событий к инцидентам, созданным вручную; - удаление определённых инцидентов из системы и всех инцидентов с удалением всей информации об инцидент и событий, связанных с ними, без удаления событий из централизованного хранилища; - массовое удаление инцидентов, сгруппированных по тенанту (при включенном режиме Multitenancy), по наименованию или по категории; - в рамках иерархической структуры СУС ИБ: o должна осуществляться автоматическая передача карточек инцидентов с подчиненных площадок на головную; o должна быть обеспечена возможность разграничения доступа пользователей головной площадки СУС ИБ к карточкам инцидентов каждой из подчиненных площадок. - возможность создавать, отслеживать, назначать, удалять задачи по инцидентам; - отображение идентификатора инцидента; - закрытие инцидента из головной ноды (при режиме Multitenancy); - экспорт инцидентов в формате json; - сохранение фильтра при переходе из события инцидента в раздел «События». Функционал удаления инцидентов должен иметь возможность ограничения определенными ролей пользователей или отключения данного функционала для всех пользователей СУС ИБ. Инциденты информационной безопасности, равно как и связанные с ними события должны храниться в системе не менее 1 года, не зависимо от срока хранения обычных сырых и нормализованных событий в системе.

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

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

Подсистема управления должна: - обеспечивать отображение состояния системы хранения и текущую ее загрузку. В случае использования кластерной сборки системы хранения, подсистема должна обеспечивать отображение состояния каждой ноды в отдельности. - обеспечивать централизованное хранение всех лицензий компонентов СУС ИБ (нод) в едином интерфейсе. - обеспечивать отображение на головной ноде статуса лицензий на подчиненных нодах. - обеспечивать хранение актуальных списков ресурсов (IP адреса и домены), заблокированных Роскомнадзором, и обеспечивать по ним поиск. - обеспечивать функционал множественной активации и деактивации правил корреляции и нормализации событий. - обеспечивать отображение статуса активации и деактивации правил, а также отображать статус наличия ошибок корреляции и нормализации. - иметь функционал передачи парсеров на подчинённые компоненты сбора событий.

В рамках иерархической структуры СУС ИБ подсистема управления должна - иметь функционал передачи пользовательских парсеров на подчинённые площадки. - иметь функционал экспорта парсеров в форматах json, yaml. - обеспечивать хранение и отображение списков в системе. Обеспечивать поиск по значениям в списке. В случае удаления из системы списка, используемого в корреляциях, система должна ограничивать удаление данного списка с отображением списка корреляция, где он используется. - обеспечивать функционал автоматического удаления записей из списков по истечению времени или отсутствую обновлений данных в списке (TTL). - обеспечивать возможность отображения состояния подсистемы Хранения событий в веб интерфейсе. - обеспечивать возможность диагностики правил нормализации с возможностью выявления событий, влияющую на производительность системы. - обеспечивать возможность сбора статистики по правилам корреляции, включая время выполнения правил корреляции, и количество инцидентов, сгенерированных правилами и созданными вручную. - обеспечивать возможность сбора статистики по парсерам, включая количество прошедших событий, процессорное время и общее время выполнения по каждому парсеру. - обеспечивать массовое удаление агентов, экспорт списка агентов и модулей, групповое управление агентами, шаблоны настроек модулей агентов. - обеспечивать управление локальной базой агента.

Требования к интеграции СУС ИБ - Технические решения по интеграции функциональных подсистем должны быть унифицированы и обеспечивать масштабируемость, наращиваемость и дальнейшее совершенствование СУС ИБ при развитии ИТС. Агент СУС ИБ должен включать в себя компонент сбора низкоуровневых событий с ядра ОС. Данный компонент должен включаться/выключаться для каждой установки агента СУС ИБ через центральный интерфейс СУС ИБ. - - Значение характеристики не может изменяться участником закупки

Источники событий должны интегрироваться с платформой СУС ИБ одним из следующих способов: - сбор событий по протоколу syslog, netflow, snmp; - Сбор событий с компонента, собирающего информацию о низкоуровневых событиях ядра ОС. - сбор событий, хранящихся в лог-файлах локально и на сетевых ресурсах (SMB, FTP); - сбор событий, хранящихся в журналах hpe Event Log; - сбор событий, хранящихся в БД MS SQL, Oracle, MySQL, PostgreSQL; - сбор информации об установленном ПО и патчах на ОС Windows; - сбор информации по произвольным WMI запросам; - сбор событий посредством проприетарных протоколов, используемых соответствующими источниками: Cisco SDEE, Checkpoint OPSEC, Amazon Web Services; - сбор результатов выполнения команд на удаленном хосте по протоколу SSH; - сбор результатов выполнения команд на удаленном хосте по протоколу Telnet; - сбор событий посредством REST API (также возможность получения EPS и информации о лицензии по Rest API-запросу).

СУС БД должна иметь функционал отделяемых компонентов, обеспечивающий сбор и нормализацию событий не более 500 событий в секунду без необходимости приобретения дополнительных лицензий. При передаче событий должна обеспечиваться их целостность и гарантированная доставка в хранилище. Должно быть предусмотрено временное хранилище при невозможности передачи событий, собранных с источников. При этом, должна обеспечиваться целостность и неизменность событий. В случае превышения лицензионных ограничений система не должна прерывать процесс сбора событий с источников данных без ограничения сроков, прошедших с момента выявления этих ограничений системой. В случае избыточной нагрузки, система должна уметь буферизовать поступающий поток во избежание потерь событий и распределения оптимальной нагрузки. СУС ИБ должна содержать инструментарий подключения новых источников событий через поддерживаемые транспорты, доступные через интерфейс пользователя. СУС ИБ должна обеспечивать функционал импорта данных в списки, используемые в системе из командной строки или с использованием RestAPI. СУС ИБ должна обеспечиваться возможность передачи инцидентов и событий инцидентов во внешние системы с использование RestAPI.

Должна быть обеспечена интеграция с IRP системой R-Vision с поддержкой следующего функционала: - передача в инциденте информации об активах в рамках инцидента; - возможность указать группу R-Vision по умолчанию, куда будут добавляться инциденты СУС ИБ. СУС ИБ должна иметь компонент интеграции с личным кабинетом ФИНЦЕРТ, позволяющий автоматически по расписанию загружать индикаторы компрометации из личного кабинета в списки, используемые в корреляциях. СУС ИБ должна иметь компонент интеграции с личным кабинетом ГосСОПКА, с поддержкой следующего функционала: - Получение уведомлений о компьютерных инцидентах и уязвимостей из личного кабинета ГосСОПКА - Получение сообщений из личного кабинета ГосСОПКА - Получение бюллетеней из личного кабинета ГосСОПКА Передачу инцидентов в ГосСОПКА

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

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

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге В соответствии с требованиями постановления Правительства Российской Федерации от 08.02.2017 №145 «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – КТРУ), для детального описания закупаемого товара, отвечающего требованиям Заказчика, и в целях улучшения качества выполнения своих функциональных обязанностей, помимо показателей, которые применялись Заказчиком из КТРУ, были использованы показатели с дополнительными функциональными, техническими и качественными характеристиками, не внесенными в КТРУ. В связи с тем, что описание соответствующей позиции каталога не содержит специфических характеристик, необходимых для удовлетворения потребностей заказчика.

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

АДМИНИСТРАЦИЯ ГОРОДА КУРГАНА - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Класс программ для электронных вычислительных машин и баз данных (02.09) Операционные системы общего назначения Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки Требования к операционной системе Операционная система должна: - иметь графическое средство настройки ограничений пользователя по запуску программ в изолированном окружении с использованием механизма пространств имён и фильтрации системных вызовов, обеспечивающих: • ограничение прав пользователя на запуск приложений ядром системы; • ограничение прав пользователя средствами графического интерфейса; • разрешение запуска только тех программных компонентов, которые явно разрешены администратором безопасности. - обеспечивать запрет запуска (исполнения) пользователем созданных самостоятельно (с использованием текстовых редакторов или непосредственно в командной строке) программ с использованием интерпретируемых языков программирования; - включать в свой состав программное обеспечение, реализующее задачи аудита и журналирования (регистрации) событий безопасности. Регистрация событий безопасности должна выполняться с учётом требований ГОСТ Р 59548-2022; - обеспечивать возможность блокировки: • запуска исполняемых файлов, включая EXE и загрузки библиотек, в том числе DLL, .NET 7/8, целостность которых нарушена; • открытия файлов, в том числе пустых, и самораспаковывающихся 7Z архивов, установленных на контроль, при нарушении их целостности. - предоставлять средство настройки профиля системы со следующими возможностями: • настройка комплекса средств защиты в соответствии с требованиями о защите информации, предъявляемыми к определенному классу защищенности информационных систем, при помощи графического интерфейса; • импорт и экспорт настроек комплекса средств защиты системы. - обеспечивать запрет операций записи в системные каталоги и файлы (программы, файлы конфигурации), а также установки программного обеспечения, запуска и остановки системных процессов операционной системы, вне зависимости от изменения пользователем своих привилегий в текущем сеансе работы. Значение характеристики не может изменяться участником закупки Операционная система должна иметь подтверждение возможности её применения для построения информационных (автоматизированных) систем, обрабатывающих информацию ограниченного доступа, и реализации функций безопасности в виде сертификатов соответствия ФСТЭК России требованиям нормативных документов: 1. «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016); 2. «Профиль защиты операционных систем типа «А» не ниже 4 класса ИТ.ОС.А4.ПЗ (ФСТЭК России, 2017); 3. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) не ниже 4 уровня; 4. «Требования по безопасности информации к средствам виртуализации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 5. «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 6. «Требования по безопасности информации к системам управления базами данных» (ФСТЭК России, 2023) не ниже 4 класса защиты. Операционная система должна поддерживать развертывание системы централизованного управления событиями информационной безопасности, которая поставляется в рамках настоящего описания объекта закупки Должны быть обеспечены работы по устранению уязвимостей и включению информации об уязвимостях программного обеспечения операционной системы в банк данных угроз безопасности информации ФСТЭК России (https://bdu.fstec.ru/vul). Механизмами безопасности операционной системы должна быть обеспечена защита системных и привилегированных процессов от несанкционированного доступа и управления (исключение возможности повышения привилегий пользователей и управления привилегированными процессами в случае использования дефектов/уязвимостей в программном обеспечении информационной системы). Требования к встроенному комплексу средств защиты информации операционной системы Операционная система должна обеспечивать встроенными сертифицированными средствами: • идентификацию и аутентификацию пользователей; • управление средствами аутентификации; • управление учетными записями пользователей, разграничение полномочий и назначение прав пользователям; • реализацию дискреционного разграничения доступа; • возможность указания параметров настройки комплекса средств защиты во время создания пользователя; • возможность создания защищенной среды виртуализации; • технологию контейнеризации с возможностью создания среды выполнения контейнеров, обеспечения работы с ними и поддержкой изоляции процессов, выполняемых в контейнерах. Значение характеристики не может изменяться участником закупки Требования к составу В составе операционной системы должна быть: - реализована возможность защиты аутентификационной информации с использованием функции хэширования; - графические средства создания единого пространства пользователей с целью реализации централизованного хранения информации об окружении пользователей и сетевой аутентификации через ldap и kerberos; - графические средства настройки защиты машинных носителей, обеспечивающие: • идентификация устрои?ств и сопоставление пользователя с устройством; • управление доступом субъектов доступа к устрои?ствам методами дискреционного управления доступом; • задание правил управления доступом, разрешающих или запрещающих доступ субъектов доступа к устрои?ствам, а также определяющих разрешенные типы доступа, в том числе с использованием атрибутов безопасности; • учет носителей информации и контроль использования интерфейсов ввода и вывода. - графические средства для работы со сторонними устройствами аутентификации - токенами, обеспечивающие следующие возможности: • двухфакторная аутентификация; • вход и разблокировка сессии по токену; • блокировка сессии при извлечении токена. - реализована возможность ограничения полномочий пользователей по использованию консолей; - реализована возможность очистки и ограничения работы с оперативной памятью. Значение характеристики не может изменяться участником закупки Требования к функциональным возможностям операционной системы Операционная система должна быть предназначена для функционирования на средствах вычислительной техники с аппаратной платформой х86-64, включая процессоры Intel не ниже 10-го поколения. Операционная система должна: - поддерживать работу на ядре Linux версии не ниже 6.1 с возможностью обновления до новых версий ядра (в соответствии с документацией на продукт). - включать в состав графические инструменты, обеспечивающие: • создание, настройку и управление несколькими репозиториями используемого программного обеспечения со следующим функционалом: 1. проверка зависимостей пакетной базы; 2. автоматическая публикация в сети по протоколам http и ftp; 3. выбор конкретных репозиториев, из которых будет произведено обновление пакетов; • управление регистрацией событий, включающее в себя управление сервисом системных событий, настройку ротации событий и настройку параметров сбора системных событий, графическое средство просмотра системных событий; • просмотр и редактирование значения переменных окружения (просматривать текущие переменные, изменять значение и описание переменных, удалять и объявлять переменные); • управление и мониторинг компонентов подсистемы безопасности; • расчёт контрольных сумм файлов и их сравнения; • оповещение пользователя о конфликте IP-адресов при подключении к сети; • работа с архивами (zip, rar, 7zip, tar, tgz, tar.gz, tar.bz, tar.xz, iso); • распечатка карточки пользователя с его параметрами. - обеспечивать поддержку файловых систем и сетевых протоколов: • ext2/3/4, fat, ntfs, XFS, ZFS, BTRFS; • TCP/IP, DHCP, DNS, FTP, TFTP, SMTP, IMAP, HTTP(S), NTP, SSH, NFS, SMB; • поддержка стандарта ISO9660; • наличие средств организации распределенной файловой системы; • наличие средств подключения ресурсов WebDAV в качестве локальной файловой системы для возможности использования их стандартными приложениями операционной системы. Значение характеристики не может изменяться участником закупки Операционная система должна обеспечивать: - среду функционирования для сертифицированных средств криптографической защиты информации, предназначенных для создания и проверки электронной подписи. - возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя, а также иметь возможность возврата к состоянию до начала установки обновлений. Установщик операционной системы должен иметь следующий функционал: - обеспечивать возможность запуска VNC сервера для удаленного подключения к клиентским машинам и управления ими как на этапе загрузки с установочного диска в главном меню программы установки, так и непосредственно в LiveCD; - иметь возможность автоматической установки при помощи файла конфигурации формата .yaml; - при установке должна предоставлять возможность добавления администратора и нескольких пользователей; - предоставлять возможность установки любых пакетов из репозитория операционной системы во время установки. Операционная система должна предоставлять: - инструмент для обновления между мажорными версиями с сохранением настроек операционной системы и ПО. - средства для локальной виртуализации (виртуальные машины, созданные на рабочей станции или удаленном сервере и используемые в однопользовательском режиме) с графическим интерфейсом управления и возможностью группировки отображаемых виртуальных машин. Средства виртуализации из состава операционной системы должны использовать системные компоненты: • qemu версии не ниже 8.2.4; • libvirt версии не ниже 10.3. Дополнительные функциональные компоненты: • web-сервер Apache или эквивалент; • почтовые сервисы и системы передачи почты: Exim, Dovecot, Postfix или эквивалент; • средства мониторинга; • средства удаленного и терминального доступа: VNC, RDP(xRDP), RemoteApp (freerdp) или эквивалент; • сервер печати; • службы резервного копирования: Bacula, Rsync или эквивалент; • аудит и журналирование событий безопасности; • набор программ для воспроизведения аудио и видео файлов; • редактор растровой графики; • запись оптических дисков; • программа сканирования; • графический сервер X.Org Xserver или эквивалент; • рабочий стол; • системные библиотеки libc или эквивалент; • компилятор GCC или эквивалент; • QT или эквивалент. Требования к комплекту поставки • тип поставки: коробка (физ. поставка); • диск с документацией; • стикер; • установочный диск; • формуляр. Значение характеристики не может изменяться участником закупки Тип техподдержки не менее уровня стандарт Значение характеристики не может изменяться участником закупки Срок действия лицензии бессрочная Значение характеристики не может изменяться участником закупки Конфигурация операционной системы сервер Значение характеристики не может изменяться участником закупки Объект лицензирования сервер 2 сокета Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Класс программ для электронных вычислительных машин и баз данных - (02.09) Операционные системы общего назначения - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки - Требования к операционной системе - Операционная система должна: - иметь графическое средство настройки ограничений пользователя по запуску программ в изолированном окружении с использованием механизма пространств имён и фильтрации системных вызовов, обеспечивающих: • ограничение прав пользователя на запуск приложений ядром системы; • ограничение прав пользователя средствами графического интерфейса; • разрешение запуска только тех программных компонентов, которые явно разрешены администратором безопасности. - обеспечивать запрет запуска (исполнения) пользователем созданных самостоятельно (с использованием текстовых редакторов или непосредственно в командной строке) программ с использованием интерпретируемых языков программирования; - включать в свой состав программное обеспечение, реализующее задачи аудита и журналирования (регистрации) событий безопасности. Регистрация событий безопасности должна выполняться с учётом требований ГОСТ Р 59548-2022; - обеспечивать возможность блокировки: • запуска исполняемых файлов, включая EXE и загрузки библиотек, в том числе DLL, .NET 7/8, целостность которых нарушена; • открытия файлов, в том числе пустых, и самораспаковывающихся 7Z архивов, установленных на контроль, при нарушении их целостности. - предоставлять средство настройки профиля системы со следующими возможностями: • настройка комплекса средств защиты в соответствии с требованиями о защите информации, предъявляемыми к определенному классу защищенности информационных систем, при помощи графического интерфейса; • импорт и экспорт настроек комплекса средств защиты системы. - обеспечивать запрет операций записи в системные каталоги и файлы (программы, файлы конфигурации), а также установки программного обеспечения, запуска и остановки системных процессов операционной системы, вне зависимости от изменения пользователем своих привилегий в текущем сеансе работы. - - Значение характеристики не может изменяться участником закупки - Операционная система должна иметь подтверждение возможности её применения для построения информационных (автоматизированных) систем, обрабатывающих информацию ограниченного доступа, и реализации функций безопасности в виде сертификатов соответствия ФСТЭК России требованиям нормативных документов: 1. «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016); 2. «Профиль защиты операционных систем типа «А» не ниже 4 класса ИТ.ОС.А4.ПЗ (ФСТЭК России, 2017); 3. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) не ниже 4 уровня; 4. «Требования по безопасности информации к средствам виртуализации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 5. «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 6. «Требования по безопасности информации к системам управления базами данных» (ФСТЭК России, 2023) не ниже 4 класса защиты. - Операционная система должна поддерживать развертывание системы централизованного управления событиями информационной безопасности, которая поставляется в рамках настоящего описания объекта закупки - Должны быть обеспечены работы по устранению уязвимостей и включению информации об уязвимостях программного обеспечения операционной системы в банк данных угроз безопасности информации ФСТЭК России (https://bdu.fstec.ru/vul). Механизмами безопасности операционной системы должна быть обеспечена защита системных и привилегированных процессов от несанкционированного доступа и управления (исключение возможности повышения привилегий пользователей и управления привилегированными процессами в случае использования дефектов/уязвимостей в программном обеспечении информационной системы). - Требования к встроенному комплексу средств защиты информации операционной системы - Операционная система должна обеспечивать встроенными сертифицированными средствами: • идентификацию и аутентификацию пользователей; • управление средствами аутентификации; • управление учетными записями пользователей, разграничение полномочий и назначение прав пользователям; • реализацию дискреционного разграничения доступа; • возможность указания параметров настройки комплекса средств защиты во время создания пользователя; • возможность создания защищенной среды виртуализации; • технологию контейнеризации с возможностью создания среды выполнения контейнеров, обеспечения работы с ними и поддержкой изоляции процессов, выполняемых в контейнерах. - - Значение характеристики не может изменяться участником закупки - Требования к составу - В составе операционной системы должна быть: - реализована возможность защиты аутентификационной информации с использованием функции хэширования; - графические средства создания единого пространства пользователей с целью реализации централизованного хранения информации об окружении пользователей и сетевой аутентификации через ldap и kerberos; - графические средства настройки защиты машинных носителей, обеспечивающие: • идентификация устрои?ств и сопоставление пользователя с устройством; • управление доступом субъектов доступа к устрои?ствам методами дискреционного управления доступом; • задание правил управления доступом, разрешающих или запрещающих доступ субъектов доступа к устрои?ствам, а также определяющих разрешенные типы доступа, в том числе с использованием атрибутов безопасности; • учет носителей информации и контроль использования интерфейсов ввода и вывода. - графические средства для работы со сторонними устройствами аутентификации - токенами, обеспечивающие следующие возможности: • двухфакторная аутентификация; • вход и разблокировка сессии по токену; • блокировка сессии при извлечении токена. - реализована возможность ограничения полномочий пользователей по использованию консолей; - реализована возможность очистки и ограничения работы с оперативной памятью. - - Значение характеристики не может изменяться участником закупки - Требования к функциональным возможностям операционной системы - Операционная система должна быть предназначена для функционирования на средствах вычислительной техники с аппаратной платформой х86-64, включая процессоры Intel не ниже 10-го поколения. Операционная система должна: - поддерживать работу на ядре Linux версии не ниже 6.1 с возможностью обновления до новых версий ядра (в соответствии с документацией на продукт). - включать в состав графические инструменты, обеспечивающие: • создание, настройку и управление несколькими репозиториями используемого программного обеспечения со следующим функционалом: 1. проверка зависимостей пакетной базы; 2. автоматическая публикация в сети по протоколам http и ftp; 3. выбор конкретных репозиториев, из которых будет произведено обновление пакетов; • управление регистрацией событий, включающее в себя управление сервисом системных событий, настройку ротации событий и настройку параметров сбора системных событий, графическое средство просмотра системных событий; • просмотр и редактирование значения переменных окружения (просматривать текущие переменные, изменять значение и описание переменных, удалять и объявлять переменные); • управление и мониторинг компонентов подсистемы безопасности; • расчёт контрольных сумм файлов и их сравнения; • оповещение пользователя о конфликте IP-адресов при подключении к сети; • работа с архивами (zip, rar, 7zip, tar, tgz, tar.gz, tar.bz, tar.xz, iso); • распечатка карточки пользователя с его параметрами. - обеспечивать поддержку файловых систем и сетевых протоколов: • ext2/3/4, fat, ntfs, XFS, ZFS, BTRFS; • TCP/IP, DHCP, DNS, FTP, TFTP, SMTP, IMAP, HTTP(S), NTP, SSH, NFS, SMB; • поддержка стандарта ISO9660; • наличие средств организации распределенной файловой системы; • наличие средств подключения ресурсов WebDAV в качестве локальной файловой системы для возможности использования их стандартными приложениями операционной системы. - - Значение характеристики не может изменяться участником закупки - Операционная система должна обеспечивать: - среду функционирования для сертифицированных средств криптографической защиты информации, предназначенных для создания и проверки электронной подписи. - возможность создания точек восстановления (снапшотов) для последующего возвращения системы к исходному состоянию в случае сбоя, а также иметь возможность возврата к состоянию до начала установки обновлений. Установщик операционной системы должен иметь следующий функционал: - обеспечивать возможность запуска VNC сервера для удаленного подключения к клиентским машинам и управления ими как на этапе загрузки с установочного диска в главном меню программы установки, так и непосредственно в LiveCD; - иметь возможность автоматической установки при помощи файла конфигурации формата .yaml; - при установке должна предоставлять возможность добавления администратора и нескольких пользователей; - предоставлять возможность установки любых пакетов из репозитория операционной системы во время установки. Операционная система должна предоставлять: - инструмент для обновления между мажорными версиями с сохранением настроек операционной системы и ПО. - средства для локальной виртуализации (виртуальные машины, созданные на рабочей станции или удаленном сервере и используемые в однопользовательском режиме) с графическим интерфейсом управления и возможностью группировки отображаемых виртуальных машин. - Средства виртуализации из состава операционной системы должны использовать системные компоненты: • qemu версии не ниже 8.2.4; • libvirt версии не ниже 10.3. Дополнительные функциональные компоненты: • web-сервер Apache или эквивалент; • почтовые сервисы и системы передачи почты: Exim, Dovecot, Postfix или эквивалент; • средства мониторинга; • средства удаленного и терминального доступа: VNC, RDP(xRDP), RemoteApp (freerdp) или эквивалент; • сервер печати; • службы резервного копирования: Bacula, Rsync или эквивалент; • аудит и журналирование событий безопасности; • набор программ для воспроизведения аудио и видео файлов; • редактор растровой графики; • запись оптических дисков; • программа сканирования; • графический сервер X.Org Xserver или эквивалент; • рабочий стол; • системные библиотеки libc или эквивалент; • компилятор GCC или эквивалент; • QT или эквивалент. - Требования к комплекту поставки - • тип поставки: коробка (физ. поставка); • диск с документацией; • стикер; • установочный диск; • формуляр. - - Значение характеристики не может изменяться участником закупки - Тип техподдержки - не менее уровня стандарт - - Значение характеристики не может изменяться участником закупки - Срок действия лицензии - бессрочная - - Значение характеристики не может изменяться участником закупки - Конфигурация операционной системы - сервер - - Значение характеристики не может изменяться участником закупки - Объект лицензирования - сервер 2 сокета - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Требования к операционной системе - Операционная система должна: - иметь графическое средство настройки ограничений пользователя по запуску программ в изолированном окружении с использованием механизма пространств имён и фильтрации системных вызовов, обеспечивающих: • ограничение прав пользователя на запуск приложений ядром системы; • ограничение прав пользователя средствами графического интерфейса; • разрешение запуска только тех программных компонентов, которые явно разрешены администратором безопасности. - обеспечивать запрет запуска (исполнения) пользователем созданных самостоятельно (с использованием текстовых редакторов или непосредственно в командной строке) программ с использованием интерпретируемых языков программирования; - включать в свой состав программное обеспечение, реализующее задачи аудита и журналирования (регистрации) событий безопасности. Регистрация событий безопасности должна выполняться с учётом требований ГОСТ Р 59548-2022; - обеспечивать возможность блокировки: • запуска исполняемых файлов, включая EXE и загрузки библиотек, в том числе DLL, .NET 7/8, целостность которых нарушена; • открытия файлов, в том числе пустых, и самораспаковывающихся 7Z архивов, установленных на контроль, при нарушении их целостности. - предоставлять средство настройки профиля системы со следующими возможностями: • настройка комплекса средств защиты в соответствии с требованиями о защите информации, предъявляемыми к определенному классу защищенности информационных систем, при помощи графического интерфейса; • импорт и экспорт настроек комплекса средств защиты системы. - обеспечивать запрет операций записи в системные каталоги и файлы (программы, файлы конфигурации), а также установки программного обеспечения, запуска и остановки системных процессов операционной системы, вне зависимости от изменения пользователем своих привилегий в текущем сеансе работы. - - Значение характеристики не может изменяться участником закупки

Операционная система должна иметь подтверждение возможности её применения для построения информационных (автоматизированных) систем, обрабатывающих информацию ограниченного доступа, и реализации функций безопасности в виде сертификатов соответствия ФСТЭК России требованиям нормативных документов: 1. «Требования безопасности информации к операционным системам» (ФСТЭК России, 2016); 2. «Профиль защиты операционных систем типа «А» не ниже 4 класса ИТ.ОС.А4.ПЗ (ФСТЭК России, 2017); 3. «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020) не ниже 4 уровня; 4. «Требования по безопасности информации к средствам виртуализации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 5. «Требования по безопасности информации к средствам контейнеризации» (ФСТЭК России, 2022) не ниже 4 класса защиты; 6. «Требования по безопасности информации к системам управления базами данных» (ФСТЭК России, 2023) не ниже 4 класса защиты.

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

Должны быть обеспечены работы по устранению уязвимостей и включению информации об уязвимостях программного обеспечения операционной системы в банк данных угроз безопасности информации ФСТЭК России (https://bdu.fstec.ru/vul). Механизмами безопасности операционной системы должна быть обеспечена защита системных и привилегированных процессов от несанкционированного доступа и управления (исключение возможности повышения привилегий пользователей и управления привилегированными процессами в случае использования дефектов/уязвимостей в программном обеспечении информационной системы).

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

Требования к составу - В составе операционной системы должна быть: - реализована возможность защиты аутентификационной информации с использованием функции хэширования; - графические средства создания единого пространства пользователей с целью реализации централизованного хранения информации об окружении пользователей и сетевой аутентификации через ldap и kerberos; - графические средства настройки защиты машинных носителей, обеспечивающие: • идентификация устрои?ств и сопоставление пользователя с устройством; • управление доступом субъектов доступа к устрои?ствам методами дискреционного управления доступом; • задание правил управления доступом, разрешающих или запрещающих доступ субъектов доступа к устрои?ствам, а также определяющих разрешенные типы доступа, в том числе с использованием атрибутов безопасности; • учет носителей информации и контроль использования интерфейсов ввода и вывода. - графические средства для работы со сторонними устройствами аутентификации - токенами, обеспечивающие следующие возможности: • двухфакторная аутентификация; • вход и разблокировка сессии по токену; • блокировка сессии при извлечении токена. - реализована возможность ограничения полномочий пользователей по использованию консолей; - реализована возможность очистки и ограничения работы с оперативной памятью. - - Значение характеристики не может изменяться участником закупки

Требования к функциональным возможностям операционной системы - Операционная система должна быть предназначена для функционирования на средствах вычислительной техники с аппаратной платформой х86-64, включая процессоры Intel не ниже 10-го поколения. Операционная система должна: - поддерживать работу на ядре Linux версии не ниже 6.1 с возможностью обновления до новых версий ядра (в соответствии с документацией на продукт). - включать в состав графические инструменты, обеспечивающие: • создание, настройку и управление несколькими репозиториями используемого программного обеспечения со следующим функционалом: 1. проверка зависимостей пакетной базы; 2. автоматическая публикация в сети по протоколам http и ftp; 3. выбор конкретных репозиториев, из которых будет произведено обновление пакетов; • управление регистрацией событий, включающее в себя управление сервисом системных событий, настройку ротации событий и настройку параметров сбора системных событий, графическое средство просмотра системных событий; • просмотр и редактирование значения переменных окружения (просматривать текущие переменные, изменять значение и описание переменных, удалять и объявлять переменные); • управление и мониторинг компонентов подсистемы безопасности; • расчёт контрольных сумм файлов и их сравнения; • оповещение пользователя о конфликте IP-адресов при подключении к сети; • работа с архивами (zip, rar, 7zip, tar, tgz, tar.gz, tar.bz, tar.xz, iso); • распечатка карточки пользователя с его параметрами. - обеспечивать поддержку файловых систем и сетевых протоколов: • ext2/3/4, fat, ntfs, XFS, ZFS, BTRFS; • TCP/IP, DHCP, DNS, FTP, TFTP, SMTP, IMAP, HTTP(S), NTP, SSH, NFS, SMB; • поддержка стандарта ISO9660; • наличие средств организации распределенной файловой системы; • наличие средств подключения ресурсов WebDAV в качестве локальной файловой системы для возможности использования их стандартными приложениями операционной системы. - - Значение характеристики не может изменяться участником закупки

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

Средства виртуализации из состава операционной системы должны использовать системные компоненты: • qemu версии не ниже 8.2.4; • libvirt версии не ниже 10.3. Дополнительные функциональные компоненты: • web-сервер Apache или эквивалент; • почтовые сервисы и системы передачи почты: Exim, Dovecot, Postfix или эквивалент; • средства мониторинга; • средства удаленного и терминального доступа: VNC, RDP(xRDP), RemoteApp (freerdp) или эквивалент; • сервер печати; • службы резервного копирования: Bacula, Rsync или эквивалент; • аудит и журналирование событий безопасности; • набор программ для воспроизведения аудио и видео файлов; • редактор растровой графики; • запись оптических дисков; • программа сканирования; • графический сервер X.Org Xserver или эквивалент; • рабочий стол; • системные библиотеки libc или эквивалент; • компилятор GCC или эквивалент; • QT или эквивалент.

Требования к комплекту поставки - • тип поставки: коробка (физ. поставка); • диск с документацией; • стикер; • установочный диск; • формуляр. - - Значение характеристики не может изменяться участником закупки

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

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

Конфигурация операционной системы - сервер - - Значение характеристики не может изменяться участником закупки

Объект лицензирования - сервер 2 сокета - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге В соответствии с требованиями постановления Правительства Российской Федерации от 08.02.2017 №145 «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – КТРУ), для детального описания закупаемого товара, отвечающего требованиям Заказчика, и в целях улучшения качества выполнения своих функциональных обязанностей, помимо показателей, которые применялись Заказчиком из КТРУ, были использованы показатели с дополнительными функциональными, техническими и качественными характеристиками, не внесенными в КТРУ. В связи с тем, что описание соответствующей позиции каталога не содержит специфических характеристик, необходимых для удовлетворения потребностей Заказчика.

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

АДМИНИСТРАЦИЯ ГОРОДА КУРГАНА - 1 -

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

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

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

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

Состав инсталляционного комплекта - В состав инсталляционного комплекта должны входить: Дистрибутив системы в защищенном футляре на DVD, формуляр изготовителя, приложение 1 к формуляру, заверенная копия сертификата соответствия СУС ИБ требованиям по безопасности информации, руководство администратора, руководство пользователя. - - Значение характеристики не может изменяться участником закупки

Инсталляционный комплект предоставляется на поставляемую в рамках настоящего описания объекта закупки систему централизованного управления событиями информационной безопасности. - соответствие - -

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге В соответствии с требованиями постановления Правительства Российской Федерации от 08.02.2017 №145 «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд» (далее – КТРУ), для детального описания закупаемого товара, отвечающего требованиям Заказчика, и в целях улучшения качества выполнения своих функциональных обязанностей, помимо показателей, которые применялись Заказчиком из КТРУ, были использованы показатели с дополнительными функциональными, техническими и качественными характеристиками, не внесенными в КТРУ. В связи с тем, что описание соответствующей позиции каталога не содержит специфических характеристик, необходимых для удовлетворения потребностей заказчика.

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

Преимущества: Преимущество в соответствии с ч. 3 ст. 30 Закона № 44-ФЗ - Размер преимущества не установлен

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

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

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

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

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

Начальная (максимальная) цена контракта: 2 281 400,00

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

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

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

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

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

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

Наименование бюджета: Бюджет города Кургана

Вид бюджета: местный бюджет

Код территории муниципального образования: 37701000: Муниципальные образования Курганской области / Городские округа Курганской области/ / город Курган

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

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

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Порядок предоставления обеспечения заявки определен статьей 44 Федерального закона № 44-ФЗ. Обеспечение заявки на участие в закупке может предоставляться участником закупки в виде денежных средств (путем блокирования денежных средств, внесенных участником закупки на банковский счет, открытый таким участником в банке, включенном в перечень, утвержденный распоряжением Правительства РФ от 13 июля 2018 года № 1451-р) или независимой гарантии, соответствующей требованиям статьи 45 Федерального закона № 44-ФЗ. Участник закупки для подачи заявки на участие в закупке выбирает с использованием электронной площадки способ обеспечения такой заявки путем указания реквизитов специального счета или указания номера реестровой записи из реестра независимых гарантий, размещенного в единой информационной системе. Срок действия независимой гарантии должен составлять не менее месяца с даты окончания срока подачи заявок. Государственные, муниципальные учреждения не предоставляют обеспечение подаваемых ими заявок на участие в закупках. Предприятия уголовно-исполнительной системы, организации инвалидов, предусмотренные частью 2 статьи 29 Федерального закона № 44-ФЗ, предоставляют обеспечение заявки на участие в закупке в размере 0,5% НМЦК. Постановлением Правительства Российской Федерации от 10 апреля 2023 года N 579 для участников закупки (за исключением закупок, участниками которых в соответствии с частью 3 статьи 30 Федерального закона № 44-ФЗ, могут быть только СМП, СОНКО), являющихся юридическими лицами, зарегистрированными на территории государства - члена Евразийского экономического союза, за исключением Российской Федерации, или физическими лицами, являющимися гражданами государства - члена Евразийского экономического союза, за исключением Российской Федерации, предусмотрены особенности предоставления обеспечения заявок в виде денежных средств (см. Раздел III приложения «Требования к содержанию, составу заявки на участие в ЭА, инструкция по ее заполнению»).

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03100643000000014300, л/c 04433021320, БИК 045004108, ОКЦ № 1 СибГУ Банка России//УФК по Курганской области, г Курган, к/c 40102810445370000108

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

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

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл. Курганская, г.о. город Курган, г. Курган, пл. имени В.И. Ленина, д. 1

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

Размер обеспечения исполнения контракта: 5 %

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Порядок предоставления обеспечения исполнения контракта, требования к такому обеспечению определены статьей 96 Федерального закона № 44-ФЗ. Исполнение контракта может обеспечиваться предоставлением независимой гарантии, соответствующей требованиям статьи 45 Федерального закона № 44-ФЗ, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия независимой гарантии определяются в соответствии с требованиями Федерального закона № 44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. При этом срок действия независимой гарантии должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой независимой гарантией, не менее чем на 1 месяц, в том числе в случае его изменения в соответствии со статьей 95 Федерального закона № 44-ФЗ. В случае наступления события, предусмотренного статьей 37 Федерального закона № 44-ФЗ, участник закупки, с которым заключается контракт, предоставляет обеспечение исполнения контракта с учетом положений указанной статьи. Особенности предоставления обеспечения исполнения контракта, заключаемого по результатам определения поставщика (подрядчика, исполнителя) в соответствии с пунктом 1 части 1 статьи 30 Федерального закона № 44-ФЗ, определены частями 6.2, 8.1 статьи 96 Федерального закона № 44-ФЗ. Обеспечение исполнения контракта не требуется в случаях, предусмотренных частью 8 статьи 96 Федерального закона № 44-ФЗ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03232643377010004300, л/c 998.01.023.3, БИК 045004108, ОКЦ № 1 СибГУ Банка России//УФК по Курганской области, г Курган, к/c 40102810445370000108

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

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Объем предоставления гарантий качества не менее уровня стандарт на срок не менее 12 месяцев

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

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

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

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

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

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

Наименование бюджета: Бюджет города Кургана

Вид бюджета: местный бюджет

Код территории муниципального образования: 37701000: Муниципальные образования Курганской области / Городские округа Курганской области/ / город Курган

Документы

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

Документы

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