docs: add product roadmap tasks
This commit is contained in:
igor04091968
@@ -0,0 +1,17 @@
|
|||||||
|
# Roadmap AWatch-rus
|
||||||
|
|
||||||
|
Этот раздел фиксирует ближайшие продуктовые задачи AWatch-rus после Pilot v1.
|
||||||
|
|
||||||
|
Roadmap не является заявлением о готовой функциональности. Каждый task-файл
|
||||||
|
разделяет цель, границы, ожидаемый результат и ограничения.
|
||||||
|
|
||||||
|
## Задачи
|
||||||
|
|
||||||
|
1. [TASK_001_PILOT_V1_STABILIZATION.md](TASK_001_PILOT_V1_STABILIZATION.md)
|
||||||
|
2. [TASK_002_PRODUCTION_HARDENING.md](TASK_002_PRODUCTION_HARDENING.md)
|
||||||
|
3. [TASK_003_EXPLAINABLE_KPI.md](TASK_003_EXPLAINABLE_KPI.md)
|
||||||
|
4. [TASK_004_RISK_NARRATIVE.md](TASK_004_RISK_NARRATIVE.md)
|
||||||
|
5. [TASK_005_RUST_AGENT_BASELINE.md](TASK_005_RUST_AGENT_BASELINE.md)
|
||||||
|
6. [TASK_006_PFSENSE_CONTRACT_LAYER.md](TASK_006_PFSENSE_CONTRACT_LAYER.md)
|
||||||
|
7. [TASK_007_CUSTOMER_DEMO_PACK.md](TASK_007_CUSTOMER_DEMO_PACK.md)
|
||||||
|
8. [TASK_008_REGISTRY_READINESS.md](TASK_008_REGISTRY_READINESS.md)
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
# TASK 001: Pilot v1 Stabilization
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Закрепить Pilot v1 как стабильный демонстрационный и приемочный контур
|
||||||
|
AWatch-rus.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Проверка ролей `executive`, `manager`, `security`, `forensics`, `admin`.
|
||||||
|
- Проверка portal smoke и degraded-path smoke.
|
||||||
|
- Проверка документации Pilot v1 и runbook перед демонстрацией.
|
||||||
|
- Фиксация известных ограничений без расширения функциональности.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не менять ролевую модель без отдельного решения.
|
||||||
|
- Не добавлять новые collectors.
|
||||||
|
- Не выдавать roadmap за реализованную функциональность.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Pilot v1 можно показывать заказчику с понятным списком готовых возможностей,
|
||||||
|
ограничений и smoke-проверок.
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
# TASK 002: Production Hardening
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Повысить надежность промышленного контура AWatch-rus при отказах источников,
|
||||||
|
перегрузке сервисов и частичной потере данных.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Fail-closed поведение для критичных API.
|
||||||
|
- Bounded timeouts и отсутствие каскадных тяжелых повторов.
|
||||||
|
- Stale cache fallback там, где это безопасно.
|
||||||
|
- Health/status, которые честно показывают degraded-состояние.
|
||||||
|
- Операторские runbook для восстановления.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не скрывать degraded-состояния за зеленым health.
|
||||||
|
- Не делать ClickHouse обязательной зависимостью worktime reports.
|
||||||
|
- Не логировать чувствительные runtime-идентификаторы.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Система контролируемо деградирует, не создает каскадную нагрузку и дает
|
||||||
|
оператору понятный порядок восстановления.
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
# TASK 003: Explainable KPI
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Сделать KPI и индексы активности объяснимыми для руководителя, эксплуатации и
|
||||||
|
ИБ.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Причины расчета KPI.
|
||||||
|
- Вклад источников данных.
|
||||||
|
- Уровень доверия к показателю.
|
||||||
|
- Отдельное отображение неполных, устаревших и fallback-данных.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не использовать ML/LLM для расчета KPI.
|
||||||
|
- Не смешивать управленческие KPI и ИБ-детализацию в одном выводе без роли.
|
||||||
|
- Не показывать персональные данные в demo-режиме.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Каждый ключевой показатель сопровождается понятным объяснением: из чего он
|
||||||
|
получен, насколько надежен и что снижает доверие к нему.
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
# TASK 004: Risk Narrative
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Сформировать понятный управленческий narrative вокруг рисков без технического
|
||||||
|
шума.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Главный риск первым.
|
||||||
|
- Причина риска.
|
||||||
|
- Подразделение или зона ответственности.
|
||||||
|
- Подтверждающие сигналы.
|
||||||
|
- Рекомендованное действие.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не утверждать нарушение без ручной проверки.
|
||||||
|
- Не превращать executive view в ИБ-отчет.
|
||||||
|
- Не использовать англоязычные технические термины в управленческом выводе.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Руководитель за несколько минут понимает, где основной риск, почему он возник и
|
||||||
|
какое действие требуется.
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
# TASK 005: Rust Agent Baseline
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Закрепить Rust Agent как основной агентный baseline для регулярного сбора
|
||||||
|
данных AWatch-rus.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Проверка стабильности Windows runtime.
|
||||||
|
- Проверка публикации worktime/session telemetry.
|
||||||
|
- Проверка spool/retry поведения.
|
||||||
|
- Документирование rollback-пути на случай отказа.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не переписывать стабильные вспомогательные компоненты только ради языка.
|
||||||
|
- Не ломать существующие Windows deployment-пакеты.
|
||||||
|
- Не добавлять неподтвержденные платформенные claims.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Rust Agent используется как основной агентный слой там, где он уже проверен, а
|
||||||
|
границы поддержки описаны честно.
|
||||||
@@ -0,0 +1,24 @@
|
|||||||
|
# TASK 006: pfSense Contract Layer
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Сохранить pfSense направление как contract/readiness layer без ложного
|
||||||
|
позиционирования AWatch-rus как SIEM.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Контракты firewall events.
|
||||||
|
- Контракты VPN events.
|
||||||
|
- Traffic summary и top destinations как модель данных.
|
||||||
|
- Документация статуса `contract_only`.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не заявлять production ingestion, если он не реализован.
|
||||||
|
- Не делать полноценный SIEM.
|
||||||
|
- Не добавлять новые collectors в рамках этой задачи.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
pfSense readiness описана как подготовленный контрактный слой, пригодный для
|
||||||
|
будущей интеграции без завышенных продуктовых обещаний.
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
# TASK 007: Customer Demo Pack
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Подготовить демонстрационный пакет, который позволяет показать AWatch-rus
|
||||||
|
руководителю, ИБ и эксплуатации за ограниченное время.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Короткий demo runbook.
|
||||||
|
- Скриншоты интерфейса на обезличенных данных.
|
||||||
|
- Markdown-отчет.
|
||||||
|
- Evidence package для расследования.
|
||||||
|
- Acceptance checklist.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не использовать реальные IP-адреса, hostname, логины, ФИО и подразделения.
|
||||||
|
- Не показывать planned/future как implemented.
|
||||||
|
- Не менять бизнес-логику ради демонстрации.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Репозиторий и демо-материалы позволяют быстро понять назначение продукта,
|
||||||
|
интерфейс и границы Pilot v1.
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
# TASK 008: Registry Readiness
|
||||||
|
|
||||||
|
## Цель
|
||||||
|
|
||||||
|
Подготовить AWatch-rus к экспертной и регистрационной проверке как
|
||||||
|
программный продукт.
|
||||||
|
|
||||||
|
## Объем
|
||||||
|
|
||||||
|
- Позиционирование продукта.
|
||||||
|
- Архитектурное описание.
|
||||||
|
- Сведения о сторонних компонентах и лицензиях.
|
||||||
|
- SBOM/release checklist.
|
||||||
|
- Сценарий экспертной проверки.
|
||||||
|
|
||||||
|
## Ограничения
|
||||||
|
|
||||||
|
- Не заявлять сертифицированную DLP/SIEM/EDR/XDR/СЗИ функциональность.
|
||||||
|
- Не использовать customer-specific название как публичное имя продукта.
|
||||||
|
- Не включать чувствительные runtime-данные в публичные документы.
|
||||||
|
|
||||||
|
## Результат
|
||||||
|
|
||||||
|
Документация готова к внешнему ознакомлению и не содержит ложных заявлений о
|
||||||
|
реализованных возможностях.
|
||||||
Reference in New Issue
Block a user