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.

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] Switches remaining rule types to use new Rule Preview API #116374

Merged
merged 35 commits into from
Dec 7, 2021

Conversation

dplumlee
Copy link
Contributor

@dplumlee dplumlee commented Oct 26, 2021

Summary

Overview

This PR switches the rule preview feature over to our new rule preview API that uses the actual rule executors instead of solely relying on a limited search strategy call over existing data. By using the actual executors, we are able to return real warnings and errors that occur in the execution process that previously couldn't be seen until the rule was created and actually ran. It also allows us to display a more accurate preview akin to what the real rule execution would show and gives us the ability to add more rule types and features to the preview functionality down the line.

Remaining tasks

  • Use /api/detection_engine/rules/preview to preview all rules
    • Custom Query
    • EQL
    • Threshold
  • Audit unit test coverage of all files in x-pack/plugins/security_solution/public/detections/components/rules/rule_preview
    • convert all enzyme tests to React Testing Library
  • Update the tests in x-pack/plugins/security_solution/cypress/integration/detection_rules with new selectors if necessary, and add preview coverage to the indicator_match_rule test.
  • Add API test coverage in x-pack/test/detection_engine_api_integration/security_and_spaces/tests for the preview endpoint as well as the preview/index endpoint
  • remove x-pack/plugins/security_solution/public/detections/components/rules/query_preview directory
  • ensure that the correct invocation count values as well as interval and from values are being supplied to Custom Query, EQL, and Threshold rules (1 execution per 1h for each time unit)
  • Switch to new rule executors

Note

Cypress tests related to threshold preview were disabled in this PR because of the way we implement the es archive data. The current method for testing the preview functionality is hard coding the look back time for the rule to 50,000 hours so it can get the data (timestamped 2019) to show up. With the new updates added in this PR, we no longer have the ability to hard code a look back time. While this is planned to be added in a future PR, it's still not a great way to maintain the tests and so I've opened an issue around updating the data generation for these (and perhaps more) cypress tests that will align with unskipping those specific cypress tests

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@dplumlee dplumlee added release_note:enhancement v8.0.0 Feature:Detection Rules Anything related to Security Solution's Detection Rules Feature:Detection Alerts Security Solution Detection Alerts Feature auto-backport Deprecated - use backport:version if exact versions are needed Team:Detection Alerts Security Detection Alerts Area Team labels Oct 26, 2021
@dplumlee dplumlee self-assigned this Oct 26, 2021
@dplumlee dplumlee added the Team:Detections and Resp Security Detection Response Team label Oct 26, 2021
@dplumlee dplumlee force-pushed the update-rule-type-preview branch 3 times, most recently from 0d47948 to 1656bdf Compare November 9, 2021 23:25
@elastic elastic deleted a comment from kibanamachine Nov 12, 2021
@dplumlee dplumlee force-pushed the update-rule-type-preview branch 2 times, most recently from 4dbfc45 to dd39c1e Compare November 18, 2021 14:30
@ecezalp ecezalp self-requested a review December 6, 2021 19:53
Copy link
Contributor

@ecezalp ecezalp left a comment

Choose a reason for hiding this comment

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

I was testing this PR locally and I came across a critical issue (409 w/ version_conflict_engine_exception) - please let me know if you are not able to reproduce it.

  1. create a test-index with @timestamp field with date mapping
  2. post an event to test-index, with current timestamp and test_id: 123
  3. create a custom query rule for test-index with test_id: * query
  4. observe that the preview returns no results on the UI (expecting 1)
  5. observe that inspecting matrix histogram query there are no results (expecting 1)
  6. observe that once the rule is created 1 alert is generated as expected
  7. observe via devtools that there is a preview event on the preview index as expected

this was the error was in the console

[2021-12-06T14:48:35.044-05:00][ERROR][plugins.ruleRegistry] ResponseError: {"took":0,"errors":true,"items":[{"create":{"_index":".internal.preview.alerts-security.alerts-default-000001","_id":"80c7e30e7572dc2fa9ef510d5c3747fafda0a10dec8f0c5afa7e03817840841a","status":409,"error":{"type":"version_conflict_engine_exception","reason":"[80c7e30e7572dc2fa9ef510d5c3747fafda0a10dec8f0c5afa7e03817840841a]: version conflict, document already exists (current version [1])","index_uuid":"sKKOrC7YSySyt16-FqFNQg","shard":"0","index":".internal.preview.alerts-security.alerts-default-000001"}}}]}
    at /Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/rule_data_client/rule_data_client.ts:194:31
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at alertWithPersistence (/Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/utils/create_persistence_rule_type_wrapper.ts:94:34)
    at /Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/factories/bulk_create_factory.ts:47:31
    at searchAfterAndBulkCreate (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/signals/search_after_bulk_create.ts:158:13)
    at Object.executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/query/create_query_alert_type.ts:66:22)
    at Object.executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/rule_types/create_security_rule_type_wrapper.ts:246:51)
    at executor (/Users/eceozalp/Workspace/kibana/x-pack/plugins/rule_registry/server/utils/create_persistence_rule_type_wrapper.ts:20:23)
    at lists (/Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts:140:11)
    at /Users/eceozalp/Workspace/kibana/x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts:178:11
    at Router.handle (/Users/eceozalp/Workspace/kibana/src/core/server/http/router/router.ts:275:30)
    at handler (/Users/eceozalp/Workspace/kibana/src/core/server/http/router/router.ts:230:13)
    at exports.Manager.execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
    at Object.internals.handler (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
    at exports.execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
    at Request._lifecycle (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/request.js:371:32)
    at Request._execute (/Users/eceozalp/Workspace/kibana/node_modules/@hapi/hapi/lib/request.js:281:9)

I deleted my preview index and started kibana again, and tried to preview the same event with a different new rule, and the problem persisted.

@dplumlee
Copy link
Contributor Author

dplumlee commented Dec 7, 2021

@ecezalp The error you're seeing in the console is a side effect of the new dedup logic we're using for the rule registry executors. It's not actually impacting the data we're getting back and displaying in the preview index/histogram. The real issue was the index having a bit of a race condition between refreshing and the read call the histogram is sending, the data was not always being indexed fully thus making it unable to be read by the histogram. In the latest commit, we add an await clause to refresh the alias + namespace before returning the initial preview call so that the UI should always be able to read the entire index correctly. As for the console error itself, @marshallmain has this PR that addresses logging the message instead of throwing the error, but from my understanding it's more of an indication that the dedup is working and not causing data to not be written properly

@dplumlee dplumlee requested a review from a team December 7, 2021 00:20
@ecezalp
Copy link
Contributor

ecezalp commented Dec 7, 2021

following the instructions from my previous comment, I am still seeing no preview results when trying to preview a custom query rule. preview index seems to get populated, but the matrix histogram query doesn't return anything. I have tested by pulling the latest changes & deleting the data directory & bootstrapping & following the steps shared above

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
securitySolution 2807 2798 -9

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
ruleRegistry 145 148 +3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
securitySolution 4.6MB 4.5MB -9.6KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
securitySolution 243.0KB 242.7KB -326.0B
Unknown metric groups

API count

id before after diff
ruleRegistry 171 175 +4

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @dplumlee

@@ -54,6 +54,10 @@ export class RuleDataClient implements IRuleDataClient {
return this.options.indexInfo.kibanaVersion;
}

public indexNameWithNamespace(namespace: string): string {
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@ecezalp ecezalp self-requested a review December 7, 2021 21:02
@ecezalp
Copy link
Contributor

ecezalp commented Dec 7, 2021

Removed the blocker as Davis pointed out that the bug identified is an existing one, and is logged here

Copy link
Contributor

@ecezalp ecezalp left a comment

Choose a reason for hiding this comment

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

LGTM, thank you for the hard work!

I was able to locally run the code and confirm that custom query rules, threshold rules, and EQL rules can be previewed as expected.

There is still some relevant work that needs to be completed, which we should do during the FF

  • fix matrix histogram bug
  • unskip tests
  • do not ignore 404
  • get product approval around what noisy is in a preview context

@@ -24,13 +24,13 @@ import { ESQuery } from '../../../../../common/typed_json';
*/
export const isNoisy = (hits: number, timeframe: Unit): boolean => {
if (timeframe === 'h') {
return hits > 1;
return hits > 20;
Copy link
Contributor

Choose a reason for hiding this comment

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

was there a particular reason for this change? as far as I know, the noisiness criteria was 1 alert per hour for all scenarios

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah maybe i misunderstood the code prior to then, I thought we were going based of the invocations themselves, we can switch that back and get a more solidified answer for noisiness in all rule scenarios

) {
return response.ok({ body: { errors: ['Invalid invocation count'] } });
}

if (request.body.type === 'threat_match') {
return response.ok({ body: { errors: ['Preview for rule type not supported'] } });
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

{
index: previewRuleDataClient.indexNameWithNamespace(spaceId),
},
{ ignore: [404] }
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm why are we ignoring 404 here? doesn't that mean that the preview index hasn't been properly created & functionality won't work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

At this point, the 404 error would show up if there were no alerts written to the index and we wouldn't have created it because no alerts were found with the preview query. I believe in the event of the index not being properly created, there are other error handlers that would throw still

Copy link
Contributor

@ecezalp ecezalp Dec 7, 2021

Choose a reason for hiding this comment

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

so if the first preview ever doesn't have any results, you get a 404, which is then suppressed? that's sounds like an edge case. I think it's conceptually not very good to suppress errors like this in general, so maybe we should let the users see the error in that case.. we could ask product

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can definitely ask, but as I understand it, this is expected behavior as it wouldn't be an error from the user's perspective. It's more of an internal error dealing with the rule registry's design behavior of creating an index only if alerts exist. Users would get no data back and the resulting histogram would be empty which would be accurate from their POV and they need not know if the index was created or not. We can for sure discuss it further though

Copy link
Contributor

@marshallmain marshallmain left a comment

Choose a reason for hiding this comment

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

LGTM
Nice work

@@ -22,6 +23,9 @@ interface PreviewRouteParams {
ruleType: Type;
timeFrame: Unit;
threatMapping: ThreatMapping;
threshold: FieldValueThreshold;
machineLearningJobId: string[];
anomalyThreshold: number;
Copy link
Contributor

Choose a reason for hiding this comment

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

Mixing params from different rule types is something of an anti-pattern IMO.

Copy link
Contributor Author

@dplumlee dplumlee Dec 7, 2021

Choose a reason for hiding this comment

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

From a UI perspective, these are always present since it's just the form state. They do get separated into their different rule types later. There's probably better ways to pass that through though

@dplumlee dplumlee merged commit 5d44d79 into elastic:main Dec 7, 2021
@kibanamachine
Copy link
Contributor

The following labels were identified as gaps in your version labels and will be added automatically:

  • v8.1.0

If any of these should not be on your pull request, please manually remove them.

@kibanamachine
Copy link
Contributor

💔 Backport failed

Status Branch Result
8.0 Commit could not be cherrypicked due to conflicts

To backport manually run:
node scripts/backport --pr 116374

dplumlee added a commit to dplumlee/kibana that referenced this pull request Dec 7, 2021
…view API (elastic#116374)

# Conflicts:
#	x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts
@dplumlee dplumlee deleted the update-rule-type-preview branch December 7, 2021 23:48
dplumlee added a commit that referenced this pull request Dec 8, 2021
…le Preview API (#116374) (#120700)

* [Security Solution] Switches remaining rule types to use new Rule Preview API (#116374)

# Conflicts:
#	x-pack/plugins/security_solution/server/lib/detection_engine/routes/rules/preview_rules_route.ts

* fix conflicts

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Heenawter pushed a commit to Heenawter/kibana that referenced this pull request Dec 8, 2021
TinLe pushed a commit to TinLe/kibana that referenced this pull request Dec 22, 2021
gbamparop pushed a commit to gbamparop/kibana that referenced this pull request Jan 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed Feature:Detection Alerts Security Solution Detection Alerts Feature Feature:Detection Rules Anything related to Security Solution's Detection Rules release_note:enhancement Team:Detection Alerts Security Detection Alerts Area Team Team:Detections and Resp Security Detection Response Team v8.0.0 v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants