Обзор экосистемы 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
      ESET Online Scanner был обновлён до версии 4.0.1. Приложение теперь работает только в 64-разрядной ОС.
    • Ego Dekker
      ESET Cyber Security был обновлён до версии 9.0.6700.
    • AM_Bot
      Теория звучит убедительно, но работает ли она на практике? Мы внимательно изучили Phishman 2.35 и решили не останавливаться на описании её возможностей. Вместо этого протестировали платформу на собственных сотрудниках и удивились, к каким результатам это привело.      1. Введение2. Методология тестирования Phishman 2.353. Первичное тестирование3.1. Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылки3.2. Тестирование доставки и отражения результатов в статистике3.3. Результаты атак4. Обучение4.1. Формирование учебной группы4.2. Составление образовательной программы по повышению киберкультуры4.3. Процесс обучения и его результаты5. Повторное тестирование5.1. Результаты атак6. Подведение итогов6.1. Сложности, с которыми мы столкнулись7. Впечатления от проекта команды «АМ Медиа»7.1. Реакция сотрудников7.2. Реакция организаторов7.3. Сотрудничество с вендором8. ВыводыВведениеPhishman 2.35 — это система повышения осведомлённости пользователей в сфере ИБ. Она помогает развивать киберкультуру и формировать у сотрудников устойчивые навыки безопасной работы с информацией, цифровыми сервисами и корпоративными ресурсами. В процессе обучения сотрудники учатся распознавать актуальные сценарии атак, закрепляют правильные модели поведения и в результате реже становятся причиной инцидентов, связанных с человеческим фактором.В первой части обзора Phishman 2.35 мы рассмотрели платформу с точки зрения её возможностей. Теперь пришло время проверить, как всё это работает на практике. За время проекта мы не только оценили эффективность различных сценариев, но и столкнулись с рядом особенностей, которые невозможно увидеть в документации. Одни из них влияли на ход тестирования, другие оказались скорее организационными нюансами, о которых стоит знать заранее.Методология тестирования Phishman 2.35В процессе работы с киберкультурой «АМ Медиа» мы будем использовать следующие метрики:Обученность. Отражает уровень знаний сотрудников в области ИБ. Показатель растёт, когда сотрудники осваивают темы: реагирование на инциденты, защита от социальной инженерии и другие критически важные компетенции.Иммунность. Показывает, как сотрудники применяют знания на практике. Она повышается, когда демонстрируется способность распознавать угрозы и правильно на них реагировать в реальных сценариях.Киберосознанность — итоговая метрика. Объединяет знания и практические навыки, показывая, насколько сотрудники в целом устойчивы к киберугрозам и действуют корректно при их возникновении.Прежде чем оценивать эффективность работы системы, необходимо определить отправную точку. Первичное тестирование определит, на какие сценарии реагирует каждый сотрудник, где чаще всего допускаются ошибки и какие темы требуют дополнительного развития. На основе этих данных формируется индивидуальная программа обучения: сотрудники проходят персонализированные курсы, выполняют практические задания и тесты, которые помогают устранить выявленные пробелы и закрепить необходимые навыки. В процессе обучения повышается уровень обученности, а закрепление знаний через практику влияет на показатель иммунности. После завершения обучения мы проведём повторное тестирование, которое покажет, какие изменения произошли по всем ключевым метрикам.Заключительный этап — сравнение результатов первичного и повторного тестирования. Здесь станет понятно, насколько вырос уровень киберкультуры сотрудников: изменилось ли их отношение к вопросам ИБ, стали ли они увереннее распознавать угрозы и чаще принимать безопасные решения в ситуациях, где раньше могли допустить ошибку.В качестве основного канала для рассылки фишинга выбрали электронную почту. Причина очевидна: именно она остаётся основным способом первичного контакта злоумышленников с сотрудниками и доставки фишинговых сценариев. По имеющимся оценкам, более 90 % успешных кибератак начинаются с электронного письма, поэтому исключать этот канал из подобных проверок было бы некорректно.Первичное тестированиеРеальные фишинговые атаки почти никогда не строятся по универсальному шаблону: злоумышленники адаптируют содержание писем под роль человека в компании, его рабочие процессы и типовые задачи. Поэтому при выборе целевой аудитории мы разделили сотрудников по функциям и уровню доступа к корпоративным данным, а сам проект разбили на 3 последовательные волны с разным уровнем сложности.Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылкиПосле определения целевой аудитории был проведён анализ структуры подразделений и рабочих процессов сотрудников. На этом этапе изучались:должностные обязанности;распределение зон ответственности;характер внутреннего взаимодействия между отделами;используемые адреса электронной почты;формат повседневной служебной переписки.Это позволило понять, какие сценарии коммуникации являются для сотрудников привычными и не вызывают подозрений.На основе собранных данных были подготовлены сценарии фишинговых сообщений. При разработке содержимого учитывались тематика рабочих задач, стиль корпоративного общения, оформление внутренних уведомлений и типовые причины отправки писем внутри организации. Основная задача заключалась в том, чтобы письмо воспринималось как стандартное рабочее сообщение, соответствующее реальным бизнес-процессам заказчика.Волна 1. Первая волна была построена как массовый фишинг. Сценарий — сверка графика отпусков. Для атаки создавали и настраивали пользовательский шаблон. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки.На этом этапе проверялась базовая реакция сотрудников на привычные рабочие триггеры и способность распознавать типовые признаки фишинга без привязки к конкретному подразделению. Рисунок 1. Шаблон для первой волны Рисунок 2. Вид фишингового письма из первой волны в почте Волна 2. Для каждого отдела были подготовлены письма, основанные на реальных рабочих процессах, характерных запросах и ситуациях, с которыми сотрудники регулярно сталкиваются в своей деятельности. Для атаки создали и настроили пользовательский шаблон, где-то добавили немного визуального оформления. Время начала рассылки — по запланированному времени. Рисунок 3. Пример шаблона из второй волны для отдела «Продажи» Рисунок 4. Вид фишингового письма из второй волны для отдела «Продажи» Волна 3. Здесь моделировались уже более сложные сценарии целевого фишинга (spear phishing). В письмах использовались специальные формулировки, элементы корпоративного брендирования. На этом этапе проверялась не только внимательность сотрудников, но и способность замечать менее очевидные признаки атаки в условиях, максимально приближённых к реальной целевой компрометации.За основу брали системный брендированный шаблон «Яндекс ID», добавили фишинговую форму и скорректировали немного её содержание. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 5. Пример шаблона из третьей волны Рисунок 6. Вид фишингового письма из третьей волны При переходе по ссылке открывалась фишинговая страница. Рисунок 7. Фишинговая страница Тестирование доставки и отражения результатов в статистикеДалее была подготовлена инфраструктура рассылки. После её настройки проводилось тестирование доставки сообщений. Проверялась доставка писем во входящие сообщения почтовых клиентов, анализировалась реакция антиспам-механизмов в почте, а также контролировалась корректность работы механизмов отслеживания действий пользователей. Рисунок 8. Результаты тестирования доставки и отображения сообщений в почте Тестирование прошло успешно.После завершения проверки была сформирована последовательность отправки сообщений по заранее определённым волнам. Такой подход позволил распределить нагрузку, контролировать ход тестирования и отслеживать реакцию сотрудников на различных этапах проведения проверки. Рисунок 9. Активные мероприятия Результаты атакБыли получены следующие результаты:Иммунность — 81 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 71 %.Уровень риска — 8, средний. Устойчивость формируется, но есть ещё риски. Рисунок 10. Общая информация после проведения первичного тестирования Самый низкий уровень иммунности — около 50 %, после первых двух волн атак. Рисунок 11. График иммунности во время первичного тестирования Далее — сформировали в системе отчёт по скомпрометированности сотрудников, на основании которого выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Рисунок 12. Отчёт по скомпрометированности всех сотрудников в Phishman 2.35 Таблица 1. Результаты первичного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот04,76 %4,76 %Продажи04,76 %9,52 %Продюсеры 0023,8 %Редакция0019,04 %Руководитель000 ОбучениеПервичное тестирование завершено, поэтому следующим этапом стало определение группы риска и формирование программы обучения.Формирование учебной группыНа этапе отбора рассматривались два варианта формирования учебной группы. Первый предполагал использование показателя иммунности сотрудников. Второй вариант заключался в создании правила, автоматически формирующего список сотрудников, которые были скомпрометированы в ходе проведённых проверок. Этот подход позволял сразу получить выборку пользователей, продемонстрировавших наибольшую подверженность атакам, без ожидания обновления показателей.Был выбран второй вариант. На основании созданного правила была сформирована группа для обучения: в неё вошли люди, которые были скомпрометированы в ходе первичного тестирования. Рисунок 13. Создание правила для выявления группы риска Рисунок 14. Отчёт по отработанному правилу для выявления группы риска Отдельно была сформирована группа сотрудников, успешно распознавших фишинговую атаку, для участия в обучении, направленном на поддержание киберкультуры.Составление образовательной программы по повышению киберкультурыПопавшиеся сотрудники были включены в отдельную учебную группу, для которой сформировали персональную образовательную траекторию. В неё вошли 3 микрокурса по фишингу и 1 курс по информационной безопасности. Содержание траектории было направлено на повышение устойчивости к методам социальной инженерии и снижение вероятности компрометации учётных данных. Рисунок 15. Заполнение параметров обучения сотрудников Рисунок 16. Составление учебной программы Отдельно была запущена программа обучения для сотрудников, которые не попали в выборку по результатам правила.Процесс обучения и его результатыПервый отчёт мы сформировали через 2 дня после запуска обучения, что позволило получить предварительную оценку вовлечённости сотрудников. Анализ данных показал, что наибольшую активность на начальном этапе продемонстрировали сотрудники, которые попались на фишинг. Рисунок 17. Промежуточный анализ обучения Через неделю после запуска обучения провели повторный анализ прогресса, включая оценку прохождения курсов и выявление участников, не приступивших к обучению. Рисунок 18. Отчёт по динамике обучения в Phishman 2.35 Анализ показал, что часть сотрудников не завершила обучение в установленный срок. Для обеспечения максимального охвата было принято решение о продлении сроков прохождения курсов. Рисунок 19. Продление и корректировка процесса обучения В результате фактическая продолжительность обучения составила 2 недели, что превысило первоначально установленный срок в одну неделю. Но и этого времени не хватило нашим сотрудникам. Чтобы узнать, кто оказался более ответственным, воспользовались возможностями правил. Рисунок 20. Пример настройки правила по выявлению сотрудников, прошедших обучение В результате была получена информация о сотрудниках, полностью и частично прошедших обучение. Рисунок 21. Отчёт по сработанному правилу по выявлению сотрудников, прошедших обучение Рисунок 22. Отчёт по сработанному правилу по выявлению сотрудников, частично прошедших обучение Результаты обучения:полностью прошли обучение — 52 %;частично — 22 %;не прошли обучение — 26 %.Мы проанализировали список сотрудников, не приступивших к обучению, и выяснили, что это те, кто не попался на фишинг во время первичного тестирования.Среди сотрудников, которые попались на фишинг, 80 % прошли обучение, остальные — прошли его частично. Рисунок 23. Результаты обучения сотрудников «АМ Медиа» Вместе с тем за этот период были зафиксированы положительные изменения в ключевых показателях: уровень обученности достиг 9 319 баллов, а показатель киберосознанности — 7 561 баллов. Несмотря на положительную динамику, полученные значения оставались гораздо ниже целевых ориентиров, что свидетельствует о необходимости дальнейшей работы по повышению вовлечённости сотрудников и развитию киберкультуры.Повторное тестированиеПовторное тестирование проводилось по тем же этапам, что и первичное: подготовка шаблонов, тестирование и проведение атак. Как и на первом этапе, основной задачей было сделать письмо максимально похожим на стандартную рабочую переписку, соответствующую реальным бизнес-процессам нашей компании.Подготовительный этап повторного тестирования потребовал дополнительных временных затрат, связанных с регистрацией новых доменов и расширением сценариев атак с учётом результатов первичного тестирования.Волна 1. Сценарии формировались не только для отдельных подразделений, но и адресно для конкретных сотрудников, что позволило повысить реалистичность и точность имитации фишинговых атак. Запустили несколько атак, для каждой из них были разработаны индивидуальные шаблоны электронных писем и соответствующие фишинговые формы. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 24. Пример фишингового письма для первой волны Рисунок 25. Пример фишинговой формы для письма из первой волны Волна 2. Вторая волна представляла собой массовую фишинговую кампанию. Для неё был создан и настроен пользовательский шаблон, основанный на триггерах срочности и страхе финансовых потерь. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки. Рисунок 26. Пример фишингового письма для второй волны Тестирование доставки писем и корректности отражения результатов в статистике прошло успешно.Результаты атакВ повторном тестировании приняли участие уже 23 человека. Увеличение числа участников на 2 человека связано с подключением новых сотрудников к нашему эксперименту. Резких скачков иммунности здесь не наблюдалось. Рисунок 27. График иммунности во время повторного тестирования Для дополнительной оценки мы и здесь также выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Таблица 2. Результаты повторного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот000Продажи008,7 %Продюсеры 008,7 %Редакция8,7 %08,7 %Руководитель000 Мы также посмотрели, как себя показали сотрудники, которые не прошли обучение, в повторном фишинговом тесте. По данным отчёта, в первой волне повторного тестирования на фишинг попались 40% из всех, кто не обучался. Рисунок 28. Поиск информации о сотруднике в отчёте по атакам Подведение итогов После завершения всех этапов эксперимента мы получили следующие показатели:Иммунность — 76 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 91,3 %.Уровень риска — 7, средний. Рисунок 29. Информационная панель Phishman 2.35 после завершения эксперимента После обучения и повторного тестирования добавились другие показатели:Обученность — 11 / 100. Знания отсутствуют, обучение следует начать с базового уровня.Киберосознанность — 10 / 100. Низкий уровень, сотрудники не знают, как действовать в случае угроз.Часть результатов сравнили и представили их в таблице ниже. Таблица 3. Сравнение показателей киберкультуры до и после обученияПоказательДо обученияПосле обученияОбученность09319Иммунность81 %76 %Киберосознанность 07561Охват аудитории (повторно попались на фишинг)71 %91,3 %Уровень риска87 Также проанализировали действия сотрудников после обучения и сравнили их с результатами первичного тестирования. Таблица 4. Сравнение действий сотрудников до обучения и послеОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДо обученияПосле обученияДо обученияПосле обученияДо обученияПосле обученияДокументооборот004,76 %04,76 %0Продажи004,76 %09,52 %8,7 %Продюсеры 000023,8 %8,7 %Редакция08,7 %0019,04 %8,7 %Руководитель000000 Рисунок 30. Процент попавшихся на фишинг до обучения и после по отделам Если во время первичного тестирования попалось 22 % участников, то после обучения этот показатель уменьшился и стал 12 %. Рисунок 31. Общий процент попавшихся на фишинг до обучения и после Результаты повторного тестирования показали, что, несмотря на заметное снижение количества взаимодействий с фишинговыми письмами, часть сотрудников по-прежнему выполняет действия, свидетельствующие о подверженности атакам. Это ожидаемый результат, поскольку киберкультуру невозможно сформировать за столь короткое время. Речь идёт о длительном процессе, который требует регулярной работы как со стороны специалистов по информационной безопасности, так и со стороны самих сотрудников.Наш эксперимент позволил проверить знания сотрудников, провести обучение и затем оценить, насколько полученные знания закрепились на практике. Однако с точки зрения развития киберкультуры — это лишь один из этапов работы, а не её завершение.Сложности, с которыми мы столкнулисьОсобенность нашего эксперимента — организация предварительного тестирования. Перед запуском каждой атаки мы проверяли её работу на собственном аккаунте, чтобы убедиться в корректной отработке сценария на стороне пользователя. Такие проверки попадали в общую статистику системы и оказывали влияние на итоговые показатели. Возможность исключить подобные события из расчётов отсутствует. Согласно комментариям вендора, для этих целей следует использовать отдельный тестовый стенд. Поэтому мы вели дополнительно самостоятельный анализ результатов эксперимента.Отдельные сложности возникли на этапе обучения сотрудников. Завершить обучение в установленные сроки не удалось из-за человеческого фактора. Не все участники смогли своевременно пройти назначенные материалы, что потребовало увеличения периода обучения и дополнительного контроля за его прохождением.Впечатления от проекта команды «АМ Медиа»Проведение тестирования не вызвало негативной реакции со стороны сотрудников. Хотя фишинговые сообщения активно обсуждались внутри коллектива, жалоб руководству или недовольства вида «зачем вообще было устраивать такую проверку» не возникло. Основной интерес был сосредоточен вокруг самих писем и попыток понять, что именно происходит.Реакция сотрудниковОдним из самых любопытных наблюдений стала реакция сотрудников после первой волны первичного тестирования. Полученные фишинговые сообщения быстро стали предметом обсуждения: сотрудники пересылали их друг другу, задавали вопросы коллегам и пытались разобраться, что происходит.Некоторые пошли ещё дальше и вступали в переписку с отправителем, воспринимая фишинговые письма как реальные рабочие сообщения. Это наглядно показало не только убедительность используемых сценариев, но и то, что практическое столкновение с угрозой вовлекает сотрудников в тему ИБ гораздо сильнее, чем абстрактные примеры из учебных материалов. Во время повторного тестирования такой реакции уже не возникло.Реакция организаторовЕсли для большинства сотрудников тестирование выглядело как неожиданно появившиеся письма в почте, то для команды, которой было поручено тестирование Phishman 2.35 этот проект сопровождался совсем другими эмоциями. Подготовка сценариев, запуск атак и ожидание результатов вызывали ощутимое волнение. Оказалось, что смотреть на ситуацию глазами злоумышленника не так просто, как может показаться со стороны. Приходилось постоянно задавать себе вопросы: какой сценарий покажется правдоподобным, что привлечёт внимание сотрудника, а что, наоборот, вызовет подозрения.Самыми напряжёнными были дни первой волны тестирования. На этом этапе ещё не было понимания, как сотрудники отреагируют на рассылки, насколько убедительными окажутся сценарии и не вызовет ли проверка негативной реакции внутри коллектива. С каждой новой зафиксированной активностью интерес смешивался с тревогой, а результаты ожидались едва ли не с большим нетерпением, чем сам запуск кампании.После завершения эксперимента стало легче: всё задуманное удалось реализовать, результаты были получены и проанализированы. Тем не менее полностью избавиться от мыслей о проделанной работе не получилось. Время от времени возвращаешься к отдельным этапам и задаёшься вопросом: а стоило ли сделать именно так? Может быть, какой-то сценарий можно было построить иначе, а какие-то решения принять по-другому?Наверное, это естественная часть любого практического проекта. Когда работа заканчивается, появляется возможность посмотреть на неё со стороны и критически оценить собственные решения. Именно в такие моменты часто приходят идеи, которые помогают сделать следующие проекты лучше.Сотрудничество с вендоромВ ходе подготовки и проведения эксперимента иногда возникали вопросы, связанные с настройкой платформы, особенностями реализации отдельных сценариев и интерпретацией результатов. Для их решения использовались как переписка, так и рабочие созвоны. Запросы обрабатывались оперативно, что позволяло своевременно получать необходимую информацию и не допускать задержек в выполнении работ. Поддержка была доступна не только в рабочее время, но и в выходные дни.ВыводыПовторное тестирование показало, что тщательно подготовленные и персонализированные фишинговые атаки значительно эффективнее. При наличии качественной разведки злоумышленники способны подобрать убедительный сценарий практически для любого сотрудника. А если специалист может ошибиться, то сотруднику, который не занимается вопросами ИБ каждый день, сделать это ещё проще.Работа в сфере информационной безопасности или информационных технологий сама по себе не защищает человека от фишинга, социальной инженерии и других современных атак. Мы убедились в этом на собственном опыте: даже профильные знания не гарантируют, что человек не попадется на хорошо продуманную атаку. Злоумышленники постоянно меняют сценарии, поэтому знания, полученные однажды, быстро устаревают.При помощи эксперимента мы не только проверили, насколько сотрудники готовы распознавать атаки, но и поняли, как с помощью Phishman 2.35 можно сделать работу по развитию киберкультуры системной. Вместо отдельных курсов появился понятный цикл: смоделировать атаку, оценить реакцию, провести обучение и проверить, изменилось ли поведение участников. При необходимости — повторить или скорректировать процесс при помощи рекомендаций платформы. Результаты фиксируются автоматически, поэтому можно видеть, какие темы требуют больше внимания, и развивать киберкультуру на основе реальных данных, а не предположений.Читать далее
    • PR55.RP55
    • santy
      RP55, есть у тебя ТГ?
×