セキュリティ管理のメモ帳

セキュリティに関する備忘録

2023年 セキュリティ脅威予測まとめ

リスクマネジメント

はじめに

　例年、年末から年初のこの時期になると各社セキュリティベンダーから今年の脅威予測が公開されます。今回は、そのまとめとISO 27001:2022で提示されている各管理策とを関連付けて残しておきたいと思います。
　注）なお、本稿は筆者が各サイトの参照と経験に基づき独自に解釈した内容が含まれるため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

１．人の脆弱性を突く攻撃が増加する

　1) proofpoint、3) KnowBe4、4) Avast で取り上げられている内容を以下にまとめます。

脅威の概要

　紛争、金利上昇など、昨年からの社会情勢の急激な変化が人々の生活にも影響を与えており、そのストレスによる要員の集中力の低下を狙った攻撃や、不安を煽るような攻撃など人の脆弱性を突く攻撃が増えることが予測される。

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

5.3 職務の分離
　担当者に加え承認者などの役割を置くことにより、実行前に異常に気付ける体制を整えます
6.3 情報セキュリティの意識向上、教育及び訓練
　定期的な教育や攻撃メール訓練、直近のソーシャルエンジニアリング手法を紹介する注意喚起などを行うことで、利用者が異常に気付ける感度を高めます。
6.8 情報セキュリティ事象の報告
　各フィルタリングによるブロックや注意喚起などをタイムリーに実施できるように、なりすましメール受信などの事象発生時に、速やかに確実にエスカレーションされる体制を整えます。
8.21 ネットワークサービスのセキュリティ
　DMARC（DKIM、SPF）や従業者からの事象報告、IoCなどをトリガーとするメールフィルタリングや警告表示を行うことで、要員がなりすましメールに接する機会を減らします。
8.23 Webフィルタリング
　レピュテーションスコア、要員からの事象報告、IoCなどをトリガーとするWebフィルタリングを行うことで、要員がフィッシングサイトに接する機会を減らします。

２．ディープフェイクのサイバー攻撃への利用が増加する

　1) proofpoint、3) KnowBe4、5) WithSecure、6) Check Point、10) TrendMicro で取り上げられている内容を以下にまとめます。

脅威の概要

　生体認証突破や偽のソーシャルメディアプロフィールの作成などのなりすましがディープフェイクの利用により巧妙化するため、それを利用するBECや情報の詐取を行う攻撃を見破ることが難しくなる。

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

　1項と同じ管理策が有効と思われます。

　他にも、8.3 情報へのアクセス制限、8.12 データ漏洩防止、8.16 監視活動、8.22 ネットワークの分離、8.23 ウェブフィルタリングのような基本的な技術的対策の実施により、攻撃者が最終目的を達成することを防ぎます

３．アカウントの乗っ取りが増加する

　1) proofpoint、3) KnowBe4、7) Barracuda で取り上げられている内容を以下にまとめます。

脅威の概要

　不正に窃取されたクレデンシャル情報がダークウェブ上で安価で取引されており、加えて、MFA Fatigue攻撃やMITMのようにMFAのトークンを窃取することを目的とした攻撃手法も観測されている。乗っ取られたアカウントによるなりすましを技術的に検知することは難しいため脅威アクターが好んで多用する可能性も考えられる。

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

5.7 脅威インテリジェンス
　脅威インテリジェンスサービスなどを利用し、自組織に関連するクレデンシャル情報がダークウェブ上で取引されていないことを確認します 。
8.5 セキュリティを保った認証
　FIDO2認証、PKI認証など、フィッシング耐性のあるMFAを利用しトークンの窃取を防ぎます 。
　前回のログイン成功日時や失敗した試行情報を表示することで、システム利用者に対し他人がなりすましてログインした可能性（ログインの試み）に気付く機会を提供します

　他にも、8.3 情報へのアクセス制限、8.12 データ漏洩防止、8.16 監視活動、8.22 ネットワークの分離、8.23 ウェブフィルタリングのような基本的な技術的対策の実施により、攻撃者が最終目的を達成することを防ぎます

４．サイバー犯罪のビジネス化がさらに進み、攻撃が増加する

　1) proofpoint、2) FORTINET、3) KnowBe4、4) Avast、7) Barracuda、9) SOPHOS で取り上げられている内容を以下にまとめます。

脅威の概要

　従来から存在するRaaSに加え、ダークウェブ上で販売される攻撃用ツール・サービスの種類は今後も増え続け、その利用により技術的な知識が無くても容易に攻撃が可能になる。このような脅威アクターの裾野の拡がりに加え、分業による攻撃の効率化もさらに進むため、今後も攻撃は増え続けることが予測される。

◆ ダークウェブ上で提供されるツール、サービスの例）

  • フィッシング、スミッシング攻撃用ツール
  • RaaS、MaaSを含むCaaS
  • 不正窃取したクレデンシャル情報の販売
  • マルウェアの運用方法の提供

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

　脅威の内容が攻撃全般と多岐に渡り、ほぼ全ての管理策が関連するため、バランス良く多層的に実装することが有効ですが、攻撃の増加という観点でしいてあげると、次のような効率的な管理策の実施が考えられます。

8.21 ネットワークサービスのセキュリティ
　脅威インテリジェンスプラットフォームなどから情報を取得し、SOARにより処理を自動化することにより人的リソースへの負荷を減らし、タイムリーな対応を行います

５．ランサムウェアによる攻撃が深刻な脅威になる

　1) proofpoint、4) Avast、6) Check Point、10) TrendMicro で取り上げられている内容を以下にまとめます。

脅威の概要

　ランサムウェアによるビジネスモデルが従来の二重脅迫から、窃取した情報の売却による換金や情報の漏洩により影響を受ける第三者を巻き込む三重脅迫に移行するなど、脅威アクターの目的は情報の暗号化から窃取に移行しており、攻撃が成立した場合の影響が外部に及ぶためターゲット組織にとって深刻な脅威と成り得る。
　さらに、攻撃の分業化にともない小規模で機敏な攻撃グループが登場し、ターゲット組織の特徴に合わせ大きなダメージを与える攻撃が選択されることが考えられる。

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

　脅威の内容が攻撃全般と多岐に渡り、ほぼ全ての管理策が関連するため、バランス良く多層的に実装することが有効ですが、情報の窃取（情報漏洩）という観点でしいてあげると、次の管理策が考えられます。

8.3 情報へのアクセス制限
　DRM/IRMなどによりファイルを暗号化しアクセス制限により保護します
8.12 データ漏洩防止
　DLPなどにより、保管、利用、移動の各ライフサイクルにおいて機密情報の漏洩の可能性を監視し、予め設定しておいたポリシーに反する行為をブロックします
8.16 監視活動
　SIEM（＋UEBA）により、攻撃者による活動の可能性を検知します

６．クラウドに特化した攻撃が増加する

　5) WithSecure、7) Barracuda、9) SOPHOS、10) TrendMicro で取り上げられている内容を以下にまとめます。

脅威の概要

　今後もクラウド（特に、SaaS）を利用する組織は増えるため、クラウド特有の脆弱性（IAMを含む設定ミスや脆弱なAPIの使用など）を狙う攻撃が増えると予測される。
　また、ランサムウェアの攻撃対象もクラウドに移行することが予測され、Windows及びLinux両方のOSを暗号化するクロスプラットフォーム型マルウェアが観測されている。

関連する管理策の例（ISO/IEC 27001:2022 Annex Aより）

5.2 情報セキュリティの役割及び責任
　クラウドサービス利用の基本的な考え方である責任共有モデルに基づき、プロバイダとカスタマにおいて各管理策（設定）の実施責任を明らかにすることにより、実施漏れに一定の効果をもたらします
5.17 認証情報
　利用者に対し、クラウド特有の環境（アクセス制御が境界防御として機能する一面があること）を説明し、認証情報の重要性を理解してもらいます
8.8 技術的脆弱性の管理
　Windows以外のOSに関しても技術的脆弱性を管理します
　必要に応じ脆弱性診断、ペンテストの実施を検討します
8.9 構成管理
　技術的脆弱性の前提として、（API、SBOMを含む）クラウドサービスの構成を管理します
5.23 クラウドサービスの利用における情報セキュリティ
　CSPM、SSPMや設定不備診断サービスなどを利用し、設定不備の有無を確認します

７．その他

　その他、次の脅威について増加・拡大、継続が予測されています。

◆増加・拡大が予測されている脅威

ゼロデイ脆弱性が増加する

　7) Barracuda

ChromeOSへの脅威が増加する

　8) McAee

ITベースのサイバー攻撃が、ITネットワークに接続されているOTシステムにも及ぶ

　10) TrendMicro

企業在宅間の境界線リスクは今後も拡大する

　10) TrendMicro

◆継続が予測されている脅威

サプライチェーンの弱い部分を狙う攻撃が継続する

　1) proofpoint、7) Barracuda

ワイパー型マルウェアが蔓延する

　2) FORTINET

オープンソースへの脆弱性悪用の攻撃が相次ぐ

　10) TrendMicro

情報源

まとめ

　各セキュリティベンダーによる予測であるため、自社で取り扱うツールやソリューションなどに関連する内容が多い傾向になると思われますが、今年は比較的ばらつきなく予測されているという印象を持ちました。
　1点目は、人の脆弱性を狙う攻撃が増えるという観点です。この点に関しては、以前よりは重要視する組織が確実に増えてはいるものの、十分なレベルに達している組織は少ないと思われ、また、近年は技術的対策による検知技術が向上しており、なりすましがし難くなったことも脅威アクターが選択する一因になっているのではないかと推測します。
　関連する管理策例の中でも紹介していますが、要員が怪しさに気付くための支援や不正の可能性のあるサイトへのアクセス制限、あるいは、なりすましたアカウントによる組織内部の活動の検知など、脅威アクターが最終目的を達成することがないように多層に防御、検知・対応することが非常に重要です。
　一方、アカウントの乗っ取りは技術的に検知することが難しいため、人的な対策を含め同様に多層的な防御を張り巡らす必要があります。
　2点目として、昨年のEmotetのテイクダウンのような一時的な減少はあるかもしれませんが、長い目で見ると外部の脅威アクターによる攻撃が減ることはないと考えた方が良さそうです。国内の課題として未だに組織内のセキュリティ人員の不足が挙げられていることも併せて考えると、SOARやSIEM/UEBAなどのツールを利用した組織内の人的リソースの有効活用も検討が必要かもしれません。
　関連する管理策の中では触れていませんが、リスク対応として幅広く見た場合、リスク移転（リスク共有）としてのサイバーセキュリティ保険への加入なども検討の余地があると思います。

「供給者のサービス提供の監視、レビュー及び変更管理」について

ISO27002管理策の考察

はじめに

　情報セキュリティのための管理策の中で組織的対策として分類されている「供給者のサービス提供の監視、レビュー及び変更管理」について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

１．管理策の概要

　先ずは管理策の本質を理解するために、ISMSに基づく管理策の指針として活用されることの多い ISO/IEC 27002:2022 にどのように記載されているかを確認してみます。

ISO/IEC 27002:2022 5.22 Monitoring, review and change management of supplier services から引用

Purpose：
To maintain an agreed level of information security and service delivery in line with supplier agreements.
管理目的：
供給者の契約に基づき、合意されたレベルの情報セキュリティ及びサービス提供を維持するため。

Control：
The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
管理策：
組織は、供給者の情報セキュリティの活動状況とサービス提供状況の変化を定期的に監視、レビュー、評価し、管理することが望ましい。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　過去にも投稿した通り、セキュリティの管理責任（accountability）は組織にあり、組織自らが必要と判断した「供給者により提供されるサービス利用に関連する各管理策の実施を含むセキュリティ要件」が満たされることを、供給者との合意により担保します。
　さらに、情報セキュリティリスクを適切に維持するためには、組織は供給者との合意事項であるセキュリティ要件の実施*1状況の変化を見極め、意図したレベルが維持されていることを確認する必要があります。
　しかしながら、供給者から提供されるサービスの利用に伴うセキュリティリスクに影響を及ぼすであろう変化を明らかにすることは容易ではなく、そのための特別な管理策の実施が必要となります。

　上記のような背景を踏まえ、本管理策では「組織は、供給者の情報セキュリティの活動状況とサービス提供状況の変化を定期的に監視、レビュー、評価し、管理する」ことが求められています。
　具体的には、次のような事項を含むリスクアセスメント（運用サイクル）及びリスク対応の実施が求められていると解釈しました。（あくまで私個人が解釈した内容です）

  • 監視：組織の状況の理解
  • レビュー：リスク特定、リスク分析
  • 評価：リスク評価
  • 管理：リスク対応を含むリスクマネジメント全般

　リスクアセスメント（運用サイクル）については、過去の記事で考察しています。 　blg8.hatenablog.com

２．具体的な実施例

　具体的には、供給者により提供されるサービス利用に関し、下表のような変更管理を実施します。

図　供給者によるサービス提供に対する変更管理の実施例

　次項以降で、上記に対する具体的な実施内容を考えます。

２－１）合意文書による遵守事項の維持

　供給者との間で合意された内容の遵守が変わらずに維持されることを監視、レビュー、評価により管理します。

a）監視手法

　監視手法について、具体的な実施例とともに紹介します。

  • サービスのパフォーマンスレベル
    　例えば、各種パフォーマンス指標を表示するダッシュボードなど、サービスの可用性やパフォーマンスの状態を可視化してくれるクラウドサービスの支援機能を利用することで組織は容易にそのパフォーマンスレベルを確認することができます。

  • 供給者によるサービスレポート
    　供給者から毎月提供されるサービスレポートにより、サービスのパフォーマンス、ダウンタイム、セキュリティインシデント等の情報を入手することができます。

  • 第三者による監査やリスクアセスメントなどの報告書
    　クラウドサービスを利用している場合、クラウドサービスプロバイダの監査を組織が自ら実施することは現実的ではないため、SOC2レポートのような客観的な評価レポートを入手し確認することが一般的です。

  • 組織による第二者監査
    　合意文書により事前に監査権を主張しておくことで、組織自らが監査により確認することが可能になります。

b）レビュー内容

　SLAなどに記載されている合意事項と監視結果との比較によりレビューを行います。

c）評価内容

　レビューの結果、合意事項への違反が確認された場合は、改善内容などその対応について供給者と協議します。
　なお、合意事項への違反が判明した場合の補償及び改善内容は合意事項により事前に明らかにしておくことも重要です。
　上記内容を含む、供給者との合意については、過去の記事が参考になります。

blg8.hatenablog.com

２－２）セキュリティ事象、インシデント、及び問題に対する適切な管理

　セキュリティ事象、インシデント、及び問題に対し速やか且つ適切な対処をするために、監視、レビュー、評価により管理します。

a）監視手法

　監視手法について、具体的な実施例とともに紹介します。

  • 脆弱性の特定
    　脆弱性はサービスリリース後に発見されることもあるため、定期的な確認によりその管理を行うことが必要です。具体的には、脆弱性スキャンやペネトレーションテスト、SBOMの管理とコンポーネントの脆弱性調査の実施などです。

  • インシデント、及びインシデントに関連する可能性のある事象の報告
    　事前に合意しておくことで、例えば、セキュリティ侵害や情報の漏洩などの組織が利用しているサービスに関連するインシデントなどが発生した場合の報告を供給者から入手することができます。

  • 供給者が管理している監査証跡
    　供給者と事前に合意が得られているケースでは、セキュリティ事象が発生した時に、サービスの利用状況、セキュリティ関連の活動の情報*2を含む監査証跡を入手することができます。

  • 不審なアクティビティの検知
    　稀なケースではありますが、供給者が提供するサービスの支援機能としてログを確認する事ができる場合は、モニタリングにより事前に設定した判定基準*3との比較や不審なアクティビティ*4の検知が可能になります。

b）レビュー内容

　レビューは、リスク対応の必要性を見極めるためのリスク分析が主な内容となります。次のような項目についてレビューが必要になると思われます。

  • 事象がインシデントに発展する可能性
  • インシデントの原因の特定と影響の分析
  • 再発防止策の必要性
c）評価内容

　レビューの結果から、事象又はインシデントへの対応の必要性、緊急度、及び対応内容を検討します。
　内容によっては供給者との協議が必要になる可能性があります。

２－３）供給者による変更がサービス提供に影響を与えないことの確認

　供給者による変更がサービス提供に影響を与えないことを確認するために監視、レビュー、評価により管理します。
　なお、適切な変更管理を行うために、次を含む内容について事前に供給者との合意により明らかにすることも検討します。

  • 変更を実施する前の組織への通知の要否
  • 変更を実施する前の組織の承諾の要否
  • 変更実施時の組織への通知内容と実施から通知までの期限
a）監視手法

  • サービスの提供に関連する変更
    　 例えば、新製品、又は新バージョンの採用やサービス施設の物理的な位置の変更など、供給者が提供するサービスの品質、性能及びセキュリティに影響を与える可能性のある変更を監視します。
    　※）サービス施設の物理的な位置の変更について
    　データの保管、転送、処理の物理的な位置が変わる場合、法域（関連法令の適用）に影響する可能性があることを理解し、リスクを特定する必要があります

  • サービス内容の変更
    　例えば、サービスの改善や新しいセキュリティ管理策の採用や実施内容の変更など、供給者がサービスに加える変更が、組織が利用するサービスの品質、性能及びセキュリティに与える影響を監視します。

b）レビュー内容

　レビューは、リスク対応の必要性を見極めるためのリスク分析が主な内容となります。ここでは、変更がサービス提供やセキュリティに与える影響を分析する必要があります。

c）評価内容

　レビューの結果から、変更内容への必要性、緊急度、及び対応内容を検討します。
　内容によっては供給者との協議が必要になる可能性があります。

まとめ

　例えば、「合意文書の遵守状況の維持」、「セキュリティ事象、インシデント、及び問題に対する適切な管理」、「供給者による変更がセキュリティリスクに影響を与えないことの確認」など、供給者が提供するサービス利用に係るセキュリティリスクを適切に管理するためには、対象となるサービスに対する監視、レビュー、変更管理が欠かせません。本稿では、その具体的な実施内容について考察しました。
　上記は、組織のみで完結できるものではなく、供給者の協力が必須となる項目が多く含まれていますので、その内容に関し事前に明確かつ具体的な合意を得ることが、インシデントの未然防止だけではなく、事象発生時の速やかな対応のために必要となります。併せて、リスクコミュニケーションなどによる協力関係、信頼関係を築くことも重要と考えます。

参考資料

  • 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-6, SR-10

脚注

*1:具体的には、リスクマネジメントや管理策の実施などの情報セキュリティに関する活動全般やサービスの提供など

*2:例えば、ログインやログアウト、システムへのアクセス、データの変更などです。

*3:例えば、ルールベースや正常なアクティビティのパターンを学習し、異常なアクティビティを検知するために機械学習により設定される基準などです。

*4:例えば、ログインエラーが一定回数以上発生した場合や、不審なIPアドレスからのアクセスなどです。

「ICTサプライチェーンにおける情報セキュリティの管理」について

ISO27002管理策の考察

はじめに

　情報セキュリティのための管理策の中で組織的対策として分類されている「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）
Framing Software Supply Chain Transparency (NTIA) より引用

　上記は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サプライチェーンの一つの形態であると考える事ができます。

図２　クラウドサービスにおける供給者関係
JIPDEC　ISMSユーザーズガイド　追補　～クラウドを含む新たなリスクへの対応～より引用

　組織がクラウドサービスを利用する場合、原則、サービスの供給者であるクラウドサービスプロバイダと責任共有モデルに基づき各管理策の実施義務を明らかにし、必要に応じ、合意又は、同意しますが、図のようにサプラチェーン状に連鎖してる場合は、その実施状況の透明性確保が難しくなります。このため、「供給者のサービス提供の監視、レビュー及び変更管理」に関し、特別な考慮が必要になります。
　上記を含め、「クラウドサービス利用のための情報セキュリティ」に関する管理策については、後日、考察する予定です。

まとめ

　本稿では、サプライチェーン上に様々な供給者が関与することで複雑な形態となり、その透明性の確保が容易ではないとの観点で、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ユーザーズガイド　追補　～クラウドを含む新たなリスクへの対応～

脚注

*1:責任共有モデルが明らかになることで、取得組織として実施責任を有するセキュリティ管理策が明確になります。

*2:例えば、ペネトレーションテストの結果、第三者認証、監査レポートなどによりレビューします。

*3:評価スキームの例として、ISMS認証（ISO/IEC 27001）、CC認証（ISO/IEC 15408）、FIPS 140-2認証の取得状況、CCRA（Common Criteria Recognition Arrangement）による評価が考えられます。

*4:リスク特定のための組織（外部）の状況の理解には、他組織で発生したインシデントが含まれることが一般的です。

「供給者との合意における情報セキュリティの取扱い」について

ISO27002管理策の考察

はじめに

　情報セキュリティのための管理策の中で組織的対策として分類されている「供給者との合意における情報セキュリティの取扱い」について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

１．管理策の概要

　先ずは管理策の本質を理解するために、ISMSに基づく管理策の指針として活用されることの多い ISO/IEC 27002:2022 にどのように記載されているかを確認してみます。

ISO/IEC 27002:2022 5.20 Addressing information security within supplier agreements から引用

Purpose：
To maintain an agreed level of information security in supplier relationships.
管理目的：
供給者との関係において、合意されたレベルの情報セキュリティを維持するため。

Control：
Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship.
管理策：
関連する情報セキュリティ要件を確立し、供給者との関係の種別に基づき各供給者との間で合意することが望ましい。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　前回の記事でも触れましたが、組織が供給者に対しセキュリティ要件などにより各セキュリティ管理策の実施を要請する場合、原則、両当事者による合意文書に基づくことで実施義務を課すことができます。本管理策では、その合意内容を明らかにすることが求められています。
　なお、本管理策は、上記のように管理策の実施義務を供給者に課すことを交渉可能なケースに適用される内容となります*1 。

　本稿では、供給者との合意事項に含めるべきセキュリティ要件他の内容を具体的に考えてみたいと思います。

２．具体的な実施例

　過去の記事でも述べていますが、供給者が関係するセキュリティにおいてもリスクマネジメントプロセスに基づくことで過不足なく適切に管理することができます。

blg8.hatenablog.com

　それと同じ考え方で、組織と供給者の間で合意すべき事柄*2を検討する際も、次のようにリスクマネジメントの各プロセスで実施すべき活動の実施責任を当事者間で明らかにすることでその漏れを防ぐことができます。

  • 供給者との関係性を理解し、リスクアセスメントによりセキュリティ要件を明らかにする
  • セキュリティ要件を満たすための管理策（リスク対応）の実施分担を当事者間で調整し、供給者に課す実施義務を明らかにする
  • 供給者により実施している管理策の適合性、有効性を適切に把握するため、セキュリティ監査などの権利を主張する（リスクモニタリングとレビュー）
  • 両当事者において発生するセキュリティ事象などの情報が適切に共有されるようにリスクコミュニケーションを確立する

　次項以降では、上記の各プロセスにおいて、供給者との合意事項に含めるべき内容を具体的に考えてみます。

２．１．供給者との関係性を理解し、リスクアセスメントによりセキュリティ要件を明らかにする

　供給者に求めるべきセキュリティ要件を明らかにするためには、その前段としてリスクアセスメントが必要になります。
　具体的には、下図に示すように組織と供給者が共有する情報及びその他関連する資産を明らかにし、その情報への供給者の関わり方とそこから想定されるリスクを特定する、すなわちリスクアセスメントすることで対応する管理策の実施責任を組織と供給者で調整することが可能になります。

図ー1　合意内容の検討のためのプロセス

　以下は、上図の各プロセスにおける実施内容と合意文書で明らかにすべき内容の例です。

１）情報の特定

　リスクアセスメントの精度向上*3、さらに、そこから得られる適切な管理策の実施のために、次の内容をリスト化するなどして合意文書の中で明らかにします。

  • 供給者が取り扱う組織の情報及びその他関連する資産、並びにその提供方法；又は
  • 組織が供給者から取得する情報及びその他関連する資産、並びにその取得方法
２）リスクアセスメント

　上記で特定した内容を基に、供給者が関係することにより想定されるリスクを特定します。
　ここでは、実施方法の一例として、情報のライフサイクル（作成、保存、使用、共有、アーカイブ、破棄）の各プロセスで供給者が関係するリスクとそのリスクを適切に管理するための各管理策を考えてみます。

① 作成（Creat）

　供給者が作成した成果物を組織が取得するケースでは、その成果物が信頼性や正確性に欠ける、あるいはマルウェアや悪意のあるコードが組み込まれている可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、信頼性と正確性を保証するための品質管理基準、供給者の要員のセキュリティ意識を高めるための教育やトレーニングの実施について合意文書により定めることが考えられます。

② 保存（Store）

　組織が提供した情報（データ）を供給者が管理するサーバーやデータベースなどに保存するケースでは、不適切な保護に起因する不正アクセス、情報の漏洩、情報の改変や改ざん、あるいはデータ喪失など、機密性、完全性、可用性が損なわれる可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、暗号化やアクセス制御によるデータ保護に関する基準、供給者の施設に対する物理的管理策の内容、DRサイトなどの代替施設に関する内容、バックアップ*4及びその復旧に関する基準などを合意文書により定めることが考えられます。

③ 使用（Use）

　業務プロセスの一部を外部委託するために組織の情報の使用を供給者に認可するケースでは、供給者による誤った取り扱いや悪用の可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、関連法令の遵守や情報の使用制限に関する方針、供給者によるアクセス制御や監視の要求、供給者の要員のセキュリティ意識を高めるための教育やトレーニングの実施について合意文書により定めることが考えられます。
　逆に、供給者から取得する情報及びその関連資産を組織が使用するケースでは、① 作成プロセスでも触れましたが、その取得物が信頼性や正確性に欠ける、あるいはマルウェアや悪意のあるコードが組み込まれている可能性があることを想定し、供給者に要件を提示することが必要になります。

④ 共有（Share）

　供給者との共同作業のために組織の情報を共有するケースでは、組織が認可する範囲*5を超えた共有の可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、第三者提供の禁止など情報の使用制限に関する方針、適切なセキュリティプロトコルやアクセス制御*6の利用について合意文書により定めることが考えられます。
　また、組織の管理下にある情報を共有する場合、データ損失防止（DLP）やデジタル著作権管理（IRM）などの技術的な管理策の対象範囲を供給者まで拡げることで効率的な管理ができる可能性があるため、その使用に関し合意が必要になるケースが考えられます。

　なお、供給者と情報を共有する際の合意では、共有する情報に求める保護ニーズが供給者に対し正確に伝わらないリスクについても考慮しなければなりません*7 。
　具体的には、セキュリティの3要件（機密性、完全性、可用性）に関し、組織と供給者との間で認識のズレが生じないように、合意プロセスにおいて情報の分類基準を当事者間で整合します。
　情報の分類については、過去の記事が参考になります。 blg8.hatenablog.com

　分類基準の整合は、次のような流れで行うのが一般的です。

  • 組織が定めた分類基準と供給者のものとを比較する
  • 比較結果に応じ調整を行う
  • 結果を文書化し、当事者間で合意する
⑤ アーカイブ（Archive）

　供給者の保有設備において組織の情報を長期保管するケースでは、適切にアーカイブが保護されないことで機密性、完全性が損なわれ、結果的に法的要件を満たさない、あるいは、暗号の危殆化など刻々と変化する技術的な環境によって組織が示す要件を継続して満たすことができなくなる可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、アーカイブにおいても通常の保存環境と同等のセキュリティ要件を求める、あるいは、適切な管理とその有効性に関する評価方法について合意文書により定めることが考えられます。
　さらに、長期アーカイブの場合はベンダーロックインリスク*8 に対する考慮が必要です。合意事項においては、移植容易性、相互運用性などについても明らかにし、供給者に大きく依存しない運用体制の確保を検討します。

⑥ 破棄(Destroy)

　供給者の保有設備において組織の情報を保存するケースでは、不適切なデータ破棄により、組織が認可していない第三者による不正アクセスやデータ復元が発生する可能性がリスクとして考えられます。
　このようなケースにおける有効な管理策としては、適切な破棄方法とは何かを一般的なガイドラインや基準をベースに具体的に定め、その実施結果に対する組織への報告や組織による監査などについて合意文書により定めることが考えられます。

⑦ その他

　情報のライフサイクルの観点以外にも、契約終了時や再委託先の利用など供給者が関連するリスクが考えられます。

　供給者との関係が解消された後もセキュリティは維持しなければならないため、契約終了時に供給者により実施されるべき、次のような管理策を明らかにしておきます。

  • アクセス権のプロビジョニング解除
  • 資産の返却
  • セキュリティに配慮した情報の処分
  • 相互運用性と移植容易性の確保
  • 「継続的な機密保持」など契約終了後も引き続き順守すべき内容*9

　さらに、供給者が提供する製品又はサービスを利用するケースでは、契約終了後も組織の業務を継続するために必要な引継支援の内容（例えば、計画・手順の策定、各種ドキュメントや情報の提供、教育や訓練、セキュリティに配慮したデータの移行、各種調整など）を明らかにし、供給者に対し実施義務を課すことを検討します。

　サプライチェーン上の透明性*10とガバナンス*11を確保し、再委託先に範囲を拡げた場合でも組織のセキュリティ要件が確実に満たされるように、次の考慮事項を含め、合意事項において再委託先管理の内容を明らかにしておきます。

  • 再委託先の選定に対する適切性の確認方法
  • 実施責任などの合意内容に対する充足性の確認方法
  • リストの提出など、組織が再委託先を特定する方法
  • 事前通知などの再委託先の変更管理に関する手続き方法
  • 組織が求めるセキュリティ要件を満たすための各管理策の実装を要求する方法
  • 管理策の実施状況及び有効性の確認方法
  • アクセス制御や認証に係る個別方針や手順などの遵守義務の伝達方法
  • 組織の情報が関連するシステムやデータへのアクセス認可の方法
  • 再委託先でインシデントが発生した場合の報告ルートなど、情報セキュリティに関するリスクコミュニケーションの実施内容

２．２．セキュリティ要件を満たすための管理策（リスク対応）の実施分担を当事者間で調整し、供給者に課す実施義務を明らかにする

　前項のプロセスで明らかにしたセキュリティ要件を満たすための各管理策の実施分担を当事者間で調整し、結果を合意文書により明らかにします。管理策の実施内容は可能な限り定量的で具体的なものにしておくことでより適切にセキュリティリスクを管理することができます。
　具体的な管理策については、前項で事例をあげているため、ここでの説明は省きます。

２．３．供給者により実施している管理策の適合性、有効性を適切に把握するため、セキュリティ監査などの権利を主張する（リスクモニタリングとレビュー）

　供給者に実施義務を課した各管理策が、組織の意図通りに実施されていることを確認します。確認方法としては、次のような方法を用いることが一般的です。

１）組織による監査の実施

　供給者に実施義務があるセキュリティ要件の順守状況を確認するため、組織による監査*12の実施権限に関し、次の項目を考慮し合意文書に含めることを検討します。

表－１　合意文書に含める監査の実施権限の例

２）第三者機関による監査

　例えば、供給者が提供するサービスがSaaSの場合、組織が直接監査することは現実的ではありません。そのようなケースにおいては、信頼性の高い監査機関による認証*13や第三者機関による監査結果の報告*14を以て、組織による監査に替えることがあります。

３）供給者からの報告

　供給者が自ら実施するセキュリティ管理策の有効性に関する確認結果*15を定期的に報告することを求めます。報告頻度は、取り扱う情報の量や重要度、リスクアセスメント結果、契約期間などにより両当事者により調整されます。

４）合意事項への違反

　供給者によるセキュリティ要件の順守状況を確認した結果、合意事項への違反が判明した場合の補償及び改善内容を事前に明らかにしておきます。改善が期待できない場合も考慮し、契約の解除も選択肢として検討する必要があります。
　合意事項への違反などの問題が判明した場合に円滑に解決するためのプロセスには、次のようなものが含まれます。

  • 問題点を特定し、相手に通知する方法
  • 問題点について協議するための方法
  • 問題点の解決のための具体的な措置を決定し、実施するための方法
  • 紛争が発生した場合に、当事者間で協議する方法
  • 協議によって紛争が解決しなかった場合に、第三者の仲裁や裁判所への訴訟提起についての方法
  • 仲裁や訴訟提起に関する手続きや費用についての合意方法

２．４．両当事者において発生するセキュリティ事象などの情報が適切に共有されるようにリスクコミュニケーションを確立する

１）連絡手段

　効果的なコミュニケーションのためには、連絡の内容に対し事前に窓口を特定しておく必要があります。例えば、セキュリティインシデントが発生した場合に迅速かつ適切に対応するために、次のように両当事者の対応窓口を特定し、合意文書やSLAなどに明記し、変更があれば更新します。

  • セキュリティに関する問題やインシデントに対する組織の対応窓口となる担当者の氏名、所属部署、連絡先（電話番号、メールアドレスなど）
  • 供給者のセキュリティ担当者の氏名、所属部署、連絡先
２）インシデント管理のための要件とその手順

　セキュリティインシデントを管理するための要件とその手順を明らかにします。具体的には、次の内容を含むインシデント管理要件を供給者に求めることを検討します。

表ー２　インシデント管理に関する要件の例

３）変更管理

　供給者に対し、組織と合意した内容に関し変更が発生する場合に通知、及び組織による承認が変更実施前に行われることなど変更管理プロセスに関し合意を得ることで、セキュリティに影響を及ぼす各種変更に対するリスクを適切に管理します。

表ー３　供給者に求める変更管理の例

まとめ

　冒頭でも述べた通り、組織が供給者に対しセキュリティ要件などにより各セキュリティ管理策の実施を要請する場合、原則、両当事者による合意文書に基づくことで実施義務を課すことができます。そのため、本管理策では、その合意内容を明らかにすることが求められています。
　本稿では、リスクマネジメントプロセスに基づき、リスクアセスメントによる管理策の検討、リスク対応に対する責任共有、モニタリング及びレビューによるセキュリティ管理策の適合性及び有効性の確認、供給者とのリスクコミュニケーションなど、効果的かつ効率的にセキュリティリスクを管理するために合意事項に含めるべき内容を考えました。
　なお、セキュリティリスクは刻々と変化するため、一般的なリスクマネジメントで行われているような組織の状況の変化に応じリスクアセスメントを実施し、その結果としてリスク対応内容を見直すのと同じように、供給者との合意内容を見直す必要があります。そうすることでリスクの変化に対し、的確に追従することができます。

参考資料

  • ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls
  • ISO/IEC 27036-2:2022 Cybersecurity — Supplier relationships — Part 2: Requirements
  • NIST SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations
    AU-16, SA-4, SA-9, SA-11, SR-2, SR-3, SR-7, SR-8, SR-10, SR-11, SR-12
  • ISO/IEC 19086-1:2016 Information technology — Cloud computing — Service level agreement (SLA) framework — Part 1: Overview and concepts

脚注

*1:パッケージソフトウェアやSaaS利用時に多い、供給者により定められた使用許諾や利用規約に組織が同意することでその利用が認められ、その内容に関し交渉の余地が無いケースは含まれません。

*2:供給者に要求する内容や合意内容は組織と供給者の関係性により異なります。その関係性については、前回記事で述べている通りです。

*3:特に、「アセットベースアプローチ」を採用する場合は、効果が顕著に表れると思います。

*4:具体的には頻度、種類（完全／差分）、場所、期間などが考えられます。

*5:利用範囲（再委託先との共有など）や処理範囲（閲覧、編集、複製、転送など）など

*6:具体的には、使用可能なリソースの範囲や使用可能なアプリケーションやシステムの種類を明確にする、アクセスを認可する情報を特定する、アクセス方法（認証方法）を明確にする、組織の情報及び関連資産にアクセス可能なIDを保有する要員を特定する、アクセスログを取得するなどが考えられます。

*7:保護ニーズが満たされないことを防ぎ、過剰な保護による非効率な管理策の実施も避けなければなりません。

*8:例えば、供給者独自のデータ形式やアーカイブ形式の使用、データのロック、契約条件の変更などが考えられます。

*9:一般的に残存条項と呼ばれるものです。

*10:組織は、サプライチェーン上に存在する再委託先とそこで実施されている業務、取り扱っている組織の情報などを把握し、リスクを特定しなければなりません。

*11:組織は、自らが定めたセキュリティ方針が再委託先を含めたサプライチェーン上で遵守されていることを確認し、維持する必要があります。

*12:一般的には、第二者監査と呼ばれます。

*13:供給者の情報セキュリティマネジメントシステム、サービス、または製品が、規定された情報セキュリティ要件を満たしていることを保証するものです。

*14:米国公認会計士協会（AICPA）SOC2レポートなどが利用されます。

*15:供給者が実施した情報セキュリティに関する活動や評価結果、管理策の運用状況、改善計画などが含まれます。

「供給者関係における情報セキュリティ」について

ISO27002管理策の考察

はじめに

　情報セキュリティのための管理策の中で組織的対策として分類されている「供給者関係における情報セキュリティ」について、主要なガイドラインを参考に自分なりに解釈した内容を、なるべく具体的に残しておきます。

１．管理策の概要

　先ずは管理策の本質を理解するために、ISMSに基づく管理策の指針として活用されることの多い ISO/IEC 27002:2022 にどのように記載されているかを確認します。

ISO/IEC 27002:2022 5.19 Information security in supplier relationships から引用

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 use of supplier’s products or services.
管理策：
供給者の製品又はサービスの利用に関連する情報セキュリティリスクを管理するために、プロセス及び手順を定め、実施することが望ましい。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　過去の記事にも書きましたが、情報セキュリティマネジメントは、リスクマネジメントプロセスに基づくことで、セキュリティ管理策を過不足なく効果的かつ効率的に実装でき、セキュリティリスクを適切に維持することができます。

blg8.hatenablog.com

　供給者が関係する情報セキュリティについても同様のことが言え、本管理策では、そのリスクマネジメントのためのプロセスと手順を定めることが求められています。

２．具体的な実施例

　ここからは、供給者が関係する情報セキュリティをリスクマネジメントプロセスに基づき管理するための具体的な実施方法について考えたいと思います。
　考え方はいたってシンプルです。組織で既に運用されているセキュリティリスクマネジメントフレームワークの適用範囲（scope）に供給者が関係するリスクも含め管理することになります。
　今回も過去の記事と同じようにISO/IEC DIS 27005:2021の情報セキュリティリスクマネジメントサイクルをベースに、供給者が関係することで追加、及び補完すべき活動（アクティビティ）を各プロセスごとに考えることにします。

図１　情報セキュリティリスクマネジメントサイクル

１）状況の設定

　リスクアセスメント及びリスク対応の判断結果には、一貫性、再現性が求められるため、この状況の設定プロセスにおいて、供給者との関係性を理解し、情報セキュリティリスクマネジメント方針への反映又は供給者が関係するセキュリティリスクに特化した個別方針の策定により方向付けを行い、その管理手法と基準を定め、組織内外において標準化します。

blg8.hatenablog.com

※）本稿では、供給者が関係する情報セキュリティリスクを管理するための個別方針（以下、「個別方針」と呼びます）を策定すると仮定し進めます。

① 適用範囲

　組織が管理対象とする範囲（組織がセキュリティリスクを直接管理しようとするサプライチェーン上の範囲）を定めます。具体的な内容としては、供給者の先に存在する再委託先などの関係組織を特定し、その管理方針を定めるなどが考えられます。
　IPAから2017年に発行されている調査報告書*1には、企業へのヒアリング結果として、再委託先の運用に関し、主に次のような2種類の形態が採られているという趣旨の報告がされています。

  • 原則、再委託を禁止しつつも、例えば、再委託先の社員を委託先に常駐させるなど、条件次第で例外的に容認する
  • 再委託を容認しつつも、再委託先がセキュリティ対策状況等の必要とする情報を開示しないなど、条件次第で禁止する

　このように組織の基本方針や供給者との関係性などにより、適用範囲、及び再委託先の管理方針の内容は左右されるため、次項以降で掘り下げて考えます。

② 組織と供給者の関係性

　一言で供給者が関係するセキュリティリスクと言っても、その関係性により組織に与える影響は異なります。したがって、その個別方針は一律に策定するのではなく、組織の事業形態により想定される供給者との関係性に応じた内容にすることで効果的に管理することが可能です。
　具体的には、既存、又は新規で取引する供給者が組織に与える影響の大きさや組織のガバナンスの及ぶ範囲などに影響する各指標を特定し、その指標による分類基準と分類毎の管理方法を予め定めます。
　上記基準をベースに、例えば、公開情報や与信調査結果などから得られる供給者の分類に対し、それぞれ個別方針を適用することで、効果的、効率的なリスクマネジメントが可能になります。
　供給者を分類するための基準策定時に考慮すべき指標は、次のようなものが考えられます。

  • 供給の対象

　組織と関係する可能性のある供給者のタイプを特定します。例えば、供給者関係におけるセキュリティマネジメントのガイドライン規格であるISO/IEC 27036-2:2022の要約では、次のように供給の対象が例示されています。

ISO/IEC 27036-2:2022　Abstract　より一部抜粋し引用

These requirements cover any procurement and supply of products and services, such as manufacturing or assembly, business process procurement, software and hardware components, knowledge process procurement, build-operate-transfer and cloud computing services.

これらの要求事項は、製造又は組み立て、業務プロセスの調達、ソフトウェアやハードウェアの構成部品、知識プロセスの調達、一括事業請負後譲渡方式（BOT：Build-operate-transfer）、クラウドコンピューティングサービスなど、製品やサービスのあらゆる調達と供給を対象としている。

※）英語部分は原文から引用、日本語部分は、DeepLで翻訳した結果を筆者が修正

　さらに、上記のような供給者のタイプから想定されるセキュリティ事象を明らかにすることで、組織に与える影響を把握することができます。
　脅威、及び想定されるセキュリティ事象については、前回の記事で紹介した次の３タイプによる分類なども参考になると思います。
　・サプライチェーンを経由した攻撃
　・サプライチェーン攻撃
　・サプライチェーン構造に起因するリスク

blg8.hatenablog.com

  • 取引規模や関係性
    　一般的に取引規模が大きい場合や長期的な取引関係がある場合は、組織による供給者への信頼や依存度は高く、組織が求めるセキュリティ要件に対し供給者が応じてくれる可能性は高くなります。それに反し、規模が小さく取引が短期的な場合は、逆の傾向があるため、リスクアセスメント時の判断に影響を与えます。
    　さらに、リスク対応時のアプローチの仕方にも影響を与える可能性があります。例えば、長期的な業務提携を前提にした供給者の場合、リスクの大きさに加え、その組織との協力により得られる事業上の価値も考慮が必要となる可能性があります。他方、一時的な取引に限定される場合、その組織との協力により得られる価値はあまり考慮せず、リスクの大きさのみでその対応を判断することが多くなります。
    　上記のような観点で「戦略的」、「戦術的」、「運用上」、「コモディティ」というように組織と供給者の関係をカテゴリ分けすることで、効果的、効率的なリスクマネジメントができると考えられています。

　他にも以下のような指標がセキュリティリスクに影響を与えます。

  • 取り扱う情報の種類、重要度
    　供給者が取り扱う可能性のある組織の情報の種類、例えば、その情報に対し求められる法的要件の有無、事業上の重要度、セキュリティの3要素（機密性、完全性、可用性）など。

  • 提供される製品、サービスが組織に与える影響
    　供給者から提供される製品やサービスが組織の事業へ与える影響の大きさや組織の脆弱性に与える影響の大きさ。

③ 役割と責任

　過去の記事でも述べた通り、サプライチェーン上におけるインシデントの発生などの結果に対する説明責任（accountability）は、原則、取得者側にあります。したがって、ここで明らかにするのはセキュリティ管理策の実施やセキュリティリスクマネジメントの実施責任（responsibility）の在り方に関する内容です*2 。

　セキュリティリスクマネジメントに基づき考えると、供給者によるセキュリティ管理策の実施責任は、合意文書に基づき担保されることが原則となるため、組織と供給者の関係性も、その可否に基づき次のように分類できます。

  • 契約時に、組織がセキュリティ要件を提示し、合意事項の中で供給者に対しその実施義務を課すことができる範囲を交渉可能なケース*3（以下「交渉可能なケース」と呼びます）
  • 契約時に、供給者により定められた使用許諾や利用規約に組織が同意することでその利用が認められ、その内容に関し交渉の余地が無いケース*4（以下「交渉の余地が無いケース」と呼びます）

　上記、２つのケースの管理方法については、２－３）リスク評価で後述します。

④ 実施のタイミング

　組織で既に運用されているセキュリティリスクマネジメントフレームワークと同じように、「戦略サイクル」と「運用サイクル」 の二種類の実施サイクルを採用することで、長期的なセキュリティマネジメントの維持改善とセキュリティ事象に対する速やかな意思決定を両立することができます。供給者が関係するセキュリティリスクマネジメントの各サイクルにおける実施内容のイメージを下図に示します。

図２　「戦略サイクル」と「運用サイクル」のイメージ

⑤ 実施手法

　実施手法に関しても、組織で既に運用されているセキュリティリスクマネジメントフレームワークの適用範囲に含め管理されるため、原則はそれに準じますが、例えば、合意すべき内容、供給者の評価・選定方法、セキュリティ管理策の実施状況の確認方法、情報の共有方法、維持継続のための方法など、供給者が関係することで発生する特別な管理手法についても、方向性を明らかにしておく必要があります。

⑥ リスクの重大性を決定するための基準

　リスクに関する基準については、原則、次のような事項を明らかにし組織内の基準と同等のものを求めます。

  • 供給者を選定するプロセスにおいて事前調査すべき内容とその評価方法*5
  • 上記関係組織に関するリスクアセスメントの実施方法

　上記以外にも、リスク対応時にリスク保有（許容）の判断に影響する供給者の必要性とそのメリットについても考慮が必要です。
　さらに、個々のセキュリティ管理策を組織又は供給者のどちらで実装するか検討し、供給者に提示するセキュリティ要件を明らかにします。その際に考慮すべき点など、詳細については次回の記事で考察したいと思います。

⑦ リスクが受容可能かどうかを決定するための基準

　リスクが受容可能かどうかを決定するための基準は、原則、組織内の場合と同程度となります。

⑧ リスク対応の選択肢

　リスク対応の選択肢に関しては、供給者との合意の仕方によって異なります。

  • 交渉可能なケース
    　組織内のセキュリティリスクマネジメント方針に準じ、リスク対応を行います。その中では、供給者が合意事項に違反した場合の是正処置方法についても明らかにしておいた方が良いと思われます。

  • 交渉の余地が無いケース
    　受容基準を超えたリスクに対し、供給者が提示する制約の中で実施しうるリスク対応の選択肢には、次のようなものがあります。
    　セキュリティ要件を満たす他の製品、サービスを探す。その結果、組織の機能要件を満たすものが他にも見つからない場合は利用しない（リスク回避）
    　供給者により提供される製品やサービスなどのメリットや必要性を考慮し、リスクを許容し利用する（リスク保有）
    　供給者により実装されるセキュリティ管理策で不足している部分を組織により補う（リスク低減）
    　※）交渉の余地が無い前提ではありますが、可能であれば、セキュリティ管理策の実施を覚書やSLAなどの追加文書により合意することでもリスク低減が期待できます

２－１）リスク特定

　次の事項を含む組織内外の状況を理解することで供給者が関係するリスクの特定漏れを防ぎます。

  • 供給者及び供給者により提供されるサービスなどにより、組織外部で処理、伝送、保存される組織の情報及びその他関連資産
  • 組織のセキュリティリスクに影響を与え得る供給者が提供する製品及びサービスの種類（例えば、ICT関連製品、システム運用保守、ビジネスアウトソーシング、製造委託、クラウドサービスの利用など）
  • 供給者がアクセス、監視、制御、利用することが可能な組織の情報及びその他関連資産（例えば、ICTサービス、物理的基盤など）
  • SBOMなどの供給者から提供される製品やサービスの構成情報（例えば、使用されているライセンスソフトウェア、オープンソースソフトウェアなど）
  • 組織内部、及びサプライチェーン上の利害関係者におけるセキュリティリスクマネジメント上の権限及び責任
  • 業界、地域、組織固有のリスク要因
  • 供給者が組織の情報を保管する位置情報とその法域での関連法令
  • 供給者が製品、又はサービスを納入する各ケースで想定される供給者の要員の悪意に基づくリスク*6
  • 供給者が提供する製品やサービスによる誤動作、構成要素を含め内在する脆弱性
  • 供給者が関係する過去のセキュリティインシデントの発生状況、及び対応内容の適切性
  • 供給者が公表しているセキュリティ関連の認証状況や外部機関による監査報告書、セキュリティ方針、セキュリティレポートの有無や内容
  • 供給者の属性情報（市場シェア、企業年齢、ビジネス環境や業種）

２－２）リスク分析

　特定したリスクに対する自組織への影響を試算します。供給者及び取得する製品、サービス毎に、例えば、次のような考慮事項を含めリスクの重大性を分析します。

  • 特定した供給者の種類（例えば、ICT関連製品、システム運用保守、ビジネスアウトソーシング、製造委託など）による組織の事業への影響度
  • 特定した供給者により提供されるICT関連の製品及びサービスの組織の事業への影響度
  • 供給者がアクセス、監視、制御、利用することが可能な組織の情報、ICTサービス、物理的基盤が組織の事業に及ぼす影響度

※）サプライチェーンの場合、供給網に関連するため、セキュリティの３要素の中でも可用性（事業継続）に対する要求が高くなる傾向を考慮し分析します

２－３）リスク評価

　前述のように、供給者が関係するセキュリティリスクの評価内容は、供給者との合意の仕方によって異なります。

  • 交渉可能なケース
    　リスク分析結果に基づき、組織のセキュリティ方針を満たすために必要となる管理策の実装を供給者に要求し、その実施義務について文書により合意します。

※）なお、取得者が供給者に対し、セキュリティ管理策の実施を要請する場合は、取得者は、独占禁止法上の優越的地位の濫用や下請法上問題にならないことを考慮しなければなりません。（気を付けるべき点については、経済産業省と公正取引委員会から連名で公開されている「サプライチェーン全体のサイバーセキュリティ向上のための 取引先とのパートナーシップの構築に向けて」が参考になります）

  • 交渉の余地が無いケース
    　組織の機能要件を満たす供給者のサービス又は製品を評価・選定し、組織が求めるセキュリティ要件の充足度をレビューします。評価時に用いる情報は、原則、使用許諾や利用規約のような遵守性が求められる文書*7ですが、その中で組織が求めるセキュリティ要件が満たされることは稀*8であるため、実際の管理策の実装状況を参考にすることがあります*9 。
    　その場合は、例えば、クラウドサービスの評価であれば、ISMAPなどの公的な評価制度や、第三者によるリスク評価サービス（レイティングサービス）などの情報を参考にすることで効率的な評価が可能になります。

３）リスク対応

　”１）状況の設定” で定めた「リスク対応の選択肢」の方針に従い、リスク対応を実施します。
　リスク対応の実施方法は、合意文書に基づく供給者への要請や組織による補完管理策の実施など多岐に渡ります。供給者に対し、リスク対応を求める場合は、組織が、正確な情報収集やレビューからリスクを正確に把握し、方針やより詳細な手順などの適切な情報を提供することで有効な結果が得られます。そのためには、供給者との協力関係、信頼関係に基づく密なリスクコミュニケーションを取ることが重要です。
　なお、セキュリティリスクを回避するために、供給先と取引をしない（又は既存の供給先との取引を停止する）ことを検討する場合には、事業及び業務上のその供給者の重要性などを考慮し、かつ、ビジネスオーナーなどの事業リスクの所有者による承認が必要になる場合があります。

４）リスクモニタリングとレビュー

　組織内のセキュリティリスクマネジメントと同様に供給者が関係するセキュリティリスクに関してもモニタリングとレビューを行い、必要に応じ改善要求を行います。

blg8.hatenablog.com

　具体的には、供給者におけるセキュリティマネジメント及び各種セキュリティ管理策の実施状況やその有効性をモニタリングしますが、組織が直接監視できないケースも多いため、第三者による監査などにより対応することもあります。
　供給者が関係するリスクのモニタリングとレビューの際に考慮すべき点には次のようなものが含まれます。

  • 変化が生じた時、及び定期的なレビューとリスクマネジメントの実施（組織のリスクマネジメント方針に準ずる）
  • 組織が求めるセキュリティ要件の遵守状況（第三者のレビュー及び製品の妥当性確認を含む）
  • サービス提供内容のモニタリングとセキュリティ事象、及びインシデントの検知・報告
  • 供給者が実施しているセキュリティ管理策の有効性の変化
  • 供給者に提供した情報及びその他関連資産の管理状況
  • 供給者が関係するリスクを含めた脅威インテリジェンスの実施
  • 供給者におけるセキュリティ監査の実施状況
  • 再委託先の使用状況及び管理状況

　さらに、モニタリングから得られた結果は供給者選定時や契約時に見落とされていたリスクの再確認や改善にも役立てられます。

５）リスクコミュニケーション

　例えば、セキュリティリスクマネジメント方針などのセキュリティ要件を組織から供給者に伝える、あるいは、セキュリティ要件の遵守状況やセキュリティインシデントの発生について供給者から組織に報告するなどのリスクコミュニケーションのためのルートや窓口について事前に明らかにします*10 。また、ISACなどの情報共有機関を設け組織横断的な連携が行われている業界もありますので、参加することで効率的なリスクコミュニケーションが可能になります。

　組織が供給者に対し通知すべき内容には次のようなものが含まれます。

  • 組織のセキュリティ方針、手順、ガイドラインなどのセキュリティ要件
  • 合意事項に反する事象が発生した場合の措置とその実施責任
  • セキュリティアセスメント、監査、評価に関する要件
  • 情報セキュリティ教育・訓練、及び認定の要件
  • セキュリティに関する契約条項、SLA、及びその他の合意事項に関する要件
  • セキュリティ上の重要な変更、改善、及び問題の報告に関する要件
  • セキュリティに関する法令、規制遵守に関する要件

　組織が供給者からの報告を求めるために事前に協議すべき内容には次のようなものが含まれます。

  • セキュリティ事象及びインシデントの発生とその影響、対応状況に関する報告
  • 新しいシステムやアプリケーションなど、変更があった時のセキュリティリスクアセスメントに関する報告
  • セキュリティに関する問題や懸念事項、リスクについての報告
  • セキュリティ方針、手順、ガイドラインなどへの違反に関する報告
  • 供給者によるセキュリティリスクマネジメントの改善や進捗状況についての報告
  • 供給者が保有する組織の情報及びその他関連資産のセキュリティに関する報告
  • 供給者が提供する製品及びサービスの危殆化など、脆弱性に関する報告
  • 第三者機関によるものを含め、セキュリティ監査や評価結果に関する報告
  • 要員に対するセキュリティ教育・訓練及びその有効性に関する報告
  • セキュリティに関する法的な変更や規制の影響、懸念事項に関する報告

まとめ

　今回は「供給者関係における情報セキュリティ」について考察しました。本管理策を実装することで、供給者との関係においても組織が求めるセキュリティレベルを維持することが可能になります。
　供給者の選定、合意形成、モニタリング、評価など、供給者との関係を解除するまでの各場面において、リスクマネジメントサイクルの各プロセスを適用することで効果的にセキュリティリスクを管理することが可能となり、さらに、供給者から取得する製品やサービスの選定から利用終了までのライフサイクルの各プロセスに関しても、リスクマネジメントサイクルの視点に基づくことで同様の効果が得られます。
　また、組織が供給者に対し直接ガバナンスを及ぼすことが難しい*11ことを考えると、供給者で実施されるリスクアセスメントとリスク対応の状況を正確に見極めるために有効なリスクコミュニケーション及びリスクモニタリングをいかにして実現するのか工夫が必要になります。

参考資料

  • ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls
  • ISO/IEC DIS 27005：2021 Information security, cybersecurity and privacy protection — Guidance on managing information security risks
  • IPA 情報セキュリティに関するサプライチェーンリスクマネジメント調査 ー調査報告書ー
  • ISO/IEC 27036-2:2022 Cybersecurity — Supplier relationships — Part 2: Requirements
  • 経済産業省/公正取引委員会 サプライチェーン全体のサイバーセキュリティ向上のための 取引先とのパートナーシップの構築に向けて

脚注

*1:情報セキュリティに関するサプライチェーンリスクマネジメント調査　ー調査報告書ー

*2:実際の個々の供給者との具体的な実施責任に関する取り決めは、SLAやセキュリティ要件の提示などの合意文書により明らかにします。ここでは、方針として基本的な考え方の方向付けを行います。

*3:具体的には、組織がシステム開発を外部に委託する際に、非機能要件としてセキュリティ管理策の実装義務を供給者に課すようなケースです。

*4:具体的には、パッケージソフトウェアやSaaSなど、既に完成している物やサービスを組織が利用するようなケースです。

*5:金融や法務と同じように、セキュリティに関してもデューディリジェンスを実施します。

*6:これまで、金銭目的などの委託先、再委託先の要員による悪意を持った情報の持出などのインシデントは多く報告されています。

*7:中には、SLA、SLO、セキュリティホワイトペーパーなどを一般公開している企業もあります。

*8:文書レビューにより、組織のセキュリティ要件が全て満たされることは稀であるため、残留リスクの許容に関する方針を予め明らかにしておくことが必要です。

*9:前述の通り、供給者による管理策の実施は、合意文書でのみ担保され、契約時点における実施状況は、その維持や変化に対する追随などが保証されてはいないため、あくまで参考情報として取り扱うことになります。

*10:リスクコミュニケーションのためのルートを新たに設けずに、既存の商流上のルートの利用が効果的なこともあります。

*11:「組織が供給者に対し直接ガバナンスを及ぼすことが難しい」理由については、過去の記事で考察しています。

サプライチェーンセキュリティリスクマネジメント（後）

リスクマネジメント

ー サプライチェーン上のセキュリティリスク ー

はじめに

　前回の記事では、サプライチェーンセキュリティリスクマネジメントに関する考察の前編として、サプライチェーン上の情報の管理責任について考えました。今回は、後編としてサプライチェーン上のセキュリティリスクについて考えてみたいと思います。

blg8.hatenablog.com

１．サプライチェーンのリスク要因

　ここでは、サプライチェーンの構造に起因するリスクについて考えたいと思います。

１．１．組織は供給者を直接管理できない

　本稿では、図１のように供給者（supplier）が何らかの製品・サービスを供給（納品、または支援）し、その取得者（acquirer）が対価を支払う商流に関連する組織群をサプライチェーンと定義します。

図１　サプライチェーンの構造

　上図のように、取得者と供給者は供給と対価に関する合意に基づき関係性が築かれていることが一般的です。また、組織B、組織Cのように供給者と取得者の両方の役割を有することが多くあります。

　この関係性を、一つ目のサプライチェーン特有のリスク要因と考えることができます。

  • 供給者などのサプライチェーン上に存在する利害関係者、及びそこで行われるプロセスを組織は直接管理することができない

　上記のような商流では、一般的に組織間で情報の共有や製品・サービスの取得が発生するため、その活動に伴う「組織から供給者に提供した情報の取り扱い不備」や「供給者から提供されるシステム・サービスに内在する脆弱性」などの組織に影響を及ぼすセキュリティリスクの範囲が拡がる一方で、子会社のように資本関係がある一部のケースを除き、通常は供給者に対し組織のガバナンスは及びにくく、リスクを直接管理できないというジレンマが生じます。
　このようなケースでは、リスクマネジメントの各プロセスで実施すべき活動（Activity）の実施責任を、組織と供給者の間で明らかにする必要があります。

　具体的には、リスク対応のために行われるセキュリティ管理策など、次の各項目を含むセキュリティに関連する各種活動の実施義務やその実施状況の確認方法について事前に当事者間で文書により合意します。

  • リスク対応：組織がリスク対応のために必要と考える各セキュリティ管理策の実施義務
  • リスクのモニタリング及びレビュー：各セキュリティ管理策の実施状況の確認
  • リスクコミュニケーション：インシデントや変更のように、速やかな対応が求められる情報の共有

　上記の考え方に基づくリスクマネジメントの実施内容については、後日、次のようなテーマで考察しようと思います。

  • 「供給者関係における情報セキュリティ」について
  • 「供給者との合意における情報セキュリティの取扱い」について
  • 「供給者のサービス提供の監視、レビュー及び変更管理」について

１．２．サプライチェーンの全体像を把握することは困難

　もう少し、サプライチェーンの構造について掘り下げて考えてみます。
　契約の形態によっては、供給者の判断で下請負業者などの再委託先を利用するケースが考えられます。その場合、プロジェクトの規模が大きくなるほど、利害関係者は多くなり、サプライチェーンの全容を把握することは益々困難になります。
　このようなケースでは、ある一つの完成品のサプライチェーンに限って考えても、図１のような数珠繋ぎの形態になることは稀で、図２のようにツリー状や網目状に近い複雑な形態になることの方が多いと思われます。

図２　複雑なサプライチェーン

　この複雑な形態を、二つ目のサプライチェーン特有のリスク要因と考えることができます。

　特にソフトウェアは、OSS（Open Source Software）をコンポーネントとして利用するなど複雑なサプライチェーンにより作成されていることが多く、そのサプライチェーンが複雑なほど、構成されているソフトウェアコンポーネントの透明性を確保することは難しくなります。
　例えば、SolarWindsに関連するインシデントやApache Log4jの脆弱性のような事象が発生した場合、リスクアセスメントにより対応内容を検討しますが、迅速にリスク特定するためには、日常的にソフトウェアコンポーネントの透明性が確保されている必要があり、近年では、SBOMによるソフトウェア構成の適切な管理が重要視されています。
　サプライチェーンに関連するリスクマネジメントの実施内容については、後日、以下のようなテーマで考察しようと思います。*1

  • 「ICTサプライチェーンにおける情報セキュリティの管理」について
  • 「クラウドサービスを利用するための情報セキュリティ」について

２．サプライチェーン上のセキュリティリスクとは

　ここからは、サプライチェーン上のセキュリティリスクについて具体的に考えてみます。
　国内でサプライチェーン上のリスクとして捉えられているものを、あえて分類すると次のように３つのケースに分けることができると思います。

　次項では、各ケースについて詳しく見ていきます。

２．１．サプライチェーンを経由した攻撃

　最終的なターゲット組織に影響を与えるために、商流のサプライチェーン上にある脆弱な関連会社、取引先、委託先などを踏み台として利用する攻撃です（海外では、Island hopping attack と呼ばれることが多いようです）。初期段階で、ターゲットが定められているため、標的型攻撃の一種に分類されると個人的に考えます。

図３　サプライチェーンを経由した攻撃イメージ

　具体的には、次のようなケースが考えられます。実際に起きたインシデント例と合わせて紹介します。

・供給者が保有するターゲット組織の情報が窃取される

　自治体からヘルプデスク業務を受託している組織のPCがマルウェア感染し、住民からの問い合わせメールが流出した可能性がある。

・供給者になりすました巧妙なBECを仕掛けられる

　供給者のメールアカウントが乗っ取られ、ターゲット組織に対する架空の請求及び支払先口座情報が送信され、不正な支払をした。

・供給者を経由してターゲット組織のネットワークに侵入される

　海外拠点のサーバーに侵入され、そこを足掛かりにして国内外の複数拠点に侵入範囲が拡大し、多くの端末がマルウェアに感染した。

・サプライチェーンが分断され、ターゲット組織の事業継続に影響が及ぶ

　供給者でセキュリティ侵害によるシステム障害とそれに伴う生産停止が発生し、その結果、部品供給が滞り、取得者であるターゲット組織の一部で生産停止を余儀なくされた。

２．２．サプライチェーン攻撃

　製品、ソフトウェア、サービスを製造する過程のサプライチェーン上で不正コードなどの部品を組み込んでおくことで、その供給先である取得者を攻撃する手法です（海外では、Supply chain attackと呼ばれます）。より多くの組織に影響を及ぼすソフトウェアや製品に悪性部品を仕込み、偵察によりその供給先を特定しターゲットを定めるため、ばらまき型の一種に分類されると個人的には考えます。

図４　サプライチェーン攻撃のイメージ

　具体的には、次のようなケースが考えられます。実際に起きたインシデント例と合わせて紹介します。

・ソフトウェア開発元が攻撃され、ソフトウェアまたはアップデートに不正コードが仕込まれる

　約50社のMSP（Managed Service Provider）が使用しているVSA（Virtual System Administrator）に対するゼロデイ脆弱性を悪用したセキュリティ侵害が発生し、そこを足掛かりとしてマルウェアが仕込まれた偽のアップデートが顧客（約1500社）システムに配信され、多くの端末が感染した。

・供給される製品に不正な部品が使用され、偽造品によるセキュリティ侵害、模造品によるレスポンス低下などが発生する

　米国でネットワーク機器用の部品に、海外製の不正な偽装品、模造品が使用されていることが判明し、ネットワークへの不正侵入の可能性があるとして大規模な調査が行われた。

２．３．サプライチェーン構造に起因するリスク

　セキュリティ管理策の実施責任が曖昧であったり、供給者内の要員の不正、過失など、主にサプライチェーン上に組織のガバナンスが及ばないことに起因するリスクが考えられます。
　具体的には、次のようなケースが考えられます。実際に起きたインシデント例と合わせて紹介します。

・供給者とのセキュリティ管理策の実施責任が明確になっていないことにより、脆弱性が放置される

　VPN装置を設置した業者と保守運用の契約が結ばれておらず、脆弱性対応の管理が誰にも行われずに放置され、その脆弱性を悪用するセキュリティ侵害が発生した。

・供給者（再委託先）の要員による不正が行われる

　再委託先社員が、委託元の顧客情報を私物スマートフォンに保存し、名簿業者に売却した。

・供給者（再委託先）の要員による過失が発生する

　Webサイトの開発を委託していた先の要員が誤って公開設定のままソースコードをGitHubにアップロードし、それに気づかず放置していたため第三者によるアクセスが可能な状態だった。

・供給者とのコミュニケーション不足により必要な対策が実施されない

　クラウド型CRMシステムを利用している多くの組織で、設定不備に起因する顧客情報の流出の可能性があることが公表された。

・サプライチェーン上で組み込まれる構成情報の把握不足により脆弱性対応が遅れる

　オープンソースソフトウェア（OSS）で深刻な脆弱性が公表されたが、多くの組織でその影響範囲を特定する作業に追われた。

２．４．具体的な管理策について

　今回、明らかにしたセキュリティリスクに対応する具体的な管理策については、次回以降の投稿でなるべく具体的に考察していきたいと思います。

まとめ

　今回はサプライチェーン上のセキュリティリスクについて考えてみました。本文でも触れましたが、サプライチェーンの規模が大きくなるほど、組織のガバナンスが及ばなくなる可能性は高くなります。さらに、サプライチェーンが関連するリスクは多岐にわたり、実際に多くのセキュリティインシデントが発生していることも理解いただけたと思います。
　サプライチェーン全体にセキュリティリスクマネジメントを適用するためには、取得者がリスクコミュニケーションなどの手法を用い主体的に関わらなければならず、かつ、効果的な運用とするためには様々な工夫が必要となります。後日、公開予定の各管理策の考察では、その辺についてなるべく具体的に考えてみたいと思います。

参考資料

　本稿は、以下の文献を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

脚注

*1:ここでは、クラウドサービスもICTサプライチェーンの一つの形態として考えています。

サプライチェーンセキュリティリスクマネジメント（前）

リスクマネジメント

ー サプライチェーン上の情報の管理責任 ー

はじめに

　多くの組織では、「専門知識や技能の不足を補う」、「コストを削減する」、「地理的な範囲を拡大する」など、様々な目的で、供給者（サプライヤー）との関係性を構築し効率的にリソースを確保しています。
　他方、その供給網であるサプライチェーンは複雑性を増すことで透明性が失われ、さらに、供給者による不正行為や提供されるサービスや製品の脆弱性によってそれを取得する組織のセキュリティを脅かす側面も併せ持ち、ここ数年、実際にサプライチェーン上の脆弱性を悪用する攻撃は増加傾向にあり、インシデント報告も目立つようになってきました。

　その対策として、海外では、以前から ISO/IEC 270036 や NIST SP800ｰ161 などのサプライチェーンに特化したセキュリティ管理策を提示しているガイドラインが発行されており、ISO/IEC 27002、NIST SP800-171など、管理策を網羅的に提示するガイドラインにおいてもサプライチェーンに関連する内容が充実してきています。
　国内に目を向けても、近年、自組織だけではなく組織に関連するサプライチェーンをリスク源としたセキュリティ上の脅威が取り沙汰されることが多くなっており、IPAが公開している情報セキュリティ10大脅威でも、2019年に初めて取り上げられてから毎年上位で扱われています。

表１「IPA 情報セキュリティ10大脅威 」における順位の変動

　同じく、脅威への対策が急務との認識が拡がっており、サプライチェーン・サイバーセキュリティ・コンソーシアム（SC3）の設立やISACなどの各業界団体において、セキュリティガイドラインの策定、実施状況のモニタリング、教育・啓発コンテンツの共有など、サプライチェーンに関連するセキュリティリスクへの対応が進められています*1 。

　昨今の状況を踏まえ、サプライチェーンにおけるセキュリティリスク*2について考えてみたいと思います。

　注）なお、本稿は筆者が文献の参照と経験に基づき独自に解釈した内容のため、認識が間違っている可能性があります。（誤りに気付いた方は、コメントいただけると幸いです）

必要とされる背景

　各組織がサプライチェーン上のセキュリティリスクマネジメントの必要性を意識するようになったきっかけとしては、NIST SP800-171が2016年に発行されたことが大きいと思います。
　それまでも、NIST SP800-53により米国連邦政府の情報及び情報システムに関連する組織を対象としたセキュリティ管理策の実施が求められていましたが、NIST SP800-171の発行に伴い政府調達（特に米国防総省）に関わる一連のサプライチェーンに存在する業務委託先、関連企業の全てにセキュリティ要件の適用範囲が拡大しました。
　国内においても、NIST SP800-171を参考にした防衛産業サイバーセキュリティ基準による防衛装備品の調達が2023年の契約から適用されることが公表されています。
　防衛装備庁 : 防衛産業サイバーセキュリティ基準の整備について

　下表にて、NIST SP800-53とNIST SP800-171を簡単に比較します。

表２　NIST SP800-53とNIST SP800-171の比較

　NIST SP800-171発行の背景として、１つのインシデントが影響していると言われています。その内容とは、米国が契約する豪州の業者の再委託先からF35戦闘機の製品仕様書を含む30GB相当の情報が窃取されたものです。
　情報を流出させた組織の当時のセキュリティ管理は非常に脆弱な状態（例えば、システム管理者が1名のみ、4か月間侵入に気付かなかった、単純なパスワードが使用されていた）であったとされています。
　このインシデントが、サプライチェーン上のリスク（脆弱性）マネジメントの必要性や、機密情報に分類されていなくともそれに準ずる複数の情報を関連付けることにより脅威に成り得るとの考え方が浸透したきっかけの一つと考えます。

サプライチェーン上の情報の管理（保護）責任

　ここからは、サプライチェーンが関連する情報のセキュリティ上の管理責任について考えます。

　取得者と供給者*3との関わり方には、次のように様々なケースが考えられますが、どのケースにおいても原則、情報の管理責任はその情報の所有者（取得者）*4にあります。

  • 　供給者から提供される製品・サービスを利用し情報を管理する
  • 　供給者に情報の管理を委託する
  • 　業務プロセスを委託するために、組織の情報を供給者に提供する

　例えば、業務プロセスの委託やクラウドサービス*5の利用により、組織の情報の管理を供給者に委託する際に、合意文書中のセキュリティ要件により供給者に管理策の実施義務（responsibility）を課すことが多いと思われますが、その場合においてもインシデントの発生などの結果に対する説明責任（accountability）は取得者側にあります。
　供給者に情報の管理（又は処理）を委託するケースを、過去に書いた記事の各役割に当てはめると、取得者はOwner（兼Steward）、供給者はCustodianという関係性になります。
　blg8.hatenablog.com

　上記の妥当性を法令、ガイドラインを参照し、デューケアとデューディリジェンスの観点で検証します。
　なお、セキュリティに関連するデューケアとデューディリジェンスの考え方については、過去の記事が参考になります。 　blg8.hatenablog.com

デューケアの観点で考える管理責任

　まず、デューケアの観点でサプライチェーンが関連する情報の管理責任について考えてみます。
　例えば、個人情報保護法では、次のように定められており、個人データの取り扱いを委託する場合、その委託先に対する必要かつ適切な監督が義務付けられています。

（委託先の監督）　第二十五条
個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。

　具体的な実施内容は、個人情報保護委員会から発行されている個人情報の保護に関する法律についてのガイドライン （通則編）において、次のように解説されています。

3-4-4　委託先の監督（法第 25 条関係）から一部抜粋
具体的には、個人情報取扱事業者は、法第 23 条に基づき自らが講ずべき安全管理措置と同等の措置が講じられるよう、監督を行うものとする。
（中略）
個人データの取扱状況（取り扱う個人データの性質及び量を含む。）等に起因するリスクに応じて、次の（1）から（3）までに掲げる必要かつ適切な措置を講じなければならない。

　リスクに応じて、実施すべき必要かつ適切な措置として次の（１）から（３）があげられています。
　（1）適切な委託先の選定
　（2）委託契約の締結
　（3）委託先における個人データ取扱状況の把握

　上記のように、法的にも委託元による管理義務が具体的に求められていることがわかります。

デューディリジェンスの観点で考える管理責任

　次にデューディリジェンスの観点でサプライチェーンが関連する情報の管理責任について考えてみます。
　例えば、組織の情報セキュリティマネジメントシステムの目的を「リスクマネジメントプロセスを適用することによって情報の機密性、完全性及び可用性を維持し、かつ、リスクを適切に管理しているという信頼を利害関係者に与える」としたときは、自ずとサプライチェーンはその情報セキュリティマネジメントシステムの適用範囲に含まれます。
　なぜなら、サプライチェーンが組織の目的に対する不確かさの影響を与えうる要因（リスク源）となるからであり、具体的には、サプライチェーンに対し、組織のリスクマネジメントプロセスを適用する必要があります。

　セキュリティに直接関連してはいませんが、筆者がデューディリジェンスの概念と具体策を再認識するためによく参照させていただいている 責任ある企業行動 (RBC) のためのOECDデュー・ディリジェンス・ガイダンス でも以下のように記載されています。

責任ある企業行動 (RBC) のためのOECDデュー・ディリジェンス・ガイダンスより
多国籍企業行動指針に基づくデュー・ディリジェンスの概念には、相互に関わり合う一連のプロセスが含まれる。すなわち、企業自体の事業、サプライチェーンおよびその他のビジネス上の関係に関して、負の影響を特定し、その負の影響を防止し軽減し、実施状況および結果を追跡調査し、どのように負の影響に対処したかを伝える　一連のプロセスである。

　すなわち、デューディリジェンスの概念は、サプライチェーンおよびその他のビジネス上の関係に関して

  • 負の影響を特定（＝リスクアセスメント（特定・分析・評価））し、
  • その負の影響を防止し軽減（＝リスク対応）し、
  • 実施状況および結果を追跡調査（＝リスクのモニタリング及びレビュー）し、
  • どのように負の影響に対処したかを伝える（＝リスクコミュニケーション）
  • 一連のプロセス（＝リスクマネジメントプロセス）である。

とされており、前述のように、サプライチェーンに対するリスクマネジメントを組織により実施することが求められています。

　以上のことから、デューケア、デューディリジェンスの観点からも原則、情報の管理責任は取得者にあるとの考え方は妥当だと結論付けます。

まとめ

　今回は、サプライチェーンに関連するセキュリティリスクマネジメントが必要とされる背景とその管理責任について考えました。
　組織が保有する情報は、生成から廃棄までのライフサイクルの様々な場面でサプライチェーン上の供給者の手に渡り処理されたり、保管されることがあります。このように情報が組織から離れることがあっても、万が一、セキュリティが損なわれた場合は、結果に対する説明責任（accountability）は取得者にあるため、主体的に管理することが求められます。
　したがって、取得者は十分なリスクマネジメントを行い、サプライチェーン上のセキュリティを管理しなければなりません。
　次回は、サプライチェーン上のセキュリティリスクについて考えてみたいと思います。

参考資料

　本稿は、以下のサイト、文献を参考にしています。より詳細な情報を得たい、正確性を重視したい方は以下を参照して下さい。

脚注

*1:https://www.ipa.go.jp/security/fy2021/reports/sme/gyoukai-hearing.html

*2:過去のブログでも何回か触れている内容ですが、管理策をすべて実施することは現実的ではなくリスクマネジメントに基づくことにより効率的なセキュリティ対応が可能です。サプライチェーン上のセキュリティマネジメントも同様で、供給される製品に過度なセキュリティ要件を求めることは管理策の不要な重複や高額な対価を招くことになります。

*3:サプライチェーン上の取得者と供給者の定義については、後日、取り上げたいと思います。

*4:ここでの情報の所有者とは、データ保護責任者（DPO）やデータの管理責任者（Owner）のことを表しており、データ主体とは異なります。

*5:最近は、SaaSを利用し業務プロセスを委託（BPO：ビジネスプロセスアウトソーシング）するBPaaS（Business Process as a Service）という委託形態もあります。