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.

Sign up for GitHub

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

[Security_solution][Detections] Refactor signal ancestry to allow multiple parents #76531

Merged
merged 12 commits into from
Sep 9, 2020
Merged

[Security_solution][Detections] Refactor signal ancestry to allow multiple parents #76531

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
39a5f49
Refactors signal ancestry to allow multiple parents
marshallmain Sep 2, 2020
de9debb
Fix depth calculation for 7.10+ signals on pre-7.10 signals
marshallmain Sep 2, 2020
a3e1559
Comment build_signal functions
marshallmain Sep 2, 2020
d818f21
Merge branch 'master' into refactor-ancestry
elasticmachine Sep 2, 2020
2c9d038
Rename buildAncestorsSignal to buildAncestors
marshallmain Sep 3, 2020
93094ab
Update detection engine depth test scripts and docs
marshallmain Sep 4, 2020
08a2a4d
Update halting test readme
marshallmain Sep 4, 2020
9143432
Match up rule ids in readme
marshallmain Sep 4, 2020
f3b294e
Continue populating signal.parent along with signal.parents
marshallmain Sep 4, 2020
166f491
Merge branch 'master' into refactor-ancestry
elasticmachine Sep 4, 2020
0a8caa5
pr comments
marshallmain Sep 8, 2020
203c363
Merge branch 'master' into refactor-ancestry
elasticmachine Sep 8, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions ...k/plugins/security_solution/server/lib/detection_engine/routes/index/signals_mapping.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,11 +22,33 @@
}
}
},
"parents": {
"properties": {
"rule": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the rule.id, not rule.rule_id right? Curious if there's any upside to using one over the other. Like if users often import/export rules, would we lose tracing by using the id?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is rule.id. I think for the parents/ancestry we want to know which specific instance of a rule generated the alert so id is a good choice.

We could consider making signal.parent.rule an object where we could have id, rule_id, and any other rule fields that could be useful in signal.parent.rule.*, but that would be a breaking change with the existing signal.parent and signal.ancestors so I think we'd need a migration.

"type": "keyword"
},
"index": {
"type": "keyword"
},
"id": {
"type": "keyword"
},
"type": {
"type": "keyword"
},
"depth": {
"type": "long"
}
}
},
"ancestors": {
"properties": {
"rule": {
"type": "keyword"
},
"index": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

index was in parent but not here

"type": "keyword"
},
"id": {
"type": "keyword"
},
Expand Down Expand Up @@ -299,6 +321,9 @@
},
"threshold_count": {
"type": "float"
},
"depth": {
"type": "integer"
}
}
}
Expand Down
Loading