
資産の評価、脅威と脆弱性の評価
今回は、資産の評価、脅威と脆弱性の評価をポイントごとに解説していきます。
資産の評価
脅威の評価
脆弱性の評価
資産の価値を評価する指標として、最も望ましいのが金額です。資産価値を金額で表現することで、リスク対策の費用対効果を明示することができるようになります。
GMITS(ISO/IEC 13335-3:1998 Annex E)の中では、情報資産の価値を以下のように数値化することを例示しています。
(1) 情報資産の価値の数値化
(a) 現物または導入予定の物理的資産
・交換または再購入のコストに基づいて評価(量的測定)する
(b) ソフトウエア資産
・購入または再構築のコストを確認する
(c) データ資産
・データ所有者にインタビューすることによって入手する
(d) 情報資産評価指針に基づいて評価を行う
(以下省略)
ただし、情報資産そのものを金額で数値化する手法は確立しておらず、現在、すべての情報資産を数値化するリスク評価手法は少ないと思います。
ハードウェアやソフトウェアそのものについては、上記のように金額で数値化することは可能ですが、書類や電子データを資産価値として金額で表現するには、評価する担当者の立場により、見解は大きく変わるでしょう。また情報資産のライフサイクルも多様であるため、客観的な数値化はまだ難しいと思います。
私どもでは、脅威が発生した場合のインパクトの大きさで、資産価値を評価する方法を推奨しています。機密性、完全性、可用性の3つの観点から、脅威が発生した場合の影響度で、点数評価する考え方です。
リスク評価手法により、資産価値の評価の方法は変わるが、厳密に定量化しても、数値遊びになってしまい、膨大な時間とコストを掛けた割には、客観的な妥当性の低い結果が出てしまうケースがよく起こります。また、職場環境は逐次変化し、業務サービスの追加や変更、情報システムの変更が起こることで、リスク評価のやり直しという可能性も大いにあります。そのため、リスク評価は、ある程度短期間で終わらすことができ、数値遊びにならずに、リスク対策の優先順位が経営者に分かり易い手法を選択することがよいでしょう。
情報セキュリティ上、対象となるリスクは、純粋リスクのみとなります。そのため、脅威として識別しなければならないものは、資産に対して負の影響が起こる物事や事象です。
GMITS(ISO/IEC 13335-3:1998 Annex C)では、以下のような脅威を例示しています。
| 人為的 |
故意的 |
D:deliberate |
| 偶発的 |
A:accidental |
| 環境的 |
環境的 |
E:emvironmental |
脅威 |
D |
A |
E |
| 地震 |
|
|
○ |
| 台風 |
|
|
○ |
| 落雷 |
|
|
○ |
| 火事 |
○ |
○ |
|
| 故意の損害 |
○ |
|
|
| 停電 |
|
○ |
|
| ハードウェアの故障 |
|
○ |
|
| 盗難 |
○ |
|
|
| 捜査員のエラー |
○ |
○ |
|
| 保守のエラー |
○ |
○ |
|
| 通信への侵入 |
○ |
|
|
| 以下、省略 |
|
|
|
(参考ISO/IEC
TR 13335 GMITS )
脅威の評価が完了したら、次に、脆弱性の識別を行います。情報資産へ対して該当する脅威が識別できましたら、その脅威に対する現状の管理体制を評価します。
GMITS(ISO/IEC 13335-3:1998 Annex C)の中では、脆弱性を以下のように例示しています。
1.環境および基礎構造
・建物,ドアおよび窓の物理的保護の欠如
・建物,部屋への物理的アクセス管理の不適当または不注意な使用
・不安定な電力配線網
・洪水の影響を受けやすい地域への配置
2.ハードウェア
・定期的な交換計画の欠如
・電圧,温度変化,湿気,ホコリ,汚れに対する影響の受けやすさ
・記憶媒体の不十分な保守/不適当な設置
・有効な構成変更管理の欠如
3.ソフトウェア
・開発者のための不明確または不完全な仕様書
・ソフトウェアのテストをしない、または不十分なソフトウェアのテスト
・アクセス権の誤った割り当て
・管理されていないソフトウェアのダウンロードおよび使用
・バックアップコピーの欠如
・適切に削除されていない記憶媒体の処理または再利用
4.通信
・保護されていない通信回線
・送信元および受信者の識別と認証の欠如
・平文でのパスワードの転送
・保護されない公衆回線への接続
5.文書
・保護されない補完
・廃棄時の注意欠如
・管理されないコピー
6.人事
・外部または清掃スタッフによる作業時の監督不在
・不十分なセキュリティ訓練
・セキュリティ意識の欠如
・不適切な採用手続
7.一般に適用される脆弱性
・単一の障害点特性
・不適切なサービス保守の対応
|