より安全なシステム構築のために～CC-Case_i によるセキュリティ要件の見える化株式会社 NTT データ

金子朋子

まだできていない．つまり現在のシステム開発方法論

1

は，要求分析，要件定義プロセスにおいてセキュリテ

はじめに

近年政府機関や企業へのサイバー攻撃や遠隔操作ウイ

ィの獲得，分析，定義を行っていないなどセキュリテルス事件など様々なセキュリティ事故が頻発し，メデ

ィ要求の取り扱いが不十分な状況にある．

ィアを騒がせている．また金銭搾取を目的としてフィッシング詐欺，スマートデバイスを狙った犯行の横行など，個人ユーザに対しても各種の脅威が取り巻いている．こうした脅威はシステム，ソフトウェアの脆弱性を突いて攻撃を仕掛けてくる．
より巧妙 化する 脅威 に対 して，よ り安全 なシ ステ
ム・ソフトウェアを開発するにはどうしたらよいだろうか？解決方法として，開発者に対する教育と訓練，経験の伝達，プロジェクト管理の徹底，運用管理の向上，セキュリティ方針の厳密化などとともに，開発方

図1法論からの対応が必要である（図 1）．システム・ソ

この現状の課題を解決するために，筆者らは，コモフトウェアの作りの仕組みの中に脅威への対抗手段をンクライテリア（CC：Common Criteria. ISO/IEC15408

含めることがより根本的な対策になりうるからである．

と 同 義 ） [1][2][3] と ア シ ュ ア ラ ン ス ケ ー ス

システム開発の観点からの取り組みには要求，設計，（ISO/IEC15026）[4]を用い，セキュリティ仕様を顧客

実装，テスト，保守の各段階からの対応があり，全開と合意の上で決定する手法 CC-Case[5] [6]を提案して発工程に対して安全性を考慮した方法論が望まれる．

いる．しかしながら、従来の CC-Case は CC 認証を伴

設計段階ではセキュリティプロトコルの検証，実装段

うセキュリティ要件定義中心の対応で、CC 認証を伴わ階ではセキュリティメカニズム，セキュリティを意識ない開発・運用に対応していない．そこで CC 認証をしたコーディング規約，テスト段階では侵入テスト，

伴わない開発・運用の中でも、現在の情報セキュリテ

脆弱性テスト，運用段階ではセキュリティアップデー

ィ対策の主流であるインシデントとその後の開発に着トによる取り組みが可能である．しかし要求段階にお目した．CC-Case を拡張し、運用時のインシデント対

いては「2.1 セキュリティ要求分析手法」に後述するよ応やインシデント後のシステム改修等本格対処する際

うに，セキュリティ要求に関して様々な研究がなされのセキュリティ要件仕様にも利用できるフレームワーているが，セキュリティ要求を抽出・分析・仕様化，

クを新たに提案する．

開発方法論・プロセスからの対応

妥当性確認，要求管理する全段階をサポートしている

2

要求分析手法もセキュリティ要求分析の標準的な手法

関連研究

2.1 セキュリティ要求分析手法もまだできていない．また運用時のインシデント後のシステム改修等本格対応する際にはセキュリティ要求

セキュリティ要求分析では，顧客は要求に基づく機が必要となるが、これらをトータルに考慮した手法も能要件の分析に加えて攻撃者の存在を考慮した非機能

1

要件の分析を必要とする．そこでセキュリティ要求はで説明すると，機能要件 FIA_AFL1.1 で TSF は、[割付：アセットに対する脅威とその対策の記述が必須となる.

認証事象のリスト]となっているので，図 4 の事例のよ

セキュリティ要求分析の手法にミスユースケース [7]，うに「最後に成功した認証以降の各クライアント操作

Secure Tropos[8]，i*-Liu 法[9][10]，Abuse Frames[11]や員の認証」，「最後に成功した認証以降の各サーバ管

アクタ関係表に基づくセキュリティ要求分析手法

理者の認証」のパタメータの割り付けする． CC のパ（SARM）[12] [13]などがある．いずれの手法もセキュー ト 3 に は セ キ ュ リ テ ィ 保 証 要 件 （ SAR ： Security

リティを考慮した脅威分析やそれに対する対策立案のAssurance Requirement）が規定されている． CC はセ

手法だが，明示されない非機能要求に関してあらゆる

キュリティ機能自体の形式化を図ることにより、IT セ

要件をつくすことは難しいのが実情である．

キュリティを評価する基準であり、特にパート 1 に規

また SQUARE[14] [15]はセキュリティのシステム品

定されたセキュリティ目標を作成するプロセスは、CC

質を高めるために定められた特定の手法によらないプ

認証を伴わないセキュリティ要求仕様においても汎用

ロセスモデルである. SQUARE は生産物の定義に基づ的に利用可能である．

いてリスク分析し，セキュリティ要求を抽出・優先順
位付け・レビューする手順である.
マイクロソフトのセキュリティ開発ライフサイクル[16] はデータフロー図を詳細化し脅威の観点 STRIDE
で脅威分析を実施する．設計による安全性確保を重視
し設計段階でセキュリティ要求を抽出している．しかしながら，セキュリティ要求を抽出・分析・仕様化，妥当性確認，要求管理する要求の全段階をサポートし

図2

CC 構成と ST の記載内容ているセキュリティ要求分析の標準的な手法や運用時のインシデント後のシステム改修等本格対処する際のセキュリティ要件仕様までトータルに考慮した手法はまだできていないのが現状である．

図3

CC パート 2 の規定

図4

準形式的な記載事例

2.2 コモンクライテリアについて
IT セキュリティ評価の国際標準である CC[2]は,開発者が主張するセキュリティ保証の信頼性に関する評価の枠組みを規定したものである[4]．CC のパート 1 に

2.3 アシュアランスケースについては評価対象のセキュリティ目標（ST: Security Target）
やプロテクションプロファイル (PP：Protection Profile)

アシュアランスケース（assurance case）とは，テスに記載すべき内容が規定されている(図 2)． CC のパー

ト結果や検証結果をエビデンスとしてそれらを根拠にト 2 に TOE のセキュリティ機能要件（SFR：Security

システムの安全性，信頼性を議論し，システム認証者

Functional Requirement）が規定されている．準形式化

や利用者などに保証する，あるいは確信させるためのするために，CC パート 2 には機能要件がカタログ的にドキュメントである[17]．アシュアランスケースは欧列挙されており，選択等の操作にパラメタやリストを米で普及しているセーフティケース[18]から始まって特定することにより，準形式的な記載ができる．図 3

おり，近年，安全性だけでなく，ディペンダビリティ22.5 CC の動向やセキュリティにも使われ始めている．アシュアラン
スケースは ISO/IEC15026 や OMG の ARM [19]と SAEM

政府における IT 製品・システムの調達に関して、[20]などで標準化がすすめられている．

ISO/IEC 15408(CC) に基づく評価・認証がされている

アシュアランスケースの構造と内容に対する最低限製品の利用が推進されており，注目すべき最新の CCの要求は，システムや製品の性質に対する主張(claim)，の動向として，情報セキュリティ政策会議で決定され主張に対する系統的な議論（argumentation），この議た「政府機関の情報セキュリティ対策のための統一基論を裏付ける証跡(evidence)，明示的な前提（explicit

準（平成 26 年度版）」[30]が挙げられる．

assumption）が含まれること，議論の途中で補助的な主本統一基準の「5.2.1 情報システムの企画・要件 定義」

張を用いることにより，最上位の主張に対して，証跡において、機器調達時には「IT 製品の調達におけるセや前提を階層的に結び付けることができることである．

キュリティ要件リスト」を参照し、適切なセキュリテ

代表的な表記方法は，欧州で約 10 年前から使用されてィ要件を策定することが求められている ．経済産業省

いる GSN [21]であり，要求を抽出した後の確認に用い，より公開されている「IT 製品の調達におけるセキュリシステムの安全性や正当性を確認することができる．

ティ要件リスト」[31]では、指定したセキュリティ要他に法律分野でアシュアランスケースの理論的背景と件が満たされていることの確認手段として、CC 認証のなる Toulmin Structures[22]や要求，議論，証跡のみのような国際基準に基づく第三者認証を活用することをシンプルなアシュアランスケースである ASCAD[23]推奨している．

もある．日本国内では GSN を拡張した D-CASE [24]CC における認証制度や cPP 活用で想定される今後[25]が JST CREST DEOS プロジェクトで開発されていの動向については,筆者らの論文[32]を参考にしてほしる．

い．CC は認証制度のコスト負担の問題などで利用しづ

2.4 セキュリティケースについて

らい基準とみなされることもあるが，国内外の CC 活

GSN を提唱した Kelly ら[26]が Security Assurance

用動向を元に考えると，大変重要な基準である．

Cases の作成に関する既存の手法とガイダンス，セーフ3

ティケースとセキュリティケースの違いなどを述べて

CC-Case の CC 認証を伴わない幅広いセキュリテ
ィ要求分析への適用方法

いるが，具体的に作成したセキュリティケースの事例
は示していない．Goodenough [27]らはセキュリティに3.1

対するアシュアランスケース作成の意味を説明してい一般にセキュリティインシデントとは、事業運営にる. Lipson H[28]らは信頼できるセキュリティケースに影響を与えたり、情報セキュリティを脅かしたりするは保証の証跡こそが重要であると主張している．

事件や事故のことをいう[33] [34]．

セキュリティインシデントとそのプロセス

Ankrum[29]らは CC，や ISO154971，RTCA/DO-178B とセキュリティインシデント対応には「1. 平時におけいう 3 つの製品を保証するための規格を ASCAD でマるインシデント対応の準備」として，インシデントにップ化し，ASCE などのアシュアランスケースツール

対応する際の目的と目標事項，通知体制の確立が必要が有効であり，保証規格を含むアシュアランスケース

である．これらはセキュリティポリシーに記載すべきは似た構造をもつことを検証している．セキュリティ事項である．次に「2. 情報セキュリティ侵害を検出」

ケースはセキュリティ設計品質の見える化やセキュリ

として，インシデントであることと，その重要性に対ティ要件の妥当性確認の容易化につながる手法であり，するインシデントの識別が必要になる．更に「3. 情報

CC-Case の重要な技術要素である．

セキュリティインシデント対応」としては暫定的対応

3

と本格的対処を行う．このインシデントの本格的対処

モデルの最下層ゴールの下に作成される実際のケース

はシステムの改修や運用方法の変更を伴うことも多い．

に応じたアシュアランスケースである．具体モデルは

3.2

CC-Case インシデント対応版提案の背景

証跡を最下層に提示するまで適宜論理分解されて記述

CC はその複雑さからデジタル複合機などの特定のされる．具体モデルは実際のケースにおける証跡と合セキュリティ機能のハードウェア製品や政府調達対象意によるステークホルダの承認結果を証跡として残す．

案件には利用されているものの，それ以外のセキュリ

各種証跡は次々と貯まりその結果，論証に使えるもの

ティ要求分析にはあまり利用されていないという課題になる．要望は確定的ではなく，変化することがありを抱えている．それゆえ CC-Case 自体の用途も限られ，うるが，変化に応じた証跡を残すことが必要である．

提案手法の利用はなされていないのが現状である．そそのため CC-Case_i では，全ての証跡を要求管理 DB

こで，CC-Case は認証を取るための開発以外においてに格納し，変更要求に随時応じられるようにする．具も，一般のセキュリティ要求分析に利用できることを体モデルの各証跡は ST の認証のための記述事項以外示したい．特にセキュリティインシデント後の本格対の必要な項目として 3.5 項に示すプロセスを全て含む

処において CC-Case を利用可能としたいと筆者は考えように作成され，保証のできる証跡を残していき，要ている．何故ならばセキュリティは非機能要件であり，

求管理として実施される．

当初のシステム設計時には機能要件として挙がらない
が，その後のインシデント発生により，システム改修が必要となる事例が多いからである．

3.3

CC-Case_i の定義と目的

インシデント発生に伴い，一時対処が終了した後の本格対処時に利用できるように CC-Case 活用の幅を広げ，CC-Case インシデント対応版を CC-Case_i と命名し提案する． CC-Case_i は CC 認証を伴わないセキュ
リティインシデントの本格対処に適した「セキュリテ
ィ要求分析と保証」をサポートするプロセスと記法の図5

論理モデルと具体モデル

統合手法である．

3.5

CC-Case_i の目的は，より巧妙化する脅威に対して，

CC-Case_i は普遍的に記載する以下の論理モデルをもより安全なシステム・ソフトウェアを開発するために，つ(図 6)．「G_1

現在のインシデントの本格対応も含め，CC 認証を伴わデント解決方法は妥当である」をトップゴールとし，ない一般的な開発におけるセキュリティ上の課題を解「C_1 インシデントの発生」の前提条件，「S_1 イン

決できるセキュアなシステム開発への対応を実施する

シデント対応が適切であることを論証する」戦略に則ことである．

り，「G_2 インシデント認識は妥当である」，「G_3

3.4CC-Case_i のプロセス

XX システムのセキュリティインシ

現状調査と原因分析は妥当である」，「G_4 対策立案

CC-Case_i の構造

CC-Case_i も CC-Case と同様に論理モデルと具体モと選択は妥当である」，「 G_5 対策実施は妥当である」，

デルの 2 層構造をもつ(図 5)．論理モデルはセキュリテ「G_6 結果の評価は妥当である」の 5 つの段階を規定

ィインシデントを解決するプロセスを提示し，具体モしている．これらのプロセスは一般的な問題解決手順

デルは実際の事例を記述する．具体モデルとは，論理に沿っており，主張と証拠を記述することで，ステー

4クホルダ間の議論をしやすくすることを意図している．

そこで図 6 に示した論理モデルの直下にある前提条

また要件定義段階の CC-Case にはない「G_5 対策実施

件や戦略は具体モデルとして，そのセキュリティイン

は妥当である」，「G_6 結果の評価は妥当である」のシデントにあわせた具体的な内容を記述するが，表 1

段階を追加している．これによって，そのインシデンの CC-Case_i のプロセスに示すゴールごとの入力，手ト解決自体が的確に要求を満たせるように行われたの続き，出力を具体的内容として記述することが求めらかを客観的に評価し，保証することを可能としている．

れる．そのため論理モデルの直下にある前提条件や戦つまり要求段階における期待としての保証ではなく，略は図 6 の GSN の形式で記述することが基本になると実際の結果を伴う保証が可能である．また理想的なイ

筆者は考えている．ただし，必ずしも全ての項目を記

ンシデント解決は検討段階において，ステークホルダ

述しなければならないわけでなく，実際のケースに応間で議論し，対策実施の確認と評価の手段として証拠

じて，表 1 の CC-Case_i のプロセスのテーラリングはをもつべきであり CC-Case_i はそれを可能としている．

可能である．例えば「システム改修を伴わない運用の

表 1 CC-Case_i のプロセス

みによる対策実施の場合は技術の対策は記述しない」

段階 ゴール

G_1

G_2

G_3

G_4

目的

入力

手続き

出力

などのテーラリングができる．また図 7 は「XX シス

出力に対する
確認方法

XXｼｽﾃﾑのセキュリティ セキュリティイン
インシデント シデントの解決 ・インシデントの G-2からG-6までのゴールがすべで ・インシデント解
妥当性確認
満たされていることを確認する
決の評価
解決方法は 方法の妥当性 発生妥当である を確認する

テムが標的型攻撃を受けた場合の対処」の CC-Case_i

インシデントをインシデント
認識し，一時対 ・セキュリティ方 基準に基づき、結果を評価する
・一時対処の実認識は妥当妥当性確認
処が妥当である 針
施結果であることを確認する
現状調査と本格対処に必・システム構成装置や機能等に分け ・ｼｽﾃﾑとｼｽﾃﾑ間
原因分析は
・設計書
要な現状調査・て脅威分析するの脅威分析結果 妥当性確認
妥当である
・保護資産
分析を行う

CC-Case_i も CC-Case 同様にアシュアランスケース

対策立案と選択は妥当 最適な対策を選・前提条件である 択するの事例である．

3.6

CC-Case_i とアシュアランスケースの役割の代表的な記法である GSN[21]を使用する．GSN の構
成要素を表 2 に示す．
表 2 GSN の構成要素

・技術と運用の対策に分けて、洗い出した脅威に対策をたてる
・対策選択根拠・基準に基づき、対策を選択する ・選択対策への
妥当性確認
・残存リスクを影響分析する
承認結果
・残存リスク

G_5

対策実施は対策を着実に実妥当である・選択した対策 実施状況を管理し，対策を実施する ・実施結果
行する

G_6

結果の評価
実施結果を評は妥当であ価し，次の改善 ・実施結果
るにつなげる

基準に基づき、結果を評価する

妥当性確認

・実施状況の評
妥当性確認
価結果

3.7

CC-Case_i の対象範囲・適用対象

図 6 に CC-Case_i の論理モデルと具体モデルを図示す

CC-Case_i の対象範囲はインシデント発生による本格る．G_1 から G_6 までのゴールは論理モデルとして固対処時から解決までのライフサイクルである．

定であるが，それ以外は具体モデルである． G_1 から

また CC-Case_i の適用対象はセキュリティインシデ

G_6 までのゴールは表 1 の CC-Case_i のプロセスに示

ント後の本格対処時の シ ステムまたは製品であ る ．

すゴールごとの入力，手続き，出力を基本的に必要とCC-Case_i も顧客と開発者との合意を形成する手法とする．その理由は 3.8 項に後述するように CC-Case_i

して利用できるが，セキュリティインシデント対応では CC-Case 同様，CC 基準に則って作成するからであ仕様を決める際に承認を取る特定の顧客がいない場合

る．

は，要件を決めるうえでの関係者と読み替える．

5

図 6.CC-Case_i のプロセス

図 7.CC-Case_i の事例

6

3.8

(2)ST の構成と CC-Case

従来の CC-Case との関係

従来の CC-Case が CC の ST とどのような関係をもち，

図 9 に示すように要求段階の CC-Case のセキュリテ

その CC-Case と CC-Case_i がどのような関係になるの

ィ対策立案段階は，セキュリティ課題定義として，攻かを順に説明する．

撃タスクと抽象的なセキュリティゴールと前提条件を(1)ST の構成とセキュリティ要求分析

洗い出す「3. セキュリティ課題定義」とこれをもとに

CC-Case はセキュリティ要求分析として ST に必要システムのセキュリティゴール，環境のセキュリティ

な成果物を作成している．その理由は ST における作

ゴール，セキュリティ課題定義との関係を示す「4. セ業プロセスとセキュリティ要件の解析方法は非常に類キュリティ対策方針」のプロセスを含んでいる．これ似しているからである．ST における作業プロセスは概らは CC 認証を伴わない一般的なセキュリティ要求分

ね以下の手順で実施される．資産ベースのセキュリテ

析の中でも重要な要素である． そこでセキュリティ対

ィ要件の分析獲得の実施， 攻撃者がいかに資産に対し策立案段階で認証のための ST 記載事項を除いたプロて脅威を与えるかについて脅威分析の実施，如何に資セスを含み，セキュリティインシデント対処に適した産を防御するかについてセキュリティ方針を規定，セプロセスに組み替えたものを CC-Case_i として定義すキュリティ要件の獲得・分析し，セキュリティ機能とる．CC-Case_i はステークホルダ間で妥当性確認をす

して整理する．図 8 に示すように，セキュリティ要求る際に用い，CC-Case のセキュリティ対策立案段階の分析として「2.適合性主張」と「6.2 セキュリティ保証

最終ゴール「セキュリティ対策方針は妥当である」で要件」以外は従来の手法で作成可能である．従来の手の妥当性確認に相当する(図 10)．

法においても，攻撃タスクはミスユースケースに，システムのセキュリティゴールはセキュリティユースケ
ースに，セキュリティ課題定義との関係とセキュリテ
ィ対策方針との関係はゴールモデルに対応しているからである．但し従来の手法は ST 全体に整合性を保ち網羅的に要求分析しながら，CC のセキュリティ基準に則った保証を可能とする手法ではない．

図9

図8

ST の構成と対応可能な従来手法

7

ST の構成と CC-Case_i

体の大規模な技術的改修も必要になることもある．イ
ンシデントが起きた装置・システムだけでなく他の装置への影響を考える必要性も生じる．単なる問題解決だけでなく今後のリスク対処も必要である．対処の確定には多様な関係者による検討が必要になる場合もある．またセキュリティの問題は，日々変化する脅威や技術を常に追いかける必要があるため，セキュリティ
専門家の知見，ノウハウ，能力を活用することも有効
である．
こうしたセキュリティインシデントの特性を考慮す
ると，インシデントから本格対処が必要な問題を抽出して，本質的な原因を分析し，対策をたて，実現して*黄色ゴールは検証，赤色ゴールは妥当性確認を示す．
図 10

セキュリティ対策立案段階

いくプロセスを議論による「レビューの強化」を伴って実現することが必要になると考える．そのため筆者
は CC-Case_i に見える化と使い方の観点で後述の長所4をもたせた．

CC-Case_i の特長

4.1

セキュリティインシデントの本質的原因

4.2

見える化の特長

セキュリティインシデントには本格対処が必要な大き

CC-Case_i は３つの見える化の特長をもつ．「1.主張な事故もあれば，対外的には問題にならないトラブルと証跡の見える化」，「2.論理の見える化」，「3.保証もある．システム運用時には「アプリケーションバグ

ストーリーの見える化」である．

や設計ミスでセキュリティ機能が動作しない．処理能(1)「1.主張と証跡の見える化」はゴールとしての主張力を超えた極限稼動でセキュリティ機能の動作不備がとその主張の正しさを裏付ける証跡が存在することで露呈する．本来見えないはずのデータにアクセス可能ある．GSN はトップゴールの主張を満たすことを可視な方法が存在していた．明らかな使用ルール違反（内化できる手法だからである．

部犯罪など）だが痕跡の残らないシステム利用が行わ(2)「2.論理の見える化」は前提条件，戦略，ゴールのれた．」などのセキュリティ関連トラブルが日常的に関係性の明示により，トップの主張から証跡までの論発生する．

理が明確化されることである．GSN は図の最下層に主このようなセキュリティインシデントを起こす本質

張が正しいことを示す証跡を記述するからである．多的な原因とは，脅威分析・システムリスク評価が不十様な GSN の論理モデルが提供されており，利用可能で分，各フェーズ間のセキュリティに関する分析の一貫ある[35]． 更にインシデントの本格対応に適したモデ

性欠如，セキュリティ対策の検証方法のあいまいさ，

ルとして，筆者は本稿で CC-Case_i を提案している．

設計・実装時のレビューが不十分でシステムバグ（IT(3)「3.保証ストーリーの見える化」はプロセスと実施

または運用環境）を見つけ切れていないとことが考え

事項の明確化によりインシデント全体の解決ストーリられる．

ーの可視化である．

解決方法にしても，運用でカバーする部分もあれば，CC-Case_i は管理プロセスと各インシデントへの対処

同様なインシデントを防ぐ仕組みの確立やシステム自がつながる統合方法論である．プロセスアプローチに8

よるインシデント抽出，分析，管理は定性的にも定量果が要件を満たすことを確認するツールである．また的にも適用可能であり，インシデント解決の適切性を

単に要件に対する検証を実施するだけでなく，ステー保証できる．

クホルダ間の議論による妥当性確認が可能である．

4.3(3)CC-Case_i は「脅威と対策の資産化ツール」である．

使い方の特長使い方の観点で CC-Case_i は「議論のツール」，「セCC-Case は一連のプロセスを形式化しているため，証キュリティ保証のツール」，「脅威と対策の資産化ツ跡単位で DB 化して脅威と対策のノウハウを資産化でール」としての長所をもつ．

きる．利用者が自社等のシステムにおいて資産化を進(1)CC-Case_i は論理的根拠を明示することにより，「議めることにより，将来的に自社システムにおけるプロ論のツール」として利用できる．通常，適切な対策を

アクティブな対処につなげられる可能性がある．

選択していることは確認するのは難しい．CC-Case_i

5

は，証跡ベースで事象の論理関係を明確化するため，まとめ

この種の確認に適している．CC-Case_i を用いること

本稿では，として CC-Case_i を提案し，その目的，によりステークホルダ間の認識の食い違いを防ぐ．評

定義，プロセス，特長と事例等を示した． CC-Case_i

価基準を示し，証跡に対する適切な妥当性確認を実施は本稿で新たに提案したものであり，まだ利用実績はできる．

ない．今後，多くの実績を積み重ね，実際の利用者のセキュリティ対策の場合，セキュリティの専門家と意見をいただき，より利便性の高いものに適宜改善しされる人たちと一般のシステム開発者に理解の壁が生ていきたい．本研究が現在の開発のセキュリティ上のじることがある．また，インシデント解決には会社の課題解決に役立つよう，世の中で広く利用されていく

経営層などの意志確認が不可欠である．それらの異なことを念願するものである．

るバックグラウンドをもつステークホルダ間で理解の壁をなくし，互いのもつ見識を活かしたインシデント

謝辞

解決を図るために役立ててほしいのがこの CC-Case_i

数々の有益なご指摘を賜った査読者の方々をはじめ，である．

この研究をするにあたりサポートして頂いた日本ネットワークセキュリティ協会の皆様，情報セキュリ

このため，CC-Case_i は実用性にこだわっており，

ティ大学院大学の先生方，㈱NTT データの皆様，励

以下の利用方法を推奨したい．

ましを頂いた恩師，友人，家族に謹んで感謝の意を

まず，できる限り 1 枚の図で論理の全体像を表記し，表する．

インシデント解決ストーリーをステークホルダで共通認識ができるようにする．また証跡や前提条件など各参考文献

項目の詳細内容にはリンクを張って参照できるように[1] Common Criteria for Information Technology Security
Evaluation, http://www.commoncriteriaportal.org/cc/[2]セキュリティ評価基準（CC/CEM)
http://www.ipa.go.jp/security/jisec/cc/index.html[3]田淵治樹：国際規格による情報セキュリティの保証手法,日科技連，2007 年 7 月[4]ISO/IEC15026-2-2011,Systems and Software
engineering-Part2:Assurance case[5]金子朋子，山本修一郎，田中英彦： CC-Case～コモ
ンクライテリア準拠のアシュアランスケースによるセキュリティ要求分析・保証の統合手法, 情報処理学会
論文誌 55 巻 9 号(2014)[6] Kaneko,T.,Yamamoto, S. and Tanaka, H.: CC-Case as

する．さらに進捗段階に応じて，妥当性確認を完了した決定事項と計画段階の未決定段階を区別し，内容を書き換えていく．図 7 の G_5 と G_6 の事例のように未決定段階のプロセスには網掛けをすることで決定事項と未決定段階を区別し，ステータス管理が可能である．
(2)CC-Case_i は「セキュリティ保証のツール」であり，インシデント解決の妥当性確認の一連のプロセスと結9

an Integrated Method of Security Analysis and Assurance
over Life-cycle Process, IJCSDF 3(1): 49-62 Society of
Digital Information and Wireless Communications, 2014
(ISSN:2305-0012)[7]Sindre, G. and Opdahl. L. A. : Eliciting security
requirements with misuse cases, Requirements Engineering,
Vol.10, No.1, pp. 34-44 (2005).
[8]Mouratidis, H. : Secure Tropos homepage, (online),available from <http://www.securetropos.org/>.
[9]Liu, L., Yu, E. and Mylopolos, J. : Security and Privacy
Requirements Analysis within a Social Setting, Proc. IEEE
International Conference on Requirements Engineering(RE 2003), pp.151-161(2003).
[10]Li, T. Liu, L. Elahi, G. et al. : Service Security
Analysis Based on i*: An Approach from the Attacker
Viewpoint, Proc. 34th Annual IEEE Computer Softwareand Applications Conference Workshops , pp. 127-133(2010).
[11]Lin, L. Nuseibeh, B. Ince, D. et al. : Introducing Abuse
Frames for Analysing Security Requirements, Proc. IEEE
International Conference on Requirements Engineering(RE 2003), pp.371-372 (2003).
[12]金子朋子，山本修一郎，田中英彦：アクタ関係表に基づくセキュリティ要求分析手法（SARM）を用いたスパイラルレビューの提案,情報処理学会論文誌 52
巻 9 号(2011)[13]Kaneko,T.,Yamamoto, S. and Tanaka, H.:
Specification of Whole Steps for the Security Requirements
Analysis Method (SARM)- From Requirement Analysis toCountermeasure Decision -,Promac2011[14]Mead, N. R., Hough, E. and Stehney, T. :Sequrity
Qualty Reqirements Engineering(SQUARE)
Methodology(CMU/SEI-2005-TR-009),
www.sei.cmu.edu/publications/documents/05.reports/05tr0
09.html[15]Mead, N. R, 吉岡信和: SQUARE ではじめるセキュ
リティ要求工学,「情報処理」Vol.50 No.3（社団法人情報処理学会，2009 年 3 月発行）
[16]Steve Lipner ,Michael Howard,:信頼できるコンピュ
ーティングのセキュリティ開発ライフサイクル,
http://msdn.microsoft.com/ja-jp/library/ms995349.aspx,2005[17]松野裕，高井利憲，山本修一郎，D-Case 入門，～
ディペンダビリティ・ケースを書いてみよう！～, ダ
イテックホールディング, 2012 ，ISBN978-4-86293-079-8[18]T P Kelly & J A McDermid, “Safety Case Construction
and Reuse using Patterns”, in Proceedings of 16th
International Conference on Computer Safety, Reliability
and Security (SAFECOMP'97), Springer-Verlag,
September
1997.
[19]OMG, ARM,
http://www.omg.org/spec/ARM/1.0/Beta1/[20]J.R.Inge.The safty case,its development and use un the
United Kingfom.In Proc.ISSC25,2007.OMG, SAEM,
http://www.omg.org/spec/ SAEM/1.0/Beta1/[21]Tim Kelly and Rob Weaver, The Goal Structuring
Notation – A Safety Argument Notation, Proceedings ofthe Dependable Systems and Networks 2004 Workshop on
Assurance Cases, July 2004[22]Stephen Edelston Toulmin, “The Uses of Argument,”
Cambridge University Press,1958[23]The Adelard Safety Case Development (ASCAD),
Safety Case Structuring: Claims, Arguments andEvdence,http://www.adelard.com/services/SafetyCaseStructuring/index.html[24]DEOS プロジェクト, http://www.crest-os.jst.go.jp[25]松野 裕 山本修一郎: 実践 D-Case～ディペン
ダビリティケースを活用しよう！～,株式会社アセッ
トマネジメント，2014 年 3 月[26]Rob Alexander, Richard Hawkins, Tim Kelly，“Security Assurance Cases: Motivation and the State of theArt，”，High Integrity Systems Engineering Department ofComputer Science University of York Deramore Lane YorkYO10 5GH，2011[27]Goodenough J, Lipson H, Weinstock C. “Arguing
Security - Creating Security Assurance Cases,”2007.
https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/643-BSI.html[28]Lipson H, Weinstock C. “Evidence of Assurance:
Laying the Foundation for a Credible Security Case, “，2008.
https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/973-BSI.html[29]T. Scott Ankrum, Alfred H. Kromholz, ”Structured
Assurance Cases: Three Common Standards, “Proceedingsof the Ninth IEEE International Symposium on
High-Assurance Systems Engineering (HASE’05), “ 2005[30] 政府機関の情報セキュリティ対策のための統一基準（平成 26 年度版）,
http://www.nisc.go.jp/active/general/kijun26.html[31]IT 製品の調達におけるセキュリティ要件リス
ト,http://www.meti.go.jp/press/2014/05/20140519003/201
40519003.html [32] 金子朋子，村田松寿：セキュリティ
基準コモンクライテリアが変わる-ユーザもベンダも乗り遅れるな！, 情報処理学会デジタルプラクティス．
Vol6 No.1(Jan.2015)[33]情報処理推進機構 セキュリティセンタ,「 インシデ
ントマネジメント V1.0」
http://www.ipa.go.jp/security/awareness/administrator/inci
dent.pdf[34]コンピュータセキュリティインシデント対応ガイ
ド, NIST Special Publication 800-61Revision 1, （2008 年
3 月）[35] Robin Bloomfield & Peter Bishop: “Safety andAssurance Cases: Past, Present and Possible Future – anAdelard Perspective”,2010
scsc.org.uk/pubs/2010%20Bloomfield.pdf

10