有効な事故対応とは？

　個人情報漏洩、メールの誤送信、ウィルス配布、web改竄、Nimdaなどなど、インターネット上での事業活動の本格化にともなって、さまざまな事故が発生するようになってきた。
　しかし、ほとんどの事故の場合、事故対応は、きわめておそまつであり、多くの問題を含んでい

製品・サービス・業界動向業界動向

2001年10月5日（金） 12時00分

　個人情報漏洩、メールの誤送信、ウィルス配布、web改竄、Nimdaなどなど、インターネット上での事業活動の本格化にともなって、さまざまな事故が発生するようになってきた。
　しかし、ほとんどの事故の場合、事故対応は、きわめておそまつであり、多くの問題を含んでいる。

　著名なセキュリティ情報サイト "Security Focus" に、最近掲載された "How to Design a Useful Incident Response Policy " を拝読すると、日本国内での事故対応の問題点がうきぼりになってくる。

How to Design a Useful Incident Response Policy
http://www.securityfocus.com/cgi-bin/infocus.pl?id=1467

　この記事によると、事故対応の方針のポイントは下記であるという。

・明解であること
・わかりやすいこと
・実行可能であること
・関係部署の協力があること
・動的であること

　これまでに発生したさまざまな事故を考えてみると、いずれのポイントに照らしても問題のあるケースが多いといわざるを得ない。

　企業のセキュリティ活動の多くは、悪いことが起こることを予防するために行われているが、全ての悪いことを予防することは不可能である。例をあげるまでもないが、あえてあげるならば、msn、オリコ、GEjapan、花王、ダウジョーンズなどなど、名だたるIT先端企業、大企業が被害にあっているのである。こうした状況を省みると、どのような企業でも必ず事故はある、被害を受ける、さらにいうならば、その被害が踏み台になって第三者に被害を与える可能性があるといわざるをえない。

　第三者に被害を与えるケースでは下記のようなことが現実に多発している。

・自社のwebにスクリプトを仕込まれて利用者がwebを見ただけで感染する改竄されてしまう

　事例：
　　msn、オリコをはじめとする多数のwebが改竄、感染の踏み台にされる
　　(2001.9.19)
　　https://www.netsecurity.ne.jp/article/9/2842.html
　　Nimda 感染サイト情報(2001.9.23)
　　https://www.netsecurity.ne.jp/article/8/2874.html
　　Nimda感染サイト情報（9/28）(2001.9.28)
　　https://www.netsecurity.ne.jp/article/8/2923.html
　・自社の発行するメールマガジンの誤送信、ウィルス付きメールの送信事例
　　パソナソフトバンク
　　https://www.netsecurity.ne.jp/article/1/2218.html
　　花王リーゼクラブ
　　https://www.netsecurity.ne.jp/article/1/2179.html
　　野村総研
　　https://www.netsecurity.ne.jp/article/1/1985.html
　　株式会社アッカ・ネットワークス（NTTグループのADSLサービス会社）
http://www.acca.ne.jp/information/statement/010330a/
パイオニア株式会社
http://www.pioneer.co.jp/comm/oshirase1.html
　・Nimda、Code Red およびその亜種に感染して、他のサーバを攻撃する。
　　LAN上の共有ファイルを汚染する
　　解説
　　複合的な攻撃、感染機能をもつウィルス　Nimda(2001.9.19)
　　https://www.netsecurity.ne.jp/article/8/2841.html
　　【続報】複合的な攻撃、感染機能をもつウィルス　Nimda(2001.9.19)
　　https://www.netsecurity.ne.jp/article/8/2846.html

　もちろん、こうした不幸な事故が起きない可能性もある。事故が起こるか、起こらないかは、単なる確率の問題である。企業として、その確率とリスクに見合うだけのコストをかけて、事故対応体制を構築する必要があるのである。

　同レポートによると、組織内の情報システムに習熟し、24時間いつでも呼び出しに応じることができるメンバーで構成されたチームが不可欠としている。ベンダーに対しても24時間対応可能であることを要求している。
　このチームは、実際に事故が起きた際には、事故を的確に分類し、緊急度、優先度を割り当て、対処にあたる。

　しかしながら、実際に発生した事故に対する対応を見ている限りでは、このような体制は、国内企業には、全くないようである。そのことが如実にわかるのが、週末の事故対応である。週末に発生した改竄などの事件に対しては、報道がなされているにも関わらず週明けまで放置されることが少なくない。

いかされない教訓　改竄webを放置の大手企業(2001.8.6)
https://www.netsecurity.ne.jp/article/1/2591.html

相次ぐweb改竄　改竄されても放置の大手企業(2001.2.5)
https://www.netsecurity.ne.jp/article/1/1581.html

　さらに、ずさんな企業では、とりあえず目立つ箇所のみ修正し、バックドアを放置したりするなど、場当たり的な対応も少なくない。

　Nimda ウィルスによって顕在化するずさんなサイト管理　利用者から公開質問状を掲載などの抗議が増加(2001.9.23)
https://www.netsecurity.ne.jp/article/8/2873.html

バックドアの利用が拡大　改竄だけ修正してもバックドアによる被害
(2001.9.25)
https://www.netsecurity.ne.jp/article/8/2881.html

　同レポートでは、事故対応の重要な項目として「業務の継続」の問題をあげている。場合によっては、システムを停止させる方がよいこともあり、その場合の停止の基準、再開の基準と決断責任者を明確にしておくことが重要であるとしている。
　過去におきた国内企業の事例でいうと、事故の原因も対処方法も利用者に告知しないまま、そのまま業務を続けた例はもちろんサービスそのものを突然完全にやめてしまうなど基準があいまいというか、基準がないのではないかと思われることも多々見うけられる。

「プライスロト FUCK japanese」事件にみる事後対処の問題点(2001.8.23)
https://www.netsecurity.ne.jp/article/1/2672.html

　事故処理においては、処理の流れが文章による説明とチャートなどによって整理されているとよいと同レポートでは指摘し、簡略化したサンプルを掲載している。

　同レポートでは、最後に、情報システム、インターネットが、事業上重要なプロセスを担っている以上、事故に対する有効な方針が必要であると指摘し、有効な事故対応方針を構成するのは、背景、事故の定義、分類、報告、業務機構、処理の流れなどであるとしている。

　国内企業が、事故対応の体制を確立するには、まだ時間がかかりそうであるが、せめて情報システム投資の数％でも事故対応のために予算化する問題意識を期待したい。

《ScanNetSecurity》