ベンダー任せにしていない？検知システム活用のキホン

SIEMを用いたセキュリティ監視の検討

近年、特定の組織を標的にした標的型サイバー攻撃 （Advanced Persistent Threat （APT）、高度サイバー攻撃とも言う）が増加しており、特定の組織を狙った標的型メールや、侵入の痕跡を巧妙に隠蔽するマルウェアなどにより、攻撃を受けたことの発覚が遅れ、長期にわたって被害を受ける事例が増えている。

標的型サイバー攻撃では、サイバーキルチェーンの複数のステップにわたる攻撃が行われるため、単体のセキュリティデバイスの監視では、攻撃の状況を把握することが難しい。

そこで、単体で不正アクセスを検知してアラートを発報するIntrusion Detection System/Intrusion Prevention System（以下、IDS/IPSと言う）などのセキュリティデバイスから、プロキシサーバや認証サーバのようにログの蓄積を行って分析に活用するシステムまで幅広く、ログの相関関係の分析や、攻撃の予兆や痕跡を可視化するSecurity Information and Event Management（以下、SIEMと言う）の導入が進んでいる。

SIEMでのセキュリティログ分析では、多様なログを分析するためのスキルが必要になることから、自組織で要員を確保できない場合はセキュリティベンダーが提供する監視サービスのManaged Security Service（以下、MSSと言う）を利用する選択肢がある。

MSSを利用する企業は、Security Operation Center（SOC）によるセキュリティログ分析とインシデント発生時の通知を受領することで、インシデント対応体制を補う目的を持っていることが多い。

SIEM利用においては、導入時にその組織を取り巻く脅威を特定し、それをユースケースに落とし込む要件定義のフェーズが必要となるが、委託者とセキュリティベンダー間での検討が不十分となり、運用後に想定よりもアラートが上がらない状況が発生する。

一方で、SIEMを導入した側の、ある企業のセキュリティ担当者から次のような発言を耳にする事が多い。

このようなギャップが生じるのはなぜだろうか。今回のテーマでは、SIEM導入における勘違いとなり得るポイントを紹介し、どのような検討を行うべきか解説する。

SIEMによる脅威の可視化

SIEMでは、次の図1の通り、セキュリティデバイス（IDS/IPS、Sandbox、ファイアウォール（以下、FWと言う））やプロキシサーバ、認証サーバなどのログを収集し、その相関関係の分析や検知ルールに基づいたアラートを確認して、脅威を可視化する。

ログとして何を収集対象とするかは重要な選択であるが、それ以前に収集対象の1次ログソースとして、アラートを発報するセキュリティデバイスの設定が最適化されているかは意外と見落とされがちである。

例えば、IDS/IPSを例に取ると、製品ベンダーにもよるが数千のシグネチャが用意されており、脅威を検知するのに必要な数のシグネチャが有効な設定になっていない場合は、そもそも検査・検知は行われないことになる。そのため、ベンダーが提供するデフォルトのシグネチャ設定のままで、自組織のIT環境にとって必要なシグネチャが無効のままでないかを確認することも重要である。

SIEMでの相関分析以前に、1次ログソースが発報するアラートで、SIEMが脅威を検知するまでのアラートを収集できない場合は、当然脅威を可視化することもできない。1次ログソースの設定の最適化は、SIEMを導入する際に認識すべきポイントである。

図1　SIEMログソースからのアラート・ログ収集

SIEM監視対象デバイスの検討

SIEMで自動的にアラートを出力するためには、事前に検知ルールの設定を行う。検知ルールを導入するまでには、次の図2の通り、Step1～3の段階を経る。

想定脅威の検討、監視ユースケースの定義を実施せず、SIEM検知ルールの作成から行った場合、何を脅威として監視を行っていくかの検討が欠けてしまい、自組織のIT環境にとって、重要でないアラートばかりが発報してしまう場合がある。

図2　SIEM検知ルール導入のステップまた、監視ユースケースに基づいたログソースの選定も重要である。標的型サイバー攻撃を例に取ると、次の図3の通り、各攻撃フェーズと監視ユースケースで、攻撃の痕跡が残るデバイスが異なる。SIEMログ収集対象に攻撃の痕跡が残るデバイスが含まれていない場合、当然SIEM検知ルールでのアラート出力がないため、脅威自体が見えてこない状態となる。結果として、SIEM導入後に想定よりもアラートが発報しない状況が生じる。

図3　標的型サイバー攻撃における主な監視ユースケースとログソース

SIEMと内部不正対策（UBA/UEBA）監視の組合せ検討

SIEMの導入で、各ログソースの監視をリアルタイムに実行出来るが、監視の領域によっては別ソリューションと組合せた方が有効な場合がある。

その例として、内部脅威に分類される内部不正対策のUser Behavior Analytics/ User and Entity Behavior Analytics（以下、UBA/UEBAと言う）が挙げられる。UBA/UEBA は、ユーザとエンティティの行動分析・監視を行い、不正な行動を検知するソリューションである。

SIEMで特定のアクティビティだけを追いかけるような検知ルールを設定することは労力がかかるため、内部不正対策のソリューションと組合せた方が、効率的に監視を行える場合が多い。

次の図4の通り、SIEMは各ログソースからのログの蓄積を「時間軸」で分析していくが、UBA/UEBAはユーザの「一連の行為」の単位で監視が可能である。例えば、Aさんの一連の行為で分析していき、不正な行動が確認された場合、アラートを発報する。SIEMでユーザごとの行動で検知ルールを作成するよりは、UBA/UEBAによる監視と組合せた方が、効率の良い監視が実現できる。

また、SIEM製品によっては、UBAモジュールを追加することが可能なため、内部不正対策の入り口として追加機能を選択肢に入れてもいいだろう。

図4　SIEMとUBA/UEBA監視の分析の差異

SIEM監視・運用フェーズにおけるチューニング

SIEM検知ルールを導入し、セキュリティ監視・運用を開始したフェーズで、次の問題が発生する場合がある。

• 想定していたよりもアラート発生頻度が低い
• 誤検知の発生頻度が高く、頻繁にアラート通知がある

先に挙げた監視のベースとなるログソース自体の設定の最適化や、ログソースの選定が出来ていない場合もあるが、検知ルールの初期チューニングの検討も重要となる。アラートの発生状況により、初期チューニングとして過剰検知ルールの抑止や、検知ルールの閾値の調整を行うことが必要である。

MSSを利用する場合は、セキュリティベンダーの定期報告を基に、次の図5に示す監視・運用フェーズにおけるチューニングのサイクルを実施して、SIEMで発報させるアラートの最適化を継続することがセキュリティレベルの向上につながるだろう。

図5　監視・運用フェーズにおけるチューニングのサイクル

SIEM導入における要件定義と監視・運用

これまでの議論をもとに、SIEM導入後のセキュリティ監視を有効にするためのポイントを次の図6に整理してみた。図を見ていただければ分かる通り、要件定義と監視・運用のレイヤの両方で、十分な検討が必要となることが分かる。

SIEMによる監視の有効性を高めるための全体像として、委託者とセキュリティベンダー間での検討の参考となるだろう。

図6　SIEM導入における要件定義と監視・運用のレイヤ

これまでSIEM導入における検討事項を述べたように、要件定義と監視・運用の各レイヤで、セキュリティベンダーだけではなく委託者も加わり、十分に検討が行われた結果、ある企業のセキュリティ担当者の発言が次に変わっていることを期待したい。

【連載】勘違いセキュリティ（あなたの理解は大丈夫？）シリーズブログ記事はこちら