[New Integration] Veeam Backup & Replication integration

# [Epic] Veeam Backup & Replication integration

## Summary

Build a first-party Elastic integration for **Veeam Backup & Replication (VBR)** that ingests the full VBR event stream over **syslog**, normalises it to ECS, and ships security- and operations-focused dashboards.

VBR v12.1 forwards every event it writes to the Windows Event Log to an external syslog server (RFC 5424, over UDP/TCP/TLS; RFC 6587 octet framing on TCP/TLS). Each message carries an `instanceId` that maps to a documented event in the [VBR Event Reference](https://helpcenter.veeam.com/docs/vbr/events/event_id_list.html), so events can be classified deterministically by ID rather than by regex-matching free text.

There is no Elastic integration for Veeam today. Other popular SIEM vendors have one, so this is a parity gap on a platform that sits at the centre of most customers' ransomware recovery story.

## Why this matters

- **Backup infrastructure is a primary ransomware target.** Attackers delete restore points and disable MFA before they encrypt. Veeam emits discrete events for exactly those actions (`10050` Restore Point Deleted, `40201` Multi-Factor Authentication Disabled) and every event in the reference is pre-mapped by Veeam to **MITRE ATT&CK tactics/techniques and NIST 800-53r5 controls** — that mapping drops straight into our detection rules and compliance story.
- **VBR v12.1 added inline malware/ransomware detection** (entropy analysis, suspicious file activity, hardened repository events). These are high-signal SOC events with no out of the box path into Elastic today.
- **Two audiences, one package.** Security gets malware/audit/authorisation telemetry; Observability gets backup job health, restore sessions and repository capacity.

## Scope

**In scope**
- `veeam_backup` package, syslog input (`tcp` / `udp`, TLS on TCP), `logfile` fallback for customers who land syslog to disk first.
- RFC 5424 envelope parsing, then branch on `instanceId` for structured parsing of the priority event set.
- ECS mappings plus a `veeam.*` vendor namespace.
- Dashboards: backup operations, security activities.
- Docs covering the in-product syslog forwarding setup.

**Out of scope (follow-up epics)**
- Veeam ONE alarms — separate product, separate event model.
- Veeam Backup for Microsoft 365, Veeam Agent standalone, Veeam Service Provider Console.
- Detection rules (will be tracked in `elastic/detection-rules`, but field design here should anticipate them).

## Event coverage

The Event Reference groups ~230 events into 12 categories. Proposed v1 coverage:

| Category | ID range (approx) | Count | v1 coverage |
|---|---|---|---|
| Malware Detection | 41600–44202 | ~13 | highest security value |
| Users | 31200–44006 | ~25 | auth, roles, MFA, four-eyes |
| Configuration | 31000–40800 | ~15 | config change auditing |
| Credential Records | 25300–42500 | ~13 |
| Security & Compliance Analyzer | 42900–42903 | ~4|
| Backup | 10010–592 | ~50 | job outcomes, restore point lifecycle |
| Restore | 210–41510 | ~6 |
| Infrastructure Components | 25600–43006 | ~60 |
| Agent Management | 29100–44102 | ~8 |
| Licenses | 24010–41306 | ~11 |
| Plug-Ins for Enterprise Apps | 36011–36026 | ~6 |
| Cloud Connect | 24110–27000 | ~20 |

**Pipeline shape**
1. `syslog` processor / grok for the RFC 5424 envelope → timestamp, hostname, appname, structured data.
2. Extract `instanceId` and dispatch to a category sub-pipeline (engineering to confirm if this is the right path)
3. Enrich from the event-ID lookup (name, category, MITRE, NIST, severity).
4. Category sub-pipelines extract event-specific params (`DetectionTimeUTC`, `OibID`, `ActivityType`, job name, object name, user, etc.).
5. `on_failure` retains the raw message and tags rather than dropping.

**Key ECS mappings**
- `event.category` / `event.type` / `event.action` / `event.outcome` / `event.severity`, `event.code` = `instanceId`
- `host.*` for the VBR server; `observer.*` for the forwarder
- `user.*` for audit and authorisation events
- `threat.*` and `file.*` for malware detection events
- `related.user` / `related.host` / `related.ip` populated throughout

**Config surface:** listen host/port, protocol (UDP/TCP/TLS), TLS server cert/key + client CA, timezone handling, RFC framing options.

## Dashboards

**1. Veeam — Backup operations**
- Stat tiles: jobs Success / Warning / Failed, total data transferred
- Backup and copy jobs: daily trend
- SureBackup jobs: daily trend
- Finished jobs by state, broken out by object type (VMs, applications, physical machines, replicas, unstructured data, tape)
- Finished jobs by type — stacked daily trend
- Finished restore sessions by type — stacked daily trend
- Unsuccessful VM backups by server
- Unsuccessful unstructured data backups by server
- Latest configuration backups per server
- Latest finished jobs per server

**2. Veeam — Security activities**
- Security status (last 24h): Healthy / Warning / Critical
- Stat tiles: all security activities, marked as infected, marked as suspicious, four-eyes authorisation events
- Security events by severity
- Security events by name
- Daily security event trend by severity
- Latest security events by server
- Events by MITRE ATT&CK tactic, and a restore-point deletion / MFA-disabled watchlist panel

## References

- [VBR Event ID list](https://helpcenter.veeam.com/docs/vbr/events/event_id_list.html)
- [Malware detection events](https://helpcenter.veeam.com/docs/vbr/events/event_malware_detection.html)
- [How syslog server integration works](https://helpcenter.veeam.com/docs/vbr/userguide/syslog_servers_hiw.html)
- [KB4522 — advanced syslog integration options](https://www.veeam.com/kb4522)
- [Veeam App for Splunk dashboards](https://helpcenter.veeam.com/docs/security_plugins_splunk/guide/splunk_dashboards.html)