ロボット支援手術(RAS)システムの脅威モデリング～医療ロボットから自動車への横展開～

Cloud Security Alliance
Health Information Management WG
Seattle, WA, USA
ロボット支援手術(RAS)システムの
脅威モデリング
～医療ロボットから自動車への横展開～
(2023年9月19日)

2
CSA関西支部／健康医療情報管理WGの2023-2024年活動計画
2023年6月ブログ 1. ゲノムデータのサイバーセキュリティとアクセス制御
2023年7月勉強会 1. ゲノムデータのサイバーセキュリティとアクセス制御
2023年8月ブログ 2. ロボット支援手術(RAS)システムの脅威モデリング
2023年9月勉強会 2. ロボット支援手術(RAS)システムの脅威モデリング
2023年10月ブログ 3. ゼロトラストアーキテクチャにおける医療機器開発とSBOM
2023年11月勉強会 3. ゼロトラストアーキテクチャにおける医療機器開発とSBOM
2023年12月ブログ 4. 医療／ライフサイエンスにおけるデータ損失防止(DLP)
2024年1月勉強会 4. 医療／ライフサイエンスにおけるデータ損失防止(DLP)
2024年2月ブログ 5. 医療／ライフサイエンスにおけるハードウェア対応型セキュリティ
2024年3月勉強会 5. 医療／ライフサイエンスにおけるハードウェア対応型セキュリティ
2024年4月ブログ 6. 医療／ライフサイエンスにおけるDevSecOps
2024年5月勉強会 6. 医療／ライフサイエンスにおけるDevSecOps

AGENDA
1. MITRE／医療機器イノベーションコンソーシアム
(MDIC)
「医療機器脅威モデリングプレイブック」
2. Cloud Security Alliance
「遠隔手術机上演習ガイドブック」
3. Automotive Cloud
4. Q&A／ディスカッション

4
1. MITRE／医療機器イノベーションコンソーシアム
(MDIC)
「医療機器脅威モデリングプレイブック」(2021年11月
30日)
(https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices)
• 医療機器エコシステムを通して脅威モデリングに関する知識
と理解を向上させるために実施した脅威モデリングブート
キャンプの知見に
基づいてプレイブックを開発する
・「脅威モデリング」＝セキュリティ及びプライバシーの特性に関す
る懸念に焦点を当てたシステム表現の分析
・脅威モデリングを行う際の設問:
設問1. 我々は何に関する作業を行っているのか？
設問2: 何が悪い結果をもたらし得るか?
設問3: 我々はそれに関して何をしているか？
設問4: 我々はよい仕事をしたか?

5
プレイブックの構成
1. イントロダクション
1.1. プレイブックの開発
1.2. プレイブックの利用
2. 脅威モデリングの概要
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.6. 設問4: 我々はよい仕事をしたか?
2.6.1. "よい仕事"向けのフィードバック・ソース
2.6.2. 文書化における"よい仕事"の評価向けのチェック
リスト
3. 脅威モデリング実装のための考慮事項
3.1. 脅威モデリングと製品安全リスク管理(品質システム)
3.1.1. 脅威モデリングとサイバーセキュリティリスクモ
デリング
3.1.2. 脅威モデリングのセキュリティリスク評価への
マッピング
3.2. 組織の採用
3.2.1. 組織的アプローチ
3.2.2. 課題と現行のプラクティス
4. 要約
附表A. 追加的な架空の医療機器事例
A.1.1. 架空事例2: 脳卒中向け神経情動撮影システム(SNAP)
A.1.2. 架空事例3: 脳卒中向け足関節・つま先運動エクササイ
ズ
機器(SKATE)
附表B. 架空の医療機器事例からの追加的考慮事項
附表C. 参考文献

6
架空の事例1: 脳卒中向け足関節モニター予測機器(AMPS)
• 脳卒中向け足関節モニター予測機器(AMPS):
• 脳卒中のリスクがあると考えられる患者が夜間に装着する家庭用医療機器
• AMPSシステムは、医療専門家が後で分析できる医学的測定値を収集する
• システムは、患者が脳卒中を経験するリスクを予測するのに役立つが、脳卒中
が差し迫っているまたは発生しているかについて、警告を発することを意図し
たものではない
• 想定使用期間:1～3ヶ月
• 医療的ケーパビリティ: 診断のみ
• 機器の侵襲性: 低 (腕時計のように、容易に除去可能)
• AMPSのコアユースケース：
アリスは、医師から、家族の履歴およびその他複数のリスク要因に基づいて、
脳卒中を経験するリスクが増大していると告げられた。さらなる洞察を得て治
療計画を決定するために、医師は、AMPSを家庭に設置し、寝る時に読み取れ
るよう装着することを勧めた。また、AMPSシステムに(Bluetooth経由で)接
続されたスマートフォンに、コンパニオンアプリケーションをインストールし、
読み取り値を毎日AMPSクラウドサービスにアップロードするよう指示された

7
• AMPSのコア技術：
• 患者から生理学的評価を行うBLE(Bluetooth Low Energy)対応型
足首モニター
• 読み取り値を表示し、クラウドサービスと通信する足首モニターと対に
なった患者向けスマートフォン／タブレットアプリケーション
• AMPSCS：脳卒中クラウドサービスの足首モニター予測器
• AMPSのデバイス：
AMPSは、患者が休んでいる時足首に装着する健康モニタリングシステム
• 患者アプリケーション：
Apple iOS対応型、Android対応型の2種類のバージョンのアプリケーションが
ある（機能は同じ）
• AMPSクラウドサービス：
AMPSCSは、クラウドインフラストラクチャ上にホスティングされた仮想マシ
ンの集合体

8
2. Cloud Security Alliance
「遠隔手術机上演習ガイドブック」(2023年1月30日発
行)
(https://cloudsecurityalliance.org/artifacts/telesurgery-tabletop-guide-book/)
• 目的: 医療機関が、ロボット支援手術(RAS)を標的にした
セキュリティインシデントへの対応活動手順書に関する議
論や
評価を計画し、促進する際に支援する
• MITRE Attack Flowに準拠したCSA’s
GitHub for IoT Medical Cloudを参照
• 対象: 医療提供組織(HDO)のサイバー
セキュリティ実務担当者および臨床責任者
• HDOのインシデント対応を支援する医療機器
出典：Cloud Security Alliance(CSA) 「Telesurgery Tabletop Guide Book」(2023年1月30日)

9
ガイドブックの構成
・謝辞
・イントロダクション
・RASシステムのアーキテクチャ
・外科医コンソール
・ロボットプラットフォーム
・クラウドサービス
・電子健康記録
・目的
・対象読者
・概要
・演習計画策定チーム
・概念と目標のミーティング
・初期計画策定ミーティング
・考慮のための演習フォーマット
・演習設計
・インプットのカテゴリー
・シナリオ
・シナリオの開発
・シナリオ事例
・状況付与
・制約
・知識チェック
・演習フロー
・シナリオ事例
・頭字語
・参考文献

10
RASシステムアーキテクチャ
出典：Cloud Security
Alliance(CSA)
「Telesurgery Tabletop
Guide Book」
(2023年1月30日)
(https://cloudsecurityallian
ce.org/artifacts/telesurger
y-tabletop-guide-book/)
ベン
ダー
遠隔管理
ベンダー責任者
電子健康記録(EHR)
クラウドサービ
ス
生物医学技師
外科医コンソール
アーム制
御
複合現実
GUI
音声
外科医
手術環境の監視
遠隔手術の監
視
デジタルツイ
ンの
維持
バイオヘルス
データの監視
シミュレー
ション
機械学習(ML)
ベースの分析
補助者
患者
手術環境
ロボットシステ
ム
患者記録
データベース
ロボット
アーム
ネットワーク
コンポーネン
ト
カメラ、環境セン
サー、バイオセン
サー
3D可視化

11
ロボットプラットフォーム
バイオセンサー
・ロボットプラットフォームのコンポーネント: 外科医によって命令
された動作を実行するロボットアーム
・ロボットアームは、テレメトリーデータを外科医コンソールとクラ
ウドに転送する
・触覚のフィードバックが、ロボットプラットフォームの位置に基づ
いて生成され、外科医コンソールに提供される
・外科医およびその他の医療専門家が、様々なバイオセンサーデータ
(血圧、脳波(EEG)、筋電図(EMG)、体温など)をリアルタイムで監視
する

12
ネットワークコンポーネント
クラウドサービス
・ネットワークコンポーネントは、外科医コンソールとロボットプ
ラットフォームを
接続するだけでなく、クラウドサービスへの接続性を提供するために
利用される。
・外科医コンソールとロボットプラットフォームの間の接続性は、
イーサネット
経由で配線された可能性がある。
・様々なコンポーネントを越えた接続性は、帯域幅と低レンテンシー
を提供する5Gセルラーリンクを通して実現される。
・テレメトリーデータ・ストレージと監視
・バイオヘルスデータ・ストレージと監視
・ロボットプラットフォームのデジタルツイン構成
・ロボットプラットフォームの3D可視化
・機械学習のサポート
・シミュレーションサービス
・遠隔管理

13
電子健康記録(EHR)
・電子健康記録(EHR)は、遠隔手術イベントにリンクしている可能性
がある。この接続は、EHRベンダーのクラウドとロボットSaaSサー
ビスの間のリンクなど、複数のメカニズムを介している。

14
机上演習(TTX)の主要フェーズと成果物
出典：Cloud Security Alliance(CSA) 「Telesurgery Tabletop Guide Book」(2023年1月30日)
計画前演習計画と準備演習設計演習の実行
成果物計画策定チーム(EPT) 演習の目標、スコープ、
責任者、責任、シナリオ、
要求事項、タイムライン
演習のスクリプトと
概要
机上演習の報告書、
推奨事項と改善の責任
-異なるロールで定義さ
れたシナリオの実行
-ラップアップと学んだ
教訓
-次のステップと責任
-シナリオの開発
-参加者のロール
-情報の注入
-制約
-知識の確認
-概念と目標のミーティ
ング
-初期計画策定
-スポンサーシップの獲得と
トップマネジメントの関与
-演習計画策定チームの定義
-ステークホルダーを関与させた
計画

15
演習設計: シナリオ1
• AF-13 ローカルWiFiルータに対する
サービス拒否(DoS)攻撃
• 外科医が、カリフォルニアの事業所からRAS
を利用して、低侵襲手術を行っている。ロ
ボットプラットフォーム、患者、支援スタッ
フは、フロリダ州フォートマイヤーズに位置
している。手術を実行している間に、コン
ソールとロボットアームの接続が失われる。
障害対応や電話の後、ITスタッフは、外科医
に対して、手術が行われていた手術室が、
DoS攻撃により、遠隔でアクセスできなく
なったことを告知する。
出典：CSA’s GitHub for IoT Medical Cloud「AF-13 DoS Against Local Wi-Fi Router」
(https://github.com/cloudsecurityalliance/IoT-Medical-
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF-
13%20DoS%20Against%20Local%20Wi-Fi%20Router)

16
• AF-10 遠隔サイトからクラウドへの転送中の
バイオセンサーデータの改ざん
• 外科医が、患者とオンサイトに
いながら、ロボット支援手術
システムを利用した手順を
行っている。
外科医の補助者は、患者の
バイオヘルスデータの異常を
通知する。外科医の補助者は、
センサーの読み取り値が不正確な
可能性があると通知する。
出典：CSA’s GitHub for IoT Medical Cloud「AF2-10 Modify Bio-Sensor Data」
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20Sensor%20Readings/AF2-10%20Modify%20Bio-Sensor%20Data)

17
• AF-3 破損したファームウェアをロ
ボット
システムにロードする(ファームウェ
アの
デバイスへの不正なロード)
• 技師が、外科手術のためにRASを準備する。
デバイスは反応しない。調査を通して、デバ
イス
が、最近、計画していないアップデートを受
けた
ことが特定される。アップデートは、不正な
アク
出典：CSA’s GitHub for IoT Medical Cloud「AF-3 Compromise of Management System on the Network」
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20Against%20Administrative%20Functions/AF2-
3%20Compromise%20Management%20System)

18
AF-12 手術中のロボットシステム
の変更状態(例.診断モードの変更状態)
• 外科医がRASサポート手術を行っている。
外科医は、ロボットのアームが入力コマンド
に反応しないことを通知した。技師はロボット
のプラットフォームが、手術中に状態を変更
して、新たなファームウェアのアップロードが
可能になっていたことを特定した。調査を
通じて、SaaSベースのベンダー管理インタ
フェースが侵害され、認証済ベンダーの管理
コマンドが転送されていることを特定した。
出典：CSA’s GitHub for IoT Medical Cloud「AF2-12 Vendor」
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20Against%20Administrative%20Functions/AF2-12%20Vendor%20Access)

19
AF-7 ロボットシステムのランサムウェア感染
• 技師が、外科手術のために、RASの準備をして
いる。準備中、機器が突然停止した。機器が
ランサムウェアに感染したという表示が出た。
外科手術は、ランサムウェアから修復するまで
実行できない。
出典：CSA’s GitHub for IoT Medical Cloud 「AF2-7 Ransomware」
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF2-7%20Ransomware)

20
AF-1 破損したファームウェアのロボット
システムへのロード(正当なステージ
サイトで破損したファームウェア)
• 技師が、ロボット支援手術システムの
日常的な維持を行っている。技師は、
機器上のファームウェアのアップデートを
開始した。ファームウェアのアップデート
完了後直ちに、機器は反応しなくなり
(例.RASがコマンドに反応しない)、もはや
稼働していない。技師は、ファームウェアの
アップデートが破損したと信じている。
出典：CSA’s GitHub for IoT Medical Cloud 「AF2-1 Corrupt Firmware DoS」
Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF2-1%20Corrupt%20Firmware%20DoS)

21
演習フロー(1)
• シナリオ事例: シナリオ4 AF-12 手術中のロボットシステムの変更
状態
・手術チームが手術安全チェックリストおよび機器チェックを調べ終
え、麻酔科医に対して冠動脈バイパス手順のために患者に麻酔をかけ
始めるよう指示を出したのは、火曜日の午前9時半だった。その数分
後、麻酔科医は指示を
出した。それからチームは、患者に挿管し、人工心肺装置など、その
他必要な生命維持対策に装着する。手術ロボットを利用して、外科医
は、患者の右肺と、患者の右冠動脈をバイパスするために利用される
ハーベストの血管を成功裏に開いた。ハーベストされた血管が大動脈
に取り付けるプロセスにあった時突然、外科医は、手術ロボットが指
示に従わず反応しないことを通知する。
ロボット手術技師により、問題に対するトラブルシューティングを行
おうという
最初の試みがあり、手術ロボットに、一時的に機器が使用できない状
態にするようなファームウェアのアップデートがあったようだという

22
演習フロー(2)
• 考慮すべき質問
1. 直ちに取組むべき必要がある患者安全の課題は何か?
2. 手術ロボットを稼働させるためにすべき追加的試みはあるか、また患者の胸
部が開かれ、手術はマニュアルで完了するか?
3. 手術チームの誰かが、この課題を生体医学またはその他の内部病院部門に報
告するか、また手術が完了し患者が安定するまで、これが延期されるか?
4. この時点で誰かが、情報セキュリティ課題を考えているか、またこれは機器
の故障だと想定するか?
5. この時点で誰かが、この課題が、病院内の他の機器に影響を及ぼす可能性が
あると考えているか、またこれが、孤立したインシデントだと想定するか?
6. ベンダーに対する呼び出しはこの時起きたか、また手術が完了した後まで
待っていたか?
7. この時、病院インシデントコマンドシステム(HICS)の稼働は指示されたか?

23
演習フロー(3)
• 状況付与1
・午前11時45分までに手術チームは手術を完了し、病院のITと生物
医学
部門が調査を行っている。ITは、ネットワークおよびその他の接続を
チェックし、生体医学は、機器の構成をチェックしている。ITのエン
ドに問題を見つけることができないので、課題は機器そのものにある
と想定され、生体医学チームは、製造業者を呼んで、異常に長い保持
時間を提示する。生体医学チームが、
製造業者の支援を引き出そうと試みている間、結腸がんの処置を受け
る患者がいる隣の手術室にある手術ロボットも、故障し始めている。
その行動は、
要求されていないファームウェアのアップデートが機器に発生して、
いかなる
外科医の指令にも反応しなくなるという点で、右冠動脈バイパスの間
に観察されたのと同じである。

24
演習フロー(4)
1. この新たな患者安全の課題に対して、どのように取組むか?
2. この時点で、誰に通知するか?
3. この時点で、単なる機器の故障以上の大きい課題が始まったと考えられるか?
4. この段階で、情報セキュリティチームを呼び出すか?
5. 他の手術室におけるロボット手術は再スケジュールされるか(可能な場合)、
またはこの時点で、マニュアル手術に置き換えるか?
6. 生体医学チームは、あらゆる機器の設定やソフトウェアに対する変更を特定
するために、機器の構成を十分に文書化しているか?
7. 既知の影響を受けた手術ロボットを、インターネットおよび／または内部
ネットワーク
から分離するよう考慮するか?
8. その他のあらゆる手術ロボットを、インターネットおよび／または内部ネッ
トワークから
分離するよう考慮するか?
9. この時、病院インシデントコマンドシステム(HICS)の稼働は指示されたか?

25
演習フロー(5)
• 状況付与2
・午後3時半、生体医学チームは、最終的に、ベンダーに伝えること
ができて、そのベンダーがサイバー攻撃を受けて、機器を遠隔管理し、
顧客に技術サポートとファームウェアアップデートを供給するために
利用しているSaaSベースシステムの侵害に至ったことを発見するこ
とができた。ベンダーは、いくつかの顧客が、要求されていない
ファームウェアのアップデートを報告してきたことを認識しているが、
調査が依然としてペンディングとなっているため、詳細な情報を提供
できないと主張している。

26
演習フロー(6)
1. これらの機器に影響を及ぼす可能性があるサイバーインシデントが確認された今、(可能な場
合)、組織の侵害された手術ロボット向けインシデント対応計画は何か?
2. この新たな情報は、最後のセクションで議論された患者のリスケジューリングや、代替的な手
術アプローチに関する決定を変えるか?
3. この新たな情報は、最後のセクションで議論されたネットワークのコネクティビティに関する
決定を変えるか?
4. ランサムウェアは明らかになっていないが、その可能性と、ランサムウェア攻撃は正常な
オペレーションまで復旧するのに数週間要し得るという事実を考えると、手術ロボットが利用
できない複数週の長い期間、患者ケアや、病院のオペレーション、病院の財務などに、どのよ
うな影響を及ぼすか?
5. 攻撃者が病院のネットワークにアクセスしたり、攻撃者がネットワーク上の他システムを攻撃
したりするための足がかりを提供するための手段として、要求されていないソフトウェアの
アップデートが活用されたか否かについて、病院はどのように判断するか?
6. 同一ベンダーが生産または管理する可能性のある、病院ネットワーク上の他の機器をリスト化
した在庫管理が、病院にあるか?
7. 同一ベンダーが製造したその他の機器は、どのようにして、潜在的侵害について評価可能か?
8. このSaaSプラットフォームに保存された保護対象保健情報(PHI)または機密情報はあるか?
9. この時点で、ベンダーに対して、どんな質問をすべきか?
10. 医療提供組織(HDO)は、このインシデントを報告すべきか?

27
演習フロー(7)
• 状況付与3
・3日後、医療提供組織(HDO)は、ベンダーから、インシデント前の
状態にSaaSベースの管理プラットフォームを完全復旧できるまで数
週間かかること、そして、HDOは、システムが完全復旧するまでの
間、ネットワークインタフェースカード(NIC)を切断しなければなら
ないことを通知される。今後2週間以上の間に、技師がHDOに派遣さ
れ、すべての手術ロボット上のファームウェアを製造業者が承認した
最新バージョンに戻して機能を復旧するという。手術の再スケジュー
リングがメディアによって告知され始め、記者がHDOに質問し始め
ている。セキュリティ侵害インジケーター(IOC)と、戦術・技術・手
順(TTP)の初期リストが、ベンダーからHDOに提供される。

28
演習フロー(8)
1. 記者へのメッセージは、インシデントに関して、どのように処理されるか?
2. 患者のインシデントに関する不満およびそのサービスへの影響は、どのよう
に処理されるか?
3. 環境をチェックするために、セキュリティ侵害インジケーター(IOC)のリス
トを、どのように有効活用することができるか?
4. 環境をチェックするために、戦術・技術・手順(TTP)を、どのように活用す
ることができるか?
5. 追加的な検知および／または制御が必要になる可能性があるか否かをチェッ
クするために、戦術・技術・手順(TTP)を、どのように利用することができ
るか?

29
演習フロー(9)
• 状況付与4
・さらに3週間後、ベンダーおよびHDOのオペレーションは正常に戻
る。
1. このような課題を低減して前に進むために、どんなことができるか?
2. 手術ロボットベンダーは、サードパーティベンダーリスク管理プロセスを乗
り越えたか?
3. RASベンダーとの契約には、適切なサービスレベルアグリーメント(SLA)と、
セキュリティ課題に関する報告があるか?
4. 追加的な制御がもし必要な場合、医療提供組織(HD)は、何の実装を考慮する
か?

Project Scope
• 自動車クラウドサービスに合わせて、特別な損失シ
ナリオにマッピングした攻撃パス／ツリーのライブ
ラリ
• ISO/SAE Work Product (WP)-15-05に適合した脅
威分析およびリスク評価プロセスで要求されるイン
プットと一貫した攻撃パス
• MITRE attack flowに適合した攻撃シミュレーショ
ンにおける潜在的利用のための機械判読可能な
フォーマットで開発された攻撃パス
• 攻撃パス分析の脅威分析およびリスク評価パッケー
ジへの統合
• (1)既存の功績のレビューと(2)理論的功績に基づい
て開発された攻撃パス

Member Recruitment
• 自動車産業のメンバー
• OEMs
• Tier 1 サプライヤー
• 自動車クラウドのSaaS ベンダー

Define Representative Automotive Cloud
Architecture
• 汎用的なコンポーネント
• 汎用的なインタフェース
• データのタイプ
• アクター
• プロセス
最終結果が提供する自動車クラウド
への理解の共有
- attack flowのモデリングのサ
ポート
Example: High Level RAS System Architecture
Source: CSA IoTWG TeleSurgery Guide Book

34
• 4. Q&A／ディスカッショ
ン

ロボット支援手術(RAS)システムの脅威モデリング～医療ロボットから自動車への横展開～

Recommended

Recommended

More Related Content

Similar to ロボット支援手術(RAS)システムの脅威モデリング～医療ロボットから自動車への横展開～

Similar to ロボット支援手術(RAS)システムの脅威モデリング～医療ロボットから自動車への横展開～ (20)

More from Eiji Sasahara, Ph.D., MBA 笹原英司

More from Eiji Sasahara, Ph.D., MBA 笹原英司 (20)