「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点：セキュリティ・アディッショナルタイム（16）（1/2 ページ）
連日公表されるソフトウェアなどの脆弱（ぜいじゃく）性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。
世の中には連日、ソフトウェアやWebアプリケーションに存在する多数の脆弱（ぜいじゃく）性の情報が流れている。こうした情報を必要な人に適切に届け、対応してもらい、ひいては安全なインターネットを実現するために整備されてきたのが「早期警戒パートナーシップ」をはじめとする脆弱性情報の流通制度だ。
2016年12月1日に行われた「Internet Week 2016」のプログラム、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」では、脆弱性情報流通の最前線が解説された。
脆弱性を闇に埋もれさせず、適切な対処を
先日、WordPressの脆弱性が公表され、直後に数千という規模でWebサイトの改ざん被害が発生したことは記憶に新しい。このケースから得られる教訓は多々あるが、少なくとも、適切な脆弱性情報を、必要とする人に、可能であればアップデートなどの修正方法とともに提供することが重要であるのは確かだ。
現在日本では、経済産業省の告示に基づいて整備された「情報セキュリティ早期警戒パートナーシップ」に沿って、脆弱性情報の届出と対応、公表が進められている。その中で、受付機関、調整機関として重要な役割を担っているのが、IPA（情報処理推進機構）とJPCERT/CCだ。
最初のセッションでは、JPCERT/CCの情報流通対策グループマネージャー、久保正樹氏が「情報セキュリティ早期警戒パートナーシップのいま」と題し、この制度の狙いと変遷を説明した。「水面下にある脆弱性情報を管理下に持ってこられるようにすることがこの制度の目的。脆弱性情報が開発者の手に届くようにし、かつ開発側が修正したり、回避策を提供するなど真摯に対応し、その上でコンシューマーの手に渡るよう公表する。この3つがかみ合って初めて、脆弱性情報を活用し、管理できる」（同氏）
2000年ごろ、まだ「脆弱性」という言葉すら一般的ではなかった当時は「ベンダー側には経験がなく、情報を受け取る窓口もなければ、どう対応したらいいかも分からない状態」（久保氏）だった。発見した脆弱性を通知しても受け取ってもらえない、といった対応を経験したセキュリティ研究者の中には、見て見ぬ振りをしたり、時には思い余って修正の用意もないまま情報を公開してしまうこともあった。一方ベンダー側も、脆弱性に関する情報の公表をネガティブに捉えるところも少なくなかった。
「企業がきちんと脆弱性情報を出してくれないと、コンシューマーは対応できない。しかし、きちんと情報を出している企業の方が『脆弱性が多いではないか』とネガティブに受け取られかねない風潮があった」（久保氏）。セキュリティ早期警戒パートナーシップは、こうした状況の改善を目指して作られたものだ。
これは決して強制力のある仕組みではないが、2004年のスタートから12年がたち、脆弱性をめぐる状況は大きく変化した。今では「脆弱性が見つかって開発者に渡るまでの流れが多様化してきた」と久保氏は述べる。例えば、企業が脆弱性に関する届出窓口や報奨金制度を整備して直接受け取るケースが増えてきた他、IPAやJPCERT/CCといった組織以外に、サービスとして報奨金プログラムを運営する企業も登場している。
中にはユナイテッド航空のように、IT企業ではないにもかかわらず、独自に「バグ発見報償プログラム」を開始した企業もあるほどだ。このように、民間でも、発見者とベンダーをつなぐプログラムやサービスが複数始まっている。
こうした変化は「エコシステム全体にとっていいことだと思う。特に、脆弱性の発見者に対する報償の形がいろいろ生まれた。今や、発見者とベンダーを結び付けるチャンネルは、国や組織、企業自身など複数あり、JPCERT/CCはその一部を担う形だ」と久保氏は述べる。
日本ではこれまで3295件の脆弱性情報が届け出られ、うち1317件が公表済みだ。「全体として、ITの世界の脆弱性情報流通マーケットは成熟期に入りつつある。海外では自動車や医療機器など、IT以外のドメインの脆弱性を探し、横展開する方向に向かっている」（久保氏）。また、日本で届け出された脆弱性の数は増えているが、その多くはオープンソースソフトウェア、特にCMS（Content Management System）に関するものだという。
そして久保氏は最後にあえて「この制度が、日本のセキュリティ向上にどこまで寄与できているか、少し疑問もある。今後IoT機器が増えていくと、脆弱性情報そのものの流通よりも、パッチの適用などが社会的課題になってくるだろう。きちんとパッチを当てて直すという部分をどうするかが、これからの制度に求められている」と問題を提起し、講演を締めくくった。
バグバウンティプログラムと診断は「補完関係」
続けて、スプラウトでバグバウンティプラットフォーム「BugBounty.jp」の運営に当たる小西明紀氏が登壇し、脆弱性報奨金制度の変遷を説明した。
賞金を設定して脆弱性情報を募集するという取り組みは決して最近のものではなく、源流は1995年のNetscapeにさかのぼるという。それからほぼ20年を経て「プログラムは幅広い企業に広がるとともに、その有効性が認められるようになっている」（小西氏）。GoogleやFacebook、Microsoft、日本ならばサイボウズのように自社で企画・運営するケースもあれば、HackerOneやBugcrowdといった第三者が提供するプラットフォームを利用するケースもある。オープンソースソフトウェアの場合は、スポンサーが代わりに運営するケースもあるそうだ。
だがそもそもなぜ、「セキュリティ診断サービス」や診断のためのツールがあるのに、バグバウンティプログラムが必要なのだろうか？ 小西氏は「診断とバグバウンティは互いに補完する関係にある」と説明する。
「診断を行う場合、コストは決して安くないが、一定のレベルは担保できる。ただ、診断員のスキルに依存する部分もある。一方バグバウンティはいろいろな人が参加するため、診断では見つからない問題や現実の攻撃に即した問題が見つかる可能性があるが、『どこで問題が見つからなかったか』は把握できないため網羅性が弱く、監査証明としても弱い」（小西氏）。それぞれの強み、弱みを理解しながら活用することで、品質の向上につながるというわけだ。
バグバウンティプログラムの効果を定量的に測るのは難しいが、「例えば2013年から脆弱性報奨金制度を進めてきたマイクロソフトのような大手ソフトウェア企業では、全ての脆弱性のうち、修正前に悪用される脆弱性の割合は2012年の18％から2013年には7％に減少している。少なくとも脆弱性が表層化し、それによって悪用される脆弱性も減るのは確かだと思う」（小西氏）
逆に、脆弱性を発見する側にとっても、脆弱性報奨金制度のメリットは大きい。脆弱性を見つけた場合の届出先には、公的機関が行うコーディネーション制度とバグバウンティを実施している企業の窓口があるが、後者の方が報奨金などのリターンは大きい（他にはいわゆるダークウェブに流すという手段もあるが、法を犯す恐れがある）。従って「報告する側、される側、双方のメリットを最大にするには、窓口を設けて報奨金を支払う方法が良い」（同氏）。
また、バグバウンティ制度を開始してから数年程度がたち、脆弱性調査に関わるリサーチャーが増えてくると、語弊はあるが“ささいな”バグが報告されるケースも増えてくる。「例えば最初の3カ月は優秀なハッカーを対象としたクローズドな形で大きな脆弱性をつぶしてもらい、その後広く参加を募ったり、脆弱性スキャナやペネトレーションテストのようなセキュリティソリューションと組み合わせるといった形で、全体としてコストとリスクを最小限にとどめることができるのではないか」と小西氏は説明する。
「今後、出回る脆弱性情報は増え続けるだろう。もし自社が抱える製品に脆弱性が見つかったときにどうするか、当事者意識を持って考える必要がある。その流れでバグバウンティプログラムは広がっている。ただ、こうしたプログラムは安易に運用できるわけではなく、入念な準備が必要なことも事実だ。そうした企業には、サードパーティーが提供するプラットフォームという選択肢もある」（小西氏）
Copyright © ITmedia, Inc. All Rights Reserved.