diff --git a/docs/DETMIR_PRODUCTION_VALIDATION_RU.md b/docs/DETMIR_PRODUCTION_VALIDATION_RU.md index 3c419d4..9c6e0d1 100644 --- a/docs/DETMIR_PRODUCTION_VALIDATION_RU.md +++ b/docs/DETMIR_PRODUCTION_VALIDATION_RU.md @@ -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. ``` diff --git a/docs/ROADMAP_CONFORMANCE_AUDIT_RU.md b/docs/ROADMAP_CONFORMANCE_AUDIT_RU.md index 2031cd5..6747507 100644 --- a/docs/ROADMAP_CONFORMANCE_AUDIT_RU.md +++ b/docs/ROADMAP_CONFORMANCE_AUDIT_RU.md @@ -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 diff --git a/docs/UEBA_CRITICAL_REVIEW_RU.md b/docs/UEBA_CRITICAL_REVIEW_RU.md new file mode 100644 index 0000000..9d6e3f5 --- /dev/null +++ b/docs/UEBA_CRITICAL_REVIEW_RU.md @@ -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 +``` diff --git a/docs/roadmap/TASK_015_UEBA_CRITICAL_EVIDENCE_REVIEW b/docs/roadmap/TASK_015_UEBA_CRITICAL_EVIDENCE_REVIEW index 0fb9ec1..3ac89b3 100644 --- a/docs/roadmap/TASK_015_UEBA_CRITICAL_EVIDENCE_REVIEW +++ b/docs/roadmap/TASK_015_UEBA_CRITICAL_EVIDENCE_REVIEW @@ -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 +```