ホワイトボックスとブラックボックス
各形式のテストの相対的な長所と短所は何ですか？
つまり静的コード分析とランタイム/動的侵入テストの違いは何ですか？
それぞれの長所と短所は何ですか？一方が他方よりも望ましい状況はありますか？
ここで本当に良い答えがいくつかありますが、私が追加することが重要だと思ういくつかの追加ポイント：
- @atdreが言及したように、それは/であってはなりません。または、これらは2つの異なる生き物であり、それらは異なるものを測定します。可能であれば、両方を実行する必要があります。
- また、@ atdreが言ったように、ホワイトボックス+ブラックボックスでさえテストでは不十分です。適切なリスク管理、分析など、全体的なSDLのすべてを含め、安全を確保するために必要なその他の作業があります。
- 要点は...通常、Blackboxはより高速で、多くの場合は桁違いです。ホワイトボックス（コードレビューを含む）は通常、さらに多くの作業を必要とします。
- ブラックボックス（つまり、ペンテスティング）は通常、合計だけでなく1時間あたりのコストもホワイトボックスよりも安価です。
- ホワイトボックスよりも高品質のサードパーティのブラックボックスプロバイダーがあります-合計ではなく、本当にが何をしているのかを知っているプロバイダーのみを数えます。 （またはそれは私の認識だけですか？）
- WBはしばしばBBよりもはるかに深い脆弱性を発見します。
- WBは、BBがバイパスできなかった（フィルターがどのように構築されているかを知るまで、灰色のボックステストに向けた別のポイント）、欠陥のあるフィルターを見つけることがよくあります。
- BBがテストすることさえできない欠陥の多くのタイプがあります-例えば。監査ログ、暗号欠陥、バックエンドの強化など.
- BBはシステム全体をテストでき、コード以外のすべての保護機能（WAF、IPS、OSの強化など）を備えており、WBはアプリケーションレベル（コード/デザインなど）にのみ存在します。これは両方の方向に進む可能性があることに注意してください-あなたがベクトルを知っていればあなたがバイパスをバイパスすることができるだろうにもかかわらず、BBスキャンを完了できないことがあります保護。
- 同様に、BBはサブシステム間の誤った相互作用を発見することができ、WBは通常それを逃します。これを、単体テストとシステムテストとで比較してください。
- 多くの場合、WBはシステムが完成するかなり前に実行できます。BBはビルド、コンパイル、起動して実行する必要があります（できれば、ほとんどの機能的なバグを取り除く必要があります）。これにより、ライフサイクルの早い段階でレビューを行うことができる場合に、SDLをより効率的にすることができます。
- 一方、システムがすでに稼働している場合は、BBを開始するのは簡単ですが、WBを実行する（正しく実行する）場合は、すべてのソースコード、ライブラリ、ツールなどを探し出す必要があります。サードパーティ、COTSなどのため、ソースコードさえありません。
この質問は、The Art of Software Security Assessmentの第4章で最もよく扱われていると思います。シュー、そしてジョン・マクドナルド。
参照としてそれがなければ、最良の方法は、ブラックボックステストを使用して「ヒット」（またはトレース、別名カバレッジ）を決定する際に、ソースコードとともにランタイムデータを使用することですが、脅威モデルの後のみです。システムの一般的なアーキテクチャはよく知られています。
著者はまた、候補点戦略と組み合わせると安全な静的コード分析が好きであるように見えますが、これらは以下が真でないと仮定すると、値が大きく異なる可能性があると私の意見ではあります：
- 言語とその基本クラスライブラリは、安全な静的分析ツールでサポートされている必要があります。
- 通常、システム全体が使用可能である必要があります。つまりすべてのサードパーティ/コントリビューションコンポーネントと外部ライブラリを含むビルド可能なソースコードを含める必要があります。システムコンパイラ、VM、または元のシステムの他のアーティファクトを含めることもできます。
- 基本クラスライブラリの一部ではないすべての外部コンポーネント/ライブラリには、安全な静的分析ツールのsource-sink-passthruデータベースで定義されたソースとシンクが必要です。一部のパススルー（つまりフィルター）の複雑さは、実装または実装者によって異なる可能性があるため、ほとんどの場合、カスタム構成が必要です。
- 特定のパターンまたはアーキテクチャコード要素をさらに使用すると、他のバリエーションが発生し、最新の安全な静的分析ツールでは不可能なカスタマイズが必要になる場合があります。
上記の理由と、NIST SATEの調査（NIST SAMATEによって行われた）で述べられた理由のため、ホワイトボックス分析で使用するために多くの安全な静的分析ツールを推奨するのは難しいと思います。ほとんどの場合、ソースコードを上から下に読むことを含む可能性が最も高いコード理解戦略を使用する方が簡単です。これは、マネージコードルートキットなどを探す場合に非常に重要です。
アプリケーションをテストおよび監査/評価する代わりに、主にテクノロジーにとらわれない別のアプローチを採用します。私の提案は、各アプリの現在実装されているアプリケーションセキュリティコントロールと共にアプリインベントリを含むアプリケーションセキュリティリスク管理ポータルを実装することです。初期のベースラインの後、アプリケーションのセキュリティ管理策は、MITRE CWE、SAFEcode、OWASP ASVSなどの業界標準に対して評価する必要があります。次に、ギャップ分析（これは標準的なリスク管理用語であり、ISO 27001または同様のものに基づく情報セキュリティ管理プログラムに実装した場合に最もよく機能することに注意してください）を使用して、最適なアプリケーションセキュリティ管理と取得するパスを決定できます。現在実装されているコントロールから必要なコントロールへ。
より良い結果を得て、プログラムの成功を測定するために、ホワイトボックスまたはブラックボックステストなどのリスク評価アクティビティを実行する前に、このリスク管理ポータルを実装する必要があります。
ブラックボックス
- 長所：簡単、迅速、簡単なテスト
- 短所：アプリケーションの一部をテストできない場合があります（ハッシュアルゴリズム、セッションIDエントロピーなどをチェックするため）。アプリケーション全体がテストされたかどうかはわかりません
ホワイトボックス
- 長所：ソースコードをチェックする機能（時間を節約-パラメータがどこでも安全に使用されていることが確認できれば、SQLインジェクションをテストする必要がありません）; GUIを使用してアクセスできない/テストできないアプリケーションの部分をテストできます
- 短所：テストは本当に複雑になる可能性があります
一般に、ホワイトボックステストでは、ソースコードに飛び込んで完全な侵入テストを実行できますが、ブラックボックスは簡単、高速、シンプルですが、非常に時間がかかる場合があります。私はグレーボックステストを好む-ブラックボックスメソッドを使用し、開発者へのインタビュー/アプリケーションの特定の部分（認証、セッション管理、構成管理、 ...）。