Журнал Реальность
Очень часто организация ведет свои журналы (или их подмножество), часто пересылая их в систему управления инцидентами и событиями безопасности (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.
Вот описание того, как работает поток:
- Наблюдайте за файлом, в который передаются журналы. При необходимости его можно заменить прослушивателем TCP или UDP.
- Сообщите NiFi, что они имеют тип mime.type «text/plain» и разбейте каждую новую строку (то есть каждый новый журнал) на отдельный файл потока.
- Извлеките поля из сообщения и сохраните их как атрибуты файла потока:
Теперь вы можете увидеть в потоковом файле атрибуты, которые мы проанализировали:
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 в зависимости от того. Несмотря на то, что эти услуги стоят дорого, при правильном выполнении они значительно уменьшат общую стоимость владения.