[Rule Tuning] GenAI or MCP Server Child Process Execution

[Mikaayenson]

Pull Request

Issue link(s): N/A

Summary - What I changed

Noise reduction by ~54%

How To Test

Over the last 30 days tested with these:

Exclusions

and not (
  (process.parent.name: (node or "node.exe") and process.name: (node or "node.exe")) or
  (process.parent.name: python* and process.name: python*) or
  (process.parent.name: (deno or "deno.exe") and process.name: (deno or "deno.exe")) or
  (process.parent.name: (bun or "bun.exe") and process.name: (bun or "bun.exe")) or
  (process.parent.name: Cursor and process.name: "Cursor Helper*") or
  (process.parent.name: Claude and process.name: "Claude Helper*") or
  (process.parent.name: Windsurf and process.name: "Windsurf Helper*") or
  (process.parent.name: Code and process.name: "Code Helper*") or
  (process.parent.name: Jan and process.name: "Jan Helper*") or
  (process.parent.name: "LM Studio" and process.name: "LM Studio Helper*") or
  (process.parent.name: Ollama and process.name: "Ollama Helper*") or
  (process.name: (docker or docker.exe) and process.args: context and process.args: ls) or
  process.args: (
    "ip neigh show" or
    "arp -a -n -l" or
    "ip neighbor show dev wlan0" or
    "ip neighbor show dev eth0" or
    "arp -a | findstr /C:---"
  ) or
  process.command_line: (
    "/bin/sh -c ip neigh show" or
    "/bin/sh -c arp -a -n -l" or
    "/bin/sh -c /bin/ps -ax -o pid=,ppid=,pcpu=,pmem=,command=" or
    "/bin/sh -c which ps"
  ) or
  (
    process.name: (git or git.exe) and (
      (process.args: remote and process.args: get-url and process.args: origin) or
      (process.args: symbolic-ref and process.args: "refs/remotes/origin/HEAD" and process.args: "--short") or
      (process.args: rev-parse and process.args: "--abbrev-ref" and process.args: HEAD) or
      (process.args: status and process.args: "-z" and process.args: "-uall") or
      (process.args: config and process.args: "--get" and process.args: "commit.template") or
      (process.args: config and process.args: "user.email") or
      (process.args: rev-parse and process.args: "--show-toplevel")
    )
  ) or
  process.args: ("--version" or "--help" or "-v" or "-h" or "-V" or version or help)
)

## Checklist

• Added a label for the type of pr: bug, enhancement, schema, maintenance, Rule: New, Rule: Deprecation, Rule: Tuning, Hunt: New, or Hunt: Tuning so guidelines can be generated
• Added the meta:rapid-merge label if planning to merge within 24 hours
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

[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.