They’re baaack: Using responder feedback to detect repeat infections

Red Canary’s purpose is to perform world-class endpoint threat detection more accurately and against a broader spectrum of threats than anyone else. To do this, we continually invest in additional detection technologies and process improvements. Our newest feature sits squarely between both of these buckets.

You can now mark detected threats as remediated to tune Red Canary’s detection engine and ensure that you’re accurately informed if the threat resurfaces. Why is this important? Allow me to explain . . .

The “standard” way of handling threat remediation

An important consideration when detecting threats is how you handle threats that have been remediated. This is straightforward and mechanical with most products: An alert or group of alerts represent a potential threat. If confirmed and remediated, those alerts are dispositioned and removed from view. All the while, detection systems are wholly unaware of the status of the affected endpoint.

This model must change when you perform endpoint threat detection, particularly when using voluminous telemetry coupled with enrichment data and other context. When detecting a malicious process, for instance, that process might be executing repeatedly. Between the time an interesting process executes for the first time and exhibits threatening behavior, we may have seen hundreds of occurrences.

The Red Canary way

Fortunately, we built a platform expressly to handle this type of thing. When a process spawns and is tracked by our engine, we can collapse many instances of the process on that endpoint into a single event. We then continue to append instances to that event as decisions are being made, even after we have notified the customer of a confirmed threat. This eliminates a tremendous amount of noise for our customers (and our analysts) because one malicious or unwanted process on a given endpoint will result in one detection. The fact that it continues to execute will be represented, but never in the form of many published detections.

A brief aside: This logic only applies to specific types of threats: Malicious Software and Unwanted Software detections are tied to specific pieces of software (“binaries”) and thus this model works well. Red Canary has a third classification, Suspicious Activity, that primarily identifies misuse of native and/or sanctioned utilities. We do not automatically append events to Suspicious Activity detections because we need to see all instances of these things in order to make threat determinations. We’re proud of the product that our technology enables: Analyst-confirmed detection details at a rate that every one of our customers, from the smallest to the largest, can digest. But there is always room for improvement.

Effective immediately, customers can provide direct feedback to our platform and improve detection accuracy by marking detections as “remediated.” You’re probably thinking: These guys are writing about marking a detection as remediated? Yes, we are, and here’s why:

When a customer resolves a threat and notifies us that it is remediated, all auto-append rules within our engine will be reverted, treating that threat on that endpoint as remediated and thus allowing re-infections or incompletely remediated infections to be reviewed by our SOC and re-alerted immediately.

The result is a system exceptionally well suited to perform its filtering and correlation function at scale, but also able to accept feedback from responders in a manner that is both simple yet granular and thus highly effective.