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

Тест антивирусов по эффективности защиты от новейших вредоносных программ I

Recommended Posts

UIT

Valery Ledovskoy

Извините если что пропустил. На Ваш взгляд, проведенный тест (с текущей методологией и спорными элементами:) показывает /примерно/ действительную эффективность именно среди тестируемых продуктов. Или нет.

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


Ссылка на сообщение
Поделиться на другие сайты
dr_dizel
Так не научились ещё определять время жизни сэмпла.

А нам не нужно время жизни. Нужно разделение на то - чем детектилось или не детектилось вообще т.е. вердикт всех АВ на сэмпл/ссылку: дата + имя.

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


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

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

Например, вот как определяются такие угрозы в Википедии:

http://en.wikipedia.org/wiki/Zero_day_virus

A Zero day virus is a previously-unknown computer virus or other malware for which specific antivirus software signatures are not yet available.[1]

Traditionally, antivirus software relies upon signatures to identify malware. This can be very effective, but cannot defend against malware unless samples have already been obtained, signatures generated and updates distributed to users. Because of this, signature-based approaches are not effective against zero-day viruses.

Most modern antivirus software still use signatures, but also carries out other types of analysis.[2]

Это одно из классических определений zero-day-угроз.

Речь идёт о том, что под zero-day-угрозами понимается вирус, под которого у антивируса ещё нет сигнатуры. Т.е. формально (при современных реалиях) это образец, который ещё не попадал к вендору на обработку, не проходил через вирусную лабораторию.

Но здесь есть засада. Ни один антивирус сегодня, который может таковым называться, не использует только сигнатуры в их классическом понимании. Именно для противодействия zero-day-угрозам стали придумываться различные проактивные технологии (среди которых и HIPS-технологии, и эвристические технологии, и другие технологии).

И авторы последнего тестирования столкнулись с тем, что практически невозможно найти образцы, которые не детектируются ни одним антивирусом. Из этого был сделан вывод, что можно в качестве zero-day-угроз использовать вирусы, которые детектируются-таки некоторыми антивирусами на Virustotal. По какому праву, кстати? Тем более, что для некоторых антивирусов (например, КАВ) детект на Virustotal ни о чём может не говорить, и я это показывал.

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

Наиболее верным направлением считаю определять время начала распространения нового сэмпла, т.к. практически все вирусописатели сегодня стараются перед началом распространения сэмпла минимизировать детект различными антивирусами. В том числе ведётся работа и по противодействию HIPS-технологиям (см. описание TDL3 того же). Но никому не приходит в голову убирать из теста сэмплы, которые ловят HIPS-технологии. Иначе зачем тогда тестирование вообще?

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

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

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

По просьбе одного из участников уточняю. Прошу упоминание здесь Virustotal не воспринимать как главное доказательство неверности методики проведённого теста. Это сообщение - для более правильного понимания того, что было сделано, и к чему можно стремиться.

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


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

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


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

Согласен, так будет более прозрачно все.

Речь идёт о том, что под zero-day-угрозами понимается вирус, под которого у антивируса ещё нет сигнатуры. Т.е. формально (при современных реалиях) это образец, который ещё не попадал к вендору на обработку, не проходил через вирусную лабораторию.

Ну так значит название правильное? :) Мы как раз брали те самплы, которые сигнатурами не детектились, если вердикты и были у того же вирустотала, то на пакеры/крипторы, в крайнем случае срабатывали дженерики. Это все описано тесте в методологии.

Потом если 10 вендоров вирус не знаю, а один какой-то из далекой далекой страны его спалил (может он все подряд палит?). Это Zero-day или нет? Я считаю, что да. Мы просто в методологии дали свое количественное определение этого понятия, как сами считаем правильным.

Сигнатурного детекта не было - не было. Самплы неизвестные - да. Zero-day-угроза - да.

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

Оно было не последнее, будет еще много :)

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Ну так значит название правильное? smile.gif Мы как раз брали те самплы, которые сигнатурами не детектились,

Нет, не правильное.

Сигнатурного детекта не было - не было.

Эвристика - это не сигнатуры. С детектом эвристики сэмплы не брались. Это не соответствует классическому определению zero-day-угроз. Очень часто на сэмплы, которые появились только что, срабатывают эвристики у многих антивирусов, до 50%. Как видим, в классическом определении zero-day-угроз речь идёт только лишь о чётких сигнатурах. А тестеры не могут определить часто, эвристик сработал у антивируса или сигнатура. Потому что вендоры не делятся такой информацией, а сами определить этого не могут.

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

Т.е. возвращаемся к изначальной логике.

dr_dizel, если Вам что-то непонятно, задавайте вопросы или не пишите ничего. По правилам форума нельзя размещать сообщения, не несущие смысловой нагрузки, п. 11.12.

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


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

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

Это похоже на иконку Ambox_content.png, которая выражает озабоченность администрации в профессионализме автора статьи на википедии, ссылку на которую вы дали. Там даже разжевано (т.к. смайлик достаточно абстрактен в отличие от моего): "This article is in need of attention from an expert on the subject".

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

P.S. Довольно странно, что всё это нужно объяснять взрослому образованному человеку на не последнем в инете портале по ИБ.

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


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

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

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

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

Не без этого, но авторы теста выбрали именно это определение zero-day-угроз для проведения теста. Возможно, администрация Википедии тоже понимает, что такое (классическое) определение термина несколько устарело.

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

Странно, что Вы не видите, что здесь дано определение Zero day attack:

A zero-day (or zero-hour) attack or threat is a computer threat that tries to exploit computer application vulnerabilities that are unknown to others, undisclosed to the software vendor, or for which no security fix is available. Zero-day exploits (actual code that can use a security hole to carry out an attack) are used or shared by attackers before the software vendor knows about the vulnerability.

И определяется здесь понятие zero-day-эксплойта уязвимости в каком-либо ПО. Про уязвимости, которые производители ПО ещё не закрыли к моменту их использования злоумышленниками. Это определение ничего не говорит нам о том, какие сэмплы нужно отбирать для тестирования антивирусов.

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


Ссылка на сообщение
Поделиться на другие сайты
dr_dizel
И определяется здесь понятие zero-day-эксплойта уязвимости в каком-либо ПО. Про уязвимости, которые производители ПО ещё не закрыли к моменту их использования злоумышленниками. Это определение ничего не говорит нам о том, какие сэмплы нужно отбирать для тестирования антивирусов.

А как, например, собирают шелкоды на загрузку и установку малдрайвера? Просветите-ка.

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


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

[offtop]

dr_dizel, если Вам что-то непонятно, задавайте вопросы или не пишите ничего. По правилам форума нельзя размещать сообщения, не несущие смысловой нагрузки, п. 11.12.

Валерий, это facepalm.

Пост написан исключительно для расширения Вашего кругозора.

[/offtop]

  • Upvote 5

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


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

Ответьте тогда, что в современном понимании является сигнатурами? :)

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

Многие сразу же стали говорить, что это те же самые сигнатуры, только вид сбоку. Можно называть их проактивными, нечеткими, да как угодно, смысл не меняется. Для иллюстрации вспоминаем эпидемию Warezov, который обновлялся так таким образом, что вендорам приходилось клепать на него сигнатуры, дженерики и новые записи эвристики постоянно. Именно тогда наглядно захлебнулась хваленая эвристика Nod32 (кому интересно, может найти на нашем форуме темы на этот счет). К чему я это? Да к тому, что все это защита от небольших модификаций известных угроз.

Очень часто на сэмплы, которые появились только что, срабатывают эвристики у многих антивирусов, до 50%.

И вы предлагаете относить их к zero-day? Это будет смешно.

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

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

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


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

Это уж точно п.11.12

За бессвязность речи я бы выдал по-полной программе, но я не модератор...

P.S. 2Umnik: Вот это уже "..... стыд", а не фейспалм :)

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Да к тому, что все это защита от небольших модификаций известных угроз.

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

Но да, ни один из существующих ныне тестов не подтвердит и не опровергнет это.

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

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

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


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

Тоже немного позволю себе поофтопить.

Валерий, это facepalm.

Пост написан исключительно для расширения Вашего кругозора.

«Услышав это, Роланд поморщился, покачал головой и прикрыл глаза изуродованной правой рукой.»

— Стивен Кинг — Тёмная Башня

Пожалуй, любимая моя книжка. Всем советую осилить :)

У меня кругозор немного шире точки, которую некоторые называют своей точкой зрения :)

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


Ссылка на сообщение
Поделиться на другие сайты
dr_dizel
Это уж точно п.11.12

О, целых 2 эксперта в теме! :lol:

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

Мы тут зеродеев обыскались уже. Может подбросите парочку md5? :rolleyes:

P.S. А все предыдущие N страниц флуда вас значит устраивали? Или вы наш Лев Толстой?

Когда революционеры сотнями убивали царских губернаторов, графов и князей, тогда граф Толстой молчал, как рыба.

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

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


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

dr_dizel, сначала разберитесь в определении термина Zero day attack, который действительно адекватный, но не по теме.

Потом флеймите дальше.

P.S. А все предыдущие N страниц флуда вас значит устраивали? Или вы наш Лев Толстой?

Нет, не устраивали. Часть была выделена в отдельную тему. А из Вашего флуда даже не знаю... Разве что в юмор.

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


Ссылка на сообщение
Поделиться на другие сайты
dr_dizel
сначала разберитесь в определении термина Zero day attack, который действительно адекватный, но не по теме.

Потом флеймите дальше.

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

Нет, не устраивали. Часть была выделена в отдельную тему.

И какой результат из всего этого? Можете "подбить баланс"? Уже пора бы.

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


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

Ах, для красоты? Ну если Вы так решили, тогда конечно можно считать, что Zero day attack - это то же самое, что и Zero day samples (viruses).

Тогда вопросов нет.

И какой результат из всего этого? Можете "подбить баланс"? Уже пора бы.

Баланс подбивают модераторы форума и бухгалтеры.

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


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

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

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


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

Если немного вспомнить историю споров на Антималваре, то припоминаются следующие очень интересные моменты :

- Более двух лет тому назад сотрудники DrWeb оспаривали необходимость внедрения в свой продукт более вменяемой самозащиты, все выпады о том, что базы антивируса можно грохнуть и он запустится без них парировались утверждением, что мол автоапдейтер тут же скачает недостающие компоненты. Чем закончился спор всем известно - самозащиту в пятёрке доработали. Следом была точно такая же дискуссия о необходимости сетевого экрана. Результат все тоже знают, пришлось вебовцам браться за разработку собственного СЭ. Сейчас - один в один дискуссия о HIPS. Думаю, что закончится как и в предыдущих случаях, через годик вебовцы объявят о начале тестирования встроенного в их антивирус HIPSa. Валерий, сколько бы вы не упирались и не пытались расписывать здесь уникальность пути, по которому идёт ваша компания, но вам всё равно придётся делать в своём антивирусе то, что другие компании в своих продуктах уже реализовали :P

  • Upvote 10

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


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

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

опять же, как относиться к эвристике.

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

Или продуктов со 2рым типом(по моей типологии (: ) не существует?

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


Ссылка на сообщение
Поделиться на другие сайты
sww
я так понимаю, у некоторых вендеров эвристика работает на базе сигнатур, а у некоторых автономно?

Сначала надо определиться с понятием "эвристика". Она очень даже разная бывает с точки зрения технологий, например:

1) Статический трейсер с правилами

2) Эмулятор с правилами

2.1) п.2 + п.1

3) ...

3.1) ...

и так далее...

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


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

Вот ещё что. Не хватало мне ещё ругаться из-за терминологии. Хотя бы понять, что есть что.

А dr_dizel для начала бы научиться вести конструктивную дискуссию. Вечно куда-нибудь заносит далеко.

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

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

Так же, как отсутствие нормального антируткита в продуктах Eset объяснялась тем, что если этот антивирус стоит на компьютере, то вирусы не пролезут. Настолько хорошая у него эвристика и проактивка. Да, эвристика неплохая. И понятно, почему так защищаются.

Вот все говорят до сих пор, что продукты ЛК тормозят - отвечают, что 200МБ сканируют за 3 секунды. Тоже всё понятно. Всё ж на поверхности.

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

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

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

Думаю, что закончится как и в предыдущих случаях, через годик вебовцы объявят о начале тестирования встроенного в их антивирус HIPSa.

Ничего подобного. Сейчас никто не говорит, что HIPS не будет. Но это не снимает никаких претензий с тестов, которые делают упор на значимости именно HIPS-технологий, хотя в название это не вынесено. Эта точка зрения не изменится никогда.

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

Что Вы здесь имеете в виду? Самозащиту, которая сделана совершенно иначе, чем у конкурентов? Антируткит, который работает иначе? Антиспам может быть похож на тот, что реализован в продуктах ЛК?

На самом деле у каждой антивирусной компании свой уникальный путь развития. Чтобы это увидеть, достаточно открыть глаза. Желательно в дневное время суток :)

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

А у некоторых, и первое, и второе, и третье, и с компотом :)

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


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

1) Статический трейсер с правилами

2) Эмулятор с правилами

2.1) п.2 + п.1

3) ...

3.1) ...

и так далее...

А у некоторых, и первое, и второе, и третье, и с компотом :)

окей ... тогда с чего вдруг это называется у всех эвристикой? :)

если исходить из общего понимания термина "эвристика", то туда можно и ХИПС засунуть :).

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
тогда с чего вдруг это называется у всех эвристикой? smile.gif

У кого у всех? Могу за нас сказать. .based - это расширенные вирусные записи. Приблизительно уровень сигнатур. Origins Trasing (.origin) - это нечто между сигнатурами и классическим эвристиком. FLY-CODE мы сейчас считаем частью эвристика, хотя здесь используются другие технологии относительно классического эвристика (который тоже никуда не делся).

если исходить из общего понимания термина "эвристика", то туда можно и ХИПС засунуть smile.gif.

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

Вот поэтому за попытку оценить возможности продуктов по противодействию новым угрозам - спасибо. А за результат... сложно поддаётся интерпретации. И выносить в заголовок некие "новые угрозы" непонятного типа по непонятно каким правилам выбранные... Не согласен лично я с тем, что так было сделано. Но, возможно, в будущем высказанные замечания будут учтены. Первый блин, как говорится, и должен быть com'ом, а exe'шники будут дальше. Тот тест, что был проведён, можно вполне взять за точку отсчёта и начинать улучшения. Но я бы не стал этот инновационный (т.е. необкатанный по сути) тест, его результаты вообще показывать широкой публике. Не готовы они для этого. Для аналитического портала - да, пойдёт, можно пообсуждать.

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


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

  • Сообщения

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