相次ぐトラブル　事後対応の雛型マニュアルの必要性

>> バラバラで、場当たりの事後対応

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

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

>> バラバラで、場当たりの事後対応

　感染力の強いウィルスの拡大とともに、商用サイトでも顧客や関係者にウィルスメールを配信してしまう事故が続いている。
　事故がおきること自体問題だが、さらにその後の問題の対応にも問題がでて
いるように思われる。対処方法とお詫び、事故の経緯の報告などを迅速に被害を与える可能性のあったところに連絡するなどの一連の処理が不可欠であろう。

　当然ながら、突然、事故がおきてからやろうと思っても、迅速な対処などできない方が当たり前だろう。
　ネット上で商用サービス、パブリックなサービスを行うサイトは、インシデントが発生した際の対処方法をあらかじめ準備しておくことが必要である。

　すでに、弊誌では、事後対応の有効な方法論について、紹介をしているが、最近の状況を見ていると、事故を起こしても平気で黙っているサイトも少なくなく、あいかわらず事後対応を軽視するように感じられる。というか、とりあえずメールでお詫びを送って、あとはなにも事後対応しないというサイトの少なくないのではないだろうか？

有効な事故対応とは？(2001.10.5)
https://www.netsecurity.ne.jp/article/1/2971.html

>> お詫びの掲載すらないサイトもある

　つい最近も下記のようなウィルス配信事件がおき、クレームによりやっとお詫びが掲載されたことがあった。

ラジオ局のJ-WAVEが、リスナーにウイルスメールを送信(2001.12.4)
https://www.netsecurity.ne.jp/article/1/3448.html

　また、個人情報を漏洩する危険のあった島さとし事務所や国内線ドットコムには、いまだにお詫びの掲載はない。

島さとし議員のWebサイト、ディレクトリのパーミッションを設定ミス
(2001.12.5)
https://www.netsecurity.ne.jp/article/1/3456.html

国内線ドットコムで個人の実名がわかるセキュリティホール
(2001.11.28)
https://www.netsecurity.ne.jp/article/1/3392.html

>> プレーンテキストでもハングアップ　事故の100％予防は不可能

　事故がおきないように、予防措置を徹底することは重要であるが、全ての事故を防ぐことは不可能である。
　例えば、メーリングリストやメールマガジンでは、添付ファイルの送信不能な設定にしておけば、ウィルスメールの送信などの事故は起こらないと考えている管理者もいる。しかし、プレーンテキストであってもウィルスもしくは破壊的な行為を行うメールを送信することは可能である。

セキュリティホール情報＜2001/11/27＞(2001.11.27)
IEに　特定の文字列でマシンがハングアップするバグ【更新】
https://www.netsecurity.ne.jp/article/6/3384.html

　特定の文字列をメーリングリストに流すだけで、IE 利用者の多くをハングアップさせることが可能である。実際にメーリングリストにこの文字列が流されてしまう事故もおきている。
　どのようなソフトにもバグがあるように、必ず事故はおきると思っていた方がよいだろう。問題は、事故の時にどのように対処すべきかである。

>> オープンソースの雛型マニュアルで必要最低限の対処を確立

　ウィルスを配信してしまった時、個人情報を漏洩してしまった時、さまざまな起こりうる事故に対してのマニュアルが必要であろう。
　ただし、個別の企業でゼロから作る必要はない。多くの要素は共通すると思われるので、標準となる雛型マニュアルさえあれば、かなり重宝するのではないかと思われる。

　編集部に能力があれば、マニュアルの雛型を作って掲載できるのであるが、残念ながら、その能力はなさそうである。
　標準マニュアルをオープンソースで作る心ある方々の登場を待つばかりである。もちろん、編集部として可能な協力（マニュアル普及、印刷などプラス若干の資金援助など）は惜しまないつもりである。我と思わん方は編集部まで、ご一報いただきたい。

[ Prisoner Langley ]

《ScanNetSecurity》