Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Importing a Sigma rule with count() aggregation returns an error #861

Closed
xeniatup opened this issue Jan 31, 2024 · 6 comments
Closed
Labels
bug Something isn't working

Comments

@xeniatup
Copy link

xeniatup commented Jan 31, 2024

What is the bug?
Importing a rule with aggregation throws an error.

Screenshot 2024-01-30 at 2 46 16 PM It looks like `count()` is not supported, and OpenSearch requires `count(*)`, which is not consistent with Sigma syntax.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Go to 'http://localhost:5601/app/opensearch_security_analytics_dashboards#/import-rule'
  2. Click on 'Create rule'
  3. Switch to YAML editor
  4. Paste the rule
  5. Select "Create detection rule"
  6. See error

What is the expected behavior?
Ideally OpenSearch should convert Sigma into a valid detection rule behind the scenes when the difference in syntax is known.

@xeniatup xeniatup added bug Something isn't working untriaged labels Jan 31, 2024
@amsiglan amsiglan transferred this issue from opensearch-project/security-analytics-dashboards-plugin Feb 17, 2024
@amsiglan
Copy link
Collaborator

@sbcd90 Feel free to close this if it's a duplicate

riysaxen-amzn pushed a commit to riysaxen-amzn/security-analytics that referenced this issue Mar 25, 2024
* Notification security fix (opensearch-project#852)

* added injecting whole user object in threadContext before calling notification APIs so that backend roles are available to notification plugin

Signed-off-by: Petar Dzepina <[email protected]>

* compile fix

Signed-off-by: Petar Dzepina <[email protected]>

* refactored user_info injection to use InjectSecurity

Signed-off-by: Petar Dzepina <[email protected]>

* ktlint fix

Signed-off-by: Petar Dzepina <[email protected]>

---------

Signed-off-by: Petar Dzepina <[email protected]>
(cherry picked from commit e0b7a5a7905b977e58d80e3b9134b14893d122b0)

* remove unneeded import

Signed-off-by: Ashish Agrawal <[email protected]>

---------

Signed-off-by: Ashish Agrawal <[email protected]>
Co-authored-by: Petar Dzepina <[email protected]>
Co-authored-by: Ashish Agrawal <[email protected]>
@engechas
Copy link
Collaborator

engechas commented Apr 9, 2024

Potentially related to the issue that was fixed by #789

@sbcd90 can you confirm this is the same issue?

@givilleneuve
Copy link

Hi everyone, not sure if anyone run into this issue. but when using the clause similar to this one, count(), it still fails on version 2.13. Unless I count by a field. For example, count(source.ip) > 6.

@sbcd90
Copy link
Collaborator

sbcd90 commented May 14, 2024

hi @givilleneuve , please use count(*)

@givilleneuve
Copy link

Thank you @sbcd90 , I was able to create it. I will perform a few more tests. Thank you,

@givilleneuve
Copy link

@sbcd90, not sure if you have this answer on top of the head, but using the count and timeframe, would it be based on the detector detection or the timeframe set on the sigma?

For example, for brute force detection: condition: selection1 and selection2 | count (*) by source.ip > 3
selection2:
event.outcome:
- failure
selection1:
event.type|all:
- authentication_failure
timeframe:

  • 3m
    Would it look for the events and count in the past 3m or will it rely on the detector that contains this rule?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants