I would like to invite you as a reader to take a deeper look at your perimeter solutions and their detection mechanisms. When you dig deep into the vendors’ websites or press releases, like I happen to do every now and then, you can find a lot of interesting information that some users are not aware of.
Specifically, I would like to draw your attention to the secrets of the detection mechanisms. As it appears from the vendors’ websites, most detection security solutions use more than one solution as their engines. Some hold an in-house-developed engine. Others only integrate external solutions into their infrastructure. You also hear about collaborations between vendors, that aim to provide you with stronger security. These typically market their solutions as even better, because “now you have five great engines that detect attacks instead of just one”.
On a first glimpse, it does seem great, that you can get several detection engines in one solution, but is this really the case? Let’s look at it from the vendor’s perspective – You now have several engines, with different levels of knowledge about how they work and operate, and you need to integrate them into one holistic solution.
Information loss on the path to one verdict
The first issue that comes in mind is that end-users should get just one decisive verdict: “passed” or “blocked”. In the case of using more than one engine integrated into one solution, you as a vendor, need to get a set of indicators from different engines and then combine them into a single verdict of “passed”/”blocked”. This means that the vendor needs to build some logic for it. Whether it’s a proprietary algorithm, a machine learning algorithm, a simple rule-based decisioning engine or any other method, it is not an easy task, especially when having a shallow knowledge about the other solutions you integrate with and the true meaning of the indicators. What we see happening here, is moving the problem to a different place, outside of the engines, and processing a set of indicators that might or might not indicate malicious behavior, to provide a definitive answer. Will you know what happens when “engine A” provides a set of indicators that, on a stand-alone deployment, would flag it as malicious, but “engine B” usually flags it as benign? Which one will you take?
Having another engine doesn’t magically increase the detection rate. In my opinion, it might be even worse when the vendor doesn’t have its own engine since the expertise is probably lesser in understanding and determining the true meaning of the indicators. The result of having too many sources of information is that some of the information is being lost.
Again, looking from a vendor’s perspective, you always measure your product economically. Running all solutions all the times is expensive, and for some cases, the license doesn’t permit to use the engine extensively. So into the decision mechanism, you have to insert financial or license restrictions which determine which solutions to use for each sample. The common way to do it is by characterizing the sample using static-analysis methods. For example, if a file contains a macro, you’ll act differently than in the case of a file that doesn’t contain macros. It gets trickier on advanced attacks when static evasion techniques are used (for example you can view our blog about a variant of CVE-2017-11882 “The Hawk in the NET (CVE 2017-11882) – Part 1“. In conclusion, this level of decision algorithm is complex and usually results in a lot of false-negatives.
It takes longer to get security and engine updates
Another problem in integrating different detection engines into one solution is the updating issue. Each detection mechanism, due to its reactive nature, is evolving and creating more indicators pretty often. Using a stand-alone deployment, the user may get those updates fast, but having it as an engine inside your product means that you need to know which new indicators were added, and adds it to the overall decision algorithm. Only then, you will get to use this update. You can imagine that it takes time to develop and test, and I guess I don’t have to tell you how risky it is to wait for these updates for so long.
So what’s the solution?
We, at BitDam, believe that these three issues are key reasons for why we see many attacks bypassing all those integrated detection solutions available today. Generally speaking, we’ve reached the times when deployment can be quick and easy (thank you SaaS!), so there is no reason not to choose the best of breed, instead of relying on your old trusted vendor to do it.
If you’re using one of those integrated solutions, I recommend testing how secure it really is. You can do this by using this free Penetration Test which takes just a minute (and is totally secure and private) on our website, or contact us for a more comprehensive PenTest.