-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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 input for Crowdstrike Falcon events #16988
New input for Crowdstrike Falcon events #16988
Conversation
Pinging @elastic/siem (Team:SIEM) |
Looking into CI errors. Need to run |
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.
Looking good :-)
couple general questions/suggestions:
- any value in geoip on ip addrs?
- if event has ips, users or hashes probably a good idea to add those to the related fields
specific questions in-line.
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Outdated
Show resolved
Hide resolved
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.
This is a great idea!
This is just a preliminary review, here's a bunch of comments and suggestions :-)
Broader discussion point: as I note in one of my comments, this seems to be a log that mixes their service's audit logs with actual endpoint detection events. Both are worth capturing, of course. But I wonder if we should find a way to separate them out in two different event.dataset
, as their meaning & semantics are pretty different.
Doing so would help clarify different handling of various things like host.name
, how to fill event.action
, etc; that have been raised by me and @leehinman.
|
||
evt.Put("event.action", tactic + "_" + technique) | ||
evt.Put("event.kind", "alert") | ||
evt.Put("event.type", "info") |
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.
Indeed. @leehinman, this is how to make it into an array, correct?
evt.Put("event.type", "info") | |
evt.Append("event.type", "info") |
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon/test/falcon-events.log-expected.json
Show resolved
Hide resolved
@@ -0,0 +1,19 @@ | |||
type: log |
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 wonder if it's worth also supporting the syslog input here? https://www.crowdstrike.com/blog/tech-center/integrate-with-your-siem/ seems to suggest that it's possible for the Connector to send date directly to a syslog server?
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 would be easy to add the config option for syslog and maybe not make it the default choice. But my concern is we can't test it to validate that the output is identical to the file output. I'm on the fence but can be convinced to add it if it's not the default choice.
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 see, makes sense. I think we can leave it out and add it if it's being requested. Then we have a way to validate it.
It looks like CI is much more happy now. The failures are from flakey tests and appear unrelated to your changes. |
Yep, thanks @andrewkroh. I was just rebuilding to see if that was the case. I'll start working on the recommendations tonight. |
x-pack/filebeat/module/crowdstrike/falcon_audit/config/pipeline.js
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon_endpoint/_meta/fields.yml
Outdated
Show resolved
Hide resolved
x-pack/filebeat/module/crowdstrike/falcon_endpoint/config/pipeline.js
Outdated
Show resolved
Hide resolved
Thanks for the feedback. PR Feedback Addressed
PR Feedback Not Addressed
|
jenkins retest this please |
I've been able to address most of the PR feedback (thanks again, everyone). I think we're ready for some LGTMs unless anyone has any additional feedback/changes. |
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.
This looks pretty good! Two small requests:
- The docs need changed to reflect there's only one fileset.
- Please add an entry to the CHANGELOG.next.asciidoc file in the root of the repo under the Filebeat/Added section.
|
||
This is the filebeat module for the Crowdstrike Falcon using the Falcon https://www.crowdstrike.com/blog/tech-center/integrate-with-your-siem[SIEM Connector]. This module collects this data, converts it to ECS, and ingests it to view in the SIEM. By default, the Falcon SIEM connector outputs JSON formated Falcon Streaming API event data in JSON format. | ||
|
||
This module segments events forwarded by the Falcon SIEM connector into two datasets for endpoint data and Falcon platform audit data. |
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.
This module segments events forwarded by the Falcon SIEM connector into two datasets for endpoint data and Falcon platform audit data. |
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 was going to keep this since we're still doing this (two datasets), just from the same fileset. That okay?
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.
Oh, that's interesting. I didn't notice that the module was setting the event.dataset
values. We've never had a case AFAIK where a fileset produced an event.dataset
value other than the default of {module}.{fileset}
. I don't think this will cause any issues. I think it would be good to callout the event.dataset values that it produces in this paragraph.
Changes look really good. Looks like you need to run "mage fmt update" and push changes though. |
…ats into feature-crowdstrike-module
Thanks for all the help @leehinman @andrewkroh @webmat and @tsg! |
What does this PR do?
This adds a new input for Crowdstrike Falcon events forwarded by Crowdstrike's SIEM forwarder. This input uses the default JSON output format from the SIEM forwarder.
Why is it important?
We've had several users asks us for adding support for Crowdstrike Falcon in ECS. We strive to be data agnostic to help enable our SOC users aggregate all of their data in our SIEM. Using some log data provided by our users, I've put this new module together to ingest the data and convert many fields into ECS (including categorization).
Checklist
How to test this PR locally
Screenshots
Proof this works
I also ran
make docs
to validate the documentation looked good.Other comments
I'll squash before merging.