WAF: интеграция в SOC через SIEM или ASOC? (Часть 2)
Преимущества интеграции SOC и WAF для мониторинга API
Здесь бы хотелось рассказать, как быть с событиями которые показывают аномалии в API и как использовать эти события при интеграции с SIEM-системами. Тут мы с Сергеем попробовали разобрать наиболее частые вариации. Но если у вас есть свои примеры — добро пожаловать в комментарии!
Основные полезности, для условной 1-й линии SOC можно распределить на 2 группы:
Мониторинг API-активности. SOC может использовать интегрированные в WAF системы обнаружения API для мониторинга активности взаимодействия с API, включая запросы, ответы, аутентификацию и авторизацию. Это позволяет обнаруживать подозрительную или незаконную активность, такую как несанкционированные попытки доступа или использование API для атак.
Обнаружение аномалий в API-трафике: Интеграция с системами обнаружения API позволяет SOC анализировать трафик и обнаруживать аномалии, такие как необычные или аномально высокие объемы запросов, необычные паттерны поведения или подозрительные изменения в обработке данных. Подобные ситуации характерны для поведенческих атак, таких как: перебор паролей, перебор идентификаторов сессии, принудительный просмотр ресурсов веб‑приложения (Forced Browsing), подстановка учетных данных.
В каких ситуациях это может быть важно.
Аномалия в API-трафике, связанная с резким повышение количества запросов к конечным точкам инфраструктуры содержащих аутентификационные данные, например пароли, токены и секретные ключи. На иллюстрации ниже представлено отображение таких эндпоинтов в «ПроAPI Структура» с указанием типов чувствительных данных (токен, пароль и т.д.) и количества хитов/атак.
За наблюдаемый период количество запросов к эндпоинтам API возросло в несколько раз по сравнению с обычным уровнем. Такая ситуация может быть вызвана различными факторами:
Маркетинговая акция. Если, в наблюдаемый период, компания запустила акцию или распродажу, для участия в которой пользователям необходимо авторизоваться в личных кабинетах, то это могло привести к резкому увеличению числа запросов.
Атака злоумышленников, которые пытаются получить доступы к аккаунтам.
Технические проблемы. Возможно, в вашей системе возникли технические неполадки, которые привели к множественному повторному отправлению запросов со стороны клиентов.
Что следует предпринять.
Самое трудное в данной ситуации — собрать те параметры, которые позволят увеличить вероятность корректного триажа событий\инцидентов.
Если простым языком «для SOCеров» — как понять, когда поведение нормальное, а когда зловредное. Тут кажется логическим следующая последовательность действий:
Мониторинг и анализ трафика. Его целью будет построение паттерна запросов для выявления аномального поведения. Следующим этапом будет выявление конечных точек API, подвергающихся наибольшему количеству атак. С помощью дашбород «Анализ угроз» платформы «Вебмониторэкс» можно визуализировать трафик запросов.
На представленной иллюстрации чётко видны пиковые значения количества запросов и количества хитов (атак).
«для SOCеров»: понятно что такой дашборд можно собрать на любой SIEM-системе, это скорее референс для быстрой сборки по параметрам. Стоит учитывать соотношение запросов к хитам (атакам) идентифицируемым WAF или системой защиты API.
На дашборде «Структура API» можно визуализировать перечень наиболее атакуемых эндпоинтов.
Выявленные в результате мониторинга паттерны трафика становятся основой для создания определения порогового значения количества запросов, используемого в корреляционном анализе для защиты от поведенческих атак. Корреляционный анализ проводится при превышении порога для количества запросов, отправленных на URL объекта с определенным идентификатором, URL директории с файлами ресурса или URL для аутентификации или активации пользователей. Порог определяется, чтобы снизить риск блокировки легитимных запросов (например, когда пользователь несколько раз вводит некорректный пароль от своего аккаунта). В нашей документации можно подробнее прочитать реализацию защиты от поведенческих атак с помощью продуктов «Вебмониторэкс».
«для SOCеров»: таким образом можно наполнить многомерный список с фиксацией количества событий к определенным группам URL, а дальше в логику правил корреляции добавить простой алерт на превышение порога по определенной группе URL.
В процессе мониторинга следует выявлять наличие в инфраструктуре потенциально опасных конечных точек. В этом поможет функция сравнения спецификаций, которая есть в «ПроAPI Структуре». Процесс организован следующим образом:
а. С помощью «ПроAPI Структуру» валидируется структура ваших эндпоинтов, их перечень и параметры, после этого структура фиксируется в виде файла в формате спецификации OpenAPI (OAS). Данную спецификацию будем использовать в качестве эталона.
б. Эталонную спецификацию сравниваем с построенной на трафике, это позволяет выявлять потенциально опасные API, такие как:
Shadow API. Недокументированный API, который существует в инфраструктуре организации без надлежащего разрешения или надзора.
Orphan API. Документированный API, который не получает трафик.
Zombie API. Устаревшие API, которые считаются отключенными, но на самом деле все еще используются.
в. Результаты сравнения будут отображены в «ПроAPI Структуре».
Подробнее про сравнение спецификаций читайте в нашей документации.
«для SOCеров»: Тут можно настроить дополнительный скоринг (повышение значимости события) в такой логике: если есть запрос к эндпоинту, но он относится к группе Shadow или Zombie — то повысить его скоринг. Списки можно наполнять автоматически через API из компонентов ПРО API или автоматически копируя URL из событий, в которых есть поле со значением Shadow\Zombie в отдельный список.
Оптимизация API. Опираясь на результаты мониторинга будет целесообразно провести оптимизацию эндпоинтов API. Целью оптимизации должно быть повышение безопасности и производительности инфраструктуры. Последнее поможет API успешно справляться с повышением нагрузки в период атак или маркетинговых акций. В первую очередь необходимо обратить внимание на потенциально опасные API, информацию о которых необходимо передать в команду разработки, в рамках процесса DevSecOps. В процессе оптимизации API мы рекомендуем использовать методы OWASP. Например, для защиты от атак вида brute-force предлагается внедрить:
а. Многофакторную аутентификацию.
б. Механизмы защиты от перебора учетных данных (В продукте «ПроWAF» это реализовано в виде триггеров с условием «Количество запросов»).
в. Captcha.
Для повышения производительности может потребоваться масштабирование API. Данный процесс рекомендуем проводить в рамках подхода API Security внутри DevSecOps. Подробнее про включение механик управления API можно посмотреть в нашей статье.
Промежуточный итог «для SOCеров» — При таком подходе появляются группы правил:
Сигнализирующие о превышении количества запросов в определенный период времени
Сигнализирующие о нехарактерных запросах к тем эндпоинтам, которым обращения быть не должно
Сигнализирующие о потенциально подозрительных запросах, которые выходят за ожидаемый диапазон для групп URL
В playbook добавляется порядок действий:
Сообщение разработчикам о наличии Shadow\Orphan\Zombie API;
Отслеживание запросов по группам URL, актуализация групп URL вместе с командой разработки
Реакция на нехарактерные запросы
Безопасность. После того как определились базовые процессы, можно приступить к тюнингу платформы. Для защиты от поведенческих атак доступны следующие инструменты:
а. Триггер на определение brute force атаки. На иллюстрации ниже представлен пример настройки триггера для блокировки классической brute force атаки.
«для SOCеров»: IP списки можно выгружать и использовать как часть TI-фидов, для обогащения информации о других атаках или сделать правило сопоставления вида «если зафиксирована атака с этого IP, занести его в список, найти другие атаки с этого же IP»
б. Триггер на определение BOLA/IDOR атак. На иллюстрации ниже представлен пример настройки триггера.
«для SOCеров»: Такой тип событий от системы можно однозначно идентифицировать как инцидент, а списки URL, для которых задетектировано событие направлять разработке
в. Триггер на определение forced browsing. На иллюстрации ниже представлен пример настройки триггера.
«для SOCеров»: Такой тип событий более сложный для однозначной идентификации, но принцип действий аналогичен варианту с brute force.
Доступность API. Настройте защиту от DDoS-атак на уровне L7. Защита от DDoS атак на уровне L7 осуществляется путём настройки триггеров на brute force и forced browsind, а также правила на rate limit. Данное правила направлено на регулирования лимита подключений, которое помогает предотвратить чрезмерный трафик к вашему API. Это правило позволяет указать максимальное количество подключений, которые можно установить к определенной области, а также гарантировать равномерное распределение входящих запросов. При превышении установленного лимита, входящий запрос будет отклонён и отправлен код, выбранный при настройке правила. Подробнее про настройку правил можно прочитать в нашей документации. Ниже представлен пример настройки правила для ограничения на 5 POST-запросов в минуту для каждого IP-адреса.
Далее рассмотрим, что происходит после выполнения действий, описанных в пунктах 1–4. Если настроенные триггеры фиксируют запросы, содержащие признаки атак типа brute force или forced browsing, они отображаются в разделе «События» платформы. Данные события будут обработаны в соответствие с настройками триггера, например ip-адрес будут добавлены в чёрный список для блокировки, а пользователь может получить уведомление об этом.
Поскольку, признаком атаки является резкое увеличение количества запросов в определённый момент времени, детектирование начала атаки необходимо производить путём сравнения двух схожих периодов времени на основе статистики по запросам. Если в рассматриваемый период есть число запросов, превышающее количество запросов в аналогичный промежутки времени в прошлом, то это является маркером начала атаки.
Проинтегрировать компоненты нашей платформы с SIEM-системами достаточно просто, выглядит примерно так:
Более подробно про детали интеграции и варианты взаимодействия с компонентами SOC\ASOC мы рассмотрим в следующей части статьи.
А пока краткий итог , что можно получить на основе тех событий, которые генерирует WAF и платформа защиты API «для SOCеров»:
Настроить несколько групп правил корреляции для отслеживания происходящего с API
Сформировать регулярные или прецедентные действия при обнаружении определенных типов событий
Обогатить TI-списки для повышения скоринга других событий идентифицируемых NGFW\IPS или NTA
Настроить интеграцию средств защиты, к примеру: блокировать на файрволе IP, с которых WAF-ом была идентифицирована атака
Подписывайтесь на наш канал в Telegram. Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы.
