Это пятая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 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