Rule Health Validation

The problem

Rules can be enabled and still broken. Some point at data you no longer collect, so they never fire. Others have logic that misses what they were written to catch, or a query that searches 14 days of data while the rule's own settings let it look back only one day. Rules that do fire can group badly. One user can be split across many alerts, because the field the rule groups on is not mapped to a user, host or address. An incident can also fill at 150 alerts and spill into a duplicate. Broken entity mappings leave analysts without the user, host or address they need. None of this shows on a dashboard.

What we check

• Rules that cannot fire, because the data they read is no longer collected.
• Logic that does not match what the rule was written to catch.
• How alerts are grouped into incidents, including incidents that fill at 150 alerts and spill into a duplicate, and repeat alerts for the same user, host or address.
• Entity mappings (the link from a rule to the user, host or address in an alert) that are broken or missing.
• The rule's settings limit how far back it looks, so it covers less time than its query was written for.

What you get

• Findings for every enabled rule, so you know which are healthy and which are not.
• A validated fix for each broken rule, ready to deploy.
• A list of the log sources you would need to switch on for the rules we cannot fix on our side.
• A change note to approve before anything is deployed.

How it works

The review is read-only. Nothing in your workspace changes until you approve the change note. You can deploy the fixes yourself, or have us deploy them, check the same day that nothing floods the queue, and re-check after seven days. Where a fix would flood the queue, we say so and hold it for your decision.