情報セキュリティモジュールの認証製品利用に関するガイドライン
東京大学生産技術研究所

松浦研究室

  平成 年 月­        

目次
第 部 本ガイドラインの位置づけ

背景



対象



理論



第部 ガイドライン





概要





手順一：採択枠組みの開発

「採択枠組み」とは何か？

                        

コストストラクチャの構築                        

リスクストラクチャの構築                        

手順二：候補の分析



総コストの算出                              





リスクスコアの算出                             





リスク許容境界の設定                            

文書化の始動                                 

手順三：統合

候補の選択                                  

選択結果の統合                              

理論に照らした検証                             

文書の更新                                  



手順四：文書化の完了

セキュリティ仕様の作成                           

予算案の準備                                 

要件変更への対応                              

改良改革                                   



第 部

本ガイドラインの位置づけ

背景
情報セキュリティシステムを構築する際に、要件に基づき最適なシステム設計をしたいという要求は強い。しかし残念ながら、技術面だけにとどまらずリスクを科学的に扱う理論基盤に基づいた設計手法や評価手法は存在しない。ただし、システム設計案全体を見通しよく比較評価するためにベストプラクティスを文書化した    !" ! が米国連邦政府で利用実績を積み重ねるなど、一定の文書化さえできれば新たな設計評価手法も利用され得るだけの土壌は整いつつある。
一方、システムの構成要素となるモジュール単位では、要件の客観的な表現を容易にする製品認証制度（モジュール製品を試験し、認証する制度）が注目を集めている。例
えば、日本の暗号モジュール試験及び認証制度 #$%& #' $''(  %) ! は、既に  年  月より、試行運用が情報処理推進機構（ %*）により開始された。そして、 年
では、暗号モジュールを月に正式運用が始まり、現在に至っている。#$%

つのレベルに分けて試験及び認証している。生体認証モジュールに関しても、研究段階だが、適当な複数レベルに分けた試験及び認証制度を可能とするための評価基準作りが試みられている!。

モジュール選択を何度も行いながらシステムを構成する場合、ベストプラクティスに基づいて設計チームを稼働させることが多いだろう。本ガイドラインは、それら多くのモジュール選択結果の間に理論的整合性（ミクロ経済学に基づく解析的な理論モデルとの整合性）があるかどうかを簡易に検証し、代替案比較によるシステム設計を支援するためのドキュメントである!" !。

対象
システム構築には、以下のように様々な立場の利害関係者が関わっている。

 ソフトウェアモジュールやハードウェアモジュールの提供者
 モジュールを用いてシステムを構築するシステムベンダ
 本ガイドラインに至る研究の一部は、新エネルギー・産業技術総合開発機構  産業技術研究助成事業（若手研究グラント）による助成を受けた。

 ベンダから最終製品を購入する消費者
 当該産業の所轄官庁
本ガイドラインの対象（想定する利用者）は、 である。
製品認証制度としては、#$% が既に運用されていることに配慮し、 つのレベルに分けて試験及び認証する制度を対象とする。ただし、レベル数が異なっても、基本的に同じ手法で %+$* サイクルを構築できる。

理論
ミクロ経済学に基づく情報セキュリティへの最適投資理論が盛んに研究されるようになってから  年弱が経過している。本ガイドラインでは、定式化を最適投資以外の問題にも適用でき、一般性が高い。
公的データによる実証研究が存在する。
豊富な含意が導出されており、それらがベストプラクティスによく整合している。
を全て満たす貴重なモデルである ,-./ モデル! とその拡張! を理論基盤とする。そこでは、次の基本パラメータを定義して定式化が行われる。
攻撃等の脅威が成功した時の経済的損失。



攻撃等の脅威が生起する確率     。理論展開の中では、表記の簡略化目的で、 0  と定義されるパラメータ （潜在損失と呼ばれる）も用いられる。



攻撃等の脅威が生起した際に、生起したという条件の下で、脅威が成功する条件付
き確率     。脆弱性と呼ばれる。
今、金額    の情報セキュリティ投資を行うことを考える。,-./ モデル

では、投資によって脆弱性を低減できると見なす。そして、低減後の脆弱性は投資金額と投資前の脆弱性のみに依存すると仮定し、低減後の脆弱性を     と表記する。この     を、セキュリティ侵害確率 12%& ( /( '// 関数と呼ぶ。
最適投資問題は、この脆弱性低減による損失低減の期待値から投資額を差し引いた値

342 135'( 4 26 7)  8)  7) 1( を最大化する問題として定式化される。 12% 関数としては、いくつかの関数系が検討されている。
とくに、    0    で定義される関数系は、「極めて低い脆弱性や高い脆弱性ではなく、中程度の脆弱性に対して重点的に投資すべきである」という投資指針を表現した解析

解をもたらし、唯一の実証サポートを有する関数系として注目されている !" !。正の「情報セキュリティの生産性」を表現していると考えられている。
定数  は、
ただし、情報セキュリティ投資の効果には本来、攻撃等の脅威の抑止力も含まれるはずである。そこで、拡張モデルでは、投資に応じて脅威生起確率  も低減されると捉えて抑止力を理論に取り込む。投資後の脅威生起確率を  0   でモデル化

を「脅威低減に関する（情報セキュリティの）生産性」と呼ぶ。これにし、非負の定数伴い、先の正の定数  は、「脆弱性低減に関する（情報セキュリティの）生産性」と呼ぶこととなる。この時、342 1 最大化問題

  0           )5の解析解は

 0         0     9  で与えられる。ただし、      9 9の場合には、投資額をゼロに限りなく近づけた時の限界効用が限界費用を上回らないので、投資はなされない。     の場合に限り、 式が最適な投資額を与える。
上記の結果は、横軸に 、縦軸にをとった平面に表現すると体系的に理解できる。すなわち、図  のようにまとめられる。この平面（二次元空間）を、情報セキュリティの生産性空間と呼ぶ。
図  において、左下部の領域（$と $-*-）は零投資領域である  。生産性がこの領域内であれば、最適投資額  は脆弱性  の値にかかわらず、 となる。導入可能な情報セキュリティ対策が極めて貧弱でどちらの観点でも生産性が低い場合には、対策を導入しても有意義ではない。零投資領域は、この直感に対応している。
続いて、図  における右下部の領域（$-2--）は中庸脆弱性重視領域である。

生産性がこの領域内であれば、脆弱性に関する  つの閾値  "  が存在し、低い脆弱性

    と高い脆弱性     に対しては最適投資額  0  となり、中程度の脆弱性
 「」などの場合分けの番号・記号は、文献応している。

 に示された証明に現れる場合分けの番号・記号に対Case II−B−1

Threat−reduction productivity

Case II−A−2→

Case II−B−2−b−1/(L*ln(t))
Case II−A−1→

Case I01/L

図Case II−B−2−ae/L
Vulnerability−reduction productivity

情報セキュリティの生産性空間      に対して  式に従う投資  が推奨される。この領域に相当する数値例を、図  に示す。図  には、文献! に記されている解析解導出方法の理解を助けるため、

最適投資曲線 だけでなく曲線       も併記した。重要な含意は、抑止効果があまり高くない場合には、費用対効果の観点で最適性を考えると、中程度の脆弱性対策に重点を置くべきであるということである。
最後に、図  における上部領域（$-*-、$-2-、そして $-2--/）は高脆弱性重視領域である。生産性がこの領域内であれば、ある閾値  以下の脆弱性  ま
では最適投資額  が  であり、その閾値を越える高い脆弱性に対しては、 式に従う投資  が推奨される。この領域に相当する数値例を、図  に示す。重要な含意は、抑止効果が充分高い場合には、費用対効果の観点で最適性を考えても、高い脆弱性に投資する余裕が出てくる

 横軸に脆弱性 Ú 、縦軸に最適投資額 Þ  をとった曲線を最適投資曲線と呼ぶ。脅威 Ø ではなく脆弱性を横軸にとる理由は、脆弱性は基本的に自己アセスメントに基づくからである。これに対し、脅威は、環境を分析しなければアセスメントできない。

ということである。元の ,-./ モデルにおいても、12% 関数として別の関数系を採用すれば、高脆弱性重視の最適投資曲線を導出できる。

Optimum investment0−alpha*v*ln(v)−beta*v*ln(t)

1/L

0V1

V2

1Vulnerability

図

中庸脆弱性重視領域の数値例と最適投資曲線              式を被害額の期待値  で除して、 0    9 
0    とおけば、
 となる。  式の右辺は、 0  において最大値   をとる。ゆえに、最適投資額は、被害額の期待値の高々   倍すなわち  : である。コストが被害額の期待値の  : を越える場合には、そのままでは過剰投資の恐れがある。この含意は、元の ,-./ モ
デルにおいても導出できる。

Optimum investment0−alpha*v*ln(v)−beta*v*ln(t)

1/L0

図V1

高脆弱性重視領域の数値例と最適投資曲線       

第V3
Vulnerability1      部ガイドライン


概要
複数のモジュール候補から一つのモジュールを採用する際、候補の中には、認証を受けていないモジュール（以下では、非認証候補という）や、特定のセキュリティレベル で認証を取得したモジュール（レベル  を取得した場合、以下では、.8 認証候補という）が存在する。本ガイドラインでは、認証候補あるいは非認証候補を取捨選択しながらシステムを開発する過程を支援する。
進めるべき手順は、 段階から成る。
手順一：採択枠組みの開発

 コスト・ストラクチャの構築
 リスク・ストラクチャの構築
 レベル１からレベル４まであるとする。

手順二：候補の分析

 総コストの算出
 リスクスコアの算出
 リスク許容境界の設定
 文書化の始動
手順三：統合 候補の選択
 選択結果の統合
 理論に照らした検証
 文書の更新
手順四：文書化の完了

 セキュリティ仕様の作成
 予算案の準備
 要件変更への対応
 改良改革手順一：採択枠組みの開発

「採択枠組み」とは何か？

代替案比較による取捨選択を体系的にするためには、どのように要素分解し統合できるのか（構造& ストラクチャ）を明らかにしなければならない。このような構造化のメカニズムを、採択の枠組み（以降では、単に「採択枠組み」）と呼ぶ。本ガイドラインにおける採択枠組みは、コストストラクチャとリスクストラクチャから構成される。

 コストストラクチャの構築： コスト要素の構造を明らかにする。総コストを算出できるようにするのが主な目的であるが、開発チームが作業に体系的に取り組む体制（心構えも含む）となるのを促すことも、目的に含まれる。

 リスクストラクチャの構築： リスク要因の相対的優先度を表現したリスクファクタを設定する。モジュールの採用による合計リスクの指標である「リスクスコア」を算出できるようにするのが主な目的であるが、開発チームが作業に体系的に取り組む体制（心構えも含む）となるのを促すことも、目的に含まれる。



コストストラクチャの構築#$% のように情報セキュリティ分野で「モジュール」と見なされ得る製品には、システムの構成要素というよりもむしろそれ自体をシステムと見なしてよいようなものも含まれる。そのため、コストがどの程度複雑な構造を持つかは、ケースバイケースである。
ここでは、例として、次のコストストラクチャが構築されたとする。

 開発費用

ß  ハードウェアの導入による費用
ß  ソフトウェアの導入による費用
ß  サポートサービスの利用による費用
 実装費用

ß  調達に際して発生する費用ß  人件費
 運用保守ß  新人教育による費用
ß  メインテナンスによる費用



リスクストラクチャの構築

リスクストラクチャの構築では、優先度で重み付けをしてリスク要因を統合できるようにすることが肝要である。開発過程では、実装ミス や、あるレベルの要件に未対応などの可能性を、想定しなければならない。それらの不具合の発生確率を、ここではセキュリ
ティ不具合率（または単に不具合率）と呼ぶ。これはモジュール選択における大きなリスク要因であって、脆弱性のあるモジュールをシステムに埋め込んでしまうと、システムの安全性に悪影響が及ぶ。リスクストラクチャの五つのリスク要因（;< =(）は、実装対象の技術自体（以降では、単に「対象技術」と記す） の不具合率と、 つのセキュリティレベル それぞれに対応する不具合率を、相対的にどの程度重視するか
 例えば暗号モジュールの場合には、暗号アルゴリズムの実装ミス。
 暗号モジュールの場合は、暗号アルゴリズム自体。
  の場合には、    暗号モジュールの  つのセキュリティレベル。

というバランスを表現する。この重み付けは、製品の利用環境などに合わせなければならない。

;<=(0           と定義する。ここに、 は対象技術の優先度を表し、 はレベル （   ）の優先度を表し、 9  9  9  9  0

: とする。例えば、  :   は、レベル  のみ重視することを表す。

: : :   は、「レベル  を最も重視し、レベル  もある程度望ましいが、執着しない。かつ、対象技術（自体に不具合がないこと）もある程度重視している。
」ということを表す。
もし、ある高い安全性レベルが必要ならば、より低い安全性レベルの優先度を  にする。例えば、レベル２の安全性が絶対条件ならば、 0  に設定する。
システム設計結果は、 ;<=( の設定に著しく依存する可能性がある。 #$% の場合には、# 1 >   暗号モジュールセキュリティレベルと要件要約を参照し、各レベルの要件を徹底的に理解した上で合理的な重み付けをすることが、極めて重要である。また、その際、次のような過不足に留意する：
脅威低減効果があまり高くないと思われる場合には、高いレベルへの過剰投資になっていないか注意する。
脅威低減効果が充分高いと思われる場合には、高いレベルへの投資不足になっていないか注意する。

手順二：候補の分析



総コストの算出

コストストラクチャに基づいてコスト要素の試算を行い、統合する。ここでは、特段の理論は用いず、単純に総和をとる。例として、レベル１で認証を取得したあるモジュールのコストを見積もり、表  のような結果が得られたとする。また、レベル２で認証を取得したあるモジュールのコストを見積もり、表  のような結果が得られたとする。

リスクスコアの算出

モジュールのセキュリティレベルが種類（レベル４、レベル３、レベル２、レベル１、非認証）しかないため、各候補のとり得るリスクスコアは、せいぜい

つの値にしか分か

表

某

認証候補のコスト試算と集計（単位：万円）

  年度

コスト見積もり年度

  年度以降

合計

 開発費用

 ハードウェア ソフトウェア
 サポート 実装費用





 調達
 人件費 運用保守 新人教育 メインテナンス
某







トータル表

 認証候補のコスト試算と集計（単位：万円）

コスト見積もり  年度

 開発費用 ハードウェア ソフトウェア
 サポート 調達 人件費 実装費用

年度

  年度以降

合計









 運用保守 新人教育 メインテナンストータル

れない。ここに、リスクスコアとは、モジュールの採用による合計リスクの指標であって、 から  までの値を取り得る。不具合率の重み付け総和をとったということを踏まえて : を添えて表記するが、何か具体的な確率を意味するわけではない。
リスクスコアの算出は単純である。各リスク要因の優先度と想定される不具合率を掛け算し、その結果をそのリスク要因のリスクスコアとし、そして５項目のリスクスコアの総和を当該候補のリスクスコアとする。

ここで、.8 認証候補を考える。#$% におけるセキュリティレベルの定義に合わせ、レベルが上がれば要件が強まるとする。簡単のため、「上位レベルの認証を取得できるにもかかわらず下位レベルの認証しか取得していない」ということはないと考え、.8
認証候補に関しては、レベル  までのリスク要因の不具合率を :、レベル  9  以上のリスク要因の不具合率を : と見なす。
リスクスコアは、不具合率をリスク要因の優先度で重み付けした総和をとって算出する。認証候補の不具合率の値は、認証を信頼して一意的に設定する。非認証候補の不具合率の値には、認証制度の運営機関により公開されたレベル別の実装不具合率を用いる。ただし、公開データが粗く、全てのレベル分けに対応していない場合には、簡易に（しかしやや慎重に）考えて「等分した値以上である」と推定する  。手順三の統合作業で必要となるので、候補に非認証モジュールが含まれていない場合でも、かりに非認証候補があればリスクスコアがいくつになるかを算出しておく  。
例として、  年のデータ ! を参照してみる。レベル  とレベル  の合計不具合率が : であり、レベル  とレベルの合計不具合率が: であった。等分して下限を決め、非認証候補に関しては、レベル  およびレベル  のリスク要因の不具合率をいずれも  :9 と設定し、レベル  およびレベル具合率をいずれも のリスク要因の不:9 と設定する。同じ実データによれば、認証を受けようとする暗号モジュールですら、アルゴリズムの実装不具合率は : にも及んだ。よって、非認証候補に関しては、暗号アルゴリズムの不具合率を :9 と設定する。ここで、?:9@という表記は、不具合率が : 以上であることを意味する。
非認証候補に関しては、入手容易なデータで不具合率を設定するならば、下限値しか設定できない。そのため、非認証候補のリスクスコアが :9 で認証候補のリスクスコアが の時、   であることも十分起こり得る。候補の分析では、 に相当する数値と  に相当する数値を直接的に比較することのないよう、注意しなければならない。手順三では、異なるモジュール選択課題の暫定的な分析結果を、  のみに着目して統合する。
もう一点の注意事項として、候補のリスクスコアが : となることは、決して「当該候補を採用すれば構成されるシステムから脆弱性が排除される」ことを意味しているわけではない。リスクスコアの定義から明らかなように、リスクスコアが : となることは、当該候補の採用がユーザのセキュリティシステム構築方針を最大限に満たすことだけを例えば、レベル１とレベル２の不具合率の合計が公開されていてその値が  である時には、レベル１とレベル２の不具合率をそれぞれ「 以上」と推定する。
統合時に必要になってから算出するのではなく、この段階で算出しておく。

意味する。言い方を変えると、リスクスコアが : となる候補を採用しても脆弱性は依然として存在するかもしれないが、ユーザに重要視されていない、と考えてよい。
例１：

ユーザが設定したリスクファクタを、: : : : : とする。この時、表 A表のようにリスクスコアを算出すればよい。計算した結果、.8〜.8のモジュールであればいかなる認証候補でもリスクスコアは : になり、.8 のモジュールであればいかなる認証候補でもリスクスコアは : になり、認証を取得していないモジュールであればいかなる非認証候補でもリスクスコアは  :9となる（   ）。なお、表  では「某 .8 認証候補」と記したが、表 A表においては「某」を削除して単に「.8 認証候補」「.8 認証候補」などと記した。
これは、同じレベルのモジュールであればいかなる候補でも同じリスクスコアとなるためである。
例２：

ユーザが設定したリスクファクタを、: : : : : とする。この時、表 A表  のようにリスクスコアを算出すればよい。計算した結果、.8〜.8のモジュールであればいかなる認証候補でもリスクスコアは : になり、.8 のモジュールであればいかなる認証候補でもリスクスコアは : になり、.8 のモジュールであればいかなる認証候補でもリスクスコアは : になり、認証を取得していないモジュールであればいかなる非認証候補でもリスクスコアは となる（ ）。
 認証候補のリスクスコア（例１）

表
リスク要因

優先度

不具合率

重み付けしたリスクスコア

アルゴリズム

レベルレベル レベルレベル 合計

:9

リスク許容境界の設定算出されたそれぞれのリスクスコア（認証候補の各レベルのリスクスコア、そして非認証候補のリスクスコア）に対して、投資できる最大予算（コスト）を見積もる。ただし、

表

認証候補のリスクスコア（例１）

リスク要因

優先度

不具合率重み付けしたリスクスコア

アルゴリズム
















レベルレベル レベルレベル 合計表 認証候補のリスクスコア（例１）

リスク要因

優先度

不具合率重み付けしたリスクスコア

アルゴリズム




















レベル
レベル 
レベル
レベル 合計表



認証候補のリスクスコア（例１）

リスク要因

優先度

不具合率重み付けしたリスクスコア

アルゴリズム



















レベルレベル レベル
レベル 合計

具体的なモジュールを想定してそれに対して投資できる最大予算を考えるのではなく、現在のモジュール選択問題の置かれた状況のもとで、それぞれのリスクスコアに対していくら投資できるかを考える。必要に応じて、同じシステムにおける他のモジュール選択問題との間で情報共有をして差し支えない。結果的に、各候補のコストとかけ離れた多額のコストを許容できるという結論になっても、見積もりを再度行う必要はない。

表

非認証候補のリスクスコア（例１）

リスク要因

優先度

不具合率

重み付けしたリスクスコア

アルゴリズム




レベル
レベル 
レベル
レベル 
合計表



 認証候補のリスクスコア（例２）

リスク要因

優先度

不具合率重み付けしたリスクスコア

アルゴリズム




















レベル
レベル レベルレベル 合計表



認証候補のリスクスコア（例２）

リスク要因

優先度

不具合率

重み付けしたリスクスコア

アルゴリズム


レベル
レベル レベルレベル 合計

なお、見積もっているのはリスクへの対策として許容できるコストの値であるが、この作業を「コスト許容境界」ではなく「リスク許容境界」の策定と呼んでいる。これは、単純に予算があるかどうかで考えるのではなく、リスク管理の観点から許容範囲を策定すべきという認識を開発チームに徹底させるためである。
また、総コストとリスクスコアを算出してからリスク許容境界を設定するという順序が



表 

 認証候補のリスクスコア（例２）

リスク要因

優先度

不具合率重み付けしたリスクスコア

アルゴリズム















レベルレベル レベル
レベル 合計表



認証候補のリスクスコア（例２）

リスク要因

優先度不具合率重み付けしたリスクスコア

アルゴリズム














レベルレベル レベル
レベル 
合計

表 



非認証候補のリスクスコア（例２）

リスク要因優先度

不具合率

重み付けしたリスクスコア

アルゴリズム 


レベル
レベル 
レベルレベル 合計大切である。開発チームの当該ミッションに関する習熟度が上がってから、また、システムに関するできるだけ新しい情報のもとで、設定することが望ましいからである。
ここでは、.8 認証候補のリスクスコアに対して許容できる最大コストが例１で  万円、例２で  万円となったとする。また、.8 認証候補のリスクスコアに対して許容できる最大コストが例１で  万円、例２で  万円となったとする。

文書化の始動



コストストラクチャの構築方法、リスク要因の設定根拠、リスク許容境界を決定する流れに関わる全ての情報と仮定を、明確かつ正確に文書化する。

手順三：統合候補の選択分析した候補から何を選択するかを、最適投資理論で直接は支援しない。しかし、必要な利害関係者を集め、経験的ではあっても費用対効果を強く意識した協議によって選択する。総コストがリスク許容境界におさまらない候補は選択しない。また、このモジュールが破られることに起因する被害額の期待値を見積もることができる場合、総コストが被害額の期待値の  : を越える候補も選択しない。

選択結果の統合

システム開発においてモジュール選択（採択）が一回あるいは少数回しか行われない場
合、選択結果の統合は行わず終了する。
モジュール選択（採択）が多数回行われる場合には、選択結果の統合を行う。あるモジュール選択を行った結果選択された候補の総コストを  、許容できる最大コストを、その選択に至る分析で算出した非認証候補のリスクスコアを  とする。横軸にリスクスコア、縦軸にコストをとり、点    と点    をマーキングして、両者を結ぶ線分を記す。この作業を、全てのモジュール選択に関して（同じ平面で）実施する。
ただし、選択に際して明らかにリスク回避的  な意志決定をした場合には、マーキングをせずに省略する（すなわち、統合作業に含めない）。

 リスク回避的とは、投資家の投資リスクに対する選好特性の一つである。投資の期待収益に第一の基準を置かず、極力リスクの小さい投資機会を選択する特性を、リスク回避的という。一方、リスクに関わりなく、より期待収益が見込める投資機会を選択する特性のことをリスク中立的という。本研究の最適投資理論では、リスク中立性が仮定されている。



理論に照らした検証

例えば、例１では某 .8 認証候補、例２では某 .8 認証候補が選択されたとする。さらにいくつも選択を行い、全てを一つの図（平面）に統合した結果が図のようになったのようになった場合（統合例２）、そして図  のようになった場合

場合（統合例１）、図（統合例３）、を考える。
Example of High-Vunerability Intensive Curve80

Cost [10k JPY]

6040

200010

図20
Risk Score [%]3040

多数回のモジュール選択の統合例１

統合例１のように、各線分を通る高脆弱性重視型の最適投資曲線を引くことが可能な場
合や、統合例２のように、各線分を通る中庸脆弱性重視型の最適投資曲線を引くことが可能な場合には、とりわけ問題視せず、統合結果を受け入れる。
統合例３のように、それらのいずれでもない場合には、意志決定の基礎となる考え方や基準が首尾一貫していなかった恐れがある。よって、統合結果を受け入れず、現在の文書を基に信頼性の低い作業を洗い出して分析を再度行うなど、 %+$* サイクルを回して再度統合する。追加サイクルを経て統合結果が受け入れられたら、終了する。このように「まずは経験的選択を信頼し、要所で体系的に検証して進むべき方向性を定める」という方針は、情報セキュリティ投資の効果を計量する米国連邦政府の取り組み ! でも使われ、「 / 87 ''(」と呼ばれることがある。

Example of Mid-Vunerability Intensive Curve80

Cost [10k JPY]

6040

200010

図20Risk Score [%]3040

多数回のモジュール選択の統合例２
Example of Suspicious Curve80

Cost [10k JPY]

6040

200010図20
Risk Score [%]30

多数回のモジュール選択の統合例３

文書の更新

統合作業も含めた追記を行い、文書を更新する。

40

手順四：文書化の完了

セキュリティ仕様の作成

システム全体に関して首尾一貫したセキュリティ仕様を明確にし、文書に反映させる。



予算案の準備

システム全体に関してほぼ揃った精度で予算案を準備し、文書に反映させる。



要件変更への対応

手順三と手順四の実行中に、急遽システムへの要件が大きく変わるなどの事態が生じる恐れがある。その場合、現在の文書を基に、要件変更の要請に対応すべきか棄却すべきかを速やかに決定する。

改良改革



要件変更の要請に対応する場合には、サイクル増加を有効利用すべく、要請に該当しない事項に関しても改良を試みる。

参考文献
! $ B $( 2 %(( $))& ?   CD-,@ $ B $(" ! 平成  年度情報経済基盤整備・情報システムの政府調達の高度化に関する調査研究「政府調達のための投資評価に関する調査研究」報告書，経済産業省， 

! 情 報 処 理 推 進 機 構& ?暗 号 モ ジ ュ ー ル 試 験 及 び 認 証 制 度@    ! 井沼 学& ?バイオメトリクスセキュリティに関する研究@ 産業技術総合研究所情報セキュリティ研究センター平成  年度研究成果報告会"  ! 楊鵬" 松浦幹太& ?#$% に関するユーザ向けガイドライン試作@ 情報処理学会創立  周年記念全国大会論文集" ( ! % E  F & ?* ( 7 * GH ,  #'$''(   %)@  *$ 1)')  7)" $)'  $))( 1( ) " *' ! . * ,   % ./& ?  ()( 7 7) ( 8)@ *$   7 I 1 1("  " 4 " ''  A" ! F & ?%(8 1'( 7 7) 1(   35 7
 ,-./H 8) @  #"  3(           

! C

 

 " ''A" 1'" 

<" F   B 1& ?/  7) 1(- 8)& * 3)'( * 7 -.( ,8)  #'@# 7 *((  %/( %("  " " '' A "  
! J ." C

<  F & ?3)'(-*  77)-1( 8)  *''(  ;/ 18 7#' =)@ 情報処理学会論文誌" 

" 4" '' A "  

! $))( 1( 3/)" $& ?$%  '@ 
! * %  # 17& ?+8' ( 7 $/( %)@= BÆ( 1) 35'  $7(" ( 