* Add pure fn and consuming hook to fetch event enrichment
It's not being invoked yet, but I've added a placeholder where it's
going.
* Move existing enrichment tests to new spec file
This is a rough copy/paste, I'll clean up as I flesh out the new tests.
* Move test constants into tests that use them
* style: declare FC function as an FC
* Extract some inline parsing logic into a helper function
And test it!
* Solidifying enrichment types on the backend
* Declares an enum for our types
* Sets type during indicator match rule enrichment
* Sets type during investigation-time enrichment
* WIP: Enrichment rows are rendered on the alerts summary
There are lots of TODOs here, but this implements the following:
* Fetching investigation-time enrichments from the backend
* Parsing existing enrichments from timeline data
* Merging the two enrichment types together, and rendering them in rows
as specified
Much of the data-fetching is hardcoded, and this broke the existing
pattern with SummaryView/SummaryRow so that got a little messy; I may
end up just using my own EuiTable but we'll see.
Threat Intel tab is currently broken; that's up next.
* Updates ThreatDetailsView to accept an array of enrichments
The investigation-time enrichments are a little messy because they
contain all the non-ECS fields that indicators contain; other than that,
this is looking good.
Still need to add the new header, and potentially sort the fields.
* Sort our details fields
This promotes sanity for the user.
* Add "view threat intel data" button
This simply opens the threat intel tab.
* Implement header for threat details sections
* Add a basic jest "unit" test around ThreatSummaryView
* Fix remaining tests for components we modified
This also addresses a bug where we were not properly sorting new
enrichments by first_seen; this is covered under the tests that were
fixed.
* Filter out duplicate investigation-time enrichments
Because the enrichment endpoint is dumb and doesn't know about the
existing event or its enrichments, we need to merge these together on
the client to reduce noise and redundant data.
* Add inspect button to investigation enrichments
* Massages the response into the format that the inspect component uses
* Moves stateful fetching of query and persisting in redux to new, more
specialized hook
* Moves existing enrichment hook to a more suitable location in
containers/
* Fix failing unit tests
* indicator match rule now specifies `matched.type` as coming from the
rule
* Inspecting the enrichment query requires use of the redux store, which
was not previously mocked
* Fix existing CTI cypress tests
This covers the basics of the Alert Summary and Threat Intel tabs; the
investigation-time enrichment functionality is up next.
* Adds a cypress test exercising investigation time enrichment
* Loads more indicators (filebeat data, `threat_indicator2` archive)
AFTER the rule has executed
* Asserts that those indicators are also found on the alert summary.
* Populate event enrichment call with actual alert fields
This was previously hardcoded during development.
* Add a new field to our suspicious event to trigger enrichment
The existing myhash field will generate an alert due to the way the rule
is written, but the alert had no other fields that would match the
investigation time enrichment. This gives it a source.ip, and updates
the indicator to match.
* Only fetch enrichments data if there are valid event fields
If none of the alert's fields would be relevant to the enrichment query,
then we don't make the request at all.
* Update enrichments matched.typed in integration tests
This field was updated to reflect the source of the match, in this case:
indicator match rules.
* Ensure draggable fields are unique in a multi-match scenario
If a given field matched multiple indicators, then the previous
contextId was not unique as it was based on field/value that matched.
Adding provider to the mix would fix it, except that we're not
guaranteed to have a provider.
I've added both provider (if present) and an index value to the key to
ensure that it's unique.
* Simplify types
This field can never be null, as we always set it in our response.
* Move helper functioons out of shared location and into consuming component
These are unlikely to be used elsewhere.
* Clean up data parsing logic using reduce
This obviates the need for our filter/guard function and the extra loop
that it entails. We have to specify the return value of our reduce fn,
however, but that's mostly equivalent to our type guard.
* Move our general function into a general location
* Extract the concept of "enrichment identifiers"
This was already partially codified with 'buildEnrichmentId,' which is
used to dedup enrichments; this extends the idea to all fields that
could uniquely identify a given indicator.
* Use existing constant as the source of our enrichments query
This is now used by both the overview card and the enrichment query.
* Codify our default enrichment lookback as constants
* Remove unnecessary flexbox
The generic SummaryView component previously had to deal with
multi-valued CTI fields, representing the multiple values coming from
the multiple nested objects with that field.
However, with the new UI we no longer have that constraint, and so the
default columnar style, and the corresponding overriding styles, are no
longer necessary.
* Filter out partial responses in the event enrichment observable
The UI does not currently handle these. We need to test the behavior of
long-running queries with this filter, but this should simplify the
behavior to complete/error until we handle partial responses.
* Display placeholders while event enrichment is loading
Displays a loading spinner in the Threat Intel tab title, and some
loading lines where the enrichments summary is.
* Update our indicator data to be within the last 30 days
This fixes our cypress test, but it's going to start failing again in 30
days. However, by that time I'll have implemented the absolute data
picker, which will allow for a more comprehensive test in addition to us
sidestepping this issue.
* Fix type error with our details tabs
The name prop on a Tab will be rendered as a node, so both strings and
elements are acceptable. This relaxes the types to inherit from the
component itself.
* Fix failing jest tests
The addition of our filtering of the search observable broke this test,
since we now need to implement the search observable.
Rather than do that, we'll instead mock our local hook as that's more
likely to change.
569c209f2c