[Rule Tuning] Linux DR Tuning - 2

[Aegrah]

Pull Request Summary

Why

This PR expands detection coverage, improves rule accuracy, and adds support for new data sources (notably SentinelOne Cloud Funnel and Auditd Manager) in several Linux security detection rules.

---

What changed

General

• Integration/Data Source Expansion

  • Added sentinel_one_cloud_funnel and auditd_manager integrations to multiple rules.
  • Expanded index patterns to include:
    • logs-sentinel_one_cloud_funnel.*
    • logs-auditd_manager.auditd-*
    • endgame-*
    • logs-endpoint.events.process*
    • logs-endpoint.events.file*
    • logs-crowdstrike.fdr*
    • auditbeat-*

• Rule Logic and Field Adjustments

  • Changed new terms detection fields (e.g., from process.group_leader.executable to process.parent.executable, from user.name to host.id or agent.id).
  • Adjusted history window durations for new terms detection (e.g., from now-10d to now-3d, now-7d to now-5d).
  • Broadened event action coverage in queries (e.g., added "start" and "ProcessRollup2").
  • Modified parent process and argument checks to reduce false positives and improve detection (e.g., more exclusions, more permissive parent process matching).
  • Increased EQL sequence maxspan from 1s to 3s in the cat network activity rule.
  • Added/modified exclusions for certain parent processes and arguments.

• Severity and Risk Score

  • Raised severity from "low" to "medium" and risk score from 21 to 47 in the curl SOCKS proxy rule.

• Rule Descriptions and Formatting

  • Improved rule descriptions for clarity and consistency.
  • Minor formatting and whitespace changes for readability.

---

Behavioral impact

• Rules will now trigger on a broader set of data sources and event types, increasing detection coverage.
• Some rules may alert on new or different fields (e.g., agent.id instead of host.id).
• Adjusted parent process and argument checks may reduce false positives or catch more sophisticated attack patterns.
• Increased severity/risk score for certain detections may affect alert prioritization.

---

Risks/edge cases

• Expanding index patterns and integrations could introduce noise if new data sources are not properly filtered or normalized.
• Changing new terms fields and history windows may affect alert frequency and baseline calculations.
• More permissive parent process checks (e.g., process.parent.name like ".*") could increase false positives if not carefully monitored.
• If new log sources are not present in all environments, some rules may not function as intended.

---

Rollout notes

• Ensure new data sources are ingested and mapped correctly before enabling updated rules.
• Monitor for increased alert volume or false positives after deployment.
• Communicate changes in detection logic and severity to SOC analysts.
• Consider phased rollout or additional tuning if noise increases.

---

Notable Rule-Specific Changes

• collection_linux_clipboard_activity.toml

  • Added SentinelOne Cloud Funnel integration and index.
  • Changed detection logic to use process.parent instead of process.group_leader.
  • New terms now use agent.id and process.parent.executable.
  • History window shortened from 7d to 5d.

• command_and_control_aws_cli_endpoint_url_used.toml

  • Added Auditd Manager and SentinelOne Cloud Funnel integrations and indexes.
  • Broadened event action coverage.
  • New terms now use host.id instead of user.name.
  • History window shortened from 10d to 3d.

• command_and_control_cat_network_activity.toml

  • Increased EQL sequence maxspan from 1s to 3s.
  • Minor formatting and whitespace changes.

• command_and_control_curl_socks_proxy_detected.toml

  • Severity increased from "low" to "medium"; risk score from 21 to 47.
  • Broadened parent process and argument checks.
  • Added/modified exclusions to reduce false positives.

• command_and_control_git_repo_or_file_download_to_sus_dir.toml

  • Expanded index to include logs-endpoint.events.file*.
  • Added exclusions for certain parent processes and arguments.

[github-actions]

Rule: Tuning - Guidelines

These guidelines serve as a reminder set of considerations when tuning an existing rule.

Documentation and Context

• Detailed description of the suggested changes.
• Provide example JSON data or screenshots.
• Provide evidence of reducing benign events mistakenly identified as threats (False Positives).
• Provide evidence of enhancing detection of true threats that were previously missed (False Negatives).
• Provide evidence of optimizing resource consumption and execution time of detection rules (Performance).
• Provide evidence of specific environment factors influencing customized rule tuning (Contextual Tuning).
• Provide evidence of improvements made by modifying sensitivity by changing alert triggering thresholds (Threshold Adjustments).
• Provide evidence of refining rules to better detect deviations from typical behavior (Behavioral Tuning).
• Provide evidence of improvements of adjusting rules based on time-based patterns (Temporal Tuning).
• Provide reasoning of adjusting priority or severity levels of alerts (Severity Tuning).
• Provide evidence of improving quality integrity of our data used by detection rules (Data Quality).
• Ensure the tuning includes necessary updates to the release documentation and versioning.

Rule Metadata Checks

• updated_date matches the date of tuning PR 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. Review to ensure the original intent of the rule is maintained.

Testing and Validation

• Validate that the tuned rule's performance is satisfactory and does not negatively impact the stack.
• Ensure that the tuned rule has a low false positive rate.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Protocol Tunneling via Chisel Client (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ ProxyChains Activity (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ IPv4/IPv6 Forwarding Activity (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Suspicious Utility Launched via ProxyChains (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Potential Linux Tunneling and/or Port Forwarding (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Potential Protocol Tunneling via EarthWorm (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Deprecated - Potential Protocol Tunneling via Chisel Server (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Linux Telegram API Request (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta
• ❌ Potential Linux Tunneling and/or Port Forwarding via SSH Option (eql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[Samirbous]

is this just a format change ?

[eric-forte-elastic]

For "/usr/bin/dockerd-rootless.sh", from the docker docs (from Docker, and from VMware) it looks like this can also be invoked at setup not just in the ExecStart in the Docker service definition.

[Aegrah]

I don't understand the comment exactly; what would you like me to resolve here?

[eric-forte-elastic]

Looks good, minor comment, but not a blocker.

Happy to approve when https://github.com/elastic/detection-rules/pull/5481/changes#r2626499614 is resolved 👍