[Tuning] Unusual Network Connection to Suspicious Web Service

[Samirbous]

excluded browsers and Dropbox/Discord expected binaries connecting to the respective domains.

https://elasticstack.slack.com/archives/C016E72DWDS/p1756174192691379

kibana.alert.rule.name :"Unusual Network Connection to Suspicious Web Service" and not (destination.domain :(*.sharepoint.com or *.azurewebsites.net or "onedrive.live.com" or *.b-cdn.net or api.onedrive.com or "drive.google.com" or *.blogspot.com) and process.code_signature.subject_name:(*Microsoft* or "Software Signing" or "Apple Mac OS Application Signing" or *VMware*) and process.code_signature.trusted:true) and not (process.code_signature.subject_name:(*Mozilla* or *Google* or *Brave* or *Opera* or "Software Signing" or *Zscaler* or *Browser*) and process.code_signature.trusted:true)  and not (destination.domain :("discord.com" or cdn.discordapp.com or "content.dropboxapi.com" or "dl.dropboxusercontent.com") and process.code_signature.subject_name :(*Discord* or *Dropbox*) and process.code_signature.trusted:true)

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Unusual Network Connection to Suspicious Web Service (kuery)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

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