セキュリティテストカバレッジの計測

図3.7: セキュリティテストとカバレッジの計測

1. コマンド抽象化ライブラリにRisky Command (RC)を定義する。

2. ソースコードを検査し、RCコマンドの存在箇所をSINKとして登録する。

3. RCの使用が潜在的な脆弱性をもたないことを実際のテストケースで確認

する。

4. テスト実行後のテストカバレッジ(ステートメントカバレッジ)を用いて、

SINKの箇所がテストされていることを確認する。

脆弱性の種類によってテストケースの記述方法は異なる。一般には、不正な外部 入力が問題を起こさないことを確認する。テストケース作成については、次節で 述べるCAPECの情報などを参照し、プログラマが作成する。RC由来のSINKに ついては、基本的にはソースコード上のすべてのSINKがテスト対象となる。つ まりセキュリティテストカバレッジの母数はRCの出現数であり、分子はそのテス トの有無となる。

3.3.2 SINK による ^SC カバレッジの計測

一方、特定のセキュリティ機能SCの場合は、SCが期待した振る舞いをするこ とと、SCの配置が適切であることの２つの確認が必要である。

SCの機能確認については、ソースコード上の存在するSCすべてをテストする 必要はない。SCの正しい配置はセキュリティ要求で定義される。つまり、セキュ リティ要求を定義しないと配置の妥当性が検証ができない。これについては3.2.4 節で説明した静的検証で保証できる。

SCの提供するセキュリティ機能の確認については、SC単体でのユニットテス トの実施と、サンプリングでコード中の任意のSCを選択し、そのSCに関する機 能テストの実施を行う。したがって、SCのSINKテストカバレッジの母数はコー ド上で利用されているSCの種類であり、分子はそれぞれのテストの有無となる。

図 3.8: 単体機能テストと結合テストによるSCの確認

認証コマンドと、認証コマンドの内部実装とテストの関係の例を図3.8に示す。ア プリケーションコード中のSCに関しては、CWE-287(認証の不備)やCWE-592(認 証のバイパス)のような脆弱性が無いことを確認するためのテストを、機能テスト や結合テストレベルで記述する。一方、SCコマンド単体についてはユニットテス トで機能を確認する。この例では、CWE-208(データ比較の時間差に起因する脆弱 性)の脆弱性対策が施されていることを確認する。

アクセス制御のテストについて、セキュリティコマンド(SC)の配置とテストの 関係を図3.9にまとめる。テストケースに参照となるアクセスコントロールリスト

(ACL)を持つ場合、これがアプリケーションのPDPのルールとして用いられる。

また、テストケース中のACLをアクセス制御ポリシーに変換し、テストケースを 記述する。

3.3.3 開発プロセスへの埋め込み

提案手法で得られるセキュリティテストカバレッジを用いることで、テスト駆動 開発へのセキュリティテストの組み込みを計画的に実施できるようになる。アジャ イルソフトウェア開発フローと提案ツールを利用した セキュリティ保証の関係を図 3.10に示す。アプリケーションコードは一旦セキュリティ検証モデル(Application model)に変換(Parser 1, P1)され、テストカバレッジの計測(Parser 2, P2)を行 う。このメトリックスをフィードバックとして、テストケースの更新や、セキュリ

図3.9: アクセス制御機能のテスト

ティ要求定義の更新を行う。個別の問題の理解と修正にはトレース機能を用いて、

特定の警告について詳細を調べる。トレースモードでツールを実行すると、関連 するモデルの情報の詳細がツールの実行時に表示される。一連のツールの動作の 詳細については4.1.5節、図4.4で詳しく説明する。

テスト駆動開発では機能要求がまずテストケースとして記述され、テストをパ スするようにアプリケーションコードを開発する。認証のような一部のセキュリ ティ機能はこの流れで開発することができるが、この段階ではまだセキュリティ テストとしての網羅性は担保していない。そこで、本手法で計測されるテストカ バレッジを元に、必要なテストケースを追加する。

SCについてはその配置については要求定義と静的検証で対応し、実際の機能に ついては、その機能を実装しているアプリケーション上の任意の箇所をサンプリ ングしてテストケースを作成する。RCについては、基本的にはRCを使用してい るすべて箇所について、テストケースを作成する。これらについての実際の数の 評価については次章で検証する。

網羅的なセキュリティテスト実施のために、大量のセキュリティテストケース を作成することは現実的ではない。提案手法は、アプリケーションの内部知識を 元に、必要最小限のセキュリティテストケース作成を支援する。

ここで計測されるメトリックスと開発者の対応、優先度を表3.1にまとめる。最 初の作業は、コマンド抽象化ライブラリの不備や、遷移が不明な制御フローモデ ルの修正を行い、セキュリティ検証モデルの精度を高める事である。次に、アク セス制御に関して、アセットとロールのテストを整備する。SC、RCのSINKカ バレッジについては、ツールが指摘するプライオリティにしたがって、テストを 整備する。

図 3.10: アジャイルソフトウェア開発フローと提案ツールを利用した セキュ リティ保証の関係

表3.1: 計測されるメトリックスと開発者の対応

Metrics action priority

Num. of command review low

Num. of command (unknown) add definition high Num. of command (tentative) add definition mid

Num. of trans. review low

Num. of trans. (unknown) add definition high Num. of trans. (tentative) add definition mid Asset cov. (AAF) update TC or tool high Role cov. (ARF) update TC or tool high Sink cov (SCU nit) update TC or tool mid Sink cov (SCF unc) update TC or tool mid Sink cov (RCF unc−high)) update TC or tool high Sink cov (RCF unc−mid) update TC or tool mid Sink cov (RCF unc−low) update TC or tool low