PR

 2004年7月から運用されている「情報セキュリティ早期警戒パートナーシップ(以下,早期警戒パートナーシップ)」。ソフトウエア製品やWebサイトに見つかったセキュリティ・ホール情報を情報処理推進機構(IPA)が受け付け,ソフト開発者やサイト運営者に修正や情報公開を促す制度である。2005年3月までに,ソフトウエアについては44件,Webサイトについては211件のセキュリティ・ホール情報を受け付けた。セキュリティの専門家や大手ベンダーの開発者には認知されてきたようだ。

 しかしながら,一般のユーザーはほとんど知らないだろう。「セキュリティ・ホールを見つけるような専門家やベンダーの開発者が知っていれば十分。ユーザーが知る必要はない」との意見があるだろうが,筆者は一般のユーザーにもぜひ知っておいてもらいたいと考える。

 というのも,現在では多数のユーザーがWebサイトを運営しているので,早期警戒パートナーシップに基づいて,セキュリティ・ホールの報告を受ける可能性があるからだ。IPAの関係者からは,「(セキュリティ・ホールが報告された)サイト運営者に連絡したら『振り込め詐欺』に間違われそうになった」という話を聞いた。このようなことがないように,製品開発に直接かかわらないユーザーにも知っておいてほしい。

 それだけでなく,製品のベンダーにセキュリティ向上を促すためにも知っておいてほしい。この制度は経済産業省の告示に基づくもので,法的な強制力はない。このため,セキュリティ・ホールの報告を受けていながら対策を施さなくても罰則はない。IPAとJPCERTコーディネーションセンター(JPCERT/CC)が共同運営するポータル・サイト「JP Vendor Status Notes(JVN)」で対応状況を公開されるだけである。だが,ユーザーの多くが早期警戒パートナーシップやJVNを知れば,どのベンダーのどのソフトが脆弱性を抱えているかが広く知られることになり,ベンダー側の対応も進むことが期待できる。逆に,ユーザーの多くがこれを知らなければ,「対応しなくても問題ない」と考えるベンダーが出かねない。

 早期警戒パートナーシップやJVNの認知度を高めることが,セキュリティ・ホールの解消を進める力になると筆者は考える。また,JVNで公表されるセキュリティ・ホール情報はユーザーにも有用である。本稿を機に,早期警戒パートナーシップやJVNについて知ってもらえれば幸いである。

リスクを抑えるために関係者が協調する

 早期警戒パートナーシップとは,ソフトウエア開発者(ベンダー)やWebサイト運営者,セキュリティ・ホールの発見者,IPAやJPCERT/CCなどの組織,電子情報技術産業協会(JEITA)や情報サービス産業協会(JISA)といった業界団体――が協調してセキュリティ・ホール情報(脆弱性情報)を適切に取り扱おうという取り組みである。

 具体的に言うと,(1)セキュリティ・ホールの発見者が,外部に漏らすことなくソフト開発者やサイト運営者に(早期警戒パートナーシップを通して)報告,(2)開発者/運営者は修正プログラム/修正版や回避策を用意,必要に応じて発見者が協力,(3)開発者/運営者がセキュリティ情報や修正プログラム/修正版を公表,(4)ユーザーが対応――といったプロセスを支援しようという取り組み(制度)である。

 これらのプロセスが円滑に運用されれば,ソフトやサイトにセキュリティ・ホールが見つかっても,リスクを最小限に抑えられるだろう。結果として,ネット全体のセキュリティ・レベルを向上させることを狙っている。

意識が低いベンダーはまだ多い

 上記のプロセスが発見者と開発者/運営者だけでうまく回れば,早期警戒パートナーシップなど必要ない。だが,現実は甘くないようだ。今までに直接的あるいは間接的に聞いたところでは,発見者からセキュリティ・ホールの存在を知らされても,真摯に受け止めない製品開発者(ベンダー)/サイト運営者は少なくないという。例えば,メールなどで報告しても無視。恫喝される場合さえあるという。

 善意で報告した発見者からすればひどい対応だ。一度でもそういった対応をされた発見者は,次からは報告することなく,メーリング・リストやWebサイトで公表することになる(ただし,発見者の報告方法などが不適切なために,ベンダーやサイト運営者の誤解を招く場合もある)。

 発見者やユーザーに黙って修正する場合もある。修正を施したバージョンをリリースする際にも,旧版にセキュリティ・ホールがあることなどは一切知らせない。数年前,そのような対応をしたベンダー数社に話を聞いたことがある。あるベンダーは「『セキュリティ・ホールが見つかった』なんて言うとユーザーが不安がる。言わないのが一番」と,悪びれることなく答えた。

 また,旧版にセキュリティ・ホールがあることを告知することなく修正版をリリースしたベンダーに「セキュリティ・ホールがあると言わないとアップデートしてもらえないのでは?」と質問すると,「最新版がリリースされれば,みんなきちんとバージョンアップしている。わざわざ言う必要はない」との答えだった。

 さすがに最近ではベンダーの意識が高くなり,上記のような対応をするベンダーは少なくなったと感じている。多くのベンダーはセキュリティ情報や修正版(修正プログラム)を公表するようになっている。セキュリティ・ホール情報の受付窓口を用意しているベンダーもある。

 ただ,意識が低いベンダーも依然多い。通常のユーザーはアクセスしないようなディレクトリの“深い”場所にセキュリティ情報のページを用意するベンダーも少なくない。問い合わせると「きちんと公開しています」と答える。公開サーバー上に置いていることは確かだが,気付かないような場所に置いた情報を「公開している」と言えるのだろうか。

 また,最近あるベンダーの広報の方に「どうしてセキュリティ・ホール情報を記事にするのですか?」と聞かれて驚いた。驚きのあまり,「ユーザーのためです」ととっさに返せず後悔している。そのベンダーでは,修正版などは用意するものの,積極的にはセキュリティ・ホール情報を公開していない。その理由を尋ねると,「ユーザーが不安に思う」「言わなくても,みんなバージョンアップする」との答え。意識の低いベンダーはまだまだ多いようだ。

第三者の仲介が効果的

 ソフトやサイトのセキュリティを向上させるには,セキュリティ・ホールが存在するという事実を開発者や運営者にきちんと認識してもらう必要がある。そのためには,発見者と開発者/運営者の間に信用のおける第三者機関が入ることが効果的だ。そうすれば,発見者の情報が妥当であるかどうかを検証できるとともに,開発者/運営者がその報告を無視しにくくなる。また,発見者と開発者/運営者の間でトラブルが発生しにくい。

 そこで早期警戒パートナーシップでは,IPAが「受付機関」となり,発見者からの届け出を受け付ける。そしてJPCERT/CCが「調整機関」となり,対象製品のベンダーに通知する。なお,対象がWebサイトの場合には,IPAがサイト運営者に連絡する。

 対象となるのは,「国内で利用されているソフトウエア」および「主に国内ユーザーを対象にサービスを提供しているWebサイト」。海外のソフト/サイトの場合や,海外でも利用されているソフト/サイトの場合には,JPCERT/CCは米CERT/CCといった海外のコーディネーション・センターとともに調整作業を行う。