PR

 現在,セキュリティ製品が数多く市場に出ている。ファイアウオールや侵入検知システム(IDS)といった「侵入対策製品」に絞っても,かなりの数である。しかし,これらは実際に使用する“現場”のニーズを満たしているのだろうか。そもそも,ユーザーは何を求めているのだろうか。

 そこで今回のコラムでは,ユーザーの声および最近の業界動向を基に,侵入対策製品に求められる条件について考えてみたい。ユーザー・ニーズを明らかにすることで,侵入対策製品--特に,筆者が専門とする IDS製品--が今後どういった方向に進むのか,進むべきなのかについても想像できるだろう。

ユーザーが要求する5条件

 ユーザーの立場で考えると,侵入対策製品に求める条件は大きく6つあると考えられる。中には,ベンダーの立場からすれば,ビジネスとして実現不可能な条件や,技術的に困難な条件もあるが,そういった制約を考えず,以下列挙してみた。

【安価であること】

 製品を購入する立場からすれば,当然の条件である。製品を提供するベンダーからすれば,永遠のテーマだろう。

 「安価であること」は,侵入対策製品に限らず,すべての製品について言えることである。しかしながら,侵入対策製品については,よりシビアに求められる場合がある。コストに対する効果が見えにくいからだ。

 製品の利用による効果--特に,利益--が予想できる場合には,喜んでお金を支払うだろうが,セキュリティ製品にそれはない。利益を生み出すのではなく,損失を防ぐ製品だからだ。ユーザー--特に,お金を出す経営層--に対して,このメリットを理解してもらうことが困難な場合が多い。そのため,「効果が分からないので,できるだけ安価な製品を」ということになりかねない。

【“絶対”侵入されないこと】

 「侵入されないこと」は,言われるまでもなく満たすべき条件だ。侵入対策製品はそのための製品なのだ。筆者も「“絶対”侵入されないようにしてください」といった要求を何度か受けている。コストをかけて導入する以上,ユーザーの要求としては理解できる。

 しかしながら,サービス・ベンダーの立場から言わせてもらうと,この条件を満たすことは不可能である。セキュリティに限らず,この世に“絶対”はないことを理解してほしい。

 いくらセキュアなホスト環境を構築しても,ネットワークにつなげた瞬間にぜい弱なってしまうと言っても過言ではない。

 また,構築時にセキュアであることを確認しても,その後いつ新たなセキュリティ・ホールが発見されるか分からない。既に存在しているにもかかわらず,セキュリティ・ホール情報が公開されていないために,気がつかない場合もあり得るのだ。

【メンテナンスの手間がいらないこと】

 セキュリティ・ホールは日々発見されている。それに対して,当然パッチなどを適用する必要がある。しかしながら,日々セキュリティ情報を集め,その中から必要なものだけを抽出するというのは,それだけを専門でやっていたとしても非常に骨の折れる作業だ。この作業を無くしたい,あるいは軽減したいというニーズは当然だろう。

【管理の手間が少ないこと】

 現在は,それぞれの機能に対して,それぞれ別製品を購入し,運用管理しなくてはならない。例えば,「監視」に関する製品一つをとっても,「マシンの稼働状況の監視」,「ウイルス/ワーム監視」,「不正アクセス監視」といった複数のカテゴリがあり,すべてを実施するには,それぞれの製品を購入し,それぞれを別々に運用管理しなくてはいけない。ただでさえやるべきことが山のようにある管理者からは,「管理の手間を減らすために,機能を統合してほしい」や「1台のコンソールからすべてを集中管理できる機能がほしい」といった要求が出る。

 実際,筆者も何度か耳にしている。上記の「不正アクセス監視」のカテゴリに該当するIDSを現場に提案すると,「同時に他のことも監視できないのか」とたずねられる。残念ながら,これらを統合した製品はほとんど存在しないのが現状である。

【自動的に対策してくれること】

 IDS をはじめとする,監視型の侵入対策製品に特に求められる条件であろう。IDS について考えると,例えばファイアウオールと比較した場合,IDS は「監視」が役割であることと,インシデントへには人が自ら対応しなくてはならないため,運用の手間がかかる(もちろん,ファイアウオールといえども,日々のログの解析などは不可欠である)。過去のコラム(http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20010625/1/)で述べたように,IDS の価値は運用次第で変わってくる。IDS によって得られた情報を,実際の対策にいかに生かすか---その運用ができていなければ,導入しても価値は低い。現在人手に頼っているこの対策作業の自動化が,強く求められるだろう。

 例えば,攻撃を検知した時点で,

  • アラーム(警告)の内容やリスク・レベルに応じて瞬時にネットワークを遮断する
  • 攻撃元IPアドレスからのアクセスを受け付けない設定に変更する
当然,誤報が無いという前提である。

 また,以下についても自動化を望まれることがある。

  • 実際に被害を受けてしまったら,元の状態に復旧する

 さらに掘り下げると,アラームの確認についても,自動化の余地がある。通常の場合,IDS がアラームを出しても,それをうのみせずに,ファイアウオールのログなどと突き合わせて,本当にアラームの内容が正しいのかどうかを判断する。もちろん,侵入された場合にはログが書き換えられているかもしれないが,ありとあらゆる情報源から確認することが不可欠である。この作業についても,自動化したいという要望があるだろう。

【自動的にチューニングしてくれること】

 侵入対策製品は,利用するサイトの状況に合わせて,ある程度チューニングする必要性がある。特に,IDS においては顕著である。これを自動化してほしいという要望も耳にする。特に,IDS を既に運用していて,日々チューニングに追われている管理者から聞く。

 IDSにおいて“チューニング”というと,不正侵入の検知に使用する「シグネチャ」に対する最適化を意味する。シグネチャとは不正侵入時にトラフィックに現れる特定のパターンにマッチするかどうかを判定するリストのことで,トラフィックを流れるパケットとリストアップされたシグネチャが合致するものがあるかどうかによって,不正侵入を検知する。

 IDSの検出精度を向上させるためには,自サイトのシステム環境ではアラートが発生しないシグネチャを削除したり,シグネチャ自体をカスタマイズする必要性が生じる。これを自動化できれば,IDS管理者の手間は大きく削減できる。

 製品ベンダーが公開する最新のシグネチャを適用することで,新しく発見された侵入手法に対しても可能となる。しかしながら,新しい侵入手法が公開されてから,ベンダーによるシグネチャが更新されるまでの間に,タイムラグが生じることがある。その場合には,CERT Advisoryやその他のセキュリティ情報を基に,最新の侵入手法に対応できるシグネチャを作成する必要が生じる(もちろん,ユーザーがシグネチャをカスタマイズできる製品に限られる)。これらについても,自動化されることが望ましいだろう。

キーワードは「自動化」

 以上,中には「要望」レベルのものも存在するが,ユーザーが侵入対策製品に求める条件を順不同で書き下してみた。まずキーワードとして挙げられるのは「自動化」であろう。特にIDS製品については顕著である。IDS製品を導入するということは,侵入行為を検知し,検知した内容に対して何らかの対策を施すことを目的としている。したがって,運用時には人手による作業が不可欠である。

 ユーザーの要望も分かるが,自動化は IDS 製品自体に求めるものではない。IDSに連携する別の製品あるいはセキュリティ・ベンダーによるサービスに求めることだろう。もちろん,別の製品やサービスを利用しても万全とはいえない。しかし,ユーザーのニーズを少しでも満たす製品やサービスの登場により,IDSの敷居は下がるだろう。実際,ユーザーが求めているのだから。

 また一方では,「統合」というキーワードも隠れているように思う。様々なカテゴリの侵入対策製品があるが,それぞれを別々のコンソールGUIで管理するには,それぞれの使い方やコンセプトなどを理解しなくてはならない。

 すべてを一つのコンソールにすることが必ずしも素晴らしいというわけではない。無理やり一つにすることで,かえって分かりづらくなる可能性もある。しかしながら,それぞれの製品で一つずつという現状では,煩雑であることは確かだ。これを解決する製品あるいはサービスも期待されている。

◇     ◇     ◇     ◇     ◇     ◇

 ファイアウオール製品が登場して以来,「次に来る侵入対策製品は何になるだろうか」と言われてきた。その1つにIDSも名を連ねており,実際に導入数も伸びている。今後さらに使われていくようになるためには,前述のようなユーザー・ニーズに応えていく必要があるだろう。


大木 英史(Eiji Ohki)
株式会社ラック 不正アクセス対策事業本部
ohki@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。