.av-comparatives.org: QA of August 2007 test-set & corrections - Тесты и сравнения - Форумы Anti-Malware.ru Перейти к содержанию
Иван

.av-comparatives.org: QA of August 2007 test-set & corrections

Recommended Posts

Иван

Ваш друган Клементи ответил на вопросы читателей на тему того, что у него битых самплов в коллекции много

http://www.av-comparatives.org/seiten/ergebnisse/QA2007.pdf

говорит проверил коллекцию, которую использовал в августе 2007 года, битых самплов гооврит всего 0,4%

изменения говорит минимальные

change.PNG

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

забавно, что Frisk F-prot, который в лице Бончева один из главных "опускальщиков" тестов Клементи, самплы-то активненько долбит, которые в тестах напропускал, причем задолбил глядите скока (смотри насколько сократилось число невзятых самплов межуд августом и ноябрем) - и зачем же он долбит, если они битые?

missed.PNG

post-10-1206793625_thumb.png

post-10-1206793647_thumb.png

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
говорит проверил коллекцию, которую использовал в августе 2007 года, битых самплов гооврит всего 0,4%

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

Вот если вернуться к схеме награждения ( http://antimalware.ru/index.phtml?part=tes...ymorphic_awards ) теста на детект полиморфов ( http://antimalware.ru/index.phtml?part=tes...est=polymorphic ) нашего портала, то 0,4% битых сэмплов означало бы, что 3 балла нужно было давать за результат где-то от 99,5% до 100% детекта, а не за точно 100%-ый результат. Чего, конечно, сделано не было. Предлагаю Сергею Ильину и соответствующим экспертам АМ обратить на этот факт внимание при проведении аналогичных тестов.

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

При этом Клементи не учитывает, что улучшение детекта по "старым" вирусам может достигаться не только за счёт сэмплов, полученных от него после проведения теста но и по сэмплам/информации, полученным из других источников?

dr_dizel, а как Вы считаете? :)

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
При этом Клементи не учитывает, что улучшение детекта по "старым" вирусам может достигаться не только за счёт сэмплов, полученных от него после проведения теста но и по сэмплам/информации, полученным из других источников?

а как он это учитывать может, он ведь просто на детект смотрит,

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
но что- то мне подсказывает что такое вот резкое падение числа недетектируемых самплов у ф-прота вряд ли из-за получения их из сторонних источников

Конечно, график может показывать, насколько интенсивно вендоры используют полученную после теста информацию.

F-Prot, Avast, Fortinet явно сразу добавили большинство из недетектируемого, McAfee тоже добавил основную часть недетектируемого в этом тесте, но спустя месяц (оперативность страдает), а вот Microsoft и Dr.Web работает над детектом планомерно, не заостряя внимание на коллекции недетектируемого, которые передаются им после тестирования.

Опять же, эти выводы верны в случае, если мы коллекцию Клементи считаем идеально репрезентативной на момент проведения теста.

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

И здесь появляется дилемма. Нужно ли пропущенные сэмплы отсылать вендорам? По-хорошему стоит, если наша цель как независимых исследователей - борьба с вирусами в глобальных масштабах (а не только ранжирование антивирусов по некоторым показателям), т.е., так сказать, благородная миссия. Но для большей точности результатов будущих тестов (которые проводятся на большой выборке сэмплов, и если эта выборка от теста к тесту не обновляется на 100%) такие сэмплы вроде как отсылать не следует, ибо иначе в результатах появляются некоторые искусственно внесённые гармоники. Но во втором случае мы теряем в прозрачности/открытости результатов, невозможности их проверить. Отсылать проблемные сэмплы частично? Здесь свои проблемы - начнутся другие подозрения, типа таких, что показывается правда, но не вся.

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
вот Microsoft и Dr.Web работает над детектом планомерно, не заостряя внимание на коллекции недетектируемого, которые передаются им после тестирования.

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Валерий какой вы молодец и тут нашли положительный момент, не побежали видите ли сломя голову работать над ошибками как некоторые дурачки, нет - "они работают планомерно" tongue.gif

Нет, просто сделал выводы на основе графика, но вряд ли можно такой вывод назвать 100%-но соответствующим действительности.

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

Можно сделать и другое предположение. Например, присланная коллекция недетектируемого была подвергнута первоначальному анализу аналитиками Dr.Web, в результати было обнаружено множество битых файлов. На этом анализ коллекции был завершён как бесперспективный. Как было на самом деле - не знаю. Равно как не знаю, соответствут ли действительности то, что у Клементи не более 0,4% битых сэмплов в коллекции.

А вообще, 0,4% - это 4000 (!) битых сэмплов на миллион. И даже как-то не поворачивается язык говорить "всего лишь".

Добавка. В авгутсе 2007 г. у Клементи в тесте было 808.344 сэмпла ( http://www.av-comparatives.org/seiten/ergebnisse_2007_08.php ). Битых оказалось, только лишь по его собственному признанию, таким образом, 3.233 сэмпла. Это действительно именно "много".

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
Добавка. В авгутсе 2007 г. у Клементи в тесте было 808.344 сэмпла ( http://www.av-comparatives.org/seiten/ergebnisse_2007_08.php ). Битых оказалось, только лишь по его собственному признанию, таким образом, 3.233 сэмпла. Это действительно именно "много".

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
А во-вторых, он пишет что уже потратил и будет продолжать тратить много сил на уменьшение числа битых самплов при помощи написания специальных утилит их проверки

Это радует. Значительные силы и время были потрачены вендорами не совсем зря.

Но также никто из независимых экспертов не подтвердил исследование коллекции Клементи на количество битых сэмплов.

И вывод Клементи о том, что 0,4% битых сэмплов изменили уровень детекта максимум на 0,08% мне кажется каким-то неестественным. Мне всегда казалось, что среди непродетекченных антивирусами сэмплов должно быть как раз больше битых сэмплов, чем среди продетекченных.

А скорректированные результаты Клементи говорят о том, что все антивирусы детектят от 80 до 100% битых сэмплов, находящихся в коллекции, как вирусы. Также не считаю эту ситуацию здоровой.

Конечно, нет ничего плохого в том, если антивирус задетектит как вирус битый сэмпл этого вируса (ибо это в общем-то не ложное срабатывание - в файле и "хорошего" ничего нет). Но эта ситуация дискредетирует данный тест как показывающий реальные возможности антивирусов. И тогда по крайней мере нужно при показе результатов ставить интервал погрешности +/-0,5%, даже если при проверке выясняется, что результаты отличаются не так сильно при удалении битых сэмплов.

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


Ссылка на сообщение
Поделиться на другие сайты
dr_dizel
dr_dizel, а как Вы считаете? :)

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

Считаю любые тесты злом, а обсуждение их пустым занятием.

:P

  • Upvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
Виталий Я.
Это радует. Значительные силы и время были потрачены вендорами не совсем зря.

Но также никто из независимых экспертов не подтвердил исследование коллекции Клементи на количество битых сэмплов.

И вывод Клементи о том, что 0,4% битых сэмплов изменили уровень детекта максимум на 0,08% мне кажется каким-то неестественным. Мне всегда казалось, что среди непродетекченных антивирусами сэмплов должно быть как раз больше битых сэмплов, чем среди продетекченных.

А скорректированные результаты Клементи говорят о том, что все антивирусы детектят от 80 до 100% битых сэмплов, находящихся в коллекции, как вирусы. Также не считаю эту ситуацию здоровой.

Конечно, нет ничего плохого в том, если антивирус задетектит как вирус битый сэмпл этого вируса (ибо это в общем-то не ложное срабатывание - в файле и "хорошего" ничего нет). Но эта ситуация дискредетирует данный тест как показывающий реальные возможности антивирусов. И тогда по крайней мере нужно при показе результатов ставить интервал погрешности +/-0,5%, даже если при проверке выясняется, что результаты отличаются не так сильно при удалении битых сэмплов.

Все неприятности идут от "автодятлов". :lol:

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


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

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

Считаю любые тесты злом, а обсуждение их пустым занятием."

А как без тестов можно сравнить АВ? Проводить голосование среди пользователей?

Что бы не тестировать "вчерашний день" нужно разнести дату тестирования и последнего обновления АВ скажем на месяц. Если по результатам 3-х таких тестов АВ будет брать >80%, то с таким АВ можно спать спокойно, а "червь долго будет искать у вас дыру" :rolleyes:

А битых сэмплов должно быть не 0,4%, а гораздо больше (~ 10-20%) иначе по ложным срабатываниям все АВ будут идеальными

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


Ссылка на сообщение
Поделиться на другие сайты
dot_sent
А битых сэмплов должно быть не 0,4%, а гораздо больше (~ 10-20%) иначе по ложным срабатываниям все АВ будут идеальными

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Считаю любые тесты злом, а обсуждение их пустым занятием.

Ну вот, можете же высказывать своё мнение. А то всё дуетесь и дуетесь :)

Все неприятности идут от "автодятлов". laugh.gif

Вполне возможно. Тоже серьёзная проблема, набирающая обороты. Особенно после таких фактов, как удаление возможности не отсылать сэмплы при проверке на virustotal.com .

А как без тестов можно сравнить АВ?

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

Лучше совсем без тестов, чем тесты, результаты которых никак не коррелируются и ничего не показывают, и точность которых далека от идеала. Потянешь за одну переменную - результаты рассыпаются, потянешь за другую - вообще бессмыслица получается :)

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


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

"Ставить каждый из продуктов на триальный срок и выработать собственное мнение."

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Тесты хотя бы сужают число АВ которые можно поставить(зачем ставить откровенных аутсайдеров).

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

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


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

о я вижу вы успешно продвигаете в жизнь мысль Шарова все тесты дерьмо поэтому мы в них участвовать не будем

тухлая затея, на тесты все равно будут смотреть и пиарить их будут

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
о я вижу вы успешно продвигаете в жизнь мысль Шарова все тесты дерьмо поэтому мы в них участвовать не будем

тухлая затея, на тесты все равно будут смотреть и пиарить их будут

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

А по заявлению Бориса Шарова могу лишь сказать, что это одно из печальных следствий альянса с AV-Comparatives.org, о возможности которых я предупреждал. Были предчувствия, хотя я об этом решении узнал только сегодня на АМ. Хорошо, если на этом всё закончится. Больше я тут комментировать ничего не могу.

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


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

А по заявлению Бориса Шарова могу лишь сказать, что это одно из печальных следствий альянса с AV-Comparatives.org, о возможности которых я предупреждал. Были предчувствия, хотя я об этом решении узнал только сегодня на АМ. Хорошо, если на этом всё закончится. Больше я тут комментировать ничего не могу.

а что Валерий закончится?

в отличии от Маркса, в рабочей группе которого ваша компания участвует, Клементи дает и коллекции вендорам для разбора и проводит работу над ошибками (смотри выше) и в тестах точно указывает какие продукты каких версий и с какими базами он тестил. Я как человек со стороны вижу, что он по крайней мере работает над собой.

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

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

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

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


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

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

Значит тесты всё же не дерьмо :rolleyes:

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
в отличии от Маркса, в рабочей группе которого ваша компания участвует, Клементи дает и коллекции вендорам для разбора и проводит работу над ошибками (смотри выше) и в тестах точно указывает какие продукты каких версий и с какими базами он тестил. Я как человек со стороны вижу, что он по крайней мере работает над собой.

Человек работает над собой (причём заметно только в последнее время), но результаты тестов до окончания работы над собой публикуют везде, где можно. Без ремарок о том, что результаты могут не соответствовать действительности, могут содержать погрешности, могут быть основаны на ошибочной методологии и прочая, и прочая.

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

По мне, так оба хороши.

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

Не знаю я таких юридических тонкостей. Если ничего не препятствует, то почему бы не потестировать?

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

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

Значит тесты всё же не дерьмо rolleyes.gif

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

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
Я ни разу не дискредетировал тесты АМ. Да, указывал на недостатки (но где их нет?). И наоборот даю всегда ссылки на тестирования АМ, чтобы их можно было сравнить с "Марксами и Энгельсами".

здесь под словом вы я понимал Доктор Веб как компанию и в гипотетическом смысле

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
здесь под словом вы я понимал Доктор Веб как компанию и в гипотетическом смысле

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

Ок, ок. Если так, то так.

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


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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Валерий, вы бы вместо критики, предложили бы свою объективную модель тестирования.

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

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


Ссылка на сообщение
Поделиться на другие сайты
alexgr
Ваш друган Клементи ответил на вопросы читателей на тему того, что у него битых самплов в коллекции много

http://www.av-comparatives.org/seiten/ergebnisse/QA2007.pdf

говорит проверил коллекцию, которую использовал в августе 2007 года, битых самплов гооврит всего 0,4%

изменения говорит минимальные

Иван, вот для полного счастья он опубликовал статистику по так называемым "фолсам", которые на проверку оказались вредоносами... СНГошные вендоры это доказывали не раз

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


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

  • Сообщения

    • 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 может сказаться ?
×