«Костыли» вместо SIEM или почему так лучше не делать?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

В 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 марта расскажем об этом на бесплатном вебинаре. Разберем с азов, куда смотреть и на что реагировать, чтобы сразу получать от системы видимый результат. Регистрируйтесь.

Источник: https://habr.com/ru/companies/searchinform/articles/801751/


Интересные статьи

Интересные статьи

CEO Bitbanker Сергей Горшунов платит деньги сотрудникам, когда и если захочет, а строптивым угрожает.Помните Валентина Преображенского из Latoken? У него появился весомый конкурент.Я специалист в сфер...
КА «Метеор-М» перед накаткой головного обтекателя. На переднем плане видны пусковые контейнеры кубсатов на переходной ферме РБ «Фрегат». Источник: «Роскосмос» 27 июня ракетой-носителем «Союз-2.1б» ...
История анализа данных начинается примерно с 70-х годов прошлого века, когда Американский математик и ученый Джон Тьюки  опубликовал свою книгу “Exploratory Data Analysis” или “Разведывательный А...
Это ответ на переведенную публикацию «Почему Kotlin хуже, чем Java?». Поскольку исходная аргументация опирается всего на два примера, то не теряя времени пройдем по этим «недостаткам» Kot...
Потому что пациенты лечатся, пока у них болит. Стоит перестать болеть — и пациенты пропадают. Если речь про терапевтическое лечение, то можно обойтись без плана: пациент остро чув...