WEBマガジン
「リスクをどのようにして見つけますか?」
2011.10.04 株式会社オージス総研 栗田 健史
皆さんは、リスクをどのようにして見つけていますか?
と、言ってもこれでは一般的過ぎて分かりにくいので"リスク"と"見つける"をそれぞれ分けて考えて見ましょう。
先ず、 "リスク"ですが、皆さんはこの言葉をどのように説明されますか?改めて説明しようとするとなかなか説明のし難い言葉ではないでしょうか?例えば、"何か悪いことが起こりそうだ"とか"このままだとまずいことになる"とかでしょうか。リスクには純粋リスク(発生した場合に損失のみをもたらす可能性があるリスク)と投機リスク(発生した場合に損失あるいは利益をもたらす可能性があるリスク)に分類されますが、ここでは純粋リスクについて考えます。取り敢えず既知の情報を調べてみましょう。
- 予測できない危険、損害を受ける可能性【大辞林】
- ある脅威が,資産又は資産のグループのぜい(脆)弱性につけ込み,そのことによって組織に損害を与える可能性。これは,事象の発生確率と事象の結果との組合せによって測定できる。【ISO13335】
- 事象の発生確率と事象の結果の組合せ。【TR Q 0008:2003 リスクマネジメント-用語-規格において使用するための指針】
- もし発生すれば、プロジェクト目標にマイナスの影響を及ぼす、不確実な事象(event)あるいは状態(condition)。【PMBOK】
これからリスクは、
- 事象の結果によってもたらされる損害
- 事象が将来発生する現時点での可能性(現時点では発生しておらずその発生は不確実)
の組合せと言えます。
一般的には、「リスク = 発生確率 × 事象の結果(損害)」の式で表されます。
これでもまだ分かりにくいと思いますのでリスクを"見える化"してみましょう。
図 1 リスクの概念図
この筆者が考案した概念図では、"目標、あるべき姿"と"実績、現実"が現時点では乖離していないが、将来のある時点で乖離することを示しています。その乖離した状態が"事象"であり、その乖離幅(GAP)を損害として表しています。この図では""実績、現実"が徐々に"目標、あるべき姿"から乖離していますが、実際には地震災害のように急に乖離する場合もあります。
なお、現時点で"目標、あるべき姿"と"実績、現実"が乖離している場合は"問題"です。"リスク"は、将来発生する可能性のある"問題"とも言えます。"リスク"についてはイメージが高まったでしょうか。
さて、次は"見つける"です。
"見つける"と言うと、何かあるものを探すように思われそうですが、上記のとおり現在においては乖離が無い状態であり、不確実な発生確率ということになると、なかなか"見つける"のは難しそうです。
リスクマネジメントのプロセスは様々な文献で示されていますが、概ねリスク識別→リスク評価→リスク対応のプロセスになります。"見つける"プロセスは、これらの文献ではリスク(因子)の特定、リスクの識別、事象の識別などと表現されています
前回の「内部統制におけるアクセスコントロールの効率化」でも触れましたが、リスクをコントロールするには、何を対象にするのかを明確にすることが重要です。では、情報システムでリスクを考えるにはどのような対象があるのでしょうか?ここで一つの考え方としては、情報システム全体像を捉えたITガバナンスが参考になります。ITガバナンスの全体像を下図に示します。
図 2 ITガバナンスの全体像
日本ITガバナンス協会の「取締役会のためのITガバナンスの手引き第2版」のITガバナンスの重点領域、
「COBIT実践ガイドブック」のITガバナンスライフサイクルを参考に筆者が作成
この図では
- ITとビジネス戦略の整合を図る体制を構築し、プロセスと戦略を推進する計画を立て
- IT資源を活用し、
- ITとしての価値の提供(価値の最大化)、と
- リスク管理(リスクの最小化)を並行して進め、
- その成果をモニタリングし、改善していく
PDCAサイクルを示しています。
このプロセスを実現・実行するために必要なものが情報資本です。こちらのページに解説があります。 http://www.ogis-ri.co.jp/rad/r-01bic-itgc.html
情報資本には、マネジメントインフラと物理インフラがありますが、言い換えれば"プロセス"と"もの"です。これらを対象にリスクを考えていくことが分かり易いでしょう。
では、具体的にはどうすれば良いのでしょうか?
まず、 "もの"はどうでしょうか。リスクアセスメントの方法としてGMITS ( Guideline for the Management of IT Security Part 3 )では、4つのアプローチが紹介されていますが、ここでは詳細リスク分析アプローチを取り上げます。
GIMTSでは情報資産を対象にリスク因子を特定することとしています。情報資産とは主には以下のものです。
- 情報/データ(支払の詳細を含んだファイル、製品情報等)
- ハードウェア(コンピュータ、プリンタ等)
- アプリケーションを含むソフトウェア(テキスト処理プログラム、特別の目的のために開発されたプログラム等)
- 通信設備(電話、銅線、ファイバー等)
- ファームウェア(フロッピーディスク、CD-ROM、PROM 等)
- 文書(契約書等)
- 資金(ATM 等)
- 製造物
- サービス(情報サービス、計算資源等)
- サービスの信頼と信用(支払サービス等)
- 環境設備
- 要員
- 組織のイメージ
これらの情報資産を棚卸しし、個々の情報資産について、脅威と脆弱性を評価します。この方法では対象とする情報資産の量が多い場合は、分析作業は膨大になります。
一方、"プロセス"はどうでしょうか。例えば、開発プロセスではどのようなリスクがあるのでしょうか?プロセスのリスクを発見する方法は、J-SOX導入当時に一般的になったプロセスフローとリスクコントロールマトリクス(RCM)があります。例えば開発業務を可視化してフロー上にリスクのある箇所を特定し、洗い出されたリスクへの対応策を一覧化してRCMを作成します。さて、こうして書くと簡単にできそうですね?業務を可視化するのは問題なさそうですが、「フロー上にリスクのある箇所を特定する」はどうでしょうか。この部分が"リスク"を"見つける"ですが、実際にはフローに書かれていない(コントロールが存在しない)部分にリスクがあることもあり、簡単ではありません。では、どうするか?
ここで"銀の弾丸"はありません。地道に、失敗したことに対する改善などの実経験を活用することが有効です。しかし、個人の経験値だけでは情報量が少なすぎるので、有識者や先人の知恵を使うことです。具体的には有識者や専門家の意見を聞く、あるいは過去の経験・実績から作成されたチェックリストなどを使うことです。以下に参考になるものを上げておきます。
- システム管理基準【経済産業省】
- 情報セキュリティ管理基準【経済産業省】
- システム管理基準 追補版(財務報告に係るIT 統制ガイダンス)【経済産業省】
- COBIT for SOX 2nd Edition 日本語版【ITガバナンス協会】
- 金融検査マニュアル【金融庁】
また、プロセスということではプロジェクトマネジメントのプロセスでもリスク管理は重要であり、PMBOKの知識エリアの一つとして"プロジェクト・リスク・マネジメント"が取り上げられています。PMBOKのリスク特定では、専門家や経験者とのブレーンストーミング、合意形成(デルファイ法)、インタビューおよびチェックリストによる分析などをツールと技法としています。ここでは上記のチェックリスト類も参考になりますが、プロジェクトは固有の目的に対して実施されるものであり、個別のプロジェクトでヒントになるものは限られます。参考になるものとしては『ITプロジェクトの「見える化」』 (SEC BOOKS) 情報処理推進機構(IPA・SEC)を上げておきます。プロジェクトの上流・中流・下流それぞれに問題を定性的に把握するチェックシートや失敗事例と対応策、プロジェクトの状況を定量的に捉えるための測定リストが過去の経験から作成されており、有効です。実際に会社で利用する場合は、これらのチェックリストを参考に自社の経験値から独自に作成するのが良いでしょう。弊社では、過去のプロジェクトマネジメントの教訓を『リスク事例ハンドブック』として作成し、リスクの顕在化を未然に防止するために利用しています。
*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。
『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。
同一テーマ 記事一覧
「システム監査の進め方」
2017.08.28 ITガバナンス 株式会社オージス総研 栗田 健史
「内部統制におけるアクセスコントロールの効率化 その3」
2013.11.11 ITガバナンス 株式会社オージス総研 栗田 健史
「内部統制におけるアクセスコントロールの効率化 その2」
2012.09.11 ITガバナンス 株式会社オージス総研 栗田 健史
「内部統制におけるアクセスコントロールの効率化」
2010.10.03 ITガバナンス 株式会社オージス総研 栗田 健史