Перейти к содержанию

Оценка риска (Risk Score)

AppSec.AIGate присваивает каждому запросу и ответу единую взвешенную оценку риска в диапазоне 0.000–1.000, а также классификацию по уровню серьёзности и разбивку по сигналам. Это позволяет оценивать угрозы по единой шкале независимо от того, какой именно детектор сработал.

Информационный характер

Оценка риска не влияет на решение о блокировке, маскировании или пропуске запроса. Это решение по-прежнему принимается на основе настроек детекторов, их порогов и приоритетов в политике. Risk Score — это наблюдаемая метрика для дашбордов, SIEM-интеграции, отчётности и WAF-сценариев.

Что вы получаете

Для каждого запроса и каждого ответа AppSec.AIGate рассчитывает три связанных значения:

Поле Тип Описание
risk_score число 0.000–1.000 Взвешенная сумма по сигналам безопасности, округлено до трёх знаков
risk_severity строка CRITICAL / HIGH / MEDIUM / LOW — порог-классификация
risk_breakdown объект Нормализованный вклад каждого сигнала — позволяет понять, почему оценка такая

Эти значения доступны:

  • в HTTP-заголовках ответа (см. HTTP-заголовки);
  • в записях событий безопасности (фильтрация в UI и API: ?min_risk_score=…, ?risk_severity=…);
  • в экспорте в SIEM (CEF / Syslog / Webhook / Kafka — см. Интеграция с WAF и SIEM);
  • в карточке события в Admin UI (оценка, бейдж серьёзности, вклад сигналов).

Формула расчёта (v1)

Оценка вычисляется детерминированно по формуле:

risk_score = Σ ( вес[сигнал] × нормализованное_значение[сигнал] )

Запросы (Input): пять сигналов

Сигнал Вес по умолчанию Что измеряет
Threat Detector 0.45 Уверенность модели в jailbreak / prompt injection
Content Safety 0.25 Категории недопустимого контента (насилие, оружие, экстремизм и т. д.)
PII 0.15 Средняя уверенность по найденным ПДн
Custom Policy 0.10 Сумма severity сработавших правил blocklist (с ограничением сверху)
Obfuscation 0.05 Степень обнаруженной обфускации (homoglyph, Unicode)
Сумма 1.00

Ответы (Response): два сигнала

Сигнал Вес по умолчанию Что измеряет
PII 0.60 ПДн в ответе LLM
Content Safety 0.40 Категории недопустимого контента в ответе

Классификация серьёзности

Пороги по умолчанию:

Уровень Условие
CRITICAL risk_score ≥ 0.80
HIGH risk_score ≥ 0.60
MEDIUM risk_score ≥ 0.40
LOW risk_score < 0.40

Поле risk_severity отличается от поля severity

Существующее поле severity события (LOW/MEDIUM/HIGH/CRITICAL) описывает тип события (например, REQUEST_BLOCKED всегда HIGH). Поле risk_severity — это порог-классификация числового risk_score. Они независимы и могут не совпадать.

Примеры расчёта (веса по умолчанию)

Сценарий Сигналы risk_score risk_severity
Чистый запрос — 0.000 LOW
Один jailbreak (уверенность 0.95) Threat = 0.95 0.427 MEDIUM
Jailbreak + опасный контент Threat = 0.95, CS = 0.95 0.665 HIGH
Несколько сильных сигналов Threat + CS + PII + Policy 0.838 CRITICAL

Настройка для профиля

Каждый профиль безопасности может переопределить веса и пороги. В Admin UI: откройте профиль на редактирование → вкладка Поведение при сбоях и риск → раскройте блок Дополнительно: риск-скоринг веса детекторов + пороги severity (информационно) (раздел Конфигурация риска).

Правила валидации:

  • Сумма весов всех сигналов должна равняться 1.0 (допуск ±0.001).
  • Пороги обязаны удовлетворять условию: medium < high < critical.
  • Все веса — неотрицательные значения в диапазоне [0.0, 1.0].

Новые профили создаются с рекомендуемыми значениями. Существующие профили без явной конфигурации используют те же значения по умолчанию.

Когда менять веса

  • Поднять Threat Detector (с 0.45 до 0.55), если вы прежде всего защищаетесь от инъекций и jailbreak.
  • Поднять PII (с 0.15 до 0.30), если основное требование — соответствие 152-ФЗ и защита ПДн.
  • Снизить Obfuscation до 0, если функция нормализации Unicode не используется.

Режим мониторинга и поле would_block

Если профиль работает в режиме мониторинга, все детекторы выполняются и события записываются, но запрос не блокируется — он проксируется к LLM без изменений. При этом в записи решения и события сохраняются:

  • would_block: true — запрос был бы заблокирован при включённом enforcement;
  • would_action — какое именно действие применилось бы (BLOCK, SANITIZE и т. д.).

Это позволяет оценить, как система поведёт себя в продуктивном режиме, до фактического перевода профиля в enforce. Соответствующие HTTP-заголовки (X-LLMFW-Would-Block, X-LLMFW-Would-Action) выставляются только в режиме мониторинга.

Обратная совместимость

  • Оценка риска никогда не меняет логику enforcement — поведение существующих профилей сохраняется.
  • События, созданные до внедрения Risk Score, не содержат соответствующих полей; UI отображает «данные недоступны».
  • Прежнее значение combined_risk (рассчитанное по принципу максимума) сохранено внутри решения в карте scores — для совместимости со старыми отчётами.

Дополнительная информация