IT システムのためのリスク ... - ipa.go.jp · この文書は下記団体によって翻訳監修されています Special Publication 800-30 IT...

この文書は下記団体によって翻訳監修されています

Special Publication 800-30

ITシステムのためのリスクマネジメントガイド

米国国立標準技術研究所による推奨

Gary Stoneburner、Alice Goguen、Alexis Feringa

Copyright © 2006 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30

NIST Special Publication 800-30

ITシステムのためのリスクマネジメントガイド米国国立標準技術研究所

による推奨

Gary Stoneburner, Alice Goguen1, Alexis Feringa1

コンピュータセキュリティ

米国国立標準技術研究所情報技術研究所コンピュータセキュリティ部門 Gaithersburg, MD 20899-8933 1Booz 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 Page iii

コンピュータシステム技術に関する報告書

米国国立標準技術研究所（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による推薦または公認を意味するものではなく、これら組織、資料、あるいは装置が、その目的に関して得られる最善のものであると意味しているわけでもない。


SP 800-30 Page iv

謝辞

作成者の 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よりは、本書の技術的内容に大きく貢献する、価値ある洞察をいただいた。また、本文書の品質と実用性の向上に寄与する多くの思慮に富んだ建設的な意見をくださった官民各セクター諸氏に、心よ

り感謝の意を表する。

本文書は、原典に沿ってできるだけ忠実に翻訳するよう努めていますが、完全

性、正確性を保証するものではありません。翻訳監修主体は本文書に記載さ

れている情報より生じる損失または損害に対して、いかなる人物あるいは団

体についても責任を負うものではありません。


SP 800-30 Page v

目次

1. はじめに ...............................................................................................................................................1 1.1 作成機関及び適用範囲 .............................................................................................................................................1 1.2 目標 ............................................................................................................................................................................1 1.3 リスクマネジメントの目的 ...........................................................................................................................................2 1.4 対象とする読者 ..........................................................................................................................................................2 1.5 関連文献.....................................................................................................................................................................3 1.6 本文書の構成.............................................................................................................................................................3

2. リスクマネジメントの概要 .......................................................................................................................4 2.1 リスクマネジメントの重要性 .......................................................................................................................................4 2.2 システム開発ライフサイクルへのリスクマネジメントの統合 .....................................................................................4 2.3 リスクマネジメントにおける主な役割 .........................................................................................................................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 優れたセキュリティ実践手法 ...................................................................................................................................39 5.2 成功の鍵...................................................................................................................................................................39

付録 A：インタビュー時の質問例 ........................................................................................................A-1

付録 B：リスクアセスメント報告書サンプル（アウトライン） ....................................................................B-1


SP 800-30 Page vi

付録 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


SP 800-30 Page 1

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 システム」という用語は、一般的な支援システムそのもの(たとえば、メインフレームコンピュータ、ミッドレンジコンピュータ、ローカルエリアネットワーク、連邦政府全体のバックボーンなど)、あるいは、利用者の特定の要求を満たす情報資源を利用するために一般的な支援システム上で実行可能な主要アプリケーションを意味する。


SP 800-30 Page 2

さらに、本ガイドは費用対効果の高いセキュリティ管理策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 「保護手段」及び「管理策」という用語は、リスク低減手段を表しており、このドキュメントでは、これら 2 つの用語を区別なく用いている。

3 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年ごとに再認可を受けることを求めている。


SP 800-30 Page 3

• システムとデータの完全性に影響を与える可能性のあるコードを開発、保守する 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は参考文献のリストである。


SP 800-30 Page 4

2. リスクマネジメントの概要

この文書はリスクマネジメントの方法論、リスクマネジメントがどのようにシステム開発ライフサイクルの各

フェーズに組み込まれるのか、さらにリスクマネジメントプロセスがシステムの認可 (または承認) プロセスとどのように連動するのかについて説明する。

2.1 リスクマネジメントの重要性

リスクマネジメントには、リスクアセスメント、リスク軽減、それらの結果の評価とアセスメントという 3 つのプロセスが含まれる。本文書の第 3 節では、リスクとリスクがもたらす影響の特定やその評価と、推奨されるリスク低減手段を含む、リスクアセスメントプロセスについて説明する。第 4 節では、リスク軽減について述べ、リスクアセスメントプロセスによって推奨される適切なリスク低減手段の優先順位づけやその導入、保守につ

いて説明する。第 5 節では、継続的な評価プロセスと、リスクマネジメントプログラムの導入を成功させるための鍵となる点について説明する。指定承認者 (DAA)又はシステム認可責任者は、残存リスクが容認できるレベルであるかどうかを判断し、また ITシステムの運用を認可する (または承認する) 前にセキュリティ管理策をさらに追加して、残存リスクをさらに低減すべきかあるいは排除すべきかを判断する責任を負う。

リスクマネジメントとは、IT 管理者がその運用と保護手段の経済的コストのバランスを取りながら、組織のミッションを支援する IT システムとデータを保護することにより、ミッション遂行能力を向上させることを可能にするプロセスである。このプロセスは IT 環境に特有のものではない。実際、我々の日常生活全般における意思決定にも広く浸透している。その例としてホームセキュリティがある。多くの人がホームセキュリティシステム

を導入し、月々の使用料をサービスプロバイダに支払い、これらシステムによって自分たちの資産をより適切

に保護する監視サービスが提供されている。おそらく世帯主はシステムや監視にかかるコストと、家財道具や

世帯主のミッションである家族の安全の価値を比較検討したことだろう。

組織の代表者は、組織のミッション達成に必要な能力を確保しなければならない。こうしたミッションの責任

者は、実世界の脅威に直面した場合、ミッション遂行のために必要なサポートレベルを提供するために、IT システムが備えていなければならないセキュリティ能力を判断する必要がある。ほとんどの組織の IT セキュリティに対する予算は厳しいものとなっている。したがって、IT セキュリティに対する支出は、他の経営判断と同様に徹底的にレビューしなければならない。適切に体系化されたリスクマネジメント方法論は、効果的に用い

られた場合、経営陣がミッション遂行に不可欠なセキュリティ能力を提供するのに適した管理策を特定する助

けとなる。

2.2 システム開発ライフサイクルへのリスクマネジメントの統合

組織が IT システムにリスクマネジメントプロセスを導入する主な理由は、組織への負の影響の最小化、及び意思決定のための確たる根拠の提供である。効果的なリスクマネジメントは、システム開発ライフサイクル

に、完全に統合されなければならない。IT システムのシステム開発ライフサイクルは、5 つのフェーズからなる：開始フェーズ、開発／調達フェーズ、導入フェーズ、運用／保守フェーズ、そして廃棄フェーズである。場合

によっては、1 つの IT システムが複数のフェーズにある場合もある。しかし、リスクマネジメントの方法論は評価の実施対象となっているシステム開発ライフサイクルのどのフェーズでも同じである。リスクマネジメントは

システム開発ライフサイクルの主要なフェーズで実施できる繰返しプロセスである。表 2-1 は、各システム開発ライフサイクルフェーズの特徴と各フェーズを支援するためのリスクマネジメントの実施方法について記述し

たものである。


SP 800-30 Page 5

表 2-1 システム開発ライフサイクルへのリスクマネジメントの統合

システム開発ライフサイク

ルにおけるフェーズフェーズごとの特徴リスクマネジメント活動による支援

第 1 フェーズ－開始 IT システムに対するニーズが示され、IT システムの目的と適用範囲が文書化される。

• 特定されたリスクは、セキュリティ要件や運用時のセキュリティ概念 (対策) を含むシステム要件の作成に利用さ

れる。

第 2 フェーズ－開発または調達

IT システムを設計、購入、プログラム、開発、あるいは構築する。

• 本フェーズで特定されたリスクは、システム開発時のアーキテクチャや設

計のトレードオフにつながる IT システムのセキュリティ分析に利用すること

ができる。

第 3 フェーズ－導入システムのセキュリティ機能を、設

定、有効化、テスト、検証する。 • リスクマネジメントプロセスは、当該要件及び、そのモデル化された運用環

境下におけるシステム導入に関する

アセスメントを支援する。特定されたリ

スクに関する判断はシステム運用前

に下さなければならない。

第 4 フェーズ－運用または保守

システムがその機能を実行する。

ハードウェアとソフトウェアの追加

や、組織内プロセス、方針、手順の

変更に伴い、システムは通常、継続

的に変更される。

• 定期的なシステムの再認可 (または再承認) に対して、IT システムの運用上、実動環境上の大幅な変更 (例えば、新しいシステムインタフェースな

ど) がある場合には、必ずリスクマネジメント活動を実施する。

第 5 フェーズ－廃棄このフェーズでは、情報、ハードウェ

ア、ソフトウェアの廃棄が行われる場

合がある。その中には、情報の移

動、アーカイブ、廃棄、破壊や、ハー

ドウェアとソフトウェアのサニタイズ

（無害化）が含まれる。

• ハードウェアとソフトウェアが適切に廃棄され、残存データが適切に処理

され、システム移行が安全かつ系統

立った方法で行われるようにするた

め、廃棄または交換予定のシステム

コンポーネントに対してリスクマネジメ

ント活動を実施する。


SP 800-30 Page 6

2.3 リスクマネジメントにおける主な役割

リスクマネジメントは経営陣の責任で行う。この節ではリスクマネジメントプロセスを支援し、関与する人員

の主な役割について説明する。

• 経営陣：ミッション遂行の最終責任を負い、一般的に払うべき注意を払う経営陣は、ミッション達成のた

めに、必要な資源が効果的に割り当てられるようにしなければならない。さらに、リスクアセスメント活動

の結果を評価し、それらを意思決定プロセスに取り入れなければならない。IT のミッションに関連するリスクを評価し、それを低減する効果的なリスクマネジメントプログラムには経営陣の支援と参加が不可欠

である。

• 最高情報責任者 (CIO)： CIO は組織の IT に関する計画、予算といった、情報セキュリティコンポーネントに含まれるものに対して責任を負う。これらの分野における意思決定は効果的なリスクマネジメント

プログラムに基づいて行うべきものである。

• システム及び情報所有者：システム及び情報所有者には、IT システムと双方が所有するデータの完全性、機密性、可用性を扱う適切な管理策が設置されていることを確実にする責任がある。通常、システ

ム及び情報所有者は IT システムの変更に対して責任を持つ。したがって、通常はシステム及び情報所有者が IT システムの変更 (例えば、システム強化、ソフトウェアやハードウェアに対する主要な変更など) を承認し署名する。このことから、システム及び情報所有者はリスクマネジメントプロセスにおける自らの役割を理解しこのプロセスを全面的に支援しなければならない。

• ビジネスマネージャー及び職務管理者：ビジネスの遂行及び IT 調達プロセスの責任を担う管理職はリスクマネジメントプロセスに積極的に関与しなければならない。これらの管理職はミッション遂行に不可

欠なトレードオフの決定を行う権限と責任を有する要員である。リスクマネジメントプロセスにこれらの管

理職が参画することにより、IT システムに適切なセキュリティが得られるようになり、その IT システムを適切に管理すれば、資源の支出を最低限に抑えつつミッションの効率的な遂行に寄与することができ

る。

• 情報システムセキュリティ責任者 (ISSO)： IT セキュリティプログラムマネージャおよびコンピュータセキュリティ責任者はリスクマネジメントを含む組織のセキュリティ導入計画に対して責任を負う。したがっ

て、ISSO は組織のミッションを支援する IT システムに対するリスクを特定、評価、最小化するための体系化された方法論を導入する際に主導的役割を果たす。ISSO は、経営陣によってこの活動が継続的に実施されることを支援するコンサルタントも務める。

• IT セキュリティ担当者： IT セキュリティ担当者 (例えば、ネットワーク、システム、アプリケーション、データベース管理者、コンピュータ専門家、セキュリティアナリスト、セキュリティコンサルタントなど) はIT システムにおけるセキュリティ要件の適切な導入に責任を持つ。既存の IT システム環境に変化が生じたとき (例えば、ネットワークの拡大、既存インフラストラクチャや組織方針の変更、新技術の導入など)、IT セキュリティ担当者は新たな潜在的リスクを特定／評価し、IT システムを保護するために必要な新たなセキュリティ管理策を導入するために、リスクマネジメントプロセスを支援、または使用しなければ

ならない。


SP 800-30 Page 7

• セキュリティ意識向上トレーニング担当者 (セキュリティ及び本件に関する専門家)：組織の人員は ITシステムの利用者でもある。IT システムやデータを、組織方針、ガイドライン、行動規範に則って使用することはリスク低減と組織の IT 資源保護に不可欠である。IT システムへのリスクを最小化するためには、システムやアプリケーション利用者がセキュリティ意識向上トレーニングを受けていることが必須であ

る。したがって、IT セキュリティ意識向上担当者やセキュリティ及び本件に関する専門家は、適切なトレーニング教材を作成し、リスクアセスメントをエンドユーザを対象としたトレーニングプログラムに取り入

れることができるように、リスクマネジメントプロセスを理解していなければならない。


SP 800-30 Page 8

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 はこれらのステップ及び、各ステップにおける情報のインプットとアウトプットを示したものである。


SP 800-30 Page 9

図 3-1 リスクアセスメント手法のフローチャート

リスクアセスメント活動インプットアウトプット • ハードウェア • ソフトウェア • システムインタフェース

• データ及び情報 • 要員／人員

ステップ 1. システムの特徴定義

• システム境界 • システム機能 • システム及びデータの重大性

• システム及びデータの機密性

ステップ 2. 脅威の特定

• システム攻撃の履歴 • 情報機関、NIPC、OIG、

FedCIRC、マスメディアからのデータ

脅威ステートメント

ステップ 3. 脆弱性の特定

• 以前のリスクアセスメント報告

• あらゆる監査コメント • セキュリティ要件 • セキュリティテスト結果

潜在的な脆弱性のリスト

ステップ 4. 管理策の分析

• 実施中管理策 • 計画中管理策

実施中及び計画中の

管理策のリスト

ステップ 5. 脅威の発生可能性の判断

• 脅威源の動機 • 脅威の威力 • 脆弱性の性質 • 現在の管理策

脅威の発生可能性レベル

ステップ 6. 影響の分析

• 完全性の損失 • 可用性の損失 • 機密性の損失

• ミッションへの影響分析 • 資産の重要度評価 • データの重要度 • データの機密度の高さ

影響レベル

ステップ 7. リスクの判断

• 脅威がつけこむ可能性 • 影響の大きさ • 計画中または現在の管理策の適切性

リスク及び関連

するリスクレベ

ステップ 8. 管理策の推奨

ステップ 9. 結果の文書化

推奨管理策

リスクアセスメ

ント報告


SP 800-30 Page 10

3.1 ステップ 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 システム及びデータの完全性、機密性、及び可用性の維持管理に必要な保護のレベル。


SP 800-30 Page 11

• 現在のネットワークトポロジ (例えば、ネットワークダイアグラムなど)

• システムとデータの可用性、完全性、機密性を保護するための情報を保存するストレージの保護

• ITシステムに属する情報の流れ (例えば、システムインタフェース、システム入出力フローチャートなど)

• IT システムに適用する技術管理策 (例えば、識別や認証をサポートする組み込み型または付加型セキュリティ製品、任意的／強制的なアクセス制御、監査、残存情報保護、暗号化手法など)

• ITシステムに適用する統制管理策 (例えば、行動規範、セキュリティ計画など)

• IT システムに適用する運用管理策 (例えば、要員セキュリティ、バックアップ、緊急時対応、及び回復と復旧活動、システム保守、オフサイトストレージ、利用者アカウントの設定や削除手順、特権利用者アク

セスと一般利用者アクセスのような利用者別機能管理など)

• ITシステムの物理的セキュリティ環境 (例えば、施設のセキュリティ、データセンター方針など)

• IT システム処理環境に導入された環境セキュリティ (例えば、湿度、水、電力、汚染、温度、化学物質の管理など)

開始フェーズまたは設計フェーズにあるシステムの場合、システム情報は設計文書や要件文書から得られ

る。開発中の IT システムの場合、将来の IT システムに対して計画中の主要セキュリティ規則や属性を明らかにする必要がある。開発中の IT システムのセキュリティについて役に立つ情報は、システム設計書やシステムセキュリティ計画書から得られる。

運用中の IT システムの場合、システム設定、接続性におけるデータ、文書化された手続き・プラクティス、文書化されていない手続き・プラクティスを含め、IT システムに関するデータはその実働環境で収集される。したがって、システム設計書は下層インフラストラクチャが提供するセキュリティまたは将来の IT システムセキュリティ計画に基づいたものとなる。

3.1.2 情報収集手法

以下のテクニックのいずれか、またはそれらを組み合わせることにより、運用範囲内の IT システム関連情報を収集できる。

• アンケート：担当者は関連情報を収集するために、計画中または稼動中の IT システム管理及び運用管理策に関するアンケートを作成することができる。当該アンケートは IT システムの設計またはサポートを担当する技術要員及び非技術要員を対象に配付すべきものである。当該アンケートは現場訪問及

びインタビューの際にも使用することができる。

• 現場インタビュー：担当者は、IT システムサポート要員や管理要員との面接により、IT システムに関する有用な情報 (例えば、システムの運用や管理方法など) を収集できる。さらにリスクアセスメント担当者は現場訪問により ITシステムの物理的、環境的、運用上のセキュリティに関する情報を観察、収集することができる。


SP 800-30 Page 12

付録 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) 脆弱性が偶発的に衝かれる恐れのある状況

及び手法、のいずれか。


SP 800-30 Page 13

脅威源とは IT システムに被害をもたらす可能性のあるあらゆる状況または

事象と定義される。一般的な脅威源に

は、自然、人為、環境によるものがあ

る。

脅威源を評価する際は、IT システムやその環境に被害を及ぼす可能性のあ

る全ての潜在的脅威源を考慮すること

が重要である。例えば、砂漠地帯に設

置された IT システムの脅威ステートメントには「自然の洪水」は発生する可能

性が低いことからそのような事象は含ま

れないかもしれないが、配管破裂などの

環境的脅威によってコンピュータ室が瞬

時に水浸しとなり、組織の IT 資産や資源に被害をもたらす可能性はある。悪意を持った者あるいは不満を持った従業員による計画的な攻撃などの

故意の行為、あるいは不注意や誤りなどの偶発的行為により、人さえも脅威源となりうる。計画的攻撃とは、

(1) システムやデータの完全性、可用性、機密性を脅かすために IT システムに不当にアクセスしようとする (例えば、パスワードの推測などによる) 悪意ある試み、あるいは (2) 悪意はないものの、故意にシステムセキュリティを迂回しようとする試み、のいずれかである。後者に属する故意の攻撃の例として、プログラマが

「仕事を片付ける」ためシステムセキュリティを迂回するトロイの木馬プログラムを作成する場合などがある。

3.2.2 攻撃の動機と脅威となる行動

動機と、攻撃を可能にする資源は、人間を潜在的に危険な脅威源にする。表 3-1 に今日一般的となった多くの人為的脅威、可能な動機、または攻撃実行に用いられる可能性のある手法や脅威となる行動の概要を

示す。本情報は組織がその人為的脅威の（人が脅威となりうる）環境を検討し、人為的な脅威ステートメントを

カスタマイズする際に役立つであろう。さらに、システム侵入履歴、セキュリティ侵害報告、インシデント報告の

レビュー、ならびに情報収集時のシステム管理者、ヘルプデスク要員、利用者コミュニティとの会見は、IT システムとそのデータに害を及ぼす可能性のある、脆弱性の存在が懸念される人為的脅威源の特定に有効で

ある。

一般的脅威源

• 自然の脅威－洪水、地震、竜巻、地滑り、雪崩、雷雨、その他の類似の事象

• 人為的脅威－偶発的行為 (不注意によるデータ入力) あるいは故意の行為 (ネットワークによる攻撃、悪意のあるソフトウェアのアップロード、機密情報への不

当なアクセス) などの、人間がきっかけとなるかあるいは原因となる事象。

• 環境的脅威－長時間停電、汚染、化学物質、液体漏洩


SP 800-30 Page 14

表 3-1 人為的脅威：脅威源、動機、及び脅威行動

脅威源動機脅威行動

ハッカー、クラッカー挑戦自己顕示反抗

• ハッキング • ソーシャルエンジニアリング • システム侵入、侵害 • 不正なシステムアクセス

コンピュータ犯罪者

情報破壊不法な情報開示金銭取得不当データ改ざん

• コンピュータ犯罪 (例えば、サイバーストーキングなど)

• 詐欺行為 (例えば、リプレイ攻撃、なりすまし、傍受など)

• 情報の贈収賄 • スプーフィング • システム侵入

テロリスト

脅迫破壊攻略復讐

• 爆弾／テロリズム • 情報戦争 • システム攻撃 (例えば、分散サービス妨害

(DDoS) など) • システム侵入 • システム改ざん

産業スパイ (企業、外国政府、その他の政府関連)

競争優位性経済的スパイ行為

• 経済的攻略 • 情報窃盗 • 個人プライバシー侵害 • ソーシャルエンジニアリング • システム侵入 • 不当なシステムアクセス (機密情報、知的財産及び／または技術関連情報へのアクセス)

インサイダー (訓練の不足した、不満を持つ、悪意のある、不注意

な、不正直な、あるいは解

雇された従業員)

好奇心自己満足自己顕示金銭取得復讐不作為の誤り及び怠

慢 (例えば、データ入力ミス、プログラミング

ミスなど)

• 従業員に対する攻撃 • 脅迫状 • 知財情報の参照 • コンピュータの不正使用 • 詐欺及び窃盗 • 情報贈収賄 • 偽造、変造されたデータの入力 • 傍受 • 悪意のコード (例えば、ウイルス、論理爆弾、トロイの木馬など)

• 個人情報販売 • システムのバグ • システム侵入 • システム損傷 • 不正なシステムアクセス

潜在的脅威源を特定した後、脅威がシステムの脆弱性を悪用する可能性を判断するために、動機、資源、

攻撃成功のために必要と思われる能力を第 3.5節で説明する方法により推定すべきである。


SP 800-30 Page 15

脅威ステートメント、あるいは潜在的脅威源のリストは、個々の組織や環境 (例えば、エンドユーザのコンピューティング習慣など) に合わせて調整が行われる。通常、自然の脅威に関する情報 (例えば、洪水、地震、嵐など) はすぐに入手できるであろう。既知の脅威は、多くの政府や民間部門の組織によって特定されてきたものである。侵入検知ツールの普及も進み、政府や業界組織のセキュリティ事象に関する継続的データ

収集によって、脅威を現実的に評価する能力も向上しつつある。情報源としては次のようなものがあるが、こ

れらに限定されるわけではない。

• 情報機関 (例えば、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 を使いシステムファイルを閲覧する。

ベンダーがシステムのセキュリティ

設計に欠陥を見つけたものの、新

しいパッチをシステムに適用してい

ない。

許可されていない利用者 (例えば、ハッカー、不満を持つ従業員、

コンピュータ犯罪者、テロリストな

ど)

既知のシステム脆弱性を悪用して

機密のシステムファイルに不正に

アクセスする。

脆弱性：悪用される (偶発的に衝かれるか、あるいは故意につけこまれる) ことによりセキュリティ侵害またはシステムセキュリティ方針違反を招く可能

性がある、システムセキュリティの手順、設計、実

装、内部制御における欠陥または弱点。


SP 800-30 Page 16

脆弱性脅威源脅威行動

データセンターでは消火のために

水スプリンクラを設置しているが、

ハードウェア及び装置を水による

害から守る防水シートが設置され

ていない。

火災、不注意な要員データセンター内の水スプリンクラ

が開栓になったままである。

システムの脆弱性を特定するための推奨手法には、脆弱性に関する情報源の利用、システムセキュリティ

テストの実施、セキュリティ要件チェックリストの作成がある。

存在するであろう脆弱性の種類や、脆弱性が実際に存在するかどうかの判断に必要とされる方法は、通常

IT システムの特性と、そのシステムが属するシステム開発ライフサイクル内の各フェーズに応じて異なることに注意すべきである。

• IT システムがまだ設計されていない場合は、脆弱性を洗い出すには、組織のセキュリティ方針、計画されるセキュリティ手順、システム要件の定義、ベンダーまたは開発者によるセキュリティ製品分析 (例えば、白書など) などを重点的に見ていく。

• IT システムが実装中である場合、脆弱性の特定には、セキュリティ設計文書に記述されたセキュリティ機能やシステム認証テストとその評価結果など、より具体的な情報を含めて脆弱性の特定を行う。

• IT システムが運用中である場合は、脆弱性を特定するプロセスには、IT システムを保護するために用いるセキュリティ機能や技術と手順（プロシージャ）の両方の管理策の分析を含める。

3.3.1 脆弱性に関する情報源

IT システムの処理環境に関連する技術的／非技術的な脆弱性は、第 3.1.2節で説明した情報収集手法によって特定することができる。業界の他の情報源 (例えば、システムバグ及び欠陥を明らかにしているベンダーのウェブページなど) の調査によって得た情報は、特定の IT システム（例えば、特定のオペレーティングシステムの特定バージョン）に関係するかもしれない脆弱性を特定するために実施されるインタビューの準備

や、効果的な質問表作成のための有益な情報となる。インターネットは、ベンダーが公開している既知のシス

テム脆弱性とともに、脆弱性を排除あるいは低減するホットフィックス（プログラムの問題を解決するために緊

急に配布される修正モジュール）、サービスパック、パッチ、その他の修復手段についての有益な情報源でも

ある。徹底した脆弱性分析を行う上で検討すべき文書化された脆弱性情報源には次のようなものがあるが、

これらに限定されるわけではない。

• 評価済み ITシステムの以前のリスクアセスメント文書

• ITシステムの監査報告、システム異常報告、セキュリティレビュー報告、システムテストと評価報告

• NIST I-CAT脆弱性データベース (http://icat.nist.gov) のような脆弱性リスト


SP 800-30 Page 17

• 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 (ネットワークセキュリティテスト概観)ではネットワークシステムのテスト手法及び自動化ツールの使用法について説明している。


SP 800-30 Page 18

3.3.3 セキュリティ要件チェックリストの作成

このステップにおいてリスクアセスメント担当者は、ITシステムに対して取り決められ、システムの特徴定義を通して収集されたセキュリティ要件が、既存のまたは計画されたセキュリティ管理策によって満たされている

かどうかを判断する。通常、システムセキュリティ要件は表形式で表現され、それぞれの要件に対し、どのよう

にしてシステム設計や導入がそのセキュリティ管理策の要件を満たすのか、あるいは満たさないのかの説明

が添付される。

セキュリティ要件チェックリストには、基本的なセキュリティ基準が含まれており、所与の IT システムに関連する情報資産 (要員、ハードウェア、ソフトウェア、情報)、自動化されていない手順、プロセス及び情報伝達における脆弱性を、次のセキュリティ領域において体系的に評価し、特定するために用いられる。

• マネジメント

• 運用

• テクニカル

表 3-3は、各セキュリティ領域における ITシステムの脆弱性を特定する際に用いるよう推奨されるセキュリティ判断基準の一覧である。

表 3-3 セキュリティ基準

セキュリティ分野セキュリティ判断基準

セキュリティマネジメント

• 責任の割当て • サポートの継続性 • インシデント対応能力 • セキュリティ管理策の定期的レビュー • 要員の身上調査や身元調査 • リスクアセスメント • セキュリティや技術的なトレーニング • 職務分離 • システム認可と再認可 • システムまたはアプリケーションのセキュリティ計画

運用セキュリティ

• 空中浮遊汚染物質の管理 (煙、粉塵、化学物質) • 電力供給の品質確保のための管理 • データメディアへのアクセスと廃棄 • 外部データの配付やラベル付け • ファシリティ保護 (例えば、コンピュータ室、データセンター、オフィスなど)

• 湿度管理 • 温度管理 • ワークステーション、ラップトップ、スタンドアローンのパーソナルコンピュータ


SP 800-30 Page 19

セキュリティ分野セキュリティ判断基準

テクニカルセキュリティ

• 通信 (例えば、ダイヤルイン、システム相互接続、ルータなど) • 暗号技術 • 任意的アクセス制御 • 識別と認証 • 侵入検知 • オブジェクト再利用 • システム監査

このプロセスの成果はセキュリティ要件チェックリストである。このようなチェックリストをまとめるのに利用で

きる情報源として、次のような政府規定とセキュリティ指令、及び 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 リスク評価報告は監査報告ではないため、サイトの中には、特定された脆弱性をリスク評価報告書における検出項目としてではなく、観察結果として扱うことを好むことがある。


SP 800-30 Page 20

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 システムがその脆弱性を悪用される可能性を下げ、そのような有害な事象の影響を軽減するために用いられる、既存のまたは計画された管理策のリスト


SP 800-30 Page 21

3.5 ステップ 5：可能性の判断

関連する脅威環境において、潜在的脆弱性が悪用される確率を示す全体的可能性レベルを得るには、以

下の管理要因を検討しなければならない。

• 脅威源の動機と能力

• 脆弱性の性質

• 現状の管理策が実際に存在すること及びその効果

ある脅威源によって潜在的脆弱性が悪用されうる可能性は、高、中、低で表すことができる。次の表 3-4 には、これら 3つの発生可能性レベルの定義を示す。

表 3-4 可能性の定義

可能性レベル可能性の定義

高脅威源は強い動機を持ち、能力も十分である。脆弱性の悪用を防止する管理策が

有効ではない。

中脅威源は動機を持ち、能力も有るが、脆弱性の悪用を妨げる管理策が導入されて

いる。

低脅威源に動機または能力が欠如している。あるいは、脆弱性の悪用を防止するか、

少なくとも著しく妨げる管理策が導入されている。

ステップ 5のアウトプット－可能性レベル (高、中、低)

3.6 ステップ 6：影響の分析

リスクレベル測定の次の主要ステップは、脅威によって脆弱性が悪用された場合にもたらされる有害な影

響についての判断である。影響分析を始める前に、第 3.1.1 節で述べたように、以下に挙げる情報を得る必要がある。

• システムのミッション (例えば、ITシステムが実行するプロセスなど)

• システムやデータの重要性 (例えば、組織にとってのシステムの価値または、重要性など)

• システムやデータの機密性

これらの情報は、ミッションに対する影響分析報告または資産重要度評価報告などの既存の組織内文書

から得られる。ミッションに対する影響分析 (ビジネス影響分析［BIA: business impact analysis］と呼ぶ組織もある) では、組織の情報資産の機密性や重要度の定性的／定量的評価に基づいて、情報資産への危害から生じる影響レベルに優先順位付けを行う。資産重要度評価では、組織の重要なミッションをサポートする機

密性と重要度の高い情報資産 (例えば、ハードウェア、ソフトウェア、システム、サービス及び関連する技術資産など) を特定し優先順位付けを行う。


SP 800-30 Page 22

こうした文書が存在しない、あるいは組織の IT 資産に対してそのような評価を行ったことがない場合は、システムやデータの機密性は、システムやデータの可用性、完全性、機密性を維持するために求められる保護

レベルに基づき判断することができる。IT システムやそのデータの機密性のレベル判定に用いられた方法にかかわらず、システムや情報の所有者は、自部門のシステムや情報に対する影響レベルを判断する責任を

負う。したがって、影響分析における適切な手法はシステムや情報の所有者へのインタビューである。

セキュリティイベントによる有害な影響は、従って、次の 3 つのセキュリティ目標、すなわち完全性、可用性、機密性のいずれか、またはこれらを組み合わせたものの損失あるいは劣化という観点から記述すること

ができる。次のリストは、各セキュリティ目標と、これらが合致しなかった場合の結果 (または影響) について簡単に記したものである。

• 完全性の損失：システムやデータの完全性とは、情報を不適切な改変から保護することを意味する。

完全性は、故意または偶発的行為のいずれかによってデータや IT システムに対し、不当な変更がなされた場合に損なわれる。システムやデータの完全性の損失が是正されない場合、劣化したシステムまた

は破損したデータを継続的に使用することは、不正確さ、詐欺、または誤判断につながる恐れがある。さ

らに完全性の侵害はシステムの可用性や機密性への攻撃を成功させる第一歩にもなりうる。これらの理

由すべてから完全性損失は ITシステムの保証を低下させる。

• 可用性の損失：エンドユーザが基幹 IT システムを使えなくなった場合、組織のミッションに影響が及ぶ可能性がある。システム機能の損失及び運用上の有効性の損失は、例えば、生産時間の損失につなが

り、その結果、組織のミッション遂行をサポートするエンドユーザの職務遂行の妨げになる。

• 機密性の損失：システムやデータの機密性とは、不当な開示から情報を保護することを意味する。機

密情報の不当開示の影響範囲は、国家安全保障への脅威から Privacy Act で保護されるべきデータの開示にまで及ぶ可能性がある。不当、不測、不作為の情報開示は、公衆の信頼を失ったり、苦境に置か

れたり、あるいは組織に対する法的行為の執行にもつながりかねない。

幾つかの有形の影響は、収入機会の損失、システムの修理コスト、あるいは脅威行動が成功した場合に発

生した問題を修正するために要する作業レベルなどによって定量的に計測できる。その他の影響 (例えば、公衆の信頼の喪失、信用失墜、組織利益への損害など) は具体的な単位として計測することはできないが、高、中、低という見方で影響を定性化もしくは表現できる。ここでは影響評価についての一般的な内容を扱っ

ているので、このガイドでは影響の定性的カテゴリーである高、中、低レベルのみを利用して説明する (表 3.5参照)。

表 3-5 影響の大きさの定義

影響の大きさ影響の定義

高脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産や資源に対する巨額な損失。(2) 組織のミッション、評判、利益に対する著しい侵害、被害、妨害。(3) 人命の損失、または重大な傷害。

中脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産または資源に対する高額な損失。(2) 組織のミッション、評判、利益に対する侵害、被害、または妨害。(3) 人の傷害。

低脆弱性の悪用により、次の結果がもたらされる可能性がある。(1) 有形資産または資源へのある程度の損失。(2) 組織のミッション、評判、利益へのある程度の影響。


SP 800-30 Page 23

定量的評価対定性的評価

影響分析を行う際には、定量的評価と定性的評価それぞれの利点及び欠点に配慮すべきである。定性的

影響分析の主な長所は、リスクに優先順位を付けることにより、脆弱性に対処する上で、即改善が必要な領

域を特定できることである。定性的分析の短所は、影響の大きさを具体的に定量化できないため、全ての推

奨される管理策に対する費用対効果分析が困難なことである。

定量的影響分析の主な利点は影響の大きさを測定できるため、結果を推奨管理策の費用対効果分析に使

用できることである。短所は、測定結果を表すために用いる数値範囲によっては定量的影響分析の意味が不

明確となり、結果の定性的な解釈が求められることである。影響の大きさを判断するためには、追加要因を検

討しなければならないことが多い。それらの要因には次のようなものがあるが、これらに限定されるわけでは

ない。

• 一定期間内 (例えば 1年など) に脅威源によって脆弱性が悪用される頻度の推定

• 脅威源によって脆弱性が悪用されるたびに発生するコストの概算

• ある脅威によって特定の脆弱性が悪用された場合の相対的影響を主観的に分析して決める重み付け

要素（ファクター）

ステップ 6のアウトプット－影響の大きさ (高、中、または低)

3.7 ステップ 7：リスクの判断

このステップの目的は IT システムに対するリスクレベルを査定することである。特定の脅威／脆弱性の組合せに対するリスク判断は以下の値の関数として表すことができる。

• ある脅威源によってある脆弱性が悪用される可能性

• 脅威源によって脆弱性が実際に悪用された場合の影響の大きさ

• リスク低減／排除するために計画済みまたは既存のセキュリティ管理策の適切性

リスクを計測するためには、リスクの尺度及びリスクレベルマトリクスを作成しなければならない。第 3.7.1節では標準的なリスクレベルのマトリクスを掲載する。第 3.7.2節は、リスクレベルの結果である。

3.7.1 リスクレベルマトリクス

ミッションに関連するリスクの最終判断は、脅威の可能性 (例えば確率など) に、脅威の影響レベル値を掛けることによって得られる。表 3.6 は脅威の可能性と脅威の影響カテゴリーを入力することにより、どのように全体のリスクレベルが決まるのかを示している。この表は、脅威の可能性 (高、中、低) と脅威の影響 (高、中、低) による 3 × 3のマトリクスである。サイトの要件やリスクアセスメントに求められる精度により、4 × 4あるいは 5 × 5のマトリクスを用いるのが適当なサイトもある。後者の場合、脅威の可能性に、「非常に低い／非常に高い」、脅威の影響に、「非常に低い／非常に高い」を含めることにより、リスクレベルとして「非常に低い

／非常に高い」を生成する。「非常に高い」リスクレベルでは、システムのシャットダウンや、IT システム統合及びテスト作業すべての中止に至る可能性がある。

表 3-6 のマトリクスでは、全体的なリスクレベルである高、中、低がいかにして得られるのかを示している。これらリスクレベルや格付けの判断は主観的でもよい。正当化のための根拠は、各脅威の可能性レベルに割

り当てた確率と、各影響レベルに割り当てた数値によって説明できる。例えば、


SP 800-30 Page 24

• 各脅威の可能性レベルに割り当てる確率を、高は 1.0、中は 0.5、低は 0.1 とする。

• 各影響レベルに割り当てる数値を、高は 100、中は 50、低は 10 とする。

表 3-6 リスクレベルマトリクス

影響

脅威の可能性低

(10)

中

(50)

高

(100)

高 (1.0) 低

10 × 1.0 = 10

中

50 × 1.0 = 50

高

100 × 1.0 = 100

中 (0.5) 低

10 × 0.5 = 5

中

50 × 0.5 = 25

中

100 × 0.5 = 50

低 (0.1) 低

10 × 0.1 = 1

低

50 × 0.1 = 5

低

100 × 0.1 = 10

リスクスケール：高 (50～100); 中 (10～50); 低 (1～10)8

3.7.2 リスクレベルの説明

表 3-7 は上記のマトリックス内に示したリスクレベルを説明するものである。高、中、低に格付けされたリスク尺度は、ある脆弱性が悪用された場合に IT システム、ファシリティ、あるいは手順がさらされうるリスクレベルを示す。リスク尺度は、各リスクレベルに対して、ミッション遂行の責任者である経営陣が取らなければなら

ない行動も示している。

表 3-7 リスク尺度と必要な行動

リスクレベルリスクの説明と必要な行動

高ある観察結果または指摘事項が高リスクと評価された場合には、是正手段を講じること

が強く求められる。既存システムは運用を続けてもよいが、できるだけ早期に是正措置

実行計画を実施しなければならない。

中ある観察結果が中リスクと評価された場合は是正措置が必要であり、妥当な期間内に

これらの措置を実施する計画を作成しなければならない。

低ある観察結果が低リスクと評価された場合、システムの指定承認者は、是正措置が必

要か否かを判断するか、リスクを容認するかしなければならない。

ステップ 7のアウトプット－リスクレベル (高、中、低)

8 ある項目に対して示されたレベルが非常に低く「無視できる」あるいは有意差なしと判断できる場合 (リスクスケール 1～

100 において値 <1 の場合)、これらにマネジメント行為を施すよりも、別の分類に分離する方が良い場合がある。これにより次の定期リスクアセスメントを実施する際にこれら項目を見落とすことがなくなるだろう。また、分析によって特定され

たリスクすべての完全な記録を作成することができる。これらのリスクは、脅威の発生確率や脅威による影響が変化するこ

とにより、再評価時に新たなリスクレベルに移る可能性がある。このため、これら特定されたリスクを作業中に見失わない

ようにすることが重要である。


SP 800-30 Page 25

3.8 ステップ 8：推奨管理策

このステップでは、特定されたリスクを、組織の活動に適した方法で軽減または排除できる管理策を提示す

る。推奨管理策の目標は、IT システムとそのデータに対するリスクレベルを許容レベルにまで低減することである。以下は特定されたリスクを最小化または排除するための管理策と代替ソリューションを推奨する際に検

討すべき要因である。

• 推奨する選択肢の有効性 (例えば、システム互換性など)

• 法律や規制

• 組織方針

• 運用への影響

• 安全性や信頼性

リスクアセスメントプロセスの結果として管理策が推奨され、それがリスク軽減プロセスに組み込まれ、プロ

セス実施期間中に、推奨される手続き的もしくは技術的なセキュリティ管理策の評価、優先順位付け、導入が

行われる。

損失を低減するために、全ての推奨管理策が導入されるわけではないということを留意しなければならな

い。特定の組織にとってどの管理策が必要であり、適しているかを判断するには、提案された推奨管理策に

対して費用対効果分析 (第 4.6 節で述べる) を行い、管理策の導入によってリスクレベルが低減されることを

示し、それにかかるコストを正当化する必要がある。さらに、推奨する選択肢の導入による運用への影響 (例

えば、システムパフォーマンスへの影響など) や実現可能性 (例えば、技術的要件、利用者による容認など)

もリスク軽減プロセスにおいて慎重に評価すべきである。

ステップ 8のアウトプット ⎯ リスクを低減する管理策や代替ソリューションの推奨

3.9 ステップ 9：結果の文書化

リスクアセスメントが完了した後 (すなわち、脅威源及び脆弱性の特定、リスク評価、推奨管理策の提示後)、その結果は、公式の報告書または概要報告書として文書化する。

リスクアセスメント報告書は、ミッション遂行の責任者である経営陣が方針、手順、予算や、システムの運用

及び管理上の変更に関する意思決定を行う際に参考となる経営的レポートである。不正を発見する監査報告

あるいは調査報告とは異なり、リスクアセスメント報告は非難するような形で書かれるべきではない。系統的

かつ分析的手法によりリスクを評価し、経営陣がリスクを把握し、損失可能性を低減もしくは是正するための

資源を割り当てられるようにすべきである。このような理由から、リスクアセスメント報告では脅威／脆弱性の

組合せを指摘事項ではなく観察結果として扱うことを好む者もいる。付録 B に、リスクアセスメント報告の概要のサンプルを掲載する。

ステップ 9 のアウトプット－脅威と脆弱性、リスクアセスメントを説明し、管理策導入の推奨事項を記載するリスクアセスメント報告書


SP 800-30 Page 26

4. リスク軽減

リスクマネジメントの 2 番目のプロセスであるリスク軽減では、リスクアセスメントプロセスで推奨された適切なリスク低減管理策の優先順位付け、評価、導入を行う。

あらゆるリスクを排除することは通常非現実的であり、ほとんど不可能であることから、経営陣ならびに中

間管理職は、組織の資源やミッションに対する悪影響を最小限に保ちつつミッションにかかわるリスクを許容レベルにまで低減するために、最もコストのかからない手法を用いて、最も適した管理策を導入する責任を負う。

この節ではリスク軽減の選択肢 (第 4.1 節)、リスク軽減戦略 (第 4.2 節)、管理策導入のアプローチ (第4.3節)、管理策の分類 (第 4.4節)、推奨管理策の導入を正当化するための費用対効果分析 (第 4.5節)、残存リスク (第 4.6節) について説明する。

4.1 リスク軽減の選択肢

リスク軽減は経営陣がミッションにかかわるリスクを軽減するために用いる系統的な手法である。リスク軽

減は以下の選択肢のいずれを用いても実現可能である。

• リスク受容：潜在的リスクを容認し、IT システムの運用を続けるか、あるいは許容レベルにまでリスクを低減するための管理策を導入する。

• リスク回避：リスクの要因か結果のどちらか、もしくはその両方を排除することによりリスクを回避する (例えば、リスクが特定された場合、システムのある機能の実施を見送るかシステムをシャットダウンするなど)。

• リスク制限：脅威によって脆弱性が悪用されることで生じる悪影響を最小限に抑える管理策を導入して

リスクを制限する (例えば、サポート、予防、検知を行う管理策の活用など)。

• リスク計画：管理策の優先順位付け、導入、維持を行うリスク軽減計画を作成してリスクを管理する。

• 調査と認知：脆弱性または欠陥を認知し、脆弱性を是正する管理策を調査することにより損失リスクを

低減する。

• リスク移転：保険契約など損失を補填する他の選択肢を用いることによりリスクを移転する。

これらリスクを軽減する選択肢のいずれを選ぶ場合も、組織の目標やミッションを考慮すべきである。見つ

け出されたリスクすべてに対処することは現実的ではないため、ミッションに対する重大な影響または被害を

もたらす可能性のある脅威と脆弱性の組合せを優先させなければならない。さらに、組織のミッションや IT システムを保護する際、リスク軽減に用いる選択肢、及び管理策導入の手法は、各組織固有の環境や目的に

よってそれぞれ異なる場合がある。「最も優れた」アプローチは、さまざまなベンダーによるセキュリティ製品の

中から適切な技術を、適切なリスク軽減選択肢や非技術的な管理的手法と共に使用することである。


SP 800-30 Page 27

4.2 リスク軽減戦略

潜在的リスクと推奨管理策を認識しているミッション遂行の責任者である経営陣は、いつどのような状況で

行動を起こすべきなのか、これらのリスクを軽減し自らの組織を保護する管理策をいつ導入すべきなのかと

いう疑問を持つであろう。

図 4-1 に示すリスク軽減チャートがこれらの疑問に対する答えである。この図では、管理策を実行するのに適したポイントを YESで示している。

図 4-1 リスク軽減アクションのポイント

次の経験則ではこの戦略がさらに明確化されており、故意の人的脅威によるリスクを軽減する際のガイダ

ンスとなる。

• 脆弱性 (あるいは欠陥、弱点) が存在する場合脆弱性を悪用される可能性を低減する手法を導入する。

• 脆弱性を悪用される可能性がある場合多層保護、アーキテクチャ設計、運用的管理策を適用することにより脆弱性を悪用されないようにするか、あるいは悪用されるリスクを最小限に抑える。

• 攻撃に要するコストが、攻撃によって得られる利益より少ない場合攻撃に要するコストを増大させ攻撃者の意図をくじくような保護を適用する (例えば、システム利用者のアクセスや操作を制限するシステム管理策を適用することにより攻撃者の利益を大幅に低減することができる)。

• 損失があまりに大きい場合攻撃範囲の拡大を制限する設計原理、アーキテクチャ設計、技術的・非技術的保護を適用することにより損失の潜在的な発生を低減する。

上に概略を示した戦略は、3 番目に記したもの (攻撃に要するコストが、攻撃によって得られる利益より少ない場合) を除き、環境的脅威あるいは無作為の人的脅威 (例えば、システムや利用者のエラーなど) によってもたらされるリスクの軽減にも適用できる。(攻撃者がいないので、動機や利益も生じない。)

脅威源

システム設計

脆弱か？ YES YES

NO NO

YES YES

NO NO

つけこまれる可能性があるか？

攻撃の対象となる脆弱性が存在する

リスクなしリスクなし

リスクが存在する

攻撃者のコスト＜利益

予想損失＞閾値

容認できないリスク

リスク容認リスク容認


SP 800-30 Page 28

4.3 管理策導入のアプローチ

管理策を導入しなければならない場合は、次の規則が適用される。

最も重大なリスクに対処し、コスト及び他のミッションに関わる機能に対する影響を最小限に保ちつつ、十分にリスクを軽減できるように努める。

以下のリスク軽減手法は管理策導入に対するアプローチを示している。

• ステップ 1 －アクションの優先順位付け

リスクアセスメント報告書に記されたリスクレベルに基づいて実行すべきアクションの優先順位付けを行

う。資源割当てにおいては、許容できないほど高いリスクレベル (例えば、「非常に高い」あるいは「高い」リスクレベルに指定されたリスクなど) の項目を最優先にすべきである。これら脆弱性／脅威の組合せに対しては、組織の利益とミッションを守るため直ちに是正措置を取る必要がある。

ステップ 1のアウトプット－実行すべきアクションの「高」から「低」までの優先順位付け

• ステップ 2 －推奨管理策の評価

リスクアセスメントプロセスにおいて推奨された管理策は、特定の組織あるいは IT システムに対して最適または実現可能な選択肢ではない場合がある。このステップでは、推奨管理策の実現性 (例えば、互換性、利用者による受入れなど) や有効性 (例えば、保護の度合い及びリスク軽減レベルなど) を分析する。目標はリスクを最小化する最適な管理策を選択することである。

ステップ 2のアウトプット－実現可能な管理策のリスト

• ステップ 3 －費用対効果分析の実施

経営陣が意思決定をする際の助けとするため、また、費用対効果の高い管理策を特定するため、費用

対効果分析を実施する。第 4.5節では費用対効果分析実施の目的と手法について詳述する。

ステップ 3 のアウトプット－管理策を導入すること、あるいは導入しないことによるコストと利益を明らかにする費用対効果分析

• ステップ 4 －管理策の選択

費用対効果分析結果に基づいて、経営陣は組織のミッションに対するリスクを低減する最も費用対効果

の高い管理策を選択する。IT システムと組織にとって適したセキュリティとなるように、選択する管理策は技術、運用、管理の要素を組み合わせたものにすべきである。

ステップ 4のアウトプット－選択した管理策


SP 800-30 Page 29

• ステップ 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


SP 800-30 Page 30

図 4-2 リスク軽減手法のフローチャート

リスク低減アクティビティインプットアウトプット

• リスク評価報告によるリスクレベル

ステップ 1. 行為の優先順位付け

行為の「高」～

「低」の順位付け

ステップ 2. 推奨管理策の評価

• 実現可能性 • 有効性

• リスクアセスメント報告

実現可能な管理策

のリスト

ステップ 3. 費用対効果分析の実施

• 導入することによる影響 • 導入しないことによる影響 • 関連コスト

費用対効果分析

ステップ 4. 管理策の選択

選択された管理策

ステップ 5. 責任の割当て

責任者のリスト

ステップ 6. 管理策導入計画の作成

• リスク及び関連するリスクレベル • 優先順位の高いアクション • 推奨管理策 • 選択、計画中の管理策 • 責任者 • 開始日 • 完了予定日 • 保守要件

管理策導入計画

ステップ 7. 選択した管理策の導入

残存リスク


SP 800-30 Page 31

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に主な技術的管理策やそれらの間の関係を図示する。


SP 800-30 Page 32

図 4-3 技術的セキュリティ管理策

4.4.1.1 サポートのための技術的管理策

サポートのための管理策は、その性質そのもののために広く普及し、他の多くの管理策と関連する。サ

ポートのための管理策は次のようなものである。

• 識別：この管理策によって利用者、プロセス、情報資源を一意に識別できるようになる。他のセキュリ

ティ管理策 (例えば任意アクセス制御［DAC：Discretionary Access Control］、強制アクセス制御［MAC：Mandatory Access Control］、アカウンタビリティなど) を導入するにはサブジェクト（訳者注：アクションを起こす人や物）とオブジェクト（訳者注：アクションを受ける人や物）の両方が明確であることが不可欠で

ある。

• 暗号鍵管理：暗号機能を他のさまざまな管理策に導入する場合には、暗号鍵を安全に管理しなければ

ならない。暗号鍵管理には鍵の生成、配布、保存、及び保守などが含まれる。

• セキュリティ管理運用： IT システムのセキュリティ機能は、個別インストールの必要性を満たし、運用環境の変更に責任を持つように設定 (例えば、セキュリティ機能の有効化または無効化) しなければならない。システムセキュリティはオペレーティングシステムセキュリティまたはアプリケーションに組み込むこ

とができる。市販のアドオン型セキュリティ製品も利用可能である。

利用者またはプロセス

トランザクション

のプライバシー認証

許可

アクセス

制御実施

侵入検知及び

封じ込め

否認防止

監査

完全性証明

状態復帰

予防

検知、回復

サポート

資源

保護された通信 (開示、置換え、改変、及びリプレイ攻撃を受けない)

識別

暗号鍵管理

セキュリティ管理

システム保護(最小特権、オブジェクト再利用、プロセス分離など)


SP 800-30 Page 33

• システム保護：システムのさまざまなセキュリティ機能の基礎となっているものは、その技術の導入に

対する信頼である。この信頼の基となるのは、使用した設計プロセスや実装を実現する方法の両方の観

点から見た実装の品質である。システム保護の例としては、残存情報保護 (オブジェクト再利用とも呼ばれる)、最小特権 (あるいは "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]、セキュアシェルなど) は個人が実行するトランザクションにおいてプライバシーが失われることを防ぐ。


SP 800-30 Page 34

4.4.1.3 検知と回復のための技術管理策

検知のための管理策とはセキュリティポリシーに対する違反または違反の試みを警告するものであり、監査

証跡、侵入検知手法、チェックサムなどがこれに含まれる。回復のための管理策は失われたコンピューティン

グ資源を回復するために利用される。検知と回復のための管理策は、サポートや予防のための技術的対策

を補完するために必要とされる。なぜなら、サポートや予防の領域における対策はいずれも完全ではないた

めである。検知及び回復管理策には以下のものが含まれる。

• 監査：セキュリティ関連事象の監査や、システム異常の監視と追跡は、セキュリティ侵害の検知と侵害

からの回復において重要な要素となる。

• 侵入検知と封じ込め：セキュリティ侵害 (例えば、ネットワーク侵入、疑わしいアクティビティなど) の検知は、これらにタイムリーに対処するために不可欠である。ただし、効果的な対応策を取れなければ、セ

キュリティ侵害を検知してもほとんど役に立たない。侵入検知と封じ込め管理策は、これら検知と対応の

2つの能力を備えている。

• 完全性証明：完全性証明のための管理策 (例えば、システム完全性ツールなど) では、システムの完全性と異常を分析し、弱点の露出及び潜在的脅威を特定する。この管理策ではセキュリティポリシー違

反を防止することはできないが、違反を検知し必要な是正措置の種類を決定する助けとなる。

• 安全な状態への復帰：セキュリティ侵害発生後、システムはこのサービスにより安全であることが確認

されている状態に復帰できる。

• ウイルス検知及び駆除：サーバ及び利用者のワークステーションにインストールされたウイルス検知及

び駆除ソフトウェアはソフトウェアウイルスを検知、識別、駆除し、システムとデータの完全性を確保す

る。

4.4.2 管理的セキュリティ管理策

損失リスクを管理、低減し、組織のミッションを遂行するために、技術及び運用的管理策とともに管理的セ

キュリティ管理策を導入する。管理的セキュリティ管理策は情報保護ポリシー、ガイドライン、標準の規定に注

力する。これらは運用手順を通して実行され、組織の目標とミッションの達成を支える。

リスク低減のために導入する予防、検知、回復のための管理的セキュリティ管理策については、第 4.4.2.1節から第 4.4.2.3節で説明する。

4.4.2.1 予防のための管理的セキュリティ管理策

この管理策には以下が含まれる。

• 基幹 ITシステムに対して適切なセキュリティが施されるようにセキュリティに対する責任を割り当てる。

• 組織のミッションをサポートする IT システムに対する現在の管理策を文書化し、計画中の管理策を実施するために、システムセキュリティ計画を作成し、保守する。

• 職務の分離、最小特権、コンピュータ利用者のアクセス権登録と抹消を含む要員セキュリティ管理策を

導入する。


SP 800-30 Page 35

• エンドユーザやシステム利用者に行動規則と組織のミッション達成に対する責任を認識させるためにセ

キュリティ意識向上活動や技術トレーニングを実施する。

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 予防のための運用的管理策

予防のための運用的管理策は以下のとおりである。

• データ媒体へのアクセスやデータ媒体の廃棄を管理する (例えば、物理的アクセス管理、消磁手法など)。

• 外部データ配布を制限する (例えば、ラベル付けの利用など)。


SP 800-30 Page 36

• ソフトウェアウイルスを管理する。

• コンピュータ施設を保護する (例えば、警備員、来客に対する応対手順、電子バッジシステム、バイオメトリクスアクセス制御、錠と鍵の管理と配布、防壁や柵など)。

• ハブとケーブルを収納した配線盤を保護する。

• バックアップ機能を提供する (例えば、データとシステムの定期的なバックアップ手順、さまざまな回復シナリオで使用するためにデータベースのあらゆる変更を記録したアーカイブログなど)。

• オフサイトストレージに関する手順及びセキュリティを確立する。

• ラップトップ、パーソナルコンピュータ (PC)、ワークステーションを保護する。

• IT 資産を火災の被害から守る (例えば、消火器使用に対する要件と手順、防水シート、ドライスプリンクラーシステム、ハロン消火システムなど)。

• 非常用電源を確保する (例えば、無停電電源、オンサイト発電機の要件など)。

• コンピュータ施設の湿度と温度を管理する (例えば、空調装置の運転、熱分散など)。

4.4.3.2 検知のための運用的管理策

検知のための運用的管理策には以下が含まれる。

• 物理的セキュリティを導入する (例えば、動作検知装置、閉回路テレビによる監視、センサとアラームの利用など)。

• 環境面のセキュリティを確保する (例えば、煙探知器、火災探知器、センサとアラームの利用など)。

4.5 費用対効果分析

資源を割り当て、費用対効果の高い管理策を導入するために、組織は利用可能な管理策すべてを特定し、

それらの実現可能性と有効性を評価した後、提案された管理策それぞれについて費用対効果分析を行った

上で、どの管理策が現在の状況に対して必要とされ適したものであるかを判断する。

費用対効果分析には定性的なものと定量的なものがある。その目的は、管理策の導入コストをリスクレベ

ルの低減によって正当化できることを実証することである。例えば、200 ドル相当のリスクを低減するための管理策に 1,000 ドルを費やそうという組織はないであろう。

新たに提案された管理策や強化された管理策の費用対効果分析において行うことは以下のとおりである。

• 新規または強化された管理策を導入することによる影響を判断する。

• 新規または強化された管理策を導入しないことによる影響を判断する。

• 導入コストを推定する。コストには次のようなものがあるが、これに限定されるわけではない。

− ハードウェアとソフトウェアの購入

− セキュリティを向上させることによりシステム性能または機能が低下した場合の運用効率の低下

− ポリシーと手順を追加することによるコスト


SP 800-30 Page 37

− 提案された方針、手順やサービスを導入するための追加要員採用のコスト

− トレーニングコスト

− 保守コスト

• 導入コストと利益を、システムやデータの重要度に照らして評価し、コストと相対的影響を前提に組織に

とっての新規管理策導入の重要性を判断する。

組織は、ミッション遂行の全体像を考慮した上で、管理策によって得られる利益を評価する必要がある。必

要な管理策を導入することによるコストが存在するのと同様に、導入しないことによるコストも存在する。管理

策を導入しないことによるミッションへの影響を考えれば、導入を見送ることができるかどうかを判断できる。

費用対効果分析の例：システム X はミッションにとって重要かつ機密性の高い従業員のプライバシー情報を保存し処理するものであるが、現在システム監査はできない状態である。システム X に監査機能を持たせるべきかどうかを判断するために費用対効果分析を行う。

項目 (1) 及び (2) は新規管理策を導入するか、あるいは導入しないことによる、無形の影響 (例えば、抑止要因など) である。項目 (3) には有形の影響を列挙した (例えば、実際のコストなど)。

(1) システム監査機能を持たせる場合の影響：システム監査機能によりセキュリティ管理者は利用者のシ

ステムアクティビティを監視できるようになるが、システム性能を低下させ、このため利用者の生産性が

影響を受ける。また、導入のために項目 (3) に示す資源がさらに必要となる。

(2) システム監査機能を持たせない場合の影響：システム監査機能が働かない場合、利用者のシステム

利用状況や違反の監視／追跡ができなくなり、組織の機密データやミッションに対する最大限の保護

が得られなくなる。

(3) システム監査機能を持たせる場合のコスト推定：

システム監査機能の有効化－組み込み済み機能のためコストはかからない 0 ドル監査レビューとアーカイブを担当する要員追加 XX,XXX ドル／年トレーニング (例えば、システム監査設定、報告書生成) X,XXX ドル監査報告書生成用のアドオンソフトウェア X,XXX ドル監査データ保守 (例えば、ストレージ、アーカイブ) X,XXX ドル／年

推定総コスト XX,XXX ドル

組織の管理者は何がミッションに関連するリスクの許容レベルを規定するのかを判断しなければならない。

その後、組織が実現可能なリスクレベルの範囲を判断した後、管理策を採用または棄却することによる影響

を評価できる。ただし、この範囲は組織ごとに異なり新規管理策適用の判断には以下の規則を適用する。

• 管理策によるリスク低減が必要とされる以上であれば、より安価な代替案がないか検討する。

• リスク低減がもたらすものよりも管理策コストの方が大きい場合は、他の方法を検討する。

• 管理策が十分にリスクを低減しない場合は、さらに管理策を追加するか、別の管理策を探す。

• 管理策によって十分にリスクが低減され、費用対効果が高い場合は、その管理策を採用する。

管理策を導入するコストは導入しないコストよりも実体としてとらえやすいことが多い。したがって、経営陣

は組織のミッション遂行のための管理策の導入に関する意思決定において重要な役割を果たす。


SP 800-30 Page 38

4.6 残存リスク

組織は、新規または強化された管理策によって得られたリスク低減の程度を、組織のミッションに対するリ

スク軽減レベルを規定する 2 つのパラメータ（脅威の発生可能性の低減と脅威の影響の低減）という観点から分析できる。

新規または強化された管理策を導入すると以下の方法でリスクを軽減できる。

• システム脆弱性 (欠陥や弱点) のうち、幾つかを排除することにより、脅威源と脆弱性の組合せ可能数を低減する。

• 目標を絞った管理策を適用し、脅威源の能力と動機を低下させる。

例えば、ある部門が、機密性の高いファイルを保存するスタンドアローン PC にアドオン型のセキュリティソフトウェアをインストールし、保守するコストを正当化できないものの、この PC へのアクセスをより困難にする管理的、物理的管理策 (例えば、PC を鍵のかかる部屋に保管し、その鍵を管理者が管理するなど) は導入すべきと判断する場合などである。

• 影響の度合いを低減する (例えば、脆弱性の度合いを制限する、あるいは IT システムと組織のミッションの関係を変更するなど)。

管理策導入と残存リスクの間の関係を図式化したものを図 4-4に示す。

図 4-4 導入する管理策と残存リスク

新規または強化された管理策の導入後に残るリスクが残存リスクである。実際にリスクの全くない IT システムはなく、導入した管理策全てが意図したリスクを排除したり、リスクレベルをゼロにまで低減してくれるわ

けではない。

OMB Circular A-130に規定されるように、組織の IT資産とミッションを保護する責任を有する経営陣または指定承認者は、IT システムの運用開始または継続を認可 (または承認) しなければならない。この認可または承認は少なくとも 3 年ごと、あるいは IT システムに大幅な変更が加えられるたびに実施しなければならない。このプロセスの意図は IT システム内の完全に対処されていないリスクを特定し、これを軽減するために更に管理策が必要かどうかを判断することである。連邦機関の場合、特定されたリスクに対する適切な管

理策を適用後、指定承認者が残存リスクの全てを容認するステートメントに署名し、新しい IT システムの運用あるいは既存 ITシステムの継続運用を許可する。残存リスクが許容レベルにまで低減されていない場合、低減する方法を見出すためにリスクマネジメントサイクルを再度実施しなければならない。

新規または強化された管理策

欠陥またはエラー数の低減

残存リスク

目標を絞った管理策の適用

影響の度合いの低減


SP 800-30 Page 39

5. 評価とアセスメント

ほとんどの組織では、ネットワークそのものの拡張と更新が継続的に行われ、そのコンポーネントは変更を

加えられ、ソフトウェアアプリケーションは新しいバージョンに置換または更新される。さらに要員の異動も発

生し、セキュリティ方針も時間とともに変わる可能性が高い。これらの変更は、新たなリスクが顕在化し、以前

軽減されたリスクが再度懸念事項となる可能性があることを意味している。このため、リスクマネジメントプロ

セスは継続的で進化し続けるものである。

この章では、実践すべき優れた手法、継続的なリスク評価とアセスメントの必要性、リスクマネジメントプロ

グラムを成功に導く要因に重点を置いて説明する。

5.1 優れたセキュリティ実践手法

連邦機関の場合、OMB Circular A-130に従い、リスクアセスメントプロセスを通常少なくとも 3年ごとに繰り返す。しかしながら、リスクマネジメントは、法律または規制によって要求されるからではなく、それが実践すべ

き優れた手法であり、組織のビジネス目標またはミッションをサポートするものであることから、IT システムのシステム開発ライフサイクルに組み入れ、実施すべきである。ミッションに関連するリスクの評価、低減のため

に具体的日程を設定すべきである。ただし、定期的に実施するプロセスは、ポリシーあるいは新技術によって

もたらされる IT システムやその処理環境に対する大幅な変更に対処できるように、十分に柔軟であるべきである。

5.2 成功の鍵

リスクマネジメントプログラムの成功は以下の要因に依存する (1) 経営陣の責任、(2) IT チームの全面的サポートと参画 (第 2.3 節参照)、(3) リスクアセスメントチームの能力。チームはリスクアセスメント手法を特定のサイトやシステムに適用し、ミッションに関連するリスクを特定し、組織のニーズに合った費用対効果の高

い保護手段を提供するための専門知識を備えていなければならない。(4) 利用者コミュニティメンバの認識と協力。メンバは手順を守り組織のミッションを保護するために導入された管理策を順守しなければならない。

(5) ITのミッションに関連するリスクに対する継続的評価とアセスメント。

Copyright © 2005 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30 Page A-1

付録 A：インタビュー時の質問例

インタビューにおける質問は評価対象の IT システムが属するシステム開発ライフサイクルのフェーズに合わせて調整すべきである。組織の運用特性を理解するためにサイト要員に対するインタビューを行う際、尋ね

るべき質問には次のようなものがある。

• 正当な利用者は誰ですか。

• あなたの組織のミッションは何ですか。

• ミッションとの関係におけるシステムの目的は何ですか。

• あなたの組織のミッションにとってシステムはどれくらい重要ですか。

• システム可用性の要件は何ですか。

• 組織が必要とする情報 (入力と出力の両方) はどのようなものですか。

• システムが生成、利用、処理、保存、取得する情報はどのようなものですか。

• あなたの組織のミッションにとってその情報はどれくらい重要ですか。

• 情報が流れる経路はどのようなものですか。

• システムが処理、保存する情報はどのような種類のものですか (例えば、財務、人事、研究開発、医療、指揮統制など)。

• 情報の機密度 (または分類体系) はどのようなものですか。

• システムが処理する情報あるいはシステムに関する情報のうち開示すべきでないものはどのようなもの

ですか。また、開示すべきでない相手は誰ですか。

• 情報を処理、保存する具体的な場所はどこですか。

• 情報を格納するストレージの種類は何ですか。

• 許可されない者に情報が開示された場合の組織に対する潜在的影響はどのようなものですか。

• 情報の可用性と完全性に対する要件は何ですか。

• システムまたは情報に対する信頼性を得られない場合の組織のミッションに対する影響はどのようなも

のですか。

• 組織が許容できるシステムダウンタイムはどれくらいですか。このダウンタイムの平均修復／回復時間に対する割合はどれくらいですか。利用者が使用できる他の処理手段または通信手段の選択肢にはど

のようなものがありますか。

• システムやセキュリティの誤動作、あるいはこれらを利用できないことで、傷害または死を招く可能性が

ありますか。

Copyright © 2005 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30 Page B-1

付録 B：リスクアセスメント報告書サンプル（アウトライン）

エグゼクティブサマリ

I. 序論

• 目的 • 本リスクアセスメントの適用範囲

システムコンポーネント、要素、利用者、現場サイトの場所 (存在する場合)、評価時に検討すべきシステムに関するその他の詳細すべてについて記述する。

II. リスクアセスメントのアプローチ

リスクアセスメントの実施にあたって用いるアプローチについて例えば次のように略述する。

• 担当者 (例えば、リスクアセスメントチームのメンバなど) • 情報収集に用いる手法 (例えば、ツール、アンケートの利用など) • リスク尺度の作成と説明 (例えば、3 × 3、4 × 4、5 × 5のリスクレベルマトリクスなど)

III. システムの特徴定義

ハードウェア (サーバ、ルータ、スイッチ)、ソフトウェア (例えば、アプリケーション、オペレーティングシステム、プロトコルなど)、システムインタフェース (例えば、通信リンクなど)、データ、利用者などを含むシステムの特徴定義を行う。接続図やシステム入出力フローチャートを示し、このリスクアセスメント作業の

適用範囲を線引きする。

IV. 脅威ステートメント

評価対象システムに当てはまる潜在的脅威源とそれに伴う脅威行動を収集編纂しリストを作成する。

V. リスクアセスメント結果

観察結果 (脆弱性／脅威の組合せ) のリストを示す。各観察結果は以下の項目を含んでいなければならない。

• 観察番号と観察結果の簡単な説明 (例えば、観察結果 1：利用者システムパスワードを推定またはクラッキングできる、など)

• 脅威源と脆弱性の組合せに関する説明 • 既存のリスク軽減管理策の特定 • 脅威の発生可能性に関する説明及び評価 (例えば、高、中、低レベルの可能性など) • 影響分析に関する説明及び評価 (例えば、高、中、低レベルの影響など) • リスクレベルマトリクスに基づいたリスクレベルの決定 (例えば、高、中、低のリスクレベルなど) • リスク低減のための推奨管理策や代替管理策

VI. まとめ

観察結果の総まとめ。リスク軽減プロセスにおける推奨管理策の導入を促進するため、観察結果、対応

するリスクレベル、推奨事項、任意のコメントを表形式にまとめる。

Copyright © 2006 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30 Page C-1

付録 C：管理策導入計画一覧表（サンプル）

(1) リスク

(脆弱性／脅威の組合せ)

(2) リスクレベル

(3) 推奨管理策

(4) アクションの

優先順位

(5) 選択され計画中

の管理策

(6) 必要な資源

(7) 責任を有する

チーム／担当者

(8) 開始日／

完了日

(9) 保守要件／コメント

許可されない利

用者がサーバ

XYZに telnetし、guest IDを用いて機密に関す

る会社のファイル

を閲覧する。

高

• インバウンドの telnetを禁止する。

• 機密に関する会社のファイルに対しては

「ワールド」アクセス

を禁止する。 • 'guest' IDを無効にするか、推定の困難な

パスワードを割り当

てる。

高

• インバウンドの telnet を禁止する。

• 機密に関する会社のファイ

ルに対しては

「ワールド」ア

クセスを禁止

する。 • guest ID を無効にする。

システムの再構

成及びテストに

かかる時間は

10時間

サーバ XYZの管理者 John Doe、会社のファイ

アウォール管理者 Jim Smith

9-1-2001～9-2-2001

• サーバ XYZ に対して適切なセ

キュリティが設定

されていることを

確認するために

定期的にシステ

ムセキュリティレ

ビューとテストを

実施すること。

(1) リスク (脆弱性／脅威の組合せ) はリスクアセスメントプロセスのアウトプットである。 (2) 特定された各リスク (脆弱性／脅威の組合せ) に関連付けられたリスクレベルはリスクアセスメントプロセスのアウトプットである。 (3) 推奨管理策はリスクアセスメントプロセスのアウトプットである。 (4) 対策の優先順位はリスクレベルと利用可能な資源 (例えば、資金、要員、技術など) に基づいて決定する。 (5) 計画中の管理策は導入を推奨された管理策の中から選択する。 (6) 選択され計画中の管理策を導入するために必要な資源 (7) 新規または強化された管理策の導入に責任を持つチームまたは要員のリスト (8) 新規または強化された管理策導入の開始日及び予想完了日 (9) 新規または強化された管理策導入後の保守要件

Copyright © 2006 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30 Page D-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 E-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-2

IT関連リスク (IT-Related Risk) 以下を考慮したミッションに対する実質的影響：(1) 特定の脅威源によって特定の情報システムの脆弱性が悪用される (偶発的に衝かれるか、故意につけこまれる) 確率、及び (2) 万一このようなことが発生した場合にもたらされる影響。IT 関連リスクは以下の事象がもたらす法的責任またはミッション遂行機会の損失が原因で発生する。

1. 情報の不当な (悪意のある、あるいは偶発的な) 開示、改変、あるいは破壊

2. 意図的ではないエラーまたは怠慢

3. 自然災害または人為的災害による ITシステムの中断

4. IT システムの導入及び運用における相当の注意及び当然払うべき注意の不履行

ITセキュリティ目標 (IT Security Goal)

セキュリティ目標 (Security Goals) を参照。

リスク (Risk) 本文書内では IT関連リスクと同義である。

リスクアセスメント (Risk Assessment)

システムセキュリティに対するリスクを特定し、発生確率、もたらされる影

響、及びこの影響を軽減する保護手段追加を判断するプロセス。リスク

マネジメント (Risk Management) の一部であり、リスク分析 (Risk Analysis) と同義である。

リスクマネジメント (Risk Management)

情報システム関連リスクの特定、管理、及び軽減のための総合プロセ

ス。これには、リスクアセスメント、費用対効果分析、及び保護手段の選

択、導入、テスト、及びセキュリティ評価が含まれる。この総合的なシス

テムセキュリティレビューでは、ミッションに対する影響及び、方針、規

制、法律による制限を含め、有効性と効率の両方を検討する。

セキュリティ (Security) 情報システムセキュリティはシステムの特性であり、論理的及び物理的

にシステム全体にまたがる一連のメカニズムである。

セキュリティ目標 (Security Goals)

5 つのセキュリティ目標とは、完全性、可用性、機密性、アカウンタビリティ、及び保証である。

脅威 (Threat) 脅威源によって特定の脆弱性が悪用される (偶発的に衝かれるか、あるいは故意に悪用される) 可能性

脅威源 (Threat-source) (1) 脆弱性を故意に悪用することを目指す意図及び手法、あるいは (2) 脆弱性が偶発的に衝かれる状況及び手法、のいずれか。

脅威分析 (Threat Analysis) 特定の運用環境下における特定のシステムに対する脅威を判断するた

めに、システムの脆弱性に照らして脅威源を検討すること。

脆弱性 (Vulnerability) 悪用される (偶発的に衝かれるか、あるいは故意につけこまれる) ことによりセキュリティ侵害またはシステムセキュリティ方針違反を招く可能

性がある、システムセキュリティの手順、設計、導入、あるいは内部制御

における欠陥または弱点。

Copyright © 2006 独立行政法人情報処理推進機構及び NRIセキュアテクノロジーズ株式会社 SP 800-30 Page F-1

付録 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.

IT システムのためのリスク ... - ipa.go.jp · この文書は下記団体によって翻訳監修されています Special Publication 800-30 IT...

Documents