SIEMとは？セキュリティログ統合管理と相関分析で実現する次世代の脅威検知

企業や組織が守るべき情報資産は、サーバー、ネットワーク機器、クラウドサービス、PC、スマートフォンなど、多岐にわたる場所に分散しています。これらの機器からは、毎日膨大な量の「ログ」が出力され続けています。

「ファイアウォールのアラートだけを見ていれば大丈夫」「サーバーのログは障害が起きた時だけ見ればいい」。もし、このような運用を続けているなら、それは非常に危険な状態です。

なぜなら、高度なサイバー攻撃は単一の機器のログを見るだけでは痕跡を見つけることが困難だからです。攻撃者は、ファイアウォールを正規の通信に見せかけて通過し、Webサーバーの脆弱性を突き、内部ネットワークへ侵入し、データベースへと横展開していきます。

複数の機器にまたがる断片的なログを「点」として見るのではなく、それらをつなぎ合わせて「線」や「面」として捉え、攻撃の全体像をリアルタイムに可視化する仕組みが、SIEM（Security Information and Event Management）です。

本記事では、セキュリティ運用の要とも言えるSIEMの役割、仕組み、そして情報処理安全確保支援士試験で問われる重要ポイントについて、実務的な観点も含めて徹底的に解説します。

この記事では、SIEMがログを収集・正規化し、相関分析で脅威を検知してから対応につなげるまでの流れと、時刻同期・誤検知のチューニング・ログの保護といった運用上の論点を学べます。

SIEMが現代のセキュリティ対策に不可欠な3つの理由

SIEMとは、Security Information Management（セキュリティ情報管理）とSecurity Event Management（セキュリティイベント管理）を組み合わせた用語です。日本語では「セキュリティ情報イベント管理」と訳されますが、現場ではそのまま「シーム」と呼ばれることが一般的です。

なぜ今、SIEMがこれほどまでに重要視されているのでしょうか。その背景には、防御側が抱える構造的な課題と、攻撃手法の高度化があります。

理由1：多層防御が生み出す「ログのサイロ化」問題

セキュリティ対策の基本は「多層防御」です。しかし、防御層を厚くすればするほど、管理すべきログの種類と量は爆発的に増加します。

主なログソースの例：

• ネットワーク機器のSyslog
• Webサーバーのアクセスログ
• データベースの監査ログ
• 認証サーバーのイベントログ
• クラウドサービスの監査ログ（AWS CloudTrail、Azure Activity Log等）
• EDR（Endpoint Detection and Response）の挙動ログ
• プロキシサーバーの通信ログ

これらは通常、それぞれの管理画面やサーバー内にバラバラに保存されています。この状態を「ログのサイロ化」と呼びます。インシデント発生時に、これらを手動で突き合わせることは、砂浜で針を探すような作業であり、迅速な対応を難しくします。

理由2：高度化するサイバー攻撃への対応

近年のサイバー攻撃、特に標的型攻撃やランサムウェア攻撃は、一見すると無害に見える操作を組み合わせて行われることが増えています。

攻撃の見えにくさの例：

「深夜2時にVPNへログインがあった」というイベント単体では、海外出張中の社員かもしれないため、即座に不正とは断定できません。また、「社内のファイルサーバーから大量のデータ送信があった」というイベントも、バックアップ処理かもしれないため、これだけでは異常とは言い切れません。

しかし、これらが同じユーザーIDで短時間に連続して発生したとしたらどうでしょうか。「深夜にVPN接続し、直後にファイルサーバーから大量データを持ち出している」となれば、これは極めて危険な兆候である可能性が高まります。

このように、異なる機器やアプリケーションから出力されるログを突き合わせ、関連性を見つけ出す手法を相関分析（Correlation Analysis）と呼びます。SIEMは、この相関分析を自動化し、膨大なログの中から調査すべき可能性が高いイベントを絞り込む役割を担っています。

理由3：コンプライアンスと監査要件への対応

PCI DSSのように監査ログの保存期間まで明示する業界基準があるほか、個人情報保護法の安全管理措置や金融商品取引法に基づく内部統制（J-SOX）への対応でも、アクセスログなどの記録・保管・点検が実務上求められます。SIEMは、こうした要求に応えるためのログの長期保管、検索可能性、改ざん防止機能を統合的に提供します。

特に重要なのは、インシデント発生時に「いつ、誰が、どこから、何をしたか」を迅速に再構築できる能力です。これは事後調査（フォレンジック）においても不可欠な機能となります。

SIEMの核心機能：ログから脅威インテリジェンスへの3ステップ

SIEMは単なる「ログ保管庫」ではありません。ログを保管するだけであれば、統合ログ管理システム（Log Management System）で十分です。SIEMの真価は、集めたデータを「標準化」し、「分析」し、「行動可能な情報（アクショナブルインテリジェンス）」に変換することにあります。上の図で「実行可能なインテリジェンス」と表記しているのも、この行動可能な情報のことです。

ステップ1：ログの収集と正規化（Normalization）

最初のステップは、あらゆるソースからのログ収集です。しかし、機器やベンダーによってログのフォーマットはバラバラです。

フォーマットの違いの例：

• ファイアウォールA: 2026-02-16 10:00:00, SRC=192.168.1.1, DST=10.0.0.1, Action=Drop
• WebサーバーB: [16/Feb/2026:10:00:05 +0900] "GET /index.html" 200
• Windows Server: イベントID 4624 （ログオン成功）

このように、日時の表記方法（タイムスタンプのフォーマットやタイムゾーン）、IPアドレスの記載位置、イベントの意味を表すコードなどが統一されていません。

SIEMはこれらを収集する際に、共通のフォーマットに変換します。これを正規化（Normalization）と呼びます。

正規化の具体的なメリット：

• 異なるベンダーの機器でも「いつ（Time）」「誰が（User）」「どこから（Src IP）」「どこへ（Dst IP）」「何をした（Event）」という共通の軸で横断的に検索・分析が可能
• タイムゾーンの統一（全てUTCまたはJSTに揃える）により、正確な時系列分析を実現
• 検索クエリの簡素化とパフォーマンス向上

特に、タイムゾーンの統一は、正確な時系列分析を行うための大前提となります。グローバル展開している企業では、各国のシステムが異なるタイムゾーンでログを出力するため、この処理が極めて重要です。

ステップ2：相関分析（Correlation Analysis）と脅威検知

正規化されたデータに対し、あらかじめ設定されたルール（シグネチャ）や統計モデル、機械学習アルゴリズムに基づいて分析を行います。これがSIEMの心臓部です。

ルールベース検知の代表例

シナリオに基づいたルールを設定し、条件に合致した場合にアラートを発報します。

具体的な検知ルール：

• ブルートフォース攻撃の検知: 「同一IPアドレスから」+「1分以内に」+「5回以上のログイン失敗」
• ワームの拡散検知: 「内部端末から」+「ポート445に対し」+「短時間に多数の異なるIPへ接続試行」
• C&Cサーバー通信の検知: 「プロキシログの接続先ドメイン」が「既知のブラックリスト」と一致
• 権限昇格の検知: 「一般ユーザーアカウント」で「管理者コマンドの実行」が発生

複合的な相関分析の実例

複数のログソースを跨いだ高度な分析により、単一ソースでは見えない攻撃を検知します。

侵入後の横展開（ラテラルムーブメント）検知：

1. IDS（侵入検知システム）がWebサーバーへの攻撃パケットを検知
2. その直後、同じWebサーバーで管理者権限への昇格イベントが発生
3. 続いて、同じWebサーバーから、通常は通信しない宛先・プロトコルでの通信（内部のActive Directoryサーバーへの接続など）が発生
4. SIEMがこれら一連のイベントを同一ホストの連続した動きとして結び付け、横展開の疑いとしてアラート化

このように時系列で関連するイベントを結び付ける照合は、手作業では時間がかかりますが、SIEMはそれを自動で行います。アラートはあくまで調査の起点であり、侵入の有無は他のログや端末の調査で裏付けます。

統計的異常検知とUEBA

近年のSIEMは、ルールベースだけでなく、統計分析や機械学習を活用したUEBA（User and Entity Behavior Analytics）の機能を備える製品が多くあります（標準機能かオプションかは製品によります）。

UEBAの検知例：

• 普段9時-18時しかログインしない社員が深夜3時にログイン
• 通常1日10MBしか扱わない社員が突然1GBのデータをダウンロード
• 過去3ヶ月アクセスしたことのないサーバーに突然アクセス

これらは「ルール」では定義しにくい「普段と違う」行動であり、内部不正や乗っ取りの兆候に気づく手がかりになります。

ステップ3：可視化・アラート・対応支援

分析結果は、ダッシュボード上にグラフ、ヒートマップ、地図として可視化されます。セキュリティアナリスト（SOCのオペレーターなど）は、このダッシュボードを監視し、異常の兆候を早期に発見します。

主な可視化機能：

• リアルタイムアラートダッシュボード（重要度別の色分け表示）
• 攻撃元IPの地理的分布マップ
• 時系列での攻撃トレンドグラフ
• 影響を受けた資産の一覧とリスクスコアリング

また、近年のSIEM（次世代SIEM）や、SOAR（Security Orchestration, Automation and Response）と連携したシステムでは、検知にとどまらず、定義したプレイブックに従って初動対応を自動化できます。

自動対応の例：

• マルウェア感染の疑いが高い端末を検知したら、自動的にネットワークから遮断するコマンドをスイッチに送信
• 不正アクセスを検知したら、該当アカウントを自動的に無効化
• 特定IPアドレスからの攻撃を検知したら、ファイアウォールのブロックリストに自動追加

これにより、検知後の初動対応や封じ込めまでの時間を短縮できます。セキュリティ運用では、封じ込めまでの平均時間をMTTC（Mean Time To Contain）と呼ぶことがあります。なお、試験の信頼性・可用性の分野で「MTTR」といえば平均修復時間（Mean Time To Repair）を指します。セキュリティ運用で使われるMTTR（Mean Time To Respond、平均対応時間）とは別の指標なので、混同しないよう注意してください。

SC試験対策のポイント

令和8年度から情報処理安全確保支援士試験はCBT方式で実施されています。SIEMは、科目A-2（旧午前II）ではSIEM・相関分析・正規化・UEBA・SOARといった用語の意味を問う4択として、科目B（旧午後）ではインシデント対応の事例の中で、時刻同期の前提、誤検知への対処、ログの保護、どのログを組み合わせれば攻撃が見えるかを説明させる形で問われることが考えられます。なお、SIEMの機能は他の試験区分の午前問題でも問われています。ここでは、特に「運用」や「インシデント対応」の文脈で押さえたい観点を整理します。

論点1：ログの時刻同期とNTPの重要性

SIEMで正しい相関分析を行うためには、すべてのログソースの時刻が正確に合っている必要があります。

なぜ時刻同期が重要なのか：

• ログの時刻がずれていると、攻撃の因果関係（どちらが先に起きたか）を誤認する
• 例：Webサーバーへの攻撃が先か、内部サーバーへの侵入が先か判断できない
• イベント同士の間隔が短い場合は、数秒のズレでも前後関係を取り違え、判断を誤るおそれがある

試験で想定される問われ方：

• 「ネットワーク内の全機器がNTP（Network Time Protocol）サーバーと同期していること」が、SIEM運用の前提条件として記述される
• 時刻同期がされていないことによる問題点を指摘させる設問
• NTPサーバー自体のセキュリティ対策（NTP増幅攻撃への対処など）

実務での対策：

• Stratum 1またはStratum 2のNTPサーバーを社内に設置
• 全機器を定期的にNTPサーバーと同期するよう設定
• NTPサーバーへのアクセスをファイアウォールで制限

論点2：誤検知（False Positive）とチューニングの必要性

SIEMは導入して終わりではありません。導入直後は、通常の業務通信を攻撃と誤認する「誤検知（フォールスポジティブ）」が大量に発生することがあります。

誤検知の典型例：

• 正規のバックアップ処理が「大量データ転送」として検知される
• 定期メンテナンスでの管理者ログインが「深夜の不正アクセス」として検知される
• 営業部門が使う正規のクラウドストレージが「未承認クラウドサービス利用」として検知される

試験で想定される問われ方：

• 「SIEMのアラートが多すぎて重要な通知が埋もれてしまう」という課題に対する解決策を問う
• 解答の方向性：「業務内容に合わせて検知ルール（閾値やホワイトリスト）をチューニングする」

実務でのチューニング手法：

• ホワイトリスト登録：正規の業務通信や信頼できるIPアドレスを除外
• 閾値調整：環境に応じて「5回」を「10回」に変更するなど
• 時間帯フィルター：バックアップ時間帯のアラートを抑制
• 段階的導入：最初は通知のみ（自動対処はしない）で運用し、誤検知率を測ってから自動対処へ広げる

論点3：ログの保存期間とフォーマット

コンプライアンスやフォレンジック（事後調査）の観点から、ログをどの程度の期間、どのような形式で保存すべきかも問われます。

保存期間の考え方（法令・基準の例）：

• ログの保存期間を法令で一律に定めているケースは少なく、法令・業界基準・契約・調査の必要性を踏まえて組織が保存ポリシーとして定めるのが基本
• PCI DSS v4.0.1（クレジットカード業界の基準、要件10.5.1）：監査ログを少なくとも12か月保存し、直近3か月分はすぐに分析できる状態にしておく
• GDPR：具体的な年数の定めはなく、目的に必要な期間を超えて個人データを保存しない「保存制限の原則」が適用される（ログに個人データが含まれる場合）
• 不正アクセス禁止法：ログの保存期間を定めた規定はない。ただし、捜査機関への情報提供や事後調査に備え、一定期間（例：1年程度）の保存を方針として定めておくことが望ましい

SIEMのストレージ戦略：

• ホットデータ（直近3ヶ月）：高速ストレージに保存、即座に検索・分析可能
• ウォームデータ（3ヶ月〜1年）：中速ストレージに保存、必要時に検索可能
• コールドデータ（1年以上）：低速・大容量ストレージやテープにアーカイブ

試験で使える解答の観点：

• 「ログサーバーを分離したセグメントに置き、通信・管理権限を制限する。保存済みログにはWORM等の改ざん防止策を併用する」
• 「ログは一度書き込んだら書き換え・削除できない（WORM: Write Once Read Many）媒体やストレージに保存する」
• 「個人情報の利用・閲覧を必要最小限に制限し、分析・共有用データは必要に応じてマスキングする。調査に必要な原本はアクセス制御下で保全する」

攻撃者は痕跡を消そうとするため、ログ自体の保護がセキュリティ上極めて重要です。

論点4：UEBA（User and Entity Behavior Analytics）への発展

従来のルールベース（閾値超えなど）では検知しにくい未知の脅威や内部不正に対応するため、AIや機械学習を用いたUEBAも、SIEMの発展形として押さえておきたい概念です。

UEBAの仕組み：

• ユーザーや機器の「普段の振る舞い」をベースライン（基準線）として学習
• ベースラインから統計的に有意に逸脱した行動を検知
• 例：普段アクセスしない時間に、普段使わない大量のファイルにアクセスした

従来のSIEMとの違い：

• 従来型：「1分間に5回ログイン失敗したら検知」という絶対的なルール
• UEBA：「このユーザーは普段1日1回しかログインしないのに、今日は10回ログインしている」という相対的な異常を検知

理解のポイント：

• SIEMの進化系、次世代SIEMの一機能として理解
• 「既知の攻撃」は主にルールベース、「未知の攻撃や内部不正」は主にUEBAで検知する。どちらか一方ではなく、両者の併用が基本

科目Bでの解答アプローチ

SIEMに関する問題が出た際は、以下の視点を持って解答を作成しましょう。

「なぜ検知できたのか？」を問われたら：

• 「複数のログ（ファイアウォールとサーバーなど）を突き合わせた」
• 「時系列での関連性を分析した」
• 「IPアドレスやユーザーIDの一致から関連するイベントを結び付けた」

「なぜ検知できなかったのか？」を問われたら：

• 「必要なログソースをSIEMに取り込んでいなかった」
• 「時刻同期がされておらず、時系列分析が正確にできなかった」
• 「検知ルールが設定されていなかった、または閾値が適切でなかった」

「運用上の注意点は？」を問われたら：

• 「ログ容量の肥大化対策として、重要度の低いログはフィルタリングする」
• 「個人情報の利用・閲覧を必要最小限に制限し、分析・共有用データは必要に応じてマスキングする。調査に必要な原本はアクセス制御下で保全する」
• 「ログサーバーを分離したセグメントに置き、通信・管理権限を制限する。保存済みログにはWORM等の改ざん防止策を併用する」
• 「誤検知を減らすため、定期的なチューニングを実施」

実践シナリオ：SIEMが防ぐ標的型攻撃の全容

科目Bでは、具体的な攻撃シナリオの中でログ分析がどう役立つかが問われることが考えられます。典型的なシナリオを詳しく見てみましょう。

攻撃シナリオ：標的型メールからランサムウェア展開まで

フェーズ1：侵入（Initial Compromise）

• 社員Aが標的型メールの添付ファイル（マクロ付きExcel）を開封
• マクロが実行され、PCがマルウェアに感染
• マルウェアは外部のC&Cサーバーへ通信を開始（ビーコン通信）

フェーズ2：潜伏と内部探索（Discovery）

• 攻撃者はPC内の認証情報（Credential）を窃取
• ファイルサーバーへアクセス権を持つ社員BのIDとパスワードを入手
• 社内ネットワークの構成を調査（横方向スキャン）

フェーズ3：横展開（Lateral Movement）

• 社員BのIDを使い、ファイルサーバーへ不正ログイン
• ファイルサーバーから重要なサーバー（会計システム）への経路を発見
• 会計システムへログインを試みる

フェーズ4：目的実行（Impact）

• 会計データを暗号化するランサムウェアを展開
• 復号と引き換えに身代金を要求

SIEMがない場合の被害拡大

検知の失敗：

• PCのアンチウイルスソフトが新種マルウェアを検知できず
• C&C通信は443番ポート（HTTPS）を使い、通常のWeb閲覧に紛れる
• プロキシログに記録はあるが、膨大な正規通信の中に埋もれて気づかれない
• ファイルサーバーへのアクセスも正規のID（社員B）で行われているため、サーバー単体のログでは異常に見えない

被害発覚のタイミング：

• ランサムウェアで暗号化された後、身代金要求画面が表示されてから
• または、情報が外部に公開（ダークウェブで売買）されてから
• この時点では既に手遅れで、復旧に長い期間がかかり、損害も大きくなりがち（期間や金額は規模により大きく異なる）

SIEMがある場合の早期検知と封じ込め

検知ポイント1：C&C通信の発見（フェーズ1）

• プロキシログの分析で「業務時間外」に「アクセス実績のないドメイン」への通信を検知
• 特定PCから「定期的」に発生（ビーコン通信の特徴）
• アラート：「未知の外部通信を検出。マルウェア感染の疑い」

検知ポイント2：なりすましアクセスの発見（フェーズ3）

• Active DirectoryログとPC使用履歴の相関分析
• 社員BのIDが、「普段社員Bが使用しないPC（社員AのPC）」から使用されていることを検知
• アラート：「通常と異なる端末からのログイン。認証情報の窃取の疑い」

検知ポイント3：横方向スキャンの発見（フェーズ2-3）

• ネットワークフローログの分析
• 特定PC（社員AのPC）から、通常アクセスしない複数の内部サーバーへの接続試行を検知
• アラート：「内部ネットワークスキャン検知。偵察活動の疑い」

複合アラートとインシデント化： SIEMは上記3つのアラートを時系列と関連IPアドレスで紐付け、「感染端末からのなりすましアクセスと横展開の疑い」として重大インシデントに格上げ。SOC（Security Operations Center）へ緊急通知。

初動対応（フェーズ4を阻止）:

• SOARとの連携により、感染が疑われる社員AのPCを自動的にネットワークから隔離
• 社員BのIDを一時的に無効化
• セキュリティチームが詳細調査を開始
• ランサムウェア展開前に封じ込めに成功

このように、SIEMは個々のログでは「正常」に見える挙動の中に潜む違和感を、コンテキスト（文脈）を理解することで炙り出します。点を線にし、線を面にすることで、攻撃の全体像を可視化するのです。

SIEM導入・運用の現実的な課題と対策

SIEMは強力なツールですが、魔法の杖ではありません。その運用には高いスキルとコストが伴います。実務で直面する主な課題と、それに対する現実的な対策を解説します。

課題1：高額な導入・運用コスト

コストの内訳：

• ライセンス費用：商用SIEM製品は高額になりやすい（金額は製品・規模・契約により大きく異なる）
• 取り込み量に応じた課金：EPS（Events Per Second）や1日あたりのデータ量（GB/日）などに応じた従量課金
• ストレージ費用：大量のログを長期保存するためのストレージコスト
• 人件費：SIEM運用エンジニアの人件費（運用コストの中で大きな比重を占めることが多い）

対策：

• ログの選別： 全てのログを取り込むのではなく、セキュリティ上重要なログに絞る
• データ圧縮： ログを圧縮して保存することでストレージコストを削減
• クラウドSIEMの活用： Microsoft Sentinel、Splunk Cloud Platform、Google Security Operations（旧Chronicle）などのクラウド型SIEMは初期投資が少ない
• オープンソース活用： ELK Stack（Elasticsearch, Logstash, Kibana）など、無料のOSSベースで構築（ただし運用スキルが必要）

課題2：深刻なセキュリティ人材不足

アラートが上がった際、それが本当に脅威なのか、誤検知なのかを判断し、実際に対処を行うのは人間（アナリスト）です。しかし、SIEMを使いこなせるセキュリティエンジニアの確保が最大の課題となっています。

必要なスキルセット：

• ログフォーマットの理解（Syslog, Windows Event, JSON等）
• ネットワークプロトコルの知識（TCP/IP, HTTP, DNS等）
• 攻撃手法の理解（MITRE ATT&CK フレームワーク等）
• インシデント対応の経験
• SIEMツール固有のクエリ言語（SPL, KQL等）

対策：

• Managed SIEMの活用： 自社運用ではなく、監視・分析業務を専門ベンダーにアウトソース
• SOCサービスの利用： 24時間365日の監視を外部SOCに委託
• 段階的な内製化： 最初は外部SOCに依存し、徐々に社内人材を育成
• プレイブックの整備： アラートごとの対応手順書を作成し、経験の浅いメンバーでも対応可能に

課題3：誤検知の嵐とアラート疲れ

導入初期は、大量のアラートが発生することも珍しくありません（件数は環境や規模により大きく異なります）。その大半が誤検知である場合、本当に重要なアラートを見逃す「オオカミ少年」状態に陥ります。

対策：

• 段階的な展開： 最初は通知のみ（自動対処はしない）で運用し、誤検知率を測ってから自動対処へ広げる
• ベースラインの確立： 正常な通信パターンを学習させる期間を設ける（学習期間は製品・分析対象による）
• 優先度の明確化： アラートを「Critical」「High」「Medium」「Low」に分類し、重要度の低いものは週次レビューに回す
• 継続的なチューニング： 週次または月次でルールを見直し、誤検知を減らす

課題4：クラウド環境への対応

近年、オンプレミスからクラウド（AWS、Azure、GCP）への移行が進んでいますが、クラウド特有のログ（CloudTrail、Azure Activity Log、Cloud Audit Logs等）は従来のSIEMでは対応が難しい場合があります。

対策：

• クラウドネイティブSIEMの採用： Microsoft Sentinel（Azure統合）、Google Security Operations（旧Chronicle、Google Cloud統合）など
• CSPM（Cloud Security Posture Management）との連携： クラウドの設定ミスやポリシー違反を検出
• マルチクラウド対応： 複数のクラウドプロバイダーのログを統合管理できるSIEMを選定

主要なSIEM製品とその特徴

市場には多くのSIEM製品が存在します。代表的な製品とその特徴を理解しておくことで、試験でも実務でも役立ちます。

商用SIEM製品

Splunk Enterprise Security

• 高機能で柔軟性が高い（Splunkは2024年にCiscoが買収）
• SPL（Search Processing Language）による強力な検索・分析
• 高額だが、大企業での導入実績が豊富

IBM QRadar

• ネットワークフロー分析に強み
• オンプレミス版のQRadar SIEMはIBMが継続提供
• SaaS版（QRadar on Cloud）は2024年にPalo Alto Networksへ売却され、2026年4月14日に提供を終了した（同社はCortex XSIAMへの移行を案内）

OpenText Enterprise Security Manager（旧ArcSight ESM。Micro Focusから移管）

• 古くからある老舗SIEM
• 複雑なルール設定が可能

クラウドネイティブSIEM

Microsoft Sentinel

• Azureとの深い統合
• KQL（Kusto Query Language）を使用
• Azureとの統合により構築負担を抑えられる場合がある。費用はログ取り込み量・保存期間等に依存する

Google Security Operations（旧Chronicle）

• Googleのインフラと検索技術を活用
• ペタバイト級のログも高速検索
• 料金体系は契約形態により異なる（取り込みデータ量に基づく課金もある）

SIEMと組み合わせて使う関連サービス

AWS Security Hub

• SIEMではなく、AWS環境のセキュリティ検出結果を集約・優先順位付けするサービス。検出結果をSIEMへ連携して相関分析に使うなど、SIEMと組み合わせて使う関連サービスとして位置づけられる
• 2025年12月に刷新され、従来の機能はSecurity Hub CSPMに改称された
• AWS環境に特化
• GuardDuty、Macieなど他のAWSセキュリティサービスと連携
• マルチアカウント管理に対応

オープンソース・低コストオプション

ELK Stack (Elastic Stack)

• Elasticsearch + Logstash + Kibana
• 無償で利用できる範囲があるが、運用には高度な知識が必要
• SIEM機能はElastic Securityとして提供（無償範囲と有償サブスクリプションあり）

Wazuh

• ホストベースの侵入検知システム（HIDS）機能を持つ
• コンプライアンス監視に強い
• 無償で利用できるオープンソース（有償のクラウド版・サポートもあり）

学習のまとめ：試験対策と実務への応用

SIEMは「検知」フェーズの要であり、情報処理安全確保支援士試験でもログ監視・インシデント対応を理解するうえで欠かせない重要キーワードです。本記事で解説した内容を振り返ります。

試験で問われる重要ポイント

1. SIEMの定義と役割
   • 複数機器のログを一元管理し、相関分析によって脅威を検知・可視化するシステム
   • ログのサイロ化問題を解決し、インシデントの全体像を把握
2. 正規化（Normalization）の重要性
   • 異なるフォーマットのログを統一形式に変換
   • （前提として）各機器の時刻同期（NTP）が不可欠
   • タイムゾーンの統一により正確な時系列分析を実現
3. 相関分析（Correlation）の仕組み
   • 単体では正常に見える複数の事象を組み合わせて脅威を検知
   • ルールベース検知と統計的異常検知（UEBA）の組み合わせ
   • 時間軸、IPアドレス、ユーザーIDなど複数の軸で関連性を分析
4. 運用上の重要ポイント
   • 誤検知を減らすためのチューニングが必須
   • ログの選別（不要なログを取り込まない）
   • ログ自体の保護（改ざん防止、別セグメント配置）
   • 人材育成またはアウトソーシング戦略

実務での応用：段階的なSIEM導入ロードマップ

実務でSIEMを導入する際の推奨ステップです。各フェーズの期間は説明用の計画例であり、標準期間ではありません。

Phase 1（準備期間：1〜2ヶ月）

• ログソースの棚卸し（何をどこに保存しているか）
• 重要資産の特定（守るべきサーバー、データの優先順位付け）
• SIEM製品の選定（オンプレ vs クラウド、商用 vs OSS）

Phase 2（構築期間：2〜3ヶ月）

• SIEM環境の構築
• 重要度の高いログソースから順次接続
• 正規化ルールの設定とテスト

Phase 3（試験運用：3〜6ヶ月）

• 検知ルールの初期設定（ベンダー提供のテンプレート利用）
• ベースライン学習期間（正常な通信パターンの把握）
• 誤検知の洗い出しとチューニング

Phase 4（本格運用）

• SOC体制の確立（24時間監視または外部委託）
• インシデント対応プレイブックの整備
• 定期的なルール見直し（月次または四半期ごと）

Phase 5（高度化）

• UEBAの導入（機械学習による異常検知）
• SOARとの連携（自動対応の実装）
• 脅威インテリジェンスフィードの統合

【演習】SIEMの仕組みと活用 理解度チェック（全10問）

科目A-2では、SIEM・正規化・相関分析・UEBA・SOARといった用語の意味が4択で、科目Bでは、インシデント対応の事例の中で、時刻同期の前提や誤検知への対処、ログの保護、どのログを組み合わせれば攻撃が見えるかを説明させる形で問われることが考えられます。定番のひっかけは、「SIEMのアラートが出れば侵入と断定できる」「誤検知が多いなら通知を止めればよい」「UEBAは固定のルールに一致した通信を検知する」といった思い込みです。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：ログは語る、SIEMは翻訳する

セキュリティ対策において「ログ」は、過去の操作や事象をたどる重要な証拠です。しかし、活用されないログは、ただディスク容量を圧迫するだけのデータに過ぎません。

SIEMは、その膨大なデータに「意味」を与え、組織を守るための「行動可能な情報（アクショナブルインテリジェンス）」へと昇華させるシステムです。

攻撃者は常に進化しています。単一の防御層を突破するだけでなく、複数の正規の操作を組み合わせて痕跡を隠蔽します。このような高度な攻撃に対抗するには、点在するログを線でつなぎ、面として捉える「相関分析」の力が不可欠です。

情報処理安全確保支援士試験対策としては、単に用語を暗記するだけでなく、「どのログを組み合わせれば、どのような攻撃が見えるようになるか」というシナリオベースの思考を養うことが、科目Bの突破、ひいては実務での活躍に繋がります。

SIEMは導入すれば終わりではなく、継続的なチューニングと人材育成が必要な「生きたシステム」です。本記事で解説した基礎知識を土台に、実際の製品やサービスに触れ、ログと対話する感覚を身につけてください。

検知の次は、いかに被害を最小限に抑えるかです。インシデント発生後の対応プロセスは「【保存版】サイバー攻撃を受けた時の初動対応：被害を最小限に抑えるインシデントレスポンス4つのフェーズ」で、CSIRT（Computer Security Incident Response Team）とSOCの組織体制・役割分担は「CSIRTとSOCの違いとは？情報処理安全確保支援士試験で問われるセキュリティ組織の役割分担」で解説しています。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• NIST SP 800-92「Guide to Computer Security Log Management」（2006年。改訂版Rev.1『Cybersecurity Log Management Planning Guide』は2023年にドラフト公開）
• PCI Security Standards Council「PCI DSS v4.0.1」（Document Library）
• EU一般データ保護規則（GDPR、Regulation (EU) 2016/679）
• IPA「応用情報技術者試験、高度試験及び情報処理安全確保支援士試験におけるCBT方式での実施について」
• Palo Alto Networks「End-of-Life Summary」