このセクションでは、脆弱性開示プログラムの立ち上げと実行を成功させるための準備方法について詳しく説明します。特定したギャップを埋める方法についての実際的なアドバイスも含まれます。
バグの発見
外部のセキュリティ研究者とともに既存のセキュリティ プログラムを強化することは、複雑な問題を見つけ、脆弱性を曖昧にする優れた方法です。ただし、VDP を使用して内部で発見された基本的なセキュリティ問題を検出すると、リソースの無駄になります。
アセット管理
バグを探すとき、何から始めればよいかを知るための唯一の方法は、何が存在するかをよく理解しているかどうかです。100 個のセキュリティ ツールを購入できますが、特に、これらのアセットを検出してセキュリティ評価を行う方法がない場合、チームがアプリケーション、システム、サービスを自分の知らないうちにアドホックに立ち上げているとしても違いはありません。新しいアプリケーション、システム、サービスの立ち上げを支援する個人やチームに、何が起こっているか、誰が所有するかのインベントリを作成、維持するためのプロセスがあるかどうかを確認します。現行のプロセスがない場合は、こうしたチームと協力してプロセスを構築する絶好の機会です。攻撃対象領域を特定するには、まず組織のアセットを理解することが重要です。このプロセスの一環として、セキュリティ チームは新しいインフラストラクチャ実装の開発に参加し、セキュリティ レビューを行う必要があります。アセットとオーナーの広範なインベントリを用意することをおすすめします。この種のインベントリは、特定のシステムを一時的にシャットダウンする必要がある新しいパッチを適用する場合に便利です。通知が必要な個人またはチームと、影響を受けるシステムのロードマップを提供します。堅牢なアセット管理プロセスを確立することで、プロセスの早い段階でオーナーを特定し、定期的に更新し、組織全体のすべてのシステムが意図したとおりに運用されるようになります。
先を見越したアセット管理に加えて、組織に属するアセットを特定するために実装できる事後対策も検討しますが、標準化されたアセット管理プロセスの見落としをすり抜けています。たとえば、VDP やバグ報奨金プログラムに参加するセキュリティ研究者が使用するのと同じ「調査」プロセスを使用できます。たとえば、インターネットに接続する IP 範囲や組織に属するドメインをスキャンして列挙する無料のオープンソース ツールを利用できます。Google で「バグ報奨金調査」を検索すると、気づかなかった組織のアセットを特定するためのさまざまなヒントとコツが表示されます。
基本的な脆弱性スキャン
セキュリティの問題を見つける必要がある場所に関する確固たる基盤が確立されたので、次は実際に行う方法を詳しく見てみましょう。組織のリソースに応じてさまざまな深さがありますが、脆弱性開示プログラムを通じて、社内のセキュリティ対策と外部のハッキング コミュニティのバランスを取る必要があります。このバランスは、使用可能なリソースに応じて、組織ごとに異なります。
ツールを選ぶ
脆弱性の特定に役立つさまざまなツールがあります。脆弱性スキャンツールには、無料で利用できるものと有料のものがあります。どのツールを選ぶべきかは、個々のニーズによって異なります。
- 組織の要件
- 各ツールが要件をどの程度満たしているか
- ツールのメリットが費用（財務と実装）を上回る場合。
この要件テンプレート（OpenDocument .ods、Microsoft Excel .xlsx）を使用すると、さまざまなツールを要件に照らして評価できます。テンプレートには要件の例が含まれていますが、セキュリティ チーム、IT チーム、エンジニアリング チームと協議して、必要な機能を調整する必要があります。脆弱性開示プログラムを開始する前に、少なくとも外部公開のアセット（ウェブサイト、API、モバイルアプリなど）に対して脆弱性スキャンを実行できる必要があります。これにより、外部のセキュリティ研究者にアセットとサービスのテストを依頼する前に、簡単に検出可能な脆弱性を見つけて修正できます。
スキャンの設定
自動脆弱性スキャンでは、多くの問題を検出できますが、誤検出が発生する可能性もあります。そのため、影響を受けるチームと共有する前に結果を検証するためのリソースが必要です。スキャンが定期的に実行されるようにプロセスを実装し、スキャンの結果に確実に対応できるようにする必要があります。これは組織ごとに異なりますが、少なくとも以下について決定する必要があります。
- スキャンの頻度
- 連続
- 毎週
- 月に 1 回
- スキャンされているアセット
- 認証情報
- 認証されたスキャンと未認証のスキャン
- （ヒント: 認証情報を使用してスキャンしない場合、VDP の開始時にセキュリティ研究者が認証情報を使用してテストを実施すると、特定された脆弱性が急増する可能性があります）
- 役割と責任
- スキャンの実行を担当するチームメンバーを特定する
- 必要に応じてローテーションを設定する
- スキャン結果
- スキャン結果の確認
- 検証済みの脆弱性のバグを報告する
- バグを修正するためのオーナーの特定
- 修復に関してオーナーにフォローアップする
特定されたセキュリティの問題を確実に修正する方法については、このガイドの後半のバグを修正するのセクションで説明します。
セキュリティ審査プロセス
脆弱性スキャンは、事後対応として組織のセキュリティ上の問題を特定する優れた方法ですが、セキュリティ レビュー プロセスを実装すると、そもそも脆弱性の侵入を防ぐことができます。このガイドでは、セキュリティ審査という用語は、セキュリティ チームのメンバーによる手動審査がトリガーされる状況を指します。通常、リスクが高いと判断された場合は、変更をブロックする権限も必要です。セキュリティ チームが危険な変更をブロックできない場合でも、リスクを文書化するためのプロセスを用意する必要があります。こうすることで、変更を推進する人は誰でも、関連するリスクを把握し、そのリスクをプロアクティブに受け入れることができます。
セキュリティ審査の基準
セキュリティ審査はいつ実施すればよいですか？セキュリティ審査をトリガーする条件のセットを作成することで、全員が同じ認識を持つことができます。セキュリティ審査が必要になるシナリオの例を以下に示します。
- ユーザーの機密情報に関連する新しい機能を提案する
- ユーザーが地図上で現在地を共有できる新機能
- 自宅の住所、生年月日、電話番号など、機密情報になり得る情報をユーザーにリクエストする
- 既存の機能に対するメジャー アップデートが実施されます。
- オプトアウトの機会を与えることなく、既存のユーザーデータを取得し、ユーザーが予期していない新しい方法で使用する
- 認証、認可、セッション管理に関連する機能の変更
- 会社の本番環境の変更
- ネットワーク構成の変更（特に、サービスが外部に公開される可能性がある変更）
- ユーザーの機密情報を扱う新しいソフトウェアのインストール（不正使用された場合、ユーザーの機密情報にアクセスするために間接的に使用される可能性があるもの）
- 新しいシステムやサービス立ち上げ
- 新しいベンダーとやり取りする、または既存のベンダーとの連携方法を変更する。
- ユーザーの機密情報を扱う新しいベンダーをオンボーディングする
- 既存のベンダーとの連携方法が変更されたため、ベンダーが機密性の高いユーザーデータを処理することになる
これはすべてを網羅したリストではありませんが、どのような変更をセキュリティ レビューが必要とするかを考えるための指針になります。セキュリティ レビューが必要なものと不要なものの基準を定義するときに、組織全体の主な関係者と話し合い、以下のことを確認します。
- 関係者は、この基準を確認してフィードバックを提供することができます。
- 関係者が要件に同意し
- 関係者が事前にセキュリティ審査を申請することに同意する
この基準と、セキュリティ審査をリクエストする方法（たとえば、セキュリティ チームがモニタリングしているキューにバグを報告する方法）を文書化して、組織がこのプロセスを簡単に行えるようにします。
セキュリティ審査のリソース
セキュリティ レビューは、自動スキャンとは異なり、実行に必要なリソースを大量に消費する可能性があります。どのセキュリティ チームも、1 日に多くのタスクを完了できる時間は限られているため、条件に基づいて生成されるセキュリティ レビューの数を見積もる必要があります。チームが手に負えなくなり、遅れをとっていると、機能のリリースを待っているチームがセキュリティ チームに不満を抱くことになります。その結果、組織内に文化的な変化がもたらされ、セキュリティ チームがパートナーではなく阻害要因と見なされる可能性があります。セキュリティ審査プロセスが効率的でない場合、多くの個人やチームが完全に回避しようとします。リソースが厳しい場合は、セキュリティ レビューを要求する基準を緩和し、残存リスクをいっそう受け入れることを検討してください。セキュリティ審査を実施するためのリソース不足の結果としてインシデントが発生した場合、セキュリティ リソースを追加する必要性を正当化できます。
セキュリティ審査の実施
実行するセキュリティ レビューとその実行方法を決定するには、取得元となる優先キューが必要です。適切な優先順位付けに必要な情報を使用して、組織内の他のユーザーがセキュリティ審査をリクエストするための標準化された方法を作成します。たとえば、変更の概要や影響を受ける可能性があるユーザーデータの種類など、変更の性質などの項目を含むアンケートを検討してください。これらの質問への回答に基づいて、潜在的なセキュリティ レビューを高リスク、中リスク、低リスクの変更に自動的に分類できます。変更のリスクが高い場合は、より詳細なセキュリティ審査プロセスが必要になることがあります。変更のリスクが低い場合は、より軽量なセキュリティ審査プロセスを実装することで、必要なリソースを減らし、プロセスを迅速化して、ビジネスを改善できる場合があります。セキュリティ審査キューの管理を担当するチーム内にローテーションを設定し、チームのメンバーが新しいセキュリティ レビューを受けられるようにし、既存のセキュリティ レビューの進捗状況をフォローアップすることを検討してください。セキュリティ審査の実際のプロセスは、調査対象によって異なります。たとえば、モバイルアプリの新機能では、セキュリティ エンジニアがコードをレビューして潜在的な脆弱性を探すことが必要になる場合があります。インストールされる新しいソフトウェアは、アクセス制御が適切に設定されていることを確認できるように、レビューが必要になる場合があります。外部のベンダーと連携する場合は、まったく異なるプロセスが発生する可能性があります。参考として、Google のベンダー セキュリティ評価アンケートをご覧ください。
バグの修正
バグの発見は重要ですが、セキュリティはバグの修正後にのみ改善されます。組織にとってどのようなリスクがあるかを把握することはよいことですが、そのリスクに効率的に対処できる方が得策です。
脆弱性の管理
脆弱性は、内部の取り組み（脆弱性スキャンやセキュリティ レビューなど）、サードパーティの侵入テストと監査、VDP の正式リリース前にサポート チャネルを通じて通知する外部のセキュリティ研究者など、さまざまなリソースから発生します。組織には、新しい脆弱性と既存の脆弱性を分類し、それらが適切な関係者に通知され、正しく優先順位付けされ、タイムリーに修正されるようにする必要があります。VDP を開始すると、新しい脆弱性のストリームが脆弱性管理プロセスに入ります。これらの脆弱性に対処するための堅牢なプロセスを確立することで、修復の進捗状況を追跡し、外部のセキュリティ研究者からの更新リクエストに対応できます。脆弱性に迅速に優先順位を付け、修復のタイムラインを VDP の参加者と伝えることができれば、セキュリティ研究者のコミュニティとの関わりが深まり、組織のセキュリティの評価も向上します。以下のセクションでは、VDP を立ち上げる前に準備しておく必要がある脆弱性管理プログラムのさまざまな側面について説明します。
重大度の基準と修復のタイムラインを確立する
脆弱性の重大度と、各重大度に対する理想的な修正タイムラインについて共通の文言を作成すると、組織での標準的な期待値の設定が容易になります。すべての脆弱性を緊急事態のように扱うと、組織はリソースを使い果たし、セキュリティ チームに対して怒りを感じます。すべての脆弱性の優先度が低いと判断されると、脆弱性は修正されず、侵害のリスクが高くなります。どの組織にもリソースには限りがあるため、重大度のランキングを確立する必要があります。このランキングは、脆弱性の重大度と、各重大度に関連付けられた予想される修復タイムラインを理解するために役立つ基準を提供します。重大度のガイドラインのセットを作成し、組織内の主要な関係者と共有してフィードバックを受けます。たとえば、エンジニアリングが重大度の基準の作成に関与している場合、エンジニアリング チームはこれらの基準に賛同し、指定された期間内に脆弱性を修正する際にそれらの基準を遵守する可能性が高くなります。この重大度のガイドラインは、ビジネスに固有のリスクによって異なります。脅威モデリングの演習で、組織にとってどのような脅威が最も高く、影響を与えるかを考え、各重大度カテゴリに該当する問題の例を含めてください。以下は、金融組織の重大度の基準と改善のタイムラインの例です。
| 重大度 | 説明 | 修復のタイムライン | 例 |
|---|---|---|---|
| 重大 | ユーザーや Google のビジネスに差し迫った脅威をもたらす問題。 | オーナー: 脆弱性の修正を担当するプライマリ オーナーを 8 時間以内に特定する必要があります。通常の営業時間外でも、必要に応じてリソースの呼び出しやページングを行います。 修正方法: 3 営業日以内に、問題自体を修正するか、少なくともリスクを軽減する必要があります。 |
すべてのユーザーの財務記録を含む本番環境のデータベースが侵害される。 攻撃者が、Google 独自の投資アルゴリズムなどの企業秘密にアクセスする。 攻撃者が Google の内部ネットワークまたは機密性の高い本番環境システムにアクセスするなどのアクティブなインシデント。 |
| 高 | 悪用された場合、重大な損害をもたらす可能性のある問題。 | オーナー: メインのオーナーは 1 営業日以内に特定されます。 修正方法: 10 営業日（約 2 週間）以内。 |
ユーザーの機密性の高いデータや機能へのアクセスにつながる可能性がある脆弱性（ユーザーが別のユーザーから資金を盗むなど）。 |
| 中 | 悪用が困難な問題や、直接的な損害につながらない問題。 | オーナー: メインのオーナーは 5 営業日以内に特定されます。 修正方法: 20 ～ 40 営業日（1 ～ 2 か月）以内。 |
自動スキャナによって特定された検証済みの問題（既知のエクスプロイトのないセキュリティ アップデートのパッチなど）。 さらなる攻撃につながる可能性が高い情報開示の問題。 悪用されるおそれのあるレート制限の問題（例: ユーザーのパスワードを継続的に推測できる）。 |
| 低 | 影響が最小限の問題。主に既知の問題のロギングに使用されます。 | 指定されたタイムライン内でオーナーを見つける、または修正するための要件はありません。 | 可能性は低いものの、外部から情報にアクセスする必要がない情報開示。 |
虫の手入れ
ここで言っているのはヘアカットではなく、簡単に修正できるようにバグを正しくフォーマットすることです。前の表をガイドラインとして使用して、独自の重大度の定義を設定します。これらの定義は、バグをさまざまな重大度に分類し、オーナーに伝えるために使用されます。
各脆弱性に重大度を割り当てるだけでなく、バグをチームが簡単に処理できる標準形式にする必要があります。脆弱性は、さまざまな形式で脆弱性管理プロセスに入ります（自動スキャナの結果、セキュリティ審査の手作業による評価など）。時間をかけて各脆弱性を標準形式に変換することで、受信側のチームが問題をすばやく把握して対処できる可能性が高くなります。
この形式またはテンプレートは、組織や、オーナーが割り当てられたバグを修正する際に最も関連する情報によって異なりますが、使用できるテンプレートの例を紹介します。このテンプレートは、後で研究者向け脆弱性開示プログラム提出フォームを作成するときに再利用できます。
タイトル: <シナリオを 1 行で説明: 脆弱性のタイプと影響を受けるアセットやサービスなど。 重大度を含めるか、問題トラッカーのフィールドに重大度をマッピング> 概要: <脆弱性の説明とそれが重要な理由> 再現手順: <この脆弱性が直接的にどのように影響するかを示す手順、この脆弱性の存在を示す手順の説明、この脆弱性の存在を示す手順の説明>重大度が「高」の潜在的な脆弱性の例を次に示します。
タイトル: [高] プロフィール ページの安全でない Direct Object Reference（IDOR） 概要: IDOR がアプリのプロフィール ページ機能内で発見されました。この IDOR は、他のユーザーのプロフィール（氏名、自宅の住所、電話番号、生年月日など）の表示や編集を行う権限をユーザーに付与する不正なアクセス権をもつものでした。ログを確認したところ、この問題はまだ悪用されていないようです。この問題は内部で発見されました。再現手順:
- Burp Suite などのプロキシを設定して、アプリがインストールされているモバイル デバイスのトラフィックをインターセプトします。
- プロフィール ページにアクセスし、関連する HTTP リクエストをインターセプトします。
- profileID=###### を profileID=000000（テストユーザー）に変更し、HTTP リクエストと一緒に送信します。
- アプリにユーザー 000000 のプロフィールが表示され、その情報を表示、編集できるようになります。
攻撃のシナリオ / 影響: すべてのユーザーがこの脆弱性を利用して、他のユーザーのプロフィールを表示、編集できます。最悪のシナリオでは、攻撃者がシステム全体ですべてのユーザーのプロファイル情報を取得するプロセスを自動化できる可能性があります。Google ではまだこの問題が悪用されていないと考えていますが、これを標準的な重大度「高」の問題として扱うことが重要です。悪用の証拠が認められた場合、重大度は「重大」に発展する可能性があります。 改善手順: サーバーサイド チェックを実装して、リクエストを行ったユーザーが、profileID の値によってリクエストされたプロフィールを表示または編集できるようにします。たとえば、ログインしている Alice のプロファイル ID は 123456 で、プロファイル ID 333444 をリクエストしているのが確認されると、ユーザーに対してエラーが表示され、このユーザーのプロファイルへのアクセスがログに記録されます。IDOR とその修正方法について詳しくは、このバグに関する OWASP の資料をご覧ください。
さまざまなソースから脆弱性を標準的な形式に変換する方法を見つけることで、時間と手作業を節約できます。脆弱性を増やすと、改善手順に共通のテーマが見つかる場合があります。汎用的なバグ形式のテンプレートに加えて、一般的な脆弱性のタイプ用に追加のテンプレートを作成することもできます。
検出結果のオーナー
脆弱性管理の最も困難な側面の一つは、バグの修正を支援するオーナーを特定することと、スケジュールどおりにバグ修正することにリソースを集中させるための賛同を得ることです。アセット管理プロセスを設定済みの場合は、この設定が少し簡単になります。そうでない場合は、これが動機付けとなる可能性があります。組織の規模によっては、オーナーを見つけるのが非常に簡単なこともあれば、非常に複雑なこともあります。組織が成長するにつれて、新たに発見されたセキュリティ問題の修正責任者を決定する作業も増加します。運用中のローテーション ローテーションの実装を検討してください。担当する人は、未割り当ての脆弱性の確認、所有者の追跡、重大度に基づく優先順位付けを行います。脆弱性の修正を担当する人物を特定してバグに割り当てることができたとしても、実際に修正に時間を費やすようユーザーを説得する必要もあります。この方法は、チームや個人、それぞれが取り組んでいる他の項目によって異なります。重大度の基準と修正タイムラインについて組織の賛同が得られていれば、それらを参照できますが、バグを修正してもらうために特別な説得が必要になる場合もあります。脆弱性の修正を推進する一般的なヒントは次のとおりです。
- 理由を説明する: 修正のために脆弱性が割り当てられると、通常は予期しない作業になります。この問題をタイムリーに修正する必要がある理由（影響 / 攻撃シナリオなど）を説明し、オーナーが理解していることを確認します。
- コンテキストを収集する: 場合によっては、バグを修正するために必要な知識を持つ人物が 1 人だけで、その人が他のタスクに取り組んでいることもあります。これらが何であるか、時間を取って確認してください。短期的にこの脆弱性を修正するよりも、他のタスクの方が重要である可能性があります。修復のタイムラインについて共感と柔軟性を示すことで、好意を得て、脆弱性の修正が必要な人々との関係を強化できます。ただし、あまり余裕を持たせすぎないように注意してください。そうしないと、組織は修復のタイムラインを重要視しません。
- 方法を説明する: バグに修正のアドバイスを含めても、問題の修正担当者が混乱したり、バグの修正方法を学習するために支援が必要になったりする可能性があります。解決策を見つけるのに助けが必要な場合は、教えてください。 オーナーを手助けせずにバグを放置するだけで、組織のセキュリティ チームとの関係が損なわれます。多くの人々を助けることで、現在と将来の脆弱性を修正し、他の人に教える助けにもなります。
- リクエストを調整する: さまざまなチームと個人に、受信した作業リクエストを受け入れて優先順位を付けるための既存のプロセスがある場合があります。チームによっては、すべての受信リクエストをマネージャーから受け取るようにしたい場合もあるでしょう。また、サポート リクエストを標準的な形式で送信したいと考える人もいます。一部のタスクは、スプリントで事前定義されているものに対してのみ機能します。いずれにしても、チームや個人がリクエストを受け付けるために通常使用している形式に合うよう、少し時間をかけてリクエストを調整することで、リクエストが優先され、対応される可能性が高くなります。
- 最後の手段としてエスカレーションする: 上記の方法をすべて試しても、脆弱性の修正を担当する個人またはチームが重大なセキュリティ問題の解決に時間をかけられない場合は、必要に応じてリーダーにエスカレーションすることを検討してください。対象の個人やチームとの関係を損なう可能性があるため、この方法は常に最後の手段とする必要があります。
根本原因の分析
個々の脆弱性を見つけて修正するだけでなく、根本原因分析（RCA）を実行することで、体系的なセキュリティ上の問題を特定して対処できます。どの担当者も限られたリソースしか持っていないため、このステップはスキップしたくなります。ただし、脆弱性データの傾向の分析や、重大または重大度の高いバグの調査に時間を費やすことで、時間を節約し、長期的なリスクを低減できます。たとえば、同じ脆弱性タイプ（インテント リダイレクトなど）がアプリ全体に何度も出現するとします。この脆弱性をアプリに導入しているチームと話をして、大多数のチームが意図のリダイレクトが何であるか、それが重要な理由、または防止する方法を理解していないことに気づくことにしたとします。ここでは、この脆弱性について組織内のデベロッパーに有用な説明とガイドをまとめています。この脆弱性が完全になくなることはないでしょうが、発生率は低下するでしょう。VDP を立ち上げると、サードパーティから報告されたすべての脆弱性が、既存の内部セキュリティ プロセスを通過したものになります。VDP からのバグに対して RCA を実行すると、セキュリティ プログラムを体系的に改善する方法をより深く理解できます。
検出と対応
検出と対応とは、組織に対する潜在的な攻撃を検出して対応するために用意しているツールとプロセスを指します。これは、データを分析して不審な動作を特定する、購入済みのソリューションまたは自社開発ソリューションの形式で実現できます。たとえば、バグの整理のセクションでは、ユーザーが別のユーザーのプロフィールへの不正アクセスを試みるたびにログに記録することについて説明しました。短期間に他のユーザーのプロファイルへのアクセス試行に何度も失敗している場合に、シグナルやアラートが生成される場合があります。状況を確認して手動でアクセスを復元できるまでの間、特定の期間または無期限に、ユーザーがどのサービスにもアクセスできないようブロックするプロセスを自動化することもできます。検出と対応のメカニズムをまだ実装していない場合は、専門のコンサルタントと協力して、組織でデジタル フォレンジックとインシデント対応（DFIR）プログラムを構築する方法を検討してください。検出と対応のメカニズムがすでに存在する場合は、5 人、10 人、または 100 人のセキュリティ研究者がインターネットに接続する攻撃対象領域をテストした場合の影響を考慮する必要があります。これは、ご使用の IDS/IPS（侵入検知および防止システム）に大きな影響を与える可能性があります。
潜在的なリスクは次のとおりです。
- アラートの過負荷: 悪意のある攻撃のように見えるが、実際には VDP に参加しているセキュリティ研究者による承認された通常のテストであるアラートやシグナルの急増。非常に多くのノイズが生成され、実際の攻撃と正当なセキュリティ テストを区別することが困難になる場合があります。
- インシデント対応による誤アラーム: 土曜日の午前 2 時に個人をページングするプロセスを導入している場合、セキュリティ研究者が実際には正当なテストを行うだけのセキュリティ研究者が潜在的な侵害を目覚めて調査することに満足しません。
- セキュリティ研究者をブロックする: 積極的な IPS（侵入防止システム）を導入している場合、脆弱性を特定して報告するために、スキャンや手動テストなどを実行するセキュリティ研究者の IP アドレスをブロックする可能性があります。特に VDP の場合、セキュリティ研究者が 5 分間のテストの後にブロックされた場合は、関心を失い、別の組織のプログラムに集中する可能性があります。その結果、セキュリティ研究者のプログラムに対する全体的な関わりが欠け、脆弱性が発見されない（つまり組織にとって未知）となるリスクが高まります。IPS 自体のトーンを下げたくない場合もありますが、研究者のエンゲージメントを低下させるリスクを軽減するためにできる対策は他にもあります。
これらのリスクへの対処方法は、外部のセキュリティ研究者と連携するためにどのようなアプローチを取るかによって大きく異なります。実際の攻撃をシミュレートするブラック ボックス スタイルのテストが必要な場合は、何もする必要はありません。この場合、研究者のトラフィックによってアラートが生成され、チームはそれに応じて調査と対応を行うための措置を取ることができます。これにより、チームは実際の攻撃に見える対応を練習できるようになりますが、特にテストがブロックされている場合は、セキュリティ研究者との関わりが低下する可能性があります。また、正当なテストの調査に時間を費やしながら、実際の攻撃を見落とす可能性もあります。グレーボックスのアプローチが必要な場合は、セキュリティ研究者と協力して、テスト トラフィックをなんらかの方法で自己識別化することを検討してください。これにより、テストからのトラフィックを許可リストに登録したり、その他の方法でフィルタして、アラート結果から除外したりできます。チームは実際の攻撃と承認済みのテストをより正確に区別できるようになります。また、研究者は侵入防止システムに妨げられることなく、脆弱性を見つけて報告できるようになります。組織によっては、研究者が生成したリクエストのヘッダーに付加できる一意の識別子を申請するためのフォームを送信するよう、セキュリティ研究者に依頼することがあります。これにより、組織は研究者のトラフィックを許可リストに登録できるだけでなく、合意された検査範囲を研究者が超え始めたかどうかを識別できるようになります。そのような場合は、研究者に連絡し、テスト計画を共同で取り組めるまで待つよう依頼してください。