14 lines
2.9 KiB
Markdown
14 lines
2.9 KiB
Markdown
# Centrally managed download evidence
|
|
|
|
Automatic collection is opt-in through signed `policy.evidence.enabled` and `policy.evidence.captureDownloads`, both off by default. Publishing an enabled policy requires the management service to have a separately protected `EVIDENCE_KEY_FILE`. The Admin console changes a draft through the normal signed publication and independent review workflow. Employees cannot override these controls.
|
|
|
|
The native download gate captures terminal allow/block decisions only when complete inspected file facts and the original managed context are available. The protected payload contains source URL with user information, query and fragment removed, sanitized filename, actual SHA-256, byte count, MIME claim and verdict/rule. Recognizable credential paths/names are excluded. File bytes, extracted text and OS save path are not collected. Interrupted/oversized/unfetched downloads do not invent file hashes; scan-only or cancelled saves do not create terminal evidence.
|
|
|
|
The source event UUID and protected payload share one DPAPI-encrypted audit-queue record. Queue updates use an exclusive temporary file, fsync and replacement. Delivery posts the ordinary event first, then evidence with that UUID. A failed evidence acknowledgement retains the pair for retry. The server treats identical replay as success and conflicting replay as an error, validates device ownership/source facts, and rechecks the fresh effective policy. Evidence never enters ordinary event metadata or SIEM exports.
|
|
|
|
Global disablement or expiry purges pending evidence while retaining security events and aborts in-flight evidence requests. Temporary managed-context unavailability pauses delivery. Already accepted evidence remains available under its separate audited access/retention rules; switching collection off does not erase an investigation. A request accepted before disablement cannot be retrospectively retracted.
|
|
|
|
Storage uses AES-256-GCM with authenticated record identity and an external owner-restricted key. Network upload now uses a dedicated application-layer PQ evidence channel over authenticated HTTPS (loopback HTTP is limited to development fixtures). It uses the pinned management signing identity, a distinct protocol domain, dual Ed25519/ML-DSA-87 challenge signatures, ephemeral ML-KEM-1024, HKDF-SHA384 and directional AES-256-GCM. Both the payload and its acknowledgement are encrypted. Device bearer authentication still depends on TLS; application encryption does not establish an individually signed device identity. The browser's DPAPI queue is scoped to the Windows user, not an isolated per-agent identity.
|
|
|
|
This increment automates download metadata only. Native click coordinates, clipboard excerpts, content-bearing forensic capture, consent/retention rollout by user profile, protected evidence key rotation and archive deletion require further implementation and deployment review. It does not imply full forensic replay or complete Chromium coverage.
|