モデルテストによるセキュリティ設計パターンの適用検証
小橋孝紀†1, 鷲崎弘宜†1, 深澤良彰†1, 大久保隆夫†2, 海谷治彦†3, 吉岡信和†4
ソフトウェア開発では開発者が必ずしもセキュリティの専門家ではなく，開発の早期段階で,システムに起こりうる脅威・脆弱性を確認・検証が十分ではない．またセキュリティ対策を施したところで，本当にセキュリティ要求仕様を満たしているかの検証も不十分である．そこで我々は UML モデルのシミュレーション環境を用いたモデルテストによるセキュリティパターンの適用検証を提案する．本手法を用いることによりセキュリティに精通しない開発者であっても設計パターンの正しい適用と，パターン適用による設計上の脆弱性の有無を検証可能とし，セキュアな設計を実現する．

1. 背景
現在ソフトウェア開発者が必ずしもセキュリティの専門家ではなく,開発の早い段階でシステムにおけるセキュリティ項目についての 3 つである．
!

既存のセキュリティ要求・設計パターンに OCL 記述を用い拡張した新たなパターンの提案．

!

テスト駆動開発の概念を基に設計上でパターンの適用検証と脆弱性を検証するテストプロセスの提案．

!

モデリングやパターン適用をサポートし，テスト実行の為のスクリプトを自動生成するツールの提案．

十分に考慮されていない. そこでセキュリティの専門家の知識を活用・再利用する方法としてセキュリティパターン[1,2]がある. セキュリティパターンとは,セキュリティに関する特定の状況下で幾らか抽象化された問題およびその解決法である. ソフトウェアにおける脅威とその対策の特定をする手法として,セキュリティ要求パターン(Security Requirements Patterns)（以下、SRP）[1] の利用が

3.1. 本手法の全体像ある. またセキュリティ要求仕様を満たすソフトウェア設計の具体本手法では既存の SRP,SDP ごとに拡張した拡張 SRP,拡張的な設計手法の一つにセキュリティ設計パターン(Security DesignSDP を予め用意しておく. 拡張 SRP,SDP の全体構成と本手法のPatterns)(以下 SDP)の利用がある.

流れを図 3.1,3.2 に示す.

2. 関連研究とその問題点
SDP の例として[2]では,25 個のセキュリティパターンが示されている. しかしながら,現状では設計モデルに対し特定済みの脅
威に対しセキュリティ対策としてパターンを適用した際,パターンを適切に適用できたか,またセキュリティ被害を引き起こしうる設計上の脆弱性が解消できたか,これらを検証することは十分おこなわれていない.
これに対し Arnon らはデータベースアプリケーションに対してステレオタイプを用いたセキュリティパターンの適用検証を提案している[3]. パターン適用の検証を行うという点では本研究と似図 3.1 拡張 SRP, SDP の全体構成ているが,この研究では構造的なパターンの適用検証のみに留まり,パターン適用後の設計モデルにおいて,適切な振る舞いによって実際に脆弱性が解消されたかの検証がなされていない.

3. 提案手法
先の背景と関連研究を踏まえ本稿で扱う Research Questionを以下に示す.
RQ1 モデル上でのセキュリティ設計パターンの適切な適用を検証できるか.
RQ2 セキュリティ設計パターンの適用前や適用後におけるモ

図 3.2 本手法の全体像

デル上で,特定済みの脅威に対する脆弱性の有無を正確に検出できるか.

本手法の流れを以下に示す.

我々は既存のセキュリティパターンを拡張した上で，新たにパ

１.	 要求に対し，拡張 SRP を適用し，要求段階において開発中のターンの適用検証プロセスとモデルテストを実行する為のテストツ

ソフトウェアにどういったアセット（資産），脅威，対策があるかールを提案し，上記の RQ1，RQ2 に応える．本研究の貢献は次を特定する．
２.	 セキュリティを考慮していないモデルを入力とし，特定した対†1 早稲田大学、†2 情報セキュリティ大学院大学、†3 神奈川大学、†4 国立情報学研究所

策毎に用意された Security Requirements (図 3.1)を満たして

表 4.2 学生情報削除処理における Security Design Requirements

いるか確認する．ここで Security Requirements を満たしてい1ない，つまり要求段階で特定した脅威に対する脆弱性が検<<UserData>>が属する<<Role>>にアク出されることを確認する．
条件

３.	 セキュリティを考慮していないモデルが Security Requirementsを満たしていないことを確認した上で，拡張 SRP の対策に対応する拡張 SDP を選択する．

2

行動

対象プロセスにおける Security Design Requirements(OCLYes Yes No No

スケープ処理が行われている

Yes No Yes No<<Actor>>に権限があると見なす。

×

削除が行われる<<UI>>で入力データのエ<<UI>>に安全な入力を受けたと見なす

××××

×

<<UI>>に危険な入力を受けたと見なす
学生情報削除処理を実行できる記述)を設定する.

4

セス権限<<Right>>が与えられている<<Actor>>に権限が無いと見なす。

４.	 各 SDP に用意された Pattern Requirements (図 3.1)を用いて,3×××

学生情報削除処理を実行できない

×××

５.	 拡張 SDP を適用する．具体的には入力として与えられたモデル図に対し拡張 SDP の構造・振る舞いを適用する．適用の際にはパターン毎に定義されたステレオタイプをもとにパターンをマッピングする．

モデルテストにて上記の 4 つのテストケースのテストを行い，パターン適用後のモデルが各テストケースに対し期待する行動をとるか 確 認 し た ． こ の よ う に ， 学 生 情 報 削 除 処 理 お い て Security

６.	 パターンを適切に適用できたかを検証する為，対象プトセスのSecurity Design Requirements が満たされているかを検証す
る.

Design Requirements を満たすか検証することで RQ1 であるセキュリティパターンの適切な適用を検証できた．
最後に学生情報削除処理おける Security Requirements を満た

4. ケーススタディしているか再度モデルテストによって検証し，パターン適用後のケーススタディではソフトウェア工学を専攻する修士学生らにモデルが Security Requirements を満たすかを確認した．これによ作成させた，学生管理システム[4] を対象にパターンを適用する

り RQ2 であるパターンの適用前後でのモデルにおける要求段階ことで，RQ1，RQ2 を評価する．このシステムは特にセキュリティをで特定した脅威に対する脆弱性の有無の検証した． 具体的には考慮していない．対象となるシステムの規模を表 4.1 に示す.

セ キ ュ リ テ ィ を 考 慮 し て い な い 入 力 モ デ ル に 対 し Security
Requirements を満たしているかを検証し，パターン適用後，再度

表 4.1 対象となるシステムの規模

Security Requirements を満たしているかを検証することで，特定ユースケース数24個済みの脅威に対する脆弱性が解消されたことを本ケーススタディ

クラスの要素数31個で確認した．

(View : 18, Controller : 5, Model : 8)

開発期間

3ヶ月

5. 終わりに
我々は UML デルのシミュレーション環境を用いたモデルテス

ケーススタディでは「Student Controller」の「delete」関数，つまりトによる，セキュリティ設計パターンの適用検証を提案した．システ「学生情報を削除する」というユースケースに対して脅威と対策をムにおける設計上の脆弱性というのは，漠然と考えていても考え特定した上で本手法を適用する．今回は学生情報の削除に対すつくものではないため，本手法ではまず，既存の問題とその対策る脅威を[Privilege Exploitation:権限昇格]と[SQL Injection]とし，が記述されているセキュリティパターンを拡張した．この拡張 SRP，その対策として[Access Control：アクセス制御]，[Input and Data

SDP を参照することで開発の早い段階でシステムにおける資産，Validation：入力データの検証]が有効なケースを想定し評価を行脅威，対策を特定し，パターンの正しい適用と，脅威によってセキっ た ． 上 記 の ユ ー ス ケ ー ス に お い て 満 た さ れ る べ き Securityュリティ被害を引き起こしうる設計上の脆弱性の解消の有無をモ

Requirements を以下に示す．

デルテストにより検証した．

context StudentController
inv SecurityRequirement :if self.DeleteUI.Actor.right = true andself.DeleteUI.Actor.valid_input_data = true thenself.delete = true
else
self.delete = false
endif! !

図 4 学生情報削除処理における Security Requirements
まずは上記の OCL で記述された Security Requirements が満たされているかを検証し，パターン適用によって脆弱性が解消されることを検証する．Security Requirements を満たしていないことを確認した上で，次にパターンを適用する．拡張 SDP には「RBAC」と「Prevent SQL Injection」を選択しパターンを適用する．表 4.2 に満たすべき Security Design Requirements を示す．

参考文献
[1] T.Okubo H.Kaiya N.Yoshikawa Effective Security Impact
Analysis with Patters for SoftwareEnhancement IJSSE 3(1): 37-61(2012)[2]M.Schumacher

Hybertson, Frank

EduardoFernandez-Buglioni

Duane

Sommerlad.SECURITY PATTERNS”Wikey.

2006[3] Arnon Sturm, Jenny Abramov, Validatingand Implementing
Security Patterns for Database Applications SPAQu ’09 2009[4] SSR-Project https://github.com/SSR-Project