CBK#03 情報セキュリティ管理 (Information Security Management)
- CBK#03 情報セキュリティ管理 (Information Security Management)
- 1.1. セキュリティの基本原則 (Fundamental Principles of Security)
- 1.1.1. セキュリティ目標 (Security objectives)
- 機密性(Confidentiality):
- 完全性(Integrity):
- 可用性(Availability):
- 1.1.2. 定義 (Definitions)
- 脆弱性 (Vulnerability):
- 脅威 (Threat):
- リスク(Risk):
- 露出 (Exposure):
- 残存リスク
- 対策 (Countermeasure) / 予防策 (Safeguard):
- トップダウンアプローチ (Top-down approach):
- ボトムアップアプローチ (Bottom-up approach):
- 運用上のゴール (Operational goals):
- 戦術上のゴール (Tactical goals):
- 戦略上のゴール (Strategic goals):
- リスク管理 (Risk Management):
- 1.2. リスク分析 (Risk Analysis)
- 3つの主要なゴールがある。
- リスクには潜在的な損害が存在する。
- 遅効型の損害 (Delayed loss):
- リスク分析のステップ
- 1.2.1. 定量的アプローチ (Quantitative Approach)
- リスクの計算 (Calculating risks)
- (強み)
- (弱み)
- 1.2.2. 定質的アプローチ (Qualitative Approach)
- シナリオを作成する際の手順:
- (強み)
- (弱み)
- 1.2.3. デルファイ法 (Delphi Technique)
- 1.2.4. 対策とリスクの計算 (Calculating countermeasures and risk)
- 1.2.5. リスクの対処 (Handling Risk)
- 1.3. セキュリティプログラム (Security Program)
- 1.3.1 セキュリティポリシー(Security Policy)
- 組織のセキュリティポリシー(Organizational security policy):
- 特定の問題のポリシー(Issue-specific policies):
- 特定のシステムのポリシー(System-specific policy):
- 1.3.2. スタンダード (Standards): ← 標準
- 1.3.3. プロシージャ (Procedure): ← 手順
- 1.3.5. ガイドライン (Guidelines): ← 推奨行為
- 1.3.4. ベースライン (Baselines): ← 基本線
- 1.4. 情報の分類
- 1.5. 組織内での役割と責任 (Responsibility to consider include):
- 経営幹部 (Executive Management):
- オーナー (Owner)
- データ・オーナー (Data Owner):
- 情報セキュリティ専門家 (Information Security professional):
- データ/システム管理者 (Data/System Custodian):
- ユーザ(User)
- 情報システム監査員 (Information System Auditor):
- 1.6. 製品/システムの評価基準 (Product/System Evaluation Criteria)
- TCSEC(Trusted Computer System Evaluation Criteria):
- ITSEC(Information Technology Evaluation Criteria):
- Common Criteria(情報セキュリティ国際評価基準):
- ISO17799
- BS7799-2
- 1.7. 人事セキュリティ (Personal Security)
- 1.1. セキュリティの基本原則 (Fundamental Principles of Security)
CBK#03 情報セキュリティ管理 (Information Security Management)
1.1. セキュリティの基本原則 (Fundamental Principles of Security)
1.1.1. セキュリティ目標 (Security objectives)
機密性(Confidentiality):
└ 必要なレベルの機密性を実現する能力を提供する。
完全性(Integrity):
└ 情報とシステムの正確性と信頼性が提供され、許可されていないデータの変更が防止されているときに保全性が守られていると言える。
可用性(Availability):
└ サービスや生産の中断を防ぐ。
※C.I.Aのバランスが重要
1.1.2. 定義 (Definitions)
脆弱性 (Vulnerability):
└ コンピュータやネットワークなどの情報システムにおいて、第三者が保安上の脅威となる行為(システムの乗っ取りや機密情報の漏洩など)に利用できる可能性のあるシステム上の欠陥や仕様上の問題点。
脅威 (Threat):
└ 情報やシステムにとっての潜在的な危険。
リスク(Risk):
└ 脆弱性を突いた脅威の可能性。/望ましくないイベントが発生する可能性。
露出 (Exposure):
└ 脅威による、損害の危険性にさらされること。
残存リスク
└ 残存する一部のリスク。
対策 (Countermeasure) / 予防策 (Safeguard):
└ 潜在的なリスクを軽減する。
トップダウンアプローチ (Top-down approach):
└ 開始、サポート、指揮がトップマネジメントから中間マネジメントを通じスタッフメンバーに進む。
ボトムアップアプローチ (Bottom-up approach):
└ セキュリティプログラムが、適切なマネジメントのサポートや指揮なしにITスタッフによって開発される。
運用上のゴール (Operational goals):
└ 日々のゴール
戦術上のゴール (Tactical goals):
└ 中期のゴール
戦略上のゴール (Strategic goals):
└ 長期のゴール
リスク管理 (Risk Management):
└ リスク(脅威と脆弱性)を特定して評価し、受け入れられるレベルまで軽減した上で
そのリスクレベルを維持するために適切なメカニズムを実行するプロセス。
• 総合リスク=脅威、脆弱性、資産価値
• 軽減管理のコンセプト:総合リスク-対策=残存リスク
1.2. リスク分析 (Risk Analysis)
セキュリティ予防策を正当化するためにリスクを特定し可能性のある損害を見積もる手法。
3つの主要なゴールがある。
├ リスクを特定する。
├ 潜在的な脅威の影響を計る。
└ リスクの影響と対策のコストの経済的バランスを提供する。
リスクには潜在的な損害が存在する。
└ 企業は実際に脆弱性を突かれた場合に何らかの損害を受けるだろう。
遅効型の損害 (Delayed loss):
└ リスクが最初に起こった後に企業に悪い影響がある。
リスク分析のステップ
├ 情報と資産の価額を定める。
├ リスク毎に潜在的な損失を見積もる。
├ 脅威分析を行う
├ リスク毎の全体の潜在的な損失を導き出す
├ それぞれのリスクに対する。対策を選択する。
└リスクの軽減, 譲渡, 受け入れをする。
1.2.1. 定量的アプローチ (Quantitative Approach)
├ 生じる損害と対策のコストに実際の数字を当てはめる。
├ 脅威とリスクの可能性を決めるときに明確なパーセンテージを定める。
└ 質的なアイテムを定量化しようとする手法であるため、純粋に量的なリスク分析は不可能である。
リスクの計算 (Calculating risks)
├ 露出要素 (EF: Exposure Factor) = 特定の脅威によって起こる資産損失のパーセンテージ
├ 単一損失予測 (SLE: Single Loss Expectancy) = 資産価値×露出要素(FE)
├ 年次発生率 (ARO: Annualized Rate of Occurrence) = 1年間に脅威が起こる頻度の推定値
└ 年次損失予測 (ALE: Annualized Loss Expectancy) = 単一損失予測(SLE)×年次発生(ARO)
(強み)
・財務上の費用を明らかにする。
・特定データの運席をより簡明にする。
・分析と計算の自動化
・明確な数量的な結果によりマネージメントへの説明が簡単
(弱み)
・多くの複雑な計算が必要
・多くの時間と労力が必要
・多くの投入データが必要
・いくつかの前提条件が必要
1.2.2. 定質的アプローチ (Qualitative Approach)
リスクの可能性の様々なシナリオを一通り見て、脅威の深刻度と資産の重要性にランクを付ける。
シナリオを作成する際の手順:
├ シナリオは主要なそれぞれの脅威を扱う。
├ シナリオはビジネスユニットマネジャーによって現実性のチェックをされる。
├ RAチームはそれぞれの脅威に対して様々な防御策を推薦する。
├ RAチームは脅威, 資産, 防御策を使用してそれぞれの最終的なシナリオを作成する。
└ チームは成果をマネジメントに提出する。
(強み)
・複雑な計算を必要としない。
・時間と労力が少なくて済む
・使用するデータ量が少なくて済む。
(弱み)
・費用を明確に出来ない。
・質的分析は簡明でない。
1.2.3. デルファイ法 (Delphi Technique)
グループ意思決定の手法でグループのメンバーのそれぞれが、特定のリスクの結果について率直な意見を言うことを保証する。
1.2.4. 対策とリスクの計算 (Calculating countermeasures and risk)
├ 企業にとっての防御策の価値
= (防御策導入前のALE) - (防御策導入後のALE) - (防御策の年間費用)
├ 総リスク = 脅威×脆弱性×資産価値
└ 残余リスク = (脅威×脆弱性×資産価値) * コントロールギャップ
1.2.5. リスクの対処 (Handling Risk)
├ リスク移転 (Transfer risk) ⇒ 保険の購入
├ リスク軽減 (Reduce risk) ⇒ 対策の導入(Implements countermeasures)
├ リスク拒否 (Rejecting risk) ⇒ リスクを拒否もしくは無視する。
└ リスク受入れ (Accept the risk) ⇒ 企業がどのレベルのリスクの元にあるか、また可能性のある損害のコストについて理解し、それと共存して行くことに決める。
1.3. セキュリティプログラム (Security Program)
ポリシーのカテゴリー(Categories of policy):
├ 規制 (Regulatory)
├ 勧告 (Advisory)
└ 情報提供 (Informative)
1.3.1 セキュリティポリシー(Security Policy)
├ シニアマネジメントが作成する。
└ 経営者の目的と目標を文章化し、伝達する。
├ 組織にとって価値があると見なされる資産および基本原則を明確にする。
├ 対象範囲、機能および組織の目的と目標を明確にする。
├ 個人の責任(説明責任)を明らかにする。
├ 全体的な声明で、組織内においてセキュリティがどのような役割をするかを定める。
└ 一般的な形式で多くの事項についてカバーするために広く外観的な言葉で書かれている。
組織のセキュリティポリシー(Organizational security policy):
└ 組織内全てのセキュリティ活動の範囲と方向を示す。
特定の問題のポリシー(Issue-specific policies):
└ 包括的な枠組みを構築し、全ての従業員がセキュリティ問題にどのように従うかについて理解するために、マネジメントがより詳細な説明と注意が必要だと感じる特定のセキュリティ問題を扱う。
特定のシステムのポリシー(System-specific policy):
└ 実際のコンピュータ, ネットワーク, アプリケーション, データに近いマネジメントの意思を示す。
1.3.2. スタンダード (Standards): ← 標準
├ ハードウェアとソフトウェア製品がどのように使用されるかを定める。
└ 特定の技術、アプリケーション、パラメータ、手順が組織全体で決まった方式で実行されるようにする方法を提供する。こうしたルールは通常企業内で強制される。
1.3.3. プロシージャ (Procedure): ← 手順
├ あるタスクを遂行するためのステップバイステップのアクションである。
└ ポリシーチェインの最も低いレベルとみなされる。
1.3.5. ガイドライン (Guidelines): ← 推奨行為
└ 特定のスタンダードが当てはまらない場合に、ユーザ、IT スタッフ、オペレーションスタッフ、その他に対する推奨されたアクションおよび運用上のガイドとなる。
1.3.4. ベースライン (Baselines): ← 基本線
└ 組織全体に必要なセキュリティの最低限のレベルを提供する。
1.4. 情報の分類
目的:
├ 情報資産を適切なレベルで保護できるようにする。
├ セキュリティを類別し、セキュリティ保護の必要性と優先度を明らかにする。
├ 不正な情報変更のリスクを最小限に抑える。
├ 不正な情報開示を防止する。
├ 競争力を維持する。
├ 合法的戦略を保護する。
└ プライバシー方法、規制、業界標準に準拠する。
1.4.1. データの分類 (Data Classification)
└ データ分類の主要な目的は、それぞれのタイプの情報に必要なレベルの機密性、完全性、可用性を示すことであり、それによりデータが最も効率的に保護される。
一般的な分類レベル(高レベルから順に):
商業ビジネス(Commercial business)
├ 秘密(Confidential)
├ プライベート(Private)
├ 取り扱い注意(Sensitive)
└ 公開(Public)
軍(Military)
├ 最高機密(Top secret)
├ 機密(Secret)
├ 秘密(Confidential)
├ 非機密だが取り扱い注意(Sensitive but unclassified)
└ 非機密(Unclassified)
1.5. 組織内での役割と責任 (Responsibility to consider include):
経営幹部 (Executive Management):
└ 資産保護に関する全ての権限が与えられる。
上級管理職/シニアマネジャー (Senior Manager):
└ 組織のセキュリティと資産の保護に最終的な責任を持つ。
オーナー (Owner)
├ 組織のセキュリティポリシーに基づく適切なセキュリティが情報システムに実装されていることを確認する。(ポリシーとの一貫性)
├ 適切な重要度レベルまたは分類を決定する。
└ アクセス権を決定する。
データ・オーナー (Data Owner):
├ 通常シニアマネジメントの一員で、データの保護と使用の最終的な責任を持つ。
├ 自分が責任を持っているデータの分類を決め、ビジネスニーズが生じたときにはその分類の変更を行う。
└ 日々のデータ保持の責任をデータ管理者に委譲することがある。
情報セキュリティ専門家 (Information Security professional):
├ 組織のセキュリティに関する、ポリシー、スタンダード、ベースライン、プロシージャ、およびガイドラインの策定、実施、管理、見直しを担当する。
└ セキュリティに関して職務上責任を持ち、マネジャーの指示を実行する。
データ/システム管理者 (Data/System Custodian):
└ 通常はネットワーク管理者または当該業務担当者が担当する。
└ データ/システムの保持と保護の責任を付与される。
ユーザ(User)
├ 仕事に関連したタスクのために日常的にデータを使用する個人全て。
├ 職位内で必要なレベルのデータアクセスを持っていなければならない。
└ セキュリティポリシーに従い、資産の可溶性、完全性、機密性を維持する責任がある。
情報システム監査員 (Information System Auditor):
├ セキュリティ目標が妥当であること、また、スタンダード、ベースライン、プロシージャ、ガイドラインが組織のセキュリティ目標を適切かつ効果的に満たしていることを
経営陣に対して監査の立場から保障する。
└ セキュリティ目標が適切な管理下で達成されているか確認する。
1.6. 製品/システムの評価基準 (Product/System Evaluation Criteria)
TCSEC(Trusted Computer System Evaluation Criteria):
├ ベンダーのセキュリティ製品に備わっている機密保持機能の評価基準となる。
├ データの機密性に関するポリシー要件を満たすベンダー製品を選択するための目安となる。
└ 製品における一定のセキュリティレベルを保障する。
├ 顧客 → 信頼性の評価基準
└ ベンダー → 組み込むべきセキュリティ機能
ITSEC(Information Technology Evaluation Criteria):
└ セキュリティ基準の国際的な調整
├ 豊富な経験に基づく。
├ セキュリティ基準の相違をなくす。
└ 国境を越えて、また商用であるか政治目的であるか軍事目的で有るかにかかわらず、基本的な概念と手法を統一する。
Common Criteria(情報セキュリティ国際評価基準):
├ 製品/システムのITセキュリティ要件を表す共通の構造と言語をあらわす。
└ 共通の基準を設けることで、ITセキュリティの評価結果が多くの関係者にとって有意義なものとなる。
*上記の3つの項目の詳細はCBK#6 Security Architecture 参照
ISO17799
└ 作業基準-指針とサポート
├ 情報セキュリティを実施する際のさまざまな管理関する総合的な指針を示す。
└ 良質なアドバイスをパッケージにしたもの。
BS7799-2
└ 管理システム基準(認証可能かつ測定可能な要件)
├ 管理システムの標準であり、定義済みの要件の遵守を実施するために用いる。
└ この基準に基づく評価は、選定した管理機能が正しく実施されており、有効であることによって判断する。
1.7. 人事セキュリティ (Personal Security)
1.7.1. 採用時等の雇用プロシージャ- (Hiring Procedures):
├ 経歴調査、信用照会調査、学業成績など。
├ 機密保持契約やビジネス倫理承諾書等へのサイン。
├ 最初は雇用時に低レベルのチェックしか行わなかった場合は、昇進時にさらに詳細のチェックを行う必要がある。
└ 雇用は、(配属先のマネージャーだけでなく)人事部門と協力して実施すること。
1.7.2. 退職時のプロシージャー (Termination Procedures):
├ アクセスカードや機器類を全て返却させる
└ 退職後は、その従業員のユーザアクセス件を全て削除させる。
1.7.3. 推奨慣行 (Good Practice):
仕事内容の説明、役割と責任の明確化。
責任の分離 (Separation of duties):
├ 従業員が牽制し、不正な目的でシステムを操作するのを阻止する。
├ 危険なタスクを1人で実行することができないようにすること。
└破壊や不正を行うのに複数の人間を必要とする場合の共謀(Collusion):の防止
ジョブローテーション(Job rotation)
└ 特定の個人にビジネスセグメントのコントロールをあまりに与えすぎないようにするため、長期間1 人の人間を同じポジションに置いておかない。
休暇取得義務
└ 休暇中に不正が発覚する。
機密保持契約(Nondisclosure agreements):
└ 従業員が何らかの理由で辞職する。場合に企業を守る。
1.8. セキュリティ意識の向上 (Security Awareness)
意識向上を目的とした資料
└ 各従業員が自分のセキュリティ責任を認識する。
トレーニングのタイプ(Types of training):
├ オペレーターへのセキュリティ関連ジョブトレーニング。
├ セキュリティが重要な職位の特定の部署やグループに対する啓蒙トレーニング。
├ IT サポート人員やシステムアドミニストレーターに対する技術的セキュリティトレーニング。
├ セキュリティ実行者や情報システム監査者に対する高度な情報セキュリティトレーニング。
└ シニアマネジャー、ファンクショナルマネジャー、ビジネスユニットマネジャーに対するセキュリティトレーニング。
教育 (Education)
└ 組織のセキュリティプログラムの成功に不可欠な意思決定スキルとセキュリティ管理を習得する。
ここまで