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

前回に引き続きNIST SP800-161[1]のリスクマネジメントプロセスに関する解説を行います。

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

4.4 Assess(評価)

Assessプロセスは図2で示すように、組織およびビジネス/ミッションレベルの重要度の分析の更新から始まります。これは、Frameプロセスで一旦分析されていた重要度をビジネス環境の変化やミッション/ビジネスの見直し、システムの変更・更改などを反映して見直すことを意味しています。また、脅威分析や脆弱性分析もAssessプロセスでの新しい変化を反映した状況認識に基づいて、連携して行われることになります。Assessプロセスの入力、アクティビティ、出力の概要を表9に示します。この表も、表4のFrameのアクティビティと同様に他のプロセスおよび組織階層間での連携を示しています。

表9. Assessプロセスのアクティビティ(SP800-161 Fig. 2-6より)

Assessプロセスでの重要なアクティビティは、重要度分析、脅威分析、脆弱性分析になります。これらは、相互に連携して実行される必要があります。Assessのアクティビティに対しても、以下の3つのタスクが規定されています。

Task 2-0 重要度分析:ミッションクリティカルな機能、システム、およびコンポーネントの重要度分析を更新して、ICT SCRMリスク評価の範囲および必要なリソースを組織として最も重要なものに絞り込む

このタスクでは、Frameプロセスで得られている重要度を見直すことから開始さます。新たに変更されたミッション/ビジネスプロセスおよび対応するエンタープライズアーキテクチャがインプットになります。ICT SCRMの見直しの対象はシステム/コンポーネントそのものだけでなくこれに係るシステムインテグレータ、サプライア、外部サービスプロバイダが含まれます。また、ICTサプライチェーンインフラストラクチャが適用されるシステムに対してはそのシステム開発ライフサイクルを考慮した検討が必要になります。この新たな前提に基づいて、Frameプロセスの重要度分析の結果が見直されます。Assessプロセスではより多くの情報が利用可能であることから、重要度分析の対象を絞り、反復による評価の精度をあげることが可能です。これにより以下のような詳細な分析を行う事が可能になります。

  • ① 情報システムのアーキテクチャを機能要素に分解して把握し、重要な機能が依存するセキュリティ機能(アクセス制御、暗号化、ディジタル署名等)などの依存関係を明確化する。
  • ② 重要なシステムで利用されるICTシステム/コンポーネントのサプライチェーンマップを含むサプライチェーンに関連した情報を入手する。
  • ③ これらの情報と、重要なシステムに対するサプライチェーン、履歴データとシステム開発ライフサイクルプロセスを相関させて、ICTサプライチェーン経路を識別する。
  • ④ 重要なシステムに対するサプライチェーン全体に渡ってのアクセスポイントを識別しそのコントロールを特定する。
  • ⑤ システム開発ライフサイクル全体で悪意のある変更が発生する可能性(例えば、バックドアの混入)を検討する。

Task 2-1 組織の情報システムとそのシステムが運用されている環境に対する脅威と脆弱性を分析、特定する

脅威分析

ICTサプライチェーンの脅威分析の対象は情報システムに係るシステムインテグレータ、サプライア、外部サービスプロバイダまでが含まれます。基本的な脅威の例は表5(より詳細な脅威の例はNIST SP 800-161 Appendix C[1])に示されています。しかし、最新の脅威情報はさまざまな外部リソース(オープンソース、セキュリティベンダー、政府機関等)からの情報を加味する必要があります。これらの情報源はFrameプロセスの段階で指定されていますが、Assessの段階での見直しも必要になると思われます。

また、自組織のインシデント管理に基づいてICTサプライチェーンに対する侵害の有無、侵害が発生したと判断される場合の原因の特定もフィードバックする必要があります。従って、システム/コンポーネントまたはSDLC1System Development Life Cycle:システム開発ライフサイクル)環境への変更を把握し、監視メカニズムを利用してサプライチェーンへの攻撃発生の有無、発生した場合のインシデントデータの収集、および特定の攻撃で使用される戦術、テクニック、および手順を監視して予兆を把握する、といったことが必要と考えられます。

  • 1: NIST SP800-161ではICTシステムの開発ライフサイクル;設計、開発、試験、運用、廃棄等の一連のライフサイクル)を特定した形でこの用語が使用されていいます。本コラムの第1回で解説したように、SDLCを構成するプロセスは、SLCP(System Life Cycle Process)として一般化されています。
脆弱性分析

脆弱性分析は、まず、重要度分析によって特定されたミッションクリティカルな機能およびシステム/コンポーネントに適用可能な脆弱性を特定することから始める必要があります。ICTサプライチェーンの脆弱性の発生には以下のようなものが考えられます。

  • ① 悪意のある関係者がシステムに関する情報を入手し、サプライチェーン内のアクセスパス(導入されるハードウェア、ソフトウエア、ファームウェア等)を通じて、最終的にはシステムの障害を引き起こす可能性のあるコンポーネントを導入する可能性。
  • ② 悪意のある行為者がシステム操作中にコンポーネントの誤動作や障害を引き起こす可能性のあるアクセスパスの存在。
  • ③ 重要なシステムに対する運用管理支援システムが悪意のある攻撃を容易に受けられる可能性が存在する。

また、組織階層に対応して脆弱性が発生する例と対応する対策例を表10に示します。

表10. 組織階層に対応して脆弱性が発生する例と対応する対策(SP800-161 Table 2-6より)
Tier 脆弱性の例 対策の例
Tier1 1) ICT SCRMの欠如といった、組織ガバナンスおよびプロセスの欠点、弱点 1) 外部組織に依存することにより生ずる脆弱性を検討するためのガイダンスを用意する。
2) 組織内での開発を含む代替技術の提供先を追求する。
Tier2 1) 欠陥を検出するためのプロセスの欠如
2) SDLCに取り入れられる交換用ICTコンポーネントの受け入れ試験、技術スクリーニングの実施に予算が割り当てられていない。
3) 革新的なテクノロジーの供給元が問題を起こすことに対する感受性(たとえば、サードパーティが所有または管理するテクノロジーはバグが多い)。
1) 偽造品を検出するためのプログラムを開発し、必要なリソースとトレーニング実施するための適切な予算を割り当てる。
2) 受け入れ試験, SDLCに入るコンポーネントの技術的なスクリーニングに必要な予算を割り当てる。
Tier3 1) システム機能の不一致が要件を満たしていないため、パフォーマンスに大きな影響が出る 1) エンジニアリングの変更を開始する。悪影響を及ぼす変更は、組織のシステムのシステムライフサイクル全般を通して発生しパフォーマンス低下に対する試験の修正を必要とする。

Task 2-2 特定された脆弱性が脅威によって侵害された場合に、組織の運営、資産、人および他の組織、国家に発生するリスクを特定する

リスクの想定は、その発生の可能性と発生した場合の影響により特定されます。

リスク発生の可能性

リスクの発生の可能性は、脅威の発生可能性(攻撃者の意図、特性等)と脅威の対象となる脆弱性によって評価されます。ICTサプライチェーンに対するリスク発生の可能性の推定には以下のような視点が必要になります。

  • ① ICTサプライチェーン自体が危険にさらされている可能性。これは、供給されるICTシステムやコンポーネントの不良率が高くなる、あるいは機密情報や知的財産等の漏洩などが想定されます。
  • ② ICTサプライチェーンに対する外部からの攻撃の可能性。これは、供給されるコンポーネント(ハード、ソフト、ファーム等)へのマルウェアの混入、あるいは自然災害や地政学的問題の発生によるものが想定されます。

リスク発生の可能性を推定するには、以下を考慮する必要があります。

  • ① 個々のシステムまたはコンポーネントが受ける脅威のタイプ(サイバー攻撃、内部犯行、物理セキュリティ侵害、自然災害等)の仮定。
  • ② 敵対者の能力、ツール、意図、目標などの実際のサプライチェーンの脅威情報。
  • ③ サプライチェーンの外部への露出度。
  • ④ システム、プロセス、コンポーネントの脆弱性とこれらが突かれてリスクが発生する可能性を分析可能な経験データ。

このように、リスク発生の可能性は脅威と脆弱性の両面から推定することになります。

リスク発生時の影響

リスク発生の影響評価にあたっては、Frameプロセスで評価した影響度を基準に、まず評価対象のミッション/ビジネスおよび情報システムの影響度を見直します。その後、侵害の発生を推定しこれが発生した時の対策の状況を評価することになります。評価にあたっては、i) 攻撃、侵害の特性(意図、強度、継続性等)、ii) 脆弱性の特定、iii) リスク対策の状況とリスク発生の影響の受けやすさ、を考慮した検討が必要です。影響評価は、組織環境やシステムの変化に対応し、リスク事象の発生時、リスク対策を変更する場合、システム開発ライフサイクルのフェーズの移行のタイミング、などで継続的に実施される必要があります。

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

NIST SP 800-161[1]ではAssessプロセスのアウトプットは各組織階層毎にその階層で受け持つ役割に応じて、ICTリスク評価報告書の形式2で用意されることを推奨しています。組織レベルでは、組織横断的なガバナンスリスクの視点が求められます。ミッション/ビジネスレベルでは、それぞれのミッション/ビジネスに対応したものが、また情報システムレベルではやはりそれぞれの情報システムに対応した評価結果が求められます。これらは、相互に参照性と整合性をもつことが求められます。また、このアウトプットは組織のリスク管理プロセスに統合される必要があります。

  • 2: NIST SP 800-30 Rev.1 Annex E[3]にそのひな型が提示されています。

4.5 Respond(対応)

Respond(対応)プロセスは、リスク評価とその結果に対応して考えられる管理策の代替案を意思決定者に伝達し、これによって適切な対応を決定することになります。またこの決定結果は、リスクベースの対応として適切に伝達される必要があります。決定として、場合によってはリスクに対して継続的監視と分析を行うことも考えられます。表11にはRespondプロセスにおける組織階層に対応した入力、アクティビティ、出力の概要を示します。この表の矢印は、階層間および他のプロセスとの連携を示しています。

表11. Respondプロセスのアクティビティ(SP800-161 Fig. 2-7より)

Respondプロセスのアクティビティに対しては、以下の4つのTaskが規定されています。

Task 3-1 リスク評価(Assess)で特定されたリスクに対応するための対策(管理策)の代替案を特定する

Responseプロセスでは、各階層においてAssessプロセスで特定されたリスクが入力されます。このTaskは、ICTサプライチェーンのリスク評価の中で対応が必要と考えられるリスクに対して、対応策の代替を提示することです。これらは、既存のITリスク管理策の一部として検討される必要があります。また、実行にあたり許容可能なリスクの洗い出しから開始されるのが一般的と考えられます。

Task 3-2 リスク対応の代替案の評価

Task 3-1で特定されたICTサプアイチェーンのリスクに対する代替案を分析・評価するプロセスです。具体的な代替案の基準はNIST SP800-53 Rev.4[2]を拡張した形で、NIST SP 800-161の第3章にまとめられています。組織は、脅威、リスク、サプライチェーンの優先順位の全体的な理解に基づいてICT SCRM管理策の代替案の評価と決定を行う必要があります。

ICT SCRMの管理策が、組織・ミッションレベルでのコスト,スケジュール,パフォーマンス,ポリシー,コンプライアンスなどのより広範な組織的要件とのバランスを適切に保つため、適用可能な要件と制約が利害関係者間でレビュー、共有されることが必要になります。
この評価は、ミッションレベルでの変更(新しいミッションの追加、新規情報システムの導入、エンタープライズアーキテクチャの変更等)をトリガーとして動的に実施されることで、費用対効果の高いICT SCRM管理策のセットをもたらすことが期待されます。

ICT SCRM管理策の費用対効果は、組織階層とシステム開発ライフサイクルプロセス中のどこに適用されるかによって異なります。例えば、購入プロセスでの不明朗なサプライチェーンの決定により、重要なコンポーネントに対するリスクの増大や設計段階での信頼性の確保(入力検証、サンドボックス、改ざん防止設計など)に影響をもたらします。従って、管理策の実行に責任のある担当者を特定し、システム開発ライフサイクル全体を通じて管理策を実施するための時間およびタイミングの段階的計画を策定する必要があります。このため、管理策が全体的なリスクにどのように影響するかを理解しておくことも重要です。

Task 3-3 リスク対応方針の決定

リスク対応の意思決定は、組織のリスク管理者が行うこともあれば、リスク管理者が組織内の他の者に委任することもあります。 つまり、意思決定はTier2またはTier3に委任できますが、決定が行われる階層は、その決定による影響の重要性と範囲によって決まります。リスク対応の決定は、必要に応じて、組織のリスク管理者、ミッション所有者、システム所有者との対話と協力により行う必要があります。また、サプライチェーンに係るサービスインテグレータ、サプライア、外部サービスプロバイダとの対話と協力も必要です。これにより、「目的に合致した」情報システムの状態を規定し、サプライチェーンの許容水準を定めることが可能になります。

意思決定の結果は、最終的にICT SCRM計画として文書化しておくことが求められます。これにより、ICTサプライチェーンの監視(Monitor)の成果を踏まえ、ICT SCRM計画の見直し、改定が可能となります。ICT SCRM計画は各組織階層で、それぞれの責任範囲に対応して策定されますが、各階層で策定されたICT SCRM計画は相互に参照され、全体で整合性をたもったものであることが必要です。
ICT SCRM計画には以下のような内容が盛り込まれます。

  • ① 組織に実装されている組織要件、ミッション要件に基づく適用可能なポリシー、プロセス、手順など、Frameプロセスで決定された環境を要約する。
  • ② 最高リスク責任者、最高財務責任者、最高情報責任者、プログラム責任者、システム責任者などの計画責任者および計画の関係者を明記する。
  • ③ 代替案の比較、分析で挙げられた管理策の案を明記し、最終的な管理策の決定根拠を示す。
  • ④ ICTサプライチェーンの階層間での相互依存の関係を保つためのフィードバックプロセスを示す。
  • ⑤ ICT SCRM計画の実施に対する監視(Monitor)の方法と実施形態を示す。
  • ⑥ 計画のレビューと改定の頻度を定義する。これには、システム開発ライフサイクルのマイルストーン、ゲートレビュー、重要な契約アクティビティなど、改訂のきっかけとなる基準を含めておく。
  • ⑦ 契約に含まれている場合は、システムインテグレータ、サプライア、外部サービスプロバイダのICT SCRM計画を含める。

表12に各組織階層でまとめられる管理策の指針とその具体例を示します。

表12. 階層毎の管理策の指針と具体例3(SP800-161 Table 2-7より)
Tier 管理策の指針 具体例
Tier1
  • Tier2,3に対する共通の基準となる管理策の提供
  • 全てのICTサプライアに適用される管理策最小セット
  • サプライア情報の処理、蓄積に適用される組織レベルの管理策
  • 組織レベルの調達スタッフに対する訓練と意識向上
Tier2
  • Tier1からの共通管理策の継承
  • Tier3に対するミッション機能レベルの共通管理策基準の提供
  • Tier1に対する、活動状況および変更要求のフィードバック
  • 特定のミッションに対するサプライアに適用される最低限の管理策
  • ICT SCRMに対する懸念対処するための実行計画レベルのアイデンティティ管理とアクセス制御に対する管理策
  • 実行計画に特化したICTサプライチェーンの訓練と意識向上
Tier3
  • Tier1,2からの共通管理策の継承
  • Tier3のシステムに特化した管理策の提供
  • Tier1,2に対する、活動状況および変更要求のフィードバック
  • 個々のシステムのハード、ソフトに適用される最低限の管理策
  • テストや統合開発環境などのICTサプライチェーンをサポートするシステムの変更管理に対する、適切で厳格な受け入れ基準
  • システムの特化したICTサプライチェーンの訓練と意識向上
  • SDLCとの連携
  • 3: NIST SP800-161 Annex E[1]にはICT SCRM計画のテンプレートがISO/IEC/IEEE 15288[4]のシステムライフサイクルプロセスに基づいて紹介されています。

Task 3-4 リスク対応方針の実行

組織は、ICT SCRM管理策を組織全体のリスク管理プロセスに統合することによりICT SCRM計画を実施する必要があります。

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

以上のTaskのアウトプットをまとめると、以下の3点になります。

  • ① 特定されたリスクに対処するICT SCRM管理策の選択、評価、調整
  • ② 識別されたICT SCRM管理策を適用するかどうかも含めた決定
  • ③ ICT SCRM計画の策定と実施

4.6 Monitor(監視)

リスク管理におけるMonitor(監視)は、組織におけるプロジェクトとその実行計画が実行中あるいは変更される段階で許容可能なリスクレベルを維持するための手順が守られているか、定期的に評価を行うプロセスです。組織、ミッション/ビジネス、情報システムおよびICTサプライチェーンに対する変更はリスク管理に影響を与えることから、これらの変更が管理され適切にリスク評価、対応が行われているかを確実にするためのメカニズムを与えるものになります。ICT SCRMに関しては、ICTサプライチェーンの変更が行われた場合、これに関係するシステムインテグレータ、サプライア、外部サービスプロバイダとの対話が適切に行われているかどうかを監視することも必要になります。表13には、Monitorプロセスにおける組織階層に対応した入力、アクティビティ、出力を示します。

表13. Monitorプロセスのアクティビティ(SP800-161 Fig.2-8より)

Monitor(監視)プロセスのTaskに対しては、以下の2つが規定されています。

Task 4-1 監視活動の目的、種類、頻度を含む組織の監視戦略の策定

監視活動には組織のICT SCRMの実施で必要な考慮すべき事項を含んでおく必要があります。監視戦略には、組織のICT SCRM活動に関するデータ、情報の収集方法と必要なツール、収集された情報の保護、収集された情報に基づいてICT SCRM活動に対して行われる監視活動の報告フォーマットの定義などが含まれます。ICT SCRMのためには外部のオープンソース、サプライア、サービスインテグレータからの情報収集が必要な場合もあります。情報収集の対象には、以下のようなものが含まれます。

  • ① 組織の脆弱性管理とインシデント管理の状況
  • ② 他組織との情報共有の状況
  • ③ サプライア、サービスインテグレータ、外部サービスプロバイダとの契約の状況および情報共有の状況(各種マニュアルを含む)

Task 4-2 組織の情報システムや業務環境を継続的に監視し、コンプライアンスの検証、リスク対応策の有効性の確認、変化を特定する

コンプライアンスの検証は、組織のICT SCRM活動が可視化され、報告が行われている事の確認です。リスク対応策の有効性の確認は、リスク対応の結果として発生しているリスクが管理されリスク管理およびICT SCRMが有効に行われているかどうかの判断が含まれることになります。また、変化の特定はリスク管理の環境変化が特定され、これに対応した対応が取られているか(例えば、新しい管理策の追加等)を監視することです。ICTサプライチェーンのリスクの変化には、さまざまなトリガーが考えられます。基本的なものとしては、Frameプロセスで特定されている組織に対する制約条件(表8)の変化があげられます。また、ICTサプライチェーンインフラストラクチャの変化としては、主要サプライアの市場からの撤退、といったものが挙げられます。これは、単に特定部品の不足によるリスクの増大だけでなく、代替製品のリスク対応といった変化の波及が考えられます。従って、組織は何が変化の要因になり得るかを組織として決定しておくことが必要であり、これを監視により確認しておくことが必要になります。

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

組織は,監視プロセスのICTサプライチェーンに関する監視結果をICT SCRM計画に統合しておく必要があります。 この計画では、必要に応じて、Frame(枠組)、Assess(評価)、Response(対応)プロセスのへのフィードバックと必要な実装のための入力を提供することになります。

引用文献

  • [1] NIST, SP800 161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations, 2015.
  • [2] NIST, SP 800-53 Rev.4 Security and Privacy Controls for Federal Information Systems and Organizations.
  • [3] NIST, SP 800-30 Rev.1 Guide for Conducting Risk Assessments, 2012.
  • [4] ISO/IEC/IEEE, 15288, Systems and software engineering — System life cycle processes, 2015.

Writer Profile

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