Современные ИБ-решения обрабатывают колоссальные потоки данных, разделяя их на безобидный и потенциально опасный трафик. Главное здесь – выявить не просто подозрительный запрос, а реальную угрозу, ведь если СЗИ будет сообщать о каждом событии ИБ, то эффективность и ценность таких алертов будет минимальной. И тогда выйдет как в притче, где мальчик кричал: «Волки!» - реальная атака потонет в море false positives. В материале для Cyber Media Динко Димитров, руководитель продуктового развития компании «Вебмониторэкс» разберет, откуда берется шум на примере WAF, как фолзы влияют на уровень ИБ в компании и за счет чего можно сократить их количество.

Откуда берутся фолзы на WAF

Для начала разберемся с определениями. Ложноположительное срабатывание (false positives) — это ситуация, когда ИБ-система ошибочно определяет безопасный объект, файл, запрос или поведение как угрозу. Есть решения, которые без корректной настройки и контекстного анализа, традиционно дают больше шума. И межсетевой экран уровня веб-приложений WAF (Web application firewall) один из них. Такая «чувствительность» WAF связана с:

• общей логикой большинства подобных решений

Многие WAF работают на сигнатурном анализе: они ищут «подозрительные» фрагменты в запросах. Однако такие фрагменты могут встречаться и в абсолютно легитимном трафике.

• отсутствием контекста исполнения

Если WAF видит только HTTP-запрос, то он не знает, как его обработает веб-приложение. В итоге решение определяет «опасные» слова, но не контекст их использования, который может быть вполне легитимным.

• использованием WAF из коробки

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

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

Приведем несколько реальных примеров, когда подозрительные на первый взгляд запросы на самом деле не составляли угрозу для компании:

'!"I sinned against you, and you forgave me. Thank you!'
"The cookie monster does'nt like muffins"
'Знаком с KVM/QEMU, Wine, VoIP/SIP, Tor, smali/baksmali (.dex), apktool, keytool."
'(\/)_(o_o)_(\/)'
'hoho ;(). -D'
'<~s#c@.~r.-i~p*t'
'1) a-b=c'

Как видите, даже безобидный «cookie monster» может вызвать подозрение у WAF.

К чему приводят фолзы

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

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

Большой объем «шумных» инцидентов засоряет не только людей, но и систему. Особенно, если WAF интегрирован в SOC и обменивается данными с SIEM. Система вынуждена тратить больше времени на обработку событий, что может замедлять скорость построения Kill Chain (последовательность действий злоумышленников) и, как следствие, скорость реагирования на инцидент. А даже небольшая задержка детектирования дает фору киберпреступникам, чтобы успешно преодолеть ИТ-периметр и закрепиться в нем.

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

Как выбрать точный WAF

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

Сложность донастройки коробочного решения

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

Есть другой вариант: компания может приобрести услугу у сервис-провайдера, готового выполнить все необходимые работы в режиме аутсорсинга. Хотя даже в случае MSS-модели для начальной настройки решения необходима четкая обратная связь от заказчика, ведь только владелец инфраструктуры знает все ее особенности и свои потребности. В противном случае правила детектирования будут недостаточно кастомизированы. А это значит, что WAF будет либо давать большой объем ложноположительных событий, либо, наоборот, пропускать часть атак.

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

Глубина анализа трафика

Для точного определения угрозы важна глубина анализа запроса. Веб в своей работе использует множество различных кодировок: ASCII, ISO-8859-* серии, Windows-1251, UTF-7, UTF-8, UTF-16. Браузеры и серверы научились автоматически понимать, на каком языке написан тот или иной запрос. Но для WAF это сложная задача – его нужно научить понимать все запросы. В противном случае он может пропустить опасный или наоборот заблокировать полезный запрос, просто потому что не поймет его. Поэтому в изначальные настройки WAF должен быть заложен полный набор кодировок, в противном случае решение потребует ручной настройки (опять же со стороны самого заказчика или сервис-провайдера). В этом случае велик риск, что при настройке какой-то редкий язык забудут, что существенно снизит уровень веб-защиты.

Помимо этого, эффективный (то есть генерящий минимум фолзов) WAF должен уметь разбирать цепочки кодировок. Иногда злоумышленники кодируют данные несколько раз: сначала в UTF-16, потом URL-encode, потом base64. Таким образом хакеры пытаются запутать системы защиты, замаскировать полезную нагрузку и в итоге обойти фильтры. Поэтому WAF обязан уметь разворачивать такие цепочки в полном объёме и приводить данные к канонической форме перед анализом.

Но кодировки — лишь часть проблемы. Веб-приложения активно используют различные форматы передачи данных: urlencode, JSON, XML, base64, gzip, deflate, zip и т. д. Причем эти форматы могут накладываться друг на друга. Например, приложение может принимать данные в base64, внутри которых окажется gzip-сжатый JSON с множеством ключей, в значениях которых снова встречается base64. Чтобы корректно анализировать такие данные, WAF должен уметь разбирать их с помощью цепочки парсеров — пошагово раскодировать, распаковывать и приводить к канонической форме, прежде чем применять правила фильтрации. Это тоже важный навык для WAF, чтобы избежать ложных сработок.                                                                                                        

Выход за рамки сигнатурного анализа

Как мы написали выше, стандартный сигнатурный анализ не эффективен. В этом случае СЗИ ищет заранее описанный паттерн атаки (регулярное выражение). Такой метод подходит для известного набора базовых угроз, но не гарантирует абсолютной защиты от 0-day атак. А из-за упрощённого подхода к оценке пакетов и строго заданного списка проверяемых сигнатур, неподготовленные правила блокируют значительную часть легитимного потока данных.

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

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

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

Экспертиза вендора и обширная база детектов

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

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

Итого

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