-
|
We are adding new plays to playbook. When we use the sigma "fieldname|re:" function it properly add the regex and doesn't escape special characters, but it uses the fieldname.keyword instead of fieldname.security. This is causing the plays to not match data as expected. I'm trying to figure out if this is a case sensitivity issue or something else, but if the regex conversion could use the .security instead of the .keyword subfield that would be helpful. |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 2 replies
-
|
What is the use case for using regex? Regex should be utilized rather sparingly, as it can cause major performance issues. |
Beta Was this translation helpful? Give feedback.
-
|
Should it work or shouldn't it? Specifically I'm trying to match a Linux
command line switch. Since there can be characters between the dash and
the option I need to match characters and not spaces or other symbols.
Therefore a wildcard is insufficient.
Bill
…On Fri, Jul 15, 2022, 16:24 Josh Brower ***@***.***> wrote:
What is the use case for using regex? Regex should be utilized rather
sparingly, as it can cause major performance issues.
—
Reply to this email directly, view it on GitHub
<#8283 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AY5BU7YEGFI2N3MGVV4C6RTVUHCHBANCNFSM53NCM2CQ>
.
You are receiving this because you authored the thread.Message ID:
<Security-Onion-Solutions/securityonion/repo-discussions/8283/comments/3159365
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
It should work. Can you share a (sanitized as needed) rule that does not work the way you are expecting? |
Beta Was this translation helpful? Give feedback.
-
|
I was trying to match something simple on the command line field and it
would match with both the base and .security but not .keyword. sending via
email so may need a code block to display.
process.command_line: /.*dir.*/
…On Fri, Jul 22, 2022, 13:12 Josh Brower ***@***.***> wrote:
It should work. Can you share a (sanitized as needed) rule that does not
work the way you are expecting?
—
Reply to this email directly, view it on GitHub
<#8283 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AY5BU7YVD7D2HDSZZLLH3ETVVLJAHANCNFSM53NCM2CQ>
.
You are receiving this because you authored the thread.Message ID:
<Security-Onion-Solutions/securityonion/repo-discussions/8283/comments/3207966
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
We are getting that field from endgame streaming and now I'm wondering if
it actually exists. I'll check that on Monday and close out the issue if
it's a missing field.
Bill
…On Fri, Jul 22, 2022, 14:20 Bill D ***@***.***> wrote:
I was trying to match something simple on the command line field and it
would match with both the base and .security but not .keyword. sending via
email so may need a code block to display.
process.command_line: /.*dir.*/
On Fri, Jul 22, 2022, 13:12 Josh Brower ***@***.***> wrote:
> It should work. Can you share a (sanitized as needed) rule that does not
> work the way you are expecting?
>
> —
> Reply to this email directly, view it on GitHub
> <#8283 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AY5BU7YVD7D2HDSZZLLH3ETVVLJAHANCNFSM53NCM2CQ>
> .
> You are receiving this because you authored the thread.Message ID:
> <Security-Onion-Solutions/securityonion/repo-discussions/8283/comments/3207966
> @github.com>
>
|
Beta Was this translation helpful? Give feedback.
-
|
The ECS compliant field from Endgame registry.path doesn't have a .keyword subfield with our setup. The Endgame specific field endgame.registry_path does. We have used the .keyword subfield before for regex so I just didn't think through this issue sufficiently. We can switch to the endgame field as a work around until we can look into why the subfield isn't there. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good! |
Beta Was this translation helpful? Give feedback.
The ECS compliant field from Endgame registry.path doesn't have a .keyword subfield with our setup. The Endgame specific field endgame.registry_path does. We have used the .keyword subfield before for regex so I just didn't think through this issue sufficiently. We can switch to the endgame field as a work around until we can look into why the subfield isn't there.