Взгляд на управление SIEM

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

Я управлял SIEM (Splunk, Graylog, ELK и т. д.) в течение многих лет, и это лишь некоторые из сбоев ведения журнала, с которыми я столкнулся.

  • Частичное отключение ведения журнала хоста → Только часть парка прекратила ведение журнала
  • Редкие потоки журналов → поток журналов, который выводится только раз в неделю, ничего не записывает в течение двух недель.
  • Изменения формата журнала → Формат данных журнала изменился, поэтому, хотя журналы все еще передаются, они не вызывают предупреждения системы безопасности.
  • Скрытые журналы → Проблема с извлечением времени привела к тому, что журналы отфильтровывались предупреждениями безопасности.
  • Потоки журналов, указывающие на сбой → Критический процесс неоднократно печатал ошибки, но журналы поступали в правильном формате.
  • Массовый рост количества журналов → Опечатка в приложении привела к тому, что журналы увеличились в десять раз по сравнению с предыдущим размером.
  • Сбой вышестоящего агрегатора → У вышестоящего сборщика журналов произошла ошибка, которая привела к сбою потока журналов.

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

Я усвоил много уроков на этом пути. Эти уроки можно разделить на две категории: уроки по стратегии оповещения журналов и уроки управления журналами.

Моя формула оповещения журнала (от простого к сложному):

  • Существование журнала → Убедитесь, что журналы передаются для каждого индекса и типа журнала.
  • Задержка журнала → Убедитесь, что последний пакет полученных журналов имеет отметку времени в соответствующем временном окне.
  • Целостность журнала → Убедитесь, что журналы поддаются разбору, содержат нужные вам поля и не усекаются.
  • Пропускная способность журнала → Убедитесь, что количество событий или общий размер журналов не сильно изменились. Это касается как падения, так и роста логов (обнаружение аномалий).
  • Покрытие журнала → Убедитесь, что частичные отключения обнаружены, проверив, что каждый актив сообщил о них.

Важные уроки, которые я усвоил:

  • Определите стандартный шаблон приема журналов.
  • Помните о важности управления активами.
  • Содействуйте сотрудничеству между DevOps и командами безопасности для реализации высокоточного мониторинга.

Фазы конвейера журналов

Этапы трубопровода следующие:

  • Создание относится к генерации исходного события.
  • Агрегация — это процесс, посредством которого журналы собираются, группируются и обогащаются перед их отправкой в ​​SIEM.
  • Извлечение — это процесс, который SIEM использует для преобразования данных журнала в структурированные события.
  • Хранение — это процесс получения структурированных событий и помещения их в соответствующие индексы.

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

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

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

Если вы являетесь инженером DevOps в продукте, вы обычно отвечаете за создание и агрегирование, а не за извлечение и хранение. Распространенной проблемой во время создания является слишком много или слишком мало логирования. Даже простая опечатка может привести к тому, что журналы выйдут из-под контроля и вызовут каскадный сбой в остальной части конвейера. Агрегация иногда является локальной (например, хост-процесс, который собирает журналы партиями), но также может выполняться через сервер журналов (например, logbuf, logstash, WEF).

Формула мониторинга журнала

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

В следующих разделах более подробно рассматривается каждый из них.

Мониторинг журнала: наличие

Существование — простейшая форма наблюдения. Идея здесь состоит в том, чтобы просто обеспечить поток журналов. Для каждого индекса вам просто нужны <Index>, <Type>, <Time Frame> и <Alert Mechanism>.

На английском языке это будет звучать так: «Проверьте наличие новых журналов в течение последних <Time Frame> для <Index>, <Type>, и если вы ничего не найдете, отправьте <Alert>».

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

Мониторинг журнала: задержка

Всегда существует задержка между созданием события и его индексацией в SIEM (т. е. когда событие доступно для поиска).

В идеале это время должно быть как можно короче (менее одной минуты), чтобы можно было быстро реагировать на действия противника. Однако есть много причин, по которым это может быть не так.

Например:

  • Источник журналов группирует журналы в группы по времени.
  • Источник журнала имеет некоторую форму сбоя.
  • Время хоста в источнике журнала отключено.
  • Прием SIEM перегружен и резервируется.
  • Подхватываются старые файлы журналов из запеченного образа или контейнера.

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

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

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

  • Возраст самого нового события (насколько близка к настоящему времени эта партия журналов?)
  • Возраст самого старого события (насколько далеко в прошлое уходит эта партия журналов?)
  • Медианный, средний или 99%-й возраст событий (каков средний возраст журналов?).

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

При желании вы можете добавить эти три проверки в формат CSV Мониторинга журналов: проверка существования. Опять же, это будет лучше выглядеть в Terraform.

Мониторинг журнала: целостность

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

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

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

Мониторинг журнала: пропускная способность

Первоначально я не считал оповещение о пропускной способности высокоприоритетным. Пока мы получали журналы в нужное время и с правильными данными, все было в порядке, верно? Неправильный.

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

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

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

Мониторинг журнала: покрытие

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

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

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

Собираем все оповещения вместе

Если вы хотите охватить все оповещения, описанные выше, вы, вероятно, выходите за рамки того, для чего оптимален CSV. Вам также нужно будет написать свою собственную автоматизацию CSV-to-alert, что является еще одной интеллектуальной фишкой, которую вам, вероятно, не придется тратить. Я рекомендую использовать инструмент «инфраструктура как код», такой как Terraform, для создания необходимой абстракции и автоматизации. Ниже приведен пример того, как может выглядеть монитор журнала Terraform:

Это всего лишь псевдокод, но я надеюсь, что он вдохновит вас на настройку мониторинга SIEM. Есть ли еще один аспект, который я упускаю? У вас есть более простая техника для мониторинга? Пожалуйста свяжись со мной! Я всегда стремлюсь узнать больше.

Важные уроки, извлеченные при мониторинге SIEM

Определение стандартного шаблона приема журналов

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

Мы предоставили каждой команде на выбор агента, API, стороннюю интеграцию или шаблон, включающий перетаскивание файлов в корзину S3. У этого подхода было много недостатков.

Предоставленный поставщиком API/агент

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

  • Первая проблема заключалась в том, что эта модель не работала ни для одного из наших более сложных сетевых требований (не у всех был прямой доступ через API к SIEM). Это также не сработало ни для одного SAAS.
  • Вторая проблема заключалась в том, что при каждом крупном обновлении или улучшении инфраструктуры нам приходилось проводить скоординированное обновление, чтобы гарантировать, что конвейеры людей не сломаются. В компании из тысяч инженеров это была огромная задача.
  • Третья проблема заключалась в том, что мы не могли контролировать, как люди планируют резервирование и восстановление в случае сбоя самой SIEM. Некоторые люди писали, что автоматизация повторной доставки журнала будет повторяться до тех пор, пока не будет успешно. Другие реализации просто удаляли данные, что приводило к частичному отключению журнала.

Интеграции, предоставляемые поставщиком

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

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

Удалить данные из хранилища BLOB-объектов

Это было, безусловно, лучшее решение.

Хранилища BLOB-объектов (Azure Blob Storage, AWS S3, Google Storage Bucket) масштабируются горизонтально и обладают исключительно хорошей избыточностью. Кроме того, для этих инструментов есть клиенты, написанные на всех языках. Его было легко описать, легко поддерживать и трудно потерять данные.

Ниже приведена архитектура:

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

На практике эта модель работает очень хорошо по следующим причинам.

  1. Доставка журнала сдвинута к краям. Владелец журнала несет ответственность за хранение журналов в хранилище объектов, таком как AWS S3. Доступный инструментарий огромен, а облачные хранилища объектов горизонтально масштабируются до очень разумных уровней.
  2. Прием журналов прост и масштабируем по горизонтали. Можно просто продолжать добавлять воркеров, чтобы получать события доставки журналов и выполнять фильтрацию, извлечение или обогащение в последнюю минуту. Это можно легко реализовать как автоматически масштабируемый набор рабочих процессов в необработанных вычислениях или как контейнер.
  3. Договор между производителем и потребителем понятен. Если журналы не доставляются в хранилище объектов, виноват производитель. Если логи поступили в хранилище объектов, но не в SIEM, то виноват потребитель. Если возникают споры о целостности журналов, можно просмотреть необработанные журналы в хранилище объектов для диагностики.
  4. Продавец-агностик. Благодаря уровню абстракции, обеспечиваемому хранилищем объектов, можно изменить лежащий в основе SIEM без необходимости перестраивать все конвейеры. Вы даже можете запускать их параллельно на этапе сравнения или миграции.

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

Важность управления активами в SIEM

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

Примеры активов включают списки:

  • каждой виртуальной машине, конечной точке, брандмауэру, VPN-устройству и т. д.
  • сторонние приложения SAAS и вышестоящие репозитории, с которыми вы интегрируетесь.
  • список используемых общедоступных IP-адресов.
  • список используемых доменов.

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

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

Мониторинг журналов: совместная работа службы безопасности и DevOps

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

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

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

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

Это предложение должно охватывать следующее:

  • установка порогов предупреждений вместе (каковы все значения для существования, задержки и пропускной способности?).
  • определение критических полей (какие поля нужны команде безопасности для каждого конвейера?).
  • критичность (какие конвейеры необходимы для ADS быстрого реагирования и должны вызывать инженера, а какие могут дождаться обычной поддержки с 9 до 5?).
  • документирование контракта на поддержку между командами (когда что-то неизбежно выходит из строя, как две команды работают вместе, чтобы совместно найти основную причину и решить проблему?).

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

Заворачивать

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

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