Журнал Реальность

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

  • Хранение журнала — такие фреймворки, как PCI DSS, требуют, чтобы вы хранили данные журнала в течение определенного периода времени.
  • Обнаружение угроз — выполнение аналитики сообщений журнала для получения значимых обнаружений для аналитиков и расследований.
  • Threat Hunting/Incident Response — для просмотра исторических артефактов, связанных с угрозами и инцидентами.

Налог на SIEM

SIEM — это полезные платформы для корреляции событий и анализа данных журналов, но все они требуют лицензии. Некоторые SIEM лицензируются по объему принимаемых данных (например, Splunk или Microsoft Sentinel) или по числу событий в секунду (например, LogRhythm или ArcSight).

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

Ты это видел?

Рассмотрим следующий сценарий в качестве практического примера для демонстрации концепций:

  • Вы ежедневно собираете большой объем данных журнала брандмауэра со всего вашего имущества.
  • Вы должны хранить эти данные по нормативным причинам в течение 12 месяцев и более широких расследований.
  • Единственная возможность обнаружения, для которой вы используете эти журналы, — это сопоставление с индикаторами компрометации (IoC), полученными из аналитики угроз.

Один из способов решить эту проблему ценности — выполнить сопоставление индикатора компрометации (IoC) вне SIEM и пересылать только те записи, которые имеют отношение к рабочему процессу SIEM, сохраняя при этом все сжатые данные в корзине Amazon AWS S3 или в хранилище блогов Microsoft Azure.

Установка

Чтобы продемонстрировать описанный выше сценарий на практике, нам нужно несколько вещей:

Данные

Для этого мы решили использовать некоторые данные Boss of the SOC v1, предоставленные Splunk (https://github.com/splunk/botsv1), в частности журналы трафика Fortinet. Этот набор данных очень удобен для экспериментов; он имеет открытый исходный код и доступен в формате JSON, а также в индексированном формате Splunk, что значительно упрощает его использование вне Splunk.

Журналы трафика Fortinet содержат около 7 675 023 записей, что соответствует примерно 89 EPS (при условии, что они были распределены равномерно в течение дня) и эквивалентны примерно 4 Гб.

В этих данных я уже знаю, что IP-адрес 97.107.128.58 появляется 7 раз, поэтому мы выберем использование этого IP-адреса в нашем смоделированном списке IoC аналитики угроз.

Для этого сценария мы также предположим, что эти данные передаются в файл, т. е. они могут быть перехвачены чем-то вроде Syslog-NG.

Место хранения

Здесь не требуется ничего слишком сложного, просто корзина Amazon AWS S3, которую можно использовать для устаревания наших данных через 12 месяцев, и экземпляр Splunk.

Если вы хотите продолжить и настроить экземпляр Splunk для экспериментов, я бы рекомендовал создать его в докере: https://hub.docker.com/r/splunk/splunk/

Конвейер данных

Есть несколько инструментов, которые вы можете использовать здесь, но в моем примере я собираюсь использовать Apache NiFi (https://nifi.apache.org/), в основном потому, что это мой инструмент, когда у меня есть конвейер данных. построить, легко начать работу и имеет возможность масштабирования, когда вы хотите использовать его в производстве.

Подготовка данных

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

https://github.com/umair-akbar/DataCleanse

Формат данных в этом случае будет выглядеть примерно так:

Из этой сути видно, что эта дата выглядит как CEF, но недействительна (в CEF нет поля типа).

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

Конвейер данных предварительной обработки

Используя Apache NiFi, мы просматриваем файл, анализируем строки данных, сравниваем его с нашими IoC и конвертируем в JSON или отправляем в Splunk в зависимости от результата. Анализ оставшихся данных в формате JSON означает, что вы можете искать их в S3 даже после их сжатия. Это позволяет вам не выбрасывать нашу хорошую работу с конвейером позже, поскольку вам не нужно беспокоиться о повторном приеме данных позже.

Ниже показан поток, который я настроил, например, в Apache Nifi (который я запускал в докере) для обработки входящих файлов журнала. Вы можете получить этот шаблон для импорта в свой собственный экземпляр Nifi, взяв XML-файл из этого списка: https://gist.github.com/umair-akbar/b3773b36ee665d7bbec4549f0fc81799.

Вот описание того, как работает поток:

  1. Наблюдайте за файлом, в который передаются журналы. При необходимости его можно заменить прослушивателем TCP или UDP.
  2. Сообщите NiFi, что они имеют тип mime.type «text/plain» и разбейте каждую новую строку (то есть каждый новый журнал) на отдельный файл потока.
  3. Извлеките поля из сообщения и сохраните их как атрибуты файла потока:

Теперь вы можете увидеть в потоковом файле атрибуты, которые мы проанализировали:

4. Следующий модуль добавляет к каждому журналу атрибут «угроза» со значением «да» или «NULL». Он настроен таким образом, что если какой-либо из IP-адресов в локальном CSV (который вы можете обновить из TIP) соответствует атрибуту dstip, значение, хранящееся рядом с ним, должно быть добавлено к атрибуту «угроза». В этом случае мой CSV выглядит просто так:

IP, угроза
97.107.128.58, да

5. Route Hits отправляет копию журналов со значением «да» в модуль «PutSplunk», который вставляет их в экземпляр Splunk.

6. Атрибуты всех журналов, как попаданий, так и не попаданий, затем преобразуются в JSON, который сохраняется в содержимом потокового файла, перезаписывая оригинал.

Затем эти записи снова объединяются, поэтому у нас меньше (минимум 100) файлов потока большего размера, например:

7. Затем эти файлы переименовываются с отметкой времени, сжимаются как минимум до 100 файлов и отправляются в корзину S3.

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

Результат

Как и предполагалось, 7 из наших записей в журнале имели IP-адрес назначения 97.107.128.58, и, поскольку они представляют собой пары ключ/значение, Splunk проанализировал их из коробки:

Это эффективно сократило мои 7 675 023 события в день до 7, что с точки зрения практического лицензирования означало:

  • Мои 4 ГБ лицензионного уха, отмеченные для журналов, которые мне больше не нужны, были уменьшены до 0,002685 МБ.
  • Мои приблизительные 89 EPS были уменьшены примерно до 0,000008 EPS.

Кроме того, размер журналов в хранилище S3 в S3 уменьшился примерно на 90 % (результаты будут различаться в зависимости от настройки уровня сжатия):

Эти сжатые журналы могут быть найдены службами Amazon AWS Athena или Microsoft Data Lake Analytics в зависимости от того. Несмотря на то, что эти услуги стоят дорого, при правильном выполнении они значительно уменьшат общую стоимость владения.