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

[Filebeat][Okta] Parse invalid risk kv data sent by Okta and add keyword fields from flattened field #33677

Closed
ynirk opened this issue Nov 15, 2022 · 3 comments · Fixed by #34030 or #34508
Labels
needs_team Indicates that the issue/PR needs a Team:* label

Comments

@ynirk
Copy link

ynirk commented Nov 15, 2022

Describe the enhancement:

This request is a follow-up of #30961

  1. debugContext.debugData.risk data sent by Okta is not valid kv

When Okta send the risk information directly in debugContext.debugData structure (not using logOnlySecurityData field) the risk field is not a proper kv and breaks the ingest pipeline.

Example of data value: "{reasons=Anomalous Device, Anomalous Location, level=MEDIUM}" reasons have several comma separated values and breaks the KV processor.

It would be better to parse as "{reasons=*, level=*}" or at least ignore the kv processor failure ?

  1. revisit okta: add extended okta.debug_context.debug_data handling integrations#3362 (comment)

As the pipeline will likely be updated it would be nice to include the proposal made in elastic/integrations#3362 (comment)

  1. Parse behaviors as keyword fields

Okta provides interesting data as part of the debug_data. Similarly as okta.debug_context.debug_data. risk_level it would be nice to have the risk.reasons and behaviors parsed as keywords.

Describe a specific use case for the enhancement or feature:

The information is used by security analyst to create detection on anomalous login. The detection could be more specific or filtered based on the new keywords fields

@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Nov 15, 2022
@botelastic
Copy link

botelastic bot commented Nov 15, 2022

This issue doesn't have a Team:<team> label.

@ynirk
Copy link
Author

ynirk commented Dec 16, 2022

@efd6 Thank you for the quick fix.
The PR only covers point 1 (and not the 2 others) Do you prefer re-opening this or creating a separate issue ?

@efd6
Copy link
Contributor

efd6 commented Dec 18, 2022

Reopening for 2. and 3. as enhancements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs_team Indicates that the issue/PR needs a Team:* label
Projects
None yet
2 participants