Система защиты веб приложений ПАО МГТС

ПАО «Московская Городская Телефонная Сеть»

Технические требования

Система защиты веб приложений ПАО МГТС.

Москва

2017

Общие сведения Предметом запроса предложений является выбор организации на выполнение работ по разработки проекта, поставки, инсталляции, интеграции в сеть, поддержки и обслуживанию системы защиты веб-приложений в ПАО МГТС (далее Система). Проект – система защиты веб-приложений ПАО МГТС. Заказчик – Публичное акционерное общество «Московская городская телефонная сеть» (119991, Россия, , стр.1), далее по тексту – Заказчик, ПАО МГТС. Назначение Системы Система предназначена для противодействия различным видам угроз, атак и другим нарушениям информационной безопасности, связанных с работой расположенных в корпоративной среде веб-ресурсов, к которым открыт публичный доступ из сети Интернет. Выявление и блокировка возможных векторов атак, а также корреляцию происходящих событий. Анализ, выявление и закрытие уязвимостей в защищаемых приложениях, осуществляющих передачу данных через HTTP и HTTPS протоколы. Возможность автоматически создавать правила для защиты уязвимых мест в коде приложений до их устранения. Предоставление актуальной информации о событиях информационной безопасности, связанных с работой веб приложений. Предоставление сводной информации о безопасности защищаемых приложений, рекомендаций по улучшению защиты. Цели создания Системы Целью внедрения Системы является уменьшение рисков, связанных с различными видами угроз и атак на веб приложения ПАО МГТС, обеспечение эффективного разрешения инцидентов информационной безопасности связанных с негативным воздействием этих угроз, предотвращение возникновения повторных инцидентов. Требования к Участнику Участник должен предоставить следующую информацию: Дату организации юридического лица с учетом возможных реструктуризации, изменения наименования. Опыт реализации проектов по защите веб приложений организаций, либо аналогичных по сложности проектов в сфере обеспечения информационной безопасности с подтверждением внедрения и успешной эксплуатации хотя бы у одного российского или зарубежного оператора связи в течение более 1 года. Наличие партнерского статуса от производителя предлагаемого решения и авторизационного письма для участия в тендере, опыта технического сопровождения оборудования операторского уровня этого производителя. Наличие в штате квалифицированных специалистов, способных участвовать в выполнении условий Договора. Наличие лаборатории для возможности эмулирования участка сети, а также работы веб приложений, и наличие в лаборатории оборудования, аналогичного предлагаемому к поставке в рамках предложения, для анализа и мониторинга эмулированного легитимного и вредоносного трафика, а также защиты от выявленных негативных воздействий. Детальное описание аппаратно-программного комплекса. Метод расчета и контроля выполнения ключевого показателя эффективности защиты веб приложений, KPI. Стоимость Системы и механизм ценообразования в зависимости от производительности. Планы по развитию (roadmap) всего оборудования и программного обеспечения на 5 лет. Стоимость продления технической поддержки в течение последующих 3-х и 5-ти лет после окончания периода действующей технической поддержки. Гарантии по сопровождению и поддержке Системы, обеспечивая поставку оборудования для расширения, замены вышедшего из строя оборудования, версий программного обеспечения, расширения функциональности и технического сопровождения во время всего периода действующей технической поддержки. Детализированный План-график реализации Проекта. Информацию о наличии сертификатов ФСТЭК и ФСБ на предоставляемое решение. Дополнительно Участник должен предоставить Методику расчета расширения Системы, включая:

Описание принципов расширения и резервирования; Описание максимально возможной конфигурации Системы; Описание принципов увеличения производительности системы (программно и аппаратно); Описание максимально возможной аппаратной конфигурации предлагаемого оборудования с указанием производительности каждого модуля.

Наличие программы и курсов для обучения и сертификации инженеров.
Технические требования к Системе Общие требования к системе Требования к составу системы

Система должна состоять из следующих компонент:

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

Требования к масштабу и производительности Системы

Система должна удовлетворять следующим требованиям:

Система должна включать в себя два кластера с конфигурацией 1+1 для обеспечения резервирования (всего 4 устройства по два устройства в кластере) на двух географически распределенных площадках; Защита веб приложений на двух географически распределенных площадках; Общая полезная пропускная способность - не менее 1 Gbps на каждое устройство; Общая производительность не менее 10 000 запросов в секунду на каждое устройство; Количество защищаемых веб приложений: не менее 15; Система должна предусматривать круглосуточную эксплуатацию программно-технических средств; Решение должно поддерживать развертывание в виртуальной среде VMware ESXi;

Требования к надежности

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

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

Система должна поддерживать круглосуточный режим функционирования. Допускается временная недоступность сервисов при проведении профилактических или восстановительных (в случае сбоя) работ.

Для программных компонент комплекса должно обеспечиваться их периодическое обновление и контроль работоспособности.

Для аппаратных компонент комплекса специалистами Заказчика должно обеспечиваться ведение контроля их работоспособности.

Требования к архитектуре системы Поддержка работы в различных режимах

Система должна позволять реализацию различных подходов по её применению и выполнять свои функции как при установке «в разрыв», так и в режиме анализа SPAN-трафика. В частности, должны быть предусмотрены следующие режимы работы:

Обратный прокси-сервер (reverse proxy);

Режим мониторинга и анализа зеркалированного трафика (включая возможность обеспечивать анализ тегированных данных при обработке трафика с нескольких VLAN ID);

Автономный режим для изучения системных журналов на предмет наличия в них следов атак, что может быть использовано при расследовании инцидентов.

Варианты реализации Системы

Узлы и компоненты комплекса должны быть реализованы в форм-факторе виртуального устройства, реализация в виде физического устройства c эквивалентным набором функций и характеристик допустима при условии возможности эксплуатации в ИТ-инфраструктуре Заказчика;

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

Работа кластера в различных режимах

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

Active/Active; Active/Passive.

Варианты работы в отказоустойчивом варианте

Система должна предоставлять возможность настроить fail-open конфигурацию штатными средствами самой Системы.

Функциональные требования к Системе Требования к подсистеме централизованного управления и мониторинга

Подсистема централизованного управления и мониторинга должна обеспечивать:

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

Отправка данных во внешние системы

Должны поддерживаться стандартные протоколы отправки данных о Системе:

по протоколу syslog;

Возможность получения обновлений

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

Интеграция с внешними средствами

Должны быть предусмотрены возможности по интеграции со следующими системами:

интеграцию с внешней системой SIEM «Arcsight ESM»; интеграция с системой управления учётными данными (AD, LDAP);

Требования к подсистеме обеспечивающей политику безопасности по разграничению и контролю доступа к веб – приложениям.
Возможность разбора с SSL/TLS соединений

Подсистема должна позволять реализовывать политику безопасности для разбора зашифрованного средствами криптографического протокола SSL/TLS соединений между клиентом и веб – приложением.

Способы блокировки трафика

Подсистема должна блокировать атаки следующими способами:

путём перехвата и блокирования частей трафика к веб приложению; путем блокирования соединения клиента с веб приложением; путем сброса соответствующих TCP соединений (TCP Reset).

Различный уровень реагирования на фиксируемые события

Для реагирования на события, регистрируемые Системой должны быть предусмотрены как минимум следующие возможности:

разрешить прохождение трафика; запретить прохождение трафика; перенаправить на произвольную веб-страницу; сформировать сигнал предупреждения (alert).

Возможность применять действия должна быть обеспечена для адреса/сессии/запроса.

Различные модели применения правил политики  безопасности

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

разрешить всё, что не запрещено в политике безопасности; запретить всё, что не разрешено в политике безопасности.

Противодействие типовым угрозам для веб – приложений

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

Система должна обеспечивать защиту от DDoS-атак на уровне приложения; HTTP-атаки, включая атаки на переполнение буфера; противодействие брутфорс-атакам; защита от мошенничества (проверка привязки к сессии пользователя, детектирование автоматизированной активности); защита от роботов, включающая наличие встроенной базы роботов и автоматическое поведенческое детектирование робота Защита cookie (в том числе флаг HttpOnly); защита от  методов обхода межсетевого экрана, включая HPC, HPP (HTTP Parameter Pollution — смешивание («загрязнение») границ HTTP-параметров) и Verb Tampering; защита от OS Commanding; защита от сложных клиентских атак Clickjacking; защита от атак типа DOM-based XSS; защита от атак Open Redirect, Path Traversal, DNS Rebinding, LFI (Local File Inclusion);

Помимо вышеперечисленного перечня должно быть обеспечено противодействие угрозам из списка OWASP TOP 10 2017:

инъекции (A1 — Injection); некорректная аутентификация и управление сессией (A2 – Broken Authentication and Session Management); межсайтовое выполнение сценариев (A3 — Cross-Site Scripting (XSS)); нарушение контроля доступа (A4 - Broken Access Control); ошибки настройки параметров безопасности (A5 — Security Misconfiguration); раскрытие чувствительных данных (A6 — Sensitive Data Exposure); недостаточная защита от атак (A7 - Insufficient Attack Protection); подделка межсайтовых запросов (A8 — Cross-Site Request Forgery (CSRF)); использование компонентов с известными уязвимостями (A9 — Using Components with Known Vulnerabilities); незащищенный API (A10 - Underprotected APIs).

Дополнительные функции подсистемы

В работе подсистемы должны быть предусмотрены следующие возможности:

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

Политика безопасности

Подсистема должна позволять формировать политику безопасности на основании следующих принципов:

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

Подсистема должна содержать предустановленные типовые политик безопасности.

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

Поддерживаемые протоколы

Подсистема должна поддерживать протоколы:

HTTP; HTTPS (SSL/TLS, включая SSL v3, TLS v1.2) SOAP; XML; JSON.

Закрытие уязвимостей в защищаемом ПО

Подсистема должна поддерживать механизмы защиты и предотвращения использования уязвимостей кода средствами динамического и интерактивного анализа, выявления набора «опасных» параметров и их значений, и автоматического создания защитного правила (virtual patching). Также подсистема должна выдавать точную информацию о найденной уязвимости и созданном правиле для дальнейшего исправления небезопасного кода специалистами.

Антивирусная защита

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

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

Подсистема представления данных, управления событиями и подготовки отчетности должна обеспечивать:

централизованную систему сбора, агрегации и формирования отчетов для всех устройств комплекса; приоритезацию событий (приоритет, тип); агрегирование событий (группировка однотипных событий); фильтрацию событий (по различным полям); создание собственных параметров для группировки и приоритезации; детальный разбор каждого события (причина регистрации данного события (тело запроса), источник, получатель, время, протокол, метод, правило/политика по которому событие было зафиксировано); создание отчётов на основе зарегистрированных событий; предустановленные шаблоны сводных отчетов; возможность создания пользовательских сводных отчетов; возможность построения детализированных отчетов с использованием фильтров диапазона даты и времени, диапазона IP адресов, пользователей веб приложения, типов инцидентов; формирование отчетов как по запросу, так и по расписанию c последующим экспортом в файлы формата PDF или CSV и возможностью отправки по электронной почте; возможность формирования отчетов на русском языке.

Восстановление Системы

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

Требования к гарантийной и послегарантийной поддержке Для обеспечения необходимого уровня сервиса Система должна быть обеспечена поддержкой производителя на обновление ПО на срок не менее 7 (семи) лет. Участник должен обеспечить русскоязычную первую линию технической поддержки, оказываемую производителем, либо его авторизированным партнером на территории Российской Федерации. Стоимость гарантийной технической поддержки должна входить в стоимость оборудования. Прием и обработку запросов Исполнитель ведет круглосуточно, семь дней  в неделю. На все компоненты оборудования должна быть предоставлена гарантия на срок не менее 3-х лет и обеспечена дальнейшая техническая поддержка на срок не менее 4-х лет. Участник обеспечивает за свой счет необходимый ремонт оборудования на протяжении гарантийного срока. Участник обеспечивает наличие необходимого объема ЗИП к поставленному оборудованию.