Когда компании реально нужен SIEM, а когда это избыточное решение? Чтобы верно ответить на вопрос, необходимо рассмотреть его как комплексную задачу. Во многом всё зависит от масштабов бизнеса, инфраструктуры, отрасли, обрабатываемых данных и иных условий. Сразу оговоримся, SIEM — это инструмент, и для оценки его эффективности, в первую очередь, нужно определиться с двумя немаловажными компонентами: команда и процессы.
Обеспечением информационной безопасности занимается команда ИБ. При отсутствии достаточного штата квалифицированных специалистов, занимающихся эксплуатацией, развитием и поддержкой SIEM системы, в таком инструменте теряется весь смысл. SIEM становится «дорогой игрушкой».
Без утвержденных и применяемых ИБ-процессов даже самые квалифицированные и опытные специалисты будут работать в хаотичном режиме, не понимая, за что браться, как приоритизировать инциденты, к каким негативным последствиям может привести отсутствие внимания, фокуса и сроков. Поэтому, когда мы говорим о любых инструментах, не только о SIEM, важно понимать, что эффективный результат в обеспечении информационной безопасности находится на стыке «трех китов»: процессы, команда, технологии.
Когда SIEM реально нужен
Цель любого бизнеса — получать прибыль. Информационная безопасность как направление бизнеса не генерирует прибыль, она ее сохраняет.
При этом, если на одной чаше весов стоимость обеспечения ИБ в компании, включающая ФОТ команды, затраты на внедрение процессов, оборудование для SIEM, лицензии на ПО, подрядчиков и пр., то на второй чаше — риски и их стоимость.
Если совокупные траты на ИБ в организации превышают стоимость рисков и ущерба, траты на содержание штатной команды ИБ и SIEM избыточны и финансово нецелесообразны. В таком случае компании необходимо рассмотреть иные способы обеспечения защиты информации, например, услуги внешних провайдеров SOC или гибридную модель.
Пример — малый, а иногда и средний бизнес, где совокупная прибыль компании и риски ИБ не перекрывают комплексное содержание штата ИБ подразделения со всеми вышеперечисленными вытекающими. Безусловно, необходимо рассматривать каждый конкретный кейс в частном порядке, но общий принцип остается таковым.
Отдельно стоит упомянуть компании, чья деятельность подпадает под требования регуляторов. В таком случае вопрос о необходимости подразделения ИБ и SIEM в частности не стоит. Наличие SIEM — одно из требований, которое необходимо выполнять, чтобы не попасть под штрафные санкции.
Типичные ошибки внедрения
Ответ хочется начать с шутки — «Купили и забыли». SIEM — это инструмент, который позволяет своевременно выявлять инциденты и атаки на ИT-инфраструктуру. Как и за любым инструментом, за SIEM нужно следить и поддерживать в актуальном состоянии. Для этого необходимо наличие обученных и квалифицированных специалистов. Зачастую, придя к пониманию, что компании нужен SIEM, и внедрив его, бизнес сталкивается с проблемой нехватки профильных специалистов, в задачи которых входит эксплуатация, настройка аналитики, мониторинг, реагирование на возникающие инциденты, а также сопровождение системы и поддержание в актуальном состоянии контентной базы. Поэтому одним из важнейших критериев необходимости внедрения SIEM является наличие штатного подразделения ИБ.
Эффективность SIEM напрямую зависит от ряда факторов:
- Часто специалисты на местах могут не знать все функциональные возможности SIEM или не до конца понимают, «что защищаем», какие объекты ИТ-инфраструктуры, пользователи, сегменты сети и пр. информационные активы должны быть покрыты мониторингом. Возникают «слепые зоны», когда не все источники ИТ-инфраструктуры подключены к SIEM, чем могут воспользоваться злоумышленники.
- Наблюдается отсутствие связанности и контекста между инцидентами и информационными активами, из-за чего много времени тратится на то, чтобы определить, где произошел инцидент.
- Контентная база для правильной работы правил корреляции остается не актуальной современным угрозам. При этом частая ошибка — встроенный контент «из коробки» производителя SIEM не тюнингуется должным образом в соответствии с существующей ИТ-инфраструктурой компании, включая отсутствие white- и black-lists, фильтров, табличных списков, репутационных баз, логики срабатывания и пр.
- Желание минимизировать ложноположительные сработки правил корреляции может привести к ситуации, когда фокус мониторинга смещается, и в итоге вместо эффективного мониторинга складывается ситуация «нет инцидентов — нет проблем», при которой реальный инцидент или атака останутся незамеченными.
Когда «коробка» подвела
В качестве примера могу привести один кейс из практики. В момент сетевой атаки логи от СЗИ, отследившего атаку и успешно ее отработавшего, исправно поступали в SIEM, но никакой реакции он не выдавал и инцидент не регистрировался.
Исследуя проблему «тишины» на стороне SIEM в момент атаки, наша команда обнаружила проблему корректности «коробочного» правила нормализации для одного важного исходного события СЗИ. Правило нормализации некорректно обрабатывало значение одного из полей исходного события, и, попадая в SIEM, данное событие оставалось ненормализованным. Как следствие, правило корреляции не обнаруживало нужное событие, а инцидент не регистрировался. Оперативно поправив правило нормализации, мы добились того, что инцидент стал выявляться в SIEM.
Как выстроить приоритеты
Как выстроить приоритеты подключения источников и разработки правил корреляции, чтобы SIEM начала приносить пользу в первые месяцы, а не через год? Вспомним закон Парето: 20% усилий дают 80% результата. Первоначально стоит подключать те источники, которые в той или иной мере затрагивают каждого пользователя инфраструктуры, а именно контроллеры домена, пограничные межсетевые экраны, серверы антивируса или EDR, с которых поступает телеметрия.
Также стоит определить информационные активы категории «business critical» и подключать уже их. При разработке контента, в частности правил корреляции, наша команда, в первую очередь обращает внимание на источники, не покрытые (либо частично) правилами «из коробки» и имеющие прямое отношение к критичным для бизнеса информационным системам.
В своей практике мы рекомендуем не забывать и о нетиповых источниках, подключение которых требует самостоятельной разработки правил нормализации, отсутствующих у производителя SIEM. Их нужно не только нормализовать, но и покрыть правилами корреляции, подходя к этому процессу поэтапно, от одного источника к другому. Именно это превращает SIEM из хранилища событий в реальный инструмент выявления инцидентов и атак.
Одна из распространенных ошибок, которую совершают при первой эксплуатации SIEM — сразу начинать собирать весь трафик и события, до которых только можно дотянуться. Цель благая — покрыть мониторингом всю ИТ-инфраструктуру компании. Но «дьявол кроется в мелочах», а в данном случае в приоритетах и сроках.
Цель охватить мониторингом всю ИТ-инфраструктуру долгосрочная, и этот процесс необходимо поддерживать всегда. При смене данной цели на краткосрочную, формируется примерно следующий подход: «сгребем все в одну кучу, а там уже как-нибудь разберемся». В итоге результат такого подхода приводит к огромному количеству событий, формирующих «мусорку», которая еле-еле переваривается SIEM.
Превышаются лимиты по EPS, а у команды ИБ закономерный вопрос: «Как к этой куче подойти? С чего начать?» Чтобы избежать такого негативного эффекта, необходимо подключать все источники по очереди, основываясь на приоритетах, погружаясь в смысл событий ИБ — для чего они нужны, какую атаку или угрозу на этом источнике необходимо детектировать.
Метрики эффективности: как отчитаться перед бизнесом
Бизнес оперирует финансами, поэтому любые итоговые показатели для бизнеса стоит переводить в деньги и риски. Самый понятный KPI — это динамика финансовых потерь от произошедших инцидентов. Приведем условный пример: «В 2024 году до внедрения SIEM ущерб от инцидентов ИБ был 100 млн рублей, а после внедрения SIEM и усиления команды ИБ в 2025 году ущерб составил 10 млн рублей».
Если говорить об эффективности в отчётах для руководства и переходить к количественным показателям, то верным решением было бы показать количество предотвращённых инцидентов, особую ценность среди которых представляют те инциденты или их совокупность, которые своим негативным воздействием могли бы нанести финансовый ущерб компании, превышающий стоимость владения SIEM.
Важно продемонстрировать снижение «слепых зон» и покрытие мониторингом в процентном соотношении от общего скоупа информационных активов, а также возросшую скорость обнаружения и реагирования на возникающие атаки и инциденты. Условно: ранее обнаружение инцидента составляло неделю, например до факта утечки, а сейчас занимает до нескольких часов. Необходимо контролировать процент ложноположительных сработок, в идеале он должен составлять не более
Поддерживаем актуальность контента
SIEM — один из инструментов, использующийся в процессе управления информационной безопасностью, и процесс этот непрекращающийся. Это как бесконечная гонка между нападающим и защищающимся. Лидерство будет за тем, кто не стоит на месте и всегда совершенствуется.
Угрозы меняются всегда, и пытаться закрыть все возможные векторы атак невозможно. Да и нужно ли? Возможно, не стоит закрывать все «дыры». Оставить намеренно самые малозначимые и безрисковые уязвимые места, но при этом внимательно следить за ними — вполне реальный и разумный сценарий, с использованием ловушек типа honeypot. А вот всё, что относится к business critical, — пристально мониторить и контролировать, фокусируясь на недопущении ситуаций, которые могут привести к нарушению бизнес-процессов.
Задача SIEM — показать и просигнализировать: «Вот здесь подозрительная активность, вот сюда уже стучатся, а вот здесь мы пока просто смотрим и наблюдаем». SIEM, являясь инструментом процесса мониторинга ИБ, во избежание потери актуальности должен регулярно получать обновления — как «коробочного» контента от производителя, так и системы в целом.
Одним из преимуществ является наличие обогащения событий постоянно обновляемыми индикаторами компрометации. Если говорить про обновление пользовательских правил корреляции, то тут можно рекомендовать пересматривать их не от случая к случаю, а на регулярной основе — например, раз в полгода, понимая, что чаще — лучше, но сложно, а реже — допустимо, но есть риски. Безусловно, речь идет не обо всех детектирующих правилах, которых может быть несколько сотен, а об основном количестве ключевых правил корреляции, формирующих цепочки атак.
ИИ и ML в SIEM
Сегодня ИИ — это тренд, который нельзя игнорировать, и его внедрение в SIEM вполне закономерное, возможно даже эволюционное. На основе своего опыта я отношусь к этому сейчас со здоровым скепсисом и одновременно с этим с открытостью к новому, потому что не до конца очевидно, к чему в итоге это приведёт. Не будет ли такого, что в определённый момент на вопрос «Какую проблему мы решаем использованием ИИ?» или «Есть ли в ИИ необходимая потребность?» не окажется ответа? Доля маркетинга на рынке всё ещё велика. Часто встречается история, когда продукт уже сделали, а зачем — придумывают позже, и начинается притягивание потребностей «за уши». Но и говорить, что ИИ в SIEM — это полностью маркетинговый ход, уже не очень корректно.
Стоит его рассматривать как рабочий инструмент, позволяющий снять часть рутинной работы с аналитика, занимающегося расследованием инцидента, например, анализ процессов ОС или деобфускация командной строки. Полностью перекладывать ответственность за разбор возникшего инцидента на ИИ пока преждевременно. Лозунг «Давайте роботам отдадим работу для роботов» здесь актуален: возможно в ближайшем будущем ИИ действительно сможет заменить L1 SOC, но вот L2 и L3 полноценно заменить не сможет. Мы уже работаем с компаниями, внедряющие SIEM c модулем ИИ, но частой практикой это назвать пока нельзя.
Эволюция требований к SIEM
Если посмотреть назад, то за последние лет 10 SIEM как решение революционно не поменялось. Системы становятся быстрее, стабильнее, удобнее, появляется дополнительный функционал. И всё же мы по-прежнему подключаем источники, собираем логи, нормализуем, коррелируем и бьём тревогу. Но если посмотреть, как расширяются продуктовые портфели различных производителей в сфере ИБ, и какие классы решений в них появляются, можно заметить, что уникальных решений становится всё меньше, а альтернатив всё больше.
Производители стремятся развивать собственную экосистему. Оценивая перспективы SIEM в ближайшие
Впрочем, это уже наблюдается у некоторых производителей, и, думаю, станет общим трендом. Возвращаясь к вопросу об ИИ: возможно в будущем мы увидим, как нормализация исходных событий выполняется автоматически, а также предлагаются решения, как правильно выстроить логику детектирования того или иного инцидента.
Требования к производительности растут, и если раньше нагрузка в несколько десятков тысяч EPS была серьёзной, и не все SIEM решения могли похвастаться обработкой такой нагрузки, то сегодня речь идёт о сотнях тысяч. Такие изменения в производительности требуют новых архитектурных подходов, что также повысит возможности горизонтального масштабирования. Добавится возможность работы в распределённых средах, появятся более эффективные алгоритмы сжатия и хранения данных.
Источник: Сергей Скородумов, руководитель отдела систем мониторинга и реагирования Angara Security
