diff --git a/CUSTOMER_PILOT_PACK_RU.md b/CUSTOMER_PILOT_PACK_RU.md new file mode 100644 index 0000000..e146010 --- /dev/null +++ b/CUSTOMER_PILOT_PACK_RU.md @@ -0,0 +1,273 @@ +# Customer Pilot Pack: AWatch-rus / DetMir + +Документ для предварительного обсуждения пилота с заказчиком. + +Продуктовое имя: `DetMir`. + +Техническая база и репозиторий: `AWatch-rus`. + +Статус: материал для коммерческого пилота. Документ не является договором, +техническим заданием, моделью угроз ФСТЭК или заявлением о сертификации +средства защиты информации. + +## 1. Что такое AWatch-rus / DetMir + +AWatch-rus / DetMir - программный комплекс для операционного контроля, +технического аудита и управленческой аналитики активности рабочих мест. + +Главная идея продукта: + +```text +Телеметрия -> Активность -> Риск -> Проверка -> Отчет +``` + +Система помогает руководителю, ИБ и ИТ видеть: + +- какие подразделения работают стабильно; +- где падает активность; +- где не хватает достоверных данных; +- какие рабочие места перестали присылать телеметрию; +- какие события требуют проверки; +- какие материалы можно приложить к внутреннему разбору. + +DetMir не позиционируется как сертифицированная 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 / DetMir; +- закрытый доступ к порталу через 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. Итоговая форма приемки пилота + +| Поле | Значение | +|---|---| +| Заказчик | `` | +| Исполнитель / правообладатель | `` | +| Проект | DetMir, программный комплекс AWatch-rus | +| Период пилота | `` - `` | +| Пилотный контур | `` | +| Количество рабочих мест в scope | `` | +| Подразделения в scope | `` | + +| Проверка | Результат | Комментарий | +|---|---|---| +| Портал доступен целевым ролям | `` | `` | +| Auth gateway / VPN / TLS согласованы | `` | `` | +| Агентское покрытие достаточно для отчета | `` | `` | +| Trust KPI отображается и понятен заказчику | `` | `` | +| Подразделения и ответственные отображаются корректно | `` | `` | +| Risk Narrative дает понятный главный вывод | `` | `` | +| DLP-lite/ИБ-сценарий пройден, если входил в scope | `` | `` | +| Investigation pack выгружается | `` | `` | +| Audit trail проверки кандидата есть | `` | `` | +| Readiness check не содержит нерешенных `FAIL` | `` | `` | +| Retention и доступ к данным согласованы | `` | `` | + +Итоговое решение: + +| Решение | Отметка | +|---|---| +| Пилот принят без замечаний | `` | +| Пилот принят с замечаниями | `` | +| Требуется доработка и повторная проверка | `` | +| Рекомендуется коммерческое внедрение | `` | + +Подписи: + +| Сторона | ФИО / должность | Подпись | Дата | +|---|---|---|---| +| Заказчик | `` | | | +| Исполнитель | `` | | | + +## Связанные документы + +- [Описание продукта](PRODUCT_DESCRIPTION_RU.md) +- [Аудит готовности к пилоту](PILOT_READINESS_AUDIT_RU.md) +- [Чек-лист пилотного внедрения](docs/PILOT_DEPLOYMENT_CHECKLIST_RU.md) +- [Акт приемки пилота](docs/CUSTOMER_PILOT_ACCEPTANCE_RU.md) +- [Портал AWatch-rus](docs/PORTAL_RU.md) +- [Business Risk](docs/BUSINESS_RISK_RU.md) +- [Модель безопасности](docs/SECURITY_MODEL_RU.md) +- [Архитектура](docs/ARCHITECTURE_RU.md) +- [Развертывание агента](docs/AGENT_DEPLOYMENT_RU.md) +- [Windows Rust Agent Worktime/RDP](docs/WINDOWS_RUST_AGENT_WORKTIME_RU.md)