To keep a security monitoring environment high-performing and dependable, apply these guidelines while building rules and filters.

Rule Development

1. Start Simple: First create rules for narrow, high-fidelity patterns. Steer clear of excessively broad rules that introduce alert noise.

2. Limit Scope: Always specify dataTypes. This keeps the engine from wasting CPU cycles on firewall rule checks against Windows event logs.

3. Use Deduplication: Always define deduplicateBy. This stops the system from producing hundreds of duplicate alerts for one ongoing attack.

4. Document Intention: Use the description and references fields. This allows SOC analysts to see why an alert fired and how to react.

5. Optimize CEL: CEL expressions run quickly, but deeply nested logic can introduce delay. Keep the where Keep the clause as succinct as possible.

Filter & Pipeline Design

1. Standardize Naming: Always map raw fields to the Unified Security Stack Common Schema (e.g., origin.ip, target.user, action).

2. Clean as you Go: Use the delete step to remove temporary metadata and unnecessary log.* fields after normalization finishes. Concentrate on fields that rules or dashboards no longer need.

   Note: The raw field remains protected for auditing reasons and parsing steps cannot remove it.

3. Handle Edge Cases: Use where clauses to ensure steps only run when fields exist (e.g., where: exists("origin.ip")).

4. Use Built-in Patterns: In grok, favor built-in patterns like {{.ipv4}} instead of custom regex. They are already optimized and easier to read.

5. Stage Logical Changes: Group renames together, then casts, then enrichment. This makes the YAML simpler for other developers to understand.

Performance Checklist

• Are data types limited?

• Are correlation windows (withinIs the time in rules limited to the minimum required?

• are correlation counts reasonable? (Max recommended is 50).