| 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 | |
| 6 | # Agent groups (Wazuh) |
| 7 | |
| 8 | **Menu:** Agents → Groups |
| 9 | |
| 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. |