AWatch-rus/docs/dlp-production-execution-roadmap.md

DLP Production Execution Roadmap

Purpose

This document converts the high-level production DLP plan into an execution sequence with explicit phase boundaries, dependencies, deliverables, and acceptance gates.

Source plan:

• dlp-production-plan-windows-10-19.md

Execution Rule

Execution order is based on dependency and operational value, not on the original stage numbering from the idea draft.

Phase Table

Phase	Name	Depends on	Primary outcome
01	Policy Engine	None	Central policy control plane with endpoint fallback
02	Content Analysis	01	Dictionary, regex, and OCR enrichment
03	Admin Tooling	01	Health checks and operator CLI
04	SIEM/SOAR Integrations	01, 03	External incident delivery and alerting
05	Case Management	01, 03	Investigation workflow and audit trail
06	Compliance Reporting	01, 02, 03, 05	Periodic reports for 152-FZ operations

Phase 01: Policy Engine

Goal Build the server-side policy control plane without breaking endpoint autonomy.

Deliverables

• aw-server/dlp-policy-engine/ service package
• SQLite-backed policy/version storage
• Active policy API
• rollback and backup flow
• endpoint server/local/cached policy modes
• Ansible deployment role and server integration

Acceptance

• Policies can be created, activated, versioned, and rolled back.
• Endpoints keep detecting while the policy service is unavailable.
• Invalid policies cannot become active.
• Operators can tell which policy source is active on each endpoint.

First tasks

• Create service skeleton and schema model.
• Define SQLite schema for policies and policy_versions.
• Add active policy endpoint and local cache contract.
• Update endpoint collector with -PolicyMode and cache fallback.
• Add Ansible variables and service deployment.

Phase 02: Content Analysis

Goal Increase detection quality with practical Russian PII and OCR enrichment.

Depends on

• Phase 01 active policy delivery

Deliverables

• 152-fz-pdn.json
• checksum validation module
• dictionary matcher
• regex packs for finance, contacts, and secrets
• OCR processor and server-side artifact enrichment
• endpoint policy fields for dictionary/regex/OCR

Acceptance

• Incidents can be enriched by dictionary and regex matches.
• SNILS/INN validation reduces false positives.
• OCR can be turned on and off via policy.
• Screenshot processing path is explicit and auditable.

First tasks

• Create checksum validator for INN and SNILS.
• Define server-side pack loading contract.
• Add policy fields for dictionaryPack, regexPack, and ocrEnabled.
• Implement OCR wrapper and artifact processing pipeline.
• Extend endpoint incident payload for OCR-bound artifacts.

Phase 03: Admin Tooling

Goal Replace ad hoc operational steps with one supported CLI and one health check path.

Depends on

• Phase 01 policy engine API

Deliverables

• scripts/dlp-admin-cli.py
• scripts/dlp-health-check.py
• health check coverage for API, service state, endpoint sync, and disk
• documented operational commands

Acceptance

• Operator can inspect policy, incident, case, and service state from CLI.
• Health checks have machine-readable exit codes.
• Critical failures are visible without manual DB access.

First tasks

• Define CLI command surface and argument model.
• Implement policy list/push and health check commands first.
• Add endpoint sync status probe.
• Add service/systemd state checks.
• Document standard operator usage.

Phase 04: SIEM/SOAR Integrations

Goal Export actionable incidents outside the AW UI.

Depends on

• Phase 01 policy engine
• Phase 03 admin tooling and health checks

Deliverables

• CEF exporter
• webhook sender
• systemd service/timer units
• Ansible deployment for integrations

Acceptance

• High-severity incidents reach syslog/webhook targets.
• Retry/backoff protects against transient delivery failure.
• Failed exports are visible through logs and health checks.

First tasks

• Define normalized export schema.
• Build CEF severity mapping.
• Implement webhook retry/backoff.
• Add integration service configs and timers.
• Extend health checks to include delivery status.

Phase 05: Case Management

Goal Introduce a practical incident-to-case workflow with immutable audit history.

Depends on

• Phase 01 policy engine
• Phase 03 admin tooling

Deliverables

• case API and schema
• SQLite case store
• case_audit append-only log
• UI hooks in aw-ru-patch.js and aw-case-management-ui.js

Acceptance

• Operator can create a case from a DLP incident.
• Case status changes preserve history.
• Evidence links remain attached through case lifecycle.

First tasks

• Define case model, status model, and audit table.
• Implement create/list/update case endpoints.
• Add incident-to-case action in UI.
• Expose related cases on incident view.
• Add CLI support for case creation and listing.

Phase 06: Compliance Reporting

Goal Generate scheduled DLP compliance reporting usable for 152-FZ operations.

Depends on

• Phase 01 policy engine
• Phase 02 content analysis
• Phase 03 admin tooling
• Phase 05 case management

Deliverables

• report generator
• HTML template
• PDF export via weasyprint
• monthly scheduler service/timer
• email delivery path

Acceptance

• Monthly report can be generated without manual data prep.
• Report includes incidents, channels, users, and case linkage where available.
• Scheduler health and last-success state are visible operationally.

First tasks

• Define report input model and time-period filters.
• Create HTML template and PDF renderer wrapper.
• Implement monthly scheduler.
• Add email delivery configuration.
• Extend health check for report freshness.

Release Discipline

• Deploy server components behind feature flags first.
• Keep endpoint fallback local until server path is proven.
• Pilot on a subset of Windows 10-19 before wide rollout.
• Do not enable OCR or external exports by default on first deployment wave.

Completion Standard

This roadmap is complete only when each phase has:

• deployed code
• Ansible coverage
• health checks
• operator documentation
• rollback notes
• a passed acceptance gate