Posted: 06 Apr. 2023 10 min. read

本当にもう脆弱性はない? ~ハッカーの力を借りるバグバウンティとは?~

【連載】勘違いセキュリティ(あなたの理解は大丈夫?)

(本ブログは、2020年に公開した連載記事「勘違いセキュリティ」を再掲載したものです)


バグバウンティやバグ報奨金制度という言葉をよく耳にするようになった。バグバウンティ(バグ報奨金制度)とは、企業が自社の製品やサービスに対する調査案件を公開し、世界中のホワイトハッカーが、製品やサービスの脆弱性(バグ)を発見・報告することで、企業がハッカーに対して報奨金を支払う仕組みのことである。本稿ではセキュリティ検証活動におけるバグバウンティの位置付けや仕組みを解説する。

はじめに(国内外で認知度が高まりつつあるバグバウンティ)

近年、バグバウンティやバグ報奨金制度という言葉をよく耳にするようになった。バグバウンティ(バグ報奨金制度)とは、企業が自社の製品やサービスに対する調査案件を公開し、世界中のホワイトハッカー(以降、ハッカーと呼ぶ)が、製品やサービスの脆弱性(バグ)を発見・報告することで、企業がハッカーに対して報奨金を支払う仕組みのことである。

バグバウンティの仕組み自体は、2000年頃から存在していたが、ここ数年で、企業とハッカーが連携して脆弱性の発見に取組むことに対する認知度が高まり、海外のIT企業を中心に、バグバウンティを導入する企業が増えてきた。また、IoTやコネクティッドカー等の普及に伴い、自動車を含む製造業においても導入する企業が登場している。一方、日本国内では、IT企業を中心に広まってきているものの、まだ認知度が低く、導入する企業が限られている状況である。

このように、国内外の企業がバグバウンティの導入を検討している中、ある企業のセキュリティ担当役員から、このような言葉が聞こえてくる。

A氏の発言は、一見正しいように聞こえるが、ネットワークやシステムが複雑化するとともに、サイバー攻撃も日々高度化、巧妙化している昨今の状況において、開発工程の中でしっかりとセキュリティ検証を行ったからといって、「もう脆弱性は残っていない」と断言できるのだろうか。

本稿では、セキュリティ検証活動におけるバグバウンティの位置付けや仕組みを述べるとともに、バグバウンティプラットフォームを活用したバグバウンティの導入について紹介する。

バグバウンティのメリット

一般的なセキュリティ検証活動を整理すると、図1のように、テスト実施者に提供される情報量の少ない方から順にBlack Box、Gray Box、White Boxの3つに分類できる。Black Boxでは、活用情報は主に公開情報となり、内部的な設計情報が無い状態で行う攻撃者視点でのテストとなる。入手した情報を基に、攻撃シナリオを作成し、実際に攻撃を仕掛けて侵入につながる脆弱性や問題点の有無を確認する。一方のWhite Boxでは、仕様書・設計書等を基に、製品の内部構造を理解した上で行う設計者視点でのテストである。例えば、設計者によるセキュリティ機能テストや、ソースコードレビューをはじめ、自動化ツールを用いたファジングテストや脆弱性診断等がある。最後にGray Boxであるが、Black BoxとWhite Boxの中間に位置し、第三者的な客観視点でのテストとしながらも、最低限の設計情報を提供することで、テストの効率性を高めることを可能とするものである。

図1:既存のセキュリティ検証活動とバグバウンティの関係

バグバウンティは、このうちBlack Boxテストに位置する。攻撃者視点で対象のシステムに対して実際にサイバー攻撃を仕掛ける点はペネトレーションテストやレッドチーム演習と同様だが、セキュリティ人材と経済性の観点でメリットがある。

まずセキュリティ人材の観点では、ペネトレーションテスト等の担当者には高度なセキュリティの知識やスキルが求められることから人材の確保が難しく、仮に、組織内で人材が確保できたとしても、限られた視点での検証となるため、継続的な運用において属人化の問題が生じ、テスト品質が担当者に依存する場合がある。これに対してバグバウンティは、世界中の多数のハッカーが調査を実施することから、より多角的な視点での脆弱性の発見が期待できる。

次に、経済性の観点では、ペネトレーションテスト等は外部の専門企業に依頼することが多く、その場合、料金体系が人月ベースの工数となる。そのため、組織によっては、予算との兼ね合いで、限られた時間内に対象の細部まで検証することが困難となり、結果として対象範囲やテスト項目が制限され、限定的な検証となる場合もある。

一方、バグバウンティは、その期間内で受けた報告のうち、技術的な裏付けを確認できた報告のみに対する成果報酬である。そのため、当初想定した以上の脆弱性が見つかることで、計画以上の報酬を支払うことになるリスクはあるものの、成果の有無に関わらず一定額のコストが固定費として発生する方法(例:ハッキングのエキスパートの雇用や外部委託等)よりも効率的であり、運用上も継続しやすい。

このようなことから、既存の社内テストやペネトレーションテスト等だけでなく、これらを補完する手法としてバグバウンティを活用することで、想定もしなかった脆弱性の発見が期待できる。

バグバウンティ導入のハードルを下げるバグバウンティプラットフォーム

では、実際にバグバウンティを導入するにあたって、何をすべきだろうか。バグバウンティの導入には、全て自社で導入する方法と、バグバウンティプラットフォームを利用する方法の2つがある。全て自社で導入する場合、全ての企業で導入可能という訳ではなく、一般的に想定される予算の確保や社内各部署との調整等に加え、図2に挙げるような課題が導入のハードルとなる。

図2:バグバウンティ導入における課題

図2の全ての課題について、自社内で対応する人材を確保した上で体制を構築するには相当の労力を要すると考えられる。ただし、近年、脆弱性を発見したい企業とハッカーをマッチングさせるバグバウンティプラットフォームと呼ばれるサービスが登場し、上記課題への対応を代行している。バグバウンティプラットフォームの仕組みについて図3に示す。

図3:バグバウンティプラットフォームの仕組みバグバウンティを自社で導入するかどうかは、社内のセキュリティ人材や予算との兼ね合いとなることが多いが、バグバウンティプラットフォームを活用することで、上記の課題への対応の代行を依頼できるため、バグバウンティ導入のハードルを下げることができる。

例えば、課題1において、企業は、報告者とのやりとりを行う窓口の構築が必要となるが、バグバウンティプラットフォームは世界中のハッカーからの報告を一手に引き受ける(図3内の③)。また、バグバウンティの参加者の多くは海外のハッカーであるため、それらの報告に対応するためには英語が必須となるが、国内向けのバグバウンティプラットフォームも立ち上がり、言語の面での不安も払拭されつつある。

次に課題2について、脆弱性を発見したハッカーからバグバウンティプラットフォームに対して報告が寄せられるが、バグバウンティでは、調査対象外となるシステムの脆弱性に関する報告や、不正確な内容の報告が寄せられることもある。

このような無効あるいは誤情報等の「ノイズ」となる報告を除外し、対処すべき脆弱性の報告を選別するには、単に労力を要するだけでなく、高度なセキュリティ知識を有する人材を確保する必要がある。バグバウンティプラットフォームは、寄せられた報告からの有益な情報の選別や脆弱性の検証、それらを基にした助言等もサービスとして提供する(図3内の④)。

また、課題3のような各種規約についても定める必要があるが、実態としてハッカーに読まれないケースも多いため、特別のこだわりがない場合は、バグバウンティプラットフォームにおいて共通化された規定を利用することで、独自に規定する労力を軽減することができる。

まずはプライベート形式の検討を

ここまで、バグバウンティの導入におけるバグバウンティプラットフォームの活用について述べたが、実際に、ハッカーに対して依頼するとなると、冒頭のA氏の二つ目の発言のように、自社の製品やサービスに係る情報を不特定多数のハッカーに公開することになる等、心理的な抵抗がある。

そこでバグバウンティプラットフォームは、企業からの依頼形式として、パブリック形式とプライベート形式の2つの形式を用意している。パブリック形式は、上述の不特定多数のハッカーに対して依頼する形式であるのに対し、プライベート形式は、プラットフォームに登録されているハッカーから、一定以上の評価を得ているハッカーだけを招待、または参加申込を経て受け付けられた人のみが参加できるものである。プライベート形式では、あらゆる側面が参加者以外に対して非公開となる。

多くの組織は、まずはプライベート形式のバグバウンティから始め、バグバウンティプラットフォームの使い勝手や、報告された脆弱性への社内の対応プロセスが有効に働くかを確認する。その上で、報奨金予算の予測や、社内調整を行い、パブリック形式へと移行する傾向がある。

以上を踏まえ、冒頭のセキュリティ担当役員A氏には次のような発言を期待したい。

IoTやコネクティッドカー等の普及に伴い、ネットワークやシステムが複雑化する中、サイバー攻撃も日々高度化、巧妙化しているため、新たな脅威や攻撃手法が登場し、いつ新たなリスクにさらされてもおかしくはない。そうしたリスクを一つでも減らすためにも、これからは企業自らハッカーと積極的に連携し、また、そうした姿勢が社会から評価されるようになることを望む。

 

本記事のPDFをダウンロード(PDF, 952KB)

執筆者

三浦 淳也/Junya Miura
デロイト トーマツ サイバー合同会社 コンサルタント

国内ベンチャー企業にて、自動車ECUのモデルベース開発を経験。2017年、デロイトトーマツ参画後は、自動車セキュリティ領域のコンサルティング業務に従事し、主にコネクティッドカーのIn-Car, Out-Car領域を含めたセキュリティリスクアセスメントや、WP29及びISO/SAE 21434対応に関する案件に関与。
 

※所属などの情報は執筆当時のものです。

プロフェッショナル