インシデント対応のポイントは「マインド」と「事前の準備」（2/2 ページ）

[高橋睦美，ITmedia]

　緊急対応が終わったあとの復旧手順で、最初に来るのは残存被害がないかどうかの調査だ。ここでありがちなのが「取っておいたバックアップが、本番システム同様に被害を受けていたケース」（西尾氏）。バックアップについてもクリーンな状態かどうかをチェックする必要があるという。

　その上で通常オペレーションへの復帰にとりかかることになる。だが「緊急対応時には、『かくかくしかじかのケースならばシステムを停止してもよい』というルールが定められておらず、システムを止められない場合が多い。同じことが復旧作業においてもいえる」（同氏）。復旧に当たっての責任者や要員の手配はもちろん、どこが費用を持つかといった事柄を含めた復旧体制を整備しておくことが必要という。

　またこのとき、復旧時に行うべき試験項目をあらかじめ準備しておくと、「復旧に要する手間はだいぶ減る」（同氏）。作業担当者が通常業務や経費清算などの雑事に追われることなく復旧作業に専念できるよう、上司側が調整を行ってくれればなおよい、という。

　ここから先は、インシデントの再発防止に向けた取り組みを進めることになる。具体的には原因分析／究明と再発防止策の検討および実施だ。「事故が起きてしまうのは仕方がないとして、次に繰り返さないことが重要」であり、事故から学ぶべきであると西尾氏は言う。

　「何らかの事故が起きた企業ではセキュリティ対策が急に進むものの、半年も経てばうやむやになってしまうケースがとても多い。だが、不幸にしてインシデントが起きたならば、その『チャンス』を逃さず、与えられる予算を有効に使う義務があると思う」（西尾氏）。

　また、インシデントが発生した場合「自分たちだけが被害者であることはまれで、被害者になると同時に加害者になっていることも多い」（西尾氏）。そこでユーザーなどへの対応が必要になる。「インシデント対応状況や再発防止策をお客さんにどう説明するかはとても大事なこと」（同氏）。

　ここで、誠意を持って対応するのはもちろんだが、意外なポイントとなるのは社内の調整だという。「営業担当者が説明に赴き『お詫びに何でもします』などと言ってしまうケースがある。気持ちとしては分かるが、それで無限責任を負うのもやりきれない話」（西尾氏）。とはいえ、営業側の「それではお客さんは納得しない」という意見にも一理ある。営業と法務部など関係する部署の間で相談、調整を行い、どこまで責任を負うのかを慎重に考慮すべきという。

　同時に、JPCERT/CCやIPA、監督官庁といった関係機関への報告やメディア／株主対応など、その他社外への対応も必要だ。「IT業界全体での対応を考えると、外部機関への報告も重要だ」と西尾氏。

ケーススタディから伝わる教訓

　西尾氏はこうした一連の手順を説明した上で、過去に発生した事件を参考に、インシデント対応のケーススタディも紹介した。

　事例の1つは、IT担当者の操作ミスで顧客のシステムに不正アクセスを仕掛けてしまい、そのことを指摘されたというケースだ。

　このケースではクレームを受けた後、プロキシサーバのログを元に即座に攻撃元を特定するとともに、翌日には社長を責任者とするプロジェクトを発足させ、原因が「セキュリティツールの操作ミス」であることを突き止めた。そして3日後には早くも、セキュリティツールを使用すべきネットワークを通常ネットワークとは分離させるといった再発防止策を講じ、社長の減給、担当者および上司に対する訓告処分を行ったほか、先方へ訪問しての謝罪も行ったという。

　このケースは、被害者が得意先であったという事情はあるが、迅速に、しかも社長自ら陣頭に立って対応したという点で参考になる。ただし、第一報が入ったのはWebサーバの管理用メールアドレスであったという点には改善の余地がありそうだ。この事例ではたまたま管理者がそのメールを読み、対応したからいいものの、常にそうであるとは限らない。「通報を受ける窓口を設置し、確実に対応を取れるようにすることが望ましい」と西尾氏は述べた。

　どちらかというと「まずい」対応に分類されるのは、管理を委託されていたWebサーバの脆弱性を、第三者から指摘された某社のケースだ。このケースでは、指摘直後に暫定的な対処は行ったものの、根本的に問題を解決する前に、委託元と委託先のどちらがプログラムの改修費用を負担するかで2週間ももめてしまった。そのうえ要員の手配がつかず、修正が完了するまでにさらに4週間を要したという。

　このケースからは「復旧にはスピード感と優先順位付けが大切」「脆弱性が発見された場合（今後は個人情報が漏洩してしまった場合も加わるだろう）の対応費用について、あらかじめ取引先と合意しておくことが重要」という教訓が得られる。また、脆弱性を通報してくれた第三者には、迅速に、誠意を示して対応することが重要とも言う。

　逆に参考になるケースとしては、管理を委託されているチケット販売用Webページが改ざんされてしまった、という例がある。このケースでは、あらかじめ対応手順を定めていたこともあり、当日のうちに説明とお詫びを掲載するとともに、電話による代替サービスへ切り替えを行った。さらに3日後には、「サーバ停止」による被害額を算出し、それに基づいて必要と見られる復旧／改善計画を提案した。

　「このケースですばらしいのは、きちんと根拠となる金額を示して『抜本的な対策としてこうしたほうがいい』と提案したこと」（西尾氏）。これにより委託側も、その投資が見合うかどうかを客観的に判断し、対応を進めることができた。

　残念ながらこうしたインシデント対応事例が表には出てくることは少ない。だがそこから得られることは多く、「情報を共有することで業界全体での対応が進むことを期待したい」と西尾氏は述べている。