Closed PoppaShell closed 1 year ago
Additionally, I would highly recommend actually keeping the Pre-Built Rules Change Log & Documentation updated to reflect what is actually in the Rules Repo that gets pushed to Elastic Cloud. When Elastic Security notifies you in the GUI that there are new Pre-Built Rule Updates, it references the Change Log linked below. None of the Rules listed have the updated from Pull Request #2593 listed. So I have no idea or heads up this field would be added so I could catch that Endgame doesn't sent the appropriate date. But I shouldn't even have to worry about doing that since Elastic owns Endgame & the Stream Integration to Elastic and it's corresponding rules.
https://www.elastic.co/guide/en/security/current/prebuilt-rules-changelog.html
Until this is fixed, I will be adding the needed field using Cribl, as we have all Endgame routing through there. But for those that don't have something in-between, this is a solid inconvenience. I've lost 9 dates of potential alerts. I should have caught this earlier, but it wasn't the most straight forward find.
@w0rk3r I shared a sample windows log coming directly from Endgame SMP, hosted by Endgame in the cloud. And I can share as many as you need me to. And below is a Linux sample. But I also just noticed something else new. There is not a "data_stream" object. Did Endgame now switch to using Data Streams recently? And maybe that is the issue? We have it sending to Cribl to do some reduction and then forwarding it on with the Bulk API, just as Endgame normally would to send it to Elastic. Is it now natively sending to a Data Stream and then doing other post processing on the Elastic side to add the "host.os.type" field?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is stale because my last comment was ignored, apparently. But I would have loved to get more dialogue on this issue. My assumption is that Endgame's Elastic Stream Integration switched to using Datastreams and Ingest Pipelines to add this field value upon ingest. But I was able to verify it is not included in the logs coming straight from Endgame.
Reopening, as I mistakenly clicked the close button.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This has been closed due to inactivity. If you feel this is an error, please re-open and include a justifying comment.
Link to rule
Pretty much all rules in the commit for Pull Request #2593 https://github.com/elastic/detection-rules/commit/59da2da4740da52df15ce11139150b61cd57f9e1
Description
When Pull Request #2593 was committed, it added host information to the queries by using the field name of "host.os.type" to isolate each endpoint query to the appropriate host type of "windows", "linux" or "macos". I think this is a good idea overall. But it broke all Endpoint Rules for Endgame Events. This is because the Endgame Stream Integration doesn't send information for the field "host.os.type". It has broken all of our alerts we have enabled for the "Endgame Elastic" tagged rules.
I would expect that changes to Detection Rules would take into consideration both the Elastic Agent & Endgame Agent Data. And with that in mind, I can think of two viable options that would not have broken this flow and/or would fix the issue for the future.
process where host.os.type == "windows" or observer.os.type == "windows"
)Screenshots You can see in this screenshot that when we pushed the Pre-Built Rules update on 04/24 that we stopped getting alerts.
Example Data
You can see in the commit (https://github.com/elastic/detection-rules/commit/59da2da4740da52df15ce11139150b61cd57f9e1) that this "host.os.type" was added to all of the endpoint rules. And that was the whole goal of Pull Request #2593. But if you look at the events being sent from Endgame (sample below) that this field is not present.