Это вторая статья цикла, который посвящен методологии создания работающих «из коробки» правил корреляции, для SIEM-систем. В предыдущей статье мы поставили перед собой данную задачу, описали преимущества, которые будут получены при ее выполнении, а также перечислили основные проблемы, стоящие у нас на пути. В этой статье мы приступим к поиску решений и начнем с проблемы трансформации модели «мира», а также ее проявления на этапе нормализации событий.
О проблеме трансформации модели «мира» было рассказано в первой статье. Коротко напомним ее суть: при возникновении какого-то явления на источнике событий (например, запуск процесса в ОС) происходит его фиксация в разных форматах сначала в памяти, затем в журнале событий ОС и далее — в SIEM-системе. Каждая стадия обработки сопровождается потерей данных, так как на уровне ОС — одна модель «мира», а в журнале ОС — другая, ограниченная набором полей — схемой журнала. Таким образом, происходит отражение (трансформация) одной модели с большим числом параметров в другую, с меньшим их числом. Нормализация и сохранение события в SIEM — это еще одна трансформация, которая также происходит с потерей данных, так как и внутри SIEM заложена собственная модель «мира».
Сложно найти способ, который бы позволил проводить трансформацию одной модели в другую без потерь. Зная это ограничение, необходимо сформулировать такой подход к нормализации и формированию перечню полей схемы событий, при котором не терялась бы информация, важная при корреляции и дальнейшем расследовании инцидентов ИБ.
В рамках SIEM модель представлена схемой — набором полей, в которые в процессе нормализации укладываются данные из исходного события. В дальнейшем именно она будет использоваться специалистами при создании правил корреляции. Чтобы специалисты по расследованию инцидентов и ответственные за разработку правил корреляции однозначно трактовали нормализованные события, схема должна удовлетворять основным свойствам:
В процессе разработки правил нормализации информацию о взаимодействии необходимо найти в исходном событии и разложить ее в специально отведенные поля. То же самое необходимо сделать с контекстом и сутью взаимодействия (подробнее об этом — в следующей статье).
Возникает вопрос: возможно ли выделить типовые схемы для взаимодействий, которым бы удовлетворяли любые события, создаваемые всеми возможными ИТ и ИБ-источниками? Если да, то как выглядят эти схемы?
Для поиска ответа на эти вопросы необходимо обратиться к аналитике и постараться проанализировать как можно больше уже разработанных и функционирующих в SIEM-решениях правил нормализации для выявления общих закономерностей. В рамках таких работ удалось провести анализ более 3000 правил нормализации от более чем 100 различных источников из таких решений, как Positive Technologies MaxPatrol SIEM и Micro Focus ArcSight. В результате анализа были получены следующие выводы:
Опишем типовые схемы для каждого уровня. Перед этим нужно выделить сущности, которые всегда присутствуют в событиях. Далее на их базе и будут построены схемы взаимодействия. К ним относятся:
Однако не все сущности могут быть одновременно представлены в событии (об этом далее), поэтому важно изначально ввести соглашения, как в таком случае заполняются соответствующе поля схемы. Это поможет в дальнейшем явно отличать случаи, при которых эти поля не были заполнены из-за ошибки специалиста, разрабатывающего правила нормализации, от случаев, при которых в исходном событии действительно не содержалось данных о какой-либо сущности.
Перейдем к схемам взаимодействия и примерам событий. Для наглядности все примеры будут приведены на базе файловых логов, сообщений syslog или записей в реляционной базе, но они могут применяться и для других форматов логов, например, бинарных.
Основной идентификатор сущностей сетевого уровня — IP-адреса. При этом важно понимать, что могут быть и иные связанные идентификаторы — MAC-адреса на канальном уровне, FQDN — на прикладном. Возникает вопрос: они говорят об одной и той же сущности или о разных? Могут ли у одной и той же сущности меняться эти идентификаторы со временем? Этому будет посвящена отдельная статья, сейчас остановимся на том, что основной идентификатор для моделей взаимодействия на сетевом уровне — IP-адрес.
Итак, типовые схемы взаимодействия этого уровня можно условно разделить на два класса — основные и вырожденные.
Схема 1.Полная схема взаимодействия
В рамках данной модели в событии, поступившем на вход SIEM, можно выделить все основные сущности: Субъект, Объект, Источник, Передатчик. На схеме взаимодействия Субъект воздействует на Объект. Это воздействие регистрирует (наблюдает) Источник и порождает событие. Событие от Источника поступает в Передатчик и с него попадает в SIEM.
Событие ниже фиксирует разрешение сетевого взаимодействия между хостами межсетевым экраном Stonesoft (ныне — Forcepoint), при этом само событие поступает в SIEM не напрямую, а от промежуточного syslog-сервера.
Здесь:
40.0.0.1 — Передатчик (промежуточный syslog-сервер),
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).
Схема 2.Схема прямого сбора без передатчика
Далеко не всегда в схеме взаимодействия есть Передатчик. Как правило, он присутствует, когда для передачи событий используется промежуточный сервер (например, syslog-сервер), или когда у решения, с которого собираются события, есть централизованная система управления — например, Kaspersky Security Center, Check Point Smart Console или Cisco Prime. По этой схеме события попадают в SIEM напрямую из Источника. Большая часть всех событий описывается именно этой схемой. Кстати, пример такого события можно увидеть в схеме 1, если бы в ней отсутствовал промежуточный syslog-сервер и мы получали события напрямую от межсетевого экрана.
Здесь:
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).
Схема 3. Взаимодействие с множеством Объектов
Эта схема взаимодействия на уровне сети встречается достаточно редко и, как правило, характерна для событий сетевого оборудования. В схеме один Субъект взаимодействует со множеством Объектов, подобное взаимодействие присутствует в событиях, описывающих multicast, unicast или broadcast рассылки.
Отметим, что иногда множество Объектов могут быть объединены общим идентификатором — адресом подсети или широковещательным адресом. Это нужно помнить, так как при анализе событий, в том числе и на уровне правил корреляции, легко можно пропустить потенциально важное взаимодействие, так как в такой схеме адрес Объекта сокрыт за групповым адресом.
Следующий пример демонстрирует событие с IGMP Relay сервера, через который транслируется запрос принадлежности к групповому адресу.
Здесь:
30.0.0.1 — Источник (IGMP Relay сервер),
10.0.0.1 — Субъект (запрашивающий принадлежность к группе),
224.0.0.252 — Объект (групповой адрес).
Субъект, Объект и Источник — базовые сущности в группе основных схем взаимодействия. Однако нередки случаи, когда в событии одна из сущностей может отсутствовать.
Схема 4. Взаимодействие без Объекта
Зачастую такая схема характерна в ситуациях, при которой Субъект сообщает об изменении своего внутреннего состояния — то есть он выступает одновременно в роли Субъекта и Объекта. Например, такое взаимодействие можно наблюдать в событиях изменения конфигурации или обнаружения вредоносного ПО на рабочей станции. Но эту информацию фиксирует не сам Субъект, а централизованная система управления и сохраняет в своем журнале.
В примере показано, как сервер управления Symantec Management Server фиксирует, что управляемый им агент Symantec Endpoint Protection обнаружил вредоносный файл на своем узле.
Здесь:
30.0.0.1 — Источник (Symantec Management Server),
10.0.0.1 — Субъект (агент Symantec Endpoint Protection).
Схема 5. Совмещение роли Субъекта и Объекта в Источнике
Последняя вырожденная схема взаимодействия характерна для ситуации, когда SIEM получает события от Источника, сообщающего об изменении своего внутреннего состояния: например, реконфигурации устройства или ПО, включении или отключении сетевого порта. В такой схеме роль Источника совпадает с ролью Субъекта и Объекта. В отличие от предыдущей схемы, здесь события в SIEM приходят напрямую.
В данном примере коммутатор на базе Cisco IOS сообщает, что его интерфейс перешел в статус UP.
Здесь 30.0.0.1 — Источник (коммутатор).
На этом уровне присутствуют взаимодействия уже известных нам сущностей: Субъекта, Объекта. Однако вся информация об Источнике и Передатчике остается непосредственно на уровне сети и не имеет своего отражения на уровне приложения.
Большая часть всех типов событий имеет в своем составе взаимодействия одновременно на уровне сети и уровне приложений. Однако, отметим, что события, генерируемые непосредственно прикладным ПО, например, 1С: Предприятие, Microsoft SQL Server или Oracle Database, могут содержать в себе исключительно взаимодействия уровня приложений.
Кроме того, на уровне приложений появляется дополнительная сущность Ресурс.
Ресурс — промежуточная сущность, через которую Субъект оказывает влияние на Объект без прямого взаимодействия. Например, предоставление пользователем Alex прав на доступ к файлу MyFile пользователю Bob. Здесь Alex — Субъект, Bob — Объект, MyFile — Ресурс. Обратите внимание, в данном примере Alex напрямую не взаимодействует с Bob-ом.
Важно: события уровня приложений могут содержать как дополнительные параметры Субъекта и Объекта, так и самого Ресурса. К примеру, дополнительными параметрами такого Ресурса, как «файл», может служить директория, в которой он находится, или его размер.
При этом Субъект, Объект и Ресурс идентифицируются по имени или уникальному идентификатору: адресу электронной почты, имени файла, имени директории, имени таблицы в базе данных.
Рассмотрим дополнительные схемы взаимодействия, характерные для уровня приложений.
Схема 6. Взаимодействие через ресурс
На этой схеме Субъект опосредованно воздействует на Объект через промежуточный Ресурс. Как правило, события с такой схемой отчетливо видны в журналах аудита баз данных или работы с правами доступа к файлам и каталогам на уровне ОС.
В примере представлена запись из журнала аудита СУБД Oracle Database. В нем зафиксирован процесс отзыва роли у пользователя.
Здесь:
«ALEX» — Субъект (имя пользователя, который отзывает роль),
«BOB» — Объект (имя пользователя, у которого отзывают),
«ROLE» — Ресурс (имя отзываемой роли).
Схема 7. Взаимодействие с множеством ресурсов
На уровне приложений, как и на уровне сети, существуют такие типы событий, в которых Субъект взаимодействует с Объектом сразу через множество Ресурсов. При этом очень редко, но бывают случаи, когда количество Объектов тоже больше одного. Такие типы события появляются при фиксации массовых операций. Например, предоставление доступа к нескольким файлам одному пользователю или изменение набора правил, входящих в политику.
В примере решение по защите виртуальных сред Код Безопасности vGate фиксирует добавление в набор новых политик.
Здесь:
«admin@VGATE» — Субъект (имя пользователя, изменяющего набор политик)
«base» — Объект (набор политик)
«Установка и поддержка целостности файловой системы», «Проверка настроек SNMP-агента», «Запрет автоматической установки VMware Tools» — Ресурсы (имена добавленных политик)
На всех схемах мы выделяли разные сущности (субъекты, объекты, ресурсы, источники, передатчики) и отмечали так называемый канал взаимодействия между ними. Остановимся подробнее на предпоследней составляющей большой модели «мира», которой должен оперировать SIEM, — на моделях канала взаимодействия между Субъектом и Объектом. Напомним, что последняя составляющая — контекст взаимодействия (этому будет посвящена следующая статья).
Итак, есть две сущности, взаимодействующие между собой. В рамках данного взаимодействия происходит передача данных от одной сущности к другой. Это могут быть сетевые пакеты с данными, файлы или команды управления. В этом случае образовавшийся канал можно представить в виде «трубы», по которой идет направленный поток данных и команд. Такая модель отчетливо видна на уровне сети, но менее выражена на уровне приложений (см. пример).
Модель канала данных
Исходя из такой модели, каждое событие, которое получает SIEM, может содержать информацию, описывающую:
Как правило, канал описывается такими параметрами, как идентификатор сессии, протокол передачи данных, время установления канала, время завершения, длительность. Данные в событиях характеризуются форматом, используемыми алгоритмами шифрования, количеством переданных пакетов, количество переданных байт.
Рассмотрим пример события, которое содержит данные о канале взаимодействия. Здесь представлено событие с системы управления процессами идентификации и контроля доступа — Cisco Identity Services Engine (ISE), фиксирующее сетевую сессия пользователя в рамках процедуры аккаунтинга (учет).
Здесь:
«Acct-Session-Id=1A346216», «Acct-Session-Time=50», «Service-Type=Framed», «Framed-Protocol=PPP» — параметры канала коммуникации,
«Acct-Input-Octets=43525», «Acct-Output-Octets=122215», «Acct-Input-Packets=234», «Acct-Output-Packets=466» — параметры переданных по каналу данных.
Итак, мы рассмотрели схемы взаимодействия уровней сети и приложений, а также модель канала взаимодействия. Далее покажем на примере, как в одном событии сочетаются схемы взаимодействия разных уровней и используется информация о модели канала.
Здесь мы видим событие от межсетевого экрана — Cisco Adaptive Security Appliance (ASA), в котором зафиксировано исходящее TCP-соединение.
В примере отчетливо видно, что внутри одного события присутствуют сущности уровня сети и уровня приложений. На уровне сети — схема взаимодействия Субъекта и Объекта, которое фиксируется Источником. Передатчик отсутствует.
Здесь:
30.0.0.1 — Источник (Cisco ASA),
10.0.0.1 — Субъект (адрес того, кто подключается),
20.0.0.1 — Объект (адрес того, к кому подключаются).
На уровне приложений — простая схема, в которой присутствуют только Субъект и Объект:
«ALEX» — Субъект (имя пользователя, который подключается),
«BOB» — Объект (имя пользователя, к которому подключаются).
Также в этом событии присутствует описание канала передачи данных, но отсутствует описание самих данных:
«TCP» — протокол, на основе которого создан канал,
«136247» — идентификатор сессии канала.
Как могут помочь выделенные нами типовые схемы взаимодействия?
Таким, образом, модель «мира», которая строится в SIEM и представляется набором полей (схемой), должна содержать разделы для описания:
Для каждой сущности необходимо определить набор свойств, которые ее однозначно идентифицируют. На уровне сети сущности идентифицируются IP-, MAC- адресами или FQDN. На уровне приложений — именами или ID. Схема должна иметь выделенные поля для хранения этих идентификаторов.
Существуют вырожденные схемы взаимодействия, в которых одна сущность может сочетать в себе сразу несколько ролей. При нормализации таких событий необходимо явно определить правило заполнения всех полей схемы, отвечающих за весь набор сущностей. В дальнейшем это поможет правилам корреляции не пропустить часть взаимодействий.
Поясним: возьмем случай с совмещением роли Субъекта и Объекта в Источнике. Если при нормализации будут заполнены только поля схемы, отвечающие за Источник, то правила корреляции, анализирующие изменения конфигурации на определенном Объекте попросту пропустят нужные нам события, так как поля Объекта будут пусты.
При написании правил корреляции важно четко понимать, с событиями какой схемы и какого уровня взаимодействия мы работаем. Это поможет правильно интерпретировать роли сущностей, участвующих в событиях.
В итоге общая схема, способная описать все множество типовых взаимодействий, выглядит так:
Схема полей, ориентированная на взаимодействия
Следующий этап — включение в модель «мира» SIEM смысла или семантики того взаимодействия, которое наблюдаем в исходном событии. Практика показывает, что недостаточно знать, что пользователь Alex со своей рабочей станции подключился к контроллеру домена, — важно понимать, что это была попытка логина и, возможно, неудачная. При написании правил корреляции лучше оперировать семантикой происходящих явлений, а не просто данными из полей событий. Конечно, как-то интерпретировать и понять смысл можно, посмотрев на данные в нормализованном событии, но коррелятору в SIEM нужно помочь это сделать.
В следующей статье расскажем про категоризацию и то, как она помогает однозначно интерпретировать смысл тех взаимодействий, которые есть в событии. Также мы соберем воедино все описанное и сформулируем основные принципы, лежащие в основе методологии нормализации событий, которые получены из разных источников.
Цикл статей:
Глубины SIEM: Корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?
Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира» (Данная статья)
Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий
Глубины SIEM: корреляции «из коробки». Часть 3.2. Методология нормализации событий
Глубины SIEM: корреляции «из коробки». Часть 4. Модель системы как контекст правил корреляции
Глубины SIEM: корреляции «из коробки». Часть 5. Методология разработки правил корреляции
О проблеме трансформации модели «мира» было рассказано в первой статье. Коротко напомним ее суть: при возникновении какого-то явления на источнике событий (например, запуск процесса в ОС) происходит его фиксация в разных форматах сначала в памяти, затем в журнале событий ОС и далее — в SIEM-системе. Каждая стадия обработки сопровождается потерей данных, так как на уровне ОС — одна модель «мира», а в журнале ОС — другая, ограниченная набором полей — схемой журнала. Таким образом, происходит отражение (трансформация) одной модели с большим числом параметров в другую, с меньшим их числом. Нормализация и сохранение события в SIEM — это еще одна трансформация, которая также происходит с потерей данных, так как и внутри SIEM заложена собственная модель «мира».
Сложно найти способ, который бы позволил проводить трансформацию одной модели в другую без потерь. Зная это ограничение, необходимо сформулировать такой подход к нормализации и формированию перечню полей схемы событий, при котором не терялась бы информация, важная при корреляции и дальнейшем расследовании инцидентов ИБ.
В рамках SIEM модель представлена схемой — набором полей, в которые в процессе нормализации укладываются данные из исходного события. В дальнейшем именно она будет использоваться специалистами при создании правил корреляции. Чтобы специалисты по расследованию инцидентов и ответственные за разработку правил корреляции однозначно трактовали нормализованные события, схема должна удовлетворять основным свойствам:
- быть унифицированной для событий любого типа и источников;
- четко описывать, кто с кем и как взаимодействовал;
- сохранять суть и контекст взаимодействия.
В процессе разработки правил нормализации информацию о взаимодействии необходимо найти в исходном событии и разложить ее в специально отведенные поля. То же самое необходимо сделать с контекстом и сутью взаимодействия (подробнее об этом — в следующей статье).
Возникает вопрос: возможно ли выделить типовые схемы для взаимодействий, которым бы удовлетворяли любые события, создаваемые всеми возможными ИТ и ИБ-источниками? Если да, то как выглядят эти схемы?
Для поиска ответа на эти вопросы необходимо обратиться к аналитике и постараться проанализировать как можно больше уже разработанных и функционирующих в SIEM-решениях правил нормализации для выявления общих закономерностей. В рамках таких работ удалось провести анализ более 3000 правил нормализации от более чем 100 различных источников из таких решений, как Positive Technologies MaxPatrol SIEM и Micro Focus ArcSight. В результате анализа были получены следующие выводы:
- Типовые схемы взаимодействия существуют.
- В каждом отдельном событии, как правило, есть информация о взаимодействии на уровне сети и на уровне приложений.
- Типовые схемы взаимодействия могут отличаться на разных уровнях, и это нужно учитывать.
Схемы взаимодействия на уровнях сети и приложений
Опишем типовые схемы для каждого уровня. Перед этим нужно выделить сущности, которые всегда присутствуют в событиях. Далее на их базе и будут построены схемы взаимодействия. К ним относятся:
- Субъект. Сущность, оказывающая воздействие на объект. Например, Пользователь, меняющий ключ реестра, либо хост с IP 10.0.0.1, отправляющий пакет на хост с IP 20.0.0.1.
- Объект. Сущность, на которую оказывает воздействие Субъект.
- Источник. Как правило, хост, который регистрирует взаимодействие Субъекта с Объектом и порождает само событие. К примеру, Источником будет являться межсетевой экран, зафиксировавший передачу пакетов от хоста — Субъекта с IP 10.0.0.1, хосту — Объекту c IP 20.0.0.1.
- Передатчик. Есть случаи, когда SIEM получает события не напрямую с источника, а с промежуточного сервера, через который данные события проходят. Самый просто пример — промежуточный syslog-сервер. Пример посложнее — когда Передатчиком может быть сервер управления, например, Kaspersky Security Center. В этом случае Источник — конкретный агент Kaspersky Endpoint Security.
Однако не все сущности могут быть одновременно представлены в событии (об этом далее), поэтому важно изначально ввести соглашения, как в таком случае заполняются соответствующе поля схемы. Это поможет в дальнейшем явно отличать случаи, при которых эти поля не были заполнены из-за ошибки специалиста, разрабатывающего правила нормализации, от случаев, при которых в исходном событии действительно не содержалось данных о какой-либо сущности.
Перейдем к схемам взаимодействия и примерам событий. Для наглядности все примеры будут приведены на базе файловых логов, сообщений syslog или записей в реляционной базе, но они могут применяться и для других форматов логов, например, бинарных.
Уровень сети
Основной идентификатор сущностей сетевого уровня — IP-адреса. При этом важно понимать, что могут быть и иные связанные идентификаторы — MAC-адреса на канальном уровне, FQDN — на прикладном. Возникает вопрос: они говорят об одной и той же сущности или о разных? Могут ли у одной и той же сущности меняться эти идентификаторы со временем? Этому будет посвящена отдельная статья, сейчас остановимся на том, что основной идентификатор для моделей взаимодействия на сетевом уровне — IP-адрес.
Итак, типовые схемы взаимодействия этого уровня можно условно разделить на два класса — основные и вырожденные.
Основные схемы взаимодействия
Схема 1.Полная схема взаимодействия
В рамках данной модели в событии, поступившем на вход SIEM, можно выделить все основные сущности: Субъект, Объект, Источник, Передатчик. На схеме взаимодействия Субъект воздействует на Объект. Это воздействие регистрирует (наблюдает) Источник и порождает событие. Событие от Источника поступает в Передатчик и с него попадает в SIEM.
Событие ниже фиксирует разрешение сетевого взаимодействия между хостами межсетевым экраном Stonesoft (ныне — Forcepoint), при этом само событие поступает в SIEM не напрямую, а от промежуточного syslog-сервера.
Здесь:
40.0.0.1 — Передатчик (промежуточный syslog-сервер),
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).
Схема 2.Схема прямого сбора без передатчика
Далеко не всегда в схеме взаимодействия есть Передатчик. Как правило, он присутствует, когда для передачи событий используется промежуточный сервер (например, syslog-сервер), или когда у решения, с которого собираются события, есть централизованная система управления — например, Kaspersky Security Center, Check Point Smart Console или Cisco Prime. По этой схеме события попадают в SIEM напрямую из Источника. Большая часть всех событий описывается именно этой схемой. Кстати, пример такого события можно увидеть в схеме 1, если бы в ней отсутствовал промежуточный syslog-сервер и мы получали события напрямую от межсетевого экрана.
Здесь:
30.0.0.1 — Источник (нода межсетевого экрана),
10.0.0.1 — Субъект (отправляющий UDP-пакеты),
20.0.0.1 — Объект (получающий UDP-пакеты).
Схема 3. Взаимодействие с множеством Объектов
Эта схема взаимодействия на уровне сети встречается достаточно редко и, как правило, характерна для событий сетевого оборудования. В схеме один Субъект взаимодействует со множеством Объектов, подобное взаимодействие присутствует в событиях, описывающих multicast, unicast или broadcast рассылки.
Отметим, что иногда множество Объектов могут быть объединены общим идентификатором — адресом подсети или широковещательным адресом. Это нужно помнить, так как при анализе событий, в том числе и на уровне правил корреляции, легко можно пропустить потенциально важное взаимодействие, так как в такой схеме адрес Объекта сокрыт за групповым адресом.
Следующий пример демонстрирует событие с IGMP Relay сервера, через который транслируется запрос принадлежности к групповому адресу.
Здесь:
30.0.0.1 — Источник (IGMP Relay сервер),
10.0.0.1 — Субъект (запрашивающий принадлежность к группе),
224.0.0.252 — Объект (групповой адрес).
Вырожденные схемы
Субъект, Объект и Источник — базовые сущности в группе основных схем взаимодействия. Однако нередки случаи, когда в событии одна из сущностей может отсутствовать.
Схема 4. Взаимодействие без Объекта
Зачастую такая схема характерна в ситуациях, при которой Субъект сообщает об изменении своего внутреннего состояния — то есть он выступает одновременно в роли Субъекта и Объекта. Например, такое взаимодействие можно наблюдать в событиях изменения конфигурации или обнаружения вредоносного ПО на рабочей станции. Но эту информацию фиксирует не сам Субъект, а централизованная система управления и сохраняет в своем журнале.
В примере показано, как сервер управления Symantec Management Server фиксирует, что управляемый им агент Symantec Endpoint Protection обнаружил вредоносный файл на своем узле.
Здесь:
30.0.0.1 — Источник (Symantec Management Server),
10.0.0.1 — Субъект (агент Symantec Endpoint Protection).
Схема 5. Совмещение роли Субъекта и Объекта в Источнике
Последняя вырожденная схема взаимодействия характерна для ситуации, когда SIEM получает события от Источника, сообщающего об изменении своего внутреннего состояния: например, реконфигурации устройства или ПО, включении или отключении сетевого порта. В такой схеме роль Источника совпадает с ролью Субъекта и Объекта. В отличие от предыдущей схемы, здесь события в SIEM приходят напрямую.
В данном примере коммутатор на базе Cisco IOS сообщает, что его интерфейс перешел в статус UP.
Здесь 30.0.0.1 — Источник (коммутатор).
Уровень приложений
На этом уровне присутствуют взаимодействия уже известных нам сущностей: Субъекта, Объекта. Однако вся информация об Источнике и Передатчике остается непосредственно на уровне сети и не имеет своего отражения на уровне приложения.
Большая часть всех типов событий имеет в своем составе взаимодействия одновременно на уровне сети и уровне приложений. Однако, отметим, что события, генерируемые непосредственно прикладным ПО, например, 1С: Предприятие, Microsoft SQL Server или Oracle Database, могут содержать в себе исключительно взаимодействия уровня приложений.
Кроме того, на уровне приложений появляется дополнительная сущность Ресурс.
Ресурс — промежуточная сущность, через которую Субъект оказывает влияние на Объект без прямого взаимодействия. Например, предоставление пользователем Alex прав на доступ к файлу MyFile пользователю Bob. Здесь Alex — Субъект, Bob — Объект, MyFile — Ресурс. Обратите внимание, в данном примере Alex напрямую не взаимодействует с Bob-ом.
Важно: события уровня приложений могут содержать как дополнительные параметры Субъекта и Объекта, так и самого Ресурса. К примеру, дополнительными параметрами такого Ресурса, как «файл», может служить директория, в которой он находится, или его размер.
При этом Субъект, Объект и Ресурс идентифицируются по имени или уникальному идентификатору: адресу электронной почты, имени файла, имени директории, имени таблицы в базе данных.
Рассмотрим дополнительные схемы взаимодействия, характерные для уровня приложений.
Схема 6. Взаимодействие через ресурс
На этой схеме Субъект опосредованно воздействует на Объект через промежуточный Ресурс. Как правило, события с такой схемой отчетливо видны в журналах аудита баз данных или работы с правами доступа к файлам и каталогам на уровне ОС.
В примере представлена запись из журнала аудита СУБД Oracle Database. В нем зафиксирован процесс отзыва роли у пользователя.
Здесь:
«ALEX» — Субъект (имя пользователя, который отзывает роль),
«BOB» — Объект (имя пользователя, у которого отзывают),
«ROLE» — Ресурс (имя отзываемой роли).
Схема 7. Взаимодействие с множеством ресурсов
На уровне приложений, как и на уровне сети, существуют такие типы событий, в которых Субъект взаимодействует с Объектом сразу через множество Ресурсов. При этом очень редко, но бывают случаи, когда количество Объектов тоже больше одного. Такие типы события появляются при фиксации массовых операций. Например, предоставление доступа к нескольким файлам одному пользователю или изменение набора правил, входящих в политику.
В примере решение по защите виртуальных сред Код Безопасности vGate фиксирует добавление в набор новых политик.
Здесь:
«admin@VGATE» — Субъект (имя пользователя, изменяющего набор политик)
«base» — Объект (набор политик)
«Установка и поддержка целостности файловой системы», «Проверка настроек SNMP-агента», «Запрет автоматической установки VMware Tools» — Ресурсы (имена добавленных политик)
Модель канала взаимодействия между Субъектом и Объектом
На всех схемах мы выделяли разные сущности (субъекты, объекты, ресурсы, источники, передатчики) и отмечали так называемый канал взаимодействия между ними. Остановимся подробнее на предпоследней составляющей большой модели «мира», которой должен оперировать SIEM, — на моделях канала взаимодействия между Субъектом и Объектом. Напомним, что последняя составляющая — контекст взаимодействия (этому будет посвящена следующая статья).
Итак, есть две сущности, взаимодействующие между собой. В рамках данного взаимодействия происходит передача данных от одной сущности к другой. Это могут быть сетевые пакеты с данными, файлы или команды управления. В этом случае образовавшийся канал можно представить в виде «трубы», по которой идет направленный поток данных и команд. Такая модель отчетливо видна на уровне сети, но менее выражена на уровне приложений (см. пример).
Модель канала данных
Исходя из такой модели, каждое событие, которое получает SIEM, может содержать информацию, описывающую:
- Параметры самого канала — «трубу»,
- Передаваемые по этой «трубе» данные.
Как правило, канал описывается такими параметрами, как идентификатор сессии, протокол передачи данных, время установления канала, время завершения, длительность. Данные в событиях характеризуются форматом, используемыми алгоритмами шифрования, количеством переданных пакетов, количество переданных байт.
Рассмотрим пример события, которое содержит данные о канале взаимодействия. Здесь представлено событие с системы управления процессами идентификации и контроля доступа — Cisco Identity Services Engine (ISE), фиксирующее сетевую сессия пользователя в рамках процедуры аккаунтинга (учет).
Здесь:
«Acct-Session-Id=1A346216», «Acct-Session-Time=50», «Service-Type=Framed», «Framed-Protocol=PPP» — параметры канала коммуникации,
«Acct-Input-Octets=43525», «Acct-Output-Octets=122215», «Acct-Input-Packets=234», «Acct-Output-Packets=466» — параметры переданных по каналу данных.
Пример моделей взаимодействия сущностей и канала в одном событии
Итак, мы рассмотрели схемы взаимодействия уровней сети и приложений, а также модель канала взаимодействия. Далее покажем на примере, как в одном событии сочетаются схемы взаимодействия разных уровней и используется информация о модели канала.
Здесь мы видим событие от межсетевого экрана — Cisco Adaptive Security Appliance (ASA), в котором зафиксировано исходящее TCP-соединение.
В примере отчетливо видно, что внутри одного события присутствуют сущности уровня сети и уровня приложений. На уровне сети — схема взаимодействия Субъекта и Объекта, которое фиксируется Источником. Передатчик отсутствует.
Здесь:
30.0.0.1 — Источник (Cisco ASA),
10.0.0.1 — Субъект (адрес того, кто подключается),
20.0.0.1 — Объект (адрес того, к кому подключаются).
На уровне приложений — простая схема, в которой присутствуют только Субъект и Объект:
«ALEX» — Субъект (имя пользователя, который подключается),
«BOB» — Объект (имя пользователя, к которому подключаются).
Также в этом событии присутствует описание канала передачи данных, но отсутствует описание самих данных:
«TCP» — протокол, на основе которого создан канал,
«136247» — идентификатор сессии канала.
Выводы
Как могут помочь выделенные нами типовые схемы взаимодействия?
- Во-первых, эксперт при написании правил корреляции и при анализе событий должен понимать, какие сущности присутствуют в рамках каждого события, поступающего в SIEM. Для этого необходимо еще на этапе нормализации событий явно выделить сущности: Субъект, Объект, Ресурс, Источник и Передатчик.
- Во-вторых, при нормализации важно учитывать, что в событии содержится информация как о взаимодействии уровня сети, так и уровня приложений. Оба эти взаимодействия могут одновременно присутствовать в одном событии.
- В-третьих, само взаимодействие представляет собой составную структуру, в которой есть информация об образованном канале и о данных, передаваемых по этому каналу.
Таким, образом, модель «мира», которая строится в SIEM и представляется набором полей (схемой), должна содержать разделы для описания:
- На уровне сети:
- Субъекта;
- Объекта;
- Источника;
- Передатчика;
- Канала взаимодействия;
- Данных, передаваемых по каналу.
- На уровне приложений:
- Субъекта;
- Объекта или множества объектов;
- Ресурса или множества ресурсов.
Для каждой сущности необходимо определить набор свойств, которые ее однозначно идентифицируют. На уровне сети сущности идентифицируются IP-, MAC- адресами или FQDN. На уровне приложений — именами или ID. Схема должна иметь выделенные поля для хранения этих идентификаторов.
Существуют вырожденные схемы взаимодействия, в которых одна сущность может сочетать в себе сразу несколько ролей. При нормализации таких событий необходимо явно определить правило заполнения всех полей схемы, отвечающих за весь набор сущностей. В дальнейшем это поможет правилам корреляции не пропустить часть взаимодействий.
Поясним: возьмем случай с совмещением роли Субъекта и Объекта в Источнике. Если при нормализации будут заполнены только поля схемы, отвечающие за Источник, то правила корреляции, анализирующие изменения конфигурации на определенном Объекте попросту пропустят нужные нам события, так как поля Объекта будут пусты.
При написании правил корреляции важно четко понимать, с событиями какой схемы и какого уровня взаимодействия мы работаем. Это поможет правильно интерпретировать роли сущностей, участвующих в событиях.
В итоге общая схема, способная описать все множество типовых взаимодействий, выглядит так:
Схема полей, ориентированная на взаимодействия
Следующий этап — включение в модель «мира» SIEM смысла или семантики того взаимодействия, которое наблюдаем в исходном событии. Практика показывает, что недостаточно знать, что пользователь Alex со своей рабочей станции подключился к контроллеру домена, — важно понимать, что это была попытка логина и, возможно, неудачная. При написании правил корреляции лучше оперировать семантикой происходящих явлений, а не просто данными из полей событий. Конечно, как-то интерпретировать и понять смысл можно, посмотрев на данные в нормализованном событии, но коррелятору в SIEM нужно помочь это сделать.
В следующей статье расскажем про категоризацию и то, как она помогает однозначно интерпретировать смысл тех взаимодействий, которые есть в событии. Также мы соберем воедино все описанное и сформулируем основные принципы, лежащие в основе методологии нормализации событий, которые получены из разных источников.
Цикл статей:
Глубины SIEM: Корреляции «из коробки». Часть 1: Чистый маркетинг или нерешаемая проблема?
Глубины SIEM: корреляции «из коробки». Часть 2. Схема данных как отражение модели «мира» (Данная статья)
Глубины SIEM: корреляции «из коробки». Часть 3.1. Категоризация событий
Глубины SIEM: корреляции «из коробки». Часть 3.2. Методология нормализации событий
Глубины SIEM: корреляции «из коробки». Часть 4. Модель системы как контекст правил корреляции
Глубины SIEM: корреляции «из коробки». Часть 5. Методология разработки правил корреляции
