ソフトウェアやWebアプリケーションの脆弱性について、発見者からの情報受付、ベンダーなどとの協議、情報の公開など、スムーズな情報の流通を目指した脆弱性届出制度が7月8日から開始された。経済産業省の告示である「ソフトウエア等脆弱性関連情報取扱基準」に基づいた枠組みで、情報処理推進機構(IPA)が受付機関、JPCERT コーディネーションセンター(JPCERT/CC)が調整機関となる今回の取り組みについて、国内では初めての取り組みであり、ベンダー側の協力が不可欠な制度であるため、IPAとJPCERTは各地で説明会を開催、制度の詳細を説明している。

届出制度とは

今回の制度は、受付機関をIPAに一本化、JPCERTがベンダー側との協議を引き受けることで脆弱性発見者の手間を低減するとともに、脆弱性の公表までをルール化することで脆弱性修正前の危険を伴うような情報公開を防ぐ、IPA/JPCERTが関与することでベンダーの確実な対応が期待できる、といったメリットが挙げられる。ベンダーにとっても脆弱性情報を事前に入手でき、余裕のある対応ができる、脆弱性情報とともに対策情報も同時公開できる、といったメリットがあるという。

告示を定めた経産省の商務情報政策局情報経済課情報セキュリティ政策室の川口修司課長補佐は、今まで対症療法的にセキュリティ問題に取り組んでいたが、2003年4月の「情報セキュリティ総合戦略」策定以降、対策に抜本的な見直しが必要になった、と指摘。脆弱性に関する国内の問題として「脆弱性に関する研究・発見の大半は海外に依存」「Webアプリケーションの場合、偶然脆弱性に気づいた人も不正アクセス禁止法の疑いを恐れ放置したり、暴露する可能性」「脆弱性の問題は、IT業界の自律的な改善が進みにくい」点を挙げ、より円滑に、効果的に業界の対策が進むように、政府がそれを補完、支援していくことが必要と判断した、と取り組みの動機を語る。

日本に必要な取り組み	今回の制度の位置づけ

制度の基本的な枠組みは、「情報セキュリティ早期警戒パートナーシップ」という名称で、IPA、JPCERTに加え、業界団体として電子情報技術産業協会(JEITA)、情報サービス産業協会(JISA)、日本パーソナルコンピュータソフトウェア協会(パソ協)、日本ネットワークセキュリティ協会(JNSA)の4団体が連名でガイドラインを発表。官民、業界を挙げて取り組むことが目指されている。

今回の制度の枠組み

政府の情報セキュリティ政策の流れの中で今回の取り組みが登場してきた	告示と今回の制度の全体

ソフトウェアは、OSやブラウザなどのクライアントPC上のソフトウェア、データベース管理システム、Webサーバーなどサーバー上のソフトウェア、ソフトウェアを組み込んだ汎用的なハードウェア製品が対象。Webアプリケーションについては、インターネット上のWebサイトで稼働している、電子申請やネットバンキングなどが対象となる。いずれも不特定多数の一般ユーザーに向けて提供されているものが対象だ。

脆弱性の定義

脆弱性発見後の手続

脆弱性を発見した場合は、所定の様式に従ってメールにてIPAに連絡する。メールには届出者の情報として氏名やメールアドレスなどその後の連絡に必要な情報と、脆弱性公表時に届出者の名前を「謝辞」として公開してもかまわないかどうか、そして対象ソフトや脆弱性の種類、再現手順、脅威、回避策などの脆弱性関連情報、IPA以外へ届け出ているかどうか、といった情報を記載する。届出者の氏名は、基本的に本名を名乗ることを求めるようだ。またセンシティブな情報のため、メールにはPGPによる暗号化を要請するが、PGP暗号の敷居の高さから、今秋をめどにSSLを用いる形でWebからの届出も可能にする予定で、IPAでは8月中にWebからの届出を実現したい考えだ。

受付機関と分析機関の位置づけと役割

IPAの役割と届出の受付方法

ソフトウェアの脆弱性情報の流れ	Webアプリケーションの場合

届け出られた情報は、すでに報告されている脆弱性かどうかの確認が行われ、取り扱いが妥当と判断された場合に、情報をJPCERTに通知する。

その情報を受けたJPCERTは、別途用意された製品開発者登録リストから、受け付けられた情報に関係するベンダーに連絡を行う。これは、業界のベンダーが、脆弱性情報の窓口(POC:Point Of Contact)をJPCERTに登録申請したリストで、ベンダーへの連絡をスムーズに行うために登録が求められている。

リストからベンダーを特定、その窓口に対して連絡した後、JPCERTはベンダーとの協議にはいる。不明な点については、基本的にJPCERTからIPAを通じる形で発見者とも連絡のやりとりが行われる。ベンダーの調査や検証が終わると、ベンダーから報告がなされ、それに基づいて公表スケジュールの調整などが行われる。基本的に公開までの日数は、米CERT/CCが経験則で定めた「45日」というルールを踏襲。それを前提として脆弱性の内容などをふまえて公表日を定める。公表日が決まると、それがIPAや、JPCERTと連携する米CERT/CC、英NISCCといった海外のインシデント対応機関(CSIRT)にも通知される。

ソフトウェアに関する脆弱性情報の処理の流れ	こちらはWebアプリケーション

ベンダー側はJPCERTに対し、脆弱性がある製品名とバージョン、脆弱性の概要、脆弱性への対応状況、回避方法や修正方法などの対策方法、関連情報へのリンク、連絡先、などを報告する。対応状況については、「該当製品あり」「該当製品あり:調査中」といった一定のフォーマットだ。それらの情報についてベンダーから報告されたJPCERTは、それに基づいて公表情報を作成。脆弱性の影響が海外ベンダーを含む複数ベンダー・製品にまたがる場合、すべてのベンダー・製品の対策状況が整うまで調整を行い、対策方法とともに一斉に情報を公開する。海外ベンダーが含まれる場合は、海外のCSIRTも同様に同時公開を行う。

JPCERTのハンドリング

公表時、影響が深刻な場合は「注意喚起」「緊急報告」などといった形で発信されるほか、IPAとJPCERTが運営する対策情報ポータルサイト「JVN」でも公開される。JVNを見れば、脆弱性が存在する製品とその対応状況が閲覧できる仕組みだ。公表時にはIPAから発見者へも通知が行われる。

脆弱性を公開する理由	今回の取り組みにおけるベンダーへのメリット

ちなみに、仮にJPCERTがベンダーに脆弱性を通知しても連絡が返ってこなかった場合は、最終的にJVNにベンダー名が公表され、対応状況の欄に「不明」と記載されることになる。JEITAの脆弱性情報取扱検討WGの主査である宮地利雄氏(NEC)は、この「不明」という状況が「ベンダーにとって不名誉であること」と認識されるように今回の枠組みを発展させていきたいと語る。