Examining the endpoint security opportunity

Keith McCammon

Share this Project

This week Network World reported on the “Massive Enterprise Endpoint Security Opportunity.” The premise is that, despite a very active Endpoint Threat Detection & Response (ETDR) market, companies still struggle with significant coverage gaps. In an ESG survey of security professionals, two data points emerge:

  • 63% believe that “[t]here is no endpoint security vendor that delivers a product suite that could meet all of my organization’s endpoint security requirements.”
  • 41% believe that “[w]e really can’t secure endpoints as we’d like to because endpoint security requires too many specialized products/agents.”

The first should come as no surprise. Endpoint security should be addressed in depth, not via a single product or suite. Hardware and firmware must be verified and trustworthy, the host operating system properly configured, users provided with the tools and capabilities that they require within the confines of least privilege, and data secured both in transit and at rest. These are only some of the preventative considerations, to say nothing of detection and response.

The second statistic is significant. It is expensive to identify and operate the vast suite of tools required to properly secure the endpoint, then detect and respond to inevitable compromise.

Let’s look at a simplified matrix of tooling required to address threats beginning with the delivery phase of the cyber kill chain. Note ahead of time that this matrix is exhaustive neither in classes of tools nor in their potential applications. It is, however, intended to highlight some of the tools without which one would find it difficult to address threats at a given stage.


That’s a lot of moving parts and each is generating a lot of data.

The reason for this is that there are multiple classes of information required to ferret out attacks as they progress. Earlier stages demand a thorough examination of inbound data, primarily for purposes of identifying malicious software. This is a rapidly evolving game of cat and mouse, and the assumption must be that this is preventing some, but never a “good enough” percentage of malicious payloads.

The middle stages require a mix of malicious software detection and detection of a wide variety of behaviors. These may be things as simple as service registration or persistence via autoruns. Then, they may be things as complex as cross-process events followed by command chaining via tools native to the target system.

And in the latter stages, particularly when facing a skilled adversary or a hostile insider, the organization is effectively looking for subtleties. These may be legitimate accounts and services used in ways that deviate ever so slightly from expected patterns. Data exfiltration not through FTP or even outbound TLS connections to co-opted sites, but via things as simple as an email attachment sent from a compromised account to one of the myriad free mailbox providers.

The tools required to address these issues must be prioritized based on relevant threat models, scoped, assessed, implemented, and then (this is critical) backed by personnel who have at their disposal the expertise, context and time required to set aside false positives and find the needle among a veritable stack of needles.

So, in a bit more detail that we get from the source article, herein lies the opportunity. And it is indeed massive. Because the solutions will not only eliminate a tremendous amount of complexity but also free up staff cycles to focus on the smaller percentage of confirmed threats versus the firehose of a feed to which they’re currently subscribed.