サプライチェーンの情報セキュリティマネジメント 第8回 ~ NIST SP800-161を中心に解説

前回に引き続きNIST SP800-161[1]の内容の解説を行います。

3. NIST SP 800-161の概要

第6回のコラムでも説明しましたが、NISTの規格、ガイダンスは米国政府機関が守るべき情報セキュリティマネジメントの指針を与えるものとしてスタートしました。これが、米国の重要インフラ、あるいは米国政府が調達する製品、サービスに対するサプライチェーンに係る組織への要求条件に拡大されています。
先にも紹介しましたが、米国政府機関に対して過去多くのセキュリティ侵害が発生しており、その多くはサプライチェーンを利用したものでした。また、単にサイバー攻撃による被害だけでなく、偽造品、不良品の混入、あるいは委託事業者を経由した情報漏洩など深刻な事例が相次ぎました。これらサプライチェーンに起因する様々な問題に対して組織1として対応するためのガイドラインと規格がNIST SP800-161でまとめられました。

この規格、ガイドラインの目的は、米国政府機関が利用する情報システムのライフサイクルを通して調達、利用する製品(ハードウエア、ソフトウエア)およびサービス(業務委託、ビジネスプロセスアウトソーシング、外部プロバイダのICTサービスの利用等)のICT サプライチェーンに対するリスクマネジメント(以降、ICT SCRM)の指針と必要となる管理策をまとめることです。
想定しているリスクは、図1に示すSecurity(セキュリティ)、Integrity(インテグリティ)、Resilience(レジリエンス)、Quality(品質)の4つになります。

  • セキュリティ:ICT サプライチェーンに関連した情報(製品、サービスに係る流通経路や内容等)、およびこれに係る関係者に関する情報の機密性、完全性、可用性への侵害。
  • インテグリティ:ICTサプライチェーンを通じて提供される製品、サービスの真正で変更されていないことおよび調達側の要求仕様以外の不要な機能が付加されていないことに対する侵害。
  • レジリエンス:ICTサプライチェーンに対して、想定外の影響を与える事象(自然災害等)あるいは障害が発生した場合でも必要な製品、サービスが供給可能であることに対する障害の発生。
  • 品質:利用される製品、サービスを構成するコンポーネントに対して意図された機能を制限したり、コンポーネントの障害を引き起こしたり、不正利用の機会を提供したりする可能性のある脆弱性。

図1にも示されていますが、これらのリスクはそれぞれ単独で起こり得ることもありますが、多くは相互に関連して発生することが想定されます。

図1. ICT SCRMの対象(SP800-161 Fig.1-1より)

図1. ICT SCRMの対象(SP800-161 Fig.1-1より)

  • 1: NIST SP800-161で「組織」とは米国政府機関を指すことになっています。本稿でもこれにならってこの用語を使用しますが、内容は汎用的であり重要インフラ事業者、あるいは大規模事業者等の民間組織と読み替えることも可能と考えられます。

ICTサプライチェーンインフラストラクチャ

NIST SP 800-161で対象としているICTサプライチェーンの中では、特に組織の内部で開発から試験、運用、維持管理、廃棄までを一貫して行うシステムに対するサプライチェーンとして”ICTサプライチェーンインフラストラクチャ”を定義しています。ICTサプライチェーンインフラストラクチャは、組織内部で行われるシステムのライフサイクル全体に渡って利用されるハードウエア、ソフトウエア、プロセスのサプライチェーンを統合したものであり、これに利用されるシステムインテグレータや外部サービスプロバイダも含まれます。具体的には、開発環境や組織内部の施設で働く要員、情報システムとそのコンポーネントの物流・配送、他のアプリケーションおよび通信インタフェースなども含まれます。開発や試験などに利用されるサービスインテグレータやシステムの運用に利用されるサービスプロバイダは、組織内でのシステムライフサイクルに直接かかわることから、NIST SP 800-161の規格の対象になることになり、これらは組織との合意形成の中で規定される必要があります。逆に、ICTサプライチェーンインフラストラクチャには、対象とするシステムのサプライチェーンに直接にはかかわらない情報システムやシステムインテグレータ、サプライヤ、外部サービスプロバイダの人員、プロセス、および技術は含まれません。

この規格では陽には記述されていませんが、通常このような組織内で開発から廃棄までのライフサイクル全体に渡って、カスタマイズされた形で利活用されるシステムは、組織にとってクリティカルなミッションに対応したものが多数あると考えられます。その分、ライフサイクルを考慮したサプライチェーンのリスクマネジメントが重要になると考えられます。

ICTサプライチェーンリスク

ICTサプライチェーンのリスク評価にあたっての一般的なプロセスを図2に示します。このフローは、第2章のNIST SP 800-30[2][3]リスク評価実施指針で述べたリスク評価プロセスのステップ2リスク評価の実施をICTサプライチェーンのリスク評価にアレンジしたものと言えます。

ICTサプライチェーンのリスクは、過去の事例でもわかる通り、その脆弱性は判明するまで数年かかる可能性もあります。また、発生したインシデントの原因がサプライチェーンに直接起因するものであるかどうかを判断することが困難な場合もあります。従って、このリスク評価は組織全体で継続的に実施していくことが必要です。
また、先に定義されているICTサプライチェーンインフラストラクチャに係るサービスインテグレータや外部サービスプロバイダは、このリスク評価に直接係ることで組織とリスクを共有することが重要です。NIST SP 800-161で示されている規格とガイダンスに従って、リスクを共有しその低減のために両者で協力して必要なセキュリティ管理策を実装することで効果的なリスクマネジメントが可能となります。このため、サービスインテグレータや外部サービスプロバイダが必要なICT SCRMを実装するためのコストが発生することになります。組織は、このコストの発生と、これを回避することで発生するリスクを評価して対応を判断することが求められます2

図2. ICTサプライチェーンのリスク評価(SP800-161 Fig.1-3より)

図2. ICTサプライチェーンのリスク評価(SP800-161 Fig.1-3より)

ここまでの前提を背景に、この規格では第2章で、組織、ミッション、情報システムの各Tier(階層)において必要なICT SCRMガイダンスを提供しています。これは、このコラムの第2章で紹介したNIST SP 800-39[4]および30の組織階層に対応したリスクマネジメントの指針とプロセスにICT SCRMを統合することを目標としています。また、第3章ではこれらのリスクマネジメントに必要となるICT SCRMに対応したセキュリティ管理策をNIST SP 800-53 Rev.4[5]の管理策に補足、追加する形でまとめています。以降、順次概要を解説します。

  • 2: ここまでで述べられている外部サービスプロバイダにはクラウドサービスプロバイダが含まれています。しかしながら、NIST SP 800-161はクラウドサービスプロバイダに対するリスク評価に直接対応したものではありません。クラウドサービスプロバイダに対してはまずFedRAMP(Federal Risk and Authorization Program:米国連邦政府クラウドの統一セキュリティ基準)[3]をベースとしたクラウドサービスセキュリティガイドラインに従うことが求められています。FedRAMPで対応しきれないプロセスや管理策が必要になった場合、この規格とガイドラインの適用が検討されることになります。

4. ICT SCRMの組織横断的なリスクマネジメントへの統合

NIST SP800-161でのリスクマネジメントはこのコラムの第2章で解説した、リスクマネジメントの体系であるNIST SP 800-39とリスク評価指針NIST SP 800-30をベースに構成されています。

4.1 ICT SCRMの組織階層に対応した役割

まず、ICT SCRMに関する組織階層に対応した役割の概要を表2に示します。第7回のコラム表1組織階層毎のリスク管理活動の例と対比して見ると、基本的にはICT SCRMに関して同じようなレベルの役割が求められています。また、これらの活動はそれぞれの階層で独立して行われるものでは無く、上位から下位、あるいはその逆の連携が必要になってくることがわかります(第7回コラム 図2)。

表2. ICT SCRMの組織階層に対応した役割
Tier 名称 代表的なICT-SCRM活動の役割
Tier1 組織 ①ICT-SCRMポリシーを、外部および組織の要件と制約(適用法令等)に基づいて確立する。これには、その目的、実行に必要な組織(組織全体でのICT-SCRMをモニタリングする組織を含む)、投資等が含まれる。
②ICT-SCRMポリシーの展開にあたって、ビジネス/ミッションレベルへのコスト,スケジュール,性能,セキュリティ,プライバシー,品質,安全性、及びICT-SCRM固有の問題等の制約を特定し、リスク許容度を設定して組織全体でのリスクマネジメント計画に統合する。
③以上を、組織全体でのリスク管理方針と活動(モニタリングを含む)に組み込む。
Tier2 ビジネス/ミッション ①ミッション/ビジネスを構成する重要なプロセスと関連するサプライチェーンリスクを特定する。
②サプライチェーンリスクに対応したICT-SCRM要件と管理策を特定しミッション/ビジネスプロセへ組み込む。また、これに対応する要員、チームを設立する。
③エンタープライズアーキテクチャへのICT-SCRM要件を統合し情報システムレベルでの管理策の実現の容易化を図る。
Tier3 情報システム ①ミッション/ビジネスを支援するシステムのシステムライフサイクルに渡るICT SCRMコントロールの適用、モニタリング、管理。

4.2 各階層の役割に対応した、ICT SCRMアクティビティ

NIST SP800-161ではNIST SP 800-39でまとめられている4つのリスクマネジメントプロセス;Frame(枠組), Assess(評価), Response(対応), Monitor(監視) をICT SCRMに対応させた場合に必要な各組織の役割に応じたアクティビティが整理されています。まず、4つのプロセスと一般的なリスク管理プロセスとの関係を図3に示します3。ここで示されたフローは単純にFrameからResponseまでが連続的に処理されるのではなく、相互に関係しながら進められるものと理解する必要があります。また、後に詳しく説明しますが、各階層に割り当てられたリスク管理の役割に応じて同時並行的に実行されることも意味しています。

図3. ICT SCRMのリスク管理プロセス(SP800-161 Fig.2-3より)

図3. ICT SCRMのリスク管理プロセス(SP800-161 Fig.2-3より)

  • 3: 一般的なリスク管理プロセスはISO/IEC 27005[7]で示されています。この図は、4つのマネジメントプロセスをこれに対応させたものと言えます。また、図2で示したICTサプライチェーンのリスク評価はこの図の脅威、脆弱性評価から影響分析までを一般化したものに対応しています。

ICT SCRMの組織階層に対応したアクティビティの要約を表3に示します。これは、各階層でそのレベルで必要な4つのリスク管理プロセスに対応したアクティビティを意味しています。それぞれのアクティビティは階層間でも関係しています。例えば、Frameでは組織レベルでICT SCRMのポリシーや組織全体にわたっての重要度の判断が行われますが、そのインプットとしてミッション/ビジネスレベルでの重要度の意思決定が行われるとともに、組織レベルの組織横断的な重要度の分析がフィードバックされる、といったことが考えられます。以降、4つのプロセスに関するより具体的なアクティビティを解説します。

表3. ICT SCRMの組織階層に対応したアクティビティ(SP800-161 Fig.2-3より)

表3. ICT SCRMの組織階層に対応したアクティビティ(SP800-161 Fig.2-3より)

4.3 Frame(枠組)

Frameプロセスで期待される結果は、組織におけるリスクマネジメント戦略の提示です。ICT SCRMでは組織において重要なシステムに影響を与えるサプライチェーンリスクを特定するための目標とその枠組みを各階層に対応して提供することにあります。Frameとは、これに引き続く3つのプロセス(評価、対応、監視)実行のための組織における現状の整理(As Is)から始まると言っても良いかと考えられます。また、サプライチェーンリスクは組織における情報セキュリティリスク全体の中で特定される必要があります。従って、Frameの実行には組織のセキュリティポリシー、戦略、ガバナンス、制約条件(法令、地理的条件等)、個別ミッション/ビジネスの重要度・セキュリティポリシー・セキュリティ要件、エンタープライズアーキテクチャと情報システムの機能・セキュリティ要件、といったものの現状が検討の前提条件(Input)になります。この中で、サプライチェーンリスクが影響を与える重要なミッション/ビジネスを特定するとともに、これに対するICT SCRMポリシー、ミッション/ビジネスに対する要件、情報システムに対する要件を特定することがアウトプットになります。表4に組織階層に対応したFrameのアクティビティの概要を示します。このアクティビティは、組織階層毎の役割に応じて相互に連携しながら実行されます(図の階層間の矢印)。また、Frame全体のアクティビティは他のプロセスからのインプットおよび他のプロセスへのアウトプットとしてリスクマネジメント全体でのPDCAを構成していることを意味しています(図の両端の矢印)。

表4. Frameプロセスのアクティビティ(SP800-161 Fig.2-5より)

表4. Frameプロセスのアクティビティ(SP800-161 Fig.2-5より)

ここで、ICT SCRM特有のインプットとしてサプライチェーンマップが挙げられています。これは、組織が利用する製品やサービスのサプライチェーンの流れを明確化したもので、リスク分析において不良品や偽造品、脅威エージェントがサプライチェーンに混入、侵入するポイントを特定することに利用されます。
また、Frameのアクティビティの出力でポイントとなるのは重要度の分析(Criticality Analysis4)です。これは組織に求められるビジネス目標・戦略を実行するミッション/ビジネスがセキュリティ侵害を受けることで被害を受けた場合のビジネス継続性への影響評価とこれに基づくミッション/ビジネスおよびこれを支援する情報システムの重要度です。FIPS199 [6]では機密性、完全性、可用性の観点での影響度評価を規定していますが、実際には侵害を受けた場合の復旧の容易性といったレジリエンシーなども考慮して決定する必要があります5。ICT SCRMの観点では、サプライチェーンの侵害、障害が発生した場合の影響度を分析することで重要度を決定して行くことになります。

NIST SP800-161ではFrameのアクティビティを実行するために4つのタスクを規定しています。以下では、それぞれの内容について説明します。

  • 4: Criticality Analysisは「致命度分析」とも訳されるがここではミッション/ビジネスおよびこれを支援する情報システムの侵害、障害に対する影響度の結果としてこのように訳している。
  • 5: 例えば、ある情報システムが侵害によって停止した場合の復旧時間や復旧までの代替の可能性(人手によるサービスの継続等)が考慮されます。

Task 1-1 組織内でリスクの評価、対応、監視に必要な前提条件を特定する

このタスクを実行する前提は、先に述べた組織のセキュリティポリシー、戦略、ガバナンスを始めとするAs Isです。また、ICTサプライチェーンに関連した脅威および脆弱性情報の前提および発生の可能性と影響評価の考え方を提示する必要があります。

脅威の前提

ICTサプライチェーンの脅威に関して大きくは、①悪意のあるサイバー/物理的攻撃、②人為的ミス、③地政学的混乱、経済の激変、自然災害や人為的災害などが想定されます。特に、①に関する例としては、表5に示すものが例示されています。脅威情報は、常に変化しているため過去の脅威事象を含め政府機関、民間事業者等様々な外部リソースから収集する必要があります。これらのリソースを特定しておくこともポイントになります。

表5. 脅威分析の前提 脅威の例6(SP800-161 Table 2-2より)
脅威の主体 シナリオ
偽造品混入 要求条件の厳しいシステムへの偽造品の混入による性能、故障率等の劣化 犯罪グループが、金銭的利益を得るために偽のICTコンポーネントを取得、販売する。具体的には、組織犯罪グループが、処分されたユニット、過剰在庫品を探して購入し、青写真を取得して、さまざまなグレーマーケットリセラーを通じてアクアイアに販売する。
内部犯行 知的財産の損失 組織に不満を持つ内部犯行者が、金銭的利益を含むさまざまな理由で、知的財産を競合他社または外国の諜報機関に売却または譲渡する。 知的財産には、ソフトウェアコード、設計図、またはドキュメントが含まれる。
海外の諜報機関 マルウェアの挿入 海外の諜報機関によりICTサプライチェーンを突破してマルウェアが混入され、機密情報の漏洩、ミッション、システムの運用の妨害、破壊が行われる。
テロリスト 不正アクセス テロリストがICTサプライチェーンを突破、あるいは妨害し不正に情報を取得、あるいはシステムの停止、破壊等を行う。
産業スパイ/サイバー犯罪 知的財産の損失 産業スパイ/サイバー犯罪者が、ICTサプライチェーンに侵入して情報を収集したり、システムやミッションの運用を停止させる方法を探す(例、HVAC, Heat, Ventilation, Air Conditioning請負業者に侵入し、クレジットカード情報を窃取する)。

これらの脅威情報は、各階層でそれぞれの役割に応じて利用されることになります。表6にICTサプライチェーンにおける脅威分析の階層毎の役割を示します。これは、想定される脅威に対して各階層の役割に基づいて脅威に対抗するための分析を行う指針を示しています。

  • 6: NIST SP 800-161ではより詳細なサプライチェーンに対する悪意のあるサイバー攻撃の脅威がいわゆるKill Chainに対応してAppendix Cに示されています。これらは、より詳細な脅威の例としてNIST SP 800-30 Rev.1のAppendix Eで示されている脅威の例からICTサプライチェーンに関係したものが抽出されています。
表6. ICTサプライチェーンにおける脅威分析の階層毎の役割(SP800-161 Table 2-3より)
Tier 検討課題 方法
Tier1
  • 組織のミッション/ビジネス
  • サプライアとの戦略的関係
  • ICTサプライチェーンの地理的分散に関する配慮
  • ICTサプライチェーンの脅威を特定する共通の取り組みの開始点を確立する。
  • 重要なシステムやコンポーネントへの偽造品の挿入など、組織全体の脅威に対抗するための組織レベルでの手順を確立する。
Tier2
  • ミッションの機能
  • 地理的位置
  • サプライアのタイプ(COTS, 外部サービス提供業者、特注等)
  • 組織で共通に利用される技術
  • 組織ミッションに対応した付加的な脅威情報を特定する。
  • 組織のICTサプライチェーン情報により特定されるサプライアとその所在地に基づいて、潜在的な脅威の発生源を特定する(たとえば、サプライチェーンマップから)。
  • 組織のICTサプライチェーン情報を使用して、特定される、ミッション機能に対応した脅威の発生源を見通す。
  • ミッションに応じた脅威の評価方法を確立する。
Tier3
  • システム開発ライフサイクル
  • システム開発ライフサイクルの各フェーズで考慮すべき脅威の詳細レベルを基準化する。
  • システム開発ライフサイクルの各プロセス毎に脅威が挿入される可能性に基づいて、脅威の発生源を特定、精緻化する。

COTS: Commercial Off-The-Shelf

脆弱性の前提

脆弱性とは、セキュリティ侵害や障害を発生させる可能性のある情報システム、システムセキュリティ手順、内部統制、または実装の脆弱性です。特に、ICTサプライチェーンで考慮すべき脆弱性の発生はシステム開発ライフサイクルに対応して、以下の3点があげられます。

  • ① システムのコンポーネント
  • ② システムの開発、試験、運用環境
  • ③ 利用されるICTシステム、コンポーネント(論理的にまたは物理的に)を輸送する物流・配送環境

これらを考慮した、各階層で実施される脆弱性分析の枠組を表7に示します。

表7. ICTサプライチェーンの脆弱性分析の枠組7(SP800-161 Table 2-4より)
Tier 検討課題 方法
Tier1
  • 組織のミッション/ビジネス
  • サプライア関係(COTS, 外部サービス提供業者等)
  • ICTサプライチェーンの地理的分散に関する配慮
  • 組織のセキュリティアーキテクチャ
  • 重要度の基準
  • サプライチェーンマップからの情報を含む、組織のICTサプライチェーン情報を調査し、特に脆弱なサプライアとその所在地を特定する。
  • 組織ミッションの潜在的脆弱性に対する感度を分析する。
  • システムインテグレータとサプライア関係の潜在的脆弱性に対する感度を分析する。
  • エンタープライズアーキテクチャと基準の限界を確認し、より堅牢なICTサプライチェーンを検討する必要がある弱点の領域を特定します。
Tier2
  • ミッションの機能
  • 地理的位置
  • サプライアのタイプ(COTS/特注等)
  • 組織で利用される技術
  • 特定のミッション機能と対応する脅威およびサプライチェーン情報に基づいて、Tier1からの分析を精緻化する。
  • Common Vulnerabilities and Exposures(CVE)およびCommon Vulnerability Scoring System(CVSS)を含むNational Vulnerability Database(NVD)を使用して、脆弱性の特徴付け、分類、およびスコアリングを検討する。
  • スコアリングガイダンスを用いて、優先すべき脆弱性の修正を検討する。
Tier3
  • 個々の技術、ソリューション、サプライアの考慮。
  • 可能な範囲でCVEを使用して、脆弱性を特定し、分類する。
  • その他の弱点を特定する。
発生可能性と発生した場合の影響の前提

セキュリティ侵害の発生の可能性は、脅威と脆弱性に基づいて判断されます。この場合、他組織での侵害、障害の例や脅威源が脆弱性を突く可能性等から判断されます。また、影響に関しては、自組織への影響だけでなく関係するステークホルダ(個人、サプライア、国家等)への影響も考慮しておく必要があります。

Task 1-2 組織内でリスクの評価、対応、監視に対する制約条件を特定する。

リスクマネジメントを実行するにあたって、組織には様々な制約が存在します。一般的には、予算、必要な要員の数とスキル、法制度あるいは契約上の制限(特に地域が異なる場合)、レガシーシステムの存在、組織カルチャ(新しい技術への取り組み姿勢)などがあります。これらは、組織全体で考慮する制約とICTサプライチェーンに対する制約に分けられます。表8は組織階層毎に制約を明確化しておく必要のある項目を示しています。

表8. 制約を明示する必要のある項目(SP800-161 Table 2-5より)
Tier 組織の制約 ICTサプライチェーンの制約
Tier1
  • 組織の戦略、ポリシー、ガバナンス
  • 利用できる法制度
  • ミッション機能
  • 組織プロセス(セキュリティ、品質等)
  • 組織の既存のポリシー、戦略、およびガバナンス(適用される法律および規制; ミッション機能; と組織のプロセス)に基づくICT SCRMポリシー。
Tier2
  • ミッション機能
  • 機能の限界
  • エンタープライズアーキテクチャ
  • ミッションレベルのセキュリティポリシー
  • ミッション/ビジネスプロセスおよびエンタープライズアーキテクチャに組み込まれているICT SCRMミッション/ビジネス要件
Tier3
  • 機能要求
  • セキュリティ要件
  • システムレベルのICT SCRM要件
Task 1-3 組織におけるリスクの受容度を評価する。

リスク受容度は、組織の目的、戦略的目標を達成する上で受け入れる必要のあるリスクです。組織は、リスク受容度の全体的なレベルを特定する際に、ICTサプライチェーンの脅威、脆弱性、制約、および重要度の基準を考慮する必要があります。リスク受容度は、組織レベルの判断に基づいて決定されるべきであり、この指針に基づいてミッション/ビジネス、情報システム階層へと展開される必要があります。

Task 1-4 リスク管理において組織が考慮する優先順位とトレードオフを特定する。

組織はICTサプライチェーンの脅威、脆弱性、制約、および重要度の基準を考慮してミッション/ビジネスおよび対応する情報システムに関する情報セキュリティ保護の優先順位とトレードオフを計画しておく必要があります。

Frameプロセスのアウトプット

Frameプロセスのアウトプットはその後のプロセス(評価、対応、監視)へのインプットとして何らかの形での文書化が要求されます。

  • ① ICT SCRMポリシー
  • ② ミッション/ビジネスの重要度基準、セキュリティ重要度(FIPS199ベース)
  • ③ ICT SCRMにおける評価、対応、監視プロセスのガイダンス
  • ④ ビジネス/ミッションの要件とこれに対応するICT SCRMの要件
  • ⑤ 上記の対応したミッション/ビジネスプロセスとエンタープライズアーキテクチャの改訂
  • ⑥ システムレベルのICT SCRM要件

ここで、①のポリシー策定にあたっては組織固有のビジネス目標、戦略に対応したICT SCRMの位置づけ、組織階層の定義や役割等を明確化しておく必要があります。組織化にあたっては、組織がICT製品、サービスを受け入れる場合の最終リスク責任者、ハード・コンポーネントの調達・交換等に関与する調達、保守技術者、これらを受け入れる受入れエンジニア、システム保守担当、システムセキュリティエンジニア、エンドユーザーと言ったICT SCRMに関与するステークホルダ(組織内部、システムインテグレータ、外部サービスプロバイダ)の類型を指定しておくことが要求されます。

以上、今回はFrameプロセスまでを解説してきました。次回は残りの3つのプロセスの解説を続けます。

参照文献

  • [1] NIST, SP800 161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations, 2015.
  • [2] NIST, SP 800-30 Rev.1 Guide for Conducting Risk Assessments, 2012.
  • [3] FedRAMP ホームページ, https://www.fedramp.gov/.
  • [4] NIST, SP 800-39 Managing Information Security Risk, Organization, Mission, and Information System View, 2011.
  • [5] NIST, SP 800-53 Rev.4 Security and Privacy Controls for Federal Information Systems and Organizations.
  • [6] NIST, FIPS199, Standards for Security Categorization of Federal Information and Information Systems, 2004.2.
  • [7] ISO/IEC, 27005 Information technology — Security techniques — Information security risk management, 2018.

Writer Profile

NTTデータ先端技術株式会社 フェロー
工学博士、CISSP, CISA
三宅 功