はじめに
SIEM やデータレイクなんてことばが流行りはじめて早数年経ちますが、運悪く業務ではなかなか関わることができていない今日このごろです。この界隈の情報収集をしているとよく CEF や LEEF ってことばを見かけます。説明しろと言われても今の自分にはできなさそうだったので、調べてみました。
Syslog の形式
Syslogの形式はいわゆる「Syslog header」部分と「Message」部分で分けて規格が存在します。
| 対象 | 規格 | 名称 |
| Syslog header | RFC 3164 | BSD Syslog Format |
| RFC 5424 | Syslog Format | |
| Message | － | CEF（Common Event Format） |
| － | LEEF（Log Event Extended Format） |
Syslog headerの規格
Syslog の形式を規定する文書には、RFC 3164 (BSD Syslog Format) と RFC 5424 (Syslog Format) があり、RFC 5424 が IETF による標準化規格となっています。
RFC 3164 と RFC 5424 ではフォーマットの構造が異なりますが、MSG（メッセージ）以外の部分（RFC 3164 であれば PRI ＋ HEADER、RFC 5424 であれば HEADER + STRUCTURED-DATA）を慣例的に Syslog ヘッダー と呼ぶようです。
RFC 3164の形式
RFC 3164のSyslogヘッダーは以下のような形式となります。
<13>Jan 18 11:07:53 192.168.1.1 Jan 18 11:07:53 myhostname # Priorityは省略可能
RFC 3164のSyslogヘッダーは以下のような形式となります。
- NOT規格、あくまで慣習をまとめたもの
- Priority はオプション扱い。
- Priority は 1 桁 から 3 桁、またその周りを不等号括弧で囲む必要がある。
- Priority は
Facility*8+Severityで計算される。
参考：Azure Sentinel | エンジニアの何でもメモ帳
RFC 5424の形式
RFC 5424のSyslogヘッダーは以下のような形式となります。
<13>1 2019-01-18T11:07:53.520Z 192.168.1.1 <133>1 2019-01-18T11:07:53.520+07:00 myhostname
- IETF 形式と呼ばれ、RFC3164 を規格化したもの
- HEADER の部分は、BSDフォーマットとの互換性を保つため1もので、BSD syslog の Facility や Severity から計算される Priorityと同義。つまりPriorityは必須であり、RFC 3164と同様に１桁 から３桁、またその周りを不等号括弧で囲む必要がある。
- BSDに存在した
TimestampやIP AddressなどはStrustured-dataに集約されている。 - タイムスタンプのフォーマットは
yyyy-MM-ddTHH:mm:ss.SSSZと規定されている。 - STRUCTURED-DATA は、好きな情報を入れる事ができる。例として”トラフィック・カウンター”だったり”IPアドレス”などの このsyslog に関係する「メタ情報」を入れ込む事ができる。
- 2048 Byte 以上となる場合、受け手は2048 Byte を超えた所を Truncate (SHOULD) か、メッセージを破棄 (MAY) する。
出典：Azure Sentinel | エンジニアの何でもメモ帳
Messageの規格
Message部分は可変長で任意のデータを格納することができますが、そのメッセージ内容を規格化しようとする動きがあり、その中で代表的なものに CEF や LEEF と呼ばれる形式があるということが調べてわかりました。
Common Event Format（CEF）の形式
CEFは以下のような形式となります。
CEF:Version|Device Vendor|Device Product|Device Version|deviceEventClassId|Name|Severity|Extension
- 特定ベンダーに依存しない、一般的なメッセージフォーマット
- 項目をパイプ（|）で区切る
CEF形式の項目とその意味は以下のとおりです。
| Version | CEF 形式のバージョンを特定する整数値 |
| Device Vendor | 送信デバイスのタイプを一意に識別する文字列 |
| Device Product | |
| Device Version | |
| deviceEventClassId | イベントタイプごとの一意の識別子 (文字列または整数値) |
| Name | イベントを表す文字列 |
| Sevirity | イベントの重要度を表す整数値 (0 ～ 10、10 が最重要イベント) |
| Extension | 任意の値 |
出典：共通イベント形式（CEF） - McAfee Enterprise Security Manager 10.2.0
Log Event Extended Format（LEEF）
LEEFは以下のような形式となります。
LEEF:Version|Vendor|Product|Version|EventID|
例としては以下のような形です。
LEEF:Version|Vendor|Product|Version|EventID| LEEF:1.0|Microsoft|MSExchange|4.0 SP1|15345| LEEF:2.0|Lancope|StealthWatch|1.0|41|^|
- IBM 製の SIEM 製品である QRadar 用にカスタマイズされたメッセージフォーマット
- 項目をパイプ（|）で区切る
- UTF-8 を使用する必要がある。
- IBM という特定ベンダー用のフォーマットではあるが、ネットワーク機器などで標準的に対応しているケースがある。
出典：Azure Sentinel | エンジニアの何でもメモ帳
LEEF形式の項目とその意味は以下の通りです。
| LEEF:Version | LEEF 形式のバージョンを特定する整数値 |
| Vendor | 送信デバイスのタイプを一意に識別する文字列 |
| Product | |
| Product Version | |
| EventID | イベントタイプごとの一意の識別子 (文字列または整数値) |
| Delimiter Character | MSG部分の区切り文字（デリミタ）の指定 |
| Predefined Key Entries | デリミタ区切りの任意の値 |
以上
役に立ったなと思う方はビール１杯奢ってください。
