Введение
Давайте представим, как могло бы выглядеть рабочее место SOC-аналитика будущего. В том числе рассмотрим, какие были бы полезны в реагировании и расследовании ML-помощники: некоторые из упомянутых в статье мы уже внедрили в наши продукты, а некоторые – еще в планах или могут послужить в качестве идеи для тех, кто сталкивается с подобными задачами.
Сначала рассмотрим, как чаще всего устроено рабочее место аналитика SOC. На самом деле в современном процессе управления инцидентами уже активно применяются доступные ИИ-помощники, упрощающие или ускоряющие работу.
К примеру, уже существует поведенческий анализ событий для выявления инцидентов за пределами правил корреляции. Это целый механизм, призванный дополнить сработки от SIEM там, где простым правилом не обойтись. Таким образом, среди одних и тех же событий получается находить инциденты различными способами.
Также в повседневной работе сотрудники SOC все чаще прибегают к помощи ИИ, когда нужно написать правило корреляции или нормализации. Такие запросы нужны обычно в двух случаях: когда понятно, что делать, но проще и быстрее объяснить, что должно получиться, чем написать сам код, а также когда работа слишком рутинная.
И, наконец, LLM для рекомендаций. Скорее всего, в каждой компании есть такой человек, который прибегает к помощи чат-бота, если ему требуется написать простенький скрипт или задать вопрос по расследованию.
No-code
Начнем с того, в какой среде работают аналитики: это может быть как консоль, так и веб-интерфейс одной или нескольких СЗИ. На наш взгляд, правильно и понятно отображать всю информацию и весь инструментарий в платформе единого окна, чтобы, с одной стороны, консолидировать всю информацию в одном месте, а с другой – упростить для аналитика управление другими системами. В том числе, при помощи no-code.
Применение No-code инструментария позволяет упростить работу сразу в трех направлениях:
Предоставляет прозрачность применяемых настроек, к примеру, правил корреляции, сценариев реагирования. Сразу можно понять, как оно будет работать и правильно ли.
Оперативность внесения изменений в правила корреляции и нормализации, сценарии реагирования. Часто на этапе постинцидента приходится вносить правки, чтобы скорректировать логику выявления инцидентов и уменьшить количество false-positive.
Снижение порога входа и легкость настроек – не нужно дополнительно изучать синтаксис и языки программирования. Таким образом, аналитик занимается расследованием и реагированием, а не разработкой.
Ограничения применения ИИ-помощников
Когда мы упростили для специалиста работу над инцидентами с визуальной точки зрения, стоит поговорить об ассистентах, которые могли бы помочь аналитику и ускорить расследование.
Какие существуют ограничения и условия добавления помощников в работу? Нам обязательно нужно учесть перед внедрением специфику каждого заказчика по отдельности.
Во-первых, сама заложенная экспертиза должна соответствовать тому, что есть у конкретного заказчика: какие выстроены процессы, в каком формате работает команда и с какими ограничениями. Мы считаем обязательным дообучение ML-моделей на территории заказчика и на его данных.
Вендор может заложить как свою экспертизу, так и best practices из международных стандартов. Дообучение необходимо также для того, чтобы ответ от ML-помощника был релевантным и актуальным, таким, чтобы его можно было сразу применить на практике.
Помимо этого, применение ML-решений в SOC накладывает дополнительные ограничения: при работе on-prem самое главное качество модели – это ее автономная работа, так как рядом уже не будет ML-специалиста, который мог бы эту модель оперативно скорректировать. Все равно тюнить модель приходится, даже если модель стабильно работает на большом отрезке времени, никто не застрахован от появления нерелевантных ответов. Причиной таких проблем могут быть изменения в структуре трафика, структуре данных, самой инфраструктуре. Тогда модель, если ее не актуализировать, может даже навредить работе SOC. Очень важным становится функционал по автоматическому отключению модели, по ее автоматическому дообучению на стороне заказчика.
С нашей стороны мы уделяем много внимания как раз автоподбору гиперпараметров: когда модель сама использует определенные алгоритмы для переобучения в заданных диапазонах, подбирая оптимум по итоговому результату на основе ретроспективы, чтобы дальше продолжить делать свою работу более качественно, адаптируясь к изменениям.
Основные проблемы
Когда мы говорим о том, что нам нужен помощник, необходимо начать эту историю с обсуждения текущих проблем и недостатков автоматизации или функционала СЗИ.
Во-первых, это огромный поток инцидентов. При тестировании пула корреляционных правил объем новых сработок может быть таким, что аналитик попросту не успеет не то что расследовать их, а даже отсмотреть каждый. В целом может быть много сработок от СЗИ – если есть зоопарк решений или еще не отлажена работа какого-то конкретного продукта. Нужно как-то дать понять аналитику, как ему приоритизировать эти инциденты, а на какие и вовсе не требуется обращать внимания.
Во-вторых, повторяющиеся кейсы. Независимо от того, внутренний ли у вас SOC или MSSP, с течением времени ваши системы будут выявлять инциденты, которые друг на друга чем-то похожи или даже будут одинаковыми. Здесь нельзя исключить человеческий фактор – что-то могут забыть донастроить, не сделана какая-то задача в рамках харденинга – и вот SOC получает пачку инцидентов об одном и том же до тех пор, пока кто-то не исправит ошибку. Важно еще заметить, что команда аналитиков в этом процессе – величина непостоянная, и каждый раз обновленный или старый состав будет пытаться вспомнить или найти в истории, что делали с такими инцидентами год, два назад, что с инцидентом сделал вчера один сотрудник, чтобы второй мог сегодня это успешно повторить. Было бы здорово, если бы эта информация агрегировалась и можно было бы каждый раз получать релевантные подсказки в ходе реагирования.
И, наконец, в-третьих, стоит проблема накопления экспертизы в формате единой базы знаний. Задача – собрать всё лучшее, все наработки, хорошие решения, действия по реагированию за весь период времени и понять, как SOC реагировал и почему.
Отдельным пунктом отметим такую задачу, как поиск и выявление новых видов атак. Иногда это приходится делать вручную, иногда потоки событий отсматривают целые экспертные центры, а автоматизация и привлечение ИИ в этом случае помогла бы распределить ресурсы более эффективно.
Мы подобрали 11 сценариев того, как ML-помощники помогли бы справиться с упомянутыми задачами, и все они здесь не просто так – у нас появилась целая концепция для этого, мы предлагаем встраивать помощников на каждом этапе расследования.
Перед вами скомбинированный процесс управления инцидентами на основе методологий NIST и SANS. Далее мы детально пройдемся по каждому из этапов.
Этап: подготовка. Нормализация событий источников
Здесь мы решаем задачу, с которой сталкиваются многие SIEM и не только вендоры в процессе интеграций: необходимость быстро и корректно нормализовать поток данных от нетипового источника. Это может быть как самописное ПО от заказчика, так и такой источник события, который в лог пишет что-либо в человекочитаемом формате – аналитику это понятно, а вот при попытке автоматизировать парсинг возникают проблемы.
Было бы полезно, если бы мы могли обучить ИИ-помощника, который сразу бы распарсил данные под атрибуты правил корреляции.
Этапы: подготовка, анализ/обогащение. Классификация и кластеризация пользователей и устройств
При решении задачи кластеризации наша цель заключается в том, чтобы сгруппировать объекты – к примеру, хосты или учетные записи – для получения дополнительного контекста для инцидента. Это может в том числе подсветить инциденты, активные для той группы, элементы которой сейчас задействованы в расследовании.
В зависимости от полученных результатов, мы можем управлять такими критериями инцидента, как массовость и критичность. Частично эта информация может уже находиться в сервисах каталогов, но не всегда она актуальна на момент запроса. К тому же, недостаточно провести кластеризацию единожды, нужно повторять этот процесс, чтобы учесть текущее состояние инфраструктуры. Здесь важна стабильность кластеров, чтобы при каждом изменении и появлении новых ассетов, уже распределенные не начали хаотично перемещаться между кластерами.
Решение этой задачи может стать дополнительным элементом для других моделей – к примеру, для рекомендательной системы.
Этап: подготовка. Скоринг активов
Если говорить о получении дополнительного контекста для активов, можно добавить ИИ-помощника для их приоритизации. Например, аналитик работает с инцидентом, в котором задействован какой-либо хост или учетная запись; аналитику нужно быстро понять, что он может делать с этими активами в части реагирования, какие действия ему доступны. Может быть это очень важный хост, с которым вообще ничего делать нельзя, особенно перезагружать или выключать на время.
Получается, задача в том, чтобы рассчитать приоритет актива в соответствии с текущей инфраструктурой и контекстом инцидента.
Как алгоритм расчета можно применять классический PageRank, но только в качестве веса использовать многофакторную модель либо получать результаты от другой модели – например, деревьев – которая заданным образом учтет критичность актива, его КЦД, установленную систему. В результате мы получаем скор, который может быть динамическим: в процессе расследования инцидента его можно учитывать для того, чтобы спрогнозировать маршрут нарушителя в контексте расследуемого инцидента или цепочки инцидентов. Подобный скоринг позволит вам определить, на что требуется обратить внимание в первую очередь, будь то актив или группа активов.
Этап: обнаружение. Детектирование типовых атак и аномальных событий
Многие вендоры уже применяют ML-модели для поиска аномалий в трафике. Но на самом деле реализовано еще далеко не все, что можно было бы использовать.
Для типовых атак работают классические деревья и бустинги; особенность в том, что работаем мы не с инцидентами, а с первичными событиями от объектов инфраструктуры. Только на таком потоке у нас есть возможность определения таких атак как, например, C2 и botnet.
Что касается аномалий, классической задачи для ML, мы активно пользуемся и опорными векторами, и isolation forest, отличие опять же в том, что работа ведется с сырыми событиями, теми, которые приходят до корреляции.
Этап: анализ/обогащение. Определение FP и TP
Большой блок проблем для аналитика SOC составляет информационный шум. Ему не понятно, что важно, а чем можно пренебречь.
Для решения этой задачи понадобится ML-помощник, который будет определять – инцидент скорее false positive или true positive, основываясь на ранее сделанных аналитиком выводах. Это поможет отсеять инциденты, пришедшие потоком в результате тестирования правил корреляции, так и сгенерированных вследствие мисконфигов и других некорректных настроек ПО, о которых аналитики знают, но в данный момент эта проблема не может быть решена. Таким образом, останутся только те инциденты, которые действительно важны.
К тому же, такая система маркировки инцидента поможет не пропустить сработку, которую аналитик на автомате пометил бы как FP – например, из-за задействованного там привычного хоста. ML-помощник в такой ситуации, определив, что инцидент достоверен, повышает уровень вероятности TP, увеличивая приоритет.
Здесь задействована одна из самых популярных моделей, которую не сложно реализовать – также подходят бустинговые алгоритмы; особенность в том, что для накопления репрезентативной выборки может потребоваться определенное время – только когда у вас в SOC будет достаточно как FP, так и TP инцидентов, размеченных вручную, тогда можно рассчитывать на релевантный результат работы модели.
Только после того, как результаты показали себя как достоверные, можно добавлять к метке от ИИ-помощника какую-либо автоматизацию; во время подготовки данных метка будет носить сугубо информационный характер.
Этапы: анализ/обогащение, реагирование. Поиск схожих инцидентов
Мы определили для себя три вектора возможной связи инцидентов: выявление паттерна злоумышленника, выстраивание цепочки атаки и наследование рекомендаций.
В случае с определением модели поведения злоумышленника мы опираемся на факт того, что будь то хакерская группировка или отдельный человек, определенный «почерк» при работе в вашей инфраструктуре все равно будет прослеживаться. ML-модель могла бы, проанализировав действия, которые выполнил атакующий, определить стиль этой атаки; таким образом, атака, которая произошла например год назад может быть связана с той, которая происходит прямо сейчас.
Также мы разными способами решали задачу макрокорреляций и выстраивания инцидентов в Kill Chain – связи инцидентов по цепочке атаки, которую можно было бы расследовать сразу в целом, а не пытаться реагировать на несколько разрозненных инцидентов.
И, в конце концов, когда мы понимаем, что инциденты схожи, мы и реагировать на них можем схожим образом, если это принесло пользу в прошлом.
Как реализацию мы используем две полярные истории: мы можем взять инцидент, выделить из него ключевой контекст, создать из него вектор и выделить из этого косинусную близость, либо, наоборот, сформировать всю информацию как краткое саммари и дальше решать эту задачу как задачу выявления схожести текста между собой.
Этап: анализ/обогащение. Скоринг инцидентов
Точно так же, как нам понадобилось ранжировать активы для понимания ограничений работы с ними, нам важен скоринг инцидентов.
К примеру, вчера вы расследовали инцидент, в котором стал недоступен сайт вашей организации. Допустим, вы – компания-заказчик, а на сайте как раз находится ваш магазин. В контексте вчерашнего дня инцидент серьезный, и нельзя допустить долгий простой, следовательно, такой инцидент мы расследуем в первую очередь.
Но сегодня все меняется, и этот инцидент приходит среди тех, в которых есть сработки DDoS, следовательно, приоритет первого инцидента должен снизиться, так как фокус внимания смещается на корень проблемы.
ИИ-помощник в данном случае должен определять степень важности инцидента на основе совокупности его характеристик, атрибутов, связанных с ним объектов и окружения.
Здесь можно привести аналогию из другой сфера: в целом, скоринг инцидента ничем по сути не отличается от скоринга людей, который применяется в процессе выдачи кредитов или регулировании убытков при страховых случаях; при достаточной степени обучения деревьев и их детализации, как и в этих сферах можно применить автоматизацию и выполнять ряд действий, если скоринг-модель достаточно обучена. При этом показатель доверия достаточен для того, чтобы модели верить.
Этап: реагирование. Цифровой слепок, поиск по базе знаний
Помимо того, что мы можем воспользоваться результатами работы ML-моделей, мы также предлагаем идею того, чтобы сформировать полноценный цифровой слепок SOC-аналитика. Мы могли бы взять или компетентного аналитика, знающего, как расследовать инциденты именно в вверенной ему инфраструктуре, или целую SOC-команду, успешно расследующую инциденты, и сформировать интерактивного помощника, в котором и собрали бы все эти навыки и знания. Так получится и сохранить у себя экспертизу аутсорс-SOC, если вы обращались за их услугами на определенное время, и подстраховать себя на случай потери ключевого специалиста.
Для создания виртуального помощника потребуется собрать базу знаний о том, как инциденты расследовались, как происходил поиск дополнительной информации, какие действия выполнялись и тому подобное. К такому виртуальному аналитику можно было бы обращаться как за подсказкой по реагированию, так и автоматизировать реагирование на основе собранных данных.
Этапы: реагирование, постинцидент. Экспертные рекомендации
Продолжая тему базы знаний, таким же образом можно составлять экспертные рекомендации по инциденту.
Если у нас имеется база расследованных инцидентов заказчика, реагирование по которым успешно завершено, мы можем для схожих инцидентов подбирать те шаги, которые повторялись наиболее часто. К сожалению, в процессе работы не получается быстро поменять плейбук или вовсе пересмотреть алгоритм реагирования; чаще всего такие изменения придется проводить через цепочку согласований и изменений, теряя время. Причем мы можем как воспользоваться историческими данными заказчика, чтобы дать персонализированные рекомендации, так и составить их на основе тех же best practices для более универсального коробочного решения.
Помимо того, что плейбуки в принципе устаревают, они еще и не могут быстро адаптироваться под изменения в инфраструктуре или кадровом составе – когда, например, появляется новое звено эскалации.
А ML-модель может автоматически отслеживать эти изменения в фоновом режиме и подстраивать рекомендации под текущую ситуацию.
С точки зрения реализации здесь также применяются деревья и бустинги. Обучение может проводиться как на внутренней экспертизе, так и на внешней. Предобученные на open source или внешней экспертизе модели должны экстраполироваться на заказчика, здесь применяются различные алгоритмы, для того, чтобы растянуть датасеты с портами или IP-адресами на инфраструктуру заказчика. Это актуально и для первичного использования модели, и для дальнейшего ее обучения и переобучения.
Этап: постинцидент. Отчетность и краткая сводка
Предположим, что заказчик применяет в работе всех разработанных нами ИИ-помощников. Что дальше?
Информационный шум исчез, аналитики заняты своей работой, и мы переходим к этапу формирования отчетности. Даже если поток нерелевантных инцидентов снижен, объем требующих расследования инцидентов все еще может оставаться большим.
Ни одному человеку не под силу быстро и без потери качества просмотреть подробно все инциденты SOC и действия по реагированию и сразу же оценить, насколько эффективно этот SOC работает, сколько пользы и инцидентов приносят СЗИ и насколько они задействованы на этапе сдерживания.
Задачей модели в данном случае будет предоставление краткой сводки по результатам расследования инцидента – по одному или сразу нескольким, а также проведение стратегического ревью всего происходящего в SOC.
Этап: постинцидент. Обновление плейбуков и правил корреляции
Самый последний этап в процессе управления инцидентами – это работа над ошибками. В процессе этой работы может потребоваться поменять правила нормализации, корреляции и сами плейбуки.
Если говорить о плейбуках, требуется определить, какие действия аналитики выполняют чаще для групп похожих инцидентов, какие появились новые инструменты, а какие совсем перестали использовать со временем.
Ручная реализация такого запроса занимает сравнительно много времени. В этом случае ИИ-помощник сам мог бы понимать, как ему нужно перестроить сценарий реагирования и предоставить рекомендации.
То же самое и с правилами корреляции – допустим, модель понимает, какие параметры правила вызывают больше всего FP – например, в связке с моделью, выявляющей эти ложные сработки. Здесь мы тоже могли бы предоставлять рекомендации по тюнингу правил.
Представьте, что у вас работает Red Team или вы наняли проведение внешнего пентеста. В процессе их работы вы фиксируете все, что делала команда пентеста: события, действия. Одновременно с этим параллельно формируется список инцидентов в результате этих атак. И ИИ-помощник мог бы, посмотрев на два этих набора данных, самостоятельно составить правила корреляции, которые были бы релевантны именно для вашей организации.
Для решения этой задачи есть два пути: с одной стороны, модель может смотреть на те действия, которые выполняет аналитик, по каким веткам он ходит или не ходит. При определенном контексте инцидента модель может убирать неиспользуемые ветки. Или, наоборот, автоматизировать те ветки, которые безусловно выполняются по достижении определенного набора параметров. С другой стороны, мы можем принять на вход весь поток событий от Red Team, телеметрию с устройств, оборудования, трафика, и заложить это автоматически в правила корреляции. Также мы смотрим на те действия, которые могут в том числе выполняться Blue Team вручную, и на основе этого собираем композитный плейбук по реагированию. Главное, чтобы модель могла достичь уровня уверенности в том, что действия являются безусловными или заложить это как ветки в сценарии реагирования.
Вместо вывода. Возможный роадмап для ML-помощников
Когда мы говорим о том, что ассистенты, безусловно, должны появиться и упросить нам работу, нужно также подумать о том, к чему мы уже готовы, а с чем стоит повременить. Рассмотрим предполагаемый роадмап внедрения помощников в SOC в зависимости от его уровня зрелости.
Первым шагом было бы логично избавиться от визуального шума и настроить пул инцидентов так, чтобы было сразу понятно, какие из сработок нужно расследовать в первую очередь:
Поиск аномальных событий;
Нормализация событий;
Определение FP и TP;
Скоринг и классификация ассетов, инцидентов и атак;
Поиск похожих инцидентов и паттернов в событиях.
Когда мы научились работать со старыми атаками, время переходить к новым. Здесь же уже можно накапливать полноценную базу знаний по расследованным инцидентам.
Детектирование типовых атак;
Экспертные рекомендации;
Поиск по базе знаний;
Корректировка плейбуков;
Отчетность и краткая сводка.
В самом конце, когда прошлые шаги пройдены, можно уже задуматься о том, чтобы воссоздать работу аналитиков в виде полноценной модели-помощника.
Корректировка правил корреляции;
Цифровой слепок.
Надеемся, что наши наработки в части ML-помощников действительно смогут упростить и ускорить работу аналитиков SOC, став надежным подспорьем в расследовании.
Со своей стороны, мы всегда были и остаемся нацелены на то, чтобы найти способ или несколько для решения актуальных проблем, будь то высокий порог входа для аналитиков или нехватка времени на обработку большого потока данных. И, скорее всего, если закрыть все проблемы, упомянутые в этой статье, скоро мы столкнемся с новыми вызовами.
