セキュリティ要件を充足するソフトウェア開発方式の検討
大久保 隆夫

中山 裕子

綿口 吉郎 田中 英彦(株)富士通研究所 〒211-8588 川崎市中原区上小田中 4-1-1
情報セキュリティ大学院大学 〒221-0835 神奈川県横浜市神奈川区鶴屋町 2-14-1
E-Mail: {okubo, nakayama.yuko, wataguchi}@jp.fujitsu.com, {dgs063104, tanaka}@iisec.ac.jp
あらまし 近年、ソフトウェアセキュリティの重要性が高まる一方で、ソフトウェア開発の現場においては、セキュリティ品質確保のために必要な作業の体系化が不十分であるのが現状である。本稿では、ソフトウェアの実装、テストと、セキュリティ要件の維持との間の関係を明確にすることを目的とし、その解決手段として、セキュリティの実装手段にある程度の制約をかけることにより、セキュリティ要件の確認が容易になることを示す。また、その関係を利用して、必要なセキュリティ作業を抽出する方式について提案する。さらに、上記の関係を利用して、セキュリティ要件を満たすために必要な作業のコスト(セキュリティ要員の必要性、費用、工数)を、開発の早期において容易に見積もる開発支援システムを構築するための方式について提案する。
キーワード ソフトウェア 開発 セキュリティ要件 実装手段 見積もり 規約 テスト

A Study on Software Development Method
which Fulfills Specified Security Requirements
Takao OKUBO

Yuko NAKAYAMA

Yoshirou WATAGUCHI

Hidehiko TANAKA

Fujitsu Laboratories ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki Kanagawa 211-8588 Japan
Institute of Information Security
2-14-1 Turuya-cho, Kanagawa-ku Yokohama, Kanagawa, 221-0835 Japan
E-Mail: {okubo, nakayama.yuko, wataguchi}@jp.fujitsu.com, {dgs063104, tanaka}@iisec.ac.jp
Abstract There is no sufficient systemized method of secure software development in spite ofgrowth of importance of software security. Project managers, architects, programmers, and testers
do not know how to implement the required security, or how to verify it. In this paper, we clarify
the correlation between the easiness of verification of implementation rule compliance, andquantity of work to meet the security requirements. Moreover, we propose a secure softwaredevelopment environment system on the basis of these correlation. This system gives project
managers quotation of cost, man-hour and security experts at the early phase of the softwaredevelopment life-cycle, by offering choices of the implementing methods. Our system also has thefeature generating

coding conventions and testing specification document which provides

guidelines at the every part of the software development life-cycle to meet the security
requirements.
Key words software development, security requirement, quotation, convention, testing

1. はじめにソフトウェアの脆弱性を原因とするセキュリ

ティインシデントが多発し、ソフトウェアセキュリティの重要性が叫ばれているにも関わらず、

ソフトウェア製品やシステムの開発現場には、様を満たしていても、それ以外に意図しない挙セキュリティ品質向上のための取り組みはあま動をする場合がある。それらは「仕様通りか」り浸透していない。その一因は、ソフトウェアの確認を行うテストでは検出できないし、「意図開発においてセキュリティ品質を実現、保証すしない挙動をしない」という設計仕様の記述方る手法が明確になっていないことにある。セキ法も従来の手法では困難である。

ュリティ知識に乏しい開発現場では、セキュリ

また、仮にセキュリティ要件を満たすような設ティ確保のために何をどれだけ行えばよいかが計を行ったとしても、実装の段階で脆弱性が混分からない。また、プロジェクト管理者にとっ入してしまう場合がある。脆弱性の代表例であては、セキュリティ品質を確保するためのコスるバッファオーバーフロー脆弱性の多くは、こトが見えにくく、完成したシステムの品質を評の実装段階に原因がある。

価できないため、セキュリティ投資もしにくい

セキュリティに必要な機能を設計、実装する方式としては、ISO/IEC 15408 として標準化状況にある。
著者らは、これらの問題を解決するため、ソされた Common Criteria(CC、[CC05])がある。

フトウェア開発のライフサイクル全体を通してCC は、システムに必要なセキュリティ機能をセキュリティの品質を確保し、検証するための仕様として整備するための体系としては有用で技術について研究を行っている。本稿では、そあるが、従来のソフトウェア開発手法に基づいの試みの一つとして、あらかじめセキュリティた機能的側面に重点が置かれているため、上記要件が与えられた場合に、その要件を満たすソのような実装段階の脆弱性の防止に対して有効フトウェア開発方式について提案する。とはいえない。

2. 現状の課題と関連技術

現在セキュリティの品質検証の主流となってソフトウェア開発、特に大規模ソフトウェアいるのは、第三者によるブラックボックステスの開発現場では、[Roy70]で提唱されたウォー

ト[McG98]、[Wei95])である。一方で、テストターフォールモデルによる開発体系が用いられ、 工程での検証に頼る方法では手戻りのコストが「分析工程で要件を確定」「設計工程で要件を満大きいという問題がある。そのため、上流でのたす機能を設計し」「実装工程で機能を実装」「テセキュリティ対処の必要性が指摘されており、スト工程で要件、設計通りに機能が実装されて[HDL04]をはじめ、いくつかの手法が提案されいるかを確認する」という手順を通じて品質をている。しかし、ソフトウェア開発の現場にこ確保、保証する手法が確立している。

れらの手法はなかなか浸透していない。

しかし、セキュリティに関する品質の確保、このように、上記に挙げた研究、技術が存在保証という点では、従来のソフトウェア開発体するにも関わらず、それらが「銀の弾丸」2とな系は十分ではない。ソフトウェアにおける一般

りえていないのは、開発の各工程間の密接な関的な機能の設計仕様は UML 等のような形式で連性を十分活用している研究が少ないためであ

明確に定義が可能である。 しかし、セキュリテると考えられる。
本質的な問題解決のためには、ィの仕様は UML 等で記述可能なものとは性質

セキュリティに関わる各工程間の関連性を明らが異なる1。[PM04]かにすることが必要となる。

、[Tom03]で指摘されているように、セキュリティ脆弱性は、ソフトウェ

3. 提案方式とその特徴
筆者らは Web アプリケーションを中心に、アにおける一般的なバグとは異なり、本来の仕1

UML の拡張を利用してセキュリティの設計を行う研究([Jür04])もある。

2

Fred Brooks の言葉で、ソフトウェア工学で用いられる「多くの問題を一発で解決するような手法」の比喩。

システム開発の上流工程からセキュリティのレの排除や不足手段の補完を行う必要がある。筆

ビューと改善支援を行うとともに、システム開者らは各実装手段間の相互関係について、計算発に必要なセキュリティ作業のノウハウを蓄積機で処理が可能なように以下の関係に整理した。

してきた。筆者らはこのノウハウを利用して、(a) AND 関係

セキュリティの知識に乏しいシステム開発者に対しても、開発ライフサイクル全体を通してセ要件の充足には、他の手段との併用が必須(b) OR 関係

キュリティ支援、教育を行えるような技術の研他の手段を含むいずれか一つの手段で要件究を行っている。の充足が可能

筆者らは分析工程でセキュリティ要件を決定(c) XOR 関係した後の設計以降の工程において、いかに決定いずれか一つの手段で要件の充足が可能でした要件が守れるかという点に着目し、(1)実装かつ、他の手段との併用が不可能手段の限定と、(2)実装手段間の相互関係と代替

また、実装手段と区別して、代替手段も定義

手段の定義が有効と考えた。

した。
代替手段は実装手段が実施されない場合、(1) 実装手段の限定セキュリティ要件を充足するために必要な次善実装工程において、あるセキュリティ要件をの手段として定義されるもので、実装手段とは実現する手段は、プログラミング言語やフレーOR の関係にあるが、選択候補として提示するムワーク、ライブラリを一意に決定したとして際には実装手段の方が優先される。

も、通常は数多くの手段が存在する。しかし、

4. 提案方式

各実装手段のセキュリティ要件に対する充足度

図 1 に提案方式を用いたシステムの構成と流はさまざまである。その実装手段をプログラマれを示す。の選択に委ねるとすると、テスト段階ではどの(1)%&'(^_`a_.bIc=>?@/AXYZ(2) IJK&LMd
89:Ic

実装手段が採用されているかは不明なので、セ!"#$%&'(キュリティ要件充足の確認は非常に困難になる。
しかし、コーディング規約などの制約によって実装手段を限定すれば、制約遵守(または違反)を確認することで、セキュリティ要件の充足-./0;<=>?@/A;<BCDEF7'(+,-./056)*の確認をその実施手段の範囲に限定できる。ま!"#$GHた、その実装手段の実施によってセキュリティ

BCDEF7'(IJK&LM12!"#$34NO
PQRSQT/.789:

要件を充足できることが分かっている時、実装手段の遵守の確認の精度が、セキュリティ要件

BCDEF7UVW

図 1：提案方式のシステム構成と流れの充足度(保証度)として利用できる。
上記の性質を利用して、実装手段の確認の容[IJ\]W
4

提案方式は、大別して二つの部分から構成さ易性から作業量や作業内容を導出することによれる：

り、セキュリティ要件に必要な作業の見積もり(1) セキュリティ専門家による、実装手段蓄積を容易にできる。
(2) 実装手段間の相互関係と代替手段(1)で挙げた各実装手段を同一のセキュリテ
ィ要件に対する充足という関係でみると、重複や手段間の依存関係が存在する。そのため実装手段により作業の見積もりを行う際には、重複情報データベースの作成(2) プロジェクト管理者による作業見積もりと、各開発担当者向け指示書の生成
以下に、これらの詳細を述べる。
(1) セキュリティ専門家による、実装手段蓄
積情報データベースの作成セキュリティ専門家が、各システム要件およト情報を入力し、入力情報と(1)の蓄積情報をもびセキュリティ要件ごとに、実装手段の候補一とに提案方式のシステムが作業情報の見積もり覧を作成する。これらの候補は、実施を強制すと指示書の生成を行う。手順は以下の通り：ることでセキュリティ要件を満たすことが可能

1. プロジェクト管理者は、システム要件、なものとする。その際、前節で述べた相関関係

セキュリティ要件および、各プロジェを利用するため、下記のデータの入力、定義をクトの情報をシステムに入力する。

行わせる。

プロジェクト情報として入力するデー(a) 実装手段間の AND/OR/XOR 関係(b) 代替手段候補の定義および AND/OR/X
OR 関係(b) 実装手段の限定方法(特定の部品や実装手順の利用を強制する、特定の部品や実装手段の利用をタの例を表 2 に示す。
(PI-1)

セキュリティ専門家要員数(PI-2)

非専門家の要員数(PI-3)

プログラム規模(PI-4)

作業者の作業単価

表 2 入力するプロジェクト情報禁止するなど。これらのパターン化に

2. 提案システムは実装手段情報データベより、下記のセキュリティ知識の要否、ースから要件に該当する実装手段群を精度、費用、工数等の計算を効率化で抽出し、必要な実装手段の選択肢をプきる)ロジェクト管理者に与える。

(c) 実装手段に対する三つの観点(制約の実

3. ここでプロジェクト管理者が実装手段施、実装箇所の検出、制約違反の検出)を選択すると、提案システムは(1)で定ごとの、セキュリティ知識の要否、精度、義した情報とプロジェクト情報から、調達費用、実装手段の選択により新規にセキュリティのために新規に発生する追加となる工数等のパラメータの概算作業の情報およびコストを導出し、プ値ロジェクト管理者に提示する。作業情(データの詳細を表 1 に示す)。

報の導出の例を表 3 に示す。

(A)

(B)

(C)

制約または代替案実施に必要な作業情報

実装箇所の検出に必要な作業情報
制約の違反検出に必要な作業情報(A-1)

セキュリティ専門家による追加工数(、kstep あたり人日)(A-2) 非専門家による追加工数(A-3) 偽陽性(%)(A-4) 偽陰性(%)(A-5) ツールの利用可能性(A-6) 調達費用(円)(A-7) セキュリティ知識の要否(A)と同様の構造(A)と同様の構造

表 1 実装手段情報のデータ構造(詳細)(PO-1)(PO-3)(PO-4)

作業見積もり情報
セキュリティ
保証レベル

セキュリティに必要な追加費用
セキュリティに必要な追加期間見積もりの導出方
法
100-[(A-4),(B-4),(C-4),の最大値](((A-1)+(B-1)+(C1)) (PI-1)+((A-2)+(B-2)+(C-2)) (PI-2))(PI-3)/((PI-1)+(PI-2))(A-6)+(B-6)+(C-6)+(PO-2) (PI-4)(PO-2)/((PI-1)+(PI-2))

表 3 作業見積もりと導出方法

4. プロジェクト管理者は実装/代替手段の(2) プロジェクト管理者による作業見積も組み合わせを変えて繰り返し見積もりりと、各開発担当者向け指示書の生成を行い、最終的にプロジェクトの要件各アプリケーションの開発プロジェクトにおに合致する手段を確定する。

いて、プロジェクト管理者が要件とプロジェク

5. システムは蓄積情報データベースの実装手段情報から規約ドキュメント、開発ガイドライン、テスト指示書の雛形を生成し出力する。
5. 提案方式の机上検討
筆者らは提案した開発方式のうち、(1)セキ
ュリティ専門家による実装手段案の作成と、(2)各開発プロジェクトにおける作業情報の取得の有効性について、Web アプリケーションのセキ
ュリティ要件を対象に、机上検討を行った。検討の目的は以下を確認することである。
・ 実装手段に関する情報をセキュリティ専門家が洗いだし、本提案方式のデータ構造に従って定義できる
・ 各プロジェクト管理者に対して、規約として与えるべき実装手段の候補が提示され、かつ全体として必要な作業の質および量、コストが判断材料として明示できる
Web アプリケーションのセキュリティ要件

次に、上記手段候補の詳細情報を定義する。
定義した例を表 5 に示す。
(A-1)

(A-2)
(A-3)
(A-4)
(A-5)
(A-6)
(A-7)

情報
セキュリ
ティ専門家による
工数
非専門家
による工数
偽陽性(%)
偽陰性(%)
ツールの利用可能性
費用(円)
セキュリ
ティ知識の要否

(B)
(C-1)
(C-2)
(C-3)
(C-4)
(C-5)
(C-6)
(C-7)

(実装 1)0(実装 2)
0.1(代替 1)
0.1

00.2

250
50
ツール+手作業

手作業

手作業

0不要

0
要100 万要(略)0000
ツール0不要(略)
0.2
0.4
3030手作業0要(略)表 5 実装手段情報の定義例

表 5 の結果を見ると、(実装 1)の違反の検出から SQL インジェクションを例として選び、作業において(C-5)はツールが利用できるため、検証を行った。システム要件はすべて Java+Se違反の検出が最も容易であることがわかる。

rvlet+JSP とした。なお、要件に対して挙げる(2) プロジェクト管理者による作業見積もり

実装手段(脆弱性への対策)の十分性、網羅性などは、本稿では議論の対象としない。

ここではまず、
プロジェクト情報を入力する。
(PI-1)

Java における SQL インジェクション対策とセキュリティ専門家要員数0(人)して、セキュリティ専門家が実装手段を 2 つ候(PI-2)

非専門家の要員数(人)10補として抽出したと仮定し、本提案方式の検証(PI-3)

プログラム規模(kstep)50を行う。

(PI-4)

作業者の作業単価(円/日)

3万(1) セキュリティ専門家による実装手段蓄積情報の作成

入力したプロジェクト情報と実装手段情報にまず、実装手段間の関係を定義し、対応する代替手段を定義する。代替手段を含めた実装手段の候補例を表 4 に示す。
(実装 1)(実装 2)(代替 1)

表 6 プロジェクト情報入力例

SQL文の実行にはjava.sql.PreparedSta
tement のみを使用する
SQL 実行の直前で危険な文字をエスケープする
ブラックボックス形式による第三者監査によってインジェクションが起きないことを確認する。

表 4 実装手段候補例

セキュリティ専門家としては、
表 4 の中では、(実装 1)を推奨したいものの、この時点ではその根拠が提示できない状態である。

より作業情報を導出した結果を表 7 に示す。
セキュリティ保証レベル
必要工数(人日)
必要な費用(円)
必要な期間(日)セキュリティ専門家の要否(実装 1)
100(実装 2)70

選択なし
5000035105 万
3.5 日

100400 万
10 日

不要

要要

表 7 作業情報の導出

プロジェクト管理者は表 7 で得られた情報と自己のプロジェクトの予算や納期、セキュリティ専門家要員などの情報を比較し、プロジェク

トの許容する範囲で実装手段を選択できる。表ュリティ要件を満たすものかどうかの検証方法が、7 の場合では、セキュリティ専門家として推奨いまだ人手の作業に依存している。今後は、これしたい実装手段(実装 1)が、本提案方式の試算にらの作業に対する技術的な支援方法についても研より、プロジェクト管理者にとっても最善(コス究していく予定である。

トが最小、かつ最も高い保証レベル)になることを提示できた。

文献

6. まとめ
本稿では、実装方式の限定が、セキュリティ要[CC05]

件の維持、確認に必要な作業に影響を与えること

http://www.commoncriteriaportal.org/public/develに着目した。また、その関連に基づき、実装方式

oper/index.php?menu=2, 2005.

を限定することにより、セキュリティ要件を満た[HDL04] M. Howard and D. LeBlanc, “Writing

すために必要な作業の情報を開発の早期においてSecure Code Second Edition, Microsoft Press,得られる開発方式の提案を行った。また、Web ア

2002.

プリケーションにおける一般的なセキュリティ要[McG98]G. McGraw, Testing for security during

件に対して提案方式の机上検証を行い、セキュリ

development:

CommonTechnology

Criteria

Security

for

Information

Evaluation

v2.3,

Why

weshould

scrap

ティ上も妥当な結果が導出されることを確認した。 penetrate-and-patch”,

IEEE

Aerospaceand今回、机上検証に用いた作業のコスト試算のためElectronic Systems, 1998.のパラメータは、あくまで概算でしかなく、試算[PM04] B. Potter and G. McGraw, “Softwareの精度には向上の余地がある。ただし、本稿の主

security testing”, Security & Privacy Magazine,

な目的は試算精度の向上よりも、むしろ実装手段

IEEE Volume: 2 Issue: 5 Sept.-Oct. 2004 pp. 81-を限定することで、セキュリティ知識の希薄なプ

85, 2004.

ロジェクト管理者にも、「セキュリティ品質と作業[Ray03] Amab Ray: “Security check: a formal yet

コスト」という、明確な指標を提示し得ることをpractical示すことにあった。その目標については、一例でarchitecture”, Proceedings of the 2003 workshop

はあるが、今回の検証で確認できたと考える。

on New security paradigms, pp. 59-65, 2003.

紙面の都合上割愛したが、他の机上検証の結果、[Roy70]framework

W.

W.

Royce,

software“Managing

由でツールのみでは実装手段の遵守、違反の確認

Proceedings of the IEEE WESCON, IEEE Press

が難しいものも多くあることがわかった(Session&Fixation 対策の認証時のセッション切り替えや、Conference on Software Engineering, IEEE Press,

Cross site Request Forgeries に対する対策な1970.

ど)。これらの対策が確実に実施されていることを[Tom03] H. H. Thompson., “Why security testing

保証するためには、確認手段の自動化技術についis hard”, Security & Privacy Magazine, IEEEても、さらに検討する必要があると考える。

Volume: 1 Issue: 4 July-Aug. 2003 pp. 83- 86,

oftheSoftware

theDevelopment

Proceedings

Largesecure

ツールが未整備であるか、技術的に困難などの理筆者らは、今後、提案方式を実現するシステム

offorNinthSystems”,

International2003.の試作を行い、実際のプログラム開発に適用して、[Wei95]C.

その有効性を検証する予定である。

Information security: an integrated collection of

また、本稿の提案方式では、実装手段情報の作Weissman.

“PenetrationTesting”,essays, IEEE Computer Society Press, Silver

成時において、要件からそれを満たすような実装

Springs, MD, 1995

手段候補を生成する方法や、実装手段候補がセキ.[Jür04]

JanJürjens,“SecureSystems

Development with UML”, Springer, 2004.