131
Ⅰ－２．リスク要件リファレンスモデル運用解説
1 リスク要件リファレンスモデルの運用イメージ
リスク要件リファレンスモデルは、発注者、受注者双方が情報システムの セキュリティ対策について共通の基準で検討するための枠組みを提供するも のであり、以下の目的を持つ。
情報システムのセキュリティ対策に関する要件定義と構築の中で大きな問 題となるのは、発注者や受注者等のシステムの関係者に対して、非機能要件 であるが、セキュリティという専門性の高い分野で議論をしなくてはいけな い事にある。
リスク要件リファレンスモデルのドキュメント集は、これらの事情を踏ま えて、発注者および受注者が構築対象としているシステムについて双方が共 通の技術的な条件と共通のリスク認識でコミュニケーションが取ることがで きるツールを想定して作成されている。しかしながら、構築される情報シス テムの形態や目的は多岐に渡っているために、それぞれ個別のシステムの事 情を全て勘案する事は現実的には出来ない。したがって、リスク要件リファ レンスモデルでは、いくつかの類型を提供している。
そこで、このドキュメントを有効に活用するためには、標準的な運用の方 法を基本として、運用体制と運用の流れを理解し必要に応じて個別の事項を 検討してもらう事が望ましい。
リスク要件リファレンスモデルでは、情報システムのセキュリティに関す る実際の検討の中で、本ドキュメントの内容を利用する際に取扱が容易にな るように、検討の対象と一連の検討の流れを一体化させた「重要脅威カタロ
リスク要件リファレンスモデルの目的
リスク要件リファレンスモデルは、情報システムの発注者と受注者
がそれぞれの立場で、具体的な脅威に基づいてシステムに組み込む
べきセキュリティ対策を検討可能とするものとして開発された。本
モデルによって、官公庁および民間の情報システム構築の発注者と
受注者は共通の理解の下に情報システムに必要なセキュリティ対
策設計が行われることを目的とする。
132
グ」と呼ばれるものを整備している。脅威カタログの構成は以下のように整 理されている。
パターン1：「正規Web 閲覧によるマルウェア感染（情報搾取）」
バリエーション１："gumblar.xウイルス系感染サイト閲覧"
振る舞い図
攻撃仕様
パターン概要図
バリエーション２："**.ru:8080ウイルス系感染サイト閲覧"
トポロジ基本図上の 設計対策概要
組織の問題点整理 攻撃事例
カタログリスト 各パターンマージ設計対策
仕様項目集（ TRM と整合）
設計対策セット
各パターンをマージした設計対策・品質要求項目リスト「仕様項目集（TRMと整合）」
脅威の実態の明確化と対策の明示 トポロジ基本図
重要脅威カタログの構造
第２章
３．３節 ３．２節 第５章
３．４節
４．２節
第６章 ３．４節
（トレース結果）
要求仕様ひな形 試験要求ひな形
要求仕様ひな形 試験要求ひな形 振る舞い図
攻撃仕様 トポロジ基本図上の 設計対策概要
設計対策セット
（トレース結果）
（６．１節）
（６．２節）
図 1-1 脅威カタログの構成
脅威カタログに含まれている各要素については、以降の節で説明されるが、
リスク要件リファレンスモデルにおける検討プロセスを一覧するものとなっ ている。
リスク要件リファレンスモデルは、システムの関係者に共通言語とコミュ ニケーションの場を提供する仕組みを重視しているので、情報システムを検 討する場合にそれぞれ異なった目的で、いくつかの利用場面を想定すること ができる。
（１） 本モデルを用いた設計要件の検討
リスク要件リファレンスモデルの作成目的の中心にあった利用形態であり、
133
構築対象となるシステムの設計時に要件として取り込む事項の検討に用いら れる。情報システムの要件定義を行う際に、発注者と受注者の間でコミュニ ケーションが適切に実施されるためには、システムを構想した時点からセキ ュリティ要件を確定するプロセスを共有しておく必要がある。さらに、セキ ュリティの分野の対策は、専門性の高い技術的な検証に裏付けられた対応が 求められることが多く、セキュリティ要件にもその事情が反映する。しかし、
発注者および受注者の窓口担当は、セキュリティ対策の領域に明るくない場 合も多い事を想定した運用体制も必要となる。
以下に、この利用場面でのイメージを示す。
重要脅威カタログ パターン概要図 振る舞い図 攻撃仕様 トポロジ基本図
有効な設計対策 事例
組織上の問題点 システム構想検討（提案）
基本図（インタネット接続型） 自システムにとって、有効な設計・管理策は何か？（含コスト見積）
自組織にとって、重要業務へのインパクトはどの程度か？
各パターンをマージした設計対策・品質要求項目リスト
「仕様項目集（TRMと整合）」
システム設計・製造（契約）
自組織にとっての影響、システム現象（何が起きる）は何か？
（BCM:発生を前提にダメージコントロール計画）
ＲＭの参照により、自組織における業務インパクトを分析し各所調整及びシステム機能要求要否を判断。
システム設計製造時においては、RM細部内容を設計・テスト等に利用。
（BCM:インパクト分析）
各所調整・要求判断 ＲＭ
基本参照モデル
ＲＭ利用者
システム製造時の設計製 造・テスト等にもRMを利用
改竄された正規Webサイトの閲覧により、マルウエア配布サイトに誘導。認証 情報等の搾取とバックドアの設置が行われる。
搾取された認証情報の利用により、自システムの管理Webサイト改ざん及び 攻撃利用基盤の拡大が図られる。
Web管理を裏Lan設計とする事により、搾取情報を用いた Webサイト誘導改竄 は防止可能。（重要業務インパクトが存在する場合、２要素認証がベター）
その他の対策効果は運用管理能力等に依存。
以下のシステムであった場合であった場合、取引停止、販売等ビジネス中断、
損害賠償等の業務インパクトの可能性があり得る。（組織活動に与える影響）
・顧客情報を預かるシステム
・ネット決済ビジネスを含むシステム
・支払決済決算に関するシステム、融資・資産運用等
サイト管理の委託構造が多層分散されている場合、事故発生時の賠償責任の 所在と契約内容との関係が契約課題となる可能性を検討。
システム基本構成から 参照部分を特定
トレース分析結果
パターン1：「正規Web 閲覧によるマル ウェア感染（情報搾取）」のケース
図 1-2 要件判断プロセスでの活用イメージ
（２） 本モデルを用いたインシデント発生時への対処
リスク要件リファレンスモデルでは、脅威カタログとして、脅威対象のパ
ターンとシステムトポロジのパターンが用意されている。この中では、それ
ぞれの脅威対象がシステムの中でどのように振る舞い、どこで問題の現象が
発現するかを把握する事はできるようになっている。したがって、既存のシ
ステムに対してサイバー攻撃等を受けた際には、システムのどの部分で問題
が発生していたかという事を特定し、その箇所に対する回避策等の暫定的な
対策をシステムに講ずるための検討に用いる事ができる。
134
以下にこの利用場面でのイメージを示す。
サイバー攻撃事案発生時、自システムへの影響と回避策設計の有無、組織活動に与える影響の検討、暫定対策等の確認並びに対 策立案に利用。
重要脅威カタログ パターン概要図 振る舞い図 攻撃仕様 トポロジ基本図
有効な設計対策 事例
組織上の問題点 サイバー攻撃発生時
基本図（インタネット接続型）
ＲＭ 基本参照モデル システム基本構成から 参照部分を特定
ＲＭ利用者
自組織にとっての影響、システム現象（何が起きる）は何か？
発生サイバー攻撃に該当する「攻撃仕様と有効な設計対策」から自システム を参照確認。 組織活動に与える影響を検討。
「最悪、この通信を遮断出来ればシステムは防御」部分の対処がなされてい れば、“攻撃目的の達成（最悪事態）”にまでは至らない。
各所調整・暫定対策検討（含工数）判断 トレース分析結果
暫定対策等検討
その他、利用可能な確認tool等の利用
■ MyJVN バージョンチェッカ
■ MyJVN セキュリティ設定チェッカ
図 1-3 インシデント発生時に暫定的な対策の検討イメージ
実際に標的型メール攻撃を受けた時の影響や危険性の判断と対応検討を行う 場合の利用について以下に一例を示す。
標的型メール添付マルウエアの解析結果が得られる場合は、その結果とリス ク要件リファレンスモデルの該当パターン分析結果と照合する事で、その危険 性及び必要な設計管理対策が見いだせる。
自システムにこの設計管理対策が既に施されていた場合は、情報漏洩（搾取）
の危険性は少ないと速やかに判断できる。
また、概要整理部分を用いて直ちに組織各所への説明及び調整に入る事が可
能となる。
135
パターン2：「標的型メール攻撃（情報搾取）」のバリエーション１：メール添付ファイル系cに該当。
:系bは443を使い、系cはPOST,GETを使う特徴で区分整理
危険性：bot化による各種情報搾取（インターネット上のサーバへ搾取情報をアップ）
多段型のマルウエアダウンロード
設計管理対策：GET,POSTコマンドで情報送信を使用するため、通信遮断可。
Webブラウザからのものに似ているが、Accepted-Languageヘッが無い。
この辺りをFirewallルールに入れられれば防御可能の可能性有り。
メール添付マルウエア解析結果
動的解析（追跡観測）
静的解析
参照
攻撃発生時のパターン照合による影響と対策判断 攻撃発生時のメール添付マルウエア解析情報とRM重要脅威カタログを 照合し、攻撃概要、トレース結果による影響と対策を確認。組織へのイン パクトと対処優先度を判断し、組織内説明等に利用
攻撃情報等
攻撃パターン照合
攻撃概要の確認
攻撃詳細動作の確認
危険性、影響範囲、対策有無の確認
図 1-4 攻撃発生時の影響と対策分析での使用事例
（３） 本モデルを用いた複合的もしくは部分的なシステム導入での検討 リスク要件リファレンスモデルでは、典型的なシステム構成を想定してセ キュリティの要件を整理しているが、実際の規模が大きなシステムでは、骨 幹 LAN、共用 LAN および支所等とシステムが接続されているが、それぞれの セキュリティポリシが異なっている場合等があり得る。このような複合的な 接続関係を持ったシステムに対しては、例えば、霞が関 WAN をインターネッ トと同様に見立てる事によって、リスク要件リファレンスモデルの運用も可 能である。
また、サーバのみを導入するような特定部位のみに使う場合にもネットワ
ークとしての脅威は変わらないので、骨幹となるシステムトポロジを含めて
検討することが必要となる。
136
骨幹Lan、共用Wan、支所等セキュリティポリシの異なるシステム接続形態でのＲＭ運用例 骨幹Ｌａｎ等に追加するシステム発注の要件定義に関する調整場面
骨幹Lan部分
②別契約追加部分
①支所部分
ケース１：共用Wan等、別ポリシで設計管理システムを介する場合（①）
共用Wan等をインターネットと同様と見立てて、重要脅威カタログで定義される攻撃仕様のトレース結果を参照利用。
ケース２：骨幹Lan上に別契約で機能追加する場合（②）
共用Wan
攻撃脅威
契約時に骨幹Lanとの接続仕様調整を規定。その上で、骨幹lanを介したトレース結果を参照利用。
図 1-5 骨幹 Lan に追加する契約形態での使用事例
1.1 リスク要件リファレンスモデルの運用の流れ
本節以降では、リスク要件リファレンスモデルの利用方法として中心的な役割 を担っている、設計要件の検討時における運用を中心に説明を加える。他の利 用の方法についても基本となる設計要件の検討での使い方を把握する事で比較 的容易に応用展開が可能である。
実際の運用に際して、本ドキュメントで整理された内容を有効に活用していく ために、いくつかの運用の前提となる条件を整理する。
（Ａ）運用に際しての体制面での前提条件
リスク要件リファレンスモデル集を有効に運用するためには、発注者
と受注者の間で正しく情報共有ができている事が重要である。しかなが
ら、セキュリティ関連は専門性が高い分野である事から、受注者である
システムベンダの SE も本ドキュメントのみで正しい理解を得られるとは
限らない。この点を考慮して、リスク要件リファレンスモデルを運用す
る際には、受注者側のベンダにセキュリティの専門家が少なくとも 1 名
137
以上がアドバイザーとして参加している体制で本ドキュメントが活用さ れる事を前提とする。
設計検討の場合で実務的な活用を行うためには、本ドキュメントに直 接記載された事項以外の要因がセキュリティ設計要件を詰める際に必要 となる場合もあるので、リスク要件リファレンスモデルの本質を理解し ているセキュリティの専門家が発注者とシステムベンダの SE をサポート することで精度の高い効果的な設計検討の体制を構築する事ができる。
具体的には、セキュリティ専門家は、リファレンスモデルを活用して、
発注者と受注側の SE のコミュニケーションの橋渡しを行う。本ドキュメ ントはその際の共通言語として利用される事を想定している。
ただし、そのような専門家がいない場合には、雛型となる仕様書のパ ターンをコピーする事で活用する事も可能としている。
（Ｂ）対象となるシステム規模に関する前提条件
リスク要件リファレンスモデルが対象としているシステムは、セキュ リティに関する対策が比較的複雑で影響範囲を確認する事も簡単ではな いシステムを想定している。したがって、本ドキュメントの運用時にお けるセキュリティ専門家のサポート等の体制を勘案した場合には、投入 可能な予算やリソースという面から見ても対象とするシステム規模は比 較的大きなものでなくてはならないと考えている。
規模が小さなシステムであれば、そこにおけるリスク評価をより的確 に実施して把握しやすい事やそこから導出される対策もより簡便な形で 構築できる可能性も高いと考えられるので、リスク要件リファレンスモ デルとは別の枠組みで検討する事の方が、効率がよい場合もある。
上記の運用上の条件の下で、セキュリティの設計要件を詰めるプロセスは以 下のように行われる。
（１） 運用の標準的な手順
リスク要件リファレンスモデルを用いてシステムを要求する発注者と具
体的なシステムを提案し受注するシステムベンダの間での標準的なやり取
りの流れは以下の図のようなイメージで進められていく。このようなやり取
りは、官民を問わず比較的規模が大きなシステムの設計時には通常実施され
ている流れの一部として組み込むことが可能である。
138
振る舞いパターン
○振る舞いパターン１
「Webサイト誘導型モデル」
○事例
○攻撃成功条件（パス単位）
・使用脆弱性
・使用通信
・コマンド内容
・erc
トポロジモデル
○トポロジモデル１
「イントラモデル」
○設定情報（NTW、SV単位）
・使用サービスパス
・開放ポート
・ゾーン設計
・etc
机上攻撃トレース結果
○振る舞いモデルでの影響分析
○トレース結果
・影響部位
・影響内容
・etc
影響・危険性（リスク）
*組織業務への影響
・何がされるのか？
・何が起きるのか？
組織上の問題認識
*組織業務上の問題視点
・何が困るのか？
・どのような組織問題なのか？
設計対策
対処設計セット
*振る舞いモデルでの机上攻 撃トレースの影響（被害範 囲）を回避するための設計内 容を整理
運用管理対策 設計時に利用可能 なジグtool
*振る舞いモデルに示す攻撃 の影響を緩和する為に考慮 すべき要素と手法について 整理（対応優先判断の技等）
運用管理時に利用 可能なジグtool 運用管理時に考慮すべ き要素
・対応優先度ファクター 脅威
脅威 影響分析
危険性
原因 問題認識
対策手段
発注要件調整場面 サービス仕様からシステム 特性の特定
RMプロセス分析結果を提案
（含むコスト見積もり）
システム特性から対象となる 脅威振る舞いパターンを特定 特定した振る舞いパターンの 対象トポロジのトレース結果
（危険性）を確認 システム特性に近いひな形 トポロジモデルを特定（必要 に応じカスタマイズ）
危険性から組織上の問題点 を整理（システムの設計対象 サービス業務）
システム製造プロセス RM プロセス分析
問題点整理の確認により発注要件要否を判断
（含むコスト見積もり）
PM プロセス結果を基に要求 項目を仕様書規定
TRM?
＊RMプロセスでは、仕様書記載レベルも規定（TRMと整合）
RMプロセスで分析した結果を基に、以降の製造各工程に展 開（システム基本設計、製造、試験等...）
RMプロセス分析結果
①
②
③
④
設計管理対策を提案（対策 後振る舞いトレース結果）
関連部門、下請け
⑥
要求側
提案側
RMはRFPの一部として運用？
脅威の実態の明確化
社内のセキュリティ設計 要件リストを RM と照合し て設計管理対策をFIX
② ①
③
④
⑥
⑤
図 1-6 標準的な運用の流れ
リスク要件リファレンスモデルでは、脅威対象となるウィルスの振る舞いパタ ーンとそれらがシステムトポロジ上でどのような障害を引き起こすのかを机上 で確認した結果とそれに基づいたセキュリティ対策セットが一連の流れとして 脅威カタログとして整理されている。
これらの基本情報を用いて上記の標準的なプロセスを踏んで設計要件を検討 していく事になるが、誰がリスク要件リファレンスモデルの主要な利用者とな り、各プロセスで誰が何を判断しなくてはならないかにも留意して取捨選別し ながら手順を組み立てる必要がある。
リスク要件リファレンスモデルの中心的な利用者としては、本ドキュメント
の内容を適切に理解し応用動作を含めた運用を想定するとある程度のセキュリ
ティの専門知識を有する人材が求められる。本ドキュメントの運用前提の体制
挙げたセキュリティの専門家が中心となり、システムベンダの技術者への説明
や要求元の発注者への説明に脅威カタログ等を用いて実施するのが設計要件を
決める際には有効である。
139
表 1-1 標準手順における主たる利用者とドキュメントとの関係 手
順
RM ドキュ
メント活用
システム要求元
（発注者）
システムベンダ SE
（受注者）
セキュリティ専門家
（アドバイザー）
１ システム機能要求お よび諸条件の提示
２ 実現可能な具体的シ
ステム構成の検討
３ シ ス テ ム ト ポロジ類型
類似するシステムト ポロジとの対応選択
４ 脅威対象の特定 脅威対象の特定 脅威対象に関するア ドバイス
脅威対象の共有 脅威対象の共有 脅威対象の共有
５ 振 る 舞 い パ ターン
脅威対象となる振る 舞いパターンの選択
６ 脅威トレース結果の
選択
７ 脅 威 ト レ ー
ス結果 リスク現象の把握 リスク現象の把握と
理解 リスク現象の説明
８ 組 織 内 影 響 と問題点
組織内影響の検討と 設計対策範囲の確認 と判断
組織影響の検討支援 組織影響の検討支援
対策範囲の共有 対策範囲の共有 対策範囲の共有
９ 対 策 セ ッ ト 一覧
システムへの対策事 項の検討
システムへの対策セ ットの検討支援
10 システムの提案
11 システム提案の合意 システム提案の合意
140 1.2 システムトポロジモデルの特定
リスク要件リファレンスモデルの最初のステップとして、設計対象としてい るシステムに関するネットワークの構成と類似するシステムトポロジを与えら れたモデルから特定する必要がある。このシステムトポロジの類型として、４ つのパターンを用意している。
システムトポロジモデルを特定する際には、構築対象とするネットワークの システムトポロジを整理する必要がある。ただし、個々のシステムは、実現す る機能と仕組みに応じて、システム規模の相違やネットワーク構成の複雑度等 がまちまちである。したがって、直接的にシステムトポロジモデルと一致する ものを見出すことは難しい。そこで、実際のネットワークの構成をここで提供 されているシステムトポロジモデルと対応させるために以下のポイントが重要 となる。
(1) ネットワークの利用環境
リスク要件リファレンスモデルで、提示している４つのシステムトポロジ モデルは、それぞれネットワークの利用形態に特徴がある。この利用形態 によって、自組織でネットワーク構成やサーバ等が調整できるものから、
契約等でその利用範囲等が制約されているようなものもある。
設計対象としているシステムトポロジの利用形態が以下のどのタイプに なっているかを選択することが重要である。
－イントラネットタイプ －閉域型ネットワークタイプ －IDC 利用型ネットワークタイプ －Saas 利用型ネットワークタイプ
これらは、システムトポロジの構成もさることながら、各サービス提供 企業との契約の問題により責任分解点に影響を与える可能性が大きい。し たがって、セキュリティ対策等を包括的に検討する際には、第三者提供の サービスとセキュリティに関するう条件を正しく把握しておく事が肝要 となる。
(2) 骨幹となるシステムトポロジ構成の類似性
設計対象としたシステムを構築するために、ネットワーク構成上重要なネ
ットワークパスの部分で類似のシステムトポロジ構成を持っているもの
があれば、そのシステムトポロジモデルを選択することでシステムの挙動
141 を確認することができる。
システムの設計範囲が、ネットワーク的に緊密に連携しているより大き なシステムの一部分を調達するような場合には、そのシステムを含む全体 のシステムトポロジとして、類似するシステムトポロジモデルを特定する 必要がある。
(3) 複数のシステムトポロジ要素の混在
設計対象のシステムが、システムトポロジモデルで示した要素を複数有し ており、それぞれに重要な役割を担っている場合には、それぞれに対応し たシステムトポロジモデルでの挙動を通して検討を加えるのがよい。複数 の要素が混在した場合に、セキュリティポリシの相違やシステムの連椄部 等の相互に与える影響を考慮する必要がある場合については、今後の検証 の中で精緻化していく予定である。
以下に、システムトポロジモデルとして提示されている４つの典型的なシス テムトポロジモデルを示す。
No モデル名 システムトポロジモデルの形態
1 イントラ
ネットモ
デル インターネット
リモートアクセス、Windows Mobile対策（LGWAN、霞ヶ関WAN）
インターネット接続システム
構内システム
インターネット接続
セキュリティトポロジーマップ
SECURITY MAP INTRANET(OPEN) MAP
基本図 （インタネット接続型）
ルーター（L3スイッチ）
ルーター（L3ス イッチ）
アプリケーションセグメント スイッチ（Ｌ２）
対策セグメント スイッチ（Ｌ２）
インターネット接続 セグメント スイッチ（Ｌ２）
イントラネットサーバ セグメント スイッチ（Ｌ２）
管理・その他 セグメント スイッチ（Ｌ２）
利用者セグメント スイッチ（Ｌ２）
利用者セグメント スイッチ（Ｌ２）
L4ファイア ウォール
L4ファイア ウォール
分室セグメント スイッチ（Ｌ２）
