SIEM - Security Information and Event Management

Руслан Рахметов, Security Vision

Рис. 1 – Эволюция SIEM

До того, как понятие SIEM было «узаконено» аналитиком Gartner, оно существовало в виде двух терминов и, соответственно, двух разных решений. SEM (Security Event Management) и SIM (Security Information Management) системы по отдельности предназначались для анализа событий ИБ «на лету» и для исторического анализа и поиска аномалий «в базе». В 2005 году одновременно с аналитическим обзором Гартнера объединённый термин SIEM упоминался на различных конференциях, например, NEbraskaCERT Conference, после чего класс решений стал широко востребован как единое окно для сбора и анализа данных, получаемых с сетевых устройств, контроллеров домена, операционных систем, баз данных и других прикладных систем ИБ и ИТ.

Сейчас зарождается SIEM второго поколения, который по факту является объединением со смежными решениями вроде Threat Intelligence и Behavior Analysis, дополняющими поиск инцидентов анализом индикаторов компрометации и алгоритмами машинного обучения. Вендоры ИБ развиваются, покупают смежные решения и поставляют больший функционал каждый год. Но поскольку TI, UBA/UEBA и другие решения существуют отдельно, мы будем рассматривать SIEM в изолированном исполнении. Такая классическая система предназначена для мониторинга событий, поиска инцидентов и аномалий как в режиме реального времени, так и в ретроспективе.

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

Рис. 2 – Решаемые задачи

Представим ситуацию, когда человек пытается зайти в чужой дом со своими ключами. Если допустить, что ключ подошёл, как в знаменитом фильме «Ирония судьбы, или С легким паром!» 1975 года, но человек имел злой умысел – он может что-то украсть. Тогда событие ИБ становится инцидентом, и хозяин дома должен об это узнать как можно скорее.

1.  Информацию о попытках входа можно получить от консьержа, умного домофона, камеры в подъезде и других источников, но каждый из источников приходилось бы изучать отдельно, если бы SIEM не решали первую задачу – нормализацию данных и группировку. Коллекторы системы позволяют собрать все события в общий формат: NGFW одного производителя может записывать в отчёт “deny”, другого “discard”, третьего – “drop”, DLP разных вендоров посылают свои отчёты в разных формах, AV добавляет в поток событий свои отчёты и алерты и т.д. Если представить, что в едином приложении есть весь журнал посещений в удобном формате, то по аналогии можно представить интерфейс SIEM, в котором человек легко разберётся, что происходит.

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

3.  В простейшем случае правила описаны в форматах RBR (Rule Based Reasoning) и анализируют триггеры, счётчики и возможные цепочки действий. Например, если человек заходит в свой интернет-банк в России, а через час попытка повторяется из Сербии – возможна попытка мошенничества, значит, сотрудник ИБ банка должен быть оповещён как можно скорее. Оповещения – это третья задача SIEM. При взаимодействии с IRP системами можно реализовать процесс, связанный не только с оповещениями, но и с автоматическим реагированием, когда средства защиты информации будут запускаться сами и защищать пользователя запуском EDR и двухфакторной аутентификацией (или звонком из банка с сотрудником экономической безопасности «на проводе»).

4.  Теперь представим ситуацию без IRP или своевременного действия ИБ-специалиста – произошла утечка данных или кража их квартиры, как в кино. Скорее всего, настоящий жилец захочет обратиться в полицию, суд или страховую компанию за компенсацией потерь, но для этого нужно собрать побольше доказательств. SIEM способна предоставить всю необходимую доказательную базу, решая четвёртую задачу. Такой комплект доказательств будет пригодным как для внутренних расследований, так и в суде.

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

Рис. 3 – Архитектура SIEM-системы

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

Самое главное и ресурсоёмкое – это серверная часть ПО. В ней функционируют коллекторы, корреляторы и база данных. Задача коллекторов - собирать данные от источников и проводить базовую группировку, удаление дубликатов и облегчение для работы второго звена. Сервер корреляции отвечает за понимание инцидентов и отсеивание простых событий от общего потока. Поток событий обычно рассчитывается заранее для оптимизации нагрузки, поэтому сайзинг описывается количеством событий в секунду (event per second, EPS). После определения инцидентов формируется оповещение либо через консоль управления (обычно веб-интерфейс), либо через другие средства коммуникации (самое частое – корпоративная электронная почта). Последний (не по значимости) серверный компонент – база данных. Её размеры и требования к дискам зависят от глубины хранения, определить которую может либо сам заказчик, либо соответствующий регулятор.

Информацию можно собирать удалённо при помощи соединения по протоколам NetBIOS, RPC, TFTP, FTP. Однако в этом случае может возникнуть проблема с нагрузкой на сеть, которую решает клиентская часть ПО. «Агенты» устанавливаются на хосты пользователей и значимые сервера, собирают данные локально и передают в центр управления по своему расписанию. 

Таким способом SIM+SEM=SIEM осуществляют автоматизированный мониторинг событий от десятков, сотен и даже тысяч разных источников, нормализуют их отчёты и группируют в возможные инциденты, а также оповещают о них ответственные лица. Собираемая статистика и поиск по базе данных позволяют сформировать единые процессы по митигации последствий и реагированию на инциденты, дополнительную эффективность в которых добавят средства автоматизации и оркестрации.