Блокировать по одному совпадению легко — правильное решение WAAP требует оценки, контекста и управления.
В традиционном подходе WAAP совпавшая сигнатура немедленно блокирует запрос. Это выглядит быстро, но в реальных развёртываниях повышает риск ложноположительных результатов. Один и тот же паттерн может представлять атаку в одном контексте и законный формат данных в другом. Вот почему одинаково жёсткое отношение к каждому правилу редко является правильным подходом.
Второй вызов — управленческая сложность больших наборов правил. Когда неясно, какое правило в какой области работает, к какой категории атак оно принадлежит, какую оценку производит и на каких сервисах активно, операционные команды в итоге запускают WAAP либо слишком разрешительно, либо слишком агрессивно.
Современная поверхность атак больше не ограничивается классическими SQL injection и XSS. API-конечные точки, поля JSON-тела, GraphQL-запросы, манипуляции JWT, NoSQL-запросы, уязвимости шаблонных движков, десериализация и новые варианты CVE — всё это появляется в одном потоке трафика. Если движок WAAP не может разделить это разнообразие по области и категории, видимость страдает.
Правильный подход — запускать сигнатуры через модель принятия решений на основе оценок. Каждое правило должно производить собственный вес, сервисные пороги должны оценивать накопленные оценки, состояние правила должно управляться как monitor или blocking, а пользовательские потребности должны быть переопределяемы на глобальном уровне или уровне пула.
TR7 WAAP Signature & Scoring реализует эту модель: делает более 3 000 production-правил, 32 категорий атак и 7 областей инспекции управляемыми через логику оценки, порога и переопределения.
Наш подход
TR7 применяет решение WAAP через многопаттерновое совпадение, пороги на основе оценок, двухуровневую модель переопределения и обогащённый набор правил атак.
Многопаттерновый движок обрабатывает тысячи сигнатур в одном сканировании
TR7 эффективно запускает большие наборы правил через подход многопаттернового совпадения regex. Правила могут компилироваться в сегментах, так что при обновлении правил пересобираются только изменённые части.
Модель оценки и порога снижает риск ложноположительных результатов
Каждое правило может производить оценку — 2, 4, 6 или 8. Эти оценки объединяются с пороговым значением на уровне сервиса, так что оценивается общая картина риска, а не единственный слабый сигнал.
Двухуровневое переопределение на глобальном уровне и уровне пула
Глобальные пользовательские правила и правила пула хранятся в отдельных пространствах имён ID. Это позволяет совместно существовать общей организационной политике и исключениям, специфическим для клиента или сервиса, без конфликтов.
Обогащённый уровень TR7 охватывает современные семейства атак
TR7 добавляет обогащённые правила для API, JWT, GraphQL, NoSQL, инъекций prompt, шаблонных инъекций и вариантов атак, специфических для CVE, в дополнение к классическим веб-сигнатурам. Этот уровень расширяет покрытие современной поверхности приложений.
Возможности
WAAP Signature & Scoring делает широкий набор production-правил управляемым через оценку, область и средства управления состоянием для каждого сервиса.
Более 3 000 production-правил охватывают широкую поверхность атак
TR7 поставляется с более чем 3 000 правилами WAAP, подготовленными для production-использования. Охватываются основные семейства атак — SQL injection, XSS, path traversal, SSRF, XXE, десериализация, шаблонные инъекции, чтение файлов, запись файлов, выполнение команд и раскрытие информации. Правила управляются не только как плоский список паттернов, но и совместно с метаданными категории, оценки, области и цели. Эта структура сочетает широкую защиту с операционным контролем.
32 категории атак делают набор правил читаемым
Правила организованы в 32 категории атак: обход управления доступом, обход аутентификации, злоупотребление бизнес-логикой, отравление кэша, CRLF injection, инъекция запросов данных, уклонение от кодирования, включение файлов, HTTP smuggling, открытый редирект, загрязнение параметров, инъекция prompt, загрязнение прототипов, манипуляции сессией и другие. Эта классификация позволяет командам безопасности понять, какие семейства атак срабатывают чаще всего. Управление правилами работает через значимые заголовки рисков, а не через тысячи необработанных записей.
7 областей инспекции оценивают каждую поверхность запроса отдельно
Правила TR7 могут работать в полях path, query, header, form, JSON, XML и raw. Каждое правило объявляет точно, с какой областью оно совпадает. Сигнатура, написанная для JSON-тела, не запускается без необходимости на заголовке, а правило, ориентированное на путь, не применяется неверно к телу трафика. Разделение областей важно как для точности, так и для производительности.
Запросы нормализуются до проверки, включая нелатинские алфавиты
Кодировки percent, HTML-entity, Base64, UTF-8 и UTF-16 декодируются до срабатывания сигнатуры, и декодер не ограничен латиницей — кириллица и другие письменности обрабатываются так же. Атака, спрятанная за двойным кодированием или нелатинским набором символов, попадает под то же правило, что и её открытая форма.
Модель принятия решений на основе оценок снижает слепую блокировку по единственному совпадению
Каждое правило производит конкретную оценку, которая сравнивается с сервисным порогом. Совпадения с низким риском могут производить только запись в лог, тогда как более высокая суммарная оценка приводит к решению о блокировке. Этот подход рассматривает общее поведение риска, а не рассматривает единственное совпадение сигнатуры как абсолютный вердикт. Настройка порога для каждого сервиса позволяет защищать разные приложения с разной чувствительностью.
Состояния enabled, disabled и monitor обеспечивают безопасные переходы правил
Каждое правило может работать в режиме enabled, disabled или monitor. В режиме enabled правило вносит вклад в оценку и решения о блокировке; в режиме disabled оно неактивно; в режиме monitor оно производит только вывод в лог. Новые или неопределённые правила можно сначала наблюдать в режиме monitor. Это делает переходы политик в production-сервисах значительно более безопасными.
Глобальное переопределение и переопределение пула обеспечивают настройку для каждого сервиса
Глобальное переопределение задаёт политику WAAP для всей организации, тогда как переопределение пула определяет разное поведение для конкретного сервиса или клиента. Правило может оставаться активным глобально, но быть переведённым в режим monitor для конкретного пула или иметь там скорректированную оценку. Эта структура балансирует централизованное управление с реальными требованиями каждого сервиса. Отдельные пространства имён ID снижают конфликты пользовательских правил.
Обогащённые правила TR7 охватывают современные атаки на API и приложения
Обогащённый уровень TR7 добавляет современные семейства атак поверх классических веб-сигнатур. Манипуляции JWT, вложенные DoS в GraphQL, инъекция запросов NoSQL, инъекция prompt, паттерны цепочки поставок и атаки на поверхность контейнеров и serverless адресуются как выделенные группы правил. Этот уровень нацелен на современные архитектуры API и платформ — а не только на устаревшие веб-формы. Защита WAAP более точно согласована с тем, как строятся современные приложения.
CVE-ориентированные сигнатуры быстро реагируют на новые варианты атак
TR7 может включать выделенные сигнатуры вариантов для CVE-ориентированных атак, таких как Log4Shell, Spring4Shell и Shellshock. Закодированные, обфусцированные или синтаксически изменённые формы перехватываются отдельными паттернами. При публикации CVE добавление пользовательского правила и горячая перезагрузка сокращают время реагирования. Эта операционная скорость критически важна как первая линия защиты после раскрытия нулевого дня.
Полезная нагрузка WAAP для каждого запроса делает сработавшие правила видимыми
Для каждого запроса TR7 может нести ID сработавших правил, оценку и соответствующую информацию о части внутри полезной нагрузки WAAP. Эти данные помогают исследователям инцидентов понять, какое правило сработало и почему. Оператор видит не просто результат «заблокировано», но и полную цепочку оценок, приведшую к блокировке. Эта видимость важна для анализа ложноположительных результатов.
Форматы логов CEF и JSON упрощают интеграцию с SIEM
События WAAP могут логироваться в форматах CEF и JSON. Поля ID правила, категории атаки, оценки, области и метаданных доступны для стороны SIEM. Команды безопасности могут подключать события WAAP к центральным системам оповещения, корреляции и отчётности. Формат лога поддерживает процессы соответствия и реагирования на инциденты.
Маппинг CWE, CAPEC, MITRE и OWASP усиливает аудиторский язык
Правила могут перекрёстно ссылаться на стандарты безопасности и таксономии атак. Ссылки CWE, CAPEC, MITRE ATT&CK и OWASP Web/API Top 10 связывают техническое событие WAAP с языком аудита и риска. Это позволяет командам SOC, безопасности приложений и соответствия обсуждать одно событие в общей системе координат. Отчётность не ограничивается необработанным ID сигнатуры.
Горячая перезагрузка развёртывает изменённые правила без прерывания сервиса
TR7 может перезагружать только изменённые части движка WAAP, не перезапуская весь стек при обновлении правил. Это делает добавление новых сигнатур или обновление пользовательских правил более быстрым и менее разрушительным. Обновлённые наборы правил могут быть введены в действие без перезапуска контейнера. Эта операционная скорость является решающей при аварийном реагировании на CVE.
Операционная глубина
Движок WAAP-сигнатур эксплуатируется совместно с режимами компиляции, распределением оценок, плотностью областей, пространствами имён ID пользовательских правил, статистикой RRD и поведением горячей перезагрузки.
Режимы компиляции
Компиляция правил может работать в режимах all, poly или mono shard. В подходе сегментированного mono правила разбиваются на разделы, которые могут компилироваться параллельно. Эта модель помогает сократить время компиляции и влияние обновлений для больших наборов правил.
Ограничение ёмкости правил
Фабрика правил TR7 WAAP работает с моделью, нацеленной на максимальную ёмкость в 10 000 правил. Этот потолок обеспечивает запас расширения для production-правил, обогащённого уровня и пользовательских правил клиентов. Операторам следует отслеживать баланс производительности и покрытия по мере роста набора правил.
Распределение оценок
Правила производят разные оценки в соответствии со своим весом. Оценки 2 и 4 представляют результаты с более слабым сигналом; 6 и 8 несут более сильные сигналы риска. Отдельные критические правила могут трактоваться с более высокой срочностью. Пороговое решение формируется совокупным эффектом этих накопленных оценок.
Распределение областей
Правила работают с разной плотностью в полях path, query, header, form, JSON, XML и raw. Поля query и form несут более высокие концентрации для классических поверхностей атак, тогда как поля JSON и raw приобретают важность для современного API-трафика. Распределение областей помогает командам понять, какие поверхности трафика генерируют наибольший сигнал защиты.
Пространства имён ID пользовательских правил
Глобальные пользовательские правила и правила пула генерируются в отдельных диапазонах ID. Глобальное пространство имён несёт общие правила всей организации; пространство имён пула несёт правила, специфические для сервиса или клиента. Это разделение снижает конфликты правил и упрощает аудит поведения переопределений.
Статистика категорий
Счётчики срабатываний правил могут агрегироваться по категориям и отображаться на графиках. Это позволяет видеть, какие семейства атак встречаются чаще всего, какие сервисы производят наибольший сигнал риска и как изменения политик влияют на распределение со временем. Статистика превращает WAAP из чистого блокировщика в обучаемый датчик безопасности.
Когда это использовать
Расширение защиты финансового API с помощью современных правил атак
Команды финансовых API могут расширить классическое покрытие, согласованное с OWASP, правилами атак JWT, GraphQL, NoSQL и современных API. Обогащённый уровень TR7 предоставляет область сигнатур, более точно соответствующую текущей API-поверхности.
Управление низкими показателями ложноположительных результатов в банковских приложениях
Банковские команды могут сначала наблюдать за конкретными правилами в режиме мониторинга, а затем настраивать пороговые значения сервиса на уровне пула. Это позволяет установить более контролируемый баланс между агрессивным применением безопасности и легитимным пользовательским трафиком.
Добавление пользовательских правил обнаружения PII на государственном портале
Государственные порталы могут добавлять пользовательские правила regex с областью, ограниченной полями form и JSON. При появлении паттернов конфиденциальных данных или неожиданных входных данных оценка и запись в лог инициируют рабочий процесс расследования.
Разделение глобальных и специфических для клиента политик в мультитенантных сервисах
Команды SaaS могут применять глобальные базовые правила ко всем тенантам, определяя пользовательские переопределения для конкретных клиентов или пулов. Отдельные пространства имён ID гарантируют, что специфические для клиента правила никогда не конфликтуют с общим набором правил.
Часто задаваемые вопросы
Как работает модель на основе оценок?
Для чего используется режим мониторинга?
В чём разница между глобальным переопределением и переопределением пула?
Что добавляет обогащённый уровень TR7?
Как новая CVE адресуется в наборе правил?
Как события WAAP передаются в SIEM?
Управляйте решениями WAAP с помощью оценки и контекста
Более 3 000 production-правил, 32 категории атак и модель принятия решений на основе оценок. Давайте пройдём, как это работает в вашей собственной среде.