ソフトウェア・セキュリティ・テスト

セキュリティ・テストには、標準の品質保証プロセスへのセキュリティの組込みを含む、リリース前のテストに関する実践法が含まれます。これには、QAでのスモーク・テストとしてのブラックボックス・セキュリティ・ツール(ファジングテスト)、リスク主導のホワイトボックス・テスト、アタック・モデルの適用、コード・カバレッジ解析などが使用されます。セキュリティ・テストでは、構造上の脆弱性を対象とします。

セキュリティ・テスト・レベル1

[ST1.1: 100] QAがエッジ/境界値条件テストをサポートすることを確認する。

QA活動では、機能テストだけでなく、基本的な敵対テストを実行し、単純なエッジ・ケースと境界条件を調べます。特別な攻撃者スキルは必要ありません。想定される入力を使用して過去の標準の機能テストを行うことには大きな価値があります。QAがこの点を理解すれば、攻撃者の視点に立って考えるきっかけになります。境界値テストについて討議することで、意図的にエッジに探りを入れる攻撃者のように考えることができるようになります(パスワードを繰り返し間違って入力したときにどうなるかを確認するなど)。

[ST1.3: 87] セキュリティ要件とセキュリティ機能を使用してテストを実行する。

QA担当者は、要件とセキュリティ機能から抽出されたテストを使って、宣言型のセキュリティ・メカニズムを検証します。たとえば、テストでは、権限のないユーザーとして管理者機能へのアクセスを試みたり、認証が何回か失敗したらユーザー・アカウントがロックされることを確認します。ほとんどの場合、セキュリティ機能は、他のソフトウェア機能と同様の方法でテストできます。想定される入力と想定外の入力の両方で、アカウントのロックアウト、トランザクションの制限、権限などの要件に基づいたセキュリティ・メカニズムをテストします。ソフトウェア・セキュリティはセキュリティ・ソフトウェアではありませんが、セキュリティ機能のテストは手始めに取り組みやすい方法です。クラウドなどの新しいソフトウェア・アーキテクチャやデプロイメント・モデルでは、新しいテスト手法が必要になる場合もあります。

セキュリティ・テスト・レベル2

[ST2.1: 32] QAプロセスにブラックボックス・セキュリティ・ツールを統合する。

組織で、QAプロセスの一貫として、1つまたは複数のブラックボックス・セキュリティ・テスト・ツールが使用されています。ツールには、一般的ではあるにしても、攻撃者の視点がカプセル化されているので、有用です。IBM Security AppScanやFortify WebInspectなどのツールはWebアプリケーションに適し、ProwlerはAWS上でのデプロイに適しています。他のグループがSSGと共同でツールを適用できる場合もあります。たとえば、テスト・チームがツールを実行し、結果の解釈をSSGに依頼します。アジャイル開発手法におけるテストの統合方法では、ブラックボックス・ツールをツールチェーンに接続したり、エンジニアリング・チームで直接使用することができます。ブラックボックス・ツールを誰が実行するかにかかわらず、テストはSSDLのQAサイクルに適切に統合されている必要があります。

[ST2.4: 15] QAとセキュリティ結果を共有する。

SSGおよびセキュリティ・テスト・データを持つその他の関係者は、常にテスト担当者とセキュリティ・レビューの結果を共有しています。テスト結果を一般的な攻撃パターンやコードの脆弱性の根本的な原因に関する話し合いの基礎として利用することにより、QAはその情報を概括して新しいテスト手法に取り入れることができます。CI/CDでは、テスト方法が部門を超えたチームに統合されているため、共有が容易になります。長期的には、QAエンジニアのセキュリティに関する意識が向上し、組織のコードに応じたセキュリティ・テストを作成する能力が向上する効果があります。

[ST2.5: 9] QAの自動化にセキュリティ・テストが含まれている。

セキュリティ・テストは、自動化されたフレームワークに含まれ、他のQAテストと同時に実行されます。多くのグループはこれらのテストを手動でトリガーしていますが、最新のツールチェーンでは、このようなテストをパイプラインの一部に組み込み、自動化によってトリガーする傾向があります。セキュリティ・テストは、ライフサイクルの前の段階で特定された悪用ケースから抽出したり、機能テスト、開発テスト、セキュリティ機能テストを適切に調整して抽出したり、ペネトレーション・テストで提示された問題の再現方法に関する指針から抽出することができます。

[ST2.6: 9] アプリケーションAPI用にカスタマイズされたファジング・テストを実行している。

QA活動には、組織の重要なAPI用にカスタマイズされたファジング・フレームワークの実行が含まれます。一から構築するか、既存のファジング・ツールキットを使用して作成できますが、カスタム・プロトコル記述の作成や、呼び出すアプリケーション・インターフェイスに関する情報をファジング・フレームワークに組み込むファイル形式テンプレートの作成だけではカスタマイズとしては不十分です。特定のアプリケーション用に明示的に開発されたテスト・ツールを使用すると、ファジング・テストを統合しやすくなります。

セキュリティ・テスト・レベル3

[ST3.3: 2] リスク解析結果を使用してテストを実行する。

テスターは、アーキテクチャ解析の結果([AA 2.1 AAプロセスの定義と使用]を参照)に従ってテストを実行します。たとえば、アーキテクチャ解析の結果として「システムのセキュリティでは、トランザクション規模が小さく、処理中に中断されないことが条件になっている」と判断された場合、トランザクションの中断が、敵対テストの主なターゲットになります。このような敵対テストは、リスク・プロファイルに従って、高リスクの欠陥を優先して作成できます。

[ST3.4: 1] カバレッジ解析を活用する。

テスターは、セキュリティ・テストのコード・カバレッジを測定([ST2.5 QAの自動化にセキュリティ・テストが含まれている]を参照)して、実行されていないコードを特定します。これにより、コード・カバレッジ解析によるセキュリティ・テストの詳細度が向上します。標準で発行されているブラックボックス・テスト・ツールのカバレッジは非常に低く、テスト対象のソフトウェアの大部分が検査されません。このため、テストでは使用しないでください。関数カバレッジ、ライン・カバレッジ、または複数条件網羅などの標準測定値を使用するとカバレッジ解析が容易になります。

[ST3.5: 2] 敵対セキュリティ・テスト(悪用ケース)の構築と適用を開始している。

テストは、悪用ケースを基にテスト・ケースを統合することから始めます([AM2.1 潜在的な攻撃者と関連付けた攻撃パターンと悪用ケースを構築する]を参照)。テスターの意識は、機能の検証から攻撃者の視点に移行します。その1つの方法として、組織の履歴からインシデントを系統的に複製することができます。攻撃者の視点の悪用および誤用ケースは、セキュリティ・ポリシー、攻撃インテリジェンス、標準や組織の上位N位の攻撃リストからも抽出できます([AM2.5 上位N位の考えられる攻撃リストを作成し更新する]を参照)。これにより、機能の検証から、テスト対象のソフトウェアへの侵入に視点が転換されます。