Что такое web application firewall

Web Application Firewall: работа на опережение

В одном из предыдущих постов мы рассказывали об отражении DDoS-атак при помощи анализа трафика по протоколу Netflow. Само собой, DDoS — далеко не единственная проблема, с которой может столкнуться ресурс. Воображение злоумышленников весьма и весьма велико, да и технических средств у них хватает. Плюс не стоит забывать о том, что какой-то из ваших ресурсов вполне может работать на ПО с zero-day-уязвимостями.

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

В этом посте мы расскажем, как работает WAF от Билайн Бизнес, какие у него есть преимущества и как его оперативно подключить для своей компании.

Зачем вообще нужен WAF

В прошлом году компания Positive Technologies выпустила своё исследование «Уязвимости веб-приложений 2019», согласно которому доля веб-приложений, содержащих уязвимости высокого уровня риска, составила уже 67%. Самые частые проблемы — недостаточно защищенная зона авторизации, SQL-инъекции и чтение произвольных данных. Плюс растёт процент систем, в которых возможна утечка данных.

О важности защиты веб-приложений говорит и один из отчётов аналитиков Gartner:

Основные различия WAF, IPS и NGFW (Gartner)

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

По данным Positive Technologies

Для защиты от подобного в компаниях и существуют специалисты по информационной безопасности, определяющие допустимость использования того или иного софта, а также общие политики безопасности. При этом общие тенденции — рост числа самих приложений, активное использование различных API, работа в условиях смешанной среды (in-house-приложения, частные и облачные) активно намекают, что многие процессы стоит автоматизировать.

Особенно в области информационной безопасности.

Основные проблемы для компаний при попытках развернуть подобные решения самостоятельно заключались в том, что время реакции на активную угрозу было довольно большим, как и стоимость владения самим решением. Хотелось, как обычно — чтобы и побыстрее, и подоступнее. А в идеале ещё и с облачной версией решения, которую можно быстро подключить и комфортно администрировать.

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

Прежде всего, мы взяли список 10 самых главных угроз для веб-приложений 2020 от OWASP и осуществили защиту от них по обеим моделям (позитивная и негативная).

Конечно, здесь же есть отражение атак нулевого дня, включая и HTTPS, а также блокировка трафика по географическому признаку.

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

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

Кстати, есть парочка мифов насчёт избыточности самой сути WAF и его необходимости. Обычно приводят в пример вот что:

Шлюз безопасности и мониторинг сессий меня защитит
Веб-приложения должны быть доступны всем, поэтому остается только разрешить весь входящий трафик на порты 80 (HTTP) и 443 (HTTPS) и надеяться, что все будут играть по правилам. Мониторинг сессий на наличие, идентификацию и блокирование исполняемого кода не заменяет анализ трафика веб-приложений, поэтому эксплуатация уязвимости посредством легитимного веб-запроса не составляет труда при наличии шлюза безопасности «всё в одном».

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

Но удобство использования и качество их работы далеки даже от среднего уровня профессиональных сканеров веб-приложений, и доверие к таким продуктам не может быть восстановлено после нахождения критических уязвимостей там, где универсальный сканер отработал на 100%.

Как всё работает

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

Есть три способа подключения, которые определяются тем, где решено проводить анализ трафика:

Кроме трёх вариантов подключения, есть и два варианта развертывания:

Преимущества решения

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

Обычно единичной услугой считается подключение WAF на определённый сайт клиента. В нашем случае, если у клиента, допустим, два сайта на одном сервере, которые доступны с двух разных IP, мы всё равно считаем это как одну услугу предоставления WAF, просто суммируя общий трафик клиента.

Источник

Эволюция Web Application Firewall: от сетевых экранов до облачных систем защиты с машинным обучением

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

Что такое WAF

Более 75% атак хакеров направлены на уязвимости веб-приложений и сайтов: такие атаки, как правило, незаметны для ИБ-инфраструктуры и ИБ-служб. Уязвимости веб-приложений несут в себе, в свою очередь, риски компрометации и фрода учетных записей и персональных данных пользователей, паролей, номеров кредитных карт. Кроме того, уязвимости в веб-сайте служат точкой входа злоумышленников в корпоративную сеть.

Web Application Firewall (WAF) представляет собой защитный экран, который блокирует атаки на веб-приложения: SQL-инъекции, межсайтовый скриптинг, удаленное выполнение кода, брутфорс и обход авторизации (auth bypass). В том числе атаки, использующие zero-day уязвимости. Файрволы приложений обеспечивают защиту, выполняя мониторинг содержимого веб-страниц, включая HTML, DHTML и CSS, и фильтруя потенциально вредоносные запросы по HTTP/HTTPS.

Какими были первые решения?

Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».

Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).

Но SEAL не являлся полноценным WAF-решением. Он представлял собой классический сетевой файрвол с расширенной функциональностью — возможностью блокировать атаки на FTP и RSH. По этой причине первым WAF-решением сегодня считается продукт компании Perfecto Technologies (позже Sanctum). В 1999 году она представила систему AppShield. В то время Perfecto Technologies занимались разработкой ИБ-решений для e-commerce, и целевой аудиторией их нового продукта стали онлайн-магазины. AppShield умел анализировать HTTP-запросы и блокировал атаки на основе динамических ИБ-политик.

Примерно в одно время с AppShield (в 2002 году) появился первый WAF с открытым исходным кодом. Им стал ModSecurity. Он создавался с целью популяризации WAF-технологий и поддерживается IT-сообществом до сих пор (вот его репозиторий на GitHub). ModSecurity блокирует атаки на приложения, основываясь на стандартном наборе регулярных выражений (сигнатур) — инструментов для проверки запросов по шаблону — OWASP Core Rule Set.

В итоге разработчикам удалось добиться своей цели — на рынке начали появляться новые WAF-решения, в том числе построенные на базе ModSecurity.

Три поколения — уже история

Принято выделять три поколения WAF-систем, эволюционировавших по мере развития технологий.

Первое поколение. Работает с регулярными выражениями (или грамматиками). К нему относится ModSecurity. Поставщик системы изучает типы атак на приложения и формирует паттерны, которые описывают легитимные и потенциально вредоносные запросы. WAF сверяется с этими списками и решает, что делать в конкретной ситуации, — блокировать трафик или нет.

Примером обнаружения на основе регулярных выражений является уже упомянутый проект Core Rule Set с открытым исходным кодом. Еще пример — Naxsi, который также является опенсорсным. Системы с регулярными выражениями имеют ряд недостатков, в частности, при обнаружении новой уязвимости администратору приходится создавать дополнительные правила вручную. В случае с масштабной IT-инфраструктурой правил может быть несколько тысяч. Управлять таким количеством регулярных выражений довольно сложно, не говоря о том, что их проверка может снижать производительность сети.

Также регулярные выражения имеют довольно высокий уровень ложных срабатываний. Знаменитый лингвист Ноам Хомский предложил классификацию грамматик, в которой разделил их на четыре условных уровня сложности. Согласно этой классификации, регулярными выражениями можно описать только правила файрвола, которые не предполагают отклонений от шаблона. Это означает, что злоумышленники могут легко «обмануть» WAF первого поколения. Один из методов борьбы с этим — добавить в запросы к приложениям специальные символы, которые не влияют на логику вредоносных данных, но нарушают сигнатурное правило.

Второе поколение. Чтобы обойти проблемы, связанные с производительностью и точностью WAF, были разработаны файрволы приложений второго поколения. В них появились парсеры, которые отвечают за выявление строго определенных типов атак (на HTML, JS и т. д.). Эти парсеры работают со специальными токенами, описывающими запросы (например, variable, string, unknown, number). Потенциально вредоносные последовательности токенов выносятся в отдельный список, с которым регулярно сверяется WAF-система. Впервые этот подход показали на конференции Black Hat 2012 в виде C/C++ библиотеки libinjection, которая позволяет выявлять SQL-инъекции.

По сравнению с WAF первого поколения, специализированные парсеры могут работать быстрее. Однако они не решили трудности, связанные с ручной настройкой системы при появлении новых вредоносных атак.

Третье поколение. Эволюция в логике обнаружения третьего поколения заключается в применении методов машинного обучения, позволяющих максимально приблизить грамматику обнаружения к реальной грамматике SQL/HTML/JS защищаемых систем. Данная логика обнаружения в состоянии адаптировать машину Тьюринга для охвата рекурсивно перечисляемых грамматик. Причем ранее задача создания адаптируемой машины Тьюринга была неразрешимой, пока не были опубликованы первые исследования нейронных машин Тьюринга.

Машинное обучение предоставляет уникальную возможность адаптировать любую грамматику для охвата любого типа атак без создания списков сигнатур вручную, как это требовалось при обнаружении первого поколения, и без разработки новых токенизаторов/парсеров для новых типов атак, таких как внедрения Memcached, Redis, Cassandra, SSRF, как того требовала методология второго поколения.

Объединяя все три поколения логики обнаружения, мы можем нарисовать новую диаграмму, на которой красным контуром представлено третье поколение обнаружения (рис. 3). К этому поколению относится одно из решений, которое мы реализуем в облаке совместно с «Онсек», разработчиком платформы адаптивной защиты веб-приложений и API Валарм.

Теперь в логике обнаружения используется обратная связь от приложения для самонастройки. В рамках машинного обучения этот цикл обратной связи называется «подкрепление». Как правило, существует один или несколько типов такого подкрепления:

Далее рассмотрим технологические возможности различных вариантов реализации WAF.

Железо, ПО или облако — что выбрать?

Один из вариантов реализации файрволов приложений — «железное» решение. Такие системы представляют собой специализированные вычислительные устройства, которые компания устанавливает локально в своем дата-центре. Но в этом случае приходится закупать собственное оборудование и платить деньги интеграторам за его настройку и отладку (если у компании нет собственного ИТ-отдела). При этом любое оборудование устаревает и приходит в негодность, поэтому заказчики вынуждены закладывать бюджет для обновления аппаратного обеспечения.

Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.

Третий вариант — настройка WAF из облака. Такие решения предоставляются облачными провайдерами в качестве сервиса по подписке. Компании не нужно приобретать и настраивать специализированное железо, эти задачи ложатся на плечи поставщика услуги. Важный момент — современный облачный WAF не подразумевает миграцию ресурсов на платформу провайдера. Сайт может быть развернут в любом месте, даже on-premise.

Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.

Что может WAF в облаке

С точки зрения технологических возможностей:

Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:

Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера #CloudMTS.

Источник

Чем защищают сайты, или Зачем нужен WAF?

В этом году компанию Positive Technologies назвали «визионером» в рейтинге Gartner Magic Quadrant for Web Application Firewalls. Это вызвало ряд вопросов о том, за какие достижения мы туда попали и что такое WAF вообще. Вопросы вполне правомерные, ведь Gartner выпускает своё исследование WAF лишь с прошлого года (для примера: «квадранты» по SIEM стали выходить на пять лет раньше, в 2009 году). Кроме того, некоторые до сих пор путаются с терминологией, не отличая «экран для защиты веб-приложений» (WAF) от обычного «межсетевого экрана» (network firewall) или «системы предотвращения вторжений» (IPS).

В этой статье мы попробуем отделить мух от котлет — и рассказать, как идёт эволюция периметровой защиты по мере роста изощрённости атак.

1. В начале времён: пакетные фильтры

Изначально термин firewall (брандмауэр, экран) обозначал сетевой фильтр, который ставится между доверенной внутренней сетью и внешним Интернетом (отсюда прилагательное «межсетевой»). Этот фильтр был призван блокировать подозрительные сетевые пакеты на основе критериев низких уровней модели OSI: на сетевом и канальном уровнях. Иными словами, фильтр учитывал только IP адреса источника и назначения, флаг фрагментации, номера портов.

В дальнейшем возможности расширились до шлюзов сеансового уровня, или фильтров контроля состояния канала (stateful firewall). Эти межсетевые экраны второго поколения повысили качество и производительность фильтрации за счет контроля принадлежности пакетов к активным TCP-сессиям.

К сожалению, подобная система защиты практически бесполезна против современных кибер-угроз, где более 80% атак используют уязвимости приложений, а не уязвимости сетевой архитектуры и сервисов. Хуже того: блокирование определенных портов, адресов или протоколов (основной способ работы межсетевых экранов) может вырубить вполне легитимные приложения. Это значит, что защитная система должна проводить более глубокий анализ содержания пакетов — то есть лучше «понимать» работу приложений.

2. Системы обнаружения/предотвращения вторжений (IDS/IPS)

Следующим поколением защитных экранов стали системы обнаружения и предотвращения вторжений (IDS/IPS). Они способны изучать в TCP-пакетах поле данных и осуществлять инспекцию на уровне приложения по определённым сигнатурам. Системы IDS приспособлены к тому, чтобы выявлять атаки не только снаружи, но и внутри сети за счет прослушивания SPAN-порта коммутатора.

Для совершенствования защитных механизмов в IDS/IPS стали применяться декодеры (разбор полей TCP-пакета) и препроцессоры (разбор частей протокола уровня приложения, например, HTTP). Применение препроцессоров в IPS Snort позволило существенно улучшить функциональность периметровой защиты в сравнении с пакетным фильтром, даже если последний проверяет пакеты на уровне приложений (iptables с модулем layer7).

Однако при этом сохранился основной недостаток пакетного фильтра: проверка осуществляется попакетно, без учета сессий, cookies и всей остальной логики работы приложения.

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

3. Всё в кучу: NGFW/UTM

Следующим шагом эволюции систем обнаружения вторжений стало появление устройств класса UTM (unified threat management, система единого управления угрозами) и NGFW (next generation firewall, экраны нового поколения).

Системы UTM отличаются от NGFW лишь маркетингом, при этом их функционал практически совпадает. Оба класса программных продуктов явились попыткой объединить функции различных продуктов (антивирус, IDS/IPS, пакетный фильтр, VPN-шлюз, маршрутизатор, балансировщик и др.) в одном устройстве. В тоже время, обнаружение атак в устройствах UTM/NGFW нередко осуществляется на старой технологической базе, при помощи упомянутых выше препроцессоров.

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

Но разница в технологической платформе — не единственное, что отличает защиту веб-приложений.

4. Защита Веба: что должен уметь WAF

Если говорить совсем просто, то веб-приложения отличаются от обычных приложений двумя вещами: огромным разнообразием и значительной интерактивностью. Это создаёт целый ряд новых угроз, с которыми традиционные межсетевые экраны не справляются: по нашим оценкам, в 2014 году 60% атак на корпоративные сети осуществлялись через веб-приложения, невзирая на наличие традиционных защитных средств.

Именно здесь вступает в дело Web Application Firewall (WAF), защитный экран для приложений, осуществляющих передачу данных через HTTP и HTTPS. Вот какие функции отличают WAF от защитных систем предыдущих поколений:

Теперь подробнее о том, что означают все эти пункты:

Multiprotocol Security

Будучи узкоспециализированным средством, WAF не защищает от проблем протоколов, отличных от HTTP/HTTPS. Но у любой медали две стороны. Многообразие способов обмена данными поверх протокола HTTP настолько велико, что ориентироваться в нём может только специализированное средство. Лишь для примера: где-то переменные и значения передаются в формате example.com/animals?dogs=32&cats=23, где-то в формате example.com/animals/dogs/32/cats/23, где-то передача параметров приложения осуществляется в Cookie, а где-то — в параметрах заголовка HTTP.

Кроме того, продвинутые модели WAF могут анализировать XML, JSON и другие протоколы современных порталов и мобильных приложений. В частности, это позволяет противодействовать большинству методов обхода защитного экрана (HPC, HPP, Verb Tampering и др).

IP Reputation

Технология IP-Reputation опирается на внешние чёрные и белые списки ресурсов, и одинаково доступна любым периметровым средствам защиты. Но ценность этого метода несколько преувеличена. Так, в практике наших специалистов случались ситуации, когда крупные новостные агентства в силу своих уязвимостей месяцами раздавали malware пользователям, и при этом не попадали в чёрные списки. К сожалению, вектора проникновения вредоносного ПО очень разнообразны, и в наши дни источником заражения для пользователей могут быть даже сайты органов государственной власти. А возможна и обратная проблема, когда по IP блокируются «невиновные» ресурсы.

Сигнатуры атак

Сигнатурный подход к обнаружению атак применяется повсюду, но только грамотный препроцессинг трафика, доступный для WAF, может обеспечить адекватное применение сигнатур. Недостатки препроцессинга приводят к излишней «монструозности» сигнатур атак: администраторы не могут разобраться в сложнейших регулярных выражениях, весь смысл которых в том, что их авторы, например, всего лишь пытались учитывать возможность передачи параметра как открытым текстом, так и в форме шестнадцатеричного кода с процентом.

Автоматическое обучение и поведенческий анализ

Для атак на веб-приложения злоумышленники активно используют уязвимости нулевого дня (0-day), что делает бесполезными сигнатурные методы анализа. Вместо этого нужно анализировать сетевой трафик и системные журналы для создания модели нормального функционирования приложения, и на основе этой модели выявлять аномальное поведение системы. WAF в силу своей архитектуры может разобрать весь сеанс связи пользователя, и потому способен на более углубленный поведенческий анализ, чем NGFW. В частности, это позволяет выявлять атаки с использованием автоматических средств (сканирование, подбор паролей, DDoS, фрод, вовлечение в ботнеты).

Однако в большинстве случаев обучение поведенческой модели состоит в том, что операторы откуда-то берут «белый трафик» и «скармливают» его средству защиты. Но после сдачи в эксплуатацию поведение пользователей может меняться: программисты дописывают интерфейс по скорректированному техническому заданию, дизайнеры «добавляют красоты», рекламные кампании меняют направление внимания. Нельзя раз и навсегда составить схему поведения «правильного» посетителя. При этом обучаться на реальном, «сером» трафике могут только единицы программных продуктов — и это только WAF’ы.

Защита пользователей

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

Рассмотрим следующий сценарий атаки: пользователь заходит на сайт банка, проходит там аутентификацию, и после этого в другой вкладке браузера открывает зараженный ресурс. JavaScript, загрузившийся в другом окне, может сделать запрос на перевод денег втайне от пользователя, а браузер при этом подставит все необходимые аутентификационные параметры для осуществления финансовой транзакции, так как сеанс связи пользователя с банком ещё не окончился. В описанной ситуации налицо слабости в алгоритме аутентификации в банковском ПО. Если бы для каждой формы, содержащейся на странице сайта, генерировался уникальный токен, проблемы бы не было.

К сожалению, разработчики ПО практически никогда так не делают. Однако некоторые WAF могут самостоятельно внедрять подобную защиту в веб-формы и защищать, таким образом, клиента – а вернее, его запросы, данные, URL и cookie-файлы.

Взаимодействие со сканерами уязвимостей

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

Лучшие образцы WAF имеют в своем распоряжении интегрированные сканеры уязвимостей, работающие в режиме чёрного ящика, или динамического анализа (DAST). Такой сканер может использоваться в режиме реального времени для быстрой проверки тех уязвимостей, которые «прощупывают» злоумышленники.

Виртуальный патчинг

Даже известные уязвимости невозможно устранить сразу: исправление кода требует средств и времени, а зачастую и остановки важных бизнес-процессов; иногда в случае использования стороннего ПО исправление невозможно вообще. Для парирования таких «частных» угроз в системах IDS/IPS, а по наследству в UTM/NGFW, применяются пользовательские сигнатуры. Но проблема в том, что написание такой сигнатуры требует от пользователя глубокого понимания механизма атаки. В противном случае пользовательская сигнатура может не только «пропустить» угрозу, но и породить большое количество ложных срабатываний.

В наиболее современных WAF используется автоматизированный подход к виртуальному патчингу. Для этого используется анализатор исходных кодов приложения (SAST, IAST), который не просто показывает в отчёте строки уязвимого кода, но тут же генерирует эксплойт, то есть вызов с конкретными значениями для эксплуатации обнаруженной уязвимости. Эти эксплойты передаются в WAF для автоматического создания виртуальных патчей, которые обеспечивают немедленное «закрытие бреши» ещё до исправления кода.

Корреляции и цепочки атак

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

Современный WAF может группировать сходные срабатывания и выявлять цепочку развития атаки — от разведки до кражи важных данных или установки закладок. В результате вместо списка из тысяч подозрительных событий ИБ-специалисты получают несколько десятков действительно важных сообщений.

Что дальше?

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

Источник