脅威と脆弱性を分離して理解できるかどうかは案外難しいものだそうです。括ってリスクと表現しても極めて自然に思える。わざわざ分離する意味があるんだろうか。
あるオッサン先生は言ってくれた。自分でコントロールできないものが脅威だと。本当かな? 天気は今の技術ではコントロールできないから脅威。でも、その内、コントロールできるようになれば脆弱性なのか。
コントロールできる領域が広がれば、脅威は萎縮していくのは当然のことかも知れない。管理策のスパンが広がるから、脆弱性の付け入る隙が出てくる。
先ず、情報資産を取り上げて、この資産に対する脅威またはリスクを並べてみる。
実施中の管理策、今後可能な管理策、他社等で方法論として確立している管理策を並べる。方法論が確立していない管理策・アイデアを並べる。
＜脅威・リスク＞＜既存の管理策＞＜予定の管理策＞＜未来の管理策＞
脅威・リスクから防御するためにできることは、
- 既存の管理策の効果を上げる。
- 予定の管理策を実施に移す。
- 未来の管理策を引き寄せる。
.*.
話を戻して。では、「脅威・リスクの洗い出し」はどのようにやりますか？。方法論としては地道にやるしかありません。以下の項目の一部または全て含むリスクを洗い出し、データベース化し、メンテナンスを定期的に行うことが求められます。
- 情報の保管状況から想定できるリスク
- 情報の移動方法から想定できるリスク
- 情報の利用方法から想定できるリスク
- 管理者・利用者等のヒューマンエラーに関連するリスク
- 疲労・風化・拡散に伴うエラー
- 技術革新・制度改革・イノベーションに伴うリスク
以上を手掛かりに、機密性リスク・完全性リスク・可用性リスクの全ての側面について、脅威・リスクを洗い出し、脅威の発生頻度を評価することが求められます。
＜１つの資産＞＜3つの側面＞＜6つの脅威・リスク領域＞＜発生頻度評価＞：既にケーススタディのツリーは膨大な量になりますし、意味も分からなくなります。ここでは網羅的にやるよりも主要なものについて評価することが大事です。可能なら3つの各側面で最大となるもの着目します。
ISMSは継続的な活動ですから、一番目立つものから順番に押さえ込んで行く考え方で十分ですし重要です。最初から網羅的でなくても構わないと理解すること、具体的に歩を進めることが出来ます。漸進ですね。
.*.
