平成 21 年度電子政府に係る情報システムの セキュリティ強化の取組みに関する調査
報告書
平成 22 年 3 月
株式会社サイバーディフェンス研究所
2
目次
1 はじめに...3
1.1 用語の定義...3
2 背景...5
3 目的及び実施概要...9
3.1 目的...9
3.2 調査の進め方...9
4 文献等調査及び個別ヒアリング等の実施結果... 11
4.1 情報システム開発手法及び保証のあり方の検討... 11
4.1.1 実施概要... 11
4.1.2 実施結果... 11
4.1.2.1 情報システムのリスクアセスメント、品質保証、ダメージコントロールの手法.... 12
4.1.2.2 国際標準等に基づく情報セキュリティの評価・認定・監査... 27
4.1.2.3 EA 等の全体最適化手法及び TCO の最小化... 35
4.1.2.4 課題解決に有効な「関連組織等各分野業務の関連性」... 44
4.1.3 現状に関する調査及び分析... 45
4.1.3.1 情報システムにおけるセキュリティ対策の現状... 45
4.1.3.2 システム調達における情報セキュリティ対策の課題及び意見... 46
4.1.4 課題解決の考え方... 49
4.1.4.1 課題解決の考察... 49
4.1.4.2 リスク要件リファレンスモデル（RM）の考案... 51
4.2 政府機関における情報システム関連基準のあり方の検討... 56
4.2.1 実施概要... 56
4.2.2 実施結果... 56
4.2.2.1 政府機関統一基準と最適化指針の相関関係の整理... 56
4.2.2.2 点検リスト... 59
4.3 政府機関の情報システム調達における課題解決... 69
4.3.1 システム類型化等のあり方の検討... 69
4.3.2 関係基準の運用体制及び手法等に関する検討... 71
4.3.3 情報システム調達におけるリスク要件リファレンスモデル（RM）活用の課題解決 72 5 検討会の概要... 78
5.1 検討会の概要... 78
5.2 検討会の実施... 78
6 まとめと提言... 80
6.1 継続検討事項について... 80
6.2 今後の進め方について... 81
3
1 はじめに
本報告書は、株式会社サイバーディフェンス研究所が、内閣官房情報セキュリティセンター
（以下、NISC）から受託し、「平成 21 年度電子政府に係る情報システムのセキュリティ強化の取り 組みに関する調査」を実施した結果をまとめたものである。本調査は、平成 21 年 6 月 21 日情報 セキュリティ政策会議で決定された「セキュア・ジャパン 2009」における施策の一つとして、政府 全体を通じて情報システムに情報セキュリティ対策が企画・設計段階から組み込まれる方策の ための材料を得ることを目的として実施された。
セキュア・ジャパン２００９ （抄）
第３章 ２００９年度に取り組む重点政策 第１節 対策実施４領域における取組みの推進と 政策目的の着実な実現
（１）対策実施４領域 ①政府機関・地方公共団体 ［政府機関］
（イ）政府全体を通じて情報システムに情報セキュリティ対策が適切に組み込まれる仕組みの 構築
ア）企画・設計段階からの情報セキュリティ対策の組込みについても意識するための方策 の検討
「情報システムの企画・設計段階からの情報セキュリティ対策の組込みについて意識す るための方策（Security by Design）について、２００９年度は、政府機関統一基準に基づき つつ、調達者と調達先ベンダの協業のあり方について検討するとともに、セキュリティを考 慮した情報システム開発手法及び保証のあり方についての調査等を行う。」
1.1 用語の定義
本報告書で記載する略称等を、次のとおり定義する。
• 政策会議
高度情報通信ネットワーク社会推進戦略本部令（2000 年政令第 555 号）第 4 条の規 制に基づき、官民における統一的・横断的な情報セキュリティ対策の推進を図るため、
高度情報通信ネットワーク社会推進戦略本部に設置されたもので、我が国の情報セキ ュリティに関する問題の根幹に関する事項を決定する情報セキュリティ政策会議のこと。
• 基本計画
政策会議において、我が国の情報セキュリティ問題への取組みを推進するための中 長期の戦略計画として決定されたもので、2006 年度から 2008 年度までを対象とした第 1 次情報セキュリティ基本計画（2006 年 2 月 2 日 第 4 回政策会議決定）と、それを引き継 ぐものとしての 2009 年度から 2011 年度までを対象とした第 2 次情報セキュリティ基本
4
計画（2009 年 2 月 3 日 第 20 回政策会議決定）のこと。本報告書では、第 2 次情報セ キュリティ基本計画のことを示す。
• セキュア・ジャパン
政策会議において、基本計画の目指した「セキュア・ジャパン」の実現（真に「情報セキ ュリティ先進国」）を目指して、年度ごとの具体的な施策を年度計画として策定されたも の。第 1 次基本計画におけるセキュア・ジャパン 2006 から同 2008、第 2 次基本計画に おけるセキュア・ジャパン 2009 がある。
• SBD（Security By Design）
電子政府における情報システムの企画・設計段階からの情報セキュリティ対策の組込 みについて意識するための方策のこと。
• 政府調達の基本指針
情報システムに係る政府調達の基本指針（2007 年 3 月 1 日 CIO 連絡会議決定）のこと。
• 政府機関統一基準
本報告においては、政府機関の情報セキュリティ対策のための統一基準（第 4 版）（2009 年 2 月 3 日第 20 回政策会議決定）のことを示す。
• 最適化指針
業務・システム最適化指針（ガイドライン）（2006 年 3 月 31 日 CIO 連絡会議決定）のこと。
• 点検リスト
DM7-03-091 情報システムに関する情報セキュリティ対策実施確認のための点検リス ト策定手引書（第 2 版）」の付表 1（2009 年 9 月 14 日改訂）のこと。
• 各種指針等
政府調達の基本指針、最適化指針等、その他、各府省庁での情報システムの調達に おいて準拠することになっている文書等のこと。
• 作業工程
情報システムのライフサイクルにおいて、企画、要件定義、設計・開発、運用・保守等 の一連の作業の集約的な単位のこと。作業工程の区分方法は目的や粒度の考え方の 相違に応じて、各種指針等毎に異なるが、本報告書では、企画、設計・開発、運用、保 守とする。
• リスクと脅威
本報告書における「リスク」とは、対象となる特定領域に損失を与える可能性（危険 性）のことを示し、「脅威」とは、その要因のことを示す。
5
2 背景
行政をはじめ様々な関連分野における IT の積極的な利活用が進む中、情報システムはま すます業務推進の基盤となり、システム化対象となる業務が大規模化、複雑化してきている。そ のため、その要求は多様化し、IT と業務活動との密接度の高まりにより、それまでの局所的な 業務効率化と比べて、上流工程で決めなければならない事が複雑化かつ増加してきている。し たがって、要件を決めなければならないステークホルダーが増加している一方で、要件定義をし っかり実施するための取り組みの重要性が高くなってきている。
電子政府構築においては、EA（Enterprise Architecture）策定ガイドラインが整備されており、
その中で EA とは「組織全体の業務とシステムを統一的手法でモデル化し、部局ごとではなく
『全体最適』の観点から業務システムを同時に顧客志向に改善していくための組織の設計・管理 手法」と定義している。言い換えると、組織と業務システムの全体構造に対し、整合性を持って設 計～管理するためのシステム見取り図というべきものが存在している。
しかしながら、2004 年経済産業省が組込みソフトウェアについて調査した資料によると、開発 案件において、「手戻り率 30％未満」という回答が全体の 62％となっている。一方で、「手戻り率 90～100％」という回答も 8％あった。また、「手戻りなし及び不明 13.8％」を除いた、約 86％で手 戻りが発生している。
（出典元： 2004 年版 組込みソフトウェア産業実体調査報告書 平成 16 年 6 月 経済産業省 商務情報政策局 情報政策ユニット 情報処理振興課）
図 1 製品出荷前の工程間の組込みソフトウェア手戻り頻度
6
手戻りの理由としては、「要求仕様の不備」を第 1 の理由と回答したケースが 30％程度で最 も多く、「仕様書の不備」も合わせ、要求仕様に関する不備を理由として挙げているのは約 50％
となる。これは件数ベースによる割合であるため、要求仕様の不備が原因となる手戻りにより発 生する工数の全体開発工数に占める割合は更に大きいと考えられる。
（出典元： 2004 年版 組込みソフトウェア産業実体調査報告書 平成 16 年 6 月 経済産業省 商務情報政策局 情報政策ユニット 情報処理振興課）
図 2 組込みソフトウェア手戻り原因（理由 1 の割合）
このように、企画段階の要求仕様フェーズにおける工数が増加し、要求仕様の獲得と分析が 複雑かつ困難になっているため、要求仕様の不一致により、開発段階における手戻りが頻発す るという問題が発生している。このため、システムの構想や計画といった要件定義以前からの
「超上流工程」において、発注者及び受注者の間で合意形成することによって、開発途中の手戻 りを減らす取り組みの重要性が高まってきた。
一方、電子政府構築計画の見直しにおける IT 化に対応した業務改革において、「システム 刷新による投資対効果の明確化」や「随意契約から競争入札への移行」等の取り組みが実施さ れる中で、明確な要求仕様の策定が求められるようになってきた。
7
以上のような背景のもと、2005 年 9 月 15 日に開催された政策会議第 2 回会合において、「政 府機関の情報セキュリティのための統一基準（2005 年項目限定版）」及びその運用指針等が決 定された。これは、各府省庁の情報セキュリティ対策の整合化・共通化を促進し、政府機関全体 としての情報セキュリティ水準の向上を図ることを目的としたものであった。これは、緊急度の高 い対策のための基礎となる基準を中心に項目を限定して策定したものである。同年 12 月 13 日に は、政策会議第 3 回会合においては、「政府機関の情報セキュリティ対策のための統一基準
（2005 年 12 月版（全体版初版））が決定された。これは、システムの開発や整備に関する対策項 目等が追加された。その後、2007 年 6 月 14 日に第 2 版、2008 年 2 月 4 日に第 3 版と改訂が され、2009 年 2 月 3 日に開催された政策会議第 20 回会合において「政府機関における情報セ キュリティ対策のための統一基準（第 4 版）1」（以下、政府統一基準）が決定された。
また、2006 年 2 月に開催された政策会議第 4 回会合において、「第１次情報セキュリティ基 本計画」が決定された。これは、我が国の情報セキュリティ問題を俯瞰した中長期戦略をさだめ たものである。また、IT 戦略本部情報セキュリティ専門調査会に設置された情報セキュリティ基 本問題委員会2の第 1 次提言3及び第 2 次提言4、両提言を受けた政府での取り組み、そして、
本基本計画の審議に資するために情報セキュリティ政策会議の下に設置されたセキュリティ文 化専門委員及び技術戦略専門委員会の両報告書を踏まえて作成されている。
2007 年 12 月 12 日に開催された政策会議第 15 回会合において、行政情報システムの企画・
設計段階からのセキュリティ確保に向けた取り組み（セキュリティ・バイ・デザイン［SBD］）につい ての検討がされた。それ以降、現在まで継続的な検討が行われている。
2008 年 6 月 19 日に開催された政策会議第 18 回会合では、第 １ 次情報セキュリティ基本 計画を受けて、2008 年度における我が国の情報セキュリティ対策の政府の重点施策を定める年 度計画として、「セキュア・ジャパン 2008」が決定され、”電子政府として構築が進みつつある各種 業務・システムに適切に情報セキュリティ要件が取り入られることは必要不可欠であり、情報セ キュリティ基本コンセプトとして取り入れられた情報システムの企画・設計が行われるための方策 について検討を進め、得られた成果を政府機関政策に反映する”という具体的施策を実施するこ とが定められた。さらに、2009 年 6 月 22 日に開催された政策会議第 18 回会合で決定された
「セキュア・ジャパン 2009」では、”情報システムの企画・設計段階からの情報セキュリティ対策の 組込みについて意識するための方策（Security by Design）について、2009 年度は、政府機関統 一基準に基づきつつ、調達者と調達先ベンダの協業のあり方について検討するとともに、セキュ
1 http://www.nisc.go.jp/active/general/pdf/K303-081.pdf
2 平成 18 年 2 月に開催された政策会議第 4 回会合において、「第 １ 次情報セキュリティ基本 計画」が決定された。
3 情報セキュリティ基本専門委員会第 1 次提言（2004 年 11 月 16 日）
4 情報セキュリティ基本専門委員会第 2 次提言（2005 年 4 月 22 日）
8
リティを考慮した情報セキュリティ開発手法及び保証のあり方について調査等を行う”という具体 的施策を実施することが定められた。
さらに、2008 年 12 月 26 日には、NISC は政府統一基準に基づく情報システムのセキュリティ 確保の推進において、”新しく構築される個々の行政情報システムについて、利便性と効率性と のバランスを維持しつつ情報セキュリティの観点を着実かつ容易に盛り込めるような取組を進め る”施策の一つとして、「DM7-03-081 情報システムに関する情報セキュリティ対策実施確認の ための点検リスト策定手引書」を公開した。2009 年 9 月 14 日には、第 2 版として、「DM7-03-091 情報システムに関する情報セキュリティ対策実施確認のための点検リスト策定手引書」が公開さ れた。
3 年度間（2008～2010 年度）の施策として、2009 年 1 月の準備会合を経て、同年 3 月には、
「情報セキュリティを企画・計画段階から確保するための方策に係る検討会」（以下、SBD 検討 会）が設置され、関連分野の経験・知見を有する有識者やシステム関連事業者を構成員として、
①政府機関統一基準に基づく情報システムのセキュリティ確保の進め方の検討、②セキュリティ を考慮した情報システム開発手法及び保証のあり方の検討及び③政府機関における情報シス テム関連基準のあり方等の検討が開始された（以下、SBD に係る検討）。
2009 年 2 月 3 日の政策会議第 20 回会合では、「第 2 次情報セキュリティ基本計画」（以下、
第 2 次基本計画）が決定され、ここでは今後 3 年間に取り組む重点政策の中に、政府全体を 通じて情報システムに情報セキュリティ対策が適切に組み込まれる仕組みの構築として、”政府 機関における各種情報システムの構築を行うに際して、トータルコストの抑制や利便性・柔軟性 の実現、情報セキュリティの確保といった様々な方向性をもった要件を止揚する観点から、情報 システムの構築や運用段階のみならず、企画・設計段階からの情報セキュリティ対策の組込み についても意識するための方策（Security by Design）を、業務・システムの最適化の取組みと一 体的に推進する仕組みの構築を図る。その際、政府全体として情報セキュリティ対策を含めた情 報システムの TCO（Total Cost of Ownership：システムの導入、維持・管理などにかかる費用の 総額）の低減を推進するための手法について検討を行う。また、情報システムや物品の調達に 際して、必要となる情報セキュリティ対策を設定するために参考となる各種情報を提示し、その 活用を図る”ことが盛り込まれた。
来年度（2010 年度）は、3 年度に亘る SBD に係る検討の最終年度として、検討の取りまとめ及 び成果物の策定等を行うこととなる。
9
3 目的及び実施概要
3.1 目的
本調査は、前述の背景のもと、「セキュア・ジャパン 2009」に基づき、NISC が電子政府の電子 政府の情報セキュリティ強化のための取り組みを検討するために実施した。
具体的には、情報システム企画段階又は設計・開発段階から情報セキュリティ対策を効率的 に検討して実現するための方策を調査しつつ、情報セキュリティ分野及び情報システム分野に おける有識者、システム関連事業者等をメンバとする検討会での議論やメンバに対して行うヒア リング調査等と連携し、相互にフィードバックしながら、電子政府のセキュリティ強化の取り組み の検討を行うことにより、電子政府に情報セキュリティ対策を企画・設計段階から組み込むため の方策の材料を得ることである。
3.2 調査の進め方
受注側における既存開発方法等、発注側における既存制度等との整合を図り、既存の枠組 みをベースにしながら、政府機関におけるシステム調達おける各工程等のすべての段階におけ る確認の仕組みがどうあるべきかの方向性で調査及び検討をする。
受注側においては、開発方法論や品質管理手続き等に内包されているセキュリティ要素と関 係性を明確にする。また、発注側においては、既存の調達制度等に内包されているセキュリティ 要素との整合性を明確にする。
図 3 調査の進め方
10
また、効率的な検討を推進するため、次のような進め方をとった。
y システム関係事業者との検討は、検討会と並行して、必要の都度、直接対話ができる個別 ヒアリング調査の場を積極的に活用した。
（理由） 一同に会した会合の場（検討会など）では、それぞれの事業者からの発言内容に 自社の知的財産に抵触する等の懸念等を抱き、自由闊達な議論が難しい状況が見られた ため。
y 検討会のメンバは固定せずに、情報セキュリティ分野の専門家やシステム関連事業者に対し て、検討会毎のテーマについて議論が可能と思われる方の出席を依頼するプロセスをとった。
（理由） 本検討会で取り扱うべきテーマが広範囲にわたるため、効率的な議論をするには、
検討会毎に設定するテーマに関する専門性や業務経験が必要となるため。
11
4 文献等調査及び個別ヒアリング等の実施結果 4.1 情報システム開発手法及び保証のあり方の検討 4.1.1 実施概要
次のような項目について深く調査及び検討し、各種課題に対する解決アプローチの立案及び 検討会への付議事項の参照元として活用する。
(1) 情報システムのリスクアセスメント、品質保証、ダメージコントロールの手法
情報システムの運用後に実施されるセキュリティ診断等で発見される脆弱性、機能不足、障 害抑制性の不足等は、設計段階で十分な対策を検討していなかったことが原因であることが多 い。そのため、「脅威及びリスクの洗い出し（リスクアセスメント）」、「要求された機能（品質）の確 保（品質保証）」、及び「障害への強さ（ダメージコントロール）」の手法に関して深く調査して、特に、
設計段階における知見や検討材料を得る。
(2) 国際標準等に基づく情報セキュリティの評価・認定・監査
導入を検討している製品を共通のセキュリティ基準で比較することができる ISO/IEC 15408 などの特定目的のためのセキュリティに係る業界基準や、米国政府主導のセキュリティ監査ガイ ドライン CAG などには、様々な観点からの知見やノウハウが凝縮されている。これらを調査し て、情報システムに係る様々な要求事項を得る。
(3) 電子政府に係る情報システムの情報セキュリティ対策の要素も加味した EA（Enterprise Architecture）等の全体最適化手法、TCO（Total Cost of Ownership）の最小化
情報システムの企画及び設計段階においては、全体的なコスト（必要費用）の算定、特に、非 機能的な要求事項となる情報セキュリティ対策にかかるコストを、適正かつ正確に見積ることが 大きな課題となることがある。EA や TCO の概念を仔細に調査し、情報システム対策の「コス ト」的な側面における知見、考え方及びノウハウを得る。
(4) 課題解決に有効な「関連組織等各分野業務の関連性」
情報システムの設計・開発段階において、SBD の観点で、関係性のある組織や団体の業務 の特性に着目し、情報セキュリティ対策における課題整理と解決に資する考え方の視点を得る。
4.1.2 実施結果
情報システムの企画段階及び設計・開発段階におけるセキュリティ機能の具備に係る諸事項 を調査した結果、次のような関係性の深い手法等を得ることができた。
12
4.1.2.1 情報システムのリスクアセスメント、品質保証、ダメージコントロールの手法 (1) 情報システムのリスクアセスメント手法
情報セキュリティにおけるリスクアセスメント手法は、保険業界などで利用されている統計的手 法を基に展開されている。現実的には、損害などが生じる可能性が高い要因や被害等の影響の レベルにより、様々な手法を組み合わせるのが一般的である。
また、セキュリティ要件を見出すためには、リスクアセスメントが強く求められる。そのため、現 在認識されているリスクアセスメントの手法を広く把握するには、SBD の検討に必要不可欠であ ると言える。
a. コートニィ理論によるリスクアセスメント手法
1992 年、英国のリチャード・コートニィにより提唱されたリスク分析手法。
コートニィ理論による分析方法は、リスクが定量的に示されるため、大変わかり易い。リスクア セスメントの目的である、リスクの定量化や金額換算による評価という要求に適合するものであ る。
b. GMITS におけるリスクアセスメント手法
GMITS（Guidelines for the Management for IT Security）は、情報システムを管理するためのガ イドラインのことで、1991 年より ISO5 において標準化が検討されているものであり、1996 年に
「ISO/IEC TR6 13335」として公表された。
GMITS は、組織としてのセキュリティ戦略、セキュリティポリシーの作成、情報システムの運用 にかかわる人や情報処理機器類の管理に必要な要件を規定したもので、次のパートで構成され ている。
Part1: コンセプトとモデル Part2: 管理と計画 Part3: 管理手法
5 ISO: International Organization for Standardization、国際標準化機構
6 TR: Technical Report、JIS とは異なる種類の情報を、規格関連情報やデータ集として提供し、
標準化の推進に資するものとして公表される標準文書。TR は、原則として発行後 5 年をもって廃 止となる。
（リスク) ＝ (脅威の発生頻度) × (被害の大きさ)
被害には、「①故意による暴露、変更、破壊」と 「②偶然による暴露、変更、破壊」がある。
13 Part4: セキュリティ対策手法
Part5: ネットワーク接続のガイドライン
また、GMITS の対象は、基本的に電子媒体であるが、「IT セキュリティマネジメントは、適切 なレベルの機密性、完全性、可用性、責任追跡性、真正性、及び信頼性を達成して維持するた めのプロセスである」と定義している。BS7799、ISO/IEC TR 17799、ISMS における認定基準で ある「機密性、完全性、可用性を維持すること」よりも広範で詳細となっている。
GMITS において規定されている情報システムのリスク分析手法。
GMITS の Part3（管理手法）において、リスクアセスメントに関する４つのアプローチが示されてい るが、詳細リスクアプローチとして、情報資産に対して「脅威」と「脆弱性」を特定し、リスクアセス メントを実施する。「脅威」と「脆弱性」を分離してコントロールを選択することにより、洗い出しす べき項目を簡易化させることができる。さらに、「資産価値」「脅威」「脆弱性」の判断を経営者、専 門家、運用者がそれぞれの項目について責任を持つため、現実に沿った判断が可能になる。し かし、その反面として、各項目値の評価が曖昧になる可能性が高く、特に脅威と脆弱性について の網羅性が課題となることが多い。
表 1 GMITS による 4 つのリスクアセスメントアプローチ
No. リスク分析の種類 用途 内容 備考
1 ベースラインアプロ ーチ
基 本 的 な 対 策 を 短 時 間 で 策 定 す る 場合
既存のセキュリティ対 策基準から、対象の 情 報 資 産 の コ ン ト ロ ールを選択
概括的で簡易ではあ るが、対策が過ぎた り 、 不 足 す る 恐 れ あ り。マネジィアルアプ ローチ
2 詳 細 リ ス ク 分 析 ア プローチ
対 象 の 情 報 資 産 の 個 々 に最適なリス ク対策を策定 する場合
情報資産価値を特定 し脅威と脆弱性の評 価 を 実 施 し た 上 で 、 設 定 し た リ ス ク の 許 容レベルのコントロー
個々に適した対策が 可能だが、専門技術 と、多くのリスク分析 の作業が必要。テク ニカルアプローチ
（リスク） ＝ （資産価値） × （脅威） × （脆弱性）
経営者の判断
専門家の知識
運用の状況
14
ルを実施 3 非形式アプローチ 対 象 範 囲 の
規 模 が 小 型 で 適 当 な 場 合
対策を実施する対象 に合わせて、リスク分 析技術者の技術と経 験で、コントロールを 選択
対策に時間がかから ないが見落としや過 不足が生じやすい。
マネジィアルアプロー チ
4 組み合わせアプロ ーチ
大規模、複雑 なシステムの 場合、多くの バランスよい 対策をとる場 合
１と２の組み合わせで 対 策 を 作 成 す る の で、リスクの軽い部分 と、影響が重大な場 合を判別し、コントロ ールを選択
重要部分と他の部分 の バ ラ ン ス が と れ た 対 策 に よ り 、 適 切 な 対策が可能折衷型
（出典元： JASA 技術部会 WG3 リスクアセスメント調査報告書 Ver1.0 平成 16 年 3 月 31 日）
c. DISC PD3000 におけるリスクアセスメント手法
DISC PD3000 は GMITS の情報資産の範囲を IT から一般の情報資産までに拡大したアプ ローチをとったもので、BS7799 のリスク分析手法として仕様化されたものである。詳細リスク分 析アプローチにより、管理基準をチェックリストとし、基準からの差異（GAP）を特定し、脆弱性を 分析しリスクを判定する手法である。メリットとして網羅性高めることができ、自動化ツールなどに 使われる事例がある（例： BS7799-GAP 方式）。
脆弱性の網羅性の根拠を、様々なガイドライン（規定、業界基準）に求めることができる利点が ある。ただし、システム固有の脆弱性や新たな脅威は、別途補う必要がある。
d. ALE 方式によるリスクアセスメント手法
米国 NIST（国立標準技術研究所）が、1977 年に開発した、定量的リスクアセスメントの方式で あ り 、 損 失 評 価 額 レ ベ ル と 発 生 頻 度 レ ベ ル か ら 、 年 間 の 予 想 損 害 額 ALE （ Annual Loss Exposure）の近似値を求めることが可能な手法である。
（リスク） ＝ （資産価値） × （脅威） × （脆弱性 ）
※管理基準をチェックリストとし、基準からの差異（GAP）に基づき脆弱性を分析する
（年間予想損失額）
＝ （損失評価額 [／回]） × 発生頻度 [回／年]）
15
厳密なリスク分析が必要な場合には最適な手法といえる。しかし、発生頻度と損失評価額の 想定は容易ではなく、リスクアセスメントを実施する能力が高く求められる。
e. その他のリスクアセスメント手法
情報セキュリティアセスメントの必要性については OECD7 の「情報セキュリティガイドライン」
における「リスクアセスメントの原則」に示されている。また BS7799/ISMS においてもリスクアセ スメントの実施が最も重要かつ必須とされている。しかし、具体的な手法を定めているわけでは なく、それぞれ最適と判断される手法を選択し実施することになる。
次の表に情報セキュリティで利用される代表的なリスクアセスメント手法を示す。
表 2 情報セキュリティリスクアセスメント手法
No. 手法 手法の特徴
1 GMITS（Guidelines for the Management for IT Security）
ISO/IEC TR 13335 が紹介している IT セキュリティの分析 手法である。情報資産の価値と関連する脅威の大きさと脆 弱性の大きさからリスク値を算定する。
2 DISC PD3002（BS7799
－GAP 方式）
GMITS の情報資産の範囲を IT から一般の情報資産に まで拡大したアプローチを取る。予め採用を決めたセキュリ ティのガイドラインをベースにし、脅威と脆弱性を分析する ことにより、組織のコントロールの実施状況を評価する GAP 分析手法である。
3 JRAM （JIPDEC Risk Analysis Method）
ホスト集中型システムを対象にした質問票の回答結果から 脆弱性を洗い出して点検評価し、JRAM 分析シートで、過 去のセキュリティ事故の損失額を洗い出す。システムの安 全性が合格レベルにあるか計ることを目的としている。
4 JRMS （JRAM 2002） 企業全体のリスクマネジメントがベース。JRAM を改良して ネットワーク分散型システム向きにした質問票で、得点方 式、定性的リスク分析、定量的事故解析による、脆弱性を 分析するリスク分析方法である。
5 CRAMM （CCTA Risk Analysis and
Management Methodology）
英国大蔵省（CCTA）と英国規格協会（BSI）が共同開発し た。資産の識別、資産評価を質的技法と量的技法を併用し ている。脅威、脆弱性を定量化し、推奨する対策を生成し、
リスクを許容レベルにする。
7 OECD: Organization for Economic Co-operation and Development、経済協力開発機構。
16 6 ALE (Annual Loss
Exposure)
米国商務省標準局 NIST が事象の損害額と発生確率か ら年間予想損失額を近似計算で算定する。各情報資産の ALE を CIA 別に分類集計する。
7 FTA
(Fault Tree Analysis)
システムの信頼性･安全上、望まない事象全て想定し、原 因事象を階層的に表現する。故障、不正動作、人的エラー 等の因果関係を示し、発生確率から事故発生確率が出る。
最近では情報セキュリティにおいても詳細で厳密な対策を 取るものに適用できる。
f. リスクアセスメント手法における脅威と脆弱姓
情報セキュリティでは、リスクを特定するために、脅威の特定を行う。脅威とは、対象となる情 報資産に損失を与える可能性のある要因である。このような脅威を分類することで、脅威の本質 的な分析がしやすくなる。
GMITS においては、次のような脅威の分類が示されている。
• 環境的脅威(E: Environmental threat)
自然災害などの文字通り環境によってもたらされる脅威
• 人為的脅威(H: Human-induced threat) 人の行為によってもたらされる脅威
• 意図的脅威(D: Deliberate threat)
ウィルスなど、目的を持って発生する脅威
• 偶発的脅威(A: Accidental threat)
プログラムのバグなど、意図せずに発生してしまう脅威
JIS TR X 0036-3（ISO/IEC 13335-3）付属書 C においては、次のような脅威の分類と例が示 されている。
表 3 脅威の分類の例（JIS TR X0036-3 X 0036-3 附属書 C）
脅威の分類 脅威の例
人為的脅威 洪水、争議行動、爆破行動、武器の使用、火事、空調故障、極端 な温度及び湿気、電磁波放射、操作員のエラー、保守のエラー、ソ フトウェアの故障、不正なユーザによるソフトウェアの使用、不正な 方法でのソフトウェアの使用、ソフトウェアの違法な使用、悪意のあ るソフトウェア、回線の損傷
17 意 図 的 （ 計
画的）脅威
故意の損害、盗難、記憶媒体の不正使用、ユーザ ID の偽り、違 法なソフトウェアの輸入/輸出、不正なユーザによるネットワークへ のアクセス、不正な方法でのネットワーク設備の使用
偶発的脅威 停電、断水、ハードウェアの故障、電力の不安定、ネットワーク構 成要素の技術的障害、送信エラー
環境的脅威 地震、洪水、台風、落雷、電力の不安定、極端な温度及び湿気、
ほこり、電磁波放射、静電荷、記憶媒体の劣化
脅威の発生に関わる要因として、脆弱性がある。脆弱性とは、意図されたのとは異なった方法、
又は目的で使用できる情報資産の性質又は属性であり、脅威の発生原因（悪意をもった人等）
によって利用されることにより、リスクの顕在化を引き起こすものと定義される。
JIS TR X 0036-3（ISO/IEC 13335-3）付属書 D においては、次のような脆弱性の分類と例が 示されている。
表 4 脆弱性の分類と例（JIS TR X 0036-3 附属書 D）
分類 脆弱性の例
環境及び基礎構造 y 建物、ドア及び窓の物理的保護の欠如
y 建物、部屋への物理的アクセス管理の不適当又は不注意な使用 y 不安定な電力配電網
y 洪水の影響を受けやすい地域への配置 ハードウェア y 定期的な交換計画の欠如
y 電圧の変化に対する影響の受け易さ y 温度変化に対する影響の受け易さ
y 湿気、ほこり、汚れに対する影響の受け易さ y 電磁放射に対する影響の受け易さ
y 記憶媒体の不十分な保守/不適当な設置 y 有効な構成変更管理の欠如
ソフトウェア y 開発者のための不明確又は不完全な仕様書
y ソフトウェアのテストをしない、又は不十分なソフトウェアのテスト y 複雑なユーザインタフェース
y ユーザの識別及び認証メカニズムの欠如 y 監査証跡の欠如
y ソフトウェアの公知の欠陥
y 保護されていないパスワードファイル
18
y 不十分なパスワード管理（簡単に推測できるパスワード、平文での パスワードの保管、不十分な頻度での変更）
y アクセス権の誤った割り当て
y 管理されていないソフトウェアのダウンロード及び使用 y ワークステーションから離れる際に“ログアウト”しない y 効果的な変更管理の欠如
y 文書化の欠如
y バックアップコピーの欠如
y 適切に削除されていない記憶媒体の処理又は再利用 通信 y 保護されていない通信回線
y ケーブル接続の欠如
y 送信元及び受信者の識別と認証の欠如 y 平文でのパスワード転送
y メッセージ送受信の証明の欠如 y ダイヤルアップ回線
y 保護されない重要度の高いトラフィック y 不適切なネットワーク管理
y 保護されない公衆回線への接続 文書 y 保護されない保管
y 廃棄時の注意欠如 y 管理されないコピー作成 人事 y 要員の不在
y 外部又は清掃スタッフによる作業時の監督不在
(2) 情報システムの品質保証
開発過程におけるセキュリティの観点からの品質保証の導入が不可欠であることは言うまで もない。納品されたシステム/プログラムへのセキュリティ実装の保証において、設計、開発した 情報システムが十分にセキュアであるという保証を、Sler ベンダから取り付ける必要がある。
a. C/C++ セキュアコーディング（米国 CERT/CC8）
米国 CERT/CC の上級脆弱性アナリストが、ソフトウェアエンジニアが一般に実装する機能 のうち、潜在的にセキュリティに影響するもの（書式指定出力や算術演算など）を中心にまとめた もの。脆弱性につながる安全性を欠くプログラミングと一般的な問題点について述べ、これらの プログラミング上の欠陥がどのように攻撃されるのか、攻撃の結果として想定され得る影響、そ して安全な回避策について説明している。
8 CERT/CC: http://www.cert.org/
19
表 5 C/C++セキュアコーディングの目次 第 1 章 今そこにある危機
1.1 現状認識 1.4 開発環境
1.2 セキュリティの概念 1.5 まとめ 1.3 C と C++ 1.6 参考資料 第 2 章 文字列操作
2.1 文字列の特性 2.7 アークインジェクション 2.2 犯しやすい文字列操作の間違い 2.8 脅威の緩和方法 2.3 文字列の脆弱性 2.9 代表的な脆弱性 2.4 プロセスのメモリ構成 2.1 まとめ
2.5 スタック破壊 2.11 参考資料 2.6 コードインジェクション
第 3 章 ポインタ偽装
3.1 データロケーション 3.8 atexit()と on_exit() 3.2 関数ポインタ 3.9 longjmp()関数 3.3 データポインタ 3.1 例外処理 3.4 命令ポインタの変更 3.11 脅威の緩和方法 3.5 グローバルオフセットテーブル 3.12 まとめ
3.6 .dtors セクション 3.13 参考資料 3.7 仮想ポインタ
第 4 章 動的メモリ管理
4.1 動的メモリ管理 4.5 脅威の緩和方法 4.2 動的メモリ管理に発生する間違い 4.6 代表的な脆弱性 4.3 Doug Lea メモリアロケータ 4.7 まとめ
4.4 RtlHeap 4.8 参考資料 第 5 章 整数演算
5.1 整数型 5.6 非例外的な論理エラー 5.2 整数の変換 5.7 脅威の緩和方法 5.3 整数のエラー条件 5.8 代表的な脆弱性
5.4 整数演算 5.9 まとめ
5.5 脆弱性 5.1 参考資料
第 6 章 書式指定出力
6.1 可変引数関数 6.5 脅威の緩和方法 6.2 書式指定出力関数 6.6 代表的な脆弱性 6.3 書式指定出力関数への攻撃 6.7 まとめ
20
6.4 スタックのランダム化 6.8 参考資料 第 7 章 ファイル入出力
7.1 並列処理 7.4 ファイルシステムへの攻撃
7.2 諸行無常 7.5 脅威の緩和方法
7.3 ロックファイルとファイルロック 7.6 まとめ 第 8 章 実践手法
8.1 安全なソフトウェア開発のための原
則 8.9 データの無害化
8.2 システム品質要求工学 8.1 静的解析 8.3 脅威のモデル化 8.11 品質保証 8.4 ユースケースとミスユースケース 8.12 メモリ保護 8.5 アーキテクチャと設計 8.13 縦深防御 8.6 既製ソフトウェア 8.14 TSP-Secure 8.7 コンパイラによる検査 8.15 まとめ 8.8 入力値の検証 8.16 参考資料
b. C/C++ セキュアコーディングスタンダード（米国 CERT/CC）
C/C++ 言語用の CERT セキュアコーディングスタンダードの目的は、それぞれのプログラミ ング言語で開発されたソフトウェアシステムのセキュリティを確保するために必要な（ただし十分 ではない）一連のルールを定めることである。コーディングスタンダードにより、プログラマは個人 の得意な方法や好みではなく、プロジェクトと組織の要件によって決められた統一的な一連のル ールとガイドラインに従うことができる。また、一度標準が策定されれば、それを（手動又は自動 のプロセスにより）ソースコードの評価基準として使用し、標準への適合を確認することもできる。
CERT が提案しているセキュアコーディングスタンダードは、標準化団体が定める明文化され た標準言語に基づく。例えば、CERT セキュアコーディングスタンダードは次の言語を対象として いる。
* プログラミング言語 C（ISO/IEC 9899:1999）[ISO/IEC 9899-1999]
* プログラミング言語 C++（ISO/IEC 14882:2003）[ISO/IEC 14882-2003]
* プログラミング言語 Java
ISO/IEC TR 24731 C 言語ライブラリ拡張 [ISO/IEC TR 24731-1-2007] のような技術正誤表 や言語拡張に、CERT セキュアコーディングスタンダードを適用することも検討されている。
適用範囲としては、特定の指針を広範なユーザ層に提供することを念頭に置いている。
ISO/IEC が策定するプログラミング言語の標準などは、主にコンパイラ実装者を対象に書かれて
21
いるが、CERT セキュアコーディングスタンダードは、それら標準で定められた言語でプログラム を書く開発者を直接の対象として書かれたルールと推奨事項を示す補助的な文書となっている。
表 6 CERT C セキュアコーディングスタンダード 第 1 章 本コーディングスタンダードの使い方
システムの品質 自動生成されるコード スタンダードへの準拠 第 2 章 プリプロセッサ（PRE）
PRE30-C. 文字列連結によってユニバーサル文字名を作成しない
PRE31-C. 代入、インクリメント、デクリメント、volatile アクセス、又は関数呼び出し を含む引数を使って安全でないマクロを呼び出さない
第 3 章 宣言と初期化（DCL）
DCL30-C. 適切な記憶域期間を持つオブジェクトを宣言する DCL31-C. 識別子は宣言してから使用する
DCL32-C. 相互に可視である識別子が一意であることを保証する
DCL33-C. 関数引数中で restrict 修飾されたコピー元及びコピー先が、重複したオ ブジェクトを参照しないようにする
DCL34-C. キャッシュできないデータには volatile を使う DCL35-C. 関数定義と一致しない型で関数を呼び出さない DCL36-C. 矛盾する結合の種類を使用して識別子を宣言しない 第 4 章 式（EXP）
EXP30-C. 副作用完了点間の評価の順序に依存しない EXP31-C. assert() の中では副作用を避ける
EXP32-C. volatile 修飾子をキャストにより無効にしない EXP33-C. 未初期化のメモリを参照しない
EXP34-C. NULL ポインタを参照しない
EXP35-C. 関数呼び出しの結果の次の副作用完了点よりあとでアクセスや変更を 行わない
EXP36-C. ポインタをより厳密にアラインされるポインタ型に変換しない EXP37-C. API が意図した引数で関数を呼び出す
EXP38-C. ビットフィールドメンバや無効な型で offsetof() を呼び出さない EXP39-C. 適合しない型のポインタを使って変数にアクセスしない 第 5 章 整数（INT）
INT30-C. 符号なし整数の演算結果がラップアラウンドしないようにする
INT31-C. 整数変換によってデータの消失や解釈間違いが発生しないことを保証 する
INT32-C. 符号付き整数演算がオーバーフローを引き起こさないことを保証する INT33-C. 除算及び剰余演算がゼロ除算エラーを引き起こさないことを保証する INT34-C. 負のビット数、あるいはオペランドのビット数以上シフトしない
INT35-C. 整数式をより大きなサイズの整数に対して比較や代入をする際には、
事前に演算後のサイズで評価する 第 6 章 浮動小数点（FLP）
FLP30-C. 浮動小数点変数をループカウンタに使用しない FLP31-C. 実数値を引数にとる関数を複素数値で呼び出さない
22
FLP32-C. 数学関数における定義域エラー及び値域エラーを防止または検出する FLP33-C. 浮動小数点数の演算時には整数を浮動小数点数に変換する
FLP34-C. 浮動小数点の型変換が新しい型の範囲に収まるようにする FLP35-C. 浮動小数点数値を比較する際には精度を考慮する
第 7 章 配列（ARR）
ARR30-C. 配列のインデックスが適切な範囲内にあることを保証する ARR31-C. すべてのソースファイルにわたり一貫性のある配列表記を用いる ARR32-C. 可変長配列のサイズ引数は適切な範囲内にあることを保証する ARR33-C. コピーは必ず十分なサイズの記憶領域に対して行われることを保証す
る
ARR34-C. 式中の配列の型は互換性があることを保証する ARR35-C. ループが配列の最後を越えて反復処理しない
ARR36-C. 異なる配列を指す 2 つのポインタに対して減算や比較を行わない ARR37-C. 配列以外のオブジェクトを指すポインタに対して整数の加算や減算を行
わない
ARR38-C. 結果の値が有効な配列要素を指さないような、ポインタに対する整数の 加算や減算を行わない
第 8 章 文字と文字列（STR）
STR30-C. 文字列リテラルを変更しない
STR31-C. 文字データと NULL 終端文字を格納するために十分な領域を確保する STR32-C. 文字列は NULL 終端させる
STR33-C. ワイド文字の文字列サイズは正しく求める
STR34-C. 文字データをより大きなサイズの整数型に変換するときは事前に unsigned 型に変換する
STR35-C. 長さに制限のないコピー元から固定長配列へデータをコピーしない STR36-C. 文字列リテラルで初期化された文字配列の範囲を指定しない
STR37-C. 文字処理関数への引数は unsigned char として表現できなければなら ない
第 9 章 メモリ管理（MEM）
MEM30-C. 解放済みメモリにアクセスしない
MEM31-C. 動的に割り当てられたメモリは一度だけ解放する MEM32-C. メモリ割り当てエラーを検出し、対処する
MEM33-C. フレキシブル配列メンバには正しい構文を使用する MEM34-C. 動的に割り当てられたメモリのみを解放する MEM35-C. オブジェクトに対して十分なメモリを割り当てる 第 10 章 入出力（FIO）
FIO30-C. ユーザ入力を使って書式指定文字列を組み立てない FIO31-C. 同一のファイルを同時に複数回開かない
FIO32-C. 通常ファイルに固有の操作をデバイスファイルに対して行わない FIO33-C. 未定義の動作となる入出力のエラーを検出して処理する FIO34-C. 文字入出力関数の返り値の取得には int 型を使用する
FIO35-C. sizeof(int) == sizeof(char) の場合、EOF 及びファイルエラーの検出に feof() と ferror() を使用する
FIO36-C. fgets() が改行文字を読み取ると仮定しない
FIO37-C. 読み取られたデータが文字データであると思い込まない FIO38-C. 入出力操作に FILE オブジェクトのコピーを使用しない
FIO39-C. fflush 関数やファイル位置付け関数を呼び出さずにストリームへの入 出力を交互に行わない
23
FIO40-C. fgets() が失敗したときは引数に渡した配列をリセットする FIO41-C. 副作用を持つストリーム引数を getc() 又は putc() に渡さない FIO42-C. 不要になったファイルは正しくクローズする
FIO43-C. 共有ディレクトリに一時ファイルを作成しない FIO44-C. fsetpos() には fgetpos() が返す値を使用する 第 11 章 環境（ENV）
ENV30-C. getenv() が返す文字列を変更しない
ENV31-C. 環境変数へのポインタを無効にするかもしれない操作の後で、そのポイ ンタを参照しない
ENV32-C. atexit() でしたハンドラ関数は必ず return する 第 12 章 シグナル（SIG）
SIG30-C. シグナルハンドラ内では非同期安全な関数のみを呼び出す SIG31-C. シグナルハンドラ内で共有オブジェクトにアクセスしない SIG32-C. シグナルハンドラ内から longjmp() を呼び出さない SIG33-C. raise() 関数を再帰的に呼び出さない
SIG34-C. 割り込み可能なシグナルハンドラ内から signal() を呼び出さない 第 13 章 エラー処理（ERR）
ERR30-C. 関数を呼び出す前に errno をゼロに初期化し、関数の異常終了時に のみ errno を参照する
ERR31-C. errno を再定義しない
ERR32-C. errno の不定の値を参照しない 第 14 章 雑則（MSC）
MSC30-C. 擬似乱数の生成に rand() 関数を使用しない MSC31-C. 関数の返り値は適切な型と比較する
MSC32-C. 乱数生成器は適切なシード値を与えて使う 付録 POSIX（POS）
POS30-C. readlink() 関数を正しく使用する
POS31-C. 他のスレッドのミューテックスをアンロックしたり破壊したりしない POS32-C. 複数スレッドによるビットフィールドへのアクセスは、ミューテックスで保
護する
POS33-C. vfork() は使用しない
POS34-C. 自動変数へのポインタを引数として putenv() を呼び出さない POS35-C. シンボリックリンクの有無のチェック時の競合状態を避ける POS36-C. 権限は正しい順序で破棄する
POS37-C. 権限の破棄は確実に行う
c. セキュア・プログラミング講座（IPA9）
現在、IPA で公開されている新版の「セキュア・プログラミング講座」の内容は、ソフトウェア開 発工程に沿うように編集されている。これは、次の図のような狙いがある。
9 IPA: 独立行政法人情報処理推進機構
