プログラム ポリシーは VDP に不可欠であり、慎重に作成する必要があります。プログラム ポリシーは、セキュリティ研究者が VDP に参加する際に最初に目にするものです。プログラムのトーンや期待値、参加を選択する研究者に対するコミットメントを定めます。
プログラム ポリシーを作成してホストする方法
以下のガイドラインを使用して、VDP のプログラム ポリシーの下書きを作成します。通常、プログラム ポリシーの長さは 1 ～ 3 ページのみで、通常は次のトピックが含まれます。
- 研究者が約束する
- テストに関するガイドライン
- プログラムの範囲
プログラム ポリシーは、研究者になる可能性があるすべての人が利用できるようにする必要があります。招待した研究者のみに限定して VDP を開始する場合は、招待した研究者のみに限定して VDP を利用できるようにするなんらかのアクセス制御が必要です。また、研究者には、レポートを追跡するためのチケット発行システムに接続されたウェブフォームやメール エイリアスなど、レポートを送信する方法も必要です。VDP のオンライン リソースを設定する際は、この点を考慮してください。
サードパーティの脆弱性開示とバグ発見報奨金プラットフォームには、一般に次のような機能があります。
- ユーザーがポリシーを作成、編集、公開するための手段
- 非公開プログラムを作成するためのアクセス制御
- 快適なペースでハッカーを自動的に招待
- 受信レポートの処理を容易にする受信トレイ機能
サードパーティ プラットフォームには、VDP の作成とリリースのプロセスを容易にする、さまざまなコンサルティング サービスも用意されています。通常、サードパーティのプラットフォームやコンサルティング サービスには費用がかかります。サードパーティを利用する場合と、プログラムを社内で構築、管理する場合を比較して、費用とメリットを比較して、最適な方法を判断してください。
プログラム ポリシーに含めるコンテンツに関するその他のアイデアについては、米国司法省の「A Framework for a Vulnerability Disclosure Program for Online Systems」をご覧ください。
プログラム ポリシーの関係者
プログラム ポリシーの草案を作成する際には、ステークホルダーとの連携方法を検討してください。さまざまなチームから、ポリシーに組み込む考慮事項に関する入力が提供される場合があります。
| 関係者 | 考慮事項 |
|---|---|
| 法務 |
|
| IT |
|
| エンジニアリング |
|
| PR |
|
| セキュリティ |
|
研究者に対する約束
研究者約束では、ポリシーに記載されているテスト ガイドラインに従って誠意をもって行動する、参加する研究者に対する組織のコミットメントについて説明します。たとえば、特定の期間内に受信するすべてのセキュリティ レポートに対応するとともに、どの脆弱性レポートを受け入れて修正するかの判断を伝えるというコミットメント。
例:
<組織名> は、セキュリティ研究者と協力して Google のシステムとサービスの脆弱性の特定と修正に取り組みます。誠意を持って行動し、このポリシーに定めるガイドラインを遵守する限り、Google は以下の事項の約束をするように最善を尽くします。- 3 営業日以内に脆弱性レポートへの最初の回答をお願いします。
- 10 営業日以内に脆弱性レポートを承認（修正予定）か拒否（報告を誤検出または許容可能なリスクとして識別する）を決定する
- Google が受け付けたレポートの修正に関する最新の進捗状況
プログラム ポリシーにセーフハーバーの文言を導入すると、研究者が誠意を持って行動し、ポリシーに記載されているすべてのガイドラインに従う限り、システムに対するテストのために法的措置が取られることはなくなります。
テストに関するガイドライン
テスト ガイドラインには、VDP の対象となるセキュリティ テストと、対象範囲外であり研究者による回避が必要なテストが記載されています。研究者が注目してほしい特定の種類の脆弱性がある場合は、このセクションでそれを強調することをおすすめします。
例:
セキュリティ テストを実施する際は、次のガイドラインを遵守してください。
- 自身のアカウントとデータに対してのみテストを行います（例: テスト アカウントを作成する）。他のユーザーのデータにアクセスする可能性がある脆弱性を発見した場合は、テストを進める前に、Google にご確認ください。
- テストで誤って他のユーザーのデータにアクセスした場合は、Google までお知らせください。また、そのようなユーザーデータは保存しないでください。
- サービス拒否状態や本番環境サービスの低下につながるテストは実行しないでください。
- ソーシャル エンジニアリングは、このプログラムの対象外です。組織やユーザーのソーシャル エンジニアリングは行わないでください。
Google では、特に次の種類の脆弱性と影響に関心があります。
- リモートコード実行
- 機密データ（セッション情報など）へのアクセスにつながる XSS
- 機密データや機能へのアクセスを引き起こす SQL インジェクション
- 機密データや機能へのアクセスにつながるビジネス ロジックの欠陥
次のような脆弱性は、誤検出や許容されるリスクとして
拒否される可能性が高いため、あまり重要ではありません。
- 状態変更機能のないページに X-Frame-Options ヘッダーがない
- 未確認の自動スキャナの結果
- 悪用される可能性が低い問題、または現実的なセキュリティに影響を与えない問題
範囲
スコープでは、研究者がテストできるアセットと、VDP の一部と見なされないアセットを定義します。スコープは慎重に検討し、チームに過負荷にならないように可能な限り拡大する必要があります。対象範囲に回答する意欲が高いほど、セキュリティ研究者から関与する可能性が高くなります。ただし、チームが受信レポートに対応できなくなるほど、スコープを広範囲にしないでください。まずはスコープ内のアセットをいくつか検討します。受け取るレポートの量がよくわかるように、範囲を広げます。時間をかけて VDP を一般公開する前に、すべての項目を対象範囲に含めてください。
プログラム ポリシー内でスコープを定義する方法に関しては、各アセットまたは領域の詳細を追加することで、セキュリティ研究者はあなたにとって何が重要で、どこに重点を置くべきかを理解しやすくなります。また、アセットを安全にテストする方法に関するヒントを含めることもできます。次の例をご覧ください。
| Asset | mail.example.com |
|---|---|
| 説明 | ユーザーがメールにアクセスするためのプライマリ ドメイン。 |
| 主な脆弱性と影響 |
|
| 却下される可能性が高い問題 |
|
| テストのガイドライン | テストは、ご自身が所有するアカウント、またはテストに対する明示的な同意があるアカウントでのみ実施してください。テスト アカウントを作成する場合は、ユーザー名のどこかに「vdptest」を含めます。テスト アカウントは mail.example.com/new で作成できます。 |
これはかなり詳細な内訳です。または、対象範囲内のアセットと対象範囲外のアセットの簡単なリストを含めることもできます。
サポート範囲内
- mail.example.com
- example.com
サポート対象外
- blog.example.com
VDP のリソースの割り当て
VDP を開始する前に、特定のリソースを用意する必要があります。次のリソースが必要になります。
- 受信した脆弱性レポートの確認
- ハッカーとのコミュニケーション
- アセット所有者の検索とバグの報告
- バグの修正
- 脆弱性の管理 / 修復のフォローアップ
主な関係者を再確認
まだの場合は、以前に VDP について話し合った主要な関係者との会話を再度確認し、VDP の開始スケジュールに合わせて調整するとともに、開始に必要なリソースをキューに入れます。たとえば、エンジニアリング リーダーと連携して、リリース後最初の数週間でセキュリティ バグが大量に処理されることにチームが備えられるようにすることをおすすめします。セキュリティ チーム内で、検出システムと対応システムのアラートをトリアージする担当者が VDP のリリース日を認識し、テスト開始時により多くの時間とリソースを割り当てることを検討します。また、VDP の日常業務をサポートするチームを作る必要もあります。
チームの構築
VDP を実行するには、割り込みベースの運用作業が相当量必要です。送られてくるすべての脆弱性レポートの確認、技術的検証、対応を行い、バグをすべて報告し、ステータスを追跡し、最新情報を研究者に伝えると、すべて自分で作業ミスをするかもしれません。大規模なセキュリティ チームがなくても、セキュリティ志向のボランティアを見つけて、VDP の運用と実行を支援するチームの構築を手伝ってもらいましょう。最終的に VDP の成功に責任を負う、定義された「オーナー」または「リーダー」が必要ですが、そのリーダーをサポートするチームも必要です。
勤務スケジュールを作成する
リソースを確保し、VDP のサポートに前向きになったら、勤務スケジュールを設定してその体制を整えます。これは任意の方法で作成できますが、毎週ローテーションするのが一般的な方法です。その週の勤務中は、次のことを行ってください。
- トリアージ - 受信した脆弱性レポートを確認します。
- 脆弱性管理 - 既存の脆弱性をプッシュフォワードします。
- 過去勤務週に報告されたバグを確認し、重大度基準と修復タイムラインに基づいて修復が進行していることを確認します。
- オーナーを見つけることのヒントを参考に、オーナーにこれらのバグに対処するよう説得してください。
- コミュニケーション - 既存のレポートに関する最新情報をセキュリティ研究者に提供します。
- 研究者は既存のレポートの更新を積極的に要求する場合があります。これを確認し、必要に応じて対応します。
- 脆弱性が修正された場合は、研究者にその旨を伝え、彼らの努力が組織にポジティブな変化をもたらしたことを伝えます。修正に漏れがないかどうかや、修正がなんらかの方法で回避される可能性があるかどうかを研究者に依頼するテンプレート言語を含めることもできます。
受け取るレポートの数、レポートの複雑さ、担当する個人のスキルや知識によって、勤務に数時間から 1 週間かかることもあります。オンデューティ ローテーションを成功させるためのヒントは次のとおりです。
- 特に重い週には出勤をサポートできるように、チームの準備を整えます。
- 適切な引き継ぎプロセスを用意します。次の担当者が直ちに対応しなければならない問題がある場合は、引き継ぎのメモを作成するか、週末にリアルタイムで会話します。
- 自動スケジュールを作成すると、全員が自分の勤務時間を把握できます。個人の定期的なカレンダー エントリを作成するのと同じくらい簡単です。
- 特に VDP の開始前には、担当する人物が週を思い出し、サポートが必要かどうかを再確認します。ローテーションに参加する経験の浅いリソースが多い場合は、より多くの上級リソースが連携して、従業員が安心して参加できるようにし、立ち上げ時に質問できるようにします。
- 週単位で入れ替える柔軟なプロセスを用意する。どうしても緊急事態で 1 週間の間に休暇を取ったり、誰かが有給休暇を取得したりすることになるでしょう。そのような場合は、全員のスケジュールに合わせて、必要に応じて週を入れ替えるようチームに促します。
- 作業内容を記載したドキュメントと作業内容を記載した「クイック リファレンス」を作成します。
自社かサードパーティかの判断
これまでのガイダンスのほとんどは、社内で VDP を構築して実行することに基づいています。VDP の作成と実行に役立つさまざまなコンサルティング サービスやプラットフォームを利用できます。通常、こうしたサードパーティには費用がかかりますが、VDP を作成、リリース、実施する方法についてのガイダンスとして役立ちます。さらに、受信する脆弱性レポートの確認、ハッカーとのコミュニケーションの処理、有効なレポートのみのエスカレーションを行うトリアージ サービスを提供していることもあります。このプロセスを社内で構築するか、サードパーティのプラットフォームを使用するかは、要件と利用可能なリソースによって決まります。予算が多くても人員が少ない場合は、プログラムの実行にサードパーティを利用することが合理的です。そうでない場合は、時間をかけてプログラムを自作する価値があるかもしれません。
レポートの受信
サードパーティのプラットフォームを使用する場合は、ハッカーがユーザーに直接報告を送信する手段を用意する必要があります。プログラムを社内で構築する場合は 自分で構築する必要がありますこれは、Issue Tracker でチケットやバグを自動的に作成するメールアドレス（security@example.com など）の場合もあれば、プログラム ポリシーと同じページからリンクまたは同じページからリンクされている必須のフォーム項目を含むウェブフォームである場合もあります。どのような形式であれ、レポートを受け取りたい形式をハッカーに伝えるために、チャンスを逃さないようにしましょう。ハッカーに対して、特定の形式でレポートを送信するよう依頼すれば、必ず報告できるとは限りませんが、報告しても問題はありません。レポート送信フォームでリクエストする内容の例を次に示します。
タイトル: [問題を 1 行で説明してください。例: "mail.example.com の XSS を 1 行追加してください。
結果的にセッションが盗まれます"]
1.
2.
3.
攻撃のシナリオと影響: [これを悪用する方法、セキュリティ上の
影響]改善策: [必要に応じて、この問題の修正方法に関するアドバイスがあれば、ここに追加します。]