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

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

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

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

Дата публикации:
04.10.2022
Посетителей:
320
Просмотров:
285
Время просмотра:
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

Осторожно, CRM: как мошенники используют систему себе во благо

Виды уязвимостей процессов в CRM-системах. Требования к антифрод-системе для защиты CRM.

Новые приоритеты в информационной безопасности США

Трагические события, которые произошли в США 11 сентября 2001 года и повергли в шок весь мир, вновь напомнили человечеству об обратной стороне технического прогресса. Варварские террористические акты, совершенные группой террористов-смертников ...

Современные проблемы информационной безопасности

Проблемы информационной безопасности, разумеется, существуют не только в компьютерном, виртуальном, но и в реальном, «физическом» мире (хотя, конечно, там они не носят столь масштабный, всепроникающий характер). Любопытно и, на наш взгляд, ...

«Хакеры не работают с 9 до 18»: как прошел SOC-Форум 2022

Почему отрасли нельзя расслабляться? В какую сторону развиваются отечественные ИБ-решения? Кого будут атаковать уже завтра?

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

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

Сервер аутентификации Kerberos

Идентификация и проверка подлинности пользователей (аутентификация) — это основное средство защиты информационных систем от одной из главных угроз — постороннего вмешательства. Если у злоумышленника нет средств для нелегального доступа, возможности ...

Как использовать ИИ в компании, чтобы очарование не стало разочарованием

Нейросети стали рабочим инструментом бизнеса. Как использовать их с минимальными рисками — читайте в материале

Как мы делаем безопасность. Макрофреймворк ИБ «Модель Аэропорт»

Как мы строили ИБ раньше и почему теперь это не работает? Макрофреймворк по ИБ «Модель Аэропорт». Как работать с рисками катастрофических инцидентов ИБ?

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






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









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

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

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

      Спасибо!

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

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