リスク分析の考え方

Last Updated 2003/1/3

NetworkWorld　2002年10月号掲載

リスク分析の考え方

セキュリティポリシーを作るとき、いきなりガイドラインや手順書を作ったとしても、現実に行なわれている運用や運営方法にそぐわない、言ってみれば「理想的」なものになってしまう。現実から著しく乖離したルールを作ったとしても、無視されて守られなくなってしまうのがオチだ。
そうならないために、リスク分析をする必要がある。
ではそのリスク分析とはどのような手順で行なうのか、そのあたりから見てみよう。
リスク分析の目的は、現状のリスクには何があるのか、そしてその程度はどのくらいか？を見極めることにある。一般的には以下のような段取りで行なう。

ポリシー作成のところでも書いたが、（１）の情報資産の洗い出し、というフェイズは、リスク分析範囲を特定することを目的にする。情報資産を列挙して分析し、プライオリティを付ける。そして重要なものだけ詳しくリスク分析をするわけだ。
もちろんすべての情報資産に対し詳細にリスク分析することが理想的だが、そんなことをやっていると作業量がものすごいことになっていしまう。限定的に詳しく、というのが現実的であろう。（リスク分析のアプローチについては後述する）
まずは情報資産というものをどうやって洗い出すのか、そのあたりから見てみよう。
情報資産の洗い出しは、とにかく直感的でも何でも良いので、がんがん列挙する。前説のところでも触れたが（表１）、列挙するときに資産の単位だとか、レベルだとかを気にする必要はあまり無い。
情報資産を列挙できたら、今度はその所有者、管理者を挙げていく。ひとつひとつの情報資産には必ず管理者が居るはずだが、もし居なかったら（笑）作成者でも良い。
こうして挙げられた情報資産に対し、業務や経営への影響度などを中心にプライオリティ付けをするのだ。プライオリティ付けの手法もさまざま存在する。GMITS（ISO13335）に挙げられている最も詳しいやり方では、資産の脆弱性（紙の弱点、電子データとその媒体の弱点など）と脅威（自然災害・天候、事故、不正アクセス、内部犯行など）を合わせて洗い出し、縦軸＝影響度と横軸＝脆弱性×脅威というマトリクスで計算している。そこまで行かなくても、影響度を考えるだけでもプライオリティを付けるには十分だろう。
以上のように相対的なプライオリティを付ければ、例えば「顧客情報」が一番重要な情報資産である、ということがはっきりするわけだ。言うまでも無く価値が最も高いものから守るべきである。後述のリスク分析アプローチの中で、そのプライオリティを利用して分析対象範囲を決める。

ここで、リスク分析手法について概観してみよう。 GMITS（ISO13335）で定義されているリスク分析アプローチには、以下のものがある。

（１）基本アプローチというのは、リスク管理項目を列挙して、それぞれ管理されているかどうか、管理されていれば○、されていなければ×という風に、ある程度機械的にチェックするやり方だ。そのサイトが管理すべき項目には何があって、その中で何が管理されていないのか、をざっと確かめるのに適しているアプローチである。
基本アプローチを採る場合は、127個の管理すべき項目の集合体であるISO17799（BS7799）が使いやすい。
また、このアプローチは機械的にチェックするだけなので時間やコストがあまりかからない。さらに、管理項目がすなわちセキュリティ対策であるため、対応策を選択するための時間がほとんどかからないで済む、などのメリットもある。
デメリットは逆に、基本アプローチでネタ元として使うチェックリストはあくまで一般的な管理項目と管理仕様なので、対象となるシステムやサイトに特有のリスクがあると抽出しにくくなってしまうというところだ。しかし、一般的な管理項目と比べて対象サイトにどれだけ特異なポイントがあるだろうか？そう考えると、このアプローチだけでもリスクのかなりの部分を抽出できるはずだ。
（２）詳細アプローチというのは、情報資産ごとに詳しく分析する方法だ。その資産の保管形態と保管方法、作成から廃棄までのライフサイクルすべてにどのような管理方法が適用されているか、などを中心に分析する。したがって容易に想像できると思うが、作業量は膨大になってしまう。
（３）融合アプローチとは、（１）基本アプローチと（２）詳細アプローチを「融合」させたものである。まずは（１）基本アプローチと同様の手法で網羅的に対象サイトのリスクをチェックし、プライオリティが高いと判断された情報資産に対してのみ、（２）詳細アプローチを採り詳しく分析する。このあたりがやはり一番現実的なアプローチであろう。
（４）経験則アプローチとは、あまり薦めない例として掲載されているが、経験豊かなセキュリティ分析の専門家が、独自のアプローチで分析するというものだ。確かに（１）から（３）までのアプローチを採用して分析作業を数多くこなしていくと、経験則としていろいろな手順をショートカットしたり、大雑把に把握するところと詳細なところの加減をコントロールできるようになる。そうなると、融合アプローチより現実に適合していて、かつ基本アプローチ程度の作業量で分析することが可能になることもある。しかし、それに頼るのは危険も伴うことはおわかりのとおりだし、ユーザーがわとしてその専門家の経験値を測定できる尺度が無いと信用することは難しい。

以上の４つのアプローチがリスク分析の主なアプローチだ。
このうちのどの手法を採用するのか、それは予算枠や期間などを睨んで決めるしかないだろう。ちなみに一般的に詳細なアプローチでのリスク分析に要する期間は半年程度、基本アプローチでは２、３週間～3ヶ月程度というのが目安になるだろう。

さて、リスク分析作業の結果は、アプローチによってもちろん異なるが、情報資産の一覧とリスク、そして現状の管理策とリスクというような結果が出てくる。結果を集約すると、例えばスタッフひとりひとりのコンピューターの中でのデータ管理のリスクが大きい、とか、紙に印刷したデータを廃棄する決まりが無い、とかが明らかになってくる。
その結果をもとにスタンダード（ガイドライン）やプロシージャ（手順書）を作れば、リスクを低減できるはずだ。
ただしその際に、すべてのリスクをルール側で背負い込む必要はなく、例えば保険契約などでリスクヘッジしたり、リスクを生じさせている業務手順そのものを廃止してしまったり、リスク管理のアプローチにもいくつかの方法がある。もちろん手順を決めてルール化する、とか、技術的対策でまっとうにリスクを低減させる方法もあるが、セキュリティポリシーを作成するときには、そのアプローチも意識して作っていくべきである。
GMITS（ISO13335）にはそのリスク管理アプローチが以下のように定義されている。

リスク回避＝リスクのある部分を使わない、など
リスク移転＝保険など
脅威の低減＝脅威に対し防御策を講じる、運用ルールや手順を確立するなど
脆弱性の低減＝媒体や資産そのものの性質にかかわる弱さを低減させるため、別な媒体に変えるなど
生じる可能性のある影響を少なくする、および＝リスクを分離するなど
好ましくないイベントを検知し、対策を講じ、そのようなイベントから回復する＝監視、管理体制を作るなど

セキュリティポリシーとそのルール体系によってリスクを低減させる、というのは脅威の低減というものに当たるが、何もこれだけがリスク管理策ではない、ということだ。すべてをルールに組み込もう、技術的対策でまかなおうとしても無理な場合もあるので、回避や移転についても検討し、その上でセキュリティポリシーを定めるべき対象範囲を設定する。きっちり分析しておけばリソースの無駄が省ける、というわけだ。
また、現実に存在するリスクを睨んでポリシーを作成すれば、当然ながら現実と乖離しないポリシーになるはずだ。そのためにリスク分析は、どのアプローチを採るにせよ必須である。

●Security INDEXへ

★TOP INDEXへ