ISMS構築で重要なリスクアセスメントの手法：GMITS-Part3：情報セキュリティマネジメントシステム基礎講座（4）

» 2002年10月17日 00時00分公開

[駒瀬彰彦，アズジェント]

　前回（第3回企業のセキュリティリスクを査定するガイドGMITS）に引き続き「リスクアセスメント」と「リスクマネジメント」についてGMITS（特にGMITS-Part3）を参照しながら、展開していく。前回、リスクアセスメントを行うに当たり、取り得る4つの戦略（ベースラインアプローチ、非形式的アプローチ、詳細リスク分析、組み合わせアプローチ）を紹介した。

どのアプローチを取るのか

　必要に応じて、“ベースラインアプローチ”と“詳細リスク分析”とを使い分けた“組み合わせアプローチ”を用いることが効率的であると紹介したが、どのような場合にどちらの手法を採用すればいいのであろうか？　どのアプローチを採用するかは一概には決定できないが、採用の決定には、情報資産を守るために求められるセキュリティ要件に依存することは確実である。

　セキュリティ要件に関しては前回触れたが、情報資産をどのように守るのかという要求事項のことで大別すると、情報資産の持つ（1）脅威・脆弱性にかかわる要件、（2）法的要件、（3）業務（ビジネス）上の要件のことである。対象となる情報資産に対しセキュリティ要件を明確化する、すなわち、ITシステムおよび取り扱われる情報のビジネス上の価値、ならびに組織がそのビジネスに対してどの程度期待しているかなどの点を明らかにすることで、リスクに対するアプローチが決定できる。

　GMITS-Part3では、これらのアプローチの採用に関しては、次の事項を考慮することとしている。

ITシステムを利用して達成すべきビジネスの目的
ビジネス・プロセスのITシステムへの依存性の度合い、すなわち、ビジネスの効果的な遂行のために非常に重要と考えている機能が、対象となるシステムまたはシステムで処理された情報の機密性、完全性、可用性、責任追跡性、真正性、および信頼性に依存しているか否かの程度
システム開発、メンテナンス、変更という観点での、対象ITシステムへの投資のレベル、および価値が高いと認知されているITシステムの資産

　これらの項目を評価し、システムがビジネス上、重要な位置付けである場合やシステム変更に伴う経費が高価である場合、または資産価値がリスクにさらされている場合など、これらの条件のいずれか1つでも対象となるシステムについては、詳細なリスク分析が必要であろう。

　つまり、ITシステムのセキュリティ欠如の結果、組織やそのビジネス・プロセス、またはその情報資産に多大な損失や損害が生じる恐れがある場合は、そのリスクを識別するために詳細なリスク分析が必要である。

　一方、それ以外の場合は、ベースラインアプローチを利用することによって適切な管理策を選択することが可能である。

●ベースラインアプローチ

　ベースラインアプローチとは、後述する詳細リスク分析とは異なり、リスクそのものを評価するわけではない。組織全体にわたり、あるレベルのセキュリティ水準に達するべく、ガイドラインや業界間で出版されているいわゆる規定や指示書などを参照して、未導入の管理策があれば、それを補強していくアプローチのことである。

●詳細リスク分析

　一方、詳細リスク分析では関連するリスクの識別、およびそのレベルの評価が含まれる。潜在的にビジネスを妨げるような事象に対し、その影響やそれらが発生する頻度を識別していく。発生する頻度は、脅威が発生する（顕在化する）可能性、脆弱性（弱点）に付け込まれる可能性、情報資産が攻撃者からどれほど魅力的なものであるのか、などに依存する。

　これらを明らかにすることで、識別されたリスクを許容範囲のレベルにまで低減させるための管理策を選択することができる。

　また、このようにして選択された管理策は、リスクマネジメント・プロセスの一環として選択されたともいえる（図1参照）。従って、リスクマネジメントを考慮すれば、これらの管理策の要件はセキュリティポリシーや手順書、計画書などで文章化しておく必要がある。図1に従い、詳細リスク分析を説明すると、まずその対象範囲を定義付けしておくことが重要である。プロセスが密に絡み合っているにもかかわらず、安易に範囲を狭め、慎重な定義付けを怠ると、後に不必要な作業が増えたり、抜けが見られたりすることにつながるからだ。

図1 詳細リスク分析を含むリスクマネジメント（GMIT-Part3より抜粋）

※注セーフガードとは、リスクを低減するための実践、手順、またはメカニズムと定義されており、いわゆる管理策のことを指している。

情報資産の識別

　情報資産とはいかなるものか？情報資産とは、組織がその価値を認識しているもので、何らかの保護を必要としているシステム全体の構成要素またはその一部である。従って、単にハードウェアやソフトウェアのみならず、さまざまなものからも構成されている。

　これを種類（形態）別に分けると下記のようになる。

情報、データ（例：顧客情報、経理情報、商品情報 ……）
ハードウェア（例：PC、サーバ、プリンタ ……）
ソフトウェア（例：OS、アプリケーションソフトウェア、処理プログラム ……）
通信設備（例：電話、銅線、ファイバ ……）
ファームウェア（例：FD、MD、CD、PROM ……）
書類（例：契約書、誓約書、規定集……）
施設、設備（例：社屋、電源、空調設備、サーバルーム ……）
要員（例：正社員、派遣社員、契約社員、顧客 ……）
商品、製造物（例：開発成果物、商品 ……）
サービス（例：情報提供サービス、計算処理サービス ……）
サービス提供から得る信頼（例：支払いサービス ……）
組織イメージ（例：企業イメージ、ブランドイメージ、評判、信用 …… ）

　実に多岐にわたっていることがお分かりいただけると思う。電子的なデータはもちろんそれらを処理するPC本体、記録媒体やファームウェアなども含まれる。また文書で記録された紙媒体情報や会話される情報、設備や建物といったものも該当する。そして企業および商品の評判、イメージなども情報資産としてリストに挙げる。何らかの理由で対象外とした情報資産も次回に忘れたり、見過ごしたりしないためにも、そのほかの項目などを設けてリストに挙げておくことは重要である。

情報資産の評価、および依存関係の確定

　情報資産を列挙したリストを作成後、資産価値を割り当てていく。これらの価値は組織のビジネスに基づく資産の重要度にほかならない。従って、組織のビジネス・ニーズに基づく情報資産の識別と評価は、リスクの判定における重要な要因となる。従って、情報資産のリスト化は、情報資産の所有者およびユーザーが行うことがよい。わが国では所有者というと、すべての資産は組織に属するという観点から、すべての情報資産に対しても組織が所有者であると思われているが、ここで所有者とは、その情報資産の作成者や責任者のことをいう。また、これらをオーナーと呼ぶ。このオーナー自身が配下にある情報資産の価値を評価していくことが望ましいが、価値を特定するには、経営企画、財務、情報システム、およびそのほかの関連事業部門からの協力を得ることは不可欠である。

　そのうえで、情報資産の価値、重要性を確定していく。しかし、実際の財務的な価値を判断することは、困難であり、容易な方法が知られていない。従って、価値の判断に対しては、3?5段階程度のレベル分けを行い、「低い」「中程度」「高い」、または「無視できる」「低い」「中程度」「高い」「非常に高い」などのレベルを設けることで判断する。

　次に、資産間の依存性を特定することも価値を判断するうえで重要である。一見、価値が低いと思われる情報資産でも、いわゆる資産価値の高いプロセスの構成要素であれば、その資産が破壊されたときに、その影響で多大な損害を受けるかもしれないからである。例えば、あるビジネス・プロセスが、プログラムによって生成される特定のデータの完全性に依存しているサービスなどであれば、このプログラムに入力されるデータも完全性を高く保たれなければならない。また、この情報の完全性は、それらが格納され、さらに処理される場合に用いられるハードウェアやソフトウェアにも依存することになる。

　また、このハードウェアは、施設からの電源供給、場合によっては空調にも依存してくる。このような場合は、その一連のビジネス・プロセスに基づき、価値を調整する必要がある。例では「完全性」を挙げたが、機密性、可用性、責任追跡性、真正性、信頼性においても同様である。従って、情報資産を単なる個別の資産ととらえずに、いわゆるビジネス・プロセス単位、またはプロセスアプローチという考えを持ち情報資産の価値を的確に調整することが肝要である。余談かもしれないが、このプロセスアプローチという考え方は品質などのほかのマネジメントシステムでも採用されている。調整に際しては、一例ではあるが、下記のような方針に従い、価値を調整することを考慮に入れていただきたい。

従属資産（例：データなど）の価値がそれらを処理するいわゆる情報資産（ハードウェア、ソフトウェアなど）より、資産価値が低いあるいは同等である場合は、ハードウェアなどの情報資産の価値に修正を加える必要はない。
従属資産（例：データなど）の価値がそれらを処理するいわゆる情報資産（ハードウェア、ソフトウェアなど）より、資産価値が高い場合は、それらの価値を次の要因を踏まえ増加させる。
- 依存度
- ほかの資産価値

　いずれにせよ、情報資産価値は、依存関係を通じて互いに影響し合っていることを念頭に置いておいていただきたい。従って、情報資産を識別するために必要な情報として、少なくとも「評価年月日」「評価者」「所有者名（管理者名）」「情報資産の形態」「保管場所」「保管状態」、「利用者」「ほかの情報との依存性（情報元や結果の反映先）」などが挙げられる。これらの情報は、その情報資産を把握し、情報の性質を理解し、資産価値だけではなく、次のステップでかかわる脅威や脆弱性などを明らかにする手助けとなる。

脅威の評価、脆弱性の評価

　資産価値の評価後、特に価値が高いものに対して、脅威、脆弱性を識別し、評価していく。脅威とは、情報資産や組織に損失や損害をもたらす不測事態の潜在的な要因で、下表のように大別される。

脅威の分類例
人為的脅威		環境的脅威
意図的（計画的）脅威（D：deliberate）	偶発的脅威（A：accidental）	環境的脅威（E：environmental）

例としては次のようなものが挙げられる。


脅威	タイプ　（D、A、E）
地震	E
火災	D、A、E
停電	A
ちり、ほこり	E
静電気	E
湿気	D、A、E
オペレータの操作ミス	D、A
人的リソース（スタッフ）不足	A
ソフトウェアの故障	D、A
送信エラー	A
盗難	D
IDの偽り	D
悪意のあるソフトウェア	D、A
不正侵入	D

　脅威の評価に関しては、その要因および対象となる情報資産を識別したうえで、その脅威が発生する可能性を評価することになる。従って、前述の資産価値の評価同様、オーナーだけではなく、他事業部門やそれらを実際に処理している管理者や専門家からの協力は不可欠であろう。

　脅威の発生頻度を評価するには、

経験や統計データが整っているのであれば、その値を脅威の頻度とする。
意図的（計画的）脅威に対しては、攻撃者の動機、必要とされる技術、利用できるリソースを考慮にいれ、情報資産の特性、魅力、脆弱性からどのような要因が脅威であるかを認識する。
偶発的な脅威に対しては、立地条件、極端な気候条件の可能性、および要員によるミスや誤動作などから影響を及ぼす可能性を識別する。

などを視野にいれて、脅威を識別し評価していく。評価では、どの程度の正確性を要求されるかにもよるが、「低い」「中程度」「高い」で区分しておく。

脆弱性の評価

　脆弱性とは、脅威の発生を誘引する情報資産固有の弱点やセキュリティホールのことである。脆弱性自体はそれだけでは何ら障害とはならないが、脅威を顕在化させ、損害や障害を導いてしまう存在である。逆にいえば、脅威が存在しない脆弱性に対しては、あまり気を配らなくてもよいということにもなる。

　また、脆弱性を識別するには、その情報資産の性質や属性と関連付けて考えていくと分かりやすい。例えば、ノートPCを例に取れば、その性質から持ち運びやすい、衝撃に弱い、公共の場で用いられることがあるなどがすぐに挙げられる。これと同時に、これらがいわゆる「盗難」「置き忘れ」「故障」「情報漏えい」という脅威に対する脆弱性を示していることに気付くであろう。脆弱性の例としては次のようなものが挙げられる。

脆弱性の分類	脆弱性の例	関連する脅威の例
環境、施設	ドア、窓などの物理的保護の欠如	盗難
	不安定な電源配給設備	停電、誤作動
	災害を受けやすい立地条件	洪水、地震など
ハードウェア	湿度変化に影響を受けやすい	故障、誤作動
ハードウェア	記憶媒体のメンテナンス不足	故障、情報漏えい
ソフトウェア	仕様書の不備	ソフトウェア障害、誤作動
	アクセスコントロールの欠如	なりすまし、改ざん、情報漏えい
	不適切なパスワード	不正アクセス、改ざん、情報漏えい
	監査証跡（ログ管理）の欠如	不正アクセス
	バックアップコピーの欠如	復旧不能
	文書化の欠如	オペレーティングミス
通信	保護されていない通信経路	盗聴
	ケーブル接続の欠陥	通信傍受、通信不能
	非暗号化	情報漏えい
文章	保管不備	盗難、紛失
文章	コピーに関する教育の不徹底	盗難、情報漏えい
人事	要員の欠如	ミス、不満によるいやがらせ
	清掃スタッフなどに対する監督不在	盗難、システム破壊
	不十分なセキュリティ訓練	オペレーションミス、復旧遅延
	セキュリティ意識の欠如	情報漏えい、システム破壊
そのほか	予算不足	さまざまな脅威
	不適切な保守サービスの利用	故障時に復旧不能
	納入情報の保管不備	信用の失墜

　前述したが、リスト化する際、上表のように脅威とペアで考えておくと、整理がしやすいであろう。

　一方、脆弱性は、その情報資産の利用環境や保管場所、プロセスの進行状況（ステージ）、形態、時間などで、大きく変化する。同じ情報資産名であっても、その環境によっては、まったく異なる脆弱性を持つこともある。その際は、同じ資産であっても、情報1、情報2などに区別して管理することが望ましい。また、そのためにも情報資産を識別する際には、これらのことを明記しておく必要がある。　

　脆弱性の評価は、その弱点がどの程度容易に利用可能であるかを評価することになる。何も対応策を施しておらず、その弱点がむき出しで、容易に利用されてしまうのであれば、脆弱性は高いことになる。どの程度の正確性を要求されるかにもよるが、脅威同様、脆弱性に関しても、「低い」「中程度」「高い」などで区分しておく。

既存および計画中のセーフガードの確認

　前述の、「資産価値の評価」「脅威の評価」「脆弱性の評価」に従って、リスクを評価する前に、リストに既存のまたは計画中のセーフガードを確認し、記述しておいた方がよい。その理由は大きく分けて3つある。

過剰にセーフガードが実装されていないかを確認し、不必要な費用投資を避ける。
脆弱性評価の見直しにつながる。
リスク評価後に採用するセーフガードと、今後導入を計画中のセーフガードに矛盾がないようにする。

　このようなメリットから、情報資産の評価リストにこれらの内容を記述しておくことを推奨する。

リスクの評価

　さて、「資産価値の評価」、「脅威の評価」、「脆弱性の評価」および、リスクを低減させる可能性のある「既存および計画中のセーフガード」の関数でリスクを評価することができる（図2参照）、さまざまな方法が知られている。

図2 情報資産、脆弱性、脅威の識別とその因果関係（参照 GMITS Part1）

●例1：定義付けられたリスク値のマトリクスを利用する（表1）

この手法では、表に示すようにあらかじめリスクの値を表中に0?8という数で示しておく。
次に、「資産価値の評価」を5段階、「脅威の評価」と「脆弱性の評価」を「低い」「中程度」「高い」といった3段階でレベル付けする。
レベル付けされたおのおのの評価から、このマトリクスを利用してリスク値を求める。例えば、資産価値が3、脅威が「高い」、脆弱性が「低い」であれば、それらがマッチするところ、すなわちリスク値は5であると評価される。

脅威のレベル		低			中			高
脆弱性のレベル		低	中	高	低	中	高	低	中	高
財産の価値	0	0	1	2	1	2	3	2	3	4
……	1	1	2	3	2	3	4	3	4	5
……	2	2	3	4	3	4	5	4	5	6
……	3	3	4	5	4	5	6	5	6	7
……	4	4	5	6	5	6	7	6	7	8

表1 リスク評価シートの例１（GMITS-3より抜粋）

●例2：リスクの度合いよる脅威のレベル（表2）

この手法では、インパクト（影響）という損害時に及ぶであろう影響度（情報資産価値ともいえる）をパラメータとして、それと脅威の発生の可能性を組み合わせて、脅威の格付けを行う。
最初にインパクト（b）を5段階程度で評価。脅威の発生頻度（c）も5段階程度に評価しておく。
次にリスクの度合いを（b）と（c）を積算すること（（b）＊（c））で求め、数値の大きい順（リスクが高い順）に階級（e）を付与していく。（e）の値が小さいほど、リスク値が大きいということである。


脅威の記述子（a）	影響（資産）の価値（b）	脅威発生の可能性（c）	リスクの度合（d）＝（（b）＊（c））	脅威の格付け（e）
脅威A	5	2	10	2
脅威B	2	4	8	3
脅威C	3	5	15	1
脅威D	1	3	3	5
脅威E	4	1	4	4
脅威F	2	4	8	3

表2 リスク評価シートの例2（GMITS-3より抜粋）

●例3：リスクの頻度および考慮される損害の価値評価（表3、表4）

この手法では、表3にあるように、脅威の発生と脆弱性を「低」、「中」、「高」で評価しておき、表3を用いて「発生頻度値」をマトリクスから抽出する。

脅威のレベル	低			中			高
脆弱性のレベル	低	中	高	低	中	高	低	中	高
発生頻度値	0	1	2	1	2	3	2	3	4

表3 リスク評価シートの例3（GMITS-3より抜粋）

次に資産価値を5段階（0～4）程度に評価しておき、表4から資産価値と前ステップで得られた「発生頻度値」を組み合わせ、リスク値を抽出するやり方である。

財産価値	0	1	2	3	4
発生頻度値	0	1	2	3	4
0	0	1	2	3	4
1	1	2	3	4	5
2	2	3	4	5	6
3	3	4	5	6	7
4	4	5	6	7	8

表4 リスク評価シートの例3（GMITS-3より抜粋）

　いずれの方法を採用し、リスク値を求めるにせよ、このリスク評価から得られた結果は対象となる情報資産に対して、妥当に評価されているものでなければ何の意味もない。例えば、明らかにリスクが高いであろうと予想されていた情報資産のリスク値が予想以上に低い値であったり、同一プロセス内で利用されているプログラムなどの情報資産のリスク値の結果に大幅な差異が生じている場合は、その見直しをし、修正が必要であれば行うべきである。そのためにも、用いる手法は反復可能でかつ、追跡可能であることが望ましい。

　また、そのためにも、その手法を支援するリスク評価ソフトウェアやデータベースを用いることを推奨する。今回紹介した手法を備えたリスクアセスメント・ソフトウェアである「RAソフトウェアツール」（RA：Risk Assessment）を近く、一般企業およびセキュリティ・ポリシーアライアンスメンバーに向けてセキュリティ・ポリシーアライアンス（http://www.policyalliance.com）より紹介する予定だ。

　今回は、リスクマネジメント・プロセスにおけるリスク評価について、GMITS-Part3を参照しながら紹介した。次回は、そのリスク評価の結果からどのような管理策を選択し、導入するのかについて触れる。