月別アーカイブ: 2023年8月

ロボット支援手術(RAS)システムの脅威モデリング（前編）

コメントをどうぞ

2023年1月30日、クラウドセキュリティアライアンス（CSA）のIoTワーキンググループ／健康医療情報管理ワーキンググループ／クラウドインシデント対応ワーキンググループは、「遠隔手術机上演習ガイドブック」(https://cloudsecurityalliance.org/artifacts/telesurgery-tabletop-guide-book/)を公開した。ここでは、脅威モデリングの観点から、ロボット支援手術(RAS)システムに代表されるクラウドコンピューティングを利用した医療機器のサイバーセキュリティについて考察する。

米国の医療機器市販後安全管理策に位置づけられた脅威モデリング

脅威モデリングに関連して、米国食品医薬品局(FDA)は、2016年12月28日に「医療機器におけるサイバーセキュリティの市販後管理 – 業界および食品医薬品局スタッフ向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices)を公開している。本ガイダンスは以下のような構成になっている。

Ⅰ. イントロダクション
Ⅱ. 背景
Ⅲ. スコープ
Ⅳ. 定義

A.補完的な制御
B. 制御されたリスク
C. サイバーセキュリティの日常的なアップデートとパッチ当て
D. サイバーセキュリティの兆候
E. 悪用
F. 患者の害
G. 救済策
H. 脅威
I. 脅威モデリング
J. 制御されないリスク
K. 脆弱性

Ⅴ. 一般原則

A. 市販前の考慮事項
B. 市販後の考慮事項
C. 安全性と不可欠なパフォーマンスの維持

Ⅵ. 医療機器サイバーセキュリティリスク管理

A. サイバーセキュリティ脆弱性の悪用可能性の評価
B. 患者の害の重大度の評価
C. 患者の害のリスクの評価

Ⅶ. サイバーセキュリティ脆弱性の救済策と報告書作成

A. 患者の害の制御されたリスク
B. 安全性と不可欠なパフォーマンスに対して制御されないリスク

Ⅷ. PMA(市販前承認)時系列報告書に含むのに推奨されるコンテンツ
Ⅸ. ISAO(情報共有・分析組織)における製造業者による活発な参加を明確化するための基準
Ⅹ. 附表: 有効な市販後サイバーセキュリティプログラムの要素

A. アイデンティ
ⅰ. 安全性と不可欠なパフォーマンスの維持
B. 保護／検知
ⅰ. 脆弱性の特徴づけと評価
ⅱ. リスク分析と脅威モデリング
ⅲ. 脅威ソースの分析
ⅳ. 脅威検知能力の取込
ⅴ. すべての機器に関する影響度評価
C. 保護／対応／復旧
ⅰ. 補完的制御の評価(検知／対応)
D. 安全性と不可欠なパフォーマンスのリスク低減策

　このうち、「Ⅴ. 一般原則」の「A. 市販前の考慮事項」では、医療機器市販前の考慮事項として、以下のような点を挙げている。

  • 資産、脅威、脆弱性の特定
  • 機器の機能とエンドユーザー／患者における脅威や脆弱性の影響度評価
  • 脅威や脆弱性が悪用される確率の評価
  • リスクのレベルと適切な低減戦略の決定
  • 残存リスクと許容リスクの基準の評価

また、B. 医療機器市販後の考慮事項」では、以下のような点を挙げている。

  • サイバーセキュリティの脆弱性とリスクの特定・検知に関するサイバーセキュリティ情報ソースのモニタリング
  • 以下のようなメカニズムを含む堅牢なソフトウェアライフサイクルプロセスの維持
    • -機器のトータル製品ライフサイクルを通した新たな脆弱性の関するサードパーティ製ソフトウェアコンポーネントのモニタリング
    • -汎用(OTS)ソフトウェア関連など、脆弱性の救済に利用されるソフトウェアのアップデートやパッチに関する検証やバリデーションの設計
  • 脆弱性の存在や影響度に対する理解、評価、検知
  • 脆弱性の取込や処理に関するプロセスの確立と伝達
    • (注: FDAは、「ISO/IEC 30111:2013: 情報技術 – セキュリティ技法 – 脆弱性対応手順」を認知してきた)
  • サイバーセキュリティリスクから保護、対応、復旧する低減策の構築によって、機器の安全性および不可欠なパフォーマンスを維持する方法を明確に規定するための脅威モデリング利用
  • 協調的脆弱性開示ポリシーおよびプラクティスの採用(FDAは、「ISO/IEC 29147:2014: 情報技術-セキュリティ技法- 製造業者にとって有益な可能性がある脆弱性開示」を認知してきた)
  • 初期および悪用される前にサイバーセキュリティリスクに取組む低減策の展開

なおFDAの市販後ガイダンスでは、「脅威モデリング」について、目標と脆弱性を特定し、システムに対する脅威の影響を防止または低減する対策を明確にすることによって、ネットワーク／アプリケーション／インターネットセキュリティを最適化するための手法と明記している。医療機器の場合、生産ラインにある製品や、患者に害を引き起こす可能性がある組織のサプライチェーンから、特定製品に対する脆弱性や脅威を明らかにすることによって、セキュリティ強化のために脅威モデリングを利用できるとしている。

そして、製造業者に対し、個々の機器向けの脅威モデリングを含むサイバーセキュリティリスク分析を実行し、これらの分析を経時的にアップデートするよう推奨している。脅威モデリングは、伝統的なリスクマネジメントと故障モード分析のパラダイム、そして、活発な敵対者／悪意ある利用からの脅威を評価するフレームワークを提供するものである。個々の脆弱性に関して、リスク分析と脅威モデリングの情報を簡潔に要約したサマリーレポートを作成すべきだとしている。また、分析の周期的な性質上、情報は、関連した文書化に追跡可能であるべきだとしている。

参考までに、日本の厚生労働省が、2023年3月に公表した「医療機器のサイバーセキュリティ導入に関する手引書(第2版)」(https://www.mhlw.go.jp/content/11120000/001094636.pdf)をみると、「5. 市販前の考慮事項」の「5.1. セキュリティ要求事項及びアーキテクチャ設計」の中で、脅威モデリングに関する記述があるが、「6. 市販後の考慮事項」にはそのような記述が見当たらない。

MITREの医療機器向け脅威モデリングガイダンス

FDAのガイダンスを受けてMITREは、2021年11月30日、医療機器イノベーションコンソーシアム（MDIC）と共同で「医療機器脅威モデリングプレイブック」(https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices)を公開している。このプレイブックは、FDAの資金助成を受けて、MITRE、MDIC、脅威モデリングの第一人者であるアダム・ショスタック氏が連携し、医療機器エコシステムを通して脅威モデリングに関する知識と理解を向上させるために実施した脅威モデリングブートキャンプの知見に基づいて開発されたものである。

プレイブックでは、「脅威モデリング」について、セキュリティ及びプライバシーの特性に関する懸念に焦点を当てたシステム表現の分析だとしている。ハイレベルでみると、脅威モデリングを行う際に、以下の4つの設問に答えることが必要だとしている。

設問1. 我々は何に関する作業を行っているのか？

設問2: 何が悪い結果をもたらし得るか?

設問3: 我々はそれに関して何をしているか？

設問4: 我々はよい仕事をしたか?

そして、各ステークホルダーが以下に挙げるような活動を行う際に、プレイブックを役立てることができるとしている。

  • 製品ラインマネージャーが、脅威モデリングを既存のプロセスに適合させる方法を理解する
  • システムエンジニアが、脅威モデリングを設計要求事項の中で周知する方法を理解する
  • 設計エンジニアやアーキテクトが、脅威モデリングを設計上の選択に周知する方法を理解する
  • 設計検証／妥当性確認(V＆V)エンジニアが、設計テスト戦略に脅威モデルを利用する方法を理解する
  • 規制専門家が、脅威モデルを表現し、文書化する方法を理解する
  • 脅威モデリングの経験がない可能性がある外部委託先製造業者やコンサルタントと契約する

プレイブックでは、脅威モデリングを実行する時、システムにどんな問題が起こり得るかを認識し始めることになるとしている。また、システムのライフサイクルにおける早期段階か、それとも全体を通してかどうかなど、低減策を必要とするような設計・実装時の課題を指摘することを可能にする。脅威モデルのアウトプットは、脅威として知られており、あとに続く設計、開発、検証、実装後フェーズにおいて行う可能性がある意思決定に必要な情報を提供するものとなる。

なお、「医療機器脅威モデリングプレイブック」は、以下のような構成になっている。

  1. イントロダクション

1.1. プレイブックの開発

1.2. プレイブックの利用

  1. 脅威モデリングの概要

2.1. 架空の事例1: 脳卒中向け足関節モニター予測機器(AMPS)

2.2. 4つの設問(概要)

2.3. 設問1. 我々は何に関する作業を行っているのか？

2.3.1. データフローダイアグラムによる構造化モデリング

2.3.2. スイムレーン図と状態遷移図による構造化モデリング

2.3.3. 多重モデリング手法の活用

2.3.4. 次の段階に移行する時を知るためのティップス

2.4. 設問2: 何が悪い結果をもたらし得るか?

2.4.1. STRIDEによる脅威の特定

2.4.2. (事例) STRIDEのAMPSシステムへの適用

2.4.3. アタックツリーによる脅威の特定

2.4.4. キルチェーンとサイバー攻撃ライフサイクルによる脅威の特定

2.4.5. ATT&CKフレームワーク

2.4.6. 想定と結果の文書化のためのティップス

2.5. 設問3: 我々はそれに関して何をしているか？

2.5.1. 除去のアプローチ

2.5.2. 低減のアプローチ

2.5.3. 受容のアプローチ

2.5.4. 転嫁のアプローチ

2.5.5. リスク低減戦略のトラッキング、文書化、評価

2.5.6. 脅威からのリスクの決定と順位付け

2.6. 設問4: 我々はよい仕事をしたか?

2.6.1. “よい仕事”向けのフィードバック・ソース

2.6.2. 文書化における”よい仕事”の評価向けのチェックリスト

  1. 脅威モデリング実装のための考慮事項

3.1. 脅威モデリングと製品安全リスク管理(品質システム)

3.1.1. 脅威モデリングとサイバーセキュリティリスクモデリング

3.1.2. 脅威モデリングのセキュリティリスク評価へのマッピング

3.2. 組織の採用

3.2.1. 組織的アプローチ

3.2.2. 課題と現行のプラクティス

  1. 要約

附表A. 追加的な架空の医療機器事例

A.1.1. 架空事例2: 脳卒中向け神経情動撮影システム(SNAP)

A.1.2. 架空事例3: 脳卒中向け足関節・つま先運動エクササイズ機器(SKATE)

附表B. 架空の医療機器事例からの追加的考慮事項

附表C. 参考文献

プレイブックでは、データフローダイアグラム(DFD)、スイムレーン図、状態遷移図、STRIDE (S:なりすまし、T: 改ざん、R:否認、I:情報漏えい、D:サービス拒否、E:権限昇格）、キルチェーンといった脅威分析手法を医療機器セキュリティの領域に適用している。

また、「3. 脅威モデリング実装のための考慮事項」では、「ISO 14971:2019(JIS T 14971:2020) 医療機器 – リスクマネジメントの医療機器への適用」に準拠しながら、脅威モデリングを製品安全リスクマネジメントプロセスに統合する方法に焦点を当てている。ここでは、危険および危険な状態の特定に基づいて、医療機器の安全性のリスクを評価するためのプロセスや、害をもたらす可能性がある一連のイベントを定義している。個々の危険な状態は、危険の重大度と危険が発生する確率の組合せで推定される。サイバーセキュリティのリスク評価も似ているが、必ずしも同じではない。サイバーセキュリティリスクが害をもたらす確率や可能性を推定することは困難であり、悪意のあるアクターの評価ができないために、誤った方向に導かれる可能性がある。

このような状況下で、脅威モデリングは、医療機器およびそれが稼働するネットワーク化された臨床環境に対するサイバーセキュリティ脆弱性や弱点、脅威をシステマチックに特定する有益なアプローチを提供する。また、脅威モデリングは、悪用の可能性、そして順番に緊急の必要性を評価するのに役立つ。製造業者は、機器のリスク管理全体へのインプットとして、脅威モデルを利用することができる。たとえば、サイバーセキュリティリスクを特定し、これらのリスクを制御するための最善のアプローチを決定し、リスクが安全上の懸念を示す可能性がある時を決定し、セキュリティや安全性の制御によってもたらされる潜在的リスクを評価することが可能である。

「AAMI TIR57: 医療機器サイバーセキュリティの原則 – リスクマネジメント」および米国医療・公衆衛生セクター調整委員会(HSCC)・共同サイバーセキュリティワーキンググループの「医療機器・医療IT共同セキュリティ計画(JSP)」の双方とも、サイバーセキュリティリスク管理とリスク評価向けに、ISO 14971リスクマネジメント原則適用のためのフレームワークを推奨している。一般的に、リスク管理プロセスは、リスク分析から始まり、リスク評価が続いて、必要があれば、制御対策を実装する。このプロセスで重要なのは、リスク制御対策が、新たなリスク源をもたらさないよう保証することだとしている。その他のリスク管理プロセスには、設計要求事項のバリデーション・検証と、市販後モニタリングが含まれる。

加えて、「附表B. 架空の医療機器事例からの追加的考慮事項」では、以下のような考慮事項を挙げている。

  • 故障モードは、必ずしも直ちに表面化するとは限らない
  • サイレントリスクの転嫁を回避する
  • 外部主体との間で確立されたコネクションに細心の注意を払う
  • クラウドは、必ずしも排他的に外部主体であるとは限らない
  • 重要なデータフローをエンドツーエンドで特定し、文書化する
  • セキュリティ制御が最も効果的に実装された可能性のある信頼境界に焦点を当てる
  • すべての特定された脅威が文書化されていることを保証する
  • 脅威に取組むための戦略の強さを過大評価しない
  • 脅威モデリングプロセスの脅威モデル
  • すべてのモデルが誤っていても、中には有益なモデルがあることを忘れてはならない

専門チームによるクラウド固有の考慮事項に配慮した脅威モデリングが必要

クラウド環境の脅威モデリングに関連して、CSAのトップスレッドワーキンググループは、2021年7月29日、「クラウド脅威モデリング」(原文: https://cloudsecurityalliance.org/artifacts/cloud-threat-modeling/、日本語版: https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/10/Cloud-Threat-Modeling_J.pdf)を公開している。本文書は、クラウドのアプリケーション、サービス、およびセキュリティに関する意思決定において、脅威モデリングを可能にし、推奨することを目的としており、以下のような構成になっている。

  • はじめに
  • 目的
  • 想定読者
  • 主な論点
  • 脅威モデリング
  • 脅威モデリングの目的：
  • コアとなる脅威モデリングの取り組み：
  • クラウド脅威モデリング
  • クラウド脅威モデリングの目的は、非クラウド脅威モデリングとは異なりますか？
  • クラウド脅威モデリングプロセス
  • クラウド脅威モデルの作成
  • どのようにしてゼロから始めるか
  • クラウド脅威モデルリファレンス
  • おわりに
  • 付録1：脅威モデリングレポート作成に関する詳細なガイダンス
  • 付録2: クラウド脅威モデリングカード

クラウド環境の脅威モデリングでも、オンプレミス環境時と同様の手法を利用するが、以下のようなクラウド固有の考慮事項に配慮する必要があるとしている。

  • 範囲: クラウドのシステムやサービスの脅威モデリングの範囲に関する考慮事項として、アイデンティティ管理、クラウドサービス構成、さらには基盤となるクラウドアカウントについて考慮する
  • 資産: データ、主要なシステムコンポーネント、金銭的な価値のある機器、及びアイデンティティに加えて、クラウドアカウント、SaaS サブスクリプション、サービスといった新しい資産も導入されている
  • 脅威: クラウドシステム、アプリケーション、および環境に対する脅威に加えて、インスタンスメタデータサービスやクロスアカウント IAM アクセスフェデレーションなどの新技術が登場しており、様々な攻撃がそれらに対して実行可能である
  • 実施されるコントロール: クラウドのシステムやサービスは、組み込まれたコントロールの恩恵を受けるが、クラウドサービスプロバイダー(CSP)に組み込まれている場合もあれば、CSP の責任範囲から外れている場合もある
  • 格付け: クラウドを範囲内にするかどうかに関係なく、重大度による脅威の格付けは必要であり、同じ考慮事項が適用される(システムが特定の脅威に対してどれほど脆弱であるか、どの資産が影響を受けるか、そしてどの程度か。クラウドアカウント、システム、およびサービス品質によって、クラウドにおいて本質的に深刻な脅威もあれば、そうでないものもある)
  • 提案される緩和策: 異なる脅威にさらされていることから、クラウドのシステムやアプリケーションによって大きく異なり、特定のクラウドシステムやアカウントでしか利用・適用できない対策(例. AWS アカウントのサービスコントロールポリシー)や、新しい独自技術(例.メタデータサービス保護、CSPM5）も考慮に入れる必要がある

クラウド脅威モデリングの成果物やアウトプットは、オンプレミス環境の場合と同様であり、以下のようなものがある。

  1.  脅威モデル(Excel シートまたはツリー型マッピングなどのビジュアルモデルを介して提示される)
  2.  優先順位がランク付けされた緩和コントロール
  3. セキュリティとデザイン上の決定、またはより明確かつ詳細な実施項目

クラウド脅威モデルの構築に関しては、システムの全体的なアーキテクチャ、コンポーネント／サービス、インフラストラクチャ、ビジネス状況の理解と、対象システムまたは設計に関連する敵対的な視点を有するセキュリティとクラウドの専門人材から構成されるチームが、責任を持つべきだとしている。

クラウドを利用した医療機器やロボット支援手術システム、SaMD(Software as a Medical Device)などの脅威モデリングにおいても、同様のことが当てはまるが、日本国内の研究開発や臨床開発の現場では、それに必要な人材や経験、知見が圧倒的に不足している。

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