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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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