課題 1: セキュリティ要求の定義と保守

調整している。こうした調整が多く必要な部分は、主に認証部分である。例えば、

Deviseなどの主要な外部認証モジュールを用いる場合は、ツール側で事前に作成

した認証部分のポリシーを開発者に提供できる。その場合、開発者はModelレベ ルでのポリシー定義の設定で十分であり、このポリシー定義が開発者の大きな負 担にはならない。

4.2.2節では、セキュリティ保証が一旦完了したWebアプリケーションに変更

を実施する際の、セキュリティ要求の変更と、セキュリティ実装の追加を、本提 案手法を用いることで計画的に進めることができることを示した。本手法により、

開発者は、初期の段階ではセキュリティ保証は考慮せずに、アプリケーションの 機能変更に注力することができる。変更が完了した時点で追加的に、変更に伴う セキュリティ要求の変更を実施し、あとはツールの指示に従って（警告を修正す る形で）、必要となるセキュリティ機能の配置を段階的に進めてゆけば良い。

開発者が作成したセキュリティ要求は、コードと一緒にレポジトリに保存して 変更を管理することで、実装コードと一貫した形での保守が可能である。

5.1.2 課題 ^2: テスト駆動開発に合致した網羅的なセキュリティテ

スト

この課題に対する提案手法の解決方法は、テスト駆動開発に組み込んだセキュ リティテストのセキュリティテストカバレッジの計測である。ブラックボックス 的なセキュリティテストのアプローチで網羅的なセキュリティテストを実施する と、大量のテストケースが必要となる。しかしながら、提案手法では、アプリケー ションの実装コードから、その振る舞いをモデル化するため、ホワイトボックス 的なセキュリティテストのアプローチが可能である。セキュリティに関係する実 装コードの場所をSINKとして、SINKへのテストの有無をセキュリティテストカ バレッジとして計測することで、セキュリティテストケースを最適に配置できる ようになった。また、セキュリティに関係するコマンドをセキュリティ機能を実 現するコマンド、SCと、その利用に脆弱性の危険があるコマンド、RCに分類す る。その結果、SCについては、セキュリティ要求定義と静的検証による配置の確 認とを組み合わせることで、動的テストによる振る舞いの確認は、SCの機能別で の実施とする事が可能となった。

4.4節では、Railsを用いた大規模なWebアプリケーション、Foremanに対し

て、Foremanの既存のテストケースのセキュリティテストカバレッジの計測と、

改善について実験を行った。アクセス制御実装のテストに関しては、高精度でテ ストカバレッジの検知が可能であり、アクセス制御テーブルを元に、セキュリティ テストの配置も可能である。一方、RCのSINKカバレッジについては、Railsの テストカバレッジ計測ツールである、SimpleCovがViewテンプレートのカバレッ ジ計測に対応しないために、限定的なものとなった。

4.3節では、テストケースの自動生成の実験を行った。Cucumberを用いたUAT レベルのテスト記述で、アクセス制御などのセキュリティ機能のテストが自動生成 可能である。ただし、Railsのテストフレームワークには、Cucumberの他にも、

RSpecや、Foremanで用いられていたRails自体のテストフレームワークなど幾 つかの選択肢がある。またテストの実装方法も、Webアプリケーションの開発毎 にかなり異なるため、ツールによる自動テストケース生成を汎用的に実装する事 が難しい。どの方法を用いる場合も、テストケースの記述自体は比較的簡素なた め、セキュリティテストのカバレッジ計測を元に、テストケースを開発者が記述 する方法が適している場合も多いと考えられる。その場合は、テスト対象となる 脆弱性の理解とセキュリティテストとなる攻撃パターンの理解が重要である。こ れについては次節が関係する。

このように、静的なセキュリティテストと動的なセキュリティテストをモデル を介して統合していることに本手法の特徴がある。テストの基本方針は、静的テ ストで網羅性を確保し、動的テストで実際の挙動を確認する。また、動的なテス トのためのセキュリティテスト生成には次の２つの目的がある。一つは実装して いるセキュリティ機能が実際に働くかのテスト確認、もうひとつは静的テストで 検出された問題の動的テストによる確認である。

5.1.2.1 セキュリティ機能のテスト

本手法では、網羅性の確認はセキュリティ機能の配置の問題として、静的テス トで確認する（4.1.4節）。この確認は、与えられたセキュリティ要求へのセキュ リティ実装の整合性の確認である。

アプリケーションが参照する外部機能は、すべてコマンド抽象化ライブラリに 登録されている。アプリケーションが参照するセキュリティ機能も、コマンドの形 でコマンド抽象化ライブラリに登録されている。静的検証の過程で、アプリケー ションが何処でどのコマンドを使っているのかを補足し、個々のセキュリティに 関係するコマンドについてテストケースを生成する(4.1.5節)。

現在の実装では、アクセス制御の問題を主に扱っており、表4.4で分類した脆弱 性の検出と、そのテストケースの生成が可能である。実際のアプリケーションを 用いた評価を4.3.2節(Hacketyhack)と4.4節(Foreman)で実施し、有効性を確 認した。

5.1.2.2 セキュリティ警告の確認

提案手法及びツールでは、アクセス制御以外のセキュリティの問題にも対応し ている。特に、開発者によるフレームワーク提供のセキュリティ機能の無効化や、

独自のセキュリティ機能の定義への対応に重点をおいた。また、本ツールを中心 として、様々な既存のセキュリティテスト・ツールとの連携機能を持つ。

本提案手法のツールも含め、こうしたセキュリティテストツールには一般に擬陽 性(False-positive)の問題がある。本ツールでも、例えば完全なインフォメーショ ンフロー解析はできておらず、疑わしい箇所は警告としてレポートしている。そ うした警告が実際に問題のある脆弱性のレポートなのか、無視して良いレポート なのかの判断に動的テストを用い、実際のアプリケーションの振る舞いから陽性 か擬陽性かを判断する。4.3.2節の例では、対象アプリケーションに、脆弱性を仕 込むことで、この機能の有効性について確認を行った。

提案ツール自体は既知の脆弱性のあるパッケージのチェックはサポートしない が、これについては、外部のツールと連携して、パッケージの脆弱性を把握でき るようにしている（4.1.7節）。利用しているパッケージに脆弱性が見つかった場 合、本来は早急に該当パッケージを最新版に更新する必要がある。しかし、更新 により機能的な問題が生じる場合などがあり、すぐには対応できないケースが発 生する。こうした場合に、依存パッケージの脆弱性が実際に問題となるのか否か 動的テストにより検証する機能は、実用性が非常に高い。本ツールでは未対応で あるが、今後対応したい機能の一つである。