はじめに
情報セキュリティのための管理策の中で組織的対策として分類されている「ICTサプライチェーンにおける情報セキュリティの管理」について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。
管理策の概要
先ずは管理策の本質を理解するために、ISMSに基づく管理策の指針として活用されることの多い ISO/IEC 27002:2022 にどのように記載されているかを確認してみます。
ISO/IEC 27002:2022 5.21 Managing information security in the ICT supply chain から引用
Purpose：
To maintain an agreed level of information security in supplier relationships
管理目的：
供給者との関係において、合意されたレベルの情報セキュリティを維持するため。
Control：
Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.
管理策：
ICT製品及びサービスのサプライチェーンに関連する情報セキュリティリスクを管理するために、プロセス及び手順を定め、実施することが望ましい。
※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正
前回、前々回の記事で供給者が関係するセキュリティマネジメントについて考察しました。
ICT製品及びサービスのサプライチェーン（以下、「ICTサプライチェーン」と呼びます）も同様に組織と供給者の関係により成り立ちますが、サプライチェーン上に様々な供給者が関与することで複雑な形態となり、その透明性の確保が容易ではないことがICTサプライチェーンの特徴であり、リスク要因となります。
また、以下のような理由により、他のサプライチェーンよりも潜在するセキュリティリスクは高くなる傾向があると言えます。
- 脅威アクターから見ると高いROIが期待できるためターゲットになりやすい
- 一度、脆弱性の存在が明らかになった場合に影響が及ぶ範囲が広い
本管理策では、上記のような背景を考慮し、供給者が関係する一般的なセキュリティリスクに加えて、ICTサプライチェーン特有のセキュリティリスクを特定することの必要性と、特定したリスクを適切に管理するための具体的なプロセスや手順を定めることが求められていると考えます。
具体的な実施例
ここからは、ICTサプライチェーン特有のセキュリティリスクとそのリスクを適切に管理するために考慮すべき点を考えてみますが、前述のように、どのリスクもサプライチェーン上に様々な供給者が関与することで複雑な形態となり、その透明性の確保が容易ではないことが主要因となっています。
１．取得したICT製品に関する構成情報の理解
供給者から取得した製品に対する正確なリスクアセスメント結果を得るためには、その製品を構成する各コンポーネントに内在するリスクも明らかにする必要があります。
具体的には、組織が取得したソフトウェアに対しリスクアセスメントを実施する場合、その構成情報を特定することで、各コンポーネントの機能、脆弱性の有無、セキュリティ対策の実施状況を理解することができ、正確な結果を得ることができます。さらに、コンポーネントに関連する脆弱性が既知となった場合にも、関連するソフトウェアを速やかに特定し対応するためには構成情報の管理は欠かせません。
ICT製品のリスクを適切に管理するためには、その供給者に対し使用されているコンポーネントの情報提供を要求するなどして、組織においてその構成情報の透明性を確保し、変更管理を行い、既知となった脆弱性情報との関連性を常に監視することが求められます。
実際に、2021年11月に起こったJavaのログ出力ライブラリとして多くのソフトウェアに利用されているOSSに脆弱性（CVE-2021-44228）が見つかった事象では、多くの組織においてソフトウェアコンポーネントに対する脆弱性管理が課題として認識されたと思います。
上記内容については、NTIA （National Telecommunications and Information Administration：米国商務省電気通信情報局）による、SBOM（Software Bill of Materials）の作成によるソフトウェアコンポーネントの透明性を高める取り組みとして、既に具体的な提言がされていますので、簡単に紹介します。
ソフトウェアが作成される過程では複雑なサプライチェーンが関与している可能性があり、その場合、プロプライエタリ、オープンソースを問わず、様々なコンポーネントにより構成されていることが少なくありません。組織は、取得した製品に関連する新たに既知となった脆弱性への対応責任を有し、さらに、供給者によるサポートが終了した場合の対応についても考慮しなければなりません。
例えば、下図のようなコンポーネントで構成されている Frank's Final Good という名称のソフトウェアを組織が使用している場合、SBOMにより透明性が確保されていれば CVE-2020-1234 として公表された脆弱性への対応が必要であることを速やかに理解することができます。
上記はSBOMが必要とされる理由の一つです。現在では、NTIAにおいてSBOMに含めるべき項目の最小要素が定義されていたり、様々な組織によりフォーマット（現時点では、SPDX、CycloneDX、SWIDタグが主なものとなっています）が定義されています。
このようにICTサプライチェーンに関連する製品を取得する場合、正確なリスクアセスメントを実施するためには取得した製品の構成情報を理解する必要があります。
２．取得したICT製品のセキュリティ機能とその設定に関する理解
取得した製品が備えているセキュリティ機能（例えば、暗号化、アクセス制御、認証方式など）を理解し、効果的に運用するために必要な設定をすることで有効に使用できますが、その設定の責任は取得者にあります。具体的には、供給者により提供されているサービスに追加要素による認証の機能が備わっているにも関わらず、利用者がその機能を無効にしている場合、そのリスクに対する責任はサービスの利用組織にあります。
例えば、2020年年末に起きたCRMソリューションを提供しているSaaS（クラウドサービスプロバイダ）を利用している複数の組織において発生した不正アクセス被害は、利用組織（クラウドサービスカスタマ）による権限設定の不備がインシデントの原因の一つとしてあげられています。
これも前項と同様にソフトウェアサプライチェーンの透明性の確保に関連する内容であり、ICTサプライチェーン特有のリスクと言えます。
上記に関連する、例えば、セキュリティ管理策の実施漏れのようなリスクに対応するためには、組織が供給者に対し情報提供を要求したり、供給者により公開されている情報から製品のセキュリティ機能を正しく理解し、責任共有モデルを明らかにする*1ことが有効と考えます。
３．取得したICT製品の完全性・真正性の確保
組織が取得するICT製品又はそのコンポーネントには悪意のある改ざんが加えられていたり、偽造品が含まれている可能性があり、それらを利用することで組織のセキュリティが損なわれるリスクがあります。
例えば、2019年に発生したPCサプライヤーが提供する自動更新ツールが改ざんされ、マルウェア配信に悪用された例などが関連する内容になります。
このリスクに対応するためには、供給者により提供されるコンポーネントの完全性及び真正性を確かめることが必要です。具体的には、改ざん防止シール、電子署名、メッセージダイジェスト（ハッシュ値）などの利用による検証が考えられます。
４．その他
その他にもセキュリティガイドラインなどでは、次のような点について考慮することが供給者が関係するセキュリティリスクに有効とされていますが、ICTサプライチェーン特有のものではなく、このブログの中でも過去の記事で取り上げている内容になるため、項目の紹介程度に留めます。
- ICT製品又はサービス取得時に適用する情報セキュリティ要件を定める
- 組織が利用するICTサービス又はICT製品がサプライチェーン構成により提供される場合、そのサプライチェーン全体に組織のセキュリティ要件を伝える
- 組織が利用するICTサービス又はICT製品がセキュリティ要件を満たしていることを検証するための方法及び監視プロセスを定める*2
- 組織が利用するICTサービス又はICT製品の機能を維持するために重要な役割を担うコンポーネントを特定し、その作成元情報などを追跡可能にする
- 組織が利用するICTサービス又はICT製品が期待通りに機能していること、及びセキュリティ要件を満たしていることを評価スキームにより確認する*3
- サプライチェーンに関連する潜在的な問題や妥協事項について、組織と供給者間で整合する
- 供給者によるICTコンポーネント利用停止を想定した代替供給者の選定及び移管プロセスを明らかにする
クラウドサービスの利用
下図構造によりサービスが提供されることを考えると、クラウドサービスも、ICTサプライチェーンの一つの形態であると考える事ができます。
組織がクラウドサービスを利用する場合、原則、サービスの供給者であるクラウドサービスプロバイダと責任共有モデルに基づき各管理策の実施義務を明らかにし、必要に応じ、合意又は、同意しますが、図のようにサプラチェーン状に連鎖してる場合は、その実施状況の透明性確保が難しくなります。このため、「供給者のサービス提供の監視、レビュー及び変更管理」に関し、特別な考慮が必要になります。
上記を含め、「クラウドサービス利用のための情報セキュリティ」に関する管理策については、後日、考察する予定です。
まとめ
本稿では、サプライチェーン上に様々な供給者が関与することで複雑な形態となり、その透明性の確保が容易ではないとの観点で、ICTサプライチェーン特有のリスクを数例あげて考察しました。ICTサプライチェーンに関連するリスクは複雑で多岐にわたるため、他にも数多く潜在していると思われますが、基本的にはこの考え方が有効だと思います。
さらに、本管理策では特定したリスクを適切に管理するための具体的なプロセスや手順を定めることの重要性についても述べられているため、組織において明らかにしておく必要があると思います。
また、記事の中でも数例紹介していますが、近年、ICTサプライチェーンが関連するインシデントが数多く発生しているため、その分析結果を組織内で蓄積することでリスク特定の精度は向上していく*4ものと考えます。
参考資料
- ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls
- NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations SR-2, SR-3, SR-4, SR-5, SR-7, SR-9, SR-11
- NTIA Software Component Transparency
- CISA Defending Against Software Supply Chain Attacks
- ISO/IEC 5962:2021 Information technology - SPDX
- ISO/IEC 19770-2:2015 Information technology — IT asset management — Part 2: Software identification tag
- OWASP CycloneDX
- ISMS-AC ISMSユーザーズガイド 追補 ～クラウドを含む新たなリスクへの対応～
