There are plenty of obvious questions you could ask an endpoint security vendor. But most won’t really help you understand the nuances of their approach, so we decided to distill the selection criteria down to a couple of key points. We’ll provide not just the questions, but the rationale behind them.


If your prevention capabilities rely on machine learning, how and how often are your machine learning models retrained?

An explanation here should provide some perspective on the vendor’s approach to math and the ‘half-life’ of their models, which indicates how quickly they believe malware attack behaviors change. Some espouse continuous retraining, while others maintain that very little changes daily, so it’s sufficient to retrain weekly or monthly. You’ll also want to understand whether model updates disrupt the end-user experience with significant downloads, restarts, or other intrusions on normal user activity.


How do your machine learning models factor in false positives and minimize them?

If a vendor claims they don’t have false positives, run away – quickly. Customer feedback and awareness of false positives are critical to keeping the products current, so get a sense of how they update their protection, models, and whitelists based on what doesn’t work in the field.


Does your agent work in user or kernel mode? Do you protect the OS kernel?

The answer is typically both, because some activities aren’t accessible from either user mode and others from kernel mode. For monitoring and EDR it’s possible to stay in user mode but if attacks need to be blocked there is a requirement for some kind of kernel access. This question enables you to get at how an EDR vendor has developed their offering to provide broader prevention.


Can you block an attack before it loads into memory? If so, how?

This digs into the vendor’s ability to block a file-less attack, a critical aspect of stopping advanced attacks.


How do you prevent an attacker from gaining root access to the device?

You are trying to understand the exploit prevention/blocking capability of the product; at some point to control the machine, an attacker will need root-level access.


How is threat intelligence integrated into the prevention agent?

This answer should be about more than getting patterns for the latest indicators of compromise. It should include the ability to block known bad IP addresses at the network layer, as well as cloud-based sandbox integration.


How often and how large are agent updates? How do you age out old signatures to conserve space? How are updates distributed?

Attacks change and machine learning models are imperfect, so agents need to be updated. Especially given that what’s old becomes new again, and care needs to be taken when specific signatures or behavioral models are no longer on endpoint agents. This question enables you to assess how the vendor distributes work between the agents and the cloud. It also gets at whether the vendor has a cloud-native management option, which wouldn’t require an on-premise aggregation point.


How does the product integrate with other enterprise security solutions, including SIEM and/or EDR?

If the vendor offers a full EDR capability use this question to figure out whether it’s a common agent between prevention and EDR, and the level of management integration. You can dig a bit into how the endpoint prevention product sends data to/from a SIEM, incident response, and network-based controls.


Does the product support automation? If so, how?

Given that you likely don’t have enough people to do what needs to be done, you’ll need to automate some functions as the only way to scale up your security operation. Some tools integrate with automation platforms (typically for incident response), while offering some auto-remediation for common problems (make sure you can control what gets done by the machine and what just sends an alert to a console).


Does the product support application control to lock down some devices? How are exceptions to the white list handled? Can you lock down USB ports?

For some devices it’s easier and safer to just lock them down and prevent unauthorized executables from running. This won’t work on all devices but having the option provides flexibility in designing endpoint controls. Likewise, locking down USB ports prevents a common mechanism of data leakage.

We could ask another couple hundred questions, but these ten should provide a lot of the insight you need to differentiate between vendors.

Next week we’ll post a similar set of criteria for Detection/Response. Enjoy the weekend!