If you frequent tech forums, you probably see this question daily “Hey… what AntiVirus do you guys use/recommend?“. Most answers are dripping with bias, tradition, financially driven/misleading “3rd party” tests, and maybe a little anecdotal evidence – none of which belongs in a conversation about a constantly evolving threat landscape. In an effort to keep these issues out of this post, no specific names will be mentioned; however, references to specific techniques used by only a few products are fair game.
One of the first things to talk about is the differences between viruses and malware. A virus is a specific type of malware (all viruses are malware, but not all malware is a virus). In order to be considered a virus, the malware must propagate by injecting code into other (executable) files. This means that in order to spread to another system, those infected files must be executed on that other system. It isn’t a very efficient way of spreading now that sneakernets aren’t widely used anymore; and it can be fairly complex to build a virus (compared to other malware). It’s also fairly easy to detect and/or prevent this activity during the infection stage; with many modern operating systems natively throwing a wrench into this activity. This means that viruses are mostly a thing of the past. The most recent piece of malware that comes close to resembling a virus is the Emotet malware. While Emotet does have virus-like behavior, it uses that behavior for maintaining persistence; not for spreading. Due to the lack of virus prevalence these days, this article will focus mostly on malware and other threats. The assumption is that even if a new “next-gen” virus was developed, it should be handled the same as any other malware. Even if a product advertises itself as an AntiVirus, in order to compete in today’s threat landscape, it must at a minimum operate as AntiMalware software.
Areas of consideration
There is no cut and dry solution to security. No single solution can protect against everything. This means that what works well for one company might not work for another. Your best plan of action is to be aware of what is available, and evaluate what will work best for your environment. Here are just a few areas to consider:
- How reliant is the organization on endpoint security?
- How much does the solution impact performance?
- How stable is the solution?
- Is it easy to manage the solution?
- Are there compliance restrictions to worry about?
- How good is their heuristics engine?
- What is your tolerance for false positives?
- How good is their signature engine?
Reliance on endpoint security
Endpoint security sucks at scaling. Managing, evaluating, and building endpoint security is a significant part of my job; in fact, it’s one of my specializations – but it doesn’t matter what solution you use, there will always be problems when relying on infrastructure that is in the hands of end-users. If you are solely relying on your endpoint security solution to keep your infrastructure safe, you’ve already lost. The solution is Defense In Depth. Move your front line as far away from your endpoints as possible; preferably with as many layers of defense between your front line and your endpoint security as is feasible. This also helps when you think about the fact that when looking at the current threat landscape, only a small part of it is malware related. Will your AntiMalware stop your user from clicking on (and heaven forbid entering credentials into) that phishing link? Some might, but it’s not their primary function. If you stop your user from visiting a suspicious site in the first place, then they probably will not be downloading malware from it (which moves the first line of defense away from the endpoint). Many times your first line of defense will be your user training program. User training is great; it is absolutely necessary to reduce your low-hanging fruit, but it is not reliable. This is why adding additional layers of defense such as solid web/email filtering, IPS, UTM, (and yes, even AM), etc is necessary.
In addition, who are your target users? Do you have the ability to take their local admin rights away? If so, this lessens (although it doesn’t eliminate) your reliance on endpoint security software to help your users make decisions, since they will need to call for assistance whenever something attempts to use admin privileges.
Endpoint security takes resources away from your users. Even if it isn’t significant, there is always some performance impact. Users tend to inherently understand that, and will often perceive a much larger impact than is actually taking place (especially immediately after a noticeable change of any sort is made). One conversation that I had with an end user stood out to me when they noticed that the first picture on the homepage of their company’s website (which I had nothing to do with) changed around the same time as when we updated the AntiMalware to a (noticeably) newer version, and it made them think that the newly updated AntiMalware program was changing pictures in their browser. If you can notice an impact in performance from an endpoint security software, trust me when I say that your users will too. Minimizing the real impact (and even running your own tests to develop real world metrics on your endpoints) will help keep your users happy.
Software stability is probably the easiest thing for most technicians to test for. We’ve all seen what users can do to mess things up – just act like your worst user when using your test machine! Even if you manage to find a solution that can find 100% of the threats out there (hint – it’s not possible), if the solution is unstable but only runs 50% of the time, is it any better than the solution that finds 70% of the threats and runs as expected 95% of the time? Does it work when it is offline? Can it be easily updated on air-gapped systems? Can the user disable it? Does it have tamper prevention? All of these are important things to ask and test for when evaluating a endpoint security solution.
One of the most important qualities for enterprise endpoint security solutions is the ease of use for the administrator. The easier you can use a solution, the quicker you can react when there is a problem. If you are deploying a endpoint security software to thousands of endpoints, the last thing that you want to be doing is remoting into each of those endpoints to configure it. This isn’t just an issue for deployment, but what happens in a year when you need to renew your license? Do you need to remote into each of your endpoints to manually update that license information, or can you simply put it in the management console and let that do the work for you? If a user complains about popups… do you have to sit there waiting for the scan to complete, or can you kick it off from the management console and go about your day? Can you rely on the management interface to provide you with timely alerts when something is wrong? Will you even know when something goes wrong? Is the management console as stable when managing 5000 endpoints as it is 5? If even one of these questions is answered undesirably, then maybe this isn’t a solution that is ready for enterprise use yet.
Any schmuck can write a signature based engine. While signature based engines are easy to build, they fall short in today’s threat landscape. The true value of a endpoint security engine is the ability to identify problems without someone explicitly stating “this file is bad – don’t let it run”. This is done through observing behavior of programs, and identifying behavior that is common to malware but rarely used in legitimate programs. It goes by many fancy names (artificial intelligence/machine learning driven prediction, behavior monitoring, etc); but all those names really come down to one concept: heuristics. The ability to recognize that something seems “off” about software, and to block it based on that. These engines are still in their infancy; even though many variations have been around for years. The best way to test these engines is to write 0-day malware that it has not seen before, and see if it recognizes the behavior instead of just the file itself. This can be hard for techs who don’t necessarily have a programming background, so if this is outside your skill set, talk to people who have done these tests; or find 3rd party tests that focus specifically on 0-day malware instead of known malware. Make some effort to write something yourself though… even if it is as simple as a fork bomb; give it a test. If what you wrote wasn’t complex and the solution fails at stopping it, then you certainly know that it probably isn’t a good heuristics solution for you.
False positive tolerance
Frequent false positives lead to complacency. If users start seeing hundreds of popups warning them that something seems suspicious, they will start to ignore them. If used correctly, popups alerting users to a potential problem can be used as a “Just In Time” training tool; but there is a fine line between education and annoyance. You will always have some level of false positives when dealing with a strong heuristics engine, but finding the small amount of middle ground between wide open endpoint security and excessive “blocks” can be challenging. It will also depend on whether or not the user can override the findings. If the user can allow the software to run even if the endpoint security solution flags it, then the threshold for false positive tolerance needs to be set much lower than the average enterprise user who has to call the helpdesk if something legitimate is being blocked.
The primary factor for a signature engine’s quality is based on speed. How quickly does the solution find new threats and send out definitions to block them? Some may argue that since our focus should be on heuristics, signatures don’t have any place in modern endpoint security. I have yet to see any heuristics based endpoint solution (including very expensive “next-gen” enterprise solutions) correctly identify and block 100% of the 0-day malware samples that I develop for testing that solution. This means that we can’t rely 100% on heuristics-only engines. If you have enough layers of security above your endpoint security that can block threats based on signatures, then a heuristics-only solution might be perfect for you; but the last thing that you want to do is wait for a endpoint security vendor to be researching how to use heuristics to block the latest malware that their solution missed (and then update the solution) while the latest malware is ravaging your network. Instead, finding a good balance of primarily relying on a heuristics engine while still being able to quickly push out a definition to the solution that says “hey… this hash [or whatever] is known to be bad – make sure to block it” is key when you are relying heavily on endpoint security. Of course, you can go the other way with signatures too – instead of defining known bad files, you can define known good files and block everything else (application whitelisting). Speaking from a lot of experience in this area, managing a whitelisting solution requires lots of tedious work, a solid deployment plan, ability to develop your own automation processes, a solid background in malware analysis, lots of research into finding the correct platform, and enough leverage to ensure that when (not if) your users complain, you have the power to enforce company policy. This also means that you must have a very high false positive tolerance, and a plan for edge cases.
If you want to find the best AntiVirus, AntiMalware, Endpoint Security, etc for your company or client, you need to evaluate what you are looking for first. Don’t rely on other people to tell you what the best solution is; because they don’t know your situation, and there’s a good chance they are wrong. Don’t rely on tradition to tell you what the best solution is – your threats are constantly evolving, why shouldn’t your security? What was the best solution a year ago might not be today; and what wasn’t even in the running 30 days ago might be cutting edge tomorrow.