サプライチェーンの情報セキュリティマネジメント 第1回 ~ ISOでの標準化の状況を中心に解説

1. はじめに

近年のビジネスあるいはサービス(公共サービス、非営利法人なども含みます)ではIT技術を始めとしてさまざまな製品、サービスあるいはコンポーネントを組み合わせて利便性の向上と製品、サービスの迅速な提供が図られています。これを支えるシステムの1つがサプライチェーン1です。サプライチェーンを構成するさまざまなパートナーの強み(機能、価格、デリバリー等)を生かし、自組織の主力ビジネスに経営資源を集中させることで市場における優位性を獲得していくことと言えます。また、サプライチェーン自体も急速に分業化、グローバル化が進み、新しいサプライチェーンが続々と生み出されています。一方で、サプライチェーンが拡大するに伴い、これに起因するさまざまなリスク、セキュリティ侵害が発生しているという現実があります。サプライチェーンに起因するリスク、セキュリティ侵害は、発見することが難しく、長期に渡る可能性が大きく、また発生した場合の影響も大きくなります。これは、1つのサプライチェーンに複数のサプライアが関与し、多段のサプライチェーンが形成されていることから、サプライチェーン全般に渡る情報セキュリティマネジメントに必要な情報共有、プロセスの可視化等が困難となり、調達側(アクアイア)のみが情報セキュリティマネジメントをいくら強化してもうまくいかないところにあります。このような状況に対応するため、サプライチェーンの情報セキュリティマネジメントをグローバルスタンダードとして標準化し、サプライチェーンを構成するアクアイア(調達側)、サプライア(供給側)がこれに準拠することで、情報セキュリティリスクを緩和する試みが行われています。

このコラムでは、現在注目されているサプライチェーンの情報セキュリティマネジメントについて標準化の動向を解説します。最初に取り上げる標準は、ISO/IEC27036 Part1[1], Part2[2], Part3[3], Part4[4]です。こちらは第1部としてまとめます。また、米国連邦政府および関連する重要インフラ関連組織向けに、より細かな方法論や規定を解説しているNIST SP800 161[5]についても概要を紹介します2。こちらは第2部でまとめたいと思います。

  • 1: サプライチェーンは製品やサービスを調達する側(以降調達側またはアクアイアと呼ぶ)とこれを供給する側(以降供給側またはサプライアと呼ぶ)で構成される。サプライアの上流には複数のサプライアが存在する可能性がある。またアクアイアはその下流にある顧客等から見るとサプライアと見做せる。
  • 2: 本コラムでは各標準の原本をベースにまとめていますが、筆者の誤解、誤用もあるかと思います。その責任は筆者にあります。問題等ありましたらぜひご連絡頂ければと思います。

サプライチェーンの情報セキュリティマネジメントに関する要求条件および管理策は、ISO/IEC 27001[6]付属書A第15項「供給者関係」およびISO/IEC27002[7]15項「供給者関係」で取り上げられています。ここでは、供給者(サプライア)3に対する情報アクセス管理やサービス提供にあたっての管理策が示されています。しかし、後でも触れますが、現代のサプライチェーンにはICT製品(ハードウエア、ソフトウエア)の供給、コンサルティング、業務委託、ビジネスプロセスアウトソーシングからクラウドサービスまで多様な形態が存在しており、情報セキュリティマネジメントを考える上でもそれぞれの形態に合わせた対応が必要になってきています。

また、サプライチェーンはアクアイアが利活用するさまざまなシステムのライフサイクル(設計、開発・調達、利用、保守・運用、廃棄)全般に渡って利用される多様なサプライアによって形成されています。システムライフサイクルに対する情報セキュリティマネジメントも、ISO/IEC27002,14項「システムの取得、開発および保守」でその一般論としての情報セキュリティ管理策が取り上げられています。しかし、サプライチェーンに対する情報セキュリティマネジメントの観点からは、十分と言えるものではありませんでした。

このような状況を背景に、サプライチェーンに着目したISO/IEC27036が開発されています。この標準の位置付けはISO/IEC27001, 27002で示されている供給者関係に関する情報セキュリティマネジメントへの要求事項と管理策を補強し、システムライフサイクルに対応した実践的な実装のためのガイドラインを示しています。ISO/IEC27036は図1に示すように4つのパートで構成されており、順次規格化が行われてきました。複数のパートで構成されている意味は、サプライチェーンの情報セキュリティ管理策の一般論に加え、その類型に対応した個別の管理策を明確化するものと言えます。また、管理策は、いわゆるシステムライフサイクルプロセス(System Life Cycle Process :以下、SLCP)に対応したフレームワークとして整理されています。先にも述べたように、サプライチェーンの情報セキュリティマネジメントは、個々の組織における情報セキュリティマネジメントの強化だけではうまくいきません。サプライチェーンを構成する各組織が、連携して対応する必要があり、その意味で情報セキュリティマネジメントの必要性や必要な管理策を共有し相互に可視化することが重要となります。ISO/IEC 27036ではアクアイアとサプライアが情報セキュリティマネジメントの基本的なプロセスを実装するとともに、対等な関係で平等な責任を行うことを求めており、両者が実装すべきプロセスと責任の指針を示していると言えます。

このコラムでは、まずISO/IEC 27036を読み解くために必要なリスクマネジメントの指針、およびSLCPに関して、その基本コンセプトをISO/IEC標準に準拠して予備知識という形で簡単に解説します。引き続き、サプライチェーンの情報セキュリティマネジメントを中心に解説しますが、サプライチェーンリスク自体には、さまざまな側面があります。そこで、一般的に言われているサプライチェーンリスクに関しても、ISO/IEC27000シリーズに基づいて簡単に紹介します。その後、ISO/IEC 27036の構成に従いつつサプライチェーンの類型とそのリスク、リスクに対応する管理策などを解説することとします。

  • 3: サプライチェーンは製品やサービスを調達する側(以降調達側またはアクアイアと呼ぶ)とこれを供給する側(以降供給側またはサプライアと呼ぶ)で構成される。サプライアの上流には複数のサプライアが存在する可能性がある。またアクアイアはその下流にある顧客等から見るとサプライアと見做せる。

図1. ISO/IEC 27036の構成

図1. ISO/IEC 27036の構成

2. リスクマネジメントとシステムライフサイクルプロセス

2.1 情報セキュリティリスクマネジメントプロセス

セキュリティマネジメントとは、セキュリティリスクを特定し、これに対処することです。従って、サプライチェーンの情報セキュリティマネジメントを考える上では、まずそのリスクに対する分析が必要となります。

情報セキュリティリスクマネジメントに関する国際標準としては、ISO/IEC 27005[8]4があります。この標準の目的は、組織に求められる情報セキュリティ要件を特定し、ISMS(Information Security Management System)を確立する上で必要な体系的アプローチを与えることです。組織には、さまざまな情報セキュリティリスクが存在し、かつ環境の変化に応じてリスクも変化します。また、あらゆるリスク全てを予測し、これに対応することは現実的ではありません。従って、ISMS確立にあたっては、それぞれの組織が有する情報資産の重要性5とこれに対する脅威と脆弱性を評価し、リスク対応の優先度に合わせたセキュリティ管理策を採用することになります。

組織がリスクマネジメントを体系化する目的は、自組織のISMSを確立するだけではありません。サプライチェーンの情報セキュリティマネジメントを確立するためには、サプライチェーンを構成する複数の組織が情報セキュリティに関して適切なコミュニケーションを取り、適切なリスク対応をする、またこれを相互に確認する必要があります。例えば、アクアイアの重要度の高いシステムに対応してサプライアが適切な情報セキュリティマネジメントを行う必要がありますが、サプライアがこれに適切に対処しているかどうかアクアイアとコミュニケーションをとる場合、リスクマネジメントの体系を相互に理解し必要な対応を相互に確認する上で、共通のリスクマネジメント体系をとっておけばこれを有効かつ効率的に行うことが可能になってきます。つまり、サプライチェーンを構成する複数の組織が共通のリスクマネジメント体系をとることで、サプライチェーンにおける情報セキュリティリスクの共有を円滑化できると言えます。

  • 4: 組織におけるリスクマネジメント自体は大変幅広い概念です。より一般的なリスクマネジメントの指針はISO/IEC 31000(2018) [12]でまとめられており。JIS Q 31000(2019)としても発行されています。
  • 5: 情報資産の重要性は、簡単に言えばその資産が失われた場合(セキュリティ侵害が発生した場合)の事業継続性への影響度を意味します。

図2. リスクマネジメントプロセス[8]

*1 Risk Assessment6, *2 Risk Evaluation

図2. リスクマネジメントプロセス[8]

図2に[8]で体系化されている一般的なリスクマネジメントのフローを示します。この図に示すように、リスクマネジメントプロセスは、組織状況の特定、リスク分析、リスク対応と受容からなる反復プロセスとこのプロセスを通じた組織内・外との連携およびプロセス自体のモニタリングとレビューから構成されます。

  1. 組織状況の特定:組織のISMSの現状の棚卸、具体的にはISMSの対象範囲(場所、組織等)、情報資産(情報、情報システム、プロセス等)、情報資産の重要度、ISMSの組織体制と考慮事項(法的制約、BCP、インシデント対応等)、セキュリティ管理策、リスク管理の体制、リスク評価基準およびリスク受容基準、を行います。
  2. リスク評価:リスク評価プロセスはリスクの特定、分析、評価のステップで構成されます。
    リスクの特定には、まず①対象となる資産とその所有者を特定し、資産とこれが関与するビジネスプロセスをリスト化する([8]付録B)、②過去あるいは外部からの情報に基づくインシデント事例、資産所有者、ユーザーからの情報に基づいて想定される脅威とその発生要因のリスト化([8]付録C)、③既存のセキュリティ管理策を特定し、その計画、実装および実施状況をリスト化する、④脅威、資産、および既存のセキュリティ管理策に基づいて脆弱性をリスト化する([8]付録D)、⑤以上の結果に基づいて想定されるインシデントシナリオをリスト化する、といった手順を取る必要があります。
    リスク分析は、リスクの特定に基づいて得られたインシデントシナリオに対して定性的あるいは定量的な分析を行い、これが発生する可能性およびインパクトを特定することです。リスク分析にはさまざまな手法があり([8]付録E)、対象となる組織の特性に合わせて選択されることになります。代表的な定性的な分析の方法としては、資産に対する機密性、完全性、可用性の観点で重要度をレベル分けするとともに、インシデントシナリオに基づいてその損失可能性を評価するものです。例えば、NISTによるFIPS199[9]でも同様の考え方に基づいて米国連邦政府の情報および情報システムに対するセキュリティ分類規格が規定されています。ここで注意すべきは、いくつかの資産に対するリスクが低いとしても、これらが関連して発生する可能性がある場合には、リスクが高まるということです。いずれにしても、リスク分析では一定のリスク評価基準に基づいてリスクがリスト化されます7
    リスク評価ではリスク評価基準に基づいてリスト化されたリスク分析が満足のいくものであるかどうか、またリスクに対応する優先順位をどうするか、が評価されます。リスク分析が不十分と判断された場合はリスク特定、分析のプロセスを再度検討する必要があります。また、リスク評価にはリクス許容度を決めおくことが求められます。
  3. リスク対応と受容は図3に示す活動に従って実行されます。リスク対応では、リスク評価の結果として明確化された新たなリスクにどう対応するか、が検討されます。リスク対応には、①代替:新たなセキュリティ管理策8を適用してリスクを軽減する、②保有:リスク対応を行わない、③排除:リスクとなる資産の保有を行わない、④移転:リスクを第3者に転嫁する、という4つの対応方針から選択が行われます。これらの対応方針は互いに排他的なものではなく、いくつかの組み合わせで対応を行うことが可能です。リスクは、先にも述べたように完全に予測されて排除できるものではありません。また、必要となる対策のための費用、時間、技術、オペレーションといった観点での制約も存在します。これらの対応方針はこの制約条件を考慮して選択されます。従って、どうしても残存リスクが発生することになります。そこで、残存リスクが許容範囲にあるかどうかが判断され、許容可能であれば、残存リスクを受け入れるリスクの受容が行われます。この場合、次の評価プロセスの実施のために、判断根拠等を明確に残しておく必要があります。

    図3. リスク対応と受容

    図3. リスク対応と受容

  4. コミュニケーションおよび協議:リスク管理プロセスで評価されたリスク情報を、組織の意思決定者とステークホルダとの間で交換、共有される必要があります。このステークホルダの中には、サプライチェーンに係るアクアイア、サプライアも含まれます。
  5. モニタリングおよびレビュー:リスク管理プロセスで評価されたリスク情報に基づいて、組織で特定されているリスク要因の変化(資産の変更、環境変化、脅威、脆弱性、発生の可能性等)をモニタリングし定期的なレビューを実施して見直しを行います。モニタリングの中にはインシデントの発生とそれへの対応状況も含まれます。また、レビューの中にはいわゆる監査活動も含まれます。インシデントへの対応結果や監査活動の結果に基づいて新たなリスク管理プロセスを実行することになります。

以上、情報セキュリティリスクマネジメントプロセスの概要を示しました。この考え方は、極めて一般的なものであり、その詳細については別の機会に紹介したいと考えていますが、サプライチェーンに対する情報セキュリティリスクマネジメントもこの考え方を使って、組織におけるサプライチェーンリスクが考えられる状況、資産の特定、リスク評価と対応等を実行する必要があります。また、このプロセスをサプライア、アクアイア双方で共有し円滑なリスクコミュニケーションと必要な管理策の選択などに生かすことが可能になります。

  • 6: Assessmentは評価方法を、またEvaluationは評価した結果を意味しています。
  • 7: リスクレジスタ―(Risk register)と呼ばれています。
  • 8: 具体的な管理策の選択には例えばISO/IEC27002[7]がベースラインとなる。

2.2 システムライフサイクルプロセス(System Life Cycle Processes)

サプライチェーンの情報セキュリティマネジメントを検討する場合、システムライフサイクルに対応したサプライチェーンのセキュリティマネジメントを考慮することが重要となります。ITシステムに対するシステムライフサイクルモデルのステージの例を図4に示します。各ステージの実行にあたっては、コンサルティング、製品(ハードウェア、ソフトウェア)、業務委託、ビジネスプロセスアウトソーシング、クラウドサービスといったさまざまなサプライチェーンを利用することになります。

図4. ITシステムのシステムライフサイクルモデルの例

図4. ITシステムのシステムライフサイクルモデルの例

一方で、システムのライフサイクルモデルは、対象とするシステムによってさまざまな形態があります。システム自体も他のシステムの一部を形成するものや、連携して利活用されるものがあります。また、システム自体もITシステムに限ったものではありません。従って、ライフサイクルモデルはシステムの特性に合わせたさまざまな形態を考えることができます9。そこで、このさまざまなライフサイクルモデルをさらに一般化し、各ライフサイクルのステージ毎に共通に利用されるプロセスを抽出整理したものが、ISO/IEC/IEEE 15288[10]10で“システムライフサイクルプロセス”として整理されています。システムライフサイクルプロセスの詳細は、また別の機会に解説したいと思いますが、具体的には、図5に示すように4つのプロセス群で構成されています(図の項番は[10]の項番に対応)。

図5. システムライフサイクルプロセスの一覧

図5. システムライフサイクルプロセスの一覧

  1. 契約プロセス群(Agreement Processes):1つの組織(調達側:アクアイア)は、別の組織(供給側:サプライア)にシステムライフサイクルを実行するための製品またはサービスを依頼することができます。 これは、両者の役割、責任等に関する関係は契約プロセスより達成されます。このプロセスは調達と供給に関するプロセスで構成されます。
  2. プロジェクト遂行支援プロセス群(Organizational Project-Enabling Processes):プロジェクトが組織の関係者のニーズと期待に応えられるようにするために必要なリソースを提供するプロセス群です。通常、戦略的なレベルで組織のビジネスまたは事業の管理と改善、人材を含むリソースと資産の提供と展開、および競争または不確実な状況におけるリスク管理に関係したプロセスで構成されます。
  3. 技術管理プロセス群(Technical Management Processes):プロジェクトの技術的取り組み、特にコスト、タイムスケール、および達成の観点からのプロジェクト計画管理、計画とパフォーマンスの基準に確実に準拠するためのアクションのチェック、および修正の特定と選択に関連したプロセスで構成されます。
  4. 技術プロセス群(Technical Processes):利害関係者のニーズをその具体的な要件に対応した製品とサービスに変換するプロセス。顧客満足度を達成するために、必要なときに必要な場所で持続可能なパフォーマンスを提供します。このプロセスはライフサイクルのあらゆるステージに適用されます。
  • 9: システム及びそのシステムライフサイクルモデルをどう捉えるかに関する一般論はISO/IEC/IEEE 14748-1[11]で解説されています。
  • 10: ソフトウェアのライフサイクルプロセスとして[10]を基本としてまとめられたISO/IEC/IEEE 12207[13]がある。

引用文献

  • [1] ISO/IEC, 27036 Information technology — Security techniques — Information security for supplier relationships Part 1: Overview and concepts, 2014.
  • [2] ISO/IEC, 27036, Information technology — Security techniques — Information security for supplier relationships Part 2: Requirements, 2014.
  • [3] ISO/IEC, 27036, Information technology — Security techniques — Information security for supplier relationships Part 3: Guidelines for information and communication, 2013.
  • [4] ISO/IEC, 27036, Information technology — Security techniques — Information security for supplier relationships; Part4-Guidelines for security of cloud services, 2016.
  • [5] NIST, SP800 161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations, 2015.
  • [6] ISO/IEC, 27001, Information technology — Security techniques — Information security management systems —, 2013.
  • [7] ISO/IEC, 27002 Code of practice for information security controls, 2013.
  • [8] ISO/IEC, 27005 Information technology — Security techniques — Information security risk management, 2018.
  • [9] NIST, FIPS199, Standards for Security Categorization of Federal Information and Information Systems, 2004.2.
  • [10] ISO/IEC/IEEE, 15288, Systems and software engineering — System life cycle processes, 2015.
  • [11] ISO/IEC/IEEE, 14748-1, Systems and software engineering - Life cycle management - Part 1: Guide for life cycle management, 2018.
  • [12] ISO/IEC, 31000, Risk management — Guidelines,, 2018.
  • [13] ISO/IEC/IEEE, 12207, Systems and software engineering — Software life cycle processes, 2017.
  • [14] ISO/IEC, 15408, Information technology - Security technigues - Evaluation criteria for IT security, Part1,2,3, 2008, 2009.

Writer Profile

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