2023年1月30日、クラウドセキュリティアライアンス（CSA）のIoTワーキンググループ／健康医療情報管理ワーキンググループ／クラウドインシデント対応ワーキンググループは、「遠隔手術机上演習ガイドブック」(https://cloudsecurityalliance.org/artifacts/telesurgery-tabletop-guide-book/)を公開した。後編では、本ガイドブックを作成するに至った背景や、具体的内容について概説する。
遠隔手術机上演習ガイドブックを支えるMITRE Attack Flow
CSAのガイドブックは、MITRE Attack Flowに準拠して策定されている。ここでは、本題に入る前に、MITRE Attack Flowの概要を説明する。
MITRE Attack Flowは、敵対的行為の順序を記述するために、支援ツールと事例を持ったデータモデルである。このモデルは、防御者が、サイバー攻撃における行為の順序に基づいて、脅威に通じた意思決定に関して理解し、共有し、実行する際に支援するものである。Attack Flowは、敵対者の行為における共通のパターンを特定するために分析することが可能であり、ATT&CK Navigatorのレイヤー上に重ね合わせて、防御範囲を理解し、インテリジェンス駆動型の敵対者エミュレーション計画の基盤構築につながるものである。
Attack Flowは、以下の3つから構成される。
- 課題(Problem): 防御者は、その時の一つの特定行為に焦点を当てて、微小に敵対者の行為を追跡することがある。これにより、敵対者の攻撃を理解し、これらの攻撃に対する効果的な防御を構築することが困難になる。
- 解決策(Solution): ATT&CK手法のフローを記述し、これらのフローを行動のパターンに結びつけるために、言語および関連するツールを構築する。
- 影響(Impact): 防御者やリーダーが、敵対者が微小な手法を攻撃の中で操作し、構築する方法を理解し、防御的なポスチャーの理解を向上させるのに役立てる
そして、Attack Flowは、脅威インテリジェンス、防御ポスチャー、エグゼクティブコミュニケーション、インシデント対応、敵対者エミュレーション、脅威ハンティングなど、様々な種類のユースケースをサポートするように設計されている。
なお、MITRE Attack Flowに関する詳細情報は、GitHub上に公開されており(https://github.com/center-for-threat-informed-defense/attack-flow）、現時点の最新版は、「Attack Flow v2.1.0」となっている（https://center-for-threat-informed-defense.github.io/attack-flow/）。
RASシステムに対する攻撃フローを整理したGitHub for IoT Medical Cloud
CSAは、MITRE Attack Flowに準拠して、RASシステムに対する攻撃フローのシナリオを「GitHub for IoT Medical Cloud」(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud)上に公開し、これをベースにしながら、机上演習ガイドブックを策定した。
「GitHub for IoT Medical Cloud」は、以下のようなアクターを想定している。
- A1 患者 (処置を受ける患者。患者の状態の変更は、プロセスフローの修正を求める可能性がある)
- A2 外科医 (ロボット機器の手術の指示および監視に責任がある)
- A3 技師 (システムの技術的運用を監視し、迅速に技術に関連する課題を特定する責任がある)
- A4 外科医の補助者 (ベッドサイドで、外科医のために、ローカルの目や耳として機能する)
- A5 ベンダーの責任者(構成のアップデートまたは遠隔によるトラブルシューティングのために、仮想プライベートネットワーク(VPN)トンネルを利用して機器にログインする権限を持っている可能性がある)
- A6 生物医学スタッフ(ロボットプラットフォームの適正な運用の保証に責任がある、医療技術管理(HTM)責任者)
また、RASシステムを構成するコンポーネントとして、以下のような資産を想定している。
- C1 外科医コンソール
通常、外科医コンソールには、手術を実行する外科医が必要とするケーパビリティや機能が含まれる。
- C1.1 複合現実(MR)グラス(外科医コンソールに統合される)
- C1.2 ハプティックデバイス(外科医コンソールに統合される)
- C1.3 3Dビデオディスプレイ(外科医コンソールに統合される)
- C1.4 音声スピーカー(外科医コンソールに統合される)
- C1.5 マイクロフォン(外科医コンソールに統合される)
- C1.6 フットペダル(外科医コンソールに統合される)
- C2 ロボットプラットフォーム
ロボットプラットフォームは、大規模なコンポーネントセット内に取り囲まれる可能性がある。ロボットプラットフォームには、外科医が司令した通りの行動を実行するロボットアームが含まれる。ロボットアームは、テレメトリーデータを外科医コンソールおよびクラウドに転送する。ハプティックのフィードバックは、ロボットプラットフォームの位置に基づいて生成され、外科医コンソールに供給される可能性がある。
- C2.1 ロボットアーム
- C2.2 ロボットのテレメトリー・トランスミッター
- C3 クラウドサービス
クラウドサービスは、多くのケーパビリティを提供する可能性がある。実際に提供されるサービスは、ベンダーおよび個々の製品提供による。クラウドで提供されるサービスの例には以下のようなものがある。
- テレメトリーデータのストレージと監視
- バイオヘルスデータのストレージと監視
- ロボットプラットフォームのデジタルツイン構成
- ロボットプラットフォームの3D可視化
- 機械学習のサポート
- シミュレーションサービス
- 遠隔管理
ロボットアームからクラウドへ転送されるテレメトリーデータは、手術の速度、ロボットアームの速度や強さを含む可能性がある。バイオヘルスデータは、温度、血圧、脳波(EEG)、心拍数、呼吸数、表面筋電位(EMG) を含む可能性がある。デジタルツイン構成データは、ロボットアームの位置を含む可能性がある。これには、3D可視化機能を告知することができる角度および直線位置が含まれる可能性がある。
- C4 電子健康記録(EHR)データベース
- C5 スイッチ
- C6 ルーター
- C7 5G アンテナ
- C8 Wi-Fi ルーター
- C9 体温バイオセンサー(体温を測定する)
- C10 心電図(ECG)バイオセンサー(心電図センサー、心臓の電気的活動を測定する)
- C11 表面筋電位(EMG)バイオセンサー(表面筋電位センサー、筋肉の電気的活動を測定する)
- C12 血圧バイセンサー(血圧を測定する)
- C13 心拍数バイオセンサー(心拍数を測定する)
- C14 呼吸数バイオセンサー
- C15 複合現実サーバー
さらに、RASシステムに対する攻撃フローについては、以下のような分類で整理している。
- 管理機能に対する攻撃
- 患者データとプライバシーに対する攻撃
- インシデント対応プロセスに対する攻撃
- コマンドアンドコントロールに関する攻撃
- デバイス、ファームウェア、構成に関する攻撃
- センサーの読み取り値に関する攻撃
- システムの可用性に関する攻撃
上記の各項目に格納した攻撃フローのシナリオを活用して、インシデント対応計画向けの机上演習教材にまとめたのが、「遠隔手術机上演習ガイドブック」である。
医療機関のインシデント対応計画を支援する机上演習ガイドブック
CSAのガイドブックは、医療機関が、ロボット支援手術(RAS)を標的にしたセキュリティインシデントへの対応活動手順書に関する議論や評価を計画し、促進する際に支援することを目的としている。対象読者は、医療提供組織(HDO)のサイバーセキュリティ実務担当者および臨床責任者であるが、HDOのインシデント対応を支援する医療機器製造業者やサービスプロバイダーにも役立つとしている。
ガイドブックの構成は以下の通りである。
・謝辞
・イントロダクション
・RASシステムのアーキテクチャ
・外科医コンソール
・ロボットプラットフォーム
・クラウドサービス
・電子健康記録
・目的
・対象読者
・概要
・演習計画策定チーム
・概念と目標のミーティング
・初期計画策定ミーティング
・考慮のための演習フォーマット
・演習設計
・インプットのカテゴリー
・シナリオ
・シナリオの開発
・シナリオ事例
・状況付与
・制約
・知識チェック
・演習フロー
・シナリオ事例
・頭字語
・参考文献
RASシステムのアーキテクチャ
RASシステムは、以下のようなコンポーネントから構成される
・ロボットプラットフォーム
・ロボットプラットフォームのコンポーネント: 外科医によって命令された動作を実行するロボットアーム
・ロボットアームは、テレメトリーデータを外科医コンソールとクラウドに転送する
・触覚のフィードバックが、ロボットプラットフォームの位置に基づいて生成され、外科医コンソールに提供される
・バイオセンサー
・外科医およびその他の医療専門家が、様々なバイオセンサーデータ(血圧、脳波(EEG)、筋電図(EMG)、体温など)をリアルタイムで監視する
・ネットワークコンポーネント
・ネットワークコンポーネントは、外科医コンソールとロボットプラットフォームを接続するだけでなく、クラウドサービスへの接続性を提供するために利用される。
・外科医コンソールとロボットプラットフォームの間の接続性は、イーサネット経由で配線された可能性がある。
・様々なコンポーネントを越えた接続性は、帯域幅と低レンテンシーを提供する5Gセルラーリンクを通して実現される。
・クラウドサービス
・テレメトリーデータ・ストレージと監視
・バイオヘルスデータ・ストレージと監視
・ロボットプラットフォームのデジタルツイン構成
・ロボットプラットフォームの3D可視化
・機械学習のサポート
・シミュレーションサービス
・遠隔管理
・電子健康記録(EHR)
・電子健康記録(EHR)は、遠隔手術イベントにリンクしている可能性がある。この接続は、EHRベンダーのクラウドとロボットSaaSサービスの間のリンクなど、複数のメカニズムを介している。
机上演習の概要
フェーズ1: 計画前
-スポンサーシップの獲得とトップマネジメントの関与
-演習計画策定チームの定義
-ステークホルダーを関与させた計画
(成果物) 計画策定チーム(EPT)
フェーズ2: 演習計画と準備
-概念と目標のミーティング
-初期計画策定
(成果物) 演習の目標、スコープ、責任者、責任、シナリオ、要求事項、タイムライン
フェーズ3: 演習設計
-シナリオの開発
-参加者のロール
-情報の注入
-制約
-知識の確認
フェーズ4: 演習の実行
-異なるロールで定義されたシナリオの実行
-ラップアップと学んだ教訓
-次のステップと責任
(成果物) 机上演習の報告書、推奨事項と改善の責任
演習計画策定チーム(EPT)
机上演習に欠かせないのが、演習計画策定チーム(EPT)である。チームは、演習開催の3ヶ月前に選定される必要がある。計画策定チームの責務には、以下のようなものがある。
・リーダーシップ／マネジメントからの賛同の獲得
・開発プロセスのガイド
・リソースの調達
・スケジューリングと調整
・演習のスコープの決定
・目標の特定
・参加者の特定
・机上演習教材の開発(例. ハンドアウト、スライド、フォーム)
そして計画策定チームは、以下のような関連する部門の代表者から構成されるべきであるとしている(ただし、チームは管理できる規模で、演習には参加しないことが前提となる)。
そして計画策定チームは、以下のような関連する部門の代表者から構成されるべきであるとしている(ただし、チームは管理できる規模で、演習には参加しないことが前提となる)。
・オーナー／マネジメント
・臨床リーダーシップ
・オペレーション
・IT／情報セキュリティ
・救急管理
・ビル・施設セキュリティ
・医師／外科医
・医療技師
・ベンダー責任者
・エンジニアリング／ファシリティ
・患者記録データベース管理者
・電子健康記録(EHR)管理者
・法務チーム
・広報チーム
・人事チーム
・患者搬送チームの主要メンバー
・自分のセクター／補助的な外科のロケーションの他メンバー
・州／地域の法執行機関
・病院インシデントコマンドシステム(HICS)の稼働に関与するその他のステークホルダー
概念と目標(C&O)のミーティング
計画策定チームを組織化したら、概念と目標(C&O)のミーティングに入る。概念と目標のミーティングは、演習の3ヶ月前に開催されるべきだとしている。このミーティングで期待される成果物には、以下のようなものがある。
・計画策定チームの確認
・コンプライアンス意味と作業のスコープ
・演習の機密性に関する議論と明確化
・演習のスコープ、タイプ、ミッション領域、演習の優先順位と目標の重要な要素に関する議論と明確化
・演習に関与するすべてのチームのコアケーパビリティに準拠した目標の保証
・演習計画策定のタイムラインとマイルストーン
・追加的な計画策定チームのメンバーへの接触と詳細な演習目標の構築を含む、次の計画策定ミーティングに先駆けて割り当てられたタスクのリスト
初期計画策定ミーティング(IPM)
概念と目標(C&O)のミーティングに続いて、初期計画策定ミーティング(IPM)が実施される。初期計画策定ミーティングでは、演習設計の要求事項、想定、シナリオ、変数、ロジスティクス、ロケーション、スケジュールの特定作業が行われる。演習の関連する詳細は、このミーティングの間、明確化され、議論されるべきである。C&OとIPMは、計画策定のタイムラインを短縮し、リソース的に面倒でなくなるようにするために、組合せることができる。このミーティングで期待される成果物には、以下のようなものがある。
・演習シナリオの設計とフォーマット化
・演習目標とコアケーパビリティの調整の最終化と明確化
・演習実行のロジスティクスとともに演習計画策定タイムラインの最終化
・すべての参加組織の取組の期待レベルの確認
・次の計画策定ミーティング前の行動アイテムと割り当てられたタスク
考慮すべき演習フォーマット
全員参加型
全員参加型フォーマットでは、参加者が、機能領域のグループ分け(例. オーナー、マネジメント、地域代表者；ファシリティセキュリティ；エンジニアリング；法執行者)をすることなく、単一グループとして組織化する。このフォーマットは、一人のファシリテーターと一人または二人の評価者／データ収集者が必要である；しかしながら、共同ファシリテーターは、単一ファシリテーターの重荷を緩和する可能性がある。一般的に、このフォーマットは、ファシリテーターおよび評価者／データ収集者の役割を充足するために、限られた人数の人々が可能な場合、25-30人の参加者が最も適している。
マルチテーブル型
マルチテーブル型では、専門分野、機関、組織、または機能領域によって組織された複数の個人テーブルがある。最初に、リードファシリテーターはシナリオを発して、すべてのプレイヤーに、ディスカッションの質問を示す。グループディスカッションは、個人のテーブルで起きて、理想的には、機能領域の専門性を持った誰かによりファシリテートされる。評価者／データ収集者が一般的なディスカッションを捉える一方、ファシリテーターが演習目標に関連した課題に取組むことに焦点を当てられるように、ファシリテーターおよび評価者／データ収集者の双方を各グループに割り当てることが望ましい。
演習設計
データのアウトプットの品質は、演習設計に依存する。ファシリテーターは、演習の品質を保証するために、確立したインプット、アウトプット、手順を持っている、確立したフレームワークに従うべきだとしている。
シナリオは、ディスカッションの基本的な要素を生成するためのハイレベルのイベントである。本ガイドブックでは、MITRE Attack Flowに準拠した「GitHub for IoT Medical Cloud」をベースに、以下の6つのシナリオを例示している。
シナリオ1: AF-13 ローカルWiFiルーターに対するサービス拒否(DoS)攻撃
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF-13%20DoS%20Against%20Local%20Wi-Fi%20Router)
・外科医が、カリフォルニアの事業所からRASを利用して、低侵襲手術を行っている。ロボットプラットフォーム、患者、支援スタッフは、フロリダ州フォートマイヤーズに位置している。手術を実行している間に、コンソールとロボットアームの接続が失われる。障害対応や電話の後、ITスタッフは、外科医に対して、手術が行われていた手術室が、DoS攻撃により、遠隔でアクセスできなくなったことを告知する。
シナリオ2: AF-10 遠隔サイトからクラウドへの転送中のバイオセンサーデータの改ざん
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20Sensor%20Readings/AF2-10%20Modify%20Bio-Sensor%20Data)
・外科医が、患者とオンサイトにいながら、ロボット支援手術システムを利用した手順を行っている。外科医の補助者は、患者のバイオヘルスデータの異常を通知する。外科医の補助者は、センサーの読み取り値が不正確な可能性があると通知する。
シナリオ3: AF-3 破損したファームウェアをロボットシステムにロードする(ファームウェアのデバイスへの不正なロード
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20Against%20Administrative%20Functions/AF2-3%20Compromise%20Management%20System)
・技師が、外科手術のためにRASを準備する。デバイスは反応しない。調査を通して、デバイスが、最近、計画していないアップデートを受けたことが特定される。アップデートは、不正なアクターにより開始され、マルウエアを含む可能性のある不正なファームウェアが含まれていたと信じられている。
シナリオ4: AF-12 手術中のロボットシステムの変更状態(例.診断モードの変更状態)
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20Against%20Administrative%20Functions/AF2-12%20Vendor%20Access)
・外科医がRASサポート手術を行っている。外科医は、ロボットのアームが入力コマンドに反応しないことを通知した。技師はロボットのプラットフォームが、手術中に状態を変更して、新たなファームウェアのアップロードが可能になっていたことを特定した。調査を通じて、SaaSベースのベンダー管理インタフェースが侵害され、認証済ベンダーの管理コマンドが転送されていることを特定した。
シナリオ5: AF-7 ロボットシステムのランサムウェア感染
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF2-7%20Ransomware)
・技師が、外科手術のために、RASの準備をしている。準備中、機器が突然停止した。機器がランサムウェアに感染したという表示が出た。外科手術は、ランサムウェアから修復するまで実行できない。
シナリオ6: AF-1 破損したファームウェアのロボットシステムへのロード(正当なステージサイトで破損したファームウェア)
(https://github.com/cloudsecurityalliance/IoT-Medical-Cloud/tree/main/Telesurgery/attackFlows/Attacks%20on%20System%20Availability/AF2-1%20Corrupt%20Firmware%20DoS)
・技師が、ロボット支援手術システムの日常的な維持を行っている。技師は、機器上のファームウェアのアップデートを開始した。ファームウェアのアップデート完了後直ちに、機器は反応しなくなり(例.RASがコマンドに反応しない)、もはや稼働していない。技師は、ファームウェアのアップデートが破損したと信じている。
演習フロー
ファシリテーターの第一の目的は、災害復旧、事業継続、インシデント対応計画のステップに焦点を当てた会話を維持することにある。最初にシナリオを提示した後、ファシリテーターは、必要な場合、控えめに、参加者の軌道修正を観察し、指示する。すべての参加者に対して、関連する情報になじませるために、できれば演習前に、関連するサイバーセキュリティポリシーや手順のコピーを提供する必要がある。演習中、すべての参加者に対して、完全なコンタクトリストが利用可能なようにする必要がある。そして、すべての参加者に対して、イベントの間、自分の意思決定プロセスに最も似たような方法で、質問に答えるよう推奨すべきだとしている。
本ガイドブックでは、演習シナリオ事例として前述の「シナリオ4: AF-12 手術中のロボットシステムの変更状態(例.診断モードの変更状態)」を取り上げて、以下のように提示している。
シナリオ事例
手術チームが手術安全チェックリストおよび機器チェックを調べ終え、麻酔科医に対して冠動脈バイパス手順のために患者に麻酔をかけ始めるよう指示を出したのは、火曜日の午前9時半だった。その数分後、麻酔科医は指示を出した。それからチームは、患者に挿管し、人工心肺装置など、その他必要な生命維持対策に装着する。手術ロボットを利用して、外科医は、患者の右肺と、患者の右冠動脈をバイパスするために利用されるハーベストの血管を成功裏に開いた。ハーベストされた血管が大動脈に取り付けるプロセスにあった時突然、外科医は、手術ロボットが指示に従わず反応しないことを通知する。ロボット手術技師により、問題に対するトラブルシューティングを行おうという最初の試みがあり、手術ロボットに、一時的に機器が使用できない状態にするようなファームウェアのアップデートがあったようだという報告があった。
[考慮すべき質問]
1. 直ちに取組むべき必要がある患者安全の課題は何か?
2. 手術ロボットを稼働させるためにすべき追加的試みはあるか、また患者の胸部が開かれ、手術はマニュアルで完了するか?
3. 手術チームの誰かが、この課題を生体医学またはその他の内部病院部門に報告するか、また手術が完了し患者が安定するまで、これが延期されるか?
4. この時点で誰かが、情報セキュリティ課題を考えているか、またこれは機器の故障だと想定するか?
5. この時点で誰かが、この課題が、病院内の他の機器に影響を及ぼす可能性があると考えているか、またこれが、孤立したインシデントだと想定するか?
6. ベンダーに対する呼び出しはこの時起きたか、また手術が完了した後まで待っていたか?
7. この時、病院インシデントコマンドシステム(HICS)の稼働は指示されたか?
状況付与1
午前11時45分までに手術チームは手術を完了し、病院のITと生物医学部門が調査を行っている。ITは、ネットワークおよびその他の接続をチェックし、生体医学は、機器の構成をチェックしている。ITのエンドに問題を見つけることができないので、課題は機器そのものにあると想定され、生体医学チームは、製造業者を呼んで、異常に長い保持時間を提示する。生体医学チームが、製造業者の支援を引き出そうと試みている間、結腸がんの処置を受ける患者がいる隣の手術室にある手術ロボットも、故障し始めている。その行動は、要求されていないファームウェアのアップデートが機器に発生して、いかなる外科医の指令にも反応しなくなるという点で、右冠動脈バイパスの間に観察されたのと同じである。
[考慮すべき質問]
1. この新たな患者安全の課題に対して、どのように取組むか?
2. この時点で、誰に通知するか?
3. この時点で、単なる機器の故障以上の大きい課題が始まったと考えられるか?
4. この段階で、情報セキュリティチームを呼び出すか?
5. 他の手術室におけるロボット手術は再スケジュールされるか(可能な場合)、またはこの時点で、マニュアル手術に置き換えるか?
6. 生体医学チームは、あらゆる機器の設定やソフトウェアに対する変更を特定するために、機器の構成を十分に文書化しているか?
7. 既知の影響を受けた手術ロボットを、インターネットおよび／または内部ネットワークから分離するよう考慮するか?
8. その他のあらゆる手術ロボットを、インターネットおよび／または内部ネットワークから分離するよう考慮するか?
9. この時、病院インシデントコマンドシステム(HICS)の稼働は指示されたか?
状況付与2
午後3時半、生体医学チームは、最終的に、ベンダーに伝えることができて、そのベンダーがサイバー攻撃を受けて、機器を遠隔管理し、顧客に技術サポートとファームウェアアップデートを供給するために利用しているSaaSベースシステムの侵害に至ったことを発見することができた。ベンダーは、いくつかの顧客が、要求されていないファームウェアのアップデートを報告してきたことを認識しているが、調査が依然としてペンディングとなっているため、詳細な情報を提供できないと主張している。
[考慮すべき質問]
1. これらの機器に影響を及ぼす可能性があるサイバーインシデントが確認された今、(可能な場合)、組織の侵害された手術ロボット向けインシデント対応計画は何か?
2. この新たな情報は、最後のセクションで議論された患者のリスケジューリングや、代替的な手術アプローチに関する決定を変えるか?
3. この新たな情報は、最後のセクションで議論されたネットワークのコネクティビティに関する決定を変えるか?
4. ランサムウェアは明らかになっていないが、その可能性と、ランサムウェア攻撃は正常なオペレーションまで復旧するのに数週間要し得るという事実を考えると、手術ロボットが利用できない複数週の長い期間、患者ケアや、病院のオペレーション、病院の財務などに、どのような影響を及ぼすか?
5. 攻撃者が病院のネットワークにアクセスしたり、攻撃者がネットワーク上の他システムを攻撃するための足がかりを提供したりするための手段として、要求されていないソフトウェアのアップデートが活用されたか否かについて、病院はどのように判断するか?
6. 同一ベンダーが生産または管理する可能性のある、病院ネットワーク上の他の機器をリスト化した在庫管理が、病院にあるか?
7. 同一ベンダーが製造したその他の機器は、どのようにして、潜在的侵害について評価可能か?
8. このSaaSプラットフォームに保存された保護対象保健情報(PHI)または機密情報はあるか?
9. この時点で、ベンダーに対して、どんな質問をすべきか?
10. 医療提供組織(HDO)は、このインシデントを報告すべきか?
11. HDOがとるべき追加的アクションはあるか？
状況付与3
3日後、医療提供組織(HDO)は、ベンダーから、インシデント前の状態にSaaSベースの管理プラットフォームを完全復旧できるまで数週間かかること、そして、HDOは、システムが完全復旧するまでの間、ネットワークインタフェースカード(NIC)を切断しなければならないことを通知される。今後2週間以上の間に、技師がHDOに派遣され、すべての手術ロボット上のファームウェアを製造業者が承認した最新バージョンに戻して機能を復旧するという。手術の再スケジューリングがメディアによって告知され始め、記者がHDOに質問し始めている。セキュリティ侵害インジケーター(IOC)と、戦術・技術・手順(TTP)の初期リストが、ベンダーからHDOに提供される。
[考慮すべき質問]
1. 記者へのメッセージは、インシデントに関して、どのように処理されるか?
2. 患者のインシデントに関する不満およびそのサービスへの影響は、どのように処理されるか?
3. 環境をチェックするために、セキュリティ侵害インジケーター(IOC)のリストを、どのように有効活用することができるか?
4. 環境をチェックするために、戦術・技術・手順(TTP)を、どのように活用することができるか?
5. 追加的な検知および／または制御が必要になる可能性があるか否かをチェックするために、戦術・技術・手順(TTP)を、どのように利用することができるか?
状況付与4
さらに3週間後、ベンダーおよびHDOのオペレーションは正常に戻る。
[考慮すべき質問]
1. このような課題を低減して前に進むために、どんなことができるか?
2. 手術ロボットベンダーは、サードパーティベンダーリスク管理プロセスを乗り越えたか?
3. RASベンダーとの契約には、適切なサービスレベルアグリーメント(SLA)と、セキュリティ課題に関する報告があるか?
4. 追加的な制御がもし必要な場合、医療提供組織(HD)は、何の実装を考慮するか?
医療ロボットから自動車への横展開
なお、本ガイドブックの策定に関わったCSA IoT WGでは、MITRE Attack Flowをロボット支援手術(RAS)システムの脅威モデリングに適用した知見・ノウハウを、自動車サイバーセキュリティの分野に活かすべく、「オートモティブクラウド」イニシアティブの立ち上げ準備を行っている。本イニシアティブは、以下のようなスコープを掲げている。
・自動車クラウドサービスに合わせて、特別な損失シナリオにマッピングした攻撃パス／ツリーのライブラリ
・ISO/SAE Work Product (WP)-15-05に適合した脅威分析およびリスク評価プロセスで要求されるインプットと一貫した攻撃パス
・MITRE attack flowに適合した攻撃シミュレーションにおける潜在的利用のための機械判読可能なフォーマットで開発された攻撃パス
・攻撃パス分析の脅威分析およびリスク評価パッケージへの統合
・(1)既存の功績のレビューと(2)理論的功績に基づいて開発された攻撃パス
現在、IoT WGでは、自動車産業のOEMおよびTier 1サプライヤーと、自動車クラウドSaaSベンダーからの協力者を募集している。
CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司