Это третья часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 — структурный разрыв в даташитах. Часть 2 — ловушки в тестировании NGFW.
WAF, IPS и DLP часто покупают по вендорским демо и заявленным rate детекта. Они же чаще всего разочаровывают в проде. Технология тут работает. Подводит методика выбора: она не отражает условия эксплуатации.
Числа производительности WAF — requests per second, throughput, latency — почти всегда снимают в условиях, которые к боевому трафику веб-приложений отношения почти не имеют.
Проблема синтетических запросов. Большинство стендов для WAF гоняют фиксированный набор HTTP/HTTPS-запросов, синтетических или из небольшого PCAP. Каждый запрос одной структуры: те же заголовки, тот же формат cookie, тот же паттерн URI. Боевой трафик устроен наоборот: динамические токены сессии в каждом запросе, разная длина контента, потоки аутентификации на несколько запросов с состоянием между ними, редиректы, разные характеристики TLS-сессий. Движку правил WAF на однородном синтетическом потоке работать заметно проще, чем на реальном выводе современного веб-приложения.
Атака отдельно и атака в потоке. Точность детекта WAF почти всегда меряют, отправляя вредоносные payload по отдельности: чистая тестовая сессия, один вредоносный запрос, ответ записан, детект подтверждён. Не проверяется, держит ли WAF ту же точность, когда payload атаки встроены в плотный поток легитимных запросов приложения. Под нагрузкой, когда движок обрабатывает тысячи одновременных сессий, точность на тонких инъекциях и слабосигнальных обходах может падать. Проверять надо оба режима: детект изолированной атаки и детект атаки на реалистичной частоте внутри фоновой нагрузки.
TLS inspection при конкурентности. Многие внедрения WAF включают терминацию TLS или полный MITM. Вендоры часто дают TLS и не-TLS числа отдельно и показывают лучшее. Эффект от терминации TLS, проверки сертификатов, обработки возобновления сессий и переустановки соединения на высокой конкурентности — вот где живёт боевое число. Тестируйте на своей реалистичной частоте TLS-соединений, своей типичной длительности сессии и с включённым TLS inspection.
Сложность набора правил. WAF с базовым набором и WAF с базовым набором плюс кастомный virtual patching на десяток приложений плюс исключения, накопленные за два года, несут разную нагрузку. Тест производительности на минимальном наборе правил не предсказывает поведение под вашей боевой политикой.
IPS оценивают почти целиком по rate детекта. Метрика легко измеряется, легко показывается и слабо связана с защитой, которая важна.
Rate детекта — замкнутое измерение, когда тестовый инструмент известен. IPS, который ловит 99% атак из библиотеки, под которую его готовил вендор, покажет 99% детекта в тесте на этой библиотеке. Измерение говорит, что устройство узнаёт атаки, которые его научили узнавать. Это полезно и неполно. Важнее вопрос: что происходит с атаками, где применены техники обхода, под которые вендор специально не готовился?
Покрытие обходов — вот где продукты расходятся. Техники обхода — фрагментация payload, игра на неоднозначности протокола, вариации кодировки, полиморфный shellcode, манипуляции с заголовками — так реальные атакующие обходят сигнатурный детект. IPS, который блокирует 99% прямых атак и пропускает 30% обёрнутых в обход вариантов тех же атак, защищает заметно хуже, чем говорит его заголовочное число.
Осмысленно проверить покрытие обходов можно только платформой эмуляции атак, которая генерирует атаки на ходу с управляемой вариацией кодировки, стратегии фрагментации и обработки протокола. Статический реплей известных payload даёт вендору знание каждого payload заранее. Это не тест безопасности, это репетиция.
Детект под нагрузкой. При 20% загрузки движок IPS может позволить себе быть тщательным. При 80% под непрерывной атакой рядом с плотным легитимным трафиком тот же движок начинает принимать решения о приоритетах: отбрасывать пакеты, снижать глубину инспекции, откладывать классификацию. Тест rate детекта на холостом ходу показывает потолок. Тест на 70–80% номинального throughput показывает, что получат пользователи в условиях, где атакующий вероятнее всего и работает.
У DLP разрыв между заявлениями вендора и реальностью прода обычно самый широкий, а последствия проваленной оценки — самые дорогие в эксплуатации.
Проблема ложных срабатываний на масштабе. Точность DLP в вендорских тестах меряют на чистых тестовых наборах: специально собранные документы с явно структурированными чувствительными данными или небольшие контролируемые корпуса. Rate ложных срабатываний тут выглядит приемлемо — 1–3% часто встречается в материалах вендора.
В проде чистых контролируемых корпусов нет. Есть годами накопленные файлы в десятках форматов, со сложным вложенным содержимым, старые шаблоны, которые совпадают с паттернами данных без реальных чувствительных данных, и терминология бизнеса, которая пересекается с определениями чувствительных данных. На реалистичной выборке корпоративного контента rate ложных срабатываний, который в тесте казался управляемым, доходит до сотен инцидентов в день. Система становится непригодной к эксплуатации без месяцев тюнинга.
Просите вендора прогнать детект DLP по выборке из вашего реального хранилища документов на этапе оценки. Разница между точностью на контролируемом тесте и точностью, близкой к проду, — вот число, которое важно.
Throughput на реальной инспекции контента. DLP требует анализа содержимого файлов на уровне приложения, а не инспекции пакетов. Это дорого по вычислениям, и стоимость сильно зависит от типа файла. Движок DLP на потоке простых текстовых писем работает с куда меньшим overhead, чем на потоке крупных книг Excel с макросами, вложенных ZIP-архивов или тяжело оформленных PDF.
Числа throughput у вендора почти всегда сняты на лёгком контенте. Тестируйте на реалистичном распределении типов файлов, которое отражает то, что ваша организация реально гоняет по сети.
Покрытие протоколов: что «DLP» на самом деле закрывает. Утечка корпоративных данных не ограничивается SMTP и загрузками по HTTP. Современная среда — это Teams, Slack, передача файлов через Zoom, клиенты облачной синхронизации (OneDrive, Google Drive, Dropbox), кастомные потоки загрузки в SaaS и длинный хвост проприетарных протоколов. Просите вендора перечислить, какие протоколы получают полную инспекцию контента, какие — только мониторинг метаданных, а какие не покрыты вообще. Это сильно меняет то, от чего платформа реально защищает.
Для WAF, IPS и DLP работает один принцип: тест должен отражать условия, в которых продукт будет работать в вашей среде.
Значит:
Ничего необычного в методике тут нет. Нужно чётко спросить, при каких условиях получено каждое число в результатах вендора, и независимо это проверить.
Дальше в серии — Пост 4: SASE. Почему облачную безопасность особенно трудно измерять и как выглядит осмысленная оценка распределённой архитектуры.
TEST4NET LLC — независимая лаборатория тестирования сетей и безопасности. Мы оцениваем WAF, IPS и DLP по методике, которая отражает боевые условия, а не вендорские сценарии. Напишите нам.