В 2022 году только 14,5% российских компаний были оснащены SIEM, показало наше исследование. При этом задачи по контролю безопасности ИТ-инфраструктуры были и остаются у всех. Их часто решают альтернативными средствами. Например, 12% наших респондентов заявляли, что имеющиеся у них средства ИБ полностью заменяют SIEM. Но так ли это на самом деле?

Разобрались вместе с системным аналитиком «СёрчИнформ» Павлом Пугачем aka @PugachPasha, какие решения используют ИБ-специалисты, чтобы «закрыть» функциональность SIEM-системы, и когда такая оптимизация может выйти боком.

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

Чем обеспечить мониторинг?

С точки зрения сбора событий кажется, что SIEM может заменить обычный лог-менеджер. Эти продукты (кстати, в большой части бесплатные) объединяют журналы от различных устройств и ПО, в которых те фиксируют свою работу.

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

С другой стороны, есть сканеры уязвимостей (по нашим данным, стоят в 47% российских компаний). Они буквально созданы, чтобы обнаруживать проблемные места в ИТ-инфраструктуре. Но есть нюанс. Сканеры, в отличие от лог-менеджеров, работают не с событиями ИБ, а с состоянием ИТ-инфраструктуры. То есть сканер не регистрирует происходящее в ней – только собирает «статичные» срезы текущей ситуации. При этом SIEM в ряде случаев может и сама контролировать состояние ИТ-инфраструктуры, особенно если к системе подключить соответствующие протоколы (SNMP, допустим, или SSH). SIEM, которая собирает сведения о состоянии того или иного устройства и ПО и проводит инвентаризацию активов, условно может заменить собой сканер. При этом такая SIEM найдет не только незакрытые порты или непропатченный софт (это задачи сканера), но и другие проблемы: например, неправильную работу или перегрев оборудования. А еще SIEM пусть опосредованно, но контролирует пользовательскую активность на ПК и серверах, в файловой системе и БД. Сканер всего этого не сделает.

То есть SIEM помогает в борьбе с угрозами и рисками ИБ, а не просто рапортует, как работает ваша инфраструктура.

Как выявлять угрозы?

Еще одно довольно близкое к SIEM решение – это XDR (Extended Detection and Response). Если лог-менеджмент — это управление событиями, то XDR – скорее, управление инцидентами. Он заточен выявлять серьезные угрозы, и не замечает, так скажем, «вялотекущие» или «ежедневные» проблемы. Например, если SIEM выявляет неполадки с питанием, видит, что сломался кулер или винчестер выходит из строя, то XDR это проигнорирует. Зато определит, когда инфраструктуру попытаются атаковать: заразить, зашифровать, хакнуть или испортить жизнь компании другими подобными способами.

XDR’ам предшествовали EDR – системы обнаружения и реагирования на события в конечных точках. Так же близко к XDR стоят IDS – системы обнаружения вторжений. Оба решения, по сути, узкопрофильные, и хорошо справляются именно со своими задачами, но фактически игнорируют инфраструктурные сбои, а значит, оставляют компанию беззащитной на уровне сети и при внутренних угрозах (на уровне пользователя).

«Изнутри» помочь могут DLP (есть у 36%): они выявляют целый ряд вещей, которые обычно «ловит» SIEM. Только DLP акцентируется на пользовательской активности, а SIEM – на всей инфраструктуре. Возьмем, например, брутфорс пароля учетной записи или изменение пользовательских полномочий: DLP «поймает» их на ПК, SIEM – на сервере AD (или на том же ПК, если работает через агент). Но при этом SIEM видит больше: система получает от контроллера домена (и тех же DLP) те же данные, только сразу в виде общей картины, и может сопоставлять ее с другими, на первый взгляд не связанными, событиями. 

Для защиты на уровне сети универсальный мастхэв – классические файрволы и NGFW (Next Generation Firewall, есть у 60% организаций), зачастую интегрированные с различными TI (Threat Intelligence). Они получают данные о скомпрометированных узлах в сети, которые, например, являются частью ботнета, или с которых идет распространение вирусов. На основании того, откуда к ним идет то или иное подключение, они выявляют угрозы и блокируют их до того, как они приведут к инцидентам. Например, если к сети компании через файрвол пытаются пробиться с адреса из черного списка (адреса, который в TI зарегистрирован как часть ботнета или распространитель вирусов). Еще есть IPS (Intrusion Prevention System, стоят у 19%) для предотвращения вторжений, и они тоже предполагают активную реакцию на инциденты.

Все эти инструменты без сомнения важные и нужные, однако по отдельности каждый из них не дает полной картины происходящего и комплексной защиты. Как это получается у SIEM.

А если взять все и сразу?

Такой вариант тоже есть. Большое количество СЗИ может «закрывать» различные фрагменты того, что делает SIEM в комплексе. Но набор решений — это не всегда эффективно, просто и дешево.

Допустим, у нас есть решения, которые точечно решают конкретные задачи. Например, IDS, NGFW, DLP и антивирус, а если добавить еще лог-менеджмент, то в сумме они могут чуть ли не целиком закрыть функционал SIEM. Но SIEM работает в одной консоли, автоматически сопоставляет события из разных источников, выявляет опасные взаимосвязи, оповещает об угрозах. Вручную управлять и добиваться того же результата с помощью даже четырех-пяти средств защиты – проблематично и крайне трудозатратно.

Можно попытаться «поженить» разные СЗИ своими силами, чтобы они обменивались данными и учитывали их при запуске реакций. Например, взять бесплатный лог-менеджер, вложить уйму сил и времени и создать некий аналог SIEM. Но даже в этом случае придется брать конкретные решения, источники. И скорее всего получится нечто, очень сильно завязанное на строго определенные продукты и даже их версии. А еще завязанное на сотрудников, которые этого «Франкенштейна» создали и поддерживают его работоспособность. Почему?

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

Немного (непрошенных) выводов

В итоге имеем такую картину:

1. Самодельный «зоопарк» решений – это риски переплатить за избыточный функционал, с одной стороны, и недобрать достаточно инструментов, с другой. Потенциально такое «лоскутное одеяло» грозит дырами в безопасности.

2. Много разных решений – это дороже, чем купить и внедрить одну систему, даже если по отдельности каждое дешевле одной SIEM. Это разные схемы лицензирования, оплата техподдержки для каждого продукта отдельно, разные аппаратные требования (которые в совокупности могут повышаться бесконечно), а с ними и затраты на оборудование. Статья расходов получается непредсказуемая.

3. Использование ряда решений – это еще и много «рук», которые будут их обслуживать, много времени на настройку и взаимную интеграцию, да даже на ежедневную работу с ними. Потребуется расширять ИБ-штат или перегружать специалистов – тоже затраты.

4. Разносторонний пул решений – это неизбежные потери данных где-то между, даже если попытки интегрировать их между собой в целом увенчаются успехом. Плюс те же трудозатраты, чтобы данные между собой «поженить» и скоррелировать. Разнонаправленные системы справляются с узкими задачами, но без «сводной» картинки их эффективность снижается: каждая воюет «о своем» и выстроить комплексную защиту сложнее.

SIEM в этом смысле удобней: оптимизирует трудозатраты, позволяя контролировать все «в одном окне», плюс сводит воедино эту самую картинку, автоматически указывая на связи между событиями. Поддержка и контроль качества системы – на стороне вендора (если мы говорим не про opensource), и одному вендору адресовать вопросы тоже сподручней. Сегодня SIEM становятся проще в эксплуатации, многие фичи работают уже «из коробки», кастомизация и донастройка сводится к паре кликов в графическом интерфейсе (либо скриптам на простейшем PowerShell – по крайней мере, так у нас). Это экономия человеческих ресурсов.

Понятно, что сама по себе, без источников в виде СЗИ SIEM защищать вас не будет. Но с ней можно отказаться от каких-то инструментов, частично дублирующих функционал.

А если вы все же сделали выбор в пользу SIEM, но не знаете, как начать с ней работу – 21 марта расскажем об этом на бесплатном вебинаре. Разберем с азов, куда смотреть и на что реагировать, чтобы сразу получать от системы видимый результат. Регистрируйтесь.