セキュリティチームが自社のアーキテクチャを検討するとき、SIEMとログ管理は最初の五分ほど同じ買い物に見えます。どちらもログを取り込み、イベントデータを保存し、ダッシュボードとクエリインターフェースを備えています。しかし両者は根本的に異なる課題を解くために作られており、互換性のあるものとして扱えば、セキュリティ上の成果につながらない機能に費用を払うか、インシデントが起きるまで表面化しない検知の空白を抱え込むか、どちらかになります。
この違いは、五年前よりも今のほうが重要になっています。クラウド環境、SaaSアプリケーション、コンテナ化されたワークロードは、それぞれ異なる形で 二つのカテゴリーに負荷をかけるログ量を生み出します。それぞれのツールが実際に何をして、何をしないのかをはっきりさせることが、実環境で機能するスタックを組み立てる出発点になります。
ログ管理が担うこと
ログ管理はインフラの層です。収集、正規化、保持、検索を担います。サーバー、アプリケーション、ネットワーク機器、クラウドサービスからイベントデータを集め、中央のリポジトリに取り込みます。主な目的は可用性と検索性です。コンプライアンス監査であれ、運用上のトラブルシューティングであれ、インシデント後のフォレンジックであれ、必要なときにログが存在している状態を確保します。
しっかりしたログ管理プラットフォームは、次のような問いに答えます。このサーバーで午前2時から3時のあいだに何が起きたのか。先週このアプリケーションに認証したアカウントはどれか。このIPアドレスは過去30日間、環境全体で何をしていたのか。
一方で、設計上あえて行わないのは、その活動が攻撃だったかどうかを判断することです。ログ管理は記録を作ります。その記録がセキュリティ上何を意味するのかを解釈するには、別のものが必要です。
SIEMが加えるもの
SIEM（Security Information and Event Management）は、ログデータの上にセキュリティ分析を重ねます。ログ管理が保存と取り出しを担うのに対し、SIEMは相関分析とアラートを担います。複数のログソースをまたいで検知ロジックを適用し、悪意ある活動を示唆するパターンを特定します。たとえば、見慣れない国からのログイン失敗の数分後に成功が続く、既知の攻撃手法に一致する権限昇格、ネットワークセグメントをまたぐラテラルムーブメントといったものです。
多くのSIEMは、シグナルの質を高めるために脅威インテリジェンスのフィード、資産のコンテキスト、ユーザー行動のベースラインを取り込みます。出力はセキュリティに特化したもので、優先度付けされたアラート、調査のタイムライン、そしてNIST、PCI DSS、SOC 2といったフレームワークに紐づくコンプライアンスレポートです。
実際には、SIEMはログ管理を土台として含んでいます。同じ生のイベントデータを取り込んで保存したうえで、その上にセキュリティインテリジェンスの層を加えます。NIST SP 800-92のコンピュータセキュリティログ管理ガイドは、この層をはっきり区別しています。ログ管理はどのデータを収集し保持するかの話であり、セキュリティ分析はそのデータが何を明らかにするかの話だというわけです。
重なりが混乱を生むところ
SIEMとログ管理の機能面での重なりは明らかで、ベンダー側もそこに寄せてきました。多くのログ管理プラットフォームがアラート機能を追加し、多くのSIEMがストレージと検索の能力を打ち出しています。境界は十分に曖昧になり、横並びの比較は本当に難しくなっています。
両者を最もはっきり分けるのは、何を第一に最適化しているかです。ログ管理は保持と検索に最適化されています。コンプライアンスや業務上の要件が求める期間だけ、実行可能な最小のコストでログにアクセスでき、クエリできる状態を保つことが目的です。SIEMは検知に最適化されています。大量のイベントから、セキュリティ上意味のあるシグナルをほぼリアルタイムで浮かび上がらせることが目的です。
SIEMがログ管理の基盤も兼ねることを期待して導入したチームは、ストレージコストが想定をはるかに超えていることに気づくことが少なくありません。SIEMベンダーは通常、取り込み量に応じて課金します。そしてクラウド環境はその量を、網羅的な保持が経済的に成り立たない水準まで押し上げます。結局、多くのチームは階層化に行き着きます。価値の高いセキュリティイベントを絞り込んでSIEMに送り、より安価なログ管理システムでコンプライアンスとフォレンジックのためにすべてを保持する、という形です。
このコスト構造は、オープンソースSIEMという選択肢が支持を広げた理由の一つでもあります。保持のコスト層を下げ、そこに目的特化型の検知ツールを組み合わせるという使い方です。
どちらもきれいには解けないデータ量の問題
二つのカテゴリーは、同じ潮流から同じ圧力を受けています。ログ量が、これらのツールが想定していた経済性よりも速く増えているのです。
従来のSIEMアーキテクチャは、Active Directory、境界ファイアウォール、エンドポイントエージェントのように、予測可能で範囲の限られたログソースを持つオンプレミス環境を前提に作られていました。現代のインフラはまったく別物です。AWSとAzureにまたがってワークロードを動かし、50を超えるSaaSアプリケーションを使い、サービスを大規模に展開している組織は、多くのSIEMプラットフォームが設計された当時には存在しなかったソースからイベントを生み出します。
その結果、ほとんどのSIEMは必要に迫られて選択的な取り込みで運用されています。カバレッジの空白は、そのまま検知の空白になります。セキュリティチームはこれを手痛い形で知ることになります。インシデントが起き、そのとき関係するログソースがSIEMに流れていなかった、というわけです。
ログ管理もこれを解決しません。網羅的な保持は何が起きたのかを再構成する助けになりますが、それは検知のあとの話です。進行中の攻撃を捉えることはできません。ログ記録と脅威検知に関するCISAのガイダンスは、ログデータの価値が、それが実際に分析されているかどうかにすべて懸かっていることを強調しています。
アーキテクチャをどう考えるか
SIEMが必要なのか、専用のログ管理が必要なのか、その両方なのかを見極めるとき、役に立つ問いはこうです。どのようなセキュリティ上の成果を目指しているのか、そしてそれに実際に責任を持つのはどちらのツールなのか。
主な動機がコンプライアンス、つまり定められた期間ログを保持し、監査時に求めに応じて提出することであれば、保持とコスト効率の高いストレージを重視した専用のログ管理プラットフォームが適切な土台になります。検知はその上に、SIEM連携か、より現代的な検知層として載せる形になります。
主な動機が検知と対応であれば、SIEMが適切な出発点です。ただし、そのログカバレッジの限界は明示的に織り込んで計画する必要があります。どのソースが最も重要か。何を選択的に取り込むか。何をより安価な保持に置くか。SIEMの移行を進めるチームは、これらの問いに正面から向き合うことになります。どれだけのログデータが検知の範囲の外にあったのか、そして新しいアーキテクチャが本当にその空白を埋めるのかが見えてくるからです。
SIEMツールの評価ガイドでは、ログ取り込みの深さ、ストレージの経済性、検知カバレッジという観点でプラットフォームを比較する際に確認すべき点を扱っています。次世代SIEMのアプローチが、より幅広いソース種別と柔軟な取り込みモデルに対応することでアーキテクチャの前提をどう変えたかについても触れています。
境界が溶けていくところ
ログ管理とSIEMによる検知の分離は、これらのツールがどう作られてきたかの産物であって、セキュリティ運用に本来備わった性質ではありません。セキュリティチームが必要としているのは、完全な可視性と、その上に載る知的な分析です。つまり、関係するすべてのログソースが取り込まれ、正規化され、脅威の兆候としてリアルタイムに評価されること、しかもカバレッジの取捨選択を強いるコスト構造なしに、ということです。
AIネイティブなセキュリティプラットフォームは、これに別の角度から取り組みます。ログソースごとに相関ルールを手で書かせるのではなく、環境全体の行動ベースラインを学習する機械学習モデルを用い、攻撃パターンに一致する逸脱を検出します。検知層は、絶え間ないルール保守を求めるのではなく、環境の変化に合わせて適応していきます。
Exaforceは、クラウド、SaaS、アイデンティティ、エンドポイントの各ソースを横断する統合的なデータ取り込みと、ビヘイビアモデルおよびセマンティックモデルによって、網羅的なルールを用意しなくても脅威を浮かび上がらせます。その結果、SIEMの選択的な取り込みという人為的な制約、つまり侵害が起きるまで気づかれないことの多いカバレッジの空白を生む要因が、以前ほど効いてこなくなります。
アーキテクチャの行き先を見極めようとしているチームにとって、実務的な問いは、次回の更新時に自社の検知カバレッジが今より良くなっているか悪くなっているか、そしてコストの推移が持続可能かどうかです。どちらかの答えが芳しくないのであれば、SIEM置き換えの選択肢はこの二年で十分に変わっており、前回評価したときとは経済性が大きく違って見えるはずです。