3.1.2 セキュリティテストプロセスを特定のアプリケーションライフサイクルモデルに合わせる

次の種類のライフサイクルプロセスには、セキュリティテストに関する問題があります。そのためライフサイクルに合わせてセキュリティテストを調整することが重要です。

シーケンシャルライフサイクル

このプロジェクトでは、セキュリティテスターは以下の点に注意する必要があります。
セキュリティのニーズとリスクはプロジェクトの初期段階で定義されており、ソフトウェア要件の仕様に文書化されている必要があります。
セキュリティのニーズはプロジェクト中に変わる可能性がありますが、最新のソフトウェア要件には反映されない可能性があります。セキュリティテストは具体的で完全なように見えるかもしれませんが、プロジェクトの後半のリスクにおいては完全でないか最新ではないかもしれません。
セキュリティテストはいつでも実行できますが、プロジェクトの後半で実行されることが一般的です。
シーケンシャルライフサイクルプロジェクトの最後にセキュリティテストの結果に対処するのは難しいかもしれません。

イテレーティブ／インクリメンタルライフサイクル

インクリメンタルプロジェクトは、アプリケーションの小規模で頻繁なリリースを提供します。アジャイルメソッドはこのアプローチの一例です。これらのプロジェクトでは、セキュリティテスターは以下の点に注意する必要があります。
セキュリティのニーズとリスクは、プロジェクト全体を通して（通常はいてレーションまたはスプリントの中で）発生し、要件仕様、ユーザーストーリー、モデル、承認基準、および/またはプロトタイプで定義できます。
セキュリティのニーズとリスクはプロジェクト中に変更される可能性があり、それらが特定されたイテレーションで対処することができます。
セキュリティテストは、プロジェクト全体を通して継続的に実行することができます。
セキュリティリスクの性質によっては、1回の短いリリースサイクルでそれを完全に軽減してテストすることが不可能な場合があります。

商用オフザシェルフ(COTS)

このプロジェクトでは本質的にブラックボックスであり、カスタマイズされていてもいなくても変わりません。セキュリティ更新プログラムやパッチが頻繁に必要とされる範囲で、セキュリティ上の脆弱性が含まれることがよくあります。コードにアクセスできないため、構造解析および構造テストはできません。

オープンソースソフトウェア

これはCOTSの変種ですが、1つ重要な違いがあります。それはコードは世界中から見ることができるということです。これらの製品にはセキュリティ上の脆弱性もあるため、セキュリティパッチを最新の状態に保つことが極めて重要です。セキュリティの脆弱性が公表されると、そのソフトウェアの特定のバージョン（およびそれ以前）のユーザは攻撃の危険にさらされます。

例：シーケンシャルライフサイクルにおけるセキュリティテストプロセス
セキュリティテストは、プロジェクト内の1つのフェーズまたはアクティビティに限定される必要はないことに注意することが重要です。またプロジェクトの承認段階までセキュリティテスト（およびその他のテスト）が実行されないという状況を回避することが特に重要です。プロジェクトの終盤に、発見された欠陥に対処することは特に費用がかかり危険だからです。以下は、シーケンシャルライフサイクルの各段階で実行する必要がある適切なセキュリティテストのタスクを示しています。

要件定義

セキュリティ要件は、組織のニーズを表現するための全体的な要件への取り組みの一環として定義およびレビューされています。これはまたユースケースが書かれる可能性のあるところです。セキュリティテストのアプローチを開発する必要があるのはこの時点です。

分析と設計

通常、ビジネスアナリストの役割を担う人が最初の要件を検討し、ギャップを埋めるようにそれらを改良していきます。システムアナリストやアーキテクトが要件を分析して、ユーザーのニーズを満たすソリューションを提供するための最も最適な方法を提案します。この場合、セキュリティは機能性と非機能性のニーズのうちの1つであり、使いやすさや効率性のようなものもあります。この時点で、セキュリティテストの設計者は、構造と機能の両方のセキュリティの観点から、アーキテクチャと何をテストする必要があるかについてのアイデアを得ることができます。主要なセキュリティテストの目的はこの時点で定義されるべきです。

詳細設計

この時点で、ユーザーインターフェイスとデータベースは設計されています。機能のルールが洗練され、セキュリティテスト設計がより詳細になります。第１のセキュリティテストはモデルに基づいて実行されても構いません。

コーディング／実装

このフェーズは設計仕様がコードとして実装されるフェーズです。
このフェーズは、バッファオーバーフローの欠陥やSQLインジェクションが発生する可能性があるフィールドレベルの編集などのセキュリティ上の脆弱性をテストするなど、アプリケーションの構造をテストする最初の機会となります。静的分析とコードレビューはこの段階で非常に有益であり、セキュリティの観点からコードを調べることを含むべきです。コンポーネントテストは、コードが仕様どおりに機能することを確認するための重要な作業でもあります。コンポーネント間の統合テストは、相互に連携するコンポーネントが小さなアセンブリでのテストに使用できるようになったときにも開始できます。

システムテスト

このフェーズはシステムとサブシステムのテストを行うフェーズです。
システムテストには、ソフトウェア、ハードウェア、データ、手順、およびユーザーがシステムと対話する方法が含まれます。このテストは、ビジネスプロセスをテストするために、本質的にトランザクション型で行います。システムテストのベースは、要件、設計モデル、ユースケース、およびシステムの観点を伝えるその他の仕様です。さらに、さまざまな（サブ）システムがどのように通信しデータをやり取りするかをテストするために、システム統合テストを実行する必要があるかもしれません。この段階でのセキュリティテストでは、ハードウェアとのデータのやり取りが関係するため、より広い視野が必要となります。認証、データストレージ、ファイアウォールの実装、手続き型セキュリティ管理などの、トランザクションのセキュリティをテストできます。

ユーザー受け入れテスト

このフェーズは、テストによって、システムが実際のビジネスプロセスをサポートし、複数の組織の複数のシステムにまたがる可能性があることが検証されるフェーズです。このフェーズの目標は、欠陥を見つけることではなく、実際の状況でシステムがユーザーのニーズを満たしていることを検証することです。これには、セキュリティ要件が正しく実装され、満たされていることを確認することも含まれます。この段階では、セキュリティテストはすでにほぼ実行されているはずですが、ビジネスプロセスレベルで発生するセキュリティシナリオのテストを実施する機会となります。

デプロイ

このフェーズは、完成してテスト済みのシステムがユーザーに公開されるフェーズです。このフェーズは、特定のグループへのパイロット公開、またはすべてのユーザーへの大規模公開など、さまざまなものがあります。もう1つは、古いシステムと新しいシステムが一時的に同時に稼働している並列配置の時です。公開する部分は、すべてのユーザーに公開するリスクと受け入れテスト中に得られた信頼性によって異なります。新しい脆弱性が導入されないような方法ですべてのシステムコンポーネントを公開する必要があるため、セキュリティはシステム公開中の問題となります。これは、セキュリティ設定がターゲット環境で正しくない場合に発生する可能性があります。
例としては、データベースアクセス権が実際の環境で正しくない場合などがあります。

メンテナンス

公開後に新しいニーズが発生したり欠陥が発見されたりすると、メンテナンスが実行されます。テストは変更部分のテストと回帰テストの実行に重点が置かれます。また、セキュリティテストを実施して、新しい脆弱性が変更中に発生しないようにする必要があります。メンテナンスプロセスの一部は、ファイアウォールやその他のセキュリティ技術を最新の状態に保つことです。継続的なシステム監視は、直ちに対処する必要があるかもしれない疑わしい活動を検出することができます。

例 - イテレーティブ/インクリメンタルライフサイクルにおけるセキュリティテストプロセス
過去20年間に渡ってソフトウェアをより小さなインクリメンタルまたはいてレーションで定義するために導入されたさまざまな方法論があります。この例では、ソフトウェアのリリースは4週間ごとに設定されています。作業（およびテスト）のベースは、それぞれ定義された受け入れ基準を持つユーザーストーリーです。

どの機能を構築して提供するかの選択は、優先順位付けされたバックログに基づいています。選択された機能は、最大の価値をもたらし、スプリント期間内に達成可能な項目を反映する必要があります。セキュリティテスターは、ビジネスおよび／または製品のオーナーと協力して、適切で正しいセキュリティ要件を構築します。

以下の例では、4つの主要なセキュリティ機能が他の多くの機能を開発するために必要になるため、最初のいてレーションで選択されています。機能は次のとおりです。
* ユーザーログイン
* SSLの有効化
* パスワードのリセット
* 3回失敗した際のアカウントロック

これらの各機能はユーザーストーリーとして記載され、それぞれが受け入れ基準を持つ、より詳細な要件に洗練されます。

セキュリティテストの観点からは、セキュリティテスターは開発者と協力して、正しいポリシーとプロトコルがコードに反映されていることを確認します。セキュリティテスターはまた、開発者の隣で機能が開発されたときに機能をテストします。

この例では、最初のリリースは、ログインページと、パスワードリセットやアカウントロックなど、ログインに関連する機能となります。次のイテレーションでは、ステークホルダの優先順位に基づいて他の機能が開発されます。各イテレーションで、セキュリティテスターはセキュリティ管理が正しく機能していること、および新しいセキュリティの脆弱性が導入されていないことを確認するためのテストを行います。バックログのタスクが完了するまで、イテレーションが続きます。

どちらの例（イテレーション／インクリメンタル）でも、セキュリティテストのプロセスステップは、安全なアプリケーションを保証するための不可欠なタスクと見なすことができます。

JSTQB AL セキュリティテスターの目次

3 セキュリティテストプロセス