docs: review ueba critical evidence

2026-06-07 22:13:43 +03:00
parent 32e1a97877
commit f2b966d5d4
4 changed files with 417 additions and 20 deletions
@@ -2,11 +2,12 @@

 Дата проверки: 2026-06-07.

-Статус после TASK_014: рабочий внутренний pilot-контур приведен к Demo Freeze
+Статус после TASK_015: рабочий внутренний pilot-контур приведен к Demo Freeze
 v1 по portal runtime, production-hardening endpoints и основным live smoke.
-Контур собирает и показывает реальные данные; расширение пилота допустимо
-только контролируемо, после ручной проверки UEBA evidence и назначения
-операционного ownership.
+UEBA `critical` разобран в `docs/UEBA_CRITICAL_REVIEW_RU.md` и
+классифицирован как `Needs Investigation`. Расширение пилота допустимо только
+контролируемо, после проверки agent coverage и назначения операционного
+ownership.

 ## Executive Summary

@@ -37,8 +38,8 @@ v1 по portal runtime, production-hardening endpoints и основным live
 - Executive visual conformance не проходит по текущему freeze smoke: в рабочем
  runtime не отображаются новые Pilot v1 блоки Risk Narrative / Explainable KPI
  / Recommended Actions;
- UEBA на live-контуре возвращает `critical` score; нужна ручная проверка
-  evidence, чтобы отличить реальный риск от шумного правила.
+- UEBA на live-контуре возвращает `critical` score; TASK_015 классифицировал
+  его как `Needs Investigation`, а не как подтвержденный инцидент ИБ.

 TASK_014 remediation update:

@@ -53,8 +54,8 @@ TASK_014 remediation update:

 Вывод: контур можно использовать для контролируемого внутреннего pilot review и
 подготовки ограниченного пилота. Перед расширением на 10-50 пользователей
-остается вручную разобрать UEBA `critical` evidence и закрепить порядок
-операционной поддержки.
+остается проверить agent coverage, уточнить missing application data и
+закрепить порядок операционной поддержки.

 ## Scope

@@ -202,13 +203,16 @@ Live endpoint:
 - reason codes: несколько;
 - score components: несколько.

-Оценка:
+Оценка после TASK_015:

 - UEBA endpoint работает;
- score `critical` требует ручной проверки evidence;
- без ручной проверки нельзя считать это подтвержденным нарушением;
- высокий score может быть как реальным риском, так и шумом от неполного
-  покрытия/устаревших источников/политики baseline.
+- score `critical` является фактическим rule-based результатом текущих
+  сигналов;
+- классификация: `Needs Investigation`;
+- security interpretation: `Operational Risk confirmed; Security Risk unknown`;
+- executive readiness: `Insufficient Confidence`;
+- основной вклад дают Workforce/baseline/history signals, а не DLP, network,
+  time или application anomaly.

 ## Risk Narrative Validation

@@ -302,8 +306,9 @@ Backlog/dead-letter:

 Потенциальный шум:

- UEBA severity `critical` / score `100` без ручной валидации evidence может
-  выглядеть завышенным;
+- UEBA severity `critical` / score `100` после TASK_015 классифицирован как
+  `Needs Investigation`: высокий score выглядит операционно значимым, но не
+  доказывает ИБ-инцидент;
 - stale исторические buckets могут искажать общее восприятие freshness, если не
  разделять active, inactive и event-driven bucket types;
 - live Executive headline/runtime naming все еще может содержать старую
@@ -344,7 +349,8 @@ Backlog/dead-letter:

 Критично перед расширением пилота:

-1. Провести ручной разбор UEBA `critical` с evidence, не меняя правила вслепую.
+1. Проверить agent coverage и missing application data, которые могли усилить
+   UEBA `critical`.
 2. Назначить операционного владельца live smoke, deploy parity и rollback.
 3. Зафиксировать регламент: после каждого deploy проверять binary/version,
   endpoint matrix и live smoke.
@@ -403,6 +409,6 @@ Executive Action Center и основным smoke-проверкам. Текущ

 ```text
 ready for controlled internal pilot review;
-ready for limited pilot preparation after manual UEBA evidence review and
-operations ownership assignment.
+ready for limited pilot preparation after agent coverage review and operations
+ownership assignment.
 ```
@@ -36,8 +36,12 @@ headline, KPI label и CLI help используют публичное назв
  действий.
 - TASK_013 live validation выявил deployment/version drift, но TASK_014 закрыл
  его controlled deploy актуального portal binary и повторным live smoke.
- Перед расширением пилота остается ручной разбор UEBA evidence и закрепление
-  операционного ownership за deploy parity, rollback и регулярными smoke.
+- TASK_015 выполнил ручной разбор UEBA `critical`: классификация
+  `Needs Investigation`, security interpretation - `Operational Risk confirmed;
+  Security Risk unknown`.
+- Перед расширением пилота остается проверить agent coverage/missing application
+  data и закрепить операционный ownership за deploy parity, rollback и
+  регулярными smoke.

 ## Overall Status

@@ -0,0 +1,349 @@
+# 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
+```
@@ -265,3 +265,41 @@ git diff --check
 персональные данные не попали в git;
 алгоритм UEBA не изменен;
 все проверки проходят.
+
+## Выполнение
+
+Дата выполнения: 2026-06-07.
+
+Статус: выполнено.
+
+Создан документ:
+
+```text
+docs/UEBA_CRITICAL_REVIEW_RU.md
+```
+
+Итоговая классификация:
+
+```text
+Needs Investigation
+```
+
+Краткий вывод:
+
+* UEBA `critical` подтвержден как фактический rule-based результат текущих
+  входных сигналов.
+* `critical` не подтвержден как доказанный инцидент ИБ.
+* Главный вклад дают Workforce signals и baseline/history, а не DLP, network,
+  time или application anomaly.
+* Нулевое agent coverage и low KPI confidence не позволяют безопасно трактовать
+  текущий score как true positive.
+* Алгоритм, weights, thresholds, Risk Narrative и Action Center не менялись.
+* Реальные пользователи, hostname, IP, логины, подразделения, события и
+  forensic payload в Git не добавлялись.
+
+Статусы:
+
+```text
+Executive readiness: Insufficient Confidence
+Security interpretation: Operational Risk confirmed; Security Risk unknown
+```