WAF подключен – что дальше? Как настроить решение, чтобы оно защищало, а не мешало

Вы прошли долгий путь от выбора WAF (Web Application Firewall) и согласования бюджета до финальной интеграции решения в инфраструктуру. Казалось бы, можно выдохнуть. Но именно здесь начинается самая важная часть работы – и именно на этом этапе спотыкается большинство команд. Даже если был проведен успешный пилот, боевая эксплуатация все равно преподносит сюрпризы. В этом посте разберём, почему «поставил и забыл» – это не лучший подход для WAF (да и для большинства ИБ-решений), как правильно подключать приложения к защите после интеграции и как в итоге понять, что всё работает как надо?

Почему пилот – не silver bullet

Пилотное тестирование сегодня стало обязательным этапом выбора ИБ-решения. И это логично, ведь никто не хочет брать кота в мешке (особенно, когда этот кот стоит десятки миллионов). Мы уже писали ранее о том, как правильно подготовиться к пилоту WAF и как корректно оценить его результат.

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

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

Например:

• У каждого приложения свой стек технологий, свои паттерны трафика и «легитимные аномалии»;

• Владельцы разных приложений по-разному относятся к идее «фильтровать мой трафик»;

• Одни и те же правила WAF, идеально работающие на официальном сайте, ломают API внутренней CRM.

Приведем пример из практики. К WMX на пилотное тестирование пришел крупный интернет-магазин. Его основной сайт работал на Bitrix. Конфигурация была максимально стандартной и простой. На настройку правил, фолзов и проверку стабильности работы нам потребовалась всего неделя. После успешного пилота началось внедрение, и заказчик стал подключать другие приложения. В итоге выяснилось, что CRM использует WebSocket, что потребовало изменения конфигурации проксирования. Потом к защите подключили файловое хранилище, и стандартные правила WAF стали фолзить на загружаемых файлах. После заказчик завел MS Exchange, но не учел, что он использует NTLM-аутентификацию, а это требует специфичной конфигурации балансировки. Конечно, на этапе боевого внедрения WAF была проведена работа с настройкой правил и исключений.

Не спешите с блокировкой - начните с мониторинга

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

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

Как это работает на практике:

1. WAF подключается в режиме Detect (мониторинг);

2. Решение/эксперты собирают трафик и анализируют false positive;

3. На основании этих данных происходит настройка исключений и кастомных правил;

4. Только после такой стабилизации WAF переключают в режим блокировки.

Обычно этот этап длится около 2 недель, а для критичных приложений – до 4 недель. А если вы выбрали WAF со сложной настройкой правил, процесс может растянуться на несколько месяцев (и это только для одного приложения).

 В итоге вы увидите:

• полный спектр легитимных сценариев и трафика (включая еженедельные пакетные задачи, интеграции, редкие пользовательские сценарии);

• паттерны, которые WAF считает подозрительными, но которые являются нормой для конкретного приложения;

• реальные атаки, что поможет при настройке правил.

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

В нашей практике был кейс, когда внедрение WAF у онлайн-ритейлера было на финальной стадии, но тут начался сезон распродаж. Тогда бизнес, опасаясь фолзов и недовольства покупателей, потребовал у ИБ отключить WAF. И практически сразу получил RCE с последующим взломом. Хотя можно было бы оставить WAF в режиме мониторинга, и пользователи не столкнулись бы с блокировками, но зато в случае подозрительного алерта, ИБ-служба заказчика смогла бы оперативно среагировать на атаку.

Не подключайте все и сразу – расставьте приоритеты

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

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

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

Итак, разберем базовую систему оценки (Risk Score), которую мы рекомендуем нашим заказчикам. Она состоит из пяти критериев, каждый из которых оценивается по шкале от 0 до 3:

Формула расчета:

Risk Score = (Exposure × 2) + Business Impact+Control Weakness+Technical Risk+Data Sensitivity

Далее эту оценку надо скорректировать с учётом реальности: результаты анализа защищенности, договороспособность владельца приложения и сложность согласования изменений. Тогда мы получим Priority Score.

Формула расчета:

Priority Score = Risk Score+TI Modifier+Org Resistance Modifier

Есть условия, при которых приложение получает приоритет на подключение к WAF:

• на него регулярно идут атаки;

• на него распространяются требования регулятора;

• на него недавно была совершена успешная кибератака, повтор которой нельзя допустить.

Давайте посмотрим на реальном примере. Есть промышленная компания с 80 веб-приложениями:

• личный кабинет клиентов;

• ERP-система;

• портал для дилеров;

• HR-система;

• несколько legacy-приложений;

• десятки тестовых и вспомогательных сервисов.

Кажется логичным сначала защитить самое критичное – например, ERP. Но её владелец говорит: «Любой простой недопустим, изменения согласовываются месяц, а сейчас идёт важный проект».

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

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

WAF требует постоянного внимания

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

• просмотр логов WAF и анализ заблокированных запросов;

• проверка актуальности правил и исключений;

• пересмотр оценки при изменениях стека, типа доступа, данных, актуальных угроз;

• обновление правил по результатам тестирований на защищенность;

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

 Когда надо не ждать, а менять оценку риска:

• Смена типа доступа (internal → public или наоборот);

• Появление новых TI-сигналов по приложению;

• Значимое изменение стека;

• Изменение регуляторных требований;

• Инцидент, связанный с приложением.

Сколько ресурсов забирает WAF

Наконец, важно убедиться, что решение не создает для ИБ-службы заказчика новую точку постоянной нагрузки. Хорошо настроенный WAF не должен заставлять команду ежедневно разбирать тысячи false positive, вручную вмешиваться при каждом изменении приложения или беспокоиться о его производительности при каждом всплеске нагрузки.

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

False Positive Rate

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

Скорость реакции на ошибки

Полностью исключить false positive невозможно. Важно, насколько быстро можно настроить исключения. Время от регистрации ошибочной блокировки до внесения и проверки корректирующего изменения должно занимать несколько минут. Если процесс растягивается на несколько часов или даже дней, то WAF сам становится источником бизнес-риска.

Бесперебойность работы WAF

Стабильность самого решения также играет важную роль. Если WAF перестает работать, это создает для заказчика серьезную проблему. Либо WAF не работает и «не пускает» трафик к приложению, либо WAF отключают, и приложение остается без защиты.

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

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

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

Заключение

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