月別アーカイブ: 2022年10月

医療のサードパーティベンダーリスク管理（前編）

コメントをどうぞ

昨今、医療・ライフサイエンス業界では、業務プロセスの一部を外部のサードパーティベンダーと契約してアウトソーシングする形態が増えている。その典型的な例が、SaaS（Software as a Service）モデルの利用である。業務効率化、費用削減といったメリットがある反面、高度化するサードパーティベンダーの契約管理、継続的なモニタリングといったリスク管理策の負荷も大きくなっている。

容易でない医療分野のサードパーティベンダーリスク管理

クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）は、2022年5月11日に「医療サプライチェーンのサイバーセキュリティリスク管理」（https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/）、2022年7月29日に「医療におけるサードパーティベンダーリスク管理」（https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/）を公開している。前者では、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示しており、それを受けた後者では、特にサードパーティベンダーに対するリスク評価・管理に焦点を当てている。

「医療におけるサードパーティベンダーリスク管理」は、以下のような構成になっている。

  • 謝辞
  • 要約
  • イントロダクション
  • 特定
    • サードパーティベンダーの特定と優先順位付け
    • サードパーティの関係性からの潜在的リスク
  • 保護
    • リスク評価
    • セキュリティに関する質問
    • リスク処理
  • 検知
    • モニタリング
  • 対応
    • 対応
  • 復旧
  • 追加的考慮事項
    • クラウド
    • 自動化
    • プログラムの効果の追跡と改善
  • 参考文献

「イントロダクション」の中で、医療におけるサードパーティベンダーリスク管理が失敗する理由として、以下のような点を挙げている。

  • 手動のリスク管理プロセスにおける自動化と信頼性の欠如によって、医療で利用されるデジタルアプリケーションや医療機器のサイバー脅威と拡散に追いつくことが困難になっている
  • ベンダーリスク評価は、時間と費用を要し、ごくわずかの組織だけが全ベンダーのリスク評価を行っている
  • 重要なベンダー管理のコントロールやプロセスは、部分的に実装されているか、実装されていない

医療機関が取扱う電子医療データの容量が拡大し、複雑化する中、機微データの処理に関わるサードパーティベンダーの数は増えている。特に、インフラストラクチャやマネージドアプリケーション、データ管理といった領域で、サードパーティベンダーへの依存度が高まっており、アクセス管理や変更管理、データ運用管理などの業務も高度化・複雑化している。

「医療におけるサードパーティベンダーリスク管理」では、サードパーティベンダーリスク管理のフレームワークとして、「重要インフラのサイバーセキュリティを向上させるためのフレームワーク(NISTサイバーセキュリティフレームワーク)1.1版」(2018年4月16日)を参照しながら、「特定」、「保護」、「検知」、「対応」、「復旧」のカテゴリーをベースに、議論を展開している。

サードパーティベンダーの特定と優先順位付け

「特定」フェーズでは、新たな外部ベンダーや既存の外部ベンダーにおける変更を特定することが、サードパーティベンダーリスク管理プログラムの第１歩だとしている。加えて、サードパーティベンダーを評価するために、当該ベンダーが組織内で、データをどのように保存・処理・転送しているかを理解する必要があるとしている。

サードパーティベンダーを特定したら、提供するサービスや処理するデータの重要性などを考慮しながら、各ベンダーのリスクを評価し、優先順位（例．重要(Critical)、高（High）、中（Moderate）、低(Low)）を付けて分類する必要がある。

医療機関にとって、業務のサードパーティベンダーへのアウトソーシングは、事業戦略の一環である。サードパーティベンダーの役割が拡大するにつれて、医療機関は、ベンダーが直面する潜在的な脅威を低減するために、様々なリスクを継続的にモニタリングすることが不可欠となる。ここでは、医療機関が認識すべきサードパーティベンダーのリスクとして、以下のようなものを挙げている。

  • サイバーセキュリティリスク：サードパーティベンダーのサイバーセキュリティ制御の不備により、組織のデータの機密性、完全性、可用性が影響を受けるリスク
  • レピュテーションリスク：サードパーティベンダーが関与するインシデントが発生した場合、医療機関のブランドレピュテーションにネガティブな影響が及ぶリスク
  • コンプライアンスリスク：事業を遂行するために組織が従わなければならない法律や規制、内部プロセスの違反から生じるリスク
  • プライバシーリスク：サードパーティベンダーと共有する個人データに対する権限のないアクセスが可能となるリスク
  • オペレーショナルリスク：サードパーティベンダーの業務は医療機関の業務と絡み合っており、ベンダーのサービス提供ができなくなると医療機関も日常活動を遂行できなくなるリスク
  • 戦略的リスク：医療機関の戦略目標と合致しないビジネス意思決定をサードパーティベンダーが行った時に生じるリスク
  • 財務リスク：サードパーティベンダーが医療機関の収入に損失を与えるリスク（例．製品リコール）

上記以外にも、様々なリスクが存在するので、医療機関は、将来を見越した拡張性のあるサードパーティベンダーリスク管理プログラムを構築・運用することが求められる。

サードパーティベンダーのリスク評価

次に、「保護」フェーズの柱となるのは、サードパーティベンダーに対するリスク評価であり、リスク分析（リスクの特定、推計、評価）のプロセスが重要になる。本文書では、以下のようなプラクティスを、推奨事項として挙げている。

  • ベンダーの分類：サードパーティベンダーを分類する手法を開発し、個々のベンダーのリスク評価に割り当てる
  • サードパーティ評価頻度の設定と固有のリスク評価に基づくスコープ：サードパーティリスク評価は、一度限りのプロセスでなく、継続的なモニタリングや再評価を必要とする
  • 認識された標準規格を利用したサードパーティ評価の実施：評価をベンダーおよび内部ステークホルダーと共有し、ベンダーが課題に取組み、評価結果をリスク登録に記録することを保証する
  • パフォーマンスの評価
  • 財務リスクの評価
  • 事業継続リスクの評価：サードパーティが中断すると、事業継続のリスクとなる可能性がある

さらに、医療機関は、ベースラインとなるサードパーティベンダー向けセキュリティ質問票を策定しておくことが望まれる。。質問には、以下のような項目も追加するよう推奨している。

  • HITRUST認証
  • SOC2レポート
  • NISTサイバーセキュリティフレームワークなど、認識された標準規格に対するサードパーティ評価
  • 内部セキュリティ統制に関する記入済質問票

サードパーティベンダーとしてのSaaS事業者に対するリスク評価

医療・ライフサイエンス業界に限らず、昨今、クラウドサービスの中で成長著しいのは、SaaSである。反面、IaaS（Infrastructure as a Service）事業者やPaaS（Platform as a Service）事業者と比較して、サードパーティベンダーとしてのSaaS事業者のリスクを評価するための指針やベストプラクティスは少ないのが現状である。そこで、クラウドセキュリティアライアンスは、2022年6月8日、「クラウド利用者のためのSaaSガバナンスのベストプラクティス」（https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf）を公開している。同文書は以下のような構成になっている。

  1. はじめに
  2. 概要
  3. 情報セキュリティポリシー
  4. 情報セキュリティ組織
  5. 資産管理
  6. アクセス制御
  7. 暗号化および鍵管理
  8. 運用セキュリティ
  9. ネットワークセキュリティマネジメント
  10. サプライヤーとの関係
  11. インシデント管理
  12. コンプライアンス
  13. CASBの機能と今後の展望
  14. 結論

SaaSサービスを初期評価する場合、重要な要素は、「使用するSaaSサービスが、自組織のリスクプロファイルおよびエンタープライズアーキテクチャに潜在的に適合しているか」を評価することだとしている。SaaSアプリケーションは、プライベートクラウドやパブリッククラウド、ハイブリッド環境に実装され、専用または共有リソース（シングルインスタンス、マルチテナント）で提供される。複数のクラウドアプリケーションをAPI経由で連携させてサービスを提供する形態もあるが、個々のSaaSによって、責任共有モデルが異なる点に注意する必要があるとしている。

また、上記の「10. サプライヤーとの関係」の中で、サードパーティベンダーとしてのSaaS事業者に係るリスク管理ポリシーに盛り込むべき項目として、以下のような点を挙げている。

  • サードパーティとの関係に対して、組織内で説明可能な単一の役割または立場
  • サードパーティ製品またはサービスに依存する業務運営の重要性について、できれば定量的に、その役割または立場を担う人物が書面による評価を提供することを要件とする
  • 上記で特定した重要性を考慮し、事故がそのようなサードパーティに影響を与える可能性およびそのような事故が組織の業務に与える影響を評価するための方法論
    • 外部監査およびセキュリティレビュー
    • セキュリティスコアリング／評価ベンダーのツール
    • 顧客組織による監査、侵入テスト、プロバイダの製品またはインフラに対する自動スキャンツールの使用など、直接的な技術デューデリジェンス
  • 上記に基づいて設定されたリスク閾値は、サードパーティがこれを超えた場合、サードパーティ側（契約で義務付けられている）、組織自体（何らかの補償的管理を通じて）、またはその両方による是正措置の要求の引き金となる
  • 上記の閾値を超えるリスクを受容する権限を有する、組織内の単一の説明可能な役割または地位、並びにそのようなリスク受容を文書化し正当化するための透明性のあるプロセス

さらに、SaaSの安全かつ信頼性の高い運用を確保するために、個々のサプライヤーに合わせた契約書の作成に際して、以下のような点に留意する必要があるとしている。

  • 製品の可用性だけでなく、基礎となるデータの機密性と完全性についてのサービスレベル合意書（SLA）の作成
  • 組織が監査や侵入テストなどの外部検証プロセスを受け、その結果を提供することの要求
  • 客観的なリスク評価システムに基づいて、組織が特定した脆弱性を、所定の期間内に解決または低減策を特定する要求事項。
  • 組織が脆弱性の重大性または悪用の可能性を低減するために代償措置を適用できるような脆弱性をサプライヤーが特定した場合，サプライヤーは特定の期間内に組織に通知するという要求事項
  • 組織のデータの機密性、完全性、可用性に影響を与えた、または与える可能性のあるインシデントの調査及び是正において、サプライヤーが組織に協力するための要求事項
  • データセンターの新規立地を通知し、好ましくない立地を拒否する権利をサプライヤーに求める要件

ただし実際には、サードパーティベンダーとしてのSaaS事業者の特定、優先順位付け、リスク評価といったプロセスを踏むことなく、ユーザー部門主導でSaaSを導入したケースが多く見受けられる。このような場合、シャドーIT化したSaaS利用の実態を把握することが、サードパーティベンダーリスク管理の第１歩とならざるを得ないので要注意だ。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司