[FN Tuning] Shared Object Created or Changed by Previously Unknown Pr…

[Aegrah]

Summary

Updating this rule to detect more paths that store shared objects + adding coverage for shared objects that leverage the .so.$int naming format such as so.2, as this was currently not detected.

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

⛔️ Tests failed:

[terrancedejesus]

Can we see if the SSM agent is created the SO because it's running a custom document? If so, this would be very suspicious IMO. AWS-managed SSM docs may do things on Linux systems as a requirement for managing these nodes, however, custom SSM docs can be abused to run whatever on that EC2 instance.

[Aegrah]

In this case we just have the file creation event, so all I have is a process name and file path. The file path for this FP pattern is: /usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/{file}.so.

As the pattern is easy to exclude based on process/path, I added the following exclusion (process.name:"ssm-agent-worker" and file.path:/usr/lib/jvm/java*) rather than just on process.name. Thanks for the review @terrancedejesus !

[DefSecSentinel]

LGTM

[tradebot-elastic]

⛔️ Tests failed:

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Tests failed:

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Tests failed:

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[eric-forte-elastic]

🟢 Manual review, looks good to me! 👍

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Shared Object Created or Changed by Previously Unknown Process (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta