この特集では，筆者が法人顧客のサポート・エンジニアとして経験した数多くの実例の中から，企業ネットワークで実際に発生したある事例について，時系列に従い，その時々でシステム管理者とセキュリティ・ベンダーのサポート・チームが試行錯誤で行った現場の対処を紹介する。
第4回は，駆除の失敗からオンサイト作業の終了までをつづる。1度目の駆除に失敗した状況から失敗の原因を調査し，それに対処して2度目の駆除作業を成功に導いた。これに伴い，インシデントの現場で発生する机上では考えにくい事象を紹介するとともに，駆除失敗時にありがちな原因とそれに陥らないための復旧作業のコツについて解説する。
|
午前7時。私はA社のシステム担当者のM氏とともに，駆除に失敗しているコンピュータに急行した。 「これらのコンピュータで駆除が失敗しているようです」 「ひとまず手分けして原因を探ってみましょう」 A社の管理者数人と私で，1台ずつコンピュータを調べてみる。数分で，あるスタッフが声を上げた。 「このコンピュータにはプロキシの設定がありません。直接インターネットに接続しています」 これを聞いて，すぐさま他のスタッフもブラウザの設定を確認する。 「ということは，URLのブロックが効いていなかったってことか」 M氏に再び焦燥の色が走る。今度はまた別のスタッフから報告が上がる。 「こちらのコンピュータにはウイルス対策ソフトが入っていないようですが……」 「なぜウイルス対策ソフトが入っていないコンピュータがあるんだ！」 M氏が声を荒げる。 「どうも部署の予算で勝手に購入していたコンピュータのようです。この分だと他の部署にも，情報システム部で管理していないコンピュータがあるかもしれません」 「URLブロックが効いていなかったコンピュータには，未知の不正プログラムが存在していると思われます。すぐにコンピュータ内を再調査して，検体をもう一度採取します」 私は再び検体採取の調査に入った。 |
現場で起こる信じられない現実
今回の事例で駆除に失敗したコンピュータは，A社に設置されたプロキシ・サーバー経由以外でインターネットにアクセスできる端末であった。修復作業を行っているかたわらで，新たな不正プログラムを次々とダウンロードしていたのである。
このような現実は何もA社に限ったことではなく，多くの企業において発生しうる事象である。筆者も，サポートの現場で幾度となく目にしている。業種や業態にもよるが，企業ネットワークにおいてWebアクセスを完全にコントロールできない環境が生じてしまうことは理解できる。ただ，このような環境がプロキシ・サーバー上で不正なURLをブロックしたにもかかわらず，新たな不正プログラムを次々とダウンロードしてしまう事態を招き，結果的に感染台数の拡大や復旧作業の長期化につながっていくのである。
さらにウイルス対策ソフトが適切にインストールされていないコンピュータも，このようなセキュリティ・インシデント下においては復旧作業の長期化を助長することも付け加えておきたい。
インシデント発生後の処理において，このようなコンピュータの存在を無くしていく努力をしない限り，同様のセキュリティ・インシデントが短期間のうちに再発する危険があるのもまた事実である。
|
午前9時。予想通り，駆除に失敗したコンピュータから新たに複数の不審なファイルが採取された。これを再びトレンドマイクロの解析エンジニアに送信する。 「ひとまず解析の結果を待ちましょう。その間に，駆除できなかったコンピュータについて復旧の優先度を決めていただけませんか」 責任者のM氏を中心に，A社のスタッフで議論が始まった。 「まず現在の状況を説明します。最初の復旧処理で失敗したコンピュータは，プロキシ経由外でインターネットに接続していました。これらのコンピュータはネットワーク・カードを2枚備え，一方をLANに，もう一方を直接インターネットに接続している状態です。そのため，初期対応のプロキシによるURLブロックが効かず，復旧作業の間にも新しい不正プログラムがダウンロードされ，再びLAN内で再感染が起こっている可能性があります」 「加えて，ウイルス対策ソフトが導入されていないコンピュータは，当然ながら先の復旧処理がなされていないため，今もウイルスに感染したままだと考えられます」 「これら例外的な使用をしている管理外のコンピュータは，復旧の優先度を下げて構わないんじゃないか」 「今は，ストップしている通常業務を少しでも早く再開できるようにすることが最優先だ。管理外コンピュータを使用しなくても，数日であれば業務に大きな支障はないだろう」 「じゃあ，再感染のリスクがあるそれらのコンピュータは，オフラインにしておいた方がよいね。一度LANから切り離して，すべてがオフラインになったのを確認してから，情報システム部がサポートしているコンピュータだけを対象に2度目の駆除処理を行おう」 「オフラインにしたコンピュータの復旧はどうしましょうか」 「とりあえず標準のコンピュータを一気に復旧した後で，ひとつずつマニュアルで作業していくのが安全じゃないかな」 「よし。では基本方針として，情報システム部サポートの標準コンピュータだけを対象に復旧し，ネットワークの回復を優先しよう。そのために，管理外コンピュータをまず完全にオフラインにする。管理外コンピュータの復旧は人海戦術になるので，手の空いた者から並行して進めることにする」 M氏が作業の方針をまとめた。 |
通常業務の再開を最優先に，復旧が難しいものは後回しと割り切る
ここで復旧の優先度についてもう一度，解説しておきたい。
今回のように，調査や復旧の作業途中で状況が変わり，当初の計画を修正せざるを得なくなるケースは珍しくない。優先順位を付けることが復旧作業の効率化にとって最重要といえども，ルールだけで完全に割り切れるものではなく，ケースバイケースの対応が求められる。
A社では，情報システム部門が把握していないコンピュータが，A社のセキュリティ・ポリシーにのっとって使用されていなかったことが原因で駆除失敗を招いた。ただ，システム担当者のM氏が情報システム部門でオフィシャルに管理している端末と管理外端末で，優先度に差をつけたのは英断であった。
感染したコンピュータの完全復旧と，安全な状態での通常業務の再開を両立することは，現実的には困難なケースが多く，ジレンマに陥りがちなポイントである。今回のA社のように，ある意味で割り切ることが肝要だと考える。完全に安全が確保できたコンピュータのみで業務を再開し，少しでも危険性が残るコンピュータはオフラインで処理する。大規模な感染にもかかわらず，A社がこの方針を採ったおかげで比較的短時間に業務を再開できたという事実は，読者の皆さまが直面するかもしれない緊急事態で役に立つだろう。
|
午後1時。ウイルス解析エンジニアによる解析結果から，新たに採取したファイルの中で10種のファイルが新しい不正プログラムであると判明した。これらに対応したパターンファイルと駆除ツールも作成され，駆除作業の準備は整った。駆除に失敗したコンピュータから再感染した可能性があるため，全コンピュータを改めてクリーンアップする必要がある。管理外コンピュータはネットワーク・ケーブルを外し，マニュアルによる復旧作業を並行して行う。 「これで，大部分のコンピュータが復旧するはずです」 A社の担当者が，ウイルスバスターコーポレートエディションの管理サーバーから新しいパターンファイルと駆除ツールを一斉に配信し始めた。100台近くのコンピュータから駆除成功，削除成功のログが次々と送信されてくる。今回は駆除失敗のログは記録されていない。 「今度こそ，やりましたね」 「駆除成功」の文字が続々と並ぶ管理サーバーのコンソールを前に，M氏と私は固い握手を交わした。 |
