水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書

「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書

2009年6月8日(月曜日)

「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書

公開: 2009年6月10日1時11分頃

「ウェブサイト構築事業者のための脆弱性対応ガイド」などを公開 (www.ipa.go.jp)……ということで。

「情報システム等の脆弱性情報の取扱いに関する研究会」2008年度報告書が公開されたというプレスリリースなのですが、タイトルを見ると、本編よりも「情報システムを安全にお使いいただくために」「ウェブサイト構築事業者のための脆弱性対応ガイド」をプッシュしたい感じなのですかね。まあ、本編は関係者以外にはどうでも良い感じの内容ですしね。

実は私もヒアリング調査に協力させていただいたりしておりまして、関係者のほうに分類されると思います。パートナーシップに関しては、「長期化案件への対応方針の検討」という部分が興味深いですね。以下、報告書本編の内容について、いくつかコメントしておきます。

24ページ: 処理の遅延について

■脆弱性届出の急増に伴う処理の遅延について

発見者は、脆弱性届出の受理通知に遅延が生じていることを認識しているが、それが大きな問題であるとの意見はなかった。

報告書には書かれていませんが、届出された脆弱性の種類や深刻度によって取扱の優先度を変えていると聞いています。緊急性のある案件については優先的に処理されているということで、たとえば、XSSよりもSQLインジェクションのほうが優先される傾向にあります。

つまり、「緊急性のある案件については優先的に処理されている」という前提で、「緊急性のない案件は大幅に遅延しているが、大きな問題ではない」と考えているわけです。遅れていても全く問題ない、と考えているわけではありませんので、そこはひとつ。

※緊急性が無いものは遅れても良いとは言え、4月14日に届け出た内容の不備を今になって質問されたりすると、だいぶ昔の届出の控えを発掘する羽目になって大変だったり……。まあ、記入の不備は私が悪いので、そこは申し訳ないのですが。

25ページ: 発見者から運営者に直接連絡

届出が多すぎて処理できない状況なので、発見者から当該ウェブサイト運営者に直接連絡してもらうよう推奨すべきとの提案も出たが、その一方、IPAが発見者に代わって交渉することで相手からも信頼が得られるという指摘もあり、さらなる検討が必要と考えられる。

これは私ではなくて、他の届出者の方からこのようなご意見があったとお聞きしております。が……そもそも、現状のパートナーシップガイドラインでは直接連絡は禁じられていません。届出者がしびれを切らして「直接連絡した方が早いじゃん!」と感じたなら、直接連絡して良いことになっています。

実際、私も発見した脆弱性すべてを届け出ているわけではなく、直接連絡した方が早いと感じたものは、直接連絡しています。直接連絡が色々な意味で面倒だから届け出ているわけで、そこを「直接連絡してもらうよう推奨」されてもちょっと、という感じはしますね。

26ページ: 製品の脆弱性に取扱開始の通知がない

製品案件については、取扱い開始の通知がなく、状況がわからない。

これは補足が必要だと思いますが、ウェブアプリケーションの脆弱性を届け出た場合、「受信」「受理」の連絡が来た後、ウェブの運営者に対して情報を通知した時点で「取扱開始」という連絡があります。そして修正された時点で「修正完了」が連絡されます。しかし、ソフトウェア製品の場合「受信」「受理」の連絡の後、いきなり「公開」の連絡となり、「取扱開始」に相当する連絡がありません。ベンダーに連絡が行っているのかいないのか、全く分からないのです。

まあ、質問すれば現在の状況は教えてもらえるのだろうと思いますが、「取扱開始」に相当する連絡があっても良いのではないかと思います。

36ページ: 古い製品を利用しているウェブサイト

「古い製品を利用しているウェブサイト」の対応が検討されています。

脆弱性の原因が、ウェブサイトの使用しているソフトウェア製品の脆弱性に起因していて、そして、その製品の修正版が既に公開されているが、アップデートしていないような案件の届出が増加している。

たとえば、とある脆弱性診断専門の会社が古いMTを使い続けていてXSS脆弱性を抱えていた、などというケースですね。届け出たところ、これは公表されている脆弱性であって、ウェブサイトの脆弱性には該当しない (けれども運営者には連絡する) という扱いになりました。このようなケースについても取り扱ってほしいという要望を伝えていましたが、それが今回検討された形になります。

そこで、脆弱性の原因が、ソフトウェア製品のアップデートを怠っていることに起因していることが明らかに判るような、極めて単純かつ不適切な運用は、取扱いを終了させる[取扱ルールを改訂]。

・脆弱性の原因が極めて単純なので、ウェブサイト運営者は自力で気付くべき。

・IPAで取扱いを終了する前に、脆弱性が攻撃された場合の脅威など、製品の脆弱性対策を促す旨の注意喚起をしたいと考えている。

・この結果、届出者は関連情報の取扱いに関する「お願い」から解放される。

結論としては、「運営者が自力で気付けよ」という話であって、積極的に扱っていくという方向ではないようですね。届出件数がやたら増加していることをふまえての判断でもあるでしょうし、これはこれで妥当であるように思います。

37ページ: 何度も修正を促したが対策がなされないウェブサイト

出ましたね。これは私も問題だと思っていたところです。25回促したケースが確認されていますが、お疲れ様でしたとしか言いようがありません。現在も、全く修正する気がないとしか思えない人がいたりして……。

※放置するだけならまだ分かるのですけれど、平然と脆弱サイトを量産し続けるのは勘弁してほしいです。

届出者としては、放置案件は取扱終了にしてほしいところです。ガイドラインでは取扱中の脆弱性関連情報は公表できませんが、取扱終了になれば、脆弱性を公表して危険性を周知することができるようになります。場合によっては回避策を提示できることもあるでしょう。

今回の報告では、一定期間後に取扱終了という方向で検討されています。

2)一定期間は1~2年程度が適当と考えている。

・ 対策できない理由として、「予算が無く、来年度の予算で対応する」旨の回答も多い。

・ 2008年第4四半期の取扱中1,907件のうち、300日(約1年間)以上未対策は81件(約4%)、700日(約2年間)以上未対策は20件(約1%)。

1~2年だそうで。なんか昔のガイドラインでは90日ルールが謳われていたような気がしなくもないですが、まあ実態に合っていなかったということなのでしょう。

※枝番が10個も振られている伝説の放置案件は昨年の8月からスタートしているので、ちょうどガイドライン改訂のタイミングで1年になるのかなと。

関連する話題: セキュリティ / IPA

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 Webプログラミング

その他サイト