# How to handle network.direction:unknown?

**URL:** <https://discuss.elastic.co/t/how-to-handle-network-direction-unknown/226143>\
**Category:** SIEM\
**Created:** [April 2, 2020, 12:15am UTC](https://discuss.elastic.co/t/how-to-handle-network-direction-unknown/226143 "2020-04-02T00:15:43Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Frank\_Hassanabad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/frank_hassanabad/32/49255_2.png) [@Frank\_Hassanabad](https://discuss.elastic.co/u/Frank_Hassanabad)\
**Post date:** [April 4, 2020, 4:29pm UTC](https://discuss.elastic.co/t/how-to-handle-network-direction-unknown/226143/3 "2020-04-04T16:29:14Z")

</div>

This conversation might be useful:

> [@SIEM detections false positive](https://discuss.elastic.co/t/siem-detections-false-positive/219287/5):
>
> 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 t…

---

_[View the full topic](https://discuss.elastic.co/t/how-to-handle-network-direction-unknown/226143)._