Тест антивирусов на детектирование полиморфных вирусов (результаты) - Страница 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
      Домашние антивирусы для Windows были обновлены до версии 19.0.14.
    • PR55.RP55
      Microsoft ускоряет Проводник в Windows 11 с помощью предзагрузки https://www.comss.ru/page.php?id=18618
    • AM_Bot
      Вендор Crosstech Solutions Group выпустил решение для защиты контейнерной инфраструктуры Crosstech Container Security (CTCS). Оно обеспечивает безопасность контейнерных сред: от сканирования образов до контроля запуска рабочих нагрузок и реагирования на инциденты в средах выполнения.      ВведениеФункциональные возможности Crosstech Container Security2.1. Анализ и контроль безопасности образов2.2. Контроль запуска контейнеров2.3. Безопасность в средах выполнения (Runtime Security)2.4. Безопасность окружения2.5. Внешние интеграцииАрхитектура Crosstech Container Security3.1. Основные компоненты Crosstech Container SecurityСистемные требования и лицензирование Crosstech Container Security4.1. Лицензирование4.2. Требования к аппаратной части4.3. Требования к программной части4.4. Процесс установкиСценарии использования5.1. Сценарий №1. Сканирование образов5.2. Сценарий №2. Политики безопасности образов контейнеров5.3. Сценарий №3. Контроль запуска контейнеров5.4. Сценарий №4. Мониторинг безопасности сред выполненияВыводыВведениеРоссийский рынок контейнерных разработок постоянно растёт. В 2024 году затраты на ПО для контейнеризации достигли 3 млрд рублей — это на 66 % больше, чем в 2023. Контейнерные технологии ускоряют процессы разработки, экономят ресурсы компаний, поэтому их всё чаще внедряют в свою работу ИТ-департаменты.Вместе с ростом масштабов контейнеризации увеличивается и поверхность атак: уязвимости в образах, ошибки конфигураций, несанкционированные действия внутри контейнеров. Crosstech Container Security помогает компаниям выстраивать комплексную систему защиты контейнерной инфраструктуры.Функциональные возможности Crosstech Container SecurityCrosstech Container Security объединяет функции анализа, мониторинга и управления безопасностью контейнерных сред. Решение охватывает весь жизненный цикл контейнера — от момента его создания до удаления. Продукт помогает DevSecOps-командам выявлять уязвимости, проверять конфигурации, контролировать сетевую активность и реагировать на инциденты в режиме реального времени.Анализ и контроль безопасности образовCrosstech Container Security интегрируется с реестрами хранения образов и позволяет проводить их сканирование как в ручном режиме, так и по расписанию. В результате анализа система обнаруживает дефекты в образах: уязвимости, неправильные конфигурации, секреты, а также фиксирует используемые в образах OSS-лицензии для пакетов и библиотек. По каждому найденному дефекту предоставляется детальная информация.CTCS поддерживает экспорт SBOM в форматах SPDX и CycloneDx, что упрощает аудит и обмен данными с другими решениями. Интерфейс продукта предоставляет визуализацию образов с маппингом (сопоставлением данных) на дефекты безопасности. CTCS также осуществляет дискаверинг (обнаружение) образов, располагающихся в защищаемых кластерах и на standalone-хостах.Для автоматизации контроля доступны настраиваемые политики безопасности образов, разделяемые по критериям:наличие уязвимостей в образах контейнеров выше заданной оценки критичности;наличие уязвимостей в образах контейнеров согласно заданным идентификаторам;обнаружение root в Dockerfile;возможность указания перечня образов, на которые будет распространяться созданная политика безопасности образов.При нарушении хотя бы одного из критериев политики администратор получает уведомление в интерфейсе CTCS и может оперативно принять меры: заблокировать образ, исключить его из деплоя или добавить в список исключений с указанием причины. Такой подход обеспечивает прозрачность процессов и повышает уровень доверия к среде разработки и эксплуатации.Контроль запуска контейнеровРешение обеспечивает контроль запуска контейнеров как в средах Kubernetes, так и на отдельных standalone-хостах в соответствии с заданными политиками безопасности. Это позволяет предотвращать запуск рабочих нагрузок, не соответствующих требованиям безопасности компании, ещё на этапе их инициализации.В зависимости от настроек администратор может выбрать режим реагирования: блокирование или оповещение о нарушении политики безопасности. Информация обо всех срабатываниях отображается в интерфейсе системы, обеспечивая прозрачность и возможность оперативного реагирования.Политики безопасности включают следующие критерии:попытка запуска контейнеров на базе образов, не соответствующих политикам безопасности;попытка запуска контейнеров из-под пользователя root;попытка запуска контейнеров с повышенными привилегиями ядра Linux;контроль запуска контейнеров на базе образов, не прошедших сканирование CTCS.Дополнительно решение поддерживает интеграцию с OPA Gatekeeper и имеет возможность создания и импорта политик через интерфейс CTCS.Безопасность в средах выполнения (Runtime Security)CTCS использует возможности инструмента Tetragon для создания и применения кастомных политик безопасности, позволяющих контролировать сетевые взаимодействия внутри контейнеров. Администраторы могут выбрать набор кластеров для распространения политик, что обеспечивает гибкость при внедрении требований безопасности.Вся информация о срабатываниях политик фиксируется в интерфейсе CTCS, предоставляя специалистам по информационной безопасности прозрачную картину активности в средах выполнения и возможность оперативного реагирования на инциденты.Безопасность окруженияРешение выполняет сканирование кластеров на соответствие стандартам конфигурирования CIS Kubernetes Benchmarks. Аналогично система проводит проверку standalone-хостов на соответствие CIS Docker Benchmarks. Дополнительно CTCS поддерживает сканирование конфигурационных файлов, расположенных в директориях нод кластеров, выполняя роль сканера на основе IaC (Infrastructure as Code, управление инфраструктурой через использование кода).Внешние интеграцииРешение поддерживает интеграцию с реестрами хранения образов, что обеспечивает доступ к актуальным данным для анализа и контроля безопасности контейнеров. Также CTCS поддерживает передачу журналов событий в системы сбора по протоколу Syslog для их централизованного хранения и обработки.Доступна интеграция с системой идентификации, управления доступом Keycloak с поддержкой OAuth и доменными службами каталогов. Это позволяет пользователям авторизовываться в интерфейсе системы через доменные учётные записи. Рисунок 1. Планы по развитию Crosstech Container Security Архитектура Crosstech Container SecurityАрхитектура CTCS реализована в формате однонаправленных соединений со стороны ядра системы в сторону агентов защиты (протокол TCP/IP), располагающихся в защищаемых кластерах. Такой подход позволяет использовать инстанс ядра в единственном экземпляре для инфраструктур, сегментированных по уровням доверия. Рисунок 2. Логическая архитектура Crosstech Container Security Основные компоненты Crosstech Container SecurityCTCS состоит из 3 основных компонентов:CTCS Core — группа микросервисов, отвечающая за управление системой: хранение данных, настроек, создание политик безопасности, бизнес-логика продукта, а также взаимодействие со смежными системами.CTCS Agent-Manager: модуль агент-менеджера реализован в формате оператора Kubernetes с целью контроля за установкой и изменениями кастомных ресурсов (custom resource definition, CRD), а также управления и передачи информации агент-воркерам, устанавливаемым на каждую защищаемую ноду в формате DaemonSet.CTCS Scanner — модуль, сканирующий образы контейнеров на уязвимости, неправильные конфигурации, конфиденциальные данные, информацию по OSS-лицензиям для пакетов и библиотек из состава образа, а также сканирующий кластеры на соответствие стандартам конфигурирования.Системные требования и лицензирование Crosstech Container SecurityПеред выбором модели лицензирования заказчикам рекомендуется оценить масштаб защищаемой инфраструктуры и нагрузку на кластеры. Crosstech Container Security предусматривает гибкий подход: ядро и агенты могут разворачиваться в разных сегментах сети, включая тестовые и продуктивные среды. Такой принцип позволяет оптимально распределять ресурсы и лицензии, избегая избыточных затрат.ЛицензированиеCTCS лицензируется по количеству защищаемых нод, на которые распространяются агенты защиты.В продукте реализовано гибкое лицензирование, которое позволяет заказчикам самостоятельно выбирать перечень защищаемых объектов. При достижении лимита по количеству лицензий, предусмотренных договором, администратор может отключить часть текущих объектов защиты и переназначить лицензии на новые кластеры и ноды. Рисунок 3. Включение/выключение агентов защиты Рисунок 4. Лицензии CTCS На странице лицензирования доступна подробная информация о параметрах действующей лицензии. Пользователь видит:количество оставшихся дней действия лицензии;количество нод, предусмотренных лицензией;актуальные данные о числе используемых нод в рамках лицензии;сведения о типе лицензии;информация о поставщике;информация о владельце лицензии.Рисунок 5. Страница «Лицензирование» Требования к аппаратной частиКластер, на котором производится установка CTCS, должен соответствовать минимальным характеристикам, приведённым ниже. Для определения значений millicpu (единицы времени процессора, эквивалентной тысячной части работы, которую может выполнить одно ядро CPU) рекомендуется воспользоваться документацией Kubernetes.Кластер, на который будет установлен helm-чарт ядра (без учёта сканера) должен иметь характеристики не ниже 8190 millicpu, 7410 MiB RAM.Для каждого экземпляра сканера: 3 CPU, 6 GB RAM, при добавлении дополнительных экземпляров значения увеличиваются пропорционально.В случае использования большего количества реплик значения пропорционально умножаются на их число. По умолчанию в чарте допускается до 6 реплик, что требует 18 CPU, 36 GB RAM.Каждый кластер для развёртывания чарт-агента должен иметь 2 CPU, 8 GB RAM.Необходимый минимум для каждой используемой СУБД PostgreSQL: 4 CPU, 8 GB RAM, 100 GB.Приведённые требования указаны для усреднённой конфигурации и могут быть изменены в зависимости от количества одновременных сканирований образов, генерируемых событий, деплоев, пространств имён (namespaces) и подов.Требования к программной частиДля корректной интеграции и работы приложение CTCS должно быть развёрнуто в кластере Kubernetes. При настройке системы в конфигурационном файле helm-чарта должны быть настроены необходимые параметры.Поддерживаемые контейнерные среды CRI (container runtime interface): containerd и docker.В момент выполнения инструкции на хосте администратора должны быть установлены следующие утилиты для выполнения установки:tar;helm;kubectl.Необходимые сервисы в инфраструктуре:PostgreSQL: рекомендуется размещать базу данных для хранения логов на отдельном инстансе от основной БД, чтобы избежать падения производительности основных операций при большом объёме логируемых событий;Keycloak (опционально, имеется возможность поставки в составе дистрибутива);Vault (опционально, имеется возможность использования стандартного объекта Kubernetes Secret).Требования к операционной системе и ядру:рекомендуется использовать ОС с версией ядра 5.4 или выше для обеспечения поддержки Tetragon;в ядре должна быть включена функция BTF;должны быть активированы модули eBPF и cgroup, а также корректным образом настроены или отключены модули безопасности Linux (LSM), контролирующие запуск eBPF-программ (в соответствии с официальной документацией Tetragon).Требования к версиям Kubernetes:центральная управляющая часть кластера – не ниже версии 1.23;дочерние кластеры – версия 1.23 или выше.Дополнительные требования:В кластере Kubernetes должен быть установлен, подключён и настроен storage class, в котором будет минимум 10 GB свободного места.В master-кластер должен быть установлен External Secrets (опционально).В дочерние кластеры должен быть установлен External Secrets (опционально).Во всех кластерах, где развёртывается ядро и агенты CTCS, должен быть установлен ingress-контроллер.Совокупность этих требований обеспечивает стабильную работу системы и корректное взаимодействие всех модулей CTCS. При соблюдении указанных параметров производительность решения остаётся предсказуемой даже при высокой интенсивности сканирований и большом количестве событий безопасности. Такой подход гарантирует надёжность, масштабируемость и устойчивость контейнерной инфраструктуры.Процесс установкиДля развёртывания CTCS вендор предоставляет архив, содержащий helm-чарты и образы системных контейнеров. При необходимости может быть предоставлена учётная запись для выгрузки дистрибутивов из репозиториев вендора напрямую.Сценарии использованияCrosstech Container Security закрывает ключевые задачи обеспечения безопасности контейнерных платформ — от анализа уязвимостей до защиты на уровне среды выполнения. Решение органично интегрируется в процессы DevSecOps и помогает компаниям повысить устойчивость инфраструктуры к современным киберугрозам без потери скорости разработки.Сценарий №1. Сканирование образовCTCS позволяет выполнять сканирование образов контейнеров, хранящихся как в интегрированных реестрах образов, так и локально в защищаемых кластерах. Рисунок 6. Подключённые реестры После интеграции с реестрами образов на вкладке «Образы» – «Реестры» отображается подключённый реестр и информация о хранящихся в нём образах. Реализовано в формате иерархии:Реестры.Название образа и количество его версий (тегов).Название образа и его версии.Карточка конкретного образа.Рисунок 7. Образ и список его версий Рисунок 8. Карточка образа На каждом уровне иерархии есть возможность запуска сканирования по требованию с выбором типа дефектов, которые будут учитываться в процессе сканирования. Дополнительно предоставляется общая информация об образе, данные о его соответствии установленным политикам, сведения о слоях образов с маппингом на обнаруженные дефекты. Рисунок 9. Слои образа На странице интеграций с реестрами в настройках доступно выставление расписания для проведения автоматизированного сканирования. Рисунок 10. Сканирование по расписанию Для работы с образами, обнаруженными локально в защищаемых кластерах, доступна отдельная вкладка «Образы» – «Локальные образы». Рисунок 11. Таблица локальных образов При запуске процесса сканирования доступен выбор ноды, на которой он будет проводиться. Если обнаруженный образ находится в интегрированном реестре, сканирование будет приоритетно выполняться на стороне ядра системы в рамках интеграции с реестром. Рисунок 12. Выбор нода для проведения сканирования Сценарий №2. Политики безопасности образов контейнеровВ рамках Crosstech Container Security реализовано создание политик безопасности для образов контейнеров. После их настройки система автоматически проверяет все известные образы на соответствие заданным критериям. По результатам проверки на карточке каждого образа отображается информация о соответствии или несоответствии политикам безопасности (Рисунок 7). Если образ нарушает несколько политик безопасности одновременно, в карточке отображается, какие именно политики безопасности были нарушены. Рисунок 13. Создание политики безопасности образов Сценарий №3. Контроль запуска контейнеровВ CTCS доступна интеграция с OPA Gatekeeper, обеспечивающая валидацию контейнерных деплоев и реагирование в соответствии с заданными политиками безопасности.При настройке политик безопасности доступен выбор режима реагирования — оповещение либо блокировка — а также определение перечня критериев безопасности, по которым будет осуществляться контроль. Рисунок 14. Таблица политик валидации и контроля запусков Политики безопасности могут создаваться по выделенным критериям (Рисунок 13) или импортироваться в виде кастомных политик (Рисунок 14). Рисунок 15. Создание политики валидации и контроля запусков Рисунок 16. Импорт кастомных политик безопасности Результаты срабатывания политик доступны в интерфейсе системы, что позволяет оперативно анализировать инциденты и корректировать настройки безопасности. Рисунок 17. Срабатывание политик валидации и контроля запусков Сценарий №4. Мониторинг безопасности сред выполненияВ текущей версии реализован мониторинг безопасности сред выполнения на базе Tetragon, что позволяет контролировать эксплуатацию рабочих нагрузок.В CTCS доступна форма для создания или импорта готовых политик безопасности с возможностью выбора области применения. Рисунок 18. Создание политики среды выполнения При срабатывании политик система отображает перечень событий в формате таблицы. Для каждого события можно перейти в режим детального просмотра, где отображается его идентификатор, дата и время создания, короткое описание и содержание в формате json. Рисунок 19. Событие срабатывания политики среды выполнения ВыводыАнализ решения Crosstech Container Security показал, что в версии 3.0.0 продукт предоставляет широкие функциональные возможности для защиты контейнерной инфраструктуры: от обеспечения безопасности образов контейнеров до контроля запуска и реагирования на нелегитимные процессы в средах выполнения в соответствии с политиками безопасности. CTCS также предоставляет инструменты для проведения сканирований защищаемых кластеров на соответствие стандартам конфигурирования, что повышает уровень безопасности контейнерной инфраструктуры.Достоинства:Архитектура. Благодаря однонаправленным соединениям со стороны ядра системы в сторону агентов защиты обеспечивается соответствие требованиям заказчиков, которые используют «Zero Trust»-модель на уровне сегментов инфраструктуры.Широкая площадь покрытия. CTCS обеспечивает контроль запуска контейнеров не только в рамках оркестратора Kubernetes, но и на отдельных хостах контейнеризации за счёт использования standalone-агентов.Гибкие возможности при работе с API. Весь функционал из веб-интерфейса CTCS также доступен для вызова через API, что позволяет специалистам заказчика решать нетривиальные задачи в рамках своей рабочей деятельности и интегрировать продукт в существующие процессы.Удобство при работе со сканированием образов. Иерархический подход обеспечивает гибкость при выборе области сканирования и повышает прозрачность анализа.Недостатки:Отсутствие возможности встраивания в процесс сборки (CI/CD) (планируется к реализации в первом квартале 2026 года).Отсутствие данных по ресурсам Kubernetes (Workloads, RBAC, Custom Resources, Feature Gates): планируется в 4-м квартале 2025 – 1-м квартале 2026).Отсутствие настройки гибкого разграничения прав доступа пользователей в интерфейс системы (реализация запланирована на первый квартал 2026).Отсутствие отчётности по результатам работы с системой (планируется в первом квартале 2026).Реклама, 18+. ООО «Кросстех Солюшнс Групп» ИНН 7722687219ERID: 2VfnxvVGwXfЧитать далее
    • demkd
    • PR55.RP55
      И ещё это: https://www.comss.ru/page.php?id=18330 Это и на работе Образов с Live CD может сказаться ?
×