- Notifications
You must be signed in to change notification settings - Fork 497
darktrace: Handle nested defeat conditions in Darktrace models #15552
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
Conversation
💚 CLA has been signed |
Done |
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there darktrace documentation to back this up? It would be helpful to include that in the commit message for future maintenance.
...ages/darktrace/data_stream/model_breach_alert/_dev/test/pipeline/test-model-breach-alert.log Outdated Show resolved Hide resolved
description: The filter the defeat is made from. | ||
- name: id | ||
type: long | ||
type: keyword |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a breaking change. I agree that it should have been a keyword
when written, but do we need to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you on this point. However, at the moment, if the id is not numeric but a string, the message is incorrectly parsed and dropped with the following error:
Cannot index event * (status=400): {\"type\":\"illegal_argument_exception\",\"reason\":\"mapper [darktrace.model_breach_alert.model.defeats.defeatID] cannot be changed from type [long] to [keyword]\"}
As the initial value can be a string, how would you handle it without stepping into this breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was in conjunction with the comment here. If one changes they both change. Do we need to make this a keyword (and change the type of the convert processor? If it's the case that we will see non-numeric IDs, then the answer is yes. If that is the case this becomes a breaking change and the changelog would need to be updated to include that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the defeatID (and by extension the id field here) can take either numeric or string, I do not see another way that could accommodate bot 1
and "1-1"
values in a single definition so from my point of view yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replied before your last edit in the thread. Yes, this is needed as we ingest non numeric IDs.
I updated the changelog type to breaking-change
on_failure: | ||
- remove: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String conversion cannot fail, so the on_failure
is no longer needed, though see comment below about this being a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this processor. Thank you for the feedback
As you may know, Darktrace is a proprietary software, hence I cannot share a direct link to the documentation. However, I can share an excerpt of it for the specific field. I am interested in how you usually tackle cases like this one when the documentation is fenced but the implementation open source. For now, I will include the definition of the field from Darktrace documentation (also in the Commit message) :
An example result for the model schema:
|
/test |
Co-authored-by: Dan Kortschak <dan.kortschak@elastic.co>
/test |
Tests should be fixed by diff --git a/packages/darktrace/changelog.yml b/packages/darktrace/changelog.yml index 352ff55219..af681bc3ad 100644 --- a/packages/darktrace/changelog.yml +++ b/packages/darktrace/changelog.yml @@ -4,7 +4,7 @@ - description: Fix model defeat handling when nested conditions exist and so defeat ID can be non-numeric. type: bugfix link: https://github.com/elastic/integrations/pull/15552 - - description: `darktrace.model_breach_alert.model.defeats.id` field type is changed from `long` to `keyword`. + - description: '`darktrace.model_breach_alert.model.defeats.id` field type is changed from `long` to `keyword`.' type: breaking-change link: https://github.com/elastic/integrations/pull/15552 - version: "1.23.0" diff --git a/packages/darktrace/manifest.yml b/packages/darktrace/manifest.yml index 290de70035..ab7dc8b2ff 100644 --- a/packages/darktrace/manifest.yml +++ b/packages/darktrace/manifest.yml @@ -1,7 +1,7 @@ format_version: "3.0.3" name: darktrace title: Darktrace -version: "1.23.1" +version: "2.0.0" description: Collect logs from Darktrace with Elastic Agent. type: integration categories: |
Changes pushed, thank you! |
/test |
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
History
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Package darktrace - 2.0.0 containing this change is available at https://epr.elastic.co/package/darktrace/2.0.0/ |
Proposed commit message
Darktrace model defeats are not 1 level only (List) as currently implemented. Latest API provides functionality for nested conditions. If not nested, the
defeatID
is an integer and the defeats list is a list of conditions. However, if nested, defeats list is a list of lists of conditions and defeatIDs can either be integers (e.g.1
) or strings (e.g.1-1, 1-2
etc.).Definition of the field from Darktrace documentation:
An example result for the model schema:
Title of PR is suggested as commit message.
This is labeled as bugfix as the incorrect parsing of defeatID leads to drop of any event that has a nested model defeat, leading to logs being lost.
Checklist
changelog.yml
file.Author's Checklist
How to test this PR locally
Related issues
Screenshots