Level3：ウイルス発見、そのときベンダーの動きは？：いま、ウイルス対策を再考する（1/2 ページ）

ウイルスに代表されるマリシャスコードへの対策においては、早期の解析と定義ファイルの作成、配布が重要になる。あまり知られることのないその舞台裏を紹介しよう。

[星澤裕二，ITmedia]

　新種のウイルスが登場したときには、前回紹介した手順に沿って速やかなアップデートを行うのが望ましいのだが、それもベンダー側の的確な対応があってこそだ。そこで今回は、ウイルスが発見された後、ベンダーはいったいどのような対応を行っているのかを紹介してみたい。

　まず、今年7月に発見されたMydoom.Mを例に、ウイルス発見後のベンダー（シマンテック）の動きを追ってみよう。時系列でまとめると以下のようになる。

日時（米国時間） 対応状況 7/26 05:00 ユーザーからマリシャスコードのサンプルが届けられる 7/26 05:45 エンジニアがウイルスサンプルを解析し、ウイルス定義を作成。ウイルス定義ファイルのビルドを開始するためにソースコードをチェックイン 7/26 06:00 ウイルス定義ファイルのビルドを開始 7/26 07:00 Rapid Release版（追加登録したマリシャスコードを確実に検出／駆除できることのみをテストしたもの）のウイルス定義ファイルをFTPサイトにアップロード 7/26 07:50 DeepSight Alertユーザー向けにウイルスアラートメールを配信 7/26 08:15 Symantec Security ResponseのWebサイトにMydoom.Mに関する情報を掲載 7/26 08:45 ウイルスアラートメール配信 7/26 09:00 Intelligent Updater版（Webサイト、FTPサイトからダウンロードできるウイルス定義ファイル更新プログラム）、LiveUpdate版（インターネット経由で更新）のウイルス定義ファイルの提供を開始 7/26 11:00 届出数増加のため危険度を「3」から「4」に変更 7/26 14:00 無償駆除ツールの提供開始 7/26 19:30 ASPackでリパックされたマイナーな亜種とMydoom.MがドロップするBackdoor.Zincite.Aを検出するLive Update版ウイルス定義ファイルの提供を開始 7/27 02:00 マイナーな亜種に対応した無償駆除ツールの提供開始

　このマリシャスコードへの対応の例を見ても、ベンダーでは、発見後24時間以内にさまざまな対応を行っていることが分かるだろう。

　実はこれ以外にも、状況の変化に応じた細かい作業が発生している。また、このケースではアンチウイルスソフトでの対応が中心になっているが、マリシャスコードの種類によっては、IDS（不正侵入検知システム）のシグネチャ作成やファイアウォールのルールの提供といった作業が発生するケースもある。

マリシャスコード入手は「ユーザー」が頼り

　ところで、セキュリティ対策ベンダーは、マリシャスコード対応の入り口となるマリシャスコードの出現をどのようにして知るのだろう？　実は、9割以上がユーザーからの報告による。残りは、他社やセキュリティコミュニティなどから情報を得るほか、独自のルートで入手することもある。この独自のルートというのは、ベンダーが積極的にマリシャスコードを探すという方法で、インターネットを自動巡回し、怪しいファイルを見つけ出すのだ。

　現在のところ、これら方法ですべてのマリシャスコードを事前に発見できているわけではない。だが、これまでにいくつもの新種を発見し、効果を挙げているのも事実だ。決して、増え続けるマリシャスコードの出現に手をこまねいているわけではない。

　しかし、情報の入手は、ユーザーからの報告が頼りであるのは間違いない。これは現実の社会と同じだ。火事や犯罪の多くは消防隊員や警察官の定期巡回で発見されるのではなく、被害者や現場の近くにいた人達によって報告されるのである。

　ユーザーからの発見報告は通常、製品が備えているレポート機能を使ってインターネット経由で行われる。この機能では、感染ファイルを暗号化し、安全な形で提出するようになっている。こうして提出されたファイルはベンダーの解析センターに直接届き、そこから解析が始まることになる。

一時間では遅すぎる

　では次に、解析センターに届けられたマリシャスコードがどのように処理されていくのかを紹介しよう。ユーザーから提出されたマリシャスコードのサンプルは、まず自動解析システムにかけられる。自動解析システムは次のような処理を行う。

1.サンプルの受付

　サンプルを受け付け、解析を開始したことをメールでユーザーに知らせる（問い合わせ用のトラッキング番号を知らせる）

2.マリシャスコード判定

　マリシャスコードか否かの判定を行う。マリシャスコードではない場合、5の解析結果の通知へ。

2.1.フィルタリング

　OSのファイルやさまざまなアプリケーションプログラムファイルのハッシュ値が登録されたデータベースと、提出されたサンプルファイルのハッシュ値を比較する。もし一致する場合は、クリーンファイルとして処理する。また、最新のウイルス定義ファイルで検出されるかどうかのチェックも行われる（中には、ユーザーが使用している定義ファイルが古いため、最新のウイルスが検出されずに調査依頼をする場合がある）。

2.2.未知ウイルスチェック

　未知ウイルス検出エンジンによりサンプルファイルをチェックする。

3.ウイルス定義ファイルの作成

　自動解析システムによりウイルス定義を自動的に生成する。自動生成できない新たな手法を使ったマリシャスコードの場合は、エンジニアによるマニュアル解析を行う。

4.ウイルス定義ファイルのテスト

　作成されたウイルス定義ファイルによって、マリシャスコードがきちんと検出／駆除できるかどうかをチェックする。過去に誤認したファイルを誤認しないこともチェックされる。また、導入したシステムに影響を与えないことも確認する。

5.解析結果の通知

　提出されたサンプルがマリシャスコードかどうか、またマリシャスコードの場合、対応したウイルス定義ファイルのダウンロード場所はどこかといった情報が通知される。

図1●マリシャスコード（ウイルス）の届出から対処までの流れ

　現在、ユーザーからの調査依頼のうち9割以上は、この自動解析システムで処理されている。逆に言えば、エンジニアの手により解析が行われウイルス定義ファイルが作成されるケースは1割以下ということだ。1割以下といっても、たとえばシマンテックの場合では月に20万件以上の調査依頼を受け付けているので、それでも相当な数であることに変わりはない。

　ここでベンダー全体に求められているのは、マリシャスコードのサンプルを受け付けてからウイルス定義ファイルをユーザーに提供するまでの時間を、もっと短縮しなければならないということだ。というのも、ご存知のとおり、マリシャスコードの感染速度はどんどん速くなっているからだ。

　以前のマリシャスコードには、数日から、早くても数時間かけて感染を広げていく能力しかなかった。しかし今では、数分単位で社内中、いや、世界中に蔓延できるまでに進化している（Slammerなどがその例だ）。現在のように、コードを入手してからユーザーにウイルス定義ファイルを提供するまでに一時間を要しているようでは遅すぎるのだ。

　しかも「一時間」というのは、アンチウイルスベンダーがウイルス定義ファイルを公開するまでの時間である。ユーザーがそれを自分たちのシステムに導入しない限り、実際にマリシャスコードから保護されたことにならない。したがって、ユーザーが保護されるまでに要する時間は、導入作業の分、さらに長くなることになる。

　企業によっては、すべてのマシンにすぐ最新の定義ファイルを導入するのではなく、管理者がテストを行い、動作を確認してから導入するといったケースがある。この場合は、社内システムに接続されている全クライアントに最新のウイルス定義ファイルが行き渡るまで、さらに時間がかかることになる。ウイルスの発見から作業が完了するまでに数時間、場合によっては数日という時間が経過してしまうかもしれない。

　したがって、ウイルス定義ファイルの配布に関するルールと体制について、企業側では十分に検討しておく必要がある。アンチウイルスソフトの管理ツールを用いた一括更新なども検討してもらいたい。

　また、冒頭の表1でも紹介したが、ベンダーの多くでは複数の種類のウイルス定義ファイルを提供しているため、必要に応じてこれらを使い分けるのもいいだろう。たとえば、ゲートウェイ側では1〜2時間おきに更新されるRapid Release版を、その他の端末ではLiveUpdate版をそれぞれ使用するといった具合だ。これにより、重要な部分（あるいはトラフィックが集中する部分）では早期対応を行っておき、残りの部分では検証を優先する、といった柔軟な運用が行える。

手作業による解析の必要性

　ウイルス定義ファイルには、もう1つ根本的な問題がある。あくまでマリシャスコードが発見された後にしか提供されないのだ。

　自動解析システムのブラッシュアップにより、定義ファイル作成までの時間を多少は短縮できるかもしれない。だがこれを、数分とか数秒までに短縮することはできないし、すべてのマリシャスコードを完全にブロックすることもできない。この辺に、アンチウイルスソフトだけでマリシャスコードをブロックすることの限界が見えてくる。