6 типичных ошибок при внедрении SIEM-решений и как их избежать

6 типичных ошибок при внедрении SIEM-решений

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

По данным Gartner, компании часто покупают второе или третье SIEM-решение, потому что действующее решение не оправдало ожиданий. Отсутствие планирования, недооценка бюджета, операционных и структурных потребностей, а также необходимых ресурсов и навыков – вот наиболее распространенные причины неудавшихся SIEM-проектов.

Специалисты Gartner выделили 6 типичных ошибок внедрения SIEM и разработали рекомендации для руководителей отделов безопасности и управления рисками, как их избежать.

Основные сложности

  • Чтобы избежать провала или приостановки проекта внедрения SIEM, необходимо тщательно планировать, четко понимая масштабы, цели и сценарии использования. Многие организации недооценивают важность и объем планирования перед покупкой и внедрением, что и приводит к провалу проекта.
  • Многие организации не осознают, что включение логов безопасности может существенно увеличить нагрузку на сервер мониторинга (на процессор и I\O).
  • Компании недооценивают ресурсы, необходимые для эффективного функционирования SIEM, и часто делают покупку без оценки своих возможностей.

Рекомендации

Чтобы избежать распространенных ошибок развертывания SIEM, руководителям отделов безопасности и управления рисками следует:

  • До выбора конкретного SIEM-решения определить четкие цели, сценарии использования и требования, в том числе планы по запуску, администрированию и работе с SIEM.
  • Разработать «дорожную карту» на первые 6-12 месяцев, включающую развертывание SIEM и поэтапное внедрение от 5 до 7 сценариев использования.
  • При планировании покупки, внедрении и расширении SIEM выбрать модель, ориентированную на конкретный результат, и использовать ее для выбора только тех источников данных, которые нужны для выбранных сценариев.
  • Придерживаться поэтапного подхода в условиях ограниченных ресурсов. Рекомендуется для начала поработать с CLM-инструментами (централизованный лог-менеджмент), чтобы ознакомиться со всеми тонкостями SIEM.
  • Использовать внешнего поставщика услуг SIEM для исправления неудачных реализаций SIEM и в дальнейшем учитывать свои возможности и ресурсы.

Ошибка № 1: Отсутствие детального планирования перед покупкой

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

Большинство SIEM-решений обеспечивают надежное управление информацией (SIM) и   управление событиями (SEM) в системе безопасности. Существуют также различные вариации коробочных решений с внешними интеграциями, например, интегрированные рабочие процессы (workflow), учёт сетевого трафика (NetFlow), мониторинг сети, обнаружение и реагирование на атаки конечных точек (EDR). Без четкого планирования правильное определение масштаба проекта превращается в гадание на кофейной гуще.

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

SIEM-инструменты подходят не для каждой организации. Они нуждаются в квалифицированных кадрах и выделенных ресурсах, опираются на четко структурированный рабочий процесс и не компенсируют нехватку инвестиций, функциональности или навыков. Если в вашей организации как раз наблюдается последнее, то вам лучше рассмотреть другие варианты – от сторонних сервисов безопасности (managed security services) или решений для обнаружения и реагирования на атаки (MDR — managed detection and response) до внешних SIEM. Это позволит инвестировать в то, что действительно подходит вам, с наименьшими усилиями и рисками.

Gartner рекомендует следующий подход к планированию и внедрению SIEM:

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

И затем использовать эту информацию для:

  • Оценки среды и ресурсов.
  • Оценки требований к архитектуре и методов сбора данных, чтобы ответить на следующие вопросы:
    • какие усилия потребуются для интеграции источников данных,
    • поддерживают ли эти источники ведение журналов безопасности без ущерба для производительности,
    • сколько потребуется коллекторов, чтобы охватить полностью сегментированную или географически распределенную сеть,
    • следует ли включать в планирование другие организационные группы (например, специалистов по сетям или приложениям).
  • Определения способности источников данных генерировать ожидаемые события. На некоторые источники логов могут быть наложены ограничения из-за производительности, версионности программного обеспечения и т. д.
  • Проработки процесса мониторинга событий и реагирования на инциденты. Уделите особое внимание детализации сценариев реагирования (playbooks), после того как ваш SIEM начнет генерировать инциденты.
  • Создания соответствующих процессов и политик с целью оценки требуемых ресурсов для SIEM.
  • Выборатехнологии.
  • Внедрениятехнологии.

Ошибка № 2: Неправильная оценка масштаба

Попытка развернуть SIEM без предварительной оценки масштаба безнадежна. Масштаб системы служит основой для дальнейшего планирования, развертывания, внедрения и созревания SIEM-проекта и связанных с ним возможностей. Он влияет на выбор решения, архитектурные требования, необходимый штат сотрудников, а также процессы и процедуры.

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

Подробное описание факторов, которые определяют внедрение SIEM-системы, смотрите в статье Задачи внедрения SIEM. Попытки определить эти факторы после внедрения приведут к провалу проекта, потерям бюджета, времени и ресурсов, которые можно было бы направить на другие цели.

Ошибка № 3: Слишком большой масштаб планирования

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

Gartner рекомендует начать с выбора 5-7 сценариев для построения изначальной маршрутной карты (roadmap) SIEM. Сроки реализации этого этапа от 6 до 12 месяцев, в зависимости от сложности сценариев, опыта сотрудников, а также необходимости привлечения дополнительных технологий или заинтересованных сторон. Затем постепенно можно добавлять сценарии. После успешной формализации и реализации первого этапа, многие организации обнаруживают, что могут внедрять новые сценарии более эффективно.

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

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

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

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

Ошибка № 4: Мониторинг шума

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

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

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

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

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

Если Вы не знаете, что искать, то от SIEM будет мало пользы, особенно с точки зрения потенциальных издержек. С другой стороны, существуют средства поведенческого анализа — user and entity behavior analytics (UEBA), которые помогают выявлять угрозы среди нескольких систем мониторинга или источников данных. Они могут поставляться изначально с SIEM или интегрироваться с ним при необходимости. Эти средства хорошо дополняют друг друга, поскольку UEBA нуждаются в источниках данных, а SIEM являются центральной точкой их сбора.

Ошибка № 5: Отсутствие достаточного контекста

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

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

  • Выбор сценария. Определить и выделить первоначальные 1 или несколько сценариев использования, которые определяют то, что вы хотите отслеживать или достичь.
  • Определение необходимого набора данных.
  • Конфигурация источников логов. Настройка необходимых источников журналов и данных для отправки данных в/из SIEM.
  • Создание, подготовка и отбор содержимого SIEM. Наполнение SIEM контентом (правила корреляции, отчеты, информационные панели и т. д.).
  • Определение необходимых операционных процессов. Установление операционных процессов для управления этим сценарием при необходимости.
  • Тестирование сценария. Создайте ожидаемое поведение или действие и убедитесь, что все настроено правильно (см. Примечание 1).
  • Совершенствование контента и цикла процессов. Исправляйте и дорабатывайте каждый процесс и содержимое SIEM.

Ошибка  № 6: Нехватка ресурсов

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

  • Функционирование. Подразумевает управление и поддержку базовой конфигурации SIEM: своевременная установка патчей, контроль объема хранилища, добавление или удаление пользователей. Как правило, это инженерная задача, особенно, если практиковать разделение обязанностей, например, согласно
  • Наблюдение. Мониторинг событий в режиме реального времени, а также реагирование, расследование и эскалация инцидентов. Обычно этим занимается аналитик безопасности.
  • Настройка. Непрерывная оптимизация и настройка правил корреляции, отчетов и сигнатур, а также процессов, связанных с мониторингом. Как правило, это обязанности старшего аналитика безопасности или третей линии поддержки.

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

Требуемые навыки для работы с SIEM
Требуемые навыки для работы с SIEM

 

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

По оценкам Gartner, минимальный штат сотрудников для типичного среднего банка составляет от 8 до 10 человек. Они должны выполнять мониторинг событий в режиме 24/7. При этом два аналитика должны работать посменно по графику 3 дня через 4. В общей сложности получается четыре 12-часовых смен в неделю, и это без учета отпусков, больничных и текучки кадров. Кроме того, здесь не учтены менеджеры и количество реальной работы. Скорее, это минимум для обеспечения мониторинга 24/7.

Есть несколько стратегий работы с SIEM при малой численности сотрудников:

Ограничение масштаба. Адаптация объема входных данных к имеющимся ресурсам будет правильным вариантом. Это относится как к количеству источников данных, так и к масштабу сценариев. Сценарии должны быть узкими и целенаправленными, чтобы их можно было максимально автоматизировать с помощью правил корреляции. Также должна быть реалистичная оценка того, сколько сценариев могут обрабатывать имеющиеся сотрудники.

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

Привлечение внешнего поставщика услуг безопасности. Можно привлечь внешнего поставщика услуг, если из-за нехватки ресурсов или компетенций вы столкнулись с проблемами при развертывании, мониторинге или подключении новых сценариев.

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

Управляемые поставщики услуг безопасности (MSSP) предоставляют мониторинг и анализ событий в реальном времени, а также сбор логов с помощью собственного SIEM-решения для создания отчетов и проведения расследований.

MDR-провайдеры (managed detection & response) не соответствуют традиционной модели внешнего поставщика услуг безопасности, но представляют альтернативу SIEM. Эти службы обычно отслеживают конкретные элементы среды клиента и используют передовые методы анализа для выявления угроз. MDR-провайдеры, в основном, концентрируются на обнаружении угроз и редко на целях комплаенса. Они могут предоставлять собственные технологии-как-услугу для клиента. Клиенту нет необходимости приобретать коммерческий SIEM, если функции безопасности включены в SOC, удаленно предоставляемый провайдером MDR.

Еще одним вариантом является услуга стороннего персонала, предоставляемая многими провайдерами. Однако стоить это будет дорого.

Статья подготовлена по материалам Gartner.

Поделиться записью: