Преимущества интеграции 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 из событий, в которых есть поле со значением ShadowZombie в отдельный список.
-
Оптимизация API. Опираясь на результаты мониторинга будет целесообразно провести оптимизацию эндпоинтов API. Целью оптимизации должно быть повышение безопасности и производительности инфраструктуры. Последнее поможет API успешно справляться с повышением нагрузки в период атак или маркетинговых акций. В первую очередь необходимо обратить внимание на потенциально опасные API, информацию о которых необходимо передать в команду разработки, в рамках процесса DevSecOps. В процессе оптимизации API мы рекомендуем использовать методы OWASP. Например, для защиты от атак вида brute-force предлагается внедрить:
а. Многофакторную аутентификацию.
б. Механизмы защиты от перебора учетных данных (В продукте «ПроWAF» это реализовано в виде триггеров с условием «Количество запросов»).
в. Captcha.
Для повышения производительности может потребоваться масштабирование API. Данный процесс рекомендуем проводить в рамках подхода API Security внутри DevSecOps. Подробнее про включение механик управления API можно посмотреть в нашей статье.
Промежуточный итог «для SOCеров» - При таком подходе появляются группы правил:
-
Сигнализирующие о превышении количества запросов в определенный период времени
-
Сигнализирующие о нехарактерных запросах к тем эндпоинтам, которым обращения быть не должно
-
Сигнализирующие о потенциально подозрительных запросах, которые выходят за ожидаемый диапазон для групп URL
В playbook добавляется порядок действий:
-
Сообщение разработчикам о наличии ShadowOrphanZombie 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-системами достаточно просто, выглядит примерно так:
Более подробно про детали интеграции и варианты взаимодействия с компонентами SOCASOC мы рассмотрим в следующей части статьи.
А пока краткий итог , что можно получить на основе тех событий, которые генерирует WAF и платформа защиты API «для SOCеров»:
-
Настроить несколько групп правил корреляции для отслеживания происходящего с API
-
Сформировать регулярные или прецедентные действия при обнаружении определенных типов событий
-
Обогатить TI-списки для повышения скоринга других событий идентифицируемых NGFWIPS или NTA
-
Настроить интеграцию средств защиты, к примеру: блокировать на файрволе IP, с которых WAF-ом была идентифицирована атака
Подписывайтесь на наш канал в Telegram. Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы.
Автор: isstoryteller
