Какие факторы негативно влияют на ИБ-расследования?
Как выглядит типовое расследование?
Зачем нужны и как работают 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 используют эти данные, чтобы эффективнее находить следы атак на хостах», — добавил Кирилл.