# Elastic detections and case sensitivity

**URL:** <https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788>\
**Category:** Elastic Security\
**Created:** [November 26, 2020, 2:53pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788 "2020-11-26T14:53:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![probson](https://avatars.discourse-cdn.com/v4/letter/p/e47c2d/32.png) [@probson](https://discuss.elastic.co/u/probson)\
**Post date:** [November 26, 2020, 2:53pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/1 "2020-11-26T14:53:33Z")

</div>

We use logstash to lowercase most fields used in detections. I was hoping the new wildcard field type would get around the issue of case-insensitivity in the detections rules (not including EQL)

Any recommendations or ideas? I was considering flipping the index fields so that the main field is text and multi-field is keyword.

---

<div class="post-metadata">

**Author:** ![rw-access](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rw-access/32/47998_2.png) [@rw-access](https://discuss.elastic.co/u/rw-access)\
**Post date:** [December 1, 2020, 4:13pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/2 "2020-12-01T16:13:31Z")

</div>

Hey @probson,

You don't have to use the new wildcard field type for case-insensitive queries. You can perform case-insensitive checks at search time using query DSL or EQL.

If you use EQL to write detections, you can make your logic case-insensitive by using the colon `:`. For example `process.name : "cmd.exe"` is the case-insensitive version of `process.name == "cmd.exe"`.

---

<div class="post-metadata">

**Author:** ![probson](https://avatars.discourse-cdn.com/v4/letter/p/e47c2d/32.png) [@probson](https://discuss.elastic.co/u/probson)\
**Post date:** [December 1, 2020, 4:28pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/3 "2020-12-01T16:28:37Z")

</div>

Hi @rw-access

EQL has been good for us, it was more the elastic built detections that use KQL.

Thanks  
Phil

---

<div class="post-metadata">

**Author:** ![rw-access](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rw-access/32/47998_2.png) [@rw-access](https://discuss.elastic.co/u/rw-access)\
**Post date:** [December 1, 2020, 5:04pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/4 "2020-12-01T17:04:25Z")

</div>

I like the way you think! We've actually been updating a lot of them in 7.11 to use EQL specifically for case-insensitivity. Hopefully we remove all case-sensitivity evasions as part of the effort.

If you'd like, you can follow along in GitHub with the tag: [`kql-to-eql`](https://github.com/elastic/detection-rules/issues?q=is%3Aopen+is%3Aissue+label%3Akql-to-eql)

---

<div class="post-metadata">

**Author:** ![probson](https://avatars.discourse-cdn.com/v4/letter/p/e47c2d/32.png) [@probson](https://discuss.elastic.co/u/probson)\
**Post date:** [December 1, 2020, 8:31pm UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/5 "2020-12-01T20:31:10Z")

</div>

@rw-access

Thats great, so moving away from KQL, i had only looked at it as a sequence based rather than single hits.

---

<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:** [November 4, 2022, 8:18am UTC](https://discuss.elastic.co/t/elastic-detections-and-case-sensitivity/256788/6 "2022-11-04T08:18:29Z")

</div>