| 1 | --- |
| 2 | title: Integration template |
| 3 | --- |
| 4 | |
| 5 | # Integration name |
| 6 | |
| 7 | ## What this integration is |
| 8 | |
| 9 | ## Data path (how it flows) |
| 10 | |
| 11 | **Typical flow:** |
| 12 | |
| 13 | 1. Source system → **collector/ingestion** (External Service, integration job, webhook, or syslog) |
| 14 | 2. Events → **SIEM storage** (Wazuh Indexer / OpenSearch-backed) |
| 15 | 3. Optional: events → **Graylog** for search/streaming + alert definitions |
| 16 | 4. Alerts → `gl-events*` → **CoPilot Incident Management → Alerts** |
| 17 | 5. Operator workflow → **Cases**, evidence, response |
| 18 | |
| 19 | > Exact wiring varies by integration and environment. This section is meant to make expectations concrete. |
| 20 | |
| 21 | ## What data you get (high level) |
| 22 | |
| 23 | ## Setup (wireframe) |
| 24 | |
| 25 | - Where to configure it in CoPilot |
| 26 | - What credentials/permissions are typically needed (high level) |
| 27 | |
| 28 | ## Success criteria (what “working” looks like) |
| 29 | |
| 30 | - [ ] Events are arriving under the correct customer |
| 31 | - [ ] You can find a recent event and identify the source |
| 32 | |
| 33 | ## Dashboards |
| 34 | |
| 35 | - What dashboards get deployed during provisioning (if applicable) |
| 36 | - What “populated” looks like |
| 37 | |
| 38 | ## Alerts (starter set) |
| 39 | |
| 40 | List 3–5 high-signal starter detections. |
| 41 | |
| 42 | ## Troubleshooting |
| 43 | |
| 44 | If events aren’t showing up: |
| 45 | |
| 46 | - confirm connector/external service is verified |
| 47 | - confirm routing/tenant association |
| 48 | - confirm index/stream assumptions |
| 49 | - confirm Graylog alert plumbing (if used) |