-
Notifications
You must be signed in to change notification settings - Fork 190
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
[DOCS] Endpoint artifact docs clarification #2111
Comments
@joepeeples and @jmikell821 - we see confusion from users around how the different endpoint "artifacts" work and should be used. Would love to get your thoughts on how we could add more specifics in docs (maybe a top level section or something for how to use these different configurations?) cc: @ferullo |
Should we document that users should refrain from adding system processes such as |
@caitlinbetz I'm excited to revisit our docs for these artifacts and making them more useful for customers. @jmikell821 and I will be collaborating on this issue in the near future and will use the details here as a solid starting point. @gabriellandau That sounds like a great detail to include as a tip or best practice. Is there an alternative strategy that we could recommend, something that would better target the kinds of attacks or exploits that use these system processes? |
hey @joepeeples just wanted to catch up on this one. We're really seeing a lot of need for this, and would like to make text updates in 8.5 that would link to this page. Let me know if you think that will work on your end! |
Discussed in today's feature sync; 8.5 sounds like a good target! |
Description
Users are often confused on exactly how endpoint artifacts work and should be used. We should maybe expand the existing Trusted Apps/Exceptions/Blocklist etc pages to add more specifics on their use cases and how they differ.
Event Filters.
These filter documents from being written to Elasticsearch only. They do not prevent Endpoint from processing the event data for possible alerting or general system state tracking. Because of that, Event Filters can't be used to lower Endpoint's CPU use. They only prevent Endpoint from writing a document to Elasticsearch. Almost all processing for an event has already happened before an Event Filter drops it.
Trusted Applications.
These prevent Endpoint from monitoring a process. They're intentional blind spots. No events other than process events are generated. Other monitoring for alerts - like Malware, Malicious Behavior, or Memory Threat alerts - is not done. Process events are still created to help render visualizations and understand process lineage in Kibana. Trusted Apps are to help deconflict with other software on the system. The classic example is two Antivirus products monitoring each other often creates a bad feedback loop. Trusted Apps also often help with performance issues since they inherently limit what Endpoint monitors on the system (a trusted app prevents Endpoint from monitoring that process.) As an inherent side effect of making a process a Trusted Process is that Endpoint won't produce alerts on what the process does, since Endpoint isn't monitoring that activity. This can lead to confusion making it seem like Trusted Apps are designed to prevent alerts.
A notable cause of confusion between Alerts and Trusted Apps is that since process events are still created for Trusted Apps, Malicious Behavior alerts that a triggered by process events still occur for trusted processes.
Alert Exceptions
These prevent Endpoint from generating alerts or preventing something. They're to address alert false positives.
Notably, alert exceptions can be created before an alert is actually generated. When monitoring activity to see if it should be prevented Endpoint checks exceptions as early as possible to help lower how much processing needs to be done. This means that if an exception is written to prevent Endpoint from generating an alert there's a good chance it will also allow Endpoint to avoid lots of processing.
Blocklist
Blocklisting was added in 8.2 to Endpoint as a secondary check while Endpoint is performing Malware protection. This was done to make sure that user blocklists couldn’t adversely affect Endpoint’s performance. User blocklist entries are checked when Endpoint is checking other Elastic-managed malware rules (i.e. the Malwarescore model and Yara signatures), so all Endpoint performance optimizations that prevent analyzing known-benign activity also prevent Endpoint for blocking blocklist entries that are also known-benign.
A different way to put this is that Blockisting allows a user to enhance Endpoint’s is-it-bad decision logic, but not overrule any existing is-it-safe optimizations. Blocklisting was implemented in Endpoint as a way for a user to add additional rules to block Malware, not to generically block applications that are not considered malicious.
The text was updated successfully, but these errors were encountered: