JNSA「セキュリティしんだん」
«(33)インターネット利用者の7割が知らない、自分の身に起こること |
(34)サプライチェーンの情報セキュリティマネジメントの関連規格と現状(2022年11月18日)
1. はじめに
最近よく話題になっている「サプライチェーンの情報セキュリティマネジメント」に関して、国際規格等を参考にその背景、考え方、課題について、ご紹介したいと思います。
この用語は次のような概念を含んでいると考えられます。
@一般的なサプライチェーンで利用される情報及び情報システムに対するセキュリティマネジメント
AICT製品、サービスのサプライチェーンに対するセキュリティマネジメント
@は一般的なサプライチェーンに関する概念である一方、AはICT(情報通信技術)製品、サービスの特性に対応したセキュリティマネジメントです。情報セキュリティマネジメントはリスク管理の1つですが、これは何に対するどのような脅威に対応するか?つまりリスクの中身(コンテキスト)で、考えるべきポイントが変わってきます。もちろん、@で利用される情報システムもAの一種と考えられることから両者は相互に関連しているとも言えます。
このあたりの関係を最新のISO/IEC 27002; 2022版[1]で見てみましょう。この規格で、@の一般的なサプライチェーンに関する管理策を述べているのが、”5.19 供給者関係における情報セキュリティ”, “5.20 供給者との合意における情報セキュリティの取り扱い”、 “5.22 供給者のサービス提供の監視、レビュー及び変更管理“になります。これに対して、”5.21 ICTサプライチェーンにおける情報セキュリティ管理”, “5.23 クラウドサービスの利用における情報セキュリティ“が特にAの観点での管理策になります。2013年版と比べると、5.19のリスクマネジメントの観点の強化、5.21のICTサプライチェーンの対象に、クラウドサービス、IoT、ホスティングサービスなどが加えられている、5.23のICTサービスの1つであるクラウドサービスの情報セキュリティマネジメントが追加されている、などの変更が加えられています。実際、ISO/IEC 27002 2013年版以降、ISOではサプライチェーンに関する規格としてISO/IEC 27036 Part1~Part4[2]、やクラウドサービスに関連したISO/IEC 27017, 207018などの追加が行われており、新しいISO/IEC 27002のサプライチェーンに関する管理策もこれらとの整合性が取られています。
2. サプライチェーンの情報セキュリティマネジメント[3]
(1)一般的なサプライチェーンとは
一般的に、サプライチェーンとは「製品やサービス提供のための原材料等の調達、製造・生産、流通、販売から消費までの一連の経済活動を構成する組織間の調達と供給の相互関係を構成しているプロセスとそこで扱われるリソース」と言う事ができます。我々の社会活動では、あらゆるところでサプライチェーンが構成され経済活動を支えています。サプライチェーンの基本的な構成要素は、供給側と調達側の2者間ですが、複数の組織が多段に重なってサプライチェーンが構成されているのが一般的です。チェーンと言う言葉は供給と調達の1つの輪が重なり合って構成されているイメージを表していますが、1つの輪の調達・供給の関係はそれに繋がる前後の輪では新たな調達と供給の輪が繋がることで、調達・供給関係の立場が変わってくることも意味しています。
(2)サプライチェーンの情報セキュリティマネジメント
サプライチェーンで扱われる製品やサービスは多様です。特に、近年産業のグローバル化が進みサプライチェーンもグローバル化してきています。また、製品やサービスの機能の高度化、革新が進むことで、飛躍的に複雑度や多様性が増大しています。例えば、自動車産業では1台の車は3万点以上の部材から構成されていると言われています。このために大規模でグローバルなサプライチェーンが形成されています。また、EVの採用、自動運転技術(ADAS/AD[4]) といった様々な技術革新により新たなサプライチェーンが生み出されています。同様の傾向は他の産業特にIT製品を始めとする先端技術分野で顕著です。
このようなサプライチェーンを円滑に構成、運用するためにはサプライチェーンに参加する組織間での適切な情報の共有が必要になります。共有が必要となる情報は産業によって個別に様々なものがあります。例えば製品の設計情報や生産規模、或いは取引先の与信、経営状況といったいわゆる営業機密に該当するものも必要になります。また、個人情報の共有も必要になる場合があります。これらの情報が棄損或いは第3者に漏洩することで、サプライチェーンに参加する組織に損害が発生し、社会的な問題を起こす可能性があります。より一般的に言えば、健全なサプライチェーンを構成、維持するためにはサプライチェーンに係る情報とそれを扱う情報システムの完全性、安全性、品質、レジリエンス[5]などが求められますが、これを達成することが「サプライチェーンの情報セキュリティマネジメント」になります。
(3)第一ポイント:円滑なサプライチェーン構築のための情報共有
サプライチェーンの情報セキュリティマネジメントの第1のポイントは、どのような情報をサプライチェーンの参加者の間で保護すべきかを明確化することです。円滑なサプライチェーン構築のための情報共有は必須ですが、一方で調達側、供給側共に独自の営業秘密を持っており、これらがサプライチェーンを通じて不必要に開示されることは防がなければなりません。あくまでNeed to Knowを相互に了解して共有情報を決定しておく必要があります。例えば、クレジットカードの利用に関しては、カード利用者、発行者(イシュア)、ペイメントブランド、カード加盟店など多数の参加者で構成された決済に関するサプライチェーンと考えることができます。ここで保護すべき最も重要な情報はカード情報になります。カード情報には利用者の氏名や与信・口座情報から始まり、カードID、パスワード、セキュリティコードなど様々なものが含まれますが、円滑で安全なサプライチェーンを形成するには組織間で必要最低限の情報を共有しつつ、これを第3者に対して保護する必要があるわけです。このセキュリティを保護する目的でPCI-DSS[6]が業界標準として作成されていますが、この標準では、一般的なISMSを基本に、カード情報の保護に関してサプライチェーンを構成する企業、組織がそれぞれの役割や規模に応じて準拠すべきセキュリティ管理策がまとめられています。
(4)第二ポイント:保護プロセスの共有
サプライチェーンを保護するには、参加する組織が個々に保護すべき情報を共有するだけでなく、これをどのようなプロセスで保護するかが共有される必要があります。このプロセスの共有により、サプライチェーンに参加する組織間での情報セキュリティ保護に対するコミュニケーションが円滑化され、信頼を向上させることが可能になります。これがサプライチェーンの情報セキュリティマネジメントのもう1つのポイントです。クレジットカードの場合で言えば、該当するプロセスの中には、カード情報の処理だけでなくこれを扱う情報システムのセキュリティ保護や、相互のセキュリティ保護の実情を開示、保証するための情報開示の範囲と監査プロセスが含まれます。PCI-DSSはこのプロセス共有のための業界標準と言って良いと思います。
サプライチェーンの情報セキュリティマネジメントのもう1つの例として、米国政府によって規定されたCUI (Controlled Unclassified Information)の管理が挙げられます。元々米国ではいわゆる機密指定の情報は全ての政府組織で共通に規定されていましたが、かなり限定されたものであり、各政府組織はその役割に応じた機微情報の管理を個別に行っていました。 これが、組織間或いは政府機関との協力関係にある非政府機関、企業との連携に必要な情報共有の妨げにもなっているとの認識に立ち政府機関共通に管理するCUIが規定されました。CUIの一連のカテゴリーは各政府機関からの申告に基づき米国国立公文管理局(NARA)に設けられたCUIレジストリに登録されます。また、具体的なCUIの定義、指定、解除、マーキング等の取り扱い規則は連邦行政規則集[7]で共通に規定されています。CUIは政府機関の製品、サービスの調達の際に調達側で指定され、NIST SP800 53のセキュリティ管理策の中程度レベルの管理策で保護することがNIST SP800 171で規定されています。
(5)第三ポイント:守るべき役割と責任の明確化
組織間でプロセスを共有するには、最終的に契約行為によってそれぞれの役割、責任が文書化され合意されておく必要があります。役割の中には個々の組織がどのようなプロセスで何を保護するかが含まれます。同じ組織内での情報セキュリティマネジメントは自己責任で行うことが可能ですが、サプライチェーンでは異なる組織間で守るべき役割と責任を明確化し、合意しておく必要があります。これが第3のポイントです。合意と文書化は供給側・調達側の2者間で、取引の内容に応じて締結されますが、この中に相互で遵守すべき情報セキュリティマネジメントの要件を明示しておくことになります。この契約行為は取引の内容や形態によって様々な形が考えられますが、もし情報セキュリティマネジメントに関してPCI-DSSのような業界標準が存在していれば、基本的なプロセスを契約の中に明確に含むことができます。また、先に述べた米国政府機関の調達に関しては、連邦政府調達規則[8]が整備されており、この中で情報セキュリティ対策、先に述べたCUIの扱いなどが政府機関共通の要件として指定されています。冒頭に述べたISO/IEC 27002のサプリチェーンに関する管理策も1つの一般的な基準を与えていると言えます。
(6)第四ポイント:環境やライフサイクルに合わせて更新、変更
ところで、現実のサプライチェーンはビジネス環境の変化に合わせてダイナミックに変化します。1つのサプライチェーンのプロセスもその製品やサービスの企画、調達、開発から運用、終了までのライフライクルを持っています。従って、守るべき情報とその管理プロセス、契約もビジネス環境やライフサイクルに合わせて更新、変更して行く必要があります。また、新たな脅威の発生への対応も適宜必要になってきます。先に述べた3つのポイントに従って、この守るべき情報、プロセス、契約の変更管理自体もサプライチェーンの情報セキュリティマネジメントの一環として確立しておく必要があります。これが第4のポイントです。例えば、グローバル化の進展によりその頻度が増しつつあると言われる、BEC詐欺[9]への対策に対応した見直しもその一例になるかと思います。
以上、サプライチェーンの情報セキュリティマネジメントの基本を概観しましたが、この考え方は同一グループ間の企業同士でも必要になります。我が国でも企業規模によらずグループ企業のグローバル化が進んでいますが、海外拠点のセキュリティ侵害が国内の組織に影響を与える例は後を絶たない状況のようです。海外での情報セキュリティに関する環境や法制度は我が国国内の状況とは大きく異なる場合があります。従って、このような違いを十分考慮した情報セキュリティマネジメントが必要になると考えられます。
3. ICTサプライチェーンの情報セキュリティマネジメント
(1)ソフトウェア利活用のライフサイクルに対応した情報セキュリティマネジメント
先に述べたISO/IEC 27002 2022年版では、ICT関連製品、サービスのサプライチェーン及びクラウドサービスに関するセキュリティマネジメントに関する管理策が5.21、5.23項で取り上げられています。現代のデジタル化の進展により、ICT製品、サービスの利活用は社会活動の中で重要な位置づけになってきていますが、それだけにその特性に合わせたサプライチェーンの情報セキュリティマネジメントが重要になってきていることを意味します。
ICTサプライチェーンが一般のサプライチェーンと最も異なる点はソフトウェアの存在です。ハードウェアもICTサプライチェーンの重要な管理対象ですが、そのほとんどはソフトウェアで制御されています。クラウドサービスも広い意味ではハードウェア資源と合わせてソフトウェアをサービスとして利用していることになります。ソフトウェアは、利用開始以降も機能追加、修正のために常に更新されます。利用開始から数年後には、ソースコード規模が数倍に膨れ上がることも普通です。また、現代のソフトウェアはオープンソースを始めとする様々なコンポーネントが組み合わされて開発、利用されています。さらに、システムレベルで見ると、OS、ミドルウェア、DB、アプリケーションといった様々なソフトウェアベースのコンポーネントが連携して動作するようになっています。このような状況から、ソフトウェアの利活用が進むにつれリスクファクタ―が増大し、情報セキュリティリスクはその増大の一途を辿ります。
ソフトウェア(ソフトウェアの更新も含む)の重大なセキュリティリスクは大きく分けると、@製品、コンポーネントレベルでの意図しない脆弱性、バグの混入、A製造段階での意図的なバックドアなどのマルウェアの混入、があります。前者は、脆弱性を突いたサイバー攻撃の対象にされます。後者はソフトウェア開発環境が侵害され、バックドア等が正規のソフトウェアに偽装されて配布される“ソフトウェアサプライチェーン攻撃”とも呼ばれる深刻なサイバー攻撃に利用されます。
ソフトウェアの取得プロセスから見ると、ⓐOEMを含む市販ソフトの購入、ⓑ自組織用にカスタマイズされたソフトウェアの開発、ⓒサービスとしてのクラウド利用、が考えられます。ⓑの場合は、開発にあたって多くの場合外部委託が利用されますが、この場合も委託業者との間でのサプライチェーンリスクマネジメントが必要になります。また、利活用時の維持管理プロセスで見ると、機能追加や脆弱性、バグ対応のソフトウェア更新が必要になります。特に脆弱性への対応は深刻なものであるほど早期の対応が求められます。さらに、利用の終了にあたっては、サポート終了の考慮、データの引継を含む次期システムとの互換性などを検討、実施するプロセスが必要です。このように、ソフトウェアの利活用のライフサイクルに対応した情報セキュリティマネジメントが求められます。
(2)ソフトウェアのインベントリ情報管理とSBOM
ソフトウェアサプライチェーンの情報セキュリティマネジメントは、調達側組織の活動で重要なビジネスプロセス、システムとそこで利用されているソフトウェアを特定することから始まります。この段階で必要最低限のソフトウェアを特定し、調達時にコンポーネントを含むその供給元、利用個所/ハードウェア、来歴、ライセンス情報、更新情報などを含めインベントリを作成することが求められます。利用するソフトウェアのコンポーネントを含む出所、真正性保証、ランセンス管理、サポート条件などが必要であり、サプライアとの合意に基づく情報共有が必要になります。また、利用フェーズにおいては正規の更新ファイルの適用や脆弱性への早期対応といったプロセスを共有しておく必要もあります。ここでもソフトウェアインベントリ情報が重要な役割を果たします。
ソフトウェアのインベントリ情報に関しては、サプライチェーンでの情報共有が必要であることから様々な標準化が試みられています。ISO/IEC 19970-2では流通するソフトウェアを一意に識別し必要な情報をXML形式で記述できるSWIDtag[10]の標準が策定されています。また、Linux Foundationではオープンソースソフトウェアの円滑な利活用のために、相互利用されているソフトウェア構成を記述するためのSPDX[11]仕様を公開しています。さらに最近米国では、2020年12月に発見された重大なソフトウェアサプライチェーン攻撃[12]を起点に2021年5月に大統領令EO14028[13]が発出され、この中で上記標準等に基づいて米国政府機関におけるソフトウェア調達に対するソフトウェア部品表:SBOM[14]の本格的な利用が検討されています。このようなインベントリ情報はその情報自体をMachine Readableにすることでソフトウェアのライセンス、脆弱性情報を含むソフトウェア管理の自動化を狙ったものとも言えます。しかし、このような標準化が進む一方で、残された課題は数多くあります。例えば、SWID含めその情報はあくまでソフトウェア開発サイドが生成するものですが、そもそもそのソフトウェアの信頼性をどのように保証するのか?は提供ベンダに委ねられており標準的な規格があるわけではありません。米国ではセキュアなソフトウェア開発標準[15]に従った開発の実施を自己宣言するラベリングプログラムなども検討が進められていますがまだ道半ばの感があります。さらに、そもそも信頼できるSBOM情報をどのように流通させるか?といった課題も残されていると思います。
(3)クラウドサービス提供側との協力、責任分担
ⓒのクラウドサービスの場合、サービスとして提供されるソフトウェア機能に対するセキュリティマネジメントはクラウドサービス提供側の責任になります。クラウドサービスにはIaaS, PaaS, SaaSといったサービス提供のレイアの異なるものが存在します。例えば、IaaSの場合、クラウドサービス提供側は基本的な計算機資源を提供します。これらのハードウェア資源は、クラウドサービス提供側で共通のリソースとして扱われますが、サービ提供時には提供対象の利用者に必要なリソースを割り当てるとともに、他の利用者から独立して運用される必要があります。このようなセキュリティに係るリソース管理は提供側の責務です。一方、その上で実行するアプリケーションは利用者側が用意することになります。この場合、アプリケーションのためのソフトウェアは調達側で管理する必要があります。また、サービスへのアクセス制御は、その機構としてはクラウドサービス側で提供されますが、利用にあたってのセキュリティマネジメントは、利用側が責任をもって実施する必要があります。このようにクラウドサービスの利用にあたっての情報セキュリティ管理は、供給側と調達側の協力と責任分担によって成立することになります[16]。クラウドサービスは、一般的に提供者が事前に用意した利用条件にあたって提供され、利用者毎のカスタマイズは原則として行われません。もちろん、サービス提供側も一定の情報セキュリティ管理の実施を明示しています。しかし、クラウドサービスの選定にあたっては、調達側でも自らの責任範囲を明確にし、クラウドサービス提供側との協力、責任分担がセキュリティリスクに対する要件を満たしているかどうかを判断する必要があります。また、実際のクラウド利用にあたっては、複数のクラウドサービスを組み合わせて利用する場合がほとんどです。例えば、SaaSサービスなどの利用にあたってはVPC(Virtual Private Cloud)を併用することが行われます。提供されるVPCにはVPN, ファイアウォール, IPS/IDSといった様々なセキュリティ機能が提供されていますが、これらを組み合わせてセキュアな環境を設計、運用するのは利用側の責任になります。従って、サービス調達側ではこの組み合わせに対するセキュリティ管理要件も考慮しておく必要があります。
まとめ
以上、サプライチェーンの情報セキュリティマネジメントに関して最近注目している点を中心にお話させて頂きました。もちろん、ここでは触れられなかった多くの視点があり、さまざまな規格、標準が出されつつあります。しかし、重要なのはサプライチェーンの情報セキュリティマネジメントは、供給側と調達側が平等な責任を負う事、そのために必要なプロセスを共有、実践することです。さらに言えば、サプライチェーンを取り巻く環境を理解するいわゆる”状況認識:Context Awareness“の共有が求められていると思っています。
- [1]
- 日本語との対訳含めて次から入手可能 日本規格協会;
https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=ISO%2FIEC+27002%3A2022 - [2]
- 概要は次の私のコラムで紹介しています。https://www.intellilink.co.jp/column/security/2020/100600.aspx
- [3]
- より広い概念としてサプライチェーンのセキュリティマネジメントがあります。例えば、サプライチェーンのセキュリティに関する国際標準としてISO/IEC 28000シリーズがありますが、これは主にサプライチェーンを形成するための物流に関するセキュリティを扱っています。
- [4]
- Advanced Driver Assistance System/ Autonomous Driving
- [5]
- 何らかの障害が発生してもサプライチェーンが維持される能力を意味します。
- [6]
- Payment Card Industry Data Security Standard; 詳しくは https://www.intellilink.co.jp/column/pcidss.aspx
- [7]
- 32 CFR 2002; https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2002
- [8]
- Federal Acquisition Regulation (FAR); https://www.acquisition.gov/
- [9]
- Business E-mail Compromise
- [10]
- SWID(Software Identification)tag
- [11]
- Software Package Data Exchange, ISO/IEC 5962として2021年に国際標準化
- [12]
- SolarWinds社のIT管理システムOrionに対する侵害
- [13]
- Executive Order on Nation’s Cybersecurity, 2021.5.21
- [14]
- Software Bill of Materials
- [15]
- NIST SP800 218 2021
- [16]
- ISO27002 5.23ではクラウドサービスを利用する側の管理策がまとめられています。クラウドサービスの選定にあたってのクラウドサービスプロバイダと利用側との責任分担とそのためのリスク分析についてはISO/IEC 27036-4, 2016及びその解説;
https://www.intellilink.co.jp/column/security/2020/111300.aspx を参照してください。
«(33)インターネット利用者の7割が知らない、自分の身に起こること |