Effective Detection and Response for Advanced Threat Protection
Are You Detecting The Right Events?
It’s become quite clear that inline prevention solutions, which block traffic identified as an intrusion attempt, cannot provide 100% protection. In fact, persistent attackers actually enjoy the immediate response they get from these solutions – leveraging it to test different attack vectors, until they find a way in.
Analysts and vendors realize that the next level in security will be to augment inline prevention security controls with “out of band” detection controls. These controls allow deeper analysis of communication layers and payloads to more effectively distinguish legitimate from malicious traffic.
Identification DOES NOT Imply Prevention
There is an important point that we security professionals sometimes overlook: the vast majority of intrusion attempts are unsuccessful. These attempts try to exploit a specific vulnerability that may exist in a small number of computers. So, most endpoints are immune against most intrusion attempts – and we need to keep this in mind when we analyze the effectiveness of prevention versus detection.
The goal of prevention is to block any traffic classified as an intrusion attempt. If it does this, it has achieved its design goal. Whether the intrusion attempt would have been successful or not is irrelevant.
And this is the catch: if the detection algorithms succeed, they will identify numerous intrusion attempts. Detection of these attempts, however, does not imply that the product actually prevented the attempts from succeeding. This may indeed have happened completely independently!
Too Many False Positives
When an intrusion attempt is detected, the administrator has to investigate the incident. In 99% of cases, it will be discovered that the endpoint was immune, and the alert was a false positive. The detection algorithm achieved its design goal – detecting an intrusion attempt – but was the design goal itself not flawed?
This has been a key point of contention in intrusion detection systems (IDS) for many years. Eventually, the technology split: the part that was accurate enough became preventive (IPS) and found itself as an integral part of next generation firewalls; the remaining part is essentially a noisy sensor, that feeds another set of SIEM products that most companies find relevant only for log retention and post-damage forensics.
What about Sandboxing?
Unfortunately, in recent months, more and more of our customers found that the above problem applies to sandboxing, too.
Sandboxing is a very good idea, if it can be deployed in blocking mode. If you could detect a malicious PDF file before it infects the targeted endpoint, this could be an important security add-on and offer significant improvement over signature-based antivirus products.
However, current exploits have learned to easily overcome inline sandboxing by delaying activity beyond what sandboxing products can afford before they must let traffic through. This forces sandboxing products to be deployed in detection mode, letting communications pass through and running the sandboxing out-of-band.
Why Sandboxing Creates So Many False Positives
Detecting a malicious PDF file without blocking it is not very effective. All you know is that an intrusion attempt took place. Now, you need to investigate whether it succeeded. And in 99% of the cases, the answer is no – either the user didn’t open the PDF file, or the machine wasn’t vulnerable. So you’ve created a false positive.
Thus, only months after deploying your new sandboxing solution, you realize that it creates a lot of additional work, and not a lot of value. You can’t chase down each and every alert, knowing most of them will turn out to be false, so you assume they are all false, and you end up sending those alerts into your SIEM – just like you did with IDS logs 10 years ago.
Here’s one good way to look at it: the amount of exploits and intrusion attempts that an enterprise network is exposed to these days is orders of magnitude higher than the amount of attacks these same networks saw 10-15 years ago. Then, firewalls were deployed to stop those attacks. And would anyone then have dreamed of deploying a firewall that would alert about suspicious traffic, but couldn’t block it?
The Takeaway: Effective Detection and Response to Advanced Threats
The amount of intrusion attempts on today’s network is so high that alerting about them without blocking them in-line is simply ineffective. And if you’re unable to block in-line, and choose instead to rely on out-of-band analysis and end user investigation and remediation – then your focus can no longer be on detecting intrusion attempts. Rather, what you need to do is to detect successful intrusions – what we at LightCyber call breach detection.