# Customer Pilot Pack: AWatch-rus

Документ для предварительного обсуждения пилота с заказчиком.

Публичное имя: `AWatch-rus`.

Техническая база и репозиторий: `AWatch-rus`.

Статус: материал для коммерческого пилота. Документ не является договором,
техническим заданием, моделью угроз ФСТЭК или заявлением о сертификации
средства защиты информации.

## 1. Что такое AWatch-rus

AWatch-rus - программный комплекс для операционного контроля,
технического аудита и управленческой аналитики активности рабочих мест.

Главная идея продукта:

```text
Телеметрия -> Активность -> Риск -> Проверка -> Отчет
```

Система помогает руководителю, ИБ и ИТ видеть:

- какие подразделения работают стабильно;
- где падает активность;
- где не хватает достоверных данных;
- какие рабочие места перестали присылать телеметрию;
- какие события требуют проверки;
- какие материалы можно приложить к внутреннему разбору.

AWatch-rus не позиционируется как сертифицированная DLP, SIEM, EDR/XDR или СЗИ.
Корректное позиционирование: Workforce-first платформа операционного контроля,
технического аудита, мониторинга пользовательской активности и поддержки
внутренних расследований.

## 2. Какие задачи решает

Для собственника и директора:

- показывает общий пульс организации на одной странице;
- помогает увидеть перегруз, недогруз и просадку подразделений;
- показывает, можно ли доверять текущему индексу активности;
- выделяет зоны организационного риска без просмотра технических логов.

Для руководителя подразделения:

- показывает индекс активности подразделения;
- сравнивает подразделения и ответственных;
- объясняет причины риска: слабое покрытие агентов, падение активности,
  устаревшая телеметрия, проблемные рабочие места;
- помогает понять, что нужно проверить в первую очередь.

Для ИБ:

- показывает DLP-lite/ИБ-сигналы, если они включены в пилоте;
- формирует кандидатов в инциденты для ручной проверки;
- сохраняет историю проверки кандидата: кто изменил статус, когда и почему;
- позволяет выгрузить investigation pack по кандидату.

Для ИТ:

- контролирует свежесть телеметрии;
- показывает качество данных агента;
- показывает покрытие рабочих мест агентами;
- помогает быстрее находить узлы, которые портят достоверность KPI.

## 3. Сценарий демонстрации на 10 минут

Цель демонстрации: показать не набор логов, а управленческую картину:
что происходит, почему это риск и какие данные это подтверждают.

| Время | Экран | Что показать |
|---|---|---|
| 0:00-1:00 | Обзор | `Связанная картина риска`: главный вывод, статус, подтверждающие слои. |
| 1:00-2:00 | Сводка руководителя | Trust KPI, покрытие агентов, подразделения высокого риска, кандидаты, открытые дела. |
| 2:00-3:00 | Достоверность данных | Почему текущему KPI можно или нельзя доверять; `local_fallback` не засчитывается в KPI. |
| 3:00-4:00 | Подразделения | ТОП-5 сильных и проблемных подразделений, ответственные, отклонения. |
| 4:00-5:30 | Карта рисков | Heatmap: где слабый Trust KPI, плохое покрытие, высокий Business Risk, открытые дела. |
| 5:30-6:30 | Корреляция Workforce и Security | Связь между падением активности, качеством данных и кандидатами в инциденты. |
| 6:30-8:00 | Кандидаты в инциденты | Очередь проверок, причина, evidence-признаки, рекомендация. Без автоматического обвинения. |
| 8:00-9:00 | Investigation Pack / Case | Выгрузка пакета расследования и ручное создание дела только после подтверждения. |
| 9:00-10:00 | Отчет | Markdown/PDF/JSON-отчет и критерии успешного пилота. |

Демонстрацию лучше проводить на подготовленном пилотном наборе данных:
несколько рабочих мест с нормальной телеметрией, один узел без свежих данных,
один пример кандидата в инциденты и один закрытый или тестовый case.

## 4. Требования к пилотному стенду

Минимальный управляемый пилот:

- отдельная VM или сервер для AWatch-rus;
- закрытый доступ к порталу через VPN, reverse proxy или иной auth gateway;
- согласованный список пилотных рабочих мест;
- установленный агент или совместимый сборщик на выбранных рабочих местах;
- согласованный перечень собираемых данных;
- согласованный retention для телеметрии, отчетов, evidence и audit-журналов;
- ответственные со стороны заказчика: бизнес-владелец, ИТ, ИБ и представитель
  пилотного подразделения.

Рекомендуемый scope первого пилота:

- 1-3 подразделения;
- 10-50 рабочих мест;
- 2 недели наблюдения;
- 1-2 согласованных сценария DLP-lite/ИБ-проверки, если они нужны заказчику;
- без автоматического сетевого enforcement и без блокировок пользователей.

Обязательные условия:

- портал не публикуется наружу без аутентификации;
- список ожидаемых рабочих мест фиксируется до старта пилота;
- сотрудники и руководители уведомляются по правилам заказчика;
- заказчик заранее утверждает, какие данные можно использовать в отчетах;
- live-данные заказчика не попадают в публичный репозиторий, демо-материалы или
  release artifacts.

## 5. Какие данные собираются

Фактический состав зависит от включенных модулей пилота. Базовый состав:

| Категория | Примеры | Для чего используется |
|---|---|---|
| Активность рабочего места | активное/неактивное время, приложения, окна, интервалы активности | Индекс активности, тренды, загрузка подразделений. |
| Сессии | local/RDP-сессии, active/disconnected, источник данных агента | Worktime, RDP-контроль, доверие к KPI. |
| Качество данных агента | `wts_api`, fallback-источники, `collector_error`, количество сессий | Понимание, можно ли использовать KPI как доказательную базу. |
| Покрытие агентов | ожидаемые узлы, свежие узлы, stale/missing nodes | Репрезентативность отчета по парку рабочих мест. |
| Сервисная готовность | состояние сервисов, readiness, свежесть источников | Эксплуатационная проверка стенда. |
| DLP-lite/ИБ-сигналы | USB, печать, буфер обмена, файловые и браузерные признаки, если включены | Очередь кандидатов в инциденты и ручная проверка. |
| Evidence metadata | идентификатор, время, хеш, тип доказательства, ссылка на просмотр | Поддержка внутреннего расследования. |
| Audit workflow | статус проверки кандидата, проверяющий, комментарий, время изменения | Доказательная цепочка принятия решения. |

Индекс активности является proxy-метрикой. Он показывает расчетную активность
по доступной телеметрии и настройкам ролей/весов приложений. Это не юридическая
оценка эффективности сотрудника и не автоматическое дисциплинарное решение.

## 6. Что НЕ собирается

В стандартном пилотном профиле система не собирает:

- ввод с клавиатуры;
- пароли;
- содержимое документов;
- содержимое переписки;
- непрерывную запись экрана;
- скрытый контроль через kernel driver;
- аудиозапись с микрофона;
- видео с камеры;
- перехват содержимого файлов как обязательный механизм;
- автоматические блокировки пользователей;
- автоматическое создание инцидентов без ручной проверки.

Evidence, включая скриншоты или артефакты, используется только если этот
сценарий отдельно включен и согласован с заказчиком. Даже в этом случае портал
работает через opaque ID и не должен отдавать сырые пути файловой системы.

pfSense или иной сетевой периметр в базовом пилоте рассматривается как
read-only интеграционный контекст. Enforcement, quarantine, блокировка VLAN или
изменение firewall policy не входят в стандартный пилот без отдельного
письменного решения.

## 7. Критерии успешного пилота

Пилот считается успешным, если за согласованный период выполнены условия:

| Критерий | Минимальный результат |
|---|---|
| Доступность портала | Целевые роли заказчика заходят в портал через согласованный auth gateway. |
| Покрытие агентов | Не менее 80% пилотных рабочих мест присылают свежую телеметрию; отклонения разобраны. |
| Достоверность KPI | Портал показывает Trust KPI и объясняет, какие данные приняты в KPI, а какие нет. |
| Управленческий отчет | Сформирован хотя бы один отчет для руководителя за день или неделю. |
| Подразделения | Видны подразделения, ответственные, индекс активности, отклонения и причины риска. |
| Кандидаты в инциденты | Минимум один тестовый или реальный кандидат проходит ручную проверку. |
| Audit trail | Смена статуса кандидата фиксируется с проверяющим, временем и комментарием. |
| Investigation pack | По кандидату можно выгрузить пакет расследования в JSON/Markdown. |
| Readiness | Состояние стенда фиксируется readiness-проверкой; `WARN` имеют план устранения. |
| Ограничения понятны | Заказчик подтверждает, что KPI является управленческой proxy-метрикой. |

Допустимый итог пилота: `принят`, `принят с замечаниями`, `требует доработки`.

## 8. Риски и ограничения

| Риск | Что это значит | Как снижается |
|---|---|---|
| Неверная трактовка KPI | Индекс активности могут принять за абсолютную оценку трудоотдачи. | В отчете явно указать proxy-характер метрики и согласовать веса приложений по ролям. |
| Низкое покрытие агентов | Отчет не отражает весь пилотный парк. | До старта заполнить expected nodes и ежедневно смотреть coverage SLA. |
| Некачественная телеметрия | Fallback-источники могут снижать точность RDP/worktime. | Использовать блок `Достоверность данных агента`; `local_fallback` не принимать в KPI. |
| Нет auth gateway | Портал может раскрыть чувствительные агрегаты. | Портал открывать только через VPN/reverse proxy/auth gateway. |
| Спорные DLP-lite события | Событие может быть рабочим процессом, а не нарушением. | Не создавать инциденты автоматически; использовать статус проверки и комментарии. |
| Evidence/privacy | Скриншоты и артефакты могут быть чувствительными. | Включать evidence только по согласованному регламенту, с retention и ограничением доступа. |
| Рост state-файлов | JSON/JSONL state в пилоте требует контроля размера. | Настроить backup, retention и периодическую проверку объема данных. |
| Периметр сети | Сетевые блокировки могут повлиять на бизнес-процессы. | В базовом пилоте только read-only сетевой контекст, без enforcement. |

## 9. План внедрения на 2 недели

### Неделя 1: запуск и первичная проверка

| День | Работы | Результат |
|---|---|---|
| День 1 | Согласовать scope, роли, список рабочих мест, данные и ограничения. | Утвержден пилотный контур и ответственные. |
| День 2 | Подготовить VM/server, доступ, auth gateway, backup path. | Есть закрытый стенд для установки. |
| День 3 | Развернуть серверные компоненты, портал, readiness checks. | Портал открывается, readiness дает первый статус. |
| День 4 | Установить агенты на первую группу рабочих мест. | Появилась telemetry, проверен agent quality. |
| День 5 | Заполнить expected nodes, проверить coverage SLA и первые отчеты. | Видно покрытие агентов и первичный Trust KPI. |

### Неделя 2: эксплуатационная проверка и приемка

| День | Работы | Результат |
|---|---|---|
| День 6-7 | Наблюдать рабочий цикл, проверить подразделения и тренды. | Руководитель видит рабочую картину по пилоту. |
| День 8 | Провести согласованный DLP-lite/ИБ test scenario, если он входит в scope. | Есть кандидат в инциденты и evidence-признаки. |
| День 9 | Пройти review workflow: `NEW -> IN_REVIEW -> CONFIRMED/FALSE_POSITIVE/POSTPONED`. | Есть audit trail решения. |
| День 10 | Выгрузить investigation pack и управленческий отчет. | Есть материалы для руководителя и ИБ. |
| День 11 | Разобрать замечания по данным, агентам, доступам и отчетам. | Список доработок или подтверждение пригодности. |
| День 12-13 | Провести повторную проверку после корректировок. | KPI, coverage и reports стабильны. |
| День 14 | Заполнить итоговую форму приемки. | Решение: принять, принять с замечаниями или доработать. |

## 10. Итоговая форма приемки пилота

| Поле | Значение |
|---|---|
| Заказчик | `<CUSTOMER_LEGAL_NAME>` |
| Исполнитель / правообладатель | `<RIGHT_HOLDER_LEGAL_NAME>` |
| Проект | AWatch-rus, программный продукт |
| Период пилота | `<PILOT_START_DATE>` - `<PILOT_END_DATE>` |
| Пилотный контур | `<PILOT_CONTOUR_NAME>` |
| Количество рабочих мест в scope | `<NODES_COUNT>` |
| Подразделения в scope | `<DEPARTMENTS>` |

| Проверка | Результат | Комментарий |
|---|---|---|
| Портал доступен целевым ролям | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Auth gateway / VPN / TLS согласованы | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Агентское покрытие достаточно для отчета | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Trust KPI отображается и понятен заказчику | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Подразделения и ответственные отображаются корректно | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Risk Narrative дает понятный главный вывод | `<OK/WARN/FAIL>` | `<COMMENT>` |
| DLP-lite/ИБ-сценарий пройден, если входил в scope | `<OK/WARN/FAIL/N/A>` | `<COMMENT>` |
| Investigation pack выгружается | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Audit trail проверки кандидата есть | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Readiness check не содержит нерешенных `FAIL` | `<OK/WARN/FAIL>` | `<COMMENT>` |
| Retention и доступ к данным согласованы | `<OK/WARN/FAIL>` | `<COMMENT>` |

Итоговое решение:

| Решение | Отметка |
|---|---|
| Пилот принят без замечаний | `<YES/NO>` |
| Пилот принят с замечаниями | `<YES/NO>` |
| Требуется доработка и повторная проверка | `<YES/NO>` |
| Рекомендуется коммерческое внедрение | `<YES/NO>` |

Подписи:

| Сторона | ФИО / должность | Подпись | Дата |
|---|---|---|---|
| Заказчик | `<CUSTOMER_SIGNER>` |  |  |
| Исполнитель | `<CONTRACTOR_SIGNER>` |  |  |

## Связанные документы

- [Описание продукта](../PRODUCT_DESCRIPTION_RU.md)
- [Аудит готовности к пилоту](PILOT_READINESS_AUDIT_RU.md)
- [Чек-лист пилотного внедрения](PILOT_DEPLOYMENT_CHECKLIST_RU.md)
- [Акт приемки пилота](CUSTOMER_PILOT_ACCEPTANCE_RU.md)
- [Портал AWatch-rus](PORTAL_RU.md)
- [Business Risk](BUSINESS_RISK_RU.md)
- [Модель безопасности](SECURITY_MODEL_RU.md)
- [Архитектура](ARCHITECTURE_RU.md)
- [Развертывание агента](AGENT_DEPLOYMENT_RU.md)
- [Windows Rust Agent Worktime/RDP](WINDOWS_RUST_AGENT_WORKTIME_RU.md)