Это пятая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 — разрыв в даташитах. Часть 2 — ловушки NGFW. Часть 3 — WAF, IPS, DLP. Часть 4 — SASE.
Прошлые посты серии показали, что идёт не так в типичных оценках продуктов безопасности: тестовые условия под вендора, инструменты PCAP-реплея, к которым вендор готовится, дрейф AppMix, из-за которого сравнение вендоров бессмысленно, и демо, не имеющие отношения к боевой нагрузке. Этот пост о том, как выглядит хорошо построенная оценка и кто должен её вести.
Перед методикой стоит прямо сказать, кто обычно ведёт оценки продуктов безопасности и какие у него стимулы.
Вендоры ведут PoC, чтобы продать свой продукт. Их инженеры умелые, профессиональные и знающие — и они работают на благоприятный результат. Профиль трафика, конфигурация DUT, выбранные для PoC сценарии, метрики в отчёте — всё это отражает эту задачу. Это не обман, это рациональное коммерческое поведение. Нейтральной оценки оно не даёт.
Интеграторы несут структурный конфликт, о котором говорят реже. Маржа интегратора на проекте зависит от того, какой продукт выбран, по какой цене и с каким объёмом услуг внедрения. Интегратор, который сравнивает трёх вендоров и рекомендует того, у кого маржа ниже, действует против своего финансового интереса. Большинство интеграторов работают добросовестно, но структура стимулов реальна, и в дорогих решениях её надо учитывать.
Внутренние команды с open-source инструментами сталкиваются с другой проблемой: обычно им не хватает глубины методики, чтобы спроектировать тест с учётом оптимизаций fast path, дрейфа AppMix и покрытия обходов. Результаты выглядят осмысленно и технически реальны, но отражают условия, к которым вендор подготовился.
Независимая лаборатория снимает структурный конфликт. Её гонорар платит покупатель, он фиксирован независимо от результата и не зависит от выбора конкретного вендора. Ценность лаборатории целиком в достоверности и защитимости её результатов.
Тест-план, который даёт результаты уровня решения, должен закрывать пять элементов, которые в типичных оценках стабильно пропускают.
Конфигурация DUT — версия прошивки, включённые функции, политики безопасности, уровни логирования, все активные и неактивные модули — задокументирована и зафиксирована до первого пакета. Никаких изменений в окне теста. Никакого «тюнинга» между прогонами. Никаких правок задним числом перед повторным прогоном сценария.
Это важно, потому что изменения конфигурации во время теста — способ управлять результатом. Устройство слабо отработало в ранних прогонах с включённой функцией X, потом X тихо выключили для финального прогона, который попал в отчёт. Это не честное сравнение. Фиксация конфигурации заранее убирает эту переменную.
Зафиксированная конфигурация должна отражать вашу целевую боевую: ваше число правил, ваши включённые политики, ваш объём логирования, ваши настройки инспекции. Не дефолт вендора. Не минимальный набор под красивые числа.
Каждая сессия генерируется на ходу. Два потока одного типа не должны иметь одинаковый payload на L7. Это значит:
Это отключает оптимизации на кеше и fast path, которые делают результаты PCAP-реплея ненадёжными. Устройство вынуждено классифицировать и инспектировать каждый поток отдельно — ровно как в проде.
Динамическая генерация не значит случайную и неуправляемую. Профиль трафика определён, параметризован и воспроизводим. Тот же seed, те же параметры, тот же тест — одинаковые характеристики трафика каждый раз. Воспроизводимость делает результаты защитимыми и позволяет перепроверять после изменений конфигурации.
Микс приложений, который проходит через DUT, надо измерять, показывать в отчёте и контролировать. Нельзя считать, что он совпадает с тем, что настроили в генераторе.
Отчёт с фразой «профиль трафика: 30% HTTPS, 20% HTTP, 15% DNS…» должен включать проверенное измерение того, что реально прошло через DUT на уровне протоколов — со счётчиков трафика самого DUT или из inline-измерения на тестовых портах. Если измеренный микс отличается от заданного больше согласованного допуска, тест недействителен.
Без этого сравнение вендоров математически несостоятельно. Нельзя сравнивать результаты устройства A и устройства B, если реальный AppMix у каждого был разным, даже при одинаковом целевом распределении.
Rate детекта и эффективность блокировки меряют во время теста производительности, не отдельно от него.
Сценарий подаёт трафик атак внутри фонового потока легитимного трафика приложений, на уровне нагрузки, близком к боевому — на 60–80% номинального throughput устройства. Rate детекта, rate блокировки, rate ложных срабатываний и любое изменение latency или throughput от работы защиты под атакой — всё это фиксируется.
Устройство, которое ловит 99% атак на холостом ходу и 65% при 75% загрузки, даёт другой уровень защиты, чем говорит заголовочная цифра. Тест в изоляции это скрывает.
Суммарный throughput, суммарная latency и общий rate детекта результат не объясняют. Отчёт должен включать:
Детальная отчётность позволяет понять, почему устройство дало такой результат, и предсказать, удержится ли он при вариациях вашего боевого профиля трафика.
Одной методики мало. Платформа генерации трафика и измерений должна реализовывать методику точно.
Профессиональные коммерческие платформы — среди них Keysight BreakingPoint и CyPerf — сделаны именно под этот класс тестов. Они генерируют трафик на ходу, держат контроль AppMix по замкнутому циклу, подают атаки внутри легитимного трафика и выдают детальную статистику по протоколам, нужную для полного отчёта. Крупнейшие операторы, финансовые организации и госструктуры используют их для квалификации инфраструктуры именно потому, что результаты воспроизводимы и проверяемы.
Open-source инструменты — это генераторы пакетов и базовые нагрузочные утилиты. Для своих задач они полезны. Для оценки продуктов безопасности их недостаточно: нет динамической генерации на L7, нет обратной связи по AppMix, нет статистики по протоколам на уровне DUT, нет встроенной эмуляции атак с вариацией обходов. Они дают числа. Понимания они не дают.
Разница в цене между профессиональными инструментами и open-source реальна, но на фоне стоимости ошибки закупки по многолетнему контракту она мала.
TEST4NET — независимая лаборатория тестирования сетей и безопасности. Работы с фиксированной стоимостью, их оплачивает организация, которая принимает решение о закупке, без коммерческих отношений с вендорами, чьи продукты оцениваются.
Тестирование идёт на Keysight BreakingPoint и CyPerf: динамическая генерация трафика, контроль AppMix по замкнутому циклу, полная детальная отчётность по всем типам протоколов. Эмуляция атак использует payload, сгенерированные на ходу, с управляемой вариацией обходов — не статический PCAP-реплей.
Каждая работа начинается с тест-плана, согласованного и зафиксированного до старта тестов: конфигурация DUT, параметры профиля трафика, целевой AppMix с методикой проверки, критерии pass/fail, формат отчёта. Тест-план — документ, который принадлежит покупателю. Если вендор или интегратор оспаривает методику, у покупателя есть защитимая запись о том, что тестировали и как.
В результаты входит:
TEST4NET приносит то, чего вендор и интегратор структурно принести не могут: отсутствие ставки на результат.
Вложение в независимый тест — доля от стоимости обязательства на 3–5 лет по инфраструктуре безопасности, выбранного по результатам под вендора. Вопрос не в том, можете ли вы позволить себе независимый тест. Вопрос в том, можете ли вы позволить себе его пропустить.
Если ваша организация планирует оценку NGFW, WAF, DLP, IPS или SASE и хочет методику с результатами, которые можно защитить перед советом директоров, аудиторами и службой эксплуатации — поговорите с TEST4NET до старта PoC.
Дальше в серии — Пост 6: почему одной оценки мало — постоянная проверка на всём жизненном цикле платформы безопасности.
Вся серия: Пост 1 · Пост 2 · Пост 3 · Пост 4 · Пост 5 · Пост 6