SIEM-процесс или SIEM-продукт?

Много лет назад, когда деревья были большими, а седины у меня не было вовсе, на прежней работе я решил запустить корпоративный центр идей, в котором сотрудники могли предлагать свои идеи, их можно было бы оценивать (в т.ч. и руководству), а самые интересные и полезные идеи — награждать. Слово за слово, запустили на внутреннем портале такой сервис, самостоятельно его разработав на PHP. Но не вышел каменный цветок у Данилы-мастера, ибо тогда я был молод и не понимал большой разницы между процессом, выстроенным вокруг какой-нибудь идем, и технической реализацией, которая могла помочь в реализации этой идем. В итоге не взлетел этот центр идей 🙁

И вот на днях, аккурат в предверии SOC Forum, о котором я уже писал, у нас с Дмитрием Мананниковым в Facebook зашла дискуссия на тему SIEM. Вообще она потянула за собой много терминологических споров, о которых мы еще поговорим (а на самом форуме продолжим). Но сейчас я хотел бы вернуться именно к SIEM, аббревиатуре, которая расшифровывается по-разному — то Security Information & Event Management, то Security Incident & Event Management, а то и вовсе SeacrhInform Event Management 🙂 Пожалуй, самым распространенным является первая расшифровка. И вот с ней-то и возникла некоторая путаница.

Точнее путаница возникла между тем, что включается в понятие SIEM. Ведь нередко под ним понимается… продукт, который продается тем или иным производителем. Хотя и тут куча споров идет. Например, мы с Олесей Шелестовой спорили на тему, Splunk — это SIEM или нет? Мы видим, что на консоль системы попадают события безопасности. Они объединяются с другими событиями, коррелируются… Вроде SIEM… Продукт.

Splunk with Cisco Security Suite

Возьмем к примеру систему Cisco FireSIGHT. Это SIEM? Ну а почему нет? События собирает, анализирует, коррелирует, визуализирует. Преимущественно от Cisco, но может брать данные и от, например, PT MaxPatrol или Qualys, а также отдавать их в тот же EnCase. Да, источников в FireSIGHT меньше, чем в том же Splunk, QRadar или ArcSight. Но где та грань, которая якобы SIEM отделяет от не-SIEM?

Cisco FireSIGHT

Ну допустим. FireSIGHT пусть и с натяжкой, но можно отнести к SIEM. Cisco MARS же многие относили, а он тоже был заточен на работу с преимущественно решениями Cisco. А вот если мы возьмем обычную утилиту SGUIL, визуализирующую работу с событиями системы обнаружения атак Snort. Это SIEM? Если брать определение из Википедии (хотя кто сказал, что это истина в последней инстанции), то мы увидим, что SIEM — это набор технологий для анализа в реальном времени сигналов тревоги, генерируемых сетевым оборудованием и приложениями.

Правда, если взять первоисточник (а определение SIEM впервые ввели в 2005-м году консультанты Gartner), то мы увидим, что по их версии SIEM — это решение, которое собирает, анализирует и представляет информацию, полученную от сетевых устройств и средств защиты, сканеров безопасности и средств управления политиками, IAM-приложений, ОС, СУБД и приложений, а также из внешних источников информации об угрозах. И почему SGUIL (особенно в связке с, например, ELSA и NetworkMiner) не попадает в это определение?

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

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

А VirusTotal или ThreatGRID, в конце концов. Это классические примеры внешних источников информации об угрозах, с которыми работают многие

VirusTotal

Cisco ThreatGRID

Все последние примеры — это не SIEM, но когда мы работаем с этими скриптами, инструментами или Web-сайтами, то мы занимаемся управлением информацией и событиями безопасности. Совершенно не обязательно все эти данные загонять в Splunk или ArcSight. Да и не загонишь их туда чаще всего, так как большинство представленных на рынке SIEM-продуктов привыкли работать только с формализованными данными. А тот же анализ современных, продвинутых угроз подразумевает, в первую очередь, творческий анализ большого массива данных с помощью некоторых инструментов автоматизации.

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

К чему я это веду? Да к тому, что покупая SIEM-продукт, надо быть готовым к выстраиванию SIEM-процесса. А не купив SIEM-продукт, нельзя утверждать, что у вас нет SIEM-процесса. Все это всегда будет базироваться на людях — своих или чужих (в рамках аутсорсинга). Все это всегда будет базироваться на процессах. Только тогда можно говорить о более менее эффективном решении задачи управления событиями и информацией безопасности. Без этого, покупка SIEM — это выброшенные на ветер деньги. Как собственно и покупка SIEM как сервиса. Если вы не знаете, что делать с теми событиями, о которых вам будет говорить сотрудник аутсорсингового SIEM, то зачем вы его покупали? Если вы не готовы на основе полученной информации перестраивать процессы, перенастраивать средства защиты, проводить расследование инцидентов и извлекать уроки из успешных проникновений, то о SIEM говорить рано. В аббревиатуре SIEM важна именно последняя буква M, означающая «управление». То есть речь идет о выстроенной и непрерывной работе с событиями ИБ. А уж будет для нее использовать широко разрекламированный продукт или нет — это уже вопрос десятый.

ЗЫ. Дальше будет еще несколько заметок в предверии SOC Forum, но посвященных уже другим темам, которые будут раскрыты на конференции. Ну а тему SIEM можно будет продолжить обсуждать там же.