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

Тест самозащиты антивирусов x64 (результаты)

Recommended Posts

Сергей Ильин
Взять КИС поставить его в ручной режим и результат будет уже другим, так как трудно будет попасть в KernelMode или использовать права LocalSystem итд.

А если ещё и рессурсы подкрутить и ещё пару галок кое где поставить ... то результат будет вообще третим.... smile.gif

Давайте конкретнее, какие настройки могут повлиять на самозащиту? Приведите примеры. Еще раз, мы не запускаем малвару, которая может как-то там определиться проактивкой. Файлы чистые и для антивируса неизвестные. Затачиваться под тулзы (заносить их в какие-то либо ограничения) нельзя, иначе это уже совсем другой тест. Да еще одна вещь, Тестовые утилиты действуют из под User Mode.

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

Домохозяйки нигде ковыряться не хотят и не будут, поверьте мне :) У них есть дела поважнее. Есть даже целые сообщества типа FlyLady.ru. Люди думают как все успевать и оптимизировать свое время, а вы говорите настройки антивируса ковырять :) Как поставили, так и работает. Логика проста: они профи, знают как нужно. В этом как очень частая уловка вендоров. Они говорят, что наши продукты самые суперфункциональные, а на деле в настройках этот самый функционал отключен по разным причинам, в основном из-за желания уменьшить ресурсоемкость. А это уже прямая манипуляция. Вам продают делая на упор на какую-то фишку, а на самом деле вы ей не пользуетесь. Нужно ли нам этому подыгрывать?

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


Ссылка на сообщение
Поделиться на другие сайты
KIS_fan
Давайте конкретнее, какие настройки могут повлиять на самозащиту? Приведите примеры. Еще раз, мы не запускаем малвару, которая может как-то там определиться проактивкой. Файлы чистые и для антивируса неизвестные. Затачиваться под тулзы (заносить их в какие-то либо ограничения) нельзя, иначе это уже совсем другой тест. Да еще одна вещь, Тестовые утилиты действуют из под User Mode.

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

Примеры:

1) Получить права LocalSystem в авто режиме - раз плюнуть. А в ручном режиме будет очень сложно, а с дополнительными рессурсами это

будет невозможно.

2) Попасть в KernelMode в авто режиме - не так сложно. А в ручном режиме будет сложно а с дополнительными рессурсами ( которые также закрывают/могут закрывать баги в продукте ) будет можно сказать невозможно.

  • Upvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
strat
2) Попасть в KernelMode в авто режиме - не так сложно. А в ручном режиме будет сложно а с дополнительными рессурсами

Я вижу рациональное зерно в утверждении, но как же быть с ответом "разрешить" в ручном режиме, и что конкретно менять в дополнительных ресурсах, что это, защита от winlock? Т.е. если сделать настройки antiwinlock, малварь не пролезет в автозагрузку, не сможет выбить ав в safe mode, типа этого?

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


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

То, о чем тут говорится имеет прямое отношение, блин, к динамическому тесту АМ, а не к тесту самозащиты.

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


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

Чего голословно? Хук запихать или WriteProcessMemory/CreateRemoteThread? Половину этих тестов даже писать не надо, можно накопипастить из готовых проектов или даже из гугля.

Потому ему не нужно заниматься не своим делом. Как экспертам портала не стоит заниматься хирургией, например.

Может это решение "ему" предоставим?

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

Я выше просил, не нужно меня "стращать" этими "страшными" утилитами. Информация, необходимая злоумышленнику, в тестах уже есть. Объясняю на пальцах. Если я 1) захочу прибить, скажем, Эмси, 2) Знаю, как это написать, то мне достаточно просто посмотреть итоговую табличку из теста и, а--га, Эмси, ACL на файлах и в реестре, оконные сообщения, модификация реестра... Остается спокойно это всё набросать, скачать пробник Эмси и через пару часиков у меня готовая "убивалка". А вот если предположить, что я 1) понятия не имею как это писать, 2) хочу защитить Эмси от этих неприятностей, то инфы для этого - нуль. Ни что где нажать, ни есть ли это "нажать" вообще в продукте. И что этот "я" должен делать в такой ситуации? Идти на форум и выслушивать про "домохозяек"? Ещё раз, кратенько, вся необходимая информация для нападения в тесте имеется, информация для защиты от такого нападения - отсутствует в принципе. Пойдёт такое объяснение?

Это тест на дефолтных настройках - согласно статистикам эти настройки не меняются в 90 и более процентах случаев. Вообще не меняются. И да, это не обзор продуктов, хотя обзоры также публикуются и ты можешь найти их здесь. Ну, могу дать ссылку на свой, например: http://www.anti-malware.ru/node/2149

Лидер теста живет на настройках по умолчанию пять секунд. Или сколько там понадобится, чтобы отправить систему в рестарт. После этого по нему можно справлять поминки. И что же, позволю себе поинтересоваться, произошло с этим тестом? Почему там всё на максимальных настройках? Может потому, что "некоторые" этот тест на дефолте пролетают со свистом? А что такое случилось с Матюшеком, что он тестирует продукты на максимуме, что даёт вполне адекватное представление о возможностях каждого продукта. А не о том, как их настроил изготовитель, исходя из каких угодно соображений, области использования, целевой аудитории, совместимости, юзабельности, даже рынка сбыта (тут вот, немного не в тему, недавно, выяснилось, что KPM использует RC4 по умолчанию. Обсудим все преимущества XOR-шифрования для "домохозяек"?) Надо уточнять, куда отправятся "некоторые" продукты со своего почетного шестого места при заводских настройках? Так почему же такая избирательность в разных тестах у одной команды тестировщиков?

В любом режиме работы KIS поднимается алерт на установку/запуск драйвера, если это делает не доверенное (т.е. слабоограниченное и ниже) приложение с не доверенным драйвером.

:lol: А я потому и сделал оговорку про ленивых. Ленивые будут долбиться в SCM, а неленивые полезут туда через другой процесс, через физпамять, через физдиск, через модификацию реестра, через... да что я, собственно, перечисляю, всё это есть в "тесте на пронкновение".

-----------------------------------

Затачиваться под тулзы (заносить их в какие-то либо ограничения) нельзя, иначе это уже совсем другой тест. Да еще одна вещь, Тестовые утилиты действуют из под User Mode.

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

И маленькая просьба, раз уж речь идёт про UM, можно попросить обходиться в статья без "нагоняющих трепет" префиксов "Zw". MS на этот счёт вполне четкие рекомендации, просто чтобы не сбивало с толку при прочтении.

Домохозяйки нигде ковыряться не хотят и не будут, поверьте мне :) У них есть дела поважнее. Есть даже целые сообщества типа FlyLady.ru.

Почему это я должен верить? И можно попросить поменьше этих "домохозяек" и этого снобизма? Я уже выше написал, что вижу, что результаты в части комодо, например, не совсем совпадают с практикой. Что я должен думать? Мне, и не только мне, известны некоторые хитрости по обходу минимальных настроек, но как я могу быть уверен, что здесь не используется что-то другое? Как я могу быть уверен, что это "другое" годится только для настроек по умолчанию? Что я должен делать в такой ситуации? Падать в ножки, и умолять что я не "домохозяйка"? Вот человек спрашивает:

Кстати, а можно попросить внештатно проверить (ради того же пресловутого спортивного интереса) воспроизводимость проблемных пунктов для Dr.Web на версии Dr.Web, находящейся в открытом бета-тестировании при включённой функции (см. скриншот)?

Он тоже "домохозяйка"? И что в ответ? "Можно будет проверить на досуге." Вот спасибо.

Люди думают как все успевать и оптимизировать свое время, а вы говорите настройки антивируса ковырять :) Как поставили, так и работает. Логика проста: они профи, знают как нужно.

Вы прямо-таки мои мысли читаете:

http://forum.kaspersky.com/index.php?showt...t&p=1543080

http://forum.kaspersky.com/index.php?showt...t&p=1564678

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

А можно попросить, что называется, "нагнать конкретики"?

  • Upvote 10

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


Ссылка на сообщение
Поделиться на другие сайты
Umnik
Чего голословно? Хук запихать или WriteProcessMemory/CreateRemoteThread? Половину этих тестов даже писать не надо, можно накопипастить из готовых проектов или даже из гугля.

Ты уже смотрел утилиты, написанные Рабиновичем, чтобы убить продукты? И в них Илья, конечно, использовал этот метод? Везде.

Может это решение "ему" предоставим?

Пошли переброски глупостями.

Пойдёт такое объяснение?

Да. Это причина не выкладывать тулзы для всех, т.к. кому надо - знают методы, а плодить кидди, нафик надо?

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

Ну и то, что дальше:

1. Слышать звон

2. Не по теме

3. Графомания

4. Полное игнорирование требований. Как на этапе их составления (публичного, обращу внимания), так и после выкатки результатов.

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


Ссылка на сообщение
Поделиться на другие сайты
KIS_fan
Я вижу рациональное зерно в утверждении, но как же быть с ответом "разрешить" в ручном режиме, и что конкретно менять в дополнительных ресурсах, что это, защита от winlock? Т.е. если сделать настройки antiwinlock, малварь не пролезет в автозагрузку, не сможет выбить ав в safe mode, типа этого?

Под ресурсами подрузамевается весь реестер (все его ключи и ветки) и весь Локальный диск. И ещё много чего отдельного...

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


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

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

WriteProcessMemory/CreateRemoteThread?

К слову это есть и всегда было в тесте. Вы не внимательно читали методологию.

После этого по нему можно справлять поминки. И что же, позволю себе поинтересоваться, произошло с этим тестом? Почему там всё на максимальных настройках?

Это не тест, а сравнение-исследование. Там проверяются возможности противостояния проникновению в ядро в принципе, любыми средствами, которые доступны в арсенале продукта, но это все оффтоп.

А можно попросить, что называется, "нагнать конкретики"?

Одни хвалятся продвинутой эвристикой, которую отключают по дефолту. Другие хвалятся поддержкой упаковщиков, но почему-то тоже по умолчанию забывают поставить нужную галку. У третьих хипс работает в полную силу только в том случае, если при уставновке выбрать некий "расширенный режим" :wacko: . Сколько можно морочить голову людям? Если функционал нужен и важен, включайте его по-умолчанию!

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


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

Обсуждение скина Пипкина тут: http://www.anti-malware.ru/forum/index.php?showtopic=9162

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


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

Хохо касперский снова платиновый... реальный отжиг от тестеров!

У вас кроме касперского в лидерах бывают, бывали, другие антивирусы?

почему я не могу в репу ставить + и -? че за жлобство со стороны админов?

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


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

По всей видимости некоторым людям очень трудно свыкнутся с мыслью, что ЛК делает приличные продукты и именно поэтому ее продукты зачастую побеждают в тестах. Гораздо легче все свалить на предвзятость тестеров и аффилированность АМ. Думаю, что такие беспочвенные обвинения нужно квалифицировать как заезжанный низкопробный троллинг со всеми вытекающими отсюда последствиями.

Господа, неужели вы думаете что АМ будет специально занижать результаты тестирования какого-либо продукта (включая Касперского), для того, чтобы создать видимость обективности портала и непредвзятости тестеров?

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

На всякий случай скажу, что не пользуюсь продукцией ЛК уже более 4 лет и не считаю использование ее продуктов единственно возможным способом надежно защитить компьютер.

  • Upvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
ntoskrnl
Ты уже смотрел утилиты, написанные Рабиновичем, чтобы убить продукты? И в них Илья, конечно, использовал этот метод? Везде.

Я ещё раз повторяю, эксперту, если он действительно эксперт, нет нужды смотреть "утилиты", ему достаточно посмотреть, что эти утилиты делают и какими средствами, благо всё это в результатах теста указано. Это искать дыры долго и нудно, а написать по готовому заданию или описанию несколько десятков строчек, особенно когда они уже где-то написаны, - дело минут или десятков минут. Для экспертов, разумеется.

Пошли переброски глупостями.

Да. Это причина не выкладывать тулзы для всех, т.к. кому надо - знают методы, а плодить кидди, нафик надо?

Ну и то, что дальше:

1. Слышать звон

2. Не по теме

3. Графомания

4. Полное игнорирование требований. Как на этапе их составления (публичного, обращу внимания), так и после выкатки результатов.

По существу возражений нет, правильно понимаю? И не надо тыкать, мы не на базаре.

----------------------------

К слову это есть и всегда было в тесте. Вы не внимательно читали методологию.

Я не понял, к чему Вы это написали применительно к контексту того обсуждения. Можете уточнить, что именно я невнимательно читал?

Это не тест, а сравнение-исследование. Там проверяются возможности противостояния проникновению в ядро в принципе, любыми средствами, которые доступны в арсенале продукта, но это все оффтоп.

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

Одни хвалятся продвинутой эвристикой, которую отключают по дефолту. Другие хвалятся поддержкой упаковщиков, но почему-то тоже по умолчанию забывают поставить нужную галку. У третьих хипс работает в полную силу только в том случае, если при уставновке выбрать некий "расширенный режим" :wacko: . Сколько можно морочить голову людям? Если функционал нужен и важен, включайте его по-умолчанию!

Я не вижу здесь никакой конкретики. Вот честно, не вижу.

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


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
Давайте обойдёмся без жонглирования словами. На форуме это упоминается в качестве "теста", там везде есть фразы "методология теста", "участники теста", "результаты теста" и т.д. И мне просто интересно понять, в чём принципиальная разница этих тестов-"сравнений", что так радикально отличаются настройки продуктов.

Давайте обойдемся без навязывание своей точки зрения, ок? Мы не считаем тот тест полноценным, поэтому он называется сравнением. Надеюсь я четко выразился. Мы сделали исследование потенциальных (максимальных) возможностей продуктов, поэтому настройки закручивались как только можно сильно. В данном тесте мы использовали строго настройки по умолчанию. И будем продолжать тестировать именно с такими настройками. Я не собираюсь больше тратить время на доказывание очевидных вещей - 80-90% юзеров используют настройки по умолчанию и тест мы делаем для них.

Я не понял, к чему Вы это написали применительно к контексту того обсуждения. Можете уточнить, что именно я невнимательно читал?

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

Я не вижу здесь никакой конкретики. Вот честно, не вижу.

Ваши проблемы. Кто знает продукты прекрасно понял о чем идет речь. Я не собираюсь публично кого-то тут "разоблачать".

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


Ссылка на сообщение
Поделиться на другие сайты
ntoskrnl
Давайте обойдемся без навязывание своей точки зрения, ок? Мы не считаем тот тест полноценным, поэтому он называется сравнением. Надеюсь я четко выразился. Мы сделали исследование потенциальных (максимальных) возможностей продуктов, поэтому настройки закручивались как только можно сильно. В данном тесте мы использовали строго настройки по умолчанию. И будем продолжать тестировать именно с такими настройками. Я не собираюсь больше тратить время на доказывание очевидных вещей - 80-90% юзеров используют настройки по умолчанию и тест мы делаем для них.

А Вы знаете, я не навязываю свою точку зрения. В отличие от Вас. Я задал несколько простых вопросов, в частности, почему так сильно отличаются методики, тем более, что эти тесты весьма взаимосвязаны. Вы и сами так считаете:

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

но, почему-то, продолжаете настаивать на лингвистических различиях и каких-то "неполноценностях". Кстати, в какой из редакций того "сравнения" оно стало "сравнением"? В первой, или во второй? Я уже не помню просто, но топик на форуме однозначно говорит о тесте. И Вы, будучи автором теста, можете ответить на один простой вопрос о тестировании Комодо? Я могу даже его переформулировать, как так получилось, что тестовые утилиты оказались не в ограничениях? Ведь это же настройка по умолчанию, у "90% юзеров".

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

Зачем мне его перечитывать, если Вы не можете объяснить, что имеете в виду? Свою точку зрения я уже высказал.

Ваши проблемы. Кто знает продукты прекрасно понял о чем идет речь. Я не собираюсь публично кого-то тут "разоблачать".

С чего Вы взяли, что я "не понял". Но зачем Вы приводите аргументы, если не хотите их кокретизировать?

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


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

Я бы сказал, что настройки по умолчанию у любых программ используют 98% пользователей. Любителей поковыряться не так много, как кажется тем, кто сам "в теме".

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


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

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

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


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

Вопрос: Были ли проблемы с Comodo? А то где-то читал, что он не совсем дружит с виртуальными системами

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


Ссылка на сообщение
Поделиться на другие сайты
Kopeicev
Вопрос: Были ли проблемы с Comodo? А то где-то читал, что он не совсем дружит с виртуальными системами

Нет не было. Он не дружит с VirtualBox, как и многие другие АВ. Мы использовали Vmware

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


Ссылка на сообщение
Поделиться на другие сайты
Dmitriy K
Вопрос: Были ли проблемы с Comodo? А то где-то читал, что он не совсем дружит с виртуальными системами

кое кто опять что-то напутал? :lol:

вы же знаете кто ;)

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


Ссылка на сообщение
Поделиться на другие сайты
ntoskrnl
Вопрос: Были ли проблемы с Comodo? А то где-то читал, что он не совсем дружит с виртуальными системами

Проблемы с Comodo, судя по результатам теста, заключались в том, что тесты работали в доверенном режиме. Хотя при настройках по умолчанию, на которые здесь все усиленно напирают, неизвестные программы считаются им недоверенными и произвести указанные, как "непройденные" действия не могут, это есть даже в руководстве пользователя. И вопрос здесь не о Comodo конкретно, а а том, по каким причинам для одного из участников теста, фактически, была изменена методика тестирования. А тестирование под виртуалкой это вообще детский садик.

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


Ссылка на сообщение
Поделиться на другие сайты
senyak
кое кто опять что-то напутал? :lol:

вы же знаете кто ;)

Кто и что? Меня интересует именно Comodo. Мне ответили, за что спасибо

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


Ссылка на сообщение
Поделиться на другие сайты
A.
Проблемы с Comodo, судя по результатам теста, заключались в том, что тесты работали в доверенном режиме. Хотя при настройках по умолчанию, на которые здесь все усиленно напирают, неизвестные программы считаются им недоверенными и произвести указанные, как "непройденные" действия не могут, это есть даже в руководстве пользователя. И вопрос здесь не о Comodo конкретно, а а том, по каким причинам для одного из участников теста, фактически, была изменена методика тестирования.

Вопрос именно в Комодо, конкретно.

Вы сами посудите - для проведения теста программы необходимо запустить. Вредоносными они не являются. Блокировка всего - это конечно забавно, но как же пользователи Комода вообще что либо на свои машины ставят ? Ждут пока файлы в "доверенные" кто-то добавит или делают это сами ? Ок, вот в ситуации когда пользователь сам файлы в доверенные внесет (из-за социальной инженерии, например) или эти файлы попадут в базу доверенных сами - Комодо и покажет тот результат, который он показал.

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

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


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
Если не поняли, то вот еще более простой пример-вопрос: - какой-то вендор тупо взял и задетектил все тестовые программы как вредоносные. И при запуске их - сигнатурами детектит и удаляет. Означает ли это что данная антивирусная программа неуязвима для типов атак, использованных в тестах ?

ntoskrnl, а такое кстати уже было в нашей практике.

Вообще тесты следует всего далеть таким образом, чтобы была проверка наихудшего сценария. И только так. Если можно нажать "Отменить/пропустить" - продукт теряет баллы. Ибо всегда найдется % юзеров которые так и сделают. Можно записать себе как теорему. К тому же другие вендоры как-то защищают в актоматическом режиме и ничего не спрашивают, не требуют "дурацкого" обучения, "расширенного режима" и т.п. Приравнивать их результаты ИМХО было бы очень несправедливо.

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


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

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

Вы сами посудите - для проведения теста программы необходимо запустить. Вредоносными они не являются. Блокировка всего - это конечно забавно, но как же пользователи Комода вообще что либо на свои машины ставят ? Ждут пока файлы в "доверенные" кто-то добавит или делают это сами ? Ок, вот в ситуации когда пользователь сам файлы в доверенные внесет (из-за социальной инженерии, например) или эти файлы попадут в базу доверенных сами - Комодо и покажет тот результат, который он показал.

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

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

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

-----------------------------------

ntoskrnl, а такое кстати уже было в нашей практике.

Вообще тесты следует всего далеть таким образом, чтобы была проверка наихудшего сценария. И только так. Если можно нажать "Отменить/пропустить" - продукт теряет баллы. Ибо всегда найдется % юзеров которые так и сделают. Можно записать себе как теорему. К тому же другие вендоры как-то защищают в актоматическом режиме и ничего не спрашивают, не требуют "дурацкого" обучения, "расширенного режима" и т.п. Приравнивать их результаты ИМХО было бы очень несправедливо.

То есть Вы уже не настаиваете, как раньше, на том, что всё должно делаться на настройках по умолчанию? Уже, оказывается, надо настроить продукт на минимальную защиту? А не рекомендованую изготовителем? Давайте разберемся с простым вопросом. Ручное добавление теста в доверенные, тогда как в реальной жизни при указанных настройках, он попадает в недоверенные, это нормально? Что конкретно проверялось? Я уже спрашивал, проверялся функционал продукта, или конкретные настройки, в том числе внесенные тестером в политику безопасности.

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


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

А где было написано что это был тест HIPSов или песочниц ? Их тестируют в другом тесте и по другой методике, в разделе "тесты" найдете.

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


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

  • Сообщения

    • 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, есть у тебя ТГ?
×