Главные тезисы о XDR системах на Mobile Forensics Day 2022
Информационная безопасность Информационная безопасность

Какие факторы негативно влияют на ИБ-расследования? Как выглядит типовое расследование? Зачем нужны и как работают XDR-системы?

Главная>Информационная безопасность>Mobile Forensics Day 2022: фокус на XDR
Информационная безопасность Тренд

Mobile Forensics Day 2022: фокус на XDR

Дата публикации:
04.10.2022
Посетителей:
344
Просмотров:
303
Время просмотра:
2.3

 

Какие факторы негативно влияют на ИБ-расследования?


Как выглядит типовое расследование?


Зачем нужны и как работают XDR-системы

 

 

15 сентября в Москве прошла шестая ежегодная конференция Mobile Forensics Day 2022. Вендоры, интеграторы и представители бизнеса собрались в отеле «Вега Измайлово», чтобы поговорить о современных трендах в расследовании ИБ-инцидентов. Среди актуальных вопросов, поднятых на конференции, стоит выделить тему внедрения XDR-систем. О набирающем популярность классе решений рассказывал Кирилл Черкинский, менеджер по развитию и продвижению продуктов Positive Technologies.

Кирилл начал выступление с небольшого опроса. «Кто в зале в принципе слышал об XDR? (-несколько человек поднимают руки-). Негусто… А кто понимает, как эти системы работают? (-руки не поднимает никто-). Окей, через 15 минут у вас появится понимание, что это такое».

Что мешает расследованиям

 

По словам спикера, существуют 3 фактора, которые чаще всего мешают компаниям успешно проводить ИБ-расследования.

 

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

 

Второй фактор — отсутствие экспертизы. С этим особенно часто сталкиваются небольшие компании, для которых ИТ и тем более ИБ — не основной профиль деятельности. У них не так много средств защиты и маленькие ИБ-команды, которые решают дженерик-задачки. Расследования — просто не их профиль. Но и у крупной компании, увешанной ИБ-инструментами как новогодняя елка, все равно может не хватить экспертизы, чтобы разобраться в инциденте. Зачастую ИБ-специалисты по незнанию пропускают полезную информацию и не обращают внимания на дополнительные данные, которые могут помочь в расследовании.


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

Как выглядит типовое расследование

 

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

 

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

 

«Отдельно отмечу, что расследования — это дорого. Последние годы рынок испытывает острую нехватку кадров, и проблема не уходит. Современному SOC требуется несколько линий аналитиков с хорошими скиллами плюс команда форензеров, исследователи malware, threat hunter’ы и т.д. Все эти люди стоят дорого, а SOC должен работать 24/7, поэтому бюджет получается действительно большой. Заказчики далеко не всегда готовы столько тратить», — добавил Кирилл.


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

Как работают XDR

 

По сути, XDR — это «расширенная версия» EDR-платформ. Само «расширение» происходит за счет того, что системы защиты, которые работают с агентами, могут интегрироваться с другими классами решений и обмениваться с ними информацией. Это могут быть сетевые сенсоры, песочницы и др. Все это позволяет глубже изучать данные и процессы в инфраструктуре и насыщать их дополнительной полезной информацией.

 

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


У XDR-решений есть агенты и серверная часть. Агенты устанавливаются на разные элементы инфраструктуры —рабочие станции, серверы и т.д., из которых система будет собирать данные. Это могут быть логи, конкретные события, отдельные файлы, которые надо проанализировать. За счет интеграции с песочницей все подозрительные файлы можно спокойно анализировать в лабораторных условиях — без лишнего «шума», который создают пользователи.


«Давайте разберемся, в чем разница между анализом в песочнице и на хосте. Во-первых, вы не сможете повесить в агент на хосте много механизмов по обнаружению угроз, поскольку для этого потребуется слишком много ресурсов. Агент XDR будет единственным, что можно на нем запустить. В песочнице механизмов гораздо больше, плюс там нет фонового шума от пользовательской активности. Соответственно, можно спокойно посмотреть, чем файл занимается при запуске, куда лезет, что читает, пишет, скачивает ли что-то из сети, — добавил Кирилл. — Файлы берутся с хостов, отправляются в песочницу на анализ, по итогу мы получаем вердикт и исходя из него можем автоматически блокировать вредоносы. Причем не на одной конкретно взятой машине, а во всей инфраструктуре — на всех подключенных агентах. Простой пример. Кто-то из сотрудников приходит в офис пораньше, наливает кофе и скачивает нехороший файл. Песочница оперативно помечает его как угрозу, и индикатор компрометации расшаривается сразу на все хосты. Благодаря этому в дальнейшем файл будет автоматически удаляться из файловых систем сотрудников».

 

В части реагирования XDR-решения позволяют выполнять базовый набор действий: удаление файлов, завершение процессов, изоляцию хостов, блокировку пользователей и др. Все волшебство заключается в логике и правилах, на основе которых автоматически принимаются все эти решения. К примеру, в XDR-системе Positive Technologies есть корреляционный движок из SIEM, «пересаженный» на хосты. За счет корреляционных механизмов и множества экспертных правил система может обнаруживать и сразу блокировать самые разные атаки прямо на устройствах пользователей.


«Здесь мы переходим к разнице между XDR и SOAR. Оба класса систем заточены на автоматизацию реагирования на угрозы, но у SOAR нет аналитических движков. Они не могут самостоятельно обнаруживать атаки и полагаются на данные, которые им отправляют другие средства защиты, а в дальнейшем отвечают за оркестрацию. Проще говоря, в них заложены определенные плейбуки, которые нужно запустить. Здесь появляется временной лаг: события идут в SIEM, коррелируются, перемещаются в SOAR и только после этого начинается реагирование. У XDR все происходит в моменте, что заметно повышает скорость ответной реакции. Причем сценарии автореагирования определяются гибкими политиками: при внедрении системы и подключении агентов мы заранее настраиваем, с какой логикой будет работать конкретный агент. Где-то можно реализовать только обнаружение, где-то обнаружение плюс реагирование и т.д.», — прокомментировал Кирилл.

 

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

 

«XDR-системы поддерживают и ручной режим реагирования. Оператор службы безопасности может самостоятельно выполнять необходимые действия за счет всевозможных “крутилок”. Другой важный плюс подобных решений — возможность интеграции с внешними и внутренними платформами Threat Intelligence, аккумулирующими знания об угрозах. XDR используют эти данные, чтобы эффективнее находить следы атак на хостах», — добавил Кирилл.

Читайте также

Пара слов об XDR

О контентной фильтрации (продолжение темы Jetinfo №8 (2006))

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

Киберучения: от сценарного подхода до платформы киберразвития

Киберучения позволяют комплексно подойти к развитию карьеры, точечно проработать hard&soft skills. Специалист «не на своем месте» вредит бизнесу. На киберучениях такие сотрудники видны лучше всего.

Как организовать Threat Hunting

Когда и зачем нужно проводить Threat Hunting? Как SIEM может помочь во время “охоты”? Кейс: выдвигаем и проверяем гипотезу?

Интервью Алексея Комкова, Технического директора компании "Лаборатория Касперского"

Интервью Комкова Алексея, технического директора компании "Лаборатория Касперского" информационному бюллетеню "Jet ...

Кто виноват и что делать: о чем спорили участники форума DLP+

Как государство мотивирует бизнес защищать информацию клиентов? Кто должен нести ответственность за утечки? Что общего у производителей топоров и DLP-систем?

Блокирование технических каналов утечки информации

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

Хорошая безопасность работает с людьми

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

DLP-отношения: от рабочей рутины до судебных процессов

Кто кому должен: обязанности компаний и сотрудников? Как регламентировать работу с конфиденциальной информацией? DLP-кейсы: почему компания может проиграть дело? Чек-лист: как оформлять данные из DLP для судебного разбирательства?

Дополнение к руководству по информационной безопасности предприятия: как выбирать поставщика интернет-услуг

Данное Дополнение к Руководству по информационной безопасности предприятия (см. также Jet Info, 1996, 10-11 – прим. перев.) призвано служить для широкой Интернет-общественности контрольным перечнем при обсуждении вопросов информационной ...

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал






    Спасибо!
    Ваш вопрос отправлен.
    Мы с вами свяжемся
    Задать вопрос
    редактору









      Оставить заявку

      Мы всегда рады ответить на любые Ваши вопросы

      * Обязательные поля для заполнения

      Спасибо!

      Благодарим за обращение. Ваша заявка принята

      Наш специалист свяжется с Вами в течение рабочего дня