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][Detections] Adds sequence callout in the exceptions modals for eql rule types #79007

Merged
merged 7 commits into from
Oct 5, 2020

Conversation

dplumlee
Copy link
Contributor

@dplumlee dplumlee commented Sep 30, 2020

Summary

Adds a callout warning to inform users of exception-related side effects should they choose to create/edit an exception tied to a eql rule type that has a sequence query.

Screen Shot 2020-09-30 at 12 30 58 PM

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@dplumlee dplumlee added Team:SIEM v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.10.0 Feature:Detection Rules Security Solution rules and Detection Engine labels Sep 30, 2020
@dplumlee dplumlee self-assigned this Sep 30, 2020
@@ -316,6 +317,13 @@ export const AddExceptionModal = memo(function AddExceptionModal({
[fetchOrCreateListError, exceptionItemsToAdd]
);

const isRuleEQLSequenceStatement = useMemo((): boolean => {
if (maybeRule != null && maybeRule.query != null) {
return maybeRule.type === 'eql' && maybeRule.query.startsWith('sequence');
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the logic I chose to go with for delineating sequence queries and non-sequence queries. When rylands validation pr gets merged, this should cover all cases given that sequence is a saved term in eql, but any comments/suggestions from those more versed in EQL would be appreciated

Copy link
Contributor

Choose a reason for hiding this comment

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

@rw-access may have ideas about the best way to do this

Copy link
Contributor

Choose a reason for hiding this comment

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

@dplumlee FYI we have some helpers available to avoid these kinds of hardcoded strings. Since this logic is duplicated in a few spots, I'd say that moving this function out to a shared location makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

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

nice. for the logic in general, first word is sequence and the second word is not where.
then you'll be set (assuming it's valid syntax in the first place)

Copy link
Contributor

Choose a reason for hiding this comment

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

is sequence where ... valid eql? I tested using sequence as an event category in the EQL ES api and got an exception, wasn't sure if that just isn't allowed since sequence is a reserved word.

Copy link
Contributor

Choose a reason for hiding this comment

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

I haven't tried sequence where true in ES EQL, wasn't sure how ANTLR handled it.

@dplumlee dplumlee marked this pull request as ready for review September 30, 2020 18:45
@dplumlee dplumlee requested review from a team as code owners September 30, 2020 18:45
@elasticmachine
Copy link
Contributor

Pinging @elastic/siem (Team:SIEM)

export const hasEqlSequenceQuery = (ruleQuery: string | undefined): boolean => {
if (ruleQuery != null) {
const parsedQuery = ruleQuery.split(' ');
return parsedQuery[0] === 'sequence' && parsedQuery[1] !== 'where';
Copy link
Contributor Author

@dplumlee dplumlee Sep 30, 2020

Choose a reason for hiding this comment

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

@rylnd @rw-access will something like this work, or is it valid syntax to begin an eql query with a leading space?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is valid, or at least valid to pass to the EQL api, so I just trimmed it that should solve any potential edge cases problems

Copy link
Contributor

@rw-access rw-access Oct 1, 2020

Choose a reason for hiding this comment

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

might wanna add a test case for other forms of whitespace and multiple between sequence and where, but I think this approach is solid.

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 yeah good call. new fix should cover that too, thanks

@dplumlee
Copy link
Contributor Author

dplumlee commented Oct 1, 2020

@elasticmachine merge upstream

@dplumlee dplumlee force-pushed the modal-sequence-callout branch from dde40d8 to abd131a Compare October 1, 2020 22:36
'xpack.securitySolution.exceptions.addException.sequenceWarning',
{
defaultMessage:
'This rule is a sequence statement. The exception created will apply to all events in the sequence.',
Copy link
Contributor

Choose a reason for hiding this comment

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

@paulewing Do you have any preferences on the language here? I'm thinking that the first sentence could be more specific and say something like this:

This rule's query contains an EQL sequence statement.

});
});

describe('when a sequence query is passed with extra white space', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

thanks for the updates.
how does this work for "sequence\n..."? or "sequence where ..." which should be invalid syntax on the ES side. but if it is accepted syntax, then it's definitely not a sequence query

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added coverage for \n but it should work for the sequence where ... case already. Added another test for coverage sake

@@ -17,6 +17,14 @@ export const hasNestedEntry = (entries: EntriesArray): boolean => {
return found.length > 0;
};

export const hasEqlSequenceQuery = (ruleQuery: string | undefined): boolean => {
if (ruleQuery != null) {
const parsedQuery = ruleQuery.split(' ').filter((word) => word !== '' && word !== '\n');
Copy link
Contributor

Choose a reason for hiding this comment

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

It still seems brittle for some reason, since there are four whitespace characters for EQL. sequence\n[x] may slip through.

ruleQuery.trim().split(/[ \t\r\n]+/); should do it the same way ANTLR does

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 cool, i'll switch to that then

@dplumlee dplumlee force-pushed the modal-sequence-callout branch 2 times, most recently from 98bcfa4 to 618cd74 Compare October 2, 2020 20:48
@dplumlee
Copy link
Contributor Author

dplumlee commented Oct 2, 2020

@elasticmachine merge upstream

1 similar comment
@dplumlee
Copy link
Contributor Author

dplumlee commented Oct 5, 2020

@elasticmachine merge upstream

@dplumlee dplumlee force-pushed the modal-sequence-callout branch from 1defbb6 to bc046d4 Compare October 5, 2020 14:54
@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

async chunks size

id before after diff
securitySolution 10.3MB 10.3MB +3.4KB

History

  • 💔 Build #79651 failed 1defbb6a8a00c9f40c082994cddd55caf2b10263
  • 💛 Build #79356 was flaky 21235d2a55f9344ba9b09a2e4c1e6702b7ae5335
  • 💔 Build #79333 failed 618cd749465ce402bb83fee2e86b23338921b4a6
  • 💚 Build #79293 succeeded 98bcfa403d666417563de7b4428d7b3fbb667f82
  • 💚 Build #79263 succeeded ba79b3542476f834b6bc3830f95880600d3b0a2f

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

Copy link
Contributor

@FrankHassanabad FrankHassanabad left a comment

Choose a reason for hiding this comment

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

LGTM (caveat) I'm not one of the original commenters but it looks like everything was addressed. And if not, well, follow ups are always possible! :-)

@dplumlee dplumlee merged commit 6a173ba into elastic:master Oct 5, 2020
@dplumlee dplumlee deleted the modal-sequence-callout branch October 5, 2020 20:39
dplumlee added a commit that referenced this pull request Oct 6, 2020
@MindyRS MindyRS added the Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. label Sep 23, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Detection Rules Security Solution rules and Detection Engine release_note:skip Skip the PR/issue when compiling release notes Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:SIEM v7.10.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants