Как НЕ надо выбирать SIEM?

На сочинском "Коде ИБ. Профи" (кстати, на прошлой неделе стали доступны все презентации и записи с него) у Льва Палея был мастер-класс о том, как выбирать средства защиты, где среди рассматриваемых в качестве примера решений были системы управления событиями ИБ (SIEM). И у меня в загашнике давно был черновик заметки на схожую тему. Но я не стану отнимать хлеб у Льва (тем более, что у него мастер-класс был практический - с заданиями и их разбором) и напишу о том, как НЕ надо выбирать SIEM :-) Тем более, что за последнее время, в ряде проектов по SOC, в которых я участвую в России и странах СНГ, накопились определенные наблюдения, которые и станут основой этой заметки.

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

Не выбирайте SIEM, потому что это модно

Ну это вроде и так понятно. Выбирайте не то, что модно, а то, что нужно. Это простая истина применима не только к SIEM, но и вообще к любому хайпу - от SOCа до блокчейна, от WAF до CASB. Для этого вам, правда, нужно знать, что нужно :-) А поняв это, вы поймете, как этого достичь и, только потом, сможете определиться с инструментарием для этого.

Не выбирайте SIEM под требования регуляторов

Регуляторы, и ФСТЭК, и ФСБ, и ЦБ, сегодня много говорят про необходимость непрерывного мониторинга ИБ и устанавливают требования к решениям этого класса. Особенно важно это при интеграции вашей инфраструктуры мониторинга с той же ГосСОПКА или ФинЦЕРТом. Но... обратите внимание, что иногда гораздо проще и лучше - строить систему мониторинга такой, какой ее хотите видеть вы (исходя из ваших условий), а на стыке с ГосСОПКОЙ или ФинЦЕРТом поставить какой-нибудь шлюз, который будет посредником между вами и регулятором и просто передавать нужные данные туда и обратно. Не ведитесь на рекламу ряда отечественных вендоров, которые говорят, что у них встроенная поддержка взаимодействия с ГосСОПКОЙ "из коробки". Зато другой функционал, который вам и нужен в первую очередь, там может быть не очень. В конце концов, если выбранный вами SIEM из-за "печати" "Approved by GosSOPKA" не сможет видеть инцидентов, то и отдавать вам будет нечего. А вот функция "генерация отчетов о соответствии требованиям регуляторов" очень неплоха; главное, чтобы эти отчеты были по регуляторике, которая применима к вам. В любом случае помните, решение по безопасности нужно для обеспечения вашей безопасности, а не требований регуляторов.

Не выбирайте SIEM, потому что вы строите SOC

Все умные люди, говоря о SOCах, обычно делают знак равенства между двумя фразами "имею SOC" и "имею SIEM", но это не совсем так. Достаточно просто вспомнить, что вы можете аутсорсить свой SOC у внешнего поставщика услуг, к которому вы предъявляете требования по скорости реакции, гарантиям, охвату вашей инфраструктуры, но точно не по тому инструментарию, который он должен использовать. Это его прерогатива, раз уж вы выбрали его из множества аутсорсинговых SOCов; доверьте ему и выбор SIEM. Вы вообще можете не знать, какой SIEM у вашего SOC-as-a-Service; вы же платите за услугу с понятными входными и выходными данными и вам не так уж и важно, что у нее внутри.

Не выбирайте SIEM, потому что он в правом верхнем углу магического квадранта

Обратите внимание, я не говорю, не выбирайте SIEM из этого угла квадранта. Я говорю, не выбирайте, потому что он там. Чувствуете разницу? Если SIEM попал в этот угол, значит он достаточно хорош (а вы же хотите все самое лучшее, не так ли?). Но вам нужна не медаль на грудь и не "мировой рекорд",  а решение стоящих перед вами задач. Возможно вас устроит что-то более простое и не столь дорогое? Возможно 50% функционала самого крутого SIEM в мире вам просто не нужны? Так зачем за нее платить (а также за специалистов, которые знают как работать с самым крутым SIEM в мире)?

Не выбирайте SIEM, потому что вас зачморили коллеги и говорят вам "Ты что, с Урала?"

Помните советский фильм "Самая обязательная и привлекательная"? Там был эпизод, где главную героиню привели к, как сейчас модно говорить, байеру, который предлагал то одну модную штуку, то другую, то третью. А на изумленный вопрос героини "А зачем это?", ее сравнили с деревенщиной, припечатав, ставшим классикой, "Ты что, с Урала?" Не выбирайте конкретный SIEM и вообще SIEM, потому что это модно и у всех ваших коллег это есть.

Не выбирайте SIEM, потому что вам надо выстроить сбор логов

Для сбора логов выбирайте решение соответствующего класса -  SIEM тут будет избыточен. Если, конечно, у вас нет четкого плана продержаться на вашем текущем месте еще лет пять, на которые у вас уже есть стратегия развернуть полноценный мониторинг ИБ, с долговременным хранением, корелляцией, оркестрацией, контролем поведения, анализом сетевого трафика и т.п. Если вы не имеете персонала, который будет пялиться в монитор SIEM круглые сутки или хотя бы в режиме 5х8 или если у вас нет задачи оперативного реагирования на инциденты (а ее может и не быть), то зачем вам SIEM? Ограничьтесь обычным LM-решением.

Не выбирайте SIEM по фичам и обещаниям вендора

Часто, смотря материалы вендоров, мы попадаем в ловушку "kill feature", которая означает, что у продукта есть какая-то классная фишка и вокруг нее выстроен процесс продаж. Помните анекдот про студента, сдающего экзамен по зоологии, который успел выучить только билет про блох? Вот так и тут. Например, у SIEM классная фишка - он по умолчанию интегрируется с ГосСОПКА, а вы, как субъект КИИ обязаны это сделать. И вот вокруг этого начинаются танцы продаванов с бубном, уводя вас в сторону от такой, например, проблемы как низкое количество событий в секунду (EPS), которое может обработать одна нода SIEM. И чтобы работать в вашей организации вам нужно поставить 4 ноды, в то время как у другого SIEM, у которого нет встроенной "килфичи" работы с ГосСОПКОЙ, достаточно всего одной ноды, да еще и с запасом.

Или другой пример. Продавец SIEM вам говорит, что вы сэкономите, купив его решение, так как у него SIEM и SOAR и IRP - все в одном флаконе. А вы же понимаете, что хотя бы IRP, но вам нужна (а может и SOAR вместо IRP). Вы берете этот SIEM, но потом оказывается, что он не работает в multi-tenant архитектуре, а у вас холдинг и каждому предприятию нужен свой "кусок". Или multi-tenant поддерживается, но нет иерархии SIEM "главный-подчиненный", которая вам нужна для охвата 9 часовых поясов и размещения нескольких центров мониторинга по России и странам СНГ, в которых у вас размещены точки присутствия. Смотрите сначала на архитектуру, а потом на конкретные функции, тем более обещаемые.

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

Не выбирайте SIEM, потому что он поддерживает искусственный интеллект

Просто повторю набор вопросов из моей большой презентации по искусственному интеллекту в ИБ, которую я читал на московском "Код ИБ. Профи", которые должны быть заданы вендору, заявляющему о наличии ИИ в его продукте.

От ответов на них зависит, понимает ли вендор, что такое ИИ и машинное обучение в частности или нет? И стоит ли вестись на всю эту хайповую тему с магической заменой кучи конструкций "IF THEN" в коде или корреляционном правиле на словосочетания "искусственный интеллект", "нейросеть" или "глубокое обучение". Для того, чтобы назвать атакой 3+ попыток неудачного входа в систему с одной учетки за короткий интервал времени, много ума не надо. В отличие от идентификации кражи учетной записи по определению нетипичного места входа в систему, опираясь на результаты кластеризации таких попыток за большой интервал предыдущего времени, опираясь именно на ваши данные. ИИ в SIEM есть и он может решать свои задачи - вопрос в том, знаете ли, как выжать максимум из него, и знает ли это локальный поставщик?

Не выбирайте SIEM, потому что у него отличная корреляция

Это древняя песня, которую я помню еще с конца 90-х годов, когда внедрял свой первый SIEM в одном из национальных банков на постсоветском пространстве. Заказчик тогда тоже купился на рассказ про корреляцию и вот это вот все, но реальность была совсем другой. Несмотря на наличие правил корреляции "из коробки", которыми так кичился вендор, пришлось писать много своей логики, отличавшейся от задумки производителя. И это при том, что число источников, подключаемых к SIEM, было на порядки меньше, чем у современных решений по мониторингу. По рынку ходит цифра, что сколько бы правил корреляции в вашем SIEM не было, только 20% их них можно применять безболезненно. Поэтому надо четко осознавать, что писать правила корреляции под ваши use case придется вам (или внешнему интегратору за дополнительные деньги) и все слова о "уникальной системе корреляции" превратятся в реальности в тыкву.

Не выбирайте SIEM, потому что он имеет универсальный коннектор ко всему

А подключать к этому коннектору ваши решения будет кто? Бывает так, что с универсальным коннектором может работать только сам вендор и больше никто. И вы сразу стали заложником конкретного вендора. И если вам, например, нужно написать коннектор к системе защиты вашего промышленного сегмента, а она куплена в единственном экземпляре и есть в России только у вас, то как вендор напишет тогда коннектор к тому, что он у себя даже развернуть не может и специалистов по чему у него нет?

Не выбирайте SIEM, у которого нет плана развития

Я уже писал выше, что надо проверять все заявленные и нужные вам фичи в рамках пилота. Не менее важно, чтобы у SIEMа был четкий план развития (с соответствующими подтверждениями), который учитывает тенденции рынка и вашу стратегию развития. Возможности масштабирования, рост производительности, новые коннекторы для интеграция с различными решениями (не забывайте учитывать все скрытые затраты такой интеграции, которые лягут тяжким бременем на ваши плечи), поддержка каких-либо стандартов (от STIX/TAXII и MITRE ATT&CK до ГосСОПКИ и ФинЦЕРТа), новые функциональные модули, новые корреляционные возможности, обнаружение новых атак и т.п. Вроде бы очевидные вещи, но часто бывает так, что продукт берется ради сиюминутных задач, а потом оказывается, что вендор и не развивает свой продукт, делая только косметические правки, оставаясь на позади конкурентов. Такое было в свое время с netForensics - лидером рынка SIEMов, который сдулся и прекратил свое существование. Кстати, план развития тоже не гарантия, что продукт будет развиваться согласно ему. Но это уже ситуация, которая не предсказуема и с которой приходится просто мириться, на ходу меняя решение на другое.

И уточните, как вендор будет учитывать ваши новые хотелки? Например, у иностранных вендоров есть такое понятие как "бизнес-кейс", который имеет вполне конкретное (у каждого свое) денежное выражение. Вендор включит ту или иную фичу в план разработки, когда один или несколько заказчиков, готовы будут заплатить в краткосрочной перспективе за эту функцию. Если вы очень маленький заказчик, то даже очень важную фичу вам писать никто не будет, хотя в план (дальний) могут и включить. У российских вендоров SIEM ситуация чуть проще - их обороты гораздо меньше оборотов любого из их заказчиков и поэтому они стараются прислушиваться к мнению "народа" и оперативно реализовывать все новые "хотелки". Но все-таки лучше этот вопрос уточнить на берегу, перед окончательным принятием решения.

Сюда я бы отнес и вопрос о санкциях. Ситуацию со Splunk знают все. Понятно, что вещь это сложно предсказуемая (Splunk просто ушел без объяснений причин), но держать в голове такой риск надо (если для вас это риск, как для отечественных государственных или военных структур).

Не выбирайте SIEM, потому что у него харизматичный лидер с горящими глазами

Проверьте, что за этим лидером есть команда, которая готова развивать и поддерживать продукт. Извините, никто не вечен и все может произойти в жизни - от рождения детей до попадания в ДТП на "джихад-такси" Яндекс.Такси. Горящие глаза и делающие руки - это классно, но любая разработка - это процесс, который не должен зависеть от одного винтика, вынув который, все ломается. К иностранным вендорам этот совет малоприменим, а вот в России такие случаи бывают. 

Не выбирайте SIEM, потому что он поддерживает ваши средства защиты периметра

Первые SIEM появились в конце 90-х годов, чтобы сократить число ложных срабатываний у систем обнаружения вторжений и межсетевых экранов. С тех пор число источников событий безопасности и объем этих событий возросли многократно. Насколько выбираемый вами SIEM способен работать с такими источниками? DLP? CASB? AWS CloudTrail? Azure Monitor? UEBA? EDR? HRM? СКУД? SCM? ERP? СУБД? Иные бизнес-системы?

Не выбирайте SIEM, у которого нет реагирования

Вам для чего нужен мониторинг ИБ? Чтобы видеть атаки или чтобы их отражать или купировать последствия? Вот так и SIEM нужен не только для того, чтобы видеть как можно больше, но и для того, чтобы оперативно реагировать на обнаруженное. Поэтому неплохо бы, чтобы выбираемый вами SIEM знал как реагировать и, желательно, применительно к вашим же средствами защиты (напрямую, через скрипты или через какой-либо SOAR). 

Не выбирайте SIEM, если не знаете, где взять людей для работы с ним

Очевидно.

Не выбирайте SIEM, если у вас нет процесса мониторинга ИБ

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

• Что вы хотите собирать?
• Где это находится?
• Кто отвечает за эти источники?
• Как и в каком формате хранятся эти данные?
• Как отдаются эти данные?
• Что надо предпринять, чтобы забрать эти данные?
• Как обеспечивается целостность и непротиворечивость этих данных?
• Что вы будете делать с этими данными?
• Сколько надо хранить эти данные?
• Какие виды анализа вы будете проводить над этими данными? 
• Как вы управляете временными метками в вашей инфраструктуре?
• Кто имеет доступ к этим данным?
• Насколько структурированы эти данные?

Вот только небольшой список вопросов, на которые надо получить ответы до начала выбора SIEM.

Не выбирайте SIEM с непонятным TCO

По результатам общения с вендором вам все понравилось и вы готовы заплатить кругленькую сумму за систему мониторинга событий ИБ. Но... посчитайте TCO для него. На тестах оказалось, что вам нужна иная конфигурация, чем вы изначально рассчитывали? Вам нужна лицензия на большее число EPS, чем думали изначально? Выбранное или рекомендованное вендором железо "не тянет" и требуется более мощное? Ваша архитектура потребовала новых коллекторов? Курсы обучения по SIEM в России не проводятся и надо ехать в Европу (а вас по приезду развернули, потому что вы под санкциями, несмотря на полную предоплату, - реальный случай)? Вы не учли размер хранилища под собираемые события ИБ (кстати, вы в курсе, что будет, если на ваш SIEM подадут больше EPS, чем надо, или база переполнится?)? Вы не заложили стоимость написания коннекторов под ваши специфические источники? Есть вендора, которые предлагают к своим решениям полную калькуляцию всех статей расходов, которые могут понадобиться для развертывания и эксплуатации SIEM с расчетом на 12, 24 или даже 36 месяцев. Ваш вендор вам такое может сделать с учетом вертикального (число EPS) и горизонтального масштабирования (число и типы источников)?

 Не выбирайте SIEM-вендора - выбирайте SIEM-партнера

В отличие от МСЭ, EDR, NGIPS или SIG, решение по мониторингу событий ИБ требует гораздо более тесного взаимодействия с его производителем (тоже можно сказать и про DLP, и про другие прикладные ИБ-игрушки). Это не коробка, которая работает по принципу "поставил и забыл". Работы с новыми источниками, понимание методов анализа, разработка правил корреляции, масштабирование, расчет TCO, обучение модели ML... Да мало ли еще тем, по которым вы будете постоянно общаться с производителем вашего SIEM. Готов ли вендор к этому? Готовы ли вы к этому?

 Не выбирайте SIEM как самодостаточную систему

Как вы будете использовать SIEM? Это важный вопрос. Не для чего, а именно как. Вы планируете ее использовать как самодостаточное решение или интегрировать с IRP/SOAR, TIP, NTA, UEBA, EDR, CASB, CMDB и другими решениями, которые вместе позволят выстроить вам цикл управления инцидентами в вашей инфраструктуре? Если второе, то смотрите на то, с чем и как может интегрироваться выбираемый вами SIEM.

Вот таким получился список из почти двадцати "как не надо" выбирать SIEM. Допускаю, что их гораздо больше. Главное, чтобы этот список был прочитан, критически обдуман и воспринят. Тогда быть может у нас будет гораздо меньше неудачных внедрений SIEM, а нам в проектах по аудиту SOCов придется реже ставить самый низкий уровень зрелости SOC из-за того, что заказчик не потратил чуть больше времени на правильный выбор правильного SIEM, который, что ни говори, но пока для многих является ядром центра мониторинга ИБ.