Comments
Description
Transcript
IT システムのためのリスクマネジメントガイド
Special Publication 800-30 IT システムのためのリスクマネジメントガイド 米国国立標準技術研究所による推奨 Gary Stoneburner、Alice Goguen、Alexis Feringa この文書は下記団体によって翻訳監修されています NIST Special Publication 800-30 IT システムのためのリスクマネジメントガイド 米国国立標準技術研究所 による推奨 Gary Stoneburner, Alice Goguen1, Alexis Feringa1 コンピュータ セキュリティ 米国国立標準技術研究所 情報技術研究所 コンピュータセキュリティ部門 Gaithersburg, MD 20899-8933 1 Booz Allen Hamilton Inc. 3190 Fairview Park Drive Fells Church, VA 22042 2002 年 7 月 米国商務省 長官 Donald L. Evans 技術管理局 技術担当商務次官 Phillip J. Bond 米国国立標準技術研究所 所長 Arden L. Bement, Jr. Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 コンピュータシステム技術に関する報告書 米国国立標準技術研究所（NIST: National Institute of Standards and Technology、以下、NIST と称する。） の情報技術ラボラトリ（ITL:Information Technology Laboratory）は、国の測定基準及び標準基盤において技 術的リーダーシップを提供することにより、米国の経済と公共福祉に貢献している。情報技術ラボラトリは、テ スト、テスト技法、参照データの作成、コンセプト導入の検証、技術的分析を行い、情報技術の開発と生産的 利用の拡大に努めている。情報技術ラボラトリの責務は、連邦政府のコンピュータシステムにおいて、費用対 効果の高いセキュリティと取り扱いに注意を要する非機密扱い情報のプライバシーを確保するための技術 的、物理的、管理的及び運用のための標準とガイドラインを策定することにある。NIST Special Publication 800 シリーズでは、コンピュータセキュリティにおける情報技術ラボラトリの調査、ガイダンス、成果を報告し、 産業界、政府機関及び教育機関との共同活動についても報告する。 National Institute of Standards and Technology Special Publication 800-30 Natl. Inst. Stand. Technol. Spec. Publ. 800-30、54 ページ (2002 年 7 月) CODEN: NSPUE2 本文書中で言及される商業的組織、装置、資料は、実験手順あるいは概念を適切に説明するためのものである。した がって、NIST による推薦または公認を意味するものではなく、これら組織、資料、あるいは装置が、その目的に関して 得られる最善のものであると意味しているわけでもない。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page iii 謝辞 作成者の Gary Stoneburner (NIST)、及び Alice Goguen と Alexis Feringa (Booz Allen Hamilton) は、本書 草稿のレビューをしていただいた両組織の同僚に感謝の意を表する。とりわけ、NIST の Timothy Grance、 Marianne Swanson、Joan Hash 及び、Booz Allen の Debra L. Banning、Jeffrey Confer、Randall K. Ewell、 Waseem Mamlouk よりは、本書の技術的内容に大きく貢献する、価値ある洞察をいただいた。また、本文書の 品質と実用性の向上に寄与する多くの思慮に富んだ建設的な意見をくださった官民各セクター諸氏に、心よ り感謝の意を表する。 本文書は、原典に沿ってできるだけ忠実に翻訳するよう努めていますが、完全 性、正確性を保証するものではありません。翻訳監修主体は本文書に記載さ れている情報より生じる損失または損害に対して、いかなる人物あるいは団 体についても責任を負うものではありません。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page iv 目次 1. はじめに ...............................................................................................................................................1 1.1 1.2 1.3 1.4 1.5 1.6 作成機関及び適用範囲 .............................................................................................................................................1 目標 ............................................................................................................................................................................1 リスクマネジメントの目的 ...........................................................................................................................................2 対象とする読者 ..........................................................................................................................................................2 関連文献.....................................................................................................................................................................3 本文書の構成.............................................................................................................................................................3 2. リスクマネジメントの概要 .......................................................................................................................4 2.1 2.2 2.3 リスクマネジメントの重要性 .......................................................................................................................................4 システム開発ライフサイクルへのリスクマネジメントの統合 .....................................................................................4 リスクマネジメントにおける主な役割 .........................................................................................................................6 3. リスクアセスメント..................................................................................................................................8 3.1 ステップ 1：システムの特徴定義..............................................................................................................................10 3.1.1 システム関連情報........................................................................................................................................ 10 3.1.2 情報収集手法 ...............................................................................................................................................11 3.2 ステップ 2：脅威の特定 ............................................................................................................................................12 3.2.1 脅威源の特定 .............................................................................................................................................. 12 3.2.2 攻撃の動機と脅威となる行動 ..................................................................................................................... 13 3.3 ステップ 3：脆弱性の特定 ........................................................................................................................................15 3.3.1 脆弱性に関する情報源 ............................................................................................................................... 16 3.3.2 システムセキュリティテスト .......................................................................................................................... 17 3.3.3 セキュリティ要件チェックリストの作成 ......................................................................................................... 18 3.4 ステップ 4：管理策の分析 ........................................................................................................................................20 3.4.1 管理手法 ...................................................................................................................................................... 20 3.4.2 管理策の分類 .............................................................................................................................................. 20 3.4.3 管理策の分析手法 ...................................................................................................................................... 20 3.5 ステップ 5：可能性の判断 ........................................................................................................................................21 3.6 ステップ 6：影響の分析 ............................................................................................................................................21 3.7 ステップ 7：リスクの判断 ..........................................................................................................................................23 3.7.1 リスクレベルマトリクス ................................................................................................................................. 23 3.7.2 リスクレベルの説明 ..................................................................................................................................... 24 3.8 ステップ 8：推奨管理策 ............................................................................................................................................25 3.9 ステップ 9：結果の文書化 ........................................................................................................................................25 4. リスク軽減.......................................................................................................................................... 26 4.1 リスク軽減の選択肢 .................................................................................................................................................26 4.2 リスク軽減戦略.........................................................................................................................................................27 4.3 管理策導入のアプローチ.........................................................................................................................................28 4.4 管理策の分類...........................................................................................................................................................31 4.4.1 技術的セキュリティ管理策 .......................................................................................................................... 31 4.4.2 管理的セキュリティ管理策 .......................................................................................................................... 34 4.4.3 運用的セキュリティ管理策 .......................................................................................................................... 35 4.5 費用対効果分析.......................................................................................................................................................36 4.6 残存リスク.................................................................................................................................................................38 5. 評価とアセスメント.............................................................................................................................. 39 5.1 5.2 優れたセキュリティ実践手法 ...................................................................................................................................39 成功の鍵...................................................................................................................................................................39 付録 A： インタビュー時の質問例 ........................................................................................................A-1 付録 B： リスクアセスメント報告書サンプル（アウトライン） ....................................................................B-1 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page v 付録 C： 管理策導入計画一覧表（サンプル） .......................................................................................C-1 付録 D： 略語 .....................................................................................................................................D-1 付録 E： 用語集 ..................................................................................................................................E-1 付録 F： 参考文献............................................................................................................................... F-1 図のリスト 図 3-1 リスクアセスメント手法のフローチャート ....................................................................................9 図 4-1 リスク軽減アクションのポイント ................................................................................................27 図 4-2 リスク軽減手法のフローチャート..............................................................................................30 図 4-3 技術的セキュリティ管理策 .......................................................................................................32 図 4-4 導入する管理策と残存リスク ...................................................................................................38 表のリスト 表 2-1 システム開発ライフサイクルへのリスクマネジメントの統合 .....................................................5 表 3-1 人為的脅威：脅威源、動機、及び脅威行動 ............................................................................14 表 3-2 脆弱性と脅威の組合せ ............................................................................................................15 表 3-3 セキュリティ基準 .......................................................................................................................18 表 3-4 可能性の定義 ...........................................................................................................................21 表 3-5 影響の大きさの定義.................................................................................................................22 表 3-6 リスクレベルマトリクス ..............................................................................................................24 表 3-7 リスク尺度と必要な行動...........................................................................................................24 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page vi 1. はじめに いかなる組織にもミッションがある。デジタル時代においては、組織が持つミッションを支援するのに必要な 情報を処理する上で、自動化された IT システム1を利用しており、リスクマネジメントは IT を利用することに よって生じるリスクから組織の情報資産及びそのミッションを守る重要な役割を果たしている。 効果的なリスクマネジメントプロセスは、IT セキュリティ導入計画を成功させる重要な構成要素の一つであ る。組織がリスクマネジメントプロセスを実施する主な目的は、IT 資産を守るだけでなく、組織及びそのミッ ションを遂行する能力自体をも守ることでなければならない。したがって、リスクマネジメントプロセスは、主に IT システムを管理運用する IT の専門家が実行する技術的な機能としてではなく、組織にとって不可欠な管 理機能としてとらえなければならない。 1.1 作成機関及び適用範囲 この文書は、NIST が、1987 年のコンピュータセキュリティ法（Computer Security Act）及び 1996 年の情報技 術管理改革法（Information Technology Management Reform Act）、合衆国法律集第 15 編第 278 条 g-3(a)(5) 項に基づき、その法的責任を推進するために作成したものである。この文書は、合衆国法律集第 15 編第 278 条 g-3(a)(3)項における意味でのガイドラインではない。 これらのガイドラインは、取り扱いに注意を要する情報を扱う連邦政府組織が使用するためのものである。 これは行政管理予算局（OMB; Office of Management and Budget）Circular A-130 付録 III の要件と一致して いる。 ここに示すガイドラインは義務または強制力のある標準ではない。本文書は、非政府組織も自由意志で使 用することができる。著作権による制約も受けない。(翻訳者注:著作権に関するこの記述は、SP800-30 の英 語の原文のことを言っており、日本語へ翻訳した本書の著作権は、独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社に帰属する）。 本文書における一切は、商務長官が法的権威に基づき連邦政府に対して義務及び拘束力を与えた標準及 びガイドラインを否定するものではない。また、これらのガイドラインは、商務長官、行政管理予算局長、また は他のすべての連邦政府当局者の既存の権威に変更を加えたり、これらに取って代わるものと解釈してはな らない。 1.2 目標 リスクとは、発生確率と事象の結果の双方を総合的に考慮して得られた脆弱性の悪用による負の影響の 度合である。リスクマネジメントとは、リスクを特定し、評価した上で許容レベルまでリスクを低減するプロセス のことである。本ガイドは、IT システムで特定されたリスクの評価と低減に必要な定義及び実務上のガイドを 含み、有効なリスクマネジメントプログラム構築のための基礎を提供する。本文書の最終的な目標は、IT に 関連した、ミッションに関わるリスクを、組織が適切に管理できるよう支援することにある。 1 「IT システム」という用語は、一般的な支援システム そのもの(たとえば、メインフレームコンピュータ、ミッドレンジコ ンピュータ、ローカルエリアネットワーク、連邦政府全体のバックボーンなど)、あるいは、利用者の特定の要求を満たす情 報資源を利用するために一般的な支援システム上で実行可能な主要アプリケーションを意味する。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 1 さらに、本ガイドは費用対効果の高いセキュリティ管理策2を選択するための情報も提供する。これらの管理 策によって、リスクを低減し、基幹業務に関わる情報や、それらの情報を処理、保存、伝達する IT システム を、適切に保護することができる。 組織はこの文書が提案する包括的なプロセスと手順を拡張または省略することにより、それぞれの環境に 合わせて、IT に関連した、ミッションに関わるリスクを管理することができる。 1.3 リスクマネジメントの目的 リスクマネジメント実施の目的は、以下の方法により組織のミッションを達成することである。 (1) 組織の情報を保存、処理、あるいは伝達する IT システムをより適切に保護する。 (2) 経営陣が、十分な情報をもとにリスクマネジメントに関して適切な判断を下し、IT 予算の一部となるリスク マネジメントに対する支出を正当化できるようにする。 (3) リスクマネジメント実施の結果作成される文書に基づいて、経営陣が IT システムに対して認可 (または 承認)3 を行えるよう支援する。 1.4 対象とする読者 この文書は、IT システムのリスクマネジメントプロセスを支援または利用する、経験者、未経験者、技術要 員、非技術要員に対して共通の基盤を提供するものである。対象者には、以下のような人々が含まれる。 • IT セキュリティ予算に関する意思決定を行う、経営陣、ミッション遂行の責任者 • 連邦政府の IT システム、及び、これら IT システム向けのセキュリティに対するリスクマネジメント実施に 責任を持つ連邦最高情報責任者 • IT システムの運用認可に関する最終決定を行う指定承認者 (DAA：Designated Approving Authority) • セキュリティ導入計画に責任を持つ IT セキュリティ導入計画管理者 • IT セキュリティに責任を持つ情報システムセキュリティ責任者 (ISSO) • IT 機能を支援するために使用するソフトウェア及びハードウェア (または、そのいずれか) を所有する IT システム所有者 • IT システムが保存、処理、伝達するデータを所有する情報所有者 • IT 調達プロセスに責任を持つビジネスマネージャーまたは職務管理者 • IT システムのセキュリティを管理統括する技術担当者 (例：ネットワーク、システム、アプリケーション、 データベース管理者、コンピュータ専門家、データセキュリティアナリスト) 2 3 「保護手段」及び「管理策」という用語は、リスク低減手段を表しており、このドキュメントでは、これら 2 つの用語を区 別なく用いている。 2000 年 11 月の Office of Management and Budget による Circular A-130、Computer Security Act of 1987、及び Government Information Security Reform Act of October 2000 は、IT システムの運用前に認可を受けること、及びその後少なくとも 3 年ご とに再認可を受けることを求めている。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 2 • システムとデータの完全性に影響を与える可能性のあるコードを開発、保守する IT システム及びアプリ ケーションのプログラマ • IT システムとデータの完全性をテストし保証する IT 品質保証担当者 • IT システムを監査する情報システム監査人 • 顧客のリスクマネジメントを支援する IT コンサルタント 1.5 関連文献 この文書は、National Institute of Standards and Technology (NIST) Special Publication (SP) 800-27, Engineering Principles for IT Security(IT セキュリティにおけるエンジニアリングの原則)に記載されている一般 概念、ならびに、NIST SP 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems（IT セキュリティの確保のための一般的原則と実践）に記載されている原理と手法に基づ いている。さらに、この文書は Office of Management and Budget (OMB) Circular A-130, Appendix III, “Security of Federal Automated Information Resources”、Computer Security Act (CSA) of 1987 、及び Government Information Security Reform Act of October 2000 と一貫性を保っている。 1.6 本文書の構成 この文書の各節では、以下について説明する。 • 第 2 章では、リスクマネジメントの概要、リスクマネジメントがシステム開発ライフサイクル (SDLC： System Development Life Cycle) にどのように組み込まれるのか、そして、このプロセスを支援、利用す る利用者各々の役割について説明する。 • 第 3 章では、リスクアセスメント手法、及び、IT システムのリスクアセスメント実施における 9 段階の主要 な手順について説明する。 • 第 4 章では、リスク軽減の選択肢と戦略、管理策導入に関するアプローチ、管理策の分類、費用対効果 分析、及び残存リスクを含む、リスク軽減プロセスについて説明する。 • 第 5 章では、実践すべき優れた手法、継続的リスク評価及びアセスメントの必要性、及びリスクマネジメ ントプログラムを成功に導く要因について述べる。 この文書には 6 つの付録がある。付録 A には、インタビューの際の質問例が記載されている。付録 B に は、リスクアセスメントの結果を文書化する際に使用するサンプル（アウトライン）を収録した。付録 C には、管 理策導入計画一覧表のサンプルが掲載されている。付録 D は、本書の中で用いられている略語のリストであ る。付録 E は、この文書の中で頻繁に使われる用語の用語集である。付録 F は参考文献のリストである。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 3 2. リスクマネジメントの概要 この文書はリスクマネジメントの方法論、リスクマネジメントがどのようにシステム開発ライフサイクルの各 フェーズに組み込まれるのか、さらにリスクマネジメントプロセスがシステムの認可 (または承認) プロセスと どのように連動するのかについて説明する。 2.1 リスクマネジメントの重要性 リスクマネジメントには、リスクアセスメント、リスク軽減、それらの結果の評価とアセスメントという 3 つのプ ロセスが含まれる。本文書の第 3 節では、リスクとリスクがもたらす影響の特定やその評価と、推奨されるリ スク低減手段を含む、リスクアセスメントプロセスについて説明する。第 4 節では、リスク軽減について述べ、 リスクアセスメントプロセスによって推奨される適切なリスク低減手段の優先順位づけやその導入、保守につ いて説明する。第 5 節では、継続的な評価プロセスと、リスクマネジメントプログラムの導入を成功させるため の鍵となる点について説明する。指定承認者 (DAA)又はシステム認可責任者は、残存リスクが容認できるレ ベルであるかどうかを判断し、また IT システムの運用を認可する (または承認する) 前にセキュリティ管理策 をさらに追加して、残存リスクをさらに低減すべきかあるいは排除すべきかを判断する責任を負う。 リスクマネジメントとは、IT 管理者がその運用と保護手段の経済的コストのバランスを取りながら、組織の ミッションを支援する IT システムとデータを保護することにより、ミッション遂行能力を向上させることを可能に するプロセスである。このプロセスは IT 環境に特有のものではない。実際、我々の日常生活全般における意 思決定にも広く浸透している。その例としてホームセキュリティがある。多くの人がホームセキュリティシステム を導入し、月々の使用料をサービスプロバイダに支払い、これらシステムによって自分たちの資産をより適切 に保護する監視サービスが提供されている。おそらく世帯主はシステムや監視にかかるコストと、家財道具や 世帯主のミッションである家族の安全の価値を比較検討したことだろう。 組織の代表者は、組織のミッション達成に必要な能力を確保しなければならない。こうしたミッションの責任 者は、実世界の脅威に直面した場合、ミッション遂行のために必要なサポートレベルを提供するために、IT シ ステムが備えていなければならないセキュリティ能力を判断する必要がある。ほとんどの組織の IT セキュリ ティに対する予算は厳しいものとなっている。したがって、IT セキュリティに対する支出は、他の経営判断と同 様に徹底的にレビューしなければならない。適切に体系化されたリスクマネジメント方法論は、効果的に用い られた場合、経営陣がミッション遂行に不可欠なセキュリティ能力を提供するのに適した管理策を特定する助 けとなる。 2.2 システム開発ライフサイクルへのリスクマネジメントの統合 組織が IT システムにリスクマネジメントプロセスを導入する主な理由は、組織への負の影響の最小化、及 び意思決定のための確たる根拠の提供である。効果的なリスクマネジメントは、システム開発ライフサイクル に、完全に統合されなければならない。IT システムのシステム開発ライフサイクルは、5 つのフェーズからな る：開始フェーズ、開発／調達フェーズ、導入フェーズ、運用／保守フェーズ、そして廃棄フェーズである。場合 によっては、1 つの IT システムが複数のフェーズにある場合もある。しかし、リスクマネジメントの方法論は評 価の実施対象となっているシステム開発ライフサイクルのどのフェーズでも同じである。リスクマネジメントは システム開発ライフサイクルの主要なフェーズで実施できる繰返しプロセスである。表 2-1 は、各システム開 発ライフサイクルフェーズの特徴と各フェーズを支援するためのリスクマネジメントの実施方法について記述し たものである。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 4 表 2-1 システム開発ライフサイクルへのリスクマネジメントの統合 システム開発ライフサイク ルにおけるフェーズ 第 1 フェーズ − 開始 フェーズごとの特徴 リスクマネジメント活動 による支援 IT システムに対するニーズが示さ • 特定されたリスクは、セキュリティ要件 れ、IT システムの目的と適用範囲が や運用時のセキュリティ概念 (対策) 文書化される。 を含むシステム要件の作成に利用さ れる。 第 2 フェーズ − 開発ま IT システムを設計、購入、プログラ • 本フェーズで特定されたリスクは、シ たは調達 ム、開発、あるいは構築する。 ステム開発時のアーキテクチャや設 計のトレードオフにつながる IT システ ムのセキュリティ分析に利用すること ができる。 第 3 フェーズ − 導入 システムのセキュリティ機能を、設 • リスクマネジメントプロセスは、当該要 定、有効化、テスト、検証する。 件及び、そのモデル化された運用環 境下におけるシステム導入に関する アセスメントを支援する。特定されたリ スクに関する判断はシステム運用前 に下さなければならない。 第 4 フェーズ − 運用ま システムが その機能を 実行する。 • 定期的なシステムの再認可 (または たは保守 ハードウェアとソフトウェ アの追加 再承認) に対して、IT システムの運 や、組織内プロセス、方針、手順の 用上、実動環境上の大幅な変更 (例 えば、新しいシステムインタフェースな 変更に伴い、システムは通常、継続 的に変更される。 ど) がある場合には、必ずリスクマネ ジメント活動を実施する。 第 5 フェーズ − 廃棄 このフェーズでは、情報、ハードウェ • ハードウェアとソフトウェアが適切に 廃棄され、残存データが適切に処理 ア、ソフトウェアの廃棄が行われる場 され、システム移行が安全かつ系統 合がある。その中には、情報の移 立った方法で行われるようにするた 動、アーカイブ、廃棄、破壊や、ハー め、廃棄または交換予定のシステム ドウェアとソフトウェアのサニタイズ コンポーネントに対してリスクマネジメ （無害化）が含まれる。 ント活動を実施する。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 5 2.3 リスクマネジメントにおける主な役割 リスクマネジメントは経営陣の責任で行う。この節ではリスクマネジメントプロセスを支援し、関与する人員 の主な役割について説明する。 • 経営陣： ミッション遂行の最終責任を負い、一般的に払うべき注意を払う経営陣は、ミッション達成のた めに、必要な資源が効果的に割り当てられるようにしなければならない。さらに、リスクアセスメント活動 の結果を評価し、それらを意思決定プロセスに取り入れなければならない。IT のミッションに関連するリ スクを評価し、それを低減する効果的なリスクマネジメントプログラムには経営陣の支援と参加が不可欠 である。 • 最高情報責任者 (CIO)： CIO は組織の IT に関する計画、予算といった、情報セキュリティコンポーネ ントに含まれるものに対して責任を負う。これらの分野における意思決定は効果的なリスクマネジメント プログラムに基づいて行うべきものである。 • システム及び情報所有者： システム及び情報所有者には、IT システムと双方が所有するデータの完全 性、機密性、可用性を扱う適切な管理策が設置されていることを確実にする責任がある。通常、システ ム及び情報所有者は IT システムの変更に対して責任を持つ。したがって、通常はシステム及び情報所 有者が IT システムの変更 (例えば、システム強化、ソフトウェアやハードウェアに対する主要な変更な ど) を承認し署名する。このことから、システム及び情報所有者はリスクマネジメントプロセスにおける自 らの役割を理解しこのプロセスを全面的に支援しなければならない。 • ビジネスマネージャー及び職務管理者： ビジネスの遂行及び IT 調達プロセスの責任を担う管理職はリ スクマネジメントプロセスに積極的に関与しなければならない。これらの管理職はミッション遂行に不可 欠なトレードオフの決定を行う権限と責任を有する要員である。リスクマネジメントプロセスにこれらの管 理職が参画することにより、IT システムに適切なセキュリティが得られるようになり、その IT システムを 適切に管理すれば、資源の支出を最低限に抑えつつミッションの効率的な遂行に寄与することができ る。 • 情報システムセキュリティ責任者 (ISSO)： IT セキュリティプログラムマネージャおよびコンピュータセ キュリティ責任者はリスクマネジメントを含む組織のセキュリティ導入計画に対して責任を負う。したがっ て、ISSO は組織のミッションを支援する IT システムに対するリスクを特定、評価、最小化するための体 系化された方法論を導入する際に主導的役割を果たす。ISSO は、経営陣によってこの活動が継続的に 実施されることを支援するコンサルタントも務める。 • IT セキュリティ担当者： IT セキュリティ担当者 (例えば、ネットワーク、システム、アプリケーション、 データベース管理者、コンピュータ専門家、セキュリティアナリスト、セキュリティコンサルタントなど) は IT システムにおけるセキュリティ要件の適切な導入に責任を持つ。既存の IT システム環境に変化が生 じたとき (例えば、ネットワークの拡大、既存インフラストラクチャや組織方針の変更、新技術の導入な ど)、IT セキュリティ担当者は新たな潜在的リスクを特定／評価し、IT システムを保護するために必要な 新たなセキュリティ管理策を導入するために、リスクマネジメントプロセスを支援、または使用しなければ ならない。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 6 • セキュリティ意識向上トレーニング担当者 (セキュリティ及び本件に関する専門家)： 組織の人員は IT システムの利用者でもある。IT システムやデータを、組織方針、ガイドライン、行動規範に則って使用す ることはリスク低減と組織の IT 資源保護に不可欠である。IT システムへのリスクを最小化するために は、システムやアプリケーション利用者がセキュリティ意識向上トレーニングを受けていることが必須であ る。したがって、IT セキュリティ意識向上担当者やセキュリティ及び本件に関する専門家は、適切なト レーニング教材を作成し、リスクアセスメントをエンドユーザを対象としたトレーニングプログラムに取り入 れることができるように、リスクマネジメントプロセスを理解していなければならない。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 7 3. リスクアセスメント リスクアセスメントはリスクマネジメント手法における最初のプロセスである。組織はリスクアセスメントを用 いて、システム開発ライフサイクル全体を通じて IT システムに対する潜在的脅威やリスクの大きさを判断す る。このプロセスでのアウトプットは、第 4 章で述べるリスク軽減プロセスにおいて、リスクを低減または排除 するための適切な管理方法を特定する際に有効である。 リスクとは、既知の脅威源が潜在的な脆弱性を悪用する可能性と、結果、その有害な事象が組織に及ぼす 影響についての関数である。（訳者注：リスクは、f(リスク)=脅威の発生可能性×脆弱性×影響という数式で 表されるため、関数として表現される。） 将来有害な事象が発生する可能性を判断するためには、潜在的な脆弱性と IT システムに導入された管理 策とともに、IT システムに対する脅威も分析しなければならない。ここでいう影響とは、脅威が脆弱性を悪用 したときにもたらしうる被害の大きさを指す。ミッションに対する潜在的な影響の度合いが影響レベルを左右 し、影響を受ける IT 資産と資源の相対的な価値を決める (例えば、IT システムコンポーネントとデータの重 要性、機密性の高さなど)。リスクアセスメント手法は、第 3.1 節から第 3.9 節で述べる 9 つの主なステップを 含む。 • ステップ 1 − システムの特徴定義 (第 3.1 節) • ステップ 2 − 脅威の特定 (第 3.2 節) • ステップ 3 − 脆弱性の特定 (第 3.3 節) • ステップ 4 − 管理策の分析 (第 3.4 節) • ステップ 5 − 脅威の発生可能性の判断 (第 3.5 節) • ステップ 6 − 影響の分析 (第 3.6 節) • ステップ 7 − リスクの判断 (第 3.7 節) • ステップ 8 − 管理策の推奨 (第 3.8 節) • ステップ 9 − 結果の文書化 (第 3.9 節) ステップ 2、3、4 及び 6 はステップ 1 完了後に並行して行うことができる。図 3-1 はこれらのステップ及び、各 ステップにおける情報のインプットとアウトプットを示したものである。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 8 インプット リスクアセスメント活動 • ハードウェア • ソフトウェア • システム インタフェース • データ及び情報 • 要員／人員 ステップ 1. システムの特徴定義 • システム攻撃の履歴 • 情報機関、NIPC、OIG、 FedCIRC、マスメディア からのデータ • 以前のリスクアセスメン ト報告 • あらゆる監査コメント • セキュリティ要件 • セキュリティテスト結果 • 実施中管理策 • 計画中管理策 • • • • 脅威源の動機 脅威の威力 脆弱性の性質 現在の管理策 • • • • ミッションへの影響分析 資産の重要度評価 データの重要度 データの機密度の高さ ステップ 2. 脅威の特定 アウトプット • システム境界 • システム機能 • システム及びデー タの重大性 • システム及びデー タの機密性 脅威ステートメント ステップ 3. 脆弱性の特定 潜在的な脆弱性の リスト ステップ 4. 管理策の分析 実施中及び計画中の 管理策のリスト ステップ 5. 脅威の発生可能性の判断 ステップ 6. 脅威の発生可能性 レベル 影響の分析 影響レベル • 完全性の損失 • 可用性の損失 • 機密性の損失 • 脅威がつけこむ可能性 • 影響の大きさ • 計画中または現在の管理 ステップ 7. リスクの判断 リスク及び関連 するリスクレベ 策の適切性 ステップ 8. 管理策の推奨 推奨管理策 ステップ 9. 結果の文書化 リスクアセスメ ント報告 図 3-1 リスクアセスメント手法のフローチャート Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 9 ステップ 1：システムの特徴定義 3.1 IT システムリスクアセスメントの最初のステップは、リスクアセスメント作業の適用範囲を定義することであ る。このステップでは IT システムの境界を明確にするとともに、システムを構成する資源や情報についても特 定する。IT システムの特徴を明確化することによって、リスクアセスメント作業の適用範囲が定まり、運用認 可 (または承認) を出す範囲が明確になり、リスクを定義するために不可欠な情報 (例えば、ハードウェア、 ソフトウェア、システム接続性、責任部署またはサポート要員) が得られる。 第 3.1.1 節では IT システムやその運用環境の特徴を明確にするために用いられるシステム関連情報につ いて説明する。第 3.1.2 節では IT システム処理環境に関連する情報提供を求める際に用いられる情報収集 手法を紹介する。 本文書に記載されている手法は単一のシステムの評価にも、相互に関連する複数のシステムの評価にも 適用できる。後者の場合、手法を適用する前に、対象とする領域、すべてのインタフェース、依存性を十分に 確認しておくことが重要である。 3.1.1 システム関連情報 IT システムのリスクを特定するにはシステム処理環境を明確に理解する必要がある。したがって、リスクア セスメント担当者は、まず、次のように分類されるシステム関連情報を収集しなければならない。 • ハードウェア • ソフトウェア • システムインタフェース (例えば、内部／外部接続性) • データや情報 • IT システムをサポート、あるいは利用する者 • システムのミッション (例えば、IT システムの実行するプロセス) • システムやデータの重要性 (例えば、システムの価値または組織にとっての重要性など) • システムやデータの機密の高さ4 IT システムの運用環境とそのデータに関する追加情報には以下のようなものがあるが、これらに限定され るわけではない。 • IT システムの機能要件 • システムの利用者 (例えば、IT システムを技術的に支援するシステム利用者、ビジネスを行うために IT システムを利用するアプリケーション利用者など) • IT システムに適用されるシステムセキュリティ方針 (組織方針、連邦要件、法律、業界慣行など) • システムセキュリティアーキテクチャ 4 システム及びデータの完全性、機密性、及び可用性の維持管理に必要な保護のレベル。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 10 • 現在のネットワークトポロジ (例えば、ネットワークダイアグラムなど) • システムとデータの可用性、完全性、機密性を保護するための情報を保存するストレージの保護 • IT システムに属する情報の流れ (例えば、システムインタフェース、システム入出力フローチャートなど) • IT システムに適用する技術管理策 (例えば、識別や認証をサポートする組み込み型または付加型セ キュリティ製品、任意的／強制的なアクセス制御、監査、残存情報保護、暗号化手法など) • IT システムに適用する統制管理策 (例えば、行動規範、セキュリティ計画など) • IT システムに適用する運用管理策 (例えば、要員セキュリティ、バックアップ、緊急時対応、及び回復と 復旧活動、システム保守、オフサイトストレージ、利用者アカウントの設定や削除手順、特権利用者アク セスと一般利用者アクセスのような利用者別機能管理など) • IT システムの物理的セキュリティ環境 (例えば、施設のセキュリティ、データセンター方針など) • IT システム処理環境に導入された環境セキュリティ (例えば、湿度、水、電力、汚染、温度、化学物質の 管理など) 開始フェーズまたは設計フェーズにあるシステムの場合、システム情報は設計文書や要件文書から得られ る。開発中の IT システムの場合、将来の IT システムに対して計画中の主要セキュリティ規則や属性を明ら かにする必要がある。開発中の IT システムのセキュリティについて役に立つ情報は、システム設計書やシス テムセキュリティ計画書から得られる。 運用中の IT システムの場合、システム設定、接続性におけるデータ、文書化された手続き・プラクティス、 文書化されていない手続き・プラクティスを含め、IT システムに関するデータはその実働環境で収集される。 したがって、システム設計書は下層インフラストラクチャが提供するセキュリティまたは将来の IT システムセ キュリティ計画に基づいたものとなる。 3.1.2 情報収集手法 以下のテクニックのいずれか、またはそれらを組み合わせることにより、運用範囲内の IT システム関連情 報を収集できる。 • アンケート： 担当者は関連情報を収集するために、計画中または稼動中の IT システム管理及び運用 管理策に関するアンケートを作成することができる。当該アンケートは IT システムの設計またはサポー トを担当する技術要員及び非技術要員を対象に配付すべきものである。当該アンケートは現場訪問及 びインタビューの際にも使用することができる。 • 現場インタビュー： 担当者は、IT システムサポート要員や管理要員との面接により、IT システムに関す る有用な情報 (例えば、システムの運用や管理方法など) を収集できる。さらにリスクアセスメント担当 者は現場訪問により IT システムの物理的、環境的、運用上のセキュリティに関する情報を観察、収集す ることができる。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 11 付録 A には、サイト要員に対するインタビューで、組織の運用特性をより適切に理解するために尋ねる 質問例を収録した。まだ設計フェーズにあるシステムの場合は、現場訪問はシステム要員から直接デー タを収集し、IT システムが運用される物理環境を評価する機会を提供することができる。 • 文書レビュー： 方針文書 (例えば、法律文書、指令など)、システム文書 (例えば、システム利用者のガ イド、システム管理マニュアル、システム設計及び要件文書、調達文書など)、及びセキュリティ関連の文 書 (例えば、以前の監査報告、リスクアセスメント報告、システムテスト結果、システムセキュリティ計画 5 、セキュリティ方針など) から、IT システムに対して適用されている、または計画中のセキュリティ管理 策に関する質の高い情報が得られる。組織のミッションに対する影響分析や資産重要度評価からは、シ ステム／データにおける重大性や機密性の高さに関する情報が得られる。 • 自動スキャンツールの利用： システム情報を効果的に収集するため、プロアクティブな技術手法を用い ることができる。例えば、ネットワークマッピングツールは、大規模なホストグループの上で動作するサー ビスを特定し、対象となる IT システムの個々のプロファイルを迅速に構築する方法を提供する。 情報収集はステップ 1 (システムの特徴定義) からステップ 9 (結果の文書化) までのリスクアセスメントプ ロセスの全ステップにおいて有効である。 ステップ 1 のアウトプット − 評価する IT システムの特徴定義、IT システム環境の俯瞰図、及びシステム範 囲の明確化 3.2 ステップ 2：脅威の特定 脅威とはある脅威源が特定の脆弱性を悪用する可能性である。脆弱性とは偶発的に衝かれるか、または故 意につけこまれる可能性のある弱点である。悪用される脆弱性 が存在しなければ脅威源がリスクを露呈することはない。脅威 脅威：脅威源が特定の脆弱性を悪 が発生する可能性 の判断(第 3.5 節)においては、脅威源、潜 用する (偶発的に衝くか、あるいは 在的脆弱性 (第 3.3 節)、及び既存のセキュリティ管理策 (第 故意につけこむ) 可能性 3.4 節) を考慮しなければならない。 3.2.1 脅威源の特定 このステップの目標は潜在的な脅威源を特定し、評価済 みの IT システムに対し、適用可能な潜在的脅威源をリスト アップした脅威ステートメントを作成することである。 5 脅威源：(1) 脆弱性に故意につけこむこと を目指す意図及び手法、あるいは (2) 脆 弱性が偶発的に衝かれる恐れのある状況 及び手法、のいずれか。 開始フェーズではリスクアセスメントは、初期システムセキュリティ計画作成に用いることができる。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 12 脅威源とは IT システムに被害をもた らす可能性のあるあらゆる状況または 事象と定義される。一般的な脅威源に は、自然、人為、環境によるものがあ る。 一般的脅威源 • 自然の脅威−洪水、地震、竜巻、地滑り、雪崩、雷 雨、その他の類似の事象 • 人為的脅威−偶発的行為 (不注意によるデータ入力) 脅威源を評価する際は、IT システム あるいは故意の行為 (ネットワークによる攻撃、悪意 やその環境に被害を及ぼす可能性のあ のあるソフトウェアのアップロード、機密情報への不 る全ての潜在的脅威源を考慮すること 当なアクセス) などの、人間がきっかけとなるかある が重要である。例えば、砂漠地帯に設 いは原因となる事象。 置された IT システムの脅威ステートメ ントには「自然の洪水」は発生する可能 • 環境的脅威−長時間停電、汚染、化学物質、液体漏洩 性が低いことからそのような事象は含ま れないかもしれないが、配管破裂などの 環境的脅威によってコンピュータ室が瞬 時に水浸しとなり、組織の IT 資産や資 源に被害をもたらす可能性はある。悪意を持った者あるいは不満を持った従業員による計画的な攻撃などの 故意の行為、あるいは不注意や誤りなどの偶発的行為により、人さえも脅威源となりうる。計画的攻撃とは、 (1) システムやデータの完全性、可用性、機密性を脅かすために IT システムに不当にアクセスしようとする (例えば、パスワードの推測などによる) 悪意ある試み、あるいは (2) 悪意はないものの、故意にシステムセ キュリティを迂回しようとする試み、のいずれかである。後者に属する故意の攻撃の例として、プログラマが 「仕事を片付ける」ためシステムセキュリティを迂回するトロイの木馬プログラムを作成する場合などがある。 3.2.2 攻撃の動機と脅威となる行動 動機と、攻撃を可能にする資源は、人間を潜在的に危険な脅威源にする。表 3-1 に今日一般的となった多 くの人為的脅威、可能な動機、または攻撃実行に用いられる可能性のある手法や脅威となる行動の概要を 示す。本情報は組織がその人為的脅威の（人が脅威となりうる）環境を検討し、人為的な脅威ステートメントを カスタマイズする際に役立つであろう。さらに、システム侵入履歴、セキュリティ侵害報告、インシデント報告の レビュー、ならびに情報収集時のシステム管理者、ヘルプデスク要員、利用者コミュニティとの会見は、IT シ ステムとそのデータに害を及ぼす可能性のある、脆弱性の存在が懸念される人為的脅威源の特定に有効で ある。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 13 表 3-1 人為的脅威：脅威源、動機、及び脅威行動 脅威源 ハッカー、クラッカー コンピュータ犯罪者 テロリスト 動機 脅威行動 挑戦 自己顕示 反抗 • • • • 情報破壊 不法な情報開示 金銭取得 不当データ改ざん • コンピュータ犯罪 (例えば、サイバーストーキング など) • 詐欺行為 (例えば、リプレイ攻撃、なりすまし、傍 受など) • 情報の贈収賄 • スプーフィング • システム侵入 脅迫 破壊 攻略 復讐 • 爆弾／テロリズム • 情報戦争 • システム攻撃 (例えば、分散サービス妨害 (DDoS) など) • システム侵入 • システム改ざん ハッキング ソーシャルエンジニアリング システム侵入、侵害 不正なシステムアクセス 産業スパイ (企業、外国政府、 その他の政府関連) 競争優位性 経済的スパイ行為 • • • • • • 経済的攻略 情報窃盗 個人プライバシー侵害 ソーシャルエンジニアリング システム侵入 不当なシステムアクセス (機密情報、知的財産及 び／または技術関連情報へのアクセス) インサイダー (訓練の不足した、不満を持 つ、悪意のある、不注意 な、不正直な、あるいは解 雇された従業員) • • • • 好奇心 • 自己満足 • 自己顕示 • 金銭取得 • 復讐 不作為の誤り及び怠 • 慢 (例えば、データ入 力ミス、プログラミング • ミスなど) • • • • 従業員に対する攻撃 脅迫状 知財情報の参照 コンピュータの不正使用 詐欺及び窃盗 情報贈収賄 偽造、変造されたデータの入力 傍受 悪意のコード (例えば、ウイルス、論理爆弾、トロ イの木馬など) 個人情報販売 システムのバグ システム侵入 システム損傷 不正なシステムアクセス 潜在的脅威源を特定した後、脅威がシステムの脆弱性を悪用する可能性を判断するために、動機、資源、 攻撃成功のために必要と思われる能力を第 3.5 節で説明する方法により推定すべきである。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 14 脅威ステートメント、あるいは潜在的脅威源のリストは、個々の組織や環境 (例えば、エンドユーザのコ ンピューティング習慣など) に合わせて調整が行われる。通常、自然の脅威に関する情報 (例えば、洪水、地 震、嵐など) はすぐに入手できるであろう。既知の脅威は、多くの政府や民間部門の組織によって特定されて きたものである。侵入検知ツールの普及も進み、政府や業界組織のセキュリティ事象に関する継続的データ 収集によって、脅威を現実的に評価する能力も向上しつつある。情報源としては次のようなものがあるが、こ れらに限定されるわけではない。 • 情報機関 (例えば、Federal Bureau of Investigation（＝連邦捜査局）の National Infrastructure Protection Center（＝基盤構造保護センター）など) • Federal Computer Incident Response Center (FedCIRC（＝連邦コンピュータ事故インシデントセンター）) • マスメディア、特に SecurityFocus.com、SecurityWatch.com、SecurityPortal.com 及び SANS.org のような ウェブベースの資源 ステップ 2 のアウトプット − システムの脆弱性を悪用する可能性のある脅威源リストを含む脅威ステートメ ント 3.3 ステップ 3：脆弱性の特定 IT システムに対する脅威の分析にはシステ ム環境に関連する脆弱性の分析が含まれなけ ればならない。本ステップの目標は潜在的脅威 源が悪用する可能性のあるシステムの脆弱性 (欠陥または弱点) のリストを作成することであ る。 脆弱性：悪用される (偶発的に衝かれるか、あるい は故意につけこまれる) ことによりセキュリティ侵 害またはシステムセキュリティ方針違反を招く可能 性がある、システムセキュリティの手順、設計、実 装、内部制御における欠陥または弱点。 表 3-2 に脆弱性と脅威の組合せの例を示す。 表 3-2 脆弱性と脅威の組合せ 脆弱性 脅威源 解雇された従業員のシステム識別 解雇された従業員 子 (ID) がシステムから削除され ていない。 脅威行動 会社のネットワークにダイヤルイン して社の知財情報にアクセスす る。 会社のファイアウォールが外部か らの telnet 接続を許可しており、 サーバ XYZ 上ではゲスト ID の 使用が可能になっている。 許可されていない利用者 (例え サーバ XYZ に telnet して、ゲスト ば、ハッカー、解雇された従業員、 ID を使いシステムファイルを閲覧 コンピュータ犯罪者、テロリストな する。 ど) ベンダーがシステムのセキュリティ 設計に欠陥を見つけたものの、新 しいパッチをシステムに適用してい ない。 許可されていない利用者 (例え 既知のシステム脆弱性を悪用して ば、ハッカー、不満を持つ従業員、 機密のシステムファイルに不正に コンピュータ犯罪者、テロリストな アクセスする。 ど) Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 15 脆弱性 脅威源 データセンターでは消火のために 火災、不注意な要員 水スプリンクラを設置しているが、 ハードウェア及び装置を水による 害から守る防水シートが設置され ていない。 脅威行動 データセンター内の水スプリンクラ が開栓になったままである。 システムの脆弱性を特定するための推奨手法には、脆弱性に関する情報源の利用、システムセキュリティ テストの実施、セキュリティ要件チェックリストの作成がある。 存在するであろう脆弱性の種類や、脆弱性が実際に存在するかどうかの判断に必要とされる方法は、通常 IT システムの特性と、そのシステムが属するシステム開発ライフサイクル内の各フェーズに応じて異なること に注意すべきである。 • IT システムがまだ設計されていない場合は、脆弱性を洗い出すには、組織のセキュリティ方針、計画さ れるセキュリティ手順、システム要件の定義、ベンダーまたは開発者によるセキュリティ製品分析 (例え ば、白書など) などを重点的に見ていく。 • IT システムが実装中である場合、脆弱性の特定には、セキュリティ設計文書に記述されたセキュリティ 機能やシステム認証テストとその評価結果など、より具体的な情報を含めて脆弱性の特定を行う。 • IT システムが運用中である場合は、脆弱性を特定するプロセスには、IT システムを保護するために用 いるセキュリティ機能や技術と手順（プロシージャ）の両方の管理策の分析を含める。 3.3.1 脆弱性に関する情報源 IT システムの処理環境に関連する技術的／非技術的な脆弱性は、第 3.1.2 節で説明した情報収集手法に よって特定することができる。業界の他の情報源 (例えば、システムバグ及び欠陥を明らかにしているベン ダーのウェブページなど) の調査によって得た情報は、特定の IT システム（例えば、特定のオペレーティング システムの特定バージョン）に関係するかもしれない脆弱性を特定するために実施されるインタビューの準備 や、効果的な質問表作成のための有益な情報となる。インターネットは、ベンダーが公開している既知のシス テム脆弱性とともに、脆弱性を排除あるいは低減するホットフィックス（プログラムの問題を解決するために緊 急に配布される修正モジュール）、サービスパック、パッチ、その他の修復手段についての有益な情報源でも ある。徹底した脆弱性分析を行う上で検討すべき文書化された脆弱性情報源には次のようなものがあるが、 これらに限定されるわけではない。 • 評価済み IT システムの以前のリスクアセスメント文書 • IT システムの監査報告、システム異常報告、セキュリティレビュー報告、システムテストと評価報告 • NIST I-CAT 脆弱性データベース (http://icat.nist.gov) のような脆弱性リスト Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 16 • FedCIRC やエネルギー省（Department of Energy）のコンピュータ事故諮問機関速報（Computer Incident Advisory Capability bulletins）などのセキュリティ推奨事項 • ベンダー推奨事項 • 商用のコンピュータインシデント／緊急事対応チームとメーリングリスト (例えば、SecurityFocus.com フォーラムのメーリングリストなど) • インフォメーションアシュランス脆弱性警告（Information Assurance Vulnerability Alert）と軍事システム用 速報 • システムソフトウェアセキュリティ分析 3.3.2 システムセキュリティテスト システムテストのような事前対策は、システムの脆弱性を効果的に特定するために用いられるが、それを 利用するかどうかは、IT システムの重大性や利用可能な資源に依存する (利用可能な資源には、例えば、 割り当てられた資金、利用可能な技術、テスト実施のための専門的知識を有する要員などがある)。、テスト手 法には次のようなものがある。 • 自動脆弱性スキャンツール • セキュリティテストと評価 (ST&E：Security Test and Evaluation) • 侵入テスト6 自動脆弱性スキャンツールは、ホストのグループあるいはネットワークをスキャンして既知の脆弱なサービ ス (例えば、システムが、匿名転送プロトコル (anonymous FTP) や、メールサーバソフトウェアの中継を許可 するなど) を探すために用いる。ただし、自動スキャンツールが特定した潜在的な脆弱性の中には、そのシス テム環境によって実際の脆弱性にはならないものもあるということを留意しなければならない。例えば、これら のスキャンツールにはサイトの環境や要件を考慮せずに潜在的脆弱性を判断するものがある。自動スキャン ソフトウェアが特定した「脆弱性」の中には、ある特定のサイトにとっては実際には脆弱ではなく、環境的要件 からそのように構成されていることがある。従って、このテスト手法はフォールスポジティブ (偽陽性) 的な結 果を産出することがある。 ST&E は、リスクアセスメントプロセスにおいて、IT システムの脆弱性を特定するために用いられる、もう 1 つの手法である。ST&E にはテスト計画 (例えば、テスト定型手続、テスト手順、予想テスト結果など) の作成 や実施も含まれる。システムセキュリティテストの目標は、IT システムセキュリティ管理策の有効性を運用環 境においてテストすることである。その目的は適用された管理策が、ソフトウェアやハードウェアの承認済みセ キュリティ要件と合致し、組織のセキュリティ方針の導入や業界標準に適合していることを確認することであ る。 侵入テストは、セキュリティ管理策のレビューを補完し、IT システムが安全かどうかを違う側面から確認す るためのものである。リスクアセスメントプロセスにおける侵入テストは、システムセキュリティを迂回しようとす る意図的な試みに対処する IT システムの能力を評価するために用いられる。その目的は IT システムを脅威 源の観点からテストすることにより、IT システム保護スキームの中の潜在的欠陥を特定することにある。 この種の任意的なセキュリティテストの結果は、システムの脆弱性特定に役立つであろう。 6 NIST SP 800-42, Network Security Testing Overview (ネットワークセキュリティテスト概観)ではネットワークシステム のテスト手法及び自動化ツールの使用法について説明している。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 17 セキュリティ要件チェックリストの作成 3.3.3 このステップにおいてリスクアセスメント担当者は、IT システムに対して取り決められ、システムの特徴定義 を通して収集されたセキュリティ要件が、既存のまたは計画されたセキュリティ管理策によって満たされている かどうかを判断する。通常、システムセキュリティ要件は表形式で表現され、それぞれの要件に対し、どのよう にしてシステム設計や導入がそのセキュリティ管理策の要件を満たすのか、あるいは満たさないのかの説明 が添付される。 セキュリティ要件チェックリストには、基本的なセキュリティ基準が含まれており、所与の IT システムに関連 する情報資産 (要員、ハードウェア、ソフトウェア、情報)、自動化されていない手順、プロセス及び情報伝達に おける脆弱性を、次のセキュリティ領域において体系的に評価し、特定するために用いられる。 • マネジメント • 運用 • テクニカル 表 3-3 は、各セキュリティ領域における IT システムの脆弱性を特定する際に用いるよう推奨されるセキュリ ティ判断基準の一覧である。 表 3-3 セキュリティ基準 セキュリティ分野 セキュリティマネジメント 運用セキュリティ セキュリティ判断基準 • • • • • • • • • • 責任の割当て サポートの継続性 インシデント対応能力 セキュリティ管理策の定期的レビュー 要員の身上調査や身元調査 リスクアセスメント セキュリティや技術的なトレーニング 職務分離 システム認可と再認可 システムまたはアプリケーションのセキュリティ計画 • • • • • 空中浮遊汚染物質の管理 (煙、粉塵、化学物質) 電力供給の品質確保のための管理 データメディアへのアクセスと廃棄 外部データの配付やラベル付け ファシリティ保護 (例えば、コンピュータ室、データセンター、オフィス など) • 湿度管理 • 温度管理 • ワークステーション、ラップトップ、スタンドアローンのパーソナルコン ピュータ Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 18 セキュリティ分野 テクニカルセキュリティ セキュリティ判断基準 • • • • • • • 通信 (例えば、ダイヤルイン、システム相互接続、ルータなど) 暗号技術 任意的アクセス制御 識別と認証 侵入検知 オブジェクト再利用 システム監査 このプロセスの成果はセキュリティ要件チェックリストである。このようなチェックリストをまとめるのに利用で きる情報源として、次のような政府規定とセキュリティ指令、及び IT システム処理環境に適した情報源がある が、これらに限定されるわけではない。 • CSA of 1987 (the Computer Security Act of 1987） （コンピュータセキュリティ法） • FIPS （Federal Information Processing Standards: 連邦情報処理規格） • OMB November 2000 Circular A-130 • Privacy Act of 1974 • 評価対象の IT システムのシステムセキュリティ計画 • 組織のセキュリティ方針、ガイドライン、基準 • 業界の慣習 NIST SP 800-26 Security Self-Assessment Guide for Information Technology Systems（IT システムのための セキュリティ自己アセスメントガイド）には、単体のシステムまたは相互接続されたシステムのグループをテス トし、計測する際の基準となる具体的な管理目的を含んだ、広範囲に及ぶアンケートが掲載されている。この 管理目的は、セキュリティやプライバシーに関する法律、方針、ガイダンスにおいて、実証済みの要件から直 接抽出されたものである。 チェックリスト (またはアンケート) の結果は順守や非順守の評価を行う際のデータとして使うことができ る。本プロセスは、潜在的脆弱性を表すシステム、プロセス、手順上の弱点を特定するものである。 ステップ 3 のアウトプット − 潜在的脅威源に悪用される恐れがあるシステム脆弱性 (観察結果)7のリスト 7 リスク評価報告は監査報告ではないため、サイトの中には、特定された脆弱性をリスク評価報告書における検出項目として ではなく、観察結果として扱うことを好むことがある。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 19 3.4 ステップ 4：管理策の分析 このステップの目標は、脅威によってシステム脆弱性が悪用される可能性 (または確率) を最小化あるい は排除するために、組織によって導入済みもしくは導入計画中の（セキュリティ）管理策を分析することであ る。 関連する脅威環境において、潜在的脆弱性が悪用される確率を示す総合的な可能性のレベルを知るには (下記ステップ 5)、実施中または計画された管理策の導入を考慮しなければならない。例えば、脅威源が示す 興味またはその能力のレベルが低い場合や、被害を排除／低減できる効果的なセキュリティ管理策が存在 する場合は、脆弱性 (例えば、システムまたは手順上の弱点など) は悪用されにくく、あるいは悪用される可 能性は低い。 第 3.4.1 節から第 3.4.3 節ではそれぞれ、管理手法、管理策の分類、管理策の分析手法について説明する。 3.4.1 管理手法 セキュリティ管理策には、技術的手法と非技術的手法の利用が含まれる。技術的管理策とは、コンピュータ のハードウェア、ソフトウェア、またはファームウェアに組み込まれた保護手段 (例えば、アクセス制御メカニ ズム、識別及び認証メカニズム、暗号化手法、侵入検知ソフトウェアなど) のことである。非技術的管理策と は、セキュリティ方針、運用手順、ならびに要員的／物理的／環境的セキュリティなどの運用面での統制やマ ネジメントのことである。 3.4.2 管理策の分類 技術的及び非技術的管理策手法のカテゴリーは、更に予防管理策と検知管理策に分類できる。これら 2 つのサブカテゴリーの説明は次のとおりである。 • 予防管理策とは、セキュリティ方針に違反しようとする試みを阻止するものであり、アクセス制御の実施、 暗号化、認可などの管理策（仕組み）がこれに含まれる。 • 検知管理策とは、セキュリティ方針に対する違反または違反未遂を警告するものであり、監査証跡、侵 入検知手法、及びチェックサムなどの管理策（仕組み）がこれに含まれる。 第 4.4 節ではこれらの管理について導入面からさらに詳しく説明する。リスク軽減プロセスにおけるこのよう な管理の導入は、リスクアセスメントプロセスにおいて既存のまたは計画された管理の欠陥 (例えば、管理が 導入されていない、あるいは管理が適切に導入されていないなど)を特定することによる直接的成果である。 3.4.3 管理策の分析手法 第 3.3.3 節で説明したように、セキュリティ要件チェックリストの作成または入手可能なチェックリストの利用 は、管理策を効率的かつ系統的に分析する方法として役立つであろう。セキュリティ要件チェックリストは、セ キュリティ順守はもとより、非順守の場合の確認にも用いることができる。したがって、このようなチェックリスト の有効性を保証するためには、組織の管理環境の変更 (例えば、セキュリティ方針、手法、要件の変更など) を反映するようにチェックリストを更新していくことが不可欠である。 ステップ 4 のアウトプット − IT システムがその脆弱性を悪用される可能性を下げ、そのような有害な事象の 影響を軽減するために用いられる、既存のまたは計画された管理策のリスト Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 20 3.5 ステップ 5：可能性の判断 関連する脅威環境において、潜在的脆弱性が悪用される確率を示す全体的可能性レベルを得るには、以 下の管理要因を検討しなければならない。 • 脅威源の動機と能力 • 脆弱性の性質 • 現状の管理策が実際に存在すること及びその効果 ある脅威源によって潜在的脆弱性が悪用されうる可能性は、高、中、低で表すことができる。次の表 3-4 に は、これら 3 つの発生可能性レベルの定義を示す。 表 3-4 可能性の定義 可能性レベル 可能性の定義 高 脅威源は強い動機を持ち、能力も十分である。脆弱性の悪用を防止する管理策が 有効ではない。 中 脅威源は動機を持ち、能力も有るが、脆弱性の悪用を妨げる管理策が導入されて いる。 低 脅威源に動機または能力が欠如している。あるいは、脆弱性の悪用を防止するか、 少なくとも著しく妨げる管理策が導入されている。 ステップ 5 のアウトプット − 可能性レベル (高、中、低) 3.6 ステップ 6：影響の分析 リスクレベル測定の次の主要ステップは、脅威によって脆弱性が悪用された場合にもたらされる有害な影 響についての判断である。影響分析を始める前に、第 3.1.1 節で述べたように、以下に挙げる情報を得る必 要がある。 • システムのミッション (例えば、IT システムが実行するプロセスなど) • システムやデータの重要性 (例えば、組織にとってのシステムの価値または、重要性など) • システムやデータの機密性 これらの情報は、ミッションに対する影響分析報告または資産重要度評価報告などの既存の組織内文書 から得られる。ミッションに対する影響分析 (ビジネス影響分析［BIA: business impact analysis］と呼ぶ組織も ある) では、組織の情報資産の機密性や重要度の定性的／定量的評価に基づいて、情報資産への危害か ら生じる影響レベルに優先順位付けを行う。資産重要度評価では、組織の重要なミッションをサポートする機 密性と重要度の高い情報資産 (例えば、ハードウェア、ソフトウェア、システム、サービス及び関連する技術 資産など) を特定し優先順位付けを行う。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 21 こうした文書が存在しない、あるいは組織の IT 資産に対してそのような評価を行ったことがない場合は、シ ステムやデータの機密性は、システムやデータの可用性、完全性、機密性を維持するために求められる保護 レベルに基づき判断することができる。IT システムやそのデータの機密性のレベル判定に用いられた方法に かかわらず、システムや情報の所有者は、自部門のシステムや情報に対する影響レベルを判断する責任を 負う。したがって、影響分析における適切な手法はシステムや情報の所有者へのインタビューである。 セキュリティイベントによる有害な影響は、従って、次の 3 つのセキュリティ目標、すなわち完全性、可用 性、機密性のいずれか、またはこれらを組み合わせたものの損失あるいは劣化という観点から記述すること ができる。次のリストは、各セキュリティ目標と、これらが合致しなかった場合の結果 (または影響) について 簡単に記したものである。 • 完全性の損失： システムやデータの完全性とは、情報を不適切な改変から保護することを意味する。 完全性は、故意または偶発的行為のいずれかによってデータや IT システムに対し、不当な変更がなさ れた場合に損なわれる。システムやデータの完全性の損失が是正されない場合、劣化したシステムまた は破損したデータを継続的に使用することは、不正確さ、詐欺、または誤判断につながる恐れがある。さ らに完全性の侵害はシステムの可用性や機密性への攻撃を成功させる第一歩にもなりうる。これらの理 由すべてから完全性損失は IT システムの保証を低下させる。 • 可用性の損失： エンドユーザが基幹 IT システムを使えなくなった場合、組織のミッションに影響が及ぶ 可能性がある。システム機能の損失及び運用上の有効性の損失は、例えば、生産時間の損失につなが り、その結果、組織のミッション遂行をサポートするエンドユーザの職務遂行の妨げになる。 • 機密性の損失： システムやデータの機密性とは、不当な開示から情報を保護することを意味する。機 密情報の不当開示の影響範囲は、国家安全保障への脅威から Privacy Act で保護されるべきデータの 開示にまで及ぶ可能性がある。不当、不測、不作為の情報開示は、公衆の信頼を失ったり、苦境に置か れたり、あるいは組織に対する法的行為の執行にもつながりかねない。 幾つかの有形の影響は、収入機会の損失、システムの修理コスト、あるいは脅威行動が成功した場合に発 生した問題を修正するために要する作業レベルなどによって定量的に計測できる。その他の影響 (例えば、 公衆の信頼の喪失、信用失墜、組織利益への損害など) は具体的な単位として計測することはできないが、 高、中、低という見方で影響を定性化もしくは表現できる。ここでは影響評価についての一般的な内容を扱っ ているので、このガイドでは影響の定性的カテゴリーである高、中、低レベルのみを利用して説明する (表 3.5 参照)。 表 3-5 影響の大きさの定義 影響の大きさ 影響の定義 高 脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産や資源 に対する巨額な損失。(2) 組織のミッション、評判、利益に対する著しい侵害、被害、 妨害。(3) 人命の損失、または重大な傷害。 中 脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産または 資源に対する高額な損失。(2) 組織のミッション、評判、利益に対する侵害、被害、 または妨害。(3) 人の傷害。 低 脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産または 資源へのある程度の損失。(2) 組織のミッション、評判、利益へのある程度の影響。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 22 定量的評価 対 定性的評価 影響分析を行う際には、定量的評価と定性的評価それぞれの利点及び欠点に配慮すべきである。定性的 影響分析の主な長所は、リスクに優先順位を付けることにより、脆弱性に対処する上で、即改善が必要な領 域を特定できることである。定性的分析の短所は、影響の大きさを具体的に定量化できないため、全ての推 奨される管理策に対する費用対効果分析が困難なことである。 定量的影響分析の主な利点は影響の大きさを測定できるため、結果を推奨管理策の費用対効果分析に使 用できることである。短所は、測定結果を表すために用いる数値範囲によっては定量的影響分析の意味が不 明確となり、結果の定性的な解釈が求められることである。影響の大きさを判断するためには、追加要因を検 討しなければならないことが多い。それらの要因には次のようなものがあるが、これらに限定されるわけでは ない。 • 一定期間内 (例えば 1 年など) に脅威源によって脆弱性が悪用される頻度の推定 • 脅威源によって脆弱性が悪用されるたびに発生するコストの概算 • ある脅威によって特定の脆弱性が悪用された場合の相対的影響を主観的に分析して決める重み付け 要素（ファクター） ステップ 6 のアウトプット − 影響の大きさ (高、中、または低) ステップ 7：リスクの判断 3.7 このステップの目的は IT システムに対するリスクレベルを査定することである。特定の脅威／脆弱性の組 合せに対するリスク判断は以下の値の関数として表すことができる。 • ある脅威源によってある脆弱性が悪用される可能性 • 脅威源によって脆弱性が実際に悪用された場合の影響の大きさ • リスク低減／排除するために計画済みまたは既存のセキュリティ管理策の適切性 リスクを計測するためには、リスクの尺度及びリスクレベルマトリクスを作成しなければならない。第 3.7.1 節では標準的なリスクレベルのマトリクスを掲載する。第 3.7.2 節は、リスクレベルの結果である。 3.7.1 リスクレベルマトリクス ミッションに関連するリスクの最終判断は、脅威の可能性 (例えば確率など) に、脅威の影響レベル値を掛 けることによって得られる。表 3.6 は脅威の可能性と脅威の影響カテゴリーを入力することにより、どのように 全体のリスクレベルが決まるのかを示している。この表は、脅威の可能性 (高、中、低) と脅威の影響 (高、 中、低) による 3 × 3 のマトリクスである。サイトの要件やリスクアセスメントに求められる精度により、4 × 4 あ るいは 5 × 5 のマトリクスを用いるのが適当なサイトもある。後者の場合、脅威の可能性に、「非常に低い／非 常に高い」、脅威の影響に、「非常に低い／非常に高い」を含めることにより、リスクレベルとして「非常に低い ／非常に高い」を生成する。「非常に高い」リスクレベルでは、システムのシャットダウンや、IT システム統合 及びテスト作業すべての中止に至る可能性がある。 表 3-6 のマトリクスでは、全体的なリスクレベルである高、中、低がいかにして得られるのかを示している。 これらリスクレベルや格付けの判断は主観的でもよい。正当化のための根拠は、各脅威の可能性レベルに割 り当てた確率と、各影響レベルに割り当てた数値によって説明できる。例えば、 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 23 • 各脅威の可能性レベルに割り当てる確率を、高は 1.0、中は 0.5、低は 0.1 とする。 • 各影響レベルに割り当てる数値を、高は 100、中は 50、低は 10 とする。 表 3-6 リスクレベルマトリクス 影響 脅威の可能性 高 (1.0) 中 (0.5) 低 (0.1) 低 中 高 (10) (50) (100) 低 中 高 10 × 1.0 = 10 50 × 1.0 = 50 100 × 1.0 = 100 低 中 中 10 × 0.5 = 5 50 × 0.5 = 25 100 × 0.5 = 50 低 低 低 50 × 0.1 = 5 100 × 0.1 = 10 10 × 0.1 = 1 リスクスケール：高 (50∼100); 中 (10∼50); 低 (1∼10) 8 リスクレベルの説明 3.7.2 表 3-7 は上記のマトリックス内に示したリスクレベルを説明するものである。高、中、低に格付けされたリス ク尺度は、ある脆弱性が悪用された場合に IT システム、ファシリティ、あるいは手順がさらされうるリスクレベ ルを示す。リスク尺度は、各リスクレベルに対して、ミッション遂行の責任者である経営陣が取らなければなら ない行動も示している。 表 3-7 リスク尺度と必要な行動 リスクレベル リスクの説明と必要な行動 高 ある観察結果または指摘事項が高リスクと評価された場合には、是正手段を講じること が強く求められる。既存システムは運用を続けてもよいが、できるだけ早期に是正措置 実行計画を実施しなければならない。 中 ある観察結果が中リスクと評価された場合は是正措置が必要であり、妥当な期間内に これらの措置を実施する計画を作成しなければならない。 低 ある観察結果が低リスクと評価された場合、システムの指定承認者は、是正措置が必 要か否かを判断するか、リスクを容認するかしなければならない。 ステップ 7 のアウトプット − リスクレベル (高、中、低) 8 ある項目に対して示されたレベルが非常に低く「無視できる」あるいは有意差なしと判断できる場合 (リスクスケール 1∼ 100 において値 <1 の場合)、これらにマネジメント行為を施すよりも、別の分類に分離する方が良い場合がある。これによ り次の定期リスクアセスメントを実施する際にこれら項目を見落とすことがなくなるだろう。また、分析によって特定され たリスクすべての完全な記録を作成することができる。これらのリスクは、脅威の発生確率や脅威による影響が変化するこ とにより、再評価時に新たなリスクレベルに移る可能性がある。このため、これら特定されたリスクを作業中に見失わない ようにすることが重要である。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 24 3.8 ステップ 8：推奨管理策 このステップでは、特定されたリスクを、組織の活動に適した方法で軽減または排除できる管理策を提示す る。推奨管理策の目標は、IT システムとそのデータに対するリスクレベルを許容レベルにまで低減することで ある。以下は特定されたリスクを最小化または排除するための管理策と代替ソリューションを推奨する際に検 討すべき要因である。 • 推奨する選択肢の有効性 (例えば、システム互換性など) • 法律や規制 • 組織方針 • 運用への影響 • 安全性や信頼性 リスクアセスメントプロセスの結果として管理策が推奨され、それがリスク軽減プロセスに組み込まれ、プロ セス実施期間中に、推奨される手続き的もしくは技術的なセキュリティ管理策の評価、優先順位付け、導入が 行われる。 損失を低減するために、全ての推奨管理策が導入されるわけではないということを留意しなければならな い。特定の組織にとってどの管理策が必要であり、適しているかを判断するには、提案された推奨管理策に 対して費用対効果分析 (第 4.6 節で述べる) を行い、管理策の導入によってリスクレベルが低減されることを 示し、それにかかるコストを正当化する必要がある。さらに、推奨する選択肢の導入による運用への影響 (例 えば、システムパフォーマンスへの影響など) や実現可能性 (例えば、技術的要件、利用者による容認など) もリスク軽減プロセスにおいて慎重に評価すべきである。 ステップ 8 のアウトプット ⎯ リスクを低減する管理策や代替ソリューションの推奨 3.9 ステップ 9：結果の文書化 リスクアセスメントが完了した後 (すなわち、脅威源及び脆弱性の特定、リスク評価、推奨管理策の提示 後)、その結果は、公式の報告書または概要報告書として文書化する。 リスクアセスメント報告書は、ミッション遂行の責任者である経営陣が方針、手順、予算や、システムの運用 及び管理上の変更に関する意思決定を行う際に参考となる経営的レポートである。不正を発見する監査報告 あるいは調査報告とは異なり、リスクアセスメント報告は非難するような形で書かれるべきではない。系統的 かつ分析的手法によりリスクを評価し、経営陣がリスクを把握し、損失可能性を低減もしくは是正するための 資源を割り当てられるようにすべきである。このような理由から、リスクアセスメント報告では脅威／脆弱性の 組合せを指摘事項ではなく観察結果として扱うことを好む者もいる。付録 B に、リスクアセスメント報告の概要 のサンプルを掲載する。 ステップ 9 のアウトプット − 脅威と脆弱性、リスクアセスメントを説明し、管理策導入の推奨事項を記載する リスクアセスメント報告書 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 25 4. リスク軽減 リスクマネジメントの 2 番目のプロセスであるリスク軽減では、リスクアセスメントプロセスで推奨された適切 なリスク低減管理策の優先順位付け、評価、導入を行う。 あらゆるリスクを排除することは通常非現実的であり、ほとんど不可能であることから、経営陣ならびに中 間管理職は、組織の資源やミッションに対する悪影響を最小限に保ちつつミッションにかかわるリスクを許容 レベルにまで低減するために、最もコストのかからない手法を用いて、最も適した管理策を導入する責任を負 う。 この節ではリスク軽減の選択肢 (第 4.1 節)、リスク軽減戦略 (第 4.2 節)、管理策導入のアプローチ (第 4.3 節)、管理策の分類 (第 4.4 節)、推奨管理策の導入を正当化するための費用対効果分析 (第 4.5 節)、残 存リスク (第 4.6 節) について説明する。 4.1 リスク軽減の選択肢 リスク軽減は経営陣がミッションにかかわるリスクを軽減するために用いる系統的な手法である。リスク軽 減は以下の選択肢のいずれを用いても実現可能である。 • リスク受容： 潜在的リスクを容認し、IT システムの運用を続けるか、あるいは許容レベルにまでリスクを 低減するための管理策を導入する。 • リスク回避： リスクの要因か結果のどちらか、もしくはその両方を排除することによりリスクを回避する (例えば、リスクが特定された場合、システムのある機能の実施を見送るかシステムをシャットダウンする など)。 • リスク制限： 脅威によって脆弱性が悪用されることで生じる悪影響を最小限に抑える管理策を導入して リスクを制限する (例えば、サポート、予防、検知を行う管理策の活用など)。 • リスク計画： 管理策の優先順位付け、導入、維持を行うリスク軽減計画を作成してリスクを管理する。 • 調査と認知： 脆弱性または欠陥を認知し、脆弱性を是正する管理策を調査することにより損失リスクを 低減する。 • リスク移転： 保険契約など損失を補填する他の選択肢を用いることによりリスクを移転する。 これらリスクを軽減する選択肢のいずれを選ぶ場合も、組織の目標やミッションを考慮すべきである。見つ け出されたリスクすべてに対処することは現実的ではないため、ミッションに対する重大な影響または被害を もたらす可能性のある脅威と脆弱性の組合せを優先させなければならない。さらに、組織のミッションや IT シ ステムを保護する際、リスク軽減に用いる選択肢、及び管理策導入の手法は、各組織固有の環境や目的に よってそれぞれ異なる場合がある。「最も優れた」アプローチは、さまざまなベンダーによるセキュリティ製品の 中から適切な技術を、適切なリスク軽減選択肢や非技術的な管理的手法と共に使用することである。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 26 4.2 リスク軽減戦略 潜在的リスクと推奨管理策を認識しているミッション遂行の責任者である経営陣は、いつどのような状況で 行動を起こすべきなのか、これらのリスクを軽減し自らの組織を保護する管理策をいつ導入すべきなのかと いう疑問を持つであろう。 図 4-1 に示すリスク軽減チャートがこれらの疑問に対する答えである。この図では、管理策を実行するのに 適したポイントを YES で示している。 脅威源 YES システム 設計 脆弱か？ つけ YES こまれる 可能性が あるか ？ NO NO リスクなし リスクなし リスク が存在 する 攻撃者 のコスト ＜利益 攻撃の対象と なる脆弱性が 存在する YES YES 予想損失 ＞閾値 NO NO リスク容認 リスク容認 容認でき ないリスク 図 4-1 リスク軽減アクションのポイント 次の経験則ではこの戦略がさらに明確化されており、故意の人的脅威によるリスクを軽減する際のガイダ ンスとなる。 • 脆弱性 (あるいは欠陥、弱点) が存在する場合 Î 脆弱性を悪用される可能性を低減する手法を導入 する。 • 脆弱性を悪用される可能性がある場合 Î 多層保護、アーキテクチャ設計、運用的管理策を適用する ことにより脆弱性を悪用されないようにするか、あるいは悪用されるリスクを最小限に抑える。 • 攻撃に要するコストが、攻撃によって得られる利益より少ない場合 Î 攻撃に要するコストを増大させ攻 撃者の意図をくじくような保護を適用する (例えば、システム利用者のアクセスや操作を制限するシステ ム管理策を適用することにより攻撃者の利益を大幅に低減することができる)。 • 損失があまりに大きい場合 Î 攻撃範囲の拡大を制限する設計原理、アーキテクチャ設計、技術的・非 技術的保護を適用することにより損失の潜在的な発生を低減する。 上に概略を示した戦略は、3 番目に記したもの (攻撃に要するコストが、攻撃によって得られる利益より少 ない場合) を除き、環境的脅威あるいは無作為の人的脅威 (例えば、システムや利用者のエラーなど) に よってもたらされるリスクの軽減にも適用できる。(攻撃者がいないので、動機や利益も生じない。) Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 27 4.3 管理策導入のアプローチ 管理策を導入しなければならない場合は、次の規則が適用される。 最も重大なリスクに対処し、コスト及び他のミッションに関わる機能に対する影響を最小限に保ちつつ、十分 にリスクを軽減できるように努める。 以下のリスク軽減手法は管理策導入に対するアプローチを示している。 • ステップ 1 − アクションの優先順位付け リスクアセスメント報告書に記されたリスクレベルに基づいて実行すべきアクションの優先順位付けを行 う。資源割当てにおいては、許容できないほど高いリスクレベル (例えば、「非常に高い」あるいは「高 い」リスクレベルに指定されたリスクなど) の項目を最優先にすべきである。これら脆弱性／脅威の組合 せに対しては、組織の利益とミッションを守るため直ちに是正措置を取る必要がある。 ステップ 1 のアウトプット − 実行すべきアクションの「高」から「低」までの優先順位付け • ステップ 2 − 推奨管理策の評価 リスクアセスメントプロセスにおいて推奨された管理策は、特定の組織あるいは IT システムに対して最 適または実現可能な選択肢ではない場合がある。このステップでは、推奨管理策の実現性 (例えば、互 換性、利用者による受入れなど) や有効性 (例えば、保護の度合い及びリスク軽減レベルなど) を分析 する。目標はリスクを最小化する最適な管理策を選択することである。 ステップ 2 のアウトプット − 実現可能な管理策のリスト • ステップ 3 − 費用対効果分析の実施 経営陣が意思決定をする際の助けとするため、また、費用対効果の高い管理策を特定するため、費用 対効果分析を実施する。第 4.5 節では費用対効果分析実施の目的と手法について詳述する。 ステップ 3 のアウトプット − 管理策を導入すること、あるいは導入しないことによるコストと利益を明ら かにする費用対効果分析 • ステップ 4 − 管理策の選択 費用対効果分析結果に基づいて、経営陣は組織のミッションに対するリスクを低減する最も費用対効果 の高い管理策を選択する。IT システムと組織にとって適したセキュリティとなるように、選択する管理策 は技術、運用、管理の要素を組み合わせたものにすべきである。 ステップ 4 のアウトプット − 選択した管理策 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 28 • ステップ 5 − 責任の割当て 選択した管理策を導入するために適切な専門知識とスキルを有する要員 (組織内部の要員あるいは外 部の契約スタッフ) を特定し、責任の割り当てを行う。 ステップ 5 のアウトプット − 責任者のリスト • ステップ 6 − 管理策導入計画の作成 このステップでは管理策導入計画9 (または実行計画) を作成する。この計画には少なくとも以下の情報 を含めるべきである。 − リスク (脆弱性／脅威の組合せ) 及び関連付けられたリスクレベル (リスクアセスメント報告書から のアウトプット) − 推奨管理策 (リスクアセスメント報告書からのアウトプット) − 優先順位付けされたアクション (｢非常に高い」及び「高い」リスクレベルで優先順位付けされたも の) − 選択、計画中の管理策 (実現可能性、有効性、組織への利益、コストに基づいて決定する) − 選択、計画中の管理策を導入するために必要な資源 − 責任を有するチーム及び要員のリスト − 導入開始日 − 導入完了予定日 − 保守要件 管理策導入計画では実行に移すべき行為の優先順位付けを行い、開始及び完了予定の日付を明らか にする。この計画によりリスク軽減プロセスを支援し促進する。付録 C に管理策導入計画の一覧表のサ ンプルを示す。 ステップ 6 のアウトプット − 管理策導入計画 • ステップ 7 ⎯ 選択した管理策の導入 個々の状況によっては、管理策の導入によりリスクレベルは低減されても、リスクは排除されない場合が ある。第 4.6 節では残存リスクについて述べる。 ステップ 7 のアウトプット − 残存リスク 図 4-2 にリスク軽減のための推奨手法を図示する。 9 NIST Interagency Report 4749, Sample Statements of Work for Federal Computer Security Services: For Use In-House or Contracting Out. December 1991 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 29 インプット リスク低減アクティビティ ステップ 1. 行為の優先順位付け • リスク評価報告に よるリスクレベル ステップ 2. 推奨管理策の評価 • リスクアセスメ ント報告 アウトプット 行為の「高」∼ 「低」の順位付け 実現可能な管理策 のリスト • 実現可能性 • 有効性 ステップ 3. 費用対効果分析の実施 費用対効果分析 • 導入することによる影響 • 導入しないことによる影響 • 関連コスト ステップ 4. 管理策の選択 ステップ 5. 責任の割当て 選択された管理策 責任者のリスト ステップ 6. 管理策導入計画の作成 • • • • • • • • 管理策導入計画 リスク及び関連するリスクレベル 優先順位の高いアクション 推奨管理策 選択、計画中の管理策 責任者 開始日 完了予定日 保守要件 ステップ 7. 選択した管理策の導入 残存リスク 図 4-2 リスク軽減手法のフローチャート Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 30 管理策の分類 4.4 リスク軽減のための推奨管理策の導入にあたり、組織は自らの IT システムと組織にとって最も有効な管 理策を実施できるように、技術的、管理的、運用的セキュリティ管理策について、もしくはこれらの組合せにつ いて検討すべきである。セキュリティ管理策を適切に利用すれば、脅威源がもたらす組織のミッションへの影 響を防止、制限、抑制することができる。 管理策を推奨するプロセスでは、組織のセキュリティ体制を向上する技術的、管理的、運用的管理策を組 合せたものを選択する。組織が検討すべきトレードオフは、例えばパスワード推測やクラッキングを最小限に 抑えるために複雑なパスワードの使用を利用者に義務付けるという決定からも見て取れる。この場合、アドオ ンのセキュリティソフトウェアを必要とする技術的管理策は、手順による管理策よりも複雑で高価なものになる 可能性があるものの、システムが自動的に実施するため、より効果的であることが多い。一方、手順による管 理策の場合、関係者全員に宛てた通達や組織のセキュリティガイドラインの変更のみで導入できるが、利用 者がこの通達とガイドラインに常に従うようにするのは困難であり、セキュリティ意識向上トレーニングの実施 や、変更が利用者によって受け入れられることも必要となる。 この節では管理策分類のいくつかを高いレベルから概観する。IT 管理策の導入及び計画に関するより詳 細なガイドラインは NIST SP 800-18 Guide for Developing Security Plans for Information Technology Systems （連邦情報システムのためのセキュリティ計画作成ガイド）ならびに NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook（コンピュータセキュリティ：NIST ハンドブック）に記載されている。 第 4.4.1 節から第 4.4.3 節では、それぞれ技術的、管理的、運用的管理策について概観する。 4.4.1 技術的セキュリティ管理策 ある種の脅威より保護するために、リスク軽減のための技術的セキュリティ管理策を設定できる。この管理 策には簡単なものから複雑なものまであり、通常、システムアーキテクチャ、エンジニアリング規約、ハード ウェア、ソフトウェア、ファームウェアを取り混ぜたセキュリティパッケージなどが含まれる。重要かつ機密性の 高いデータ、情報、IT システム機能を保護するには、これらの手段すべてが連携して機能する必要がある。 技術的管理策は主要目的に従って主に以下のカテゴリーに分けられる。 • サポート (第 4.4.1.1 節)： この管理策は一般的なものであり、ほとんどの IT セキュリティ機能の基礎と なっている。他の管理策を導入するには、この管理策を設定しておかなければならない。 • 予防 (第 4.4.1.2 節)： この予防管理策では、セキュリティ侵害が発生しないようにその防止に注力す る。 • 検知と回復 (第 4.4.1.3 節)： この管理策では、セキュリティ侵害を検知し、回復することに注力する。 図 4-3 に主な技術的管理策やそれらの間の関係を図示する。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 31 予防 トランザクション のプライバシー 否認防止 認証 利用者 または プロセス 検知、回復 サポート 許可 監査 アクセス 制御実施 資源 完全性証明 侵入検知及び 封じ込め 状態復帰 保護された通信 (開示、置換え、改変、及びリプレイ攻撃を受けない) 識別 暗号鍵管理 セキュリティ管理 システム保護 (最小特権、オブジェクト再利用、プロセス分離など) 図 4-3 技術的セキュリティ管理策 4.4.1.1 サポートのための技術的管理策 サポートのための管理策は、その性質そのもののために広く普及し、他の多くの管理策と関連する。サ ポートのための管理策は次のようなものである。 • 識別： この管理策によって利用者、プロセス、情報資源を一意に識別できるようになる。他のセキュリ ティ管理策 (例えば任意アクセス制御［DAC：Discretionary Access Control］、強制アクセス制御［MAC： Mandatory Access Control］、アカウンタビリティなど) を導入するにはサブジェクト（訳者注：アクションを 起こす人や物）とオブジェクト（訳者注：アクションを受ける人や物）の両方が明確であることが不可欠で ある。 • 暗号鍵管理： 暗号機能を他のさまざまな管理策に導入する場合には、暗号鍵を安全に管理しなければ ならない。暗号鍵管理には鍵の生成、配布、保存、及び保守などが含まれる。 • セキュリティ管理運用： IT システムのセキュリティ機能は、個別インストールの必要性を満たし、運用環 境の変更に責任を持つように設定 (例えば、セキュリティ機能の有効化または無効化) しなければなら ない。システムセキュリティはオペレーティングシステムセキュリティまたはアプリケーションに組み込むこ とができる。市販のアドオン型セキュリティ製品も利用可能である。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 32 • システム保護： システムのさまざまなセキュリティ機能の基礎となっているものは、その技術の導入に 対する信頼である。この信頼の基となるのは、使用した設計プロセスや実装を実現する方法の両方の観 点から見た実装の品質である。システム保護の例としては、残存情報保護 (オブジェクト再利用とも呼ば れる)、最小特権 (あるいは "need to know"：知るべき人にだけ知らせる原則)、プロセス分離、モジュー ル化、多層化、信頼性確保を要する事項の最小化などがある。 4.4.1.2 予防のための技術的管理策 セキュリティポリシー違反の試みを阻止するための管理策には次のようなものがある。 • 認証： 認証管理は、ある対象が主張する本人情報が正当であることを確認するために、その本人情報 を検証する方法を提供する。認証メカニズムには、パスワード、個人識別番号、PIN、または強力な認証 が得られる新しい認証技術 (例えば、トークン、スマートカード、デジタル認証、Kerberos など) がある。 • 承認： 承認管理は、所定のシステムに対して許される行動の規定やその後の管理を可能にする (例え ば、オンライン利用者グループがアクセスする共有ファイルの更新を誰に許可するのかを、情報所有者 またはデータベース管理者が決定する場合など)。 • アクセス制御の導入： データの完全性と機密性はアクセス制御によって確保される。ある主体の要求に より特定のプロセスへのアクセスが許可される場合、定められたセキュリティポリシー (例えば、MAC あ るいは DAC など) に基づいて許可される必要がある。これらの方針に基づいた管理はシステム全体に 行き渡ったアクセス制御メカニズムによって実施される (例えば MAC 機密ラベル、DAC ファイル許可 セット、アクセス制御リスト、役割、ユーザプロファイルなど)。アクセス制御の有効性と強度は、アクセス 制御判断の正確さ (例えば、セキュリティ規則の実装の度合いなど) とアクセス制御強制力の強さ (例 えば、ソフトウェアまたはハードウェアセキュリティの設計など) に依存する。 • 否認防止（Nonrepudiation）： システムアカウンタビリティは、送信者が情報を送信したことを否認でき ず、受信者がその情報を受信したことをを否認できないようにする機能に依存する。否認防止は防止と 検知の両方にまたがるものである。このガイドでは防止に分類されているが、それは導入されるメカニズ ムがある行為の否認を防止するものだからである (例えば、所有者の秘密鍵を含むデジタル証明書は 所有者にしかわからないなど)。したがって、この管理策は通常送信または受信を行う時点で適用され る。 • 保護された通信： 分散システムにおいてセキュリティ目標が達成できるかどうかは、信頼性の高い通信 であるかどうかに大きく依存する。機密性が高く重要な情報が伝達される際、その情報の完全性、可用 性、機密性は、保護された通信管理によって確保される。保護された通信では、リプレイ攻撃、傍受、パ ケットスニフィング、盗聴、あるいは通信傍受などのネットワークの脅威を最小化するために、データ暗号 化手段 (例えば、仮想プライベートネットワーク[VPN：Virtual Private Network]、インターネットプロトコル セキュリティ［IPSEC］プロトコルなど) を用い、暗号化技術 (例えば、DES、トリプル DES、RAS、MD4、 MD5、セキュアハッシュ標準、及び Clipper のようなエスクロー暗号アルゴリズムなど) を利用する。 • トランザクションのプライバシー： 行政及び民間の両部門において個人のプライバシー保護がますま す求められるようになっている。トランザクションのプライバシー管理策 (例えば、SSL[Secure Socket Layer]、セキュアシェルなど) は個人が実行するトランザクションにおいてプライバシーが失われることを 防ぐ。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 33 4.4.1.3 検知と回復のための技術管理策 検知のための管理策とはセキュリティポリシーに対する違反または違反の試みを警告するものであり、監査 証跡、侵入検知手法、チェックサムなどがこれに含まれる。回復のための管理策は失われたコンピューティン グ資源を回復するために利用される。検知と回復のための管理策は、サポートや予防のための技術的対策 を補完するために必要とされる。なぜなら、サポートや予防の領域における対策はいずれも完全ではないた めである。検知及び回復管理策には以下のものが含まれる。 • 監査： セキュリティ関連事象の監査や、システム異常の監視と追跡は、セキュリティ侵害の検知と侵害 からの回復において重要な要素となる。 • 侵入検知と封じ込め： セキュリティ侵害 (例えば、ネットワーク侵入、疑わしいアクティビティなど) の検 知は、これらにタイムリーに対処するために不可欠である。ただし、効果的な対応策を取れなければ、セ キュリティ侵害を検知してもほとんど役に立たない。侵入検知と封じ込め管理策は、これら検知と対応の 2 つの能力を備えている。 • 完全性証明： 完全性証明のための管理策 (例えば、システム完全性ツールなど) では、システムの完 全性と異常を分析し、弱点の露出及び潜在的脅威を特定する。この管理策ではセキュリティポリシー違 反を防止することはできないが、違反を検知し必要な是正措置の種類を決定する助けとなる。 • 安全な状態への復帰： セキュリティ侵害発生後、システムはこのサービスにより安全であることが確認 されている状態に復帰できる。 • ウイルス検知及び駆除： サーバ及び利用者のワークステーションにインストールされたウイルス検知及 び駆除ソフトウェアはソフトウェアウイルスを検知、識別、駆除し、システムとデータの完全性を確保す る。 4.4.2 管理的セキュリティ管理策 損失リスクを管理、低減し、組織のミッションを遂行するために、技術及び運用的管理策とともに管理的セ キュリティ管理策を導入する。管理的セキュリティ管理策は情報保護ポリシー、ガイドライン、標準の規定に注 力する。これらは運用手順を通して実行され、組織の目標とミッションの達成を支える。 リスク低減のために導入する予防、検知、回復のための管理的セキュリティ管理策については、第 4.4.2.1 節から第 4.4.2.3 節で説明する。 4.4.2.1 予防のための管理的セキュリティ管理策 この管理策には以下が含まれる。 • 基幹 IT システムに対して適切なセキュリティが施されるようにセキュリティに対する責任を割り当てる。 • 組織のミッションをサポートする IT システムに対する現在の管理策を文書化し、計画中の管理策を実施 するために、システムセキュリティ計画を作成し、保守する。 • 職務の分離、最小特権、コンピュータ利用者のアクセス権登録と抹消を含む要員セキュリティ管理策を 導入する。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 34 • エンドユーザやシステム利用者に行動規則と組織のミッション達成に対する責任を認識させるためにセ キュリティ意識向上活動や技術トレーニングを実施する。 4.4.2.2 検知のための管理的セキュリティ管理策 この管理策は以下のとおりである。 • 要員の身上調査及び身元調査、職務のローテーションなどの要員に対するセキュリティ管理策を導入す る。 • 管理策が有効であることを確認するために定期的にセキュリティ管理策をレビューする。 • 定期的なシステム監査を行う。 • リスクを評価、軽減するために継続的リスクマネジメントを行う。 • IT システムを認可し、残存リスクを処理し容認する。 4.4.2.3 回復のための管理的セキュリティ管理策 この管理策には以下が含まれる。 • 緊急時あるいは災害時の運用継続性の確保やビジネスの再開に備え、継続的なサポートを提供し、運 用継続計画を開発、テスト、維持する。 • インシデント対応能力を確立し、インシデントの際には、検知、報告、対応により IT システムを運用でき る状態に復帰させることができるよう準備する。 4.4.3 運用的セキュリティ管理策 組織のセキュリティ標準を策定し、、組織の IT 資産や資源の利用を統制するセキュリティ手順が適切に実 施され、組織の目標とミッションに従って導入されていることを確認するための一連の管理策とガイドラインを 確立する。管理者は、ポリシーの導入を監督し、適切な運用的管理策を確立する上で重要な役割を果たす。 運用管理策は、基本的要件（例えば技術的管理策など）と優れた業界プラクティスに従って導入されたもの であり、潜在的脅威源に悪用される恐れのある運用上の欠陥を是正するために用いる。セキュリティ運用の 一貫性と均一性を確保するために、運用的管理策を導入する段階的な手順と手法を明確に規定、文書化、 保守する必要がある。これら運用的管理策には下記の第 4.4.3.1 節及び第 4.4.3.2 節に示したものなどがあ る。 4.4.3.1 予防のための運用的管理策 予防のための運用的管理策は以下のとおりである。 • データ媒体へのアクセスやデータ媒体の廃棄を管理する (例えば、物理的アクセス管理、消磁手法な ど)。 • 外部データ配布を制限する (例えば、ラベル付けの利用など)。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 35 • ソフトウェアウイルスを管理する。 • コンピュータ施設を保護する (例えば、警備員、来客に対する応対手順、電子バッジシステム、バイオメ トリクスアクセス制御、錠と鍵の管理と配布、防壁や柵など)。 • ハブとケーブルを収納した配線盤を保護する。 • バックアップ機能を提供する (例えば、データとシステムの定期的なバックアップ手順、さまざまな回復シ ナリオで使用するためにデータベースのあらゆる変更を記録したアーカイブログなど)。 • オフサイトストレージに関する手順及びセキュリティを確立する。 • ラップトップ、パーソナルコンピュータ (PC)、ワークステーションを保護する。 • IT 資産を火災の被害から守る (例えば、消火器使用に対する要件と手順、防水シート、ドライスプリンク ラーシステム、ハロン消火システムなど)。 • 非常用電源を確保する (例えば、無停電電源、オンサイト発電機の要件など)。 • コンピュータ施設の湿度と温度を管理する (例えば、空調装置の運転、熱分散など)。 検知のための運用的管理策 4.4.3.2 検知のための運用的管理策には以下が含まれる。 • 物理的セキュリティを導入する (例えば、動作検知装置、閉回路テレビによる監視、センサとアラームの 利用など)。 • 環境面のセキュリティを確保する (例えば、煙探知器、火災探知器、センサとアラームの利用など)。 費用対効果分析 4.5 資源を割り当て、費用対効果の高い管理策を導入するために、組織は利用可能な管理策すべてを特定し、 それらの実現可能性と有効性を評価した後、提案された管理策それぞれについて費用対効果分析を行った 上で、どの管理策が現在の状況に対して必要とされ適したものであるかを判断する。 費用対効果分析には定性的なものと定量的なものがある。その目的は、管理策の導入コストをリスクレベ ルの低減によって正当化できることを実証することである。例えば、200 ドル相当のリスクを低減するための 管理策に 1,000 ドルを費やそうという組織はないであろう。 新たに提案された管理策や強化された管理策の費用対効果分析において行うことは以下のとおりである。 • 新規または強化された管理策を導入することによる影響を判断する。 • 新規または強化された管理策を導入しないことによる影響を判断する。 • 導入コストを推定する。コストには次のようなものがあるが、これに限定されるわけではない。 − ハードウェアとソフトウェアの購入 − セキュリティを向上させることによりシステム性能または機能が低下した場合の運用効率の低下 − ポリシーと手順を追加することによるコスト Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 36 • − 提案された方針、手順やサービスを導入するための追加要員採用のコスト − トレーニングコスト − 保守コスト 導入コストと利益を、システムやデータの重要度に照らして評価し、コストと相対的影響を前提に組織に とっての新規管理策導入の重要性を判断する。 組織は、ミッション遂行の全体像を考慮した上で、管理策によって得られる利益を評価する必要がある。必 要な管理策を導入することによるコストが存在するのと同様に、導入しないことによるコストも存在する。管理 策を導入しないことによるミッションへの影響を考えれば、導入を見送ることができるかどうかを判断できる。 費用対効果分析の例：システム X はミッションにとって重要かつ機密性の高い従業員のプライバシー情報を 保存し処理するものであるが、現在システム監査はできない状態である。システム X に監査機能を持たせる べきかどうかを判断するために費用対効果分析を行う。 項目 (1) 及び (2) は新規管理策を導入するか、あるいは導入しないことによる、無形の影響 (例えば、抑 止要因など) である。項目 (3) には有形の影響を列挙した (例えば、実際のコストなど)。 (1) システム監査機能を持たせる場合の影響：システム監査機能によりセキュリティ管理者は利用者のシ ステムアクティビティを監視できるようになるが、システム性能を低下させ、このため利用者の生産性が 影響を受ける。また、導入のために項目 (3) に示す資源がさらに必要となる。 (2) システム監査機能を持たせない場合の影響：システム監査機能が働かない場合、利用者のシステム 利用状況や違反の監視／追跡ができなくなり、組織の機密データやミッションに対する最大限の保護 が得られなくなる。 (3) システム監査機能を持たせる場合のコスト推定： システム監査機能の有効化 − 組み込み済み機能のためコストはかからない 監査レビューとアーカイブを担当する要員追加 トレーニング (例えば、システム監査設定、報告書生成) 監査報告書生成用のアドオンソフトウェア 監査データ保守 (例えば、ストレージ、アーカイブ) 0 ドル XX,XXX ドル／年 X,XXX ドル X,XXX ドル X,XXX ドル／年 推定総コスト XX,XXX ドル 組織の管理者は何がミッションに関連するリスクの許容レベルを規定するのかを判断しなければならない。 その後、組織が実現可能なリスクレベルの範囲を判断した後、管理策を採用または棄却することによる影響 を評価できる。ただし、この範囲は組織ごとに異なり新規管理策適用の判断には以下の規則を適用する。 • 管理策によるリスク低減が必要とされる以上であれば、より安価な代替案がないか検討する。 • リスク低減がもたらすものよりも管理策コストの方が大きい場合は、他の方法を検討する。 • 管理策が十分にリスクを低減しない場合は、さらに管理策を追加するか、別の管理策を探す。 • 管理策によって十分にリスクが低減され、費用対効果が高い場合は、その管理策を採用する。 管理策を導入するコストは導入しないコストよりも実体としてとらえやすいことが多い。したがって、経営陣 は組織のミッション遂行のための管理策の導入に関する意思決定において重要な役割を果たす。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 37 4.6 残存リスク 組織は、新規または強化された管理策によって得られたリスク低減の程度を、組織のミッションに対するリ スク軽減レベルを規定する 2 つのパラメータ（脅威の発生可能性の低減と脅威の影響の低減）という観点か ら分析できる。 新規または強化された管理策を導入すると以下の方法でリスクを軽減できる。 • システム脆弱性 (欠陥や弱点) のうち、幾つかを排除することにより、脅威源と脆弱性の組合せ可能数 を低減する。 • 目標を絞った管理策を適用し、脅威源の能力と動機を低下させる。 例えば、ある部門が、機密性の高いファイルを保存するスタンドアローン PC にアドオン型のセキュリティ ソフトウェアをインストールし、保守するコストを正当化できないものの、この PC へのアクセスをより困難 にする管理的、物理的管理策 (例えば、PC を鍵のかかる部屋に保管し、その鍵を管理者が管理するな ど) は導入すべきと判断する場合などである。 • 影響の度合いを低減する (例えば、脆弱性の度合いを制限する、あるいは IT システムと組織のミッショ ンの関係を変更するなど)。 管理策導入と残存リスクの間の関係を図式化したものを図 4-4 に示す。 欠陥または エラー数の低減 新規または 強化された管理策 目標を絞った 管理策の適用 残存リスク 影響の度合いの低減 図 4-4 導入する管理策と残存リスク 新規または強化された管理策の導入後に残るリスクが残存リスクである。実際にリスクの全くない IT シス テムはなく、導入した管理策全てが意図したリスクを排除したり、リスクレベルをゼロにまで低減してくれるわ けではない。 OMB Circular A-130 に規定されるように、組織の IT 資産とミッションを保護する責任を有する経営陣また は指定承認者は、IT システムの運用開始または継続を認可 (または承認) しなければならない。この認可ま たは承認は少なくとも 3 年ごと、あるいは IT システムに大幅な変更が加えられるたびに実施しなければなら ない。このプロセスの意図は IT システム内の完全に対処されていないリスクを特定し、これを軽減するため に更に管理策が必要かどうかを判断することである。連邦機関の場合、特定されたリスクに対する適切な管 理策を適用後、指定承認者が残存リスクの全てを容認するステートメントに署名し、新しい IT システムの運 用あるいは既存 IT システムの継続運用を許可する。残存リスクが許容レベルにまで低減されていない場合、 低減する方法を見出すためにリスクマネジメントサイクルを再度実施しなければならない。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 38 5. 評価とアセスメント ほとんどの組織では、ネットワークそのものの拡張と更新が継続的に行われ、そのコンポーネントは変更を 加えられ、ソフトウェアアプリケーションは新しいバージョンに置換または更新される。さらに要員の異動も発 生し、セキュリティ方針も時間とともに変わる可能性が高い。これらの変更は、新たなリスクが顕在化し、以前 軽減されたリスクが再度懸念事項となる可能性があることを意味している。このため、リスクマネジメントプロ セスは継続的で進化し続けるものである。 この章では、実践すべき優れた手法、継続的なリスク評価とアセスメントの必要性、リスクマネジメントプロ グラムを成功に導く要因に重点を置いて説明する。 5.1 優れたセキュリティ実践手法 連邦機関の場合、OMB Circular A-130 に従い、リスクアセスメントプロセスを通常少なくとも 3 年ごとに繰り 返す。しかしながら、リスクマネジメントは、法律または規制によって要求されるからではなく、それが実践すべ き優れた手法であり、組織のビジネス目標またはミッションをサポートするものであることから、IT システムの システム開発ライフサイクルに組み入れ、実施すべきである。ミッションに関連するリスクの評価、低減のため に具体的日程を設定すべきである。ただし、定期的に実施するプロセスは、ポリシーあるいは新技術によって もたらされる IT システムやその処理環境に対する大幅な変更に対処できるように、十分に柔軟であるべきで ある。 5.2 成功の鍵 リスクマネジメントプログラムの成功は以下の要因に依存する (1) 経営陣の責任、(2) IT チームの全面的 サポートと参画 (第 2.3 節参照)、(3) リスクアセスメントチームの能力。チームはリスクアセスメント手法を特 定のサイトやシステムに適用し、ミッションに関連するリスクを特定し、組織のニーズに合った費用対効果の高 い保護手段を提供するための専門知識を備えていなければならない。(4) 利用者コミュニティメンバの認識と 協力。メンバは手順を守り組織のミッションを保護するために導入された管理策を順守しなければならない。 (5) IT のミッションに関連するリスクに対する継続的評価とアセスメント。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page 39 付録 A：インタビュー時の質問例 インタビューにおける質問は評価対象の IT システムが属するシステム開発ライフサイクルのフェーズに合 わせて調整すべきである。組織の運用特性を理解するためにサイト要員に対するインタビューを行う際、尋ね るべき質問には次のようなものがある。 • 正当な利用者は誰ですか。 • あなたの組織のミッションは何ですか。 • ミッションとの関係におけるシステムの目的は何ですか。 • あなたの組織のミッションにとってシステムはどれくらい重要ですか。 • システム可用性の要件は何ですか。 • 組織が必要とする情報 (入力と出力の両方) はどのようなものですか。 • システムが生成、利用、処理、保存、取得する情報はどのようなものですか。 • あなたの組織のミッションにとってその情報はどれくらい重要ですか。 • 情報が流れる経路はどのようなものですか。 • システムが処理、保存する情報はどのような種類のものですか (例えば、財務、人事、研究開発、医 療、指揮統制など)。 • 情報の機密度 (または分類体系) はどのようなものですか。 • システムが処理する情報あるいはシステムに関する情報のうち開示すべきでないものはどのようなもの ですか。また、開示すべきでない相手は誰ですか。 • 情報を処理、保存する具体的な場所はどこですか。 • 情報を格納するストレージの種類は何ですか。 • 許可されない者に情報が開示された場合の組織に対する潜在的影響はどのようなものですか。 • 情報の可用性と完全性に対する要件は何ですか。 • システムまたは情報に対する信頼性を得られない場合の組織のミッションに対する影響はどのようなも のですか。 • 組織が許容できるシステムダウンタイムはどれくらいですか。このダウンタイムの平均修復／ 回復時間 に対する割合はどれくらいですか。利用者が使用できる他の処理手段または通信手段の選択肢にはど のようなものがありますか。 • システムやセキュリティの誤動作、あるいはこれらを利用できないことで、傷害または死を招く可能性が ありますか。 Copyright © 2005 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page A-1 付録 B：リスクアセスメント報告書サンプル（アウトライン） エグゼクティブサマリ I. 序論 • • 目的 本リスクアセスメントの適用範囲 システムコンポーネント、要素、利用者、現場サイトの場所 (存在する場合)、評価時に検討すべきシステ ムに関するその他の詳細すべてについて記述する。 II. リスクアセスメントのアプローチ リスクアセスメントの実施にあたって用いるアプローチについて例えば次のように略述する。 • • • 担当者 (例えば、リスクアセスメントチームのメンバなど) 情報収集に用いる手法 (例えば、ツール、アンケートの利用など) リスク尺度の作成と説明 (例えば、3 × 3、4 × 4、5 × 5 のリスクレベルマトリクスなど) III. システムの特徴定義 ハードウェア (サーバ、ルータ、スイッチ)、ソフトウェア (例えば、アプリケーション、オペレーティングシス テム、プロトコルなど)、システムインタフェース (例えば、通信リンクなど)、データ、利用者などを含むシ ステムの特徴定義を行う。接続図やシステム入出力フローチャートを示し、このリスクアセスメント作業の 適用範囲を線引きする。 IV. 脅威ステートメント 評価対象システムに当てはまる潜在的脅威源とそれに伴う脅威行動を収集編纂しリストを作成する。 V. リスクアセスメント結果 観察結果 (脆弱性／ 脅威の組合せ) のリストを示す。各観察結果は以下の項目を含んでいなければ ならない。 • • • • • • • 観察番号と観察結果の簡単な説明 (例えば、観察結果 1：利用者システムパスワードを推定また はクラッキングできる、など) 脅威源と脆弱性の組合せに関する説明 既存のリスク軽減管理策の特定 脅威の発生可能性に関する説明及び評価 (例えば、高、中、低レベルの可能性など) 影響分析に関する説明及び評価 (例えば、高、中、低レベルの影響など) リスクレベルマトリクスに基づいたリスクレベルの決定 (例えば、高、中、低のリスクレベルなど) リスク低減のための推奨管理策や代替管理策 VI. まとめ 観察結果の総まとめ。リスク軽減プロセスにおける推奨管理策の導入を促進するため、観察結果、対応 するリスクレベル、推奨事項、任意のコメントを表形式にまとめる。 Copyright © 2005 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page B-1 付録 C：管理策導入計画一覧表（サンプル） (1) リスク (脆弱性／脅威 の組合せ) 許可されない利 用者がサーバ XYZ に telnet し、guest ID を用 いて機密に関す る会社のファイル を閲覧する。 (1) (2) (3) (4) (5) (6) (7) (8) (9) (2) リスク レベル 高 (3) 推奨管理策 • インバウンドの telnet を禁止する。 • 機密に関する会社の ファイルに対しては 「ワールド」アクセス を禁止する。 • 'guest' ID を無効にす るか、推定の困難な パ ス ワ ー ド を割 り 当 てる。 (4) アクションの 優先順位 高 (5) 選択され計画中 の管理策 (6) 必要な資源 • インバウンド の telnet を禁 止する。 • 機密に関する 会社のファイ ルに対しては 「ワールド」ア クセスを禁止 する。 • guest ID を無 効にする。 システムの再構 成及びテストに かかる時間は 10 時間 (7) 責任を有する チーム／ 担当者 (8) 開始日／ 完了日 (9) 保守要件／ コメント サ ー バ XYZ 9-1-2001∼ • サーバ XYZ に 9-2-2001 対して適切なセ の管理者 キュリティが設定 John Doe、 会社のファイ されていることを 確認するために アウォール 管理者 定期的にシステ Jim Smith ムセキュリティレ ビューとテストを 実施すること。 リスク (脆弱性／脅威の組合せ) はリスクアセスメントプロセスのアウトプットである。 特定された各リスク (脆弱性／脅威の組合せ) に関連付けられたリスクレベルはリスクアセスメントプロセスのアウトプットである。 推奨管理策はリスクアセスメントプロセスのアウトプットである。 対策の優先順位はリスクレベルと利用可能な資源 (例えば、資金、要員、技術など) に基づいて決定する。 計画中の管理策は導入を推奨された管理策の中から選択する。 選択され計画中の管理策を導入するために必要な資源 新規または強化された管理策の導入に責任を持つチームまたは要員のリスト 新規または強化された管理策導入の開始日及び予想完了日 新規または強化された管理策導入後の保守要件 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page C-1 付録 D：略語 AES Advanced Encryption Standard (次世代暗号化標準) CSA Computer Security Act (コンピュータセキュリティ法) DAA Designated Approving Authority (指定承認者) DAC Discretionary Access Control (任意アクセス制御) DES Data Encryption Standard (データ暗号化標準) FedCIRC Federal Computer Incident Response Center (連邦コンピュータインシデント対応センター) FTP File Transfer Protocol (ファイル転送プロトコル) ID Identifier (識別子) IPSEC Internet Security Protocol (インターネットセキュリティプロトコル) ISSO Information system security officer (情報システムセキュリティ責任者) IT Information Technology (情報技術) ITL Information Technology Laboratory (情報技術ラボラトリ) MAC Mandatory Access Control (強制アクセス制御) NIPC National Infrastructure Protection Center (国家インフラ防護センター) NIST National Institute of Standards and Technology（米国国立標準技術研究所） OIG Office of Inspector General (総括監察官室) OMB Office of Management and Budget（行政管理予算局） PC Personal Computer (パーソナルコンピュータ) SDLC System Development Life Cycle (システム開発ライフサイクル) SP Special Publication (特別刊行物) ST&E Security Test and Evaluation (セキュリティテスト及び評価) Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page D-1 付録 E：用語集 用語 定義 アカウンタビリティ (Accountability) あるエンティティのアクションをそのエンティティに対して一意に追跡する ための要件を生成するセキュリティ目標。これは否認防止、抑止、欠陥 の分離、侵入検知と防御、及びインシデント発生後の回復と法的措置の 基礎となる。 保証 (Assurance) 他の 4 つのセキュリティ目標 (完全性、可用性、機密性、及びアカウン タビリティ) が具体的な管理策の導入によって適切に満たされたという 信頼性の根拠。「適切に満たされる」という意味には以下が含まれる。 (1) 適切に動作する機能、(2) 意図的でないエラー (利用者またはソフ トウェアによる) に対する十分な保護、及び、(3) 故意の侵入または迂 回に対する十分な抵抗力。 可用性 (Availability) 以下に対処する保護手段の要件のもととなるセキュリティ目標。 • 次のような故意または偶発的な試み：(1) データの不当な削除 (2) サービス拒否またはデータ拒否 • システム資源の不当な利用 機密性 (Confidentiality) 故意または偶発的な不当なデータ読み出しに対する保護手段の要件の もととなるセキュリティ目標。機密性は保存されているデータ、処理中の データ、及び転送中のデータに適用される。 サービス妨害 (Denial of Service) 資源に対する許可されたアクセスを妨害するか、あるいは時間が重要で ある操作を遅延させること。 相当の注意 (Due Care) 管理者及びその組織は、管理策の種類、コスト、展開方法が管理策の 対象となるシステムに適していることを確実にするための情報セキュリ ティを提供する責務を有する。 完全性 (Integrity) データの完全性 (不当な方法で改変されていないデータが有する特性) またはシステムの完全性 (意図した機能が損なわれずに実行され不当 な操作を含まないシステムが有する品質) を侵害する故意または偶発 的な試みに対する保護手段の要件のもととなるセキュリティ目標。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page E-1 IT 関連リスク (IT-Related Risk) 以下を考慮したミッションに対する実質的影響：(1) 特定の脅威源によっ て特定の情報システムの脆弱性が悪用される (偶発的に衝かれるか、 故意につけこまれる) 確率、及び (2) 万一このようなことが発生した場 合にもたらされる影響。IT 関連リスクは以下の事象がもたらす法的責任 またはミッション遂行機会の損失が原因で発生する。 1. 情報の不当な (悪意のある、あるいは偶発的な) 開示、改変、ある いは破壊 2. 意図的ではないエラーまたは怠慢 3. 自然災害または人為的災害による IT システムの中断 4. IT システムの導入及び運用における相当の注意及び当然払うべき 注意の不履行 IT セキュリティ目標 (IT Security Goal) セキュリティ目標 (Security Goals) を参照。 リスク (Risk) 本文書内では IT 関連リスクと同義である。 リ ス ク ア セ ス メ ン ト Assessment) (Risk システムセキュリティに対するリスクを特定し、発生確率、もたらされる影 響、及びこの影響を軽減する保護手段追加を判断するプロセス。リスク マ ネ ジ メ ン ト (Risk Management) の 一 部 で あ り 、 リ ス ク 分 析 (Risk Analysis) と同義である。 リ ス ク マ ネ ジ メ ン ト Management) (Risk 情報システム関連リスクの特定、管理、及び軽減のための総合プロセ ス。これには、リスクアセスメント、費用対効果分析、及び保護手段の選 択、導入、テスト、及びセキュリティ評価が含まれる。この総合的なシス テムセキュリティレビューでは、ミッションに対する影響及び、方針、規 制、法律による制限を含め、有効性と効率の両方を検討する。 セキュリティ (Security) 情報システムセキュリティはシステムの特性であり、論理的及び物理的 にシステム全体にまたがる一連のメカニズムである。 セキュリティ目標 (Security Goals) 5 つのセキュリティ目標とは、完全性、可用性、機密性、アカウンタビリ ティ、及び保証である。 脅威 (Threat) 脅威源によって特定の脆弱性が悪用される (偶発的に衝かれるか、あ るいは故意に悪用される) 可能性 脅威源 (Threat-source) (1) 脆弱性を故意に悪用することを目指す意図及び手法、あるいは (2) 脆弱性が偶発的に衝かれる状況及び手法、のいずれか。 脅威分析 (Threat Analysis) 特定の運用環境下における特定のシステムに対する脅威を判断するた めに、システムの脆弱性に照らして脅威源を検討すること。 脆弱性 (Vulnerability) 悪用される (偶発的に衝かれるか、あるいは故意につけこまれる) こと によりセキュリティ侵害またはシステムセキュリティ方針違反を招く可能 性がある、システムセキュリティの手順、設計、導入、あるいは内部制御 における欠陥または弱点。 Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page E-2 付録 F：参考文献 Computer Systems Laboratory Bulletin. Threats to Computer Systems: An Overview. March 1994. NIST Interagency Reports 4749. Sample Statements of Work for Federal Computer Security Services: For Use In-House or Contracting Out. December 1991. NIST Special Publication 800-12. An Introduction to Computer Security: The NIST Handbook. October 1995. NIST Special Publication 800-14. Generally Accepted Principles and Practices for Securing Information Technology Systems. September 1996. Co-authored with Barbara Guttman. NIST Special Publication 800-18. Guide For Developing Security Plans for Information Technology Systems. December 1998. Co-authored with Federal Computer Security Managers' Forum Working Group. NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems. August 2001. NIST Special Publication 800-27. Engineering Principles for IT Security. June 2001. OMB Circular A-130. Management of Federal Information Resources. Appendix III. November 2000. Copyright © 2006 独立行政法人 情報処理推進機構 及び NRI セキュアテクノロジーズ株式会社 SP 800-30 Page F-1