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

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

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

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

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

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

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

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

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

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

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

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

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

Почтовый адрес: Российская Федерация, 125373, Москва, Походный, Д. 3

Место нахождения: Российская Федерация, 125373, Москва, Походный, Д. 3

Ответственное должностное лицо: Татаринова О. Г.

Адрес электронной почты: o.tatarinova.r9965@tax.gov.ru

Номер контактного телефона: 7-495-1985307

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

Регион: Москва

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

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

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

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

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

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

Начальная (максимальная) цена контракта: 10 647 000,00

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

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

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

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

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

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

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

Наименование бюджета: Федеральный бюджет

Вид бюджета: федеральный бюджет

Код территории муниципального образования: 00000001:

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

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

- 58.29.50.000 - Продление программного обеспечения подсистемы защиты приложений от несанкционированного доступа Application Firewall Общие требования к функциям системы Подсистема должна поддерживать кластеризацию с обеспечением отказоустойчивости. Подсистема должна поддерживать следующие режимы работы: Обратный прокси-сервер (reverse proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак; Мониторинг (sniffer). Назначение: Анализ трафика без возможности блокировки запросов и предотвращения атак. Об обнаруженных атаках отправляются уведомления; Сетевой мост (bridge). Назначение: Режим предназначен для обнаружения вторжений без вмешательства в работу приложений; Прозрачный прокси-сервер (transparent proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак в прозрачном режиме; Автономный режим (forensic). Назначение: Офлайн-анализ журналов веб-сервера, сетевых дампов на предмет обнаружения в них следов атак. ... Подсистема обнаружения и предотвращения атак Подсистема должна осуществлять контроль структуры HTTP-запросов: – контроль соответствия структуры запроса RFC 2616; – перечня разрешенных методов HTTP; – максимального количества заголовков HTTP-запроса и максимальной длины каждого из них; – максимального размера запроса; – максимального времени ожидания заголовка запроса; – максимального времени ожидания тела запроса; – перечня допустимых типов данных в запросе. Подсистема должна автоматически с использованием технологии машинного обучения формировать вероятностную модель данных для каждого атрибута HTTP-запроса и контролировать отклонение от нее. Подсистема должна обеспечивать защиту от SQL-инъекций путем обнаружения и блокирования запросов, содержащих выражения языка SQL. Подсистема должна осуществлять обнаружение и блокирование XSS-атак, в том числе: – stored XSS (хранимого XSS); – reflected XSS (отраженного XSS); – DOM Based XSS. Подсистема должна осуществлять обнаружение и блокирование уязвимости открытого перенаправления (Open Redirect): – в HTTP-заголовке Location; – HTML-теге Meta; – HTTP-заголовке Refresh. Подсистема должна обеспечивать защиту от атак класса CSRF путем: – добавления CSRF-токена к ответам приложения; – обнаружения или блокирования POST-запросов с отсутствующим или неверным CSRF-токеном ... Подсистема проактивной защиты Подсистема должна запрещать доступ к веб-приложению через анонимные сервисы (Tor, VPN, анонимайзеры). Подсистема должна запрещать модификации данных форм и cookie на стороне клиента путем контроля их неизменности между запросом и ответом. Подсистема должна обеспечивать автоматическое формирование CSP на основе анализа работы защищаемого приложения с возможностью применения сформированной политики после периода обучения. Подсистема должна обеспечивать обнаружение признаков кражи сессионного идентификатора пользователя и блокировку попыток доступа с использованием скомпрометированного идентификатора - Штука - 3,00 - 3 549 000,00 - 10 647 000,00

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Общие требования к функциям системы Подсистема должна поддерживать кластеризацию с обеспечением отказоустойчивости. Подсистема должна поддерживать следующие режимы работы: Обратный прокси-сервер (reverse proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак; Мониторинг (sniffer). Назначение: Анализ трафика без возможности блокировки запросов и предотвращения атак. Об обнаруженных атаках отправляются уведомления; Сетевой мост (bridge). Назначение: Режим предназначен для обнаружения вторжений без вмешательства в работу приложений; Прозрачный прокси-сервер (transparent proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак в прозрачном режиме; Автономный режим (forensic). Назначение: Офлайн-анализ журналов веб-сервера, сетевых дампов на предмет обнаружения в них следов атак. Значение характеристики не может изменяться участником закупки В состав системы должны входить следующие функциональные подсистемы: – обнаружения и предотвращения атак; – проактивной защиты; – подтверждения уязвимостей; – разграничения доступа; – интеграции; – управления Подсистема обнаружения и предотвращения атак. Назначение: Подсистема обнаружения атак обеспечивает анализ заголовков и содержимого HTTP-пакетов с запросами пользователей и ответами приложения Подсистема проактивной защиты. Назначение: Подсистема проактивной защиты позволяет использовать априорные решения об атаках и злоумышленниках для снижения вероятности проведения атак Подсистема подтверждения уязвимостей. Назначение: Подсистема подтверждения уязвимостей предназначена для динамического анализа уязвимостей и обнаружения атак с целью снижения количества ложных срабатываний Подсистема разграничения доступа. Назначение: Подсистема разграничения доступа предназначена для идентификации пользователя по его учетным данным, используемым в защищаемом приложении, и контроля доступа пользователя к отдельным частям приложения Подсистема интеграции. Назначение: Подсистема интеграции представляет собой набор интерфейсов и протоколов для взаимодействия с внешними системами Подсистема управления. Назначение: Подсистема управления обеспечивает бесперебойную работу всех компонентов подсистемы защиты приложений от несанкционированного доступа и их взаимодействие между собой, а также предоставляет консольный и графический интерфейс управления Допускается объединение двух или нескольких функциональных подсистем в одну с сохранением реализуемых функций, либо разделение одной функциональной подсистемы на несколько. Доступ к подсистеме защиты приложений от несанкционированного доступа должен осуществляться по защищенному сетевому соединению. Подсистема защиты приложений от несанкционированного доступа должна выдерживать нагрузку до 10 000 RPS (запросов в секунду). Подсистема защиты приложений от несанкционированного доступа должна осуществлять обнаружение сетевых атак (вторжений), направленных на веб-приложения, следующими способами: – сигнатурный метод — посредством сопоставления параметров (частей) текущих запросов на доступ с сигнатурами атак, которые содержатся в БД; – профилирование — посредством построения модели работы приложения или пользователя и обнаружения аномальных отклонений; – проактивная защита — посредством использования априорных решений об атаках и злоумышленниках для снижения вероятности проведения атак. Подсистема защиты приложений от несанкционированного доступа должна поддерживать протоколы: – HTTP, – HTTPS включая SSL v3, TLS v1.0, v1.1, v1.2, – Simple Object Access Protocol (SOAP), – eXtensible Markup Language (XML), – JavaScript Object Notation (JSON) Подсистема защиты приложений от несанкционированного доступа должна осуществлять контроль трафика: разрешение, блокирование и (или) генерацию предупреждения. Подсистема защиты приложений от несанкционированного доступа должна обеспечивать хранение информации об атаках для дальнейшего анализа. Подсистема защиты приложений от несанкционированного доступа должна предоставлять оператору возможность определить, по какой причине трафик был классифицирован как вредоносный. Взаимодействие пользователей с Подсистема защиты приложений от несанкционированного доступа должно осуществляться посредством графического интерфейса пользователя. Графический интерфейс пользователя Подсистема защиты приложений от несанкционированного доступа должен быть выполнен на русском и английском языках. Должна быть совместима с существующей Подсистемой защиты приложений от несанкционированного доступа без дополнительных доработок Подсистема обнаружения и предотвращения атак Подсистема должна осуществлять контроль структуры HTTP-запросов: – контроль соответствия структуры запроса RFC 2616; – перечня разрешенных методов HTTP; – максимального количества заголовков HTTP-запроса и максимальной длины каждого из них; – максимального размера запроса; – максимального времени ожидания заголовка запроса; – максимального времени ожидания тела запроса; – перечня допустимых типов данных в запросе. Подсистема должна автоматически с использованием технологии машинного обучения формировать вероятностную модель данных для каждого атрибута HTTP-запроса и контролировать отклонение от нее. Подсистема должна обеспечивать защиту от SQL-инъекций путем обнаружения и блокирования запросов, содержащих выражения языка SQL. Подсистема должна осуществлять обнаружение и блокирование XSS-атак, в том числе: – stored XSS (хранимого XSS); – reflected XSS (отраженного XSS); – DOM Based XSS. Подсистема должна осуществлять обнаружение и блокирование уязвимости открытого перенаправления (Open Redirect): – в HTTP-заголовке Location; – HTML-теге Meta; – HTTP-заголовке Refresh. Подсистема должна обеспечивать защиту от атак класса CSRF путем: – добавления CSRF-токена к ответам приложения; – обнаружения или блокирования POST-запросов с отсутствующим или неверным CSRF-токеном Значение характеристики не может изменяться участником закупки Подсистема должна осуществлять обнаружение и блокирование атаки на уязвимости, связанные с обработкой формата XML, путем: – контроля соответствия XML-сообщения рекомендациям консорциума W3C (https://www.w3.org/TR/REC-xml/); – контроля соответствия XML-сообщения формату, заданному в виде схемы XSD; – контроля соответствия запроса описанию сервиса, заданному в виде схемы WSDL; – контроля наличия внешних сущностей и ссылок на них (external entity) в XML-сообщении; – контроля максимального уровня вложенности в структуре XML-сообщения. Подсистема должна обеспечивать защиту от утечек данных путем обнаружения и маскирования чувствительных данных в ответах приложения. Подсистема должна осуществлять контроль автоматизированной активности: – выявление и блокирование запросов роботов и других средств автоматизации, основанное на сигнатурном анализе запросов и эвристическом анализе возможностей клиентского ПО; – контроль доступа «хороших роботов» (поисковых систем и т. п.). Подсистема должна обеспечивать защиту от DDoS-атак уровня приложения путем: – постоянного анализа действий пользователей и кластеризации их по схожему поведению с использованием технологии машинного обучения; – обнаружения DDoS-атак за счет контроля показателей работы приложения: • количество запросов в секунду; • количество ошибок сервера; • среднее время ответа; – прогнозирования DDoS-атак путем экстраполяции текущих значений контролируемых показателей работы приложения; – блокировки групп пользователей, оказывающих существенное влияние на показатели работы приложения Подсистема проактивной защиты Подсистема должна запрещать доступ к веб-приложению через анонимные сервисы (Tor, VPN, анонимайзеры). Подсистема должна запрещать модификации данных форм и cookie на стороне клиента путем контроля их неизменности между запросом и ответом. Подсистема должна обеспечивать автоматическое формирование CSP на основе анализа работы защищаемого приложения с возможностью применения сформированной политики после периода обучения. Подсистема должна обеспечивать обнаружение признаков кражи сессионного идентификатора пользователя и блокировку попыток доступа с использованием скомпрометированного идентификатора Значение характеристики не может изменяться участником закупки Подсистема подтверждения уязвимостей Подсистема должна иметь возможность подтверждения наличия уязвимости в веб-приложении путем сканирования объекта атаки Значение характеристики не может изменяться участником закупки Подсистема разграничения доступа Подсистема должна обеспечивать возможность идентификации пользователя приложения на основании его успешных попыток входа в приложение с использованием: – аутентификации через HTML-форму; – аутентификации HTTP Basic. Подсистема должна осуществлять контроль доступа пользователей к приложению в целом и отдельным его частям Значение характеристики не может изменяться участником закупки Подсистема интеграции Подсистема должна иметь возможность интеграции: – с системами управления событиями информационной безопасности (SIEM) в части передачи информации об обнаруженных атаках; – системами защиты от утечек данных (DLP) в части анализа пересылаемых через защищаемое приложение файлов на наличие чувствительных данных; – системами статического анализа кода (SAST) для автоматического формирования правил блокировки уязвимостей (virtual patching), обнаруженных в ходе анализа исходного кода веб-приложений; – системами мониторинга состояния сетевого оборудования в части предоставления информации о состоянии аппаратной части системы; – электронной почтой для оповещения персонала об обнаруженных атаках; – сервисами для защиты от атак отказа в обслуживании (DDoS); – межсетевыми экранами в части передачи адресов атакующего для блокировки. Подсистема должна предоставлять программный интерфейс (API) для автоматизации задач по управлению системой с помощью внешних программных средств Значение характеристики не может изменяться участником закупки Подсистема управления Подсистема должна обеспечивать аутентификацию обслуживающего персонала на основании имени учетной записи и пароля. Подсистема должна обеспечивать регистрацию действий эксплуатирующего персонала при работе с компонентами системы. Подсистема должна обеспечивать функцию разграничения доступа обслуживающего персонала к настройке системы. Подсистема должна предоставлять визуальные возможности для оперативного информирования эксплуатирующего персонала о событиях ИБ, вызванных инцидентами ИБ. Подсистема должна обеспечивать возможность настройки компонентов Подсистемы защиты приложений от несанкционированного доступа и профилей защиты приложений, переключения режимов защиты приложений. Подсистема должна обеспечивать функцию архивации и восстановления компонентов и данных Подсистемы защиты приложений от несанкционированного доступа. Подсистема должна обеспечивать возможность обновления модулей и сигнатур атак. Подсистема должна предоставлять оператору возможность изменять сигнатуры в базе данных, а также переопределять реакцию на атаки Значение характеристики не может изменяться участником закупки Подсистема должна иметь следующие механизмы управления событиями (атаками): – механизм сортировки по любому из отображаемых атрибутов событий; – механизм фильтрации событий по любому из отображаемых атрибутов событий или их комбинации; – механизм группировки однотипных событий; – механизм корреляции, позволяющий группировать взаимосвязанные события и выявлять комплексные атаки с использованием предустановленных правил и (или) правил, созданных пользователем. Подсистема должна предоставлять возможность просмотра информации о событии в краткой и полной форме. Подсистема должна предоставлять следующую информацию о событии: – информацию об источнике атаки: • IP-адрес и порт; • информацию о местоположении (страна, регион, город); • версию ОС; • версию браузера; • полный перечень параметров и заголовков запроса и их значений; • имя пользователя в приложении (если известно); – информацию о цели атаки: • идентификатор защищаемого приложения; • адрес, на который направлена атака (URL); • код состояния ответа; • полный перечень заголовков ответа; • содержимое ответа; • время ответа; – информация о самой атаке: • идентификатор защитного механизма, обнаружившего атаку; • описание атаки; • атрибут запроса или ответа, в котором были обнаружены признаки атаки; • уникальный идентификатор события; • перечень действий, выполненных по результатам атаки; • приоритет (важность события) Подсистема должна предоставлять сводную информацию об атаках в графическом виде (графики, круговые диаграммы, гистограммы, географическое распределение). Подсистема должна предоставлять возможность выполнения непосредственно из таблицы, содержащей перечень событий, следующих часто используемых действий: – проверка наличия уязвимости, на которую направлена атака; – блокировка атакующего; – добавление правила для фильтрации ложного срабатывания. Подсистема должна предоставлять информацию о статусе компонентов Подсистемы и текущей загрузке Требования к сертификации ПО Программное обеспечение Подсистемы защиты приложений от несанкционированного доступа должно иметь сертификат ФСТЭК России на соответствие требованиям руководящего документа «на соответствие требованиям руководящих документах «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» - по 4 уровню доверия Значение характеристики не может изменяться участником закупки Требования к объему, содержанию и условиям передачи прав Требования к объему продлеваемых прав – право использования результатов интеллектуальной деятельности – программного обеспечения, осуществляется на условиях простой неисключительной лицензии, способом воспроизведения, ограниченного инсталляцией, запуском и копированием программного обеспечения. Срок передачи продления прав использования программного обеспечения: в течение 10 (десяти) дней с даты заключения Контракта. Территория использования программного обеспечения, неисключительные права на которое предоставляются – Российская Федерация. Срок, на который продлеваются неисключительные права – с момента окончания действия соответствующих лицензий на 1 год. В указанный срок Исполнитель обязан обеспечить гарантийное сопровождение программного обеспечения на следующих условиях: – предоставление обновлений программного обеспечения; – предоставление новых версий программного обеспечения; – предоставление консультаций по телефону и электронной почте в рабочие дни в рабочее время Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Общие требования к функциям системы - Подсистема должна поддерживать кластеризацию с обеспечением отказоустойчивости. Подсистема должна поддерживать следующие режимы работы: Обратный прокси-сервер (reverse proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак; Мониторинг (sniffer). Назначение: Анализ трафика без возможности блокировки запросов и предотвращения атак. Об обнаруженных атаках отправляются уведомления; Сетевой мост (bridge). Назначение: Режим предназначен для обнаружения вторжений без вмешательства в работу приложений; Прозрачный прокси-сервер (transparent proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак в прозрачном режиме; Автономный режим (forensic). Назначение: Офлайн-анализ журналов веб-сервера, сетевых дампов на предмет обнаружения в них следов атак. - - Значение характеристики не может изменяться участником закупки - В состав системы должны входить следующие функциональные подсистемы: – обнаружения и предотвращения атак; – проактивной защиты; – подтверждения уязвимостей; – разграничения доступа; – интеграции; – управления - Подсистема обнаружения и предотвращения атак. Назначение: Подсистема обнаружения атак обеспечивает анализ заголовков и содержимого HTTP-пакетов с запросами пользователей и ответами приложения - Подсистема проактивной защиты. Назначение: Подсистема проактивной защиты позволяет использовать априорные решения об атаках и злоумышленниках для снижения вероятности проведения атак - Подсистема подтверждения уязвимостей. Назначение: Подсистема подтверждения уязвимостей предназначена для динамического анализа уязвимостей и обнаружения атак с целью снижения количества ложных срабатываний - Подсистема разграничения доступа. Назначение: Подсистема разграничения доступа предназначена для идентификации пользователя по его учетным данным, используемым в защищаемом приложении, и контроля доступа пользователя к отдельным частям приложения - Подсистема интеграции. Назначение: Подсистема интеграции представляет собой набор интерфейсов и протоколов для взаимодействия с внешними системами - Подсистема управления. Назначение: Подсистема управления обеспечивает бесперебойную работу всех компонентов подсистемы защиты приложений от несанкционированного доступа и их взаимодействие между собой, а также предоставляет консольный и графический интерфейс управления - Допускается объединение двух или нескольких функциональных подсистем в одну с сохранением реализуемых функций, либо разделение одной функциональной подсистемы на несколько. Доступ к подсистеме защиты приложений от несанкционированного доступа должен осуществляться по защищенному сетевому соединению. Подсистема защиты приложений от несанкционированного доступа должна выдерживать нагрузку до 10 000 RPS (запросов в секунду). Подсистема защиты приложений от несанкционированного доступа должна осуществлять обнаружение сетевых атак (вторжений), направленных на веб-приложения, следующими способами: – сигнатурный метод — посредством сопоставления параметров (частей) текущих запросов на доступ с сигнатурами атак, которые содержатся в БД; – профилирование — посредством построения модели работы приложения или пользователя и обнаружения аномальных отклонений; – проактивная защита — посредством использования априорных решений об атаках и злоумышленниках для снижения вероятности проведения атак. Подсистема защиты приложений от несанкционированного доступа должна поддерживать протоколы: – HTTP, – HTTPS включая SSL v3, TLS v1.0, v1.1, v1.2, – Simple Object Access Protocol (SOAP), – eXtensible Markup Language (XML), – JavaScript Object Notation (JSON) - Подсистема защиты приложений от несанкционированного доступа должна осуществлять контроль трафика: разрешение, блокирование и (или) генерацию предупреждения. Подсистема защиты приложений от несанкционированного доступа должна обеспечивать хранение информации об атаках для дальнейшего анализа. Подсистема защиты приложений от несанкционированного доступа должна предоставлять оператору возможность определить, по какой причине трафик был классифицирован как вредоносный. Взаимодействие пользователей с Подсистема защиты приложений от несанкционированного доступа должно осуществляться посредством графического интерфейса пользователя. Графический интерфейс пользователя Подсистема защиты приложений от несанкционированного доступа должен быть выполнен на русском и английском языках. Должна быть совместима с существующей Подсистемой защиты приложений от несанкционированного доступа без дополнительных доработок - Подсистема обнаружения и предотвращения атак - Подсистема должна осуществлять контроль структуры HTTP-запросов: – контроль соответствия структуры запроса RFC 2616; – перечня разрешенных методов HTTP; – максимального количества заголовков HTTP-запроса и максимальной длины каждого из них; – максимального размера запроса; – максимального времени ожидания заголовка запроса; – максимального времени ожидания тела запроса; – перечня допустимых типов данных в запросе. Подсистема должна автоматически с использованием технологии машинного обучения формировать вероятностную модель данных для каждого атрибута HTTP-запроса и контролировать отклонение от нее. Подсистема должна обеспечивать защиту от SQL-инъекций путем обнаружения и блокирования запросов, содержащих выражения языка SQL. Подсистема должна осуществлять обнаружение и блокирование XSS-атак, в том числе: – stored XSS (хранимого XSS); – reflected XSS (отраженного XSS); – DOM Based XSS. Подсистема должна осуществлять обнаружение и блокирование уязвимости открытого перенаправления (Open Redirect): – в HTTP-заголовке Location; – HTML-теге Meta; – HTTP-заголовке Refresh. Подсистема должна обеспечивать защиту от атак класса CSRF путем: – добавления CSRF-токена к ответам приложения; – обнаружения или блокирования POST-запросов с отсутствующим или неверным CSRF-токеном - - Значение характеристики не может изменяться участником закупки - Подсистема должна осуществлять обнаружение и блокирование атаки на уязвимости, связанные с обработкой формата XML, путем: – контроля соответствия XML-сообщения рекомендациям консорциума W3C (https://www.w3.org/TR/REC-xml/); – контроля соответствия XML-сообщения формату, заданному в виде схемы XSD; – контроля соответствия запроса описанию сервиса, заданному в виде схемы WSDL; – контроля наличия внешних сущностей и ссылок на них (external entity) в XML-сообщении; – контроля максимального уровня вложенности в структуре XML-сообщения. Подсистема должна обеспечивать защиту от утечек данных путем обнаружения и маскирования чувствительных данных в ответах приложения. Подсистема должна осуществлять контроль автоматизированной активности: – выявление и блокирование запросов роботов и других средств автоматизации, основанное на сигнатурном анализе запросов и эвристическом анализе возможностей клиентского ПО; – контроль доступа «хороших роботов» (поисковых систем и т. п.). Подсистема должна обеспечивать защиту от DDoS-атак уровня приложения путем: – постоянного анализа действий пользователей и кластеризации их по схожему поведению с использованием технологии машинного обучения; – обнаружения DDoS-атак за счет контроля показателей работы приложения: • количество запросов в секунду; • количество ошибок сервера; • среднее время ответа; – прогнозирования DDoS-атак путем экстраполяции текущих значений контролируемых показателей работы приложения; – блокировки групп пользователей, оказывающих существенное влияние на показатели работы приложения - Подсистема проактивной защиты - Подсистема должна запрещать доступ к веб-приложению через анонимные сервисы (Tor, VPN, анонимайзеры). Подсистема должна запрещать модификации данных форм и cookie на стороне клиента путем контроля их неизменности между запросом и ответом. Подсистема должна обеспечивать автоматическое формирование CSP на основе анализа работы защищаемого приложения с возможностью применения сформированной политики после периода обучения. Подсистема должна обеспечивать обнаружение признаков кражи сессионного идентификатора пользователя и блокировку попыток доступа с использованием скомпрометированного идентификатора - - Значение характеристики не может изменяться участником закупки - Подсистема подтверждения уязвимостей - Подсистема должна иметь возможность подтверждения наличия уязвимости в веб-приложении путем сканирования объекта атаки - - Значение характеристики не может изменяться участником закупки - Подсистема разграничения доступа - Подсистема должна обеспечивать возможность идентификации пользователя приложения на основании его успешных попыток входа в приложение с использованием: – аутентификации через HTML-форму; – аутентификации HTTP Basic. Подсистема должна осуществлять контроль доступа пользователей к приложению в целом и отдельным его частям - - Значение характеристики не может изменяться участником закупки - Подсистема интеграции - Подсистема должна иметь возможность интеграции: – с системами управления событиями информационной безопасности (SIEM) в части передачи информации об обнаруженных атаках; – системами защиты от утечек данных (DLP) в части анализа пересылаемых через защищаемое приложение файлов на наличие чувствительных данных; – системами статического анализа кода (SAST) для автоматического формирования правил блокировки уязвимостей (virtual patching), обнаруженных в ходе анализа исходного кода веб-приложений; – системами мониторинга состояния сетевого оборудования в части предоставления информации о состоянии аппаратной части системы; – электронной почтой для оповещения персонала об обнаруженных атаках; – сервисами для защиты от атак отказа в обслуживании (DDoS); – межсетевыми экранами в части передачи адресов атакующего для блокировки. Подсистема должна предоставлять программный интерфейс (API) для автоматизации задач по управлению системой с помощью внешних программных средств - - Значение характеристики не может изменяться участником закупки - Подсистема управления - Подсистема должна обеспечивать аутентификацию обслуживающего персонала на основании имени учетной записи и пароля. Подсистема должна обеспечивать регистрацию действий эксплуатирующего персонала при работе с компонентами системы. Подсистема должна обеспечивать функцию разграничения доступа обслуживающего персонала к настройке системы. Подсистема должна предоставлять визуальные возможности для оперативного информирования эксплуатирующего персонала о событиях ИБ, вызванных инцидентами ИБ. Подсистема должна обеспечивать возможность настройки компонентов Подсистемы защиты приложений от несанкционированного доступа и профилей защиты приложений, переключения режимов защиты приложений. Подсистема должна обеспечивать функцию архивации и восстановления компонентов и данных Подсистемы защиты приложений от несанкционированного доступа. Подсистема должна обеспечивать возможность обновления модулей и сигнатур атак. Подсистема должна предоставлять оператору возможность изменять сигнатуры в базе данных, а также переопределять реакцию на атаки - - Значение характеристики не может изменяться участником закупки - Подсистема должна иметь следующие механизмы управления событиями (атаками): – механизм сортировки по любому из отображаемых атрибутов событий; – механизм фильтрации событий по любому из отображаемых атрибутов событий или их комбинации; – механизм группировки однотипных событий; – механизм корреляции, позволяющий группировать взаимосвязанные события и выявлять комплексные атаки с использованием предустановленных правил и (или) правил, созданных пользователем. Подсистема должна предоставлять возможность просмотра информации о событии в краткой и полной форме. Подсистема должна предоставлять следующую информацию о событии: – информацию об источнике атаки: • IP-адрес и порт; • информацию о местоположении (страна, регион, город); • версию ОС; • версию браузера; • полный перечень параметров и заголовков запроса и их значений; • имя пользователя в приложении (если известно); – информацию о цели атаки: • идентификатор защищаемого приложения; • адрес, на который направлена атака (URL); • код состояния ответа; • полный перечень заголовков ответа; • содержимое ответа; • время ответа; – информация о самой атаке: • идентификатор защитного механизма, обнаружившего атаку; • описание атаки; • атрибут запроса или ответа, в котором были обнаружены признаки атаки; • уникальный идентификатор события; • перечень действий, выполненных по результатам атаки; • приоритет (важность события) - Подсистема должна предоставлять сводную информацию об атаках в графическом виде (графики, круговые диаграммы, гистограммы, географическое распределение). Подсистема должна предоставлять возможность выполнения непосредственно из таблицы, содержащей перечень событий, следующих часто используемых действий: – проверка наличия уязвимости, на которую направлена атака; – блокировка атакующего; – добавление правила для фильтрации ложного срабатывания. Подсистема должна предоставлять информацию о статусе компонентов Подсистемы и текущей загрузке - Требования к сертификации ПО - Программное обеспечение Подсистемы защиты приложений от несанкционированного доступа должно иметь сертификат ФСТЭК России на соответствие требованиям руководящего документа «на соответствие требованиям руководящих документах «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» - по 4 уровню доверия - - Значение характеристики не может изменяться участником закупки - Требования к объему, содержанию и условиям передачи прав - Требования к объему продлеваемых прав – право использования результатов интеллектуальной деятельности – программного обеспечения, осуществляется на условиях простой неисключительной лицензии, способом воспроизведения, ограниченного инсталляцией, запуском и копированием программного обеспечения. Срок передачи продления прав использования программного обеспечения: в течение 10 (десяти) дней с даты заключения Контракта. Территория использования программного обеспечения, неисключительные права на которое предоставляются – Российская Федерация. Срок, на который продлеваются неисключительные права – с момента окончания действия соответствующих лицензий на 1 год. В указанный срок Исполнитель обязан обеспечить гарантийное сопровождение программного обеспечения на следующих условиях: – предоставление обновлений программного обеспечения; – предоставление новых версий программного обеспечения; – предоставление консультаций по телефону и электронной почте в рабочие дни в рабочее время - - Значение характеристики не может изменяться участником закупки

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

Общие требования к функциям системы - Подсистема должна поддерживать кластеризацию с обеспечением отказоустойчивости. Подсистема должна поддерживать следующие режимы работы: Обратный прокси-сервер (reverse proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак; Мониторинг (sniffer). Назначение: Анализ трафика без возможности блокировки запросов и предотвращения атак. Об обнаруженных атаках отправляются уведомления; Сетевой мост (bridge). Назначение: Режим предназначен для обнаружения вторжений без вмешательства в работу приложений; Прозрачный прокси-сервер (transparent proxy). Назначение: Анализ всех HTTP-запросов к веб-приложению с возможностью активного предотвращения атак в прозрачном режиме; Автономный режим (forensic). Назначение: Офлайн-анализ журналов веб-сервера, сетевых дампов на предмет обнаружения в них следов атак. - - Значение характеристики не может изменяться участником закупки

В состав системы должны входить следующие функциональные подсистемы: – обнаружения и предотвращения атак; – проактивной защиты; – подтверждения уязвимостей; – разграничения доступа; – интеграции; – управления

Подсистема обнаружения и предотвращения атак. Назначение: Подсистема обнаружения атак обеспечивает анализ заголовков и содержимого HTTP-пакетов с запросами пользователей и ответами приложения

Подсистема проактивной защиты. Назначение: Подсистема проактивной защиты позволяет использовать априорные решения об атаках и злоумышленниках для снижения вероятности проведения атак

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

Подсистема разграничения доступа. Назначение: Подсистема разграничения доступа предназначена для идентификации пользователя по его учетным данным, используемым в защищаемом приложении, и контроля доступа пользователя к отдельным частям приложения

Подсистема интеграции. Назначение: Подсистема интеграции представляет собой набор интерфейсов и протоколов для взаимодействия с внешними системами

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

Допускается объединение двух или нескольких функциональных подсистем в одну с сохранением реализуемых функций, либо разделение одной функциональной подсистемы на несколько. Доступ к подсистеме защиты приложений от несанкционированного доступа должен осуществляться по защищенному сетевому соединению. Подсистема защиты приложений от несанкционированного доступа должна выдерживать нагрузку до 10 000 RPS (запросов в секунду). Подсистема защиты приложений от несанкционированного доступа должна осуществлять обнаружение сетевых атак (вторжений), направленных на веб-приложения, следующими способами: – сигнатурный метод — посредством сопоставления параметров (частей) текущих запросов на доступ с сигнатурами атак, которые содержатся в БД; – профилирование — посредством построения модели работы приложения или пользователя и обнаружения аномальных отклонений; – проактивная защита — посредством использования априорных решений об атаках и злоумышленниках для снижения вероятности проведения атак. Подсистема защиты приложений от несанкционированного доступа должна поддерживать протоколы: – HTTP, – HTTPS включая SSL v3, TLS v1.0, v1.1, v1.2, – Simple Object Access Protocol (SOAP), – eXtensible Markup Language (XML), – JavaScript Object Notation (JSON)

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

Подсистема обнаружения и предотвращения атак - Подсистема должна осуществлять контроль структуры HTTP-запросов: – контроль соответствия структуры запроса RFC 2616; – перечня разрешенных методов HTTP; – максимального количества заголовков HTTP-запроса и максимальной длины каждого из них; – максимального размера запроса; – максимального времени ожидания заголовка запроса; – максимального времени ожидания тела запроса; – перечня допустимых типов данных в запросе. Подсистема должна автоматически с использованием технологии машинного обучения формировать вероятностную модель данных для каждого атрибута HTTP-запроса и контролировать отклонение от нее. Подсистема должна обеспечивать защиту от SQL-инъекций путем обнаружения и блокирования запросов, содержащих выражения языка SQL. Подсистема должна осуществлять обнаружение и блокирование XSS-атак, в том числе: – stored XSS (хранимого XSS); – reflected XSS (отраженного XSS); – DOM Based XSS. Подсистема должна осуществлять обнаружение и блокирование уязвимости открытого перенаправления (Open Redirect): – в HTTP-заголовке Location; – HTML-теге Meta; – HTTP-заголовке Refresh. Подсистема должна обеспечивать защиту от атак класса CSRF путем: – добавления CSRF-токена к ответам приложения; – обнаружения или блокирования POST-запросов с отсутствующим или неверным CSRF-токеном - - Значение характеристики не может изменяться участником закупки

Подсистема должна осуществлять обнаружение и блокирование атаки на уязвимости, связанные с обработкой формата XML, путем: – контроля соответствия XML-сообщения рекомендациям консорциума W3C (https://www.w3.org/TR/REC-xml/); – контроля соответствия XML-сообщения формату, заданному в виде схемы XSD; – контроля соответствия запроса описанию сервиса, заданному в виде схемы WSDL; – контроля наличия внешних сущностей и ссылок на них (external entity) в XML-сообщении; – контроля максимального уровня вложенности в структуре XML-сообщения. Подсистема должна обеспечивать защиту от утечек данных путем обнаружения и маскирования чувствительных данных в ответах приложения. Подсистема должна осуществлять контроль автоматизированной активности: – выявление и блокирование запросов роботов и других средств автоматизации, основанное на сигнатурном анализе запросов и эвристическом анализе возможностей клиентского ПО; – контроль доступа «хороших роботов» (поисковых систем и т. п.). Подсистема должна обеспечивать защиту от DDoS-атак уровня приложения путем: – постоянного анализа действий пользователей и кластеризации их по схожему поведению с использованием технологии машинного обучения; – обнаружения DDoS-атак за счет контроля показателей работы приложения: • количество запросов в секунду; • количество ошибок сервера; • среднее время ответа; – прогнозирования DDoS-атак путем экстраполяции текущих значений контролируемых показателей работы приложения; – блокировки групп пользователей, оказывающих существенное влияние на показатели работы приложения

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

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

Подсистема разграничения доступа - Подсистема должна обеспечивать возможность идентификации пользователя приложения на основании его успешных попыток входа в приложение с использованием: – аутентификации через HTML-форму; – аутентификации HTTP Basic. Подсистема должна осуществлять контроль доступа пользователей к приложению в целом и отдельным его частям - - Значение характеристики не может изменяться участником закупки

Подсистема интеграции - Подсистема должна иметь возможность интеграции: – с системами управления событиями информационной безопасности (SIEM) в части передачи информации об обнаруженных атаках; – системами защиты от утечек данных (DLP) в части анализа пересылаемых через защищаемое приложение файлов на наличие чувствительных данных; – системами статического анализа кода (SAST) для автоматического формирования правил блокировки уязвимостей (virtual patching), обнаруженных в ходе анализа исходного кода веб-приложений; – системами мониторинга состояния сетевого оборудования в части предоставления информации о состоянии аппаратной части системы; – электронной почтой для оповещения персонала об обнаруженных атаках; – сервисами для защиты от атак отказа в обслуживании (DDoS); – межсетевыми экранами в части передачи адресов атакующего для блокировки. Подсистема должна предоставлять программный интерфейс (API) для автоматизации задач по управлению системой с помощью внешних программных средств - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Требования к объему, содержанию и условиям передачи прав - Требования к объему продлеваемых прав – право использования результатов интеллектуальной деятельности – программного обеспечения, осуществляется на условиях простой неисключительной лицензии, способом воспроизведения, ограниченного инсталляцией, запуском и копированием программного обеспечения. Срок передачи продления прав использования программного обеспечения: в течение 10 (десяти) дней с даты заключения Контракта. Территория использования программного обеспечения, неисключительные права на которое предоставляются – Российская Федерация. Срок, на который продлеваются неисключительные права – с момента окончания действия соответствующих лицензий на 1 год. В указанный срок Исполнитель обязан обеспечить гарантийное сопровождение программного обеспечения на следующих условиях: – предоставление обновлений программного обеспечения; – предоставление новых версий программного обеспечения; – предоставление консультаций по телефону и электронной почте в рабочие дни в рабочее время - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

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

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Требование об обеспечении заявки на участие в аукционе в равной мере относится ко всем участникам аукциона, за исключением государственных, муниципальных учреждений, которые не предоставляют обеспечение подаваемых ими заявок на участие в аукционе. Предприятия уголовно-исполнительной системы, организации инвалидов предоставляют обеспечение заявки на участие в закупке в размере одной второй процента начальной (максимальной) цены контракта. Выбор способа обеспечения осуществляется участником закупки самостоятельно. 1 способ. Путем блокирования денежных средств, на банковском счете, открытом таким участником в банке, включенном в перечень, утвержденный Правительством РФ, для их перевода в случаях, предусмотренных статьей 44 Закона № 44-ФЗ, на счет, на котором в соответствии с законодательством Российской Федерации учитываются операции со средствами, поступающими заказчику, или в соответствующий бюджет бюджетной системы Российской Федерации. Участник аукциона для подачи заявки на участие в аукционе выбирает с использованием электронной площадки способ обеспечения такой заявки путем указания реквизитов специального счета. При этом подача заявки на участие в аукционе означает согласие участника аукциона на блокирование денежных средств, находящихся на его специальном счете, в размере обеспечения заявки. 2 способ. Предоставлением независимой гарантии, соответствующей требованиям ст.45 Закона № 44-ФЗ. Участник аукциона для подачи заявки на участие в аукционе выбирает с использованием электронной площадки способ обеспечения такой заявки путем указания номера реестровой записи из реестра независимых гарантий, размещенного в ЕИС. Независимая гарантия должна быть безотзывной, должна быть составлена по утвержденной ПП РФ от 08.11.2013 № 1005 типовой форме независимой гарантии, предоставляемой в качестве обеспечения заявки на участие в аукционе и должна содержать условия, указанные в ст. 45 Закона № 44-ФЗ и в ПП РФ от 08.11.2013 № 1005. См.приложение №5 к Извещению

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 00000000000000000000, л/c См. прилагаемые документы, БИК 000000000

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

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, г Москва, 125373, Походный проезд, домовладение 3

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

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

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

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

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Требования к обеспечению исполнения контракта устанавливаются заказчиком в соответствии с условиями ст.96 Закона № 44-ФЗ, с учетом применения антидемпинговых мер, предусмотренных статьей 37 Закона № 44-ФЗ. Контракт заключается после предоставления участником аукциона, с которым заключается контракт, обеспечения исполнения контракта. Документ, подтверждающий предоставление такого обеспечения, подписанный усиленной электронной подписью лица, имеющего право действовать от имени участника аукциона, с которым заключается контракт, размещается таким участником на электронной площадке одновременно с подписанным электронной подписью указанного лица проектом контракта. В случае непредоставления участником аукциона, с которым заключается контракт, обеспечения исполнения контракта в срок, установленный для заключения контракта, такой участник считается уклонившимся от заключения контракта. 1 способ. Внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством РФ учитываются операции со средствами, поступающими Заказчику. 2 способ. Предоставлением независимой гарантии, соответствующей требованиям ст. 45 Закона № 44-ФЗ. Независимая гарантия должна быть безотзывной, должна быть составлена по утвержденной ПП РФ от 08.11.2013 № 1005 типовой форме независимой гарантии, предоставляемой в качестве обеспечения исполнения контракта и должна содержать условия, указанные в ст. 45 Закона № 44-ФЗ и в ПП РФ от 08.11.2013 № 1005. См.приложение №5 к Извещению

Платежные реквизиты для обеспечения исполнения контракта: p/c 00000000000000000000, л/c См. прилагаемые документы, БИК 000000000

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

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

Документы

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

Документы

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