-
Notifications
You must be signed in to change notification settings - Fork 469
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
[New Rule] Threat intel indicator match rule #1133
Conversation
👋
Some other dependencies before this will pass
A separate PR will be added for CLI support of the rule type |
Co-authored-by: Ross Wolf <31489089+rw-access@users.noreply.github.com>
Co-authored-by: Ross Wolf <31489089+rw-access@users.noreply.github.com>
Co-authored-by: Ross Wolf <31489089+rw-access@users.noreply.github.com>
0c7b27f
to
d1e3a2d
Compare
""" | ||
|
||
|
||
[[rule.threat_filters]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to manually lint/format this @rw-access . There appears to be an issue with the MarshmallowDataclassMixin.to_dict
method on schema.dump
, but I think it is only happening on threat_match
rules, so it may not be rendering the schema properly. As of now, it strips a lot of fields
@@ -174,6 +174,9 @@ def get_beats_sub_schema(schema: dict, beat: str, module: str, *datasets: str): | |||
dataset_dir = module_dir.get("folders", {}).get(dataset, {}) | |||
flattened.extend(get_field_schema(dataset_dir, prefix=module + ".", include_common=True)) | |||
|
|||
# we also need to capture (beta?) fields which are directly within the module _meta.files.fields | |||
flattened.extend(get_field_schema(module_dir, include_common=True)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm... is this the right call?
IIRC, this blew up the schema significantly before and added more fields that shouldn't be there.
do you have a sense what new fields and how many were added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not for every module, but threatintel.indicator*
(and some other threatintel.*
specifically was entirely embedded under this. Not sure if this is actually where beta fields are stuffed, but it seems consistent. Without it, validation will fail on threatintel.indicator*
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i'm following that this is the only way for this rule to be validated.
we should double check the impact on the schema and validation in general. i think for other beats and modules, this brings in more fields than is correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a full dump of what's included per beats/module in the base directory only:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
tags = ["Elastic", "Windows", "Elastic Endgame", "Network", "Continuous Monitoring", "SecOps", "Monitoring"] | ||
type = "threat_match" | ||
|
||
threat_index = [ "filebeat-*"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's kinda too bad that this all get flattened, but that's more of a kibana API thing
i think it would be nicer if the fields were all namespaced by type instead of jammed together
Co-authored-by: Ross Wolf <31489089+rw-access@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Successfully exported and imported into Kibana
If all of the rule data looks accurate to you @peasead, then LGTM to merge 👍
Solid. The indicator match timeline template should be in 7.13, would that be a timeline UUID I could add now? |
yep, just find the guid and timeline title (and test 🙂 ) |
Here's the GUID ( |
add this to the rule and upload it to a stack that has that template timeline_id = "495ad7a7-316e-4544-8a0f-9c098daee76e"
timeline_title = "Generic Threat Match Timeline" Unit tests/validation may need to be updated to pass |
FYSA @rw-access in a separate PR we can start removing irrelevant tests and moving others to within the marshmallow schema validation under |
Co-authored-by: Justin Ibarra <brokensound77@users.noreply.github.com>
[New Rule] Threat intel indicator match rule (elastic#1133)
Issues
Resolves #1065
Resolves https://github.com/elastic/protections-team/issues/368
Summary
This adds an Indicator Match rule for the Detection Engine. The indicators are provided by the Threat Intel Filebeat module from the following sources:
Of note, currently, the Indicator Match rule type isn't in the
detection_rules
module, so this rule was exported from the Detection Engine and converted to TOML manually. This will likely need some massaging to pass unit tests.Contributor checklist