elastic / detection-rules

https://www.elastic.co/guide/en/security/current/detection-engine-overview.html
Other
1.92k stars 493 forks source link

[Rule Tuning] Threat Intel Indicator Match #2684

Closed MakoWish closed 3 months ago

MakoWish commented 1 year ago

Link to rule

threat_intel_fleet_integrations.toml

Description

This rule gives tens of thousands of false-positives per day due to the typical internet scans that happen from known-malicious (or known questionable) IP addresses. A large portion of these detections in our environment are from firewall "deny" events from our logs-cisco_ftd* Data Streams.

Example Data

I am open to some discussion on this, but I am thinking at least a start would be to add an exception in the query for Cisco Message ID 710003 (event.code: 710003).

... and not event.code: "710003"

710003 - Access denied by ACL

Some other tips on helping to reduce the noise on this one would be incredibly helpful. As it is right now, I am about to turn the rule off, because the vast majority of alerts are just port scans that our firewalls are blocking anyway, but I am having a hard time finding exceptions to add to cut these down.

Current sources of data for the alerts we are receiving (in order of number of alerts): logs-cisco_ftd* logs-netflow* logs-cisco_asa* logs-network_traffic* logs-suricata*

Eric

botelastic[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

w0rk3r commented 1 year ago

@MakoWish I'll leave this open by now, I plan to revisit the threat match rules as a continuation of #2777, it would be awesome to hop on Slack to chat about them (If you want to) ;)

MakoWish commented 1 year ago

@w0rk3r ,

Perfectly fine with leaving this open. I closed it, because it turns out our Networking team has a pretty bad misconfiguration that is creating "TCP connection built" events for every single packet that hits our firewall. Unwanted events are blocked later, but at least from the firewall side, it looks like they are 100% successful connections. There may be some other ways to help clean up this rule, but I believe 99.999999999% of our false positives are from this misconfiguration.

MakoWish commented 1 year ago

Oh, and Slack username is the same as on GH.

w0rk3r commented 1 year ago

Hey @MakoWish, I tried to find your user on Slack but hadn't succeeded. Can you ping me? @Jonhnathan

w0rk3r commented 3 months ago

Closing this one as it has been stale for a year, and the main issue seems to be related to a misconfiguration