Docs: Mintlify restructure + operator/admin guides + integrations (#718)
* docs: improve Get Started flow + enlarge hero video * docs: mintlify restructure + operator playbooks + integrations --------- Co-authored-by: Clawdbot <clawdbot@Clawdbots-Mac-mini.local>
taylorcopilot committed
Feb 15, 2026 at 13:59 UTC
40fc400acd8e6376e7a8ba74bfcb939f775fb783
153 files changed
+5217
-263
docs/admin.mdx
new
+32
@@ -0,0 +1,32 @@
1
+---
2
+title: Admin / Platform Guide
3
+description: Provisioning, integrations/connectors, and platform reliability for CoPilot.
4
+---
5
+
6
+# Admin / Platform Guide
7
+
8
+This section is organized around **data onboarding and reliability**.
9
+
10
+## Start here
11
+
12
+- [Admin/Engineer quickstart](/user/admins-quickstart)
13
+- [First wins (30 minutes)](/getting-started/first-wins)
14
+
15
+## Tenancy & onboarding
16
+
17
+- [Customer provisioning](/user/customer-provisioning)
18
+- [Customers (UI reference)](/user/ui/customers)
19
+
20
+## Integrations & connectors
21
+
22
+- [3rd‑party integrations](/user/ui/external-third-party-integrations)
23
+- [Network connectors](/user/ui/external-network-connectors)
24
+
25
+## Platform health
26
+
27
+- [Indices management](/user/ui/indices-management)
28
+- [Graylog management](/user/ui/graylog-management)
29
+
30
+## Video walkthroughs
31
+
32
+- [Admin/Engineer track videos](/user/videos#adminengineer-track)
docs/assets/hero/customer-provisioning-walkthrough-thumb.jpg
Binary files /dev/null and b/docs/assets/hero/customer-provisioning-walkthrough-thumb.jpg differ
docs/assets/images/crowdstrike/crowdstrike_api_settings.png
Binary files /dev/null and b/docs/assets/images/crowdstrike/crowdstrike_api_settings.png differ
docs/assets/images/crowdstrike/docker_ps.PNG
Binary files /dev/null and b/docs/assets/images/crowdstrike/docker_ps.PNG differ
docs/assets/ui/agents-copilot-actions-action-details.png
Binary files /dev/null and b/docs/assets/ui/agents-copilot-actions-action-details.png differ
docs/assets/ui/agents-copilot-actions-invoke.png
Binary files /dev/null and b/docs/assets/ui/agents-copilot-actions-invoke.png differ
docs/assets/ui/agents-copilot-actions-overview.png
Binary files /dev/null and b/docs/assets/ui/agents-copilot-actions-overview.png differ
docs/assets/ui/agents-copilot-actions-results.png
Binary files /dev/null and b/docs/assets/ui/agents-copilot-actions-results.png differ
docs/assets/ui/agents-detection-rules-edit.png
Binary files /dev/null and b/docs/assets/ui/agents-detection-rules-edit.png differ
docs/assets/ui/agents-detection-rules-list.png
Binary files /dev/null and b/docs/assets/ui/agents-detection-rules-list.png differ
docs/assets/ui/agents-detection-rules-restart.png
Binary files /dev/null and b/docs/assets/ui/agents-detection-rules-restart.png differ
docs/assets/ui/agents-detection-rules-search.png
Binary files /dev/null and b/docs/assets/ui/agents-detection-rules-search.png differ
docs/assets/ui/agents-groups-advanced-fields.png
Binary files /dev/null and b/docs/assets/ui/agents-groups-advanced-fields.png differ
docs/assets/ui/agents-groups-details.png
Binary files /dev/null and b/docs/assets/ui/agents-groups-details.png differ
docs/assets/ui/agents-groups-list.png
Binary files /dev/null and b/docs/assets/ui/agents-groups-list.png differ
docs/assets/ui/agents-sca-overview-filters.png
Binary files /dev/null and b/docs/assets/ui/agents-sca-overview-filters.png differ
docs/assets/ui/agents-sca-overview-load.png
Binary files /dev/null and b/docs/assets/ui/agents-sca-overview-load.png differ
docs/assets/ui/agents-sca-overview-results.png
Binary files /dev/null and b/docs/assets/ui/agents-sca-overview-results.png differ
docs/assets/ui/agents-sysmon-config-edit.png
Binary files /dev/null and b/docs/assets/ui/agents-sysmon-config-edit.png differ
docs/assets/ui/agents-sysmon-config-overview.png
Binary files /dev/null and b/docs/assets/ui/agents-sysmon-config-overview.png differ
docs/assets/ui/agents-sysmon-config-reload.png
Binary files /dev/null and b/docs/assets/ui/agents-sysmon-config-reload.png differ
docs/assets/ui/agents-vulnerability-overview-distribution.png
Binary files /dev/null and b/docs/assets/ui/agents-vulnerability-overview-distribution.png differ
docs/assets/ui/agents-vulnerability-overview-filters.png
Binary files /dev/null and b/docs/assets/ui/agents-vulnerability-overview-filters.png differ
docs/assets/ui/agents-vulnerability-overview-table.png
Binary files /dev/null and b/docs/assets/ui/agents-vulnerability-overview-table.png differ
docs/assets/ui/agents-vulnerability-overview-top-packages.png
Binary files /dev/null and b/docs/assets/ui/agents-vulnerability-overview-top-packages.png differ
docs/assets/ui/alerts-siem-filters.png
Binary files /dev/null and b/docs/assets/ui/alerts-siem-filters.png differ
docs/assets/ui/alerts-siem-overview.png
Binary files /dev/null and b/docs/assets/ui/alerts-siem-overview.png differ
docs/assets/ui/artifacts-collect.png
Binary files /dev/null and b/docs/assets/ui/artifacts-collect.png differ
docs/assets/ui/artifacts-recommendation.png
Binary files /dev/null and b/docs/assets/ui/artifacts-recommendation.png differ
docs/assets/ui/artifacts-results.png
Binary files /dev/null and b/docs/assets/ui/artifacts-results.png differ
docs/assets/ui/graylog-alert-provisioning.png
Binary files /dev/null and b/docs/assets/ui/graylog-alert-provisioning.png differ
docs/assets/ui/graylog-custom-alert.png
Binary files /dev/null and b/docs/assets/ui/graylog-custom-alert.png differ
docs/assets/ui/graylog-event-definitions.png
Binary files /dev/null and b/docs/assets/ui/graylog-event-definitions.png differ
docs/assets/ui/healthcheck-alerts.png
Binary files /dev/null and b/docs/assets/ui/healthcheck-alerts.png differ
docs/assets/ui/healthcheck-check-names.png
Binary files /dev/null and b/docs/assets/ui/healthcheck-check-names.png differ
docs/assets/ui/healthcheck-overview.png
Binary files /dev/null and b/docs/assets/ui/healthcheck-overview.png differ
docs/assets/ui/healthcheck-thresholds.png
Binary files /dev/null and b/docs/assets/ui/healthcheck-thresholds.png differ
docs/assets/ui/incident-alerts-create-ioc.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-create-ioc.png differ
docs/assets/ui/incident-alerts-details-assets.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-details-assets.png differ
docs/assets/ui/incident-alerts-details-comments.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-details-comments.png differ
docs/assets/ui/incident-alerts-details-iocs.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-details-iocs.png differ
docs/assets/ui/incident-alerts-details-overview.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-details-overview.png differ
docs/assets/ui/incident-alerts-filters-customer-tag.png
Binary files /dev/null and b/docs/assets/ui/incident-alerts-filters-customer-tag.png differ
docs/assets/ui/incident-cases-details-alerts.png
Binary files /dev/null and b/docs/assets/ui/incident-cases-details-alerts.png differ
docs/assets/ui/incident-cases-details-comments.png
Binary files /dev/null and b/docs/assets/ui/incident-cases-details-comments.png differ
docs/assets/ui/incident-cases-details-datastore.png
Binary files /dev/null and b/docs/assets/ui/incident-cases-details-datastore.png differ
docs/assets/ui/incident-cases-details-overview.png
Binary files /dev/null and b/docs/assets/ui/incident-cases-details-overview.png differ
docs/assets/ui/incident-cases-generate-report.png
Binary files /dev/null and b/docs/assets/ui/incident-cases-generate-report.png differ
docs/assets/ui/incident-sources-create-source.png
Binary files /dev/null and b/docs/assets/ui/incident-sources-create-source.png differ
docs/assets/ui/incident-sources-field-mapping.png
Binary files /dev/null and b/docs/assets/ui/incident-sources-field-mapping.png differ
docs/assets/ui/incident-sources-graylog-event-def.png
Binary files /dev/null and b/docs/assets/ui/incident-sources-graylog-event-def.png differ
docs/assets/ui/incident-sources-list.png
Binary files /dev/null and b/docs/assets/ui/incident-sources-list.png differ
docs/assets/ui/indices-management-customer-storage.png
Binary files /dev/null and b/docs/assets/ui/indices-management-customer-storage.png differ
docs/assets/ui/indices-management-delete-index.png
Binary files /dev/null and b/docs/assets/ui/indices-management-delete-index.png differ
docs/assets/ui/indices-management-health.png
Binary files /dev/null and b/docs/assets/ui/indices-management-health.png differ
docs/assets/ui/indices-snapshots-create-snapshot.png
Binary files /dev/null and b/docs/assets/ui/indices-snapshots-create-snapshot.png differ
docs/assets/ui/indices-snapshots-repos.png
Binary files /dev/null and b/docs/assets/ui/indices-snapshots-repos.png differ
docs/assets/ui/indices-snapshots-restore.png
Binary files /dev/null and b/docs/assets/ui/indices-snapshots-restore.png differ
docs/assets/ui/indices-snapshots-schedule.png
Binary files /dev/null and b/docs/assets/ui/indices-snapshots-schedule.png differ
docs/assets/ui/patch-tuesday-cve-card.png
Binary files /dev/null and b/docs/assets/ui/patch-tuesday-cve-card.png differ
docs/assets/ui/patch-tuesday-filters.png
Binary files /dev/null and b/docs/assets/ui/patch-tuesday-filters.png differ
docs/assets/ui/patch-tuesday-kev-toggle.png
Binary files /dev/null and b/docs/assets/ui/patch-tuesday-kev-toggle.png differ
docs/assets/ui/patch-tuesday-summary.png
Binary files /dev/null and b/docs/assets/ui/patch-tuesday-summary.png differ
docs/assets/ui/power-atomic-red-team-overview.png
Binary files /dev/null and b/docs/assets/ui/power-atomic-red-team-overview.png differ
docs/assets/ui/power-atomic-red-team-results.png
Binary files /dev/null and b/docs/assets/ui/power-atomic-red-team-results.png differ
docs/assets/ui/power-atomic-red-team-run.png
Binary files /dev/null and b/docs/assets/ui/power-atomic-red-team-run.png differ
docs/assets/ui/power-mitre-attack-overview.png
Binary files /dev/null and b/docs/assets/ui/power-mitre-attack-overview.png differ
docs/assets/ui/power-mitre-attack-tabs.png
Binary files /dev/null and b/docs/assets/ui/power-mitre-attack-tabs.png differ
docs/assets/ui/power-mitre-attack-technique.png
Binary files /dev/null and b/docs/assets/ui/power-mitre-attack-technique.png differ
docs/assets/ui/report-general-panels.png
Binary files /dev/null and b/docs/assets/ui/report-general-panels.png differ
docs/assets/ui/report-general-wizard.png
Binary files /dev/null and b/docs/assets/ui/report-general-wizard.png differ
docs/assets/ui/report-sca-generate.png
Binary files /dev/null and b/docs/assets/ui/report-sca-generate.png differ
docs/assets/ui/report-sca-overview.png
Binary files /dev/null and b/docs/assets/ui/report-sca-overview.png differ
docs/assets/ui/report-vulnerability-filters.png
Binary files /dev/null and b/docs/assets/ui/report-vulnerability-filters.png differ
docs/assets/ui/report-vulnerability-generate.png
Binary files /dev/null and b/docs/assets/ui/report-vulnerability-generate.png differ
docs/docs.json
+112
-186
@@ -2,7 +2,7 @@
2
"$schema": "https://mintlify.com/docs.json",
3
"theme": "mint",
4
"name": "SOCFortress CoPilot",
5
- "description": "SOCFortress CoPilot documentation — operator workflows, admin/engineer configuration, and developer/AI-agent guides.",
5
+ "description": "SOCFortress CoPilot documentation \u2014 operator workflows, admin/engineer configuration, and developer/AI-agent guides.",
6
"logo": {
7
"light": "/assets/brand/logo-text.png",
8
"dark": "/assets/brand/logo-text.png",
@@ -18,58 +18,25 @@
18
"tabs": [
19
{
20
"tab": "Get Started",
21
- "groups": [
22
- {
23
- "group": "Welcome",
24
- "pages": [
25
- "index",
26
- "getting-started/what-is-copilot",
27
- "getting-started/roles-and-mental-model",
28
- "getting-started/first-wins"
29
- ]
30
- },
31
- {
32
- "group": "Quickstarts",
33
- "pages": [
34
- "user/operators-quickstart",
35
- "user/admins-quickstart"
36
- ]
37
- },
38
- {
39
- "group": "Core concepts",
40
- "pages": [
41
- "user/overview",
42
- "user/navigation",
43
- "user/features"
44
- ]
45
- },
46
- {
47
- "group": "Watch next",
48
- "pages": [
49
- {
50
- "title": "Operator track videos",
51
- "href": "/user/videos#operator-track"
52
- },
53
- {
54
- "title": "Admin/Engineer track videos",
55
- "href": "/user/videos#adminengineer-track"
56
- }
57
- ]
58
- }
21
+ "pages": [
22
+ "getting-started/start-here",
23
+ "getting-started/what-is-copilot",
24
+ "getting-started/roles-and-mental-model",
25
+ "getting-started/first-wins",
26
+ "user/operators-quickstart",
27
+ "user/admins-quickstart",
28
+ "user/overview",
29
+ "user/navigation",
30
+ "user/features"
31
]
32
},
33
{
34
"tab": "Operator",
63
- "groups": [
64
- {
65
- "group": "Start here",
66
- "pages": [
67
- "operator/index",
68
- "user/operators-quickstart"
69
- ]
70
- },
35
+ "pages": [
36
+ "operator",
37
+ "user/operators-quickstart",
38
{
72
- "group": "Incident workflow",
39
+ "group": "Incident Management",
40
"pages": [
41
"user/ui/incident-alerts",
42
"user/ui/incident-cases",
@@ -77,200 +44,159 @@
44
]
45
},
46
{
80
- "group": "Reference (by menu)",
81
- "pages": [
82
- "user/ui/incident-management",
83
- "user/ui/incident-sources"
84
- ]
85
- },
86
- {
87
- "group": "Videos",
88
- "pages": [
89
- {
90
- "title": "Operator track",
91
- "href": "/user/videos#operator-track"
92
- },
93
- "user/videos"
94
- ]
95
- }
96
- ]
97
- },
98
- {
99
- "tab": "Admin / Platform",
100
- "groups": [
101
- {
102
- "group": "Start here",
47
+ "group": "Agents",
48
"pages": [
104
- "admin/index",
105
- "user/admins-quickstart",
106
- "user/customer-provisioning"
49
+ "user/ui/agents",
50
+ "user/ui/agents-groups",
51
+ "user/ui/agents-sysmon-config",
52
+ "user/ui/agents-detection-rules",
53
+ "user/ui/agents-copilot-actions",
54
+ "user/ui/agents-vulnerability-overview",
55
+ "user/ui/agents-patch-tuesday",
56
+ "user/ui/agents-sca-overview"
57
]
58
},
59
{
110
- "group": "Integrations & connectors",
60
+ "group": "SOCFortress Capsules",
61
"pages": [
112
- "user/ui/external-third-party-integrations",
113
- "user/ui/external-network-connectors"
62
+ "user/capsules/index"
63
]
64
},
65
{
117
- "group": "Platform (by menu)",
66
+ "group": "Reporting",
67
"pages": [
119
- "user/ui/customers",
120
- "user/ui/indices-management",
121
- "user/ui/graylog-management",
122
- "user/ui/graylog-pipelines",
123
- "user/ui/graylog-metrics"
68
+ "user/ui/report-creation",
69
+ "user/ui/report-general",
70
+ "user/ui/report-vulnerability",
71
+ "user/ui/report-sca"
72
]
73
},
74
{
75
"group": "Videos",
76
"pages": [
129
- {
130
- "title": "Admin/Engineer track",
131
- "href": "/user/videos#adminengineer-track"
132
- },
77
"user/videos"
78
]
79
}
80
]
81
},
82
{
139
- "tab": "Developer",
140
- "groups": [
83
+ "tab": "Admin / Platform",
84
+ "pages": [
85
+ "admin",
86
+ "user/admins-quickstart",
87
{
142
- "group": "Start here",
88
+ "group": "Log ingestion",
89
"pages": [
144
- "developer/start-here"
90
+ "user/customer-provisioning",
91
+ "user/ui/external-third-party-integrations",
92
+ "user/ui/external-network-connectors"
93
]
94
},
95
{
148
- "group": "Architecture",
96
+ "group": "Alerting (Graylog \u2192 CoPilot)",
97
"pages": [
150
- "architecture/ARCHITECTURE",
151
- "architecture/MAP",
152
- "architecture/DEPLOYMENT",
153
- "architecture/DATA_FLOWS",
154
- "architecture/DATABASE_SCHEMA"
98
+ "user/ui/incident-sources",
99
+ "user/ui/graylog-management"
100
]
101
},
102
{
158
- "group": "Integrations",
103
+ "group": "Indices (Wazuh Indexer)",
104
"pages": [
160
- "integrations/ADDING_A_CONNECTOR"
105
+ "user/ui/indices-management",
106
+ "user/ui/indices-snapshots"
107
]
108
},
109
{
164
- "group": "Videos",
110
+ "group": "Health (InfluxDB)",
111
"pages": [
166
- {
167
- "title": "Browse videos",
168
- "href": "/user/videos"
169
- }
112
+ "user/ui/healthcheck"
113
]
171
- }
114
+ },
115
+ "user/videos"
116
]
117
},
118
{
175
- "tab": "Videos",
119
+ "tab": "Integrations",
120
"groups": [
121
{
178
- "group": "Library",
122
+ "group": "Catalog",
123
"pages": [
180
- "videos/index",
181
- "user/videos"
124
+ "integrations",
125
+ "integrations/wazuh",
126
+ "integrations/office-365",
127
+ "integrations/mimecast",
128
+ "integrations/huntress",
129
+ "integrations/crowdstrike",
130
+ "integrations/duo",
131
+ "integrations/defender-for-endpoint",
132
+ "integrations/bitdefender",
133
+ "integrations/carbon-black",
134
+ "integrations/cato-networks",
135
+ "integrations/darktrace",
136
+ "integrations/sap-siem"
137
]
138
},
139
{
185
- "group": "Role tracks",
140
+ "group": "Network connectors (syslog)",
141
"pages": [
187
- {
188
- "title": "Operator track",
189
- "href": "/user/videos#operator-track"
190
- },
191
- {
192
- "title": "Admin/Engineer track",
193
- "href": "/user/videos#adminengineer-track"
194
- }
142
+ "integrations/network-connectors",
143
+ "integrations/network-connectors/fortigate",
144
+ "integrations/network-connectors/palo-alto",
145
+ "integrations/network-connectors/cisco-asa",
146
+ "integrations/network-connectors/sonicwall",
147
+ "integrations/network-connectors/opnsense",
148
+ "integrations/network-connectors/sentinelone"
149
]
150
}
151
]
152
},
153
{
200
- "tab": "UI Reference",
154
+ "tab": "Power Features",
155
"groups": [
156
{
203
- "group": "Overview",
204
- "pages": [
205
- "user/ui/overview"
206
- ]
207
- },
208
- {
209
- "group": "Incident Management",
210
- "pages": [
211
- "user/ui/incident-management",
212
- "user/ui/incident-alerts",
213
- "user/ui/incident-cases",
214
- "user/ui/incident-sources"
215
- ]
216
- },
217
- {
218
- "group": "Customers",
219
- "pages": [
220
- "user/ui/customers",
221
- "user/customer-provisioning",
222
- "user/ui/external-third-party-integrations",
223
- "user/ui/external-network-connectors",
224
- "user/ui/external-services",
225
- "user/ui/connectors"
226
- ]
227
- },
228
- {
229
- "group": "Graylog",
230
- "pages": [
231
- "user/ui/graylog",
232
- "user/ui/graylog-management",
233
- "user/ui/graylog-pipelines",
234
- "user/ui/graylog-metrics"
235
- ]
236
- },
237
- {
238
- "group": "Indices",
239
- "pages": [
240
- "user/ui/indices",
241
- "user/ui/indices-management",
242
- "user/ui/indices-snapshots"
243
- ]
244
- },
245
- {
246
- "group": "Agents",
157
+ "group": "Add-ons",
158
"pages": [
248
- "user/ui/agents",
249
- "user/ui/agents-groups",
250
- "user/ui/agents-vulnerability-overview",
251
- "user/ui/agents-sca-overview",
252
- "user/ui/agents-sysmon-config",
253
- "user/ui/agents-patch-tuesday",
254
- "user/ui/agents-detection-rules",
255
- "user/ui/agents-copilot-actions"
256
- ]
257
- },
258
- {
259
- "group": "Reports",
260
- "pages": [
261
- "user/ui/report-general",
262
- "user/ui/report-creation",
263
- "user/ui/report-sca",
264
- "user/ui/report-vulnerability"
159
+ "power-features",
160
+ "power-features/mitre-attack",
161
+ "power-features/patch-tuesday",
162
+ "power-features/cloud-security-assessment",
163
+ "power-features/web-vulnerability-assessment",
164
+ "power-features/github-audit",
165
+ "power-features/ai-analyst",
166
+ "power-features/atomic-red-team",
167
+ "power-features/report-creation"
168
]
266
- },
169
+ }
170
+ ]
171
+ },
172
+ {
173
+ "tab": "Developer",
174
+ "pages": [
175
+ "developer/start-here",
176
+ "architecture/ARCHITECTURE",
177
+ "architecture/MAP",
178
+ "architecture/DEPLOYMENT",
179
+ "architecture/DATA_FLOWS",
180
+ "architecture/DATABASE_SCHEMA",
181
+ "integrations/ADDING_A_CONNECTOR"
182
+ ]
183
+ },
184
+ {
185
+ "tab": "Videos",
186
+ "pages": [
187
+ "videos",
188
+ "user/videos"
189
+ ]
190
+ },
191
+ {
192
+ "tab": "Reference",
193
+ "groups": [
194
{
268
- "group": "Other",
195
+ "group": "Essentials",
196
"pages": [
270
- "user/ui/healthcheck",
271
- "user/ui/scheduler",
272
- "user/ui/artifacts",
273
- "user/ui/customer-portal"
197
+ "reference",
198
+ "reference/troubleshooting",
199
+ "user/navigation"
200
]
201
}
202
]
docs/getting-started/roles-and-mental-model.mdx
+88
@@ -10,6 +10,94 @@ CoPilot is easiest to learn if you separate it into **two jobs**:
10
1) **Operate incidents** (alerts → cases → evidence → response)
11
2) **Make incidents possible** (connect sources/integrations so alerts flow)
12
13
+---
14
+
15
+## The mental model (visual)
16
+
17
+CoPilot becomes intuitive when you see it as **two loops** that share the same data:
18
+
19
+<Columns cols={2}>
20
+ <Card title="Admin / Platform loop" icon="gear">
21
+ You make detection possible.
22
+
23
+ <Steps>
24
+ <Step title="Connect & verify">
25
+ Integrations + syslog connectors are healthy.
26
+ </Step>
27
+ <Step title="Ingest & route">
28
+ Streams/pipelines route logs where they should go.
29
+ </Step>
30
+ <Step title="Provision & visualize">
31
+ Customers/tenants, dashboards, indices, retention.
32
+ </Step>
33
+ <Step title="Enable alerting">
34
+ Event definitions + notifications are configured.
35
+ </Step>
36
+ <Step title="Tune & maintain">
37
+ Reduce noise, validate coverage, keep things reliable.
38
+ </Step>
39
+ </Steps>
40
+ </Card>
41
+
42
+ <Card title="Operator loop" icon="siren">
43
+ You run incidents.
44
+
45
+ <Steps>
46
+ <Step title="Alert appears">
47
+ New alert lands in Incident Management.
48
+ </Step>
49
+ <Step title="Triage">
50
+ Decide: true positive? priority? scope?
51
+ </Step>
52
+ <Step title="Case work">
53
+ Create a case, collect artifacts/evidence.
54
+ </Step>
55
+ <Step title="Respond">
56
+ Contain, eradicate, recover.
57
+ </Step>
58
+ <Step title="Feedback">
59
+ Feed improvements back into tuning/detections.
60
+ </Step>
61
+ </Steps>
62
+ </Card>
63
+</Columns>
64
+
65
+### How alerts become cases (the shared pipeline)
66
+
67
+<Steps>
68
+ <Step title="1) Data arrives">
69
+ Endpoints (Wazuh), API integrations (O365/Mimecast/Huntress/CrowdStrike), and syslog devices (FortiGate/PAN‑OS/ASA).
70
+ </Step>
71
+ <Step title="2) Normalize & route">
72
+ Graylog streams/pipelines normalize fields and route logs.
73
+ </Step>
74
+ <Step title="3) Detect">
75
+ Graylog Event Definitions evaluate conditions and generate events.
76
+ </Step>
77
+ <Step title="4) Persist">
78
+ Alerts are written to `gl-events*`.
79
+ </Step>
80
+ <Step title="5) Operate">
81
+ CoPilot surfaces alerts → operators create/work cases → response.
82
+ </Step>
83
+</Steps>
84
+
85
+### “Where do I click?” (quick map)
86
+
87
+<Columns cols={3}>
88
+ <Card title="Operators" icon="siren" href="/user/operators-quickstart">
89
+ Incident Management → Alerts → Cases
90
+ </Card>
91
+ <Card title="Admins / engineers" icon="gear" href="/user/admins-quickstart">
92
+ Provisioning → Integrations → Connectors → Indices
93
+ </Card>
94
+ <Card title="Developers" icon="code" href="/developer/start-here">
95
+ Architecture → Data flows → Connectors
96
+ </Card>
97
+</Columns>
98
+
99
+---
100
+
101
## SOC operator / analyst
102
103
You spend most of your time in **Incident Management**.
docs/getting-started/start-here.mdx
new
+186
@@ -0,0 +1,186 @@
1
+---
2
+title: Start here
3
+description: A guided checklist to get logs flowing, dashboards populated, and alerts/cases working in SOCFortress CoPilot.
4
+---
5
+
6
+# Start here
7
+
8
+This is the **primary onboarding checklist** for CoPilot.
9
+
10
+CoPilot sits on top of an open-source SIEM stack. To get value fast, you want this order:
11
+
12
+1) **Ingest** (endpoints + integrations + syslog)
13
+2) **Visualize** (dashboards)
14
+3) **Detect** (alerts)
15
+4) **Respond** (alerts → cases → IR)
16
+
17
+If you’re unsure what role you are, read [Roles & mental model](/getting-started/roles-and-mental-model) first.
18
+
19
+---
20
+
21
+## Success definition (what “done” looks like)
22
+
23
+You’re “onboarded” when:
24
+
25
+- [ ] You can confirm **endpoint logs** are arriving (Wazuh)
26
+- [ ] You can confirm **integration/syslog logs** are arriving (External Services / Network Connectors)
27
+- [ ] You can open a **Grafana dashboard** that is populated with real data
28
+- [ ] A **Graylog alert** appears in CoPilot (**Incident Management → Alerts**)
29
+- [ ] An operator can open a **case** from an alert and track investigation work
30
+
31
+---
32
+
33
+## 0) Prereqs (10 minutes)
34
+
35
+Do these before troubleshooting anything else.
36
+
37
+- [ ] In CoPilot, configure and verify **Connectors** (Wazuh, Graylog, Grafana, Velociraptor).
38
+ - If a connector can’t verify, stop here and fix connectivity/credentials.
39
+- [ ] Decide your **customer code** convention (short, stable, no spaces).
40
+ - You’ll use this for routing/indexing/provisioning.
41
+
42
+Helpful pages:
43
+- [Admin/Engineer quickstart](/user/admins-quickstart)
44
+- [Customer provisioning (tenancy)](/user/customer-provisioning)
45
+- [UI navigation guide](/user/navigation)
46
+
47
+---
48
+
49
+## 1) Ingest logs (make data exist)
50
+
51
+### 1A) Endpoints — Wazuh (usually first)
52
+
53
+**Goal:** endpoints are enrolled and reporting; CoPilot shows them as healthy.
54
+
55
+Checklist:
56
+- [ ] Enroll at least 1 endpoint (Windows or Linux) into Wazuh.
57
+- [ ] Confirm the endpoint appears in CoPilot under **Agents** and shows online/healthy.
58
+- [ ] Confirm the agent is associated with the correct tenant/customer context.
59
+
60
+Success criteria:
61
+- You can point to **one real endpoint** in CoPilot and say “this host is actively producing telemetry.”
62
+
63
+Next (UI reference):
64
+- [Agents](/user/ui/agents)
65
+- [Agent groups](/user/ui/agents-groups)
66
+
67
+### 1B) Third‑party integrations — API sources
68
+
69
+Examples: Office 365, Mimecast, Huntress, CrowdStrike.
70
+
71
+**Goal:** events are arriving under the correct customer scope.
72
+
73
+Checklist:
74
+- [ ] Configure at least 1 integration under **External Services**.
75
+- [ ] Confirm events are flowing (don’t worry about dashboards yet).
76
+
77
+Success criteria:
78
+- You can find at least **one recent event** for the integration and tie it to a customer.
79
+
80
+Next (UI reference):
81
+- [External services](/user/ui/external-services)
82
+- [3rd party integrations](/user/ui/external-third-party-integrations)
83
+
84
+### 1C) Network connectors — syslog
85
+
86
+**Goal:** syslog events arrive from at least one device/source.
87
+
88
+Checklist:
89
+- [ ] Configure a network connector.
90
+- [ ] Confirm syslog events are arriving and are tenant-aware (routed/tagged correctly).
91
+
92
+Success criteria:
93
+- You can identify the source device + see fresh events in the expected location.
94
+
95
+Next (UI reference):
96
+- [Network connectors](/user/ui/external-network-connectors)
97
+
98
+---
99
+
100
+## 2) Visualize (make data understandable)
101
+
102
+CoPilot uses **Grafana** for dashboards. During **customer provisioning**, CoPilot can deploy **templated dashboards** so you get immediate visibility.
103
+
104
+Checklist:
105
+- [ ] Verify the **Grafana connector**.
106
+- [ ] Run **customer provisioning** for a test customer.
107
+- [ ] Confirm dashboards are deployed into the customer’s Grafana org.
108
+- [ ] Open at least 1 dashboard and confirm it’s populated (not empty panels).
109
+
110
+Success criteria:
111
+- You can show a dashboard with **real, current** data for a specific customer.
112
+
113
+Next:
114
+- [Customer provisioning](/user/customer-provisioning)
115
+- Videos (browse by role): [Videos](/user/videos)
116
+
117
+---
118
+
119
+## 3) Detect (make data actionable)
120
+
121
+CoPilot uses **Graylog** for searching and alerting.
122
+
123
+Mental model:
124
+- ingestion → streams/pipelines → event definitions → alerts written to `gl-events*`
125
+- CoPilot reads those into **Incident Management → Alerts**
126
+
127
+Checklist:
128
+- [ ] Verify the **Graylog connector**.
129
+- [ ] Ensure alert plumbing exists (built-in definitions or create one custom).
130
+- [ ] Trigger a test event and confirm an alert is created.
131
+- [ ] Confirm the alert is visible in CoPilot under **Incident Management → Alerts**.
132
+
133
+Success criteria:
134
+- A new alert appears in CoPilot and you can explain “what fired” + “what data it was based on.”
135
+
136
+Next (UI reference):
137
+- [Graylog management](/user/ui/graylog-management)
138
+- [Incident alerts](/user/ui/incident-alerts)
139
+
140
+---
141
+
142
+## 4) Respond (alerts → cases)
143
+
144
+Checklist:
145
+- [ ] Open an alert.
146
+- [ ] Create a case from it.
147
+- [ ] Add at least one note/comment/evidence link.
148
+- [ ] Assign/track status so it’s obvious what’s being worked.
149
+
150
+Success criteria:
151
+- An operator can manage an investigation end-to-end without leaving CoPilot.
152
+
153
+Next (UI reference):
154
+- [Incident cases](/user/ui/incident-cases)
155
+
156
+---
157
+
158
+## 5) Endpoint IR (Velociraptor)
159
+
160
+Velociraptor provides response capabilities: remote commands, artifact collection, and evidence gathering.
161
+
162
+Checklist:
163
+- [ ] Verify the **Velociraptor connector**.
164
+- [ ] Run one basic artifact collection against a test endpoint.
165
+- [ ] Confirm you can retrieve/view results in CoPilot.
166
+
167
+Success criteria:
168
+- You can collect at least one artifact and attach/associate results to investigation work.
169
+
170
+Next:
171
+- Velociraptor-focused walkthroughs in [Videos](/user/videos)
172
+
173
+---
174
+
175
+## 6) Expand (power features)
176
+
177
+Once the core SIEM loop is working, layer in these modules:
178
+
179
+- Vulnerability + SCA views (Wazuh-backed)
180
+- Microsoft Patch Tuesday prioritization
181
+- Cloud security assessment outputs (Scout Suite)
182
+- Web vulnerability assessment (Nuclei)
183
+- GitHub audit
184
+- AI-assisted reporting / report creation
185
+
186
+(We’ll link each of these to dedicated pages as we wireframe them.)
docs/getting-started/what-is-copilot.mdx
+30
@@ -13,6 +13,36 @@ It sits above tools like **Wazuh**, **Graylog**, **Velociraptor**, **Grafana**,
13
- **Onboard data**: customer/tenant provisioning, integrations, and connectors
14
- **Reduce context switching** with a consistent UI and workflow
15
16
+<Frame>
17
+ <div style={{ width: '100%', maxWidth: 1100, margin: '0 auto' }}>
18
+ <video
19
+ autoPlay
20
+ loop
21
+ muted
22
+ playsInline
23
+ preload="auto"
24
+ controls={false}
25
+ disablePictureInPicture
26
+ onClick={(e) => e.currentTarget.play()}
27
+ style={{
28
+ width: '100%',
29
+ aspectRatio: '16 / 9',
30
+ height: 'auto',
31
+ display: 'block',
32
+ borderRadius: 16,
33
+ background: 'rgba(0,0,0,0.2)',
34
+ }}
35
+ >
36
+ <source src="/assets/hero/copilot-hub.webm" type="video/webm" />
37
+ <source src="/assets/hero/copilot-hub.mp4" type="video/mp4" />
38
+ </video>
39
+ </div>
40
+</Frame>
41
+
42
+<div style={{ fontSize: 13, opacity: 0.8, marginTop: 8 }}>
43
+ If the animation doesn’t autoplay in your browser, click once to start playback.
44
+</div>
45
+
46
## Who is it for?
47
48
<Columns cols={3}>
docs/index-mkdocs.md
renamed
docs/index.mdx
+27
-13
@@ -9,6 +9,10 @@ CoPilot is a **single pane of glass** for operating an open‑source SOC/SIEM st
9
10
**Choose your path:**
11
12
+<Card title="Start here" icon="map" href="/getting-started/start-here" horizontal>
13
+ Guided path: ingest → dashboards → alerts → cases → response.
14
+</Card>
15
+
16
<Card title="SOC Operator / Analyst" icon="siren" href="/user/operators-quickstart" horizontal>
17
Alert triage → cases → investigations.
18
</Card>
@@ -22,19 +26,29 @@ CoPilot is a **single pane of glass** for operating an open‑source SOC/SIEM st
26
</Card>
27
28
<Frame>
25
- <video
26
- autoPlay
27
- loop
28
- muted
29
- playsInline
30
- preload="auto"
31
- controls={false}
32
- disablePictureInPicture
33
- style={{ width: '100%', height: 'auto', display: 'block', borderRadius: 16 }}
34
- >
35
- <source src="/assets/hero/copilot-hub.webm" type="video/webm" />
36
- <source src="/assets/hero/copilot-hub.mp4" type="video/mp4" />
37
- </video>
29
+ <div style={{ width: '100%', maxWidth: 1100, margin: '0 auto' }}>
30
+ <video
31
+ autoPlay
32
+ loop
33
+ muted
34
+ playsInline
35
+ preload="auto"
36
+ controls={false}
37
+ disablePictureInPicture
38
+ onClick={(e) => e.currentTarget.play()}
39
+ style={{
40
+ width: '100%',
41
+ aspectRatio: '16 / 9',
42
+ height: 'auto',
43
+ display: 'block',
44
+ borderRadius: 16,
45
+ background: 'rgba(0,0,0,0.2)',
46
+ }}
47
+ >
48
+ <source src="/assets/hero/copilot-hub.webm" type="video/webm" />
49
+ <source src="/assets/hero/copilot-hub.mp4" type="video/mp4" />
50
+ </video>
51
+ </div>
52
</Frame>
53
54
<div style={{ fontSize: 13, opacity: 0.8, marginTop: 8 }}>
docs/integrations.mdx
new
+44
@@ -0,0 +1,44 @@
1
+---
2
+title: Integrations
3
+description: Source-by-source setup guides and expectations for what data, dashboards, and alerts you get in CoPilot.
4
+---
5
+
6
+# Integrations
7
+
8
+This section is a **catalog**.
9
+
10
+Pick a source, follow a short setup guide, then validate that:
11
+
12
+- logs are ingesting
13
+- dashboards populate (after provisioning)
14
+- alerting can be enabled (built-in or custom)
15
+
16
+If you’re brand new, start with the guided checklist: [Start here](/getting-started/start-here).
17
+
18
+---
19
+
20
+## The mental model
21
+
22
+Almost every integration follows this pattern:
23
+
24
+1. **Ingest** events (API integration or syslog)
25
+2. Store events in your SIEM datastore (Wazuh Indexer / OpenSearch-backed)
26
+3. (Often) build alerts in **Graylog** → alerts land in `gl-events*`
27
+4. CoPilot shows alerts in **Incident Management → Alerts** → operators open **Cases**
28
+
29
+---
30
+
31
+## First-wave integrations
32
+
33
+- [Wazuh (endpoints)](/integrations/wazuh)
34
+- [Office 365](/integrations/office-365)
35
+- [Mimecast](/integrations/mimecast)
36
+- [Huntress](/integrations/huntress)
37
+- [CrowdStrike](/integrations/crowdstrike)
38
+
39
+## Network connectors (syslog)
40
+
41
+- [Network connectors overview](/integrations/network-connectors)
42
+- Fortinet: [FortiGate](/integrations/network-connectors/fortigate)
43
+- Palo Alto Networks: [PAN-OS](/integrations/network-connectors/palo-alto)
44
+- Cisco: [ASA](/integrations/network-connectors/cisco-asa)
docs/integrations/_template.mdx
new
+49
@@ -0,0 +1,49 @@
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)
docs/integrations/bitdefender.mdx
new
+108
@@ -0,0 +1,108 @@
1
+---
2
+title: Bitdefender (GravityZone)
3
+description: Ingest Bitdefender GravityZone events into the SOCFortress SIEM stack via the Event Push Service connector.
4
+---
5
+
6
+# Bitdefender (GravityZone)
7
+
8
+## What this integration is
9
+
10
+This integration ingests **Bitdefender GravityZone** security events into your SIEM stack using GravityZone’s **Event Push Service**.
11
+
12
+In SOCFortress CoPilot deployments, Bitdefender typically pushes events to a small HTTP receiver/connector, which then forwards them to **Graylog** over syslog.
13
+
14
+---
15
+
16
+## Data path (how it flows)
17
+
18
+1) Bitdefender GravityZone (cloud) → **Event Push Service**
19
+2) Event Push Service → **CoPilot-hosted HTTP receiver** (connector)
20
+3) Receiver → **Graylog input** (syslog)
21
+4) Graylog → stream/index/dashboards (provisioned)
22
+5) Optional: Graylog alerting → Incident ingestion (if configured)
23
+
24
+---
25
+
26
+## Prerequisites
27
+
28
+- Bitdefender API access is enabled and an API client is created.
29
+- Network path is in place so Bitdefender can reach your HTTP receiver.
30
+- You have a target syslog host/port (Graylog input).
31
+
32
+Vendor reference:
33
+- Event Push Service API connector (CEF): https://www.bitdefender.com/business/support/en/77209-144080-build-an-event-push-service-api-connector-for-cef-standard.html
34
+
35
+---
36
+
37
+## Credentials & configuration you’ll need
38
+
39
+From Bitdefender:
40
+- API credentials / auth string (connector uses an `authentication_string`)
41
+
42
+From your SIEM:
43
+- Graylog host + port (syslog target)
44
+
45
+From your deployment:
46
+- A public-facing DNS/port so Bitdefender can deliver events to the receiver
47
+
48
+Example receiver config (for context; CoPilot provisioning typically generates this for you):
49
+
50
+```json
51
+{
52
+ "port": 3200,
53
+ "syslog_port": 10514,
54
+ "transport": "Tcp",
55
+ "target": "YOUR_GRAYLOG_SERVER",
56
+ "authentication_string": "Basic <base64>",
57
+ "secure": {
58
+ "enabled": true,
59
+ "key": "api/config/server.key",
60
+ "cert": "api/config/server.crt"
61
+ }
62
+}
63
+```
64
+
65
+---
66
+
67
+## CoPilot setup (recommended workflow)
68
+
69
+1) **Provision the customer** first (so the tenant wiring exists).
70
+2) In CoPilot, open the customer and add the **Bitdefender** integration.
71
+3) Enter the required configuration values.
72
+4) Deploy/start the Bitdefender connector container generated during provisioning.
73
+
74
+Provisioning typically creates:
75
+- Graylog CEF/syslog input
76
+- Graylog stream + index
77
+- Grafana datasource + dashboards
78
+- Bitdefender docker compose + config
79
+
80
+---
81
+
82
+## Deployment notes (connector container)
83
+
84
+In a standard layout, provisioning creates a customer-specific folder under:
85
+- `/opt/CoPilot/data/data/<CUSTOMER_NAME>/`
86
+
87
+Start the connector:
88
+
89
+```bash
90
+docker compose -f /opt/CoPilot/data/data/<CUSTOMER_NAME>/<CUSTOMER_NAME>_bitdefender_docker-compose.yml up -d
91
+```
92
+
93
+---
94
+
95
+## Success criteria
96
+
97
+- [ ] Bitdefender events are arriving in Graylog
98
+- [ ] Events are routed to the customer’s index/stream
99
+- [ ] Dashboards show non-empty data (after a short delay)
100
+
101
+---
102
+
103
+## Troubleshooting
104
+
105
+- Verify inbound firewall/NAT allows Bitdefender → HTTP receiver traffic.
106
+- Verify the receiver can reach Graylog syslog input (host/port).
107
+- Validate TLS cert/key configuration if `secure.enabled=true`.
108
+- Confirm auth string matches what Bitdefender expects.
docs/integrations/carbon-black.mdx
new
+68
@@ -0,0 +1,68 @@
1
+---
2
+title: Carbon Black Cloud
3
+description: Ingest Carbon Black Cloud alerts into the SOCFortress SIEM stack.
4
+---
5
+
6
+# Carbon Black Cloud
7
+
8
+## What this integration is
9
+
10
+This integration ingests **VMware Carbon Black Cloud** alert data into your SOCFortress SIEM stack using the Carbon Black Cloud APIs.
11
+
12
+---
13
+
14
+## Data path (how it flows)
15
+
16
+1) Carbon Black Cloud → API polling/collector
17
+2) Collector → SIEM ingestion (indexing/search)
18
+3) Optional: alerting + routing into Incident Management
19
+
20
+---
21
+
22
+## Prerequisites
23
+
24
+- Carbon Black Cloud console access
25
+- API access enabled
26
+
27
+Vendor reference:
28
+- Alerts API: https://developer.carbonblack.com/reference/carbon-black-cloud/platform/latest/alerts-api/
29
+
30
+---
31
+
32
+## Credentials & permissions you’ll need
33
+
34
+From the Carbon Black Cloud console:
35
+- API ID
36
+- API Secret Key
37
+- ORG Key
38
+- ORG ID
39
+- Base API hostname (e.g., `https://defense.conferdeploy.net`)
40
+
41
+The recommended pattern is to create:
42
+1) a **custom access level** with **Alerts: READ**
43
+2) an **API key** bound to that access level
44
+
45
+---
46
+
47
+## CoPilot setup (recommended workflow)
48
+
49
+1) Provision the customer (tenant wiring).
50
+2) In CoPilot → customer → Integrations → **Add integration** → **Carbon Black**.
51
+3) Paste the API credentials + org identifiers.
52
+4) Deploy/start the collector/connector component (if your deployment model uses a containerized collector).
53
+
54
+---
55
+
56
+## Success criteria
57
+
58
+- [ ] Carbon Black alerts are arriving
59
+- [ ] Alerts/events are tagged to the correct customer
60
+
61
+---
62
+
63
+## Troubleshooting
64
+
65
+- Confirm API key permissions include alerts read access.
66
+- Confirm ORG identifiers match your tenant.
67
+- Validate base URL/region (commercial vs other environments).
68
+- Check collector logs for rate limiting/auth failures.
docs/integrations/cato-networks.mdx
new
+65
@@ -0,0 +1,65 @@
1
+---
2
+title: Cato Networks
3
+description: Ingest Cato Networks SASE events into the SOCFortress SIEM stack.
4
+---
5
+
6
+# Cato Networks
7
+
8
+## What this integration is
9
+
10
+This integration ingests **Cato Networks** events into your SOCFortress SIEM stack using the Cato API (commonly via the `eventsFeed` capability).
11
+
12
+Vendor reference:
13
+- Cato API docs: https://api.catonetworks.com/documentation/
14
+
15
+---
16
+
17
+## Data path (how it flows)
18
+
19
+1) Cato Networks → events API feed
20
+2) CoPilot collector → SIEM ingestion (indexing/search)
21
+3) Optional: alerting and incident workflows
22
+
23
+---
24
+
25
+## Prerequisites
26
+
27
+- Cato Management Application access
28
+- API key created with appropriate permissions
29
+- Event feed enabled (Administration → Event Integrations)
30
+
31
+---
32
+
33
+## Credentials you’ll need
34
+
35
+From Cato:
36
+- **Account ID** (from the URL)
37
+- **API key**
38
+
39
+API key notes:
40
+- Choose **View permissions** for read-only ingestion.
41
+- Copy the key immediately when generated (can’t be retrieved later).
42
+
43
+---
44
+
45
+## CoPilot setup (recommended workflow)
46
+
47
+1) Provision the customer.
48
+2) Add **Cato Networks** integration under the customer.
49
+3) Provide account ID + API key.
50
+4) Validate that events begin flowing.
51
+
52
+---
53
+
54
+## Success criteria
55
+
56
+- [ ] Events show up for the expected customer
57
+- [ ] You can correlate an event in Cato with an event in the SIEM
58
+
59
+---
60
+
61
+## Troubleshooting
62
+
63
+- Confirm “Event Feed Enabled” is toggled on.
64
+- Confirm the API key is not expired/revoked.
65
+- Validate the account ID is correct and in-scope.
docs/integrations/crowdstrike.mdx
new
+169
@@ -0,0 +1,169 @@
1
+---
2
+title: CrowdStrike
3
+description: Ingest CrowdStrike Falcon events using the Falcon SIEM Connector and route them into your SOCFortress SIEM stack.
4
+---
5
+
6
+# CrowdStrike
7
+
8
+## What this integration is
9
+
10
+This integration ingests **CrowdStrike Falcon** events into your SOCFortress SIEM stack using the **Falcon SIEM Connector** (FalconHose).
11
+
12
+CrowdStrike events are forwarded to your SIEM (typically Graylog) over syslog, where they can be searched, routed, and used for alerting and investigations.
13
+
14
+Vendor references:
15
+- Integrate with your SIEM: https://www.crowdstrike.com/blog/tech-center/integrate-with-your-siem
16
+- Get access to Falcon APIs: https://www.crowdstrike.com/blog/tech-center/get-access-falcon-apis/
17
+
18
+---
19
+
20
+## Prerequisites
21
+
22
+- CrowdStrike Falcon console access
23
+- An API client created with scope that includes **read access for Event streams**
24
+
25
+Important:
26
+- If you are in **CrowdStrike Government cloud**, you must open a support ticket with CrowdStrike to enable the Falcon SIEM Connector.
27
+
28
+
29
+
30
+---
31
+
32
+## Configuration (Falcon SIEM Connector)
33
+
34
+Connector configuration is stored at:
35
+- `/opt/crowdstrike/etc/cs.falconhoseclient.cfg`
36
+
37
+CoPilot provisioning typically generates this for you, but for reference the key values that must be set include:
38
+- `api_url`
39
+- `client_id`
40
+- `client_secret`
41
+- `syslog_host` / `syslog_port`
42
+
43
+Example configuration:
44
+
45
+```ini
46
+[Settings]
47
+version = 3
48
+api_url = REPLACE_BASE_URL/sensors/entities/datafeed/v2
49
+request_token_url = REPLACE_BASE_URL/oauth2/token
50
+app_id = SIEM-Connector-v2.0.0
51
+
52
+enable_correlation_id = false
53
+format_floats_as_scientific = true
54
+
55
+# API Client ID
56
+client_id = REPLACE_CLIENT_ID
57
+# API Client Secret
58
+client_secret = REPLACE_CLIENT_SECRET
59
+
60
+# Amount of time (in seconds) we will wait for a connect to complete.
61
+connection_timeout = 10
62
+# Amount of time to wait (in seconds) for a server's response headers after fully writing the request.
63
+read_timeout = 30
64
+
65
+# Specify partition number 0 to n or 'all' (without quote) for all partitions
66
+partition = all
67
+
68
+http_proxy =
69
+
70
+# Output formats
71
+# Supported formats are
72
+# 1.syslog: will output syslog format with flat key=value pairs uses the mapping configuration below.
73
+; Use syslog format if CEF/LEEF output is required.
74
+# 2.json: will output raw json format received from FalconHose API (default)
75
+output_format = syslog
76
+
77
+# Will be true regardless if Syslog is not enabled
78
+# If path does not exist or user has no permission, log file will be used
79
+output_to_file = false
80
+output_path = /var/log/crowdstrike/falconhoseclient/output
81
+
82
+# Offset file full filepath and filename
83
+offset_path = /var/log/crowdstrike/falconhoseclient/stream_offsets
84
+
85
+[Output_File_Rotation]
86
+# If the output is writing to a file, then the settings below will govern output file rotation
87
+#
88
+# If true, then the rotation rules will apply. If not, the client will continue to write to the same file.
89
+rotate_file = true
90
+# Maximum individual output file size in MB
91
+max_size = 500
92
+# Number of backups of the output file to be stored
93
+max_backups = 10
94
+# Maximum age of backup output files before it is deleted in DAYS
95
+max_age = 30
96
+
97
+[Logging]
98
+verbose_log = true
99
+# Maximum individual log file size in MB
100
+max_size = 500
101
+# Number of backups to be stored
102
+max_backups = 10
103
+# Maximum age of backup files before it is deleted in DAYS
104
+max_age = 30
105
+
106
+[Syslog]
107
+send_to_syslog_server = true
108
+host = REPLACE_SYSLOG_HOST
109
+port = REPLACE_SYSLOG_PORT
110
+protocol = tcp
111
+```
112
+
113
+---
114
+
115
+## CoPilot provisioning
116
+
117
+Once you have saved the CrowdStrike configuration for the customer, you are ready to deploy the integration.
118
+
119
+In CoPilot, navigate to the **Customers** section and select the appropriate customer. Provisioning typically creates:
120
+- Graylog CEF input
121
+- Graylog stream
122
+- Graylog index
123
+- Grafana datasource
124
+- Grafana dashboards
125
+- CrowdStrike docker compose file
126
+
127
+---
128
+
129
+## Deployment (connector container)
130
+
131
+The CrowdStrike integration runs via a docker container.
132
+
133
+During provisioning, a customer directory is created:
134
+- `/opt/CoPilot/data/data/<CUSTOMER_NAME>`
135
+
136
+Inside you’ll typically find:
137
+- `<CUSTOMER_NAME>_docker-compose.yml`
138
+- `cs.falconhoseclient.cfg`
139
+
140
+Start the container:
141
+
142
+```bash
143
+docker compose -f /opt/CoPilot/data/data/<CUSTOMER_NAME>/<CUSTOMER_NAME>_docker-compose.yml up -d
144
+```
145
+
146
+You should now see the container running:
147
+
148
+
149
+
150
+---
151
+
152
+## Success criteria
153
+
154
+- [ ] CrowdStrike events are arriving in Graylog
155
+- [ ] Events are routed to the correct customer stream/index
156
+- [ ] Dashboards populate (after a short delay)
157
+
158
+---
159
+
160
+## Troubleshooting
161
+
162
+- No events:
163
+ - verify Falcon SIEM Connector is enabled for your tenant (GovCloud note above)
164
+ - confirm API client has event stream read scope
165
+ - check connector container logs
166
+
167
+- Events arriving but not routed:
168
+ - confirm Graylog input/stream/index created during provisioning
169
+ - confirm syslog host/port match your Graylog input
docs/integrations/darktrace.mdx
new
+62
@@ -0,0 +1,62 @@
1
+---
2
+title: Darktrace
3
+description: Ingest Darktrace alert logs (AI Analyst / Model Breach / System Status) into the SOCFortress SIEM stack.
4
+---
5
+
6
+# Darktrace
7
+
8
+## What this integration is
9
+
10
+This integration ingests **Darktrace** alert logs into your SOCFortress SIEM stack.
11
+
12
+Darktrace provides multiple event types that can be useful for SOC operations:
13
+- AI Analyst alerts
14
+- Model breach alerts
15
+- System status alerts
16
+
17
+---
18
+
19
+## Data path (how it flows)
20
+
21
+1) Darktrace → API pull (token-authenticated)
22
+2) CoPilot collector → SIEM ingestion
23
+3) Optional: alerting and case workflows
24
+
25
+---
26
+
27
+## Credentials you’ll need
28
+
29
+Darktrace requires an **API token pair** (Public + Private). You typically need one per Master instance.
30
+
31
+Ways to obtain tokens:
32
+
33
+### Per-user token
34
+1) Enable “API Access” for a local user (Threat Visualizer → Admin → Permissions)
35
+2) Log in as that user → Account Settings → generate API tokens
36
+
37
+### Global token
38
+1) Threat Visualizer → System Config → Settings → generate API tokens
39
+
40
+---
41
+
42
+## CoPilot setup (recommended workflow)
43
+
44
+1) Provision the customer.
45
+2) Add **Darktrace** integration under the customer.
46
+3) Provide the Darktrace API endpoint + token pair.
47
+4) Validate alerts begin flowing.
48
+
49
+---
50
+
51
+## Success criteria
52
+
53
+- [ ] AI Analyst / Model Breach alerts show up in the SIEM
54
+- [ ] Events are associated with the correct customer
55
+
56
+---
57
+
58
+## Troubleshooting
59
+
60
+- Confirm the user used for token creation has API access enabled.
61
+- Confirm tokens are stored correctly and haven’t been rotated.
62
+- Validate time range/polling schedule in the collector.
docs/integrations/defender-for-endpoint.mdx
new
+92
@@ -0,0 +1,92 @@
1
+---
2
+title: Microsoft Defender for Endpoint
3
+description: Ingest Microsoft Defender for Endpoint alerts into the SOCFortress SIEM stack.
4
+---
5
+
6
+# Microsoft Defender for Endpoint
7
+
8
+## What this integration is
9
+
10
+This integration ingests **Microsoft Defender for Endpoint** alerts via the Defender for Endpoint API.
11
+
12
+Vendor reference:
13
+- Get alerts API: https://learn.microsoft.com/en-us/defender-endpoint/api/get-alerts
14
+
15
+---
16
+
17
+## Data path (how it flows)
18
+
19
+1) Microsoft Defender for Endpoint → API polling (OAuth2)
20
+2) Collector → syslog/ingest into Graylog (implementation-dependent)
21
+3) Graylog → stream/index/dashboards
22
+
23
+---
24
+
25
+## Prerequisites
26
+
27
+- Azure app registration for API access
28
+- API permissions granted:
29
+ - `Alert.Read.All`
30
+ - `Alert.ReadWrite.All`
31
+
32
+---
33
+
34
+## Credentials & config you’ll need
35
+
36
+- Tenant ID
37
+- Client ID
38
+- Client secret
39
+- Token URL: `https://login.microsoftonline.com/<TENANT_ID>/oauth2/token`
40
+- Syslog host/port (Graylog)
41
+
42
+Example (for context; CoPilot provisioning typically fills this):
43
+
44
+```yaml
45
+filebeat.modules:
46
+- module: microsoft
47
+ defender_atp:
48
+ enabled: true
49
+ var.oauth2.client.id: "CLIENT_ID"
50
+ var.oauth2.client.secret: "CLIENT_SECRET"
51
+ var.oauth2.token_url: "https://login.microsoftonline.com/TENANT_ID/oauth2/token"
52
+
53
+output.logstash:
54
+ hosts: ["REPLACE_SYSLOG_HOST:REPLACE_SYSLOG_PORT"]
55
+```
56
+
57
+---
58
+
59
+## CoPilot setup (recommended workflow)
60
+
61
+1) Provision the customer.
62
+2) Add **Defender for Endpoint** integration under the customer.
63
+3) Provide tenant/client credentials.
64
+4) Deploy/start the connector container generated during provisioning.
65
+
66
+Provisioning typically creates:
67
+- Graylog input + stream + index
68
+- Grafana datasource + dashboards
69
+- A customer-specific docker compose + Filebeat config
70
+
71
+---
72
+
73
+## Deployment notes (connector container)
74
+
75
+```bash
76
+docker compose -f /opt/CoPilot/data/data/<CUSTOMER_NAME>/<CUSTOMER_NAME>_docker-compose-defender-for-endpoint.yml up -d
77
+```
78
+
79
+---
80
+
81
+## Success criteria
82
+
83
+- [ ] Defender alerts are arriving
84
+- [ ] Events are routed to the correct customer index/stream
85
+
86
+---
87
+
88
+## Troubleshooting
89
+
90
+- Confirm the Azure app has the required permissions and admin consent.
91
+- Confirm tenant ID/client ID/secret match.
92
+- Check connector logs for OAuth failures.
docs/integrations/duo.mdx
new
+65
@@ -0,0 +1,65 @@
1
+---
2
+title: Duo
3
+description: Ingest Duo authentication logs into the SOCFortress SIEM stack using the Duo Admin API.
4
+---
5
+
6
+# Duo
7
+
8
+## What this integration is
9
+
10
+This integration ingests **Duo authentication and admin logs** into your SOCFortress SIEM stack via the **Duo Admin API**.
11
+
12
+Vendor reference:
13
+- Duo Admin API overview: https://duo.com/docs/adminapi#overview
14
+
15
+---
16
+
17
+## What data you get (high level)
18
+
19
+- Authentication logs
20
+- Telephony logs
21
+- Administrator action logs
22
+
23
+---
24
+
25
+## Prerequisites
26
+
27
+- Duo Admin Panel access
28
+- **Owner** role (required to create/modify Admin API applications)
29
+
30
+---
31
+
32
+## Credentials you’ll need
33
+
34
+From the Duo Admin Panel “Admin API” application:
35
+- Integration key
36
+- Secret key
37
+- API hostname
38
+
39
+Permissions note:
40
+- Grant the Admin API application **read log** permissions at minimum.
41
+
42
+---
43
+
44
+## CoPilot setup (recommended workflow)
45
+
46
+1) Provision the customer.
47
+2) Add the **Duo** integration under the customer.
48
+3) Paste the integration key/secret key/API hostname.
49
+4) Validate logs appear in the SIEM.
50
+
51
+---
52
+
53
+## Security notes
54
+
55
+Treat the Duo secret key like a password:
56
+- store it in a secure secrets manager
57
+- rotate if exposure is suspected
58
+
59
+---
60
+
61
+## Troubleshooting
62
+
63
+- Confirm the Admin API application has the required permissions.
64
+- Confirm the API hostname is correct for your Duo tenant.
65
+- Check for clock drift on the collector (Duo auth is time-sensitive).
docs/integrations/huntress.mdx
new
+51
@@ -0,0 +1,51 @@
1
+---
2
+title: Huntress
3
+description: Ingest Huntress telemetry and operationalize it inside CoPilot.
4
+---
5
+
6
+# Huntress
7
+
8
+## What this integration is
9
+
10
+Huntress provides managed detection/response-style telemetry that can complement endpoint and identity sources.
11
+
12
+## Data path (how it flows)
13
+
14
+**Typical flow:**
15
+
16
+1. Huntress → **External Service integration** (API collector or export)
17
+2. Events → **SIEM storage** (Wazuh Indexer / OpenSearch-backed)
18
+3. Optional: events → **Graylog** alert definitions
19
+4. Alerts → `gl-events*` → **CoPilot Incident Management → Alerts**
20
+5. Operator workflow → **Cases**
21
+
22
+## What data you get (high level)
23
+
24
+- Alerts/detections (depending on enabled exports)
25
+- Host/agent context (depending on integration design)
26
+
27
+## Setup (wireframe)
28
+
29
+- Configure Huntress under **External Services / 3rd Party Integrations**.
30
+- Ensure events are tenant-aware.
31
+
32
+## Success criteria
33
+
34
+- [ ] You can find at least one recent Huntress event/detection
35
+- [ ] It is associated with the expected customer
36
+
37
+## Dashboards
38
+
39
+- [ ] Confirm dashboards populate (after provisioning)
40
+
41
+## Alerts (starter set)
42
+
43
+- High-confidence Huntress detections promoted into SOC alerting
44
+- Repeated detections on the same host
45
+- New persistence indicators (if present in telemetry)
46
+
47
+## Troubleshooting
48
+
49
+- Verify external service status
50
+- Confirm export mechanism (API/webhook) and permissions
51
+- Confirm routing
docs/integrations/index.mdx
new
+44
@@ -0,0 +1,44 @@
1
+---
2
+title: Integrations
3
+description: Source-by-source setup guides and expectations for what data, dashboards, and alerts you get in CoPilot.
4
+---
5
+
6
+# Integrations
7
+
8
+This section is a **catalog**.
9
+
10
+Pick a source, follow a short setup guide, then validate that:
11
+
12
+- logs are ingesting
13
+- dashboards populate (after provisioning)
14
+- alerting can be enabled (built-in or custom)
15
+
16
+If you’re brand new, start with the guided checklist: [Start here](/getting-started/start-here).
17
+
18
+---
19
+
20
+## The mental model
21
+
22
+Almost every integration follows this pattern:
23
+
24
+1. **Ingest** events (API integration or syslog)
25
+2. Store events in your SIEM datastore (Wazuh Indexer / OpenSearch-backed)
26
+3. (Often) build alerts in **Graylog** → alerts land in `gl-events*`
27
+4. CoPilot shows alerts in **Incident Management → Alerts** → operators open **Cases**
28
+
29
+---
30
+
31
+## First-wave integrations
32
+
33
+- [Wazuh (endpoints)](/integrations/wazuh)
34
+- [Office 365](/integrations/office-365)
35
+- [Mimecast](/integrations/mimecast)
36
+- [Huntress](/integrations/huntress)
37
+- [CrowdStrike](/integrations/crowdstrike)
38
+
39
+## Network connectors (syslog)
40
+
41
+- [Network connectors overview](/integrations/network-connectors)
42
+- Fortinet: [FortiGate](/integrations/network-connectors/fortigate)
43
+- Palo Alto Networks: [PAN-OS](/integrations/network-connectors/palo-alto)
44
+- Cisco: [ASA](/integrations/network-connectors/cisco-asa)
docs/integrations/mimecast.mdx
new
+51
@@ -0,0 +1,51 @@
1
+---
2
+title: Mimecast
3
+description: Ingest Mimecast security events and turn them into dashboards and alerts in CoPilot.
4
+---
5
+
6
+# Mimecast
7
+
8
+## What this integration is
9
+
10
+Mimecast telemetry provides email security signals (policy actions, suspicious messages, detections) that are useful for SOC alerting and investigation.
11
+
12
+## Data path (how it flows)
13
+
14
+**Typical flow:**
15
+
16
+1. Mimecast → **External Service integration** (API collector)
17
+2. Events → **SIEM storage** (Wazuh Indexer / OpenSearch-backed)
18
+3. Optional: events → **Graylog** alert definitions
19
+4. Alerts → `gl-events*` → **CoPilot Incident Management → Alerts**
20
+5. Operator workflow → **Cases**
21
+
22
+## What data you get (high level)
23
+
24
+- Email security events
25
+- Policy actions / detections (depends on API endpoints enabled)
26
+
27
+## Setup (wireframe)
28
+
29
+- Configure Mimecast under **External Services / 3rd Party Integrations**.
30
+- Confirm events are tenant-aware.
31
+
32
+## Success criteria
33
+
34
+- [ ] You can locate at least one recent Mimecast event
35
+- [ ] Events map to the correct customer
36
+
37
+## Dashboards
38
+
39
+- [ ] After provisioning, confirm dashboards populate for this customer
40
+
41
+## Alerts (starter set)
42
+
43
+- Spike in blocked/quarantined messages
44
+- Repeated phishing detections for a user
45
+- High-risk sender domains or attachment types (if available)
46
+
47
+## Troubleshooting
48
+
49
+- Verify external service is connected/verified
50
+- Confirm API credentials/permissions
51
+- Confirm routing/tenant association
docs/integrations/network-connectors.mdx
new
+49
@@ -0,0 +1,49 @@
1
+---
2
+title: Network connectors (syslog)
3
+description: Vendor-by-vendor syslog ingestion patterns and validation steps.
4
+---
5
+
6
+# Network connectors (syslog)
7
+
8
+Network connectors ingest **syslog events** from firewalls and network devices (and some syslog-forwarding services).
9
+
10
+## Data path (how it flows)
11
+
12
+**Typical flow:**
13
+
14
+1. Network device → **syslog sender** (UDP/TCP)
15
+2. Syslog collector/ingestion → **Graylog** (inputs/streams/pipelines)
16
+3. Routed/normalized events → **Wazuh Indexer / OpenSearch-backed storage** (tenant-aware)
17
+4. Graylog alert definitions → `gl-events*` → **CoPilot Incident Management → Alerts**
18
+5. Operator workflow → **Cases**
19
+
20
+> The key requirement in multi-tenant setups is **tenant-aware routing**.
21
+
22
+## Vendor/device guides
23
+
24
+- [Fortinet FortiGate](/integrations/network-connectors/fortigate)
25
+- [Palo Alto Networks](/integrations/network-connectors/palo-alto)
26
+- [Cisco ASA](/integrations/network-connectors/cisco-asa)
27
+
28
+## Success criteria
29
+
30
+- [ ] Syslog events are arriving
31
+- [ ] You can identify the device/source
32
+- [ ] Events are routed/tagged to the correct customer
33
+- [ ] You can build at least one alert on top of the data (optional)
34
+
35
+## Starter alerts (generic)
36
+
37
+These are useful across most firewall/device syslog sources:
38
+
39
+- Excessive denies/drops from a single source IP
40
+- Inbound connections to sensitive ports (RDP/SSH/VPN admin)
41
+- New admin login or configuration change event
42
+- Threat/UTM events (if your device emits them)
43
+
44
+## Troubleshooting
45
+
46
+- Validate the device is sending to the correct IP/port
47
+- Confirm the collector is listening and receiving
48
+- Confirm parsing/extraction fields exist (vendor format)
49
+- Confirm routing rules / customer association
docs/integrations/network-connectors/cisco-asa.mdx
new
+38
@@ -0,0 +1,38 @@
1
+---
2
+title: Cisco ASA (syslog)
3
+---
4
+
5
+# Cisco ASA (syslog)
6
+
7
+## What you get (high level)
8
+
9
+- Firewall connection logs
10
+- ACL denies/permits
11
+- VPN-related logs (optional)
12
+
13
+## Data path (how it flows)
14
+
15
+ASA → syslog → ingestion/collector → Graylog parsing/routing → storage/indexing → alerts (`gl-events*`) → CoPilot Alerts/Cases.
16
+
17
+## Setup (wireframe)
18
+
19
+- Configure ASA logging + syslog destination.
20
+- Confirm downstream parsing and tenant-aware routing.
21
+
22
+## Success criteria
23
+
24
+- [ ] You can find fresh ASA events
25
+- [ ] You can identify the device/source
26
+- [ ] Events are routed to the correct customer
27
+
28
+## Starter alerts
29
+
30
+- Excessive denies/drops
31
+- VPN auth failures
32
+- Admin login/config change events
33
+
34
+## Troubleshooting
35
+
36
+- Confirm logging level
37
+- Confirm syslog host and interface
38
+- Confirm event volume is not overwhelming ingestion
docs/integrations/network-connectors/fortigate.mdx
new
+38
@@ -0,0 +1,38 @@
1
+---
2
+title: Fortinet FortiGate (syslog)
3
+---
4
+
5
+# Fortinet FortiGate (syslog)
6
+
7
+## What you get (high level)
8
+
9
+- Firewall traffic logs
10
+- Threat/UTM logs (depending on FortiGate config)
11
+- Admin/audit events (optional)
12
+
13
+## Data path (how it flows)
14
+
15
+FortiGate → syslog → ingestion/collector → Graylog parsing/routing → storage/indexing → alerts (`gl-events*`) → CoPilot Alerts/Cases.
16
+
17
+## Setup (wireframe)
18
+
19
+- Configure FortiGate to send syslog to your collector.
20
+- Ensure parsing and tenant-aware routing are in place.
21
+
22
+## Success criteria
23
+
24
+- [ ] You can find fresh FortiGate events
25
+- [ ] You can identify the sending device
26
+- [ ] Events are tenant-aware
27
+
28
+## Starter alerts
29
+
30
+- Excessive denies from a single source
31
+- Inbound connections to sensitive services
32
+- Admin login/config change events
33
+
34
+## Troubleshooting
35
+
36
+- Confirm FortiGate syslog destination and facility/severity
37
+- Confirm the collector is reachable from the FortiGate
38
+- Confirm key parsing fields exist downstream
docs/integrations/network-connectors/fortinet.mdx
new
+62
@@ -0,0 +1,62 @@
1
+---
2
+title: Fortinet FortiGate (syslog)
3
+description: Configure FortiGate to forward logs to your SIEM via syslog.
4
+---
5
+
6
+# Fortinet FortiGate (syslog)
7
+
8
+## What this connector is
9
+
10
+This connector covers how to configure a **Fortinet FortiGate** firewall to forward logs to your SIEM using **syslog**.
11
+
12
+---
13
+
14
+## Data path (how it flows)
15
+
16
+1) FortiGate → syslog (TCP/UDP)
17
+2) SIEM syslog input (typically Graylog)
18
+3) Stream/index routing + dashboards
19
+
20
+---
21
+
22
+## Configuration steps (FortiGate)
23
+
24
+### Step 1: Access the firewall
25
+
26
+- Open the FortiGate web UI (e.g., `https://192.168.1.99`)
27
+- Log in with administrative credentials
28
+
29
+### Step 2: Configure syslog forwarding
30
+
31
+In the FortiGate UI:
32
+
33
+- Go to **Log & Report**
34
+- Select **Log Settings**
35
+- Under **Syslog Servers**, click **Create New**
36
+
37
+Configure:
38
+- **Name:** recognizable name
39
+- **IP/Domain:** SIEM syslog server
40
+- **Reliable:** TCP (reliable) or UDP (faster)
41
+- **Port:** listening port (default 514)
42
+- **Facility:** e.g., Local7
43
+- **Source IP:** optional
44
+
45
+Note:
46
+- Syslog format is configured via FortiGate **CLI**. Set the format to **rfc5424**.
47
+
48
+### Step 3: Save
49
+
50
+Click **OK/Apply**.
51
+
52
+### Step 4: Verify reception
53
+
54
+Confirm logs appear on the SIEM syslog input.
55
+
56
+---
57
+
58
+## Additional considerations
59
+
60
+- Ensure firewall rules allow outbound syslog traffic to the SIEM.
61
+- If logs traverse the internet, use a secure transport (VPN/TLS collector pattern).
62
+- Keep NTP/time sync correct for reliable correlation.
docs/integrations/network-connectors/opnsense.mdx
new
+38
@@ -0,0 +1,38 @@
1
+---
2
+title: OPNsense (syslog)
3
+description: Configure OPNsense to forward logs to your SIEM via remote syslog.
4
+---
5
+
6
+# OPNsense (syslog)
7
+
8
+## What this connector is
9
+
10
+This connector covers how to configure **OPNsense** to forward logs to an external syslog server.
11
+
12
+Vendor reference:
13
+- https://docs.opnsense.org/manual/settingsmenu.html#logging
14
+
15
+---
16
+
17
+## Configuration steps (OPNsense)
18
+
19
+1) Log into the OPNsense web interface
20
+2) Navigate to **System → Settings → Logging**
21
+3) Check **Enable Remote Logging**
22
+4) Enter the syslog server hostname/IP under **Remote log servers**
23
+ - optionally set port (default 514) and protocol (UDP/TCP)
24
+5) Click **Save**
25
+
26
+---
27
+
28
+## Success criteria
29
+
30
+- [ ] Logs appear in your SIEM input
31
+- [ ] Source is attributed to the expected OPNsense device
32
+
33
+---
34
+
35
+## Notes
36
+
37
+- Ensure the network path is secure; consider VPN/TLS forwarding when logs traverse untrusted networks.
38
+- Ensure firewall rules allow outbound syslog traffic.
docs/integrations/network-connectors/palo-alto.mdx
new
+38
@@ -0,0 +1,38 @@
1
+---
2
+title: Palo Alto Networks (syslog)
3
+---
4
+
5
+# Palo Alto Networks (syslog)
6
+
7
+## What you get (high level)
8
+
9
+- Traffic logs
10
+- Threat logs
11
+- System logs (optional)
12
+
13
+## Data path (how it flows)
14
+
15
+PAN-OS → syslog → ingestion/collector → Graylog parsing/routing → storage/indexing → alerts (`gl-events*`) → CoPilot Alerts/Cases.
16
+
17
+## Setup (wireframe)
18
+
19
+- Configure PAN-OS to export syslog.
20
+- Confirm parsing and tenant-aware routing.
21
+
22
+## Success criteria
23
+
24
+- [ ] You can find fresh PAN logs
25
+- [ ] You can identify source device
26
+- [ ] Events are tenant-aware
27
+
28
+## Starter alerts
29
+
30
+- Threat log severity thresholding (high/critical)
31
+- Repeated denies/drops from a single source
32
+- Admin login/config change events
33
+
34
+## Troubleshooting
35
+
36
+- Confirm syslog profile and server configuration
37
+- Confirm connectivity and UDP/TCP choice
38
+- Confirm parsing fields exist
docs/integrations/network-connectors/sentinelone.mdx
new
+64
@@ -0,0 +1,64 @@
1
+---
2
+title: SentinelOne (syslog over TLS)
3
+description: Forward SentinelOne alerts/events to the SIEM using TLS (mutual auth).
4
+---
5
+
6
+# SentinelOne (syslog over TLS)
7
+
8
+## What this connector is
9
+
10
+This connector forwards **SentinelOne** alerts and events to your SIEM using **TLS-encrypted syslog** with **mutual authentication**.
11
+
12
+Detailed guide:
13
+- https://socfortress.supportbench.net/article/sentinelone-syslog-forwarder-to-siem-stack
14
+
15
+---
16
+
17
+## Architecture
18
+
19
+```
20
+SentinelOne Cloud → TLS (mutual auth) → SIEM Stack
21
+```
22
+
23
+---
24
+
25
+## Setup steps (high level)
26
+
27
+### 1) Configure Syslog integration in SentinelOne
28
+
29
+- Log into the SentinelOne console
30
+- Go to **Settings → Integrations**
31
+- Select **Syslog**
32
+
33
+Set:
34
+- **Host:** SIEM FQDN/IP
35
+- **Port:** typically 6514 for TLS
36
+- Enable **Use TLS secure connection**
37
+- Syslog format: **RFC-5424**
38
+
39
+### 2) Upload certificates (mutual TLS)
40
+
41
+You’ll typically upload:
42
+- Root CA certificate
43
+- Client certificate
44
+- Client private key
45
+
46
+### 3) Firewall rules
47
+
48
+Ensure inbound rules allow SentinelOne cloud endpoints to reach your syslog listener, and that internal routing allows traffic to Graylog.
49
+
50
+### 4) Select event types
51
+
52
+In the integration’s Notifications tab, select which event categories to forward.
53
+
54
+### 5) Test
55
+
56
+Use **Test Connection** and confirm events arrive in the SIEM.
57
+
58
+---
59
+
60
+## Troubleshooting
61
+
62
+- TLS handshake failures: validate PEM formats, chain, and expiry.
63
+- Missing events: confirm event types selected + verify ingestion parsing.
64
+- Connectivity: confirm firewall/NAT and correct port.
docs/integrations/network-connectors/sonicwall.mdx
new
+65
@@ -0,0 +1,65 @@
1
+---
2
+title: SonicWall (syslog)
3
+description: Forward SonicWall firewall logs to the SIEM via direct syslog or syslog-ng with TLS.
4
+---
5
+
6
+# SonicWall (syslog)
7
+
8
+## What this connector is
9
+
10
+This connector covers two approaches for forwarding **SonicWall** logs to your SIEM:
11
+
12
+1) Direct syslog forwarding (UDP/TCP)
13
+2) Syslog-NG collector (local UDP) → TLS forwarding (recommended for production)
14
+
15
+Direct syslog guide:
16
+- https://socfortress.supportbench.net/ar-1084/
17
+
18
+---
19
+
20
+## Method 1: Direct syslog forwarding (UDP/TCP)
21
+
22
+1) Log into SonicWall web management UI
23
+2) Go to **Log → Settings → Syslog**
24
+3) Enable syslog
25
+4) Configure syslog server:
26
+ - Host/IP
27
+ - Port
28
+ - Format (Syslog or CEF)
29
+ - Optional Syslog ID
30
+5) Select log categories (attacks, drops, user activity, etc.)
31
+6) Apply/Accept
32
+
33
+Validate logs arrive in the SIEM.
34
+
35
+---
36
+
37
+## Method 2: Syslog-NG collector (recommended)
38
+
39
+### Architecture
40
+
41
+```
42
+SonicWall (UDP) → Syslog-NG Collector (local) → TLS → SIEM Stack
43
+```
44
+
45
+### Steps (high level)
46
+
47
+1) Deploy a local syslog-ng collector:
48
+ - https://socfortress.supportbench.net/article/local-log-collector-using-syslog-ng
49
+
50
+2) Point SonicWall syslog destination to the **local collector IP**
51
+
52
+3) Configure syslog-ng to forward via **TLS** to the SIEM
53
+
54
+4) Verify end-to-end flow:
55
+ - collector receiving
56
+ - TLS connection established
57
+ - SIEM receiving and parsing
58
+
59
+---
60
+
61
+## Notes
62
+
63
+- If logs traverse the internet, prefer TLS forwarding.
64
+- Keep NTP/time sync correct.
65
+- Monitor log volume.
docs/integrations/office-365.mdx
new
+54
@@ -0,0 +1,54 @@
1
+---
2
+title: Office 365
3
+description: Ingest Microsoft 365 audit and sign-in telemetry, then visualize and alert on it in CoPilot.
4
+---
5
+
6
+# Office 365
7
+
8
+## What this integration is
9
+
10
+Office 365 (Microsoft 365) telemetry is typically **API-collected** audit/sign-in activity that becomes part of your tenant’s SIEM dataset.
11
+
12
+## Data path (how it flows)
13
+
14
+**Typical flow:**
15
+
16
+1. Microsoft 365 → **External Service integration** (API collector)
17
+2. Events → **SIEM storage** (Wazuh Indexer / OpenSearch-backed)
18
+3. Optional: events → **Graylog** alert definitions
19
+4. Alerts → `gl-events*` → **CoPilot Incident Management → Alerts**
20
+5. Operator workflow → **Cases**
21
+
22
+## What data you get (high level)
23
+
24
+- Audit activity (user/admin activity)
25
+- Authentication/sign-in related events (depending on collector scope)
26
+
27
+## Setup (wireframe)
28
+
29
+- Configure Office 365 under **External Services / 3rd Party Integrations**.
30
+- Ensure events are **tenant-aware** (associated with the correct customer).
31
+
32
+## Success criteria
33
+
34
+- [ ] You can locate at least one **recent** Office 365 event in CoPilot
35
+- [ ] The event is associated with the expected customer
36
+
37
+## Dashboards
38
+
39
+After provisioning, CoPilot can deploy templated dashboards for supported integrations.
40
+
41
+- [ ] Confirm relevant Grafana dashboards for this customer are **populated** (not empty panels)
42
+
43
+## Alerts (starter set)
44
+
45
+- Suspicious sign-ins (impossible travel / unfamiliar location, if available)
46
+- Admin role changes
47
+- Mailbox forwarding / inbox rule changes
48
+- OAuth consent / suspicious app registrations (if available)
49
+
50
+## Troubleshooting
51
+
52
+- Verify the external service/integration is connected and healthy
53
+- Confirm customer code / tenant routing assumptions
54
+- Validate the ingestion pipeline (collector → storage → CoPilot view)
docs/integrations/sap-siem.mdx
new
+50
@@ -0,0 +1,50 @@
1
+---
2
+title: SAP SIEM (Customer Data Cloud)
3
+description: Collect SAP Customer Data Cloud audit events and forward them into the SOCFortress SIEM stack.
4
+---
5
+
6
+# SAP SIEM (Customer Data Cloud)
7
+
8
+## What this integration is
9
+
10
+This integration collects **audit events** from SAP Customer Data Cloud (Gigya) and forwards them into your SOCFortress SIEM stack.
11
+
12
+It may also support higher-level detections such as:
13
+- multiple logins detection
14
+- suspicious login detection
15
+
16
+Vendor reference:
17
+- SAP doc: https://help.sap.com/docs/SAP_CUSTOMER_DATA_CLOUD/8b8d6fffe113457094a17701f63e3d6a/4143815a70b21014bbc5a10ce4041860.html
18
+
19
+---
20
+
21
+## Credentials you’ll need
22
+
23
+- API Key
24
+- User Key
25
+- Secret Key
26
+- API Domain (site domain)
27
+
28
+---
29
+
30
+## CoPilot setup (recommended workflow)
31
+
32
+1) Provision the customer.
33
+2) Add the **SAP SIEM** integration under the customer.
34
+3) Provide the API key/user key/secret and domain.
35
+4) Validate events arrive and are searchable.
36
+
37
+---
38
+
39
+## Success criteria
40
+
41
+- [ ] Audit events appear for the expected tenant
42
+- [ ] Optional detections (if enabled) mark/analyze events as expected
43
+
44
+---
45
+
46
+## Troubleshooting
47
+
48
+- Confirm you are using the correct domain/region for your SAP tenant.
49
+- Confirm the secret is the one associated with the userKey.
50
+- Ensure HTTPS is used when required by the auth method.
docs/integrations/wazuh.mdx
new
+55
@@ -0,0 +1,55 @@
1
+---
2
+title: Wazuh (endpoints)
3
+description: Endpoint log ingestion and security telemetry via Wazuh.
4
+---
5
+
6
+# Wazuh (endpoints)
7
+
8
+## What this integration is
9
+
10
+Wazuh is the primary endpoint telemetry source in many CoPilot deployments.
11
+
12
+It provides:
13
+- endpoint security events
14
+- agent inventory/health
15
+- vulnerability and SCA signals (when enabled)
16
+
17
+## Data path (how it flows)
18
+
19
+**Typical flow:**
20
+
21
+1. Endpoints → **Wazuh agent**
22
+2. Wazuh Manager → decoding/rules → events
23
+3. Events → **Wazuh Indexer / OpenSearch-backed storage**
24
+4. Optional: events → **Graylog** for search + alerting (environment-dependent)
25
+5. Alerts → `gl-events*` → **CoPilot Incident Management → Alerts**
26
+6. Operator workflow → **Cases**
27
+
28
+## Setup (wireframe)
29
+
30
+- Configure and verify the **Wazuh connector** in CoPilot.
31
+- Enroll at least one agent and ensure it’s tagged/routed to the correct customer context.
32
+
33
+## Success criteria
34
+
35
+- [ ] A test endpoint appears in CoPilot **Agents** and is online
36
+- [ ] You can find recent endpoint events
37
+- [ ] (Optional) You can tune detection rules and see changes reflected in alert volume
38
+
39
+## Dashboards
40
+
41
+After provisioning, default dashboards can be deployed per customer.
42
+
43
+- [ ] Confirm dashboards populate for the customer (endpoint/security views)
44
+
45
+## Alerts (starter set)
46
+
47
+- High-severity authentication events
48
+- Suspicious process/command execution signals (where applicable)
49
+- Privilege changes / new admin users
50
+
51
+## Troubleshooting
52
+
53
+- Confirm agent enrollment and connectivity to Wazuh Manager
54
+- Confirm indexing/storage health
55
+- Confirm tenant routing/customer association
docs/operator.mdx
new
+23
@@ -0,0 +1,23 @@
1
+---
2
+title: Operator Guide
3
+description: Playbooks and workflows for SOC operators and analysts using CoPilot.
4
+---
5
+
6
+# Operator Guide
7
+
8
+This section is organized by **outcomes** (what you’re trying to do), not menu items.
9
+
10
+## Start here
11
+
12
+- [Operator quickstart](/user/operators-quickstart)
13
+- [First wins (30 minutes)](/getting-started/first-wins)
14
+
15
+## Daily workflow
16
+
17
+- [Triage alerts](/user/ui/incident-alerts)
18
+- [Work cases](/user/ui/incident-cases)
19
+- [Artifacts & evidence](/user/ui/artifacts)
20
+
21
+## Video walkthroughs
22
+
23
+- [Operator track videos](/user/videos#operator-track)
docs/power-features.mdx
new
+34
@@ -0,0 +1,34 @@
1
+---
2
+title: Power features
3
+description: Add-on capabilities that extend CoPilot beyond the core ingest→detect→respond loop.
4
+---
5
+
6
+# Power features
7
+
8
+These features make CoPilot more powerful, but they’re not required for the initial SIEM bring-up.
9
+
10
+If you’re still onboarding, start with the guided checklist: [Start here](/getting-started/start-here).
11
+
12
+---
13
+
14
+## How to think about power features
15
+
16
+Power features usually fit into one of these buckets:
17
+
18
+- **Exposure management** (patch/vuln posture)
19
+- **Assessment** (cloud/web scanning outputs)
20
+- **Reporting** (shareable artifacts)
21
+- **Acceleration** (AI assistance)
22
+
23
+They typically have additional inputs (connectors, permissions, targets) and should be rolled out after your core ingest→alerting path is healthy.
24
+
25
+---
26
+
27
+## Included modules
28
+
29
+- [Microsoft Patch Tuesday](/power-features/patch-tuesday)
30
+- [Cloud security assessment (Scout Suite)](/power-features/cloud-security-assessment)
31
+- [Web vulnerability assessment (Nuclei)](/power-features/web-vulnerability-assessment)
32
+- [GitHub audit](/power-features/github-audit)
33
+- [AI analyst / AI-assisted investigation](/power-features/ai-analyst)
34
+- [Report creation](/power-features/report-creation)
docs/power-features/_template.mdx
new
+41
@@ -0,0 +1,41 @@
1
+---
2
+title: Power feature template
3
+---
4
+
5
+# Feature name
6
+
7
+## What it is
8
+
9
+## Who this is for
10
+
11
+- Admin / Platform
12
+- Operator
13
+
14
+## Inputs (what it needs)
15
+
16
+- Required connectors/integrations
17
+- Required data sources
18
+
19
+## Outputs (what you get)
20
+
21
+- UI views
22
+- Reports/artifacts
23
+- Alerts (if applicable)
24
+
25
+## Where it lives in the UI
26
+
27
+- Menu path and/or route
28
+
29
+## Success criteria
30
+
31
+- [ ] The feature loads and returns data
32
+- [ ] You can complete one end-to-end action
33
+
34
+## Safety / guardrails
35
+
36
+- What this feature should and should not be used for
37
+- Any exposure cautions
38
+
39
+## Troubleshooting
40
+
41
+- Most common failure points
docs/power-features/ai-analyst.mdx
new
+142
@@ -0,0 +1,142 @@
1
+---
2
+title: AI analyst / AI-assisted investigation
3
+description: AI-assisted workflows to speed up alert triage, investigation, and knowledge capture across your open-source SIEM stack.
4
+---
5
+
6
+# AI analyst / AI-assisted investigation
7
+
8
+CoPilot’s AI features are designed to reduce context switching and speed up common SOC workflows:
9
+- understand an alert faster ("what am I looking at?")
10
+- decide what to do next ("benign or investigate?")
11
+- generate drafts for repetitive engineering tasks (exclusions/tuning)
12
+- chat with your stack (Wazuh, Velociraptor, CoPilot) using natural language
13
+
14
+---
15
+
16
+## What it is
17
+
18
+In the videos, AI in CoPilot shows up in two main ways:
19
+
20
+### 1) AI analyst (alert-focused)
21
+
22
+AI analyst is embedded directly into CoPilot’s alert experience.
23
+
24
+Typical flow:
25
+1) Open an alert
26
+2) Select the impacted asset/hostname
27
+3) Use **AI analyst** to generate context and suggested next steps
28
+
29
+It can help:
30
+- summarize what triggered the detection
31
+- explain why the behavior can be suspicious
32
+- suggest what to validate next (triage steps)
33
+
34
+The same area can also support workflows like drafting **Wazuh exclusion rules** for noisy/expected behavior.
35
+
36
+### 2) AI chatbot / “chat with your stack” (tool-assisted)
37
+
38
+CoPilot can expose an AI chatbot that can interface with:
39
+- **Wazuh Manager**
40
+- **Wazuh Indexer (OpenSearch)**
41
+- **Velociraptor**
42
+- **CoPilot**
43
+
44
+This makes it possible to ask questions like:
45
+- “show me recent alerts for customer X”
46
+- “pull surrounding events for this index document”
47
+- “run a Velociraptor artifact on host Y”
48
+
49
+…and have CoPilot handle the underlying API/tool calls.
50
+
51
+The chatbot can also be extended with additional “tools” (as shown in the videos), such as:
52
+- threat intelligence lookups (IP/domain reputation)
53
+- cyber news summaries
54
+- internal knowledge base search/summarization
55
+- high-level attack surface/exposure checks
56
+
57
+---
58
+
59
+## Why this is a power feature
60
+
61
+AI assistance is most valuable after your core stack is stable:
62
+- alerts are flowing
63
+- assets/customers are properly scoped
64
+- investigation pivots work (index_id/index_name, artifacts, cases)
65
+
66
+Once that foundation is in place, AI can:
67
+- reduce time-to-understanding for analysts
68
+- standardize triage narratives
69
+- accelerate tuning (without living in XML/rules all day)
70
+
71
+---
72
+
73
+## Operator workflows (practical)
74
+
75
+### Triage an alert faster
76
+
77
+1) Open the alert and review key fields (command line, parent process, user, host)
78
+2) Run **AI analyst** to get:
79
+ - a plain-English explanation of the detection
80
+ - what makes it suspicious
81
+ - recommended validation steps
82
+3) Decide:
83
+ - escalate/investigate further, or
84
+ - mark as expected (and consider tuning)
85
+
86
+### Draft a Wazuh exclusion rule (noise reduction)
87
+
88
+If an alert is expected/benign but noisy:
89
+1) collect the key discriminators (image, command line pattern, user, parent, host group)
90
+2) generate a draft exclusion rule
91
+3) review it like code (avoid over-broad exclusions)
92
+4) deploy + validate
93
+
94
+### Chat with your stack (investigation + response)
95
+
96
+Use the chatbot when you want to do “SOC glue work” quickly:
97
+- ask questions against recent alerts
98
+- pivot into index logs for context
99
+- run Velociraptor collections/artifacts without leaving CoPilot
100
+
101
+---
102
+
103
+## Setup checklist (high level)
104
+
105
+Exact steps depend on your CoPilot release, but the videos show a common pattern:
106
+
107
+1) **Update your CoPilot deployment**
108
+ - pull the latest images
109
+ - update `docker-compose.yml` with the new AI/MCP service (if required)
110
+
111
+2) **Configure AI provider access**
112
+ - set your model provider API key(s) (example shown in the video: OpenAI)
113
+
114
+3) **Configure stack connectivity for tool-assisted chat**
115
+ - Wazuh Indexer (OpenSearch) URL + credentials
116
+ - Wazuh Manager connection details (if used)
117
+ - Velociraptor connection details
118
+
119
+4) **Validate permissions + scoping**
120
+ - ensure users can only summarize/ask questions over data they’re authorized to access (multi-tenant safety)
121
+
122
+---
123
+
124
+## Safety / guardrails
125
+
126
+- Don’t paste secrets into prompts.
127
+- Treat AI output as a draft: verify before acting.
128
+- Be careful with exclusion rules: tune precisely to avoid blinding detections.
129
+- Restrict access: AI can summarize sensitive customer data; enforce RBAC/tenant scoping.
130
+
131
+---
132
+
133
+## Video context
134
+
135
+- AI analyst (alert-context + exclusion-rule assistance):
136
+ - https://www.youtube.com/watch?v=-2srPC-Dw-0
137
+
138
+- AI chatbot + MCP-style “chat with your stack” (Wazuh/Indexer/Velociraptor/CoPilot):
139
+ - https://www.youtube.com/watch?v=FHjD9QBaLD4
140
+
141
+- Expanded AI companion features (threat intel, cyber news, knowledge base search, exposure view):
142
+ - https://www.youtube.com/watch?v=QaLrmSgEcLI
docs/power-features/atomic-red-team.mdx
new
+127
@@ -0,0 +1,127 @@
1
+---
2
+title: Atomic Red Team (detection simulation)
3
+description: Run Atomic Red Team simulations to verify telemetry flow and validate that Wazuh detection rules fire as expected.
4
+---
5
+
6
+# Atomic Red Team (detection simulation)
7
+
8
+Atomic Red Team is a detection validation workflow: you simulate known adversary behaviors (“atomic tests”) and confirm your stack detects what it should.
9
+
10
+In CoPilot, this is commonly used to:
11
+- validate that **telemetry is flowing** end-to-end
12
+- verify your **Wazuh detection rules** are triggering as expected
13
+- identify blind spots and tuning opportunities before a real attacker shows up
14
+
15
+
16
+
17
+---
18
+
19
+## What it is
20
+
21
+Atomic Red Team is a library of small, self-contained tests mapped to the **MITRE ATT&CK** framework.
22
+
23
+Regularly running these tests helps:
24
+- prevent detection drift
25
+- validate new rules and changes
26
+- confirm the “alerting pipeline” still works after upgrades
27
+
28
+---
29
+
30
+## Why this is a power feature
31
+
32
+Detection simulation isn’t required for initial SIEM bring-up, but it’s one of the best ways to build confidence in your detections.
33
+
34
+It’s especially valuable when:
35
+- you just deployed new Wazuh rules
36
+- you changed Sysmon collection or agent group configs
37
+- you’re onboarding a new customer and need to prove coverage
38
+
39
+---
40
+
41
+## How it works (high level)
42
+
43
+The workflow shown in the videos:
44
+
45
+1) Install Atomic Red Team on an endpoint (Windows or Linux)
46
+2) Use a **Velociraptor artifact** to run a chosen atomic test remotely
47
+3) Confirm events are collected and shipped (agent → manager/indexer → Graylog/CoPilot)
48
+4) Validate:
49
+ - the expected alert fired
50
+ - the alert arrived in the right place (SIEM views and/or Incident Management)
51
+
52
+---
53
+
54
+## Operator workflow (practical)
55
+
56
+1) Choose a technique/test you want to validate (start with something safe)
57
+2) Run it on a **dedicated test endpoint** (recommended)
58
+3) Watch for:
59
+ - Wazuh alert firing
60
+ - the event appearing in SIEM search
61
+ - the alert being routed into Incident Management (if that’s part of your pipeline)
62
+4) If it didn’t fire:
63
+ - validate telemetry collection (Sysmon/auditd)
64
+ - validate rule logic and mapping
65
+ - validate routing/streams/event definitions
66
+
67
+---
68
+
69
+## Setup checklist
70
+
71
+### 1) Use a safe test target
72
+
73
+- Prefer a **lab endpoint** (not production)
74
+- Document which tests you run and when
75
+
76
+### 2) Install Atomic Red Team
77
+
78
+The videos demonstrate installing Atomic Red Team so the test library exists locally on the endpoint.
79
+
80
+### 3) Import Velociraptor artifacts to run tests remotely
81
+
82
+A key improvement is using Velociraptor artifacts to run tests without manually SSH/RDP’ing into hosts.
83
+
84
+Canonical repo for the Atomic Red Team Velociraptor artifacts:
85
+- https://github.com/socfortress/VELOCIRAPTOR-ATOMIC-RED-ARTIFACTS
86
+
87
+The videos reference:
88
+- a Windows Atomic test execution artifact
89
+- a Linux attack simulation artifact
90
+
91
+Once imported into Velociraptor, CoPilot/Velociraptor can run tests in a repeatable way.
92
+
93
+### 4) Validate detection + routing
94
+
95
+Use CoPilot to confirm the end-to-end path:
96
+- detections trigger in Wazuh
97
+- events are searchable in your datastore
98
+- alerts show up where you expect (SIEM views vs Incident Management)
99
+
100
+---
101
+
102
+## Where to find it
103
+
104
+- UI: [Atomic Red Team (alerts view)](/user/ui/alerts-atomic-red-team)
105
+
106
+---
107
+
108
+## Gotchas
109
+
110
+- Don’t run aggressive tests on production systems.
111
+- Some tests can create artifacts (scheduled tasks, registry changes, etc.). Understand cleanup behavior before running.
112
+- A “failed” test is still useful: it often reveals missing telemetry, broken routing, or overly strict rule logic.
113
+
114
+---
115
+
116
+## Related repositories
117
+
118
+- Velociraptor Atomic Red artifacts:
119
+ - https://github.com/socfortress/VELOCIRAPTOR-ATOMIC-RED-ARTIFACTS
120
+
121
+## Video context
122
+
123
+- Windows-focused validation workflow:
124
+ - https://www.youtube.com/watch?v=TMJOBATTK9M
125
+
126
+- Linux-focused validation workflow:
127
+ - https://www.youtube.com/watch?v=tL3oNEx_3M8
docs/power-features/cloud-security-assessment.mdx
new
+121
@@ -0,0 +1,121 @@
1
+---
2
+title: Cloud security assessment (Scout Suite)
3
+description: Run Scout Suite scans inside CoPilot to generate cloud posture reports (AWS supported; Azure/GCP may be limited depending on release).
4
+---
5
+
6
+# Cloud security assessment (Scout Suite)
7
+
8
+CoPilot can run **Scout Suite** scans and surface the resulting report inside the UI.
9
+
10
+Scout Suite is an open-source cloud security assessment tool that scans a cloud account via provider APIs, identifies risky configurations, and generates a report with remediation guidance.
11
+
12
+---
13
+
14
+## Why this is a power feature
15
+
16
+Cloud posture assessment is not required for the initial SIEM bring-up, but it becomes valuable once your core pipeline is healthy.
17
+
18
+Use it for:
19
+- periodic cloud posture reviews (monthly/quarterly)
20
+- identifying misconfigurations and risky exposures
21
+- producing a shareable “here’s what to fix next” report for stakeholders
22
+
23
+---
24
+
25
+## How it works in CoPilot (high level)
26
+
27
+1) You create cloud credentials with read-only assessment permissions (provider-specific)
28
+2) In CoPilot, you create a new cloud assessment report
29
+3) CoPilot runs Scout Suite in the background
30
+4) When complete, the report is listed and can be opened/viewed in CoPilot
31
+
32
+---
33
+
34
+## Supported providers
35
+
36
+- **AWS**
37
+- **Azure**
38
+- **Google Cloud (GCP)**
39
+
40
+CoPilot can run Scout Suite scans for these providers as long as the appropriate credentials and API permissions are in place.
41
+
42
+---
43
+
44
+## Setup checklist (AWS / Azure / GCP)
45
+
46
+### 1) Create a dedicated Scout Suite cloud principal
47
+
48
+Create a dedicated identity for assessments:
49
+- **AWS:** IAM user/role
50
+- **Azure:** App registration / service principal
51
+- **GCP:** service account
52
+
53
+Guidance:
54
+- Use **least privilege**.
55
+- Prefer read-only where possible.
56
+
57
+Provider-specific credential setup (recommended):
58
+- AWS: https://github.com/nccgroup/ScoutSuite/wiki/Amazon-Web-Services
59
+- Azure: https://github.com/nccgroup/ScoutSuite/wiki/Azure
60
+- GCP: https://github.com/nccgroup/ScoutSuite/wiki/Google-Cloud-Platform
61
+
62
+### 2) Generate credentials
63
+
64
+Create the credentials required for the provider you’re scanning.
65
+
66
+Common patterns from the Scout Suite wiki:
67
+- **AWS:** standard AWS credential sources (profiles in `~/.aws/credentials`, environment variables, role assumption, or explicit access keys)
68
+- **Azure:** Azure CLI login, user-account browser login (MFA-friendly), or service principal (including file-based SDK auth)
69
+- **GCP:** application-default user credentials or a service account key JSON
70
+
71
+### 3) Run the scan in CoPilot
72
+
73
+In CoPilot:
74
+1) Open **Cloud security assessment**
75
+2) Select provider type (AWS / Azure / GCP)
76
+3) Set a report name
77
+4) Enter credentials
78
+5) Submit
79
+
80
+The scan runs in the background. Runtime depends on the size of the cloud environment.
81
+
82
+Operational tip (from the video):
83
+- You can tail CoPilot container logs to see when report generation completes.
84
+- Use Refresh in the UI; when done, the report appears in the list.
85
+
86
+---
87
+
88
+## Success criteria
89
+
90
+- [ ] You can create a report and the scan completes
91
+- [ ] The report shows in the UI after refresh
92
+- [ ] The report content is accessible to authorized users
93
+
94
+---
95
+
96
+## Safety / guardrails
97
+
98
+- Cloud posture reports can contain sensitive inventory details (accounts, resources, IAM relationships).
99
+ - Restrict access (RBAC) appropriately.
100
+- Use dedicated credentials and rotate them.
101
+- Avoid storing long-lived keys if your environment supports roles/short-lived credentials.
102
+
103
+---
104
+
105
+## Troubleshooting
106
+
107
+- Report never appears:
108
+ - confirm credentials are valid
109
+ - confirm required API permissions exist
110
+ - check CoPilot container logs for Scout Suite errors
111
+
112
+- Report takes a long time:
113
+ - large environments can take longer to enumerate
114
+ - rerun during a quieter window
115
+
116
+---
117
+
118
+## Video context
119
+
120
+Walkthrough + setup:
121
+- https://www.youtube.com/watch?v=G3MDJSMvnRo
docs/power-features/github-audit.mdx
new
+40
@@ -0,0 +1,40 @@
1
+---
2
+title: GitHub audit
3
+description: Collect and review GitHub audit-related data inside CoPilot.
4
+---
5
+
6
+# GitHub audit
7
+
8
+## What it is
9
+
10
+CoPilot contains schema and capability to store GitHub audit-related data (wireframe).
11
+
12
+## Who this is for
13
+
14
+- **Admin / Platform**: org security posture and governance
15
+
16
+## Inputs (what it needs)
17
+
18
+- GitHub org access and permissions to collect audit/security signals (implementation-dependent)
19
+
20
+## Outputs (what you get)
21
+
22
+- Audit views / reports (to be documented)
23
+
24
+## Where it lives in the UI
25
+
26
+- (Wireframe) This page will be updated with the exact menu path/route.
27
+
28
+## Success criteria
29
+
30
+- [ ] GitHub audit data can be collected
31
+- [ ] Data can be displayed and searched
32
+
33
+## Safety / guardrails
34
+
35
+- Treat audit exports as sensitive (users, access patterns, security events).
36
+
37
+## Troubleshooting
38
+
39
+- Confirm GitHub permissions/token scopes
40
+- Confirm collection job is running and storing results
docs/power-features/index.mdx
new
+36
@@ -0,0 +1,36 @@
1
+---
2
+title: Power features
3
+description: Add-on capabilities that extend CoPilot beyond the core ingest→detect→respond loop.
4
+---
5
+
6
+# Power features
7
+
8
+These features make CoPilot more powerful, but they’re not required for the initial SIEM bring-up.
9
+
10
+If you’re still onboarding, start with the guided checklist: [Start here](/getting-started/start-here).
11
+
12
+---
13
+
14
+## How to think about power features
15
+
16
+Power features usually fit into one of these buckets:
17
+
18
+- **Exposure management** (patch/vuln posture)
19
+- **Assessment** (cloud/web scanning outputs)
20
+- **Reporting** (shareable artifacts)
21
+- **Acceleration** (AI assistance)
22
+
23
+They typically have additional inputs (connectors, permissions, targets) and should be rolled out after your core ingest→alerting path is healthy.
24
+
25
+---
26
+
27
+## Included modules
28
+
29
+- [MITRE ATT&CK integration](/power-features/mitre-attack)
30
+- [Microsoft Patch Tuesday](/power-features/patch-tuesday)
31
+- [Cloud security assessment (Scout Suite)](/power-features/cloud-security-assessment)
32
+- [Web vulnerability assessment (Nuclei)](/power-features/web-vulnerability-assessment)
33
+- [GitHub audit](/power-features/github-audit)
34
+- [AI analyst / AI-assisted investigation](/power-features/ai-analyst)
35
+- [Atomic Red Team (detection simulation)](/power-features/atomic-red-team)
36
+- [Report creation](/power-features/report-creation)
docs/power-features/mitre-attack.mdx
new
+107
@@ -0,0 +1,107 @@
1
+---
2
+title: MITRE ATT&CK integration
3
+description: Technique-centric investigation and coverage lens powered by MITRE technique enrichment in Wazuh rules.
4
+---
5
+
6
+# MITRE ATT&CK integration
7
+
8
+MITRE ATT&CK in CoPilot gives you a technique-centric lens across alerts/events. It’s useful for:
9
+- coverage conversations (“what do we detect?”)
10
+- investigation context (“what does this behavior usually mean?”)
11
+- mapping detections to a globally recognized adversary behavior framework
12
+
13
+
14
+
15
+---
16
+
17
+## What it is
18
+
19
+MITRE ATT&CK is a widely used framework that maps adversary behavior from **initial access** through **execution, persistence, lateral movement, and exfiltration**.
20
+
21
+In CoPilot, the MITRE ATT&CK view is built from **MITRE technique IDs attached to Wazuh rules**.
22
+
23
+Key idea:
24
+- When a Wazuh rule fires and includes MITRE technique metadata, CoPilot can display that technique and group related events under it.
25
+
26
+---
27
+
28
+## Why this is a power feature
29
+
30
+Most SIEM alert views are “alert-first.” MITRE ATT&CK flips it to “behavior-first.”
31
+
32
+This helps:
33
+- leadership and customers understand coverage in a standardized language
34
+- analysts quickly interpret what a detection is *trying* to tell them
35
+- detection engineers spot gaps (tactics/techniques you never hit)
36
+
37
+---
38
+
39
+## How technique enrichment works (Wazuh)
40
+
41
+Wazuh’s rule syntax supports attaching MITRE technique IDs to a rule.
42
+
43
+That means:
44
+- default Wazuh rules can provide technique mappings
45
+- your custom rules can also include technique IDs
46
+- SOCFortress rules can include technique IDs as part of your tuned ruleset
47
+
48
+When those rules generate events, CoPilot can present them inside the MITRE ATT&CK experience.
49
+
50
+---
51
+
52
+## What you can do in the UI
53
+
54
+When you open a technique, CoPilot shows an overview page with:
55
+- description
56
+- references
57
+- direct link out to the MITRE technique page
58
+
59
+
60
+
61
+You can then pivot through supporting tabs such as:
62
+- **Tactics** (the “why” / objectives)
63
+- **Mitigations** (recommended controls)
64
+- **Software** (tools/malware commonly associated)
65
+- **Alerts / events** mapped to that technique
66
+- **Atomic tests** (where available) to validate detections
67
+
68
+
69
+
70
+---
71
+
72
+## Operator workflow (practical)
73
+
74
+Use MITRE ATT&CK when you want a fast interpretation loop:
75
+
76
+1) Open **Alerts → MITRE ATT&CK**
77
+2) Pick a technique showing activity
78
+3) Review tactics/mitigations/software context
79
+4) Pivot into the linked alerts/events for the concrete evidence
80
+5) If you’re testing, run an Atomic test to validate end-to-end detection coverage
81
+
82
+---
83
+
84
+## Prerequisites
85
+
86
+- Wazuh detections are flowing into the stack
87
+- Your Wazuh rules include MITRE technique IDs (default rules + your custom rules)
88
+
89
+---
90
+
91
+## Gotchas
92
+
93
+- MITRE mapping quality depends on rule metadata. If a rule has no technique ID, it won’t show up here.
94
+- This view is best for context and coverage—not necessarily the primary incident queue.
95
+
96
+---
97
+
98
+## Where to find it
99
+
100
+- UI: [MITRE ATT&CK (alerts view)](/user/ui/alerts-mitre)
101
+
102
+---
103
+
104
+## Video context
105
+
106
+Walkthrough of the feature:
107
+- https://www.youtube.com/watch?v=wK4aA7QrXmE
docs/power-features/patch-tuesday.mdx
new
+50
@@ -0,0 +1,50 @@
1
+---
2
+title: Microsoft Patch Tuesday
3
+description: Track and prioritize Microsoft monthly vulnerabilities inside CoPilot.
4
+---
5
+
6
+# Microsoft Patch Tuesday
7
+
8
+## What it is
9
+
10
+CoPilot includes a Patch Tuesday experience to help operators/admins track and prioritize Microsoft monthly vulnerabilities.
11
+
12
+## Who this is for
13
+
14
+- **Admin / Platform**: triage exposure and prioritize remediation
15
+- **Operator**: understand which CVEs matter during investigations
16
+
17
+## Inputs (what it needs)
18
+
19
+- Internet access for Patch Tuesday data fetch (implementation-dependent)
20
+- No endpoint agent changes required
21
+
22
+## Outputs (what you get)
23
+
24
+- Cycle summary (current/recent)
25
+- Search and prioritization helpers
26
+
27
+## Where it lives in the UI
28
+
29
+- **Agents → Patch Tuesday**
30
+- Route: `/patch-tuesday`
31
+
32
+Operator walkthrough (UI guide):
33
+- [Patch Tuesday (Microsoft)](/user/ui/agents-patch-tuesday)
34
+
35
+## Success criteria
36
+
37
+- [ ] Patch Tuesday data loads
38
+- [ ] You can open a cycle and view prioritized items
39
+- [ ] You can search for a CVE and get results
40
+
41
+## Safety / guardrails
42
+
43
+- Patch Tuesday prioritization is guidance. Always validate against your environment and asset exposure.
44
+
45
+## Troubleshooting
46
+
47
+- If data won’t load:
48
+ - verify outbound connectivity (if required)
49
+ - check connector/service health (if applicable)
50
+ - retry with a different cycle (if UI supports it)
docs/power-features/report-creation.mdx
new
+51
@@ -0,0 +1,51 @@
1
+---
2
+title: Report creation
3
+description: Generate and export reports (often Grafana dashboards) for customers.
4
+---
5
+
6
+# Report creation
7
+
8
+## What it is
9
+
10
+CoPilot supports report creation, commonly via Grafana dashboards and PDF generation.
11
+
12
+## Who this is for
13
+
14
+- **Admin / Platform**: scheduled or ad-hoc reporting for customers
15
+- **Operator**: case-related evidence packets and summaries (depending on workflow)
16
+
17
+## Inputs (what it needs)
18
+
19
+- Grafana connector configured (for dashboard-backed reports)
20
+- Customer provisioning completed (dashboards/org exist)
21
+
22
+## Outputs (what you get)
23
+
24
+- Report outputs (PDF/exports, depending on configuration)
25
+- Shareable artifacts for customers and internal documentation
26
+
27
+## Where it lives in the UI
28
+
29
+- (Wireframe) This page will be updated with the exact menu path/route.
30
+
31
+## Success criteria
32
+
33
+- [ ] You can generate a report for a customer
34
+- [ ] Output can be downloaded/shared
35
+
36
+## Safety / guardrails
37
+
38
+- Reports can contain sensitive event data. Apply RBAC and retention rules.
39
+
40
+## Troubleshooting
41
+
42
+- Confirm Grafana connectivity
43
+- Confirm dashboards exist for the customer
44
+- Confirm report storage/output paths and permissions
45
+
46
+## Related UI reference pages
47
+
48
+- [Report creation](/user/ui/report-creation)
49
+- [General reports](/user/ui/report-general)
50
+- [SCA reports](/user/ui/report-sca)
51
+- [Vulnerability reports](/user/ui/report-vulnerability)
docs/power-features/web-vulnerability-assessment.mdx
new
+124
@@ -0,0 +1,124 @@
1
+---
2
+title: Web vulnerability assessment (Nuclei)
3
+description: Run Nuclei-based web vulnerability scans inside CoPilot and review findings with request/response detail.
4
+---
5
+
6
+# Web vulnerability assessment (Nuclei)
7
+
8
+CoPilot includes a web vulnerability scanning module powered by **Nuclei**.
9
+
10
+It’s designed to give operators/admins a fast way to validate web exposure and identify common web/app misconfigurations across owned/authorized targets.
11
+
12
+---
13
+
14
+## Why this is a power feature
15
+
16
+Web scanning is not required for initial SIEM bring-up, but it’s a high-leverage add-on for reducing attack surface.
17
+
18
+Use it for:
19
+- periodic external exposure reviews (what are we accidentally exposing?)
20
+- validating suspected vulnerabilities during an incident
21
+- confirming whether a customer-facing app has known weak configurations (TLS, headers, exposed endpoints)
22
+
23
+---
24
+
25
+## How it works in CoPilot (high level)
26
+
27
+1) You enable the CoPilot Nuclei module
28
+2) You submit a target host/domain (and any supported scan options)
29
+3) CoPilot runs Nuclei in the background
30
+4) Results are stored and displayed as a report
31
+5) You can drill into each finding for evidence and reproduction detail
32
+
33
+---
34
+
35
+## Setup checklist
36
+
37
+### 1) Enable the Nuclei module (Docker)
38
+
39
+In the video walkthrough, Nuclei is enabled by adding the **CoPilot Nuclei module container** to your CoPilot `docker-compose.yml`, then running a compose up.
40
+
41
+Success check:
42
+- the Nuclei module container is running
43
+- the **Web vulnerability assessment** entry becomes available in the UI
44
+
45
+### 2) Confirm scanner reachability
46
+
47
+The scanner runtime must be able to reach your targets.
48
+
49
+Confirm:
50
+- DNS resolution works from the scanner runtime
51
+- egress is allowed to the target(s)
52
+- you’re scoping to assets you own/have permission to scan
53
+
54
+---
55
+
56
+## Running a scan
57
+
58
+Typical workflow (from the video):
59
+
60
+1) Open **Web vulnerability assessment**
61
+2) Select **Create new report** (if applicable)
62
+3) Enter a target host/domain
63
+ - you usually don’t need to include `http://` or `https://` if the UI accepts a host
64
+4) Submit
65
+5) Wait for completion, then **refresh** the page
66
+
67
+---
68
+
69
+## Understanding results
70
+
71
+Once results are available, you can typically:
72
+- see a list of findings (grouped by type)
73
+- open a finding to review details
74
+
75
+Per-finding detail often includes:
76
+- description of what was detected
77
+- affected URL
78
+- the HTTP request/response evidence
79
+- the **curl command** Nuclei used (useful for reproduction and follow-up testing)
80
+
81
+This makes it easy to:
82
+- validate the finding
83
+- hand evidence to an app owner
84
+- reproduce safely in a test environment
85
+
86
+---
87
+
88
+## Practical operator usage
89
+
90
+A good operator loop:
91
+
92
+1) Run a scan against a specific application
93
+2) Identify quick wins (weak TLS/ciphers, exposed Swagger/OpenAPI, debug endpoints)
94
+3) Create remediation tasks and validate closure by rescanning
95
+
96
+---
97
+
98
+## Safety / guardrails
99
+
100
+- Only scan assets you **own** or have **explicit permission** to test.
101
+- Scanning can trigger WAF blocks, rate limits, or availability impact.
102
+ - start with a single target
103
+ - schedule scans during a quiet window
104
+ - avoid aggressive configurations by default
105
+
106
+---
107
+
108
+## Troubleshooting
109
+
110
+- No results / scan never completes:
111
+ - confirm the Nuclei module container is running
112
+ - confirm the scanner can reach the target host
113
+ - check CoPilot/Nuclei module logs
114
+
115
+- False positives:
116
+ - use the request/response + curl output to validate
117
+ - tune templates/scan scope as needed
118
+
119
+---
120
+
121
+## Video context
122
+
123
+Enablement + walkthrough:
124
+- https://www.youtube.com/watch?v=-SVHKuQUxlI
docs/reference.mdx
new
+22
@@ -0,0 +1,22 @@
1
+---
2
+title: Reference
3
+description: Deep links, mental models, and troubleshooting for CoPilot.
4
+---
5
+
6
+# Reference
7
+
8
+Use this section when you need:
9
+
10
+- menu-mirroring UI reference
11
+- deep links / navigation tips
12
+- a symptom-based troubleshooting index
13
+
14
+If you’re onboarding, start here instead: [Start here](/getting-started/start-here).
15
+
16
+---
17
+
18
+## Key reference pages
19
+
20
+- [UI navigation guide](/user/navigation)
21
+- [UI reference overview](/user/ui/overview)
22
+- [Troubleshooting index](/reference/troubleshooting)
docs/reference/index.mdx
new
+22
@@ -0,0 +1,22 @@
1
+---
2
+title: Reference
3
+description: Deep links, mental models, and troubleshooting for CoPilot.
4
+---
5
+
6
+# Reference
7
+
8
+Use this section when you need:
9
+
10
+- menu-mirroring UI reference
11
+- deep links / navigation tips
12
+- a symptom-based troubleshooting index
13
+
14
+If you’re onboarding, start here instead: [Start here](/getting-started/start-here).
15
+
16
+---
17
+
18
+## Key reference pages
19
+
20
+- [UI navigation guide](/user/navigation)
21
+- [UI reference overview](/user/ui/overview)
22
+- [Troubleshooting index](/reference/troubleshooting)
docs/reference/troubleshooting.mdx
new
+117
@@ -0,0 +1,117 @@
1
+---
2
+title: Troubleshooting index
3
+description: Symptom → likely causes → what to check (CoPilot + SIEM stack).
4
+---
5
+
6
+# Troubleshooting index
7
+
8
+This page is a **symptom-based index**. Find what you’re seeing, then follow the checks.
9
+
10
+> Wireframe note: this is intentionally high-level. As we fill docs, each item will link to deeper pages with exact UI clicks and screenshots.
11
+
12
+---
13
+
14
+## Ingestion
15
+
16
+### No endpoint logs (Wazuh)
17
+
18
+Likely causes:
19
+- Wazuh connector not verified
20
+- agent not enrolled / offline
21
+- indexing/storage issue
22
+- tenant/customer association missing
23
+
24
+What to check:
25
+- CoPilot: Connectors → Wazuh status
26
+- CoPilot: Agents shows host online
27
+- Wazuh: agent status + manager logs
28
+- Indexer/OpenSearch: index health
29
+
30
+### No syslog / network logs
31
+
32
+Likely causes:
33
+- device not sending syslog
34
+- collector not listening / firewall/ACL
35
+- parsing pipeline not extracting fields
36
+- routing/tenant association missing
37
+
38
+What to check:
39
+- device syslog destination IP/port
40
+- collector receive logs
41
+- Graylog input/stream/pipeline
42
+
43
+### No third-party integration events (O365/Mimecast/etc.)
44
+
45
+Likely causes:
46
+- API credentials/scopes wrong
47
+- export/collector not running
48
+- routing/tenant association missing
49
+
50
+What to check:
51
+- CoPilot: External Services / Integration status
52
+- credential permissions
53
+- ingestion job logs (if applicable)
54
+
55
+---
56
+
57
+## Visualization
58
+
59
+### Grafana dashboards are empty
60
+
61
+Likely causes:
62
+- Grafana connector not verified
63
+- provisioning not completed
64
+- index pattern/data source misconfigured
65
+- data is not flowing yet
66
+
67
+What to check:
68
+- CoPilot: connector status
69
+- customer provisioning status
70
+- Grafana: data source points at correct indices
71
+
72
+---
73
+
74
+## Alerting
75
+
76
+### Graylog alerts not showing in CoPilot
77
+
78
+Likely causes:
79
+- Graylog connector not verified
80
+- event definitions not firing
81
+- `gl-events*` not being written
82
+- CoPilot not querying the correct index/pattern
83
+
84
+What to check:
85
+- CoPilot: Graylog connector status
86
+- Graylog: event definitions + streams
87
+- Indexer: `gl-events*` exists and has recent docs
88
+
89
+---
90
+
91
+## Incident workflow
92
+
93
+### Can’t create cases / case workflow feels broken
94
+
95
+Likely causes:
96
+- permissions/RBAC
97
+- missing required configuration
98
+
99
+What to check:
100
+- user permissions/roles
101
+- customer/tenant context
102
+
103
+---
104
+
105
+## Response
106
+
107
+### Velociraptor actions not working
108
+
109
+Likely causes:
110
+- Velociraptor connector not verified
111
+- agent not enrolled in Velociraptor org
112
+- permissions missing
113
+
114
+What to check:
115
+- CoPilot: Velociraptor connector status
116
+- Velociraptor: client visibility
117
+- CoPilot: agent metadata has velociraptor identifiers
docs/user/capsules/c2-alert-to-containment.mdx
new
+31
@@ -0,0 +1,31 @@
1
+---
2
+title: "Step-by-Step IR: From C2 Alert to Full Containment"
3
+description: Containment-first playbook for C2 beaconing alerts.
4
+---
5
+
6
+# Step-by-Step IR: From C2 Alert to Full Containment
7
+
8
+**Video:** https://www.youtube.com/watch?v=PUQ3H913xGs
9
+
10
+## Goal
11
+Contain the host quickly, preserve evidence, then work the investigation to full containment.
12
+
13
+## When to use
14
+- Alerts indicating command-and-control (C2) / beaconing
15
+
16
+## Prereqs
17
+- Alert routing into CoPilot is working
18
+- Ability to isolate/quarantine endpoints (if enabled)
19
+
20
+## Procedure (high level)
21
+1) Confirm scope (customer, host, user)
22
+2) Contain first (isolate/quarantine where appropriate)
23
+3) Pivot into surrounding events + endpoint evidence
24
+4) Create/attach a case and document actions
25
+
26
+## Validation
27
+- Host is contained
28
+- Evidence captured and case notes updated
29
+
30
+## Safety notes
31
+- Prefer containment that preserves volatile evidence when possible.
docs/user/capsules/endpoint-response-actions-copilot.mdx
new
+28
@@ -0,0 +1,28 @@
1
+---
2
+title: "Endpoint Response Actions with CoPilot"
3
+description: Execute repeatable endpoint response actions and confirm results.
4
+---
5
+
6
+# Endpoint Response Actions with CoPilot
7
+
8
+**Video:** https://www.youtube.com/watch?v=SJjR-2ATRug
9
+
10
+## Goal
11
+Run endpoint response actions (collection/containment) from CoPilot and verify outcomes.
12
+
13
+## When to use
14
+- During active incident response
15
+- For repeatable evidence collection workflows
16
+
17
+## Prereqs
18
+- Response/action capability is configured and tested
19
+
20
+## Procedure (high level)
21
+1) Select the action
22
+2) Target the correct endpoint
23
+3) Execute and monitor completion
24
+4) Review results and document in a case
25
+
26
+## Validation
27
+- Action completed successfully
28
+- Evidence/results captured and accessible
docs/user/capsules/index.mdx
new
+61
@@ -0,0 +1,61 @@
1
+---
2
+title: SOCFortress Capsules
3
+description: Operator playbooks that walk you from alert → investigation → response using CoPilot.
4
+---
5
+
6
+# SOCFortress Capsules
7
+
8
+Capsules are short, task-focused operator playbooks based on SOCFortress video walkthroughs.
9
+
10
+Use them when you want a **step-by-step path** from an alert to investigation and response inside CoPilot.
11
+
12
+---
13
+
14
+## Quick start: pick a goal
15
+
16
+- **Contain a host from a C2 alert** → [C2 alert to containment](/user/capsules/c2-alert-to-containment)
17
+- **Investigate suspicious persistence** → [Suspicious scheduled tasks](/user/capsules/suspicious-scheduled-tasks)
18
+- **Remove unauthorized privilege** → [Rogue local admin accounts](/user/capsules/rogue-local-admin-accounts)
19
+- **Validate a detection** → [Atomic Red Team validation](/user/capsules/validate-detections-atomic-red-team)
20
+- **Run response actions** → [Endpoint response actions](/user/capsules/endpoint-response-actions-copilot)
21
+- **Memory forensics / malware hunting** → [Volatility 3 malware hunting](/user/capsules/volatility-3-malware-hunting)
22
+
23
+---
24
+
25
+## Capsules by category
26
+
27
+<details>
28
+ <summary><strong>Incident Response Playbooks</strong></summary>
29
+
30
+- [Step-by-Step IR: From C2 Alert to Full Containment](/user/capsules/c2-alert-to-containment)
31
+- [SOC Playbook: Detecting and Removing Suspicious Scheduled Tasks](/user/capsules/suspicious-scheduled-tasks)
32
+- [Detecting & Removing Rogue Local Admin Accounts](/user/capsules/rogue-local-admin-accounts)
33
+
34
+</details>
35
+
36
+<details>
37
+ <summary><strong>CoPilot How-Tos</strong></summary>
38
+
39
+- [Endpoint Response Actions with CoPilot](/user/capsules/endpoint-response-actions-copilot)
40
+- [Validate Detections with Atomic Red Team (CoPilot)](/user/capsules/validate-detections-atomic-red-team)
41
+
42
+</details>
43
+
44
+<details>
45
+ <summary><strong>Forensics</strong></summary>
46
+
47
+- [Volatility 3 Malware Hunting (Full Tutorial)](/user/capsules/volatility-3-malware-hunting)
48
+
49
+</details>
50
+
51
+---
52
+
53
+## What each capsule includes
54
+
55
+- What you’re trying to accomplish
56
+- When to use it (what kind of alert/context)
57
+- Prerequisites (data sources + access)
58
+- Step-by-step procedure
59
+- Validation (“what good looks like”)
60
+- Safety notes (containment vs evidence preservation)
61
+- Video link
docs/user/capsules/rogue-local-admin-accounts.mdx
new
+27
@@ -0,0 +1,27 @@
1
+---
2
+title: "Detecting & Removing Rogue Local Admin Accounts"
3
+description: Validate and remediate unauthorized local admin changes.
4
+---
5
+
6
+# Detecting & Removing Rogue Local Admin Accounts
7
+
8
+**Video:** https://www.youtube.com/watch?v=ogJMUFMOXLY
9
+
10
+## Goal
11
+Validate a local admin change is unauthorized and remove rogue admin access.
12
+
13
+## When to use
14
+- Alerts indicating local account creation or group membership changes
15
+
16
+## Prereqs
17
+- Endpoint telemetry + identity context
18
+
19
+## Procedure (high level)
20
+1) Validate who/what created the account or modified the group
21
+2) Confirm whether change is approved
22
+3) Remove unauthorized accounts / admin group entries
23
+4) Capture evidence and update the case
24
+
25
+## Validation
26
+- Rogue admin access removed
27
+- No recurrence after monitoring window
docs/user/capsules/suspicious-scheduled-tasks.mdx
new
+27
@@ -0,0 +1,27 @@
1
+---
2
+title: "SOC Playbook: Detecting and Removing Suspicious Scheduled Tasks"
3
+description: Investigate scheduled task persistence alerts and remove malicious tasks.
4
+---
5
+
6
+# SOC Playbook: Detecting and Removing Suspicious Scheduled Tasks
7
+
8
+**Video:** https://www.youtube.com/watch?v=5xHxhSBROEc
9
+
10
+## Goal
11
+Identify suspicious scheduled tasks used for persistence and remove them safely.
12
+
13
+## When to use
14
+- Alerts indicating scheduled task creation/modification
15
+
16
+## Prereqs
17
+- Endpoint telemetry (Windows) + investigation pivots
18
+
19
+## Procedure (high level)
20
+1) Triage the alert and identify the host/user/process context
21
+2) Enumerate scheduled tasks on the endpoint
22
+3) Identify suspicious task(s) and associated binaries/commands
23
+4) Contain/remediate and document
24
+
25
+## Validation
26
+- Suspicious task removed/disabled
27
+- Follow-on telemetry confirms no re-creation
docs/user/capsules/validate-detections-atomic-red-team.mdx
new
+31
@@ -0,0 +1,31 @@
1
+---
2
+title: "Validate Detections with Atomic Red Team (CoPilot)"
3
+description: Run controlled simulations to confirm detection rules fire as expected.
4
+---
5
+
6
+# Validate Detections with Atomic Red Team (CoPilot)
7
+
8
+**Video:** https://www.youtube.com/watch?v=HXnT-wnpxuQ
9
+
10
+## Goal
11
+Simulate attacker behaviors and verify detections + routing end-to-end.
12
+
13
+## When to use
14
+- After deploying/tuning detection rules
15
+- After telemetry changes (Sysmon, agent configs)
16
+
17
+## Prereqs
18
+- Atomic Red Team available on a test endpoint
19
+- Velociraptor artifacts to execute tests remotely
20
+
21
+Related:
22
+- [Atomic Red Team (detection simulation)](/power-features/atomic-red-team)
23
+
24
+## Procedure (high level)
25
+1) Pick a safe atomic test
26
+2) Execute it via CoPilot/Velociraptor
27
+3) Confirm the expected alert fires
28
+4) Tune rules/telemetry if needed
29
+
30
+## Validation
31
+- Alert fires and is visible in the expected UI surface(s)
docs/user/capsules/volatility-3-malware-hunting.mdx
new
+28
@@ -0,0 +1,28 @@
1
+---
2
+title: "Volatility 3 Malware Hunting (Full Tutorial)"
3
+description: Memory-forensics workflow for malware hunting using Volatility 3.
4
+---
5
+
6
+# Volatility 3 Malware Hunting (Full Tutorial)
7
+
8
+**Video:** https://www.youtube.com/watch?v=R1X8V9yy_Y4
9
+
10
+## Goal
11
+Use Volatility 3 to hunt malware and suspicious activity in memory dumps.
12
+
13
+## When to use
14
+- When you have a memory capture from a suspicious host
15
+- When you need deeper insight than disk/EDR telemetry provides
16
+
17
+## Prereqs
18
+- Memory dump acquired and stored securely
19
+- Volatility 3 available in your analysis environment
20
+
21
+## Procedure (high level)
22
+1) Identify profile/context and validate the dump
23
+2) Enumerate processes and suspicious artifacts
24
+3) Pivot into network, modules, command lines, and persistence indicators
25
+4) Document findings and feed back into detections
26
+
27
+## Validation
28
+- Findings are reproducible and mapped to concrete evidence
docs/user/customer-provisioning.md
+31
@@ -12,6 +12,7 @@ Provisioning is designed to create the *plumbing* that makes customer data land
12
muted
13
playsInline
14
preload="auto"
15
+ poster="/assets/hero/customer-provisioning-walkthrough-thumb.jpg"
16
style={{
17
width: '100%',
18
borderRadius: 16,
@@ -40,6 +41,36 @@ This same customer context is also where you configure:
41
42
These are set up **per customer** so that ingestion, routing, and alerting stay tenant-aware.
43
44
+### Also: Shuffle (SOAR) for tickets + notifications
45
+
46
+CoPilot can plug into **Shuffle** (SOAR) so SIEM stack alerts can be forwarded to third‑party tools such as:
47
+
48
+- Jira
49
+- email notifications
50
+- ConnectWise
51
+- other ticketing systems / custom webhooks
52
+
53
+This allows you to take an alert created by the stack and automatically:
54
+- create a ticket
55
+- enrich it with alert context
56
+- route it to the right destination per customer
57
+
58
+#### Per-customer workflows (recommended)
59
+
60
+In many environments, different customers want different routing (different Jira projects, different email recipients, different ticketing systems).
61
+
62
+CoPilot + Shuffle supports this pattern by letting you map alerts to **different Shuffle workflow IDs per customer**.
63
+
64
+Practical example:
65
+- Customer A → Jira Project `SOC`
66
+- Customer B → ConnectWise tickets
67
+- Customer C → email-only notifications
68
+
69
+> Tip: The alert context sent to Shuffle is driven by what you map in **Incident Sources** (title/asset/context fields).
70
+
71
+Video context:
72
+- https://www.youtube.com/watch?v=Ko5jLfkSCrk
73
+
74
### 1) Dedicated customer index + routing (Graylog → Wazuh Indexer)
75
76
- A **customer-specific index** (for example: `wazuh-<customer_code>`) with your chosen:
docs/user/ui/agents-copilot-actions.md
+176
-3
@@ -1,9 +1,182 @@
1
-# CoPilot Actions
1
+---
2
+title: CoPilot actions
3
+description: Run repeatable response actions across endpoints using CoPilot + Velociraptor, and visualize results in Grafana.
4
+---
5
+
6
+# CoPilot actions
7
8
**Menu:** Agents → CoPilot Actions
9
5
-**Best for:** Admin/Engineer + Response engineering
10
+CoPilot Actions provides a more flexible way to launch endpoint actions (response + collection) across your infrastructure.
11
7
-Configure or manage endpoint actions / response capabilities.
12
+At a high level it combines:
13
+- **CoPilot** (operator UI)
14
+- **Velociraptor** (executes artifacts to run the action)
15
+- **Custom scripts** (the action logic)
16
+- **Grafana** (dashboards to visualize action results)
17
18
19
+
20
+Repo (required for setup assets + implementation details):
21
+- https://github.com/socfortress/CoPilot-Action
22
+
23
+---
24
+
25
+## Why this exists (vs “traditional Wazuh Active Response”)
26
+
27
+Wazuh Active Response is powerful, but at scale it can become cumbersome to:
28
+- deploy scripts to endpoints
29
+- keep action logic consistent across OSes
30
+- manage parameters and rollouts cleanly
31
+
32
+CoPilot Actions is designed to make automated responses **simpler to run and easier to operationalize**.
33
+
34
+---
35
+
36
+## How it works
37
+
38
+Conceptually:
39
+
40
+1) You choose an action in CoPilot
41
+2) CoPilot invokes a **Velociraptor artifact** (Windows or Linux)
42
+3) The artifact downloads/executes the **action script** for the selected action
43
+4) Results are written to logs and ingested into the stack
44
+5) Grafana dashboards let you explore outcomes over time
45
+
46
+CoPilot’s own UI also shows:
47
+- supported OS/technology
48
+- action metadata + description
49
+- a link to the underlying source code repo for the action
50
+
51
+
52
+
53
+---
54
+
55
+## Prerequisites
56
+
57
+- CoPilot is deployed and you can access **Agents → CoPilot Actions**.
58
+- Velociraptor server + clients are deployed (the CoPilot-Action repo recommends Velociraptor **0.74.1+**).
59
+- CoPilot can authenticate to Velociraptor (Connector configured).
60
+
61
+---
62
+
63
+## Setup checklist (recommended)
64
+
65
+This is the practical “get it working end-to-end” checklist.
66
+
67
+### 1) Import the required Velociraptor artifacts
68
+
69
+From the repo:
70
+- `velociraptor/Linux.Execute.RemoteBashScript.yaml`
71
+- `velociraptor/Windows.Execute.RemotePowerShellScript.yaml`
72
+
73
+Import them into Velociraptor (UI):
74
+- **View Artifacts → Upload Artifacts**
75
+
76
+Why: these artifacts are the execution layer that downloads and runs action scripts consistently.
77
+
78
+### 2) Confirm the CoPilot ↔ Velociraptor connector
79
+
80
+In CoPilot, configure and test the Velociraptor connector:
81
+- **Connectors → Velociraptor**
82
+
83
+Why: CoPilot needs API access to launch the artifact executions.
84
+
85
+### 3) Ensure endpoints can download action scripts
86
+
87
+CoPilot Actions commonly downloads scripts from public GitHub repos.
88
+
89
+Verify:
90
+- endpoints have egress to `raw.githubusercontent.com` (or wherever your scripts live)
91
+- DNS + TLS inspection/proxy rules won’t block downloads
92
+
93
+### 4) (Windows) Verify PowerShell can run scripts
94
+
95
+If a Windows action relies on PowerShell, validate the execution policy and permissions on target endpoints.
96
+
97
+(Example from the repo docs: `RemoteSigned` at `LocalMachine` scope.)
98
+
99
+### 5) Create SIEM routing for action output (Graylog)
100
+
101
+Recommended pattern:
102
+- Create a dedicated **Graylog index set** (e.g., `copilot_action`)
103
+- Create a **Graylog stream** that routes CoPilot Action output to that index
104
+
105
+Why: action output is operational/response telemetry—keep it searchable without polluting core security logs.
106
+
107
+### 6) Add/verify Wazuh rule support for action output
108
+
109
+Action output is typically written to active response logs that the Wazuh agent already ships.
110
+
111
+Add/verify the supporting detection rules so the Wazuh manager can identify/classify “CoPilot Action” results.
112
+
113
+### 7) Import Grafana dashboards (optional but recommended)
114
+
115
+The CoPilot-Action repo includes dashboards under:
116
+- `Grafana/`
117
+
118
+Import them into Grafana and point the datasource at the CoPilot Action index.
119
+
120
+Why: dashboards make it much easier to confirm actions are firing and to review results across time.
121
+
122
+---
123
+
124
+## Repo pointers
125
+
126
+Everything you need to stand this up (artifacts + dashboards + docs) lives in:
127
+- https://github.com/socfortress/CoPilot-Action
128
+
129
+---
130
+
131
+## Common tasks
132
+
133
+### Find an action
134
+
135
+Use search to filter actions by name/technology.
136
+
137
+### Invoke an action
138
+
139
+
140
+
141
+Typical flow:
142
+1) Select an action
143
+2) Review metadata (OS support, parameters)
144
+3) Select a target agent
145
+4) Invoke
146
+
147
+Examples shown in the video:
148
+- collecting browser history
149
+- blocking an IP address via Windows Firewall
150
+
151
+### View results
152
+
153
+Results can be viewed:
154
+- in Grafana dashboards (recommended for trending/overview)
155
+- in Velociraptor execution logs/results (best for deep troubleshooting)
156
+
157
+
158
+
159
+---
160
+
161
+## Troubleshooting (fast checks)
162
+
163
+If an action fails:
164
+- Confirm the required Velociraptor artifacts exist and are runnable
165
+- Check the Velociraptor artifact execution **logs/results** for errors
166
+- Verify Graylog stream/index routing if you expect results in dashboards
167
+- Confirm endpoint prerequisites (PowerShell availability, script paths, permissions)
168
+
169
+---
170
+
171
+## Gotchas
172
+
173
+- Actions can be disruptive (containment/firewall changes). Use approvals + logging.
174
+- Start by testing actions on a lab endpoint and then roll out.
175
+- Ensure your routing keeps action output separated from core security telemetry.
176
+
177
+---
178
+
179
+## Video context
180
+
181
+Feature walkthrough + setup approach:
182
+- https://www.youtube.com/watch?v=l9OLtgemYOQ
docs/user/ui/agents-detection-rules.md
+92
-3
@@ -1,9 +1,98 @@
1
-# Detection Rules
1
+---
2
+title: Detection rules (Wazuh)
3
+description: View and manage Wazuh detection rules in CoPilot to tune signal vs noise.
4
+---
5
+
6
+# Detection rules (Wazuh)
7
8
**Menu:** Agents → Detection Rules
9
5
-**Best for:** Detection engineering
10
+Detection rules in CoPilot map to **Wazuh detection rules**. These rules are what Wazuh uses to generate alerts from decoded telemetry.
11
7
-Edit and manage detection rules (Wazuh) through CoPilot.
12
+CoPilot lets you **view, search, and manage** these rules without SSH’ing into the Wazuh manager.
13
14
15
+
16
+---
17
+
18
+## What you’re looking at
19
+
20
+
21
+
22
+This page exposes the rule files that live on the **Wazuh manager** (e.g., the standard `*_rules.xml` files and your local exclusions/custom rules).
23
+
24
+Key point:
25
+- **Rules still live on the Wazuh manager.** CoPilot pulls them via API and can upload/save changes back to the manager.
26
+
27
+---
28
+
29
+## Why this matters
30
+
31
+Rules are one of your main control points for:
32
+- reducing noisy alerts (exclusions)
33
+- adding new detection logic for emerging threats
34
+- aligning alerting to what you actually care about in a given customer environment
35
+
36
+---
37
+
38
+## Common tasks
39
+
40
+### Search for rules
41
+
42
+
43
+
44
+Use search when you need to:
45
+- find a rule by **ID**
46
+- locate a specific field match / keyword
47
+- quickly identify which file contains the logic you need to adjust
48
+
49
+### Add an exclusion (reduce noise)
50
+
51
+A typical workflow (from the video):
52
+1) Open your exclusions/custom rule file
53
+2) Add or modify a rule (incrementing the rule ID when needed)
54
+3) Update the match conditions/fields
55
+4) Save/upload the file
56
+
57
+
58
+
59
+### Upload/save changes to the Wazuh manager
60
+
61
+After editing, you must upload/save so the updated file is written to the manager.
62
+
63
+Important:
64
+- Saving changes updates the file on the **Wazuh manager**.
65
+
66
+### Restart Wazuh to apply rule changes
67
+
68
+Rule changes typically require a Wazuh manager restart/reload to take effect.
69
+
70
+
71
+
72
+Operational note:
73
+- Treat restarts as a controlled change (maintenance window, customer comms if needed).
74
+
75
+---
76
+
77
+## When to use it
78
+
79
+Use Detection Rules when you need to:
80
+- reduce false positives / noisy detections
81
+- validate why an alert did or did not fire
82
+- tune alert fidelity for a specific customer
83
+- add detection logic for a new threat/use case
84
+
85
+---
86
+
87
+## Gotchas
88
+
89
+- Rule changes can impact alert volume immediately—roll out carefully and document changes.
90
+- Keep ownership/change control clear (avoid ad-hoc production edits).
91
+- Any restart/reload step should be treated as operationally significant.
92
+
93
+---
94
+
95
+## Video context
96
+
97
+This page and workflow are demonstrated here:
98
+- https://www.youtube.com/watch?v=31lCr80-NVM
docs/user/ui/agents-groups.md
+101
-4
@@ -1,9 +1,106 @@
1
-# Agent Groups
1
+---
2
+title: Agent groups (Wazuh)
3
+description: Multi-tenant Wazuh agent groups used to apply endpoint configuration, control telemetry, and reduce SIEM noise.
4
+---
5
3
-**Menu:** Agents → Groups
6
+# Agent groups (Wazuh)
7
5
-**Best for:** Admin/Engineer
8
+**Menu:** Agents → Groups
9
7
-Use groups to segment endpoints and attach customer labels used for routing.
10
+Agent groups in CoPilot map to **Wazuh agent groups**. Wazuh uses these groups to apply endpoint configuration such as:
11
+- log collection settings
12
+- Security Configuration Assessment (SCA) policy configuration
13
+- File Integrity Monitoring (FIM) configuration
14
15
16
+
17
+---
18
+
19
+## What you’re looking at
20
+
21
+
22
+
23
+This page shows:
24
+- the list of Wazuh groups
25
+- how many agents are in each group
26
+- group details/config once selected
27
+
28
+Multi-tenancy note:
29
+- Groups are typically created **per customer**.
30
+- We usually also split by **operating system** (Windows / Linux / macOS).
31
+
32
+Common naming pattern:
33
+- `Windows_<customer_code>`
34
+- `Linux_<customer_code>`
35
+- `Mac_<customer_code>`
36
+
37
+Example groups visible in the lab:
38
+- `Windows_lab`, `Linux_lab`, `Mac_lab`
39
+
40
+---
41
+
42
+## Why groups matter
43
+
44
+Groups are one of the highest leverage controls in the stack:
45
+
46
+- They define what telemetry is collected and shipped to the Wazuh Manager.
47
+- They standardize configuration across fleets (repeatable, auditable).
48
+- They help prevent SIEM bloat by letting you suppress noise **at the agent**, before it ever hits the manager/indexer.
49
+
50
+---
51
+
52
+## Common tasks
53
+
54
+### Add an agent to a group
55
+
56
+Typical workflow:
57
+1) Identify the agent
58
+2) Assign it to the correct customer + OS group
59
+3) Verify the agent receives updated configuration
60
+
61
+### Validate a group is applied
62
+
63
+In Wazuh terms, group configuration ends up under the manager’s shared group config and is pushed down to agents.
64
+
65
+---
66
+
67
+## Advanced: group configuration fields (why they’re powerful)
68
+
69
+
70
+
71
+Group configuration is where you can:
72
+- tune Windows EventChannel collection
73
+- apply QueryList include/exclude logic
74
+- configure SCA policy behavior
75
+- adjust FIM rules
76
+
77
+### Using groups to reduce SIEM noise (from the video)
78
+
79
+Windows Security events can be extremely noisy. If you filter noise only on the **Wazuh Manager**, the manager still has to:
80
+- receive the event
81
+- parse/decode it
82
+- evaluate it against rules
83
+
84
+A better performance move is to suppress events at the **Wazuh agent**, so they are **never shipped** to the manager in the first place.
85
+
86
+Approach (high level):
87
+1) Start with broad collection (so you know what you’re getting)
88
+2) Identify noisy event IDs / patterns
89
+3) Add suppressions in the group’s agent configuration (QueryList / suppression rules)
90
+4) Validate the agent received the updated config and the noise stopped upstream
91
+
92
+This improves:
93
+- Wazuh Manager performance
94
+- indexer storage consumption
95
+- Graylog pipeline load
96
+- downstream alerting signal-to-noise
97
+
98
+Video context:
99
+- https://www.youtube.com/watch?v=_vfd9eslwN0
100
+
101
+---
102
+
103
+## Gotchas
104
+
105
+- Group config syntax can be sensitive (especially Windows event query filters). Make small changes and validate.
106
+- Don’t suppress blindly—ensure you’re not hiding high-signal events you need for detection.
docs/user/ui/agents-patch-tuesday.md
+113
-4
@@ -1,9 +1,118 @@
1
-# Patch Tuesday
1
+---
2
+title: Patch Tuesday (Microsoft)
3
+description: Patch-cycle view that prioritizes Microsoft CVEs by urgency (P0–P3), KEV, CVSS, and EPSS.
4
+---
5
3
-**Menu:** Agents → Patch Tuesday
6
+# Patch Tuesday (Microsoft)
7
5
-**Best for:** Ops + reporting
8
+**Menu:** Agents → Patch Tuesday
9
7
-Patch-focused reporting/overview.
10
+Patch Tuesday is a patch-cycle view focused on **Microsoft Patch Tuesday** releases. It helps you triage CVEs for a given patch cycle and prioritize what to patch first using:
11
+- priority bands (**P0–P3**)
12
+- **KEV** (Known Exploited Vulnerabilities)
13
+- **CVSS** severity
14
+- **EPSS** (exploit likelihood)
15
+- affected product family / product
16
17
18
+
19
+---
20
+
21
+## What you’re looking at
22
+
23
+### Cycle summary
24
+
25
+
26
+
27
+At the top, you’ll see:
28
+- count of **unique CVEs**
29
+- counts by priority (P0 Emergency, P1 High, P2 Medium, P3 Low)
30
+- the patch cycle date and generation timestamp
31
+
32
+Use this for:
33
+- a fast “how big is this month?” snapshot
34
+- tracking backlog reduction over the patch window
35
+
36
+### Filters
37
+
38
+
39
+
40
+You can filter by:
41
+- **Cycle** (e.g., `2026-Feb`)
42
+- **Priority**
43
+- **Product family**
44
+- **Severity**
45
+- **Search** (CVE, title, product)
46
+
47
+### KEV toggle
48
+
49
+
50
+
51
+Turn on **KEV** to focus on vulnerabilities that are known to be exploited.
52
+
53
+### CVE cards
54
+
55
+
56
+
57
+Each CVE entry typically includes:
58
+- CVE ID + title
59
+- priority (P0–P3)
60
+- KEV indicator (when applicable)
61
+- product family and affected products
62
+- CVSS
63
+- EPSS + percentile
64
+- associated KBs / updates (when available)
65
+
66
+---
67
+
68
+## How to use this page (operator workflow)
69
+
70
+A practical monthly flow:
71
+
72
+1) **Start with KEV + P0**
73
+ - Turn on KEV
74
+ - Filter to P0 (Emergency)
75
+ - Patch these first (or implement compensating controls immediately)
76
+
77
+2) **Use EPSS to prioritize within a priority band**
78
+ - When you have many P1/P2 items, sort mentally by EPSS (higher likelihood first)
79
+
80
+3) **Group work by product family**
81
+ - Cluster Windows Server vs Workstations vs Office/Edge/etc.
82
+
83
+4) **Coordinate by customer / environment**
84
+ - In multi-tenant stacks, drive patch work per tenant and track completion
85
+
86
+5) **Validate outcome**
87
+ - Confirm patch deployment via your patch tooling
88
+ - Re-check vulnerability posture in CoPilot after inventory refresh
89
+
90
+---
91
+
92
+## What P0–P3 means (recommended interpretation)
93
+
94
+Use the priority bands as an urgency rubric:
95
+- **P0 (Emergency):** patch immediately (especially if KEV/high EPSS)
96
+- **P1 (High):** patch in the first wave of the cycle
97
+- **P2 (Medium):** patch in the standard window
98
+- **P3 (Low):** patch as capacity allows
99
+
100
+Always combine this with:
101
+- asset criticality
102
+- exposure (internet-facing vs internal)
103
+- compensating controls (EDR, network controls, app allowlisting)
104
+
105
+---
106
+
107
+## Prerequisites
108
+
109
+- Patch Tuesday feed/data source is enabled and up-to-date
110
+- Vulnerability data ingestion is working (for EPSS/CVSS enrichment where applicable)
111
+
112
+---
113
+
114
+## Gotchas
115
+
116
+- Don’t treat CVSS as a patch order by itself—use KEV + EPSS + exposure + asset criticality.
117
+- Patch Tuesday prioritization is about **urgency**, not just severity.
118
+- Some environments require maintenance windows—use compensating controls when you can’t patch immediately.
docs/user/ui/agents-sca-overview.md
+90
-4
@@ -1,9 +1,95 @@
1
-# SCA Overview
1
+---
2
+title: SCA overview
3
+description: Review Wazuh Security Configuration Assessment (SCA) posture across endpoints.
4
+---
5
3
-**Menu:** Agents → SCA Overview
6
+# SCA overview
7
5
-**Best for:** Ops + reporting
8
+**Menu:** Agents → SCA Overview
9
7
-Security Configuration Assessment overview.
10
+SCA (Security Configuration Assessment) is Wazuh’s secure configuration/hardening framework. It evaluates endpoints against policies (benchmarks) and reports pass/fail results so you can:
11
+- find configuration drift
12
+- measure baseline hardening posture
13
+- prioritize remediation of failed controls
14
15
16
+
17
+---
18
+
19
+## What you’re looking at
20
+
21
+### Filters
22
+
23
+
24
+
25
+You can scope results by:
26
+- **Customer** (multi-tenant)
27
+- **Agent Name**
28
+- **Policy Name**
29
+- **Score range** (min/max)
30
+
31
+### Load SCA Data
32
+
33
+
34
+
35
+This page typically requires an initial fetch.
36
+
37
+Use **Load SCA Data** to pull the latest SCA results into the view.
38
+
39
+### Results view
40
+
41
+
42
+
43
+Once loaded, you’ll use this page to identify:
44
+- which agents are failing baseline policies
45
+- which policies are producing the lowest scores
46
+- where remediation work will produce the biggest posture improvement
47
+
48
+---
49
+
50
+## When to use it
51
+
52
+Use SCA overview when you need to:
53
+- identify endpoints failing hardening baselines
54
+- find drift after a change window (GPO, tooling rollout, new images)
55
+- support audits/compliance reporting with repeatable evidence
56
+
57
+---
58
+
59
+## Common tasks
60
+
61
+### Triage low scores first
62
+
63
+A practical flow:
64
+1) Filter by customer
65
+2) Set a **Max Score** threshold (start low)
66
+3) Identify the bottom-scoring endpoints/policies
67
+4) Remediate the highest leverage failures (the ones that apply broadly)
68
+
69
+### Investigate and remediate failed checks
70
+
71
+Use the agent’s dedicated page to drill down:
72
+- open an agent and review the **SCA** tab for policy/check details
73
+
74
+Remediation usually happens outside CoPilot (GPO, configuration management, image updates), then you validate by re-running SCA and confirming the score improves.
75
+
76
+### Export / reporting
77
+
78
+If you need a deliverable:
79
+- see: [SCA report](/user/ui/report-sca)
80
+
81
+---
82
+
83
+## Prerequisites
84
+
85
+- Wazuh SCA is enabled on agents
86
+- Policies are deployed to the endpoints/groups you care about
87
+- Agents are checking in and SCA scans have run
88
+
89
+---
90
+
91
+## Gotchas
92
+
93
+- SCA is only as good as your policies and rollout. Keep policies consistent per OS/group/customer.
94
+- Score changes often lag behind configuration changes (depends on scan cadence + agent check-in).
95
+- Don’t chase perfect scores blindly—prioritize controls that reduce real risk for your environment.
docs/user/ui/agents-sysmon-config.md
+92
-3
@@ -1,9 +1,98 @@
1
-# Sysmon Config
1
+---
2
+title: Sysmon config (Windows)
3
+description: Centralized Sysmon configuration management for Windows telemetry collected by Wazuh.
4
+---
5
+
6
+# Sysmon config (Windows)
7
8
**Menu:** Agents → Sysmon Config
9
5
-**Best for:** Admin/Engineer
10
+Sysmon (System Monitor) is a Microsoft Sysinternals tool that logs high-value system activity to the **Windows Event Log**. We use it on Windows endpoints to collect richer telemetry (process, network, file, etc.) that improves detections and investigations.
11
7
-Manage Sysmon configuration in a repeatable way.
12
+In the CoPilot stack:
13
+- **Sysmon** generates telemetry on the Windows endpoint
14
+- The **Wazuh agent** collects Sysmon events
15
+- The **Wazuh manager** is the source of truth and forwards that telemetry into the SIEM
16
17
18
+
19
+---
20
+
21
+## Why we use Sysmon
22
+
23
+Windows Security logs are useful, but Sysmon provides additional, security-relevant telemetry that is widely adopted in SOC environments.
24
+
25
+Benefits:
26
+- higher-fidelity investigation data (what ran, how it ran, what it talked to)
27
+- better detection coverage for common attacker techniques
28
+- consistent event schemas when you standardize a baseline configuration
29
+
30
+---
31
+
32
+## What this page is
33
+
34
+A centralized place to manage Sysmon configuration files so you can:
35
+- keep Windows telemetry consistent across endpoints
36
+- tune noise (exclude expected/benign activity)
37
+- roll out changes per customer/group
38
+
39
+
40
+
41
+---
42
+
43
+## How Sysmon config management works in CoPilot (high level)
44
+
45
+Based on the workflow in the video:
46
+
47
+1) You maintain a Sysmon config (XML)
48
+2) CoPilot writes the config into the appropriate Wazuh shared group directory (typically per Windows customer group)
49
+3) Endpoints receive the updated file via Wazuh agent group sync
50
+4) A reload mechanism applies the new Sysmon config without requiring a reboot (implementation depends on your environment)
51
+
52
+---
53
+
54
+## Step 1 — Review and edit the Sysmon config
55
+
56
+
57
+
58
+Operator/engineer tips:
59
+- Make small, intentional changes
60
+- Track versions and keep a rollback path
61
+- Prefer customer/group-specific configs when environments differ (EDR tools, server roles, etc.)
62
+
63
+---
64
+
65
+## Step 2 — Apply / reload the config
66
+
67
+
68
+
69
+A practical pattern is to reload Sysmon after pushing a new config so changes take effect quickly.
70
+
71
+Why this matters:
72
+- you can respond to noise quickly (exclude noisy, expected software)
73
+- you can add coverage quickly when a new detection need appears
74
+
75
+---
76
+
77
+## Using Sysmon to reduce SIEM noise
78
+
79
+Sysmon configs can be very detailed. A common problem is “too much telemetry.”
80
+
81
+Use this page to:
82
+- exclude known-benign software that generates high event volume
83
+- reduce ingestion costs (compute + storage)
84
+- keep detections focused on high-signal telemetry
85
+
86
+Example from the video context:
87
+- if an endpoint is running an EDR tool and Sysmon is generating noisy events around specific event IDs, you can add exclusions so you don’t ingest bloat into the SIEM.
88
+
89
+Video context:
90
+- https://www.youtube.com/watch?v=XT1d49HTqQw
91
+
92
+---
93
+
94
+## Gotchas
95
+
96
+- Sysmon configs can be complex—test changes on a small set of endpoints first.
97
+- Any change can shift event volume dramatically—coordinate with index/retention planning.
98
+- A broken config may fail to apply; keep validation and rollback procedures.
docs/user/ui/agents-vulnerability-overview.md
+104
-4
@@ -1,9 +1,109 @@
1
-# Vulnerability Overview
1
+---
2
+title: Vulnerability overview
3
+description: Review vulnerability posture across agents with EPSS scoring and package detail.
4
+---
5
3
-**Menu:** Agents → Vulnerability Overview
6
+# Vulnerability overview
7
5
-**Best for:** Both (Ops + reporting)
8
+**Menu:** Agents → Vulnerability Overview
9
7
-High-level view of vulnerabilities (often backed by Wazuh vulnerability detection data).
10
+Vulnerability Overview provides near real-time vulnerability data (from **Wazuh Indexer**) enriched with **EPSS** scoring and package details, so you can prioritize remediation based on both severity and likely exploitation.
11
12
13
+
14
+---
15
+
16
+## What you’re looking at
17
+
18
+### Distribution
19
+
20
+
21
+
22
+A quick breakdown of vulnerabilities by severity (Critical / High / Medium / Low).
23
+
24
+Use this for:
25
+- “How bad is it right now?”
26
+- tracking whether patching is reducing overall exposure
27
+
28
+### Coverage + top packages by EPSS
29
+
30
+
31
+
32
+This section highlights:
33
+- how many **agents** are impacted
34
+- how many **unique packages** are involved
35
+- how many **customer codes** are represented
36
+
37
+And surfaces packages/vuln clusters ranked by **EPSS** (a good “what should we care about first?” view).
38
+
39
+### Detailed table
40
+
41
+
42
+
43
+The table is the working view where you can pivot by:
44
+- CVE
45
+- severity
46
+- affected agent/hostname
47
+- package / OS / architecture
48
+- **CVSS**
49
+- **EPSS score** and **EPSS percentile**
50
+- timestamp (when observed)
51
+
52
+---
53
+
54
+## EPSS (Exploit Prediction Scoring System) — how to use it
55
+
56
+EPSS is a probability model maintained by FIRST that estimates the likelihood a CVE will be exploited “in the wild.”
57
+
58
+In CoPilot you’ll typically see:
59
+- **EPSS**: a score between **0 and 1** (higher means more likely exploitation)
60
+- **EPSS Pct**: percentile ranking (how that CVE compares to other CVEs)
61
+
62
+How to operationalize it:
63
+- Use **CVSS** to understand *impact/severity*
64
+- Use **EPSS** to understand *likelihood/urgency*
65
+- Prioritize items that are **High CVSS + High EPSS** first
66
+
67
+Rule of thumb:
68
+- A Medium CVSS with a very high EPSS can be more urgent than a High CVSS with very low EPSS.
69
+
70
+Reference:
71
+- https://www.first.org/epss/
72
+
73
+---
74
+
75
+## Common tasks
76
+
77
+### Filter by tenant/customer
78
+
79
+Use filters to focus on one customer code at a time in multi-tenant environments.
80
+
81
+
82
+
83
+### Identify “top risk” items
84
+
85
+A practical triage flow:
86
+1) Review **Top Packages by EPSS**
87
+2) Open the package/CVE details
88
+3) Identify affected agents
89
+4) Create remediation tasks (patch/update/remove package)
90
+5) Validate closure by confirming the item disappears as inventory updates
91
+
92
+### Pivot to reporting
93
+
94
+If you need a deliverable for a customer or internal patch window:
95
+- use the reporting workflow described here: [Vulnerability report](/user/ui/report-vulnerability)
96
+
97
+---
98
+
99
+## Prerequisites
100
+
101
+- Wazuh inventory (syscollector) is flowing for endpoints
102
+- Wazuh vulnerability detection is enabled and indexing results
103
+
104
+---
105
+
106
+## Gotchas
107
+
108
+- Stale inventory = stale posture. If an agent hasn’t checked in recently, its vulnerability list may be outdated.
109
+- EPSS is a prioritization signal, not a guarantee—use it alongside your environment context (internet exposure, compensating controls, exploitability, asset criticality).
docs/user/ui/agents.md
+76
-3
@@ -1,9 +1,82 @@
1
+---
2
+title: Agents
3
+description: Operator-facing views and controls for endpoints, groups, actions, and security posture.
4
+---
5
+
6
# Agents
7
8
**Menu:** Agents
9
5
-**Best for:** Admin/Engineer + Detection engineering
10
+
11
7
-Agent-related pages cover endpoint group configuration, Sysmon config, detection rules, and security posture views.
12
+---
13
9
-
14
+## What this page is
15
+
16
+Agents are the onboarded endpoints reporting to the **Wazuh Manager**.
17
+
18
+In CoPilot, the **Wazuh Manager is the source of truth** for agent inventory and core endpoint status.
19
+
20
+This section includes:
21
+- viewing agent inventory
22
+- organizing agents into groups
23
+- reviewing posture (vulnerabilities, Patch Tuesday, SCA)
24
+- running response workflows (artifact collection, commands, quarantine, active response)
25
+
26
+---
27
+
28
+## When to use it
29
+
30
+Use Agents when you need to:
31
+- confirm an endpoint is onboarded and reporting
32
+- find endpoints by hostname/customer/group
33
+- pivot from an alert to the impacted endpoint
34
+
35
+---
36
+
37
+## Prerequisites
38
+
39
+- Agents are enrolled and reporting into the stack
40
+- Customer labels/grouping is configured (if you’re multi-tenant)
41
+
42
+---
43
+
44
+## Common tasks
45
+
46
+### Open an agent’s dedicated page
47
+
48
+You can open an agent directly by ID:
49
+
50
+`/agents/<agent_id>`
51
+
52
+On the dedicated agent page you can typically access:
53
+- **Overview** (identity + last seen + versions + customer_code)
54
+- **Vulnerabilities** (Wazuh vulnerability module)
55
+- **SCA** (Wazuh SCA results)
56
+- **Cases** the endpoint is part of
57
+- **Artifacts** previously collected
58
+- **Alerts** the endpoint is part of
59
+- **Collect** (run Velociraptor artifacts)
60
+- **Command** (run remote commands)
61
+- **Quarantine** (isolate/unisolate endpoint)
62
+- **Active Response** (run response capabilities)
63
+- **File Collection** (collect a file)
64
+- **Data Store** (endpoint data store)
65
+
66
+### Other pages in this section
67
+
68
+- View agents: [Agents](/user/ui/agents)
69
+- Manage groups: [Agent groups](/user/ui/agents-groups)
70
+- Sysmon config: [Sysmon config](/user/ui/agents-sysmon-config)
71
+- Detection rules: [Detection rules](/user/ui/agents-detection-rules)
72
+- Response/actions: [CoPilot actions](/user/ui/agents-copilot-actions)
73
+- Posture:
74
+ - [Vulnerability overview](/user/ui/agents-vulnerability-overview)
75
+ - [Patch Tuesday](/user/ui/agents-patch-tuesday)
76
+ - [SCA overview](/user/ui/agents-sca-overview)
77
+
78
+---
79
+
80
+## Gotchas
81
+
82
+- If an agent isn’t visible here, it’s usually an enrollment/ingestion issue upstream.
docs/user/ui/alerts-atomic-red-team.md
+8
-2
@@ -2,8 +2,14 @@
2
3
**Menu:** Alerts → Atomic Red Team
4
5
-**Best for:** Detection engineering / validation
5
+**Best for:** Operators + detection engineering / validation
6
7
-Use Atomic Red Team workflows to test detections and confirm alert routing.
7
+Use Atomic Red Team workflows to:
8
+- simulate attacker behaviors (Atomic tests)
9
+- verify telemetry and alert routing end-to-end
10
+- validate that detection rules are firing as expected
11
+
12
+Related power feature:
13
+- [Atomic Red Team (detection simulation)](/power-features/atomic-red-team)
14
15
docs/user/ui/alerts-mitre.md
+10
-2
@@ -2,8 +2,16 @@
2
3
**Menu:** Alerts → MITRE ATT&CK
4
5
-**Best for:** Detection engineering + reporting
5
+**Best for:** Operators + detection engineering + reporting
6
7
-Use this view for ATT&CK alignment, coverage discussions, and investigation context.
7
+This page provides a technique-centric lens across alerts/events.
8
+
9
+Use it for:
10
+- ATT&CK alignment and coverage discussions
11
+- investigation context (tactics/mitigations/software)
12
+- validating detection coverage (including Atomic tests, when available)
13
+
14
+Related power feature:
15
+- [MITRE ATT&CK integration](/power-features/mitre-attack)
16
17
docs/user/ui/alerts-siem.md
+28
-1
@@ -4,6 +4,33 @@
4
5
**Best for:** Both
6
7
-Use the SIEM view to search/pivot into surrounding events. This is often where you use `index_name` + `index_id` references.
7
+This page shows a **high-level view of SIEM alerts** based on what **Graylog** indicates (using the filters on the page).
8
+
9
+Important:
10
+- These are **different from Incident Management alerts**.
11
+- SIEM alerts shown here are **not created/managed** in CoPilot’s Incident Management queue.
12
+
13
+Use this page for:
14
+- a quick overview of alert volume and themes
15
+- validating that Graylog alerting is working
16
+- validating that alerts configured in Graylog are flowing into **Incident Management** when expected
17
+
18
+It is **not** intended to be the primary analyst workflow surface for alert handling.
19
20
21
+
22
+---
23
+
24
+## How to use it (practical)
25
+
26
+1) Apply your filters (customer/time window/stream/etc.)
27
+2) Confirm Graylog is producing the alerts you expect
28
+3) Pick an alert and pivot to underlying SIEM events (when available)
29
+4) Cross-check whether a corresponding Incident Management alert exists (if your routing/provisioning is configured to create one)
30
+
31
+---
32
+
33
+## Gotchas
34
+
35
+- If you see SIEM alerts here but not in Incident Management, it usually indicates an ingestion/routing gap (Graylog event definition/stream → CoPilot incident ingestion).
36
+- If you only need the analyst queue, go to: [Incident alerts](/user/ui/incident-alerts)
docs/user/ui/alerts.md
+3
-1
@@ -4,7 +4,9 @@
4
5
**Best for:** Admin/Engineer + Detection engineering + SOC leadership
6
7
-This section is oriented around SIEM views and testing/coverage (not the day-to-day triage queue).
7
+This section is oriented around **high-level alert visibility and validation** (not the day-to-day alert triage queue).
8
+
9
+These pages are **not** the same as [Incident alerts](/user/ui/incident-alerts). Incident Management is where analysts/operators typically work alerts.
10
11
## Sub-pages
12
docs/user/ui/artifacts.md
+163
-4
@@ -1,9 +1,168 @@
1
-# Artifacts
1
+---
2
+title: Artifacts (Velociraptor)
3
+description: Run Velociraptor artifacts from CoPilot to collect DFIR evidence from endpoints and review results.
4
+---
5
3
-**Menu:** Artifacts
6
+# Artifacts (Velociraptor)
7
5
-**Best for:** SOC operators / analysts
8
+**Menu:** Artifacts
9
7
-Artifacts are where you manage investigation files and evidence.
10
+CoPilot’s Artifacts feature integrates with **Velociraptor** (DFIR / threat hunting) to run **Velociraptor Artifacts** via the Velociraptor API and pull results back into CoPilot.
11
12
13
+
14
+---
15
+
16
+## What is Velociraptor?
17
+
18
+Velociraptor is an advanced **digital forensics and incident response (DFIR)** platform that gives you endpoint visibility and targeted evidence collection at scale.
19
+
20
+A few key concepts (Velociraptor terminology):
21
+- **VQL**: Velociraptor Query Language (how evidence is collected)
22
+- **Artifacts**: packaged collections (YAML) of one or more VQL queries + parameters + preconditions
23
+
24
+Velociraptor artifacts are designed to be reusable and safe to run across fleets using **preconditions** (if a precondition fails, that source is skipped).
25
+
26
+Reference:
27
+- Velociraptor docs: https://docs.velociraptor.app
28
+- Artifacts concept: https://docs.velociraptor.app/docs/vql/artifacts/
29
+
30
+---
31
+
32
+## What you can do in CoPilot
33
+
34
+From an operator perspective, CoPilot lets you:
35
+
36
+- **Select an endpoint** (agent/hostname / Velociraptor ID)
37
+- **Choose an artifact** to run (collection)
38
+- **Provide parameters** (when the artifact requires them)
39
+- **Run the artifact** and review the returned results
40
+
41
+---
42
+
43
+## Before you start (required identifiers)
44
+
45
+CoPilot needs a way to target the correct Velociraptor client.
46
+
47
+In the UI you’ll typically see fields like:
48
+- **Hostname** (optional)
49
+- **Velociraptor ID** (the Velociraptor client id)
50
+
51
+If the endpoint doesn’t have a valid Velociraptor ID mapped, collections won’t run against that host.
52
+
53
+---
54
+
55
+## Step 1 — Run an artifact collection
56
+
57
+
58
+
59
+1) Open **Artifacts**
60
+2) Select (or enter) the target endpoint (Hostname / **Velociraptor ID**)
61
+3) Choose the artifact you want to run
62
+4) Fill in any required parameters
63
+5) Start the collection
64
+
65
+Operator tips:
66
+- Prefer artifacts that are **targeted** (high-signal) rather than “collect everything.”
67
+- If an artifact supports parameters (time range, path, user, regex), start narrow.
68
+
69
+---
70
+
71
+## Step 2 — Review results
72
+
73
+
74
+
75
+After the artifact finishes, review:
76
+- returned rows/tables (the “answers” from VQL)
77
+- any files collected (if the artifact uploads files)
78
+- errors or skipped preconditions (common when an artifact is OS-specific)
79
+
80
+What good looks like:
81
+- You can answer: *what evidence did we collect, from which host, and what does it mean for the alert/case?*
82
+
83
+---
84
+
85
+## Step 3 — Use artifacts from an alert (fast triage)
86
+
87
+CoPilot also surfaces artifact collection entry points from **Alerts → Assets**.
88
+
89
+Practical workflow:
90
+1) Open an alert
91
+2) Go to the impacted asset
92
+3) Run a targeted artifact (process listing, persistence checks, event logs, etc.)
93
+4) Bring the result back into the case via notes/comments
94
+
95
+---
96
+
97
+## Step 4 — (Optional) Artifact recommendations
98
+
99
+Some CoPilot views may provide artifact recommendations to speed up response.
100
+
101
+
102
+
103
+---
104
+
105
+## Operator artifact starter pack (recommended)
106
+
107
+Use this section as a default playbook when you’re in triage and need to move fast.
108
+
109
+### 1) Identify the host (what system is this?)
110
+
111
+Run:
112
+- `Generic.Client.Info` (basic host facts)
113
+- `Generic.Client.DiskSpace` (quick disk pressure check)
114
+
115
+### 2) Process triage (what’s running right now?)
116
+
117
+Run:
118
+- Windows: `Windows.System.Pslist`
119
+- Linux: `Linux.Sys.Pslist`
120
+
121
+### 3) Network triage (is it talking to something?)
122
+
123
+Run:
124
+- Windows: `Windows.Network.Netstat`
125
+- Linux: `Linux.Network.Netstat`
126
+
127
+### 4) Persistence triage (will it come back?)
128
+
129
+Run:
130
+- `Windows.Sys.StartupItems`
131
+
132
+### 5) Find a file fast (where is this binary/script across the host?)
133
+
134
+Run:
135
+- `Windows.Search.FileFinder`
136
+
137
+### 6) Execution evidence (what ran recently?)
138
+
139
+Run:
140
+- `Windows.Forensics.Prefetch`
141
+- `Windows.System.Amcache` (alternate view of execution evidence)
142
+
143
+### 7) Log triage (high-signal Windows event hunting)
144
+
145
+Run:
146
+- `Windows.EventLogs.EvtxHunter`
147
+
148
+### 8) YARA hunting (when you have an IOC or suspect binary)
149
+
150
+Run:
151
+- Windows: `Windows.Detection.Yara.Process` (fast, memory/process focused)
152
+- Windows: `Windows.Detection.Yara.NTFS` (disk scan)
153
+- Linux: `Linux.Detection.Yara.Process`
154
+
155
+> Tip: Start with **Process**-scoped YARA first (fastest), then broaden to disk if needed.
156
+
157
+---
158
+
159
+## Common gotchas
160
+
161
+### “The artifact didn’t run / no results returned”
162
+Common causes:
163
+- The endpoint doesn’t have a correct **Velociraptor ID** mapped.
164
+- The artifact precondition skipped the collection (e.g., wrong OS).
165
+- Velociraptor connectivity/API credentials are not configured correctly.
166
+
167
+### “This collected too much data”
168
+Use parameterized artifacts, tighten time windows, and prefer targeted artifacts. Velociraptor is designed to return high-value results rather than bulk collection.
docs/user/ui/graylog-management.md
+89
-1
@@ -1,5 +1,93 @@
1
-# Graylog Management
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:** 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)
docs/user/ui/healthcheck.md
+98
-3
@@ -1,9 +1,104 @@
1
-# Healthcheck
1
+---
2
+title: Healthcheck (InfluxDB + Telegraf)
3
+description: Monitor endpoint and SIEM health signals via Telegraf metrics stored in InfluxDB.
4
+---
5
+
6
+# Healthcheck (InfluxDB + Telegraf)
7
8
**Menu:** Healthcheck
9
5
-**Best for:** Both
10
+**Best for:** Admin / Engineer (primary) + Operator (awareness)
11
+
12
+CoPilot’s Healthcheck ties into **InfluxDB** to surface health signals collected by **Telegraf**.
13
+
14
+Typical signals include:
15
+- CPU consumption
16
+- memory consumption
17
+- disk space utilization
18
7
-Healthcheck provides a high-level signal of platform/stack health.
19
+This is useful for detecting spikes, capacity issues, and “slow burn” failures before they impact your SIEM.
20
21
22
+
23
+---
24
+
25
+## How it works (high level)
26
+
27
+1) **Telegraf** runs on endpoints/servers and collects metrics (cpu/mem/disk)
28
+2) Metrics land in **InfluxDB** (CoPilot queries the InfluxDB `_monitoring` bucket)
29
+3) Health checks and thresholds create alert states (ok/info/warn/crit)
30
+4) CoPilot displays the resulting alerts in the Healthcheck UI
31
+
32
+---
33
+
34
+## What you can do in CoPilot
35
+
36
+### Review active alerts
37
+
38
+
39
+
40
+Use this to quickly see:
41
+- what is currently broken / at risk
42
+- which systems are trending toward failure
43
+
44
+### Triage by severity
45
+
46
+Healthcheck alerts are categorized by severity (for example: **Critical**, **Warning**, **Info**, **Ok**).
47
+
48
+
49
+
50
+---
51
+
52
+## What to monitor (recommended)
53
+
54
+### CPU
55
+- sustained high CPU on Graylog/Wazuh components can cause ingestion/alerting lag
56
+
57
+### Memory
58
+- memory pressure can lead to OOM kills and unstable services
59
+
60
+### Disk
61
+- disk thresholds are the most common SIEM failure mode (indexes stop accepting writes)
62
+
63
+---
64
+
65
+## Practical runbook (when something trips)
66
+
67
+1) Identify what triggered (disk vs cpu vs mem)
68
+2) Identify the system/host
69
+3) Decide whether this is:
70
+ - a transient spike
71
+ - a sustained capacity issue
72
+ - a misconfiguration (wrong retention / noisy ingestion)
73
+4) Take action:
74
+ - disk: snapshot/restore + retention tuning + index cleanup
75
+ - cpu/mem: scale resources, tune ingestion, investigate heavy queries
76
+
77
+Related pages:
78
+- [Index management (Wazuh Indexer)](/user/ui/indices-management)
79
+- [Snapshot & restore (cold storage)](/user/ui/indices-snapshots)
80
+
81
+---
82
+
83
+## Advanced: check names and thresholds
84
+
85
+Depending on your deployment, Influx may expose many checks.
86
+
87
+
88
+
89
+If you want to standardize what shows up in CoPilot, define consistent Telegraf inputs and consistent alert thresholds.
90
+
91
+
92
+
93
+---
94
+
95
+## Common gotchas
96
+
97
+### “Healthcheck is empty”
98
+Common causes:
99
+- Telegraf isn’t deployed or isn’t shipping metrics
100
+- InfluxDB connector isn’t configured in CoPilot
101
+- wrong org/bucket configuration (CoPilot expects `_monitoring`)
102
+
103
+### “Alerts are noisy”
104
+Tune thresholds to avoid flapping (especially CPU) and focus on sustained conditions.
docs/user/ui/incident-alerts.md
+161
-5
@@ -1,11 +1,167 @@
1
-# Incident Alerts
1
+---
2
+title: Incident alerts
3
+description: How to triage, filter, tag, and collaborate on alerts in SOCFortress CoPilot.
4
+---
5
3
-**Menu:** Incident Management → Alerts
6
+# Incident alerts
7
5
-**Best for:** SOC operators / analysts
8
+**Menu:** Incident Management → Alerts
9
10
This is your primary triage queue.
11
9
-Deep link tip: `/incident-management/alerts?alert_id=<id>`
10
-
12
13
+
14
+---
15
+
16
+## What you’re looking at
17
+
18
+The Alerts view is split into two parts:
19
+
20
+- **Alerts list** (left): your queue (newest/most relevant alerts)
21
+- **Alert details** (right or modal): the selected alert, with tabs like **Overview** and **Timeline**
22
+
23
+Deep link tip: you can open/highlight an alert directly with:
24
+
25
+`/incident-management/alerts?alert_id=<id>`
26
+
27
+---
28
+
29
+## Step 1 — Triage an alert (quick workflow)
30
+
31
+1) Open **Incident Management → Alerts**
32
+2) Click an alert in the list to open **details**
33
+3) In **Overview**, confirm:
34
+ - **Customer** (tenant)
35
+ - **Title / Description**
36
+ - **Assets** impacted (an alert can include multiple assets)
37
+ - Any existing **Tags**, **Comments**, and **IOCs**
38
+4) Decide your next action:
39
+ - add a **Comment** (notes + handoff)
40
+ - add an **IOC** (evidence you want tracked)
41
+ - apply **Tags** (triage labels + RBAC visibility)
42
+ - move to a **Case** (if you need investigation tracking)
43
+
44
+---
45
+
46
+## Step 2 — Filter the queue (find what matters fast)
47
+
48
+Use the filter controls to narrow your queue.
49
+
50
+
51
+
52
+### UI callout: Add filter → Customer Code + Tag
53
+
54
+1) Click **Add filter**
55
+2) Add **Customer Code**
56
+ - Pick a tenant from the dropdown (shows as `#<code> - <name>`)
57
+3) Add **Tag**
58
+ - The Tag filter is **multi-select**
59
+ - You can type a tag and press **Enter** to add it
60
+4) Click **Submit** to apply
61
+
62
+Available filters include:
63
+
64
+- **Status** (Open / Closed / In progress)
65
+- **Assigned To** (dropdown)
66
+- **Customer Code** (dropdown)
67
+- **Source** (dropdown)
68
+- **Tag** (multi-select; type + Enter)
69
+- **Title** (text)
70
+- **Asset Name** (text)
71
+- **IoC** (text)
72
+
73
+Notes:
74
+- Filters are intended to speed up triage — they don’t bypass security.
75
+- **Customer scoping** and **tag-based visibility** are enforced server-side.
76
+
77
+---
78
+
79
+## Step 3 — Apply tags (triage + access control)
80
+
81
+Tags are used for two things:
82
+
83
+1) **Triage / workflow labels** (examples: `needs-validation`, `high-confidence`, `containment`, `false-positive`)
84
+2) **Role-based access control (RBAC)**: some environments restrict alert visibility by tag.
85
+
86
+Operator-facing tips:
87
+- If an alert “disappears” from your view, it may be because:
88
+ - you no longer have access to that **customer**, or
89
+ - you don’t have access to one of the alert’s **tags**.
90
+
91
+---
92
+
93
+## Step 4 — Understand assets on alerts (why one alert can have many)
94
+
95
+
96
+
97
+
98
+
99
+An alert can be linked to **multiple assets** (hosts/users/entities).
100
+
101
+CoPilot also has **dedup/merge** behavior:
102
+
103
+- If a *new incoming alert* matches an **existing OPEN alert** for the **same customer** and has the **same title**, CoPilot will **not** create a second alert.
104
+- Instead, it **adds the new asset** to the existing alert.
105
+- A new alert is created when:
106
+ - the previous alert was moved to a **CLOSED** phase for that customer, or
107
+ - the same title appears for a **different customer**.
108
+
109
+Why this matters in triage:
110
+- The alert title may look “unchanged,” but the **asset list grows**, which is often your first signal that scope expanded.
111
+
112
+---
113
+
114
+## Step 5 — Comments and IOCs (collaboration + evidence)
115
+
116
+
117
+
118
+
119
+
120
+In the alert details pane, use the tabs:
121
+- **Comments** (for notes + handoff)
122
+- **IoCs** (for evidence you want tracked)
123
+
124
+### UI callout: Add a comment
125
+
126
+1) Open the alert details
127
+2) Click the **Comments** tab
128
+3) Type into **“Write a new comment…”**
129
+4) Click **Send comment**
130
+
131
+Tip: use comments for decision logging (“why we think this is benign/malicious”), scope notes, and handoff.
132
+
133
+### UI callout: Add an IOC
134
+
135
+
136
+
137
+1) Open the alert details
138
+2) Click the **IoCs** tab
139
+3) Click **Create IoC**
140
+4) Fill out:
141
+ - **Description**
142
+ - **Type** (IP / DOMAIN / HASH / URL)
143
+ - **Value**
144
+5) Click **Submit**
145
+
146
+Notes:
147
+- The **Value** field is disabled until you select a **Type**.
148
+- IOCs can be deleted later from the IoCs list.
149
+
150
+---
151
+
152
+## Timeline (audit trail)
153
+
154
+Use the **Timeline** tab to review alert activity over time (updates, notes, linked context).
155
+
156
+---
157
+
158
+## Common gotchas
159
+
160
+### “Why didn’t a new alert get created?”
161
+It was likely merged into an existing OPEN alert (same customer + same title) and the new entity showed up under **Assets**.
162
+
163
+### “I can’t delete this alert in bulk”
164
+Bulk delete intentionally skips alerts that are **linked to cases**.
165
+
166
+### “Why can’t I see an alert my teammate can see?”
167
+Tag-based RBAC and customer access are enforced server-side. Differences in **tag access** or **customer access** can change visibility.
docs/user/ui/incident-cases.md
+109
-4
@@ -1,11 +1,116 @@
1
-# Incident Cases
1
+---
2
+title: Incident cases
3
+description: How to build and run an investigation case by linking multiple alerts, tracking work, and generating reports.
4
+---
5
+
6
+# Incident cases
7
8
**Menu:** Incident Management → Cases
9
5
-**Best for:** SOC operators / analysts
10
+Cases are where you **bundle related alerts into one investigation** (example: Wazuh + firewall + third‑party integration alerts) and track the work from triage → resolution.
11
7
-Cases track investigation lifecycle and allow you to link related alerts, comments, and artifacts.
12
+Deep link tip: you can open/highlight a case directly with:
13
9
-Deep link tip: `/incident-management/cases?case_id=<id>`
14
+`/incident-management/cases?case_id=<id>`
15
16
17
+
18
+---
19
+
20
+## What you’re looking at
21
+
22
+The Cases view is split into two parts:
23
+
24
+- **Cases list** (left): your queue of open/in‑progress/closed cases
25
+- **Case details** (right or modal): the selected case, with tabs like:
26
+ - **Overview**
27
+ - **Alerts** (linked alerts)
28
+ - **Comments**
29
+ - **Data Store**
30
+
31
+---
32
+
33
+## Step 1 — Create or open a case
34
+
35
+
36
+
37
+1) Open **Incident Management → Cases**
38
+2) Click a case in the list to open **details**
39
+3) Use **Overview** to confirm:
40
+ - case name + description
41
+ - customer (tenant)
42
+ - status + assignee
43
+
44
+---
45
+
46
+## Step 2 — Link multiple alerts to the same case
47
+
48
+A case becomes valuable when it holds *all the signals* for the incident.
49
+
50
+Example workflow:
51
+- A **Wazuh** alert fires (endpoint)
52
+- A **firewall** alert fires (network)
53
+- A **third‑party integration** alert fires (cloud / email / EDR)
54
+
55
+Link them all to the same case so the case becomes the single place to:
56
+- see the full timeline of signals
57
+- coordinate comments
58
+- generate a consolidated report
59
+
60
+### UI callout: Review linked alerts
61
+
62
+
63
+
64
+1) Open the case details
65
+2) Click the **Alerts** tab
66
+3) Confirm all related alerts are listed under this case
67
+
68
+> Tip: You can link alerts from the **Alerts** screen as well (operators usually start from an alert, then attach it to an existing case).
69
+
70
+---
71
+
72
+## Step 3 — Use comments for investigation notes + handoff
73
+
74
+
75
+
76
+1) Open the case details
77
+2) Click **Comments**
78
+3) Add investigation notes, decisions, and handoff context
79
+
80
+---
81
+
82
+## Step 4 — Use Data Store for supporting material
83
+
84
+
85
+
86
+Use **Data Store** to keep files tied to the case (exports, screenshots, timelines, supporting artifacts).
87
+
88
+---
89
+
90
+## Step 5 — Generate a case report (Jinja templates)
91
+
92
+Cases can generate reports using templates.
93
+
94
+### UI callout: Generate Report
95
+
96
+
97
+
98
+1) Open the case details
99
+2) In **Overview**, click **Generate Report**
100
+3) Choose a **Template**
101
+4) Enter a **Filename**
102
+5) Click **Generate**
103
+
104
+Template notes:
105
+- Templates are **customizable** and support **Jinja** templating.
106
+- Different template types may generate different outputs (for example: a `.docx` template vs an `.html` template used to generate a PDF).
107
+
108
+---
109
+
110
+## Common gotchas
111
+
112
+### “Why can’t I find all alerts for this incident in one place?”
113
+Make sure you link each relevant alert (endpoint + network + third‑party) into the same case via the **Alerts** tab.
114
+
115
+### “My report template isn’t available in the dropdown”
116
+Report templates are managed in the template manager (your environment may restrict who can upload/manage templates).
docs/user/ui/incident-sources.md
+125
-3
@@ -1,9 +1,131 @@
1
-# Incident Sources
1
+---
2
+title: Incident sources (Graylog → Alerts)
3
+description: Configure how CoPilot reads Graylog event alerts and turns them into Incident Management alerts.
4
+---
5
+
6
+# Incident sources (Graylog → Alerts)
7
8
**Menu:** Incident Management → Sources
9
5
-**Best for:** Admin/Engineer (setup) + Operator (awareness)
10
+**Best for:** Admin / Engineer
11
+
12
+Incident Sources define how CoPilot **turns Graylog event alerts into CoPilot Incident Alerts**.
13
7
-Sources define how alerts are grouped and routed into Incident Management.
14
+In practice, Sources answer:
15
+- *Which logs/index patterns are eligible to create alerts?*
16
+- *How do we group alerts by “source” (Wazuh vs O365 vs Mimecast vs …)?*
17
+- *Which fields become the alert title, asset, timestamp, and context we see in CoPilot?*
18
19
20
+
21
+---
22
+
23
+## How alerting works (mental model)
24
+
25
+CoPilot uses **Graylog** to do the detection logic and searching.
26
+
27
+High level:
28
+
29
+1) Graylog evaluates **Event Definitions** (your detection logic)
30
+2) When an event fires, Graylog writes an alert into an index (commonly `gl-events*`)
31
+3) CoPilot reads those event alerts and **creates/updates** alerts inside **Incident Management → Alerts**
32
+
33
+
34
+
35
+---
36
+
37
+## What a “Source” means in CoPilot
38
+
39
+A **Source** is essentially an **alert category**.
40
+
41
+Examples:
42
+- **Wazuh** (endpoint alerts)
43
+- **Office 365**
44
+- **Mimecast**
45
+- **CrowdStrike**
46
+- **Firewall / Syslog**
47
+
48
+This keeps your triage queue clean and helps you group alerts by where they came from.
49
+
50
+---
51
+
52
+## Step 1 — Create a source
53
+
54
+
55
+
56
+1) Open **Incident Management → Sources**
57
+2) Click to **add** a new source
58
+3) Give it a name you’ll use consistently (example: `wazuh`, `office365`, `mimecast`)
59
+
60
+---
61
+
62
+## Step 2 — Choose the index pattern(s) for this source
63
+
64
+
65
+
66
+You’ll select which index patterns/log sources are relevant for this alert source.
67
+
68
+Important:
69
+- This does **not** mean “alerts can only be created from this one index.”
70
+- It’s defining what data CoPilot can use as **alert context** when it builds the alert record.
71
+
72
+---
73
+
74
+## Step 3 — Map the fields CoPilot needs (the important part)
75
+
76
+
77
+
78
+A source defines which fields CoPilot should use when it creates an alert.
79
+
80
+### Alert title field
81
+This becomes the alert’s **title** in CoPilot.
82
+
83
+Example (Wazuh):
84
+- rule description is often the best title field (it explains *why* it fired).
85
+
86
+### Asset name field
87
+This controls which entity becomes the **Asset** on the alert (and is key for dedup/merging behavior).
88
+
89
+Example (Wazuh):
90
+- agent name is commonly used as the asset name.
91
+
92
+### Time field
93
+This controls which timestamp CoPilot uses for alert ordering/timelines.
94
+
95
+Tip:
96
+- Pick the most reliable timestamp for the detection record you’re using.
97
+
98
+### Context fields
99
+These are the fields you want visible inside the alert details.
100
+
101
+Important distinction:
102
+- Context fields are **not** the detection logic.
103
+- Detection logic stays in **Graylog Event Definitions**.
104
+- Context fields define what metadata CoPilot stores/displays when the alert fires.
105
+
106
+---
107
+
108
+## Step 4 — Validate end-to-end
109
+
110
+1) In Graylog, confirm your **Event Definition** is firing (test with a known event)
111
+2) Confirm Graylog writes events into `gl-events*`
112
+3) In CoPilot, confirm a new alert appears under **Incident Management → Alerts** with:
113
+ - correct **Source**
114
+ - correct **Title**
115
+ - correct **Asset**
116
+ - useful **Context** fields
117
+
118
+---
119
+
120
+## Common gotchas
121
+
122
+### “Graylog is alerting, but CoPilot shows nothing”
123
+Usually one of:
124
+- the event alerts aren’t being written where CoPilot expects (index / permissions)
125
+- source field mappings don’t match the fields in the event payload
126
+
127
+### “Alerts are grouped wrong / mixed between integrations”
128
+Create separate Sources (Wazuh vs O365 vs Mimecast vs firewall) and ensure your Graylog event definitions populate the fields needed to classify them.
129
+
130
+### “Alerts don’t have enough metadata”
131
+Add more **context fields** to the source mapping so CoPilot can store/display the details operators need.
docs/user/ui/indices-management.md
+69
-1
@@ -1,5 +1,73 @@
1
-# Index Management
1
+---
2
+title: Index management (Wazuh Indexer)
3
+description: Monitor index health, disk usage by customer, and manage retention in the Wazuh Indexer.
4
+---
5
+
6
+# Index management (Wazuh Indexer)
7
8
**Menu:** Indices → Index Management
9
10
+**Best for:** Admin / Engineer
11
+
12
+Index Management gives you an operational view of your **Wazuh Indexer** storage and index health.
13
+
14
+This matters because the indexer is where your SIEM data lives — if storage or index health degrades, search/alerting and investigations degrade with it.
15
+
16
17
+
18
+---
19
+
20
+## What you can do here
21
+
22
+- Check overall **indexer health** (high-level “are we OK?” signal)
23
+- See **storage usage by customer** (who is consuming the most disk)
24
+- Identify large/noisy indexes
25
+- Delete indexes when appropriate (careful: destructive)
26
+
27
+---
28
+
29
+## Step 1 — Review overall health
30
+
31
+
32
+
33
+Use this as your first stop when you see:
34
+- searches slowing down
35
+- ingestion backpressure
36
+- dashboards timing out
37
+- alerting gaps
38
+
39
+---
40
+
41
+## Step 2 — Review storage by customer (who is using the disk?)
42
+
43
+
44
+
45
+This view helps you answer:
46
+- Which customers have the highest log volume?
47
+- Which customer is driving storage growth this week?
48
+- Do we need to tune ingestion/noise upstream?
49
+
50
+Practical actions:
51
+- confirm high-volume customers match expectations (endpoint count, integrations)
52
+- tune noisy sources (drop/suppress earlier in the pipeline)
53
+- adjust retention strategy
54
+
55
+---
56
+
57
+## Step 3 — Delete indexes (only when you mean it)
58
+
59
+
60
+
61
+Deleting an index is destructive.
62
+
63
+Use cases:
64
+- removing test/lab data
65
+- cleaning up misconfigured pipelines that created junk indexes
66
+- emergency disk recovery (prefer snapshots + retention tuning first)
67
+
68
+---
69
+
70
+## Related: cold storage via Snapshot & Restore
71
+
72
+If you need to free up space without losing historical logs, use:
73
+- [Snapshot & Restore](/user/ui/indices-snapshots)
docs/user/ui/indices-snapshots.md
+82
-1
@@ -1,5 +1,86 @@
1
-# Snapshot & Restore
1
+---
2
+title: Snapshot & restore (cold storage)
3
+description: Offload old indexes into snapshot repositories and restore them later when needed.
4
+---
5
+
6
+# Snapshot & restore (cold storage)
7
8
**Menu:** Indices → Snapshot & Restore
9
10
+**Best for:** Admin / Engineer
11
+
12
+Snapshots let you **offload older indexes into cold storage** (snapshot repositories) so you can make room for new events while still keeping the ability to restore history later.
13
+
14
15
+
16
+---
17
+
18
+## When to use snapshots
19
+
20
+Use snapshots when you need to:
21
+- reduce disk usage on the indexer
22
+- keep long-term historical logs without keeping them “hot”
23
+- preserve data before major maintenance/changes
24
+
25
+---
26
+
27
+## Repository registration is required
28
+
29
+CoPilot can manage snapshots, but the snapshot **repository must exist and be registered** in the Wazuh Indexer cluster first.
30
+
31
+In the UI you’ll see this warning if none exist:
32
+
33
+> “Snapshot repositories must be manually registered in your Wazuh Indexer cluster …”
34
+
35
+
36
+
37
+---
38
+
39
+## Step 1 — Verify repositories
40
+
41
+1) Open **Indices → Snapshot & Restore**
42
+2) Click **Repositories**
43
+3) Confirm at least one repository exists and is healthy
44
+
45
+---
46
+
47
+## Step 2 — Create a snapshot
48
+
49
+
50
+
51
+1) Go to **Snapshots**
52
+2) Choose the repository
53
+3) Select the index/index pattern(s) to snapshot
54
+4) Run the snapshot
55
+
56
+---
57
+
58
+## Step 3 — Restore a snapshot (when you need old data)
59
+
60
+
61
+
62
+Restoring brings historical data back so you can:
63
+- investigate an incident with older timelines
64
+- run retro-hunts
65
+- rebuild context for cases
66
+
67
+---
68
+
69
+## Step 4 — Schedule snapshots (automation)
70
+
71
+
72
+
73
+If you regularly offload older logs, scheduled snapshots help keep disk usage stable.
74
+
75
+---
76
+
77
+## Common gotchas
78
+
79
+### “No snapshot repositories found”
80
+A repository must be registered in the Wazuh Indexer cluster before snapshots can run.
81
+
82
+### “Snapshots succeed but disk is still full”
83
+Snapshots don’t automatically delete hot indexes. You still need a retention plan:
84
+- delete old indexes (with intent)
85
+- reduce ingestion volume
86
+- tune retention windows
docs/user/ui/report-creation.md
+25
-4
@@ -1,9 +1,30 @@
1
-# Report Creation
1
+---
2
+title: Report creation (operator)
3
+description: Generate General (Grafana-to-PDF), Vulnerability, and SCA reports in CoPilot.
4
+---
5
+
6
+# Report creation
7
8
**Menu:** Report Creation
9
5
-**Best for:** Admin/Engineer + SOC leadership
10
+**Best for:** SOC operators / analysts + SOC leadership
11
+
12
+CoPilot supports three report types:
13
+
14
+1) **General reports**: snapshots Grafana dashboard panels and generates a PDF
15
+2) **Vulnerability reports**: pulls vulnerability data from the **Wazuh Vulnerability Detection** module
16
+3) **SCA reports**: pulls hardening/compliance results from the **Wazuh SCA** module
17
+
18
+---
19
+
20
+## Choose the report type
21
+
22
+Use the Report Creation area to select which report you want to generate:
23
7
-Report Creation is where you generate PDF/report outputs (Grafana dashboards and security reporting).
24
+- [General reports](/user/ui/report-general)
25
+- [Vulnerability reports](/user/ui/report-vulnerability)
26
+- [SCA reports](/user/ui/report-sca)
27
9
-
28
+Tip:
29
+- Use **General reports** for executive summaries and “what did we see?” dashboards.
30
+- Use **Vulnerability/SCA** reports for operational security posture and remediation tracking.
docs/user/ui/report-general.md
+58
-1
@@ -1,5 +1,62 @@
1
-# General Reports
1
+---
2
+title: General reports (Grafana → PDF)
3
+description: Create PDF reports by snapshotting Grafana panels and combining them into a single document.
4
+---
5
+
6
+# General reports (Grafana → PDF)
7
8
**Menu:** Report Creation → General Reports
9
10
+General reports generate a PDF by taking snapshots of selected **Grafana dashboard panels**.
11
+
12
13
+
14
+---
15
+
16
+## What you need
17
+
18
+- A Grafana org + dashboard you can access
19
+- The panels you want to include
20
+
21
+---
22
+
23
+## Step 1 — Pick dashboard + time range
24
+
25
+
26
+
27
+1) Open **Report Creation → General Reports**
28
+2) Select the **Organization**
29
+3) Select the **Dashboard**
30
+4) Choose a **time range** (ex: `24h`, `7d`, `30d`)
31
+
32
+---
33
+
34
+## Step 2 — Select panels to include
35
+
36
+
37
+
38
+1) Pick the panels you want in the report
39
+2) Arrange/confirm the selection
40
+
41
+---
42
+
43
+## Step 3 — Generate the PDF
44
+
45
+When you generate the report, CoPilot will:
46
+- create secure iframe links for the selected panels
47
+- capture panel images
48
+- assemble a PDF
49
+
50
+Operator tips:
51
+- Keep reports focused: pick 6–12 panels rather than trying to include everything.
52
+- Use consistent time ranges so reports are comparable week-to-week.
53
+
54
+---
55
+
56
+## Common gotchas
57
+
58
+### “This only works on desktop”
59
+General report generation is desktop-oriented (panel selection/layout).
60
+
61
+### “Panels are blank / missing data”
62
+Usually a Grafana permissions or time range issue.
docs/user/ui/report-sca.md
+57
-1
@@ -1,5 +1,61 @@
1
-# SCA Reports
1
+---
2
+title: SCA reports (Wazuh)
3
+description: Generate CSV reports for Security Configuration Assessment (SCA) results from Wazuh policy scans.
4
+---
5
+
6
+# SCA reports (Wazuh)
7
8
**Menu:** Report Creation → SCA Reports
9
10
+SCA (Security Configuration Assessment) reports pull from the **Wazuh SCA module**, which evaluates endpoints against hardening/compliance policies.
11
+
12
+Wazuh SCA model (simplified):
13
+- agents scan against SCA **policies** (rules/checks)
14
+- results are tracked per check (pass/fail/not applicable)
15
+- agents send diffs/summary to the manager to reduce noise
16
+
17
18
+
19
+---
20
+
21
+## What you can do
22
+
23
+- Review SCA posture across a customer (policy score, failing checks)
24
+- Generate a CSV report for auditing and remediation planning
25
+
26
+---
27
+
28
+## Step 1 — Review SCA overview
29
+
30
+
31
+
32
+Common operator filters:
33
+- Customer
34
+- Agent/host
35
+- Policy id/name
36
+- Minimum/maximum score
37
+
38
+---
39
+
40
+## Step 2 — Generate and download
41
+
42
+
43
+
44
+When you generate an SCA report, CoPilot produces a **CSV** containing policy results.
45
+
46
+Operator tips:
47
+- Treat SCA as a “secure baseline drift” signal.
48
+- Use policy-based grouping (CIS/NIST mappings) for audit discussions.
49
+
50
+---
51
+
52
+## Common gotchas
53
+
54
+### “No SCA data found”
55
+Common causes:
56
+- SCA is not enabled on the agents
57
+- policies are not deployed
58
+- the agents haven’t scanned yet (or haven’t checked in)
59
+
60
+### “Why did results change?”
61
+SCA alerts are typically emitted on **status change** between scans (pass↔fail↔n/a) rather than spamming every scan.
docs/user/ui/report-vulnerability.md
+57
-1
@@ -1,5 +1,61 @@
1
-# Vulnerability Reports
1
+---
2
+title: Vulnerability reports (Wazuh)
3
+description: Generate CSV reports from the Wazuh Vulnerability Detection module data in the Wazuh Indexer.
4
+---
5
+
6
+# Vulnerability reports (Wazuh)
7
8
**Menu:** Report Creation → Vulnerability Reports
9
10
+Vulnerability reports pull data from the **Wazuh Vulnerability Detection** module.
11
+
12
+Wazuh’s model (simplified):
13
+- agents collect software inventory via **Syscollector**
14
+- the manager correlates inventory with CTI feeds and flags CVEs
15
+- results are indexed and queryable (inventory + alerts)
16
+
17
18
+
19
+---
20
+
21
+## What you can generate
22
+
23
+- A vulnerability report for a specific **customer/tenant**
24
+- Filtered views by severity, agent, package, CVE, etc. (depending on UI/options)
25
+
26
+---
27
+
28
+## Step 1 — Filter what you want to report on
29
+
30
+
31
+
32
+Common operator filters:
33
+- Customer
34
+- Severity (Critical/High/Medium/Low)
35
+- Agent/host
36
+- Specific CVE (`CVE-…`)
37
+
38
+---
39
+
40
+## Step 2 — Generate and download
41
+
42
+
43
+
44
+When you generate a report, CoPilot produces a **CSV** and stores it for download.
45
+
46
+Operator tips:
47
+- Use “Critical + High” first for remediation prioritization.
48
+- If you’re generating very large reports, prefer background generation if available.
49
+
50
+---
51
+
52
+## Common gotchas
53
+
54
+### “The report is empty”
55
+Common causes:
56
+- the Wazuh vulnerability module isn’t enabled or isn’t indexing status
57
+- the customer has no Syscollector inventory data
58
+- filters are too narrow
59
+
60
+### “Why do vulnerabilities exist even if we patched?”
61
+Wazuh correlates inventory versions + hotfix data (Windows) against CVE ranges. Inventory and patch state need to be current.
docs/videos.mdx
new
+15
@@ -0,0 +1,15 @@
1
+---
2
+title: Videos
3
+description: The CoPilot YouTube playlist, summarized and organized by role.
4
+---
5
+
6
+# Videos
7
+
8
+Use the playlist like documentation: each video is linked and summarized into skimmable bullets.
9
+
10
+- [Open the video library](/user/videos)
11
+
12
+## Role-based tracks
13
+
14
+- [Operator track](/user/videos#operator-track)
15
+- [Admin/Engineer track](/user/videos#adminengineer-track)
mkdocs.yml
+1
-1
@@ -70,7 +70,7 @@ extra_css:
70
- stylesheets/extra.css
71
72
nav:
73
- - Home: index.md
73
+ - Home: index-mkdocs.md
74
- User Guide:
75
- Overview: user/overview.md
76
- Quickstart (Operators): user/operators-quickstart.md