前回のコラムでは，IDS（Intrusion Detection System：不正侵入検知システム）の概要について説明した。今回は，IDSの弱点や，IDSを運用する際のポイントについて解説する。IDSはネットワークを守るシステムではなく，あくまでも監視するだけである。不正侵入に実際に対応するのは主に“人”であり，運用していくのも“人”である。そのことを十分認識して利用しないと，効果は望めない。
IDSの弱点
（1）多くのコンピュータ・リソースを必要とする
IDSの運用には，予想以上にコンピュータ・リソース（CPUパワーやメモリーなど）を必要とする。そのため，IDSを導入するマシンのパワーは，十分に考慮しなければならない。
ネットワーク上を流れるパケットを逐一監視するには，多くのCPUパワーを必要とする。また，ネットワーク型のIDS（NIDS）では，TCPコネクションやARPテーブル，IPフラグメント化などの情報をメモリー上に一定時間保持しなければならない。そのために，十分なメモリーが必要だ。さらに，監視対象のシステムや，IDS自身の監視モジュールからは大量のログが出力される。それらを保存しておくための，大容量の記憶媒体が必要である。これらのリソースが不十分だと，DoS（Denial of Service：サービス不能）攻撃により，IDSが無効化する恐れがある。
（2）シグニチャ更新に時間がかかる
一般に，新たな攻撃手法が出現した場合，それに対応するシグニチャがリリースされるまでには数日かかる。従って，この間は，IDSでこの攻撃を検知することは難しい。
実際には，シグニチャに頼らず，攻撃対象となるソフトウエアなどのパッチを迅速に適用するなどの，別の対策をとらなければならない。
（3）誤報がある
IDSには誤報がある。特に，検出精度を上げようとすると，検出に誤報が含まれる可能性は高くなる。「異常検出」よりも，検出精度の高い「シグニチャ検出」であっても，ある程度の誤報は避けられない。このことは，実際にIDSを導入にして監視を運用する際には，大きな問題となる（詳しくは後述する）。
（4）パケットを取りこぼす
現在のNIDSの処理スピードは，製品によって違いはあるものの，せいぜい数万パケット/秒（1パケット＝200バイト）程度である。そのため，広帯域のネットワークでは，処理が追いつかない恐れがある。
ある製品のテストによると，100Mビット/秒の帯域の使用率が約70％を超えると，パケットを取りこぼしたり，処理しきれなくなる可能性があるという。今後，ギガビット・イーサーネットなどの広帯域ネットワークが導入されることを考えると，この問題はさらに深刻になることが予想される。
現状での対策としては，マルチレイヤ・スイッチなどで，IPアドレスやサービス・プロトコルごとにトラフィックを振り分け，そこに複数のNIDSを接続し，分散させて監視する方法などが考えられる。
（5）SPOOFINGに対処できない
NIDSは，IPヘッダーの偽造によるSPOOFING（なりすまし）には対処できない。つまり，キャプチャしたIPヘッダーの情報が，正しい情報なのか，それとも偽造されたものなのかを判断することができない。この点については，ファイアウオールも同様である。SPOOFINGを防ぐには，アンチ・スプーフィング機能のある機器や，ユーザー認証を行うシステムなど，IDSとは別のシステムが必要である。
運用上のポイント
IDSを用いて，実際にネットワーク・システムを監視し，侵入時に対応する体制を整える場合，現実にはいくつかの課題に直面する。一番の課題は，“人間の対応”である。IDSは不正侵入を検出して，通知するだけである。ファイアウオールなどと連携させれば，多少の対応は自動で行えるものの，通知を受けて実際に対応するのは，多くの場合は人間である。この“人間の対応”を，いかに適切にできるようにするかがポイントである。
（1）緊急対応のスキームを決めておく
侵入事実を確認したら，まず緊急対応をすることが重要である。原因追求は後回しだ。そのためには，「×××の警告が通知されたら，インターネットとの接続を切断する」などといった，具体的な対応のスキームをあらかじめ決めておく必要がある。
緊急対応が終わったら，もちろん原因を追求する必要がある。そこで，次のような2つのグループに分けて，IDSを運用するとよいだろう。
[a] 常時監視を行うグループ
IDSからの通知を受け，侵入事実の確認を行い，確認できた場合には緊急対応を行うグループ。決められたスキームを行うだけなので，それほどスキルを必要としない。
[b] スーパーバイザーのグループ
緊急対応後に，不正侵入の原因調査，復旧に向けての対応を行うグループ。ある程度のスキルを必要とする。
（2）できるだけ誤報を減らす
誤報が相次ぐと，担当者はIDSの警告に慣れてしまい，“本当の”不正侵入を見過ごしてしまう恐れがある。このようになってしまったら，せっかく導入したシステムも“無用の長物”だ。それを防ぐために，IDSでは確実な警告だけをするようにしたい。「IDSの弱点」のところで述べたように，ある程度の誤報は避けられない。しかし，次に挙げるようなポリシー設定をすれば，極力減らすことはできる。
[a] シグネチャを使わない
シグネチャを使った検出は，基本的には採用しない。シグネチャ検出では，警告が通知されても，それが不正侵入によるものかどうかの判断が難しく，あいまいな対応しか取れない場合が多い。そのため，異常検出による警告だけを採用する。
[b] OSシステム・コールだけを監視する
ホスト型IDSの場合には，実際に「LOGIN/LOGOUT」や，ファイルの変更などが発生した場合にだけ，警告を出すように設定する。
[c] 異常なコネクションだけを監視する
ネットワーク型IDSの場合には，通常の運用では発生しえないコネクションを監視するようにする。
（3）人の判断が入らない連絡系統にする
担当者の“勝手な”判断が，適切な連絡や対応を遅らせる可能性がある。例えば，ある担当者がIDSからの警告をまず受けて，その担当者が重要だと思ったら，実際に緊急対応する担当者へ伝えるような連絡系統を作ったとする。この場合，最初の担当者の判断ミスで，対応が遅れる可能性がある。そのようなことがないように，担当者全員へIDSからの通知が直接届くようにするなどして，なるべく主観的な判断が間に入らない，連絡系統や指示系統を作っておく必要がある。
IDSはまだ発展途上の技術である。そして，ネットワークを守るものではなく，監視するだけのシステムである。万能ではない。OSやサーバーなどのセキュリティ維持を怠っていては，たとえIDSを導入しても，効果がないことを忘れてはいけない。
斎藤松彦（SAITO Matsuhiko）
株式会社ラック 不正アクセス対策事業本部
m_saitoh@lac.co.jp
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。
