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

Развитие ландшафта угроз в сторону сложных таргетированных атак и многообразие систем защиты создают потребность в автоматизации сбора и анализа событий ото множества источников данных. Это ведёт к росту популярности комплексов класса «управление информацией и событиями по безопасности» (Security Information and Event Management, SIEM).

1. Введение
2. Необходимость использования SIEM
3. Пилотные проекты SIEM: как проводить и на что обратить внимание
4. Процесс «пилотирования» SIEM и выгода от него
5. Что делать дальше? Само внедрение
6. Процесс эксплуатации
7. Выводы

Введение

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

Необходимость использования SIEM

С развитием бизнеса компании обрастают как бизнес-сервисами, так и системами информационной безопасности. В определённый момент наступает этап зрелости, когда не только процессы требуют соответствия требованиям регуляторов, но и сами работники ИБ и ИТ начинают нуждаться в инструменте мониторинга технических данных и поиска признаков вредоносной активности. В итоге компания приходит к выводу о необходимости SOC (Security Operations Center) — команды специалистов по мониторингу, анализу и реагированию на события и инциденты. Для реализации потребностей таких специалистов требуется инструмент сбора, корреляции и анализа логов, то есть SIEM.

Для начала следует определить, нужна ли компании SIEM. В целом можно выделить следующие предпосылки к её внедрению:

1. Большое количество разнообразных систем в инфраструктуре. Требуется единая точка входа для сбора и анализа журналов.
2. Большое количество «белых пятен» в инфраструктуре компании, особенно при быстром росте и развитии бизнес-систем. Каждый отдел или команда ведёт и сопровождает только свои системы и процессы, не имея представления о смежных системах и интеграциях. У части систем может вообще не оказаться ответственного администратора.
3. Потребность в своевременном реагировании на инциденты. Любой простой и любые неполадки наносят материальный ущерб, так что разрешать такие ситуации нужно оперативно.
4. Большое количество систем защиты информации (СЗИ) имеют собственные журналы, события из которых необходимо соотносить между собой для выявления сложных инцидентов.
5. Есть достаточно большой штат ИБ-специалистов, который нуждается в единой консоли для решения задач по инцидентам и событиям.
6. Необходимо обеспечивать соответствие требованиям нормативных правовых актов регуляторов (законов № 152-ФЗ, 161-ФЗ, 187-ФЗ, приказов ФСТЭК России № 21, 17 и 31, СТО БР ИББС, РС БР ИББС-2.5-2014, ГОСТ Р 57580.1-2017, международного стандарта PCI DSS).
7. Необходимость импортозамещения имеющейся SIEM от иностранного вендора.
8. Требуется независимая оценка состояния инфраструктуры.
9. Необходимо охватить средством мониторинга не только центральный офис, но и все филиалы. Например, SIEM-систему Kaspersky Unified Monitoring and Analysis Platform (KUMA) можно использовать как для централизованного управления событиями во всех филиалах, так и для локального мониторинга событий в каждом из них. Подобная функциональность позволяет ответственным за ИБ в филиалах и подразделениях или внешним поставщикам ИБ-услуг обнаруживать и приоритизировать угрозы в рамках своих зон ответственности.

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

Компании задумываются о SIEM-системе и в принципе смотрят в сторону создания собственного SOC или отдела мониторинга ИБ тогда, когда уже есть достаточное количество СЗИ и необходимо выстроить или скорректировать внутренние ИБ-процессы. При этом SIEM может быть интересна не только специалистам по ИБ, но и ИТ-специалистам, пусть и в ограниченном доступе. Например, если нам важна работа некой бизнес-значимой системы в режиме 24×7, мы можем отслеживать её доступность путём сбора логов в SIEM; если получить логи не удаётся, это становится сигналом о недоступности системы. Ещё одним нестандартным примером может служить контроль невмешательства в конфигурационные файлы ИТ- или бизнес-систем, для того чтобы любые изменения в их настройках были контролируемыми.

Когда в компании приходят к выводу о необходимости внедрения SIEM, встаёт выбор: пойти к облачному провайдеру и заказать у него услугу SOC, куда будет уже добавлена стоимость их SIEM, либо внедрить и поддерживать собственное локальное (on-premise) решение. Кстати, у облачного SOC есть различные тарифы и возможности, с которыми важно внимательно ознакомиться перед приобретением, так как в конечном счёте можно остаться с очень ограниченной функциональностью — например, просто получать сигналы об обнаружении вирусной активности на хостах. С таким же успехом можно настроить оповещения и получать эту информацию от Kaspersky Security Center, без приобретения услуги SOC.

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

При наличии же большой инфраструктуры, штата ИБ-специалистов, парка из сотен или тысяч бизнес-серверов и большого количества различных СЗИ встаёт дилемма: использовать программное обеспечение как услугу (SaaS) или внедрить SIEM в собственной инфраструктуре.

Рассмотрим «плюсы» внедрения локальной системы (вместо SaaS-сервиса).

• Основным и главным «плюсом» являются полный контроль и понимание собственной инфраструктуры ИБ- и ИТ-специалистами. Облачный провайдер будет знать о вашей инфраструктуре и её процессах только то, что вы предоставите в виде анкет или логов подключённых систем, а инфраструктура и процессы имеют свойство динамически изменяться. Также нужно иметь в виду, что легитимная по версии облачного провайдера активность конкретно для вашей компании может быть аномальной.
• Сроки исполнения задач по подключению новых систем, написанию коннекторов, новых правил корреляции и расследованию инцидентов стоят на контроле у внутренней команды SIEM. Срочные задачи будут выполняться в приоритетном для неё порядке.
• Возможность неограниченного подключения новых источников, написания своих правил нормализации, обогащения, составления сложных правил корреляции. В случае локального развёртывания нет необходимости изменять рамки договора услуг или выделять дополнительные средства под такие задачи.
• Локальная SIEM-система не позволит упустить, забыть или проигнорировать случившийся инцидент. На него всё равно нужно будет отреагировать, и у руководства будет карт-бланш на проверку исполнительности сотрудников в части расследования инцидента.
• Возможность подключения внешней команды для расследования сложного инцидента в случае нехватки компетенций. Ей можно продемонстрировать все данные в локальной SIEM для установления причин возникшего инцидента и выдачи рекомендаций по недопущению подобных инцидентов в будущем.

Пилотные проекты SIEM: как проводить и на что обратить внимание

В этой части статьи коснёмся того, каким образом может проводиться выбор производителя системы. Источниками информации и критериев могут быть:

• Руководства, обзоры рынка, презентации систем.
• Рекомендации от других компаний в вашем или похожем сегменте бизнеса.
• Собственные требования и опыт, удобство работы для аналитиков, простота управления, написания новых правил корреляции событий, разработки коннекторов.
• Цена продукта и стоимость владения (на дистанции в три года и более).
• Разнообразие и достаточность набора коннекторов «из коробки», удобство сбора логов и формата их представления.
• Производительность системы — число обрабатываемых событий в секунду (EPS). Кстати, KUMA от «Лаборатории Касперского» отличается на сегодня одним из наиболее высоких показателей производительности, подтверждённым в тестах на реальной инфраструктуре — более 300 тысяч EPS.
• Возможности масштабирования (увеличение количества обрабатываемых EPS) и отказоустойчивости (кластеризация системы). Ряд производителей заранее закладывают такие возможности в архитектуры своих систем.
• Репутация и опыт вендора системы.
• Необходимость подключения к ГосСОПКА в рамках обязательного информирования об инцидентах в соответствии с законом № 187-ФЗ.

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

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

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

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

Исходя из вышесказанного, коротко определим важные аспекты проведения «пилота»:

1. Убедиться на деле в том, что система подходит по всем требованиям, которые мы для себя определили при выборе SIEM, отладить тонкости и нюансы архитектуры перед внедрением.
2. Подключить все критически значимые источники, ради которых первоначально и задумывалось внедрение SIEM.
3. Сравнить несколько систем, в идеале — на основе чек-листа и требований выбрать две и начать с них. «Пилот» большего количества систем будет как минимум неэффективным из-за больших затрат ресурсов ИБ и ИТ-специалистов и может не уложиться в рамки бесплатного периода. Помимо этого, интегратор не всегда готов поддерживать пилотную эксплуатацию множества систем. Обращение к иным интеграторам для тестирования систем со всего рынка сделает «пилот» слишком долгим и дорогим, даже не учитывая последующее внедрение.
4. Выбрать объём лицензирования согласно событиям в секунду с источников, чтобы при внедрении не оказалось, что купленная лицензия уже заканчивается на середине подключения источников и требует расширения.
5. Понять, интересен ли вообще этот продукт в инфраструктуре организации и не потребует ли он кардинальных доработок прежде, чем от SIEM будет какая-либо польза. Например, может оказаться, что в компании много самописных сервисов и систем, вследствие чего написание коннекторов и правил корреляции превратится в невыполнимую задачу.

Процесс «пилотирования» SIEM и выгода от него

Для начала важно составить план и прописать все требования к системе. На основании этих требований подготавливается чек-лист, на основе которого будет оцениваться успешность проведения «пилота». Дальше разворачиваются и готовятся виртуальные машины или физические серверы с операционной системой под требования SIEM. Рассмотрим архитектуру и требования к «железу» на примере той же KUMA от «Лаборатории Касперского».

• Ядро предоставляет веб-интерфейс для администраторов и аналитиков, а также является хранилищем настроек и центром координации для всех остальных служб.
• Коллектор отвечает за получение событий и их предварительную обработку: нормализацию, фильтрацию, агрегацию и обогащение данными из внешних источников.
• Коррелятор обрабатывает нормализованные события от коллекторов и применяет корреляционные правила для обнаружения взаимосвязей между событиями.
• Хранилище отвечает за хранение и поиск событий. Поиск можно выполнять либо в явном виде через веб-интерфейс, либо через виджет панели мониторинга или отчёта, а также с помощью функциональности ретроспективного поиска.

Рисунок 1. Архитектура SIEM KUMA от «Лаборатории Касперского»

Если «пилотирование» производится на физических мощностях заказчика, то он предоставляет удалённый доступ либо подготавливает физические рабочие места для инженеров интегратора. Это — организационный этап.

После того как вычислительные мощности будут готовы, начнётся этап установки ПО SIEM, а также вспомогательных программ (набор последних зависит от выбранной системы; как пример, это может быть дополнительный браузер). Дальше подготавливаются учётные записи для доступа в систему и начинается процесс конфигурирования как самой SIEM, так и источников, логи от которых мы ожидаем увидеть в консоли. Затем для SIEM открываются необходимые порты для получения трафика с логами из источников событий, и далее идёт накопление поступающей информации.

После того как события начнут поступать, понадобится рассмотреть, какие инциденты генерируются и насколько много среди них ложноположительных. Это нужно для того, чтобы понять, насколько большая работа предстоит в рамках последующего внедрения и индивидуализации системы. Дальше заказчик эксплуатирует систему на протяжении некоторого времени — как правило, нескольких недель.

По окончании «пилотирования» заполняется чек-лист, составленный на начальном этапе, отмечается, корректно ли настроена и работает система, все ли основные критически важные возможности протестированы. Если тестировалась не одна система, то в отчёте делается несколько чек-листов, по которым сравниваются инструменты и оценивается степень удовлетворённости потребностей. На основании этой оценки заказчик уже может принять решение.

Кстати, «пилотирование» SIEM может быть полезно не только для выбора решения. Приведём пару примеров.

Пример № 1

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

Пример № 2

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

Наконец, офицер безопасности в рамках пилотирования SIEM сможет проверить работоспособность и корректность настроек комплекса средств защиты информации, а также достоверно оценить поведение сотрудников и эффективность ИБ-процессов во время активных инцидентов.

Что делать дальше? Само внедрение

Ниже — небольшое руководство по быстрому старту внедрения. Здесь я собрал всё, что важно не забыть.

1. Написать техническое задание (ТЗ) с учётом выявленных на «пилоте» аспектов: всё, что было обозначено в отчёте по «пилоту», должно лечь в основу будущего ТЗ.
2. Определиться с реализацией SIEM: достаточно ли собственных ресурсов для внедрения и настройки системы или необходима помощь подрядчика в области ИБ.
3. Определиться с финальной архитектурой и предусмотреть все необходимые модули и лицензии для корректной работы SIEM, выделить требуемые мощности.
4. Подготовить карты готовности ко внедрению и убедиться согласно чек-листу, что всё готово: например, произведена настройка смежных систем, настроены правила межсетевого экранирования и т. д.
5. Разработать технический проект и рабочую документацию на SIEM-систему, отражающие процесс её установки в реальную инфраструктуру. Эта документация должна содержать всю необходимую функциональность для будущих операторов системы и быть чем-то вроде вики-справочника, где можно найти всё необходимое. Также важно не забыть о разработке регламентов работы с системой и расследования инцидентов.
6. Установить систему, активировать лицензию, произвести обновление до финальной версии. Реализовать интеграцию со смежными системами, в частности — со службой каталогов (например, Active Directory), почтой, средствами мониторинга инфраструктуры, инструментами резервного копирования и т. д.
7. Подключить необходимые источники событий.
8. Написать правила нормализации для систем, которые не входят в список поддерживаемых у выбранного производителя.
9. Разработать правила агрегации и обогащения событий.
10. Подстроить правила корреляции в части важности генерируемых инцидентов под инфраструктуру компании либо, при необходимости, написать свои правила корреляции.
11. Обработать ложноположительные инциденты, то есть убрать такого рода срабатывания.
12. Скорректировать ИБ-процессы и встроить в них инструмент SIEM.

Процесс эксплуатации

Наконец, нужно принять тот факт, что SIEM — это не та система, которую «поставил и забыл». Вот на что важно обращать внимание в рамках эксплуатации решения:

1. Важно помнить, что новые события требуют свободного места на дисках. Необходимо проводить аудит поступающих событий и их всплесков, а также настроить архивацию событий старше определённого возраста. Для исключения потери данных оптимальным решением будет использование кластера и / или резервное копирование архивных логов (не все SIEM-системы поддерживают подобную функциональность, но в некоторых она отлично реализована — например, в той же KUMA).
2. ИБ-специалистов нужно обучать работе с SIEM-системой, написанию новых правил, расследованию инцидентов и даже анализу не входящих в инцидент событий. Грамотный инженер, анализируя события, может обнаружить инцидент, который не увидела система, и затем автоматизировать обнаружение ему подобных, пополнив базу знаний новым правилом корреляции.
3. Важно составить и актуализировать внутренние нормативные документы (например, регламент расследования инцидентов), привести их к актуальным целям, задачам и потребностям функционирования SIEM.
4. Для поддержания работоспособности системы требуется постоянная актуализация настроек, правил корреляции событий и коннекторов согласно имеющемуся составу объектов инфраструктуры, а также периодическое обновление версии SIEM и её базы знаний.
5. Также важно контролировать исполнение указанных в соглашении о качестве (SLA) требований по реагированию и обнаружению инцидентов, их обработке и расследованию. В некоторых случаях может понадобиться пересмотр SLA.

Для того чтобы система была тем самым надёжным мощным инструментом контроля и мониторинга событий по информационной безопасности, этим аспектам нужно уделить должное внимание.

Выводы

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