AWatch-rus/docs/dlp-production-plan-windows-10-19.md

Production DLP Plan for Windows 10-19

Goal

Build a reliable, easy-to-deploy, and maintainable production DLP system on top of the existing AWatch-rus platform, with Windows hosts 10-19 as the primary target scope.

This plan assumes the current baseline already exists:

• Windows collectors for endpoint/browser/email/file telemetry
• ActivityWatch-based ingestion and Web UI overlays
• Ansible deployment for AW server and Windows endpoints
• InnoSetup-based Windows install kit

Scope

In scope:

• Centralized DLP policy lifecycle
• Advanced practical content analysis for Russian personal data
• SIEM/SOAR exports and notifications
• Case management for investigations
• Compliance reporting
• Administrative tooling and health checks

Out of scope for this phase:

• Full enterprise RBAC/SoD model
• Multi-tenant administration
• Heavy ML/UEBA
• Approval workflows more complex than basic policy rollback/case review

Delivery Principles

• Keep deployment simple: Python + SQLite + systemd on server, PowerShell on endpoints.
• Default to last-known-good behavior on every critical component.
• Do not break current Phase-1/2 DLP behavior while adding server-side controls.
• Prefer additive rollout behind feature flags and config toggles.
• Every new service must have Ansible deployment, health checks, logs, and rollback notes.

Current Baseline and Gap

Current AWatch-rus DLP already provides:

• Rule-based endpoint detection
• Incident buckets and review UI
• Basic enforcement for clipboard/USB/print
• Email/file/browser collectors
• Initial reliability hardening work

Main gap to production DLP:

• Policies are still too endpoint-local
• Content analysis is not centralized or rich enough
• Incident export/investigation/reporting chain is incomplete
• Health/operations model is not yet unified

Stage 1: Policy Engine

Objective

Centralize policy management and distribution without breaking endpoint autonomy.

Files

• aw-server/dlp-policy-engine/policy_service.py
• aw-server/dlp-policy-engine/policy_schema.py
• aw-server/dlp-policy-engine/policy_storage.py
• aw-server/dlp-policy-engine/policy_distributor.py
• aw-server/dlp-policy-engine/requirements.txt
• aw-server/dlp-policy-engine/dlp-policy-engine.service
• ansible/roles/dlp-policy-engine/tasks/main.yml
• docs/dlp-policy-engine.md
• windows/dlp-policy-client.ps1

Server responsibilities

• REST API:
  • GET /api/0/dlp/policies
  • POST /api/0/dlp/policies
  • PUT /api/0/dlp/policies/{id}
  • DELETE /api/0/dlp/policies/{id}
  • GET /api/0/dlp/policies/active
• SQLite-backed storage with version history in policy_versions
• Validation through Pydantic and JSON schema before activation
• Backup and rollback of active policy versions
• Heartbeat-aware policy distribution model

Endpoint changes

Update windows/dlp-endpoint-signals-collector.ps1:

• add -PolicyMode with values local and server
• in server mode pull active policy every 5 minutes
• cache last valid server policy locally
• fallback to local cached policy if server is unavailable

Acceptance criteria

• Policy can be created, versioned, activated, and rolled back through API.
• Endpoints continue working during policy engine outage.
• Invalid policy cannot become active.
• Endpoint logs clearly show source of active policy: local, server, or cached.

Main risks

• Breaking current local-policy-only flow
• Partial rollout where server mode is enabled before engine is healthy
• Policy drift between server and endpoints

Risk controls

• Feature flag: aw_dlp_policy_engine_enabled
• Default endpoint mode remains local until validation is complete
• Store active policy checksum/version on both server and endpoint

Stage 2: Advanced Content Analysis

Objective

Add practical, legally relevant detection quality without overengineering.

2.1 Dictionary packs for 152-FZ personal data

Files

• aw-server/dlp-content-analysis/dictionaries/152-fz-pdn.json
• aw-server/dlp-content-analysis/checksum_validator.py
• aw-server/dlp-content-analysis/dictionary_matcher.py

Required capabilities

• Detect:
  • INN
  • SNILS
  • Russian passport patterns
• Validate checksums where applicable to reduce false positives

2.2 Regex packs

Files

• aw-server/dlp-content-analysis/regex-packs/financial.json
• aw-server/dlp-content-analysis/regex-packs/contacts.json
• aw-server/dlp-content-analysis/regex-packs/secrets.json

Required capabilities

• Reusable grouped pattern packs
• Server-defined matching rules distributed via policy
• Match metadata attached to incidents

2.3 OCR for screenshots

Files

• aw-server/dlp-content-analysis/ocr_processor.py
• aw-server/dlp-content-analysis/requirements.txt
• ansible/roles/dlp-content-analysis/tasks/main.yml

Required capabilities

• Tesseract wrapper for screenshots in incident_artifacts
• OCR text sent through regex and dictionary pipeline
• OCR enrichment attached to the original incident

2.4 Endpoint integration

Update:

• windows/dlp-policy.example.json
• windows/dlp-endpoint-signals-collector.ps1

Add policy fields:

• dictionaryPack
• regexPack
• ocrEnabled

Endpoint behavior:

• load server-delivered dictionary/regex references
• perform checksum-aware validation for supported PII
• upload screenshots for OCR when enabled by policy

Acceptance criteria

• Server can enrich incidents with dictionary, regex, and OCR findings.
• False positives are reduced through checksum validation.
• OCR can be disabled per policy without code changes.
• Screenshot upload path is explicit and logged.

Main risks

• OCR cost and latency
• Privacy overreach from over-collecting screenshots
• Regex pack sprawl and poor maintainability

Risk controls

• OCR disabled by default
• Artifact retention policy documented
• Pack ownership and naming convention enforced

Stage 3: SIEM and SOAR Integrations

Objective

Make DLP incidents operational outside the AW UI.

3.1 CEF exporter

Files

• aw-server/dlp-integrations/cef_exporter.py
• aw-server/dlp-integrations/cef-config.yaml
• aw-server/dlp-integrations/cef-exporter.service
• aw-server/dlp-integrations/cef-exporter.timer

Required capabilities

• Read normalized incidents from SQLite/PostgreSQL
• Convert incidents to CEF
• Send via syslog
• Map DLP severities to CEF severities

3.2 Webhook notifications

Files

• aw-server/dlp-integrations/webhook_sender.py
• aw-server/dlp-integrations/webhook-config.yaml

Required capabilities

• Notify on severity=high
• Retry with backoff
• Include incident details, source host, user, rule, and evidence link

3.3 Ansible integration

Update ansible/deploy_aw_server.yml:

• install Python dependencies
• deploy configs/services/timers
• manage enable/start state

Acceptance criteria

• High-severity incidents can be exported to SIEM and webhook endpoints.
• Export failures are visible and retry safely.
• Timers/services are idempotently managed by Ansible.

Main risks

• Duplicate exports
• Alert fatigue
• Silent delivery failure to external systems

Risk controls

• Event ID based dedupe
• Severity thresholding
• Delivery logs and health checks

Stage 4: Case Management

Objective

Provide a practical investigation workflow without introducing a heavy IR platform.

Files

• aw-server/dlp-case-management/case_service.py
• aw-server/dlp-case-management/case_schema.py
• aw-server/dlp-case-management/case_storage.py
• aw-server/dlp-case-management/case-service.service
• install-kit-awindows-20260427-211240/aw-server/aw-case-management-ui.js

Required capabilities

• Create a case from an incident
• Attach evidence links
• Support statuses:
  • open
  • investigating
  • resolved
  • closed
• Support comments
• Maintain immutable audit records in case_audit

UI integration

Update install-kit-awindows-20260427-211240/aw-server/aw-ru-patch.js:

• add Create case action in DLP review table
• add Case Management section in UI
• show linked cases on incident views

Acceptance criteria

• An operator can create and track a case directly from a DLP incident.
• Evidence remains linked after status transitions.
• Case audit trail is append-only.

Main risks

• UI debt in current patch overlay
• Weak evidence chain semantics
• Mixing incident review and case workflow logic

Risk controls

• Keep case service isolated from core AW server
• Use immutable audit table
• Treat evidence as links/references first, not copied blobs

Stage 5: Compliance Reporting

Objective

Generate regular compliance-grade reporting for Russian personal data handling.

Files

• aw-server/dlp-compliance/report_generator.py
• aw-server/dlp-compliance/templates/152-fz-report.html
• aw-server/dlp-compliance/report-scheduler.service
• aw-server/dlp-compliance/report-scheduler.timer

Required capabilities

• Period incident report
• Leak-channel statistics
• User statistics
• PDF export via weasyprint
• Scheduled email delivery

Acceptance criteria

• Monthly report can be generated unattended.
• Report includes traceable source metrics.
• Output is usable by operations/compliance without manual cleanup.

Main risks

• Weak data quality in upstream incidents
• PDF rendering dependency issues
• Email delivery failures

Risk controls

• Validate report inputs before generation
• Keep HTML template under version control
• Add health check for scheduler and last successful report

Stage 6: Administrative Tooling

Objective

Make the whole stack operable without manual database edits or ad hoc scripts.

Files

• scripts/dlp-admin-cli.py
• scripts/dlp-health-check.py

Required CLI functions

• python3 dlp-admin-cli.py policies list
• python3 dlp-admin-cli.py policies push --host HOSTNAME
• python3 dlp-admin-cli.py incidents list --severity high
• python3 dlp-admin-cli.py cases create --incident-id ID
• python3 dlp-admin-cli.py health check

Health checks

• API endpoint availability
• endpoint reachability and policy sync state
• queue health if implemented
• disk space
• systemd service state

Acceptance criteria

• Operator can inspect policy, incident, case, and service health from CLI.
• Health check has machine-readable exit status.
• All critical services are covered by a single operational runbook.

Cross-Cutting Ansible Work

Update:

• ansible/deploy_aw_server.yml
• ansible/group_vars/all.example.yml
• ansible/roles/dlp-policy-engine/tasks/main.yml
• ansible/roles/dlp-content-analysis/tasks/main.yml

Required variables:

• aw_dlp_policy_engine_enabled: true
• aw_dlp_policy_engine_port: 5601

Ansible quality bar:

• idempotent
• rollback-aware
• systemd-managed
• config templated, not hand-edited in prod

Execution Order

1. Stage 1: Policy Engine
2. Stage 2: Advanced Content Analysis
3. Stage 6: Administrative Tooling
4. Stage 3: SIEM and SOAR Integrations
5. Stage 4: Case Management
6. Stage 5: Compliance Reporting

Rationale:

• centralized policies are the control plane
• content analysis increases signal quality
• admin tooling is needed before broadening operations
• integrations, cases, and reports depend on stable normalized incidents

Release Strategy

Wave 1

• Deploy policy engine on AW server
• Keep endpoints in local mode
• Validate API, versioning, rollback

Wave 2

• Enable server policy mode for a pilot subset of Windows 10-19
• Validate cache/fallback behavior
• Measure heartbeat and policy freshness

Wave 3

• Roll out dictionary/regex/OCR selectively
• Enable SIEM/webhook export
• Stabilize case management and reporting

Definition of Done

The plan is considered implemented only when:

• all new services are deployed by Ansible
• endpoint fallback works under server outage
• policy activation/rollback is proven
• content analysis is documented and testable
• SIEM/webhook integrations are observable
• case workflow is usable from UI
• monthly compliance report is generated automatically
• admin CLI and health checks replace ad hoc operational steps

Deliverables Checklist

• Policy engine service and API
• Endpoint policy client and cache/fallback
• SQLite policy versioning and rollback
• Dictionary packs for 152-FZ
• Regex packs for financial/contact/secret data
• OCR processing pipeline
• CEF exporter
• Webhook sender
• Case management service and UI integration
• 152-FZ report generator and scheduler
• Administrative CLI
• Unified health check
• Ansible deployment coverage
• Operational documentation