[Security Solution] Populates threat.indicator.event with _source.event (#951)#95697
[Security Solution] Populates threat.indicator.event with _source.event (#951)#95697ecezalp merged 3 commits intoelastic:masterfrom
Conversation
ecezalp
added
release_note:feature
ecezalp
added
v7.13.0
Team: SecuritySolution
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
rylnd
left a comment
rylnd
left a comment
There was a problem hiding this comment.
This looks great, just a small change to the mappings and this should be good to go.
It would be great if you could add/update an integration test to account for this new behavior, as well.
| ...ecsMapping.mappings.properties.threat, | ||
| properties: { | ||
| ...ecsMapping.mappings.properties.threat.properties, | ||
| ...indicatorMapping, |
There was a problem hiding this comment.
I don't think this is correct; we want these to be part of the nested threat.indicator objects, e.g. threat.indicator[].event.*, and this looks to generate threat.event.* mappings.
There was a problem hiding this comment.
hey thanks for the catch
| } | ||
| const atomic = get(matchedThreat?._source, query.value) as unknown; | ||
| const type = get(indicator, 'type') as unknown; | ||
| const event = get(matchedThreat?._source, 'event') as unknown; |
There was a problem hiding this comment.
👍 this logic is correct, it's just the mappings that are off.
|
latest changes
|
rylnd
left a comment
rylnd
left a comment
There was a problem hiding this comment.
Looks great! Glad we have those integration and cypress tests for coverage here, and appreciate the added unit tests as well 👍
|
|
||
| import signalsMapping from './signals_mapping.json'; | ||
| import ecsMapping from './ecs_mapping.json'; | ||
| import indicatorMapping from './indicator_mapping.json'; |
There was a problem hiding this comment.
Since this file is just currently "ECS event mappings," what do you think about using ecsMapping.mappings.properties.event instead of this new file? I expect we'll want these indicator mappings to be in sync with the latest from ECS, so that might be the best way to accomplish this.
| expect(get(indicator, 'matched.atomic')).toEqual('domain_1'); | ||
| }); | ||
|
|
||
| it('returns event values as a part of threat', () => { |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @ecezalp |
…nt (elastic#951) (elastic#95697) * [Security Solution] Add event data to threat.indicator (elastic/security_team/elastic#951) * fixes mappings, updates tests * refactor mappings
4 participants
Summary
This change copies all
eventdetails from the source event to the alert underthreat.indicator.event.Closes elastic/security-team#951.
Relates to elastic/security-team#946.
Images
Notes
I am not entirely sure if the changes to
x-pack/plugins/security_solution/server/lib/detection_engine/routes/index/indicator_mapping.jsonandx-pack/plugins/security_solution/server/lib/detection_engine/routes/index/get_signals_template.tswere necessary, please let me know if they should be reverted to their original state.Checklist
Delete any items that are not applicable to this PR.