Add rule ID field to alert structure

[esoadamo]

Summary

This PR adds rule.id field to the rule JSON alert's data in compliance with ECS Rule fields. This will allow to match the alert with exact rule even in case multiple rule packs are enabled, which can be used to gain insights into which rules/rule packs are responsible for which percentage of overall alert volume. Using rule ID instead of rule name keeps this future-proof in case the name changes.

The ID is prefixed with the engine (yara, sigma, ioc) so that is is assured to be unique within the rustinel rules (as the specs require).

Detailed changes

1. Added rule.id ( <type>::<actual id> ):
   • Sigma rules: If the rule file contains an explicit id (e.g., UUID), formats the output rule.id field as sigma::<uuid> . If no ID is specified, the rule.id field is omitted from the JSON alert entirely.
   • YARA rules: If the rule block contains an id field in its metadata section (e.g., id = "yara-lnx-xmrig-coinminer" ), formats the output rule.id field as yara::<metadata_id>. Otherwise, the field is omitted from the JSON alert.
   • IoC rules: The rule ID is formatted as ioc::<kind>::<indicator> (e.g. ioc::domain::example.com or ioc::hash::0c2674... ), referencing the type of indicator matched and the indicator value itself.
2. Added Integration Tests:
   • Added a new integration test suite test_rule_id_mapping_and_omit_behavior to tests/ecs_contract.rs to verify that when rule_id is defined, it is formatted and serialized correctly, and when it is absent, it is omitted from the alert JSON payload.

Type of change

• feat / enhancement — new feature
• bug — bug fix
• refactor — refactoring, no behaviour change
• documentation — docs only
• ci — CI/CD changes
• dependencies — dependency update

Test plan

• Tested on Windows
• Tested on Linux
• Existing tests pass (cargo test)
• New tests added (if applicable)

Checklist

• Label added to this PR
• Docs updated (if behaviour changed)

[Karib0u]

Thanks for the contribution. The implementation looks solid overall, but I found one blocking interaction with alert deduplication.

Blocking issue

The dedup key still uses rule_name rather than the new stable rule_id (src/alerts/dedup.rs:25-38).

Since deduplication is enabled by default, two rules with the same title and process context but different IDs are treated as the same alert. The second rule can be suppressed, and the resulting rollup is attributed to the first rule. This conflicts with the goal of distinguishing identical rule names across rule packs.

Please use rule.id in the dedup key when available, falling back to rule.name for rules without an ID. A regression test covering equal names with different IDs should also be added.

Once the deduplication issue is fixed, this should be ready to merge.

[esoadamo]

Thanks for the review! I have made the rule ID a primary de-duplicator with fallback to name::<rule name> if no ID is set for the rule. Tests were added for this feature as well.