Как выбрать и эффективно использовать SIEM-систему?

В ходе беседы Сергей раскрыл, какие требования к архитектуре SIEM обеспечивают её эффективность: от высокой производительности при минимальных вычислительных ресурсах до масштабируемости, отказоустойчивости и гибкой интеграции. Эксперт также поделился мнением о текущих тенденциях на рынке, отметив, что, несмотря на разговоры об устаревании SIEM, этот класс решений продолжает развиваться, поглощая функции других инструментов информационной безопасности, таких как SOAR. Однако, по словам Сергея, подход «всё в одном» подходит только для начального уровня зрелости компании и несёт определённые риски, такие как зависимость от одного вендора и сложности масштабирования.

Отдельное внимание было уделено работе с данными: оптимизации их сбора, ротации и хранения, а также разнице подходов к настройке — от «собирай всё» до выбора минимально необходимой информации. Сергей рассказал о типичных проблемах, возникающих при интеграции SIEM с другими системами, таких как несовместимость форматов данных и необходимость постоянного обновления интеграций. Также была затронута важная тема снижения ложноположительных срабатываний и использования дополнительных аналитических инструментов, таких как UEBA, для повышения точности выявления инцидентов.

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

Ответ на этот вопрос, я полагаю, печалит любого разработчика. В голову сразу приходит аналогия: в первобытные времена каменный топор был максимально эффективен при всех своих недостатках. Сейчас у нас есть десятки разных топоров: колуны, боевые, метательные и т.д., — каждый из которых наилучшим образом решает определенную задачу. Тем не менее люди все равно мечтают об универсальном инструменте, не уступающем специализированным. С программными продуктами происходит то же самое: их создают для решения конкретной задачи, и они прекрасно работают. Потом количество задач, связанных с первоначальной, растет, как и требования к продуктам. В результате продукты усложняются, и на их обслуживание требуется все больше людей, причем с хорошими компетенциями. А такие люди в дефиците.

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

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

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

В общей системе управления информационной безопасностью есть набор действий (операций): мониторинг, выявление, расследование и реагирование. Если раньше SIEM отвечал только за первые два, то сейчас многие продукты закрывают все четыре подпроцесса. Также SIEM являются связующим звеном или агрегатором информации для процессов недопущения инцидентов, таких как TI, TH, управление уязвимостями и др.

Технология SOAR, будучи результатом эволюции IRP-решений, призвана автоматизировать какие-то действия в конечных системах и СЗИ на основе получаемой информации и инструкций, что и в каких случаях выполнять. Она работает с подозрениями на инциденты, которые получает от СЗИ, SIEM или TIP. При этом связь SOAR-SIEM должна быть двусторонней (push/pull), чтобы SOAR могла запросить дополнительные данные из SIEM, например для обогащения или сбора контекста и проверки условия. Это требует богатого API на стороне SIEM. Вообще, связка SIEM-IRP или SIEM-SOAR настолько хорошо показала себя, что наблюдается тенденция объединения этих решений в один продукт. Международные аналитические агентства считают, что в горизонте пары лет большинство продуктов превратятся в такое консолидированное решение.

Вместе с тем я скептически отношусь к этой тенденции: швейцарский нож или мультитул удобен лишь компактностью, но сильно уступает в удобстве и возможностях отдельным инструментам. Безусловно, мы отвечаем на потребности рынка и развиваем наш продукт как комплексное решение, в том числе дополняя его возможности реагированием. Однако я считаю, что такое решение лучше использовать организациям на начальном уровне управления ИБ. Подход «все в одном» быстро внедряется и дает очень заметный результат, если раньше ничего не было. Для заказчика решение дешевле в моменте, но влечет множество рисков на долгой дистанции: вендорозависимость всего процесса, одна, но сверхкритичная точка отказа, сложность масштабирования. Поэтому мы параллельно наращиванию функций развиваем интеграционные возможности, и не только с IRP/SOAR-решениями. Мне кажется это очень важно, так как экосистема – это, безусловно, удобно, но за все приходится платить.

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

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

SIEM, который мы разрабатываем, изначально был рожден в ядре коммерческих услуг SOC. Мы использовали второй подход, так как клиент приобретает, по сути, свое спокойствие, а не набор из выявляемых инцидентов. И иметь максимум информации было критически важно для качества обнаружения. Продолжаем придерживаться этой точки зрения.

Независимо от того, какой подход использует SIEM-система, обязательно надо продумать ротацию и архивацию данных. Но важно выяснить, поддерживает ли SIEM-решение необходимые механизмы и разделение данных. Например, данные netflow или события DNS и DHCP-серверов стоит хранить не больше недели, события ОС, не относящиеся к событиям безопасности, — не более двух недель, события безопасности, — не более месяца, а вот инциденты, критичные события ИБ или события от определенного СЗИ может понадобиться хранить годами (по требованию регулятора). Важно, чтобы SIEM позволяла гибко настроить: что, от каких источников, сколько хранить, иначе для оптимизации потребуется много скриптов и в последствии легаси.

SIEM интегрируют для двух задач: собрать какие-то данные и отдать какие-то данные. И в каждом из случаев своей набор болей.

Например, при подключении источников несмотря на наличие стандартов, описывающих какой-то протокол обмена информацией (RFC), многие производители не следуют им. В своей практике при написании коннекторов мы сталкивались со многим. Например, в Syslog-сообщение добавляют зачем-то данные в JSON, при разложении полей не следуют стандарту, указывают некорректный Syslog-заголовок. При этом никто из вендоров про такие «приятные сюрпризы» не напишет в своей документации. Вы приступаете к подключению нестандартного источника, надеясь решить задачу за полчаса, но по факту приобретаете массу несоответствий RFC, которые можно выявить, только получив пример всех возможных событий. А иногда инициировать все возможные события на источнике и невозможно.

Другой пример: необходимо забрать события из базы данных, так как источник не умеет отправлять их. Источник поддерживает несколько СУБД, и, казалось бы, схема данных БД должна быть в них идентична, но по факту это не так. Коннектор, который успешно разбирает события от одного и того же источника работает корректно с MSSQL, но не работает с PostgreSQL (так как запрос, формирующий нужный датасет, не находит часть полей или связей). Бывают ситуации, когда источник вообще не приспособлен для отдачи данных. Например, один из российских криптошлюзов до недавнего обновления не предоставлял возможности отправки событий, а в своей БД события держал в зашифрованном виде. И это не шифрование на уровне СУБД, а собственное шифрование, что делало невозможным сбор событий в целом без приобретения специальной и редкой лицензии на программу от вендора, которая занималась извлечением и расшифровкой логов.

Если говорить про передачу данных из SIEM куда-либо, скажем, в IRP или другую SIEM (такое тоже бывает), то сложности могут возникнуть от того, что получающая сторона поддерживает только один конкретный способ передачи и он специфический. Например, нет такого универсального API, которое бы позволило передать информацию об обнаруженных инцидентах в любую IRP или SOAR. У каждого свои «ручки» и своя модель данных. Для интеграции методом push на стороне SIEM приходится писать и постоянно обновлять (ведь на стороне получателя все может измениться) словари мапинга полей, структуру API запросов и др. Например, Alertix поддерживает интеграцию с НКЦКИ (ЛК ГосСОПКА) «из коробки» с использованием API. За год в среднем мы получаем два обновления Swagger-контракта и вносим соответствующие изменения в продукт, чтобы интеграция продолжала работать. Но это наша зона ответственности, как вендора, а если говорить про интеграцию других решений в инфраструктуре, то это может стать проблемой клиента.

Универсальных подходов, которые помогают решить все перечисленные проблемы, нет. Мы руководствуемся принципом максимизации возможностей для интеграции. Например, забрать данные из Alertix можно не только по API, но и из файлов, из СУБД. А загрузить в SIEM сведения об IOC можно не только в формате STIX, но и в произвольном CSV, по API или через готовую интеграцию с конкретной TI-платформой. Благодаря этому при интеграции можно выбрать тот способ, который будет проще.

Снизить FP-rate правил можно, но до определенного предела. Так как сама идея корреляции подразумевает, что если вы начинаете игнорировать что-то, то вы сужаете угол обзора. Стандартно для снижения количества FP используются списки исключений, а также дополнительные условия, которые действуют только в конкретной инфраструктуре. С белыми списками все просто, но таким образом вы просто отключаете детект на конкретном хосте, для конкретного процесса или пользователя, чтобы было меньше «шума», но при этом лишаетесь возможности выявить реальный инцидент.

Дополнительные условия удобно объяснить на примере классического правила выявления брутфорса пароля. Обычно считают какое-то количество неуспешных попыток входа с вариациями: с разных хостов или одного, одной учетки или разных и т.д. FP-rate таких правил обычно высокий. Например, у сотрудника установлена система ЭДО (электронного документооборота), использующая аутентификацию на прокси-сервере и доступ в интернет. Пользователь сменил пароль или пароль просрочился, когда тот был в отпуске, а компьютер продолжал работать. ЭДО работает в фоновом режиме под старым паролем, не может успешно пройти аутентификацию и генерирует ложноположительную сработку правила. Чтобы избежать подобного можно добавить условие отсутствия флага устаревания пароля в учетной записи или отсутствия события смены пароля в течение 2–3 дней до событий ошибки аутентификации. Но если пользователь все еще в отпуске, вы все равно получите FP, просто не сразу. А если увеличите окно «дней после смены или устаревания пароля за которые допустимы ошибки аутентификации», то увеличите риск пропустить реальный брутфорс, происходящий в этот период. То есть любые способы снижения FP-rate отдельного правила всегда снижает и их «чувствительность». Это похоже на принцип неопределенности в квантовой механике.

Решением сейчас видится использование дополнительных контекстных сведений с корреляционными событиями для определения, инцидент это или не инцидент. Заключение должно быть сделано не коррелятором, а более интеллектуальной логикой.

Объясню на примере, который привел ранее: подбор пароля на хосте внутри периметра не случается вдруг. Ему точно предшествовали какие-то другие события: получение подозрительного письма, вложения, файла на флешке, переход на какую-то страницу, соединение с каким-то другим узлом в корпоративной сети или в интернете. Такое дерево вариантов встроить в корреляционную логику почти невозможно — это поведенческий контекст. И каждый такой контекстный фактор можно использовать как индикатор, повышающий или понижающий вероятность реального брутфорса. Для этого хорошо использовать UEBA-решения, которые позволяют этот нечеткий контекст собрать. Например, если бы на компьютере были зарегистрированы события запуска ранее не наблюдавшихся исполняемых файлов, соединения с новыми адресами, то вероятность брутфорса повышается. Это уже некая оценка «подозрительности» происходящего на хосте или от имени пользователя или вообще в инфраструктуре. Работать с отдельными поведенческими аномалиями сложно, а вот в совокупности с правилом это может снизить FP-rate без рисков пропустить реальный инцидент. Такую связку мы предлагаем реализовать с использованием двух наших продуктов Alertix и Dataplan.

Дополнительно к этому некоторые SIEM-решения, включая наше, двигаются в сторону рассмотрения отдельных инцидентов, выявляемых правилами корреляции как звеньев чего-то большего. Это не просто цепочка действий, которую можно задать условием вроде «если произошло А, Б и С, то это плохо и похоже на атаку». Это применение машинного обучения для оценки того, какие последовательности и комбинации являются нормальными, а какие нет. Это требует большого количества размеченных данных для обучения, дополнительные мощности и точность такого подхода пока неприемлемая. Однако мы верим в такую методику и продолжаем исследования в этой области.

Предлагаю говорить не про команды, а про роли, которые заказчик может распределить по командам, как ему нравится.

Я вижу пять основных задач, которые требуют специфических компетенций и выражаются в роли специалистов. Надо поддерживать работоспособность SIEM, непрерывность приема событий, действующих интеграций; заниматься непрерывным мониторингом сработок; заниматься свободным поиском (TH, TI); писать новый контент и адаптировать старый (дополнять, снижать FP-rate, повышать полезность получаемых данных, в том числе обогащать); реагировать на инциденты: локализовать, оценивать распространение, думать над недопущением в будущем, восстанавливать состояние, извлекать индикаторы и добывать цифровые доказательства.

Для каждой верхнеуровневой задачи свой большой набор подзадач. Ресурсы есть не у всех и не на все. SIEM-решение должно предоставлять инструменты, облегчающие эти задачи, и это можно сделать очень небольшим количеством способов:

Все зависит от подхода и оценки угроз каждого заказчика. При проведении пилотов мы рекомендуем собирать то, что важно почти для всех.

В первую очередь это события ОС (Win/Linux), события критичных сервисов и приложений как АРМ, так и серверов, включая дополнительную телеметрию о запускаемых процессах, устанавливаемых сетевых соединениях и др. Не менее важна телеметрия сетевых соединений (например, Netflow), как на периметре, так и между сегментами внутри сети. И, конечно, события СЗИ, которые есть в каждой инфраструктуре: межсетевых экранов, средств предотвращения вторжений, антивирусных средств, гигиены электронной почты, средств фильтрации доступа в интернет.

Также на пилотах мы рекомендуем подключать несколько бесплатных списков индикаторов компрометации с проверено высокой степенью достоверности, таких как списки узлов TOR, списки известных командных центров C2.

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

Это общие рекомендации, а в каждой конкретной инфраструктуре могут понадобиться свои дополнительные сведения. Пример: у заказчика есть изолированный от интернет сегмент сети. Заказчик предполагает, что так как связи с интернетом нет, то и соответствующих рисков нет. Однако если на АРМ нет соответствующих СЗИ или настроек, запрещающих подключать USB-устройства или подключаться к беспроводным сетям, то нарушитель может получить доступ в интернет с «изолированного» АРМ, подключив USB модем или раздав интернет с телефона. В этом случае неплохо было бы собирать системные события подключения USB-устройств, изменения конфигурации сетевого оборудования и контролировать сетевые соединения с интернетом на хосте.

Эффективность – это производительность по отношению к каким-то затратам. Часто можно спутать эффективность с производительностью. Если два разных SIEM на одних и тех же вычислительных ресурсах могут обрабатывать разные потоки – это все еще производительность или уже эффективность? На мой взгляд, эффективность появляется тогда, когда продуктом начинают пользоваться люди и решать конечные задачи.

В связи с тем, что SIEM — инструмент сложный, а задачи, которые он решает, разнообразны, говорить логичнее не об эффективности в целом, а об эффективности решения отдельных задач и притом с какими-то ограничениями. Поясню: одна из основных задач SIEM – выявлять инциденты и атаки, которые не обнаружили отдельные СЗИ. Как я говорил ранее, эта способность зависит от настройки, понимания людьми бизнес-процессов, инфраструктуры и компетенций этих людей. То есть даже один и тот же продукт в разных проектах может показать разную эффективность выявления. Значит стоит исключить влияние человеческого фактора: проверить эффективность выявления контентом «из коробки» без адаптации. Для этого клиенту надо запустить у себя в инфраструктуре тесты, имитирующие вредоносную и нежелательную деятельность, например, используя бесплатный инструментарий Atomic red, и посмотреть, какое решение выявит больше имитаций. Конечно, источники к тестируемым решениям надо подключить идентичные. Эту метрику часто называют Detection Rate.

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

Остальные метрики, которые мы часто слышим, я считаю их малополезными:

Постараюсь ответить на этот вопрос максимально непредвзято, но, скорее всего, звучать это будет как накопленная боль, так как ошибки при внедрении приводят к негативному восприятию продукта. Не стоит делать так:

Во-первых, надо рассчитать совокупную стоимость владения на горизонт от трех лет. Не все решения, привлекательные по стоимости в первый год, обеспечивают лучший ТСО на длительных интервалах. Замена SIEM – это не отказ от подписки, в пару кликов не обойдется.

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

Не стоит забывать, что вендоры всегда поворачивают товар привлекательным бочком, иногда преувеличивая значимость каких-то функций. Например, на мой взгляд погоня за катастрофоустойчивостью SIEM (когда у вас образуется две SIEM разных ЦОД, которые постоянно обмениваются данными и готовы стать основными если первая инсталляция полностью откажет) – это пример того, когда фича не стоит денег и вообще не требуется. Любые ИТ-сервисы имеют разную критичность для бизнеса. SIEM для внутренних нужд никак не подходит под определение ни mission-critical, ни business-critical, и резервировать этот сервис таким образом – пустая трата средств. Конечно, если мы говорим не о сервис-провайдере, у которого этот инструмент — основа каких-либо предоставляемых услуг.