0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【書評】Information Risk Management, 2nd Edition

0
Posted at

はじめに

「情報リスク管理」という言葉は耳慣れているようで、実際に体系的に学ぼうとすると意外と整理された資料が少ないものです。David Sutton著の『Information Risk Management, 2nd Edition』(BCS発行)は、情報リスク管理のプロセスを一冊でカバーした実践的な書籍です。ISO/IEC 27001や27005に準拠した構成になっており、セキュリティ設計や組織のガバナンスに携わるエンジニアにとって参考になる内容が多く含まれています。

本記事では、この書籍の全体像を章ごとに整理しつつ、エンジニア視点で特に重要なポイントをまとめます。


書籍の全体像

本書は以下の構成になっています。

  • 第1章:情報リスク管理の必要性
  • 第2章:情報セキュリティの基礎の見直し
  • 第3章:情報リスク管理プログラム
  • 第4章:リスク特定
  • 第5章:脅威と脆弱性の評価
  • 第6章:リスク分析とリスク評価
  • 第7章:リスク治療
  • 第8章:リスク報告と提示
  • 第9章:コミュニケーション、協議、監視およびレビュー
  • 第10章:NCSC認定プロフェッショナル制度
  • 第11章:英国政府のセキュリティ関連文書
  • 付録A〜I:分類・脅威・脆弱性・テンプレートなど

第1章:情報リスク管理の必要性

「データ」と「情報」の違い

本書はまず、データと情報の概念の違いから始まります。気象データ単体は単なる数値の羅列ですが、複数地点のデータを時系列で組み合わせることで「天気予報」という情報になります。このように、データはコンテキストを持つことで情報になるという整理はシンプルですが重要です。

本書では両者を一体として扱い、どちらも保護の対象として位置づけています。

情報のライフサイクル

情報は「作成→加工→共有→アーカイブ→廃棄」という流れを経ます。このライフサイクルの各段階で、情報が意図せず失われたり改ざんされたりしないよう保護する必要があります。これが情報リスク管理の出発点です。

IoT・AI・リモートワークというホットトピック

初版発行以降に重要性が増したテーマとして、以下の3つが取り上げられています。

IoT(モノのインターネット):スマートデバイスはデフォルト設定のままにされがちで、セキュリティ上の弱点になりやすい点が指摘されています。個人レベルではプライバシーの問題、医療や重要インフラではより深刻なリスクにつながります。

AI:機密情報を扱うAIシステムにおいて、CIA(機密性・完全性・可用性)の観点でどのようなリスクが生じるかが検討されています。自動運転車や医療診断AIを例に、情報の正確性や完全性の欠如が命に関わりうることが示されています。

リモートワーク:コロナ禍を機に急拡大したリモートワーク環境では、個人デバイスの管理や安全な通信インフラの確保、物理的な文書の取り扱いなど、新たな情報リスクが生じています。

情報リスク管理の利点

情報リスク管理を実践することで、組織には以下のメリットがあります。

  • 情報資産とその価値に対する社内認識の向上
  • 全体的なリスクレベルの低減
  • 保険料の削減につながる可能性
  • 混乱イベントへの対応・回復力の強化
  • ISO/IEC 27001や ISO 22301の認証取得への道筋

能力成熟度モデル(CMM)

情報リスク管理の成熟度を測る指標として、5段階のCMMが紹介されています。

レベル 説明
1:初期 場当たり的、文書化なし
2:繰り返し可能 一定の再現性あり
3:定義 標準化・文書化されている
4:管理 メトリクスによる管理
5:最適化 継続的な改善が行われている

第2章:情報セキュリティの基礎の見直し

CIAトライアドとその周辺概念

情報セキュリティの三本柱はCIA(Confidentiality・Integrity・Availability)ですが、本書はそこに以下を加えた包括的な枠組みを示しています。

  • 機密性(Confidentiality):許可された者のみがアクセスできること(ISO/IEC 27000:2018)
  • 完全性(Integrity):情報の正確性と完全性を保つこと
  • 可用性(Availability):権限のある者が必要なときにアクセスできること
  • 否認不能性(Non-repudiation):ある行為を実行したことを証明できること
  • 認証(Authentication):主体の特性が正しいことを保証すること
  • 説明責任(Accountability):行動と決定を特定の主体に帰属させること
  • 信頼性(Reliability):意図した動作と結果の一貫性

情報分類スキーム

情報は分類することで、取り扱い方法・保管方法・廃棄方法を標準化できます。英国政府の分類例は以下の通りです。

分類 説明
TOP SECRET(最高機密) 漏洩で人命損失や国家安全への重大影響
SECRET(機密) 軍事・外交・捜査に深刻な損害をもたらす可能性
OFFICIAL(公的情報) 通常の業務情報。紛失すると損害は生じうる

民間組織向けには「極秘」「機密」「個人」「社内限定」「公開」などの分類が一般的です。

また、CERTコミュニティで広く使われる**トラフィックライトプロトコル(TLP)**も紹介されています。RED・AMBER・GREEN・WHITEの4段階で情報共有の範囲を定義するシンプルなスキームです。

PDCAサイクル

情報リスク管理のフレームワークとして、Plan-Do-Check-Act(PDCA)サイクルが有効に機能します。計画→実装→モニタリング→改善という継続的なサイクルは、ISMS(情報セキュリティ管理システム)の運用において基本的な考え方です。


第3章:情報リスク管理プログラム

プログラムの構成要素

情報リスク管理は単発のプロジェクトではなく、継続的なプログラムとして運用することが推奨されています。プログラムには以下の要素が含まれます。

  • 目標・範囲・目的とポリシー
  • 役割と責任(権限・所有権・説明責任)
  • ガバナンスプロセス
  • 内部基準(リスク基準・報告・文書化)
  • 財務上の取り決め
  • トレーニングと意識向上
  • 監視とレビュー

ガバナンスの三層構造

リスク管理のガバナンスは、以下の三層で構成されます。

  1. 戦略層:取締役会レベルの責任と意思決定
  2. 戦術層:リスクインテリジェンスやポリシー管理
  3. 運用層:脅威・脆弱性・影響の特定と評価、リスク登録

リスク処理の4オプション

戦略レベルのリスク処理には以下の4択があります。

オプション 説明
回避・終了 リスクのある活動をやめる
軽減・修正 影響度や発生確率を下げる
移転・共有 保険やアウトソーシングで第三者に移す
受容・許容 リスクを認識した上で受け入れる

重要なのは、リスクを無視することは選択肢ではないという点です。受容する場合でも必ず記録し、継続的に監視する必要があります。


第4章:リスク特定

リスクの構造

リスクは「影響度 × 発生可能性」で表現されますが、その背後には以下の関係があります。

脅威 → 脆弱性を悪用 → 情報資産に影響

同一の脆弱性を複数の脅威が悪用することもあれば、一つの脅威が複数の脆弱性を同時に攻撃することもあります。さらに、「結果の連鎖(chain of consequences)」として、ある資産への影響が別の資産への脅威となるドミノ効果も考慮する必要があります。

影響の種類

情報資産に損害が生じた場合、以下のような影響が発生します。

  • 運用上の影響:業務停止、生産性損失、顧客流出
  • 財務上の影響:収益損失、保険料値上がり、株価下落
  • 法的・規制上の影響:罰金、業界規制当局からの警告
  • 評判への影響:メディア報道、ブランド毀損
  • スタッフ・社会への影響:健康リスク、士気低下

定性的・定量的・半定量的評価

評価手法には3種類あります。

  • 定性的:「低・中・高」のような主観的な表現。簡便だが曖昧
  • 定量的:金額・頻度などの数値。精度は高いが時間がかかる
  • 半定量的:数値範囲に定性的ラベルを付与(例:低 = 25,000£未満)。実用的でバランスが良い

本書は半定量的アプローチを推奨しています。取締役会が理解できる言葉で表現しつつ、一定の客観性を確保できるためです。


第5章:脅威と脆弱性の評価

主な脅威カテゴリ

脅威 具体例
悪意のある侵入・ハッキング DoS攻撃、不正アクセス、資格情報窃取
環境の脅威・危険 自然災害、停電、パンデミック
エラーと障害 ソフトウェアバグ、ユーザーエラー
ソーシャルエンジニアリング フィッシング、なりすまし
誤用・乱用 内部不正、権限昇格
物理的脅威 機器盗難、不正侵入
マルウェア ウイルス、ランサムウェア、スパイウェア

内部からの攻撃は、すでにファイアウォールの内側にいて権限を持っている分、外部攻撃より成功確率が高い点に注意が必要です。

主な脆弱性カテゴリ

  • アクセス制御の失敗:ポリシー不備、退職者の権限未削除、デフォルトパスワードの継続使用
  • システムの調達・開発・保守の不備:仕様不明確、テスト不十分、未承認ソフトウェア
  • 物理的・環境的障害:入退室管理の不備、洪水リスクのある立地
  • 通信・運用管理の失敗:職務分離の欠如、パッチ未適用、BYOD管理の不備
  • 人的セキュリティの失敗:トレーニング不足、監視機構の欠如

既存コントロールの確認

新たなコントロールを検討する前に、既存コントロールの棚卸しが必要です。重複を避けると同時に、機能していないコントロールを除去・置換するためです。コントロールは以下の3層で分類できます。

  • 戦略的:回避・移転・軽減・受容
  • 戦術的:検知・予防・指示・是正
  • 運用的:物理的・手続き的・技術的

第6章:リスク分析とリスク評価

リスクマトリックス

影響度と発生可能性をそれぞれ5段階で評価し、5×5のマトリックスにプロットすることでリスクを視覚化します。

発生可能性
  高 | 中 高 高 危 危
  中 | 低 中 高 高 危
  低 | 低 低 中 高 高
 極低 | 低 低 低 中 高
極々低| 低 低 低 低 中
      ――――――――――――――
       極小 小 中 大 極大   影響度

マトリックス上のリスクは優先度順に対応が求められます。特に右上に位置するリスク(影響・確率ともに高い)は緊急対応が必要です。

リスク登録簿(Risk Register)

特定・評価したリスクはリスク登録簿に一元管理します。登録すべき主な項目は以下の通りです。

  • リスク参照番号
  • 情報資産名と資産オーナー
  • リスクの説明
  • 影響度・発生可能性・リスクレベル
  • 推奨コントロールと担当者
  • 実施期限と次回レビュー日

リスク登録簿自体が機密情報となるため、アクセス制御を適切に設定する必要があります。


第7章:リスク治療

コントロールの体系

リスク治療のコントロールは以下の3層・複数タイプで体系化されています。

戦略的コントロール(方向性を決める)

  • 回避・終了 / 移転・共有 / 軽減・修正 / 受容・許容

戦術的コントロール(手段を決める)

  • 検知的(何かが起きていることを検知)
  • 予防的(インシデント発生を防ぐ)
  • 指示的(ポリシー・手順による指示)
  • 是正的(発生後に状態を修正する)

運用的コントロール(実装手段)

  • 物理的:CCTV、電子ドアロック
  • 手続き的:クリアデスクポリシー、変更管理手順
  • 技術的:ファイアウォール、ウイルス対策、VLAN分離

代表的なコントロール基準

本書では3つの主要なフレームワークが参照されています。

CIS Controls v8(18のコントロール):企業資産インベントリ、アクセス制御管理、継続的な脆弱性管理、インシデント対応管理など

ISO/IEC 27001:2017:A.5〜A.18の14カテゴリで114の運用レベルコントロールを定義

NIST SP 800-53 Rev.5:20カテゴリで283のコントロールを定義。ISO/IEC 27001との対応表も提供


第8章:リスク報告と提示

ビジネスケースの重要性

リスク対応に必要な投資を経営陣から承認してもらうには、情報セキュリティの技術的な話ではなく、ビジネスリスクとして表現したビジネスケースの提示が不可欠です。

効果的なビジネスケースには以下を含めます。

  • エグゼクティブサマリー(1ページ程度)
  • 実施することで得られるメリット
  • 主なリスクと潜在的な影響の概要
  • 提案ソリューションとそのコスト(3〜5年間の資本・運用支出)
  • 実装計画とマイルストーン

経営幹部が情報セキュリティの技術を理解できなくても、ビジネスリスクは必ず理解できます。その視点で語ることが重要です。

事業継続管理(BCM)とDR

リスク治療の一環として事業継続管理(BCM)が必要になる場合があります。BCMには以下が含まれます。

計画 目的
インシデント管理計画(IM) 発生直後の初動対応
事業継続計画(BCP) 正常運営への回復プロセス
災害復旧計画(DR) ITシステムの機能復旧
業務再開計画(BR) インシデント前の状態への回帰

DR環境のスタンバイ方式は、コストと復旧時間のトレードオフで選択します。

方式 復旧速度 コスト
コールドスタンバイ 遅い(数時間〜) 安い
ウォームスタンバイ 中程度 中程度
ホットスタンバイ/高可用性 即時 高い

高可用性システムは「9の数」で表され、5 nines(99.999%)は年間約5分のダウンタイムに相当します。


全体を通じた設計上の示唆

本書を読んで、エンジニアリングの文脈で特に参考になった視点を整理します。

1. リスクは「影響 × 確率」だが、連鎖を忘れない

単体の情報資産に対するリスクだけを考えるのでは不十分です。ある資産の損害が別の資産への脅威になるという結果の連鎖(根本原因分析)は、システム設計の依存関係整理にも通じます。

2. コントロールは三層で考える

戦略・戦術・運用の三層でコントロールを設計することで、抜け漏れが減ります。例えば「認証強化」という施策一つとっても、ポリシー(指示的/手続き的)、技術実装(技術的/予防的)、監視(検知的/技術的)の組み合わせで成り立ちます。

3. 半定量的評価を活用する

「高・中・低」という定性評価だけでは議論が発散します。「低 = 25万円未満」のように金額レンジを対応させることで、経営層との議論が具体化します。

4. リスク登録簿は生きたドキュメントとして運用する

リスク登録簿を作って終わりにしてはいけません。担当者・期限・レビュー日を明記し、定期的に更新し続けることで初めて機能します。また、登録簿自体の機密管理も必要です。

5. 経営陣への報告は「ビジネスリスク」の言葉で

技術的な詳細ではなく、「このリスクが現実化した場合の損失は○○万円、対策コストは△△万円」という形で表現することが、承認を得るための鍵です。


おわりに

本書は英国のセキュリティ実務文脈を背景としているため、NCSCや英国政府のフレームワークへの言及が多いですが、ISO/IEC 27001・27005・31000を軸とした内容はグローバルに適用可能です。

情報リスク管理を「ITの話」として閉じてしまわず、組織全体のビジネスリスク管理の一部として位置づける視点が本書の最大のメッセージだと感じました。セキュリティエンジニアだけでなく、アーキテクトや技術リードにとっても、組織のリスク管理に関わる場面で参照できる一冊です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?