|
事件・事故の原因を掘り下げて実効性ある再発防止策を考える
〜セキュリティ事件・事故の本質的な原因の解明手法〜
日々報道されるセキュリティに関する事件・事故。なぜこんなにも頻繁に起こるのでしょうか。小職は、もともとソフトウェア技術者でしが、その当時のソフトウェアのバグ（障害）管理の経験から得たことを用いて、実効性のある再発防止策を導きすための事件・事故の直接的な原因と本質的な原因をどのように捉え、掘り下げていくのかについて考えてみましょう。
本質的な原因を探る手順（図１、図２を参照）
ソフトウェアの「バグの原因を捉える」例をみながら考えてみましょう。基本的にソフトウェアにバグがないことを保証することは不可能です。バグが検出されたらその本質的な原因を早く突き止め、対策を立てて再発防止に努めることが基本です。
バグが検出されるとその管理票をもとにその現象、原因、対応策をまとめますが、大半の原因は“テストケース漏れ“です。そのケースについてテストしていれば、その結果を見落とさない限り確かにバグは検出されるはずです。したがって、この原因が直接的なもののひとつであるといえます。しかし、これは本質的な原因ではないので適切な再発防止策を打つことはできません。
１．バグが発生した本質的な原因を突き止める場合には、まず「バグを埋め込んでしまった原因」とそれを「除去できなかった原因」の２つの側面から考える必要があります。（図１）
（１）バグを埋め込んでしまった主な原因を考えます。それらには、要求分析が曖昧であった（要求分析が曖昧）、要求が正しく設計されなかった（設計ミス）、設計どおり実装しなかった（実装ミス）ということなどがあり、さらにそれらをレビューで検出できなかったことも原因の１つといえます。
（２）バグを除去できなかった主な原因を考えますが、前述の通りその大半は「テストケース漏れ」（そのケース未テスト）です。また、テストは実施したが結果を見過ごしてしまった（テスト結果見落とし）ということもありえます。
２．ここでは、さらに「テストケース漏れ」（そのケース未テスト）についてさらに掘り下げて本質的原因を探ってみます。（図２）
この「テストケース漏れ」は、一見、ケアレスミス（テストケースの洗い出し漏れ）のように思われがちでが、それ以前にプロジェクト計画や設計の問題であったり、変更管理の問題（変更管理不十分）であったりすることもあります。しかしながら、「テスト技法スキル不足」であることも多いものです。原因をさらに掘り下げて、その根っこまで辿り着くとその原因の本質が具体的に見え、自ずとその対策も作ることができるとうことです。
（図1）
（図2）
セキュリティ事件・事故の本質的な原因を捉え、再発防止策を作る
事故が発生すると、まず事故調査委員会を立ち上げ、原因究明と再発防止策に取り組む例が多く見られます。2003年11月にACCS（（社）コンピュータソフトウェア著作権協会）で起きた個人情報流出事件でも同じで、小職は、この事故調査委員会のメンバーとして参加していたこともあり、その事件の「事故調査委員会調査報告書」から内容を一部抜粋補記したものを下記に掲載したので検証してみましょう。この事件は、“不正アクセス”と“善意による脆弱性の指摘行為”について、多方面から議論を呼びましたので記憶している方も多いかと思います。
１．本件が発覚した経緯等
平成１５年１１月8日、ある方（以下「情報提供者」という）からACCSに「ホームページ上から個人情報を入手できる」とのメールが届いた。そこでACCS側で確認したところ、ホームページで使用されていたCGIプログラムに、セキュリティの脆弱な部分が存在しており、それを意図的に攻撃することでホームページに質問を寄せた約１２００人の送信日時・氏名・住所・電話番号・年齢・メールアドレス・相談内容等（以下「個人情報」という）を入手できる状態にあったことが確認された。ACCSは直ちに当該CGIプログラムの使用を中止し、サイトを閉鎖した。
２．本件発生の原因
＜技術的な原因（直接的原因）とは＞
技術的な原因は、セキュリティの脆弱性が認められるCGIプログラムを使用していたことにある。ホームページは、レンタルサーバー会社のサーバーで運営されており、ホームページ上の質問フォームで入力された情報は、担当者に送信されるとともにテキストファイル形式でサーバーに保存される仕組みになっていた。担当者は、この保存のためにレンタルサーバー会社からホームページの開設時に提供されていた標準CGIプログラムを利用していた。
しかし、このCGIプログラムには、ある特別な操作をする事で質問フォームに入力された情報をダウンロードできてしまうという脆弱性が存在していたため、ホームページ上の質問フォームで入力された情報を取得することが可能となっていた。
＜本質的な原因とは＞
上記のとおり、本件の技術的な原因は、当該CGIプログラムに脆弱性があった点にあるが、本質的には、次のような問題があると判断した。
（１）ACCSは、ホームページについて、セキュリティチェック等の充分な検証を実施していなかった。また、当該CGIプログラムを採用するに際しても、特にセキュリティ上の検証を行っていなかった。
ホームページで広く個人情報を収集・取得していたのであるから、そのセキュリティについては細心の注意を払うことが求められていたというべきである。第三者が作成したソフトウェアを利用する場合には、その選定に際して細心の注意を払う必要があると考えるし、採用した後においても、セキュリティ上の問題がないか否かを、継続的に自らの責任で検証する必要があると考える。
さらに、ACCSは、これまで情報の取り扱いに関する啓発活動を自ら行ってきていることからすれば、自ら運営するホームページのセキュリティについては、通常の企業等以上に、充分なスキル、体制で臨む必要があると考える。しかし、レンタルサーバー会社の提供するCGIプログラムを採用する際に、セキュリティ上の検証について入念な検査をしたとは認められなかった。
（２）ホームページでは、必要と認められる以上の個人情報を入力させていたと考えられる。また、不特定の第三者から広く質問を受け付け、それに回答することを目的としていた以上、回答を送付するために必要な最低限の個人情報（メールアドレス等）の入力を求めることはやむを得ないと考える。
しかし、ホームページの質問フォームでは、さらに住所・氏名等の個人情報の入力まで要求していたが、そこまでの情報が必要であったとは認めがたい。個人情報を扱う際には、その管理に万全を尽くすことはもちろんであるが、それと同時に、そもそも不必要な個人情報は取得しないことも求められているというべきである。
＜小 括＞ 本件の技術的な原因（直接的な原因）は、ホームページで採用していたCGIプログラムの脆弱性にある。しかし、本質的な原因は、（1）ACCSが、当該CGIプログラムの採用にあたって、十分なセキュリティ等のチェックを行っていなかったこと、（2）必要以上に個人情報を取得したことの２点にある。
※この件についてもっと詳細にお知りになりたい方は、Google等で「“ASKACCS” “個人情報流出事故調査委員会”」で検索してみてください。
以上が事故調査委員会の報告書の抜粋検証です。
最後にもし、原因として技術的な原因（直接的な原因）までしか捉えられなかったとすると、再発防止策は、「脆弱性のあるCGIプログラムを使用しない」といった短絡的なものになり、実効性のある再発防止策を作ることは出来ません。
これに対して、本質的な原因を認識すれば、以下のような具体策が導き出すことができます。
�‖荵絢圓�作成したプログラムを採用する際には特に十分なセキュリティ検証を行う
�▲札�ュリティ検証チェックリストを作成し、十分検証の上でシステム運用を開始する
�８朕余霾鵑亮萋世虜檗¬榲�に必要な最小限の情報のみを取得する
また、これらを遵守徹底できるように、
�ぅ札�ュリティ規定や運用マニュアルが整備
されれば、さらに実効性のある再発防止策となるでしょう。
これらのことに加え普段から、他で発生した事例についても直接的な原因にとどまらず、本質的な原因まで掘り下げて捉え、自社の状況を検証することもお薦めします。