459 lines
12 KiB
Markdown
459 lines
12 KiB
Markdown
# 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
|