An endpoint antivirus (called simply AV in this article) is able to run on any many computers as it needs, although it is managed from a single place. It monitors each stage of the execution of any processes on each computer and takes a decision if that behavior should be allowed or not.
2. How it works
An endpoint AV, as any endpoint tool, is usually based on the Agent Programming Paradigm, meaning that it has:
- a Server/ Management Console which defines the behavior of the AV for each of the endpoints, using policies and application whitelisting/ blacklisting.
- an agent (named “sensor”) running on each of the endpoints that does all the practical work for the particular endpoint where it is installed, independent of what is happening on the other endpoints. It connects periodically to the Server component to get any updated requirements, definitions about how it should behave and to let the Server know about any incidents and it is still alive on that endpoint.
3. Decision Taking
It takes a decision if that behavior should be allowed, based on:
- a series of metrics named TTPs
- configured policies
- application reputation
The decisions it can take usually vary depending on the tool, but you would want to look for these ones: terminate the application, deny the action, allow it, allow it but log it.
4. Whitelisting and Blacklisting
You would also want to be able to whitelist applications on top of the set policies (some endpoint AV tools apply the policies on top of whitelisting, meaning even if you whitelist a tool, if it does something unusual, its execution will still get blocked). You should be able to whitelist/ blacklist based on: process path, process reputation, certification used to sign the process, hash, parent process, parent certifications. In this way, you should be able to avoid getting legitimate processes blocked, such as the unsigned ones used by Windows or drivers. If you don’t have these capabilities and you want to lock the processes down, you will have a lot of trouble… If the tool supports wild cards, you want to be sure you don’t use them when whitelisting certificates and as much as possible you will avoid using them when whitelisting applications by path. In fact, you should try to avoid them at all costs, otherwise you will leave holes you will forget and not maintain. You could also benefit by having the possibility of automatically blacklisting applications that have a malicious score above a threshold you predefined.
Each application will have a reputation associated with it. If the process is trusted, the reputation will be good, if it is untrusted, the reputation will be worse. The exact implementation varies on the tool you use. You would generally want to have other reputation values available, such as what happens if the sensor does not know the reputation of some process because either it cannot connect to the server to find it out, or neither the server has seen that application before or reputations assigned internally for processes you created and use inside the company. Even more, you would find it useful to be able to set policies based on the reputation.
TTPs are metrics used by an endpoint AV to determine if a process behaves anomalous or it has patterns that identify with malicious reasons. They can also be perceived as descriptors of the process behavior that led to raising an alert.
Some TTPs you can look for: buffer overflow, beaconing, code drop, company blacklist, compromised process, code injection, memory snapshot/ dump of another process, email client behavior though non-email app, enumerate process, impersonating app, attempting to transfer files over network, file-less script, dynamic code, hidden processes, input injection into another process, modify permissions of another process, dropping a new app, connection with a peer of low reputation, attempt to control a Windows Service, using non-standard ports, attempt to monitor device inputs, attempt to start a less trusted app etc.
A policy will be applied to each endpoint. In that policy you will define the behavior of the AV on that sensor, meaning you will tell it which applications or behaviors to allow, which to deny, which to terminate and so on.
Shortly said, the policy matches the behavior of the application with the consequences. For example, if the application behaves as a malware, adware or untrusted app/ blacklisted app you might want to terminate it or deny its actions. You might want to be able to set policies also based on the application behavior, path, hash, reputation, parent reputation and so on.
You should be able to choose what happens with it depending on the kind of operations it does. You may look for the following:
- behaving as a malware/ adware
- communicating across the Internet
- trying to modify the memory or the execution of another process
- calling a process that is less trusted
- trying to execute scripting or code interpreters
9. Deny vs Terminate
The difference between these two is mainly if you would still allow that process to run or not. The deny value will deny the specific operation the process does at some point, but it will allow it to continue its execution even if it altered that bit. The terminate will kill the process. You may want to terminate the process when you’re sure they are highly malicious and whenever you can in general as this is the safest option. On the other side, if the process is legitimate, by choosing to terminate it, you will affect the person trying to use the application and eventually block it during critical business moments.
10. Other Features
You should look for the following settings and features as well:
- time or interval to update the tool and to update the signatures
- paths to be completely overlooked though this should be avoided at all costs because you will not have visibility on them
- seeing and alerting on misconfiguration such as sensors getting deactivated on some systems
- some basic templates for policies to help getting you started
- a way to notify you immediately if something of interest happens (based on actions, TTPs, the alert rating)
- a way to quarantine devices at request and automatically if malicious behavior is identified already running and not have been stopped because of any reasons
- eventually a way to get yourself into that device without infecting the rest of the network (by still keeping it isolated)
- you should be able to see details of the event with as much detail as possible; at the very least, the device name, the logged in user, the application name, the parent application name, the date and time, the reputation, the reason of raising the alert and so on
These should be enough to get you started in choosing the right endpoint antivirus. There is only one problem you will have though: even after choosing the tool you think would be the best, you will have false positives. Deciding if they are false positives or not, that is a tricky part if you don’t have other tools to help you, such as a host IDS to correlate what happens on that host, a network IDS and a SIEM to correlate the results from all these tools.