Hello,
For anyone reading this,
before continuing to read my post just remember that
everyone has their own opinions and standards for an Antivirus/Internet Security product. Bear in mind that I am already aware that some points in this post I have written have already been commented on by other members, however I always prefer to start from the beginning and so this is what I will be doing in this post.
1). RAM USAGE & CPU USAGE
ESET Smart Security has good RAM usage in comparison. About 120MB RAM is good compared to what it could be. As far as I am aware, ESET is good with the CPU usage, too... Of course in cases like when it is running a scan or updating then the CPU may become very high.
The memory usage can be improved by closing the User Interface. If the product is properly developed, this won't effect your protection... The services for the protection should still then be active, and when an alert needs to be displayed or anything regarding the User Interface, it would be reopened for you...
2). DISK SPACE
330MB is not a lot compared to other products and what it could be. Just remember that as the product improves (introduces new features, bug fixing (sometimes may not always increase file size as they may remove things and recode it resulting in less code), or other things like database updates) the disk space may increase. ESET add detections every day for new threats; thus resulting in a larger database of threats to be detected with static detection (static detection is detection based on scanning without executing the sample).
For example, someone submits malware to ESET. ESET analyse it and find it to be malicious software. Then they add it to their database. Then they release an update after they reach A amount of new submissions to the database in that day. ESET product installed on the users system checks for a update at a certain interval and then see's there is a new update. It then starts to download the update - as a result, the CPU usage of the product on the system will increase. After the download has completed it may do some more things to finish the installation of the signatures. The disk usage would have increased since the database became larger, and the RAM usage may also increase generally speaking if ESET loads in that new database (as well as keeping all the other signatures they had loaded into RAM). Remember though, products like Emsisoft use a lot of RAM but they use a lot of signatures (Emsisoft uses more than 6 million. I do not know the exact numbers). ESET may not load all of their signatures in, but only when they need too, or they may load a certain amount and then unload them, then proceed to load the rest. So they may split up the loading into sections: they load in X amount ... Compare with the file. Then they may load in X amount again and then rescan. And so on until they have scanned with their database completely (which the product uses). This technique may increase the scanning times, as well as potentially the CPU usage (CPU usage because it's carrying out more actions). > this is an example. I don't work at ESET so I don't know how they actually work the updater.
From time to time, the vendors may clean up their database. As false positives are found, the database size may decrease. Meaning the database sizes on the users system will also decrease once they receive the update with the removed false positive signatures.
3). SCANNING TIMES
In this test the scanning time was about 14 minutes (taken from the Good/Bad area. I did not re-watch the video to check so hopefully it was accurate). This is not "slow".
I noticed someone mentioned Emsisoft scanning times. I shall quote them and talk about scanning times a bit more.
emsi quick scans takes less than 2 minutes, may be 1 in a fast pc. (on my end 1:28)
There is more to scanning times than the timer counter.
Every vendor is different. For example, ESET most likely do not email Emsisoft telling them all the areas they may scan on the system. Of course a company could just watch the paths and log them down (or the paths accessed) during scanning, but... Point being, each product may scan in other areas.
Typically, most of the time a Quick scan may include some/areas in the Windows directory (like System32), AppData, the root of the drive/s, ... Like I said, each product may scan in other areas.
Scan times depends on many factors:
- Amount of files needing/being to be scanned. For example, since they may scan other areas, there may be a different amount of files required to be scanned.
- File size of the files needing/being scanned. If the file size of the file is very large, the scanning times for that particular file may take longer. Meaning it would slower down the scan overall (since the time to scan that would is counted).
- How the files are scanned. Depending on how the vendor decides to have the product programmed to actually scan the files may determine between the scanning times. If the product just grabs the SHA-256 or MD5 hash of the file and then compares it to a database in a file, then the scanning times will be faster than a product which may do this as well as performing in-depth analysis on the file.
- Amount of threads used in the product. People may not understand what I mean, however there is something called "multithreading". One product may use more threads than another. As a result, the product using more threads (if they are used correctly) may be able to scan more files quickly, but a disadvantage result to this would be a increase of CPU usage.
- How the database/s are managed. Does the product load the database in at once, or does the product load in a certain amount and then scan the file, then unload that and load in more and then rescan the file, and continuously do this with one file until the database has been all scanned with the file? If a product does this, of course the scanning times will be increased... However, it would be better for system optimisation in terms of RAM usage. CPU may increase when doing this since the product is doing more calculations/actions.
There is just so much to determine for the scanning times. Don't judge a product due to it. I can tell you one thing for sure which is a fact - I would personally rather a product take longer than another product to scan to find a real threat on my system. For example, the faster product may find nothing. Then the slower product may end up finding a serious infection on my system. I'd rather have the slower product (as long as I know that I can trust it, it has a good repuation and I have a good personal experience with using the product in the past), than the fast one. Because chances are, the product scanning more files and in more areas and doing a more in-depth analysis on the system is most likely to find an infection. Although that's not to say the quicker one won't, I am just saying in terms of this as an example.
(
@gricardo21 this is not specifically aimed at you. You may already know what I mentioned above, I mentioned it as others may not).
4). BOOT TIMES
Boot times may be increased due to many reasons (like with the scanning times). Although, ESET adding an additional 15 seconds is not the end of the world. Other products may take longer. (don't worry
@Av Gurus, I am not saying you were saying it was the 'end of the world'. I am referring in general to anyone reading this who may think to themselves "That is so bad! ESET is an awful product now"..).
Unless someone is in a hurry and need to get some important documents off a system in less than 30 seconds then there should be no issue with waiting 15 additional seconds...?
5). Synthetic test
You may as well just not bother with this to avoid for arguments sake. You'd be better off using real threats which do the same thing (so keyloggers but not "test" ones). Then you can see if the product really does protect from it.
But truth be told, they are just tests at the end of the day. So information in
@tonibalas post is true.
At the end of the day, I don't see how a product would be able to protect from threats like keylogger in real-time with the BB/HIPS if it doesn't detect the synthetic test. I believe this because the synthetic tests are desinged to be like malicious software. Commonly, the products would detect such threats through hooking. This works by executing X code when API B is called. So a product may call a API to steal keystrokes typed by the user on the system and then as a result the function may be hooked and in result suspend the process threads of the process which called the function, show an alert to the user asking if they want to allow or block. If they click allow, then return back and allow it to call the function (as well as "resuming" the process threads of the targetted process) and if they click block then terminate the process from memory and/or remove it from the system (which may result in "special" techniques to clear the malware off the system - may involve overwriting of the file muliple times (possibly 10, possibly up to 30 or more) and then removing it. There is a lot to making a file "unrecoverable", so I'll keep that separate from here and leave the information I just wrote).
Then a real keylogger may come along and use the same API call that the tool in the Synthetic test used, but then it shouldn't be detected if the synthectic test tool was not detected... Unless it whitelisted the tools in the synthectic test. But, this should not happen with HIPS/BB because HIPS/BB should work by alerting regardless of whether it managed to detect malicious or safe components in the application.
Of course in some cases the product may not block the Synthetic test and may protect in the real-world. It's true, it does happen.
6). Self-defence
First up, if the User Interface process is terminated this is not much of a "security risk". The only issue I can see with this, is if the alert was linked to the UI process and needed to be shown but could not be because it kept on becoming terminated from memory due to malware. In the case of this, the service used for protection could leave a counter and count up each time the alert is terminated before the user could decide the action they wanted to make. Once it reaches the maximum counter, set protection for that UI process until the user has proceeding into deciding the action. I do not know if ESET do something like this, I have never purposefully tried to see how it would react in this case. I mean in some cases it could be a "security risk", but in this case it is not.
However, if a product is set to "Auto-Quarantine" then there should be no issue in terms of protection with the UI process being terminated. The threat which was found would have been at least dealt with. Chances are the product may log which processes are trying to terminate it, and may turn on it after a certain amount of times if it is not a known legitimate and safe program (or part of the Windows Operating System provided by Microsoft; for example it could be Task Manager but this is by Microsoft and built into Windows (and in other words is clean)). Again, I do not know if ESET will ever actually detect a process trying to terminate it after it knows it's not legitimate.
Point being, as long as the threat is delt with the UI process being terminated shouldn't be too much of an issue.
On the other hand, what is a issue is the services/other processes used for protection being stopped/terminated. This is where ESET will protect... As we saw in the video, using Terminator in Process Hacker, one of the processes by ESET failed to be terminated. This would be an important process used by ESET, most likely for "protection". However, it's running in user-mode.
If the drivers for the product become unloaded or crtiical processes in the product are stopped by malware, then there is an issue.
As well as this, the product needs to protect from the actual Antivirus files from being deleted. This is also important.
The protection for the processes/services can be done in either the drivers or through DLL injection. I won't go further in this here.
7). Detection ratio
It's impossible to determine if a product is good/bad due to a low detection rate than another vendor on one or a few tests. ESET has been proven to be effective at detecting on many users systems, and in many other tests.
In my opinion I believe ESET is a good product overall and has a good detection rate. But this is my opinion, not a fact. There is no "best" product for detection ratio, and every vendor has it's good and bad days.
Take any reviews on a security product with a grain of salt. (no matter who the reviewer is).
8). Malware still active
Yes, it's true that this is bad. I can't really say anything here I didn't say above in #7 apart from bad luck from ESET this test.
---------------------------------------------------------------------------------------
Gosh, this post is already so long...
Thank you for the test
@Av Gurus !
Cheers.
