3.3.1 セキュリティテスト設計

詳細なセキュリティテストは、セキュリティリスク、セキュリティテスト戦略、および脅威モデルなどの他のソースに基づいています。セキュリティテストは、本質的に機能的および構造的とみなすこともできます。たとえば、電子商取引Webサイトのセキュリティテストの場合、機能的なセキュリティリスクは、SQLインジェクション、アカウント収集、およびパスワードクラッキングです。構造的なセキュリティリスクの例は、攻撃者がメモリ障害を介してアクセスできるようにするバッファオーバーフローです。

詳細なセキュリティテストの重要な属性は次のとおりです。
* 特定されたセキュリティリスクと脅威モデルによる優先順位付け
* 定義されたセキュリティ要件とのトレーサビリティ
* 対象読者（開発者、機能テスター、セキュリティテスター）に基づいた定義
* セキュリティ欠陥プロファイルに基づいた定義
* 自動化できるように設計

セキュリティテスト設計の基本的な流れは次のようになります。
1.セキュリティテストのアプローチ（プロジェクトレベル）
2.セキュリティテストのリスク、脅威モデル、および要件（プロジェクトレベル）
3.セキュリティテストの設計手法（リスク、要件、およびアプリケーションに基づく）
4.セキュリティテストケースとシナリオ

この章の残りの部分では、一般的なセキュリティリスクと脆弱性を、関連するセキュリティテストの設計手法とともに示します。新しいセキュリティリスクと脆弱性はすぐに出現するため、第9章で参照されているように、セキュリティテストプランナーはセキュリティ標準と脅威リストを最新の状態に保つことをお勧めします。

重要なことは、セキュリティテストの設計プロセスが、特定されたセキュリティリスク、要件、または脅威に基づいてテストを作成および実装できることです。

機能的セキュリティ管理（例：トランザクション管理）

これらのテストは、コントロールが適切に機能していることを検証および妥当性確認するように設計されており、不正なアクションの検出と防止に効果的です。

例：銀行の出納係は、システムに支店長の承認が入力されない限り、特定の金額を超える現金の引き出しを許可することはできません。

機能的アクセス制御（ログイン、パスワード、トークンなど）

これらのテストは、おそらくほとんどの人がすぐにセキュリティテストの観点から考えるものです。以下のテストが含まれます：
* ユーザー名とパスワードのポリシーが正しく適用されていること
* アクセス制御のレベルがリスクに適していること
* アクセス制御はパスワードクラッキングソフトウェアに耐性があること

例：アカウントハーベストは、ユーザー名を識別する方法です。ユーザー名が推測または識別されると、システムアクセスに必要な残りの部分はパスワードになります。一般的なテストは、間違ったパスワードで正しいユーザー名が入力されたときに、どの項目が間違っているかをエラーメッセージが示していないことを確認することです。

構造的アクセス制御（ユーザーアクセス権、暗号化レベル、認証など）

これらの制御のテストは、データアクセス、機能的アクセス、プライバシーレベルに対するユーザー権限の確立方法をベースにします。構造的なアクセス制御は通常、システム管理者、セキュリティ管理者、またはデータベース管理者によって適用されます。場合によっては、アクセス権はアプリケーションの構成オプションです。その他の場合、アクセス権はシステム環境レベルで適用されます。

構造的なアクセス制御のテストには、セキュリティアクセスの各レベルのテストユーザーアカウントの作成と、各レベルのアクセスがそのレベルに制限されたアクセス権を持たないことの確認が含まれます。たとえば、最小レベルのアクセス、マネージャーレベルのアクセス、および管理者アクセス用のユーザーアカウントが作成されます。最小限のアクセス権を持つユーザーがマネージャーレベルのアクセスアクティビティを実行できないことを確認するために、テストを実施する必要があります。

セキュリティコーディングプラクティス

セキュリティコーディングプラクティスとは主に、ソフトウェアおよびシステムの開発者がアプリケーションの作成時に確立されたセキュリティメソッドに従っているかどうかを判断する静的なテスト方法のことです。

重要なことは、多くのセキュリティ攻撃がソフトウェアの欠陥を悪用して達成され、システムが予期しない動作をするということです。

セキュリティコーディングプラクティスのリストは以下です。
* 実証済みのセッション管理アルゴリズムとコントロールを使用して、ランダムセッションIDを作成する。
* 承認の決定は、承認を提供する組織の管理下にある信頼できるシステムオブジェクトによってのみ行われる（たとえば、承認はサーバー側で発生する必要がある）。
* 安全な情報はエラーメッセージに表示されない。この情報には、システムの詳細、セッション識別子、アカウント情報が含まれる。
* サーバーの構成に依存するのではなく、アプリケーション内でアプリケーションエラーを処理する必要がある。
* HTTP GET要求には機密情報を含めない。
* エラーハンドラーは、スタックトレースまたはその他のデバッグ情報を表示しない。
* データ入力バリデーションのエラーはすべてログに記録する必要がある。
* サーバーに一時的に保存される機密情報は保護する必要がある（たとえば、暗号化を使用する必要がある）。この一時的な安全な情報は、不要になったら消去する必要がある。
* アプリケーションは、オペレーティングシステムに直接コマンドを発行できない。代わりに、組み込みAPIを使用してオペレーティングシステムのタスクを実行する必要がある。
* パスワード、接続文字列、またはその他の機密情報は、クライアントマシン上にクリアテキスト（Cookieなど）で保存しない。このような情報をAdobeフラッシュ、コンパイル済みコード、MSビューステートなどの安全でない形式に埋め込むことは禁止する必要がある。
* すべての機密情報の送信には暗号化を使用する必要がある。トランスポート層セキュリティ（TLS）は、HTTP接続を使用するときに転送中のデータを保護する方法です。非HTTP接続の場合、機密情報の送信には暗号化を使用する必要がある。
* ユーザーが入力したデータは、動的な「include」関数に直接渡さない。
* ユーザー入力のデータはすべて、アプリケーションで使用する前に適切にサニタイズおよび検証する必要がある。
* 変数は、型チェックをサポートする言語で型付けする必要がある。つまり、変数には入力のタイプが定義されている必要がある。たとえば、数値フィールドには英字を使用できないこと。この制限は、変数の型定義とデータベースで定義される。 JavaScript（Node JS）またはコンパイラーによる型チェックをサポートしない他の言語でも安全なコードを書くことができる。
* 一般的なタスクに新しいアンマネージコードを使用する代わりに、構成管理下にあるテスト済みの信頼できる承認済みコードを使用する。
* 可能な限り最小限の特権で（rootの下で）サービスを実行する。各サービスには、オペレーティングシステム上で独自のユーザーアカウントが必要であること。

セキュアコーディングプラクティスのリストは、OWASPセキュアコーディングプラクティスクイックリファレンスガイド[OWASP1]およびトップ10セキュアコーディングプラクティス[CERT1]にあります。さらに、SANSは[SANS1]で上位25の最も危険なソフトウェアエラーのリストを作成しています。

動的テストを実行して、開発者がデータ検証やエラーメッセージングなどのプラクティスに従っているかどうかを判断できます。さらに、最も一般的なセキュリティ脆弱性の1つであるメモリバッファオーバーフローは、動的メモリテストツールで特定することができます。

オペレーティングシステムアクセス

オペレーティングシステムにアクセスすると、攻撃者はデータ、ネットワークアクセスを制御し、マルウェアを植え付けることができます。このテストには、ルートキットやその他の悪意のあるコードをシステムに植え付ける機能のテストを含めることができます。

言語の脆弱性(例 Java)

アプリケーションセキュリティベンダーであるWhiteHat Securityのセキュリティ研究者によると、セキュリティの脆弱性に関しては、言語間で大きな違いはありませんでした。 [WhiteHat Security、2014]
2014年4月、WhiteHatセキュリティは、独自のスキャナーを使用して30,000の顧客Webサイトに対して実施した脆弱性評価に基づくWebサイトセキュリティ統計レポートを発行しました。 .NET、Java、PHP、ASP、ColdFusion、およびPerl。これらの6つの言語は比較的類似した脆弱性の平均数を共有しており、SQLインジェクションやクロスサイトスクリプティングの脆弱性などの問題は依然として広まっています。 [WhiteHat Security、2014]
安全でないコードと同様に、多くの言語で安全なコードを実現できることを認識することが重要です。どの言語を使用する場合でも、アプリケーションのコーディング方法（実装）が重要な要素です。

Software Engineering InstituteのCERT部門は、言語固有のセキュリティ問題に対処する出版物[CERT2]およびツール[CERT3]を提供しています。 さらに、Vulnerability Notes Database [CERT4]は、ソフトウェアの脆弱性に関するタイムリーな情報を提供しています。 脆弱性ノートには、概要、技術詳細、修復情報、影響を受けるベンダーのリストが含まれます。

プラットフォームの脆弱性

各コンピューティングプラットフォームには、独自のセキュリティ脆弱性があります。 セキュリティテスターの懸念は、プラットフォームのセキュリティ更新プログラムが、影響を受けるプラットフォームを実行するすべてのデバイスに迅速に適用されるようにすることです。

外部の脅威

外部セキュリティの脅威は、ほとんどの人がサイバー攻撃を考えるものです。 アプリケーションや言語の脆弱性の悪用などの外部の脅威は、検出、テスト、および防止できます。

サービス妨害（DoS）は、別の種類の外部の脅威です。 一般に、これらの攻撃は、システムまたはアプリケーションに正当なユーザーがアクセスできなくなるように、システムまたはアプリケーションのリソースを過負荷にすることに基づいています。 DoS攻撃は、ネットワークの帯域幅、システムまたはアプリケーションの接続性、または特定のサービスまたは機能を標的にすることができます。

分散型サービス妨害（DDoS）攻撃は、他のコンピューターリソースを使用して間接的に攻撃が開始されるタイプのDoSです。 可能な技術は、増幅またはボットネットの使用です。これは、攻撃者の制御または指揮下にある、以前に侵害された多数のコンピューターです。 攻撃者は、単純にウイルス感染またはトロイの木馬の使用を開始することによって制御を得る可能性があります。 感染したコンピューターはエージェントとして使用され、それぞれが攻撃者の標的として特定の被害者（ネットワーク）にトラフィックを送信します。

増幅攻撃または反射攻撃を使用する場合、攻撃者は特定のプロトコル（DNSやNTPなど）で脆弱性（または必要な機能）を使用しています。 攻撃者は、被害者のスプーフィングされたソースアドレスを含むIPブロードキャストアドレス（複数のホスト）に大量のトラフィックを送信します。 これにより、ブロードキャストサービスはこのトラフィックを被害者のアドレスにエコーし、元のトラフィック量にホストの数を掛けます。 攻撃者がこの種のリクエストを1秒間に数回送信すると、被害者は送信する必要のある多数の応答に突然直面します。

例：攻撃者Aは、被害者Cになりすまし、多くの場合スプーフィングされたIPアドレスで、既知のすべてのDNSレコードの完全なリストの要求をシステムBに送信します。 次に、システムBは完全なリストをVictim Cに送信し、Victim Cサーバーに増幅されたデータ量をフラッディングします。

DoS攻撃のもう1つの形式は、リソース枯渇攻撃です。 これらの種類の攻撃は、機能を提供するために必要なコンピューティングリソース（CPU、メモリ、ディスクストレージなど）を消費することにより、目的の機能を悪用します。

例：SSLプロトコルの機能の1つは、クライアントまたはサーバーが侵害されたセッションを疑った場合に、既存のセッションで新しいキーを生成するオプションです。 キーの生成は、リソースを消費するプロセスです。 攻撃者が新しいキーを毎秒数回生成する要求を送信すると、不適切に構成または保護されていないシステムは、新しいキーを生成するだけで、他のことを行うためのリソースが残っていない状況に陥ります。

最後に、いわゆる論理的なDoS攻撃があります。攻撃者は、意図した機能を悪用して、他のユーザーがシステムにアクセスできないようにすることができます。

例：アプリケーションは予測可能なユーザー名を使用し、3回ログインに失敗するとユーザーを永続的にロックします。 攻撃者はユーザー名を推測し、システム内の多くのアカウントをロックして、多くのユーザーがアクセスできないようにします（そして間接的にヘルプデスクをDoSします）。

DDoSのテストには4つのレベルがあります。
* コンピューターが既知のマルウェアに感染していないことを確認するためのテスト
* 侵入検知システムの能力をテストして、単一のコンピューターからの複数の要求を短時間で迅速に識別する
* 攻撃者によって悪用される可能性のある機能（SSL、Webサーバー、DNSなど）を許可する構成を特定する
* DoSを許可する可能性のあるロジックの欠陥を特定する

侵入は、外部攻撃の別の形態です。 システムへの外部侵入を実現する方法は多数あります。 これらの攻撃は、誰かがシステムに「侵入して」情報を取得することに基づいています。 いくつかの方法を以下のリストで説明します。

ソーシャルエンジニアリング

* インジェクション攻撃（SQL、悪意のあるコード）
* アカウントの侵害（収集、パスワードのリセット）
* 既知の脆弱性（ファイアウォール、OS、フレームワーク、アプリケーション）の悪用
* マルウェア攻撃
* 安全でない構成攻撃
* 認証の欠陥
* アプリケーションロジック攻撃（特にWebベースのアプリケーションでアプリケーションの欠陥を利用して、機能を悪用する-たとえば、eコマースショッピングアプリケーションで順序を変えてステップを実行して割引やクレジットを達成する）

組織内部から別の組織の誰かに送信されるネットワーク伝送を傍受することは、侵入攻撃ではなく、内部侵害と見なされます。

内部の脅威

最大の脅威は内部的なものです。 次の内部攻撃のソースを考慮してください。
信頼された従業員が顧客アカウント情報、企業秘密、従業員のアクセス情報などを含む企業情報を販売する可能性のある企業スパイ。
外部委託された開発者、テスター、およびその他の担当者（顧客サービス担当者など）が取得した情報。 時々、人々はアウトソーシング会社の仕事を辞めて、頭の中で情報を取ります。
ハードドライブおよびその他の物理ストレージデバイスの盗難
機密情報を漏らしたり、正当な（ただし偽造された）請求書を装って金を支払うことで盗難行為を行って会社に損害を与えようとする不満のある従業員

セキュリティテストの形式と構造

セキュリティテストを実行する各組織には、詳細なテストをフォーマットする独自の方法があります。 多くの場合、セキュリティテストの設計に他のタイプのテストと同じ形式を使用できますが、テストとテスト環境のターゲットのみが異なります。

組織がIEEE 829-2008やISO 29119 [ISO / IEC / IEEE 29119-3]などの標準に従っている場合でも、その標準の使用は組織のニーズに合わせて調整する必要があります。 ただし、これらの標準は、さまざまなテスト計画文書に含まれるべき内容の標準的な理解を形成します。 多くの場合、テストケースとテスト手順（スクリプト）は、多くの場合フォーマット構造を提供するテスト管理ツールで定義および実装できます。

テストケースは、テスト記述の最もスタンドアロンの形式です。 順次実行する必要はありません。 特定のテスト目標を達成するために順次実行が必要な場合、テストケースはテスト手順またはスクリプトで表現された順序で結合されます。 テストケースは通常、単一の条件をテストするために使用されます。 たとえば、セキュリティテストでは、ログイン機能のテストは、パスワードのフォーマット要件が正しく実施されていることを検証するように設計されたテストケースで構成されます。

テストの実装中に、テスト手順の仕様でテストケースが開発され、優先順位が付けられ、整理されます。 テストプロシージャは、テストケースの実行シーケンスを指定します。 テスト実行ツールを使用してテストを実行する場合、アクションのシーケンスはテストスクリプト（自動テスト手順）で指定されます。 テスト手順は、シーケンスが重要な場合に使用されます。 たとえば、「失われたパスワードを回復する」プロセスをテストするには、テスト手順が役立ちます。

探索的テストなどの経験ベースのテストが必要な場合、テスト条件と期待される結果はテストの前に定義されませんが、テストする条件と実際の結果は報告のためにセキュリティテスターによって記録される必要があります。

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

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