Согласитесь, иногда на демо ИБ‑продукт выглядит стройным, быстрым и почти гениальным, но в проде внезапно начинает блокировать пользователей, захлебываться под нагрузкой, а то и совсем падать. В итоге сайт лежит, бизнес кричит, а ИБ не знает, что с этим делать. Чтобы не брать «кота в мешке», можно провести пилотное тестирование. Оно позволяет увидеть конкретное решение в деле — понять, как продукт ведет себя под нагрузкой, насколько уживается с существующими системами и насколько удобен в управлении. Ранее мы уже писали о том, как подготовиться к пилоту, чтобы старт тестирования не растянулся на месяцы, не превратился в шоковую терапию для вашей инфраструктуры и не перессорил все отделы. А в этом посте мы расскажем, как понять, был ли пилот успешным.

Мы подготовили перечень критериев, на которые стоит смотреть заказчику при пилотировании WAF (межсетевой экран уровня веб‑приложений), чтобы не ошибиться с выбором и не страдать потом от бесчисленных фолзов и «тормозящих» сайтов. 

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

*В конце поста вы найдете сводную таблицу со всеми критериями.

WAF не мешает защищаемым ресурсам

Одно из ключевых требований к любому сетевому ИБ‑фильтру — отсутствие деградации трафика и пользовательского опыта. Поэтому первая группа критериев связана с влиянием WAF на работоспособность и производительность веб‑приложений.

Должно быть так: при включении веб‑защиты приложения остаются полностью работоспособными и доступными для легитимных пользователей. В частности, бизнес‑критичные пользовательские сценарии выполняются корректно и не возникает неконтролируемых отказов. Если возникают сбои, которые нельзя быстро устранить, — это повод рассмотреть других вендоров.

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

Также WAF не должен перегружать выделенные вычислительные ресурсы: утилизация центрального процессора (CPU) и оперативной памяти (RAM) находятся в допустимых пределах, не допускается утечка памяти RAM при длительной работе. Этот показатель крайне важно оценить в реальных условиях, потому что вендоры часто лукавят, указывая в характеристиках продукта красивые значения, которые на самом деле достижимы только в идеальных условиях. Например, в ТТХ указана пропускная способность решения для «лабораторного» профиля трафика (при отключенных парсерах, без загрузки файлов, маленьком размере запросов и ответов). В реальности же профиль трафика намного сложнее: есть TLS‑шифрование, передача бинарных данных, использование сложных JSON и XML и другие параметры, которые значительно влияют на скорость обработки запросов, производительность WAF и могут потреблять значительные вычислительные мощности.

WAF не обмануть сложными атаками

Итак, WAF вам не мешает, и железа хватает — можно двигаться дальше. Ключевым показателем эффективности любого ИБ‑продукта является качество детектирования атак. Должен быть баланс между высокой точностью детектирования и минимальным количеством ложных блокировок.

Как проверить, хорошо ли защищен периметр вашей организации и корректно ли работают какие‑то ИБ‑решения? Самый очевидный способ — это провести пентест. В случае пилота — запустить WAF на боевом трафике и проверить его с помощью опытной команды пентестеров. Такой путь эффективен, но долог и дорог. Поэтому позволить его себе могут далеко не все.

Более бюджетный вариант — это проверка WAF с помощью специальных утилит, которые генерируют синтетический трафик с вредоносной нагрузкой (GoTestWaf, waf‑bypass, WAFNinja и тому подобные), или DAST‑решений. Они имитируют трафик с классическими веб‑атаками, а некоторые инструменты также позволяют загрузить кастомные payload, сымитировав более сложную атаку. Подобные тесты проводят и сами вендоры, гордо вынося высокие показатели в ключевые характеристики своих продуктов. Но никто не мешает перепроверить эти цифры в рамках пилота.

Но что конкретно проверять? Каждый WAF умеет защищать от базовых атак (XSS, RCE, SQL и тому подобное). Здесь все просто — вредоносная нагрузка находится в одном запросе, который легко вычислить правилами и заблокировать. Сложнее с поведенческими атаками — они стараются «запутать» веб‑приложение и его защиту, используя легитимные функции в злонамеренных целях. Вредоносного payload в запросе просто нет. Здесь важна способность WAF детектировать атаку в совокупности разрозненных и легитимных на первый взгляд запросов. Поэтому в рамках пилота стоит проверить решение на детект атак типа bruteforce, forced browsing, BOLA, dirbust.

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

• автоматически реагировать на подозрительную активность и самостоятельно пополнять чёрные списки;

• задавать время блокировки (ведь IP‑адрес очень быстро меняет «владельцев»).

WAF не фолзит

Есть ИБ-решения, которые без корректной настройки и контекстного анализа традиционно дают больше шума. И WAF – один из таких продуктов. Таков веб-трафик!

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

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

Не только детект — что еще умеет WAF

Не стоит ограничивать полезность WAF одним только отражением атак. Межсетевой экран уровня веб‑приложений поможет снизить нагрузку на инфраструктуру заказчика. Так почему бы не проверить и эти опции на пилоте?

Например, возможность создавать Virtual Patch — это не только про закрытие актуальных CVE, когда нет возможности быстро «накатить» обновление ПО. Например, виртуальным патчем можно «аварийно отключить» ресурсоемкие функции. Представьте: на сайте появилась функция «скачать каталог продукции», которая при массовом запросе «кладет» сайт. Виртуальным патчем можно заблокировать доступ к URI или поставить Rate Limiting, решив временную проблему без значительных архитектурных изменений.

Еще одна опция — добавление дополнительных механизмов защиты в виде блокировки запросов по географическому признаку и фильтрации по типу источника (включая VPN, Tor, публичные прокси и облачные платформы).

В интерфейсе все понятно

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

Представьте, что ваш сайт обрабатывает 100 RPS (немного, согласитесь). По статистике, примерно 5% этого трафика — атаки. А значит, каждую секунду вам приходит по 5 алертов. Кажется, немного. Но когда события ИБ отражаются в консоли в виде постоянно пополняющейся ленты, эти 5 алертов быстро потонут в бесконечном потоке, отследить который невозможно.

Здесь поможет дашборд. Он должен корректно визуализировать данные по трафику, источникам и типам атак, эксплуатируемым уязвимостям. Любой всплеск на графике легко отследить. Визуализация — это не просто красивый интерфейс, а важный инструмент, который позволяет вовремя реагировать на инцидент.

Также важно получать оперативные уведомления (например, через мессенджеры), чтобы критичный алерт не потонул в горе непрочитанных писем в почте или в консоли. Работоспособность этой опции тоже стоит проверить на пилоте.

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

Выгрузка отчетов по событиям безопасности — это еще один важный критерий, на который стоит смотреть в рамках пилота. Это должен быть удобный и визуально понятный документ, который можно представить руководству с минимальными доработками. У качественного WAF пользователь может легко настроить фильтры для формирования выгрузки по событиям ИБ, получать данные в разных форматах (PDF, CSV и тому подобные) и через удобные для клиента каналы.

Сапожник без сапог — WAF без защиты

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

Еще один критерий — это безопасный доступ в консоль управления. В частности, речь идет о многофакторной аутентификации (ну, это база), SSO с использованием современных и безопасных протоколов и разграничении доступа к консоли управления WAF в соответствии с пользовательской ролевой моделью.

***

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

Сводная таблица с критериями тут.

Автор: Владимир Гриднев, заместитель генерального директора по развитию бизнеса WMX