なぜ今SIEMが必要なのか――「点」の防御から「線」の可視化へ

EDR・メール・WAFを入れていても侵害は起きる。個別製品という「点」の防御では見えない、攻撃チェーンという「線」をどう可視化するか。

EDR、メールセキュリティ、WAF、Firewall。日本企業の多くは、この10年でレイヤーごとのセキュリティ製品を着実に積み上げてきました。「各層に製品を入れているのだから、対策としては十分だ」――そう考えるのは自然なことです。しかし、それでも侵害は起き続けています。しかも、発覚までに1年近くかかるケースが珍しくありません。

問題は、個々の製品の性能ではありません。製品と製品の「あいだ」に、誰も見ていない空白があることです。本稿では、この空白がなぜ生まれるのか、そしてそれを埋める現実的な選択肢としてSIEMを再検討すべき理由を整理します。

「点」を守る製品は、自分の持ち場しか見ていない

メールセキュリティ製品は、メールが配送される瞬間の脅威を判定します。EDRはエンドポイント上のプロセスの挙動を、WAFはWebアプリケーションへのHTTPリクエストを、Firewallはネットワーク境界の通信を、それぞれ監視します。

どの製品も、自分の担当範囲では優秀です。しかし裏を返せば、各製品は自分の担当範囲の外で何が起きているかを知りません。メールセキュリティ製品は「このメールの送信元が、社内の端末と通信を始めた」ことを知る術がなく、EDRは「この通信先IPが数時間前に不審メールの送信元として弾かれていた」ことを知りません。

つまり、各製品が出すアラートは、それぞれ独立した「点」です。点を増やすことと、全体が見えることは、同じではありません。

攻撃は「線」で進む

攻撃者の行動を考えてみます。典型的な攻撃チェーンは、初期侵入→権限昇格→横展開→データ持ち出し、という段階を踏みます。ここで重要なのは、攻撃者は単一の製品・単一のログソースで完結する行動を取らないという点です。

具体的なシナリオで考えます。ある朝、標的型メールの一部がメールセキュリティ製品にブロックされました。製品としては「防御成功」であり、深刻度の低いログが1件残るだけです。しかし数通はすり抜け、ある社員が添付ファイルを開きました。数時間後、EDRがその端末上でやや不審なプロセスを検知しますが、単体では確信度が低く、低優先度アラートとして流れていきます。その夜、その端末から普段アクセスしないファイルサーバーへの認証が成功し、数日後、境界のFirewallログに外部への断続的なデータ送信が記録されます。

このシナリオの各段階を切り出すと、どれも「単体では対応不要と判断されうるイベント」です。しかし「ブロックされたメールの送信元IPと、EDRが検知した不審プロセスの通信先が一致している」という事実を重ねた瞬間、これは明確な攻撃チェーンとして浮かび上がります。この判断は、複数のログソースを横断し、時系列で突き合わせる「線」の視点でしか成立しません。

ここに逆説があります。ツールを増やすほど「点」は増えます。しかし点をつなぐ仕組みがなければ、担当者が見るべきコンソールとアラートが増えるだけで、全体の可視性はむしろ低下しうるのです。

データが示す「発覚までの長い空白」

この構造的な問題を示唆するデータがあります。

サイバーセキュリティクラウド社が国内の個人情報漏えい1,000件以上の不正アクセス事案を分析した調査(2021年版)では、攻撃発生から発覚までに平均349日、発覚から公表までにさらに平均82日を要していました。発覚までに90日超かかった事案は6割以上にのぼります。グローバルでも、IBMの「Cost of a Data Breach Report 2025」によれば、侵害の特定までに平均181日、封じ込めまでにさらに60日、合計241日を要しています。これは過去9年で最短の数字ですが、それでも8カ月です。

断っておくと、これらの数字は「SIEM未導入が長期化の原因である」と証明するものではありません。ただ、各製品のアラートを個別に眺める運用では侵害の全体像に気づきにくい、という本稿の指摘とは整合的なデータだと考えられます。

一方で、日本企業のSIEM導入状況を見ると、JIPDECとITRの「企業IT利活用動向調査2025」ではSIEM/XDRを「導入している」企業は28.5%(導入予定を含めても57.4%)、日経クロステックの調査では「導入している」は17%にとどまります。調査により幅はあるものの、おおむね2〜3割前後、つまり多数派はいまだ「点の防御」の段階にあると見てよさそうです。

「SIEMは高くて運用が大変」――その認識は半分正しい

導入が進まない理由は明確で、従来型SIEMには実際に高いハードルがありました。この認識を無視して「SIEMを入れましょう」と言っても説得力はありません。

従来型SIEMのコスト構造には2つの問題がありました。第一に、取り込むログ量に応じた課金体系です。ログを網羅的に入れるほど費用が膨らむため、コストを抑えようとするとログを絞ることになり、せっかくの「線の可視化」に穴が開きます。市場の相場感としても、SaaS型SIEMで取込ログ量1〜5GB/日で月額10〜30万円、10〜50GB/日で30〜100万円という水準が報告されており、ログ量が増えるほど負担は重くなります。第二に、相関ルールの設計・チューニング・アラートの一次トリアージを担う専任アナリストが前提だったことです。ライセンス費用に加えて人件費と教育コストがのしかかり、体力のある大企業以外には手が届きませんでした。

さらに、運用する側の疲弊も指摘されています。海外調査(Tines「Voice of the SOC」、参考値)では、SOCメンバーの81%がストレスを感じ、67%がバーンアウトを経験しているとされます。人手前提の運用モデル自体が持続可能性を欠いていた、というのが過去のSIEMの実像です。

ログを集めるだけでは、アラートの発生源が一つ増えるだけ

ここで釘を刺しておきたいのは、「SIEMさえ導入すれば解決する」わけでもない、ということです。

ログを一元化しても、相関ルールを設計し、鳴ったアラートを一次判定する仕組みがなければ、SIEMは「大量のアラートを出す新たな点」になるだけです。従来これを人手で担ってきたことが、前述の高コスト・高負荷の正体でした。

したがって、SIEMが現実的な選択肢になる条件は2つです。ログ量を気にせず集約できる低コストな基盤であること。そして、相関分析とアラートの一次トリアージをAIが肩代わりすること。この2つが揃って初めて、「線の可視化」は大企業専用の贅沢品ではなくなります。近年この組み合わせは「AI SOC」と呼ばれ、SIEMとセットで運用するモデルとして確立しつつあります。

ヤグラのアプローチ――DataLake型SIEMとAI SOCの組み合わせ

ヤグラは、この2条件を満たすことを設計思想とした自社SIEM(DataLake基盤)を保有しています。

構造はシンプルです。まず、汎用的なDataLakeアーキテクチャの上にログ基盤を構築することで、保管・取込のコストを従来型SIEMより低く抑え、「コストのためにログを絞る」というジレンマを解消します。EDR、メール、WAF、Firewall、クラウド――既存製品のログをそのまま集約する前提です。次に、集約したログの相関分析とアラートの一次トリアージをAIが担うことで、専任アナリストの常駐を前提としない運用を可能にしています。人が向き合うのは、AIが「線」としてつなぎ、確度を評価した後の少数の事案だけです。

費用面では月額30万円程度からの水準で、ログ量や構成によって変わりますが、従来「SIEM+専任アナリスト」に必要とされた投資とは桁の異なる出発点になっています。