Интервью Игоря Данилова для журнала Cnews - Страница 4 - Интервью с экспертами - Форумы Anti-Malware.ru Перейти к содержанию
dolph2005

Интервью Игоря Данилова для журнала Cnews

Recommended Posts

Valery Ledovskoy
Ответ В. Ледовского (сотрудника "Доктор Веб") -- да\нет [Y\N]?

Ответ В. Ледовского (личное мнение) -- да\нет [Y\N]?

На оба вопроса ответ "да".

Принимаю во внимание, что результаты и методику этих тестов принимали положительно ответственные за это направление сотрудники компании (на тот момент).

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

И вот какой парадокс. Отсутствие в этих тестах Dr.Web НЕ сделало бы его НЕ лидером в лечении активных заражений. Есть возражения на этот тезис?

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

АМ как бы не делает продукты лидерами по тому или иному направлению (лишь пытается констатировать тот или иной факт), это делают совсем другие люди и тратят на это больше своих сил, чем тратят сил тестировщики на тестирование. АМ не является сущностью, дарующей лидерство, если хотите.

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

Но, опять же, мир не идеален. Я это прекрасно понимаю.

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

  • Upvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
посетитель
Ровно это мы всегда предлагали лично Борису Шарову. Не согласны с чем-то - давай сделаем лучше! Давайте готовить тесты заранее, можно ведь влиять на методологию. Мы же не догматики, упершиеся лбом в методогию вековой давности. Мы всегда готовы к диалогу, конечно, если он ведется уважительно на уровне бизнеса :)

ное это оторванный от жизни идиализм и самообман с целью объяснить свою неудачи.

М-да. Для кого это пишется? Вы не догматики, вы сотрдуники конкурирующей антивирусной компании. То, что вы говорите просто не может восприниматься, как "уважительно на уровне бизнеса", потому что это бизнес другой компании. И тот обман который вы затеяли с цирком про независимый портал дискредитировал вас полностью и именно этот обман, а не упертость Данилова и Шарова делают невозможным никакое дальнейшее сотрудничество с вами.

Повторю вопрос, для кого это пишется!? Все же знают это... Все, кто еще сюда приходит.

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


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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
K_Mikhail
На оба вопроса ответ "да".

Ну вот, "да" по всем пунктам. А говоришь "Я не знаю, чем подтверждена эта строчка. Возможно, независимыми экспертами в личных разговорах smile.gif Т.е. вопрос не к тому человеку."

Принимаю во внимание, что результаты и методику этих тестов принимали положительно ответственные за это направление сотрудники компании (на тот момент).

А как ты хотел без этого?

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

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

По поводу неидеальности -- спасибо, Капитан Очевидность! :) Однако речь идёт всё-таки не об (не-)идеальности, а о последовательности.

И вот какой парадокс. Отсутствие в этих тестах Dr.Web НЕ сделало бы его НЕ лидером в лечении активных заражений. Есть возражения на этот тезис?

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

Есть возражения. Поясню. Твой тезис ("отсутствие в этих тестах Dr.Web НЕ сделало бы его НЕ лидером в лечении активных заражений.") базируется на результатах двух тестов (для 4.44 (beta) и для 5.0). Представь себе ситуацию, если этих двух тестов не было б вообще. Вот просто не было б. Тут появляется Валера Ледовской от "Доктор Веб" и говорит: "Dr.Web -- лидер в лечении активного заражения". На каком базисе ты бы подтверждал это утверждение (лидер в лечении)? На основании чего? Сторонних тестов, внутренних тестов?

По ходу, загляни вот сюда, пожалуйста, bug_id=0021095. Актуально было для 4.44. Поймёшь о чём я.

АМ как бы не делает продукты лидерами по тому или иному направлению (лишь пытается констатировать тот или иной факт), это делают совсем другие люди и тратят на это больше своих сил, чем тратят сил тестировщики на тестирование. АМ не является сущностью, дарующей лидерство, если хотите.

И, тем не менее, как раз результат теста на АМ даёт подтверждение вышеупомянутой строке на сайте. С чем ты, несмотря на ("Я не знаю, чем подтверждена эта строчка..."), но таки согласился.

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

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

P.S. Опять же, повторюсь, всё это тлен и суета. :)

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Твой тезис ("отсутствие в этих тестах Dr.Web НЕ сделало бы его НЕ лидером в лечении активных заражений.") базируется на результатах двух тестов (для 4.44 (beta) и для 5.0). Представь себе ситуацию, если этих двух тестов не было б вообще. Вот просто не было б. Тут появляется Валера Ледовской от "Доктор Веб" и говорит: "Dr.Web -- лидер в лечении активного заражения". На каком базисе ты бы подтверждал это утверждение (лидер в лечении)? На основании чего? Сторонних тестов, внутренних тестов?

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

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

  • Upvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
K_Mikhail
Не хочешь ли ты этим сказать, что без АМ невозможно увидеть лидерство того или иного продукта?

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

На самом деле вредосносных программ, участвующих в таких тестированиях, не так много. Они ключевые. И они известны всем уважающим себя антивирусным лабораториям. Насколько я знаю, Dr.Web перед каждым выпуском сканера тестируется на предмет корректности лечения от ключевых в смысле активного заражения вредоносных программ. Чтобы доказать, что Dr.Web лидирует в лечении активного заражения необходимо лишь попробовать вылечить систему от этих ключевых (актуальных на сегодняшний момент) вирусов (на самом деле их не так много) с помощью нескольких других наиболее популярных продуктов (можно даже не всех нескольких десятков существующих).

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

Я тебе недаром сказал -- посмотри тот баг-репорт (bug_id=0021095, там речь шла об Trojan.Msliksur'е ((alilserv.sys, alil.dll), вполне себе ключевое семейство). По ходу, есть предложение включить этот тип в будущие тестирования. Я тебе просто показал, как легко можно найти семпл(-ы), на которых существуют проблемы у того или иного вендора, и из-за чего будут возникать прецеденты для спекуляций. Внешнее тестирование тем и хорошо, что является не привязанным к тому или иному вендору. Во всяком разе, претендует на непривязанность.

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

См. выше по поводу спекуляций.

Отредактировал Сергей Ильин

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


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

Umnik, Сергей Ильин, в чём была суть правок в посте K_Mikhail? Просто техническая накладка?

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

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

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

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

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

А если то, о чём я написал не произойдёт, то получается вот что.

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

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

Предчувствую вопрос: "Так ты уже не думаешь, что тесты АМ на активное заражение подтверждают лидерство Dr.Web в лечении активного заражения?" Этот вопрос будет неправильным, т.к. то, что я думаю и знаю, никак не увеличивает ценность результатов, полученных АМ. А ценность у них низка из-за их уникальности (см. выше).

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


Ссылка на сообщение
Поделиться на другие сайты
K_Mikhail
Umnik, Сергей Ильин, в чём была суть правок в посте K_Mikhail? Просто техническая накладка?

В том, что я напортачил с квотированием в своём предыдущем сообщении.

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

Я всего лишь ответил на твой вопрос "Не хочешь ли ты этим сказать, что без АМ невозможно увидеть лидерство того или иного продукта?"

Кроме того, если ты ещё раз, но на этот раз внимательно прочтёшь первую часть моего предыдущего поста ("Пока АМ является единственным ресурсом..."), то увидишь\поймёшь, что там речь не шла о том, что невозможно что-то сделать или создать, и, тем более, там не приводились доказательства этой невозможности. Я моделировал ту ситуацию, когда может произойти, если основываться на выдвигаемых тобой тезисах. Повторюсь, что пока АМ -- единственный портал, который проводил тесты на лечение активного заражения, он и является единственным подтверждающим лидерство в данном случае Dr.Web в этом направлении (то бишь, лечения). Т.е., фактически, монополистом. Появится ещё пара-тройка порталов\организаций, проводящих тесты на лечение активного заражения со своими методиками (улучшенными или просто принципиально другими) и набором семплов, -- будет с чем сравнивать. Но! Самый важный момент, независимо от того одна, две, три... пять и большее организаций проводят тест -- любая методология должна обеспечивать воспроизводимость результатов в пределах допустимой погрешности измерений. Если этого нет, то цена соответствующая.

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

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

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

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

А если то, о чём я написал не произойдёт, то получается вот что.

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

Ну вот, допустим, воспроизведёшь ты с помощью студентов последний тест на лечение, и у тебя окажется KAV на первом месте вместо Dr.Web'а. Будешь оспаривать результаты, полученные Василием? Хотя это может только сказать о том, что методика не обеспечивает воспроизводимости результатов, и ты должен будешь об этом заявить, что грош цена такой методологии.

И ещё одно сравнение. Вот ты говоришь, нужно верить результатам теста АМ по активному заражению, потому что никто больше не проводит такое тестирование.

Я не говорил о вере или о том, что нужно верить. Я говорил только о том, что пока АМ -- единственный портал, который проводил тесты на лечение активного заражения, он и является единственным подтверждающим лидерство в данном случае Dr.Web в этом направлении (то бишь, лечения). И подтверждающим висящий на сайте "Доктора" тезис: "Улучшено! Антивирус – лидер в лечении активных заражений." С чем ты и согласился, ответив "да" как сотрудник "Доктор Веб", и как просто человек. Перечитай выше. :)

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

Опять же, вопрос упирается в обеспечение методологией воспроизводимости результатов и в выборке семплов. Если методология "по Клементи" её не обеспечит -- грош ей цена. Если да (на выбранных Клементи семплах!), то вопрос переходит в техническую стадию -- почему тот или иной антивирус не справился с лечением той или иной вредоносной программы. Смотри мой пост по поводу Trojan.Msliksur и 4.44. АМ не взял его тогда в тестирование, а Клементи бы взял (допустим). И получил бы 4.44, допустим, не золото, а серебро. Т.е. при воспроизводимости обеих методик был бы провал на одном семпле (семействе), который (-ое) повлиял(-о) на итоговую расстановку мест.

Предчувствую вопрос: "Так ты уже не думаешь, что тесты АМ на активное заражение подтверждают лидерство Dr.Web в лечении активного заражения?" Этот вопрос будет неправильным, т.к. то, что я думаю и знаю, никак не увеличивает ценность результатов, полученных АМ. А ценность у них низка из-за их уникальности (см. выше).

Вопрос ненужный, ибо твои два "да" уже прозвучали:

=====

Valery Ledovskoy: Прошу не мешать моё мнение и понимание ситуации с тем, что кто-то где-то пишет.

Я не знаю, чем подтверждена эта строчка. Возможно, независимыми экспертами в личных разговорах smile.gif Т.е. вопрос не к тому человеку.

K_Mikhail: Нет проблем -- поставлю вопрос таким образом -- считаешь ли ты, что результаты тестов на лечение активного заражения для Dr.Web 4.44 (beta) и для Dr.Web 5.0 подтверждают строчку на сайте "Улучшено! Антивирус – лидер в лечении активных заражений".

Ответ В. Ледовского (сотрудника "Доктор Веб") -- да\нет [Y\N]?

Ответ В. Ледовского (личное мнение) -- да\нет [Y\N]?

Valery Ledovskoy: На оба вопроса ответ "да".

===

UPD: На том game over.

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


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

K_Mikhail, всего лишь разные взгляды на одно и то же :) Твою точку зрения я тоже понимаю.

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

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


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

"любая методология должна обеспечивать воспроизводимость результатов".

Т.е. если антивирусник "А" занял первое место, то при следующем тестировании, он просто обязан взять "золото" :-)

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


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

Т.е. если антивирусник "А" занял первое место, то при следующем тестировании, он просто обязан взять "золото" :-)

Не утрируйте, пожалуйста. Не при следующем, а при аналогичном, проводимом по такой же методологии и с такими же сэмплами.

  • Upvote 5

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


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

Я бы сказал - в тех же условиях -))

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


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

А какай смысл через год(месяц) по старым сэмплам гонять?

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


Ссылка на сообщение
Поделиться на другие сайты
Deja_Vu
А какай смысл через год(месяц) по старым сэмплам гонять?
Я бы сказал - в тех же условиях -))

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


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

Про корпоративный таки да, но давайте не перегибать палку про "домашний сегмент". Исправьте пожалуйста свой пост и добавьте "в Америке", так будет точнее и правильней. ;)

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

Видимо, г-н Данилов считает, что самые тайные тайны есть только у России и США. Остальным "папуасам" скрывать нечего :)

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

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

  • Upvote 5

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


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

  • Сообщения

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