Привет, Хабр!
Мое приключение началось с того, что я поймал очередную двухполюсную волну, похожую на всем известное расстройство. С одной стороны, маркетинг вендоров рапортует, что SIEM (Security information and event management) системы - это сердце SOC (Security Operations Center), новый век наступил и текущий уровень развития решений этого класса настолько высок и зрел, что его внедрение разом избавит всех от неприятностей. Всем станет легко собрать данные из множества источников, с минимальными затратами обнаруживать подозрения на инциденты и далее по списку. С другой стороны, эксплуатанты и внедренцы SIEM, с которыми я пересекаюсь, говорят, что везде боль, тлен, безысходность.
Так кто же на самом деле прав? Чтобы ответить себе на этот вопрос, я решил провести небольшое исследование среди специалистов по своему роду деятельности так или иначе связанных с разработкой, внедрением и эксплуатацией SIEM систем. И в этой статье я хочу поделиться с сообществом его результатами.
Кратко о том, что вас ждет дальше:
Сперва будут ключевые вопросы респондентам об их опыте с SIEM системами, графики, показывающие как обстоят дела в реальности, и пояснения к ним;
После цифр – основные мои мысли и выводы по этому поводу;
И на последок, конечно же, слова благодарности.
Кто эти люди?
Знакомиться с ними будем основываясь на том, как опрошенные связаны с SIEM системами: создают, внедряют или эксплуатируют, а также на том, сколько EPS (Events per Second) подают в систему. Вот так выглядят опрошенные с точки зрения графиков (все картинки кликабильны):
![Рисунок 1 – Участники опроса Рисунок 1 – Участники опроса](https://habrastorage.org/getpro/habr/upload_files/f5d/314/851/f5d3148518428b566df53780e4247ea4.png)
В опросе участвовали 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 уходит на коррелятор?
![Рисунок 2 – Поток событий на коррелятор Рисунок 2 – Поток событий на коррелятор](https://habrastorage.org/getpro/habr/upload_files/12d/2aa/644/12d2aa644677ae10ec984ac974bcde42.png)
Рисунок выше наглядно нам показывает:
Самый популярный поток на коррелятор - до 10k EPS, то есть 45%;
За ним идет категория с диапазоном 10k-50k, где 33% опрошенных;
А вот уже по возрастанию EPS процент опрошенных падает и составляет всего 16% у диапазона 50k-100k;
В диапазон 100k-500k попадают 5%;
А в более 500k EPS на коррелятор всего 2%.
Справа на графике представлены показатели "EPS на коррелятор", сгруппированные по входящему потоку. Глядя на график соотношения входящего потока и потока на коррелятор, можно сказать, что из SIEM в полный рост делают достаточно дорогой лог менеджер. В некоторых случаях только каждое 10е событие проходит через коррелятор.
Ок, с EPSами на коррелятор все понятно, а как дела обстоят с хранением?
![Рисунок 3 – Время хранение событий Рисунок 3 – Время хранение событий](https://habrastorage.org/getpro/habr/upload_files/3e4/f82/ec0/3e4f82ec0636691fafe8a14de0758d50.png)
Тут я думаю комментарии излишни... Поэтому я все-таки решил пойти дальше и узнать реальную глубину хранения данных, задав соответствующий вопрос.
А сколько же реально хранятся данные?
![Рисунок 4 – Время хранения событий Рисунок 4 – Время хранения событий](https://habrastorage.org/getpro/habr/upload_files/081/0a8/3ef/0810a83efb62994dac03299695e9571a.png)
Информация на графике слева говорит нам о том, что:
27% опрошенных хранят данные один квартал;
У кого эта глубина составляет месяц - 22%;
Полгода обеспечивают хранение всего 19%;
А больше, чем один год - 17%.
Рядом гистограмма с корреляцией глубины хранения и входящего потока логов. Честно говоря, я ожидал более ярко выраженного "квартала". И несколько печалит "неделя", потому как на практике данных за неделю не всегда хватает, чтобы "размотать" ту или иную атаку.
Кроме этого, меня также волновали вопросы: умеют ли SIEM системы опрашиваемых обеспечивать централизованный сбор? И может каким-то системам тоже нужны эти логи?
![Рисунок 5 – Возможность централизованного сбора и потребители Рисунок 5 – Возможность централизованного сбора и потребители](https://habrastorage.org/getpro/habr/upload_files/899/2dc/1e8/8992dc1e8f12fa7a985ca4830f0cd366.png)
Централизованный сбор так или иначе умеют 97% решений опрошенных. В то же время систем-потребителей логов, кроме SIEM, не имеют всего 17% опрошенных. Что непрозрачно намекает о насущной необходимости выделенного LM(Log Management) решения, а может, даже и SDL(Security Data Lake).
Из более-менее объективных данных приглашаю вас окунуться в максимально субъективную историю. Дальше мне было интересно узнать, как респонденты в целом оценивают время поиска событий системе? Устраивает ли оно их?
![Рисунок 6 – Удовлетворенность поиском событий Рисунок 6 – Удовлетворенность поиском событий](https://habrastorage.org/getpro/habr/upload_files/572/83e/08d/57283e08d97983a19ea20094868b5b07.png)
И вот, что из этого получилось на выходе:
Большее количество опрошенных (55%) сказали, что их все скорее устраивает;
При этом, как ни странно, второе место занимают те, кто, не удовлетворены скоростью поиска - 28%;
А тех, кто совсем не удовлетворены – целых 13%;
Предыдущий показатель намного выше оценки полностью довольных, которых всего составило 5%.
Справа на графике представлена корреляция глубины хранения и удовлетворенности.
А далее следует график удовлетворенности временем поиска в зависимости от входящего потока EPS.
![Рисунок 7 – Удовлетворенность в зависимости от EPS Рисунок 7 – Удовлетворенность в зависимости от EPS](https://habrastorage.org/getpro/habr/upload_files/893/ecd/a00/893ecda00593733b7fbc5d7b1b945e2c.png)
Можно долго рассуждать о причинах, но факт говорит, что времени поиска есть куда улучшаться.
Источники данных
Перейдем к следующему блоку вопросов, он будет более прикладным и связан с источниками данных, поставляемых c SIEM-системами. Первый и, пожалуй, один из ключевых вопросов, который я задал респондентам: а устраивает ли их список источников событий, поддерживаемых в SIEM?
![Рисунок 8 – Удовлетворенность поддерживаемыми источниками Рисунок 8 – Удовлетворенность поддерживаемыми источниками](https://habrastorage.org/getpro/habr/upload_files/de0/074/836/de00748368cdf833ecf13cb32ed7db3b.png)
Как мы видим, всё вроде даже очень неплохо. Список поддерживаемых источников скорее (55%) или полностью устраивает (13%) - 68% респондентов. Обратная ситуация у 33%.
Как же я "обожаю" округления. С точностью до десятых там:
54.7% и 12.5% с положительной коннотацией;
28.1%, 4.7% с отрицательной.
А вот на рисунке 9, мы можем увидеть насколько часто участвующие в опросе подключают уникальные источники событий?
![Рисунок 9 – Подключение новых источников данных Рисунок 9 – Подключение новых источников данных](https://habrastorage.org/getpro/habr/upload_files/662/37e/c29/66237ec29ca35c625f2b6d22ffb463b3.png)
В свою очередь, с историей добавления нового/уникального источника не сталкивалось только 6% опрошенных. Для остальных новых источников скорее рутина с разной степенью повторяемости.
С источниками событий вроде понятно, но SIEM же должен уметь в корреляцию, да?
![Рисунок 10 – Удовлетворённость списком правил корреляции Рисунок 10 – Удовлетворённость списком правил корреляции](https://habrastorage.org/getpro/habr/upload_files/ab7/625/6fe/ab76256fe8c875cecc808be4056ef493.png)
В итоге правила корреляции из коробки:
Скорее НЕ устраивают большинство опрошенных, а если быть точнее - 44%;
При этом полностью НЕ устраивает 23%;
В положительном ключе оценивают список правил корреляции – всего 33%.
А сейчас давайте посмотрим, как часто приходится пилить свои правила для уникальных источников?
Больше 5 раз в квартал этим занимаются больше половины, а именно 58% респондентов. Как обычно их связь на соседнем графике.
![Рисунок 11 – Частота создания правил корреляции для уникальных источников Рисунок 11 – Частота создания правил корреляции для уникальных источников](https://habrastorage.org/getpro/habr/upload_files/e06/055/6cd/e060556cd815e3f11360b24118394c25.png)
И здесь становится понятным, что новые правила под источники приходится делать часто.
Теперь предлагаю ознакомиться с привычными инструментами их создания. Поэтому следующий вопрос, который я задал респондентам, был связан с частотой разработки правил в конструкторе.
![Рисунок 12 - Инструменты для разработки правил корреляции Рисунок 12 - Инструменты для разработки правил корреляции](https://habrastorage.org/getpro/habr/upload_files/43a/36f/13c/43a36f13c8b5f9f4122c6706b6332b34.png)
И решения извечного холивара: «"наелозить" правило мышкой VS написать код/псевдокод» так и не случилось, поскольку итоги у нас получились следующими:
36% используют оба способа;
30% чаще "елозинг";
19% чаще код;
16% коррелятор не трогают.
Соседний график нам рассказывает кто эти люди.
Перейдем к следующему. Хорошей практикой при разработке является также версионирование и тестирование.
![](https://habrastorage.org/getpro/habr/upload_files/39f/e6f/39d/39fe6f39d6ef65d073a5dd6e0c8b22eb.png)
![Рисунок 13 – Наличие процессов версионирования и тестирования разработанных правил корреляции Рисунок 13 – Наличие процессов версионирования и тестирования разработанных правил корреляции](https://habrastorage.org/getpro/habr/upload_files/a5f/b39/8e6/a5fb398e6291e807250da8d934c5c369.png)
В этом вопросе, как оказалось:
Со мной согласны 47%, они ответили, что используют версионирование и тестирование;
Только тестируют это 33%;
При этом 14% опрошенных считают, что это всё от лукавого и правила нужно сразу деплоить в прод без всякого теста и версионирования.
На графике рядом показана корреляция с инструментами для написания правил.
И ...барабанная дробь... сколько же правил у нас на корреляторе?
![Рисунок 14 – Количество используемых правил корреляции Рисунок 14 – Количество используемых правил корреляции](https://habrastorage.org/getpro/habr/upload_files/2bf/408/1f6/2bf4081f699cb4121f4c040d09b60747.png)
Скажу честно, результат меня весьма удивил! Что мы видим:
Большинство участников ответили, что количество используемых ими правил составило от 100 до 500 42%;
На следующем месте оказались респонденты, применяющие от 50 до 100 правил - 34%;
А вот более 500 – 16%;
Только 8% опрошенных используют либо менее 50 правил, либо не владеют такими данными.
На соседней гистограмме показана корреляция количества правил и входящего потока EPS. Коллеги, со 100+ правилами, вы герои. Поддерживать такой объем и вручную - это настоящий подвиг.
А "на сладкое" вашему вниманию еще один холивар мой заключительный вопрос: Какой подход по "нормализации" данных для вас является более предпочтительным?
![Рисунок 15 – Предпочтительный подход к нормализации данных Рисунок 15 – Предпочтительный подход к нормализации данных](https://habrastorage.org/getpro/habr/upload_files/187/375/a99/187375a99c3208f69cf5607e9ab83a52.png)
И опять что-то интересное:
52% ответили, что "Все события могут быть нормализованы в любую модель данных, модель данных могут быть созданы, как вендором, так и самим пользователем";
38% адептов "Все события нормализуются в единую модель данных (пример CEF)";
и только 8% за вариант "Все события нормализуются в несколько заранее созданных вендором моделей данных, в зависимости от типа событий (Authentication, Object Access, Networks)".
Но, все-таки почему?
Да-да, выше я обещал, что вопрос про нормализацию будет последним, однако открытым остался самый главный вопрос статьи: почему везде "боль, тлен и безысходность?"
Опираясь на все полученные данные по итогам опроса, я презентую ниже подборку "болей".
Как говорил Михаил Николаевич Задорнов: "Готовы?"
![Рисунок 16 – Трудности эксплуатации SIEM (группировка по ролям) Рисунок 16 – Трудности эксплуатации SIEM (группировка по ролям)](https://habrastorage.org/getpro/habr/upload_files/f84/c64/b73/f84c64b73ebba747b1c48126495811d8.png)
![Рисунок 17 – Трудности эксплуатации SIEM (группировка по болям) Рисунок 17 – Трудности эксплуатации SIEM (группировка по болям)](https://habrastorage.org/getpro/habr/upload_files/148/a70/fb4/148a70fb4bd44a356c6f3915e646c760.png)
Сильнее всего у эксплуатантов болит от того, что SIEM не поддерживает нужный им источник, при этом они имеют возможность добавить его самостоятельно – так ответили 23% опрошенных. Также наиболее критичными моментами являются отсутствие возможности обновления SIEM без остановки работы всей системы (12%) и ее производительность - архитектура этого класса решений не позволяет выполнять нужное масштабирование (8%).
Перейдем к внедренцам. У них болит там же, только в несколько других пропорциях: 14%, 11% и 6% соответственно.
А у создателей болят лапки :3
Далее я попытаюсь подвести итоги всего вышенаписанного.
Во-первых, что сразу "бросилось" в глаза, так это частое использование SIEM в качестве Log Management. При этом, учитывая, что в инфраструктурах пользователей есть еще системы-потребители логов, и я подозреваю, что там ситуация с необходимостью хранить логи аналогичная. В итоге один и тот же набор данных хранится в 3+ системах одновременно (где-то тут всплакнул один Сакити Тоёда). Во многом из-за такого нерационального использования ресурсов не все опрошенные могут обеспечить необходимую глубину хранения данных в соответствии со своей же нормативкой.
Если говорить о более прикладных аспектах использования SIEM систем, то временем поиска скорее или полностью удовлетворены больше половины участников опроса. И "изкоробочные" источники также скорее устраивают более половины респондентов. Но на мой взгляд, такое "скорее" можно приравнять к тройке с плюсом по пятибалльной шкале, потому что сильнее всего болит именно отсутствие источников из коробки. При этом испытывать "боль" за квартал приходится 2-5 раз 34% и 6-20 31% опрошенных.
Перейдем к правилам обнаружения, и здесь стоит отметить, что "изкоробковые" правила корреляции большинство респондентов не устраивают, а количество боевых правил у большинства исчисляется сотнями.
Среди остальных участвующих осталось 20% смельчаков, деплоящих правила сразу в прод без тестирования. Тут можно только процитировать Максима Горького "Безумству храбрых поём мы славу".
В опросе было еще несколько пунктов, которые я решил вынести за скобки, например, вопрос: Как часто вы переносите разработанные правила корреляции между серверами SIEM? Чуть больше половины так или иначе сталкивается с такой необходимостью. При этом 41% не занимается переносом вовсе.
![Рисунок 18 – Частота переноса разработанных правил корреляции между серверами SIEM. Частота использования обогащения Рисунок 18 – Частота переноса разработанных правил корреляции между серверами SIEM. Частота использования обогащения](https://habrastorage.org/getpro/habr/upload_files/9b2/fec/5f7/9b2fec5f79be05e79323c9f5e26f1254.png)
Выше я упомянул про закономерную и понятную "боль" с источниками, а вот трудности из-за отсутствия возможности помодульного обновления SIEM для меня стали неожиданностью. Еще большее удивление вызвал высокий результат "невозможности скейлиться" с учетом повального ухода в "куберы". При этом боль, связанная с моделью данных, не вошла даже в топ-3.
![](https://habrastorage.org/getpro/habr/upload_files/94a/24e/da1/94a24eda1d274c9ad3c001adaa497ba2.jpg)
Кстати, о моделях данных. Доминирующего мнения получить так и не удалось. Первые дни опроса уверенно лидировал подход единой датамодели (CEF и ей подобные), позже вперед вырвалась кастомная дата модель. Выражая свое сугубо личное мнение, скажу, что связаны такие качели в первую очередь с эксплуатационным опытом. Конечно же укладывать всё в единую модель гораздо лучше точки зрения разработки, переносимости и далее по списку. Но на другой чаше весов находится расширяющийся набор источников и задач, которые не всегда могут вписаться в единую модель. Да и в перспективе возможность кастомизации несет больше плюсов, чем минусов.
Вместо заключения
Надеюсь, эта статья помогла и вам ответить на вопрос "Так где же правда?" в этом споре маркетинга и "полей". Задавайте вопросы, пишите комментарии (((=
Напоследок расскажу про само проведение опроса.
Его я проводил своими силами прося коллег "по цеху" распространить дальше. Бывали ситуации, что распространителей опроса, едва ли не "на вилы поднимали" за инициативу, объявляя ведьмой и несли на костер. Но в основном, сообщество весьма живо откликнулось, в какой-то момент опрос уже "отвязался" от меня лично и разлетелся по профильным чатам.
Всем участникам и распространителям ОГРОМАДНЕЙШЕЕ СПАСИБО!
Вот вам котик
![](https://habrastorage.org/getpro/habr/upload_files/2aa/804/ed4/2aa804ed406aa6fd6525035b6e83dc66.png)
UPD
Статью перенес в корп блог
AlexeyK77
Спасибо, хорошая статья, во всяком случае она поднимает проблему, которую принято заметать под ковер. Как эксплуатан SIEMа смутили некторые цифры:
В опросе поток событий до 10k определен в одну категорию. Но это реально огромный поток событий, даже для среднего банка будет достаточно 1.5-3к событий, это если конечно думать головой а не валить в сием весь мусор подряд. Я бы категорию до 10к разбил бы на категории (до 1к, 1-3к, 3-5к, больше 5к).
Во вторых, 100 правил это как то мало вообще. С учетом того, что сием часто еще и мониторит события на требования комплаенса по системам. Вижу тут несоответсвие потока событий и кол-ву правил коррелляции. По моей оценке 100 правил это минимальная норма для потока в 1к-3к епс. Хотя конечно все очень сильно зависит от истоников и типов событий.
Для представление о сложности SIEM не хватает цифры по кол-во источникао и кол-ву уникальных типов источников. Только EPS тут недостаточно.
С версионированием правил проблема, т.к. движки часто вообще не поддерживают текстовое предстваление правил и даже вытащить текст правила уже проблема. В общем тут в лучшем случае костыли сосбственного производства.
Но это все типовые мелочи сопровождения любой крупной корпоративной системы, а основную пробелму сиемов я вижу совсем в другом:
они не работают как антивирусы из коробки!
Поясню: представьте себе антивирусное решение, которое ты ставишь, но само оно ничего не ловит. В поставке есть редактор сигнатур, некторые сигнатуры для примера, но которые без тщательного тюнинга не работают и даже вредны. Тюнинг решения до вывода в продуктив требует огромного скила, все равно что самому свой антивирус написать.
Т.е. индустрия безопасности нуждается в сиемах, которые будутработать сами без тюнинга и закрывать 99% типовых зада мониторинга и лишь для 1% особых случаев нужен фремворк для своей кастомных задач. А по факту, если провести аналогию, это не продукт а фреймоворк - пилите все сами. В результате - СИЕМ могут себе позовлить только крупные конторы, а не все, треуют больших трат и главное - наличие скилованых спецов в штате. Т.е. тлен и безысходность.