Встроенные правила WAAP необходимы — но никакие два приложения не ведут себя одинаково.
Встроенные WAAP-сигнатуры обеспечивают базовую защиту от SQL injection, XSS, path traversal, SSRF, известных CVE и общих техник атак. Однако в реальных production-средах каждое приложение отличается. Некоторые API требуют определённых форматов заголовков, некоторые приложения полагаются на устаревшие структуры параметров, а трафик, абсолютно нормальный для одного сервиса, может выглядеть подозрительным для встроенного набора сигнатур.
Из этого следуют два требования. Первое — добавление специфических для приложения правил WAAP без нарушения встроенного набора правил. Второе — изменение поведения существующего встроенного правила для конкретного сервиса: его отключение, перевод в режим мониторинга, снижение оценки или ограничение конкретным разделом трафика.
В традиционных подходах написание пользовательских правил часто является тяжёлой работой. Оператору приходится изучать проприетарный язык скриптов, синтаксис правил становится сложным, плохо написанный regex может прервать production-трафик, а развёртывание правила может создать риск прерывания сервиса. В результате команды либо пишут слишком широкие правила, либо временно игнорируют рискованный трафик.
Управление ID, обработка переопределений и изоляция уровней добавляют ещё одно измерение. Когда встроенные правила, общеорганизационные пользовательские правила и специфические для приложения правила разделяют одно пространство имён, обслуживание становится затруднительным. Если одно правило должно вести себя по-разному в разных приложениях, подход дублирования и редактирования быстро становится неустойчивым.
Модель TR7 Пользовательских правил WAAP упрощает эту сложность: пользовательские правила определяются с помощью regex, области, оценки и состояния; существующие правила корректируются с помощью переопределений; глобальные уровни и уровни пула управляются через неконфликтующие диапазоны ID.
Наш подход
TR7 превращает создание пользовательских правил WAAP из отдельной задачи кодирования в верифицируемый, многоуровневый поток политик, нативный для основного движка WAAP.
Пользовательские сигнатуры определяются через мастер или модель необработанного правила
Оператор определяет пользовательское правило WAAP с полями имени, описания, regex, области совпадения, оценки и состояния. Режим мастера достаточен для повседневного использования; команды, желающие более жёсткого контроля, могут управлять той же структурой как необработанным JSON.
Потоки нового правила и переопределения разделены
Новые паттерны regex могут добавляться для специфических для организации или приложения потребностей. Для существующих встроенных правил переопределяется только то конкретное поведение, которое необходимо изменить — состояние, оценка или область совпадения; встроенный набор правил никогда не разветвляется.
Глобальные уровни и уровни пула сосуществуют без конфликтов
Глобальный уровень предоставляет общеорганизационный базовый уровень для всех сервисов; уровень пула применяет более узкие настройки для конкретных приложений или сервисов. Поскольку диапазоны ID разделены, встроенные правила, глобальные пользовательские правила и правила, специфические для сервиса, никогда не сталкиваются.
Модель валидации и горячей загрузки снижает риск production
Перед вводом правила в действие проверяются поля имени, оценки, области и regex. Если правило действительно, целевой сегмент сигнатур перекомпилируется; незатронутые части движка не затрагиваются.
Возможности
Пользовательские правила WAAP запускают пользовательскую логику безопасности на том же уровне, что и основная система оценки WAAP.
Пользовательские правила WAAP создаются с помощью regex, области, оценки и состояния
Каждое пользовательское правило определяется с именем, описанием, regex, областью совпадения, оценкой и состоянием. Regex задаёт паттерн атаки или запрещённый формат; область определяет, ищется ли этот паттерн в path, query, header, form, json, xml или raw-содержимом. Значение оценки несёт угрозовый вес в модель оценки WAAP. Поле состояния контролирует, является ли правило enabled, monitor или disabled.
Семь областей инспекции гарантируют, что правило работает в правильном разделе трафика
Пользовательское правило не применяется вслепую ко всему запросу. Точный раздел трафика для поиска выбирается явно. Параметры области path, query, header, form, json, xml и raw сужают, где работает правило. Это снижает риск ложноположительных результатов и гарантирует, что regex работает только там, где он значим. Один и тот же паттерн может использоваться в разных областях с разными эффектами.
Четыре уровня оценки вносят угрозовый вес в модель WAAP
Пользовательским правилам назначается один из четырёх уровней оценки: 2, 4, 6 или 8. Более низкие оценки подходят для мониторинга или слабых сигналов; более высокие оценки указывают на сильные индикаторы атаки. Оценка входит в основной механизм принятия решений WAAP и оценивается наряду с другими сигнатурами. Пользовательское правило — не изолированный переключатель блокировки; оно является частью составного расчёта риска.
Режим мониторинга тестирует правило на production-трафике без блокировки
Новое пользовательское правило не обязательно сразу переходить в режим блокировки. В режиме monitor совпадения правил логируются, но трафик не прерывается. Операционная команда наблюдает за частотой ложноположительных результатов на реальном трафике, уточняет regex и область, а затем уверенно переводит правило в enabled. Эта модель обеспечивает контролируемое внедрение в production.
Встроенные правила WAAP могут быть переопределены без их копирования
Если существующее встроенное правило создаёт слишком много шума в конкретном приложении, нет необходимости копировать и изменять набор правил. Переопределение изменяет поведение состояния, оценки или области совпадения. То же встроенное правило может оставаться активным глобально, будучи переведённым в режим monitor или суженным до меньшей области для конкретного пула. Это снижает бремя обслуживания и предотвращает расхождение с текущим набором сигнатур.
Глобальные пользовательские правила и правила пула хранятся в отдельных диапазонах ID
ID глобальных пользовательских правил генерируются в диапазоне 1 000 000–4 999 999; ID пользовательских правил пула — в диапазоне 5 000 000–9 999 999. Это разделение предотвращает конфликты между встроенными правилами, общеорганизационными правилами и специфическими для приложения правилами. Операционная команда может идентифицировать область правила только по его ID. Управление инвентарём правил становится более упорядоченным в больших средах.
Перекомпилируется только затронутый сегмент сигнатур — не весь движок
При изменении пользовательского правила перекомпилируется только целевой сегмент сигнатур. Подход остановки и перезапуска всего неизменённого набора правил не используется. Это делает операции с правилами более быстрыми и менее рискованными. Поведение особенно ценно для часто меняющихся временных правил защиты.
Пользовательские правила появляются в логах и SIEM точно так же, как встроенные
Совпадения пользовательских правил не хранятся в отдельном, отключённом формате логов. ID правила, имя, состояние, значение оценки и совпадающая область включаются в основной поток событий WAAP. На стороне SIEM пользовательские и встроенные правила могут проверяться через одну модель событий. Эта видимость обеспечивает последовательность для реагирования на инциденты и отчётности о соответствии.
Операционная глубина
Управление пользовательскими правилами WAAP рассматривается совместно с валидацией, управлением конфликтами, горячей загрузкой, аудитом и процедурами отката.
Валидация правила
Перед вводом правила в действие проверки подтверждают, что regex непустой, оценка является одним из допустимых значений, а список областей действителен. Уникальность имени и диапазон ID также являются частью процесса валидации. Недействительное правило не допускается в движок WAAP.
Приоритет уровней
Глобальный уровень предоставляет общеорганизационный базовый уровень; уровень пула определяет более специфическое поведение для конкретного сервиса или приложения. Когда одна и та же логика нуждается в разных результатах на разных уровнях, используется механизм переопределения. Эта модель предоставляет управляемые, ограниченные исключения вместо дублированных правил.
Безопасность regex
Небрежно написанные паттерны regex могут создавать риск производительности. Паттерны, которые слишком широки, требуют обратного отслеживания или применяются к излишне большим областям, могут создавать затраты в production-трафике. Поэтому regex следует определять с как можно более узкой областью и как можно более точным паттерном.
Переход от monitor к enabled
Безопасный рабочий процесс для нового пользовательского правила — сначала наблюдать реальный трафик в режиме monitor. Результаты логов проверяются, а пути, заголовки или параметры, производящие ложноположительные результаты, оцениваются. Когда поведение правила ясно, оно переводится в режим enabled.
Аудит и след изменений
Добавление, обновление, отключение и переопределение пользовательских правил должны быть привязаны к записям аудита. Кто изменил оценку, область или состояние какого правила и когда — это критически важная информация для пост-инцидентного анализа. История изменений особенно важна для операционной безопасности правил с эффектом блокировки.
Управление откатом
Если пользовательское правило производит неожиданные эффекты, оно может быть быстро переведено в состояние monitor или disabled. Изменения переопределений также могут быть отменены для восстановления поведения встроенного правила. Это делает операции с правилами возможными без прерывания production-трафика.
Когда это использовать
Добавление временного правила защиты от нулевого дня
Команда безопасности может добавить временное правило на основе regex для вновь раскрытой уязвимости без ожидания официального обновления сигнатур. Правило сначала тестируется в режиме мониторинга и переводится в enabled после подтверждения паттерна атаки.
Сужение встроенного правила, производящего ложноположительные результаты
Если встроенное правило WAAP влияет на нормальный трафик в конкретном приложении, оно переопределяется, а не полностью отключается. Область сужается, оценка снижается или правило переводится в режим мониторинга только для соответствующего пула.
Применение проверок формата соответствия на уровне edge
Финансовые или медицинские приложения могут использовать пользовательские правила для валидации ожидаемых форматов в конкретных заголовках, полях форм или JSON-полях. Несоответствующие запросы оцениваются или блокируются до достижения кода приложения.
Блокировка специфических для приложения злоупотреблений API
Команды SaaS могут перехватывать паттерны злоупотреблений, специфические для поведения их собственного API, в областях path, query, header или JSON. Нарушения бизнес-логики, не охватываемые встроенным набором сигнатур, управляются как пользовательские правила внутри TR7 WAAP.
Часто задаваемые вопросы
Работает ли пользовательское правило WAAP независимо от встроенного движка сигнатур?
Какие свойства существующего правила можно изменить через переопределение?
Какова цель режима мониторинга?
Как глобальный уровень и уровень пула управляют одним пользовательским правилом?
Каковы семь параметров области и почему они важны?
Перезапускает ли изменение правила весь движок WAAP?
Привяжите логику WAAP вашей организации к основному движку сигнатур
Пользовательские правила безопасности с regex, областью, оценкой и переопределением. Давайте пройдём живую настройку в вашей собственной среде.