SE Labs Test of Enterprise AV

Security Statistics and Reports
32 Replies 6,631 Views
Thanks, master. :)
Your welcome my Grand Master!
download.jpeg
 
I see they're talking about me, so I'll answer :D

Basically, I don't read any company tests (apart from @Adrian Ścibor which I really like). Whether it's AV-Comparative, AV-Test etc, I don't read any.

Then, I don't like the word "competition" because for me, there isn't any. As much as I hate these test boxes, you really need to look at how the test was run (AV configured? recent malware sample? attacks used? etc ).
An AV can do 100% on EXEs and get screwed on .VBS , .JS , .HTA etc ;)

Note that they didn't test DeepInstinct, Trend Micro's ApexOne and other big names...

(And I've been doing corporate AVs for a while now, and honestly, they're the ones I prefer to test :p )
 
I remember your posts (with videos) from several years ago about the danger of scripts and scriptors, for example:

View attachment 277459

It seems that they are equally dangerous today, despite the big effort done by AV vendors.
They will always be an issue if script engines have admin rights and whole system access. In the end work smart and not hard.
 
And before someone suggests it, getting rid of PowerShell, etc. is not always an option.
It is an option most of the time. I am not sure in this day and age which sysadmin will want to run complicated scripts on PowerShell when they can just log-in and do the job quickly, and more reliably.
Of course on a development environment, it may not be brilliant. If the developed software/software installer relies on PowerShell in a way. PowerShell is not the only danger though.

I’ve been living a PowerShell-less life for long time without any issues.
 
A well developed anti-malware application should have no issue with Scriptors of any type. The desire to have various things blocked (like PowerShell or vbs) is just catering to those products that are not as well coded.

The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.
 
A well developed anti-malware application should have no issue with Scriptors of any type. The desire to have various things blocked (like PowerShell or vbs) is just catering to those products that are not as well coded.

The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.
Agreed. But then again its not easy. Simple scripts can even breach these solutions. Even some of the betters ones always get bypassed. I guess its all about lowering damages and insurance payouts.
 
The burden is that the developer should differentiate between the good and the bad, and not for the User to determine what should or should not be run.
It’s easy to say what should and shouldn’t be done but when one attempts to do it, there is a whole load of challenges that come up.
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top