[New] Alerts in Different ATT&CK Tactics by Host

[Samirbous]

Using ES|QL and alerts risk score to identify top risky hosts based on presence of multiple alert touching at least 4 unique tactics in a 24h time Window.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Alerts in Different ATT&CK Tactics by Host (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Multiple Elastic Defend Alerts by Agent (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[HeroGamers]

Isn't this quite similar to Multiple Alerts in Different ATT&CK Tactics on a Single Host?

Although I would say this logic is better, since the other rule logic could be triggered by a single alert having 3 different ATT&CK tactics.

Wouldn't it make sense to deprecate the other detection rule?

[Samirbous]

@HeroGamers

Wouldn't it make sense to deprecate the other detection rule?

I would say they are slightly different, the new one should be less noisier as it has more restrictive conditions to reduce FPs (higher risk score of the alerts, less than 500 alert per rule to reduce the impact of the noisy ones and at least 5 unique rules):

Multiple Alerts in Different ATT&CK Tactics on a Single Host:
[rule.threshold]
field = ["host.id", "host.name"]
value = 1
[[rule.threshold.cardinality]]
field = "kibana.alert.rule.threat.tactic.id"
value = 3


Alerts in Different ATT&CK Tactics by Host:
| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50

Instead of deprecating you can just disable it. Maybe after sometime if we judge the new one is good in term of perf and FP rate we can deprecate the new term one.

[HeroGamers]

@Samirbous

Instead of deprecating you can just disable it. Maybe after sometime if we judge the new one is good in term of perf and FP rate we can deprecate the new term one.

True, however - I would even argue that the logic of the old one isn't correct as it stands right now, as it doesn't require "Multiple Alerts", but a single alert with 3 tactics could also trigger the detection. So, it would likely have to be rewritten to ES|QL to add another cardinality threshold for the amount of unique alert rule names.

[Samirbous]

@HeroGamers

it doesn't require "Multiple Alerts", but a single alert with 3 tactics could also trigger the detection.

good catch, we will push a tuning for the threshold rule.