Есть два основных направления:
Но! Очень важно соблюсти баланс: разгружая таким образом SIEM-систему, мы нагружаем команду. И если в случае с перегрузкой SIEM достаточно просто масштабировать систему, то команда – актив гораздо более ценный и более чувствительный к перегрузкам.
Лучшие практики уже достаточно давно известны, они заключаются в поступательном наращивании возможностей SOC. Попытка сбора избыточных данных и работы с ними без методологической основы и процессной модели – основная причина избыточной нагрузки как на SIEM, так и на персонал. Мы рекомендуем отказаться от хранения сырых событий для части источников, использовать нормализацию только для необходимых в корреляции, а контекстную информацию хранить в ненормализованном виде с точечной настройкой сроков и правил архивации, распределять нагрузку, используя агентский сбор там, где это возможно.
Если достигнут предел производительности, и нет ресурсов, чтобы оперативно заменить оборудование или докупить лицензии, нашу SIEM можно масштабировать горизонтально. Часть мощностей переносится на другое, даже более слабое железо, там система может хранить данные или производить миноритарные аналитические операции. Во-вторых, можно исключить из лога источников события нормальной работы – это снизит поток данных на несколько порядков и оставит в фокусе только сбои и угрозы. Так потеряется детализация, необходимая в расследованиях, но в качестве крайней или временной меры это допустимо.
Для правильной разгрузки уже функционирующей SIEM-системы необходимо:
Не требуется оптимизация SIEM, если правильно настроены система, правила корреляции и источники. В иных случаях необходимо проанализировать все процессы SIEM. Например, для снижения нагрузки можно использовать LM-решение для глубокого/холодного хранения и второстепенных логов, которые не подлежат корреляции. В SIEM следует оставлять только события, необходимые для корреляции и оперативного расследования оповещений. При создании правил корреляции и нормализации рекомендуется использовать продвинутые возможности среды разработки и оптимизировать разрабатываемые правила. Например, можно использовать инструмент бенчмаркинга в R-Vision R-Object для замера скорости работы правила.
Мы рекомендуем проанализировать работу SIEM-системы с самого начала, в частности, с подключения и мониторинга источников. Во время запуска MaxPatrol SIEM версии 8.2 этим летом мы выдавали нашим пользователям специальный гайд, в котором рассказали, какие источники и в каком порядке нужно подключать, как их настраивать. На основе собранной информации мы уже можем определить, какая экспертиза в системе требуется, какие правила и табличные списки можно отключить. Кроме того, нашим клиентам мы предлагаем мигрировать на LogSpace, что позволит высвободить ресурсы под выполняемые задачи.
Следует начать с настройки глубины логирования источников, чтобы собирать и обрабатывать только нужные события. Не менее важна настройка дополнительных правил фильтрации и агрегации событий, а также оптимизация существующих правил корреляции для повышения точности выявления инцидентов и снижения вероятности ложноположительных срабатываний. В части хранения и ускорения поиска событий поможет настройка индексов и использования горячих, теплых или холодных нод для оперативного хранения событий, а также архивов – для экономии дискового пространства при хранении исторических данных.
Можно применить несколько приемов.
Во-первых, необходимо сегментировать активы в инфраструктуре, выделяя действительно важные. Во-вторых, предфильтрация событий: избавляться от мусорных данных до начала их обработки. В-третьих, выбирать SIEM-решения с максимальной возможной степенью сжатия событий не только на хранении, но и на всех этапах передачи, чтобы сократить нагрузки на каналы связи.