Level3:ウイルス発見、そのときベンダーの動きは?いま、ウイルス対策を再考する(2/2 ページ)

» 2004年10月04日 19時30分 公開
[星澤裕二,ITmedia]
前のページへ 1|2       

 マリシャスコードの解析とウイルス定義ファイルの作成のすべてを自動化することができない現状では、エンジニアのマニュアル解析技術が必要になる。

 マリシャスコードの解析には、「ブラックボックス」と「ホワイトボックス」という二つの方法がある。エンジニアは二つの解析方法をうまく組み合わせて解析を行っている。エンジニアによるウイルス解析の際には、ウイルス定義ファイルの作成だけでなく、マリシャスコードがどのように振る舞い、どのような対策が有効で、万が一感染してしまった場合にはどういった対処方法があるのかといったことまで調査しなければならない。

図2 図2●ブラックボックス方式とホワイトボックス方式の違い

 ブラックボックスは、実際にマリシャスコードを実行して、その動きをチェックする手法だ。そのコードがどんなファイルにアクセスするのか、レジストリに書き込みが行われたか、ポートがオープンされたかといった事柄をチェックする。ブラックボックス手法では、短時間のうちにそのウイルスがどんなことをするのかを調べることができる。

 しかし、ブラックボックスのやり方には問題点がある。マリシャスコードによっては、リアルなインターネット環境や特定の条件を満たしていなければ感染を広げないものもある。こういったケースでは、ブラックボックスによる解析がうまく行えない。

 そこで、もう1つのホワイトボックスという解析方法が必要になる。ホワイトボックスとは、マリシャスコードをリバースエンジニアリングし、その内容を解析する手法だ。時間はかかるが、マリシャスコードの一行一行をチェックし、それが何をするかを確実に知ることができる。

 アンチウイルスベンダーは、マリシャスコードの発見からウイルス定義ファイル作成までの時間を短縮するため、さまざまな努力を重ねてきている。たとえば、エンジニアの数を増やすだけでなく、迅速にウイルス定義ファイルを作成するための解析ツールを開発したり、自動解析ツールを強化したりといったことが、ユーザーには見えない裏側で日々行われているのだ。新たなタイプのマリシャスコードを効率よく見つけるため、スキャンエンジンの追加、改善も行われている。

 とはいえウイルス作者側も、そのウラをかこうと工夫を凝らしてきており、一種のいたちごっこ状態だ。マリシャスコードに少しでも速く対応するための挑戦は、これから先もずっと続けられていくだろう。

名称をめぐるあれこれ

 解析手法とは関係ないが、ウイルス名について疑問や不満を持っている人とが多いので、ここで少し触れておく。

 ベンダーによってウイルス名が微妙に違うという事実には、すでに多くの人が気付いているだろう。このことはかなり前から問題視されている。自分が使っているアンチウイルスソフトが警告するウイルスと、他のベンダーが出している警告とは同一のものなのかどうか、という問い合わせもよくある。

 たしかにこれは問題だ。

 ウイルスの名称は、基本的には、上記の手法でウイルス解析を行ったエンジニアが命名している。各社にそれぞれウイルス解析エンジニアがいるため、ベンダーごとに名前が異なっていてもおかしくない話だが、元のコードが共通な上、他社との情報交換によって、おおむね似たような名称になっているわけだ。

 ユーザーから届けられたサンプルがマリシャスコードかどうかは解析エンジニアが判断するのだが、それはアンチウイルスベンダーが独自に定めたルールに従って行われる。各アンチウイルスベンダーは自社なりのマリシャスコードの定義を持っていて、この定義により、どういったものを検出して、どういったものは検出しないのかが明確に線引きされている。

 これは業界標準の定義ではなく、あくまで各ベンダーが独自に決めているものだ。つまり、極端な例では、あるアンチウイルスベンダーが「これはウイルスである」と判断したものが、他のアンチウイルスベンダーでは対象外とする場合もある。

 実際にはウイルスやワームの場合こういったケースは少ないのに対し、トロイの木馬やスパイウェアなどでは、こういったズレが比較的多いようだ。また、ルールの相違というよりもエンジニアのスキル不足により、判断を誤ってしまうケースもたまにはあるようだ。

 ウイルスやワームの場合は、他のファイルに感染したり、他のコンピュータに複製を作るので判断を誤ることは稀だ。しかしトロイの木馬などの場合、その判断は難しい。バックドア型トロイの木馬とリモート管理ツールが持っている機能はほぼ同じだが、前者はマリシャスコードであり、後者は正常なソフトウェアである、というのがその例だ。

 マリシャスコードの新種/亜種の判定にも同じようなことが言える。それが亜種かどうかの判定には、エンジニアの経験がものをいう。過去のマリシャスコードに似たようなものが存在していたかどうかを知っている必要があるからだ。

図3 図3●同じマリシャスコードでもA社、B社、C社によって解釈が違う

 こう考えていくとむしろ、共通の名前にする方が難しく、各ベンダーが勝手に名前を付ける方が楽である。また、亜種などもいちいち判定するのではなく、すべて新種として登録したほうが、ベンダーにとって楽なのは間違いない。もっと極端なことを言えば、検出・駆除ができるのであれば、ウイルスに名前など付けない方が楽である。しかし、それではユーザーは納得しないだろう。

 ユーザーにとっては混乱の種かもしれないが、別の面から見ればこの現象は、ベンダー間での名称の統一よりも解析/定義ファイル作成を優先し、処理している結果ともいえる。なかなか「これ」という解決策はなく、不便ではあるのだが、別記事でも紹介した複数ベンダーの製品の使い分けによって、少なくともマリシャスコードがすり抜ける可能性を抑えることができるだろう。

プロアクティブな対策が必要に

 最近のマリシャスコードは、アンチウイルスソフトだけでは防ぐことができないものが多くなってきている。ファイアウォールやIDSを併用し、組織としての対応体制を整備し、ユーザーの注意力を高めておかなければ防げない。

 そう考えると、ウイルス解析エンジニアに求められる役割はますます大きくなってきている。たとえば技術的な面で言えば、エンジニアは、ウイルス定義ファイルを作成するだけでなく、IDSのシグネチャも書けなければならない。

 しかし、いくらエンジニアが優秀でも、ウイルスが発見される前にそれを検出するウイルス定義ファイルを作ることはできない。つまり、ウイルスが出現し、どこかで被害を及ぼさない限り、対応を始めることはできず、その間に被害が広まってしまうのだ。こればかりは、現行のウイルス対策ソフトウェアの限界だといえるだろう。

 特に、最近のワームは感染速度が恐ろしく速い。発見されてから対応したのでは遅すぎるのだ。アンチウイルスソフトの存在を否定するわけではないが、それに頼りすぎるのは良くない。

 アンチウイルスソフトに加え、他のセキュリティ対策が必要である。今求められるのは、ファイアウォールやIDSのようなリアクティブな対策だけでなく、プロアクティブな対策だ。マリシャスコードが広がる前の兆候を見逃さずに対処しなければならない。脆弱性情報を収集したり、インターネット定点観測を利用したりすることにより、次に何が起ころうとしているのか知り、あらかじめ不要なサービスを止めておいたり、ユーザーに注意を促すといった対策が必要なのだ。

前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ