Poor business decisions can be very costly, especially in cybersecurity, where labeling clean items as malicious, or false positives, can be very damaging.
So, how can you simultaneously keep the error rates low, uphold detection rates and keep protection strong? With a combination of a well-tuned security solution and experienced human supervision.
In the cybersecurity universe, everything revolves around one basic question: is the detected sample malicious or clean? As in life, the answer is more complicated than just these two options, creating a vast grey area where good and bad things resemble one another.
Established cybersecurity vendors, such as ESET, have to navigate that dilemma every day. With a growing number of clients in its global network, the number of items that need to be evaluated increases along with the risk of causing so-called false positives (FPs).
In cybersecurity, this term describes the errors when a protection solution incorrectly labels clean items as malicious. This leads to them being quarantined, blocked or deleted. However, many post-truth vendors choose to downplay their importance, emphasizing their machine learning (ML) capabilities instead.
Now, not every false positive necessarily means total collapse for a business’s IT infrastructure. Some errors only have a minor impact on daily operations and can be resolved by adding a simple exception. But other glitches can disrupt business continuity and thus potentially be even more destructive than an actual malware infection.
Aggressive detection can cause a flood of FPs
Most businesses use general-purpose systems –in other words, endpoints – that need to communicate with the “outside world”. With the current trend of non-static incoming data, it is very hard to predict how all clean inputs should look. And now that apps have morphed into mere executors, every data input can potentially turn them malicious and thus needs to be monitored and correctly labeled.
Using aggressive detection – seen in some solutions made by post-truth vendors – does not resolve this situation. On the contrary, in such conditions, aggressive detection can lead to an alarming rate of false positives, overburdening the IT department and rendering workstations unusable. This would lead to financial and productivity losses for a company – which can be simulated in our simple calculator (see below).
What’s worse, with tens or hundreds of false alarms, admins would only have two choices: keep the settings strict and waste time dealing with the FPs, or loosen the protective setup, which at the same time would likely create new vulnerabilities in the company’s systems.
You have to ask yourself, how difficult would it be for attackers to provoke and exploit such a scenario if an aggressive solution were in place?
Why you should care about false positives
Besides dysfunctional endpoints, there are other worrisome scenarios caused by false positives. Just imagine an automotive factory halting production because its security solution labeled part of the production line’s software as malicious and subsequently deleted it. A “glitch” like that can translate into massive delays and millions of dollars in financial and reputational damage.
In such situations, a quick fix is needed. However, a protective solution that relies heavily on unsupervised machine learning – as many post-truth vendors say they do – can lead to painfully long update sessions. This is because the ML model requires both an update and then needs go through another learning phase to distinguish correctly between clean and malicious items.
Errors in the evaluation of samples can appear in machine learning solutions as early as in the learning period and, with no oversight of the process, can stay there for an extended period before wreaking havoc.
Reaching equilibrium
So how can a business achieve equilibrium, where it protects itself from malicious items and minimizes false positives to a manageable level? Honestly, it would be easy to achieve 100% detection or 0% false positives, but it is impossible to have both at the same time.
Some IT environments require 24/7 monitoring, and a responsible person who can react almost instantaneously to any suspicious activity or security notification. This is certainly the case for sensitive systems – such as the car factory scenario described above.
In restrictive environments – such as bank employee terminals, with identical devices running only a limited set of applications – admins can opt for whitelisting. This allows them to create a detailed list of authorized actions and software. Anything off the list gets blocked, regardless of whether it is clean or malicious.
This “whitelisting lockdown” reduces the attack surface significantly and minimizes false positives, but it also shrinks the functionality of the system and is not applicable universally. Another limit to this approach is that blocking automatic updates can force endpoint users to run a vulnerable version of the app.
“Smart” whitelisting, with defined exceptions for updaters, paths or file names, can circumvent this problem, but can also open the door to attackers.
What is best for you?
Almost every business in the world uses a unique mix of software and solutions within their network. It is therefore up to each business to decide how restrictive its systems should be to achieve the desired level of protection.
If the system can be stripped down to minimal functionality, it lowers the attack surface, but leaves a lot of legitimate activity and files out. On the other hand, for some businesses a false positive would have a higher cost than a potential infection, which forces them to take the risk.
The most effective way to protect general-purpose systems, networks and/or endpoints is to deploy a well-tuned security solution (with high detection ratio and a false positive rate close to zero) and to supervise it with experienced administrator(s) who can take care of the rare cases when FPs occur.
Some post-truth vendors might argue that by implementing machine learning they can avoid the need for this “human variable” in the equation. However, ESET’s experience shows that it is crucial to use machine learning within the right boundaries, and correct its possible errors.