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

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

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

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

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

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

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

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

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

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

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

SSGは、常にQA部門とセキュリティ・レビューの結果を共有しています。セキュリティ結果を使用した特定のテスト・パターンの周知と変更は、セキュリティ・テストの改善に非常に有効なメカニズムです。CI/CDでは、テスト方法が部門を超えたチームに統合されているため、共有が容易になります。長期的には、QAエンジニアのセキュリティに関する意識が向上します。このアクティビティは、QA部門の技術力が高いと効果が上がります。

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

セキュリティ・テストは、自動化された回帰テストの一貫として、機能テストと同時に実行されます。同じ自動化フレームワークで両方のテストが実行され、セキュリティ・テストが日常業務に組み込まれています。セキュリティ・テストは、ライフサイクルの前の段階で特定された悪用ケースから抽出したり、機能テストを適切に調整して抽出することができます。

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

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

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

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

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

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

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

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

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