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