# SIEM detections false positive

**URL:** <https://discuss.elastic.co/t/siem-detections-false-positive/219287>\
**Category:** SIEM\
**Created:** [February 13, 2020, 10:04pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287 "2020-02-13T22:04:58Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![danielsnelling](https://avatars.discourse-cdn.com/v4/letter/d/76d3ee/32.png) [@danielsnelling](https://discuss.elastic.co/u/danielsnelling)\
**Post date:** [February 13, 2020, 10:04pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/1 "2020-02-13T22:04:59Z")

</div>

We've upgraded our stack to 7.6.0 yesterday, and we love the new Detections mechanism!

I'm aware these are in beta, but some of the definitions have a boolean 'or' where there should be an 'and'.

This is particularly where the rule is ' from/to the Internet'.

eg. SMB Activity to the Internet definition is 'network.transport: tcp and destination.port: (139 or 445) and ( network.direction: outbound **or** ( source.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and not destination.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) ) )'

This will result in detections for '10.0.0.1 to 10.0.0.2:445' when it shouldn't.  
I've highlighted the 'or' that should be changed to 'and'

---

<div class="post-metadata">

**Author:** ![Nathan\_Reese](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nathan_reese/32/84829_2.png) [@Nathan\_Reese](https://discuss.elastic.co/u/Nathan_Reese)\
**Post date:** [February 14, 2020, 1:14pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/2 "2020-02-14T13:14:40Z")

</div>

@ danielsnelling I am changing the category from Kibana to SIEM so the SIEM team can pick up your question.

---

<div class="post-metadata">

**Author:** ![randomuserid](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@randomuserid](https://discuss.elastic.co/u/randomuserid)\
**Post date:** [February 14, 2020, 1:36pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/3 "2020-02-14T13:36:03Z")

</div>

Glad to hear you are liking the detection engine. This is a known issue with use of the network.direction field that is fixed in 7.61. The workaround is to duplicate the rule and remove the network.direction test. This issue is also discussed here:

> <https://github.com/elastic/kibana/issues/57447>
>
> Kibana version: 7.6.0
> Describe the bug:
> Detection rule: "SSH (Secure Shell) from the Internet", contains wrong logical operator which causes the rule to...

---

<div class="post-metadata">

**Author:** ![danielsnelling](https://avatars.discourse-cdn.com/v4/letter/d/76d3ee/32.png) [@danielsnelling](https://discuss.elastic.co/u/danielsnelling)\
**Post date:** [February 15, 2020, 11:08am UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/4 "2020-02-15T11:08:58Z")

</div>

I've read through that bug, and the proposed fix.  
The fix seems to be wanting to completely ignore signals from sysmon (usually stored in winlogbeat-\*), and take the view that the signal only comes from a firewall log and not an endpoint.

The rule will work (from a monitored endpoint point of view) if the logic changes the 'or' to an 'and'.  
ie SMB Activity to the Internet:  
If the traffic is **tcp** and the destination port is 139/445, and the traffic is outbound and the destination ip isn't RFC1918, then Alert!

---

<div class="post-metadata">

**Author:** ![Craig\_Chamberlain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/craig_chamberlain/32/70079_2.png) [@Craig\_Chamberlain](https://discuss.elastic.co/u/Craig_Chamberlain)\
**Post date:** [March 2, 2020, 9:50pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/5 "2020-03-02T21:50:37Z")

</div>

Hi, yes, you can remove the network.direction test when using these on endpoint data. This field is more useful when it has been populated by a Suricata, Snort or Zeek network list. It is not a super reliable layer three context in endpoint pipelines because these typically have no network lists or maps. The rule needs more branching logic to confine evaluation of the network.direction field to appropriate event types.

Such a modified version of the search for endpoint events would look like this;

network.transport: tcp and destination.port: (139 or 445) and source.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and not destination.ip: (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 25, 2020, 4:07pm UTC](https://discuss.elastic.co/t/siem-detections-false-positive/219287/7 "2020-04-25T16:07:14Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
