BSIMM との比較

2.3.4節でBSIMMで成熟度評価に用いられているセキュリティ保証プロセスに

ついて、アジャイルソフトウェア開発との整合性を分類した。ここでは本提案手

法との関係を議論する。

GOVERNANCE: STRATEGY AND METRICS 基本的には、開発手法に無関係 であるがSM2.2については、RailroadMapの警告をメトリックスと活用す ることで、アジャイルソフトウェア開発との整合性が実現できる。

GOVERNANCE: COMPLIANCE AND POLICY 基本的には、開発手法に無関 係である。

GOVERNANCE: TRAINING 基本的には、開発手法に無関係である。

INTELLIGENCE: ATTACK MODELS セキュリティ要求を文書化するため、AM1.2 の整合性が高まる。また、攻撃のテストケース記述により、AM1.3、AM1.4、

AM2.1の整合性が高まる。開発者全体で共通のセキュリティツールを用い

ることで、最新のセキュリティ問題への対応が早まれば、AM1.5、AM3.1、 AM3.2の整合性が高まる。

INTELLIGENCE: SECURITY FEATURES AND DESIGN セキュリティ要求 を文書化するため、SFD1.1、SFD3.3の整合性が高まる。最新のWebアプ リケーションフレームワークを用いるとSFD2.1の整合性が高まる。

INTELLIGENCE: STANDARDS AND REQUIREMENTS 基本的には、開発 手法に無関係である。

SSDL TOUCHPOINTS: ARCHITECTURE ANALYSIS セキュリティ要求を文 書化するため、AA1.1、AA1.2の整合性が高まる。セキュリティ検証モデル

によりAA.2.2の整合性が高まる。セキュリティツールにノウハウが集約さ

れる事は、AA3.1の整合性を高めることに近い。

SSDL TOUCHPOINTS: CODE REVIEW セキュリティ検証モデルによりCR1.4 の整合性が高まる。

SSDL TOUCHPOINTS: SECURITY TESTING) 提案手法によりST1.3 の整 合性が高まる。外部テスト連携はST2.1の整合性を高める。ダッシュボード によりST2.4 の整合性を高める。

DEPLOYMENT: PENETRATION TESTING 動的テスト生成機能は PT1.3の 整合性を高める。

DEPLOYMENT: SOFTWARE ENVIRONMENT 基本的には、開発手法に無関 係である。

DEPLOYMENT: CONFIGURATION MANAGEMENT AND VULNERABILITY

MANAGEMENT基本的には、開発手法に無関係である。

BSIMMは単一組織のセキュリティの取り組みの成熟度を測る指標であるが、

Railsや本提案ツールのようなオープンソースによるソフトウェア開発では、BSIMM

の組織の枠はオープンソース・コミュニティとして捉えるべきであろう。つまり、

組織横断の情報共有は、コミュニティにおける情報共有と言える。その中で、提 案手法のようなセキュリティテストツールの機能を絶えず更新し充実させること は、そのコミュニティのセキュリティ保証に関する成熟度を高める事になる。

5.2.4 各種のトレードオフについて

提案手法の実現及び実装にあたり、様々なトレードオフがあった。この節では トレードオフの種類と今回選択した対応についてまとめる。

コマンド抽象化ライブラリの作成と精度： 提案手法ではコマンド抽象化ライブラ リの作成が本手法を利用する上での前提となる。未知のコマンドについては ツール実行時に検出し、ライブラリへの追加のためのテンプレートを表示す る。そのため、コマンド抽象化ライブラリへの登録自体の手間は少ない。そ の際に、そのコマンドの持つセキュリティ属性、モデル生成で必要となる属 性については、開発者が定義を追加する必要がある。アプリケーション側で 作成して利用しているコマンドについては、開発者がその機能について把握 しているはずであり、開発者自身でコマンドに対して正しい分類を定義する 必要がある。一方、フレームワーク側のコマンドについては共有のライブラ リとして、ツール側で整備し、利用者間で共有する仕組みとした。セキュリ ティに関しては、当初はコマンドを独自の分類で扱っていたが、この分類作 業がライブラリ作成のうえで、大きな負担であった。その後、CWE,CAPEC の定義と連携することで、定義の作成が不要となり、割当も番号の指定のみ で良いため作業が簡略化できた。

コマンド抽象化ライブラリで正しく定義できていない場合、ツールは正しい 解析ができない。定義の正しさを確認する一つの方法は、過去の事例（CVEや レポジトリで問題がコードレベルで確認できる事例）を用いた評価である。

これについては、過去の事例をテストケースとして取り込みながら、ツー ルの開発を行うことで対応した。また、4.5節で示した実装コードとCWE、

CAPECとの対応の確認は、ツールが想定している脆弱性が取り扱えている

かを確認する意味で有効であった。

セキュリティ検証モデルの精度、制御フロー： Railsの場合、実装コードとMVC の各状態との対応が一意に対応するため、制御フローの各状態は正しく抽出 することができる。遷移については、遷移に関係するコマンドがコマンド抽 象化ライブラリで定義されていれば抽出可能である。

セキュリティ検証モデルの精度、データフロー： Rubyのコードの静的解析には 限界があるため、Railsの場合、データフローの完全な解析は難しい。現在 の実装では、コード上で解析可能範囲でデータフローモデルを構築する。

セキュリティ上問題となるのは、RC近傍の変数の扱いである。この際にSC との対応が不明なデータパスについては警告となる。

セキュリティ検証モデルの精度、遷移条件： 制御フローモデルで遷移が正しく抽 出出来た場合、ViewからControllerへの遷移については、ナビゲーション エラーの検出精度が上がる。アクセス制御については、任意の状態からの Controllerへの遷移が問題となるため、モデル上でのControllerへの遷移 パスや遷移条件は関係ない。

例えば、セキュリティ検証モデルをBメソッドに変換し、別のツールを使って アプリケーションの振る舞いの評価を行う場合には、正しいアプリケーショ ンの振る舞いを模すためにできるだけ正確な内部変数の定義と遷移条件の指 定が必要となる。

Railsの場合、コマンドの分類とMVCコードの静的検証でセキュリティ検

証モデルを構築することが可能である。正しくモデル化できない一部の箇所 については、ツールの精度を求めるより、開発者が補足できる仕組みを用意 した。一般に、ツールの精度を高めることと、ツールの実行速度にはトレー ドオフとなるが、ここでは、ツールを出来るだけ軽量に実装することを優先 した。

ツールの形態： 提案手法をツール化するにあたり、当初は単体のツール（実行コ マンド）での機能の実現を目指した。これは静的解析ツールと同様の使用方 法を想定したためである。典型的なRailsのアプリケーションの実装形態に ついては、単体ツールで対応可能である。

しかしながら、大規模なRailsアプリケーションでは、アプリケーション独 自の実装方式（特にコードの配置方法）を用いる場合があり、ツールの機能 を個別のケースにも対応できるように拡張することは難しい。こうしたケー スに本手法を適用する一つの方法は、個別のセキュリティ検査機能をライブ ラリ化し、アプリケーション開発側で利用することで、独自のセキュリティ 保証を実行する環境を構築することである。そのためには、現在のツール内 部の処理をモジュール化し、内部のデータ構造を整理する必要がある。

以上のようなトレードオフは、対象とするアプリケーション（及びアプリケー ションフレームワーク）で異なる可能性がある。