CUSTOMER_PILOT_PACK_RU.md

Customer Pilot Pack: AWatch-rus

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

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

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

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

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

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

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

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

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

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

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>

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

• Описание продукта
• Аудит готовности к пилоту
• Чек-лист пилотного внедрения
• Акт приемки пилота
• Портал AWatch-rus
• Business Risk
• Модель безопасности
• Архитектура
• Развертывание агента
• Windows Rust Agent Worktime/RDP