ТОП 8 сценариев для SIEM систем

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

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

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

Корреляция по нескольким источникам

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

Фильтрация источников

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

Например наиболее распространенные сейчас веб-сервера это NGINX, Apache, IIS. У каждого из серверов свой собственный формат лога (На самом деле у NGINX и Apache формат лога полностью совпадает) и источник. При этом угрозы для них одинаковые. т.е. должен быть встроенный механизм позволяющий создать корреляцию только для веб-сервера.

Поддержка загрузки Threat Intelligence

Различные Threat Intelligence (TI) источники, как коммерческие так и бесплатные, являются полезным инструментом для выявления угроз в организации, позволяя выявлять в событиях артефакты свойственные различным угрозам, это могут быть хеши (MD5, SHA1, SHA256), IP адреса, доменные имена, контрольные суммы сертификатов и т.д.

Современные SIEM системы должны иметь встроенный инструмент, позволяющий загрузить и использовать TI данные.

При этом механизм загрузки TI  должен обеспечивать:

  • Загрузку списков по сети
  • Загрузку списков с веб сервера
  • Валидация входящих данных (проверка типа, к примеру что это  IPv4)
  • Возможность написания своих формул нормализации
  • Устаревание данных (TTL)

Свои формы нормализации позволяют указать в каком поле или строке содержаться полезные данные и какого они типа.

Конкатенация

SIEM система должна иметь встроенный механизм "склеивания" данных внутри события.

К примеру, некоторые вендоры при отправке событий могут разделить URL на разные части: в первой будет протокол, во второй домен, а в третьем поле может оказаться URI.

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

Ретроспективный анализ

Механизм позволяющий позволяющий проверить возникал ли инцидент в прошлом.

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

Сравнение полей

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

Пример:

"Предсказание сбоя": На рабочем месте администратора был запущен putty, после чего с этого же узла были зафиксированы обращения к серверам habr.

Сценарий конечно является шуткой, но позволяет понять что необходимо сравнивать не только поля источников (SRC), но и хосты между собой

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

Отсутствие события

Тоже довольно распространенный сценарий, когда пришло событие, но после него в течение времени не пришло второе событие.

К примеру на сервере антивируса возникло событие: обнаружен вирус, и после этого не пришло событие что вирус вылечен или помещен в карантин.

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

Обогащение

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

Пример: Есть три разных источника, в которых авторизуется пользователь, при этом в каждой системе имя пользователя уникально и не совпадает с другими источниками.

В первой системе имена пользователей вырядят как: i.ivanov, p.petrov, вторая же система содержит только фамилии: ivanov, petrov, а в третье системе у пользователей только идентификаторы: 0211241, 4818800

Это позволяет отслеживать что пользователь вошел в первую или вторую систему, и только после этого зашел в третью.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий