| 1 | --- |
| 2 | title: Graylog management (alerting) |
| 3 | description: Define Graylog event alerts (detections) so CoPilot can ingest them into Incident Management. |
| 4 | --- |
| 5 | |
| 6 | # Graylog management (alerting) |
| 7 | |
| 8 | **Menu:** Log Management → Graylog Management |
| 9 | |
| 10 | This page is for **Admin / Engineer** workflows. |
| 11 | |
| 12 | CoPilot uses **Graylog** as the detection and alerting engine. If Graylog isn’t creating event alerts, CoPilot won’t have anything to ingest into **Incident Management → Alerts**. |
| 13 | |
| 14 |  |
| 15 | |
| 16 | --- |
| 17 | |
| 18 | ## How CoPilot alerting works (Graylog → gl-events* → CoPilot) |
| 19 | |
| 20 | 1) Your log metadata is ingested (Wazuh, O365, firewall, third-party, etc.) |
| 21 | 2) Graylog evaluates **Event Definitions** (your detection logic) |
| 22 | 3) When a condition matches, Graylog creates an **Event/Alert** and writes it to an index (commonly `gl-events*`) |
| 23 | 4) CoPilot reads those event alerts and creates/updates alerts in **Incident Management** |
| 24 | |
| 25 | --- |
| 26 | |
| 27 | ## Alert Provisioning (pre-built detections) |
| 28 | |
| 29 | SOCFortress ships a set of **pre-built alert provisioning items** to help you get alerts flowing quickly. |
| 30 | |
| 31 |  |
| 32 | |
| 33 | Examples visible in the lab: |
| 34 | - **WAZUH SYSLOG LEVEL ALERT** — triggers when `SYSLOG_LEVEL = ALERT` (usually set via pipeline when Wazuh rule level is > 11) |
| 35 | - **OFFICE365 EXCHANGE ONLINE** — example O365 alert source |
| 36 | - **OFFICE365 THREAT INTEL** — O365 threat intel alerts |
| 37 | - **CROWDSTRIKE ALERT** — CrowdStrike alerts |
| 38 | - **FORTINET SYSTEM / FORTINET UTM** — FortiGate alerts |
| 39 | - **PALOALTO ALERT** — Palo Alto alerts |
| 40 | |
| 41 | > These pre-built items assume you have pipeline rules that normalize key fields (for example: setting an `alert_severity` or equivalent “this is an alert” marker). |
| 42 | |
| 43 | --- |
| 44 | |
| 45 | ## Event Definitions (your detection logic) |
| 46 | |
| 47 | Event Definitions are where you define: |
| 48 | - the query/conditions |
| 49 | - aggregation/time window |
| 50 | - when an event should fire |
| 51 | |
| 52 |  |
| 53 | |
| 54 | Operator impact: |
| 55 | - Better event definitions → higher signal alerts → less noise in CoPilot. |
| 56 | |
| 57 | --- |
| 58 | |
| 59 | ## Custom alerts (build your own) |
| 60 | |
| 61 | You are not limited to SOCFortress pre-built detections. |
| 62 | |
| 63 | If you can ingest metadata into Graylog, you can create an alert off it. |
| 64 | |
| 65 | Practical examples: |
| 66 | - Alert on risky admin actions in Office 365 |
| 67 | - Alert on firewall activity to known phishing URLs |
| 68 | - Alert on anomalous authentication patterns |
| 69 | |
| 70 |  |
| 71 | |
| 72 | --- |
| 73 | |
| 74 | ## Related configuration (ties into Incident Sources) |
| 75 | |
| 76 | After Graylog is firing events, you still need CoPilot to map those events into an operator-friendly alert. |
| 77 | |
| 78 | Next step: |
| 79 | - Configure **Incident Sources** (field mappings for title/asset/time/context): |
| 80 | - [Incident sources (Graylog → Alerts)](/user/ui/incident-sources) |
| 81 | |
| 82 | --- |
| 83 | |
| 84 | ## Common gotchas |
| 85 | |
| 86 | ### “I configured a Graylog alert, but CoPilot alerts are missing context” |
| 87 | That’s typically an **Incident Sources mapping** issue: CoPilot needs to know which fields to treat as title, asset name, and context. |
| 88 | |
| 89 | ### “My detection is firing, but CoPilot shows nothing” |
| 90 | Confirm: |
| 91 | - the Event Definition actually creates events |
| 92 | - events are written to `gl-events*` |
| 93 | - CoPilot can read that index (permissions/connectivity) |