Для чего нужна система SIEM и как её внедрить TADетали. Информационные технологии, ИБ - Управление информацией и событиями в системе безопасности (SIEM), Россия
 
2017/10/10 09:35:25

Для чего нужна система SIEM и как её внедрить? TADетали

Что такое SIEM-системы? Какие задачи решают такие решения? Каковы особенности их внедрения и эксплуатации? В этих вопросах TAdviser разбирался совместно с экспертами компании «АМТ-Груп».

Содержание

Что такое SIEM?

Системы SIEM (Security information and event management) происходят от двух классов продуктов: SIM (Security information management) — управление информационной безопасностью и SEM (Security event management) — управление событиями безопасности. Одно из первых упоминаний о SIEM было в 2005 году от аналитиков Gartner.



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

Производители SIEM иногда разделяют данный класс продуктов на SIEM первого и второго поколения (это можно рассматривать как маркетинговый приём). Как правило, под вторым поколением специалисты понимают более многофункциональный инструмент с возможностью интеграции со сторонними продуктами (системы управления политиками ИБ, c Threat Intelligence платформами, функции Network Behavioral Analysis и др.).

Использование SIEM второго поколения с функциями Threat Intelligence, в частности, предлагает сервис AMTSOC. Данная интеграция позволяет создавать корреляционные правила с критерием поиска в виде обновляемых в TI баз индикаторов. Это существенно повышает эффективность корреляции, превращая статическую корреляцию в динамическую.

Функциональные задачи SIEM

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

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

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

Панели визуализации (dashboards): графики различных типов и форматов, таблицы, списки и другая визуализация по текущим событиям и инцидентам. Визуализация в значительной мере влияет на общее восприятие продукта и является важным элементом процесса Incident Monitoring/Tracking.

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

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

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

Какие компоненты входят в состав SIEM?

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

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

Коллекторы: отвечают за сбор сырых событий. Могут поддерживать массу различных протоколов и сервисов: Syslog, Windows Event Forwarding, SDEE, SNMP Trap, клиентов баз данных (MSSQL, Oracle и т. д.) и другие специфичные сервисы от разных производителей.

Сам сбор событий может происходить как в пассивном режиме (например, syslog), так и в режиме "по запросу". Коллектор чаще всего отправляет нормализованные события в коррелятор, а сырые события отправляются в хранилище данных. В различных реализациях от разных производителей схема взаимодействия коллектора с другими компонентами может отличатся.

Хранилище данных: отвечает за хранение сырых событий. Возможны реализации с хранением нормализованных событий.

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

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

Упомянутые SIEM второго поколения могут содержать также дополнительные компоненты: сбор Flow и SPAN-трафика, BI-компоненты, TI-модуль, модули защиты от фрода, управления политиками ИБ.

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

Каковы основные задачи и возможности современных SIEM-решений?

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

Задача SIEM номер один – регистрация инцидентов в режиме Real-Time.

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

Современный SIEM, по сути, уже должен содержать в себе Big Data технологии, обрабатывающие события ИБ как некий интенсивный поток телеметрии. От SIEM требуется как скорость, так и удобство – потому что это основной инструмент аналитики ИБ, предназначенный для расследования инцидентов, поиска следов таргетированных атак (Threat Hunting).

Тренды развития SIEM идут в сторону добавления функций Machine Learning и поведенческого анализа, что позволяет передать на откуп автоматизации все больше и больше рутинных задач Incident Monitoring, Forensic, Investigation. На практике это позволит обнаруживать не только предопределенные вручную инциденты, но и приблизиться к автоматизации процесса создания правил корреляции, что является ключевой и самой сложной задачей при настройке и поддержке SIEM (особенно на больших внедрениях).

На какие особенности внедрения SIEM нужно обращать внимание прежде всего?

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

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

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

Третий вопрос – обеспечение надежности SIEM. Может заключатся как в дублировании компонент для отказоустойчивости, так и в дублировании по регионам для катастрофоусточивости.

Четвертый вопрос – срок хранения событий и их защита для возможности ретроспективного анализа в течение необходимого периода времени и для минимизации риска компрометации/потери данных.

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

Шестой вопрос – соответствие текущим требованиям законодательства, регуляторов, отраслевых и корпоративных стандартов. Например, недавно принятый Федеральный Закон «О безопасности критической информационной инфраструктуры Российской Федерации», а также некоторые требования регулятора, могут предписывать использовать сертифицированный ФСТЭК SIEM.

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

Как выбираются источники данных для SIEM?

В идеальной ситуации чем больше источников событий – тем меньше вероятность пропустить важное событие и не идентифицировать значимый инцидент, получив так называемую ошибку второго рода (False Negative).

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

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

Иногда лучшие практики рекомендуют "обрезать" объем событий посредством определения важности (severity) и конкретных модулей-источников (facility).

Подобные приёмы также используют и для сохранения производительности SIEM.

Каковы особенности эксплуатации SIEM-решений? Требуется ли поддержка?

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

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

Например, в сервисной модели AMTSOC задачу взаимодействия с производителем SIEM берет на себя оператор данной экспертной услуги.

В чем преимущества сервисной модели SIEM? Какую ответственность несет поставщик сервиса?

Для начала нужно выделить два элемента сервисной модели:

1. Сервисная модель продажи оператором коммерческого SOC самого SIEM как инструмента: MSSP (Managed Security Service Provider);

2. Экспертиза ИБ, предоставляемая на аутсорсинг сервисными операторами коммерческого SOC.

В итоге сервисная модель как сочетание экспертизы команды коммерческого SOC и OPEX-модели инструмента SIEM имеет следующие преимущества:

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

Как сделать выбор - классическая или сервисная схема SIEM? По каким параметрам можно оценить выгоду той или иной модели?

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

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

Специалисты AMTSOC часто предлагают клиентам наглядные графики со сравнением затрат на OPEX и CAPEX модель при одинаковых параметрах SIEM. Чаще всего OPEX оказывается значительнее выгоднее как по затратам, так и по набору функций – ведь MSSP модель почти всегда предлагает клиенту не просто инструмент, а ещё и набор сервисных процессов мониторинга ИБ:

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

В итоге очевидно, что OPEX модель предлагает больше за меньшие деньги. Отказаться от такого подхода можно только в силу внутренних политик, предписывающих сосредоточение всех функций внутри организации или в целом консервативности ИБ. Данная демонстрация показывает причину того, что рынок услуг аутсорсинга ИБ растёт бо́льшими темпами чем рынок ИБ в целом.

187