Конкурс «Чего нам не хватает в SIEM»: победители и разбор полетов

image

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

В начале апреля редакция SecurityLab.ru объявила конкурс рецензий на системы SIEM (Security Information and Event Management). За два месяца мы получили более двух десяток отзывов ИБ-специалистов о том, чего им не хватает в таких системах мониторинга информационной безопасности, как HP ArcSight, IBM QRadar, McAfee ESM, RSA enVision, Symantec SIM, Cisco MARS, GFI ESM, — и в других, менее известных. Наше экспертное жюри внимательно прочло все письма и комментарии, и теперь мы готовы объявить результаты.

Победители конкурса:

I место — Николай К. (рецензия на RSA envision)

II место — Андрей Б. (рецензия на ArcSight и другие SIEM)

III место — Евгений Петров (рецензия на ArcSight)

Редакция свяжется с победителями и расскажет, как получить призы.

Нас спрашивали, будем ли мы публиковать рецензии, пришедшие на конкурс. Изначально это не планировалось, поскольку не все ИБ-специалисты согласны раскрыть свое критическое отношение к системам, с которыми работают; именно по этой причине мы предлагали два способа участия: можно было опубликовать отзыв как открытый комментарий либо прислать приватным письмом.

Однако мы готовы опубликовать рецензии трех победителей, если сами авторы на это согласятся (мы обсудим с ними этот вопрос при вручении призов). А пока для всех участников конкурса и других заинтересованных читателей предлагаем общий разбор присланных рецензий и полезные выводы, которые можно из них сделать. Автор обзора — один из членов жюри конкурса Олеся Шелестова, системный аналитик исследовательского центра Positive Research.

Чего нам не хватает в SIEM: подводим итоги

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

1. Определите спектр покрываемых задач перед покупкой SEIM от определенного вендора

Как правило, каждый вендор хорош в узком спектре выполняемых задач. Кто-то хорошо интегрируется со СКУД и может работать с этими данными, кто-то с IAM, кто-то со snort-like-системами... Если вы планируете обрабатывать события и с бизнес-приложений, и с сетевых экранов — скорее всего вам придется написать свою вторую систему. Универсального швейцарского ножа в вопросе обработки событий не существует.

2. Оценивайте, насколько хорошо решает ваши задачи тот или иной продукт

К примеру, по syslog можно передать события от Snort\Surricata. Можно написать правила корреляции для работы с данными по извлеченным полям. Но для корреляции с наличием на ассетах уязвимостей вам предстоит горы свернуть. Во-первых, понадобится единый унифицированный справочник с уязвимостями, отдаваемыми со Snort, и уязвимостями от сканеров. Во-вторых, механизмы корреляции должны позволять при получении события об атаке со Snort проверить наличие уязвимости на этом сервисе и ассете данной уязвимости. Считаете, что это все возможно? Возможно, если у вас ассет со статическим IP-адресом. Нет ложных срабатываний? А учитываете ли достижимость до данного сервиса? Не закрыт ли межсетевым экраном порт? Прошел ли трафик до сетевого порта на ассете с данным сервисом?..

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

Следует учитывать, в каком формате и с помощью каких протоколов и API ваша будущая система может быть связана с уже имеющимися и новыми комплексами. Скорее всего, вам понадобится работа с инцидентами во внешней системе, запуск внешних программ и скриптов по событию, интеграция со сканерами, NetFlow, DPI. Вполне возможно, что вы захотите собирать и обрабатывать статистику по угрозам в больших данных. Скорее всего, вам для SOC необходим будет dashboard. Только не со стандартными графиками, а со «семафорами». Сможет ли выбранная система вам это дать?

4. SIEM не равно log management

Выбирая между SIEM и LM, подумайте, что именно вы хотите получить и за какую цену. SIEM стоит дороже, но часто это оправданное решение. SIEM должен не просто собирать логи и выводить что-то в консольку оператору, но и автоматически регистрировать алерты. Оператор не должен смотреть на поток бегущих событий, он должен уже работать с выводами, инцидентами и статистикой! Если у вас много ложных срабатываний – значит необходимо настраивать правила корреляции.

5. 10 разных SIEM и LM — как мертвому припарка. Имейте единую консоль

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

6. Рассчитывайте производительность с учетом роста инфраструктуры

Вспомнилась пара случаев, когда оперативно разрешить инцидент было практически невозможно. В одном случае пришлось выгружать события в новую оперативную базу (процесс занял около трех часов), во втором быстрее было выгрузить Windows event log в оригинальном формате и разослать его всем, кто участвовал в расследовании.

7. Покупая SIEM — покупайте к нему специалиста

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

8. Хотите нормализацию и вот тот, «синенький» источник событий? Готовьтесь кодить!

Увы, но на практике почти всегда так. Даже для стандартных источников порой приходится переписывать шаблоны, поставляемые по умолчанию. Да, в современных SIEM достаточно много входных путей: syslog, snmp, wmi, импорт событий из файлов. Но зачастую чтобы отправить логи из системы, вам придется сначала выгрузить эти события в файл, потом написать шаблон для нормализации полученных событий, а потом «научить» систему с ними обращаться.

9. Миллион алертов или десять?

Вспоминается жизненный пример, когда я на одном из форумов подсказала человеку, как настроить в Symantec SIM правила формирования инцидента. Наутро возник ожидаемый вопрос: как удалить миллионы инцидентов?

10. Доступная поддержка, багрепорты на сайте вендора, частота обновлений

Перед принятием решения о приобретении SIEM — загляните на форум или в блог на сайте производителя. Продукт должен обновляться не реже двух раз в год. Должны появляться новые возможности для лучшего обнаружения угроз. Имейте в виду: то, что вы купите, проработает у вас по меньшей мере ближайшие 5—7 лет. Некоторые компании обожглись, купив Cisco MARS, Netforensic и Symantec SIM. Да, эти продукты будут работать, но только если у вас есть команда крутых экспертов ИБ и крупный отдел разработки.

Не забывайте: вы купили молоток. Какие гвозди вы будете забивать и как — это ваша головная боль. Зачастую клиент приобретает то или иное решение — и начинает требовать от вендора и интегратора невозможного, говоря «я хочу, чтобы это работало так». Поймите, что продукт разрабатывается с учетом мнения многих экспертов, он работает так, как он может и должен работать. Поэтому и следует изначально рассчитывать — с какими данными будет работать продукт, может ли он эти данные обработать, какие задачи должен решать, какие выводы может сделать, какие есть средства взаимодействия (API, импорт и экспорт данных из системы).

А чего же не хватает на самом деле?

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

1) Большой красной кнопки

«Включил и все работает». Работать-то будет большинство решений. С встроенными правилами корреляции. И при этом даже что-то «ловить». И возможно, подключит какие-то источники автоматически. Но поймите, что на практике каждая инфраструктура и угрозы в ней — индивидуальны.

2) Гибкого, интуитивно понятного поиска по событиям (форенсики)

На самом деле, он есть везде. В некоторых системах даже графический: вы можете набрасывать кубики вместо построения длинного языкового запроса (и учиться языку, смотря на автоматически отображаемые запросы). Где-то язык запросов реализован гибче, где-то неудобен. На мой взгляд, самый развитый язык у Splunk (это решение класса LM). Поверьте, порешав с любой системой, даже без чтения мануалов, ежедневно возникающие кейсы, вы привыкнете к языку и откроете для себя массу возможностей.

3) Гибкости в языке описания правил оповещения

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

4) Работы SIEM не только с событиями, но и с другими данными

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

5) Ассетов и возможности агрегации разнородных данных

Здесь действительно существует проблема. Ассет в понятии всех систем — это IP плюс (не всегда) FQDN. Да, в некоторых системах есть еще и MAC-адрес и информация об уязвимостях. Но как только IP у актива сменится или запустится вторая установленная OС — возникнет проблема. Это будет новый ассет. А значит, будет потеряна масса важной информации: какие угрозы были на нем, кто из сотрудников работал, права доступа, пути достижимости... И это — если касаться только случай «один актив — один компьютер». А ведь можно выделить еще массу активов, интересных на всех этапах жизненного цикла: пользователь, данные, база данных, бизнес-процесс...

6) Автоматически подключаемых новых источников и «понимания» событий от них

Те, кто уже имел опыт установки и настройки SIEM, знают о сложностях нормализации событий. По пессимистичным заявлениям в рецензиях, даже у топовых вендоров «лишь 5 из 300 коннекторов работоспособны». Это связано с массой нюансов. Например, правила нормализации, написанные для английской Windows 8, не будут работать для событий той же Windows 8 на пигмейском языке. Если у вас есть промежуточный ретрансмиттер событий, который собирает события, а потом передает на SIEM (syslog к примеру) — появится еще одна проблема с неверным ip_src\ip_dst в событиях в виде этого промежуточного сборщика.

7) Поддержки мультиязычности интерфейса продукта и источников

Количество жалоб в рецензиях на отсутствие русскоязычного интерфейса потрясает. На самом деле, интерфейс на английском - это все же лучше, чем на китайском. Привыкнуть можно. Совсем другое дело — источники событий на различных языках. Вполне ожидаемо, что специально созданное правило корреляции, генерирующее алерт при интерактивном входе с системной учетной записью «Администратор», — вовсе не сработает, если войдет администратор китайской операционной системы.

8) Возможности подключения нестандартных источников и настройки собственных парсеров

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

Кроме того, рецензенты указывали на нехватку:

9) интуитивно понятных SDK,

10) API,

11) средств кастомизации отчетов,

12) средств инцидент-менеджмента.

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


или введите имя

CAPTCHA