Обзор экосистемы Kaspersky OT CyberSecurity - Выбор корпоративных средств защиты - Форумы Anti-Malware.ru Перейти к содержанию
AM_Bot

Обзор экосистемы Kaspersky OT CyberSecurity

Recommended Posts

AM_Bot
Обзор экосистемы Kaspersky OT CyberSecurity
«Лаборатория Касперского» интегрировала между собой две разработки для защиты критической инфраструктуры и систем промышленного сектора — Kaspersky Industrial CyberSecurity for Nodes и Kaspersky Industrial CyberSecurity for Networks, тем самым объединив возможности анализа и защиты как сетевого трафика, так и конечных точек в единую панель управления безопасностью инфраструктуры предприятия.     ВведениеKaspersky OT CyberSecurity: экосистема промышленной кибербезопасности2.1. Технологии2.2. Экспертиза2.3. ЗнанияАрхитектура промышленной XDR-платформы KasperskyПример расследования киберинцидента с использованием XDR-платформы KICSОписание расследования инцидента на основе тестового стендаВыводыВведениеС помощью комплексного моновендорного подхода возможно максимально быстро и эффективно для бизнеса внедрить средства контроля, мониторинга и устранения различных угроз. Такие средства могут включать в себя защиту ИТ-периметра промышленной организации, контроль непрерывности процесса производства, безопасность передачи данных вовне и внутри организации.Обозримое будущее — за адаптивными экосистемами, которые возможно интегрировать в стек технологий заказчика для реализации всесторонней киберзащиты от всевозможных векторов современных атак.Решения, сервисы и экспертиза, объединённые в экосистему, могут полноценно накапливать и анализировать данные, управлять информационными потоками и предоставлять возможности для своевременного реагирования и организации многоуровневой системы информационной безопасности. Без комплексного подхода труднее обеспечивать развитие и цифровизацию предприятия, защиту его ресурсов, технологических процессов и информационных активов, конкурентоспособность и доверие к продукции, а также исполнение регуляторных требований по безопасности критически важных объектов инфраструктуры. Пример такой экосистемы — Kaspersky OT CyberSecurity для защиты промышленных сред. «Лаборатория Касперского» продемонстрировала возможности ключевого элемента своей промышленной экосистемы — XDR-платформы Kaspersky Industrial CyberSecurity.Kaspersky OT CyberSecurity: экосистема промышленной кибербезопасностиУстойчивое развитие промышленных предприятий и объектов КИИ напрямую зависит от стабильности производственных и бизнес-процессов, надёжной защиты важных активов и безопасности промышленной (OT) и информационной (ИТ) инфраструктур. Постоянный рост количества и сложности киберугроз в эпоху четвёртой промышленной революции, глобализация информационной среды и необходимость соответствия требованиям регулирующих органов — всё это побуждает организации задуматься о комплексном подходе к обеспечению кибербезопасности.Назовём основные стимулы, подталкивающие промышленные предприятия к рассмотрению и внедрению комплексных решений для киберзащиты:Увеличение количества точек входа злоумышленников в инфраструктуру на стыке OT и ИТ.Ужесточение регуляторных требований в отношении защиты КИИ.Рост интереса злоумышленников к промышленным предприятиям.Отсутствие собственных компетенций и кадров в области обеспечения ИБ на предприятии, необходимость автоматизировать мониторинг и реагирование на угрозы.Проблематика промышленного сектора в области ИБ в целом такая же, как у бизнес-сегмента, основным отличием же является то, что при реализации киберинцидента здесь возможен прямой физический ущерб: сбой на производстве, утечка опасных материалов, прекращение поставок продукции, урон государственному сектору экономики и промышленности. В связи с этим выбор в пользу грамотных компетенций в части защиты инфраструктуры с помощью нескольких взаимосвязанных продуктов по безопасности выглядит наиболее приемлемым решением, тем более когда их безопасность для процессов и оборудования технологического предприятия подтверждена сертификатами. Рисунок 1. Состав экосистемы Kaspersky OT CyberSecurity Экосистема Kaspersky OT CyberSecurity — это не только перечень программных продуктов, но и опыт, знания и экспертиза в промышленной безопасности в целом.ТехнологииОсновной стек технологий защиты включает в себя XDR-платформу Kaspersky Industrial CyberSecurity (KICS for Nodes и KICS for Networks), а также решение класса SIEM Kaspersky Unified Monitoring and Analysis (KUMA) для сбора, мониторинга и корреляции событий по информационной безопасности. Эффективное внедрение этого комплекса решений мы рассмотрели в статье «Как АЭМЗ построил экосистему киберзащиты производства на базе решений Kaspersky», где рассказали о том, как в рамках промышленного предприятия было развёрнуто более 10 решений от одного вендора для киберзащиты как промышленного сектора, так и бизнес-подразделений.Помимо основных продуктов по части защиты перечень решений включает в себя Kaspersky Machine Learning for Anomaly Detection (MLAD) — систему мониторинга и выявления аномалий в работе технологических процессов, Kaspersky SD-WAN — решение для обеспечения надёжности сети и построения безопасной распределённой инфраструктуры промышленных объектов, а также Kaspersky Antidrone — систему защиты от беспилотных роботизированных аппаратов: дронов, квадрокоптеров и прочих управляемых объектов, с помощью которых возможно вести шпионаж или наблюдение либо попытаться нанести физический вред на территории предприятия.Отдельно необходимо отметить класс решений на базе собственной операционной системы KasperskyOS — к примеру, комплекс защиты объектов интернета вещей Kaspersky IoT Infrastructure Security и средство организации безопасного удалённого рабочего места Kaspersky Secure Remote Workspace.ЭкспертизаВ части применения накопленных знаний и опыта следует выделить анализ защищённости. Kaspersky ICS Security Assessment — это комплекс процедур по тестированию применяемых организационных мер и технологий защиты на устойчивость к реальным попыткам проникновения и взлома.Kaspersky Managed Detection and Response, сервис по мониторингу и реагированию на инциденты в ИБ силами экспертов «Лаборатории Касперского», проверяет оповещения и проактивно анализирует метаданные, получаемые от установленных в сети клиента продуктов «Лаборатории Касперского», на предмет наличия признаков компрометации. Эти метаданные сопоставляются с аналитическими сведениями «Лаборатории Касперского» об угрозах с целью выявления тактик, техник и процедур, применяемых преступниками против конкретной организации. Kaspersky Incident Response обеспечивает реагирование на инциденты и ликвидацию их последствий.Отметим здесь также Kaspersky Industrial Emergency Kit — «стартовый набор» сервисов, технологий и экспертизы для оперативной помощи промышленным предприятиям в вопросах защиты объектов КИИ. Эксперты «Лаборатории Касперского» оценят текущий уровень защищённости АСУ ТП промышленного объекта, а заказчик получит аналитику по возможным киберугрозам и рекомендации в отношении того, как своевременно реагировать на киберинциденты и повышать уровень осведомлённости в организации.ЗнанияKaspersky ICS Threat Intelligence — это обширная и постоянно пополняемая аналитика по угрозам, включающая в себя специализированные отчёты и потоки данных (data feeds) об угрозах и уязвимостях в АСУ ТП, в том числе на основе данных, которые поступают от линейки продуктов «Лаборатории Касперского».Kaspersky Security Awareness Platform — это онлайн-платформа обучения персонала и повышения осведомлённости в области кибербезопасности АСУ ТП о современных киберугрозах и приёмах злоумышленников, в том числе методах социальной инженерии.Kaspersky ICS CERT Training — это экспертные тренинги и курсы для ИБ-специалистов предприятия от ведущих экспертов «Лаборатории Касперского» по безопасности АСУ ТП.Архитектура промышленной XDR-платформы KasperskyKaspersky Industrial CyberSecurity (KICS) представляет собой XDR-платформу, которая объединяет мониторинг и обнаружение вторжений в промышленной сети, где работает KICS for Networks, с защитой промышленных рабочих мест, на которых развёрнуто решение KICS for Nodes со встроенной технологией EDR. Платформа обеспечивает защиту технологических процессов без влияния на них, в том числе с возможностью работы в неблокирующем режиме, когда действия по активному реагированию не применяются. Помимо пассивного мониторинга решение KICS for Networks имеет функцию активного опроса, которую можно использовать в отношении выбранного объекта сети. Благодаря интеграции компонентов платформы друг с другом можно централизованно контролировать все разрозненные промышленные сети, рабочие места и системы автоматизации. Это способствует повышению осведомлённости о ситуации и более эффективному противодействию сложным угрозам. Рисунок 2. XDR-платформа Kaspersky Industrial CyberSecurity За счёт интеграции KICS for Nodes и KICS for Networks заказчик получает возможность реализовывать сценарии инвентаризации промышленной сети, мониторинга защищённости АСУ ТП в единой консоли и обогащения сетевых событий телеметрией с конечных узлов. Все события, сформированные KICS for Nodes, могут отправляться в консоль KICS for Networks и участвовать в корреляции с уже имеющимися сетевыми событиями. Функциональные возможности KICS for Networks позволяют:составлять список активов и логическую карту сети,выявлять аномалии технологического процесса,контролировать целостность сети и появление новых устройств,проводить аудит безопасности и оценку рисков, формировать отчётность,обнаруживать уязвимости как в ПО, так и в прошивках промышленного оборудования,обеспечивать возможность интеграции с иными СЗИ для обогащения телеметрии.Основным поставщиком данных для анализа выступает агент на конечной точке, в частности — EDR-решение «Лаборатории Касперского», специально разработанное для промышленного сегмента АСУ ТП. Оно предоставляет базовые возможности по расследованию и реагированию на инциденты, включая изоляцию узла, сканирование по индикаторам компрометации, завершение подозрительного процесса.Отдельно необходимо отметить, что в KICS for Nodes поддерживается автоматизированная настройка аудита безопасности конечных точек, включая ряд необходимых проверок в формате OVAL на основе стандартов, законодательства или индивидуальных настроек заказчика. Рисунок 3. Возможности автоматизированного аудита OVAL Все указанные наработки — что в части сбора расширенной телеметрии, что в части автоматизированного аудита — приводят заказчика к иному взгляду на управление киберинцидентами: процесс отходит от стандартного «что случилось?» в сторону оценки киберрисков и управления ими, то есть к парадигме «что может случиться?».Ядром всей платформы мониторинга событий по ИБ выступает SIEM-система KUMA, в которую возможно направлять не только события из сетей АСУ от продуктов из линейки Kaspersky ОТ CyberSecurity, но и информацию из бизнес-инфраструктуры от Kaspersky Symphony, получая тем самым полную картину происходящего во всей инфраструктуре организации. События и инциденты обогащаются актуальной информацией о репутации файлов, IP- и URL-адресов путём интеграции SIEM KUMA с потоками данных об угрозах из портфолио Threat Intelligence. Рисунок 4. Корреляция событий в рамках единой SIEM По направлению Threat Intelligence в команде «Лаборатории Касперского» работают не только стандартные поставщики информации об угрозах, как внешние, так и внутренние (Red Team, APT Research Team или специалисты SOC), но и эксперты по изучению уязвимостей сектора АСУ ТП и реагированию на инциденты — международная команда Kaspersky ICS CERT.Пример расследования киберинцидента с использованием XDR-платформы KICSВ качестве примера мы рассматриваем киберинцидент в АСУ ТП на объекте электроэнергетики, а именно — в инфраструктуре трансформаторной подстанции 110/10 кВ, и используем для этого имитационную модель на базе виртуальных машин с ПО АСУ ТП и устройств защиты. Мы допускаем, что данная подстанция может обеспечивать электроэнергией жилой квартал, производственное предприятие или промышленный объект, для которых бесперебойная подача электричества может иметь критическое значение. В этой инфраструктуре можно выделить сегмент АСУ ТП, где представлены узлы локальной системы управления: узел оператора, сервер SCADA, инженерная станция. Уровнем выше находится сегмент диспетчерского центра, который предположительно контролирует работу в том числе других подстанций, но в данном случае нас интересует выделенная подстанция, а также офисный ИТ-сегмент, в котором сотрудники работают с базовыми офисными приложениями, корпоративной почтой и ресурсами интернета. Высокоуровневая схема инфраструктуры представлена на рисунке 5. Рисунок 5. Инфраструктура виртуальной подстанции Для обеспечения информационной безопасности объекта в его состав включены следующие продукты «Лаборатории Касперского»:SIEM-система KUMA,средство защиты узлов (серверов и рабочих станций АСУ ТП) KICS for Nodes,средство мониторинга промышленной сети KICS for Networks.Высокоуровневая схема инфраструктуры с интегрированными СЗИ представлена на рисунке 6. Рисунок 6. Инфраструктура виртуальной подстанции с СЗИ В представленном тестовом сценарии не преследуется цель полностью воспроизвести реальный случай целевой атаки, однако синтезированный для демонстрации случай использует элементы имевшей место и хорошо изученной к настоящему времени целевой атаки Industroyer, а также легитимные компоненты и утилиты операционных систем и средства администрирования. Мы умышленно не противодействуем ходу атаки и применяем такие конфигурации продуктов защиты, которые позволят ей проявить себя в полной мере, чтобы наглядно представить возможные последствия, а также возможности платформы в части обнаружения и реагирования.Отправной точкой развития атаки является ноутбук инженера, свободно перемещающийся между сегментами сети. Функции защиты ноутбука выключены или не задействованы в полной мере, а пользователь является локальным администратором. Компрометация ноутбука происходит в ИТ-сегменте предположительно в результате поиска его владельцем необходимого ПО и посещения для этого небезопасных ресурсов в открытых источниках сети «Интернет». Компрометация сопровождается хищением с ноутбука инженера данных о технологическом объекте и загрузкой на него первоначального скрипта, который явным образом не содержит вредоносных файлов, но является источником развития будущей атаки.Ноутбук возвращается в ОТ-сегмент, и атака получает новое развитие, затрагивая уже диспетчерский центр и расположенный в нём сервер телемеханики, на котором имеется интерфейс удалённого доступа для обслуживания и наладки, использующий для установления связи публичную сеть «Интернет». Скрипт активирует этот интерфейс и инициирует загрузку компонентов, необходимых для дальнейшего развития целевой атаки. В том числе скрипт блокирует удалённый доступ к серверу телемеханики, чем затрудняет противодействие атаке. Одновременно с этим скрипт выполняет подмену штатной службы клиента протокола МЭК 104 на сервере в диспетчерском центре, равно как и компонентов системы управления в сегменте подстанции, лишая оператора возможности управлять системой локально.Дальнейшее развитие атаки происходит по скомпрометированному таким образом каналу управления МЭК 104 от диспетчерского центра к подстанции. За счёт перенаправления нелегитимных управляющих команд через центральный сервер системы управления на оборудование подстанции предполагаемому злоумышленнику удаётся повлиять на работу объекта и прервать электроснабжение потребителей.В заключение вредоносная программа восстанавливает работу легитимного клиента протокола МЭК 104 и очищает следы своей работы, удаляя большую часть использованных компонентов, загруженных на узлы инфраструктуры объекта.Описание расследования инцидента на основе тестового стендаРассмотрим, как приведённый выше сценарий выглядит на стороне объекта защиты и как информация от средств защиты позволяет выявить и/или предотвратить развитие вредоносной активности.На АРМ диспетчерского центра оператор может обнаружить факт начала вредоносной активности по событиям обнаружения вредоносных компонентов целевой атаки, поступающим от специализированного средства антивирусной защиты KICS for Nodes. Как было указано ранее, компоненты защиты намеренно настроены с учётом возможности полной реализации атаки, потому вполне скоро в интерфейсе системы управления мы сможем увидеть результаты вредоносной активности, а именно — постепенный перевод коммутационных аппаратов подстанции в инверсное состояние (выключатели и разъединители размыкаются, а заземляющие ножи начинают замыкаться). Данное поведение говорит о том, что электрическая цепь «разбирается» и, как следствие, происходит отключение потребителя от источника. При этом оператор лишён возможности управления со своей рабочей станции и не может противодействовать атаке и оперативно восстановить электроснабжение потребителя.Визуальное отображение интерфейсов и событий на экране АРМ оператора представлено на рисунке 7. Рисунок 7. Визуальное отображение атаки на тестовом стенде Одновременно с атакой на технологический сегмент происходит завершение сессии удалённого управления со стороны диспетчерского центра без возможности повторного подключения. В отсутствие возможности управления, а также в условиях намеренно задействованного неблокирующего режима функций защиты сценарий атаки выполняется полностью до своего завершения. Рисунок 8. Разрыв сессии подключения к серверу телемеханики в диспетчерском центре Воспользовавшись данными от средств защиты узлов и телеметрией, собранной средством сетевого мониторинга, попробуем изучить, что произошло в инфраструктуре системы управления. Для этого откроем консоль SIEM KUMA и рассмотрим поступившие события. Рисунок 9. Уведомления в консоли KUMA Начать следует с телеметрии, собранной с сервера диспетчерского управления. В уведомлениях SIEM кроме факта обнаружения вредоносного объекта, компонента Industroyer, нам доступны данные о сетевой активности, контрольные суммы задействованных в целевой атаке файлов, их расположение в файловой системе, а также ссылки на идентификаторы угроз, обогащённые данными из источников Threat Intelligence.Корреляция выполнена как по факту выявления вредоносной программы, так и по признакам её активности, в том числе по взаимодействию с узлами в сети. Присутствует информация о технологических изменениях — отключениях разъединителей, замыканиях ножей, прочая полезная для расследования инцидента и последующего восстановления работоспособности подстанции и технологического процесса информация. Следует отметить, что XDR-платформа Kaspersky Industrial CyberSecurity позволяет выполнить корреляцию событий автоматически на основе набора обновляемых правил, заложенных в продукт. Тем не менее на уровне SIEM-системы KUMA аналитиком ИБ могут быть созданы собственные корреляционные правила, отвечающие актуальным потребностям работы с инцидентом. Рисунок 10. Подробный разбор активности вредоносного объекта Рассмотрев подробнее зафиксированные события в ОТ-сегменте сети, можно предположить, что первым был скомпрометирован ноутбук инженера, с которого в дальнейшем было инициировано подключение к серверу диспетчерского управления, откуда и продолжилась основная атака. Но нам всё же не хватает подробных данных о принадлежности ноутбука и пути его заражения. Выполнив поиск по MAC-адресу ноутбука и изучив полученные логи, можно понять, что узел с данным МАС-адресом ранее подключался к ИТ-сегменту сети, где получал IP-адрес от сервера DHCP. Из журналов сетевой активности, полученных с прокси-сервера, можно понять, что ноутбук обращался к неизвестному ресурсу в интернете. Взаимодействие с интернет-ресурсом сопровождалось обменом файловыми данными, в частности отправкой файлов PDF, по названиям которых можно судить об их отношении к проектной или рабочей документации АСУ ТП, и загрузкой EXE-файлов, по названиям которых можно судить об их принадлежности к компонентам и утилитам для обновления прошивок промышленных устройств. На основе этих данных можно предположить, что через упомянутый публичный ресурс и произошла компрометация инженерного ноутбука, а данные по организации промышленного сегмента сети стали доступны злоумышленнику. Рисунок 11. Изучение логов активности скомпрометированного ноутбука Для проверки репутации ресурса, к которому обращается ноутбук инженера, а также для выявления возможных связанных с этим ресурсом угроз, в которых он уже был замечен ранее, мы можем сделать запрос Threat Lookup. Рисунок 12. Поиск информации в фидах Threat Intelligence К сожалению, подробная информация по данному ресурсу отсутствует, но это не всегда является критерием отсутствия рисков: возможно, ресурс используется в этих целях впервые.В рассматриваемом случае средства защиты на ноутбуке инженера не установлены или деактивированы, и это лишает нас возможности получить информацию и исследовать, что происходило на скомпрометированном узле между его включением в ИТ- и OT-сегменты защищаемой сети.Сделав первичные выводы о точке проникновения вредоносной активности через ИТ-сегмент, перейдём к более детальному исследованию инцидента в OT-сегменте и постараемся имеющимися средствами отследить основные этапы развития атаки.Данные карты сетевых взаимодействий KICS for Networks подтверждают факт нелегитимного сетевого взаимодействия ноутбука инженера. Красные линии на диаграмме от ноутбука к серверу телемеханики и далее от него к серверу SICAM-PAS, играющему роль центрального коммутирующего устройства подстанции, показывают наличие нехарактерных сетевых взаимодействий и событий по ИБ. Также следует отметить, что сервер SCADA выделен на карте красным; это говорит о наличии событий по безопасности и на этом узле, однако нелегитимных коммуникаций к узлу не зарегистрировано, что может свидетельствовать об атаке на узел через легитимный канал связи. Рисунок 13. Карта сетевых взаимодействий Перейдя в раздел «События», мы сможем увидеть несколько групп событий, объединённых по принципам использованных техник и тактик MITRE, а также источников информации, скоррелированных в один инцидент. Рисунок 14. События корреляции Среди событий, полученных из телеметрии, поставляемой компонентом EDR с узлов инфраструктуры (в том числе с узла сервера телемеханики в диспетчерском центре), стоит обратить внимание на событие активации на атакованном узле дополнительного интерфейса с доступом в сеть «Интернет». Вероятно, именно через данный интерфейс был осуществлён доступ ко внешнему C&C-серверу, послужившему источником дальнейшего развития атаки. О наличии возможности активации и использования этого интерфейса на атакованном узле злоумышленник мог узнать вследствие произошедшей ранее утечки информации. Вспомним, что на момент подключения ноутбука инженера к ИТ-сегменту был зарегистрирован обмен данными со внешним ресурсом в сети «Интернет», который и мог послужить каналом утечки данных об инфраструктуре. Рисунок 15. Обнаружение дополнительного сетевого интерфейса узла RDC В разделе событий мы видим подробную информацию обо всех действиях, которые были зафиксированы средствами защиты узлов KICS for Nodes и системой мониторинга KICS for Networks. В их числе присутствуют события об изменениях в реестре, файловых операциях в папках проекта SCADA, запуске скриптов и программ, а также нарушения технологического характера, заключающиеся в некорректной последовательности выдачи команд управления. Рисунок 16. События на узле диспетчерского центра и сервере SCADA На основе этой информации возможно выявить действия, которые выполнялись вредоносной программой, в том числе получить сведения об изменённых ключах реестра для блокировки удалённого доступа к узлу, об именах подменённых файлов в проекте SCADA. События по выявленным нелегитимным сетевым взаимодействиям и командам управления технологическим процессом обогащены данными с узлов о конкретных приложениях — источниках этих взаимодействий.Перейдя в карточку инцидента, сформированную на основе данных агента EDR на сервере телемеханики, мы увидим подробную информацию о процессах узла, связанных с инцидентом, в виде цепочки атаки. В карточке есть не только информация о вредоносном объекте, но и сведения о родительском процессе и его действиях на узле: сетевые коммуникации, загрузка файлов, правки реестра, запуск исполняемых файлов. Рисунок 17. Карточка инцидента Переходя от расследования к реагированию на инцидент, мы можем не только запретить запуск обнаруженных компонентов атаки, но и создать задачи по обнаружению индикаторов компрометации (IoC) или схожей активности на других доступных узлах инфраструктуры. Отдельно отметим, что поиск подозрительной файловой активности может осуществляться в том числе по данным функции контроля запуска приложений на узлах, опирающейся на эталонный набор разрешённого ПО. Этот механизм может способствовать выявлению используемых нелегитимных процессов либо блокировать их при соответствующих настройках. Рисунок 18. Задача поиска IoC (индикаторов компрометации) на узлах инфраструктуры С помощью модуля анализа конфигураций на базе OVAL дополнительно можно провести исследование и выявить узлы инфраструктуры, которые также могут или могли быть подвержены атаке в силу наличия в них соответствующих критических уязвимостей. Данные об уязвимостях могут быть получены вместе с обновлениями наборов правил OVAL, поставляемых экспертной группой ICS CERT «Лаборатории Касперского». Также для анализа конфигураций могут быть задействованы наборы правил от внешних поставщиков либо пользовательские наборы правил, подготовленные под определённые задачи. Рисунок 19. Использование модуля OVAL для поиска уязвимых узлов Результаты поиска индикаторов компрометации на узлах инфраструктуры показывают, что ряд артефактов вредоносной активности всё ещё присутствует на некоторых узлах. Рисунок 20. Результаты выполнения задачи по поиску IoC Например, «autorun.exe» был найден не только на сервере телемеханики, но и на SCADA-сервере, где файл может представлять дополнительную угрозу. В нашем случае угроза может быть нейтрализована одним из двух способов: переводом модуля контроля запуска приложений из состава KICS for Nodes в блокирующий режим (при условии, что в разрешающих правилах модуля данного файла нет — это можно легко проконтролировать поиском по определяемой контрольной сумме файла) либо запретом запуска указанного файла через блокирование его в политике агента EDR. Стоит отметить, что поиск IoC может быть использован и ретроспективно, за период хранения телеметрии на узлах; в этом случае выполняемая задача сканирования на IoC оповестит о следах присутствия файлов в том числе в ситуациях, когда подозрительные файлы уже были удалены. Рисунок 21. Рассмотрение обнаруженных IoC на конечных узлах В числе доступных мер реагирования на инцидент в безопасности доступно также контролируемое вручную полное отключение узла — источника угрозы от сети организации. Этот механизм может быть реализован путём API-интеграции KICS for Networks с активным сетевым оборудованием защищаемой инфраструктуры. В рассматриваемом случае интеграция с коммутатором Cisco сетевой инфраструктуры объекта позволяет блокировать порт коммутатора вручную через деавторизацию устройства на стороне KICS for Networks и в то же время таким же образом контролировать подключение в инфраструктуру любого другого неавторизованного устройства, доступ которому будет закрыт до момента авторизации соответствующего узла системой мониторинга.Рассматривая сценарий выявления авторизованного, но скомпрометированного устройства, которое было замечено во вредоносной активности, для точного определения места его подключения в инфраструктуре можно также воспользоваться топологической картой сети, построенной на основе данных активного опроса, выполненного KICS for Networks. Коммутатор и порт, к которому подключён скомпрометированный узел, мы видим по данным топологической карты. В то же время в рассматриваемом случае имеется настроенная интеграция KICS for Networks с коммутатором по API. При её наличии блокирование скомпрометированного узла доступно через его деавторизацию (смену статуса устройства на «неразрешённое») в интерфейсе KICS for Networks. Рисунок 22. Топологическая карта организации Рисунок 23. Смена статуса устройства на «Неразрешённое» в сети организации ВыводыПроведённая демонстрация работы XDR-платформы Kaspersky Industrial CyberSecurity и сценариев кросс-продуктовых интеграций, например, с SIEM-системой KUMA показывает широкий набор возможностей по анализу защищённости и предоставлению данных для планирования мер превентивной защиты предприятий от возможных угроз и вторжений (например, детальная инвентаризация инфраструктуры с данными об активах, их уязвимостях и сетевой инфраструктуре, ключевых рисках), по выявлению угроз в инфраструктурах промышленных предприятий и реагированию на них (включая специализированные возможности по сбору и анализу телеметрии и корреляции данных из различных источников, поиску признаков компрометации, встроенные инструменты расследования и реагирования).Совместное использование и интеграция специализированных решений KICS с другими решениями «Лаборатории Касперского» позволяет построить целостную экосистему для защиты промышленного сегмента предприятий, существенно расширив возможности по своевременному выявлению, расследованию и предотвращению промышленных угроз. В интеграции со средствами защиты, обнаружения и реагирования на угрозы для ИТ-сегмента предприятия появляется возможность существенно повысить общую осведомлённость об информационной безопасности и защищённость инфраструктуры, обеспечить своевременное обнаружение и оптимизировать реагирование на угрозы, имея в распоряжении коррелируемые данные из специализированных источников.

Читать далее

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


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

  • Сообщения

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