274 lines
22 KiB
Markdown
274 lines
22 KiB
Markdown
# 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)
|