ページの先頭です

ページ内を移動するためのリンク
本文(c)へ

セキュリティの部屋

Sec2023-01-02_欧米の各種規格等の最新動向と概要【ドラフト版】

2023.4.3

Sec2023-01-02_欧米の各種規格等の最新動向と概要【ドラフト版】

■■この資料の趣旨■■

概要

  • 本要約資料は、サイバーセキュリティ関連の国際標準であるISO/IEC27002:2022等で提示された内容の目次項目およびポイントを要約したものである。
  • 具体的な内容は、各規格書原本の本文を参照していただきたい。

記載している国際標準、業界標準

  • ISO/IEC27001:2022 「情報セキュリティ、サイバーセキュリティ及びプライバシー保護 - 情報セキュリティ管理策」
  • (作成予定)
    • NIST SP800-53 Revision 5 組織と情報システムのためのセキュリティおよびプライバシー管理策
    • NIST SP800-61 Revision 1 コンピュータセキュリティ インシデント対応ガイド
    • NIST SP800-171 [Rev.1] 連邦政府外のシステムと組織における管理された非格付け情報の保護
    • NIST SP800-172_制御された未分類の情報を保護するための強化されたセキュリティ要件:NIST SP800-171の補足
    • NIST SP800-207 Zero Trust Architecture
    • NIST CSF 重要インフラのサイバーセキュリティを改善するためのフレームワーク
    • 欧州サイバーセキュリティ法(CSA) 、NLF関連指令/規則、NIS指令(Directive (EU) )
    • EU一般データ保護規則(GDPR)

原本

この要約資料の改版履歴

  • 2023年4月3日 0.2.3版
  • 2023年2月20日 0.2.2版
  • 2023年2月13日 0.1版

■■ ISO/IEC27002:2022 ■■

1 概要

0.1 背景と文脈
  • このドキュメントは、あらゆる種類と規模の組織を対象としています。
  • 情報セキュリティは、ポリシー、ルール、プロセス、手順、組織構造、ソフトウェアおよびハードウェア機能を含む一連の適切な制御を実装することによって実現されます。
0.2 情報セキュリティ要件
  • a)組織の全体的なビジネス戦略と目的を考慮した、組織に対するリスクの評価。これは、情報セキュリティ固有のリスク評価を通じて促進またはサポートできます。これにより、組織に対する残存リスクがリスク受容基準を満たすことを保証するために必要な管理策が決定されるはずです。
  • b)組織とその利害関係者 (取引パートナー、サービス提供者など) が遵守しなければならない法的、法定、規制、および契約上の要件と、その社会文化的環境。
  • c)組織がその運用をサポートするために開発した、情報のライフサイクルのすべてのステップに関する一連の原則、目的、およびビジネス要件。
0.3 コントロール
  • コントロールは、リスクを修正または維持する手段として定義されます。このドキュメントのコントロールには、リスクを変更するコントロールもあれば、リスクを維持するコントロールもあります。たとえば、情報セキュリティ ポリシーはリスクを維持することしかできませんが、情報セキュリティ ポリシーを遵守することでリスクを修正することができます。さらに、一部のコントロールは、異なるリスク コンテキストで同じ一般的な測定を記述します。このドキュメントは、国際的に認められたベスト プラクティスから導き出された、組織、人、物理的、および技術的な情報セキュリティ コントロールの一般的な組み合わせを提供します。
0.4 管理策の決定
  • コントロールの決定は、明確に定義された範囲で、リスク評価に続く組織の決定に依存します。特定されたリスクに関連する決定は、リスク受容の基準、リスク対応オプション、および組織が適用するリスク管理アプローチに基づく必要があります。管理の決定では、関連するすべての国内および国際的な法律および規制も考慮に入れる必要があります。コントロールの決定は、コントロールが相互に作用して多層防御を提供する方法にも依存します。
  • 組織は、必要に応じてコントロールを設計したり、任意のソースからコントロールを識別したりできます。このような統制を指定する際、組織は、実現されたビジネス価値に対する統制を実装および運用するために必要なリソースと投資を考慮する必要があります。ISMSへの投資に関する決定のガイダンス、およびリソースに対する競合する要件のコンテキストにおけるこれらの決定の経済的影響については、ISO/IEC TR 27016を参照してください。
  • コントロールを実装するために配置されたリソースと、それらのコントロールがない場合にセキュリティインシデントから生じるビジネスへの潜在的な影響との間でバランスを取る必要があります。リスク評価の結果は、適切な管理アクション、情報セキュリティリスクを管理するための優先順位、およびこれらのリスクから保護するために必要と判断された制御を実装するためのガイドおよび決定に役立つはずです。
  • このドキュメントのコントロールの一部は、情報セキュリティ管理の指針となる原則であり、ほとんどの組織に適用できるものと見なすことができます。コントロールの決定およびその他のリスク対応オプションの詳細については、ISO/IEC 27005 を参照してください。
0.5 組織固有のガイドラインの作成
  • このドキュメントは、組織固有のガイドラインを作成するための出発点と見なすことができます。このドキュメントのすべてのコントロールとガイダンスがすべての組織に適用できるわけではありません。組織の特定のニーズと特定されたリスクに対処するために、このドキュメントに含まれていない追加の管理策とガイドラインが必要になる場合もあります。追加のガイドラインまたは管理策を含むドキュメントを作成する場合、将来の参照用にこのドキュメントの条項への相互参照を含めると便利な場合があります。
0.6 ライフサイクルに関する考慮事項
  • 情報には、作成から廃棄までのライフサイクルがあります。情報の価値とリスクは、このライフ サイクル全体で変化する可能性があります (たとえば、企業の金融口座の無許可の開示や盗難は、公開された後は重要ではありませんが、完全性は依然として重要です)。したがって、情報セキュリティは依然としてある程度重要です。すべての段階。
  • 情報システムおよび情報セキュリティに関連するその他の資産には、構想、仕様設定、設計、開発、テスト、実装、使用、保守、そして最終的にはサービスの廃止と廃棄というライフサイクルがあります。情報セキュリティは、すべての段階で考慮する必要があります。新しいシステム開発プロジェクトと既存システムの変更は、組織のリスクとインシデントから学んだ教訓を考慮しながら、セキュリティ管理を改善する機会を提供します。
0.7 関連する国際規格
  • このドキュメントは、多くの異なる組織で一般的に適用される幅広い情報セキュリティ管理策に関するガイダンスを提供しますが、ISO/IEC27000ファミリーの他のドキュメントは、情報セキュリティ管理のプロセス全体の他の側面に関する補足的なアドバイスまたは要件を提供します
  • ISMS と一連のドキュメントの概要については、ISO/IEC 27000を参照してください。ISO/IEC 27000は、ISO/IEC27000ファミリーのドキュメント全体で使用されるほとんどの用語を定義する用語集を提供し、ファミリーの各メンバーの範囲と目的を説明しています。
  • 特定の領域に対処することを目的とした追加の制御を備えたセクター固有の規格があります (例:クラウド サービスのISO/ IEC 27017、プライバシーのISO/IEC 27701、エネルギーのISO/IEC 27019、電気通信組織のISO/IEC27011、およびISO27799健康のため)。そのような基準は参考文献に含まれており、その一部は条項5から8のガイダンスおよびその他の情報セクションで参照されています。

1 適用範囲

  • a) ISO/IEC 27001に基づく情報セキュリテイマネジメントシステム(ISMS)
  • b) 国際的に認められている最適な慣行に基づいて情報セキュリティ管理策を実施するため
  • C) 組織固有の情報セキュリテイマネジメントの指針を作成するため

2 引用規格(参考文献)

  • このドキュメントには規範的な参照はありません。

3 用語、定義および略語

  • ISO及びIECは,標準化に使用するための用語のデータベースを次のアドレスに維持している。
  • ISOオンラインブラウジングプラットフォーム:https://www.iso.org/obp
  • IECエレクトロペディア:https://www.electropedia.org/
3.1 用語と定義
  • このドキュメントでは、次の用語と定義が適用されます。
  • ISOおよびIECは、次のアドレスで標準化に使用する用語データベースを維持しています。
  • -- ISO オンライン ブラウジング プラットフォーム: https://www.iso.org/obp で利用可能
  • -- IEC エレクトロペディア: https://www.electropedia.org/ で入手可能
3.1.1 アクセス制御 (accesscontrol)
  • 資産(3.1.2)への物理的および論理的アクセスが、ビジネスおよび情報セキュリティ要件に基づいて承認および制限されることを保証する手段
3.1.2 資産 (asset)
  • 組織にとって価値のあるものすべて
  • 注記1:情報セキュリティの文脈では、2種類の資産を区別することができます:
  • 一次資産:
  • 情報;
  • ビジネスプロセス (3.1.27)と活動
  • すべてのタイプのサポートアセット(プライマリアセットが依存するもの)。たとえば、次のとおりです。
    • ハードウェア;
    • ソフトウェア;
    • ネットワーク;
    • 人員 (3.1.20) ;
    • サイト;
    • 組織の構造。
3.1.3 攻撃 (attack)
  • 資産を破壊、変更、無効化、アクセスする試み(3.1.2)の無許可の試みの成功または失敗、または資産 の公開、盗難、または無許可の使用(3.1.2)の試み
3.1.4 認証 (authentication)
  • エンティティ の主張された特性(3.1.11)が正しいという保証の提供
3.1.5 真正性(信憑性) (authenticity)
  • エンティティ (3.1.11)が主張するものであるというプロパティ
3.1.6 受渡記録(親権の連鎖)(chainof custody)
  • ある時点から別の時点までの資料の所持、移動、取り扱い、および場所の証明
  • 注記 1:資料には、 ISO/IEC 27002の文脈における情報およびその他の関連資産 (3.1.2)が含まれます。
  • [出典:ISO/IEC 27050-1:2019, 3.1, modified -- "Note 1 to entry" を追加]
3.1.7 秘密情報(機密情報)(confidential information)
  • 許可されていない個人、エンティティ(3.1.11)またはプロセス(3.1.27)に提供または開示されることを意図していない情報
3.1.8 管理策(コントロール) (control)
  • リスクを維持および/または修正する手段
  • 注記 1:コントロールには、プロセス (3.1.27)、ポリシー (3.1.24)、デバイス、慣行、またはリスクを維持および/または修正するその他の条件および/またはアクションが含まれますが、これらに限定されません。
  • 注記2:コントロールは、意図した、または想定した変更効果を常に発揮するとは限りません。
  • [出典:ISO 31000:2018、3.8]
3.1.9 事業の中断・阻害 (disruption)
  • 組織の目的に応じた製品およびサービスの予想される配送からの計画外の負の逸脱を引き起こす、予期されていたかどうかにかかわらず、インシデント。
  • [出典:ISO 22301:2019、3.10]
3.1.10 終端装置(エンドポイント デバイス) (endpoin device)
  • ネットワークに接続された情報通信技術 (ICT) ハードウェア デバイス
  • 注記 1:エンドポイント デバイスは、デスクトップ コンピューター、ラップトップ、スマートフォン、タブレット、シンクライアント、プリンター、またはスマート メーターやモノのインターネット (IoT) デバイスを含むその他の特殊なハードウェアを指す場合があります。
3.1.11 エンティティ(実在物)(entity)
  • 認識可能なほど明確に存在するドメインの運用目的に関連する項目
  • 注記1実体は、物理的又は論理的な具現化を持つことができる。
  • 例:個人、組織、デバイス、そのようなアイテムのグループ、テレコム サービスの加入者、SIM カード、パスポート、ネットワーク インターフェイス カード、ソフトウェア アプリケーション、サービス、または Web サイト。
  • [出典:ISO/IEC 24760-1:2019、3.1.1]
3.1.12 情報処理施設,情報処理設備 (information processing facility)
  • 情報処理システム、サービス、インフラストラクチャ、またはそれを収容する物理的な場所
  • [出典:ISO/IEC 27000:2018、3.27、修正 -- 「施設」は施設に置き換えられました。]
3.1.13 情報セキュリティ侵害 (information security breach)
  • 送信、保存、またはその他の方法で処理された、保護された情報の望ましくない破壊、損失、改ざん、開示、またはアクセスにつながる情報セキュリティの侵害
3.1.14 情報セキュリティ事象(イベント) (information security event)
  • 情報セキュリティ違反 (3.1.13)または制御 の失敗(3.1.8)の可能性を示す発生
  • [出典:ISO/IEC 27035-1:2016、3.3、修正 -- 「情報セキュリティの違反」は「情報セキュリティの違反」に置き換えられました]
3.1.15 情報セキュリティインシデント (information security incident)
  • 組織の資産(3.1.2)に損害を与えたり、組織の運営を危険にさらしたりする可能性がある、 1 つまたは複数の関連し、特定された情報セキュリティ イベント (3.1.14) 。
  • [出典:ISO/IEC 27035-1:2016、3.4]
3.1.16 情報セキュリティインシデント管理 (information security incident management)
  • 情報セキュリティインシデント の処理に対する一貫した効果的なアプローチの実施 (3.1.15)
  • [出典:ISO/IEC 27035-1:2016、3.5]
3.1.17 情報システム (information system)
  • アプリケーション、サービス、情報技術資産 (3.1.2)、またはその他の情報処理コンポーネントのセット
  • [出典:ISO/IEC 27000:2018、3.35]
3.1.18 利害関係者 (interested party)
  • 決定または活動に影響を与える、影響を受ける、または影響を受けると認識できる人または組織
  • [出典:ISO/IEC 27000:2018、3.37]
3.1.19 否認防止 (non-repudiation)
  • 主張された事象または行動の発生とその元の実体 (3.1.11)を証明する能力
3.1.20 要員 (personnel)
  • 組織の指示の下で仕事をする人
  • 注記 1:人員の概念には、組織の構成員、例えば、統治機関、経営陣、従業員、臨時職員、請負業者、およびボランティアが含まれます。
3.1.21 個人を特定できる情報 (PII)(personally identifiable information)
  • (a)情報とその情報が関係する自然人との間のリンクを確立するために使用できる情報、または (b) 自然人と直接または間接的にリンクしている、またはリンクできる情報。
  • 注記 1:定義における「自然人」はPII プリンシパル (3.1.22)です。PII プリンシパルが識別可能かどうかを判断するには、PII のセットと自然人の間のリンクを確立するために、データを保持するプライバシー利害関係者またはその他の当事者が合理的に使用できるすべての手段を考慮する必要があります。
  • [出典:ISO/IEC 29100:2011/Amd.1:2018, 2.9]
3.1.22 PII主体 (PII principal)
  • 個人を特定できる情報 (PII) (3.1.21) が関連する自然人
  • 注記 1:法域および特定のデータ保護とプライバシーに関する法律によっては、「PII プリンシパル」という用語の代わりに「データ主体」という同義語を使用することもできます。
  • [出典:ISO/IEC 29100:2011、2.11]
3.1.23 PII処理者 (PII processor)
  • 個人を特定できる情報 (PII) (3.1.21)を、PII 管理者に代わって、その指示に従って処理するプライバシー利害関係者。
  • [出典:ISO/IEC 29100:2011、2.12]
3.1.24 方針 (policy)
  • トップマネジメントによって正式に表明された、組織の意図と方向性
  • [出典:ISO/IEC 27000:2018、3.53]
3.1.25 プライバシー影響評価 (privacy impact assessment)
  • 個人を特定できる情報(PII) (3.1.21)の処理に関して、潜在的なプライバシーへの影響の処理を特定、分析、評価、コンサルティング、伝達、および計画する全体的なプロセス (3.1.27)であり、組織のより広範なリスク管理の枠内に収まるものフレームワーク
  • [出典:ISO/IEC 29134:2017, 3.7, modified -- エントリの注 1 を削除]
3.1.26 手順 (procedure)
  • 活動またはプロセス を実行する特定の方法(3.1.27)
  • [出典:ISO 30000:2009、3.12]
3.1.27 プロセス (process)
  • 入力を使用または変換して結果を提供する、相互に関連または相互作用する活動のセット
  • [出典:ISO 9000:2015、3.4.1、修正 -- エントリへの注記が削除されました。]
3.1.28 記録 (record)
  • 法的義務を追求するため、またはビジネスの取引において、組織または個人によって証拠および資産 (3.1.2)として作成、受信、および維持される情報。
  • 注記 1:この文脈における法的義務には、法律上、法定上、規制上、および契約上のすべての要件が含まれます。
  • [出典:ISO 15489-1:2016, 3.14, modified -- "Note 1 to entry" を追加]
3.1.29 復旧ポイント目標 (recoverypoint objective) RPO
  • 中断 (3.1.9)が発生した後、データが回復される時点
  • [出典:ISO/IEC 27031:2011、3.12、修正 -- 「しなければならない」を「あるべきである」に置き換えた。]
3.1.30 復113時間目標 (recovery time objective) RTO
  • 中断 (3.1.9)が発生した後、最小限のレベルのサービスおよび/または製品、およびそれをサポートするシステム、アプリケーション、または機能を回復する期間
  • [出典:ISO/IEC 27031:2011、3.13、修正 -- 「しなければならない」を「あるべきである」に置き換えた。]
3.1.31 信頼性 (reliability)
  • 一貫した意図された動作と結果の特性
3.1.32 規則 (rule)
  • 何をする必要があるか、何が許可され、何が許可されないかについての組織の期待を述べる、受け入れられた原則または指示。
  • 注記 1規則は、トピック固有のポリシー (3.1.35)およびその他の種類のドキュメントで正式に表現できます。
3.1.33 取扱いに慎重を要する情報 (sensitive information)
  • 個人、組織、国家安全保障、または公共の安全に悪影響を及ぼす可能性があるため、利用不能、不正アクセス、変更、または公開から保護する必要がある情報
3.1.34 酋威 (threat)
  • システムまたは組織に損害を与える可能性のある望ましくないインシデントの潜在的な原因
  • [出典:ISO/IEC 27000:2018、3.74]
3.1.35 トピック固有の個別方針 (topic-specific policy)
  • 適切なレベルの管理者によって正式に表明された、特定の主題またはトピックに関する意図と方向性
  • 注記1トピック固有のポリシーは、規則 (3.1.32)または組織の標準を正式に表現することができます。
  • 注記2:一部の組織では、これらのトピック固有のポリシーに別の用語を使用しています。
  • 注記3:このドキュメントで言及されているトピック固有のポリシーは、情報セキュリティに関連しています。
  • 例:アクセス制御 に関するトピック固有のポリシー(3.1.1)、クリア デスクおよびクリア スクリーンに関するトピック固有のポリシー。
3.1.36 利用者 (user)
  • 組織の情報システム (3.1.17)にアクセスできる利害関係者 (3.1.18 )
  • 例:人員 (3.1.20)、顧客、サプライヤー
3.1.37 利用者終端装置 (user endpoint device)
  • ユーザーが情報処理サービスにアクセスするために使用するエンドポイント デバイス (3.1.10)
  • 注記 1:ユーザー エンドポイント デバイスは、デスクトップ コンピューター、ラップトップ、スマートフォン、タブレット、シン クライアントなどを指す場合があります。
3.1.38 ぜい弱性 (vulnerability)
  • 1 つ以上の脅威 (3.1.34)によって悪用される可能性がある資産 (3.1.2)またはコントロール (3.1.8)の弱点。
  • [出典:ISO/IEC 27000:2018、3.77]
3.2 略称

この文書の構成

4.1 箇条
  • a) 組織的管理策 (箇条5)
  • b) 人的管理策 (箇条6)
  • c) 物理的管理策 (箇条7)
  • d) 技術的管理策 (箇条8)
4.2 テーマ及び属性
箇条5~8に示す管理策の分類を、テーマと呼ぶ。
  • a) 個人に関係する場合は、人的
  • b) 物理的対象に関係する場合は、物理的
  • c) 技術に関係する場合は、技術的
  • d) それ以外の場合は、組織的と分類される。
属性値(それらを検索可能にするために"#"を前に付けている)をもつ五つの属性に関連付けている。
4.2.1 a)管理策タイプ
  • 管理策タイプは、情報セキュリティインシデントの発生との関係において、リスクを管理策がいつどのように修正するかという観点から管理策を見る属性。
  • 予防(Preventive)(情報セキュリティインシデントの発生を予防することを意図した管理策)
  • 検知(Detective)(Detective)(情報セキュリティインシデントの発生時に機能する管理策)
  • 是正(Corrective)(情報セキュリティインシデントの発生後に機能する管理策)
4.2.2 b)情報セキュリティ特性
  • 情報セキュリティ特性は、管理策が情報のどの特性を維持するのに寄与するかという観点から管理策を見る属性
  • 機密性 (Confidentiality)
  • 完全性(|ntegrity)
  • 可用性(Availability)
4.2.3 c)サイバーセキュリティ概念
  • サイバーセキュリティ概念は、1S0/IEC TS27110に記述されているサイバーセキュリティフレームワーク(CSF)で定義されたサイバーセキュリティ概念との管理策の関連付けの観点から管理策を見る属性
    • (※ISO/IEC TS 27110は、クラウドサービスプロバイダーとクラウドサービスユーザー間でのセキュリティの共有責任を説明し、クラウドサービスプロバイダーが提供するクラウドサービスの安全性を確保するために必要なリスク評価、セキュリティポリシーの策定、セキュリティ監視およびアウトソーシング契約に関する要件などを定義している。)
  • 識別(Identify)
  • 防御(Protect)
  • 検知(Detect)
  • 対応(Respond)
  • 復旧(Recover)
4.2.4 d)運用機能
  • 運用機能は、実践者の情報セキュリティ機能の観点から管理策を見る属性
  • ガバナンス(Governance)
  • 資産管理(Asset_management)
  • 情報保誰(lnformation_protection)
  • 人的資源のセキュリティ(Humanresourcesecurity
  • 物理的セキュリティ(Physical_security)
  • システム及びネットワークのセキュリティ(Systemandnetwork_security)
  • アプリケーションのセキュリティ(Application_security)
  • セキュリティを保った構成(Secure_configuration)
  • 識別情報及びアクセスの管理(ldentityandaccess_management)
  • 脅威及びぜい弱性の管理(Threat andvulnerabilitymanagement)
  • 継続(Continuity)
  • 供給者関係のセキュリティ(Supplierrelationshipssecurity)
  • 法及び順守(LegalandCompliance)
  • 情報セキュリティ事象管理(lnformationsecurityevent_management)
  • 情報セキュリティ保証(lnformation_security assurance)
4.2.5 e)セキュリティドメイン
  • セキュリティドメインは、四つの情報セキュリティドメインの観点から管理策を見る属性
  • ガバナンス及びエコシステム(Governanceand Ecosystem)
    • (内部及び外部の利害関係者を含め)情報システムセキュリティのガバナンス及びリスクマネジメント、エコシステムサイバーセキュリテイマネジメントを含む
  • 保護(Protection)
    • ITセキュリティアーキテクチャ、ITセキュリティ管理、識別情報及びアクセスの管理、ITセキュリティ保守、物理的及び環境的セキュリティを含む
  • 防御(Defence)
    • 検知、コンピュータセキュリティインシデント管理を含む
  • 対応力(Resilience)
    • 運用の継続、危機管理を含む。
4.3 管理策の構成
  • 管理策の標題: 管理策の短い名称
  • 属性の表: その管理策に該当する各屈性の値を表で示している。
  • 管理策: 管理策が何であるか。
  • 目的: なぜ管理策を実施することが望ましいか。
  • 手引: どのように管理策を実施することが望ましいか。
  • その他の情報: 説明文又はその他の関連文書の参照

【ISO/IEC27001:2022より】4.マネジメント基準(ISO/IEC27001:2013→2022)

4.1 マネジメント基準
4.2 記載内容について
4.3 凡例
4.4 情報セキュリティマネジメントの確立
  • 4.4.1 組織の役割、責任及び権限 [27001:2013-5.3 / 5.1]
  • 4.4.2 組織及びその状況の理解 [27001:2013-4.1]
  • 4.4.3 利害関係者のニーズ及び期待の理解 [27001:2013-4.2]
  • 4.4.4 適用範囲の決定 [27001:2013-4.3]
  • 4.4.5 方針の確立 [27001:2013-5.2 / 6.2 / 5.1]
  • 4.4.6 リスク及び機会に対処する活動 [27001:2013-6.1]
  • 4.4.7 情報セキュリティリスクアセスメント [27001:2013-6.1.2]
  • 4.4.8 情報セキュリティリスク対応 [27001:2013-6.1.3]
A.4.5_情報セキュリティマネジメントの運用
  • 4.5.1 資源管理 [27001:2013-7.1 / 5.1]
  • 4.5.2 力量、認識 [27001:2013-7.2 / 7.3 / 5.1]
  • 4.5.3 コミュニケーション [27001:2013-7.4]
  • 4.5.4 情報セキュリティマネジメントの運用の計画及び管理 [27001:2013-8.1]
  • 4.5.5 情報セキュリティリスクアセスメントの実施 [27001:2013-8.2 / 8.3]
A.4.6_情報セキュリティマネジメントの監視及びレビュー
  • 4.6.1 有効性の継続的改善 [27001:2013-10.2 / 8.2 / 9.2 / 9.3 / 5.1]
  • 4.6.2 パフォーマンス評価 [27001:2013-9]
  • 4.6.3 マネジメントレビュー [27001:2013-9.3]
A.4.7_情報セキュリティマネジメントの維持及び改善
  • 4.7.1 是正処置 [27001:2013-10.1]
A.4.8_文書化した情報の管理
  • 4.8.1 文書化 [27001:2013-7.5.1]
  • 4.8.2 文書管理 [27001:2013-7.5.2 / 7.5.3]

5 管理策

A.5_組織的対策
  • 5.1 情報セキュリティのための方針群

    • テーマ及び属性
    • 管理策タイプ:#予防
    • 情報セキュリティ特性:#機密性、#完全性、#可用性
    • サイバーセキュリティ概念:#識別
    • 運用機能:#ガバナンス
    • セキュリティドメイン:#ガバナンス及びエコシステム、#対応力
    • 管理策
    • 情報セキュリティ方針及びトヒ°ック固有の個別方針は,これを定義し,経営陣によって承認され,発行し,関連する要員及び関連する利害関係者へ伝達し認識され,計画した間隔で及び重要な変化が発生した場合にレビューすることが望ましい。
    • 目的
    • 事業,法令,規制及び契約上の要求事項に従って,経営陣の方向性の継続的な適合性,適切性,有効性,及び情報セキュリティのサポートを確実にするため。
    • 手引
    • 組織は,方針群の最も商いレベルに, 一つの"情報セキュリティ方針"を定めることが望ましい。この情報セキュリティ方針は, トップマネジメントによって承認されるものであり,組織の情報セキュリティの管理に対する取組を示すものである。
    • 情報セキュリティ方針は,次のものから導き出される要求事項を考慮に入れることが望ましい。
      • a) 事業戦略及び要求事項
      • b)規制,法令及び契約
      • C) 現在の及び予想される情報セキュリティのリスク及び脅威
    • 情報セキュリティ方針には,次の事項に関する記載を含めることが望ましい。
      • a) 情報セキュリティの定義
      • b) 情報セキュリティの目的,又は情報セキュリティの目的を設定するための枠組み
      • c) 情報セキュリティに関する全ての活動の指針となる原則
      • d) 情報セキュリティに関連する適用可能な要求事項を満たすことのコミットメント
      • e) 情報セキュリテイマネジメントシステムの継続的な改善へのコミットメント
      • f) 情報セキュリテイマネジメントに関する責任の,定められた役割への割当て
      • g) 逸脱及び例外を取り扱う手順
    • 情報セキュリティ方針のいかなる変更もトップマネジメントが承認することが望ましい。
      • 方針群のより低いレベルでは,情報セキュリティ方針は,必要に応じて情報セキュリテイ管理策の実施をさらに義務付けるために, トピック固有の個別方針によって支持されることが望ましい。トピック固有の個別方針は, 一般に組織内の対象となる特定のグループの要求に対処するように,又は特定のセキュリティ領域を対象とするように構成されている。トピック固有の個別方針は, 組織の情報セキュリティ方針に沿い,それを補完することが望ましい。
    • このような個別方針のトピックの例を,次に示す。
      • a) アクセス制御
      • b) 物理的及び環境的セキュリティ
      • c) 資産管理
      • d) 情報の転送
      • e) 利用者終端装岡の安全な構成及び取扱い
      • f) ネットワークセキュリティ
      • g) 情報セキュリティインシデント管理
      • h) バックアップ
      • i) 暗号及び鍵管理
      • j) 情報の分類及ぴ取扱い
      • k) 技術的ぜい弱性の管理
      • l) セキュリティに配應した開発
    • トピック固有の個別方針の作成,レビュー及び承認に関する百任は,関連する要員に,彼らの適切なレベルの権限及び技術的力最に基づいて割り当てることが望ましい。レビューには,次のものの変化に応じた,組織の情報セキュリティ方針及びトヒ°ック固有の個別方針並びに情報セキュリティの管理に関する,改善の機会の評価を含めることが望ましい。
      • a) 組織の事業戦略
      • b) 組織の技術環境
      • C) 規制,法律及び契約
      • d) 情報セキュリティリスク
      • e) 現在の及び予想される情報セキュリティの西威の環境
      • f) 情報セキュリティ事象及びインシデントから学んだ教訓
    • 情報セキュリティ方針及びトピック固有の個別方針のレビューでは,マネジメントレビュー及び監査の結果を考盛することが望ましい。一貰性を維持するため,一つの方針を変更する場合は, 他の関連する方針のレビュー及び更新を検討することが望ましい。
    • 情報セキュリティ方針及びトヒ゜ック固有の個別方針は,意図する読者にとって適切で,アクセスでき,かつ理解しやすい形式で,関連する要員及ぴ利害関係者に伝達することが望ましい。該当する場合には,方針の受領者に,方針を理解したこと及びその順守に同意することの確認を求めることが望ましい。組織は,これらの方針文書について,組織の要求を満たす形式及び名称を決定することができる。組織によって,情報セキュリティ方針及びトピック固有の個別方針を単一の文害にすることがある。組織は,これらのトピック固有の個別方針に,標準,指令,方針,その他の名称を付けることがある。
    • 情報セキュリティ方針及びトピック固有の個別方針を組織外に配布する場合には,秘密情報を開示しないように注意することが望ましい。
    • 表1に,情報セキュリティ方針とトピック固有の個別方針との違いを示す。
    • 文書化し,正式に承認する人
      • 情報セキュリティ方針:トップマネジメント
      • トピック固有の方針:適切なマネジメントレベル
  • 5.2 情報セキュリティの役割と責任

  • 5.3 職務の分離
  • 5.4 管理責任
  • 5.5 当局との連絡
  • 5.6 特別利益団体との接触
  • 【新規】5.7 Threat intelligence(脅威インテリジェンス)
    • 情報セキュリティの脅威に関連する情報を収集・分析し、「脅威インテリジェンス」を作成
      • 脅威インテリジェンスとは、脅威の防止や検知に利用できる情報の総称(情報≠脅威インテリジェンス)
      • サイバー攻撃等の感知・防御や、同業他社で発生したような セキュリティインシデントの発生防止のため
    • 例えば
      • 定期的にIPA やセキュリティベンダーの発信情報を収集する
      • 収集した脅威インテリジェンスを適切な部門や組織に展開し、リスク分析など適切な対応をとる
      • システムの不具合や脆弱性、脅威などを検知した際の報告先・対応手順を策定する
  • 5.8 プロジェクト管理における情報セキュリティ
  • 5.9 情報およびその他の関連資産のインベントリ
  • 5.10 情報およびその他の関連資産の許容される使用
  • 5.11 資産の返却
  • 5.12 情報の分類
  • 5.13 情報のラベル付け
  • 5.14 情報の転送
  • 5.15 アクセス制御
  • 5.16 アイデンティティ管理
  • 5.17 認証情報
  • 5.18 アクセス権
  • 5.19 サプライヤー関係における情報セキュリティ
  • 5.20 サプライヤー契約における情報セキュリティへの対応
  • 5.21 ICTサプライチェーンにおける情報セキュリティの管理
  • 5.22サプライヤーサービスの監視、レビュー、変更管理
  • 【新規】5.23 Information security for use of cloud services(クラウドサービス利用のための情報セキュリティ)
    • クラウドサービスに関して選定~契約~利用~終了までの方針・規定をあらかじめ決めておく
      • 障害により使えなくなる、クラウドサービス側への攻撃、利用者の設定ミスなど、クラウドサービスを利用する際の情報セキュリティリスクの防止・対応のため
      • 旧規格の供給者管理について、クラウドをより特筆したもの
    • 例えば
      • クラウドサービスの選定基準を決める
      • 自社とクラウドサービス提供者の責任分界点を明確にする(自社の責任を把握する)
      • インシデント発生時などに備え、自社とクラウドサービス提供者間の連絡経路を明確にする
      • クラウドサービスの管理方法を決める(管理者の特定、アクセス権、容量・能力の管理方法など)
      • クラウドサービスの利用契約内容に変更がないか確認する
      • クラウドサービスの利用終了時や変更時、停止時などに必要な手順を明確にする
  • 5.24 情報セキュリティインシデント管理の計画と準備
  • 5.25 情報セキュリティ事象の評価及び決定
  • 5.26 情報セキュリティインシデントへの対応
  • 5.27 情報セキュリティインシデントから学ぶ
  • 5.28 証拠の収集
  • 5.29 中断時の情報セキュリティ
  • 【新規】5.30 ICT readiness for business continuity(事業継続のためのICTの備え)
    • ICTサービスに関しての事業継続計画策定、実施、維持、テストを行う
      • ICTサービスとは、インターネットのような通信技術を活用したサービスのこと
      • 例)自社で提供するサービス、業務で利用するクラウドサービスなど
      • 災害やインシデント発生等によりICTシステムが故障しない、または故障しても資産が損なわれないように可用性を維持する
    • 例えば
      • ICTサービス停止による事業への影響を評価し、優先順位の高い活動や ICT サービスを特定する
      • 復旧時間目標(RTO)と復旧ポイント目標 RPO を設定する
      • ICTサービス停止に備え、以下を含む ICT 継続計画を策定しておく
        • 役割/権限
        • 設定したRTO/RPO を含む ICT サービスの対応・復旧手順
        • RTO/RPOを満たすための ICT サービスの容量・能力の使用
      • 対応/復旧手順は演習やテストを通して、定期的に実施・評価しておく
  • 5.31 法的、法的、規制および契約上の要件
  • 5.32 知的財産権
  • 5.33 記録の保護
  • 5.34 プライバシーとPIIの保護
  • 5.35 情報セキュリティの独立したレビュー
  • 5.36 情報セキュリティに関する方針、規則及び基準の遵守
  • 5.37 文書化された操作手順
A.6_人的対策
  • 6.1 スクリーニング
  • 6.2 雇用条件
  • 6.3 情報セキュリティの認識、教育およびトレーニング
  • 6.4 懲戒手続き
  • 6.5 雇用の終了または変更後の責任
  • 6.6 守秘義務または秘密保持契約
  • 6.7 リモートワーク
  • 6.8 情報セキュリティ イベントの報告
A.7_物理的対策
  • 7.1 物理的なセキュリティ境界
  • 7.2 物理エントリー
  • 7.3 事務所、部屋、施設の確保
  • 【新規】7.4 Physical security monitoring(物理的セキュリティの監視)
  • 7.5 物理的および環境的脅威からの保護
  • 7.6 安全な場所での作業
  • 7.7 クリアデスクとクリアスクリーン
  • 7.8 機器の配置と保護
  • 7.9 オフプレミスの資産のセキュリティ
  • 7.10 ストレージメディア
  • 7.11 サポートユーティリティ
  • 7.12 ケーブルのセキュリティ
  • 7.13 機器のメンテナンス
A.8_技術的対策
  • 8.1 ユーザーエンドポイントデバイス
  • 8.2 特権アクセス権
  • 8.3 情報アクセス制限
  • 8.4 ソースコードへのアクセス
  • 8.5 安全な認証
  • 8.6 キャパシティ管理
  • 8.7 マルウェアに対する保護
  • 8.8 技術的脆弱性の管理
  • 【新規】8.9 Configuration management(構成管理)
  • 【新規】8.10 Information deletion(情報削除)
  • 【新規】8.11 Data masking(データマスキング)
  • 【新規】8.12 Data leakage prevention(データ漏洩防止)
  • 8.13 情報のバックアップ
  • 8.14 情報処理設備の冗長化
  • 8.15 ロギング
  • 【新規】8.16 Monitoring activities(監視活動)
  • 8.17 クロック同期
  • 8.18 特権ユーティリティ プログラムの使用
  • 8.19 運用システムへのソフトウェアのインストール
  • 8.20 ネットワークのセキュリティ
  • 8.21 ネットワークサービスのセキュリティ
  • 8.22 ネットワークの分離
  • 【新規】8.23 Web filtering(Webフィルタリング)
  • 8.24 暗号の使用
  • 8.25 安全な開発ライフサイクル
  • 8.26 アプリケーションのセキュリティ要件
  • 8.27 安全なシステム アーキテクチャとエンジニアリングの原則
  • 【新規】8.28 Secure coding(セキュアコーディング)
  • 8.29 開発および受け入れにおけるセキュリティテスト
  • 8.30 外部委託開発
  • 8.31 開発、テスト、本番環境の分離
  • 8.32 変更管理
  • 8.33 テスト情報
  • 8.34 監査テスト中の情報システムの保護

Anex A (Informative) 属性の使用

Anex B (Informative) ISO/IEC 27002:2022とISO/IEC 27002:2013との対応

【米国】国家のサイバーセキュリティの改善に係る米国大統領令の署名

  • 官民の脅威情報共有における障害の除去(Section 2)
  • 連邦政府におけるより強力な標準の近代化と導入(Section 3)
  • ソフトウェア・サプライチェーンのセキュリティ向上(Section 4)
  • サイバー安全審査委員会の創設(Section 5)
  • インシデント対応のための標準プレイブックの策定(Section 6, 7)
  • 調査及び修復能力の向上(Section 8)

【米国】セキュリティ関連NIST文書

NIST SP800-53 Revision 5

NIST SP800-61 Revision 1 コンピュータセキュリティ インシデント対応ガイド

NIST SP800-171 [Rev.1] 連邦政府外のシステムと組織における管理された非格付け情報の保護

NIST SP800-172_制御された未分類の情報を保護するための強化されたセキュリティ要件:NIST SP800-171の補足【2021年2月】

NIST SP800-207 Zero Trust Architecture

...

NIST CSF 重要インフラのサイバーセキュリティを改善するためのフレームワーク

【欧州】サイバーセキュリティ法(CSA) 、NLF関連指令/規則、NIS指令 (Directive (EU) )

  • 2010年1月1日、欧州連合(EU)では、「既存のニューアプローチ指令の整合化を促進する枠組み」であるNLF(New Legislative Framework)が策定された。
  • サイバーセキュリティ法(Regulation (EU) 2019/881)は、欧州初の統合されたサイバーセキュリティ認証の枠組み
  • 2020年12月、欧州委員会は、域内の重要インフラ事業者等のサイバーセキュリティ対策について規定するNIS指令(Directive (EU) 2016/1148)の改訂案を公表
  • 2022年5月13日 欧州連合理事会、重要インフラセキュリティ対策を強化するNIS2指令をEU各国に適用
    • 欧州連合理事会と欧州議会は、EU全域の重要インフラセキュリティ対策を強化するNIS2指令を加盟各国に適用すること合意した。
  • NIS2指令は、2016年に成立した「ネットワークと情報システムのセキュリティに関する指令(NIS指令)」を改定し、対象分野の拡大やサイバーレジリエンスの強化などを行う

【欧州】 EU一般データ保護規則(GDPR)

ページトップへ