履き違えてはいけない。トーマツ方式のリスクアセスメント。トーマツに迷惑を掛けてしまう。多分、方式の問題でなくて担当コンサルの問題でしょう。リスクアセスメントの負担を感じさせないように超単純化したサンプルを見せて説明を繰り返したのではないか。
世の中にそう都合よくマジックがある訳ではない。ラフにやればラフな結果が得られるだけですが、人間都合よく考えたいものです。自分の頭の仲に勝手にマジックを作っているんでしょうか。
トーマツ方式と言って済ませている審査員がいる。有効なリスクアセスメントに至っていなくても、トーマツ方式は一つの考え方なのだと嘯いて何の検証も無く通り過ぎていく。甘いものだ。
.*.
Ａ部門がある。Ａ部門と言うプロセスがある。丼の資産（a1,a2,a3,...)とレベル(A1)、丼の脆弱性(v1,v2,v3,...)とレベル(V1)、丼のリスク(r1,r2,r3,...)とレベル(R1)。R1の値が大きければ何か手を打ってV1を下げる。管理策と言う奴だ。少し気を利かせれば、これをＣＩＡ側面ごとにやるかな。評価作業の一環として、脆弱性を理解するための資産の状況を確認するが、この場合はあくまで丼（ドンブリ）だ。部内に有るか、電子化されているか、くらいでしょう。
誤用の一番の肝は、プロセスと資産と一体化。本来全く別のものを1つのものとして扱うこと。プロセスアプローチは本来資産洗い出しの方法論に過ぎない。
1部門に1人しかいなくて毎日同じような単純作業なら、1部門1プロセスでも何かが見えるだろうが、世間の実態は結構なことに複雑だ。プロセスをサブ・プロセスに分解して見て行くしかない。
では、何処まで細分化を繰り返すか。ＩＳＭＳは単純というか親切と言うか、そこで悩む必要は無い。資産・資産価値と「管理策」の関連付けが明確になるところまで。勿論、その前提として、資産とリスクの関係を明確にするのが詳細分析。資産がグルーピングされることは構わない。
.*.
ベースライン方式の場合は必ずしも資産とリスクの関係を明確にしない。一括方式です。どう括るかが味噌だね。取り合えずカテゴリーとしておきます。属性区分でも構わない。管理策はカテゴリーあるいは属性に対して打つことになります。複数のカテゴリーあるいは属性を持つ場合はそれぞれの管理策が打たれることになります。簡単ですね。欠点は個別のリスクが理解されないままに進むこと。今一つの欠点は、カテゴリー内の最大リスクを想定すると言うこと。抜け漏れの懸念があるにもかかわらず全体としては過剰防衛になります。
もしプロセスに名前をつけることができるなら、プロセスという属性で一括りに資産と管理策を設定できる可能性があります。
.*.
初めて取り組む組織では、ベースライン方式でスタートします。
- ラフなプロセス
- ラフな資産・資産価値
- ラフな資産属性・カテゴリー
- カテゴリー別・属性別の管理策設定。（既に組織内あるいは世間の常識として実施されている内容です）
次に重要資産に関連するプロセスに注目して、
- プロセスの分解
- 資産・資産価値
- 資産属性・カテゴリーの精査あるいは細分化
- 主要な脅威と脆弱性の理解
- 詳細カテゴリー、属性区分に応じた管理策の設定。
初期フェーズはここまで。ＩＳＭＳ認証取得準備段階の初期フェーズ。でも、このまま取得に入ってしまう組織もある。悲惨な例。認証を取って毎年審査でフォローされるようになると殆ど手直しは出来ない。一旦認証返上の覚悟でもなければ現状維持が関の山。
.*.
詳細リスク分析の導入は必須要件。推進スキームの中にこの手法を取り込んでおかないと必ず行き詰る。
詳細分析と言ってもやることは単純。重要な資産については、個別に脅威・脆弱性を洗い、リスクレベルを評価する。脆弱性を軽減する施策を導入する。必要ならリスク対応計画とする。（リスク対応計画はベースライン方式でも必要）
.*.
話をトーマツ方式（の誤用）に戻すと、詳細分析との連携が無いままにしておくと、ＩＳＭＳのレベルを上げていく時に、リスクアセスメントの方法論が実質的に全く役立たずになり、二枚舌ＩＳＭＳが出来上がってしまう。リスクアセスメントは無意味で、勝手に選択された施策だけを垂れ流す構図です。この施策は世間で問題になったような事例から判断して後追いで導入するもの。完全な後手管理です。
正しいトーマツ方式を導入するにはトーマツの本物のコンサルから時間を掛けて聞くべきです。
上滑りの見よう見まねでは返ってリスキーです。
.*.
