At this point in time, it’s well understood that signature-based, endpoint malware detection is no longer able to detect the majority of threats being generated by attackers. In the last couple of years we have seen a variety of alternative approaches all focused on monitoring endpoint software behavior rather than relying on signatures. However, if the technical control software resides in “user” space, it’s actually adding to the attack surface. The attackers detect the control and either disable it or work around it. The only feasible solution is for the control to reside in the operating system kernel space and thus invisible to the attacker.
At this point in time, our cyber adversaries have rendered signature-based endpoint controls virtually useless. Persistent attackers have powerful automated tools at their disposal. Their attack methods rapidly evolve such that signature-based approaches cannot keep up. Endpoints that access the Internet are the easiest to compromise. It is simply not possible to block all malware. (That is not to say the Prevention controls are no longer important. They do reduce the attack surface and provide resistance to attacks.)
For an endpoint malware detection control to succeed in the current environment, there are two key properties it must have. First, it must be invisible to attackers. Therefore it must reside in the kernel rather than in user space. If it resides in user space, it can be detected, attacked, and disabled by the adversary.
Second, it must be able to detect a rich range of malicious behavior. Some are calling these behaviors, “conditions” for a successful compromise. For a real-world example of the relationship between a compromise and the “conditions” needed, think of a Molotov cocktail. The conditions for the explosion of a Molatov cocktail are Oxygen, a combustible material, a container, and a match. If any of these conditions are absent, the Molatov cocktail will not work. But while combustible material is surely a condition of a Molatov cocktail, if you find it in someone’s garage, you cannot conclude that the owner is planning on building Molatov cocktails.
An information technology example might be that malware must be able to write temporary files. However, good software might also need to write temporary files. On the other hand, it would be highly unlikely that a PDF needs to write a temporary file.
Therefore, a good endpoint malware detection control must be able to detect “conditions” of malware. However, just as noted above, a single indicator of malware is not enough to “convict” a piece of software. Once a condition/indicator is detected, that software in question must be watched carefully to determine if it’s really malware. The processing needed for this approach is significant, and if done on the endpoint, would surely degrade its performance. Therefore this type solution needs a console/server with significant compute power to monitor all of the endpoints exhibiting conditions/indicators of malware.
If you have a question or a comment, or would like more information, please let us know by completing the Contact Us box on the upper right side of this page.