[New Integration] Cyberhaven

## 1. Summary
Collect data-loss and insider-risk incidents from Cyberhaven into Elastic Security. Cyberhaven detects risky data movement — files copied to USB, uploaded to cloud apps, sent by email, pasted into the browser, or printed — and each incident carries the full lineage of where the data came from and where it went. This brings those incidents, plus endpoint sensor status and admin audit activity, into Elastic for investigation and correlation.

## 2. Vendor and product
Cyberhaven is a data detection and response (DDR) platform. Its endpoint sensors track data lineage across a company's devices, cloud apps, browser, and email, and raise incidents when data moves in ways that break policy.

- **Transport:** Cyberhaven's REST API. The integration polls on a schedule; nothing needs to be opened inbound.
- **Auth:** an API key generated in the Cyberhaven console, exchanged for a short-lived bearer token. The customer supplies their tenant host and the API key.
- **Deployment:** built on CEL as an API pull, so it can run agentless — no Elastic Agent to deploy, Elastic-managed infrastructure does the polling.

## 3. Data
Three typed data streams:

- **Incidents** — the core. Each is a policy violation with severity, resolution status, the user, the file and its sensitivity, the matched policy, any PII involved, and — most valuably — the **data-lineage edge**: the source and destination of the movement, with the action type (upload, copy, clipboard, email send, print, move to USB, cloud app) and the surrounding context (hostname, app, browser URL, cloud provider, USB device, email account, printer). This is what makes Cyberhaven distinct — not just "a violation happened" but the full story of where the data went.
- **Endpoints** — sensor inventory and health: hostname, OS, group, sensor version, last check-in, and any health issues (inactive, extension missing, update needed). Useful for coverage and operational monitoring.
- **Audit log** — admin activity in the Cyberhaven console: policy, category and dataset changes, with before/after state.

Incidents are the v1 priority; endpoints and audit follow.

## 4. What we get
Cyberhaven incidents in Elastic, mapped to ECS and sitting next to a customer's other security data, so a data-exfiltration incident can be tied to the same user's endpoint, identity, and network activity already there. The lineage fields map to file, user, host, and destination context. Comes with a dashboard and detection rules for the cases that matter — sensitive data to personal cloud or USB, high-risk users, repeated exfiltration.

## 5. Dashboards
A Cyberhaven overview:
- incidents over time by severity and by resolution status
- movement by destination — USB, cloud app, email, browser, print
- top users and top datasets/sensitive-data categories involved
- most-affected files and endpoints
- a recent-incidents table for triage

An endpoint-coverage view (sensor health, versions, inactive sensors) and an admin-audit view follow their data streams.

## 6. References
- [Cyberhaven public API (OpenAPI/ReDoc)](https://storage.googleapis.com/cyberhaven-docs/redoc-static.html)
- [Cyberhaven documentation](https://docs.cyberhaven.io/)
- [Cyberhaven integrations](https://www.cyberhaven.com/product/integrations)

Start with Cyberhaven’s public API (OpenAPI/ReDoc) and documentation to confirm authentication and payloads. Implement incidents first, then endpoints and audit, covering the ECS mapping, overview dashboard, and detection rules described in the issue. Done means the three data streams are available in Elastic with the requested dashboards and detections.

Written by the indexing model from the issue text.