Если события безопасности и трафика не поступают в SIEM в стандартном формате, SOC видит полную картину слишком поздно.
В корпоративных операциях безопасности события WAAP, ADC, AAM, проверок здоровья, действий администраторов и GTM не должны оставаться заблокированными внутри консоли продукта. Команды SOC хотят видеть эти события в своих SIEM, системах аналитики логов и системах соответствия. Когда вендор хранит логи в проприетарных или сложно конвертируемых форматах, расследование инцидентов становится фрагментированным.
Разные SIEM-платформы имеют разные требования к форматам. Одни команды хотят JSON для поиска и индексирования, другие полагаются на CEF для готовых парсеров, а третьи предпочитают простой поток plainText syslog. Продукты, навязывающие единый формат, увеличивают сроки интеграции и перекладывают нормализацию логов на организацию.
В мультитенантных средах или средах с разделёнными namespace потоковая передача логов становится ещё более чувствительной. Логи каждого тенанта должны поступать в его собственный SIEM, а события из разных namespace не должны смешиваться. Единый глобальный вывод syslog не отвечает требованиям ни изоляции, ни аудитопригодности в таких архитектурах.
Объём логов — ещё одна проблема. В сценариях с высокочастотными проверками здоровья или событиями безопасности отправка каждого незначительного события в SIEM может генерировать затраты и шум. Фильтрация на уровне источника, контроль подробности проверок здоровья, несколько профилей и sampling там, где это уместно, должны быть частью операционной модели логов.
TR7 SIEM Log Streaming решает всё это с помощью транспортных профилей, ограниченных namespace, UDP/TCP syslog, поддержки RFC3164/RFC5424, форматов сообщений JSON/CEF/plainText и фильтрации на уровне источника — перенося события платформы в собственный конвейер SIEM организации.
Наш подход
TR7 рассматривает пересылку логов не как единый глобальный вывод, а как модель профилей, управляемую на уровне namespace, формата, источника и назначения.
Отдельный транспортный процесс на namespace обеспечивает изоляцию логов
Для каждого сетевого namespace может работать выделенный транспортный процесс логов. Эта модель предотвращает смешивание потоков логов разных тенантов в мультитенантных средах и обеспечивает, чтобы логи каждого тенанта поступали в его собственную цель SIEM.
Пул форматов адаптируется к разным требованиям SIEM
Сообщения логов могут создаваться как JSON, CEF или plainText. JSON служит рабочим процессам поиска и индексирования, CEF позволяет использовать готовые парсеры SIEM, а plainText обеспечивает общую совместимость с syslog.
Фильтрация источников на уровне профиля снижает лишний шум логов
Каждый транспортный профиль выбирает, какие источники логов пересылать. Действия администраторов, события проверок здоровья, уведомления, события GTM и события безопасности могут управляться отдельными профилями по мере необходимости.
Синхронизация на основе БД применяет изменения профилей без перезапуска
Транспортные профили логов синхронизируются из данных управления. При добавлении, изменении или удалении профиля соответствующий процесс namespace обновляется без перезапуска всей системы.
Возможности
SIEM Log Streaming переносит события платформы TR7 во внешнюю инфраструктуру логов через стандартные syslog-транспорты и форматы сообщений, дружественные к SIEM.
UDP-транспорт обеспечивает быстрый и простой поток syslog
UDP-транспорт — это прямолинейная выходная модель, совместимая с традиционными топологиями syslog. Может использоваться стандартный порт syslog 514, или другой порт может быть выбран на уровне профиля. Это обеспечивает малозатратную пересылку логов для надёжных LAN-сред. Поскольку UDP по своей природе не гарантирует доставку, TCP предпочтительнее для критических сред.
TCP-транспорт обеспечивает подключённый и более контролируемый поток логов
TCP-транспорт используется командами, которые хотят ориентированный на подключение поток логов к целевому SIEM. Целевой хост, порт и тайм-аут могут быть определены в профиле; типичный TCP-тайм-аут составляет 10 000 мс. TCP обеспечивает более контролируемую доставку, чем UDP, но поведение подключения должно контролироваться при замедлении целевой системы.
Поддержка RFC3164 обеспечивает совместимость с устаревшими syslog-приёмниками
RFC3164 поддерживается для интеграции с системами, использующими традиционный формат BSD syslog. Поле профиля syslogAppName может использоваться как префикс сообщения; значение по умолчанию может быть TR7_syslog_client. Это обеспечивает широкую совместимость для старых SIEM или syslog-приёмников. Данный формат является практичным выбором в средах, не требующих современных структурированных данных.
Поддержка RFC5424 работает с современными архитектурами syslog
RFC5424 — более современный стандарт syslog, поддерживающий поля структурированных данных. Профиль логов TR7 может выбрать этот стандарт для создания более организованных и машинно-обрабатываемых syslog-сообщений. Разбор полей и классификация событий становятся более последовательными на стороне SIEM. В сочетании с полезной нагрузкой JSON или CEF образует надёжную модель интеграции.
Формат JSON хорошо подходит для систем поиска и индексирования
В формате JSON такие поля, как timestamp, source, severity, message и meta, легко машинно-обрабатываемы. Полевой поиск упрощается для систем аналитики, индексирования и запросов логов. Команды SOC могут изучать события как разобранные поля, а не сырые текстовые строки. Этот формат предпочтителен в интеграциях с современными платформами логов.
Формат CEF обеспечивает быструю интеграцию с готовыми парсерами SIEM
CEF-сообщения создаются со структурой CEF:0|TR7|LogTransport|1.0|...|. Значения серьёзности отображаются по шкале 0-10; используются уровни, такие как info 3, warning 5, error 7 и critical 10. Поля «ключ-значение» могут обрабатываться готовыми парсерами на стороне SIEM. Этот формат подходит командам SOC, которые хотят стандартный CEF-поток для классификации и корреляции событий.
Формат PlainText используется в средах, требующих базовой совместимости с syslog
Формат PlainText создаёт поля ISO timestamp, severity, source и message как человекочитаемый текст. Может быть быстро развёрнут в средах без сложных парсеров или для временных интеграций. Обеспечивает высокую человекочитаемость и подходит для простых целей логов, где JSON или CEF были бы излишними.
Четыре основных источника логов могут быть выбраны на уровне профиля
userLogs охватывает действия администраторов, hcLogs — события проверок здоровья, notificationLogs — системные уведомления, а gtmLogs — события GTM. Каждый профиль может быть определён для отправки только нужных источников, поэтому в SIEM поступают только релевантные классы логов. События безопасности WAAP также могут пересылаться в инфраструктуру логов организации через тот же конвейер транспорта.
Контроль подробности проверок здоровья управляет объёмом логов
Логи проверок здоровья могут генерировать большой объём на нагруженных системах. Когда hcLogsVerbose равен false, отправляются только события проверок здоровья с условием stateChange. Этот подход снижает шум в SIEM и обнаруживает только значимые переходы состояния сервиса. Подробное поведение может быть временно включено во время периодов устранения неполадок.
Несколько профилей могут отправлять один и тот же лог в разные цели в разных форматах
В рамках одного namespace может быть активно более одного транспортного профиля. Один профиль может отправлять в формате CEF в SOC SIEM, пока другой пересылает в формате JSON в систему аналитики логов. Эта структура разветвляет один поток логов для удовлетворения потребностей разных команд. Сценарий с несколькими целями снижает необходимость развёртывания отдельного внешнего маршрутизатора логов.
Операционная глубина
SIEM Log Streaming эксплуатируется совместно с форматированием, синхронизацией профилей, валидацией, изоляцией ошибок и санитизацией сообщений.
Модель форматирования CEF
Поля вендора и продукта CEF создаются как TR7 / LogTransport / 1.0. Серьёзность отображается по шкале 0-10. Поля сообщений структурированы как пары «ключ-значение», читаемые парсерами SIEM.
Конфигурация имени приложения
Поле профиля syslogAppName используется как имя приложения в syslog-сообщениях. Значение по умолчанию может быть TR7_syslog_client. Это поле важно для идентификации источника и фильтрации на стороне SIEM.
Синхронизация профилей
Изменения профилей группируются по namespace и применяются к соответствующим транспортным процессам. Если старый профиль удаляется, связанный с ним процесс завершается. Новые или изменённые профили могут быть введены в активный поток логов без перезапуска.
Валидация профилей
Если значение transportType не является syslog, профиль не допускается в текущий конвейер syslog-транспорта. Эта структура оставляет место для расширения на разные типы транспорта в будущем. Текущая поддержка — UDP и TCP syslog.
Изоляция ошибок
События подключения и ошибки syslog-клиента записываются через внутренний логгер. Ошибки подключения к целевому SIEM не останавливают главный процесс управления. Операторы могут отслеживать проблемы подключения через логи и статус профилей.
HTML-санитизация
Если сообщения, поступающие из пользовательского интерфейса, содержат HTML-содержимое, текстовое содержимое извлекается перед отправкой в syslog. Это особенно важно для безопасности полей и последовательности парсеров в формате CEF. Сообщения логов доставляются в SIEM в более чистом и безопасном виде.
Когда применять
Пересылка событий WAAP в SOC-систему в формате CEF
Команды безопасности могут отправлять события WAAP в SIEM в формате CEF. Поля правила, серьёзности, источника и meta обрабатываются парсерами SIEM. Команда SOC видит события на собственном экране корреляции без входа в интерфейс TR7.
Подача платформы поиска и аналитики потоком логов JSON
Команды эксплуатации могут выбрать формат JSON для пересылки логов на внешнюю платформу логов в индексированном по полям виде. Поля timestamp, source, severity и meta становятся запрашиваемыми. Анализ ошибок и извлечение трендов упрощаются.
Разделение SIEM на уровне namespace в мультитенантных средах
Провайдер управляемых сервисов может определить отдельный namespace и отдельный транспортный профиль логов для каждого тенанта. Логи каждого тенанта поступают в его собственную цель SIEM. Предотвращается смешивание данных тенантов в одном потоке логов.
Экспорт событий администраторов и системных событий для соответствия
Команды соответствия могут зеркалировать userLogs, notificationLogs и события изменения состояния проверок здоровья в центральный SIEM. Даже если локальные логи удаляются или ротируются, критические события остаются во внешней системе. Действия администраторов и системные события могут быть проверены ретроспективно во время аудитов.
Часто задаваемые вопросы
Какие источники логов могут быть включены в транспортный профиль?
В чём разница между форматами сообщений CEF и JSON?
Могут ли несколько профилей работать в одном namespace одновременно?
Как объёмы логов проверок здоровья держатся под контролем?
Когда TCP-транспорт предпочтительнее UDP?
Как изменения профилей применяются без простоя?
Позвольте вашему SIEM читать каждое событие платформы
Профили с ограничением по namespace, форматы JSON/CEF/plainText и фильтрация на уровне источника — проведём живой демонстрационный запуск в вашей среде.