What Sets Falcon Apart: Intelligent Host Sensors

December 08, 2015

| danbrown | Endpoint Security & XDR

It can be difficult to distinguish between “next-generation” endpoint security solutions currently available.

Usually the technology lags marketing by a significant margin, and the marketing mostly sounds the same.

But important differences lurk beneath the surface.

When the wrong choices are made in the design of a solution, those design decisions impose lasting limitations on the system’s capabilities, with the result that the vendor and its customers must work around those limitations. Those workarounds mask the limitations of the solutions, which is unfortunate, since those limitations can (and do) make the difference between accurately detecting attacks and not. One limiting design decision that is prevalent in this market is the “dumb sensor” model. In this model the endpoint sensor does little or no processing, but merely collects data and sends it off to a server for analysis. This implicitly precludes

the sensor from providing any form of prevention. The design choice to send data off to a server rather than processing it on the endpoint is a huge missed opportunity. Security products in this position can and should add protective value. It’s worth comparing this to a more sophisticated architecture, such as CrowdStrike Falcon® next-generation endpoint platform, that supports data processing and decision making on the endpoint.

This enables not only highly accurate detection and prevention, but also intelligent filtering that determines which data should be made available to the analyst and under what conditions.

This helps with incident prioritization and reduces alarm fatigue. Achieving all this in a lightweight sensor is not easy, which explains the popularity of the dumb sensor model.

The accomplishment of a smart yet truly lightweight sensor is a testament to the first rate R&D organization at CrowdStrike. Detecting browser exploits is a useful example to illustrate this difference. In the dumb sensor model, a browser exploit detection might look like “an unexpected process was spawned by a browser”, which is very false positive prone, but this is the best that the dumb sensor can do since the most granular data available is process information. A smart sensor, on the other hand, has access to more granular information, such as thread activity.

This allows the detections to be far more discriminative, such as “an unusual process was spawned by a browser’s Flash plugin thread”.

Since there are orders of magnitude more threads on an endpoint than processes, sending threads to a server and generating the detection there is not just inefficient for a dumb sensor model, it’s a non-starter given the overwhelming data volume required to be transmitted. In other words, in that model an accurate detect of this sort is not just infeasible, it’s not possible.

Additionally,

if your only behavioral detection mechanism takes place on the server, you can’t prevent those behaviors. In the dumb sensor model you can’t detect unsigned processes accessing files that contain sensitive data, because the volume of data implied is, like the previous example, too prohibitive to collect in a generalized fashion.

On the other hand, a smart sensor can be programmed to detect the specific conditions that indicate malicious behavior, and send along only the relevant data.

I should point out that this does not preclude proactively sending along data that is relevant for hunting, visibility, and incident response purposes (which is also collected by CrowdStrike Falcon®), but that this subset of available data should not form the limiting bar on the detection capabilities of the platform, which is all too often the case. This is an important point that is worth highlighting. Detection and prevention should not be limited to acting on just the data that is reported for visibility. The examples we have outlined so far are very simple examples of the improved capability allowed in the smart sensor model.

There are, in fact, whole classes of detection that require gathering additional information in certain circumstances that are impossible without a smart sensor.

One specific example implemented by Falcon is detecting and preventing side effects of common return-oriented programming (ROP) gadgets that are used in many exploits, which requires selectively accessing additional endpoint data under certain carefully chosen circumstances in order to detect the malicious behavior.

Once again, this is not possible in the dumb sensor model.

A smart sensor can also report this type of data to the analyst that is otherwise too verbose to send using the dumb sensor model. The deficiencies of the dumb sensor model are often overlooked because a marketing-level view frequently does not make them apparent.

But evidence of the use of this model is apparent if you know what to look for.

Vendors that use such a model stress manually-intensive incident response, integration with other (FP-prone) alerting appliances, and (you the customer) rolling your own detection logic - all of which is evidence of the limitations inherent in that model. It is important that the end result of the design process be technology that “just works” and makes the analyst’s job simpler instead of adding yet more data sifting to their workload.

Making the technology work should not be the job of the customer.

The differences are technical, but they matter.

Detection and prevention matter.