Как будет выглядеть распределенная SIEM?

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

В – мы следим за этим пространством уже несколько лет, и когда я исследовал пространство для третьей версии Radar Report, я столкнулся с теми же проблемами и рассказами от поставщиков, которые сводятся к тому, чтобы «делать больше». менее”.

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

Исследование IBM показало, что в среднем требовалось 277 дней — около 9 месяцев— для выявления и локализации нарушения. Таким образом, SIEM должны хранить данные примерно в течение одного года, чтобы поддерживать действия по поиску угроз.

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

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

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

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

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

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

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

Не будем забывать, что одним из основных преимуществ SIEM является вышеупомянутая функция корреляции, которая влечет за собой установление очевидных или неочевидных связей между несколькими источниками данных. Здесь организаторы могут координировать корреляции, сопоставляя только релевантную информацию из разных источников. Их можно фильтровать по таким базовым параметрам, как временные метки, использовать предварительно обученные алгоритмы машинного обучения или использовать структуру MITRE ATT&CK для общих шаблонов.

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