SIEM とテレメトリの送出
このページは送出コントラクトです。コントロールプレーンから何が、どの方言で、どの トランスポートで出ていき、受信側がそれをどう扱うのかを定めます。ArcSight のルール、 QRadar の DSM、Sentinel の DCR、あるいは code scanning へのアップロードを一発で動かす 必要がある人に向けて書かれています。
ここに書かれた内容はすべてベンダー自身の仕様に照らして確認済みで、確認日を併記して います。ベンダーが規定していない事項は、推測せずにその旨を記します。そうした箇所は ベンダー未定義と明示し、エンコーダーはそれぞれ保守的な側を採用します。
2 つのフィード
Section titled “2 つのフィード”レコードの発生源は独立に 2 つあり、方言が乖離しないよう同一のエンコーダーを共有します。
| フィード | 内容 | プル | プッシュ |
|---|---|---|---|
| 監査台帳 | 追記専用・ハッシュ連鎖の台帳と、その整合性フィールド（シーケンス、前ハッシュ、ハッシュ、署名） | GET /v1/audit/export?format=…（NDJSON、1 行 1 レコード） | 台帳フォワーダー経由、任意の出力コネクター |
| 通知と検出結果 | ガバナンスの検出結果、ポリシー判定、ヘルスおよびライフサイクルのイベント | — | 任意の出力コネクター |
台帳の整合性フィールドはどの形式でもそのまま運ばれるため、SOC は製品側だけでなく 自社 SIEM 内のコピーからも連鎖を再検証できます。
| 形式 | 標準 | 固定バージョン | 選択できる場所 |
|---|---|---|---|
| CEF | ArcSight Common Event Format | V27（2024 年 7 月） | 台帳エクスポート、コネクター |
| LEEF | IBM QRadar Log Event Extended Format | 2.0 | 台帳エクスポート、コネクター |
| syslog | RFC 5424（+ RFC 5426 UDP、RFC 6587 TCP フレーミング、RFC 5425 TLS） | — | 台帳エクスポート、コネクター |
OTLP リクエスト（otlp） | OTLP/HTTP JSON エクスポートリクエスト（ExportLogsServiceRequest） | 後述の射影を参照 | 台帳エクスポート、コネクター |
OTLP リクエスト（otlp_envelope） | otlp のバイト単位で完全に一致するエイリアス | 後述の射影を参照 | 台帳エクスポート、コネクター |
OTLP LogRecord（otlp_log_record） | OpenTelemetry logs、1 行 1 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 |
イベンティングシンク（push サブスクリプションの sink_format） | 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 の届き方は場所ごとに異なります。イベンティングシンクは捕捉した
イベントエンベロープを生のまま（方言変換なしの構造化パススルーとして）投稿しますが、
通知コネクターは最小限の通知プロジェクションだけをレンダリングします — 表示用の
フィールドであって、元のペイロードではありません。asim は s3archive を含む
4 つの通知コネクターすべてが受け付けます。場所ごとのリストにない形式は拒否されます。
作成時や設定時の打ち間違いには、その場所が受け付けるトークンを明示するエラーが返り、
破損した保存値はエンコード時に（リストではなく破損した綴りだけを示して）拒否され
ます。黙って JSON にフォールバックすることはありません。
重大度：単一の真実の源
Section titled “重大度：単一の真実の源”重大度でフィルタするすべてのルールはこの表に依拠します。マッピングは 1 か所に 1 つだけ なので、同じイベントの 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 | (省略) |
次の 2 つの性質はテストで固定しています。どちらもうっかり失われやすいためです。
- 判定済みの 5 つの重大度が同じ数値を共有することはない。
local0.noticeのような コレクターのセレクター、ArcSight のルール、Sentinel の DCR はいずれも出力された数値で フィルタし、RFC 5424 フレームには他に重大度の手がかりがありません。2 つの重大度が同じ プライオリティを共有すれば、区別は静かに、かつ復元不能に失われます。 - 未判定の重大度をでっち上げない。 CEF V27 は
0を Low から Unknown に改称して おり、重大度が判定されなかったイベントにはそれが入ります。（LEEF だけは例外で、範囲が 1-10 で「不明」に相当する値がないため下限を適用します。後述。）
CEF の詳細
Section titled “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 ディクショナリの要求どおり 10 進の エポックミリ秒です。
LEEF の詳細
Section titled “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 のタイムスタンプに優先すると文書化しており、だからこそ運任せにしていません。
syslog トランスポートと受信側の上限
Section titled “syslog トランスポートと受信側の上限”syslog コネクターは、ネイティブな RFC 5424 レコード、または CEF / LEEF レコードを仕様 準拠の RFC 5424 フレームの MSG として運びます。ArcSight と QRadar が syslog 経由でこれら の形式を取り込む方法そのものです。
- 既定は 6514 番ポートの TLS（RFC 5425） で、RFC が要求するオクテットカウント方式の フレーミングを使います。平文の TCP / UDP は運用者による明示的なオプトアウトであり、 TLS 宛先を平文に降格させるコードパスは存在しません。
- 受信側ペイロード予算（
max_payload_bytes、既定0= 無効）。過大なレコードを分割 する受信側は、1 つの監査対象イベントを解析不能な 2 つの断片に変えてしまいます。運用して いる宛先の予算を宣言すると、それを超えるレコードは分割されるために送られるのではなく、 配信を失敗させます（リトライののち DLQ に入り、可視化されます）。レコード自体は決して 切り詰められません。
この設定の参考値と、各出典が実際に述べている内容（2026-07-24 確認）：
| 受信側 | バイト | 出典の記述 |
|---|---|---|
| すべての RFC 5424 受信側 | 480 | 受信側が対応しなければならない最小値（§6.1） |
| すべての RFC 5424 受信側 | 2048 | 実装が対応すべきサイズ |
| ArcSight syslog デーモン | 1024 | ガイドは、これを超えるメッセージが**「分割されることがある」**と述べています — 受信側の規則ではなく配備上の注意であり、ファイル／パイプ経路には当てはまりません |
| QRadar TCP | 4096 | 既定の最大ペイロード。引き上げ可能（IBM は 8192 を、上限として 32000 を文書化） |
いずれの出典も syslog ヘッダーを数に含めるか明示していないため、予算はレコード全体を UTF-8 オクテットで測ります。
イベントは ai_operation プロファイル付きの OCSF 1.8.0 として出力され、プロファイルを
登録している 3 クラス — API Activity（6003、既定）、Process Activity（1007）、Datastore
Activity（6005）— を使います。出力はテストスイートで公式の 1.8.0 クラススキーマに照らして
検証されます。これらのスキーマは未知のフィールドを禁じているため、プロファイル外の属性や
不完全なプロファイルオブジェクトは、利用者に届く前にビルドを落とします。
エンベロープではない射影
Section titled “エンベロープではない射影”コレクターを向ける前に知っておくべき、2 つの正直な制約です。
otlpはどの場所でも POST 可能なリクエストであり、素の射影はotlp_log_recordです。 形式カタログの再マッピング以降、otlpのイベント行は、トークンが受け付け られるすべての場所 — 台帳エクスポート、出力コネクター、イベンティングの push — で、 コレクターが必要とするリソース識別情報と計装スコープを備えた、完全な OTLP/HTTP JSON エクスポートリクエスト（ExportLogsServiceRequest）です。otlp_envelopeはどの 場所でもotlpのバイト単位で完全に一致するエイリアスで、エンベロープを最初に載せた 綴りだから残されています — 両者が異なることは決してありません。1 行 1 LogRecord の 射影 — 1 行 1 JSON オブジェクト、ファイル／NDJSON での消費向け — は、その正直な名前otlp_log_recordの下で、台帳のプルエクスポートに限って今も存在します。単体の LogRecord 行は/v1/logsに POST できるボディではないため、push 側の場所は意図的に これを提供しません。さもなければ午後をひとつ失う 3 点：プル出力の最終行は Olivares の{"export_complete":true,…}マーカーであり、リクエストでは ありません。全行を POST するループはこれを飛ばす必要があり、部分文字列ではなく構造で判定してください （例：jq -c 'select(has("resourceLogs"))'）。アクターやターゲットにexport_completeを含む正当なイベントがgrep -vで落ちるのは、マーカーのスキップではなく証跡の削除です。 プッシュ先はコレクターの/v1/logsを正確に指す必要があります（エンドポイントはそのまま 使われます）。そして汎用 HTTPS シンクは partial-success 応答を読まずに 2xx を配信成功 として扱います ── 専用の OTLP ログコネクターはそれを読みます。otlp_log_recordは、 再マッピング前のotlpトークンが生成していたバイト列を、通常のタイムスタンプ領域 （ゼロ時刻、およびエポックから2262-04-11T23:47:16.854775807Zまでの任意の時点）で そのまま保ちます。その外側ではバイト単位の互換性は保証されません。バイト列が異なる 箇所は修正です。エポック以前の日付は以前、OTLP が符号なしと宣言するフィールドに負値を 出しており、符号付きと符号なしの上限の間の日付は今その真の符号なし値を持ち、2554-07-21T23:34:33.709551615Zより後の日付は、桁あふれした値（1970 年初頭と 読める小さな正値を含む）ではなく不明（0）として符号化されます。ゼロへ桁あふれする 個別の入力では、旧新のバイト列が一致します。アップグレード上の注意も 2 点明記します。 プルのファイル自体は依然 NDJSON（1 行 1 リクエスト＋完了マーカー）であって単一の リクエストではありません。また、再マッピング前に形式をちょうどotlpと綴って保存 されたイベンティングのサブスクリプションは、以前は素の行を届けていた場所で今は エンベロープを届けます ── エンジンは該当サブスクリプションごとに構造化された警告を 1 件記録し、再マッピング前に記録された監査メタデータはトークンの旧来の意味のまま 読まれます。- OWASP Agentic AI Security のトレース拡張は OCSF の
unmappedコンテナに入ります。 これはその仕様（v0.1 パブリックプレビュー）が定める配置です。OCSF の第一級の属性群では なく、スキーマ検証が担保するのは配置のみです。
検出結果を SARIF で
Section titled “検出結果を SARIF で”ガバナンスの検出結果は、code scanning の利用者向けに SARIF 2.1.0 Errata 01 として エクスポートできます。
GET /v1/m/security/findings/export?format=sarif— 検出結果一覧と同じフィルター、 結果数の上限、そして上限に達したときの正直な truncation ヘッダー付き。olivares findings export— 同じエクスポートを CLI から。パーミッション0600で アトミックに書き出します。
この run は、結果のロケーションが解決される URI ベースを宣言し、利用者が再アラートでは
なく重複排除できるよう検出結果ごとに安定した
partialFingerprints.primaryLocationLineHash を持ち、rule id が空、あるいは level が
列挙外の結果の出力を拒否します。この 2 つは利用者がファイル全体を拒否する原因であり、
アップロード時に気づくのはここで気づくより悪いからです。
対象がバージョン管理下のファイルでない検出結果には、合成のロケーション URI が付きます。 run は有効で取り込み可能なままですが、GitHub がアラートを描画するのはチェックアウト内の ファイルに一致する URI だけです。GitHub 上でのアンカーを狙う検出器は、アーティファクトの URI を明示的に設定してください。