Как-то раз наш начИБ Алексей Дрозд (aka @labyrinth) оказался в эфире AM Live – медиа собрало коллег по цеху обсудить будущее SIEM. Компания подобралась отменная: IBM, Positive Technologies, Micro Focus, Kaspersky, RuSIEM, мы и Solar JSOC. Обсудили много всего – больше трех часов эфира, без шуток!
Так как прозвучало много дельных мыслей, перескажем суть дискуссии (для тех, кому лень смотреть запись; кому не лень – рекомендуем): что SIEM представляют собой сейчас, что должны уметь и куда двинутся дальше. А на закуску дадим слово Алексею – он поделится выводами, к которым пришел в итогеи пояснит за заголовок.
И пока не ушли в большой разговор, пользуясь случаем зовём вас на наше Road Show о SIEM. Проведём его в Санкт-Петербурге (30 ноября), в Москве (1 декабря), а также онлайн (тоже 1 декабря). Зарегистрироваться можно по ссылке.
И обратно к основной теме.
SIEM кончились, не успев начаться?
(Здесь и далее по ссылкам в заголовках – таймкоды на фрагменты обсуждения, чтоб не быть голословными).
На мировой арене SIEM как технология появилась, по разным оценкам, 10-15 лет назад. Это уже зрелые продукты, хотя в сравнении с условными антивирусами все еще выглядят молодо. И вдруг в 2021 году IDC предрекает рынку SIEM глубокую стагнацию: рост в пределах 4-5% на ближайшие 5 лет, никаких технологических прорывов. Западный заказчик сокращает внедрения. Вендоры не предлагают нового функционала. SIEM захиревает и скоро, видимо, окончательно сдаст позиции всевозможным SOAR’ам, UEBA’м и XDR’ам. А мы-то радовались – сделали свою систему и только созрели, чтобы широко представлять ее на рынке, как тут такие новости.
При этом по субъективным ощущениям внимание к SIEM наоборот усилилось. Наши опросы показывали, что с 2017 года обеспеченность SIEM-системами в российских компаниях выросла на 7%, динамика не замедлилась даже в пандемийный кризис. По темпам внедрения своей SIEM тоже видим подтверждение тенденции.
Но субъективным впечатлениям верить нельзя. Что у коллег по рынку?
Фото с Anti-Malware Live
По словам грандов (IBM, Micro Focus), растет не столько число внедрений, сколько их объемы, а также количество доработок по индивидуальным запросам (а это говорит, что SIEM не пылится, а вовсю используется).
Взрывной рост рынка произошел в начале десятых, когда российский энтерпрайз только начал закупаться SIEM по примеру своих западных коллег. Сейчас решения становятся актуальными для более мелкого бизнеса. Например, небольшие компании, особенно из финансового и сопредельных секторов, стремятся выполнить требования закона (внедрять SIEM предписывают стандарты ЦБ, приказы ФСТЭК №235 для объектов КИИ и №21 для защиты персданных, другие нормативные акты). В этом сегменте нет астрономических сумм внедрений, потому на общую картину он влияет мало.
Но динамика, очевидно, есть, потому что есть спрос. Подтверждение этому – появление новых игроков на рынке, вроде нас или «Лаборатории Касперского». Как правило толчком к решению выпускать «непрофильный» продукт выступает клиентский запрос. К нам, например, несколько лет назад пришел давний заказчик и без обиняков сказал – не хотим дорогущий «комбайн», сделайте нам вычитку логов быстро, просто, из коробки, и чтобы хорошо работало с вашей DLP. И мы сделали. Коллеги из Kaspersky подтверждают: спрос на SIEM у многих компаний рождается из точечной задачи, и, если она состоит в контроле другого защитного ПО, логично обращаться к его создателям.
Программа минимум, или что должна уметь SIEM и что из этого действительно нужно?
Итак, в новых реалиях средний и малый бизнес дорос до «надо» и «хочу», но пока не знает, «как». Взять тот же комплаенс: выполнять требования регулятора – вполне подходящий мотив, чтобы взять под контроль события безопасности в компании. Тем более, что собрать и посмотреть логи практически любой сисадмин в состоянии. Но все же соорудить что-то, функционально похожее на SIEM, под силу не каждой компании. Поэтому большинство, согласно опросу AM, в случае необходимости обращается к вендорам – 64% зрителей эфира указали, что используют коммерческие, а не самописные или опенсорсные SIEM.
[IMG alt="Результаты опроса AM Live: Какой тип системы сбора событий вы используете?
"]https://habrastorage.org/r/w1560/ge...f3a2eb0c4f0231fb1f12d6e7e.png[/IMG]Результаты опроса AM Live: Какой тип системы сбора событий вы используете?
Проблема в том, что готовое «к бою» решение от вендоров часто бывает начинено, как звездолёт. Кажется, что современные SIEM умеют все и сразу: и в контроль источников, и в аналитику, и в прогнозирование, и в комплаенс, и в инвентаризацию, и в превент… А на практике оказывается, что такой насыщенный функционал может выйти боком. Заказчик такому изобилию не радуется, потому что система становится слишком сложной, разворачивается месяцами, чтобы с ней работать – нужно месяцами же учиться.
А что из этого всего реально нужнее и что нужно контролировать в первую очередь? Это самый популярный вопрос и в чате во время эфира, и, чего греха таить, у большинства заказчиков при первом запуске.
Отвечая, участники дискуссии сформулировали более-менее универсальный минимум задач, которые стоит решать с помощью SIEM на старте:
· контроль аутентификации;
· контроль изменений прав пользователей/групп;
· отслеживание перемещений по периметру;
· выявление атак на Active Directory;
· использование матрицы Mitre Att&ck или БДУ;
· инвентаризация оборудования и ПО.
Дальше требования к функционалу SIEM зависят от необходимости углубляться в специфику каждой конкретной задачи.
Потом идут индивидуальные потребности заказчиков. Например, компания может решать с помощью SIEM бизнес-задачи: оптимизировать инфраструктуру, наблюдать за работоспособностью процессов. Коллеги рассказывают, что не раз видели, как SIEM в живой практике используют как BI-систему.
Другой пример: есть специфическая задача по контролю сложной филиальной сети. Нужно разбираться с объемами и маршрутизацией трафика, чтобы сетка не легла, события при этом не терялись, а в итоговом результате учитывались уникальные настройки каждого филиала, но синхронизировались и складывались в единую картину. Или совсем просто (нет): есть в компании КИИ – нужна поддержка ГосСОПКА, есть критичное самописное ПО – нужна возможность подключить его как источник и не пос(е/и)деть в процессе.
Реально ли в тесте SIEM понять, подходит ли вам система?
Выбор SIEM должен начинаться с четкой постановки задач и отсева избыточного функционала, чтобы не платить больше.
Лучше всех свои задачи понимает заказчик, но загвоздка в том, что конкретика в запросах, как аппетит, приходит во время еды. Коллеги по рынку говорят, что реальное понимание у клиентов приходит только на втором-третьем «пилоте». До тех пор неразбериха приводит к неверным расчетам за лишнюю «мишуру» или неудовлетворенности результатом – ваша SIEM, мол, не работает.
Мы все же убеждены, что хороший тест вполне решает проблему «не знаю, что хочу» у заказчиков-новичков. Если посмотреть на стандартный ход «пилотов», становится ясно: во многих случаях тест не удается, потому что заказчика не подстраховали. Ведь слово-то одинаковое, а под пилотом все понимают разное.
Например, мы делаем ставку на обучение. Часто обнаруживается, что даже опытным спецам со стороны заказчика требуется дополнительная поддержка. Если SIEM в компании занимается ИТ-отдел, его нужно переориентировать на контроль не только работоспособности сервисов, но и их уязвимостей, контроль действий пользователей. Если функцию ИБ выполняет «классическая» служба безопасности, вендор, по сути, должен стать внешним ИТ-консультантом и помочь прокачать технические навыки.
Поэтому у нас кроме персонального менеджера, инженеров и аналитиков каждую компанию «ведет» отдел внедрения. Это сотрудники, которые разбирают с клиентами буквально каждую кнопочку и галочку в интерфейсе. На обучение работе с продуктом отводится не меньше пяти часов, чтобы и подкрутить настройки, и обкатать сценарии угроз, варианты реагирования на сбои и расследования инцидентов. Мы уже в курсе типичных «болей» и можем подсказать, куда обратить внимание – то ли на комплаенс, то ли на капризные источники, то ли на позабытые хосты.
В результате подходим к каждому пилоту как к «боевому» внедрению за деньги. И с помощью практического обучения рассчитываем, что на выходе у клиента в команде будет аналитик, хорошо знакомый с системой и понимающий, на что она способна. Конечно, SIEM – системы сложные, но если подойти к тесту с умом, то и результаты заказчик получит чуть ли не с первого включения.
Требовать ли доработок от вендора?
Только 20% заказчиков довольствуются правилами корреляции и другой аналитикой из коробки. Коннекторов тоже порой оказывается недостаточно, потому что в IT-инфраструктуре всегда достаточно и чего-то самописного, и каких-то древних версий, которые не дружат с Syslog. Поэтому систему нужно донастраивать, подключать нетипичные источники данных, писать под них аналитику.
Результаты опроса AM Live: Чей контент для обнаружения (правила) вы используете?
Клиенты способны на это и сами, но производителям SIEM это сделать гораздо проще. Для вендора сотрудничать с производителем оборудования/ПО, к которому делается коннектор, – правило хорошего тона. Это позволяет определить оптимальный набор передаваемых в SIEM данных, сформировать модель угроз, наиболее характерных для источника, вместе написать правила корреляции. У конечного потребителя вряд ли есть возможность запросить у разработчика такие данные, по крайней мере, это требует куда больших усилий.
Поэтому, если запросы на помощь по какой-то задаче от клиентов повторяющиеся и актуальны для разных компаний – мы делаем новые коннекторы/правила и выпускаем в основном релизе. Более распространенная среди вендоров практика – предложить доработки за деньги или привлечь третью сторону. Многие эксперты (но не мы) сходятся в том, что к SIEM должен «прилагаться» хороший интегратор.
Чаще всего обращение к вендору чревато для клиента лишними затратами ресурсов и трудочасов. Поэтому доплачивать за доработки готовы только 17% заказчиков. С учетом того, что компании и так считают, что SIEM – это дорого (мы баловались опросом в нашем ТГ-канале), больше трети пользователей выбирают самостоятельно кастомизировать свои системы.
Это естественное положение вещей, и если относиться к SIEM как к решению для «взрослых» продвинутых пользователей – нет проблем. Но вряд ли таких много среди небольших компаний, которые только открыли для себя автоматизированный мониторинг ИБ. Как быть с ними?
Увы и ах – им тоже придется учиться плавать. Ни один вендор не в состоянии всюду подстелить для заказчика соломку, как ни один родитель не в силах уберечь ребенка от набитых шишек.
Так что отличает хорошегородителя вендора? Он старается максимально облегчить пользователю жизнь, когда тот отправляется «в свободное плавание».
Нам повезло, с самого первого релиза создание нашей SIEM требовало соблюдения этого принципа. Мы смотрели на систему глазами новичка: а что, если тут вместо консоли с кодом сделать интерактивный конструктор? (так у нас работает создание правил кросс-корреляции). А что, если сделать шаблон коннектора, который пользователь сам сможет подключить к чему угодно? (сделали готовые скрипты для PowerShell, подробно рассказывали, как это работает, вот здесь). С позиции практиков – если разработчику приходится водить клиента по продукту «за руку», это не очень хороший продукт. Поэтому мы все настройки реализуем по принципу «три галки в интерфейсе», а не «выучи ЯП и напиши сам».
SIEM на аутсорсинге – реально ли?
Приходится констатировать, что даже в идеальном исполнении SIEM-системы вряд ли станут проще в использовании. Поэтому в ходе беседы мы пришли к выводу, что в новых условиях – с притоком на рынок того самого МСБ – для многих компаний целесообразней отдавать SIEM на частичный аутсорсинг. Это может быть внешний SOC или формат Managed SIEM (решение внедрено локально, обслуживанием и настройкой занимается аутсорсер). Такие проекты реализуют интеграторы, сами вендоры, местами сервисы встают на государственные рельсы – например, компания Russian Robotics совместно с Ассоциацией цифрового развития Краснодарского края планирует оказывать услуги ИБ-аутсорсинга с помощью нашей «СёрчИнформ SIEM».
Правда, пока полный аутсорс вызывает у пользователей недоверие, особенно если выносить инсталляцию за периметр (в облако и пр.). Такие реализации есть, особенно за рубежом, единичные проекты появляются и в России. Главный тормоз – SIEM воспринимают как потенциально самый уязвимый элемент ИБ, потому что там агрегируется вся (вообще вся) информация об инфраструктуре, ее состоянии и слабых местах. Отсюда требования, которые к системам предъявляет рынок: пользователи хотят видеть публичный пентест и баг-баунти с привлечением независимой внешней экспертизы, чтобы убедиться, что конкретная коммерческая SIEM защищена от взломов и утечек сама по себе, данные хранятся и передаются безопасно.
А в скором будущем SIEM вероятнее всего ждет переезд в облака – вслед за всей остальной инфраструктурой и ИБ-инструментами. Мы уже закатали рукава и готовимся пробовать облачную адаптацию – проторили дорожку, выведя в Microsoft Azure нашу DLP, в SIEM сделали коннекторы для всей Azure-инфраструктуры, дело за малым.
И авторский лирический постскриптум (@labyrinth, в студию!)
Мои собеседники в студии пришли к выводу, что радикальных трансформаций на рынке ждать не стоит, SIEM – зрелый класс продуктов. Но даже если системы не отрастят вдруг «вторую голову», то будут планомерно меняться по запросам заказчиков. И «запрос» я бы воспринимал не только как уникальность каждого внедрения и бесконечную кастомизацию под заказчика. По-моему, уже сейчас разные SIEM кардинально отличаются друг от друга как раз тем, из какого пользовательского запроса выросли. Разные запросы – разные точки отсчета. Поясню.
По большому счету, есть только два вида SIEM. Первые – самостоятельные, которые вендоры делали «с нуля» именно под парсинг логов и корреляцию событий ИБ. Вторые – «дочерние» к какому-то другому ИБ-продукту. «Родителями» могут быть сканеры уязвимостей, антивирусы, сетевое оборудование, системы внутреннего контроля, практически что угодно. Естественно, в первую очередь такие SIEM расширяют возможности «родительского» продукта и лучше всего с ним интегрированы.
При этом и те, и другие удовлетворяют более-менее универсальным сложившимся требованиям к классу решений (см. перечисленное выше плюс возможности предсказывать и блокировать инциденты).
Но каждый вендор реализует их по-разному. Тот же превент можно сделать минимум четырьмя способами (через скрипты / API / AD / на эндпоинте), каждый со своими плюсами и минусами. Даже базовый функционал кто-то реализует лучше, кто-то хуже. Поэтому отталкиваться от простого перечисления возможностей сложно.
Отсюда и возникает парадокс.
С одной стороны, есть естественная эволюция SIEM: системы усложняются и обрастают нетипичными функциями. В итоге SIEM-старожилы рынка – это настоящие космолеты, которые умеют все и сразу. Вроде бы идеальный выбор для любого заказчика. C другой, заказчику «все и сразу» не нужно. Одному достаточно вычитки логов, второму нужен парсинг плюс сканер уязвимостей, для третьего в приоритете инвентаризация активов, а реагирование на инциденты не так интересно. И вполне может оказаться, что в этих узких областях лучше справятся небольшие SIEM, специально созданные под меньший спектр задач.
Выбор в пользу точечных решений позволяет сэкономить: зачем платить за SIEM с инвентаризацией, если с ней априори лучше справится профильный продукт – проще подключить его к менее прокачанной SIEM как источник данных. Тем удобнее для заказчика, если SIEM при этом отечественная (все больше компаний должны соблюдать это требование), недорогая, с вменяемой политикой лицензирования и низкими аппаратными требованиями.
Получается такой вот «Интерстеллар»: параллельно мы проживаем сразу несколько вариантов развития событий, где SIEM одновременно эволюционируют и «стоят на месте» (и огорчают IDC).
Каждая отдельно взятая SIEM во времени неизбежно развивается и добавляет в функционале, растет вместе со своими заказчиками. При этом в ходу остаются и даже появляются новые «простые» системы – ведь всегда есть заказчики-новички, которым нужно закрыть «базу». Поэтому выходит, что «маленькие» SIEM не менее важны, чем «большие», и полноправно присутствуют на рынке одновременно.
Вот такой вам взгляд из «четвертого измерения» (хотелось ещё пошутить по поводу натягивания совы на Вазу Клейна, но, наверное, это уже перебор).
habr.com
Так как прозвучало много дельных мыслей, перескажем суть дискуссии (для тех, кому лень смотреть запись; кому не лень – рекомендуем): что SIEM представляют собой сейчас, что должны уметь и куда двинутся дальше. А на закуску дадим слово Алексею – он поделится выводами, к которым пришел в итоге
И пока не ушли в большой разговор, пользуясь случаем зовём вас на наше Road Show о SIEM. Проведём его в Санкт-Петербурге (30 ноября), в Москве (1 декабря), а также онлайн (тоже 1 декабря). Зарегистрироваться можно по ссылке.
И обратно к основной теме.
SIEM кончились, не успев начаться?
(Здесь и далее по ссылкам в заголовках – таймкоды на фрагменты обсуждения, чтоб не быть голословными).
На мировой арене SIEM как технология появилась, по разным оценкам, 10-15 лет назад. Это уже зрелые продукты, хотя в сравнении с условными антивирусами все еще выглядят молодо. И вдруг в 2021 году IDC предрекает рынку SIEM глубокую стагнацию: рост в пределах 4-5% на ближайшие 5 лет, никаких технологических прорывов. Западный заказчик сокращает внедрения. Вендоры не предлагают нового функционала. SIEM захиревает и скоро, видимо, окончательно сдаст позиции всевозможным SOAR’ам, UEBA’м и XDR’ам. А мы-то радовались – сделали свою систему и только созрели, чтобы широко представлять ее на рынке, как тут такие новости.
При этом по субъективным ощущениям внимание к SIEM наоборот усилилось. Наши опросы показывали, что с 2017 года обеспеченность SIEM-системами в российских компаниях выросла на 7%, динамика не замедлилась даже в пандемийный кризис. По темпам внедрения своей SIEM тоже видим подтверждение тенденции.
Но субъективным впечатлениям верить нельзя. Что у коллег по рынку?
По словам грандов (IBM, Micro Focus), растет не столько число внедрений, сколько их объемы, а также количество доработок по индивидуальным запросам (а это говорит, что SIEM не пылится, а вовсю используется).
Взрывной рост рынка произошел в начале десятых, когда российский энтерпрайз только начал закупаться SIEM по примеру своих западных коллег. Сейчас решения становятся актуальными для более мелкого бизнеса. Например, небольшие компании, особенно из финансового и сопредельных секторов, стремятся выполнить требования закона (внедрять SIEM предписывают стандарты ЦБ, приказы ФСТЭК №235 для объектов КИИ и №21 для защиты персданных, другие нормативные акты). В этом сегменте нет астрономических сумм внедрений, потому на общую картину он влияет мало.
Но динамика, очевидно, есть, потому что есть спрос. Подтверждение этому – появление новых игроков на рынке, вроде нас или «Лаборатории Касперского». Как правило толчком к решению выпускать «непрофильный» продукт выступает клиентский запрос. К нам, например, несколько лет назад пришел давний заказчик и без обиняков сказал – не хотим дорогущий «комбайн», сделайте нам вычитку логов быстро, просто, из коробки, и чтобы хорошо работало с вашей DLP. И мы сделали. Коллеги из Kaspersky подтверждают: спрос на SIEM у многих компаний рождается из точечной задачи, и, если она состоит в контроле другого защитного ПО, логично обращаться к его создателям.
Программа минимум, или что должна уметь SIEM и что из этого действительно нужно?
Итак, в новых реалиях средний и малый бизнес дорос до «надо» и «хочу», но пока не знает, «как». Взять тот же комплаенс: выполнять требования регулятора – вполне подходящий мотив, чтобы взять под контроль события безопасности в компании. Тем более, что собрать и посмотреть логи практически любой сисадмин в состоянии. Но все же соорудить что-то, функционально похожее на SIEM, под силу не каждой компании. Поэтому большинство, согласно опросу AM, в случае необходимости обращается к вендорам – 64% зрителей эфира указали, что используют коммерческие, а не самописные или опенсорсные SIEM.
[IMG alt="Результаты опроса AM Live: Какой тип системы сбора событий вы используете?
"]https://habrastorage.org/r/w1560/ge...f3a2eb0c4f0231fb1f12d6e7e.png[/IMG]Результаты опроса AM Live: Какой тип системы сбора событий вы используете?
Проблема в том, что готовое «к бою» решение от вендоров часто бывает начинено, как звездолёт. Кажется, что современные SIEM умеют все и сразу: и в контроль источников, и в аналитику, и в прогнозирование, и в комплаенс, и в инвентаризацию, и в превент… А на практике оказывается, что такой насыщенный функционал может выйти боком. Заказчик такому изобилию не радуется, потому что система становится слишком сложной, разворачивается месяцами, чтобы с ней работать – нужно месяцами же учиться.
А что из этого всего реально нужнее и что нужно контролировать в первую очередь? Это самый популярный вопрос и в чате во время эфира, и, чего греха таить, у большинства заказчиков при первом запуске.
Отвечая, участники дискуссии сформулировали более-менее универсальный минимум задач, которые стоит решать с помощью SIEM на старте:
· контроль аутентификации;
· контроль изменений прав пользователей/групп;
· отслеживание перемещений по периметру;
· выявление атак на Active Directory;
· использование матрицы Mitre Att&ck или БДУ;
· инвентаризация оборудования и ПО.
Дальше требования к функционалу SIEM зависят от необходимости углубляться в специфику каждой конкретной задачи.
Потом идут индивидуальные потребности заказчиков. Например, компания может решать с помощью SIEM бизнес-задачи: оптимизировать инфраструктуру, наблюдать за работоспособностью процессов. Коллеги рассказывают, что не раз видели, как SIEM в живой практике используют как BI-систему.
Другой пример: есть специфическая задача по контролю сложной филиальной сети. Нужно разбираться с объемами и маршрутизацией трафика, чтобы сетка не легла, события при этом не терялись, а в итоговом результате учитывались уникальные настройки каждого филиала, но синхронизировались и складывались в единую картину. Или совсем просто (нет): есть в компании КИИ – нужна поддержка ГосСОПКА, есть критичное самописное ПО – нужна возможность подключить его как источник и не пос(е/и)деть в процессе.
Реально ли в тесте SIEM понять, подходит ли вам система?
Выбор SIEM должен начинаться с четкой постановки задач и отсева избыточного функционала, чтобы не платить больше.
Лучше всех свои задачи понимает заказчик, но загвоздка в том, что конкретика в запросах, как аппетит, приходит во время еды. Коллеги по рынку говорят, что реальное понимание у клиентов приходит только на втором-третьем «пилоте». До тех пор неразбериха приводит к неверным расчетам за лишнюю «мишуру» или неудовлетворенности результатом – ваша SIEM, мол, не работает.
Мы все же убеждены, что хороший тест вполне решает проблему «не знаю, что хочу» у заказчиков-новичков. Если посмотреть на стандартный ход «пилотов», становится ясно: во многих случаях тест не удается, потому что заказчика не подстраховали. Ведь слово-то одинаковое, а под пилотом все понимают разное.
Например, мы делаем ставку на обучение. Часто обнаруживается, что даже опытным спецам со стороны заказчика требуется дополнительная поддержка. Если SIEM в компании занимается ИТ-отдел, его нужно переориентировать на контроль не только работоспособности сервисов, но и их уязвимостей, контроль действий пользователей. Если функцию ИБ выполняет «классическая» служба безопасности, вендор, по сути, должен стать внешним ИТ-консультантом и помочь прокачать технические навыки.
Поэтому у нас кроме персонального менеджера, инженеров и аналитиков каждую компанию «ведет» отдел внедрения. Это сотрудники, которые разбирают с клиентами буквально каждую кнопочку и галочку в интерфейсе. На обучение работе с продуктом отводится не меньше пяти часов, чтобы и подкрутить настройки, и обкатать сценарии угроз, варианты реагирования на сбои и расследования инцидентов. Мы уже в курсе типичных «болей» и можем подсказать, куда обратить внимание – то ли на комплаенс, то ли на капризные источники, то ли на позабытые хосты.
В результате подходим к каждому пилоту как к «боевому» внедрению за деньги. И с помощью практического обучения рассчитываем, что на выходе у клиента в команде будет аналитик, хорошо знакомый с системой и понимающий, на что она способна. Конечно, SIEM – системы сложные, но если подойти к тесту с умом, то и результаты заказчик получит чуть ли не с первого включения.
Требовать ли доработок от вендора?
Только 20% заказчиков довольствуются правилами корреляции и другой аналитикой из коробки. Коннекторов тоже порой оказывается недостаточно, потому что в IT-инфраструктуре всегда достаточно и чего-то самописного, и каких-то древних версий, которые не дружат с Syslog. Поэтому систему нужно донастраивать, подключать нетипичные источники данных, писать под них аналитику.
Клиенты способны на это и сами, но производителям SIEM это сделать гораздо проще. Для вендора сотрудничать с производителем оборудования/ПО, к которому делается коннектор, – правило хорошего тона. Это позволяет определить оптимальный набор передаваемых в SIEM данных, сформировать модель угроз, наиболее характерных для источника, вместе написать правила корреляции. У конечного потребителя вряд ли есть возможность запросить у разработчика такие данные, по крайней мере, это требует куда больших усилий.
Поэтому, если запросы на помощь по какой-то задаче от клиентов повторяющиеся и актуальны для разных компаний – мы делаем новые коннекторы/правила и выпускаем в основном релизе. Более распространенная среди вендоров практика – предложить доработки за деньги или привлечь третью сторону. Многие эксперты (но не мы) сходятся в том, что к SIEM должен «прилагаться» хороший интегратор.
Чаще всего обращение к вендору чревато для клиента лишними затратами ресурсов и трудочасов. Поэтому доплачивать за доработки готовы только 17% заказчиков. С учетом того, что компании и так считают, что SIEM – это дорого (мы баловались опросом в нашем ТГ-канале), больше трети пользователей выбирают самостоятельно кастомизировать свои системы.
Это естественное положение вещей, и если относиться к SIEM как к решению для «взрослых» продвинутых пользователей – нет проблем. Но вряд ли таких много среди небольших компаний, которые только открыли для себя автоматизированный мониторинг ИБ. Как быть с ними?
Увы и ах – им тоже придется учиться плавать. Ни один вендор не в состоянии всюду подстелить для заказчика соломку, как ни один родитель не в силах уберечь ребенка от набитых шишек.
Так что отличает хорошего
Нам повезло, с самого первого релиза создание нашей SIEM требовало соблюдения этого принципа. Мы смотрели на систему глазами новичка: а что, если тут вместо консоли с кодом сделать интерактивный конструктор? (так у нас работает создание правил кросс-корреляции). А что, если сделать шаблон коннектора, который пользователь сам сможет подключить к чему угодно? (сделали готовые скрипты для PowerShell, подробно рассказывали, как это работает, вот здесь). С позиции практиков – если разработчику приходится водить клиента по продукту «за руку», это не очень хороший продукт. Поэтому мы все настройки реализуем по принципу «три галки в интерфейсе», а не «выучи ЯП и напиши сам».
SIEM на аутсорсинге – реально ли?
Приходится констатировать, что даже в идеальном исполнении SIEM-системы вряд ли станут проще в использовании. Поэтому в ходе беседы мы пришли к выводу, что в новых условиях – с притоком на рынок того самого МСБ – для многих компаний целесообразней отдавать SIEM на частичный аутсорсинг. Это может быть внешний SOC или формат Managed SIEM (решение внедрено локально, обслуживанием и настройкой занимается аутсорсер). Такие проекты реализуют интеграторы, сами вендоры, местами сервисы встают на государственные рельсы – например, компания Russian Robotics совместно с Ассоциацией цифрового развития Краснодарского края планирует оказывать услуги ИБ-аутсорсинга с помощью нашей «СёрчИнформ SIEM».
Правда, пока полный аутсорс вызывает у пользователей недоверие, особенно если выносить инсталляцию за периметр (в облако и пр.). Такие реализации есть, особенно за рубежом, единичные проекты появляются и в России. Главный тормоз – SIEM воспринимают как потенциально самый уязвимый элемент ИБ, потому что там агрегируется вся (вообще вся) информация об инфраструктуре, ее состоянии и слабых местах. Отсюда требования, которые к системам предъявляет рынок: пользователи хотят видеть публичный пентест и баг-баунти с привлечением независимой внешней экспертизы, чтобы убедиться, что конкретная коммерческая SIEM защищена от взломов и утечек сама по себе, данные хранятся и передаются безопасно.
А в скором будущем SIEM вероятнее всего ждет переезд в облака – вслед за всей остальной инфраструктурой и ИБ-инструментами. Мы уже закатали рукава и готовимся пробовать облачную адаптацию – проторили дорожку, выведя в Microsoft Azure нашу DLP, в SIEM сделали коннекторы для всей Azure-инфраструктуры, дело за малым.
И авторский лирический постскриптум (@labyrinth, в студию!)
Мои собеседники в студии пришли к выводу, что радикальных трансформаций на рынке ждать не стоит, SIEM – зрелый класс продуктов. Но даже если системы не отрастят вдруг «вторую голову», то будут планомерно меняться по запросам заказчиков. И «запрос» я бы воспринимал не только как уникальность каждого внедрения и бесконечную кастомизацию под заказчика. По-моему, уже сейчас разные SIEM кардинально отличаются друг от друга как раз тем, из какого пользовательского запроса выросли. Разные запросы – разные точки отсчета. Поясню.
По большому счету, есть только два вида SIEM. Первые – самостоятельные, которые вендоры делали «с нуля» именно под парсинг логов и корреляцию событий ИБ. Вторые – «дочерние» к какому-то другому ИБ-продукту. «Родителями» могут быть сканеры уязвимостей, антивирусы, сетевое оборудование, системы внутреннего контроля, практически что угодно. Естественно, в первую очередь такие SIEM расширяют возможности «родительского» продукта и лучше всего с ним интегрированы.
При этом и те, и другие удовлетворяют более-менее универсальным сложившимся требованиям к классу решений (см. перечисленное выше плюс возможности предсказывать и блокировать инциденты).
Но каждый вендор реализует их по-разному. Тот же превент можно сделать минимум четырьмя способами (через скрипты / API / AD / на эндпоинте), каждый со своими плюсами и минусами. Даже базовый функционал кто-то реализует лучше, кто-то хуже. Поэтому отталкиваться от простого перечисления возможностей сложно.
Отсюда и возникает парадокс.
С одной стороны, есть естественная эволюция SIEM: системы усложняются и обрастают нетипичными функциями. В итоге SIEM-старожилы рынка – это настоящие космолеты, которые умеют все и сразу. Вроде бы идеальный выбор для любого заказчика. C другой, заказчику «все и сразу» не нужно. Одному достаточно вычитки логов, второму нужен парсинг плюс сканер уязвимостей, для третьего в приоритете инвентаризация активов, а реагирование на инциденты не так интересно. И вполне может оказаться, что в этих узких областях лучше справятся небольшие SIEM, специально созданные под меньший спектр задач.
Выбор в пользу точечных решений позволяет сэкономить: зачем платить за SIEM с инвентаризацией, если с ней априори лучше справится профильный продукт – проще подключить его к менее прокачанной SIEM как источник данных. Тем удобнее для заказчика, если SIEM при этом отечественная (все больше компаний должны соблюдать это требование), недорогая, с вменяемой политикой лицензирования и низкими аппаратными требованиями.
Получается такой вот «Интерстеллар»: параллельно мы проживаем сразу несколько вариантов развития событий, где SIEM одновременно эволюционируют и «стоят на месте» (и огорчают IDC).
Каждая отдельно взятая SIEM во времени неизбежно развивается и добавляет в функционале, растет вместе со своими заказчиками. При этом в ходу остаются и даже появляются новые «простые» системы – ведь всегда есть заказчики-новички, которым нужно закрыть «базу». Поэтому выходит, что «маленькие» SIEM не менее важны, чем «большие», и полноправно присутствуют на рынке одновременно.
Вот такой вам взгляд из «четвертого измерения» (хотелось ещё пошутить по поводу натягивания совы на Вазу Клейна, но, наверное, это уже перебор).
Системы большие и маленькие: парадокс «четвёртого измерения» в эволюции SIEM
Кадр из х/ф «Интерстеллар», все права у правообладателей Как-то раз наш начИБ Алексей Дрозд (aka @ labyrinth ) оказался в эфире AM Live – медиа собрало коллег по цеху обсудить будущее SIEM. Компания...
habr.com