On Mac specifically, the falcon sensor tampering prevents you from unloading it via sudo or root, and additionally generates alerts to the console so you can follow up with the end user to see why or what they were trying to accomplish, and give them the policy violation spiel.
honestly not sure but something you can for sure ask/test as part of your POC
Heres what i see from Crowdstrikes customer accessible documents:
Sensor Tampering Protections
Windows: When enabled, it protects sensor related files, folders, and registry objects from renaming or deletion.
MacOs: When enabled, it protects sensor related files and folders from modification, renaming, or deletion.
I specifically stated they are internal customer accessible KBs so no. Your a prospective customer, get on the horn with a sales person and theyll make it their life’s mission to get you answers if theres a chance youll pay them lol
It should have. You should use both sensor tampering and uninstallation protection.
If you are a customer, here are resources:
[https://supportportal.crowdstrike.com/s/article/ka16T000001xjaZQAQ](https://supportportal.crowdstrike.com/s/article/ka16T000001xjaZQAQ)
[https://falcon.eu-1.crowdstrike.com/documentation/page/e5c21607/prevention-policy-settings#if52e0a4](https://falcon.eu-1.crowdstrike.com/documentation/page/e5c21607/prevention-policy-settings#if52e0a4)
I mean, it's kind of "new", it works with sensor version 7.10 or later and Ventura and later.
The description of it in the prevention policy for mac "Blocks attempts to tamper with the sensor. If disabled, the sensor still creates detections for tampering attempts but doesn't block them. Disabling not recommended."
That paired with, under Sensor update policy", Uninstall and maintenance protection "Require a token for the uninstall and maintenance on the sensor when not performed by the Falcon platform." I think you will be as protected as you can get.
The anti-tamper works well and have caught devs blaming CS for their crap not working (EDR tools are always to blame yes?) and thinking they can quietly disable/remove it, then you grab the corporate IT security policy docs out and start beating them up with it.
Or the other way.."I'm sorry, we assumed you were an insider threat..so we contained your device. Get your manager to request an un-contain. Yes, you will have to explain why"
If you have a SOAR capability, you can automate that whole process with API calls. CS APIs are freakin' great to work with.
On Mac specifically, the falcon sensor tampering prevents you from unloading it via sudo or root, and additionally generates alerts to the console so you can follow up with the end user to see why or what they were trying to accomplish, and give them the policy violation spiel.
Your EDR should protect or at least alert against tampering to the sensor fwiw.
Does Crowdstrike have the anti tampering ability to prevent unloading its plist, deleting/renaming plist etc? And deleting the client directory?
honestly not sure but something you can for sure ask/test as part of your POC Heres what i see from Crowdstrikes customer accessible documents: Sensor Tampering Protections Windows: When enabled, it protects sensor related files, folders, and registry objects from renaming or deletion. MacOs: When enabled, it protects sensor related files and folders from modification, renaming, or deletion.
Can you provide the public sources you are looking at?
I specifically stated they are internal customer accessible KBs so no. Your a prospective customer, get on the horn with a sales person and theyll make it their life’s mission to get you answers if theres a chance youll pay them lol
If you have access to CRWD then why do you need public sources?
It seems he is sharing information that is not public.
Doesn’t matter really, the info is stored on the Falcon cloud for a year.
It should have. You should use both sensor tampering and uninstallation protection. If you are a customer, here are resources: [https://supportportal.crowdstrike.com/s/article/ka16T000001xjaZQAQ](https://supportportal.crowdstrike.com/s/article/ka16T000001xjaZQAQ) [https://falcon.eu-1.crowdstrike.com/documentation/page/e5c21607/prevention-policy-settings#if52e0a4](https://falcon.eu-1.crowdstrike.com/documentation/page/e5c21607/prevention-policy-settings#if52e0a4) I mean, it's kind of "new", it works with sensor version 7.10 or later and Ventura and later. The description of it in the prevention policy for mac "Blocks attempts to tamper with the sensor. If disabled, the sensor still creates detections for tampering attempts but doesn't block them. Disabling not recommended." That paired with, under Sensor update policy", Uninstall and maintenance protection "Require a token for the uninstall and maintenance on the sensor when not performed by the Falcon platform." I think you will be as protected as you can get.
The anti-tamper works well and have caught devs blaming CS for their crap not working (EDR tools are always to blame yes?) and thinking they can quietly disable/remove it, then you grab the corporate IT security policy docs out and start beating them up with it. Or the other way.."I'm sorry, we assumed you were an insider threat..so we contained your device. Get your manager to request an un-contain. Yes, you will have to explain why" If you have a SOAR capability, you can automate that whole process with API calls. CS APIs are freakin' great to work with.