Больной бизнес - статья Ильи Рабиновича - Аналитика - Форумы Anti-Malware.ru Перейти к содержанию
Иван

Больной бизнес - статья Ильи Рабиновича

Recommended Posts

Иван

Больной бизнес

Источник: Компьютерра (Москва)

Автор: Илья Рабинович

Дата: 9 октября 2007

АНТИВИРУСЫ ИГРАЮТ ЧЕРНЫМИ. И ПРОИГРЫВАЮТ?

Спроектированные еще десять-пятнадцать лет назад антивирусы отважно защищают пользователей от компьютерных вирусов. Только вот пользователям угрожают вовсе не вирусы.

***

ВЧЕРА

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

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

Но и стелсы, и полиморфы - это вчерашний день. В Сеть пришли простые люди. Простые люди с простыми деньгами. Люди, которые совершали покупки в интернет-магазинах и управляли банковскими счетами через глобальную сеть. А вслед за ними потянулись искатели быстрой и легкой наживы, благодаря которым понятие зловредного ПО (сокращенно - зловреды, на некоторых интернет-форумах по безопасности такие программы еще называют "зверьками") было существенно расширено. Сегодня под malware (от английского malicious software) понимают adware (ПО, показывающее пользователям рекламу), spyware (ПО, которое шпионит за пользователями),

dialers (этот вымирающий класс программ пользуется обычным телефонным модемом для звонков на платные телефонные номера), rootkits (этот класс программ используется для сокрытия присутствия в системе зловредного программного обеспечения, вспоминаем стелс-вирусы!), backdoors (это программы для удаленного управления компьютером), trojans (этот класс программ выдает себя не за то, чем на самом деле является), ransomeware (шифруют данные пользователей и вымогают деньги за дешифровку), worms (черви, делятся на почтовые и сетевые по методу распространения). Все эти программы часто путают с вирусами, хотя к вирусам они не имеют никакого отношения, так как не могут самостоятельно инфицировать файлы.

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

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

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

***

СЕГОДНЯ

Сегодняшняя индустрия защиты от зловредного ПО представляет собой экстенсивное развитие технологий конца 80-х начала 90-х годов. Сигнатурные сканеры, эвристика, резидентные антивирусные мониторы. Конечно, общий уровень организации работ и качество реализации пользовательского интерфейса поднялись на небывалую высоту, но под капотом у них все по-старому. И если еще в начале 2000 года эти методы работали относительно эффективно, то уже в 2007 году многим становится очевидно, что старые технологии борьбы больше не справляются с потоком зловредного ПО, захлестнувшим Интернет. Ибо бизнес диктует простое правило - деньги капают лишь до тех пор, пока твой зловред не начал детектироваться антивирусами. А значит, надо всеми силами предотвратить это!

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

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

Счет в этой войне идет буквально на дни, если не на часы. Антивирус начал детектировать зловредный модуль на сайте, распространяющем заразу? Производитель зловреда в течение нескольких часов модифицирует его так, чтобы он больше не обнаруживался, и выкладывает обратно на сайт! Теперь вы понимаете, надеюсь, что стандартное тестирование антивирусных движков на качество обнаружения уже известных образцов зловредного ПО со стандартным 90-99% результатом с реальной ситуацией, с которой сталкивается пользователь при заражении, имеет мало общего?

Ахиллесова пята современных антивирусных технологий - их реактивность. То есть, сначала зараза, а лишь потом - средства ее обнаружения и зачистки. Все то время, пока образец не попал в антивирусную лабораторию, идет инфицирование. Единственная надежда - на эвристик, но уровень его детектирования не дотягивает даже до 70%. Кроме того, ложные срабатывания становятся головной болью для производителей легитимного ПО (знаю по собственному опыту!) и обычных пользователей.

Так какие же технологии будут занимать умы пользователей в ближайшем будущем? Безусловно, это технологии, основанные на анализе поведения (так называемые HIPS) и белых списках. Рассмотрим каждую из них.

Исторически первая технология анализа поведения была основана на модели детекторов аномалий (на ней же базируются файрволлы) и имеет общее название classic HIPS. To есть, если приложение совершает потенциально опасное действие (запись в автозагрузку, например), защита выдает предупреждение об оном и просит пользователя принять решение (например, разрешить, запретить или внести в локальную базу правил как разрешенное). Для уменьшения количества подобных окон с вопросами обычно используется режим обучения (как и у файрволлов) либо онлайновая база знаний (community HIPS). Все подобные схемы имеют одну неразрешимую проблему: они перекладывают принятие решения на самого пользователя со всеми вытекающими. Такие защиты сложны в каждодневном использовании простым юзером и не получили сколь-нибудь массового распространения. Их ниша - суперпрофессиональные пользователи, считающие контроль синонимом слова "защита" (и наоборот). Примеры - почивший в бозе ProcessGuard, ProSecurity, SSM.

Следующее поколение защит основывается на модели "поведенческих сигнатур", имеет общее название blacklisting HIPS или expert HIPS и является невольным продолжением традиций антивирусных решений. То есть защита анализирует последовательность поведенческих шагов программ с шаблонами (сигнатурами) поведения известных зловредов и выносит вердикт. Защита практически не мешает обычной повседневной работе, но имеет типичные недостатки всех антивирусных решений - ложные срабатывания на легитимном ПО и несрабатывания на зловредном. Кроме того, подобные системы все же перекладывают принятие окончательного решения на самого пользователя (не все из них, но ложные срабатывания тогда хуже контролируются) и предъявляют некоторые требования к его технической подготовленности. Типичные примеры - Kaspersky PDM, Norton Antibot, PC Tools Threatfire.

***

ЗАВТРА

Модель "белых списков" в мире безопасности не нова, например, компания Microsoft внедряет цифровые подписи в мир программного обеспечения довольно давно. Кроме того, есть несколько реализаций данной модели для систем HIPS, имеющих общее название whitelisting HIPS и основанных на контроле запускаемых приложений. То есть при запуске нового приложения, которого нет в белом списке разрешенных, выдается окно с предупреждением (обычно доступно несколько действий - "разрешить", "запретить", "добавить в список разрешенных"), как с возможностью уменьшения выдачи оных за счет проверки их цифровых подписей (например, Comodo Anti-virus, Comodo Firewall v3), так и без (например, Anti-Executable).

Несколько компаний собирают цифровые отпечатки заведомо легитимных файлов в единую базу данных (например, Bit9). Недостатки подобных систем в том, что не все файлы можно подписать (скажем, cmd-скрипты, doc-файлы), а попытка создать базу всех легитимных исполняемых файлов в мире заведомо обречена на провал из-за гигантских размеров базы и необходимости обрабатывать громадный, постоянно растущий объем данных ежедневно (и, как следствие, обречена на провал попытка защитить пользователя от запуска вредоносных программ на сто процентов). Кроме того, скорость реакции whitelisting HIPS... такая же, как у антивирусов (но с другим знаком, конечно, - система не успевает за выходом "хорошего" ПО). Единственно правильное решение для применения идеологии "белого списка", которое я видел, - добавление данного элемента к уже существующим решениям в области защиты (например, упрощение анализа логов зараженных компьютеров с помощью программы AVZ и базы заведомо чистых элементов автозагрузки и системных библиотек).

Если все описанные выше поведенческие защиты были основаны на переработанных, но уже известных и апробированных моделях из мира PC security, то следующий класс продуктов безопасности пришел, скорее, из мира разработки ПО. Речь идет о системах, общее название которых - sandbox HIPS (Host Intrusion Prevention System), "песочница". В основе их построения - модель разделения всех приложений в системе на "доверенные" и "недоверенные" и предположение о том, что зловредное ПО проникает лишь через процессы, работающие с небезопасными сегментами Интернета и потенциально опасными файлами оттуда:

то есть через браузеры, почтовые, IM-, IRC-, Р2Р- и мультимедиа-клиенты. Доверенные приложения (например, системные процессы) работают как обычно, недоверенные - ограничены в правах на потенциально опасные операции (например, установка драйвера). Никаких всплывающих окон с вопросами, перекладывающими принятие решения на пользователя, здесь нет, потенциально опасные действия недоверенных приложений просто блокируются согласно внутренним предустановленным правилам. Максимум, что можно увидеть, - редкие короткие уведомительные сообщения (на самом деле, и такие системы могут заблокировать "хороший" софт, ошибочно отнеся его к "недоверенным", поскольку четких критериев разделения, увы, не существует. - Прим. ред.). Требования к технической подготовке пользователя практически отсутствуют. Также, ограниченно, можно безопасно устанавливать неизвестное, новое ПО как недоверенное для его пробы.

Разделяют sandbox HIPS с виртуализацией файловой системы и реестра и без оных (или имеющих их в минимальном объеме). Те "песочницы", что имеют виртуализацию файловой системы и реестра, нуждаются в постоянной очистке контейнера виртуализации из соображений безопасности. Sandbox HIPS без виртуализации проще в повседневной эксплуатации. Недостатки подобных систем - необходимость помнить, как именно будет запущен только что выкачанный из Интернета инсталлятор нового приложения. Типичные примеры - DefenseWall HIPS (без виртуализации), SandboxlE (с виртуализацией).

Если же мы вспомним Windows Vista UAC, то эта модель есть не самый удачный, с моей точки зрения, вариант смеси модели classical HIPS и sandbox HIPS.

Так что же предложат нам антивирусные компании для защиты от зловредного ПО в ближайшие несколько лет? По моему личному мнению, это будет смесь из sandbox HIPS и элементов "белого списка". Дело в том, что основная проблема антивирусной индустрии - временной лаг между началом распространения новой модификации зловредного ПО и добавлением соответствующей сигнатуры в базу данных. Если заполнять его blacklisting HIPS, получится то же самое, что есть сейчас, только вид сбоку, поскольку данный вид также зависит от (да, поведенческих, но тем не менее!) сигнатур, да и зачастую будет забрасывать пользователя своими вердиктами с просьбой подтвердить их или опровергнуть. Если же это будут whitelisting HIPS, то постоянные всплывающие окна на неподписанных приложениях также сведут эффективность данной системы на нет. Только системы, построенные на основе sandbox HIPS, могут похвастаться отсутствием раздражающих окон с вопросами, отсутствием перекладывания ответственности за принятие окончательного решения на пользователя и очень высоким интегральным уровнем защиты, способной удерживать зловредное ПО внутри "недоверенной" зоны до тех пор, пока соответствующая сигнатура не будет добавлена в антивирусную базу.

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

КОММЕНТАРИИ

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

По моему мнению, эффективным не может быть только один из рассмотренных подходов. Лучшие защитные решения в дальнейшем будут совмещать в себе технологии защиты на основе Black-list- и White-list-подходов; также будут совместно использоваться эвристические и сигнатурные технологии. Эффективность бинарного деления (хороший/плохой, разрешать все/запрещать все) явно недостаточна для обеспечения безопасности в современном сложном и быстроменяющемся мире. Эта концепция сменится парадигмой гибкой защиты, в которой и категорий ПО будет несколько (например, известный хороший, известный плохой, неизвестный доверенный, известный недоверенный), и работа ПО будет ограничиваться гибко - набор разрешенных операций будет гибко настраиваемым, что позволит эффективно бороться с вредоносным программным обеспечением, при этом не блокируя работу нормального, хоть и похожего на подозрительный, софта.

Николай Гребенников, ЗАМЕСТИТЕЛЬ ДИРЕКТОРА ДЕПАРТАМЕНТА ИННОВАЦИОННЫХ ТЕХНОЛОГИЙ "ЛАБОРАТОРИИ КаСПЕРСКОГО"

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


Ссылка на сообщение
Поделиться на другие сайты
Storm
АНТИВИРУСЫ ИГРАЮТ ЧЕРНЫМИ. И ПРОИГРЫВАЮТ?

Еще не начав читать статью был уверен, что Илья вспомнит DW :)

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


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

Это 8-ка будет смесью хипс-технлогоий и традиционного (в понимании ЛК) антивируса, значит. Или они на 9-ку перенесли эти планы?

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


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

Короче, все умерли, будет только песочница как единственно жизнеспособное решение. И все побегут к автору за правами на его детище.

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


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

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

К томуже, если вирусописатели и иже с ними придумали методы обхода всех существующих на данный момент технологий (распространенных, конечно), то почему не проглядывается мысль, что ПОСЛЕЗАВТРА "злодеи научились красиво и элегантно обходить песочницы"?

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


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

Меж тем да, технологии виртуализации уже обходятся.

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

Кстати, Проактивная защита Касперского - не только поведенческая HIPS.

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


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

э только щас допер, надо было тему назвать Больной бизнес Ильи Рабиновича :D

Простите Илья, просто броский заголовок бы получился :D

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


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

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

Но все же без сигнатур в том или ином виде не обойтись.

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

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

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


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

Что ж тут парадоксального-то? Классическая философская концепция "вызов-ответ".

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


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

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

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


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

Причем здесь Norman то ?

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


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

Чёткие критерии существуют:всё,что приходит извне (из интернета,CD,DVD,флэшки и прочих поставщики информации,программ,документов и т.д.),приходит из,или посредством,реально недоверенной зоны.Это и есть причина считать и пришедшее оттуда недоверенным с соответствующим запретом пришедшему именно на те действия,которыми он может и навредить.Размытости в этом не существует.(К "Чт Окт 11, 2007 7:04 pm":вышесказанное проверено на DefenseWall)

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

К томуже, если вирусописатели и иже с ними придумали методы обхода всех существующих на данный момент технологий (распространенных, конечно), то почему не проглядывается мысль, что ПОСЛЕЗАВТРА "злодеи научились красиво и элегантно обходить песочницы"?

Они пользуются неустранимым слабым местом классического АВ:всё,что не запрещено,есть разрешено.Для этого достаточно старых методов.Только для этого надо значительно дольше,чем раньше,искать,что АВ ещё не имеет в тех или иных сигнатурах,так как и антивирусы свои возможности того,что они вообще могут детектить,повысили.

Песочницы не зависимы от сигнатур.Их детект и запрет вредоносного наступает не после того,когда вирус попадёт к аналитикам, потом к защитному ПО в виде сигнатуры (до этого вирус делает всё),а наступает сразу с попаданием файла на комп,так как файл приходит из недоверенной зоны,а этим сразу с аттрибутом "недоверенный".

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


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

Да, это действительно проблема. Иногда очень нехватает информации. Однако учитывая быстрое появление и большое количество новых вирусов такая проблема ясна :(

Мне кажется, что комментарий специалиста Лаборатории Касперского справедлив. Одним только ХИПСом ограничиваться нельзя ни в коем случае. Да и подписи зловредописатели научатся подделывать очень быстро.

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


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

В целом правдиво, но весьма натянуто. Полиморфных/самопрепаковывающихся малвар - считанные еденицы в потоке десятков тысяч однообразных школьных поделок на VB. Концептуально новые "методы заражения" появляются еще реже - еще 2 года назад никто не знал ransonware как класс, а теперь сразу вспоминают gpcode... и все - больше заметных представилелей небыло.

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

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

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

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


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

Отвечу всем и сразу.

1. Название статьи- целиком и полностью редакционное. Жираф большой, ему виднее...

2. Если действительно внимательно прочитать статью, а не по верхам, то становится очевидно, что в ней описан HIPS, поддерживающий сигнатурный анти-вирус в тех местах, где он не справляется с поставленной задачей.

3. ransomeware- первые вариенты имели место ещё в 90-е, просто неразвитость Инета и online-платёжных систем делало их невыгоднями экономически.

4. Sandbox HIPS к Norman sandbox имеет такое же отношение, как автомобиль к ракете- оба делаются из железа, но назначение и функционал совершенно разное.

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

6. DW действительно упоминается, но лишь по одной причине- я больше не знаю удобных end-user'овских sandbox-ов без виртуализации файловой системы. Если знаете- приведите пример.

7. Более того, я, св общем-то, не заинтересован в российском рынке (и, соответственно, в пиаре)- end-user программы здесь не продаются, а на корпоративный рынок у меня лезть пока не получается.

8. Панацеи нет и не будет- на новые виды угроз будут создаваться новые виды защиты, на новые виды защиты- новые виды угроз. Это бесконечный процесс, ибо базируется на особенностях homo sapience.

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


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

Согласен с Dr.Golova, но не согласен с его примером:

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

А с какой стати браузер будет доверенным?

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


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

Браузер есть по умолчанию недоверенный и прав на компрометацию доверенных процессов,документов,файлов не имеет,а этим не имеет прав и всё,приходящее через него.

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

Не может.Там автор кнопку предусмотрел для "а вдруг".Не исключаю,что даже её не нужно.Детали знает автор по конкретным примерам.

Лучше узнать что ты затроянился завтра, чем не узнать об этом вобще,

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

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

Это есть вторая причина,почему я так не делаю.

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

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

Если к security продукту нужно ставить в дополнение какие-то сторонние дополнения, то такой продукт не стОит внимания и должен сразу отправляться в топку.

Знаешь,почему security продукт становится security продуктом?Догадываешься,что составляющие этого продукта могут быть от разных авторов?

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


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

Ммм, отходы моего гнилого мозга задели народ....

> Браузер есть по умолчанию недоверенный и прав на компрометацию доверенных процессов,документов,файлов не имеет

Наоборот! На локальной машине именно браузер получит максимальные привелегии, и обойдет все хипсы. (хипс будет ругаться, но юзер твердой рукой подавит все выходки!) Ибо дрочер хочет посмотреть свою авишку =) Думай не как админ, думай, как обычный юзер!

> А с какой стати браузер будет доверенным?

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

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

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

Да мне и не нужны твои потуги. Затроянят же обычных пользователей, а не экспертов анималвары =)

ЗЫ: простите что совсем не в тему топика, так уж получилось, на ближайшем офицальном слете расскажу поподробней =)

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


Ссылка на сообщение
Поделиться на другие сайты
Илья Рабинович
Наоборот! На локальной машине именно браузер получит максимальные привелегии, и обойдет все хипсы. (хипс будет ругаться, но юзер твердой рукой подавит все выходки!) Ибо дрочер хочет посмотреть свою авишку =) Думай не как админ, думай, как обычный юзер!

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

> А с какой стати браузер будет доверенным?

А теперь браузер - главная часть системы, и если его забанить то вся система колом встает

Не встаёт. Люди работают без проблем.

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


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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Werasy
хипс будет ругаться, но юзер твердой рукой подавит все выходки!) Ибо дрочер хочет посмотреть свою авишку =) Думай не как админ, думай, как обычный юзер!

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

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

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

И ведь придет точно

Мне нет.Зачем мне наверняка затрояненное с левого сайта?

Затроянят же обычных пользователей

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

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


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

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

Авишка не появится,так как подавляется хипсом.Проверено на обычных юзерах мною лично.Если что-то "не шло",то исправлялось дополнением правил в Firewall или АВ.

Большинство людей это будет бесить. Я хочу сказать, а он #%#% не качает. Что за фигня? Каждый раз лезть куда-то и проверять правила в лом.

Давайте отталкиваться от маркетинга и четко обозначим целевую аудиторию. Кто должен покупать sandbox HIPS и т.д.?

Профессионал? Врят ли, он типа и так все знает.

Продвинутый юзер? Заломает все настраивать (см. выше).

"Домохозяйка"? Она сама во-первых такое не купил. А если ей принесет друг сердца, то после 3-го обращения типа "я хочу установить ... а она не ставится, приди и помоги", точно снесет.

Пусть лучше с вирусами живет, но не парит мозг каждый день :-)

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


Ссылка на сообщение
Поделиться на другие сайты
Werasy
Чем больше я читаю эту ветку, тем больше убеждаюсь, что мне не нравится как пользователю мысль, что что-то там будет подавляться без поего на то согласия. ...Большинство людей это будет бесить. Я хочу сказать, а он #%#% не качает. Что за фигня? Каждый раз лезть куда-то и проверять правила в лом.

Ты прав.Это есть причина непользования прог,требующих этого.Какие б они в остальном замечательные не были б.Любой,читающий "HIPS",думает "та самая PDM".Я же говорю про DefenseWall.Ты используешь Firewall?В случае "да" тебе уже пришлось большие знания иметь для конфигурации Firewall,чем для использования DefenseWall HIPS.Если ты хотя бы одну настройку не наугад,а с пониманием эффекта в АВ с default переключаешь,то этим уже имеешь переквалификацию по отношению к DW.По любой новой проге интернетской тебе придётся дольше с твоей Firewall и АВ возиться,чем с DW.Хочешь спорить?

Давайте отталкиваться от маркетинга и четко обозначим целевую аудиторию. Кто должен покупать sandbox HIPS и т.д.?

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

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


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

Inkogn вернулся с новым ником - предположил по стилю изложений мыслей б. :)

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


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

http://www.antimalware.ru/index.phtml?part...d=185&arc=0

Уже ставшие привычным сообщения,что "оказались заражены более вот это да защищенных компьютеров (имеющих установленное активное и обновленное решение безопасности) и ну тут всё ясно незащищенных компьютеров."

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

DefenseWall HIPS знает так же и ответ на "что делать":известных и неизвестных для антивирусов зловредов и прочий деструктив и келоггейство блокировать,доверенный же софт не трогать.Без вопросов и "впопад".Ошибочная блокировка при пользовании ничего не подозревающих пользователях замечена не была.

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


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

  • Сообщения

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