Posted under: Research and Analysis
After exploring prevention approaches, you should understand some common technologies which are foundational to endpoint advanced prevention offerings.
Machine learning is a catch-all term to indicate that the endpoint protection vendor uses sophisticated mathematical analysis on a large set of data to generate models for detecting malicious files or activity on devices. There are a couple mathematical algorithms which can improve malware prevention.
Static file analysis: With upwards of a billion malicious file samples in circulation, mathematical analysis of malware can pinpoint commonalities across malicious files. With a model of what malware looks like, advanced prevention products then search for these attributes to identify malware. As mentioned earlier, false positives are a concern with static analysis, so ensure the models are constantly being tested; and static analysis should be one data point among several for detecting malware.
Behavioral profiles: The behavior of malware can also be analyzed and profiled using these machine learning during dynamic analysis of malware. Profiling the behaviors of malware provides a model that can be used to look for malicious behavior during attack execution.
Those are the main use cases for machine learning in malware detection, but there are a number of considerations including:
- Targeted attacks: Over recent years attacks have increasingly been targeted, so it is useful to distinguish attack delivery from device compromise. Targeted attacks use custom (and personalized) methods to deliver malware, but once it’s on the device it’s much like any other malware. Vendors can train their machine learning models on all available malware samples.
- Cloud analytics: Developing machine learning models of malware is very compute intensive. (This is different than applying those models to evaluate files or activity on endpoints, which can run locally). Cloud computing is the most flexible way to access that kind of compute power, so it makes sense that most vendors perform most of their machine learning in the cloud. But where analysis takes place doesn’t really make much difference. The focus of your evaluation should be the verdicts drawn and how accurate the models are. We’ll dig deeper into the cloud’s impact on prevention next.
- Sample sizes: Some vendors will claim that their intel is better than another company’s. That’s a hard claim to prove but sample sizes do matter. Looking at a billion malware samples is better than looking at 10,000. Is there a difference between looking at 100 million samples and a billion? That’s less clear, and a larger sample size utilized ineffectively will cause a lot of false positives. So evaluation of these approaches needs to be focused on effectiveness, not merely sample size.
- Positive and negative training: The great thing about machine learning is that you can profile anything. It doesn’t need to only be malicious code, and in fact behavioral profiles for applications are built by analyzing legitimate behavior. The models should evaluate both positive (normal) and negative (‘bad’) attributes and behaviors to improve accuracy.
- Data collection/retention: Another consideration is where they get malware samples. There will always be a base of samples assembled and shared among vendors. But relative effectiveness is determined in the margins. Where are vendors getting unique samples? How do they age them out?
- Retraining: How often models change is another important consideration when comparing machine learning approaches. Are vendors running models daily and updating detection? Is it a monthly thing? There isn’t really a right or wrong answer but understanding the vendor’s mindset provides perspective on how they believe malware works and their most effective detection methods.
There is this thing called the cloud – you might have heard of it. But the fact is that every endpoint security vendor needs the cloud to keep pace with attackers and competitors.
There are a few areas to dig into, regarding how a vendor leverages the cloud:
Signatures/rules: It’s not possible to keep all file hashes and attack indicators on every device, so vendors typically cache a small subset of rules and signatures; if a file or pattern isn’t known, the endpoint can send it up to the cloud for analysis to provide a verdict on whether it’s malicious or not. But of course you want to prevent attacks whether or not endpoints have access to the cloud, so comprehensive offline support is important.
Machine learning: Some vendors have their own data lakes and associated analytics capabilities to support machine learning. Other depend on cloud computing providers. There isn’t a single right answer, although it’s hard to see how it makes economic sense for a vendor to maintain an analytics cluster running in their own data center today. This is really about the future, and how each vendor plans to scale their analytics, because the only thing we can be sure of is that there will be more security data to analyze tomorrow than there is today.
Management: At this point vendors should provide an option to manage endpoint agents, define policies, and investigate attacks via a cloud-based console and service. Given the remote nature of many endpoints, and the fact that keeping devices up to date is a critical facet of endpoint defense, a cloud console is table stakes. This also means you don’t need to stand up a management server to deploy and manage endpoint agents. You should also expect a vendor to distribute updates to their agents automatically via their cloud service, with an option to vet updates before deployment. You may also want a hybrid alternative (on-premise or cloud) for environments where storing sensitive data in the cloud is a problem.
As critical as the cloud is to scaling endpoint security and to keeping pace with attackers, there are some cloud security questions you should investigate.
- Authentication: The vendor should support multi-factor authentication to access the console. It seems obvious, but ask anyway.
- Data security: You will have proprietary data in their service (if only a list of employees), so you need to figure out how they protect your data. Find out what kind of encryption they use and whether it’s built into the back end of the technology stack or just at the network layer.
- Data privacy: Hand in hand with encryption is support for multi-tenancy. Make sure you understand how they keep your data isolated from their other customers. And no, providing a login and password for each customer isn’t a great answer.
- Logging/PUM: Once you move a lot of management of endpoint devices to the cloud, you need to ensure sufficient visibility into what changes are being made in your environment. This is both a way to be on top of potentially faulty changes (inadvertent errors) and a tool for Privileged User Monitoring (PUM) of personnel could turn off protections as part of an insider attack.
- Penetration testing: You’ll also want to make sure they aren’t just breathing their own exhaust about their security, and actually have professional attackers trying to break it. They are security folks – they should know all about red teams, and they should eat their own dog food and try to break their applications. If they don’t have an internal red team tasked with trying to break their own environment, as well as a team of hunters making sure adversaries haven’t compromised their systems (with your data in them!), they are doing it wrong.
- Data migration: Finally, selecting an endpoint prevention product should not be a lifelong commitment. You will want to understand how you can get your data out, in case you want to give them the boot and pick someone else. There is also psychological value to making sure the vendor knows they always have to prove their value or you’ll kick them out – be sure to harp on this one a bit.
It’s a multi-platform world, and your endpoint security strategy needs to factor in not just Windows devices, but also Macs and Linux. Even if these platforms aren’t primary targets they could be repositories, used as staging grounds and file stores in sophisticated operations.
But the reality of multi-platform support is that there are different levels of both need and opportunity for vendors to prevent attacks on the various operating systems. A vendor has more limited access to the kernel on both the Mac and Linux than Windows, which influences which kinds of prevention are possible. For example Mac agents tend to focus more on detection/response because of limitations in their ability to prevent attacks. Likewise on Linux (if the vendor even supports it), endpoint security tends to boil down to preventing privilege escalation. Digging into the specific capabilities of a vendor for each of your platforms will also enable you to sniff test whether they understand the technology nuances.
Also dig into how vendors leverage built-in operating system services, especially on Windows with its extensive exploit protection capabilities. There are certainly factions within the security world who don’t believe you even need an endpoint agent on the latest versions of endpoint operating systems, that using exploit protection and least privilege on devices locks them down sufficiently. Use this as an opportunity to understand how the vendor positions its value-add, above and beyond the operating system.
Mobile devices are also a consideration in a multi-platform world. These devices clearly have access to critical enterprise data, although specific attack vectors and protection models are still being debated. We won’t consider mobile threat defense as part of these selection criteria, but for many organizations an integrated capability is an advantage.
It should be obvious, but devices agents are also targets. Malware writers spend time to determine which endpoint protections are in place and how to neutralize or compromise them. If malware detects it’s running in a virtual environment such as a sandbox, it won’t execute.
So ensuring that your endpoint security agent is tamper-proof and protected is critical. Make sure you can quickly tell when an agent is running on a device, and throw an alert when it’s off. Make sure the vendor performs frequent application security tests against its technology, and checks for a heartbeat from each agent to ensure it’s still operational and working.
Historically, malware detection has been based on looking for an attack on a single endpoint. The agent would evaluate the activity on that endpoint and look for malicious behavior. To refine that approach endpoint prevention products added threat intelligence, so new attacks could be detected even before they were seen by a specific organization.
But adversaries have gotten increasingly sophisticated and attacks rarely (if ever) involve just one endpoint. Detection needs to evolve to evaluate activity not just within a single endpoint, but across an organization. Optimally, when deciding what activity to block on a device, context beyond a single endpoint should be considered.
Very sophisticated enterprise-scale analysis tends to be associated with EDR (Enterprise Detection and Response) offerings, which we’ll discuss later in this Buyer’s Guide. If you are looking only at prevention technology (presumably to replace existing anti-malware), you’ll be looking more at a lite EDR capability, which involves gathering some telemetry and using that to correlate alerts among a number of devices. You’ll also want some semblance of retrospective search, which enables you to look for activity on other endpoints, once you detect an attack on one of them.
Next we’ll cover the Top 10 questions you should discuss with potential vendors. This is as much a review as a comprehensive list, but after getting thumped the past 4 days with a prevention blitz, we figure it’ll be nice to revisit the high points.
*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by firstname.lastname@example.org (Securosis). Read the original post at: http://securosis.com/blog/endpoint-advanced-protection-buyers-guide-key-prevention-technologies