セキュリティ情報マネジメント概論[中編]

セキュリティ情報マネジメントの仕組みを
技術的に理解する(1)

二木 真明
住商情報システム株式会社
セキュリティソリューション事業部
事業部長補佐(技術担当)
CISSP
2005/9/6

 イベントフォーマットの標準化に一工夫あり

 ひとことで共通フォーマットといっても、SIMが扱う機器の多様性を考えると簡単ではない。一般のセキュリティ機器や製品、例えばファイアウォール、IDS/IPS、ウイルス対策製品、認証サーバなどだけを見ても、発生するログやアラームに含まれる項目は数十種類に上る。OSとその周辺プログラム、各種のサーバ用ソフトウェアなどを加えると、おそらくその種類は100に届くだろう。

 しかし、SIMがあらゆる機器からのイベントを分け隔てなく取り扱い、さらに異なる機器からのイベントに含まれる特定の項目値、例えばIPアドレスなどを比較してイベントを関連付けていくという処理を行うことを考えれば、共通化されたイベントフォーマットには利用する可能性がある項目をできるだけ多く格納できなければならない。さらに、特徴的な機能を持つ製品の優位性を殺さないために、その製品独特の項目をSIMに取り込まなければいけない場合もある。

 これらの要件に単純に対応してしまうと、共通フォーマットに変換された1個のイベントのサイズは数倍から数十倍に膨らんでしまう。これではSIMのデータベースはすぐにあふれてしまう。汎用性を保ちながらイベントデータのサイズをできるだけ小さくするためにSIMの設計にはさまざまな工夫が必要だ。

 一般的には、カテゴライズした特定の製品群に共通のイベントフォーマットを標準化し、製品カテゴリごとの書式で保存する方法や、データベースの可変長フィールドを使って容量を圧縮する方法などが採られている。それでも機器のログをそのまま保存した場合に比べて、容量が多少なりとも増加してしまうのはやむを得ないところだ。これをどの程度に抑えられるかが、SIMメーカーの技量ともいえる。

 イベントフォーマットの標準化には、もう1つ大きな問題がある。項目は標準化できても、各機器がその項目に格納する内容そのものが大きく異なる場合があることだ。例えば、IDSが発するアラームは、その製品が持つシグネチャの名前を含んでいる。同一の脆弱性への攻撃であっても、IDSメーカーによってそれを検出するシグネチャの名前はさまざまだ。

 攻撃の深刻さを示す指標も、製品によって3段階から5段階程度の分類方法の違いがある。異なる種類のIDSを同時監視し、イベントを関連付けて何かを見つけ出したいとき、これは大きな障害となる。例えば、独立した事業部門を集中監視する大企業の監視センターや監視サービス業者が、SIMを利用して特定の攻撃やウイルスの流行などの広範なインシデントや傾向を発見したい場合がある。

 イベントの深刻さについては、収集エージェントが個々のログやアラームが持つ値をSIM自身が持つ評価尺度(5段階から10段階程度)に共通の基準で変換すればよい。しかし、脆弱性の種類の統一は、例えばCVEやBugtraq IDといった共通ID値をイベントが含んでいればそれらを利用できるが、そうでない場合は困難だ。

 あるSIMでは、収集エージェントが製品固有のアラームに対して独自の抽象的なカテゴリに分類した情報を付加してイベントの関連付けに利用する試みが行われている。こうしたチャレンジはSIMがより汎用的な監視・管理インフラとして進化していくためには不可欠だろう。

 イベントマネージャの役割と機能

 収集エージェントによって収集された情報(イベント)は、共通フォーマットの形でイベントマネージャに集められる。集められたイベントは、データベースにそのまま格納されると同時に、イベントマネージャ上に一定時間保持されてさまざまな処理に利用される。SIMの最も大きな機能の1つである複数イベントの関連付け(Correlation:相関分析とも訳される)もここで行われる。リアルタイムなイベントの関連付けは、あらかじめ定められた規則(ルール)による。

 あるインシデントが発生する際は、そのプロセスに固有のいくつかのイベントが連続して、もしくは同時に発生することが多い。例えば、インターネットに公開しているサーバが外部から攻撃を受けて侵入される過程では、(1)ポートスキャンの実行と脆弱性の発見、(2)脆弱性への攻撃、(3)侵入とツールなどの導入による足場固め、といったステップが実行されることが多い。

 これをSIM側から見ると、(1)ファイアウォールで同一の発信元から当該サーバあてもしくは周辺のIPアドレスあての複数の通信記録(多くはポリシー違反による通過拒否ログ)が発生する。(2)DMZ上のIDSがアラームを発生する。(3)攻撃されたサーバから正常通信ログが発生、もしくはまったくログを発生しない。(4)当該サーバから外部へHTTP、FTPなどの通信が発生、という一連のイベントとなることが想像できる。逆にいえば、SIM側で想像する一連のイベントが発生したならば、そのサーバは危機的な状況に陥っている可能性が極めて高いといえる。

 もし、SIMを使用していない場合、ユーザーは(2)のIDSからのアラームを頼りにするほかない。しかし、一般にIDSは攻撃が成功したかどうかまでは検知できないうえ、時折、誤検知によるアラームを発生させる。つまり、本当に攻撃が成功したかどうかを確認するために、ユーザーはそのサーバを念入りに調査しなくてはならず、多くの場合それは(幸いにもというべきか)徒労に終わってしまう。

 このように、一連の事象を検知するルールを設定したSIMを使用することで、本当に深刻な事態のみを警告することができる。これは、監視センターのインシデント対応チームにとっては朗報である。

 IDSの誤検知もしくは無効な攻撃検知を排除するために、いくつかのSIMは脆弱性検査ツールによってあらかじめ検査した内容を基に、CVEなどのコードを使って脆弱性がある対象への有効と思われる攻撃のみを抽出する機能を持っている。こうした機能は、SIMばかりではなく、最近ではIDS自体に実装されているケースも多いのだが、そうでないIDSを使用している場合には役立つ。

 もう1つ、関連付けルールの簡単な利用法を紹介しておこう。最近、ウイルス対策ソフトウェアが新種のウイルスを見落とすケースが多くなっている。これは、ウイルスの変化が速すぎて、対策ソフトメーカーの対応速度が限界に達していることが主な原因だが、SIMを使ってウイルス感染の発生を発見することも可能だ。

 メール大量送信型のウイルスは、感染したPCから大量のメールを直接インターネットに向けて送信する。いまでは多くの組織が、こうしたPCから直接の(自社メールサーバを経由しない)メール送信をファイアウォールで規制している。

 この規制の有無にかかわらず、ファイアウォールのログから特定のPCが大量のメールを送信した(しようとした)事実をSIMは把握できる。例えば、1分以内という短時間に、あるしきい値を超える数のメールを直接送信しようとしたPCを検出するルールは、かなり高い確率でウイルスに感染したPCを見つけ出すことができる。「メタ(meta)IDS」。SIMのことをそう呼ぶ人がいるのは、こうしたことが可能であるからだ。

2/4


Index
セキュリティ情報マネジメントの仕組みを技術的に理解する(1)
  Page1
SIMのコンポーネント
収集エージェントはなぜ必要か
Page2
イベントフォーマットの標準化に一工夫あり
イベントマネージャの役割と機能
  Page3
関連付けルールの処理の流れ
メタイベントとアクション処理
  Page4
アノーマリ検知とモニタオブジェクト

セキュリティ情報マネジメント概論
  SIMで企業のセキュリティを統合管理せよ
  セキュリティ情報マネジメントの仕組みを技術的に理解する(1)
  セキュリティ情報マネジメントの仕組みを技術的に理解する(2)

SIMを上手に使いこなす
  業務中にSkypeやIMを使っているのは誰だ?
  不審な通信や無許可ホストを見逃さない

Security&Trust記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間