-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[SecuritySolution][Threat Hunting] Fix a couple of field ids for highlighted fields #124941
Conversation
Pinging @elastic/security-solution (Team: SecuritySolution) |
@elasticmachine merge upstream |
@@ -101,7 +97,7 @@ function getFieldsByEventCode( | |||
switch (eventCode) { | |||
case EventCode.BEHAVIOR: | |||
return [ | |||
{ id: ALERT_RULE_DESCRIPTION, label: ALERTS_HEADERS_RULE_DESCRIPTION }, | |||
{ id: 'rule.description', label: ALERTS_HEADERS_RULE_DESCRIPTION }, |
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.
When viewing the same alert in a branch based off main
(before the change), the alert description appears in the flyout, because the alert is populated with kibana.alert.rule.description
, per the before
screenshot below:
before
When running this PR branch, the dns.question.name
now shows up as expected, but the rule description no longer appears, because the event does not contain rule.description
, per the after
screenshot below:
after
Is it possible that I'm missing a change in my local environment that would populate rule.description
?
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.
That is something that I was also struggling with to understand. From what @paulewing explained to me I understood that kibana.alert.rule.description
is not the same as rule.description
. I am not sure though, how it gets populated. Maybe Paul has some more insights into that.
}) as TimelineEventsDetailsItem[]), | ||
{ | ||
category: 'dns', | ||
field: 'dns.question.name', |
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.
Does it make sense to also display dns.question.type
in the flyout summary for parity with the DNS row renderer, shown in the screenshot below?
CC @paulewing
@elasticmachine merge upstream |
1ce760e
to
91700fa
Compare
💛 Build succeeded, but was flakyTest Failures
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @janmonschke |
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 for this fix @janmonschke!
LGTM 🚀
The following labels were identified as gaps in your version labels and will be added automatically:
If any of these should not be on your pull request, please manually remove them. |
…lighted fields (elastic#124941) * fix: use correct DNS field id * fix: for behavior alerts we should display rule.description (cherry picked from commit 8fabaf3)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
Summary
dns.question.name
instead ofdns.query.name
.kibana.alert.rule.description
we're supposed to showrule.description
for behavior alerts.This PR fixes these ids and adds test for all of them
Checklist