Преимущества интеграции SOC и WAF для мониторинга API

Здесь бы хотелось рассказать, как быть с событиями которые показывают аномалии в API и как использовать эти события при интеграции с SIEM-системами. Тут мы с Сергеем попробовали разобрать наиболее частые вариации. Но если у вас есть свои примеры – добро пожаловать в комментарии!

Основные полезности, для условной 1-й линии SOC можно распределить на 2 группы:

Мониторинг API-активности. SOC может использовать интегрированные в WAF системы обнаружения API для мониторинга активности взаимодействия с API, включая запросы, ответы, аутентификацию и авторизацию. Это позволяет обнаруживать подозрительную или незаконную активность, такую как несанкционированные попытки доступа или использование API для атак.

Обнаружение аномалий в API-трафике: Интеграция с системами обнаружения API позволяет SOC анализировать трафик и обнаруживать аномалии, такие как необычные или аномально высокие объемы запросов, необычные паттерны поведения или подозрительные изменения в обработке данных. Подобные ситуации характерны для поведенческих атак, таких как:  перебор паролей, перебор идентификаторов сессии, принудительный просмотр  ресурсов веб‑приложения (Forced Browsing), подстановка учетных данных.

В каких ситуациях это может быть важно. 

Аномалия в API-трафике, связанная с резким повышение количества запросов к конечным точкам инфраструктуры содержащих аутентификационные данные, например пароли, токены и секретные ключи. На иллюстрации ниже представлено отображение таких эндпоинтов в «ПроAPI Структура» с указанием типов чувствительных данных (токен, пароль и т.д.) и количества хитов/атак.

За наблюдаемый период количество запросов к эндпоинтам API возросло в несколько раз по сравнению с обычным уровнем. Такая ситуация может быть вызвана различными факторами:

  • Маркетинговая акция. Если, в наблюдаемый период, компания запустила акцию или распродажу, для участия в которой пользователям необходимо авторизоваться в личных кабинетах, то это могло привести к резкому увеличению числа запросов.

  • Атака злоумышленников, которые пытаются  получить доступы к аккаунтам.

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

Что следует предпринять.

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

Если простым языком «для SOCеров» – как понять, когда поведение нормальное, а когда зловредное. Тут кажется логическим следующая последовательность действий:

  1. Мониторинг и анализ трафика. Его целью будет построение паттерна запросов для выявления аномального поведения. Следующим этапом будет выявление конечных точек 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 в отдельный список.

  1. Оптимизация 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 вместе с командой разработки

  • Реакция на нехарактерные запросы

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

    а. Триггер на определение brute force атаки. На иллюстрации ниже представлен пример настройки триггера для блокировки классической brute force атаки.

«для SOCеров»: IP списки можно выгружать и использовать как часть TI-фидов, для обогащения информации о других атаках или сделать правило сопоставления вида «если зафиксирована атака с этого IP, занести его в список, найти другие атаки с этого же IP»
б. Триггер на определение BOLA/IDOR атак. На иллюстрации ниже представлен пример настройки триггера.

 

«для SOCеров»: Такой тип событий от системы можно однозначно идентифицировать как инцидент, а списки URL, для которых задетектировано событие направлять разработке

в. Триггер на определение forced browsing. На иллюстрации ниже представлен пример настройки триггера.

«для SOCеров»: Такой тип событий более сложный для однозначной идентификации, но принцип действий аналогичен варианту с brute force.

  1. Доступность 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. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. 

Комментарии (0)