Если патч приложения не готов, надеяться на то, что злоумышленник подождёт, — не стратегия безопасности.
Когда публикуется новый нулевой день или критическая CVE, реальная проблема, с которой сталкивается организация, редко состоит в незнании уязвимости — она в том, насколько быстро можно применить патч к приложению. Устаревшие приложения, версии без поддержки, хрупкие зависимости и программное обеспечение с привязкой к поставщику — всё это делает прямое исправление кода затруднительным.
Официальный патч может занять дни или недели. Даже когда патч выходит, его развёртывание в production — отдельный процесс: регрессионное тестирование, окно изменений, цепочка утверждений, план отката и риск простоя сервиса. Когда начинается активная волна атак, эти процессы недостаточно быстры для команды безопасности.
При облачных или внешне зависимых фидах сигнатур WAAP организации не всегда могут контролировать, когда придёт сигнатура критической CVE или насколько она будет настраиваемой. Это особенно важно в on-premises, изолированных или суверенных облачных архитектурах, где реагирование на безопасность должно выполняться внутри организации.
Неправильно применённый virtual patching создаёт новые проблемы. Слишком широкие правила regex могут нарушить работу легитимных пользователей, неправильный выбор области может затронуть несвязанные приложения, а правило, помещённое непосредственно в режим блокировки, может создать ложноположительные результаты в production. Поэтому быстрое реагирование требует контролируемого тестирования и возможности отката — не только скорости.
Подход TR7 к virtual patching сужает поверхность атаки на уровне трафика до готовности кода приложения — делая это через режим мониторинга, управление оценкой, выбор области и горячую перезагрузку без внесения операционного риска.
Наш подход
TR7 рассматривает virtual patching не как разовое аварийное правило, а как тестируемый, управляемый жизненный цикл безопасности.
Готовые сигнатуры для критических CVE включены в набор безопасности
Готовые сигнатуры для критических уязвимостей, таких как Log4Shell, Spring4Shell и Shellshock, доступны в базе данных WAAP. Отдельные паттерны охватывают несколько вариантов и закодированные формы атак.
Пользовательские правила патча создаются шаг за шагом
Операторы пишут regex, выбирают поле совпадения, назначают оценку и устанавливают состояние правила. Правила могут применяться к различным полям трафика, включая path, query, header, form, json, xml или raw body.
Дата патча записывается и трассируется
Каждое пользовательское правило хранится с временной меткой даты. Эта запись упрощает просмотр того, когда был добавлен временный патч, и очистку после введения постоянного исправления приложения.
Режим мониторинга обеспечивает безопасную валидацию в production
Правило в состоянии `monitor` генерирует логи без блокировки трафика. После наблюдения командой безопасности за влиянием на ложноположительные результаты то же правило может быть переведено в `enabled` для активации блокировки.
Возможности
TR7 Virtual Patching объединяет готовые CVE-сигнатуры, создание пользовательских правил и контролируемую активацию в едином конвейере политик.
Готовые CVE-сигнатуры быстро охватывают критические семейства атак
База данных TR7 WAAP включает готовые сигнатуры для критических уязвимостей, таких как Log4Shell, Spring4Shell и Shellshock. Для Log4Shell базовые JNDI-паттерны, закодированные варианты и попытки обфускации могут быть адресованы отдельными паттернами. Эта структура снижает необходимость писать правила с нуля для известных атак высокого риска. Организации могут активировать готовую сигнатуру в режиме мониторинга или блокировки для быстрого реагирования.
Проверьте выражение до того, как оно к чему-либо привязано
Напишите выражение, вставьте запрос, который должен совпасть, и запрос, который совпадать не должен, и посмотрите результат — прямо в интерфейсе, ещё до того как правило будет привязано хотя бы к одной службе. Классическая авария виртуального патчинга — шаблон, оказавшийся чуть шире нужного и заблокировавший реальных клиентов в момент выхода в бой; здесь это ловится при написании, а не из канала инцидентов. Режим наблюдения остаётся для следующего шага: правило смотрит на живой трафик прежде, чем ему позволят что-либо блокировать.
Пользовательские виртуальные патчи на основе regex могут быть написаны для новых уязвимостей
Пользовательское правило regex может быть определено для уязвимости, специфической для организации, изъяна плагина CMS или результата теста на проникновение. Правило может применяться к различным полям совпадения, включая path, query, header, form, json, xml или raw body. Это позволяет команде безопасности перехватывать паттерн атаки на уровне трафика без изменения кода приложения. Подход создаёт быстрый уровень защиты до готовности постоянного патча.
Режим мониторинга измеряет реальное влияние трафика до включения блокировки
Вновь добавленное правило в состоянии `monitor` только генерирует логи и не блокирует пользовательский трафик. Команда безопасности может наблюдать, какие запросы соответствуют правилу, вызывает ли оно ложноположительные результаты и каково его влияние на оценку. Когда результат безопасен, правило переводится в состояние `enabled`. Этот поток балансирует скорость аварийного реагирования с безопасностью production.
Модель принятия решений на основе оценки управляет разными уровнями риска
Пользовательским правилам можно назначать оценки, такие как 2, 4, 6 или 8. Высокая оценка используется для сценариев прямой блокировки; более низкая оценка вносит вклад в совокупное пороговое решение. Эта структура позволяет настраивать каждый виртуальный патч в соответствии с определённостью атаки и деловым влиянием, а не применять одинаковую серьёзность к каждому правилу. Операторы могут создавать как точные, так и агрессивные политики.
Разные области патча могут быть определены на глобальном уровне и уровне пула
Виртуальный патч может применяться глобально ко всем пулам сервисов или быть привязан только к конкретному пулу. Глобальный уровень обеспечивает быстрое покрытие для широко распространённых CVE-атак, тогда как уровень пула предлагает более контролируемую область для конкретных уязвимостей приложения. Это гарантирует, что единственная уязвимость CMS не усилит без необходимости всю политику платформы. Область правила может быть сужена в соответствии с риском приложения.
Состояние и оценка существующих правил могут быть переопределены
Состояние существующего правила может быть изменено на `enabled`, `disabled` или `monitor`. Аналогично, значение оценки может быть увеличено или уменьшено для корректировки веса правила в процессе принятия решений. Эта функция используется для временного помещения известной сигнатуры в режим мониторинга или её более агрессивного применения в аварийной ситуации. Политика организации может быть настроена с учётом реального поведения трафика.
Горячая перезагрузка не превращает развёртывание патча в операцию перезапуска
При добавлении нового виртуального патча изменённое содержимое regex обрабатывается, обновляются соответствующие хэш-структуры и перекомпилируется только затронутый сегмент. Этот процесс нацелен на активацию правила без перезапуска всего уровня прокси. Операция компиляции выполняется в рамках контролируемых ресурсных ограничений. Команды безопасности могут применять аварийные патчи, не делая их зависимыми от окна обслуживания.
Поведение патча может быть валидировано со словарём тестовых атак
Конкретные примеры атак из готового словаря атак могут воспроизводиться в тестовом фреймворке TR7. Инструмент `Attack.js` позволяет выбирать целевой хост и порт и запускать конкретные ID атак. Этот метод практически верифицирует, перехватывает ли виртуальный патч ожидаемый паттерн атаки. Операционные команды могут конкретно наблюдать поведение перед выводом правила в production.
Операционная глубина
Virtual patching требует трассируемости правил, отката, управления областью и тестовой дисциплины в не меньшей степени, чем быстрого аварийного реагирования.
Диапазоны ID правил
Глобальные пользовательские правила и пользовательские правила уровня пула хранятся в отдельных диапазонах ID. Глобальные правила находятся в диапазоне 1M–5M, правила пула — в диапазоне 5M–10M. Это разделение делает операционно более заметной область, на которую влияет правило.
Отслеживание даты патча
Пользовательские правила хранятся с временной меткой даты в формате `ДД.ММ.ГГГГ`. Это поле важно для предотвращения забывания временных патчей. После завершения постоянного исправления приложения связанные виртуальные патчи могут быть очищены группой.
Процесс компиляции горячей перезагрузки
При обработке нового содержимого regex соответствующие хэш-значения пересчитываются и изменённый сегмент перекомпилируется. Процесс выполняется в рамках ресурсных ограничений и обеспечивает обновление затронутого конвейера безопасности. Аварийное добавление правил не требует широкого прерывания сервиса.
Тестирование атак до production
Готовый словарь атак помогает с валидацией правил с использованием известных примеров атак. Операторы могут запускать конкретные ID атак и наблюдать, логирует или блокирует ли правило. Этот тест снижает риск ложноположительных и ложноотрицательных результатов особенно для новых правил regex.
Управление откатом правила
Виртуальные патчи следует рассматривать как временные средства управления безопасностью. После постоянного исправления приложения связанные пользовательские правила могут быть отключены или удалены группой. Без этой дисциплины старые аварийные правила накапливаются со временем, создавая путаницу в политиках и риск ненужной блокировки.
Генерация аудита и свидетельств
Имя правила, описание, дата, состояние, оценка и поля совпадения создают значимые записи с точки зрения аудита. Команды безопасности могут показать, какое временное средство управления было добавлено для конкретной CVE или результата теста на проникновение и когда оно было применено. Это особенно полезно в процессах соответствия для демонстрации цепочки: уязвимость обнаружена, средство управления применено, постоянный патч ожидается.
Когда это использовать
Аварийное реагирование на Log4Shell
При обнаружении риска Log4Shell в устаревшем Java-приложении, которое не может быть немедленно пропатчено, готовая сигнатура может быть активирована в TR7 для блокировки вариантов JNDI на уровне трафика и выигрыша времени для исправления приложения.
Временная защита Spring4Shell на устаревшем приложении
Если в устаревшем фреймворке приложения существует риск манипуляции загрузчиком классов, правило можно сначала запустить в режиме мониторинга. После измерения влияния на трафик в течение дня правило переводится в режим блокировки для устранения уязвимости.
Пользовательская блокировка параметров для уязвимости плагина CMS
До выхода патча поставщика для плагина CMS паттерн атаки может быть виден в конкретных параметрах. В TR7 написано пользовательское правило regex, нацеленное только на соответствующий путь или поле query. Это блокирует рискованные запросы без вывода всего приложения из строя.
Временное средство управления безопасностью после результата теста на проникновение
Когда команда по тестированию на проникновение сообщает об эксплуатируемой уязвимости в production, команде разработки требуется время для постоянного исправления. TR7 virtual patching обеспечивает промежуточное средство управления, предотвращающее превращение результата в атакующий трафик в этот период.
Часто задаваемые вопросы
Действительно ли TR7 virtual patching защищает без изменения кода приложения?
Блокирует ли TR7 новые CVE автоматически?
Что такое режим мониторинга и почему его следует использовать?
Требует ли добавление правила виртуального патча перезапуска сервиса?
В чём разница между virtual patching на глобальном уровне и уровне пула?
Как управляются виртуальные патчи после постоянного исправления приложения?
Закрывайте уязвимости без изменения кода
От Log4Shell до результатов тестов на проникновение — TR7 virtual patching задействуется на уровне трафика в каждом аварийном сценарии. Давайте пройдём живую настройку в вашей собственной среде.