[Security Solution][CTI] Event enrichment search strategy#101553
[Security Solution][CTI] Event enrichment search strategy#101553rylnd merged 7 commits intoelastic:masterfrom
Conversation
This is going to be a subtype of the general SecSol search strategy; the main functionality is going to be: * transformation of the incoming parameters into named equivalents * transformation of responses to include enrichment context fields (matched.*)
A few type errors because our functions don't actually do anything yet, nor are our request/response types fleshed out.
* Defines a basic request, along with a mock * Defines helper function to generate should clauses from field values * Adds placeholder tests throughout
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @rylnd |
| INDICATOR_LASTSEEN, | ||
| ]; | ||
|
|
||
| export const EVENT_ENRICHMENT_INDICATOR_FIELD_MAP = { |
There was a problem hiding this comment.
what do you think about
const specialFields = ["foo", "bar"]
const desiredFieldmap = specialFields.reduce((acc, item) => {
acc[item] = `${DEFAULT_INDICATOR_SOURCE_PATH}.${item}`;
return acc;
}, {})
There was a problem hiding this comment.
source.ip and destination.ip break that pattern, unfortunately.
| import { IEsSearchResponse } from 'src/plugins/data/public'; | ||
|
|
||
| import { | ||
| CtiEventEnrichmentRequestOptions, |
There was a problem hiding this comment.
should we consider treating CTI as an acronym in general?
There was a problem hiding this comment.
Ahh, the old "acronyms in camel case" debate! I know it well 😄 .
My personal preference is to use pascal case for acronyms longer than two characters: CtiEventEnrichment or HtmlButton, but I agree that consistency is tantamount. I don't think we have any existing constants that break this pattern, but if you've been taking another approach in some parallel work let's discuss.
…1553) * Adding boilerplate for new CTI search strategy type This is going to be a subtype of the general SecSol search strategy; the main functionality is going to be: * transformation of the incoming parameters into named equivalents * transformation of responses to include enrichment context fields (matched.*) * More boilerplate, including tests A few type errors because our functions don't actually do anything yet, nor are our request/response types fleshed out. * Starting to flesh out the request parsing * Defines a basic request, along with a mock * Defines helper function to generate should clauses from field values * Adds placeholder tests throughout * Fleshing out unit tests around our enrichment query * Fleshing out response parsing of eventEnrichment strategy * Fix types from elasticsearch Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…1553) * Adding boilerplate for new CTI search strategy type This is going to be a subtype of the general SecSol search strategy; the main functionality is going to be: * transformation of the incoming parameters into named equivalents * transformation of responses to include enrichment context fields (matched.*) * More boilerplate, including tests A few type errors because our functions don't actually do anything yet, nor are our request/response types fleshed out. * Starting to flesh out the request parsing * Defines a basic request, along with a mock * Defines helper function to generate should clauses from field values * Adds placeholder tests throughout * Fleshing out unit tests around our enrichment query * Fleshing out response parsing of eventEnrichment strategy * Fix types from elasticsearch Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…102275) * Adding boilerplate for new CTI search strategy type This is going to be a subtype of the general SecSol search strategy; the main functionality is going to be: * transformation of the incoming parameters into named equivalents * transformation of responses to include enrichment context fields (matched.*) * More boilerplate, including tests A few type errors because our functions don't actually do anything yet, nor are our request/response types fleshed out. * Starting to flesh out the request parsing * Defines a basic request, along with a mock * Defines helper function to generate should clauses from field values * Adds placeholder tests throughout * Fleshing out unit tests around our enrichment query * Fleshing out response parsing of eventEnrichment strategy * Fix types from elasticsearch Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This adds a new search strategy implementation to perform simplified "indicator match" logic in service of a new CTI feature. As design for the UI component of this is still being finalized, I'm opening this backend-only work as a self-contained PR to get the ball rolling.
At a high level, this strategy:
enrichments, as specified in the enrichments RFCChecklist
For maintainers