Карточка защитной меры

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

Реализация очистки входящего из сети Интернет сетевого трафика от аномалий на уровне L3/L4

1 17

Цель: обеспечение защиты инфраструктуры от сетевых атак, направленных на "отказ в обслуживание".

Распределенная атака отказа в обслуживании (DDoS) — это злонамеренная попытка нарушить нормальную работу сервера, сети, веб-приложения и других компонентов инфраструктуры путем перегрузки самой цели или ее окружения вредоносным трафиком, сгенерированным множеством одновременных и скоординированных DoS-атак.

В частности, DDoS-атаки уровня L3 и L4 нацелены на процессы и оборудование, работающие на нижних уровнях модели OSI: сетевом (уровень 3) и транспортном (уровень 4). Основная цель таких атак — истощение ресурсов сетевой инфраструктуры, в результате чего легитимные пользователи теряют доступ к целевому ресурсу.

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

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

Рекомендации к заполнению карточки:

Приложите скан-копию договора с провайдером в Реестр документов по защите информации (в модуле активов SECURITM). Укажите созданный актив в качестве инструмента к данной защитной мере.
Добавить шаблон регулярной контрольной задачи на продление (перезаключение) приложенного договора.

Область действия: Вся организация

Классификация

Тип

Техническая

Превентивная

Реализация

Вручную

Периодичность

Ежегодно

Ответственный

Не определено

Инструменты

Не определено

Для просмотра файла необходимо авторизоваться!

Требования к защите от DDoS.docx

Ресурсная оценка

	Качественная оценка			Количественная оценка		Итоговая оценка
	Стоимость	Трудозатраты	Сложность	Стоимость, тыс. руб	Трудозатраты, дней/ год	Итоговая оценка
CAPEX ^?	Средняя	Низкие	Низкая	Неизвестно	Неизвестно	6 - Низкая
OPEX ^?	Средняя	Низкие	Низкая	Неизвестно	Неизвестно	6 - Низкая

Связанные риски

Ничего не найдено

Заметки

SECURITM

2 дня назад

Community

1. Требования к подсистеме фильтрации трафика DDoS-атак:
● Подсистема должна обеспечивать защиту от всего спектра атак вида «отказ в обслуживании», направленных как на исчерпание канальной емкости, так и на исчерпание ресурсов прикладной системы;
● Подсистема должна сохранять функциональность и инфраструктуру телекоммуникационной сети Заказчика, находящейся на момент разработки настоящего ТЗ в эксплуатации. Обеспечение возможности фильтрации вредоносного трафика и защиты не должно зависеть от физического расположения компонентов веб-инфраструктуры заказчика;
● Подсистема должна поддерживать возможность фильтровать зашифрованный трафик (HTTPS) сайта на всех уровнях сети, включая прикладной, без предоставления закрытых ключей шифрования;

● Подсистема должна поддерживать возможность работы с зашифрованным трафиком (HTTPS) сайта, включая:

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

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

- анализ и защита сервиса на транспортном и сетевом уровне (протоколы IP, TCP и т. д.);

● Подсистема должна поддерживать возможность импорта информации о подозрительных IP-адресах, подлежащих блокировке, посредством протокола syslog от систем управления событиями информационной безопасности (SIEM), обслуживающих сетевую инфраструктуру Заказчика.

● Подсистема должна поддерживать возможность немедленной блокировки подозрительного IP-адреса по особому HTTP-коду ответа сервера Заказчика как в раскрытом HTTP и HTTPS-трафике, так и зашифрованном HTTPS-трафике на основе анализа журналов доступа.

● Подсистема должна обладать собственным номером автономной системы (AS) и собственными IP-сетями для фильтрации и перенаправления трафика;

● Подсистема должна предоставлять возможность подключения посредством установления BGP-сессий между автономной системой (AS) Заказчика и своей AS в каждой точке присоединения и анонса любого подмножества сетевых префиксов Заказчика размерностью не менее /24.

● Подсистема должна быть в состоянии обрабатывать трафик защищаемого ресурса единовременно на не менее чем двух центрах очистки трафика, расположенных на территории Российской Федерации и использующих для этой цели не менее чем трёх различных поставщиков услуг связи, и одновременно с этим единовременно на не менее чем двух центрах очистки трафика, расположенных вне территории Российской Федерации и использующих для этой цели не менее чем трёх различных поставщиков услуг связи уровня не менее Tier-1. Подсистема в целом должна быть в состоянии одновременно задействовать для обработки трафика защищаемого ресурса не менее чем шесть независимых подключений к поставщикам услуг связи;

● Подсистема должна осуществлять обработку и фильтрацию трафика без непосредственного подключения к точкам обмена трафиком (Internet Exchange);

● Подсистема должна функционировать без вмешательства во взаимодействие пользователя и веб-приложения;

● Подсистема должна поддерживать функциональность мониторинга IP-сетей на предмет утечек BGP-маршрутов и угона IP-префиксов;

● Подсистема должна поддерживать функциональность мониторинга IP-сетей на предмет наличия серверов, уязвимых к атакам типа amplification;

● Подсистема должна иметь возможность предоставить IP-адреса из своего адресного пространства в количестве не менее 2 шт.;

● Подсистема должна поддерживать возможность осуществления HTTP redirect;

● Подсистема должна поддерживать предоставление программного интерфейса (API) для управления доступом к ресурсу на основе «чёрных» и «белых» списков IP-адресов, получения статистики работы защищаемого ресурса;

● Подсистема должна поддерживать возможность использования совместно с системами кеширования статического контента сайта (CDN);

● Подсистема должна предоставлять возможности по защите DNS-серверов от DDoS-атак следующими методами:

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

● Подсистема должна поддерживать возможность балансировки нагрузки между серверами защищаемого веб-приложения по алгоритмам primary-backup, round-robin, iphash, а также в определённых пропорциях;

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

● Подсистема должна иметь функционал формирования отчетов о произошедших инцидентах безопасности, включающих в себя данные о количестве и составе заблокированных ip-адресов, тип атаки и ее показатели;

● Подсистема должна иметь функционал формирования ежемесячных отчетов о предоставленном сервисе и уровне его качества;

● Подсистема должна поддерживать возможность установки туннельных инкапсулирующих соединений (IP-in-IP, GRE) между центрами очистки трафика и интернет-инфраструктурой заказчика;

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

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

● В системе должен быть реализован сбор статистики в реальном времени со средним (за неделю) интервалом не более 5 минут и предоставление ее в виде графиков в персональном кабинете пользователя и в виде программного интерфейса (API);

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

● Классификация запросов пользователей к защищаемому сервису в системе должна осуществляться на основе поведенческого анализа, моделирования взаимодействия легитимных пользователей с защищаемым ресурсом и генерации сценариев их поведения;

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

- общий объем входящего трафика (Мбит/с, пакетов/с),

- объем легитимного входящего трафика (Мбит/с, пакетов/с),

- объем исходящего трафика (Мбит/с),

- количество входящих HTTP-запросов,

- скорость работы защищаемого HTTP-ресурса,

- количество HTTP-ошибок,

- динамику списка заблокированных IP-адресов,

- географическое распределение списка заблокированных IP-адресов,

- прочие параметры работы ресурса -- по запросу,

- ежемесячное формирование отчетов об инцидентах;

● Подсистема должна осуществлять мониторинг и оповещение по SMS и электронной почте о проблемах с защищаемыми ресурсами.

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

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

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

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

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

перебор и скачивание содержимого сетевого ресурса (web scraping)
перебор логинов, паролей, промо-кодов в полях ввода и формах авторизации (brute-force attacks)
массовая подстановка значений в формы контактных данных, опросов, поисковых систем (credential stuffing)
атаки на заполнение корзины покупателя и исчерпание товарного каталога
автоматизированная массовая скупка билетов, товаров, услуг на сетевых ресурсах, осуществляющих розничную онлайн-торговлю

● Подсистема должна реализовывать следующие методы обнаружения ботов в web-приложениях:

Анализ заголовков запросов, тела запросов и контекста сессий прикладного трафика на предмет аномалий, характерных для автоматизированных инструментов.
Сбор отпечатка клиентского веб-браузера с использованием инъекции JavaScript-кода на отдельной странице, демонстрируемой сетевому пользователю, и передача данного отпечатка в Подсистему для анализа и выявления аномалий в параметрах браузера и устройства пользователя.
Поиск наличия компонентов, характерных для автоматизированных headless-браузеров в данных отпечатка клиентского веб-браузера.
Поведенческий анализ одиночных пользователей и групп пользователей на предмет активности, нехарактерной для общей пользовательской базы, и оценка его влияния на состояние публичного ресурса Заказчика.

● Подсистема должна обеспечивать защиту API нативных мобильных клиентов на базе iOS и Android, поддерживая следующие возможности:

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

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

Запись в журнал
Разметка запроса особым заголовком и пропуск в сторону ресурса Заказчика.
Демонстрация страницы проверки с JavaScript-кодом для сбора отпечатка браузера.
Отдача пользователя ответа с кодом ошибки.
Блокировка IP-адреса пользователя на варьируемый временной интервал.

● Подсистема должна поддерживать возможность передачи IP-адресов выявленных вредоносных ботов подсистеме фильтрации трафика для их блокировки на распределенном периметре защиты.

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.