Эволюция потребностей и возможностей обработки логов в SIEM-системах не стоит на месте. И сегодня мы, Иван Прохоров, руководитель продукта MaxPatrol SIEM, и Петр Ковчунов, который пишет экспертизу для этого продукта, разберем наш ответ этому челленджу.

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

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

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

Логи о логах, или Небольшой экскурс в историю

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

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

Так на базе решений класса log management появились первые SEM- и SIM-системы, которые предоставляли базовые инструменты обработки данных для решения задач ИБ (базовые детекты, обогащения) и могли использоваться как ИБ-, так и ИТ-подразделениями.

Но эти первые SIEM-системы не решали задачи качественного real-time-детекта инцидентов внутри заданной инфраструктуры и повышения прозрачности для оператора происходящих в инфраструктуре событий ИБ.

Так появился полезный SIEM — решение, имеющее экспертизу и технологии обнаружения атак. Это решения, работающие исключительно «на детект». Те самые инструменты, которые позволяют сотрудникам подразделений ИБ и SOC обеспечивать мониторинг и менеджмент событий ИБ.

Решения этого класса являются сложными для использования и зачастую имеют высокий порог входа. А интеграции с внешними системами, позволяющие расширить функциональность SIEM и повысить эффективность работы оператора, упираются в сложность кастомизации под процессы обеспечения ИБ и низкую производительность. Один из таких примеров — анализ потока событий, собираемых с Windows, с использованием обогащения событий данными GeoIP и последующей корреляцией типа «подозрительный логин».

Каким должен быть результативный SIEM

Специалисты по ИБ постепенно осознавали свои потребности, и сама методология построения защиты значительно изменилась. Теперь наличие продукта, который позволяет детектировать и анализировать события, — лишь часть успеха.

На первый план вышли вопросы:

• понимания инфраструктуры, в которой необходимо строить ИБ;

• связи «источник данных — контроль данных — анализ данных — детект»;

• качественного, полного детекта и последующего реагирования;

• методологического построения и обеспечения ИБ.

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

Результативный SIEM обязательно содержит необходимый оператору контекст, то есть методологическую и экспертную помощь по каждому инциденту: почему система на него среагировала, какие меры нужно предпринять и как митигировать возможные риски. Кроме того, такой SIEM должен иметь возможность органично встраиваться в другие системы защиты, например интегрироваться с решениями класса EDR или выступать в роли сенсора метапродукта, такого, как наш MaxPatrol O2.

Все это мы вместе с коллегами постарались реализовать в нашем MaxPatrol SIEM, о котором теперь предлагаем поговорить подробнее.

Как происходит обработка событий

Предлагаю заглянуть под капот MaxPatrol SIEM и посмотреть, что там происходит и какие уникальные решения мы применили в нашей разработке. Схема довольно верхнеуровневая, но чтобы составить представление вполне подходит.

На схеме представлен пайплайн обработки событий в MaxPatrol SIEM. Обратим внимание на несколько аспектов. В первую очередь, у нас есть возможность организовать сбор как безагентского, так и агентского трафика. Это особенно важно с точки зрения того, что сбор данных оторван от процесса их обработки.

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

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

Итак, мы в общих чертах рассказали про пайплайн обработки событий и далее подробнее разберем этапы нормализации, обогащения и подключения источников.

Нормализация событий и объектно-ориентированная схема полей

Нормализация — это первый этап, с которым столкнется любое событие после детекта SIEM. Дело в том, что все сообщения об инцидентах поступают в систему в разных форматах и оформлены по разным стандартам. Чтобы провести анализ, их принято приводить к общему формату и виду, что и называется нормализацией. Чем этот процесс у нас отличается от того, что есть в других решениях?

Одна из главных особенностей заключается в том, что правила нормализации отделены от процесса сбора. Каким бы способом инцидент ни попал в MaxPatrol SIEM, если он подходит под правила, то будет нормализован. И сколько бы ни было таких источников в вашей инфраструктуре, все они будут отработаны.

Следующая особенность — объектная схема полей событий. Она позволяет с помощью формул нормализации размещать данные в абсолютно любом формате, из любых источников, с разной степенью «полноты». Причем инциденты не просто размещаются, а размещаются в удобном для аналитика виде. Как нам кажется, прозрачность и понятность для пользователя выгодно отличает нашу модель от популярного формата CEF. Например, по имени object.process.name уже можно понять, что речь идет об имени процесса объекта для данного события.

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

А так выглядит заполненная схема полей нормализованного события. Как видно, поля отсортированы по семантическому признаку: мы можем посмотреть на начало события, быстро определить четыре ключевых поля — subject, action, object, status — и понять, что случилось. Если же посмотреть на все события от начала до конца, то получим целостную картину инцидента.­­­­

Объектно-ориентированная модель или CEF?

Раз уж затронули эту тему, давайте попробуем разобраться подробнее. Конечно, можно сказать, что для базовых задач достаточно и формата CEF, а что дает объектно-ориентированная схема полей событий? Главное преимущество — она сокращает время на реагирование, потому что в ней нет огромного количества полей просто с ID сообщения, типа cs1 в CEF, который сам по себе ни о чем не говорит. И чтобы понять, с каким инцидентом имеешь дело, нужно посмотреть на лейбл (cs1Label), на действия и их спецификацию. Поскольку мы непосредственно отвечаем за подключение источников, можем с уверенностью сказать, что в случае CEF на это уходит огромное количество времени. С другой стороны, глядя на именованную схему данных, сразу понимаешь, что находится в поле и зачем.

Одно из ключевых преимуществ этой схемы, помимо ее организации, — большое количество полей типа Enum. Это значит, что у нас есть список предопределенных значений: например, у поля «статус» есть три предопределенных значения — «успех», «неудача» и «в процессе». Если мы захотим написать какое-то правило, то достаточно выбрать нужное значение из готовых вариантов. И даже при написании на языке eXtraction and Processing (XP) получается некий аналог кубиков — предопределенных значений. Чем больше у нас таких стандартных «кубиков», тем более простым и унифицированным получается весь процесс обработки событий, включая поиск, постобработку, аналитику и написание кода.

SIEM и написание контента

Для написания кода в нашей базе знаний есть три способа.

Язык XP. Мы пишем на языке собственной разработки — языке XP. Это наш внутренний DSL, который позволяет написать весь код SIEM, начиная от нормализации и заканчивая обогащением, корреляцией, агрегацией, табличными списками — всем, что у нас участвует в процессе обработки событий. Этот способ мы используем, когда нужно тонко настроить SIEM. Например, когда речь идет об XP-макросах, то есть предопределенных функциях, которые можно использовать бесчисленное количество раз без риска, что при редактуре или «копипасте» части данных нарушится весь процесс.

Специальный плагин для Visual Studio Code. Если вы предпочитаете работать в Visual Studio Code, у нас есть отдельный плагин, который позволяет быстро коммитить изменения, и красивое приложение с графической оболочкой PTSIEMSDK GUI, в котором вы можете писать и отлаживать код.

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

Инциденты ИБ и с чем их едят

Еще одна особенность MaxPatrol SIEM — это всеядность, возможность работать с событиями абсолютно любого формата. Если источник смог передать данные в систему, то SIEM в любом случае нормализует и обработает его. Например:

• Текстовая строка. События в формате произвольной текстовой строки типа Syslog или TEXT, которые будут разбираться с помощью токенов. Вам даже не придется реагировать на регулярные выражения.

• Табличные базы данных. Мы также поддерживаем события табличного формата. Ключевое слово TABULAR позволяет интегрироваться с абсолютно любыми данными, собранными SQL-запросом из базы.

• JSON. Формат JSON используется для интеграции с системами, которые могут передавать информацию о событиях по API.

• EventLog. Отдельный формат EventLog предназначен для интеграции со сложными многоуровневыми журналами Windows. Он позволяет упростить анализ и разбор событий, которые присылают продукты Microsoft.

• XML. Формат предназначен для интеграции с legacy-системами. Подойдет для компаний, которые еще не перешли на журналирование в более «трендовом» формате LOG или JSON. Он дает нам ту самую обратную совместимость: чем больше систем может поддержать наш SIEM, тем лучше.

Вы спросите, а что же делать, если через syslog приходят события, содержащие внутри себя JSON? По нашему опыту, такая ситуация возникает с «завидной» регулярностью, при этом существует несколько распространенных кейсов.

• Так происходит, например, когда в архитектуре системы есть форвардер — узел, в который приходят сообщения от разных источников. Он преобразует их в формат syslog и отправляет в SIEM — в результате события поступают в виде текстовой строки, в середине которой полезная нагрузка другого формата.

• Частый кейс — «общение» с облачными API. Только там все обычно наоборот: в SIEM приходит JSON, внутри которого вложена другая структура, например строка, которая описывает статус или ответ модуля.

• Более тяжелый случай — когда многоуровневые структуры вложены друг в друга. Например, поступает единый огромный JSON, внутри лежат события поменьше, которые содержат фрагменты данных для отдельного разбора.

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

Обогащение

Конечно, просто так мониторить нормализованные события — сложная и трудоемкая задача. Возникает и еще одна проблема: порой сам источник может прислать события, у которых не хватает контекста.

Представьте, что вы работаете с системой «1С», которая посылает вам алерты. Вы получаете уведомление о событии, что некий пользователь Windows совершил вход в «1С». У вас есть имя пользователя Windows и логин от «1С», но для всех дальнейших действий «1С» не логирует имя пользователя Windows. Вот тут механизм обогащения и помогает нам увидеть полную картину.

Здесь же срабатывает и real-time-реагирование. Каждый раз, когда пользователь входит в «1С», допустим под именем «администратор», данные о его учетной записи Windows записываются в табличный список и привязывается к аккаунту «1С». Пока не произойдет новый вход в систему и контекст не изменится в реальном времени, все действия от имени «администратора» будут принадлежать ему. Так мы сможем понять, кто и с какой машины создал платежный документ и, например, отследить удаленный вход.

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

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

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

Цепочки событий

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

Поэтому в MaxPatrol SIEM есть механизм формирования цепочек процессов, который при каждом старте процесса проверяет, существуют ли данные об этом процессе с соответствующим идентификатором и «родителем» в табличном списке. Если процесса там нет, он его туда дописывает и добавляет его в существующие цепочки. Так SIEM формирует цепочку запусков процесса и помещает ее в отдельное поле object или subject process chain.

Как такой подход работает на практике, мы разобрали на этом вебинаре, где рассмотрели конкретные примеры нашей работы с реальными кибератаками.

Вывод

Мы убеждены, что результативная SIEM-система начинается с обеспечения полноты и качества сбора данных о событиях. Так аналитик сможет сэкономить время и получить полноценную нормализацию, обогащение и генерацию детектов известных и неизвестных аномалий. Результативная SIEM-система базируется не только на статическом детекте известных атак, но и на обнаружении неизвестных атак и аномалий. Это система, способная подсказать действия, которые нужно предпринять после обнаружения инцидента. Но и это еще не все. Какие еще фишки продукта делают SIEM результативным решением? Об этом расскажем в наших следующих статьях.

Иван Прохоров

Руководитель продукта MaxPatrol SIEM, Positive Technologies

Петр Ковчунов

Руководитель группы базы знаний MaxPatrol SIEM, Positive Technologies