SIEM. Маркетинг VS «Поля»: результаты опроса

Привет, Хабр!

Мое приключение началось с того, что я поймал очередную двухполюсную волну, похожую на всем известное расстройство. С одной стороны, маркетинг вендоров рапортует, что SIEM (Security information and event management) системы — это сердце SOC (Security Operations Center), новый век наступил и текущий уровень развития решений этого класса настолько высок и зрел, что его внедрение разом избавит всех от неприятностей. Всем станет легко собрать данные из множества источников, с минимальными затратами обнаруживать подозрения на инциденты и далее по списку. С другой стороны, эксплуатанты и внедренцы SIEM, с которыми я пересекаюсь, говорят, что везде боль, тлен, безысходность.

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

Кратко о том, что вас ждет дальше:

• Сперва будут ключевые вопросы респондентам об их опыте с SIEM системами, графики, показывающие как обстоят дела в реальности, и пояснения к ним;

• После цифр – основные мои мысли и выводы по этому поводу;

• И на последок, конечно же, слова благодарности.

Кто эти люди?

Знакомиться с ними будем основываясь на том, как опрошенные связаны с SIEM системами: создают, внедряют или эксплуатируют, а также на том, сколько EPS (Events per Second) подают в систему. Вот так выглядят опрошенные с точки зрения графиков (все картинки кликабильны):

В опросе участвовали 64 респондента, из которых на долю эксплуатантов пришлось 41 человек или в процентном соотношении 64%. Внедренцев SIEM из числа откликнувшихся было 21, то есть 33% от общего числа опрошенных. А из разработчиков аж целых 2 человека. Ребят, спасибо вам огромное за ваш нелегкий труд!

Посмотрим на ситуацию EPS:

• В основном участвующие в исследовании специалисты сталкиваются с диапазоном 10k-50k, а это 42% опрошенных;

• При этом с диапазоном 50k-100k сталкиваются всего 22% респондентов, а вот уже с 100k-500k — 17%;

• Остальные 19% разделились между самыми маленькими и самыми большими до 10k, что составляет 14%;

• И только у 5% от общего числа участвующих в опросе — «мастодонтов» – более 500k EPS.

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

Результаты опроса

Потоки событий

Первый вопрос, который меня интересовал: а какой поток из всего объема логов SIEM уходит на коррелятор?

Рисунок выше наглядно нам показывает:

• Самый популярный поток на коррелятор — до 10k EPS, то есть 45%;

• За ним идет категория с диапазоном 10k-50k, где 33% опрошенных;

• А вот уже по возрастанию EPS процент опрошенных падает и составляет всего 16% у диапазона 50k-100k;

• В диапазон 100k-500k попадают 5%;

• А в более 500k EPS на коррелятор всего 2%.

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

Ок, с EPSами на коррелятор все понятно, а как дела обстоят с хранением?

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

А сколько же реально хранятся данные?

Информация на графике слева говорит нам о том, что:

• 27% опрошенных хранят данные один квартал;

• У кого эта глубина составляет месяц — 22%;

• Полгода обеспечивают хранение всего 19%;

• А больше, чем один год — 17%.

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

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

Централизованный сбор так или иначе умеют 97% решений опрошенных. В то же время систем-потребителей логов, кроме SIEM, не имеют всего 17% опрошенных. Что непрозрачно намекает о насущной необходимости выделенного LM(Log Management) решения, а может, даже и SDL(Security Data Lake).

Из более-менее объективных данных приглашаю вас окунуться в максимально субъективную историю. Дальше мне было интересно узнать, как респонденты в целом оценивают время поиска событий системе? Устраивает ли оно их?

И вот, что из этого получилось на выходе:

• Большее количество опрошенных (55%) сказали, что их все скорее устраивает;

• При этом, как ни странно, второе место занимают те, кто, не удовлетворены скоростью поиска — 28%;  

• А тех, кто совсем не удовлетворены – целых 13%;

• Предыдущий показатель намного выше оценки полностью довольных, которых всего составило 5%.

Справа на графике представлена корреляция глубины хранения и удовлетворенности.

А далее следует график удовлетворенности временем поиска в зависимости от входящего потока EPS.

Можно долго рассуждать о причинах, но факт говорит, что времени поиска есть куда улучшаться.

Источники данных

Перейдем к следующему блоку вопросов, он будет более прикладным и связан с источниками данных, поставляемых c SIEM-системами. Первый и, пожалуй, один из ключевых вопросов, который я задал респондентам: а устраивает ли их список источников событий, поддерживаемых в SIEM?

Как мы видим, всё вроде даже очень неплохо. Список поддерживаемых источников скорее (55%) или полностью устраивает (13%) — 68% респондентов. Обратная ситуация у 33%.
Как же я «обожаю» округления. С точностью до десятых там:

• 54.7% и 12.5% с положительной коннотацией;

• 28.1%, 4.7% с отрицательной.

А вот на рисунке 9, мы можем увидеть насколько часто участвующие в опросе подключают уникальные источники событий?

В свою очередь, с историей добавления нового/уникального источника не сталкивалось только 6% опрошенных. Для остальных новых источников скорее рутина с разной степенью повторяемости.

С источниками событий вроде понятно, но SIEM же должен уметь в корреляцию, да?

В итоге правила корреляции из коробки:

• Скорее НЕ устраивают большинство опрошенных, а если быть точнее — 44%;

• При этом полностью НЕ устраивает 23%;

• В положительном ключе оценивают список правил корреляции – всего 33%.

А сейчас давайте посмотрим, как часто приходится пилить свои правила для уникальных источников?

Больше 5 раз в квартал этим занимаются больше половины, а именно 58% респондентов. Как обычно их связь на соседнем графике.

И здесь становится понятным, что новые правила под источники приходится делать часто.

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

И решения извечного холивара: «»наелозить» правило мышкой VS написать код/псевдокод» так и не случилось, поскольку итоги у нас получились следующими:

• 36% используют оба способа;

• 30% чаще «елозинг»;

• 19% чаще код;

• 16% коррелятор не трогают.

Соседний график нам рассказывает кто эти люди.

Перейдем к следующему. Хорошей практикой при разработке является также версионирование и тестирование.

В этом вопросе, как оказалось:

• Со мной согласны 47%, они ответили, что используют версионирование и тестирование;

• Только тестируют это 33%;

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

На графике рядом показана корреляция с инструментами для написания правил.

И …барабанная дробь… сколько же правил у нас на корреляторе?

Скажу честно, результат меня весьма удивил! Что мы видим:

• Большинство участников ответили, что количество используемых ими правил составило от 100 до 500 42%;

• На следующем месте оказались респонденты, применяющие от 50 до 100 правил — 34%;

• А вот более 500 – 16%;

• Только 8% опрошенных используют либо менее 50 правил, либо не владеют такими данными.

На соседней гистограмме показана корреляция количества правил и входящего потока EPS. Коллеги, со 100+ правилами, вы герои. Поддерживать такой объем и вручную — это настоящий подвиг.

А «на сладкое» вашему вниманию еще один холивар мой заключительный вопрос: Какой подход по «нормализации» данных для вас является более предпочтительным?

И опять что-то интересное:

• 52% ответили, что «Все события могут быть нормализованы в любую модель данных, модель данных могут быть созданы, как вендором, так и самим пользователем»;

• 38% адептов «Все события нормализуются в  единую модель данных (пример CEF)»;

• и только 8% за вариант «Все события нормализуются в несколько заранее созданных вендором моделей данных, в зависимости от типа событий (Authentication, Object Access, Networks)».

Но, все-таки почему?

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

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

Как говорил Михаил Николаевич Задорнов: «Готовы?»

Сильнее всего у эксплуатантов болит от того, что SIEM не поддерживает нужный им источник, при этом они имеют возможность добавить его самостоятельно – так ответили 23% опрошенных. Также наиболее критичными моментами являются отсутствие возможности обновления SIEM без остановки работы всей системы (12%) и ее производительность — архитектура этого класса решений не позволяет выполнять нужное масштабирование (8%).

Перейдем к внедренцам. У них болит там же, только в несколько других пропорциях: 14%, 11% и 6% соответственно.

А у создателей болят лапки :3

Далее я попытаюсь подвести итоги всего вышенаписанного.

Во-первых, что сразу «бросилось» в глаза, так это частое использование SIEM в качестве Log Management. При этом, учитывая, что в инфраструктурах пользователей есть еще системы-потребители логов, и я подозреваю, что там ситуация с необходимостью хранить логи аналогичная. В итоге один и тот же набор данных хранится в 3+ системах одновременно (где-то тут всплакнул один Сакити Тоёда). Во многом из-за такого нерационального использования ресурсов не все опрошенные могут обеспечить необходимую глубину хранения данных в соответствии со своей же нормативкой.

Если говорить о более прикладных аспектах использования SIEM систем, то временем поиска скорее или полностью удовлетворены больше половины участников опроса. И «изкоробочные» источники также скорее устраивают более половины респондентов. Но на мой взгляд, такое «скорее» можно приравнять к тройке с плюсом по пятибалльной шкале, потому что сильнее всего болит именно отсутствие источников из коробки. При этом испытывать «боль» за квартал приходится 2-5 раз 34% и 6-20 31% опрошенных.

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

Среди остальных участвующих осталось 20% смельчаков, деплоящих правила сразу в прод без тестирования. Тут можно только процитировать Максима Горького «Безумству храбрых поём мы славу».

В опросе было еще несколько пунктов, которые я решил вынести за скобки, например, вопрос: Как часто вы переносите разработанные правила корреляции между серверами SIEM? Чуть больше половины так или иначе сталкивается с такой необходимостью. При этом 41% не занимается переносом вовсе.

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

Кстати, о моделях данных. Доминирующего мнения получить так и не удалось. Первые дни опроса уверенно лидировал подход единой датамодели (CEF и ей подобные), позже вперед вырвалась кастомная дата модель. Выражая свое сугубо личное мнение, скажу, что связаны такие качели в первую очередь с эксплуатационным опытом. Конечно же укладывать всё в единую модель гораздо лучше точки зрения разработки, переносимости и далее по списку. Но на другой чаше весов находится расширяющийся набор источников и задач, которые не всегда могут вписаться в единую модель. Да и в перспективе возможность кастомизации несет больше плюсов, чем минусов.

Вместо заключения

Надеюсь, эта статья помогла и вам ответить на вопрос «Так где же правда?» в этом споре маркетинга и «полей». Задавайте вопросы, пишите комментарии (((=

Напоследок расскажу про само проведение опроса.

Его я проводил своими силами прося коллег «по цеху» распространить дальше. Бывали ситуации, что распространителей опроса, едва ли не «на вилы поднимали» за инициативу, объявляя ведьмой и несли на костер. Но в основном, сообщество весьма живо откликнулось, в какой-то момент опрос уже «отвязался» от меня лично и разлетелся по профильным чатам.

Всем участникам и распространителям ОГРОМАДНЕЙШЕЕ СПАСИБО!

Вот вам котик

UPD
Статью перенес в корп блог