Экспорт в SIEM и телеметрия

Эта страница — контракт исходящего потока: что покидает control plane, на каком диалекте, каким транспортом и что с этим делает приёмник. Она написана для того, кому нужно с первого раза заставить работать правило ArcSight, DSM QRadar, DCR Sentinel или загрузку в code scanning.

Всё здесь сверено со спецификациями самих вендоров, с датой проверки. Там, где вендор чего-то не определяет, страница так и говорит, а не догадывается: такие пробелы помечены как не определено вендором, и кодировщик выбирает консервативную сторону.

Два потока

Источников записей два, они независимы и используют один кодировщик, чтобы диалекты не разошлись:

Поток	Что несёт	Pull	Push
Журнал аудита	Журнал «только на добавление», сцепленный хешами, со своими полями целостности (последовательность, предыдущий хеш, хеш, подпись)	GET /v1/audit/export?format=… (NDJSON, одна запись в строке)	Пересылка журнала через любой выходной коннектор
Уведомления и находки	Находки управления, решения политик, события состояния и жизненного цикла	—	Любой выходной коннектор

Поля целостности журнала передаются дословно в каждом формате, поэтому SOC может перепроверить цепочку по копии в собственной SIEM, а не только в продукте.

Форматы

Формат	Стандарт	Зафиксированная версия	Где выбирается
CEF	ArcSight Common Event Format	V27 (июль 2024)	экспорт журнала, коннекторы
LEEF	IBM QRadar Log Event Extended Format	2.0	экспорт журнала, коннекторы
syslog	RFC 5424 (+ RFC 5426 UDP, кадрирование TCP по RFC 6587, TLS по RFC 5425)	—	экспорт журнала, коннекторы
Запрос OTLP (otlp)	Запрос экспорта OTLP/HTTP JSON (ExportLogsServiceRequest)	см. Проекции ниже	экспорт журнала, коннекторы
Запрос OTLP (otlp_envelope)	Точный побайтовый псевдоним otlp	см. Проекции ниже	экспорт журнала, коннекторы
LogRecord OTLP (otlp_log_record)	OpenTelemetry logs, один LogRecord на строку	см. Проекции ниже	экспорт журнала
OCSF	Open Cybersecurity Schema Framework, профиль ai_operation	1.8.0	экспорт журнала, коннекторы
ASIM	Microsoft Sentinel Advanced SIEM Information Model	—	коннекторы
ECS	Elastic Common Schema	9.4.0	коннектор Elastic
UDM	Google SecOps Unified Data Model	—	коннектор Chronicle
SARIF	OASIS Static Analysis Results Interchange Format	2.1.0 Errata 01	экспорт находок

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

Поверхность	Принимаемые токены	По умолчанию
Экспорт журнала (GET /v1/audit/export?format=…)	cef|leef|syslog|otlp|otlp_envelope|otlp_log_record|ocsf	cef
Sink событий (sink_format push-подписки)	ocsf|cef|leef|syslog|otlp|otlp_envelope|json	ocsf
Коннекторы уведомлений (filelog, splunkhec, s3archive, siem)	json|cef|leef|syslog|otlp|otlp_envelope|ocsf|asim	json
Коннектор syslog	syslog|cef|leef	syslog

У экспорта журнала нет сквозной передачи сырого JSON — его JSON-формы и есть формы OTLP выше. json означает две разные доставки: sink событий отправляет сырой конверт захваченного события (структурированную сквозную передачу, без преобразования диалекта), тогда как коннекторы уведомлений формируют лишь минимальную проекцию уведомления — отображаемые поля, а не исходную полезную нагрузку. asim принимают все четыре коннектора уведомлений, включая s3archive. Формат вне списка своей поверхности отклоняется: опечатка при создании или настройке получает ошибку, называющую принимаемые токены этой поверхности, а повреждённое сохранённое значение отвергается при кодировании (с указанием повреждённого написания, а не списка); ничто не откатывается молча к JSON.

Серьёзность: единственный источник истины

Любое правило, фильтрующее по серьёзности, опирается на эту таблицу. Одно отображение в одном месте — поэтому число CEF, приоритет syslog и серьёзность OTLP одного и того же события не могут противоречить друг другу.

Серьёзность продукта	CEF (0-10)	syslog (0-7)	OTLP	ECS	UDM
info	1	6 (info)	INFO	1	INFORMATIONAL
low	3	5 (notice)	INFO2	3	LOW
medium	5	4 (warning)	WARN	5	MEDIUM
high	7	3 (error)	ERROR	7	HIGH
critical	10	2 (critical)	FATAL	10	CRITICAL
не определена	0 (Unknown)	6 (info)	UNSPECIFIED	0	(опускается)

Два свойства закреплены тестами, потому что оба легко потерять по невнимательности:

• Пять определённых серьёзностей никогда не делят одно число. Селектор коллектора вроде local0.notice, правило ArcSight или DCR Sentinel фильтруют по выданному числу, а кадр RFC 5424 не несёт иного признака серьёзности: две серьёзности на одном приоритете уничтожили бы различие тихо и безвозвратно.
• Неопределённая серьёзность не выдумывается. CEF V27 переименовал 0 из Low в Unknown — именно это получает событие без определённой серьёзности. (Исключение — LEEF: его диапазон 1-10 и значения «неизвестно» нет, поэтому там действует нижняя граница. См. ниже.)

Почему столбец syslog именно такой

Ни CEF, ни RFC 5424 не определяют отображение серьёзности CEF в приоритет syslog — сверено с обеими спецификациями 2026-07-24. Поэтому столбец syslog — это продуктовая политика, выбранная так, чтобы каждая серьёзность оставалась различимой, а «critical» попадал на приоритет, который сам RFC 5424 называет critical. Единственное существующее вендорское отображение (настраиваемый параметр коннектора ArcSight) тоже кладёт свою верхнюю полосу на crit. Если у вас стандартизована другая разбивка — отобразите её на своём коллекторе: эти числа не сдвинутся без записи Changed в changelog.

Особенности CEF

• Размеры полей заголовка ограничены максимумами V27: device vendor 63, device product 63, device version 31, event class id 1023, name 512.
• Спецификация публикует эти числа, но нигде не говорит, считают ли они символы или передаваемые октеты, и не определяет поведение для слишком длинного поля (не определено вендором, проверено 2026-07-24). Поэтому соблюдаются обе трактовки: значение ограничивается этим числом и в декодированных символах, и в передаваемых октетах UTF-8. Имя устройства или события не из ASCII умещается в меньшее число символов, чем подсказывает цифра, — консервативное направление.
• Усечение касается только заголовка. Расширение, несущее аудируемое содержимое, не усекается никогда.
• Ключи расширения со значением времени (rt, start, end) — десятичные миллисекунды эпохи, как требует словарь CEF.

Особенности LEEF

• sev — целое в задокументированном LEEF 2.0 диапазоне 1-10. Событие, чья серьёзность так и не была определена, выходит как sev=1: в LEEF нет значения «неизвестно», а sev=0 вне диапазона.
• devTime — 13-значное значение эпохи, которое QRadar принимает без devTimeFormat. Для события без записанного времени оно опускается — никогда не выдумывается, — и QRadar тогда, как задокументировано, откатывается ко времени приёма.
• sev, devTime и devTimeFormat принадлежат кодировщику. Если событие несёт поле с одним из этих имён (в любом регистре), оно выдаётся переименованным в olvSev / olvDevTime / olvDevTimeFormat: значение всё равно доходит до вас, но не может ни перекрыть нормализованную серьёзность, ни переставить дату события. IBM документирует, что распознанный devTime главнее отметки времени syslog, — поэтому это не отдаётся на волю случая.

Не определено IBM

IBM не документирует, что QRadar делает с sev=0, с неразбираемым devTime и учитывается ли регистр ключей атрибутов (проверено 2026-07-24). Выше — консервативная трактовка каждого случая. Если у вас есть обратные данные со стороны приёмника, это стоит issue.

Транспорт syslog и ограничения приёмников

Коннектор syslog несёт либо нативную запись RFC 5424, либо запись CEF / LEEF как MSG корректного кадра RFC 5424 — именно так ArcSight и QRadar принимают эти форматы по syslog.

• По умолчанию — TLS на 6514 (RFC 5425) с кадрированием подсчётом октетов, как требует RFC. Открытые TCP или UDP — явный отказ оператора от защиты; кода, понижающего TLS-назначение до открытого канала, не существует.
• Бюджет полезной нагрузки приёмника (max_payload_bytes, по умолчанию 0 — выключено). Приёмник, который режет слишком большую запись, превращает одно аудируемое событие в две неразбираемые половины. Когда вы объявляете бюджет назначения, которым управляете, запись сверх него проваливает доставку — с повтором и последующей DLQ, где вы её увидите, — вместо того чтобы уйти на разрезание. Сама запись не усекается никогда.

Опорные значения для этой настройки и то, что источники говорят на самом деле (проверено 2026-07-24):

Приёмник	Байты	Что говорит источник
Любой приёмник RFC 5424	480	Минимум, который приёмник ОБЯЗАН поддерживать (§6.1)
Любой приёмник RFC 5424	2048	Размер, который реализациям СЛЕДУЕТ поддерживать
Демон syslog ArcSight	1024	Его руководства говорят, что более длинное сообщение «может быть разрезано» — предупреждение о развёртывании, а не правило приёмника, и оно не относится к путям файла или канала
QRadar TCP	4096	Максимальная нагрузка по умолчанию; повышаема (IBM документирует 8192, потолок 32000)

Ни один из источников не определяет, входит ли в счёт заголовок syslog, поэтому бюджет измеряется по полной записи в октетах UTF-8.

OCSF

События выдаются как OCSF 1.8.0 с профилем ai_operation, в трёх классах, которые его регистрируют: API Activity (6003, по умолчанию), Process Activity (1007) и Datastore Activity (6005). Вывод проверяется в тестах против официальных схем классов 1.8.0, запрещающих неизвестные поля, — поэтому атрибут вне профиля или неполный объект профиля ломают сборку, а не доезжают до вас.

AWS Security Lake принимает OCSF ≤ 1.3

Пользовательский источник Security Lake ограничен OCSF 1.3 в Parquet, поэтому события ai_operation версии 1.8.0 туда как есть не попадают (проверено 2026-07-24). Пока нет эмиттера с понижением до 1.3, маршрутизируйте в Security Lake через собственное преобразование или используйте другое назначение. Это объявленный пробел, а не недосмотр.

Проекции, которые не являются конвертами

Два честных ограничения — оба стоит знать, прежде чем направлять коллектор:

• otlp — отправляемый запрос на каждой поверхности; otlp_log_record — голая проекция. После ремапа каталога форматов строка СОБЫТИЯ otlp — это полный запрос экспорта OTLP/HTTP JSON (ExportLogsServiceRequest) везде, где токен принимается — экспорт журнала, выходные коннекторы, push событий, — с идентичностью ресурса и областью инструментирования, которые нужны коллектору. otlp_envelope — точный побайтовый псевдоним otlp на каждой поверхности, сохранённый потому, что именно это написание первым принесло конверт: они не различаются никогда. Проекция «один LogRecord на строку» — по одному JSON-объекту на строку, для файлового/NDJSON потребления — по-прежнему существует под своим честным именем otlp_log_record и только в pull-экспорте журнала: одиночная строка LogRecord не является телом, пригодным для POST в /v1/logs, поэтому push-поверхности сознательно её не предлагают. Три уточнения, которые иначе стоят половины дня: ПОСЛЕДНЯЯ строка pull-экспорта — это маркер {"export_complete":true,…} Olivares, и он не является запросом (цикл, который постит каждую строку, обязан его пропустить). Фильтруйте по СТРУКТУРЕ, например jq -c 'select(has("resourceLogs"))', и никогда по подстроке: законное событие, у которого actor или target содержит export_complete, будет выброшено grep -v — это удаление доказательства, а не пропуск маркера; push-приёмник должен указывать на точный URL /v1/logs коллектора, так как эндпоинт постится дословно; и обобщённый HTTPS-sink считает доставленным любой 2xx, не читая ответ о частичном успехе — выделенный коннектор логов OTLP его читает. otlp_log_record сохраняет в точности те байты, которые производил токен otlp до ремапа, в обычном диапазоне времени — нулевое время и любой момент от эпохи до 2262-04-11T23:47:16.854775807Z. Вне него побайтовая совместимость НЕ гарантируется, и там, где байты различаются, это исправление: дата до эпохи раньше давала отрицательное значение в поле, которое OTLP объявляет беззнаковым; дата между знаковым и беззнаковым пределами теперь несёт своё истинное беззнаковое значение; а дата после 2554-07-21T23:34:33.709551615Z теперь кодируется как неизвестная (0) вместо переполненного значения — в том числе небольших положительных, читаемых как начало 1970 года. На отдельных входах, дающих переполнение в ноль, старые и новые байты совпадают. Две заметки об обновлении, названные прямо: сам файл при pull остаётся NDJSON (один запрос на строку плюс маркер завершения), а не одним запросом; а сохранённая подписка событий, чей формат до ремапа был записан ровно как otlp, теперь доставляет конверт там, где раньше доставляла одиночную строку — движок пишет одно структурированное предупреждение на каждую такую подписку, а метаданные аудита, записанные до ремапа, читаются в старом значении токена.
• Расширение трассировки OWASP Agentic AI Security едет в контейнере unmapped OCSF — там, где предписывает его спецификация (v0.1, public preview). Это не первоклассный набор атрибутов OCSF, и валидация схемы покрывает только его размещение.

Находки в формате SARIF

Находки управления экспортируются как SARIF 2.1.0 Errata 01 для потребителя code scanning:

• GET /v1/m/security/findings/export?format=sarif — те же фильтры, что и у списка находок, с ограничением на число результатов и честным заголовком об усечении, когда оно достигнуто.
• olivares findings export — тот же экспорт из CLI, записывается атомарно с правами 0600.

Run объявляет базу URI, относительно которой разрешаются местоположения результатов, несёт стабильный partialFingerprints.primaryLocationLineHash для каждой находки, чтобы потребитель дедуплицировал, а не поднимал тревогу заново, и отказывается выдавать результат с пустым rule id или level вне перечисления — именно эти две вещи заставляют потребителя отвергнуть весь файл, а узнать об этом при загрузке хуже, чем здесь.

Находки, чей субъект не является версионируемым файлом, получают синтетический URI местоположения. Run остаётся валидным и пригодным к приёму, но GitHub отрисовывает оповещения только для URI, совпадающих с файлом в checkout, — так что детектор, которому нужна привязка в GitHub, должен явно задавать URI артефакта.