Одного теста мало: почему инфраструктуре безопасности нужна постоянная проверка
Alexander Zemskov
Это шестая часть серии о том, как оценивать продукты сетевой безопасности. Часть 1 — разрыв в даташитах. Часть 2 — ловушки NGFW. Часть 3 — WAF, IPS, DLP. Часть 4 — SASE. Часть 5 — методика и независимый тест.
Первые пять постов были про этап закупки: как построить тест, результатам которого можно доверять, до подписания контракта. Этот пост про то, что происходит после подписания. Относиться к первичной оценке как к разовому событию — одна из самых частых и дорогих ошибок в эксплуатации безопасности.
Через два года вы работаете не на той платформе, которую покупали
Любая корпоративная платформа безопасности — NGFW, WAF, IPS, DLP, SASE — регулярно получает обновления ПО: релизы прошивки, патчи безопасности, обновления баз threat intelligence, выкатки новых функций, смену алгоритмов, оптимизации производительности. Вендоры выпускают их непрерывно. Только в сегменте NGFW крупные вендоры выпускают крупные обновления прошивки по несколько раз в год, а хотфиксы и патчи безопасности — заметно чаще.
Каждое такое обновление меняет платформу. Иногда изменения мелкие. Иногда нет.
Обновление прошивки с новым алгоритмом DPI — выше точность детекта, шире покрытие протоколов, лучше устойчивость к обходам — добавляет и новый overhead на обработку каждой инспектируемой сессии. Обновление базы threat intelligence на 50 000 новых сигнатур улучшает защиту и повышает стоимость поиска на каждый пакет. Новая функция с реальной пользой — инспекция шифрованного DNS, ML-детект аномалий, плотная интеграция с облачной песочницей — расходует память, такты CPU и, возможно, выделенную ёмкость ASIC.
Платформа, которую вы проверили на закупке, на конкретной версии прошивки, с конкретным набором функций и состоянием баз, — это не та платформа, что работает через 18 месяцев регулярных обновлений. Диапазон производительности смещается с каждым значимым изменением. Вопрос в том, отслеживаете ли вы это смещение или узнаёте о нём, когда авария в проде заставляет разбираться.
Железо — фиксированное ограничение. Софт — нет.
Здесь разрыв между облачными и аппаратными платформами безопасности становится операционно значимым так, как решения о закупке обычно не учитывают.
У облачного SASE или виртуального NGFW на эластичной инфраструктуре есть запас гибкости, когда обновление ПО поднимает расход ресурсов: базовые вычисления масштабируются, поднимаются дополнительные инстансы, добавляется память и CPU без цикла закупки железа. Операционное трение реально, стоимость растёт, но потолок не фиксирован.
Аппаратный appliance — закрытый бюджет ресурсов. RAM распаяна. CPU фиксирован. Сетевой процессор и ASIC безопасности такие, какие есть. Обновление прошивки подняло расход памяти на сессию — добавить память нельзя. Новый алгоритм инспекции добавил 15% нагрузки на CPU — добавить ядра нельзя. Сочетание новых функций и обновлённой базы сигнатур подняло расход памяти на одновременные сессии до 90% установленной RAM — запас на всплески трафика исчез.
Вендоры анонсируют новые возможности прошивки маркетингом, где на первом месте улучшения по безопасности и функциональности. Последствия для расхода ресурсов описаны в release notes, если вообще описаны, техническим языком, который редко превращается в чёткое «это обновление снизит эффективный throughput на N% на таких-то моделях». Заказчик видит анонс функции. Эффект на производительность приходит в прод.
Это не гипотеза. Компании, которые на закупке работали на 60–70% номинальной ёмкости аппаратных appliance, регулярно оказываются на 85–90% через два-три года эксплуатации — без смены железа, без заметного роста трафика, со списком обновлений прошивки, каждое из которых по отдельности казалось мелким.
Новые функции как троянский конь
Есть конкретный паттерн, который стоит назвать прямо, потому что он повторяется у разных вендоров и категорий продуктов.
Вендор выпускает крупную версию прошивки с возможностями, которые заказчику реально нужны: лучше видимость шифрованного трафика, точнее идентификация приложений, новый движок детекта угроз с явно более высоким catch rate. Команда безопасности оценивает новые возможности, подтверждает, что они закрывают реальные пробелы, планирует апгрейд.
Что не оценивают — потому что структурного теста под это нет — так это эффект от включения новых возможностей на текущем железе, под боевым профилем трафика, на боевом уровне нагрузки.
Апгрейд выкатили. Новые функции включили. Первые дни всё выглядит нормально. Потом, плавно или резко в зависимости от характера изменения, появляются симптомы: рост latency под пиком, деградация темпа установки соединений, расход памяти ползёт вверх и не возвращается, приходят первые тикеты от пользователей о медленных приложениях, которые раньше были быстрыми.
Запускается разбор инцидента. Вывод: новая прошивка на текущем железе при текущем объёме трафика больше не имеет достаточного запаса. Варианты: откатить прошивку и потерять улучшения по безопасности, выключить новые функции и потерять причину апгрейда, ускорить обновление железа и получить незапланированный capex.
Все три исхода можно было выявить до выката в прод. Ни один не требует дорогого или сложного тестирования. Нужен структурный процесс проверки перед развёртыванием.
Проверка перед развёртыванием: что реально нужно
Проверить обновление платформы безопасности до выката в прод — это не воспроизводить весь PoC этапа закупки. Это ответить на более точечный набор вопросов.
Регрессия throughput. Держит ли обновлённая прошивка throughput в приемлемом допуске от предыдущей версии, под тем же профилем трафика? Регрессия в 5% может быть приемлема. Регрессия в 20% — это событие для планирования ёмкости.
Расход ресурсов на боевой нагрузке. Какие CPU, память и число одновременных сессий на характерной боевой нагрузке под новой прошивкой? Как это соотносится с предыдущей версией? Каков новый запас?
Корректность новых функций. Работают ли новые возможности как в документации? Корректно ли взаимодействуют с текущими политиками? Нет ли неожиданных изменений в обработке трафика?
Регрессия безопасности. Сохраняет ли обновление эффективность детекта или улучшает её? Изменения прошивки, которые трогают движок DPI, логику сопоставления правил или парсеры протоколов, могут вносить регрессии в покрытие детекта — не потому что вендор так задумал, а потому что сложные системы меняются неочевидно. Это надо проверять, а не предполагать.
Работоспособность отката. Если обновление даст неожиданную проблему в проде, можно ли откатить его чисто? Проверка пути отката до выката — это разница между плановым откатом за 20 минут и аварийным откатом за четыре часа, пока боевая система деградирует.
Аргумент за постоянную тестовую функцию
Совокупный вывод этого поста — довод в пользу постоянного тестирования как операционной дисциплины, а не тестирования как эпизода, который запускает событие закупки.
В точке, где организация управляет несколькими платформами безопасности, у каждой свой ритм обновлений, а в проде важны базовые уровни производительности и безопасности, операционная модель меняется. Разовые тесты перед крупными обновлениями — начало. Структурный воспроизводимый процесс проверки с заданными базовыми уровнями, порогами регрессии и понятным маршрутом от «обновление вышло» до «допущено в прод» — вот уровень зрелости, который убирает описанный класс инцидентов.
Строить эту функцию внутри — верный ответ на определённом масштабе: когда объём тестирования, частота обновлений, требующих проверки, и наличие внутренних людей оправдывают вложение в постоянную тестовую инфраструктуру и инструменты. В этой точке собственный тестовый стенд с генерацией трафика коммерческого уровня даёт команде безопасности возможность, которая окупается на закупках, проверке обновлений, разборе инцидентов и планировании ёмкости.
Для организаций, которые ещё не на этом масштабе или которым возможность нужна сразу, без времени на постройку внутренней инфраструктуры, операционная модель — постоянные отношения с независимой лабораторией. Не разовая работа на этапе закупки, а повторяемый процесс: обновление вышло, тест проверки прогнан против согласованного базового уровня, результаты сопоставлены, решение go/no-go принято до выката в прод.
Стоимость такого процесса на цикл обновления предсказуема и ограничена. Стоимость непроверенного обновления, которое дало деградацию в проде — инженерное время, разбор инцидента, возможная экстренная закупка железа, ущерб бизнесу — нет.
Рабочая рамка проверки обновлений
Независимо от того, тестируете вы внутри или через лабораторию, процессу нужны три элемента, чтобы быть последовательным и защитимым.
Замороженный базовый уровень. На проверке при закупке (или при запуске программы тестирования) фиксируется база по производительности и безопасности против согласованного профиля трафика. Это точка отсчёта для всех последующих обновлений. Throughput на заданном AppMix, расход ресурсов на заданных уровнях нагрузки, rate детекта против согласованного профиля атак. Эти числа заблокированы и не меняются до осознанного решения обновить базу.
Заданный допуск на регрессию. Какой размах изменения любого измеряемого параметра требует эскалации до выката в прод? Пороги задают заранее и согласуют между командой безопасности и эксплуатацией, а не выводят задним числом на разборе инцидента. Типичные параметры: регрессия throughput больше X%, рост утилизации памяти больше Y процентных пунктов, снижение ёмкости по одновременным сессиям больше Z%.
Воспроизводимый процесс прогона теста. Тест должен выполняться тем, кто его ведёт — внутренняя команда, внешняя лаборатория — и давать сопоставимый результат каждый раз. Тот же профиль трафика, те же уровни нагрузки, та же методика измерений. Разброс в методике прогона даёт разброс в результатах, и анализ тренда становится невозможен.
Что не меняется
Одно остаётся неизменным на любом уровне зрелости программы: достоверность теста держится на качестве профиля трафика и точности инструментов измерения.
Все проблемы из прошлых постов серии — дрейф AppMix, предсказуемость PCAP-реплея, проверка эффективности защиты в изоляции — применимы к проверке обновлений так же, как к тестам на закупке. База, снятая ненадёжными инструментами, — это не база. Сравнение регрессии инструментом, который даёт непостоянный результат, защитимых выводов не даёт.
Вложение в правильную методику и правильные инструменты на этапе закупки окупается в каждом последующем прогоне на всём жизненном цикле платформы.
Тестирование — это операционная инфраструктура
Тест на закупке — начало отношений с платформой безопасности, а не их конец. Ограничения железа фиксированы, сложность софта растёт с каждым циклом обновлений. Новые функции и алгоритмы, которые вендор продаёт как улучшения, способны тихо съесть тот запас производительности, который обосновал выбор железа.
Организации, которые обходят описанный класс инцидентов, объединяет одно: они относятся к тестированию как к постоянной операционной инфраструктуре, а не как к разовой статье расходов в проекте. У них есть база. У них есть процесс. Они его прогоняют.
Для тех, кто строит этот уровень зрелости или кому проверка нужна сейчас, TEST4NET LLC закрывает и первичную оценку на закупке, и рамку проверки обновлений. Одна модель работы, одна методика, результаты сопоставимы в любой точке жизненного цикла платформы.
Вся серия: Пост 1 · Пост 2 · Пост 3 · Пост 4 · Пост 5 · Пост 6
