Тест антивирусов на детектирование полиморфных вирусов (результаты) - Страница 6 - Тесты и сравнения - Форумы Anti-Malware.ru Перейти к содержанию
Сергей Ильин

Тест антивирусов на детектирование полиморфных вирусов (результаты)

Recommended Posts

Иван
Не сходится ...

Вот тут.

Первое же предложение.

Если бы вот такой текст:

Уважаемые коллеги! Конечно это досадная ошибка, что тестирование было проведено изначально на необновленной версии программы.

В связи с этим предлагаю исключить из данного теста результаты VBA32 полностью. Давайте будем считать, что в этом тесте мы не участвовали. Думаю, что это будет справедливо по отношению ко всем участникам теста. Спасибо за понимание.

ООО "ВирусБлокАда"

появился позавчера - последних 4-х листов флейма тут бы просто не было.

если бы я был на месте белорусов, то первое требование, которое мне бы пришло в голову - требование перетестировать, а не исключить себя из теста

В этом анализе теста деструктивен только один, А.

не, у него есть и конструктив

а у других деструктива тоже навалом

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Семашко
Будете смеяться, но лично мое мнение с Вашим в этом отношении полностью совпадало/совпадает.

Сергей, прочитайте пожалуйста ОЧЕНЬ внимательно вот ЭТОТ пост.

Посмотрите на даты, на слова, на подписи.

А теперь перечитайте все что вы понаписали в своем последнем комментарии (на который я сейчас отвечаю).

Еще раз перечитайте тот фрагмент, моего комментария, на который Вы решили обратить такое внимание: "Будете смеяться, но лично мое мнение с Вашим в этом отношении полностью совпадало/совпадает."

Надеюсь, Вам нет необходимости объяснять, что мое личное мнение может не всегда совпадать с мнением остальных сотрудников фирмы, а особенно коммерческого отдела? Я бы попросил принять это во внимание и не строить на этом высказывании какие-либо далеко идущие выводы, как Вы пытаетесь делать в последних Ваших комментариях. Надеюсь, что вопрос исчерпан?

Как уже отметили, предложение исключить результаты VBA из отчета тестирования появилось в том числе и как вариант решения вопроса, поднятого Вами тут: http://www.anti-malware.ru/forum/index.php...amp;#entry33681

Пожалуйста определитесь, чего Вы вообще хотите?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Семашко
ну где вы в моей логике видите огрехи в данной ситуации, покажите ? Я то не вижу.

Есть факты.

1. Позавчера белорусы не согласились с результатом.

Верно

2. Позавчера белорусы попросили провести новый тест на новой версии.

Не совсем верно. Подразумевалось проведение теста версии, актуальной на момент проведения общего тестирования.

3. После оглашения новых результатов - белорусы просят себя из теста совсем исключить.

Не совсем верно. Такой вариант решения конфликтной ситуации мы предложили, после Вашего (справедливого) замечания о версии.

Я говорю о том,что пункта 2 делать вообще не следовало и им сразу надо было бы просить исключения. И Сергей Семашко говорит, что он с этим согласен.

Я с этим согласен, поскольку понимаю, что корректно провести повторное тестирование именно той версии, которая нормально впишется в общие таблицы результатов, не так уж просто и может вызвать много вопросов. Но попрошу опять-таки меня тут не цитировать, потому что это только мое личное мнение.

Но сегодня. А не позавчера. То есть сами эскалировали ситуацию до абсурда и теперь хотят чтобы я предложил вариант решения.

Нормальный подход...

Мне кажется, что это конструктивный подход. Поскольку именно Вы подняли вопрос и именно Вам все предложеные решения не нравятся, предложить что-либо еще было бы разумно. А пока получается, что это Вы эскалируете ситуацию...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Иван
если бы я был на месте белорусов, то первое требование, которое мне бы пришло в голову - требование перетестировать, а не исключить себя из теста

хм, кстати не только у меня такая логика

в своё время ЛК тоже просила тест провести повтороно, утверждая, что есть ошибка

http://www.anti-malware.ru/forum/index.php...ost&p=12154

при этом речи о снятии с теста не велось в принципе ни с начала ни потом

забавно, что Dexter в той теме выступал по алгоритму сходному с выступлением А. сейчас:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин

Коллеги, я внимательно прочитал все ваши доводы выше в пользу и против снятия VBA из теста. Тест сделан и опубликован, критическая ошибка, допушенная в ходе теста, устранена. Я считаю это правильным. Как я писал выше, и это подтвердил Сергей Семашко, докрутить что-либо в детекте за 2 дня было нереально без самплов (а их у белоруссов не было после истории с Доктором).

По всему зафиксированный сейчас результат для VBA нет оснований считать невалидным. Я бы блин понял вас если бы 3.12.6.2 взяла больше вдруг после пересканирования 30 баллов. Ну не хуже этот продукт по детекту полиморфов, чем Sophos, Panda или VirusBaster! Поэтому я считаю, что нет смысла снимать его из теста.

Прицидентов аналогичных полно было. Никто не забыл про "провал" Eset в тесте VB? :-) Ошиблись, пересчитали, всякое бывает.

Давайте не будем создавать прецидент, гораздо более серьезный, чем передачу кому-то самплов.

А то ведь завтра каждый второй будет писать: "Снимайте наш/их продукт!". Хорошо ли это? Думаю нет.

P.S. До первой победы DrWeb в тесте на лечение активного заражения, мне пиарщики из Доктор Веб тожи писали мол, какого хрена вы тестируете наш продукт? Кто вам разрешил?

Пресс-релиз прошел, результаты опубликованы, позно пить боржоми уже.

*****************

Хочу сказать большое спасибо за замечания по методологии. Это действительно важно для меня. В следующий раз мы обязательно это учтем. Мусор не стоит допускать в коллекцию, а подсчет результатов надо сделать более устройчивым к погрешностям измерений (попавшему мусору, сбоям, временной разнице между сканированиями).

Тест на лечением нужно делать как-то по-другому, это также стало очевидно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
A.
Надеюсь, Вам нет необходимости объяснять, что мое личное мнение может не всегда совпадать с мнением остальных сотрудников фирмы, а особенно коммерческого отдела? Я бы попросил принять это во внимание и не строить на этом высказывании какие-либо далеко идущие выводы, как Вы пытаетесь делать в последних Ваших комментариях. Надеюсь, что вопрос исчерпан?

Да, вполне. Именно поэтому я и просил всех высказывающихся со стороны VBA представиться и обрисовать круг полномочий.

Это и Ильину на заметку на будущее - любое общение по результатам тестов должно вестить только с уполномоченными представителями вендорами, чтобы не было больше ситуаций, когда некие virusu.net подписываются как ООО "Вирусблокада", а другие люди говорят что их мнение может и не совпадать с коммерческим отделом и т.д.

В ЛК уже давно существует отдельная должность, которая отвечает именно за взаимоотношения со ВСЕМИ тестирующими организациями в мире и только этот человек вправе получать самплы, выдвигать требования, предоставлять требуемый продукт (и базы) для тестирования и т.д и т.п.

Думаю, что у всех крупнейших вендоров такие люди тоже есть. Если у VBA нет, то наверное пора уже задуматься о введении в штат.

Как уже отметили, предложение исключить результаты VBA из отчета тестирования появилось в том числе и как вариант решения вопроса, поднятого Вами тут: http://www.anti-malware.ru/forum/index.php...amp;#entry33681

Пожалуйста определитесь, чего Вы вообще хотите?

Я хочу чтобы результатов тестов были объективны. Ни первый результат VBA, ни второй, объективными не являются. Приятно услышать, что мои возражения были вами же учтены, непонятно только что бы было - если бы я молчал все это время.

Что делать теперь - я не знаю. Точнее знаю, но не в курсе насколько это реально. Надо взять релизную версию VBA существовавшую 15 января, надо взять базы от 15 января и протестировать. Это было вторым вариантом решения проблемы изначально - либо сразу снятие с теста, либо пересчет на актуальном продукте. Вы на первое не пошли, вы (VBA) выбрали второй вариант, но неправильный - тест на продукте на полтора месяца более новом, чем дата теста. Ни о каких двух днях - речи вообще не идет. Полтора месяца.

Не совсем верно. Подразумевалось проведение теста версии, актуальной на момент проведения общего тестирования.

Кем подразумевалось ? Товарищем virusov.net aka ООО "Вирусблокада" ? В его посте четко написано - "Версия VBA32 3.12.6.2 (действующая)".

Из поста следует требование пересчета именно по этой версии.

Которая вышла в паблик 25 февраля. Тест закончился 20 февраля.

И не надо тут валить на Ильина - это не его задача выискивать даты выхода версий продуктов. Вы (VBA) сказали ему - 3.12.6.2. Он ее и взял.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Virusu.net

МДа... Бурные дебаты!

Давайте внесем ясность!

Мы действительно были шокированы результатами первого теста и поступили именно так, как поступил бы любой другой на нашем месте: потребовали пересмотреть результаты теста.

НО! Наш голос не решающий в данном случае. Нам могли и отказать или просто предложить убрать из теста.

Реакция Ильина и его решение проведения нового теста и публикации его результатов - нас также удивила: мы ожидали услышать извинения и максимум предложения убрать нас из теста.

О новом тесте мы узнали после публикации его результатов.

Из этих результатов мы поняли, что допущена вторая ошибка: тест проведен на ядре и вирусной базе не соответствующей времени проведения теста.

Решение было принято сразу и именно так поступил бы любой другой на нашем месте: мы спровоцировали своей жалобой вторую ошибку - за это удалите нас из теста и вопрос закрыт.

Все остальные предложения, умозаключения, вымыслы и домыслы были высказаны участниками форума и они не имеют под собой никаких оснований.

С уважением, ООО "ВирусБлокАда"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Иван
Реакция Ильина и его решение проведения нового теста и публикации его результатов - нас также удивила: мы ожидали услышать извинения и максимум предложения убрать нас из теста.

О новом тесте мы узнали после публикации его результатов.

Из этих результатов мы поняли, что допущена вторая ошибка: тест проведен на ядре и вирусной базе не соответствующей времени проведения теста.

гм, ребята вы говорите да не заговаривайтесь, а то я начинаю сомневаться зачем я вас защищал выше

Считаю ответ Ильина: "Качал с сайта, какая версия официально выложена, такая и тестировалась. Мне кажется, это логично." недостойным ответом. Версия VBA32 3.12.6.2 (действующая) отличается от версии, которую тестировали как минимум на один год, это во первых. Во вторых, в тесте использовалась версия без обновления. Если бы было выполнено обновление в тесте участвовала бы новая версия и соответственно свежие вирусные базы данных.

С Вашей стороны это не корректно;

Считаю, что Вы обязаны как минимум опровергнуть результаты тестов и выполнить новое тестирование для VBA32. С уважением ООО "ВирусБлокАда"

здесь явным образом написано, что вы требуете проведения нового теста - что интересно вас тогда удивило в поведении Ильина скажите ка? Он ведь как раз сделал "выполнить новое тестирование для VBA32"

здесь же явным образом написано что надо было тестировать VBA32 3.12.6.2 - а вы значит теперь утверждаете, что это мол Ильин ошибся во второй раз, опять не ту версию взял

совесть то есть?

кстати а кто такой умный грохнул 8 постов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman
Лично мое мнение - не надо было изначально пересчитывать результаты VBA32. Была допущена ошибка в тестировании - ок, она установлена, она повлияла на результат. Значит вот тот первый результат и надо было аннулировать = убрать VBA из теста совсем.

Нет, вместо этого сделали пересчет и пришли к тому, к чему пришли - требование\пожелание\просьба снять результаты.

Извините, но это выглядит именно как попытка всеми средствами избежать демонстрации плохих, провальных данных для VBA. Они провальные, что в первом случае, что во втором. Теперь, когда вы уже видите это - два провала, то просьба все-таки снять результаты вообще - это ...

Фактически VBA дали две попытки. Обе неудачные. Итог - "не надо нас вообще считать".

Если не согласны с тем что это были две попытки - считайте это одной. Итог тот же - "не надо нас вообще считать".

Отсюда и вопрос - почему же теперь любой другой вендор не может сказать то же самое - "не надо нас считать" ? Имхо, может. И даже найдет несколько фактов в свою пользу. Например, мол, у нас в это время базы оптимизировались - бага была на нашей стороне, вы не при чем, но результат все равно снимите.

так что ли ?

Так что за косяк с обновлениями VBA32:

1 Он не обновлялся?

2 Обновлялся, но не смог обновится (вина VBA)?

3 Обновлялся, но не смог обновится (вина тестовой лаборатории)?

Если вендоры VBA (и не только) хотят объективный тест, то пусть вышлют обновления за 15 января и актуальную версию на тот момент.

Помнится, когда Касперский накасячил с обновлениями, за что и не получил VB100, его результаты не пересматривали.

Так вот, если обновление происходило по п.2, то и пересмотр результатов думаю так же некорректен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Virusu.net

Давайте не будем вешать друг на друга ярлыки и призывать к совести. Это уже лишнее.

Осталось три варианта решения вопроса:

1. Исключить VBA32 из теста.

2. Выполнить третий тест с версией 3.12.6.1 (отличие результатов тестов от 3.12.6.2 будет не значительное)

3. Оставить все как есть (т.е. результаты теста на версии 3.12.6.2)

Предлагаю сообществу проголосовать(высказать свое мнение), а Ильину принять решение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Иван

оставить надо как есть, чтоб не порождать следующую волну негатива - а она полюбому будет

хватит уже "телодвижений"

Если вендоры VBA (и не только) хотят объективный тест, то пусть вышлют обновления за 15 января и актуальную версию на тот момент.

не вариант - я первый скажу, что то что они вышлют может быть докрученной специальной сборкой

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
2. Выполнить третий тест с версией 3.12.6.1 (отличие результатов тестов от 3.12.6.2 будет не значительное)

Вот именно, отличие будет результатов будет копеечным, если вообще будет. Какой смысл перетестировать и оспаривать результаты сейчас, если это очевидно?

3. Оставить все как есть (т.е. результаты теста на версии 3.12.6.2)

Кстати, в отчете написано черным по белому 3.12.6 ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Groft
Кстати, в отчете написано черным по белому 3.12.6 ;)

поправили после 2-го теста

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman
Вот именно, отличие будет результатов будет копеечным, если вообще будет. Какой смысл перетестировать и оспаривать результаты сейчас, если это очевидно?

Очевидно? Почему?

Если 3.12.6.2 вышел после тестов, то судя по словам Ивана, это может быть специальной докрученной сборкой. Тогда уж 3.12.2 или 3.12.6.1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Groft
Если 3.12.6.2 вышел после тестов, то судя по словам Ивана, это может быть специальной докрученной сборкой. Тогда уж 3.12.2 или 3.12.6.1

версия 3.12.6.2:

25.02.2008 Vba32 build 3.12.6.2

* documentation was revised

* INF extension was added to the list of default file extensions to scan

3.12.6.1:

2.02.2008 Vba32 build 3.12.6.1

+ vba32ar.dll module. This module implements Vba32 AntiRootkit technology.

It is integrated into memory check process and can be accessed in Console Scanner only.

To activate antirootkit scanning, specify the following command line arguments /mr+/ha

Module is available on 32-bit operating systems starting with Windows 2000.

http://vba32.de/wbb2/thread.php?threadid=207

вот что нового докручивали :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman

Хм, я реально думал, что там напишут что подкрутили "детект" для Anti-Malware.ru

:)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy

Хотелось бы внести свою лепту в обсуждение. Больше в качестве размышлений на будущее.

Если кому-то покажется, что мои замечания и предложения призваны поднять в этом тесте Dr.Web, то это не так, т.к. предложения не влияют существенно на результат антивируса этой марки, зато сильно влияют на результаты некоторых других антивирусов. Поэтому прошу отнестись к этому сообщению конструктивно. Не исключаю, что я где-то в своих размышлениях или рассчётах ошибся. Если не прав - исправлюсь.

Вот результаты авторов теста для сравнения (они пригодятся для сравнений, которые будут ниже):

Avira 31

F-Secure 31

Kaspersky 31

Avast 25

AVG 22

DrWeb 21

Eset 20

Microsoft 19

Trend Micro 18

Symantec 17

BitDefender 16

Agnitum 15

Panda Security 14

Sophos 14

VBA 14

McAfee 11

Все нижеследующее касается этой страницы:

http://www.anti-malware.ru/index.phtml?par...ymorphic_awards

Т.е. схеме награждений.

Не считаю эту схему корректной (и, соответственно, предлагаю пути по её совершенствованию) по нескольким причинам.

Причина первая. 3 балла продуктам даётся за точно 100%-ный детект. Считаю, что радиус интервала вокруг этой точки (100%) необходимо увеличить с 0 до какого-нибудь ненулевого результата. Аргументы:

1. Участвующие в тесте 29 785 сэмплов могут не покрывать (и наверняка не покрывают) всего многообразия вариантов рассматриваемых вирусов. Т.е. могут существовать сэмплы вирусов, которые антивирусы со 100% результатом в тесте по этим вирусам детектировать не будут.

2. В тестовой коллекции есть какой-то процент битых файлов. Пока этот вопрос не решён, считаю, что нельзя считать результат в 99,75% и в 100% детекта на коллекции существенно разными, т.е. на столько разными, чтобы оценивать их разницей между 2 и 3 очками (при максимуме в 3 очка).

В таких условиях нельзя особо выделять результат в точно 100%, т.к. он ничего не показывает, т.е. это идеализированная фикция.

Я попробовал увеличить радиус точки 100% с 0 до 0,25%, остальные критерии оставил без изменений. Т.е. попробовал дать 3 балла за результат от 99,75% до 100%, 2 балла за результат от 99% до 99,75% и 1 балл за результат от 90% до 99%.

У меня получились следующие результаты:

Avira 32

F-Secure 32

Kaspersky 32

Avast 28

DrWeb 25

AVG 24

Eset 21

Microsoft 21

Trend Micro 19

Symantec 18

BitDefender 17

Panda Security 17

Agnitum 16

Sophos 14

VBA 14

McAfee 12

(подправил предыдущие результаты, нашёл ошибку).

Существенных изменений не произошло, но некоторые продукты перешли на смежные позиции.

Причина вторая. При обсуждении возможности проведения очередного интегрального теста антивирусов мы пришли к выводу, что балльная система мало годится для такого теста. В данном тесте считаю, что балльная система для интегрирования результатов детекта различных вирусов тоже мало что показывает. Я решил взять за общую оценку антивирусов в тесте их средний показатель по всем вирусам из коллекции.

Получился следующий результат:

F-Secure 99,97%

Kaspersky 99,97%

Avira 99,95%

Avast 99,26%

DrWeb 98,04%

AVG 90,49%

Eset 90,23%

BitDefender 89,06%

VBA 86,44%

Microsoft 85,76%

Panda Security 81,62%

Agnitum 80,88%

Sophos 79,88%

Symantec 79,20%

Trend Micro 73,28%

McAfee 61,80%

Здесь изменения уже достаточно серьёзные для некоторых продуктов.

Считаю, что последняя схема на данный момент наиболее приемлема для подобных тестирований.

Соответственно, я бы дал следующие медали после обработки полученных результатов по существующей коллекции и существующей методологии проведения тестов (которые и так довольно активно обсуждаются):

золотые - F-Secure, Kaspersky, Avira (как это и было сделано),

серебряные - Avast, Dr.Web,

бронзовые - AVG, Eset, с большой натяжкой BitDefender.

Ещё раз подчёркиваю, что всё написанное - сугубо моё личное мнение, но если оно найдёт у кого-нибудь поддержку, буду рад.

P.S. Заметил в Таблице 1 результатов теста на пересечении VBA - Allaple.3 значение 92.2%% при обработке результатов в Excel, уберите один % :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Groft

поддерживаю :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman

тож поддерживаю, трех бальная система несколько неточна.

Можно увеличить радиус интервала только для максимальной оценки, т.е. результат 99-100%=100%(на погрешность битых файлов) и увеличить бальность до 10.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
и увеличить бальность до 10.

Баллы - вообще весьма дискретная и неточная штука. Интервалы в реальных показателях в ней часто существенно разные, а в баллах вроде как и одинаковые. Считаю, что баллы нужно вводить только в тех немногих случаях, когда количественные показатели вообще отсутствуют - более/менее красивый интерфейс, качество выступления в фигурном катании etc. В противном же случае введение лишних искусственных критериев только снижает точность результатов и делает менее прозрачной их привязку к реальным показателям тестируемых параметров.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman

Valery Ledovskoy

Как вы сами говорили:

1. Участвующие в тесте 29 785 сэмплов могут не покрывать (и наверняка не покрывают) всего многообразия вариантов рассматриваемых вирусов. Т.е. могут существовать сэмплы вирусов, которые антивирусы со 100% результатом в тесте по этим вирусам детектировать не будут.

2. В тестовой коллекции есть какой-то процент битых файлов. Пока этот вопрос не решён, считаю, что нельзя считать результат в 99,75% и в 100% детекта на коллекции существенно разными, т.е. на столько разными, чтобы оценивать их разницей между 2 и 3 очками (при максимуме в 3 очка).

В таких условиях нельзя особо выделять результат в точно 100%, т.к. он ничего не показывает, т.е. это идеализированная фикция.

Т.е. что бы это нивелировать и нужно увеличить бальность.

А 100% не что иное как 100 баллов.

А что бы антивирус с 89,4% не считался хуже с другим со значением 90,1% по тем же причинам, сократить бальность со "100" до 10 или другой золотой середины.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
А что бы антивирус с 89,4% не считался хуже с другим со значением 90,1% по тем же причинам, сократить бальность со "100" до 10 или другой золотой середины.

Да не нужна дискретность - ни на 100 баллов, ни на 10.

Только на конечном этапе раздачи наград сказать, что выше такой-то планки - золотая награда и т.д. Этого достаточно для того, чтобы антивирусы с различием значений в несколько десятых процента считались одинаково достойными одной и той же награды.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Chaman

Полностью согласен, просто есть некоторые опасения, что из-за 0,4% начнут пиарить свой продукт, как самый лучший.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Zyx

Тоже поддерживаю Валерия. Баллы действительно как-то взяты с потолка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Иван

[Дорогой Валерий и поддержавшие его.

Во-первых баллы взяты не с потолка - смотри методологию.

Во-вторых, смотреть общий детект в данном случае не в коем случае нельзя. Поскольку продукты, которые занимают приличные места в этом тесте должны хорошо справляться со ВСЕМИ семействами полиморфов. А ваше сваливание всего в одну кучу приводит к тому, что продукты, которые показали откоровенно провальные результаты по какому-то семейству - попали в красный сектор, вылезают выше чем они того стоят.

так что у сваливания всего в одну кучу и подсчет общего детекта имеет имхо более существенные недостатки, чем балльная система.

кроме того оценка просто по уровню детекта в случае с полиморфами тоже не совсем уместна, поскольку процентики по смемйству Валерий, это не уровень детекта разных вирусов, это способность антивируса справляться с многообразием образцов одного и того же вируса. Причем поскольку это полиморф - то это многообразие сидит не на разных компах, а на компе одного и того же пользователя. И этому пользователю будет по большому счету все равно 80% этого многообразия вы у него на компе нашли или 30% - все равно у него проблемы и большие.

я бы скорее брал средний детект по всем семействам - но и тут есть свои косяки

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      ESET Online Scanner был обновлён до версии 4.0.1. Приложение теперь работает только в 64-разрядной ОС.
    • Ego Dekker
      ESET Cyber Security был обновлён до версии 9.0.6700.
    • AM_Bot
      Теория звучит убедительно, но работает ли она на практике? Мы внимательно изучили Phishman 2.35 и решили не останавливаться на описании её возможностей. Вместо этого протестировали платформу на собственных сотрудниках и удивились, к каким результатам это привело.      1. Введение2. Методология тестирования Phishman 2.353. Первичное тестирование3.1. Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылки3.2. Тестирование доставки и отражения результатов в статистике3.3. Результаты атак4. Обучение4.1. Формирование учебной группы4.2. Составление образовательной программы по повышению киберкультуры4.3. Процесс обучения и его результаты5. Повторное тестирование5.1. Результаты атак6. Подведение итогов6.1. Сложности, с которыми мы столкнулись7. Впечатления от проекта команды «АМ Медиа»7.1. Реакция сотрудников7.2. Реакция организаторов7.3. Сотрудничество с вендором8. ВыводыВведениеPhishman 2.35 — это система повышения осведомлённости пользователей в сфере ИБ. Она помогает развивать киберкультуру и формировать у сотрудников устойчивые навыки безопасной работы с информацией, цифровыми сервисами и корпоративными ресурсами. В процессе обучения сотрудники учатся распознавать актуальные сценарии атак, закрепляют правильные модели поведения и в результате реже становятся причиной инцидентов, связанных с человеческим фактором.В первой части обзора Phishman 2.35 мы рассмотрели платформу с точки зрения её возможностей. Теперь пришло время проверить, как всё это работает на практике. За время проекта мы не только оценили эффективность различных сценариев, но и столкнулись с рядом особенностей, которые невозможно увидеть в документации. Одни из них влияли на ход тестирования, другие оказались скорее организационными нюансами, о которых стоит знать заранее.Методология тестирования Phishman 2.35В процессе работы с киберкультурой «АМ Медиа» мы будем использовать следующие метрики:Обученность. Отражает уровень знаний сотрудников в области ИБ. Показатель растёт, когда сотрудники осваивают темы: реагирование на инциденты, защита от социальной инженерии и другие критически важные компетенции.Иммунность. Показывает, как сотрудники применяют знания на практике. Она повышается, когда демонстрируется способность распознавать угрозы и правильно на них реагировать в реальных сценариях.Киберосознанность — итоговая метрика. Объединяет знания и практические навыки, показывая, насколько сотрудники в целом устойчивы к киберугрозам и действуют корректно при их возникновении.Прежде чем оценивать эффективность работы системы, необходимо определить отправную точку. Первичное тестирование определит, на какие сценарии реагирует каждый сотрудник, где чаще всего допускаются ошибки и какие темы требуют дополнительного развития. На основе этих данных формируется индивидуальная программа обучения: сотрудники проходят персонализированные курсы, выполняют практические задания и тесты, которые помогают устранить выявленные пробелы и закрепить необходимые навыки. В процессе обучения повышается уровень обученности, а закрепление знаний через практику влияет на показатель иммунности. После завершения обучения мы проведём повторное тестирование, которое покажет, какие изменения произошли по всем ключевым метрикам.Заключительный этап — сравнение результатов первичного и повторного тестирования. Здесь станет понятно, насколько вырос уровень киберкультуры сотрудников: изменилось ли их отношение к вопросам ИБ, стали ли они увереннее распознавать угрозы и чаще принимать безопасные решения в ситуациях, где раньше могли допустить ошибку.В качестве основного канала для рассылки фишинга выбрали электронную почту. Причина очевидна: именно она остаётся основным способом первичного контакта злоумышленников с сотрудниками и доставки фишинговых сценариев. По имеющимся оценкам, более 90 % успешных кибератак начинаются с электронного письма, поэтому исключать этот канал из подобных проверок было бы некорректно.Первичное тестированиеРеальные фишинговые атаки почти никогда не строятся по универсальному шаблону: злоумышленники адаптируют содержание писем под роль человека в компании, его рабочие процессы и типовые задачи. Поэтому при выборе целевой аудитории мы разделили сотрудников по функциям и уровню доступа к корпоративным данным, а сам проект разбили на 3 последовательные волны с разным уровнем сложности.Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылкиПосле определения целевой аудитории был проведён анализ структуры подразделений и рабочих процессов сотрудников. На этом этапе изучались:должностные обязанности;распределение зон ответственности;характер внутреннего взаимодействия между отделами;используемые адреса электронной почты;формат повседневной служебной переписки.Это позволило понять, какие сценарии коммуникации являются для сотрудников привычными и не вызывают подозрений.На основе собранных данных были подготовлены сценарии фишинговых сообщений. При разработке содержимого учитывались тематика рабочих задач, стиль корпоративного общения, оформление внутренних уведомлений и типовые причины отправки писем внутри организации. Основная задача заключалась в том, чтобы письмо воспринималось как стандартное рабочее сообщение, соответствующее реальным бизнес-процессам заказчика.Волна 1. Первая волна была построена как массовый фишинг. Сценарий — сверка графика отпусков. Для атаки создавали и настраивали пользовательский шаблон. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки.На этом этапе проверялась базовая реакция сотрудников на привычные рабочие триггеры и способность распознавать типовые признаки фишинга без привязки к конкретному подразделению. Рисунок 1. Шаблон для первой волны Рисунок 2. Вид фишингового письма из первой волны в почте Волна 2. Для каждого отдела были подготовлены письма, основанные на реальных рабочих процессах, характерных запросах и ситуациях, с которыми сотрудники регулярно сталкиваются в своей деятельности. Для атаки создали и настроили пользовательский шаблон, где-то добавили немного визуального оформления. Время начала рассылки — по запланированному времени. Рисунок 3. Пример шаблона из второй волны для отдела «Продажи» Рисунок 4. Вид фишингового письма из второй волны для отдела «Продажи» Волна 3. Здесь моделировались уже более сложные сценарии целевого фишинга (spear phishing). В письмах использовались специальные формулировки, элементы корпоративного брендирования. На этом этапе проверялась не только внимательность сотрудников, но и способность замечать менее очевидные признаки атаки в условиях, максимально приближённых к реальной целевой компрометации.За основу брали системный брендированный шаблон «Яндекс ID», добавили фишинговую форму и скорректировали немного её содержание. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 5. Пример шаблона из третьей волны Рисунок 6. Вид фишингового письма из третьей волны При переходе по ссылке открывалась фишинговая страница. Рисунок 7. Фишинговая страница Тестирование доставки и отражения результатов в статистикеДалее была подготовлена инфраструктура рассылки. После её настройки проводилось тестирование доставки сообщений. Проверялась доставка писем во входящие сообщения почтовых клиентов, анализировалась реакция антиспам-механизмов в почте, а также контролировалась корректность работы механизмов отслеживания действий пользователей. Рисунок 8. Результаты тестирования доставки и отображения сообщений в почте Тестирование прошло успешно.После завершения проверки была сформирована последовательность отправки сообщений по заранее определённым волнам. Такой подход позволил распределить нагрузку, контролировать ход тестирования и отслеживать реакцию сотрудников на различных этапах проведения проверки. Рисунок 9. Активные мероприятия Результаты атакБыли получены следующие результаты:Иммунность — 81 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 71 %.Уровень риска — 8, средний. Устойчивость формируется, но есть ещё риски. Рисунок 10. Общая информация после проведения первичного тестирования Самый низкий уровень иммунности — около 50 %, после первых двух волн атак. Рисунок 11. График иммунности во время первичного тестирования Далее — сформировали в системе отчёт по скомпрометированности сотрудников, на основании которого выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Рисунок 12. Отчёт по скомпрометированности всех сотрудников в Phishman 2.35 Таблица 1. Результаты первичного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот04,76 %4,76 %Продажи04,76 %9,52 %Продюсеры 0023,8 %Редакция0019,04 %Руководитель000 ОбучениеПервичное тестирование завершено, поэтому следующим этапом стало определение группы риска и формирование программы обучения.Формирование учебной группыНа этапе отбора рассматривались два варианта формирования учебной группы. Первый предполагал использование показателя иммунности сотрудников. Второй вариант заключался в создании правила, автоматически формирующего список сотрудников, которые были скомпрометированы в ходе проведённых проверок. Этот подход позволял сразу получить выборку пользователей, продемонстрировавших наибольшую подверженность атакам, без ожидания обновления показателей.Был выбран второй вариант. На основании созданного правила была сформирована группа для обучения: в неё вошли люди, которые были скомпрометированы в ходе первичного тестирования. Рисунок 13. Создание правила для выявления группы риска Рисунок 14. Отчёт по отработанному правилу для выявления группы риска Отдельно была сформирована группа сотрудников, успешно распознавших фишинговую атаку, для участия в обучении, направленном на поддержание киберкультуры.Составление образовательной программы по повышению киберкультурыПопавшиеся сотрудники были включены в отдельную учебную группу, для которой сформировали персональную образовательную траекторию. В неё вошли 3 микрокурса по фишингу и 1 курс по информационной безопасности. Содержание траектории было направлено на повышение устойчивости к методам социальной инженерии и снижение вероятности компрометации учётных данных. Рисунок 15. Заполнение параметров обучения сотрудников Рисунок 16. Составление учебной программы Отдельно была запущена программа обучения для сотрудников, которые не попали в выборку по результатам правила.Процесс обучения и его результатыПервый отчёт мы сформировали через 2 дня после запуска обучения, что позволило получить предварительную оценку вовлечённости сотрудников. Анализ данных показал, что наибольшую активность на начальном этапе продемонстрировали сотрудники, которые попались на фишинг. Рисунок 17. Промежуточный анализ обучения Через неделю после запуска обучения провели повторный анализ прогресса, включая оценку прохождения курсов и выявление участников, не приступивших к обучению. Рисунок 18. Отчёт по динамике обучения в Phishman 2.35 Анализ показал, что часть сотрудников не завершила обучение в установленный срок. Для обеспечения максимального охвата было принято решение о продлении сроков прохождения курсов. Рисунок 19. Продление и корректировка процесса обучения В результате фактическая продолжительность обучения составила 2 недели, что превысило первоначально установленный срок в одну неделю. Но и этого времени не хватило нашим сотрудникам. Чтобы узнать, кто оказался более ответственным, воспользовались возможностями правил. Рисунок 20. Пример настройки правила по выявлению сотрудников, прошедших обучение В результате была получена информация о сотрудниках, полностью и частично прошедших обучение. Рисунок 21. Отчёт по сработанному правилу по выявлению сотрудников, прошедших обучение Рисунок 22. Отчёт по сработанному правилу по выявлению сотрудников, частично прошедших обучение Результаты обучения:полностью прошли обучение — 52 %;частично — 22 %;не прошли обучение — 26 %.Мы проанализировали список сотрудников, не приступивших к обучению, и выяснили, что это те, кто не попался на фишинг во время первичного тестирования.Среди сотрудников, которые попались на фишинг, 80 % прошли обучение, остальные — прошли его частично. Рисунок 23. Результаты обучения сотрудников «АМ Медиа» Вместе с тем за этот период были зафиксированы положительные изменения в ключевых показателях: уровень обученности достиг 9 319 баллов, а показатель киберосознанности — 7 561 баллов. Несмотря на положительную динамику, полученные значения оставались гораздо ниже целевых ориентиров, что свидетельствует о необходимости дальнейшей работы по повышению вовлечённости сотрудников и развитию киберкультуры.Повторное тестированиеПовторное тестирование проводилось по тем же этапам, что и первичное: подготовка шаблонов, тестирование и проведение атак. Как и на первом этапе, основной задачей было сделать письмо максимально похожим на стандартную рабочую переписку, соответствующую реальным бизнес-процессам нашей компании.Подготовительный этап повторного тестирования потребовал дополнительных временных затрат, связанных с регистрацией новых доменов и расширением сценариев атак с учётом результатов первичного тестирования.Волна 1. Сценарии формировались не только для отдельных подразделений, но и адресно для конкретных сотрудников, что позволило повысить реалистичность и точность имитации фишинговых атак. Запустили несколько атак, для каждой из них были разработаны индивидуальные шаблоны электронных писем и соответствующие фишинговые формы. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 24. Пример фишингового письма для первой волны Рисунок 25. Пример фишинговой формы для письма из первой волны Волна 2. Вторая волна представляла собой массовую фишинговую кампанию. Для неё был создан и настроен пользовательский шаблон, основанный на триггерах срочности и страхе финансовых потерь. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки. Рисунок 26. Пример фишингового письма для второй волны Тестирование доставки писем и корректности отражения результатов в статистике прошло успешно.Результаты атакВ повторном тестировании приняли участие уже 23 человека. Увеличение числа участников на 2 человека связано с подключением новых сотрудников к нашему эксперименту. Резких скачков иммунности здесь не наблюдалось. Рисунок 27. График иммунности во время повторного тестирования Для дополнительной оценки мы и здесь также выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Таблица 2. Результаты повторного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот000Продажи008,7 %Продюсеры 008,7 %Редакция8,7 %08,7 %Руководитель000 Мы также посмотрели, как себя показали сотрудники, которые не прошли обучение, в повторном фишинговом тесте. По данным отчёта, в первой волне повторного тестирования на фишинг попались 40% из всех, кто не обучался. Рисунок 28. Поиск информации о сотруднике в отчёте по атакам Подведение итогов После завершения всех этапов эксперимента мы получили следующие показатели:Иммунность — 76 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 91,3 %.Уровень риска — 7, средний. Рисунок 29. Информационная панель Phishman 2.35 после завершения эксперимента После обучения и повторного тестирования добавились другие показатели:Обученность — 11 / 100. Знания отсутствуют, обучение следует начать с базового уровня.Киберосознанность — 10 / 100. Низкий уровень, сотрудники не знают, как действовать в случае угроз.Часть результатов сравнили и представили их в таблице ниже. Таблица 3. Сравнение показателей киберкультуры до и после обученияПоказательДо обученияПосле обученияОбученность09319Иммунность81 %76 %Киберосознанность 07561Охват аудитории (повторно попались на фишинг)71 %91,3 %Уровень риска87 Также проанализировали действия сотрудников после обучения и сравнили их с результатами первичного тестирования. Таблица 4. Сравнение действий сотрудников до обучения и послеОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДо обученияПосле обученияДо обученияПосле обученияДо обученияПосле обученияДокументооборот004,76 %04,76 %0Продажи004,76 %09,52 %8,7 %Продюсеры 000023,8 %8,7 %Редакция08,7 %0019,04 %8,7 %Руководитель000000 Рисунок 30. Процент попавшихся на фишинг до обучения и после по отделам Если во время первичного тестирования попалось 22 % участников, то после обучения этот показатель уменьшился и стал 12 %. Рисунок 31. Общий процент попавшихся на фишинг до обучения и после Результаты повторного тестирования показали, что, несмотря на заметное снижение количества взаимодействий с фишинговыми письмами, часть сотрудников по-прежнему выполняет действия, свидетельствующие о подверженности атакам. Это ожидаемый результат, поскольку киберкультуру невозможно сформировать за столь короткое время. Речь идёт о длительном процессе, который требует регулярной работы как со стороны специалистов по информационной безопасности, так и со стороны самих сотрудников.Наш эксперимент позволил проверить знания сотрудников, провести обучение и затем оценить, насколько полученные знания закрепились на практике. Однако с точки зрения развития киберкультуры — это лишь один из этапов работы, а не её завершение.Сложности, с которыми мы столкнулисьОсобенность нашего эксперимента — организация предварительного тестирования. Перед запуском каждой атаки мы проверяли её работу на собственном аккаунте, чтобы убедиться в корректной отработке сценария на стороне пользователя. Такие проверки попадали в общую статистику системы и оказывали влияние на итоговые показатели. Возможность исключить подобные события из расчётов отсутствует. Согласно комментариям вендора, для этих целей следует использовать отдельный тестовый стенд. Поэтому мы вели дополнительно самостоятельный анализ результатов эксперимента.Отдельные сложности возникли на этапе обучения сотрудников. Завершить обучение в установленные сроки не удалось из-за человеческого фактора. Не все участники смогли своевременно пройти назначенные материалы, что потребовало увеличения периода обучения и дополнительного контроля за его прохождением.Впечатления от проекта команды «АМ Медиа»Проведение тестирования не вызвало негативной реакции со стороны сотрудников. Хотя фишинговые сообщения активно обсуждались внутри коллектива, жалоб руководству или недовольства вида «зачем вообще было устраивать такую проверку» не возникло. Основной интерес был сосредоточен вокруг самих писем и попыток понять, что именно происходит.Реакция сотрудниковОдним из самых любопытных наблюдений стала реакция сотрудников после первой волны первичного тестирования. Полученные фишинговые сообщения быстро стали предметом обсуждения: сотрудники пересылали их друг другу, задавали вопросы коллегам и пытались разобраться, что происходит.Некоторые пошли ещё дальше и вступали в переписку с отправителем, воспринимая фишинговые письма как реальные рабочие сообщения. Это наглядно показало не только убедительность используемых сценариев, но и то, что практическое столкновение с угрозой вовлекает сотрудников в тему ИБ гораздо сильнее, чем абстрактные примеры из учебных материалов. Во время повторного тестирования такой реакции уже не возникло.Реакция организаторовЕсли для большинства сотрудников тестирование выглядело как неожиданно появившиеся письма в почте, то для команды, которой было поручено тестирование Phishman 2.35 этот проект сопровождался совсем другими эмоциями. Подготовка сценариев, запуск атак и ожидание результатов вызывали ощутимое волнение. Оказалось, что смотреть на ситуацию глазами злоумышленника не так просто, как может показаться со стороны. Приходилось постоянно задавать себе вопросы: какой сценарий покажется правдоподобным, что привлечёт внимание сотрудника, а что, наоборот, вызовет подозрения.Самыми напряжёнными были дни первой волны тестирования. На этом этапе ещё не было понимания, как сотрудники отреагируют на рассылки, насколько убедительными окажутся сценарии и не вызовет ли проверка негативной реакции внутри коллектива. С каждой новой зафиксированной активностью интерес смешивался с тревогой, а результаты ожидались едва ли не с большим нетерпением, чем сам запуск кампании.После завершения эксперимента стало легче: всё задуманное удалось реализовать, результаты были получены и проанализированы. Тем не менее полностью избавиться от мыслей о проделанной работе не получилось. Время от времени возвращаешься к отдельным этапам и задаёшься вопросом: а стоило ли сделать именно так? Может быть, какой-то сценарий можно было построить иначе, а какие-то решения принять по-другому?Наверное, это естественная часть любого практического проекта. Когда работа заканчивается, появляется возможность посмотреть на неё со стороны и критически оценить собственные решения. Именно в такие моменты часто приходят идеи, которые помогают сделать следующие проекты лучше.Сотрудничество с вендоромВ ходе подготовки и проведения эксперимента иногда возникали вопросы, связанные с настройкой платформы, особенностями реализации отдельных сценариев и интерпретацией результатов. Для их решения использовались как переписка, так и рабочие созвоны. Запросы обрабатывались оперативно, что позволяло своевременно получать необходимую информацию и не допускать задержек в выполнении работ. Поддержка была доступна не только в рабочее время, но и в выходные дни.ВыводыПовторное тестирование показало, что тщательно подготовленные и персонализированные фишинговые атаки значительно эффективнее. При наличии качественной разведки злоумышленники способны подобрать убедительный сценарий практически для любого сотрудника. А если специалист может ошибиться, то сотруднику, который не занимается вопросами ИБ каждый день, сделать это ещё проще.Работа в сфере информационной безопасности или информационных технологий сама по себе не защищает человека от фишинга, социальной инженерии и других современных атак. Мы убедились в этом на собственном опыте: даже профильные знания не гарантируют, что человек не попадется на хорошо продуманную атаку. Злоумышленники постоянно меняют сценарии, поэтому знания, полученные однажды, быстро устаревают.При помощи эксперимента мы не только проверили, насколько сотрудники готовы распознавать атаки, но и поняли, как с помощью Phishman 2.35 можно сделать работу по развитию киберкультуры системной. Вместо отдельных курсов появился понятный цикл: смоделировать атаку, оценить реакцию, провести обучение и проверить, изменилось ли поведение участников. При необходимости — повторить или скорректировать процесс при помощи рекомендаций платформы. Результаты фиксируются автоматически, поэтому можно видеть, какие темы требуют больше внимания, и развивать киберкультуру на основе реальных данных, а не предположений.Читать далее
    • PR55.RP55
    • santy
      RP55, есть у тебя ТГ?
×