# UEBA Critical Evidence Review Дата проверки: 2026-06-07. Статус: выполнен ручной разбор текущего `critical` без изменения алгоритма, весов, thresholds, Risk Narrative и Action Center. ## Executive Summary Текущий UEBA severity `critical` подтвержден как фактический результат rule-based scoring, но не подтвержден как доказанный инцидент ИБ. Классификация: ```text Needs Investigation ``` Причина: score `100/100` складывается в основном из Workforce/coverage сигналов, а не из DLP, network, time или application anomaly: - `activity_anomaly`: `81`; - `history_anomaly`: `19`; - `application_anomaly`: `0`; - `network_anomaly`: `0`; - `time_anomaly`: `0`. Главный вывод: текущий `critical` безопаснее трактовать как высокий операционный риск качества данных и активности, требующий ручной проверки. Показывать его руководителю как подтвержденное нарушение нельзя. ## Scope Проверялось: - live `/portal/api/ueba`; - live `/portal/api/reports` в разных ролях; - live `/portal/api/workforce/kpi/explain`; - live `/portal/api/risk/narrative`; - live `/portal/api/actions`; - агрегированная свежесть ActivityWatch buckets; - состояние portal service и production endpoints; - согласованность UEBA -> Risk Narrative -> Recommended Actions. Не выполнялось: - изменение UEBA score calculation; - изменение severity thresholds; - изменение weights; - отключение правил; - изменение Risk Narrative; - изменение Action Center; - выгрузка сырых событий; - сохранение реальных пользователей, hostname, IP, логинов, подразделений или forensic payload в Git. ## Current Severity Live UEBA summary: | Поле | Значение | | --- | --- | | Score | `100` | | Severity | `critical` | | Status | `FAIL` | | Model | `rule_based` | | ML used | `false` | | LLM used | `false` | | Policy version | `ueba-rule-v1` | | Score cap | `100` | В full report также подтверждено: - `confidence`: `0.8`; - `baseline_status`: `per_user_department_baseline_skeleton`; - `baseline_window_days`: `30`; - `user_baseline_available`: `true`; - `department_baseline_available`: не подтверждено; - baseline samples: `total=40`, `users=19`, `departments=21`. ## Evidence Summary Обезличенная цепочка evidence: | Источник | Статус | Наблюдение | | --- | --- | --- | | DLP counts | доступен | `warn=0`, `fail=0` | | Incident queue | доступен | открытые вопросы есть | | Evidence metadata | доступен | `items=0`, `screenshots=0`; используется только для confidence | | Workforce insights | доступен | `items=9` | | Workforce policy audit | доступен | политика доступна | | UEBA baseline | доступен | baseline samples есть | | UEBA policy | доступен | ошибка policy loading отсутствует | Из этого следует: - текущий `critical` не подкреплен DLP fail/warn; - текущий `critical` не подкреплен screenshot/evidence package; - основной источник риска - Workforce insights и baseline deviation; - security-events агрегат есть, но сам по себе не доказывает инцидент. ## Signal Contributions Raw rule contributions до score cap: | Сигнал | Количество | Вес | Raw contribution | | --- | ---: | ---: | ---: | | `open_incidents` | 1 | `+15` | `+15` | | `workforce_drop` | 8 | `+15` | `+120` | | `workforce_anomaly` | 1 | `+10` | `+10` | | `baseline_deviation` | 1 | `+15` | `+15` | Raw total: ```text 15 + 120 + 10 + 15 = 160 ``` Final score после cap: ```text min(160, 100) = 100 ``` Компоненты после пересчета capped score: | Component | Score | | --- | ---: | | `activity_anomaly` | `81` | | `history_anomaly` | `19` | | `application_anomaly` | `0` | | `network_anomaly` | `0` | | `time_anomaly` | `0` | Важное наблюдение: повторяющиеся `workforce_drop` являются главным драйвером `critical`. Это может быть реальной массовой просадкой активности, но при нулевом agent coverage также может быть следствием деградации источников. ## Coverage Assessment Explainable KPI: | Поле | Значение | | --- | --- | | KPI score | `0` | | Confidence | `low` | | Agent coverage | `0%` | | Data freshness | `fresh` | | Missing sources | `agent_coverage`, `applications` | Agent coverage SLA в admin scope: | Поле | Значение | | --- | ---: | | Expected nodes | `1` | | Reporting nodes 24h | `0` | | Stale nodes | `1` | | Missing nodes | `0` | | Coverage | `0%` | | Freshness | `0%` | | SLA status | `CRITICAL` | ActivityWatch buckets aggregate: | Показатель | Значение | | --- | ---: | | Total buckets | `27` | | Buckets with metadata end | `22` | | Fresh within 15 minutes | `9` | | Fresh within 1 hour | `9` | | Fresh within 24 hours | `11` | | Old or missing metadata | `16` | Оценка покрытия: проблемы покрытия могли искусственно усилить severity. При `agent_coverage=0%`, `confidence=low` и missing `applications` нельзя отделить реальную просадку активности от недостатка данных без ручной проверки. ## Explainability Consistency UEBA, Risk Narrative и Action Center в целом согласованы: - UEBA показывает `critical` из-за Workforce и baseline/history signals; - Risk Narrative показывает `critical` и указывает на низкий KPI, низкое доверие к KPI, низкое покрытие агентов, baseline/security context и кандидатов на проверку; - Action Center рекомендует проверить агентов, назначить владельца действий и проверить подразделение/активность. Найденные ограничения согласованности: 1. `/portal/api/ueba` в standalone response не показывает full explainability поля `confidence`, `baseline_*`, `risk_sources`; они доступны в `/portal/api/reports`. 2. Risk Narrative показывает candidates в executive/admin context, а security role получает другой scope: security correlation есть, но executive candidate list скрыт. Это похоже на role filtering, а не на runtime bug. 3. Risk Narrative включает агрегированные security events, но UEBA components показывают `application_anomaly=0` и `network_anomaly=0`; значит security events не должны трактоваться как доказанная причина `critical`. Противоречий, требующих немедленного изменения алгоритма, не выявлено. ## False Positive Analysis Признаки возможного true positive: - много Workforce signals; - baseline deviation есть; - открытая очередь проверки есть; - Risk Narrative и Action Center согласованно поднимают приоритет. Признаки возможного false positive / data-quality noise: - agent coverage `0%`; - freshness SLA `0%`; - missing sources: `agent_coverage`, `applications`; - KPI confidence `low`; - DLP warn/fail отсутствуют; - evidence screenshots отсутствуют; - network/time/application components равны `0`; - score достигает `critical` за счет повторяющихся однотипных `workforce_drop`. Вывод: текущих данных недостаточно для True Positive. Также недостаточно данных, чтобы назвать это False Positive. Корректная классификация - `Needs Investigation`. ## Security Interpretation Текущий `critical` нельзя считать подтвержденным security incident. Статус для ИБ: ```text Operational Risk: confirmed Security Risk: unknown ``` Что можно утверждать: - есть критичный операционный риск качества данных и интерпретации Workforce KPI; - есть очередь ручной проверки; - есть baseline/workforce отклонения. Что нельзя утверждать: - подтвержденная утечка; - подтвержденный DLP incident; - подтвержденная сетевой атакой anomaly; - подтвержденное нарушение конкретного пользователя или подразделения. ## Executive Interpretation Executive readiness: ```text Insufficient Confidence ``` Текущий `critical` можно показывать руководителю только как пример: ```text Система обнаружила критичный риск, но перед управленческим выводом требуется проверить покрытие агентов и подтвердить первичные данные. ``` Нельзя показывать как: ```text Система доказала нарушение / инцидент / виновника. ``` Для демо руководителю безопасная формулировка: > Главный риск сейчас - не доказанное нарушение, а недостаточная достоверность > данных при множественных сигналах просадки активности. Следующее действие - > проверить покрытие агентов и передать кандидаты на ручной разбор. ## Classification Итоговая классификация: ```text Needs Investigation ``` Не `True Positive`, потому что нет достаточного evidence для подтверждения инцидента: DLP/network/time/application components равны `0`, screenshots/evidence отсутствуют, agent coverage `0%`. Не `False Positive`, потому что Workforce/baseline/open-review signals реально сработали и runtime ошибок portal service не показал. ## Risks 1. Руководитель может воспринять `critical` как доказанный инцидент, если не пояснить низкую confidence/coverage. 2. Нулевое покрытие агентов может искусственно снижать KPI и усиливать workforce_drop signals. 3. Повторяющиеся `workforce_drop` могут доминировать score до cap `100`. 4. Высокий агрегат security events без DLP/network contribution может выглядеть как ИБ-доказательство, хотя это только контекст. 5. Standalone `/api/ueba` менее объясним, чем full report, потому что не возвращает full baseline/confidence metadata. ## Recommendations До расширения пилота: 1. Проверить агент на ожидаемом рабочем месте: почему expected node есть, но reporting nodes за 24 часа `0`. 2. Проверить, почему Explainable KPI видит missing `agent_coverage` и `applications`. 3. Проверить freshness по active worktime/window/application buckets без раскрытия пользователей и hostname. 4. Передать ИБ только обезличенную очередь signals: `open_incidents`, `workforce_drop`, `baseline_deviation`; не заявлять подтвержденный инцидент. 5. На демо использовать wording `требует ручной проверки`, а не `подтверждено нарушение`. 6. Отдельно рассмотреть product recommendation: standalone `/api/ueba` может возвращать больше explainability metadata, уже присутствующей в report. Это recommendation, не изменение в рамках TASK_015. Не делать в TASK_015: - не менять weights; - не менять thresholds; - не подавлять `workforce_drop`; - не снижать score вручную; - не отключать `critical`; - не менять Risk Narrative или Action Center. ## Conclusion UEBA `critical` на live-контуре является корректно рассчитанным rule-based результатом текущих входных сигналов, но не является подтвержденным security incident. Финальный статус: ```text Classification: Needs Investigation Executive readiness: Insufficient Confidence Security interpretation: Operational Risk confirmed; Security Risk unknown Algorithm changes: none Scoring changes: none Sensitive data committed: none ```