ТЗ в2. Техническое задание на установку, настройку и сопровождение системы защиты вебприложений от несанкционированного доступа Positive Technologies Web Application

• Название: Техническое задание на установку, настройку и сопровождение системы защиты вебприложений от несанкционированного доступа Positive Technologies Web Application
• Дата: 02.12.2022
• Размер: 44.77 Kb.
• Имя файла: ТЗ в2.docx
• Тип: Техническое задание; #824850

Техническое задание

на установку, настройку и сопровождение системы защиты веб-приложений от несанкционированного доступа Positive Technologies Web Application Firewall (PT AF) и системы защиты контейнеров и контейнеризированной среды StackRox для

CAPITAL GROUP
В ходе проведения работ в соответствии с настоящим Техническим Заданием должна быть проведена установка и настройка системы защиты веб-приложений от несанкционированного доступа и системы контроля контейнеров и контейнеризированной среды (далее - системы) на mvp зоне, сопровождение Систем, а также обучение персонала Заказчика в соответствии с выбранной программой обучения.
Системы должны обеспечивать защищённость разрабатываемых веб-приложений, систем и сервисов Заказчика от несанкционированного доступа и контроль контейнеров и контейнеризированной среды Заказчика.
Используемые решения:

• 
  Система защиты веб-приложений от несанкционированного доступа Positive Technologies Web Application Firewall (PT AF);
  
• 
  Система контроля контейнеров и контейнеризированной среды StackRox.
  

1. 
   ПЕРЕЧЕНЬ РАБОТ
   

1. 
   Этап 1. Установка и настройка Систем. В ходе этапа должны быть проведены следующие работы:
   

• 
  Подготовка объектов Заказчика к вводу Систем в действие путем настройки IT‑инфраструктуры и оборудования объектов Заказчика для обеспечения прохождения веб-трафика в соответствии с выбранной схемой развертывания PT AF.
  
• 
  Разработка проектных решений и проектной документации на Системы
  
• 
  Разработка рабочей документации
  
• 
  Разработка эксплуатационной документации
  
• 
  Подготовка объекта автоматизации к вводу в действие Систем
  
• 
  Монтажные работы
  
• 
  Пусконаладочные работы
  
• 
  Проведение предварительных испытаний
  
• 
  Проведение опытной эксплуатации
  
• 
  Проведение приемочных испытаний
  

2. 
   Этап 2. Обучение персонала Заказчика
   
   
   
   
   1. 
      В целях обучения персонала Заказчика проводится онлайн тренинг «Основные уязвимости web-приложений».
      

Данный курс знакомит слушателей с основными уязвимостями веб-приложений по классификации OWASP Top 10, причинами возникновения и способами защиты. В рамках курса проводится демонстрация на реальных приложениях, а слушатели имеют возможность самостоятельной тренировки в обнаружении и эксплуатации рассматриваемых уязвимостей.

Продолжительность: 16 ак. часов.

Состав курса:

Модуль	Описание
Модуль 1 Основы безопасности и веб-приложений	Основные понятия Важность организации безопасности Основные угрозы Концепция безопасности web-приложений
Модуль 2 Основы криптографии	Основные понятия Базовые принципы работы криптоалгоритмов Симметричное/асимметричное шифрование Хэширование Принципы безопасной передачи данных
Модуль 3 OWASP	Что такое OWASP Основные проекты OWASP: Top 10, WSTG и ASVS Обзор OWASP Top 10 A1 Внедрение зловредного кода A2 Некорректная аутентификация и управление сессиями A3 Утечка защищаемых данных A4 Внедрение внешних XML- сущностей A5 Некорректный контроль доступа A6 Небезопасная конфигурация A7 Межсайтовый скриптинг A8 Небезопасная десериализация A9 Использование компонентов с известными уязвимостями A10 Недостатки протоколирования и мониторинга
Модуль 4 Внедрение зловредного кода	Различные контексты инъекций SQL инъекции Причины возникновения Разновидности Последствия эксплуатации Способы обнаружения Примеры Практическое задание Способы защиты
Модуль 5 Уязвимости, связанные с некорректной реализацией механизмов аутентификации и управлением сессиями	Основные методы аутентификации в веб-приложениях Основные проблемы этого класса уязвимостей Общие принципы защиты механизмов аутентификации и управления сессиями Примеры Практическое задание
Модуль 6 SOP, CORS, CSRF	Механизм Same Origin Policy Механизмы JSONP, Cross Origin Resource Sharing (CORS): Описание механизмов Примеры реализации Уязвимости, ошибки конфигурации Атаки Cross-site Request Forgery (CSRF): Причины возникновения Последствия эксплуатации Примеры Практическое задание Способы защиты
Модуль 7 Утечка защищаемых данных	Описание сути уязвимостей этого класса Причины возникновения уязвимостей Последствия эксплуатации Примеры Практическое задание Способы защиты
Модуль 8 Внедрение внешних XML-сущностей	Описание сути уязвимости Детали XML и DTD, являющиеся причиной для возникновения уязвимости Условия возникновения уязвимости Последствия эксплуатации Примеры Способы защиты
Модуль 9 Некорректный контроль доступа	Описание уязвимостей этого типа Основные типы и примеры уязвимостей Небезопасный доступ по идентификатору Обход ограничений учетной записи Directory traversal Манипуляция параметрами Внедрение локальных файлов Повышение привилегий Последствия эксплуатации Практическое задание Способы защиты
Модуль 10 Небезопасная конфигурация	Описание уязвимостей этого типа Последствия эксплуатации Основные проблемы администрирования и разработки, приводящие к уязвимостям Заголовки безопасности: X-Frame-Options Strict-Transport-Security X-Content-Type-Options Referrer-Policy Примеры уязвимостей Способы защиты
Модуль 11 Cross Site Scripting (XSS)	Описание уязвимости Разновидности Последствия эксплуатации Способы обнаружения Практическое задание Защита от возникновения Механизм Content Security Policy
Модуль 12 Небезопасная десериализация	Описание уязвимости Причины возникновения уязвимости JSON/XML и Binary сериализация Последствия эксплуатации уязвимости Примеры уязвимости Способы защиты
Модуль 13 Использование сторонних компонентов с известными уязвимостями	Описание уязвимостей этого типа Причины возникновения уязвимостей Демонстрация общедоступных систем публикации уязвимостей Последствия эксплуатации уязвимостей Примеры эксплуатации уязвимостей, приведшие к большим утечкам данных Основные нашумевшие уязвимости (FREAK, POODLE, ShellShock, EventStream, Zip-Slip) Оценка безопасности компонента Способы защиты
Модуль 14 Недостатки протоколирования и мониторинга	Описание уязвимостей этого класса Проблемы, приводящие к эксплуатации уязвимостей Способы защиты
Модуль 15 Защита в целом и перспективы	Итоги тренинга и общие рекомендации по защите Развитие процессов безопасности в организации Краткий обзор OWASP ASVS, Testing Guide Заключение

3. 
   Этап 3. Сопровождение Систем
   

В сопровождение Систем входят следующие работы со стороны Исполнителя (с учетом ограничений указанных в п. п. 5 настоящего Технического задания):

1. 
   Включение артефактов программного обеспечения в конвейер разработки ПО с учетом анализа Системой StackRox;
   
2. 
   Первичное сканирование Исполнителем исходного кода, артефактов, развернутых на стендах экземпляров программных продуктов;
   
3. 
   Формирование перечня дефектов ИБ, включающего обнаруженные уязвимости программного обеспечения;
   
4. 
   Настройка и автоматизация процесса сканирования;
   
5. 
   Написание правил для Системы PT AF;
   
6. 
   Проведение воркшопов по работе с Системами:
   

• 
  Проводится 1 воркшоп по работе с cистемой PT AF
  
• 
  Проводится 1 воркшоп по работе с cистемой StackRox
  

Формат – онлайн. Каждый воркшоп длительностью 1,5 часа. проводится с тренером/преподавателем и практическими заданиями.

2. 
   СРОКИ ПРОВЕДЕНИЯ РАБОТ
   

Наименование Этапа	Выполняемые работы	Срок
Этап 1. Установка и настройка Систем	Подготовка объектов Заказчика к вводу Систем в действие путем настройки IT‑инфраструктуры и оборудования объектов Заказчика для обеспечения прохождения веб-трафика в соответствии с выбранной схемой развертывания PT AF. Разработка проектных решений и проектной документации на Системы Разработка рабочей документации Разработка эксплуатационной документации Подготовка объекта автоматизации к вводу в действие Систем Монтажные работы Пусконаладочные работы Проведение предварительных испытаний Проведение опытной эксплуатации Проведение приемочных испытаний	3 календарных месяца, с даты подписания Договора
Этап 2. Обучение персонала Заказчика	Проведение онлайн тренинга «Основные уязвимости web-приложений»	3 календарных месяца, с даты подписания Договора
Этап 3. Сопровождение Систем	Включение артефактов программного обеспечения в конвейер разработки ПО с учетом анализа Системой StackRox; Первичное сканирование Исполнителем исходного кода, артефактов, развернутых на стендах экземпляров программных продуктов; Формирование перечня дефектов ИБ, включающего обнаруженные уязвимости программного обеспечения; Настройка и автоматизация процесса сканирования; Написание правил для Системы PT AF; Проведение воркшопов по работе с Системами	12 календарных месяцев с даты завершения этапа № 1

3. 
   ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СИСТЕМАМ
   
   1. 
      Функциональные требования к подсистеме защиты веб-приложений от несанкционированного доступа Positive Technologies Web Application Firewall (PT AF)
      
      1. 
         Требования к подсистеме анализа и обработки веб-трафика
         
         1. 
            Подсистема должна поддерживать использование следующих вариантов и обработки трафика:
            

• 
  базовый узел (с ролью обработки трафика);
  
• 
  узел обработки трафика (управляемый узел);
  
• 
  внешний агент.
  

1. 
   Должны поддерживаться следующие способы обработки трафика:
   

• 
  в режиме обратного прокси-сервера (reverse proxy) — соединение в разрыв, в котором Подсистема выступает в качестве прокси-сервера между клиентом и защищаемым веб‑приложением (в том числе с помощью внешних агентов, расположенных в ИТ‑инфраструктуре).
  

1. 
   Должны поддерживаться различные варианты установки агентов в ИТ‑инфраструктуре Заказчика:
   

• 
  в качестве модуля веб-сервера Nginx;
  
• 
  в качестве Sidecar-контейнера в кластере Kubernetes;
  
• 
  с интеграцией в Ingress controller в кластере Kubernetes.
  

1. 
   Должно поддерживаться определение IP-адреса отправителя веб-трафика (включая случаи с наличием балансировщиков и прокси-серверов).
   
2. 
   Должна поддерживаться возможность задания перечня защищаемых серверов, на которых расположены веб-приложения.
   
3. 
   Должна поддерживаться возможность создания профилей собираемого (обрабатываемого) трафика веб-приложений, с возможностью указания:
   

• 
  IP-адресов и портов, которые Система будет использовать для приема клиентских запросов и проксирования их на защищаемое веб-приложение;
  
• 
  протокола клиентских запросов к серверу;
  
• 
  серверов из перечня защищаемых серверов веб-приложений;
  
• 
  режима работы серверов веб-приложений (активный/запасной);
  
• 
  характера распределения (балансировки) нагрузки между защищаемыми серверами;
  
• 
  времени ожидания неактивного соединения.
  

1. 
   Должны поддерживаться анализ и обработка трафика веб-приложений по протоколам:
   

• 
  HTTP(s) 1.0, 1.1 и HTTPS, включая TLS 1.0, 1.1, 1.2 и 1.3;
  
• 
  WebSocket (ws, wss);
  
• 
  XML-based protocols.
  
• 
  В веб-трафике также должен выполняться анализ файлов в нотации:
  
• 
  XML;
  
• 
  JSON;
  
• 
  GraphQL.
  

1. 
   Должна обеспечиваться возможность обработки трафика на основании списков IP-адресов в формате CIDR (далее также — глобальных списков); в том числе должны поддерживаться статические и динамические белые и черные списки, устанавливаемые на основе правила:
   

• 
  для конкретного приложения;
  
• 
  для всех приложений.
  

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

• 
  Apache Struts — включает только те правила, которые предназначены для защиты веб-приложений, разработанных на фреймворке Apache Struts;
  
• 
  ASP.NET — включает только те правила, которые предназначены для защиты веб-приложений, созданных на платформе ASP.NET;
  
• 
  Java — включает только те правила, которые предназначены для защиты веб-приложений, разработанных на языке Java;
  
• 
  Joomla CMS — включает только те правила, которые предназначены для защиты веб-приложений, основанных на системе управления контентом Joomla;
  
• 
  LAMP (PHP, Apache, MySQL) — включает только те правила, которые предназначены для защиты веб-приложений, разработанных при помощи инструментов PHP, Apache или MySQL;
  
• 
  Microsoft Exchange — включает те правила, которые предназначены для защиты сервера Microsoft Exchange;
  
• 
  Node.js — включает только те правила, которые предназначены для защиты веб-приложений, созданных на платформе Node.js;
  
• 
  PHP — включает только те правила, которые предназначены для защиты веб-приложений, разработанных на языке PHP;
  
• 
  Default template (стандартный шаблон) — включает правила всех остальных системных наборов.
  

1. 
   Для системных правил должны быть указаны:
   

• 
  наименование правила;
  
• 
  статус активности правила (включено или отключено);
  
• 
  принадлежность к системному набор правил;
  
• 
  действие при срабатывании;
  
• 
  принадлежность к группе правил;
  
• 
  точность определения атаки правилом (по оценке экспертов);
  
• 
  фаза срабатывания правила (запрос/ответ);
  
• 
  метки (теги), помогающие при сортировке;
  
• 
  классификация правила (CAPEC, WASC, OWASP) с указанием года (при наличии);
  
• 
  тип угрозы безопасности, обнаруживаемой в результате срабатывания правила;
  
• 
  уровень опасности события безопасности, зарегистрированного в результате срабатывания правила.
  

1. 
   Должна поддерживаться возможность создания новых пользовательских правил (набора пользовательских правил), в том числе должны поддерживаться возможности задания:
   

• 
  наименования правила;
  
• 
  описания (опционально);
  
• 
  метки (теги), помогающие при сортировке;
  
• 
  классификации правила (CAPEC, WASC, OWASP), с указанием года (опционально);
  
• 
  типа события (атака, уязвимость, инцидент, информация);
  
• 
  уровня опасности события, регистрируемого в результате срабатывания пользовательского правила (низкий, средний, высокий, критический);
  
• 
  конфигурации правила (включая возможность задания пользовательских параметров и привязку к конкретному параметру, например списку IP-адресов в формате CIDR, зарегистрированному в системе);
  
• 
  действий при срабатывании.
  

1. 
   Должны поддерживаться стандартные действия для правил, применяемые по выбору пользователя:
   

• 
  block (отправить пользователю страницу, которая будет отображаться при блокировании запросов вместо ответа защищаемого сервера);
  
• 
  log to db (записи информации об обнаруженных событиях безопасности в базу данных Системы);
  
• 
  send to syslog server;
  
• 
  skip (только для статических ресурсов).
  
• 
  Должна поддерживаться возможность создания пользовательских действий для правил на основе типа этих действий:
  
• 
  log to db;
  
• 
  send custom response;
  
• 
  send to syslog server.
  

1. 
   Должна поддерживаться возможность редактирования пользовательских правил.
   
2. 
   Должна поддерживаться возможность создания исключений для правил.
   
3. 
   Должно поддерживаться обнаружение событий безопасности на основе установленных правил.
   
4. 
   Должна поддерживаться агрегация единичных событий безопасности, зарегистрированных одним правилом для одного IP-адреса в рамках веб-приложения. Результаты агрегации должны регистрироваться в виде «событий агрегации».
   
5. 
   Должна сохраняться следующая информация о событиях агрегации:
   

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

1. 
   Должна поддерживаться:
   

• 
  сортировка событий по любому из отображаемых атрибутов события;
  
• 
  фильтрация событий по любому из отображаемых атрибутов события.
  

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

• 
  аутентификации через веб-форму;
  
• 
  базовой аутентификации.
  

В том числе, должны фиксироваться все успешные и неуспешные попытки аутентификации пользователя.

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

• 
  событий безопасности;
  
• 
  параметров безопасности и данных о конфигурации системы;
  
• 
  крупных бинарных объектов, таких как резервные копии и отчеты.
  

1. 
   Требования к подсистеме управления
   
   1. 
      Должна быть обеспечена мультиарендность, позволяющая пользователям работать в изолированном пространстве защищаемых приложений, связанных с ними событий безопасности и политик безопасности.
      
   2. 
      Должна обеспечиваться возможность управления собственными узлами Системы через консольный интерфейс (SSH) — для выполнения системных настроек.
      
   3. 
      Должна обеспечиваться возможность управления функциями системы через веб-интерфейс (HTTPS).
      
   4. 
      Возможность управления Системой через любой из интерфейсов должна предоставляться только авторизованным (уполномоченным) пользователям.
      
   5. 
      Должна обеспечиваться реализация ролевой модели управления доступом к функциям Системы, доступным через веб-интерфейс.
      
   6. 
      Должна обеспечиваться возможность управления (в том числе создание, изменение, удаление) учетными записями пользователей Системы:
      

• 
  логинами и паролями;
  
• 
  ролями (только веб-интерфейс).
  

1. 
   Должна обеспечиваться регистрация событий, связанных с действиями пользователей системы, а также системных операциях.
   
2. 
   Должна обеспечиваться возможность создания изолированных пространств:
   

• 
  для собственных узлов;
  
• 
  для агентов.
  

1. 
   Должна обеспечиваться возможность назначения администраторов изолированных пространств.
   
2. 
   Должна поддерживаться опция «потребовать смены пароля» администратора изолированного пространства.
   
3. 
   Должна обеспечиваться возможность задания перечня защищаемых серверов:
   

• 
  по имени узла;
  
• 
  по IP-адресу сервера.
  

1. 
   Должна обеспечиваться возможность выбора протокола между защищаемым сервером и узлом Системы:
   

• 
  HTTP;
  
• 
  HTTPS.
  

1. 
   Должна обеспечиваться возможность загрузки цепочки SSL сертификатов для расшифровки HTTPS-трафика, отправляемого на защищаемые серверы.
   
2. 
   Должна обеспечиваться возможность загрузки ключей для расшифровки HTTPS-трафика, отправляемого на защищаемые серверы;
   
3. 
   Должна обеспечиваться визуализация данных о событиях безопасности (атаках, инцидентах, уязвимостях, информационных событий) с помощью информационных панелей (дашбордов) в виде гистограмм и ленты событий.
   
4. 
   Должна обеспечиваться возможность указания временного периода, за который отображаются события безопасности, зафиксированные Системой.
   
5. 
   Должно обеспечиваться автоматическое обновление данных о событиях на дашбордах.
   
6. 
   Должна обеспечиваться возможность отправки записей обращений (access.log) к защищаемому веб-приложению в систему регистрации событий и выявления инцидентов информационной безопасности (SIEM).
   
7. 
   Должна поддерживаться возможность генерации отчетов о работе системы, доступных к выгрузке из графического интерфейса. Выгрузка отчетов должна осуществляться в формате PDF.
   
8. 
   Должна обеспечиваться возможность создания резервных копий Системы, содержащих сведения о конфигурации системы, в том числе:
   

• 
  параметры контроля доступа;
  
• 
  параметры безопасности.
  

1. 
   Должно поддерживаться создание списков IP-адресов в формате CIDR:
   

• 
  статических (из файла);
  
• 
  динамических (при срабатывании правила или путем ручного добавления).
  

1. 
   Должен поддерживаться экспорт глобальных списков.
   
2. 
   Должна обеспечиваться автоматическая очистка динамических списков (удаление IP-адресов из списка после истечения заданного промежутка времени (не более одной недели).
   
3. 
   Должна обеспечиваться возможность блокировки учетной записи пользователя в Системе.
   
4. 
   Должна обеспечиваться возможность отслеживания нагрузки на базы данных, входящие в подсистему хранения.
   
5. 
   Должно обеспечиваться отслеживание статуса применения настроек СЗВП, доступных пользователю через веб-интерфейс.
   
1. 
   Требования к подсистеме обновления
   
   1. 
      Должна обеспечиваться возможность автоматизированного обновления Системы (включая образы хостовой ОС).
      
   2. 
      Должно обеспечиваться автоматизированное обновление баз знаний (правил защиты). Обновление базы знаний не должно зависеть от выпуска новых версий ПО Системы.
      
2. 
   Требования к лингвистическому обеспечению Системы
   
   1. 
      Эксплуатационная документация должна быть выполнена на русском языке.
      
   2. 
      Программное обеспечение, входящее в состав системы должно поддерживать выбор языка (русский или английский).
      
3. 
   Требования к программному обеспечению
   
   1. 
      Программное обеспечение, входящее в состав Системы должно поддерживать развертывание как на физических, так и на виртуальных серверах.
      
   2. 
      Программное обеспечение, входящее в состав Системы должно входить в Единый реестр российских программ для электронных вычислительных машин и баз данных.
      
   3. 
      Программное обеспечение, входящее в состав Системы должно устанавливаться без подключения к сети Интернет;
      
   4. 
      Программное обеспечение, входящее в состав системы должно устанавливаться из ISO-, OVA- или QCOW‑2 образов.
      
   5. 
      Программное обеспечение из состава системы должно функционировать под управлением операционной системы Debian версии не ниже 10 (x64).
      
   6. 
      Работа с графическим интерфейсом пользователя Системы должна осуществляться на автоматизированном рабочем месте (АРМ) пользователя с помощью браузера.
      
   7. 
      Система должна поддерживать работу пользователя с использованием графического интерфейса через браузеры:
      

• 
  Google Chrome версии 60 или выше.
  

2. 
   Функциональные требования к подсистеме контроля контейнеров и контейнеризированной среды StackRox
   
   1. 
      ПО должно проводить сканирование образов контейнеров на наличие проблем безопасности (уязвимости, наличие конфиденциальных данных);
      
   2. 
      ПО должно проводить сканирование хостов на наличие проблем безопасности (уязвимости, небезопасные конфигурации);
      
   3. 
      ПО должно проводить оценку образа контейнера на соответствие заданной политике безопасности;
      
   4. 
      ПО должно проводить проверку настроек кластера на соответствие Kubernetes CIS;
      
   5. 
      База данных подсистемы может быть вынесена за пределы защищаемой среды контейнеризации.
      
   6. 
      ПО должно иметь возможность объединять группы элементы контейнерной инфраструктуры (cluster, namespace, label) с целью определения области действия политик;
      
   7. 
      ПО должно выполнять визуализацию взаимодействия между компонентами кластера(-ов) в консоли управления;
      
   8. 
      ПО должно иметь возможность моделирования сетевых политик в реальном времени.
      
   9. 
      ПО должно выполнять проверку защищенности от изменений контейнеров согласно определенным политикам среды выполнения:
      

• 
  Доступ к файлам;
  
• 
  Подключение новых файловых пространств;
  
• 
  Исполнение команд ОС;
  
• 
  Организация подключений от заданных IP-адресов;
  
• 
  Повышения привилегий, использования УЗ root;
  
• 
  Запрет использования нестандартных базовых образов;
  

1. 
   ПО должно иметь поддержку протоколов автоматизации управления данными безопасности SCAP;
   
2. 
   ПО должно обладать возможностью создания профиля безопасности контейнера и применения его на другие контейнера на основе обучения поведенческой модели и сетевого взаимодействия. Должна поддерживаться возможность изменять время обучения.
   
3. 
   ПО должно обладать возможностью создавать правила для контроля трафика между контейнерами;
   
4. 
   ПО должно выполнять логирование следующих событий:
   

• 
  Действий в консоли управления;
  
• 
  Действий, связанных с использованием Docker API или команд на контейнере и хосте;
  
• 
  Событий, связанных с найденными проблемами безопасности;
  

14. 
    ПО должно поддерживать интеграцию с SIEM;
    
15. 
    ПО должно поддерживать интеграцию с системой Jira и/или YouTrack;
    
16. 
    ПО должно поддерживать SSO, PKI;
    
17. 
    ПО должно поддерживать интеграцию с CI/CD-системами с помощью плагинов либо CLI (command line interface): GitLab, Jenkins, TeamCity;
    

4. 
   ТРЕБОВАНИЯ К МЕТОДИЧЕСКОМУ ОБЕСПЕЧЕНИЮ УСЛУГ И НОРМАТИВНОМУ СООТВЕТСТВИЮ
   
   1. 
      В процессе выполнения работ должны использоваться методические разработки Исполнителя, общепризнанные стандарты и руководства по обеспечению информационной безопасности, такие как:
      

• 
  Модель зрелости «Software Assurance Maturity Model (openSAMM)»;
  
• 
  Модель зрелости «Building Security In Maturity Model (BSIMM)»;
  
• 
  Методики «Open Web Application Security Project (OWASP)»;
  
• 
  ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;
  
• 
  «Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении», утвержденная ФСТЭК России 25.12.2020.
  

5. 
   ГРАНИЦЫ ПРОЕКТА И ДОПУЩЕНИЯ
   
   1. 
      Ограничения на объем покрываемого кода – 2 миллиона строк кода (2 mSLOC).
      
   2. 
      Объём команды разработки – не более 30 человек.
      
   3. 
      Объем трудозатрат в рамках сервиса сопровождения Систем ограничен и составляет 20 человеко-часов / месяц.
      
   4. 
      Все сервисы и компоненты Подсистемы разворачиваются на серверных мощностях Заказчика.
      
   5. 
      Для реализации Заказчик, при содействии Исполнителя, планирует получить необходимые тестовые лицензии на использование Систем, в объеме, необходимом для использования Систем на ознакомительный период для реализации проекта. Тестовые лицензии предоставляются поставщиками Программного обеспечения и встраиваются в Системы без оказания влияния на процесс разработки ПО.