Как провести тест ИБ продукта, результатам которого можно доверять

Это пятая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 — разрыв в даташитах. Часть 2 — ловушки NGFW. Часть 3 — WAF, IPS, DLP. Часть 4 — SASE.

Прошлые посты серии показали, что идёт не так в типичных оценках продуктов безопасности: тестовые условия под вендора, инструменты PCAP-реплея, к которым вендор готовится, дрейф AppMix, из-за которого сравнение вендоров бессмысленно, и демо, не имеющие отношения к боевой нагрузке. Этот пост о том, как выглядит хорошо построенная оценка и кто должен её вести.

Проблема конфликта интересов

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

Вендоры ведут PoC, чтобы продать свой продукт. Их инженеры умелые, профессиональные и знающие — и они работают на благоприятный результат. Профиль трафика, конфигурация DUT, выбранные для PoC сценарии, метрики в отчёте — всё это отражает эту задачу. Это не обман, это рациональное коммерческое поведение. Нейтральной оценки оно не даёт.

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

Внутренние команды с open-source инструментами сталкиваются с другой проблемой: обычно им не хватает глубины методики, чтобы спроектировать тест с учётом оптимизаций fast path, дрейфа AppMix и покрытия обходов. Результаты выглядят осмысленно и технически реальны, но отражают условия, к которым вендор подготовился.

Независимая лаборатория снимает структурный конфликт. Её гонорар платит покупатель, он фиксирован независимо от результата и не зависит от выбора конкретного вендора. Ценность лаборатории целиком в достоверности и защитимости её результатов.

Обязательные элементы честного тест-плана

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

1. Зафиксированная конфигурация до начала тестов

Конфигурация DUT — версия прошивки, включённые функции, политики безопасности, уровни логирования, все активные и неактивные модули — задокументирована и зафиксирована до первого пакета. Никаких изменений в окне теста. Никакого «тюнинга» между прогонами. Никаких правок задним числом перед повторным прогоном сценария.

Это важно, потому что изменения конфигурации во время теста — способ управлять результатом. Устройство слабо отработало в ранних прогонах с включённой функцией X, потом X тихо выключили для финального прогона, который попал в отчёт. Это не честное сравнение. Фиксация конфигурации заранее убирает эту переменную.

Зафиксированная конфигурация должна отражать вашу целевую боевую: ваше число правил, ваши включённые политики, ваш объём логирования, ваши настройки инспекции. Не дефолт вендора. Не минимальный набор под красивые числа.

2. Динамическая генерация трафика с разнообразием сессий на L7

Каждая сессия генерируется на ходу. Два потока одного типа не должны иметь одинаковый payload на L7. Это значит:

• уникальные HTTP-транзакции с разными заголовками, токенами, паттернами URI и длиной контента;
• TLS-сессии с разным согласованием cipher suite, обработкой сертификатов и значениями SNI;
• SMTP с разными комбинациями отправитель/получатель, структурами письма и профилями вложений;
• DNS с разными типами запросов и обработкой ответов.

Это отключает оптимизации на кеше и fast path, которые делают результаты PCAP-реплея ненадёжными. Устройство вынуждено классифицировать и инспектировать каждый поток отдельно — ровно как в проде.

Динамическая генерация не значит случайную и неуправляемую. Профиль трафика определён, параметризован и воспроизводим. Тот же seed, те же параметры, тот же тест — одинаковые характеристики трафика каждый раз. Воспроизводимость делает результаты защитимыми и позволяет перепроверять после изменений конфигурации.

3. Контроль AppMix по замкнутому циклу с проверкой на DUT

Микс приложений, который проходит через DUT, надо измерять, показывать в отчёте и контролировать. Нельзя считать, что он совпадает с тем, что настроили в генераторе.

Отчёт с фразой «профиль трафика: 30% HTTPS, 20% HTTP, 15% DNS…» должен включать проверенное измерение того, что реально прошло через DUT на уровне протоколов — со счётчиков трафика самого DUT или из inline-измерения на тестовых портах. Если измеренный микс отличается от заданного больше согласованного допуска, тест недействителен.

Без этого сравнение вендоров математически несостоятельно. Нельзя сравнивать результаты устройства A и устройства B, если реальный AppMix у каждого был разным, даже при одинаковом целевом распределении.

4. Эффективность защиты под нагрузкой, а не в изоляции

Rate детекта и эффективность блокировки меряют во время теста производительности, не отдельно от него.

Сценарий подаёт трафик атак внутри фонового потока легитимного трафика приложений, на уровне нагрузки, близком к боевому — на 60–80% номинального throughput устройства. Rate детекта, rate блокировки, rate ложных срабатываний и любое изменение latency или throughput от работы защиты под атакой — всё это фиксируется.

Устройство, которое ловит 99% атак на холостом ходу и 65% при 75% загрузки, даёт другой уровень защиты, чем говорит заголовочная цифра. Тест в изоляции это скрывает.

5. Детальная отчётность по протоколам

Суммарный throughput, суммарная latency и общий rate детекта результат не объясняют. Отчёт должен включать:

• throughput и rate успешных транзакций по протоколам (HTTPS отдельно от HTTP, DNS, SMTP и т.д.);
• распределения latency по протоколам — не только средние, важны 95-й и 99-й перцентили;
• проверенное распределение AppMix на DUT;
• rate детекта и блокировки по категориям атак;
• число неуспешных транзакций по типам протоколов;
• утилизацию ресурсов устройства за окно теста — CPU, память, число одновременных сессий.

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

Правильные инструменты: почему это важно

Одной методики мало. Платформа генерации трафика и измерений должна реализовывать методику точно.

Профессиональные коммерческие платформы — среди них Keysight BreakingPoint и CyPerf — сделаны именно под этот класс тестов. Они генерируют трафик на ходу, держат контроль AppMix по замкнутому циклу, подают атаки внутри легитимного трафика и выдают детальную статистику по протоколам, нужную для полного отчёта. Крупнейшие операторы, финансовые организации и госструктуры используют их для квалификации инфраструктуры именно потому, что результаты воспроизводимы и проверяемы.

Open-source инструменты — это генераторы пакетов и базовые нагрузочные утилиты. Для своих задач они полезны. Для оценки продуктов безопасности их недостаточно: нет динамической генерации на L7, нет обратной связи по AppMix, нет статистики по протоколам на уровне DUT, нет встроенной эмуляции атак с вариацией обходов. Они дают числа. Понимания они не дают.

Разница в цене между профессиональными инструментами и open-source реальна, но на фоне стоимости ошибки закупки по многолетнему контракту она мала.

Что делает TEST4NET

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

Тестирование идёт на Keysight BreakingPoint и CyPerf: динамическая генерация трафика, контроль AppMix по замкнутому циклу, полная детальная отчётность по всем типам протоколов. Эмуляция атак использует payload, сгенерированные на ходу, с управляемой вариацией обходов — не статический PCAP-реплей.

Каждая работа начинается с тест-плана, согласованного и зафиксированного до старта тестов: конфигурация DUT, параметры профиля трафика, целевой AppMix с методикой проверки, критерии pass/fail, формат отчёта. Тест-план — документ, который принадлежит покупателю. Если вендор или интегратор оспаривает методику, у покупателя есть защитимая запись о том, что тестировали и как.

В результаты входит:

• документ с методикой, зафиксированный до начала тестов;
• сырые данные тестов с детализацией по протоколам;
• проверенные измерения AppMix с DUT;
• сравнение вендоров бок о бок в одинаковых условиях;
• итоговый отчёт с находками, анализом и рекомендацией по закупке на измеренных данных.

TEST4NET приносит то, чего вендор и интегратор структурно принести не могут: отсутствие ставки на результат.

До того как подписать контракт

Вложение в независимый тест — доля от стоимости обязательства на 3–5 лет по инфраструктуре безопасности, выбранного по результатам под вендора. Вопрос не в том, можете ли вы позволить себе независимый тест. Вопрос в том, можете ли вы позволить себе его пропустить.

Если ваша организация планирует оценку NGFW, WAF, DLP, IPS или SASE и хочет методику с результатами, которые можно защитить перед советом директоров, аудиторами и службой эксплуатации — поговорите с TEST4NET до старта PoC.

Дальше в серии — Пост 6: почему одной оценки мало — постоянная проверка на всём жизненном цикле платформы безопасности.

Вся серия: Пост 1 · Пост 2 · Пост 3 · Пост 4 · Пост 5 · Пост 6