I. открытый запрос предложений


НазваниеI. открытый запрос предложений
страница4/7
ТипДокументы
filling-form.ru > Договоры > Документы
1   2   3   4   5   6   7

РАЗДЕЛ 4. ТЕХНИЧЕСКОЕ ЗАДАНИЕ




Общие сведения


Наименование работ: Создание системы защиты веб-приложений.

Условное обозначение: Система.

Заказчик – ООО «МультиКарта».

Цели и задачи выполнения работ

    1. Цель создания системы


Целью создания Системы является выявление и предотвращение атак на веб-приложения Заказчика.

В результате создания Системы должны быть решены следующие задачи:

  • предотвращение атак на веб-сервисы Заказчика;

  • предотвращение утечки конфиденциальных данных через веб-приложения;

  • предотвращение несанкционированных изменений внешнего вида и содержимого веб-приложений;

  • предотвращение материальных потерь из-за атак на веб-приложения;

  • выполнение требований регуляторов;

  • аутентификация внешних приложений по клиентским сертификатам на Системе;

  • защита от атак типа «отказ в обслуживании» на прикладном уровне сетевой модели OSI.

Границы проведения работ


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

  • г. Москва, Воронцовская ул., 43 стр. 1;

  • г. Санкт-Петербург, ул. Маршала Говорова, д. 52.

На двух площадках Заказчика должен быть построен геораспределенный кластер.

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

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

    1. Общие требования к функциям Системы


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

подсистема обнаружения атак;

подсистема подтверждения уязвимостей;

подсистема управления.

Система должна иметь возможность отправки сообщений об атаке в универсальном формате syslog и Common Event Format (CEF).

Система должна обеспечивать защиту от DDoS-атак на прикладном уровне сетевой модели OSI.

Система должна обеспечивать анализ журналов событий веб-серверов и pcap-файлов.

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

Система должна поддерживать обновление модулей и сигнатур атак.

Система должна поддерживать терминацию клиентских SSL/TSL соединений на себе.

Система должна обеспечивать возможность создания правил, направленных на предотвращение реализации известных уязвимостей (virtual patching).

Система должна иметь возможность интеграции с системами:

управления событиями информационной безопасности (SIEM);

антивирусной защиты или DLP-системами с использованием протокола ICAP;

статического и динамического анализа кода (SAST/DAST) для автоматического формирования правил блокировки уязвимостей (virtual patching), обнаруженных в ходе анализа исходного кода веб-приложений.

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

Системы должна поставляться в виде программно-аппаратного комплекса.

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

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

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

Система должна поддерживать протоколы HTTP, HTTPS (SSL/TLS, включая SSL v3, TLS v1.2 без использования алгоритмов (DH, DHE, EDH, ECDHE) согласования ключей, обладающие свойствами perfect forward secrecy), Simple Object Access Protocol (SOAP), (eXtensible Markup Language (XML), JavaScript Object Notation (JSON).

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

механизм фильтрации событий (по приоритету, типу события);

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

механизм приоритезации (по приоритету, типу события);

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


Подсистема должна обеспечивать выявление и предотвращение атак, связанных с эксплуатацией рисков безопасности, описанных в списке OWASP Top Ten 2013.

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

HTTP-атаки, включая атаки на переполнение буфера;

противодействие брутфорс-атакам (подбор паролей);

защита от фрода (проверка привязки к сессии пользователя, детектирование автоматизированной активности);

защита от роботов;

защита Cookie (флаг HttpOnly);

атак XSS (Сross Site Sсriрting);

атак HPP (HTTP Parameter);

атак HPC (HTTP Parameter Contamination — обработка некорректных параметров);

атак XXE (XML eXternal Entity);

атак класса SQL Injection;

атак LFI (Local File Inclusion);

атак RFI (Remote File Inclusion);

атак XQuery Injection;

атак HTTP Verb Tampering;

атак DNS Rebinding;

атак Resource Injection;

атак OS commanding;

атак CSRF (Cross Site Request Forgery);

атак Path Traversal;

атак DOM-based XSS;

атак Open Redirect.

Подсистема должна осуществлять обнаружение сетевых атак (вторжений), направленных на веб-приложения, следующими способами:

сигнатурный метод — посредством сопоставления параметров (частей) текущих запросов на доступ с сигнатурами атак, которые содержатся в БД;

эвристический метод — посредством сопоставления характеристик текущих запросов с характеристиками аналогичных запросов, полученных ранее.

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

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


Подсистема должна иметь механизм подтверждения наличия уязвимости веб-приложения. В случае не подтверждения присутствия уязвимости подсистема должна иметь возможность отключения сработавшего правила.
    1. Требования к подсистеме управления


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

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

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

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


Система обнаружения и предотвращения атак на веб-приложения должна иметь сертификат на соответствие требованиям руководящего документа «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» — по 4-му уровню контроля и технических условий.

Система обнаружения и предотвращения атак на веб-приложения должна быть включена в Единый реестр российских программ для электронных вычислительных машин и баз данных.
    1. Требования к архитектуре системы


В состав Системы должны входить:

серверный модуль (модули);

клиентский модуль (консоль управления).

Система должна быть установлена в отказоустойчивом геораспределенном кластере

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

обратный прокси-сервер;

non-inline-подключение в режиме мониторинга;

автономный режим.

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

Active/Active;

Active/Passive.

Система должна обеспечивать хранение информации об атаках для дальнейшего анализа.

Состав и содержание работ по созданию системы


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

предпроектное обследование и разработка Технического задания;

разработка технического проекта и рабочей документации;

ввод в действие;

сервисное обслуживание.

Ограничения при проведении работ:

  • разработка политик безопасности для двух веб приложений.

  • разработка 10 специализированных правил для политик безопасности.

  • настройка обработки и проверки пользовательских сертификатов.

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

  • разработка 3 специализированных отчетов.

  • настройка интеграции с SIEM ArcSight.
    1. Предпроектное обследование и разработка Технического задания


Целями этапа являются:

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

формирование требований к Системе.

На этапе предпроектного обследования специалистами Исполнителя должны быть выполнены следующие работы:

проведение интервью с разработчиками и администраторами АС;

осмотр серверных помещений.

На данном этапе должны быть собраны сведения:

о структуре комплекса используемых программно-технических средств;

о типах оборудования и его размещении на объектах;

о наименованиях системного и прикладного ПО;

об используемых каналах связи и точках подключения к сетям связи;

об используемых программно-технических средствах защиты информации;

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

На основании анализа собранной информации должен быть сформирован перечень технических требований к Системе. Данный перечень требований должен быть задокументирован и оформлен в виде документа «Техническое задания на создание системы защиты веб приложений)» (ТЗ).

Структура и содержание ТЗ должны быть разработаны в соответствии с требованиями ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» и руководящих документов в области защиты информации.
    1. Разработка технического проекта и рабочей документации


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

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

Пояснительная записка к техническому проекту.

В состав комплекта рабочей документации требуется включить следующие документы:

Описание настроек средств защиты информации;

Программа и методика испытаний.

Структура и содержание документации должны быть разработаны в соответствии с требованиями РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».
    1. Ввод в действие


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

комплектация Системы оборудованием и программным обеспечением;

пусконаладочные работы;

проведение опытной эксплуатации;

проведение приемочных испытаний.

Комплектация Системы оборудованием и программным обеспечением

На стадии комплектации Системы проводятся работы по закупке и поставке Заказчику средств защиты в соответствии со спецификацией оборудования и программного обеспечения, подготовленной Исполнителем.

Пусконаладочные работы

На стадии пусконаладочных работ производятся:

монтаж оборудования;

установка и настройка программного обеспечения в соответствии с решениями, описанными в техническом проекте и рабочей документации;

комплексная наладка всех средств системы.

Опытная эксплуатация

На стадии опытной эксплуатации проводятся следующие работы:

опытная эксплуатация;

анализ результатов опытной эксплуатации АС;

доработка и дополнительная наладка программного обеспечения и технических средств (при необходимости);

оформление акта о завершении опытной эксплуатации.

Приемочные испытания

На этапе приемочных испытаний должны быть проведены:

испытания на соответствие Техническому заданию в соответствии с программой и методикой приемочных испытаний;

анализ результатов испытаний и устранение недостатков, выявленных при испытаниях;

оформление акта приемки в промышленную эксплуатацию.
    1. Расширенная техническая поддержка


Расширенная техническая поддержка Системы должна осуществляться Исполнителем в течение одного календарного года с момента подписания Акта приемки системы в промышленную эксплуатацию. Описание уровня технической поддержки и основных метрик оказания услуг приведено в Таблице 1 и Таблице 2.

Таблица . Описание Технической поддержки

Сервисные опции

Комментарии

Решение инцидентов работоспособности

Консультации по проблемам




Удаленная диагностика




Аварийный выезд

1 раз в течение контракта

Регламентные работы

Сопровождение обновления




Администрирование конфигурации

Консультации по функционалу




Администрирование политики

Консультации по политикам




Таблица . – Основные метрики оказания услуг

Наименование

Значение

Время обслуживания

11*5

С 9 до 20 Москвы по рабочим дням

Время реагирования на запросы согласно уровню критичности

Очень срочно – не более 2 часов

Срочно – не более 4 часов

Некритично – не более 6 часов

Количество зарегистрированных (уполномоченных) сотрудников Заказчика

Не более 4 сотрудников



1   2   3   4   5   6   7

Похожие:

I. открытый запрос предложений iconДокументация на открытый запрос предложений
Открытый запрос предложений в электронной форме на право заключения договора на оказание услуг по комплексной уборке

I. открытый запрос предложений iconОткрытый запрос предложений на
Нормативные основы регулирования порядка проведения открытого запроса предложений (далее – Запрос предложений)

I. открытый запрос предложений iconОткрытый запрос предложений
Участники) к участию в процедуре открытого запроса предложений (далее — Запрос предложений) на право заключения договоров на поставку...

I. открытый запрос предложений iconО проведении
Форма закупочной процедуры: открытый запрос предложений (далее – запрос предложений)

I. открытый запрос предложений iconО проведении
Форма закупочной процедуры: открытый запрос предложений (далее – запрос предложений)

I. открытый запрос предложений iconО проведении
Форма закупочной процедуры: открытый запрос предложений (далее – запрос предложений)

I. открытый запрос предложений iconИзвещение о проведении открытого запроса предложений в электронной...
Форма процедуры закупки: Открытый запрос предложений в электронной форме далее «Запрос предложений»

I. открытый запрос предложений iconТверждаю а Департамента по у правлению конкурентными закупками документация...
Документация о Запросе предложений Запрос предложений №045/ГАвиа/2-3219/20. 07. 11/З

I. открытый запрос предложений iconИзвещение о проведении открытого запроса предложений в электронной форме
Форма процедуры закупки: Открытый запрос предложений в электронной форме далее «Запрос предложений»

I. открытый запрос предложений iconДокументация по запросу предложений открытый запрос предложений на право заключения
Исполнителей) к участию в процедуре открытого конкурентного Запроса предложений (далее — Запрос предложений) на право заключения...

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск