Skip to main content

Findings & Rules

Use this guide to understand how IDS findings are generated from Wazuh alerts, normalized in Cloudaware, linked to CMDB configuration items (CIs), and tuned to reduce noise.

Rule Sets and Decoders​

Cloudaware IDS builds on Wazuh’s standard rules, decoders, and lists, with additional tuning for cloud and Kubernetes environments:

  • Baseline rules detect file integrity changes, suspicious processes, authentication anomalies, and policy violations.
  • Cloudaware rules incorporate cloud provider metadata (for example, account, region, instance ID) and Kubernetes context where available.
  • Custom rules can be added for organization-specific applications and controls.

Cloudaware maintains and updates the shared rule packs.

For severity levels, see also Rules classification

Findings in CMDB​

When an event matches a rule:

  • Wazuh generates an alert.
  • Cloudaware normalizes the data and creates or updates IDS findings linked to CMDB CIs.
  • Severity, category, and other attributes are derived from the rule metadata and Cloudaware mappings.

On CIs that participate in IDS:

  • An IDS status indicator summarizes the current state (for example, Not monitored, Monitored, Under attack).
  • Linked IDS findings provide detail and history for investigations and reporting.

Tuning, Noise Reduction, and Exceptions​

To keep alerts actionable:

  • Suppress or downgrade noisy rules that represent acceptable behavior in your environment.
  • Use exceptions to handle known-but-accepted patterns such as routine administrative tasks or vulnerability scans.
  • Align severities with your internal risk model so high and critical findings match your incident response priorities.
  • Periodically review top talkers (most frequent rules or sources) and tune accordingly.

Coordinate tuning with Cloudaware support for complex use cases or multi-tenant environments.

Mapping to Frameworks​

Many rules can be mapped to security frameworks and taxonomies (for example, MITRE ATT&CK, CIS controls, and PCI DSS requirements). Use these mappings to:

  • Demonstrate coverage for specific controls.
  • Group IDS findings by technique or control family for reporting.
  • Prioritize tuning and remediation in areas with higher regulatory or business importance.