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

STIX Shifter sometimes Silently Ignores Unmapped Properties in Complex Querie #1716

Open
Eliott-fujitsu opened this issue Jul 29, 2024 · 6 comments
Assignees

Comments

@Eliott-fujitsu
Copy link

Describe the bug
When a STIX pattern contains a mix of mappable and unmappable properties, STIX Shifter translates and executes the query without raising an error, even though parts of the query will have no effect due to the missing mappings. This can lead to incomplete or inaccurate results.

To Reproduce

  • Use a STIX Shifter module (e.g., Elastic ECS) that lacks a mapping for a specific STIX property (e.g.,windows-event-log:event_id).
  • Execute a translation with a query that includes both mappable and unmappable properties. For example:
    stix-shifter translate elastic_ecs query {} "[windows-event-log:event_id = '4726'] AND [user-account:account_login = 'admin']" "{"validate_pattern":"true","time_range":1000}"

Expected behavior
STIX Shifter should:
Throw an error: Clearly indicate that a portion of the query cannot be mapped to the target data source just as it does when trying to translate with a query that is only using the unmmap properties.
List unmapped properties: Ideally, the error message should specify which STIX objects and properties could not be mapped.

Desktop (please complete the following information):

  • OS: Ubuntu 22.04.3 LTS
  • STIX Shifter version: 7.0.11

Actual behavior

  • STIX Shifter silently ignores the unmappable part of the query ([windows-event-log:event_id = '4726'] in the example) and returns a translated query that only includes the mappable part. No error or warning is provided to the user.
  • 2024-07-29 13:39:21,845 stix_shifter_modules.elastic_ecs.stix_translation.query_translator
    INFO Converting STIX2 Pattern to data source query
    {
    "queries": [
    "(user.name : "administrator" OR user.name : "admin") AND (@timestamp:["2024-07-28T18:59:21.845Z" TO "2024-07-29T11:39:21.845Z"])"
    ]
    }

Impact
Incomplete Results: Users might unknowingly retrieve incomplete data, as the unmapped filter criteria are not applied.
Difficult Debugging: The lack of error messages makes it challenging to identify and troubleshoot mapping issues, potentially leading to wasted time and effort.

Additional context
This behavior makes it difficult for users to trust the completeness and accuracy of translated queries. Enhanced error reporting and handling of unmapped properties are crucial for improving the reliability and usability of STIX Shifter.

@pcoccoli
Copy link
Contributor

In case anyone finds it useful, I think x-oca-event:code is mapped to ECS event.code which should be the Windows EventID.

@DerekRushton
Copy link
Collaborator

Hi, I am wondering if you are using the "unmapped_fallback" option that most stix_shifter modules should have support for.

Should look something like

"{\"host\":\"example.com\",\"options\":{\"unmapped_fallback\":true}}"

This sounds like what you are looking for. Can you give that a shot a let me know if that helps?

@Eliott-fujitsu
Copy link
Author

Thank you for your response. I'm sorry I forgot to tell that I already tried it. When running this command I still get the same result with no error message or any indicator that a part of the query was unmapped :
stix-shifter translate elastic_ecs query {} "[windows-event-log:event_id = '4726'] AND [user-account:account_login = 'admin' OR user-account:account_login = 'administrator']" "{\"validate_pattern\":\"true\",\"time_range\":1000,\"unmapped_fallback\":true}"

@DerekRushton DerekRushton self-assigned this Jul 30, 2024
@DerekRushton
Copy link
Collaborator

Ah, yea I see the issue. This seems like a valid issue. Right now the code is already compiling the invalid mappings, but it only outputs it if there is no valid query.

There is an easy solution to this to simply expand the error handling to always display the unmapped fields/operators. However a more correct solution would likely be to validate the mappings and fail the request if an unmappable operator/field is provided. At the moment I have other priorities, but if I get a chance I (or someone else) can take a look into implementing it.

@Eliott-fujitsu
Copy link
Author

Thanks for acknowledging the issue.
I agree that validating mappings and failing the request when unmappable fields is given would be ideal.
I understand that you have other priorities, so no rush. Any quick fixes or workarounds in the meantime would be appreciated.
Thank you!

@DerekRushton
Copy link
Collaborator

For the time being I have introduced a warning message that should now appear when there are unmapped fields in the query.

It's not a perfect solution as it doesn't validate the whole query (just the mapping and operators) but it should work. I've left it as a warning instead of throwing the exception as some users may be used to the way it was working. However the warning message does tell you which mappings were invalid and were being ignored.

You can see the PR here
#1729

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants