2.3監視データ型の用途

監視データは「詳しければ詳しいほど良い」わけではありません。詳細なデータは保持コストが跳ね上がり、粗いデータは調査の深さに限界があります。優れたSOCは、複数のデータ型を層状に組み合わせ、日常はアラートと軽量なメタデータで広く監視し、必要なときだけ深いデータに掘り下げます。この節では、6つの監視データ型それぞれがどの問いに答え、どのくらいのコストがかかるかを整理し、「この調査にはどのデータ型が要るか」を選べるようにします。

2.3.1深い（重い）データ型

• フルパケットキャプチャ＝通信の全内容（ヘッダ＋ペイロード）を記録する最も詳細なデータ。攻撃で実際に送られたコマンドやファイルを完全に再構成でき、証拠価値が高い。反面、データ量が桁違いに大きく長期保存や全社常時取得は非現実的。深い調査対象を絞ってから使う。
• トランザクションデータ＝アプリ層の個々のやり取り（要求と応答）の記録。例：HTTPの GET /login＋応答コード、DNSの問い合わせと回答、SMTPの送受信。中身の一部（URL・ステータス・クエリ名）は分かるがフルペイロードほど重くない。「どのURLに何回アクセスし何が返ったか」を追える。

2.3.2軽い（広く持てる）データ型

• セッションデータ＝1つの会話（フロー）の要約。5-tuple（送信元/宛先IP・ポート・プロトコル）＋開始/終了時刻＋転送バイト/パケット数。中身は無いが「誰が誰といつどれだけ通信したか」を軽量に長期保持でき、NetFlowはこのセッション/トランザクション寄りの代表例。相関の背骨になる。
• 統計データ＝多数の通信を集計/ベースライン化したもの（時間帯別の平均トラフィック、プロトコル比率、上位通信先など）。個別のイベントではなく全体の傾向を示し、「普段と違う」逸脱の検知に使う。メタデータは各通信に付随する記述情報（ファイル名・ハッシュ・証明書情報・ユーザエージェント等）で、中身そのものではないが強力な手掛かりになる。
• アラートデータ＝IDS/IPS・アンチウイルス・SIEM等がルール/シグネチャ/挙動に基づいて生成した「注意すべき事象」の通知。それ自体は「何かが起きたかもしれない」という起点で、真偽（真陽性/偽陽性）は他のデータ型（セッション・トランザクション・フルパケット）で裏取りする。

あなたのSIEMが「マルウェア感染の疑い」というアラートデータを上げました。ここで即座に端末を隔離して報告を終える、あるいは逆に「アラートが出た＝確定」として大騒ぎするのは、どちらも未熟な対応です。アラートは真偽を裏取りする起点にすぎません。まず軽量に長期保持されているセッションデータ（NetFlow）で、その端末がアラート発生前後に外部のどこと通信したかを確認します。次にトランザクションデータで、HTTPの GET した具体的なURLやDNSの問い合わせ名を見て、C2ドメインや不審なダウンロード先が含まれていないかを調べます。さらにメタデータとして、ダウンロードされたファイルのハッシュを取り、脅威インテリジェンスで既知マルウェアか照合します。ここまでで真陽性の確度が高まったら、最後に該当端末・該当時間帯に絞ってフルパケットキャプチャを確認し、実際に送受信されたペイロード（盗まれたデータやC2コマンド）を確定させ、証拠として保全します。この順序が重要です——広く軽いデータ（セッション・統計・メタデータ）で当たりを付け、狭く深いデータ（フルパケット）で確定する。もし普段から統計データでベースラインを取っていれば、そもそもこの端末の「普段と違う」通信量やプロトコル比率の逸脱で、シグネチャに載る前の未知の兆候にも気づけたはずです。データ型は競合ではなく役割分担であり、コストと深度のトレードオフを理解して層状に組むのがSOC設計の本質です。

2.3.3この節のまとめ

• フルパケットは全内容で最重・トランザクションは要求応答単位・セッション（NetFlow）は5-tupleの会話要約で軽量長期
• 統計データはベースラインからの逸脱検知、メタデータはハッシュや証明書等の付随手掛かり、アラートは裏取りの起点
• コストと深度はトレードオフ。広く軽いデータで当たりを付け、狭く深いデータで確定する層状の組み合わせがSOC設計の要