From cff6e7c425650c5a2d66bc20af6698b72a05db88 Mon Sep 17 00:00:00 2001 From: igor04091968 Date: Sun, 7 Jun 2026 19:09:41 +0300 Subject: [PATCH] docs: add pilot validation package --- README.md | 13 ++ docs/COMPETITIVE_POSITIONING_RU.md | 57 +++++ docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md | 62 +++++ docs/PILOT_GAP_ANALYSIS_RU.md | 195 +++++----------- docs/PILOT_SUCCESS_CRITERIA_RU.md | 58 +++++ docs/PILOT_VALIDATION_CHECKLIST_RU.md | 75 ++++++ docs/roadmap/TASK_010_PILOT_VALIDATION.md | 59 ++++- scripts/pilot-validation-smoke.mjs | 270 ++++++++++++++++++++++ 8 files changed, 655 insertions(+), 134 deletions(-) create mode 100644 docs/COMPETITIVE_POSITIONING_RU.md create mode 100644 docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md create mode 100644 docs/PILOT_SUCCESS_CRITERIA_RU.md create mode 100644 docs/PILOT_VALIDATION_CHECKLIST_RU.md create mode 100644 scripts/pilot-validation-smoke.mjs diff --git a/README.md b/README.md index ac59381..ec6bc44 100755 --- a/README.md +++ b/README.md @@ -91,6 +91,14 @@ Security Analytics + Forensics для ролей `executive`, `manager`, `securi - [ценность пилота для заказчика](docs/PILOT_VALUE_PROPOSITION_RU.md); - [преддемо-runbook](docs/DEMO_RUNBOOK_RU.md). +Pilot validation: + +- [чеклист проверки пилота](docs/PILOT_VALIDATION_CHECKLIST_RU.md); +- [gap analysis пилота](docs/PILOT_GAP_ANALYSIS_RU.md); +- [вопросы для discovery с заказчиком](docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md); +- [критерии успеха пилота](docs/PILOT_SUCCESS_CRITERIA_RU.md); +- [конкурентное позиционирование](docs/COMPETITIVE_POSITIONING_RU.md). + Границы показа: - pfSense показывается только как `contract_only/readiness`, без заявления @@ -239,6 +247,11 @@ collectors. - [Pilot value proposition](docs/PILOT_VALUE_PROPOSITION_RU.md) - [Pilot v1.0 acceptance checklist](docs/PILOT_V1_ACCEPTANCE_CHECKLIST_RU.md) - [Pilot v1.0 evidence](docs/PILOT_V1_EVIDENCE_RU.md) +- [Pilot validation checklist](docs/PILOT_VALIDATION_CHECKLIST_RU.md) +- [Pilot gap analysis](docs/PILOT_GAP_ANALYSIS_RU.md) +- [Customer discovery questions](docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md) +- [Pilot success criteria](docs/PILOT_SUCCESS_CRITERIA_RU.md) +- [Competitive positioning](docs/COMPETITIVE_POSITIONING_RU.md) - [Production readiness портала](docs/PRODUCTION_READINESS_RU.md) - [Explainable Workforce KPI](docs/EXPLAINABLE_KPI_RU.md) - [Executive Action Center](docs/EXECUTIVE_ACTION_CENTER_RU.md) diff --git a/docs/COMPETITIVE_POSITIONING_RU.md b/docs/COMPETITIVE_POSITIONING_RU.md new file mode 100644 index 0000000..d067ec5 --- /dev/null +++ b/docs/COMPETITIVE_POSITIONING_RU.md @@ -0,0 +1,57 @@ +# Competitive Positioning + +Сравнение носит ориентировочный характер и основано на публичном +позиционировании продуктов. Перед коммерческим использованием его нужно +сверить с актуальными официальными материалами поставщиков. + +AWatch-rus не позиционируется как замена сертифицированным DLP, SIEM, EDR или +XDR. Корректное позиционирование: Workforce Analytics + Security Analytics + +Forensics с прозрачными rule-based объяснениями. + +## Краткое сравнение + +| Продукт | Публичная категория | Сильная сторона | Как позиционировать AWatch-rus рядом | +| --- | --- | --- | --- | +| ActivityWatch | Open-source automated time tracker | Локальный, открытый и понятный сбор активности приложений и сайтов | AWatch-rus развивает этот подход в пилотный корпоративный контур с ролями, отчетами, Risk Narrative и эксплуатационной документацией | +| Стахановец | Контроль сотрудников, мониторинг активности, DLP-возможности | Зрелый классический контроль рабочих мест и политик мониторинга | AWatch-rus не должен заявлять функциональный паритет; его сильная зона - объяснимый управленческий KPI, Security Analytics и пилотная прозрачность | +| StaffCop | Employee Monitoring, Insider Risk, Workforce Analytics, DLP | Широкий набор функций мониторинга, productivity analytics, расследований и DLP-направления | AWatch-rus нужно показывать как более узкий и прозрачный пилотный контур, без обещания заменить StaffCop по широте функций | +| SearchInform | DLP, Risk Monitor, SIEM, TimeInformer и смежные продукты | Комплексная линейка ИБ-продуктов и мониторинга внутренних рисков | AWatch-rus не конкурирует как полноценный SIEM/DLP; он может быть легким аналитическим слоем для Workforce-first пилота | +| InfoWatch | DLP и защита от утечек конфиденциальной информации | Сильное DLP-направление, политики, интеграции и регуляторный контекст | AWatch-rus не заменяет DLP; он показывает операционную активность, объяснимые риски и материалы для внутренней проверки | + +## Где AWatch-rus уместен + +- Быстрый пилот для руководителя, ИБ и эксплуатации без тяжелого SIEM/DLP + внедрения. +- Workforce-first аналитика с объяснением KPI, coverage и confidence. +- Разделение Executive, Workforce, Security и Forensics сценариев. +- Прозрачная rule-based модель UEBA Score v1 и Risk Narrative без ML/LLM. +- Подготовка evidence package и Markdown-отчетов для ручной проверки. +- Честная демонстрация границ: planned, future и contract_only не выдаются за + implemented. + +## Где зрелые конкуренты обычно сильнее + +- Глубокие DLP-политики, контентная фильтрация и блокировки каналов утечки. +- Масштабные SIEM/SOC-процессы и готовые интеграции ИБ. +- Сертификация, регуляторные пакеты и длительная промышленная поддержка. +- Большое количество готовых коннекторов, политик и отчетов для типовых + отраслей. +- Поддержка сложных enterprise-сценариев с централизованным управлением + агентами и политиками. + +## Что нельзя заявлять + +- Что AWatch-rus заменяет DLP, SIEM, EDR или XDR. +- Что planned или future providers уже работают в production. +- Что pfSense readiness означает готовый ingestion, если он находится в статусе + `contract_only`. +- Что Risk Narrative является ML-прогнозом. +- Что система автоматически оценивает персонал или принимает кадровые решения. + +## Публичные источники для сверки + +- ActivityWatch: https://activitywatch.net/ +- StaffCop: https://www.staffcop.com/ +- SearchInform products: https://searchinform.com/products/ +- InfoWatch Traffic Monitor: https://www.infowatch.ru/products/dlp-sistema-traffic-monitor/vozmozhnosti-dlp-sistemy +- Стахановец: https://stakhanovets.ru/ diff --git a/docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md b/docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md new file mode 100644 index 0000000..2724637 --- /dev/null +++ b/docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md @@ -0,0 +1,62 @@ +# Customer Discovery Questions + +Вопросы нужны до пилота, чтобы не показывать AWatch-rus в отрыве от реальных +управленческих, ИБ и эксплуатационных задач заказчика. + +## Директор + +- Какой главный управленческий вопрос должен закрыть пилот через 30 дней? +- Какие подразделения или процессы сейчас вызывают больше всего вопросов по + активности, загрузке или прозрачности работы? +- Какие выводы руководитель хочет видеть ежедневно, еженедельно и по итогам + пилота? +- Что будет считаться доказательством ценности: снижение ручного контроля, + выявленные пробелы, отчетность, управляемость, экономия времени? +- Кто принимает решение о масштабировании после пилота? +- Какие темы нельзя показывать в демо руководителю без отдельного согласования + с ИБ или юристами? + +## Руководитель подразделения + +- Какие команды, роли или группы надо сравнивать между собой? +- Какие рабочие приложения считаются основными для подразделения? +- Какие признаки перегрузки и недозагрузки действительно важны для руководителя? +- Какие периоды считать рабочим временем, удаленной работой и допустимой + внеурочной активностью? +- Как трактовать низкую активность: простой, встреча, выездная работа, + отсутствие данных или реальная проблема? +- Какие рекомендации руководитель готов принимать к исполнению после отчета? + +## ИБ + +- Какие типы кандидатов на проверку наиболее полезны для первого пилота? +- Какие reason codes UEBA Score v1 должны быть понятны аналитику ИБ? +- Какие события нельзя показывать бизнес-ролям по умолчанию? +- Какой порядок ручной проверки incident candidate считается приемлемым? +- Какие ограничения evidence package нужно указать заранее? +- Нужно ли показывать pfSense readiness как `contract_only`, или этот блок + лучше скрыть из демонстрации до появления ingestion? +- Какие DLP/SIEM/EDR claims недопустимы в коммуникации с заказчиком? + +## ИТ + +- Где будет развернут портал: отдельный сервер, VM, контейнер или существующий + контур? +- Какие ОС и версии должны быть покрыты в пилоте? +- Какие рабочие станции или серверы можно подключить первой волной? +- Какой способ доступа к порталу допустим: VPN, reverse proxy, внутренний FQDN, + отдельная учетная запись? +- Кто управляет TLS, DNS, firewall rules и резервным копированием? +- Какие ограничения есть на установку агента, запуск служб и outbound traffic? +- Какой порядок отката считается безопасным? + +## Эксплуатация + +- Кто смотрит health, smoke и журналы во время пилота? +- Какие симптомы считать инцидентом эксплуатации: stale data, degraded reports, + недоступность портала, рост ошибок сбора? +- Какой допустимый RTO и RPO для пилотного стенда? +- Где хранить runbooks и кому разрешено выполнять restart или rollback? +- Как фиксировать замечания после демонстрации и кто закрывает каждое замечание? +- Какая периодичность контрольного отчета нужна: ежедневно, два раза в неделю + или по запросу? diff --git a/docs/PILOT_GAP_ANALYSIS_RU.md b/docs/PILOT_GAP_ANALYSIS_RU.md index c7eb610..b4d9dae 100644 --- a/docs/PILOT_GAP_ANALYSIS_RU.md +++ b/docs/PILOT_GAP_ANALYSIS_RU.md @@ -1,145 +1,74 @@ -# Анализ разрывов готовности пилота AWatch-rus +# Pilot Gap Analysis -Дата аудита: 2026-06-06. - -Аудируемый срез: `origin/main`, -`9c57d6d2ce7eae1b133c937f037b24933f5797fe`. - -Цель: объективно определить готовность AWatch-rus к контролируемой пилотной -эксплуатации и демонстрации руководителю, ИБ и эксплуатации. - -Ограничения аудита: код, архитектура, сущности и интеграции не изменялись. -Сформирован только этот аудитный документ. - -Не входило в аудит: pfSense, Telegram, Grafana, InfluxDB. +Документ фиксирует текущую готовность AWatch-rus к контролируемому пилоту. +Оценка относится к существующему состоянию продукта и не добавляет новых +функций, API, агентов или интеграций. ## Что готово -- Архитектура пилота выстроена как понятная цепочка: - `агент -> телеметрия -> аналитика -> риск -> расследование -> отчет`. -- Rust workspace на текущем `origin/main` проходит обязательные проверки: +- Сформирован Pilot v1 контур с ролями `executive`, `manager`, `security`, + `forensics` и `admin`. +- Есть Executive, Workforce, Security и Forensics сценарии для демонстрации. +- Реализованы Workforce reports, Explainable KPI, UEBA Score v1, Risk Narrative + и Executive Action Center. +- Есть Rust Backend, Rust Agent baseline, HTML/HTMX portal и role-based + контракты Pilot v1. +- Подготовлен demo pack: сценарии руководителя, ИБ и расследований, синтетический + demo dataset, evidence pack, пример итогового отчета и value proposition. +- Подготовлены registry readiness документы без ложных заявлений о сертификации. +- Подготовлены enterprise deployment документы: topology, sizing, backup and + recovery, operations runbook, hardening и acceptance checklist. +- pfSense readiness описан как `contract_only`, без заявления production + ingestion или SIEM-функциональности. +- Скриншоты портала вынесены в `docs/screenshots/` и описаны в README. +- Есть отдельный smoke для проверки demo, registry, deployment, screenshots, + roadmap, reports и runbooks. -| Проверка | Результат | -| --- | --- | -| `cargo test --workspace` | Пройдено. | -| `cargo clippy --all-targets --all-features` | Пройдено. | -| `cargo build --release` | Пройдено. | -| `node scripts/detmir-portal-tabs-smoke.mjs` | Пройдено против рабочего портала через временный туннель; `security_events=available`. | +## Что требует доработки -- Portal UX проходит smoke: вкладки `Обзор`, `Сотрудники`, - `Подразделения`, `Риски`, `Расследования`, `Сетевой периметр`, `Отчеты`, - `Настройки` открываются без ошибок консоли и HTTP 4xx/5xx. -- Executive View готов к показу руководителю: главный вывод расположен первым, - порядок управленческих блоков подтвержден smoke, англоязычные и лишние - технические термины в проверяемом пользовательском слое не обнаружены. -- Security View готов к показу ИБ: есть кандидаты на проверку, расследования, - аудит, материалы расследования и переход из риска в карточку расследования. - Smoke подтвердил 3 кнопки перехода к расследованию. -- Operations View готов к показу эксплуатации: видны полнота и качество - данных, состояние источников, режим событий безопасности и ошибки сбора. -- ClickHouse integration работает в пилотном контуре: `/api/health` - возвращает `ok=true`, источник `security_events` активен, портал получает - агрегированные события безопасности через ClickHouse. -- Сбор данных 1С и DLP зафиксирован как Rust-first runtime: `aw-1c-ingest-rust` - и Windows telemetry/evidence sync работают с 15-минутным циклом; скриншоты - 1С не копируются, доказательные PNG остаются только для DLP-событий. -- Agent/Rust migration закрывает критичный runtime-риск: основной сбор - worktime, browser/domain, URL/domain extraction, clipboard/USB/print - incident semantics и DLP evidence path покрыты Rust-бинарниками и тестами. -- Документы `docs/PORTAL_RU.md` и `docs/SECURITY_EVENTS_CLICKHOUSE_RU.md` - присутствуют и отражают текущую модель портала и ClickHouse-событий. -- Пилотные документы находятся в единой структуре `docs/`: - `docs/CUSTOMER_PILOT_PACK_RU.md`, `docs/PILOT_READINESS_AUDIT_RU.md`, - `docs/SALES_POSITIONING_RU.md`, `docs/DEMO_RUNBOOK_RU.md`. -- 10-минутный демонстрационный путь технически доступен: главный риск, - подразделение, причина риска, кандидат, расследование, пакет расследования и - итоговый управленческий вывод показываются в портале. +- Провести live pilot smoke на целевом стенде заказчика, а не только локальную + проверку репозитория. +- Зафиксировать согласованные источники данных, ожидаемое покрытие агентов и + допустимую задержку обновления данных. +- Выполнить контрольный тест backup and recovery на стенде пилота. +- Проверить reverse proxy, TLS, авторизацию и доступность портала из сети + заказчика. +- Провести визуальную проверку портала на рабочем разрешении демонстрационного + ноутбука и на мобильном/планшетном экране, если такой показ предполагается. +- Подтвердить, что Markdown-отчеты не содержат персональных данных и внутренних + идентификаторов заказчика. +- Зафиксировать владельцев действий по Recommended Actions: бизнес, + эксплуатация, ИБ. -## Что критично исправить +## Что не входит в пилот -Критичных блокеров в коде, сборке и smoke-проверке для контролируемого пилота -на текущем срезе не выявлено. +- Полноценная DLP-система с контентной фильтрацией, блокировками и политиками + предотвращения утечек. +- Полноценная SIEM-система с централизованной корреляцией всех событий ИБ. +- EDR/XDR, антивирусная защита, реагирование на вредоносный код и управление + изоляцией хостов. +- ML/LLM-прогнозирование, автоматическая классификация сотрудников и + генеративная аналитика. +- Автоматическое применение дисциплинарных или кадровых решений. +- Обязательный production ingestion pfSense. +- Юридически значимая экспертиза без ручной проверки материалов ответственным + лицом. -Критичные условия перед фактическим показом: +## Что отложено на roadmap -- Демо должно запускаться на контуре, где развернут именно commit - `9c57d6d2ce7eae1b133c937f037b24933f5797fe` или более новый проверенный срез. -- Перед показом нужен короткий преддемо-прогон на той же сети и экране: - открыть портал, дождаться `Данные готовы`, проверить кандидата, открыть - расследование и сформировать отчет. -- Нельзя продавать текущий срез как промышленно завершенную платформу без - оговорок по доступу, retention, backup, versioning и регламенту эксплуатации. +- Расширенные agentless providers: PowerShell, SSH, Syslog, 1C, VPN и SCUD. +- Production validation российских ОС: Astra Linux, РЕД ОС, Альт и РОСА. +- Расширенный React/TypeScript Enterprise UI и Tauri Desktop Forensics. +- Глубокие enterprise-коннекторы AD/LDAP, SIEM и корпоративных учетных систем. +- Нагрузочное тестирование крупного контура с формальным capacity baseline. +- Формальный release package с подписанными артефактами, SBOM и процедурой + поставки для промышленной эксплуатации. +- Дополнительные регламентные материалы для закупки и юридической приемки. -## Что желательно исправить +## Итог -- Русифицировать заголовки customer-facing документов: текущие документы - используют названия вроде `Customer Pilot Pack` и `Sales Positioning`, что - слабее выглядит на показе руководителю и заказчику. -- Отдельно перед демо проверить экспорт в формате, который будет показан: - текстовый отчет, печать или PDF. -- Добавить в регулярный smoke мобильный/визуальный прогон. Текущий - `detmir-portal-tabs-smoke.mjs` хорошо проверяет функциональный путь, но не - является полноценной визуальной regression-проверкой. -- Сформировать явную матрицу совместимости API: agent, portal, telemetry, - ClickHouse security events и investigation state. -- Убрать из публичного customer-facing пакета внутренние формулировки про - ``, private contour и служебные runtime-детали. - -## Что перенести после пилота - -- Полное hardening локальных JSON/JSONL/state-хранилищ: atomic write, - блокировки, retention, backup/restore и нагрузочные тесты больших файлов. -- Промышленный app-layer RBAC для портала. Сейчас ролевые представления есть в - UX, но контроль доступа должен оставаться задачей защищенного контура или - reverse proxy до отдельного product hardening. -- Полное удаление оставшихся PowerShell deploy/bootstrap/fallback-элементов. - Для пилота важно отсутствие PowerShell как основного runtime-сборщика; полная - зачистка deploy-истории не является блокером показа. -- Load/sizing-профиль под промышленную эксплуатацию: количество рабочих мест, - объем событий, глубина хранения, требования к ClickHouse и файловому evidence. -- Формальные регламенты хранения и доступа к материалам расследований. -- CI-упаковку customer-facing документов с проверкой путей, ссылок и русских - заголовков. - -## Риски пилота - -| Риск | Влияние | Оценка | -| --- | --- | --- | -| Контур демо не совпадает с проверенным commit | Возможны расхождения UI, API или данных | Критично контролировать перед показом | -| Документы или ссылки изменятся без проверки | Путает hand-off и приемку пакета | Контролировать markdown link-check перед передачей | -| Первый запуск портала без прогрева | Может выглядеть как зависшая загрузка | Управляемо преддемо-прогоном | -| В текущих данных исчезнут кандидаты на расследование | 10-минутный сценарий потеряет самый сильный пример | Проверять `/api/reports` перед демо | -| ClickHouse станет недоступен | Operations View покажет fallback/ошибку вместо полного ИБ-среза | Не блокер UI, но слабее для ИБ | -| Нет промышленного RBAC внутри приложения | Нельзя открывать портал вне защищенного контура | Для контролируемого пилота приемлемо | -| Остаточные PowerShell deploy/fallback артефакты | Могут вызвать вопросы эксплуатации о миграции | Объяснять как legacy/fallback, не runtime-core | -| Нет полной визуальной mobile regression-проверки в обязательном smoke | Возможны мелкие UX-дефекты на нестандартном экране | Проверить вручную перед показом с планшета/ноутбука | - -Дополнительное наблюдение: один первичный запуск smoke через только что -созданный туннель один раз не дождался `READY` за 30 секунд. Повтор с тем же -30-секундным таймаутом прошел примерно за 8 секунд, `/portal/api/reports` -отвечал примерно за 0.4 секунды. Это не выглядит как продуктовый блокер, но -подтверждает необходимость преддемо-прогона. - -## Итоговая оценка готовности - -Статус: AWatch-rus готов к контролируемому демонстрационному пилоту на текущем -`origin/main`. - -Оценка готовности: 88%. - -Обоснование: - -- Сборка, тесты, clippy, release build и portal smoke на проверенном срезе - успешны. -- Executive/Security/Operations View закрывают основной сценарий для - руководителя, ИБ и эксплуатации. -- Rust runtime migration убрал главный риск зависимости от PowerShell в - рабочих сборщиках. -- ClickHouse-события безопасности доступны и отражаются в портале. -- Оставшиеся разрывы относятся в основном к вычитке документов, преддемо - дисциплине, промышленному hardening и формальному управлению доступом. - -Рекомендация: допустить к пилоту только как контролируемый демонстрационный -контур. Перед показом выполнить короткий smoke на рабочем URL, проверить -наличие кандидата на расследование, открыть пакет расследования и заранее -подготовить итоговый отчет. +AWatch-rus готов к контролируемому пилоту и демонстрации Pilot v1 как +Workforce-first платформы с Security Analytics и Forensics-контуром. Главный +остаточный риск не в функциональности демо, а в неподтвержденной готовности +целевого стенда: доступность портала, покрытие источников, свежесть данных, +резервное восстановление и роли ответственных за действия после пилота. diff --git a/docs/PILOT_SUCCESS_CRITERIA_RU.md b/docs/PILOT_SUCCESS_CRITERIA_RU.md new file mode 100644 index 0000000..6a3a45c --- /dev/null +++ b/docs/PILOT_SUCCESS_CRITERIA_RU.md @@ -0,0 +1,58 @@ +# Pilot Success Criteria + +Документ задает приемочные критерии 30-дневного пилота AWatch-rus. Критерии +ориентированы на проверяемую ценность, а не на маркетинговые заявления. + +## Критерии успеха пилота + +- Портал стабильно открывается для согласованных ролей. +- Executive сценарий за 10 минут показывает KPI, объяснение, Risk Narrative и + Recommended Actions. +- Workforce сценарий показывает активность, подразделения, тренды, coverage и + confidence без ручной сборки отчета. +- Security сценарий показывает incident candidates, UEBA Score v1 и понятные + reason codes без заявления полноценной DLP/SIEM-функциональности. +- Forensics сценарий позволяет собрать evidence package и Markdown-отчет на + проверяемом кейсе. +- Операторы понимают, как диагностировать stale/degraded данные по runbook. +- Данные пилота не раскрывают лишние персональные, сетевые или внутренние + идентификаторы в демо и отчетах. +- Заказчик может принять решение: масштабировать, доработать или остановить + пилот на основании фактов. + +## Критерии провала пилота + +- Портал недоступен или регулярно не проходит smoke без понятной причины. +- Ролевые ограничения показывают бизнес-ролям техническую ИБ-детализацию. +- KPI отображается без объяснения покрытия, свежести и confidence. +- Отчеты зависают при деградации источников вместо controlled degraded/stale + поведения. +- Невозможно объяснить, почему объект попал в incident candidates. +- В документах или демо обнаружены реальные IP, hostname, логины, ФИО, + подразделения заказчика или события безопасности. +- Нет владельца дальнейших действий после Recommended Actions. +- Заказчик воспринимает продукт как заявленный DLP/SIEM/EDR, хотя это не + соответствует границам пилота. + +## KPI пилота + +- Доступность портала в рабочее время пилота. +- Доля успешных smoke-прогонов. +- Покрытие согласованных источников данных. +- Freshness данных для ключевых отчетов. +- Время открытия Executive и Reporting сценариев. +- Количество подтвержденных и отклоненных incident candidates. +- Доля отчетов, принятых руководителем без ручной переработки. +- Количество выявленных gaps по данным, доступам, ролям и эксплуатации. +- Количество Recommended Actions, по которым назначен владелец. + +## Ожидаемый результат через 30 дней + +- Подтверждено, какие сценарии AWatch-rus дают ценность заказчику. +- Сформирован список источников данных, которые нужны для масштабирования. +- Зафиксированы ограничения пилота и roadmap-доработки. +- Подготовлен отчет для руководителя, ИБ и эксплуатации. +- Принято решение о следующем этапе: масштабирование, ограниченная доработка + или завершение пилота. +- Согласованы требования к production deployment: роли, доступы, резервное + копирование, мониторинг, ответственные и окна изменений. diff --git a/docs/PILOT_VALIDATION_CHECKLIST_RU.md b/docs/PILOT_VALIDATION_CHECKLIST_RU.md new file mode 100644 index 0000000..92c37af --- /dev/null +++ b/docs/PILOT_VALIDATION_CHECKLIST_RU.md @@ -0,0 +1,75 @@ +# Pilot Validation Checklist + +Документ фиксирует проверку AWatch-rus перед реальным пилотом. Цель проверки: +подтвердить, что уже реализованные сценарии можно показать заказчику без +добавления нового функционала и без ложных заявлений о DLP, SIEM или EDR. + +## Executive сценарий + +- Главный управленческий вывод отображается первым. +- Руководитель видит KPI, Risk Narrative и Recommended Actions без технических + ИБ-деталей по умолчанию. +- Explainable KPI отвечает на вопрос, почему индекс активности имеет текущее + значение. +- Risk Narrative объясняет, что происходит, почему это риск и что делать дальше. +- Ролевые ограничения не дают роли `executive` видеть расследовательскую и + техническую ИБ-детализацию без смены роли. +- В демо используются только синтетические данные. + +## Workforce сценарий + +- Отображается индекс активности и объяснение факторов. +- Доступно сравнение подразделений и ответственных. +- Видны тренды daily, weekly и monthly, если данные есть. +- Отдельно показываются признаки перегрузки и недозагрузки. +- Coverage и freshness показывают надежность KPI. +- При неполных данных система снижает доверие к KPI, а не выдает уверенный + вывод. +- Отчеты не формулируют автоматическую кадровую оценку сотрудника. + +## Security сценарий + +- ИБ видит UEBA Score v1, risk score, severity и reason codes. +- Список incident candidates содержит объяснимые причины попадания в очередь. +- Security View отделен от управленческого Workforce Dashboard. +- pfSense readiness отображается только как `contract_only`, если задействован + соответствующий слой контрактов. +- Интерфейс не заявляет AWatch-rus как полноценный SIEM или DLP. +- Все выводы rule-based, без ML и LLM. + +## Forensics сценарий + +- Расследователь видит карточку расследования, timeline, evidence и экспорт + Markdown-отчета. +- Связка user, host, app и network event показывается только в рамках доступных + demo/contracts данных. +- В demo-режиме отсутствуют реальные ФИО, логины, IP-адреса, hostname и домены. +- Система помогает собрать материалы, но не формирует юридически обязательный + вывод без проверки ответственным лицом. + +## Agent сценарий + +- Rust Agent baseline описан и проверяется через документацию. +- Для пилота определены источники данных, ожидаемое покрытие и допустимая + задержка. +- Потеря части данных снижает confidence и фиксируется как operational gap. +- Массовое развертывание агента выполняется волнами после согласования с ИТ. +- Agentless-направления считаются roadmap или planned, если не подтверждены + текущей поставкой. + +## Reporting сценарий + +- `/api/reports` и портальные отчеты возвращают данные в рамках роли. +- Markdown-отчет формируется на демонстрационных данных. +- В отчете видны KPI, Explainable KPI, Risk Narrative и Recommended Actions. +- При деградации источников отчеты должны возвращать контролируемый degraded + или stale статус, а не зависать. +- Оператор может открыть runbook и понять порядок диагностики. + +## Evidence перед запуском пилота + +- Выполнен `scripts/pilot-validation-smoke.mjs`. +- Выполнен актуальный smoke портала на целевом стенде. +- Проверены скриншоты из `docs/screenshots/`. +- Проверены ссылки README и ключевых pilot-документов. +- Зафиксированы открытые gaps в `docs/PILOT_GAP_ANALYSIS_RU.md`. diff --git a/docs/roadmap/TASK_010_PILOT_VALIDATION.md b/docs/roadmap/TASK_010_PILOT_VALIDATION.md index 61476b6..479e82d 100644 --- a/docs/roadmap/TASK_010_PILOT_VALIDATION.md +++ b/docs/roadmap/TASK_010_PILOT_VALIDATION.md @@ -157,4 +157,61 @@ scripts/pilot-validation-smoke.mjs 2. Выявленные пробелы. 3. Основные риски пилота. 4. Конкурентное позиционирование. -5. Проверки. \ No newline at end of file +5. Проверки. + +--- + +## Выполнение + +Статус: выполнено. + +Созданы документы: + +- `docs/PILOT_VALIDATION_CHECKLIST_RU.md` +- `docs/PILOT_GAP_ANALYSIS_RU.md` +- `docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md` +- `docs/PILOT_SUCCESS_CRITERIA_RU.md` +- `docs/COMPETITIVE_POSITIONING_RU.md` + +Добавлен smoke: + +- `scripts/pilot-validation-smoke.mjs` + +Обновлен README: + +- добавлены ссылки на pilot validation пакет рядом с demo, registry и + deployment материалами. + +Выявленные пробелы: + +- нужен live smoke на целевом стенде заказчика; +- нужно подтвердить покрытие источников данных и freshness; +- нужен контрольный backup and recovery тест; +- нужно проверить reverse proxy, TLS, авторизацию и внешнюю доступность портала; +- нужно закрепить владельцев действий по Recommended Actions. + +Основные риски пилота: + +- целевой стенд может отличаться от локального demo-стенда; +- неполное покрытие источников снизит confidence KPI; +- заказчик может ошибочно ожидать DLP/SIEM/EDR, если заранее не проговорить + границы пилота; +- без владельцев действий управленческие рекомендации останутся отчетом без + исполнения. + +Конкурентное позиционирование: + +- AWatch-rus позиционируется как Workforce Analytics + Security Analytics + + Forensics; +- продукт не заявляется как замена ActivityWatch, Стахановец, StaffCop, + SearchInform или InfoWatch; +- сравнение сделано честно: зрелые DLP/SIEM/employee monitoring продукты + сильнее в глубине политик, сертификации и ширине enterprise-функций; +- сильная сторона AWatch-rus в пилоте: explainable KPI, Risk Narrative, + role-based сценарии и прозрачные ограничения. + +Проверки: + +- `node --check scripts/pilot-validation-smoke.mjs` +- `node scripts/pilot-validation-smoke.mjs` +- `git diff --check` diff --git a/scripts/pilot-validation-smoke.mjs b/scripts/pilot-validation-smoke.mjs new file mode 100644 index 0000000..c07cd43 --- /dev/null +++ b/scripts/pilot-validation-smoke.mjs @@ -0,0 +1,270 @@ +#!/usr/bin/env node +import fs from "node:fs"; +import path from "node:path"; +import process from "node:process"; +import { fileURLToPath } from "node:url"; + +const root = path.resolve(path.dirname(fileURLToPath(import.meta.url)), ".."); + +const validationDocs = [ + "docs/PILOT_VALIDATION_CHECKLIST_RU.md", + "docs/PILOT_GAP_ANALYSIS_RU.md", + "docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md", + "docs/PILOT_SUCCESS_CRITERIA_RU.md", + "docs/COMPETITIVE_POSITIONING_RU.md", +]; + +const demoDocs = [ + "docs/PILOT_DEMO_SCENARIO_RU.md", + "docs/DEMO_RUNBOOK_RU.md", + "docs/DEMO_REPORT_EXAMPLE_RU.md", + "docs/PILOT_VALUE_PROPOSITION_RU.md", + "docs/demo/DEMO_SCENARIO_EXECUTIVE_RU.md", + "docs/demo/DEMO_SCENARIO_SECURITY_RU.md", + "docs/demo/DEMO_SCENARIO_FORENSICS_RU.md", + "docs/demo/DEMO_PACK_ACCEPTANCE_CHECKLIST_RU.md", + "docs/fixtures/pilot-v1-demo/README_RU.md", + "docs/fixtures/pilot-v1-demo/demo-seed-data.json", +]; + +const registryDocs = [ + "docs/REGISTRY_PRODUCT_PASSPORT_RU.md", + "docs/REGISTRY_ARCHITECTURE_RU.md", + "docs/REGISTRY_FUNCTIONAL_SCOPE_RU.md", + "docs/REGISTRY_DEPENDENCY_STATEMENT_RU.md", + "docs/REGISTRY_DEPLOYMENT_MODEL_RU.md", + "docs/REGISTRY_COMMERCIAL_POSITIONING_RU.md", + "docs/REGISTRY_READINESS_CHECKLIST_RU.md", +]; + +const deploymentDocs = [ + "docs/ENTERPRISE_DEPLOYMENT_GUIDE_RU.md", + "docs/DEPLOYMENT_TOPOLOGIES_RU.md", + "docs/SIZING_GUIDE_RU.md", + "docs/BACKUP_AND_RECOVERY_RU.md", + "docs/OPERATIONS_RUNBOOK_RU.md", + "docs/SECURITY_HARDENING_RU.md", + "docs/ENTERPRISE_ACCEPTANCE_CHECKLIST_RU.md", +]; + +const screenshots = [ + "docs/screenshots/01-executive-overview.png", + "docs/screenshots/02-risk-heatmap.png", + "docs/screenshots/03-security-view.png", + "docs/screenshots/04-operations-view.png", + "docs/screenshots/05-investigation-pack.png", + "docs/screenshots/06-markdown-report.png", + "docs/screenshots/07-product-architecture.png", +]; + +const roadmapDocs = [ + "docs/roadmap/README.md", + "docs/roadmap/TASK_001_PILOT_V1_STABILIZATION.md", + "docs/roadmap/TASK_002_PRODUCTION_HARDENING.md", + "docs/roadmap/TASK_003_EXPLAINABLE_KPI.md", + "docs/roadmap/TASK_003A_PORTAL_HARDENING_CLEANUP.md", + "docs/roadmap/TASK_004_RISK_NARRATIVE.md", + "docs/roadmap/TASK_005_RUST_AGENT_BASELINE.md", + "docs/roadmap/TASK_006_EXECUTIVE_ACTION_CENTER.md", + "docs/roadmap/TASK_007_CUSTOMER_DEMO_PACK.md", + "docs/roadmap/TASK_008_REGISTRY_READINESS.md", + "docs/roadmap/TASK_009_ENTERPRISE_DEPLOYMENT_GUIDE.md", + "docs/roadmap/TASK_010_PILOT_VALIDATION.md", +]; + +const reportsAndRunbooks = [ + "docs/DEMO_REPORT_EXAMPLE_RU.md", + "docs/PRODUCTION_INCIDENT_REPORT_2026-06-07_RU.md", + "docs/OPERATIONS_RUNBOOK_RU.md", + "docs/OPERATIONS_RUNBOOK_WORKTIME_RU.md", + "docs/BACKUP_AND_RECOVERY_RU.md", + "docs/DEMO_RUNBOOK_RU.md", +]; + +function readText(file) { + return fs.readFileSync(path.join(root, file), "utf8"); +} + +function exists(file) { + return fs.existsSync(path.join(root, file)); +} + +function checkFiles(files) { + return files.filter((file) => !exists(file)); +} + +function checkScreenshots(files) { + const pngSignature = Buffer.from([0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]); + const findings = []; + for (const file of files) { + const fullPath = path.join(root, file); + if (!fs.existsSync(fullPath)) { + findings.push({ file, reason: "missing" }); + continue; + } + const data = fs.readFileSync(fullPath); + if (data.length <= 1000 || !data.subarray(0, 8).equals(pngSignature)) { + findings.push({ file, reason: "not_png_or_too_small", size: data.length }); + } + } + return findings; +} + +function checkMarkdownLinks(files) { + const findings = []; + const linkPattern = /!?\[[^\]]+\]\(([^)]+)\)/g; + for (const file of files) { + if (!file.endsWith(".md")) continue; + let match = null; + const text = readText(file); + while ((match = linkPattern.exec(text)) !== null) { + const raw = String(match[1] || "").trim(); + const target = raw.split(/\s+/)[0].replace(/^<|>$/g, ""); + if ( + !target + || target.startsWith("#") + || target.startsWith("http://") + || target.startsWith("https://") + || target.startsWith("mailto:") + ) { + continue; + } + const withoutAnchor = target.split("#", 1)[0]; + if (!withoutAnchor) continue; + const resolved = path.resolve(root, path.dirname(file), withoutAnchor); + if (!fs.existsSync(resolved)) { + findings.push({ file, target }); + } + } + } + return findings; +} + +function checkRequiredContent() { + const checks = [ + { + file: "docs/PILOT_VALIDATION_CHECKLIST_RU.md", + markers: ["Executive", "Workforce", "Security", "Forensics", "Agent", "Reporting"], + }, + { + file: "docs/PILOT_GAP_ANALYSIS_RU.md", + markers: ["Что готово", "Что требует доработки", "Что не входит в пилот", "Что отложено на roadmap"], + }, + { + file: "docs/CUSTOMER_DISCOVERY_QUESTIONS_RU.md", + markers: ["Директор", "Руководитель подразделения", "ИБ", "ИТ", "Эксплуатация"], + }, + { + file: "docs/PILOT_SUCCESS_CRITERIA_RU.md", + markers: ["Критерии успеха", "Критерии провала", "KPI пилота", "30 дней"], + }, + { + file: "docs/COMPETITIVE_POSITIONING_RU.md", + markers: ["ActivityWatch", "Стахановец", "StaffCop", "SearchInform", "InfoWatch"], + }, + ]; + const findings = []; + for (const check of checks) { + const text = readText(check.file); + for (const marker of check.markers) { + if (!text.includes(marker)) { + findings.push({ file: check.file, marker }); + } + } + } + return findings; +} + +function checkSensitiveStrings(files) { + const patterns = [ + { name: "private_network_10", re: /10\.10\.10\./ }, + { name: "private_network_192", re: /192\.168\./ }, + { name: "private_network_172", re: /172\.(1[6-9]|2\d|3[0-1])\./ }, + { name: "private_operator_domain", re: /dm\.iri/i }, + { name: "customer_codename", re: new RegExp(`${["Det", "Mir"].join("")}|${["SHARKON", "2025"].join("")}`, "i") }, + { name: "local_operator_path", re: /\/home\/igor/i }, + { name: "mts_phishing_context", re: /\b(lk|l)\.mts\.ru/i }, + ]; + const findings = []; + for (const file of files) { + if (!file.endsWith(".md") && !file.endsWith(".json")) continue; + const text = readText(file); + for (const pattern of patterns) { + if (pattern.re.test(text)) { + findings.push({ file, pattern: pattern.name }); + } + } + } + return findings; +} + +function pass(checks, name, ok, details = {}) { + checks.push({ name, ok: Boolean(ok), ...details }); +} + +function main() { + const checks = []; + const docsToScan = [ + "README.md", + ...validationDocs, + ...demoDocs, + ...registryDocs, + ...deploymentDocs, + ...roadmapDocs, + ...reportsAndRunbooks, + ]; + const sensitiveScanFiles = [ + ...validationDocs, + "docs/fixtures/pilot-v1-demo/README_RU.md", + "docs/fixtures/pilot-v1-demo/demo-seed-data.json", + ]; + + pass(checks, "validation_docs_exist", checkFiles(validationDocs).length === 0, { + missing: checkFiles(validationDocs), + }); + pass(checks, "demo_docs_exist", checkFiles(demoDocs).length === 0, { + missing: checkFiles(demoDocs), + }); + pass(checks, "registry_docs_exist", checkFiles(registryDocs).length === 0, { + missing: checkFiles(registryDocs), + }); + pass(checks, "deployment_docs_exist", checkFiles(deploymentDocs).length === 0, { + missing: checkFiles(deploymentDocs), + }); + pass(checks, "roadmap_exists", checkFiles(roadmapDocs).length === 0, { + missing: checkFiles(roadmapDocs), + }); + pass(checks, "reports_and_runbooks_exist", checkFiles(reportsAndRunbooks).length === 0, { + missing: checkFiles(reportsAndRunbooks), + }); + + const screenshotFindings = checkScreenshots(screenshots); + pass(checks, "screenshots_exist_and_are_png", screenshotFindings.length === 0, { + findings: screenshotFindings, + }); + + const requiredContentFindings = checkRequiredContent(); + pass(checks, "validation_docs_have_required_sections", requiredContentFindings.length === 0, { + findings: requiredContentFindings, + }); + + const linkFindings = checkMarkdownLinks(docsToScan); + pass(checks, "markdown_links_valid", linkFindings.length === 0, { + findings: linkFindings, + }); + + const sensitiveFindings = checkSensitiveStrings(sensitiveScanFiles); + pass(checks, "sensitive_string_scan", sensitiveFindings.length === 0, { + findings: sensitiveFindings, + }); + + const ok = checks.every((check) => check.ok); + process.stdout.write(`${JSON.stringify({ + ok, + generated_at_utc: new Date().toISOString(), + checks, + }, null, 2)}\n`); + process.exitCode = ok ? 0 : 2; +} + +main();