後編では、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)／鍵管理やハードウェア対応型セキュリティに関連したガイダンス類の概要について紹介する。

クラウドネイティブ技術の実装を推進する米国FDA

2023年9月13日、米国食品医薬品局(FDA)は、「2024～2027会計年度FDA情報技術戦略」(https://www.fda.gov/about-fda/office-digital-transformation/fda-information-technology-strategy-fy-2024-fy-2027)を公表し、以下の6つの戦略目標を掲げた。

1. コラボレーションの強化
2. インフラストラクチャの強化
3. サービスの現代化
4. データの共有
5. AIとイノベーションの採用
6. 人材とリーダーシップの育成

このうち「2. インフラストラクチャの強化」では、以下の4つの目標を掲げている。

1. 柔軟なインフラストラクチャのオファリング提供
2. クラウド採用の加速
3. サービスの可用性の保証
4. ゼロトラストアプローチの実装

このような医薬品・医療機器行政DXの進展とともに、医療・ライフサイエンス分野でも、ゼロトラスト環境を前提としたアプリケーションコンテナやマイクロサービス、サーバーレス、DevSecOpsに代表されるようなクラウドネイティブ技術の実装が本格化している。セキュリティの領域においても、ソフトウェア主導型の新たなサービスが次々と開発・導入されている。

その一方で、ハードウェアセキュリティモジュール(HSM）やセキュアチップに代表されるような、半導体を軸とするハードウェア対応型セキュリティ技術の開発・導入も進んでいる。特に医療現場の場合、ユーザーインタフェースや業務フローに影響を及ぼす可能性があるアプリケーションソフトウェア層よりも、プラットホームハードウェア層でセキュリティ機能の実装や運用・保守を行った方がメリットのある場合も多い。

米国NISTが推進するハードウェア対応型セキュリティの標準化

このような状況下で、米国立標準技術研究所(NIST)は、クラウドネイティブ技術に係るNIST SP 800-204シリーズと並行して、ハードウェア対応型セキュリティにフォーカスしたNISTIR 8320シリーズのドキュメント作成・公開を行ってきた。。

現在、NISTIR 8320シリーズとして、以下のような文書が公表されている。

• NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
• 「NIST IR 8320A ハードウェア対応型セキュリティ：コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
• 「NIST IR 8320B ハードウェア対応型セキュリティ：信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
• 「NIST IR 8320C ハードウェア対応型セキュリティ：マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)

以下では、NIST IR 8320シリーズの各ドキュメントの概要について説明する。

「NIST IR 8320 ハードウェア対応型セキュリティ: クラウド・エッジコンピューティングのユースケース向けプラットフォームセキュリティの階層型アプローチ実現」(2022年5月4日)
(https://csrc.nist.gov/pubs/ir/8320/final)

今日のクラウドデータセンターやエッジコンピューティングにおいて、攻撃対象領域はシフトしており、場合によっては、非常に拡大している。それと同時に、ハッキングが業態化しており、大抵のセキュリティ制御の実装が理路整然としていないか、首尾一貫していない。あらゆるデータセンターやエッジコンピューティングのセキュリティ戦略の基盤は、データやワークロードが実装され、アクセスされるプラットフォームをセキュア化すべきである。物理的プラットフォームは、あらゆる階層型セキュリティアプローチにおける第一の層を表しており、ハイレベルの層のセキュリティ制御が信頼できることを保証するのに役立つような最初の保護を提供する。この文書では、クラウドデータセンターやエッジコンピューティング向けのプラットフォームセキュリティやデータ保護を改善できるようなハードウェア対応型セキュリティの技術や手法を説明している。

NIST IR 8320は、以下のような構成になっており、附属書において、インテル、AMD、Arm、シスコ、IBMの具体的な技術を例示している。

1. 序論
2. ハードウェアプラットフォームセキュリティの概要
3. プラットフォームの完全性の検証
3.1 ハードウェアセキュリティモジュール(HSM)
3.2 チェーン・オブ・トラスト
3.3 サプライチェーン保護
4. ソフトウェアのランタイム保護メカニズム
4.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
4.2 アドレス変換攻撃
4.3 メモリ安全性違反
4.4 サイドチャネル攻撃
5. データ保護と秘密計算
5.1 メモリの分離
5.2 アプリケーションの分離
5.3 VMの分離
5.4 暗号化アクセラレーション
6. 遠隔証明サービス
6.1 プラットフォーム証明
6.2 遠隔高信頼性実行環境(TEE)証明
7. ハードウェア対応型セキュリティを活用したクラウドユースケースのシナリオ
7.1 セキュリティアーキテクチャに対する可視性
7.2 高信頼性プラットフォーム上のワークロード配置
7.3 資産のタグ付けと高信頼性ロケーション
7.4　ワークロードの機密性
7.5　鍵と秘密の保護
8. 次のステップ
参考文献
附属書A – ベンダーに依存しない技術の例
A.1 プラットフォームの完全性の証明
A.1.1 UEFIセキュアブート(SB)
A.2 キーライム
附属書B – インテルの技術の例
B.1 プラットフォームの完全性の証明
B.1.1 チェーン・オブ・トラスト(CoT)
B.1.2 サプライチェーン保護
B.2 ソフトウェアのランタイム保護メカニズム
B.2.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
B.2.2 アドレス変換攻撃
B.3 データ保護と秘密計算
B.3.1 メモリの分離
B.3.2 アプリケーションの分離
B.3.3 VMの分離
B.3.4 暗号化アクセラレーション
B.3.5 技術事例の概要
B.4 遠隔証明サービス
B.4.1 Intel Security Libraries for the Data Center (ISecL-DC)
B.4.2 技術の概要
附属書C – AMDの技術の例
C.1 プラットフォームの完全性の証明
C.1.1 AMD Platform Secure Boot (AMD PSB)
C.2 データ保護と秘密計算
C.2.1 メモリの分離
C.2.2 VMの分離
附属書D – Armの技術の例
D.1 プラットフォームの完全性の証明
D.1.1 Arm TrustZone Trusted Execution Environment (TEE) for Armv8-A
D.1.2 Arm Secure Bootとチェーン・オブ・トラスト(CoT) D.1.3 Platform Security Architecture (PSA) Functional APIs
D.1.4 Platform AbstRaction for SECurity (Parsec)
D.2 ソフトウェアのランタイム保護メカニズム
D.2.1 リターン指向プログラミング(ROP)とコール／ジャンプ指向プログラミング(COP／JOP)に対する攻撃
D.2.2 メモリ安全性違反
D.2.3 サイドチャネル攻撃に対するArmの低減策
D.3 データ保護と秘密計算
D.3.1 Armの秘密計算アーキテクチャ(CCA)
D.3.2 Armの暗号化アクセラレーション
附属書E – シスコの技術の例
E.1 プラットフォームの完全性の証明
E.1.1 シスコプラットフォームのルート・オブ・トラスト
E.1.2 シスコのチェーン・オブ・トラスト(CoT)
E.2 シスコのサプライチェーン保護
E.3 シスコのソフトウェアランタイム保護
E.4 シスコのデータ保護と秘密計算
E.5 シスコの暗号化アクセラレーション
E.6 シスコのセキュリティインフラストラクチャに対する可視性
E.7 シスコの信頼されたプラットフォームへのワークロードの配置
附属書F – IBMの技術の例
F.1 プラットフォームの完全性の証明
F.1.1 ハードウェアセキュリティモジュール(HSM)
F.1.2 IBMのチェーン・オブ・トラスト(CoT)
F.2 ソフトウェアランタイム保護メカニズム
F.2.1 IBMのROPとCOP／JOPに対する攻撃への防御
F.3 データ保護と秘密計算
F.3.1 IBMのメモリ分離技術
F.3.2 IBMのアプリケーション分離技術
F.3.3 IBMのVM分離技術
F.3.4 IBMの暗号化アクセラレーション技術
F.4 遠隔証明サービス
F.4.1 IBMのプラットフォーム証明ツール
F.4.2 IBMの継続的ランタイム証明
附属書G – 頭字語と略語
附属書H – 用語集

「NIST IR 8320A ハードウェア対応型セキュリティ：コンテナプラットフォームのセキュリティプロトタイプ」(2021年6月17日)
(https://csrc.nist.gov/pubs/ir/8320/a/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。その中で、IaaS（Infrastructure as a Service）クラウドコンピューティング技術や、リソースアセットのタグ付けフォームにおける位置情報など、セキュリティの課題を説明した上で、これらの課題に取組むために設計された概念実証の実装(プロトタイプ)を説明している。

NIST IR 8320Aは、以下のような構成になっており、附属書において、インテル、AMI、Kubernetesの具体的な技術を例示している。また、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及しており、これらを介してCSA STAR／CCMとの紐づけも可能になっている。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. プロトタイプの実装
2.1 目的
2.2. 目標
2.2.1 ステージ0：プラットフォームの証明と評価されたワーカーノードの設定
2.2.2 ステージ1：信頼されたワークロードの配置
2.2.3 ステージ2：アセットのタグ付と信頼された位置情報
3. プロトタイピングのステージ0
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. プロトタイピングのステージ1
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. プロトタイピングのステージ2
5.1 ソリューション概要
参考文献
附属書A – ハードウェアのアーキテクチャと前提条件
A.1 ハイレベルの実装アーキテクチャ
A.2 Intel Trusted Execution Technology (Intel TXT)とTrusted Platform Module (TPM)
A.3 証明
附属書B – プラットフォームの実装：AMI TruE
B.1 ソリューションアーキテクチャ
B.2 ハードウェアの記述
B.3 AMI TruEのインストールと構成
B.3.1 AMI TruE Trust Managerのインストール
B.3.2 AMI TruE Attestation Serverのインストール
B.3.3 AMI True向けファイアウォールの構成
B.3.4 デバイスアクセス鍵の構成
B.3.5 Discovery RangeとManageability Rangeの構成
B.4 信頼されたクラウドクラスターのインストールと構成
B.4.1 TruEエージェントの遠隔プロビジョニング
B.4.2 TruEエージェントの手動プロビジョニング
B.5 AMI TruEの利用
B.5.1 AMI TruEを利用した信頼状況のモニタリング
B.5.2 信頼性レポートの生成
B.5.3 AMI TruEを利用したプラットフォームのタグ付け
B.5.4 信頼性イベントアラート通知の受領
B.5.5 救済策のためのAMI TruE利用
附属書C – プラットフォームの実装：Kubernetes
C.1 プロトタイプのアーキテクチャ
C.2 ハードウェアの記述
C.3 Kubernetesのインストールと構成
C.3.1 Kubernetes Controller Nodeの構成
C.3.2 Kubernetes Worker Nodeの構成
C.3.3 Kubernetesのオーケストレーション
附属書D – NIST SP 800-53のセキュリティ制御
附属書E – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書F – 頭字語およびその他の略語

「NIST IR 8320B ハードウェア対応型セキュリティ：信頼されたコンテナプラットフォームにおけるポリシーベースのガバナンス」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/b/final)

本文書では、マルチテナント型クラウド環境におけるコンテナデプロイメントを保護するためのハードウェア対応セキュリティの技術や手法に基づくアプローチを説明している。また、一般的なセキュリティコミュニティ向けの青写真やテンプレートとなることを意図したアプローチのプロトタイプ実装について説明している。

NISTIR 8320Bは、以下のような構成になっており、附属書において、インテル、OpenShift、TSIの具体的な技術を例示している。また、NISTIR8320Aと同様に、NIST SP800-53改定第5版やNISTサイバーセキュリティフレームワーク第1.1版とのマッピングについても言及している。

1.序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2.プロトタイプの実装
2.1 目的
2.2 目標
2.2.1 ステージ0：プラットフォームの証明と測定されたワーカーロードの設定
2.2.2 ステージ1：信頼されたワークロードの配置
2.2.3 ステージ2：アセットのタグ付と信頼された位置情報
2.2.4 ステージ3：信頼に基づくワークロードの暗号化
2.2.5 ステージ4：信頼に基づくワークロードの情報へのアクセス
2.3 追加的リソース
3. プロトタイピングのステージ0
4. プロトタイピングのステージ1
5. プロトタイピングのステージ2
6. プロトタイピングのステージ3
6.1 ソリューション概要
6.2 ソリューションアーキテクチャ
7. プロトタイピングのステージ4
7.1 ソリューション概要
7.2 ソリューションアーキテクチャ
参考文献
附属書A – ハードウェア・ルート・オブ・トラストの実装
A.1 ハイレベルの実装アーキテクチャ
A.2 ハードウェア・ルート・オブ・トラスト：Intel TXTとTrusted Platform Module (TPM)
A.3 証明：Intel Security Libraries (ISecL)
附属書B – ワークロードオーケストレーションの実装：OpenShift
B.1 プロトタイプのアーキテクチャ
B.2 OpenShiftのインストールと構成
B.2.1 VMwareベースの管理クラスター(クラスターA)
B.2.2 KVMベースのマネージドクラスター(クラスターB)
B.2.3 MCM Pak 1.3(MCM HUB – VMware)のインストール
附属書C – ワークロード暗号化の実装
C.1 プロトタイプのアーキテクチャ
C.2 ワークロード暗号化の構成
附属書D – Trusted Service Identity(TSI)
D.1 TSIの概要
D.2 TSIのインストールと構成
附属書E – NIST SP 800-53 セキュリティ制御および発行文書のサポート
附属書F – サイバーセキュリティフレームワークのサブカテゴリーのマッピング
附属書G – 頭字語およびその他の略語

「NIST IR 8320C ハードウェア対応型セキュリティ：マシンアイデンティティ管理と保護(初期公開草案)」(2022年4月20日)
(https://csrc.nist.gov/pubs/ir/8320/c/ipd)

組織は、容量が拡大するマシンアイデンティティを導入しており、一組織当たり数千または数百万の数に至る場合もよくある。秘密暗号鍵のようなマシンアイデンティティは、個々のマシンにどのポリシーを強制する必要があるかを特定するために利用できる。マシンアイデンティティの中央集中型管理は、デバイスやワークロード、環境を越えたポリシー実装の簡素化に役立つ。しかしながら、利用する機微データ向けの保護策の欠如(例.メモリにおけるマシンアイデンティティ)により、リスクに晒される。本文書では、ライフサイクルを通じたマシンアイデンティティの生成、管理、保護に関するセキュリティ課題を克服するための効果的なアプローチを提示している。そして、このような課題に取り組む概念実証(PoC)の実装、プロトタイプについて記述している。本文書は、一般的なセキュリティコミュニティが、記述された実装を検証し、有効活用するために利用できるような青写真やテンプレートとなることを意図している。

NIST IR 8320C初期公開草案の構成は以下のようになっており、附属書において、Vanafi、インテルの具体的な技術を例示している。

1. 序論
1.1 目的とスコープ
1.2 専門用語
1.3 文書の構造
2. マシンアイデンティティを保護する際の課題
3. ステージ0：エンタープライズ向けマシンアイデンティティ管理
3.1 ソリューション概要
3.2 ソリューションアーキテクチャ
4. ステージ1：ハードウェアベースの秘密計算による秘密鍵利用時の保護
4.1 ソリューション概要
4.2 ソリューションアーキテクチャ
5. ステージ2：マシンアイデンティティ管理とエンドツーエンドの保護
5.1 ソリューション概要
5.2 ソリューションアーキテクチャ
附属書A – ハードウェアアーキテクチャ
附属書B – Vanafiのマシンアイデンティティ管理の実装
附属書C – インテルの利用時秘密鍵保護の実装
附属書D – マシンアイデンティティ・ランタイム保護と秘密計算との統合
D.1 ソリューション概要
D.2 ソリューションアーキテクチャ
D.3 インストールと構成
附属書E – 頭字語およびその他の略語

ここまで、NISTのハードウェア対応型セキュリティに関連した文書を紹介してきたが、業種・業界別にみると、決済系に代表される金融業界で、具体的な技術の開発・導入に関するユースケースが多く提供されており、オンプレミス環境とクラウド環境を組み合わせたハイブリッド環境におけるセキュリティ管理策の最適化に向けたソリューション開発が加速している。さらにマシンアイデンティティ管理をみると、情報技術(IT)と制御技術(OT)の融合に係るアイデンティティ管理の効率化・自動化を想定していることが伝わってくる。

元々、クローズドな境界防御を前提として情報システムが構築・運用されていた医療・ライフサイエンス業界の場合、ゼロトラストアーキテクチャやアプリケーションコンテナに代表されるクラウドネイティブ技術の導入も、ハイブリッド環境下が中心とならざるを得ない。医療機器のIoMT(Internet of Medical Things)やバイオ製造のデジタルツインを支えるセキュリティ管理策についても、ソフトウェア、ハードウェアの両面から最適化を図る必要があるだろう。

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

近年、金融決済領域を中心に普及し、医療IoT(IoMT: Internet of Medical Things)などの医療・ライフサイエンスの領域でも関心が高まっている技術に、ハードウェアセキュリティモジュール(HSM)に代表されるハードウェア対応型セキュリティ(Hardware-enabled Security)がある。クラウドセキュリティアライアンス(CSA)では、「クラウドネイティブな鍵管理サービス採用のための推奨事項」（2021年9月14日発行）(https://cloudsecurityalliance.org/artifacts/recommendations-for-adopting-a-cloud-native-key-management-service)、「鍵管理ライフサイクルのベストプラクティス」(2023年12月19日発行)( https://cloudsecurityalliance.org/artifacts/key-management-lifecycle-best-practices)、「HSM-as-a-Serviceのユースケース、考慮事項、ベストプラクティス」(2024年発行予定)など、クラウド鍵管理の観点から研究が進んでいる。 ここでは、クラウドネイティブ技術を支えるハードウェアセキュリティモジュール(HSM)や鍵管理の現状、米国立標準技術研究所(NIST)におけるハードウェア対応型セキュリティの標準化動向について概説する。

金融業界を中心に普及してきたハードウェアセキュリティモジュール(HSM)

CSAでは、ハードウェアセキュリティモジュール(HSM)について、暗号化のオペレーションを実行し、鍵を保護するために、認証された信頼されるプラットフォームと定義している。それは、改ざんに対応し、侵入を防止するデバイスであり、セキュリティ暗号化アクセラレータ、ハードウェアベースの乱数発生器、プロセッサー、RAM、ストレージ、外部インタフェース(例. ネットワーク／シリアルポート)から成る。HSMは、HSMにより生成・生産された暗号鍵として、組織インフラストラクチャのセキュリティを支えるために利用されるような信頼の起点(Root of Trust)と考えられる。通常、HSMは、強力なユーザ認証と職務分離を実装する。

HSMのタイプとしては、ユースケースに従って、一般目的のHSMと決済目的のHSMの2種類がある。双方を比較すると、以下のようになる。

[一般目的のHSM]

• 暗号化アルゴリズム: 汎用的、対称／非対称暗号化
• 管理上の柔軟性: とても柔軟
• セキュリティ機能: 汎用的
• 適用可能な標準規格: ETSI TS 419 series、CEN EN 419 221、PCI DSS & 3DS、FISMA、FedRAMP、FICAM
• ユースケース: 汎用的な暗号化署名、暗号化／復号化、TLSオフロード

[決済目的のHSM]

• 暗号化アルゴリズム: 領域固有、対称暗号化
• 管理上の柔軟性: いくらか柔軟
• セキュリティ機能: 強化型
• 適用可能な標準規格: PCI P2PE、PCI 3DS、PCI SPoC、PCI CPoC、PCI PIN
• ユースケース: カードPINライフサイクル、カードと暗号の妥当性評価、決済資格情報の発行、鍵管理向けオペレーションのポイントツーポイント暗号化(P2PE)、EMV取引処理

医療・ライフサイエンス領域は、一般目的のHSMに含まれ、標準化された暗号化アルゴリズムや業界標準のAPIをサポートする形で技術の導入が進んでいる。

加えて、HSMには、セキュアエンクレーブ(安全な飛び地)のような派生製品のケースがあり、領域固有のアルゴリズムやビジネスロジックが、セキュアで制御されたランタイム環境上に展開されることを要求する仕組みになっている。

成長するクラウド型のHSM-as-a-Service

他方、ハードウェアセキュリティモジュール・アズ・ア・サービス(HSM-as-a-Service)は、API、Web、ローカルインタフェースを介して、ハードウェアセキュリティモジュール(HSM)へのアクセスを提供するような、クラウドベースのサービスモデル／ソリューションである。HSM-as-a-Serviceは成長市場であり、多くの組織が、鍵管理や暗号化のニーズ向けにクラウドベースのソリューションを採用している。現在、HSM-as-a-Serviceソリューションは、SaaSデリバリーモデルに参入したクラウドサービスプロバイダ(CSP)およびHSMベンダーの双方が提供している。

HSM-as-a-Serviceの採用に影響を及ぼす要因として、以下のような点が挙げられる。

• クラウドベースのセキュリティソリューションに対する需要の拡大:
  組織の多くがアプリケーションやデータをクラウドに移行し、新たなアプリケーションがクラウドネイティブ環境に構築されるにつれて、低レイテンシーや統合のオプションなど、オンプレミス型ソリューションと同等レベルのセキュリティを提供できるようなクラウドベースのセキュリティソリューションに対する需要が拡大している。
• コンプライアンス要求事項:
  多くの業界、特に銀行・金融サービス・保険(BFSI)セクターや、デジタルガバメント、デジタルトラストサービス・セクターでは、国レベルの標準規格や規制により強制された、厳格なコンプライアンス／プライバシー要求事項を抱えており、機微データの保護、暗号鍵の制御、デバイスのバリデーション水準に関する特別な要求事項が見込まれる。このようなコンプライアンス要求事項は、どのHSM-as-a-Serviceのサブセットが有効活用できるかに影響を及ぼす。
• CAPEX(資本的支出)の削減:
  HSMは、通常、高額な投資と考えられている。同等のクラウドサービスは、このようなサービスの採用のために適切な計画と設計を設定する限り、実際のサービス消費量に応じた支払いを可能にすることによって、費用の削減を提供できる。
• OPEX(事業運営費)の削減:
  HSMデバイスは、その運用維持のために、熟練したエンジニアを必要とする。HSM-as-a-Serviceの提供は、維持や日々の運用をCSPやHSMベンダーに移管して、組織が業務費用を削減し、その他のタスクにリソースを再配分することを可能にする。

ハードウェアとソフトウェアが融合するHSMの技術アーキテクチャ

HSMは、機微データや暗号鍵を保護するために設計された専用デバイスであり、、セキュアな暗号化の運用を実行する。HSMは、専用の物理的デバイスまたは仮想アプライアンスとして運用することができ、暗号鍵の生成、保存、管理のために、多層型のセキュリティアプローチを導入して、物理的・デジタル的両面の脅威からの保護を保証する。HSMの論理的アーキテクチャは、セキュアな鍵ストレージ、暗号化アルゴリズム、改ざん対応モジュールなど、様々なセキュリティの階層から成る。これらのモジュールは、改ざんに対応するよう設計されることが多く、その中に保存された機微情報に対して、不正な主体がアクセスすることが極めて困難になっている。この中には、セキュアブートプロセス、暗号化ストレージ、鍵生成・保存専用ハードウェアなどの機能が含まれることが多い。

HSMには、リアルタイム改ざん検知メカニズムのような先進的セキュリティ機能が装備されており、物理的な侵害の試みに対する保護対策(例. 物理的に侵入が検知されたら鍵を消去する)の引き金となる。さらに、HSMは、アクセス制御、保存データの暗号化、セキュアな鍵のバックアップ・復旧に関するサポートなど、包括的なセキュリティ機能を提供する。このような特性により、金融取引、デジタル署名、セキュアな通信など、様々なアプリケーションの暗号化資産の機密性、完全性、可用性を保証する際、HSMは重要なコンポーネントとなる。

そして、HSM共通のフォームファクターとして、以下のようなものが挙げられる。

• トラステッドプラットフォームモジュール(TPM)または組み込み型HSM
• ローカルPCI Express(PCIe)カード
• ネットワークHSM
• スマートカード(統合型チップカード)
• USB備え付けデバイス

HSM-as-a-Serviceの場合、PCIeカードやネットワークHSMなど、特定のフォームファクターに複数のインスタンスを集約させることによって、サービスを構築することが可能である。

前述の一般目的であれ決済目的であれ、フォームファクターに関係なく、ハードウェア実装の観点から、以下のようなHSM共通の技術要素が挙げられる。

• 暗号化プロセッサー:
  暗号化オペレーションだけを実行する、専用の特別なタイプのマイクロプロセッサ。通常は、対称暗号化機能、非対称暗号化機能、ハッシュ機能、乱数発生など、固有のタイプの暗号化オペレーションを担う、より小さいプロセッシングユニットに、物理的にセグメントされる。暗号化プロセッサーは、セキュアなI/Oチャネル経由でアクセス可能であり、サーキットレベルで物理的対策により保護され、追加的なレベルの改ざん対策を提供する。
• 永続性メモリ:
  生成またはインポートされた鍵を保存するためにセキュアなスペース。永続性メモリスペースは、スロットと呼ばれる論理的パーティションに分割される。個々のスロットは、複数の鍵を保存することができる。スロットへのアクセスは、サーキットレベルでセキュア化されるだけでなく、強力な認証、アクセスと認可制御により保護される。
• I/Oモジュール:
  HSMとその他のシステムの間の通信を確立する役割を担う。フォームファクターに依存して、I/Oモジュールには、USB、PCI、UART、CPIOなど、標準的なプロトコルに応じて様々なコネクターが含まれる。

このような技術要素に基づいてHSM-as-a-Serviceを開発・提供するベンダー／サービスプロバイダーが参照すべき標準規格として、以下のようなものが挙げられる。

• FIPS(Federal Information Processing Standards)140
  • CAVP（Cryptographic Algorithm Validation Program）
  • CMVP (Cryptographic Module Validation Program)
• Common Criteria (CC) for Information Technology Security Evaluation
  • EAL (Evaluation Assurance Level)
  • PP (Protection Profile)
  • CEN EN 419 221-5
• PCI SSC (Payment Card Industry Security Standards Council) PTS (PIN Transaction Security) HSM Specification
• ISO/IEC 27001:2022
• ISO/IEC 27017:2015
• CSA STAR (Cloud Security Alliance Security Trust Assurance and Risk Framework)
• AICPA SOC (American Institute of Certified Public Accountants System and Organization Controls)
  • SOC 1: ICFR (Internal Control over Financial Reporting)
  • SOC 2: Trust Services Criteria
  • SOC 3: Trust Services Criteria for General Use

HSMの物理的・論理的セキュリティ制御と顧客の関係

上記のような標準規格をベースとして、HSM-as-a-Serviceベンダー／サービスプロバイダーに対しては、物理的セキュリティおよび論理的セキュリティの両側面から、制御策を講じることが望まれる。

HSMの物理的セキュリティ制御においては、コンスタントに、モニタリングされ、検証可能なHSMへのアクセス制御を提供することを目標としている。ベンダー／サービスプロバイダーが提供すべき物理的セキュリティ制御の基本的要素として、以下のようなものが挙げられる。

• セキュアな境界、侵入検知、論理的アクセス制御ポリシーの強制、ビジター管理、装置のingress/egressモニタリング、アクセス制御システムの保護、要員によるモニタリング、アクセス認可の強制、すべてのアクセスのログ付け。
• 出荷、試験、オペレーションの間など、HSMライフサイクルの置換と修正の制御
• HSMのアクセス、置換、修正保護におけるデュアル制御の強制など、HSMオペレーションのアクセス制御
• HSMの状態、顧客へのアロケーション、鍵のバックアップを管理するシステムに関するアクセス制御
• 遠隔管理とセキュアな鍵のバックアップに関するアクセス制御、デバイスやスマートカード向けのセキュアなストレージ、遠隔管理活動向けの施設や安全な空間、遠隔のHSMへのアクセスと鍵のバックアップ
• オペレーションや管理に関するコネクションなど、HSMに接続するネットワークの保護
• アクセス制御とビデオシステム向けのセキュアな領域、システムの可用性と完全性のモニタリングなど、アクセス制御システムの保護

なお、HSM-as-a-Serviceベンダー／サービスプロバイダーが顧客の遠隔管理デバイス利用向けに提供する場合、顧客が物理的セキュリティ上の責任を有する可能性がある。その場合、顧客は、サービス利用とストレージに関する物理的制御に責任を負うことになるので、注意が必要である。

他方、HSMの論理的セキュリティ制御においては、ベンダー／サービスプロバイダーが、顧客データの分離、従業員の顧客リソースへのアクセスの制御、最小特権アクセス、最小権限(need-to-know)アクセス、アクセスの認可とレビュー、スタッフのトレーニングなど、ISO 27001やPCI DSSなどで記述された要求事項を遵守することが前提となる。その上で、デバイスや鍵の管理で必要となるHSM固有の論理的セキュリティ制御策として、以下のようなものが挙げられる。

• 個々のHSMについて、製造からサービスにおける有効化、オペレーション、廃止・破壊に至るまでのチェーン・オブ・カストディ(CoC)の維持
• 顧客が利用可能になる前の段階におけるHSMの論理的・暗号的検証
• ライフサイクルを通してHSMに物理的なアクセスを行うすべてのスタッフに対するデュアル制御のためのプロセス、トレーニング、認可、規則
• HSM固有の物理的制御を実装するための電子アクセス制御・動画など、物理的アクセス制御に関する構成、アクセス管理、モニタリング
• 鍵管理プロセスの確立、維持、記録、モニタリング
• 鍵の管理者やカストディアンに関する認可、アクセス管理、モニタリング
• リソース管理、顧客の鍵のバックアップと復旧など、HSM管理プロセス自動化の確立、認可、管理、モニタリング
• HSM管理コネクション向けTLS認証管理など、HSMに対するネットワークアクセス制御
• HSM管理アプリケーションまたはコンソール以外のHSMへのアクセスに関するアクセス制御
• HSMサービス管理とHSMへのアクセスに関するクラウドサービスプロバイダのアイデンティティ／アクセスの構成
• クラウドサービスプロバイダのネットワークアクセスの構成
• セキュアな遠隔管理デバイスの利用

医療・ライフサイエンス領域においても、ゼロトラストアーキテクチャの導入に向けた動きが始まっており、その環境で稼働する医療IoT関連機器・サービスにも、マイクロサービスやサーバーレスアーキテクチャに代表されるクラウドネイティブ技術やDevSecOpsの波が押し寄せつつある。そのような状況に、5Gから6Gへのネットワークの進化が加わってくると、ハードウェアとソフトウェアの両面からのセキュリティ管理策実現により、さらなるイノベーションが期待される。

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

2023年10月4日、クラウドセキュリティアライアンス（CSA）の健康医療情報管理ワーキンググループは、「医療におけるデータ損失防止(DLP)」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-in-healthcare/)を公開した。ここでは、その概要について概説する。

医療データシステムのクラウド化で広がるDLPの活用機会

「医療おけるデータ損失防止(DLP)」は、医療業界における患者情報の転送に焦点を当てて、DLPを有効活用する方法の概要を示すことを目的としており、以下のような構成になっている。

・謝辞
・要約
・イントロダクション
-医療におけるデータ損失防止（DLP）
-DLPクラウドはデータ転送の重要な手段
・DLPはどのように機能するか
・DLPのタイプ
・DLPのEDM（正確なデータマッチング）とIDM（インデックス文書マッチング）
-偽陽性
-データ分類
・DLPと脅威インテリジェンス
・地域別のデータ用途
・DLPの保護
・DLPのベストプラクティスがデータセキュリティを強化する
・DLPポリシー設定のベストプラクティス
・リアルタイムのDLP
・DLP成熟度の評価
・結論
・参考文献

近年のクラウドコンピューティングの普及拡大とともに、組織は、主にクラウド経由で、データを転送・共有するようになり、世界的なCOVID-19パンデミックによって、その傾向が顕著になった。反面、組織がデータを遠隔で保存し、アクセスできるようになると、権限のない個人によるアクセスの可能性や、意図しない暗号鍵の削除といった技術的問題に起因する損失など、医療データに対する新たなリスクが生まれている。

ここでは、DLPの定義について、「患者記録、個人健康情報（PHI）など、機微情報の偶発的または許可されていない損失や暴露を防止する対策」としている。PHIの侵害は、ID窃盗や治療処置に対する害など、患者に重大な結果をもたらす可能性があり、これらの対策は、医療業界において特に需要である。DLPは、検知困難なデータの流出をレビューするために、多くの組織や医療業界が検討する多面的なセキュリティソリューションであり、データ漏えいを防止し、医療データのセキュリティや完全性を保証するために、DLP戦略を設定することが重要だとしている。

DLPソリューションの技術機能とタイプ

「DLPはどのように機能するか」では、DLPソリューションで利用される技術機能として、以下の8つを挙げている。

1. ルールベースのマッチング: 特定のルールにマッチするデータを発見するために、既知のパターンを利用する
2. データベース指紋: EDM（正確なデータマッチング）として知られているこの手法は、ファイル内の構造化データの正確なマッチングを探し出す（例. “患者番号123”の正確なストリング向け）
3. 正確なファイルマッチング: ここでは、ファイルコンテンツ全体よりも、ファイルコンテンツの暗号学的ハッシュ値に対してマッチングが行われる
4. コンテキスト分析: これは、ユーザーのロール、物理的ロケーション、利用するアプリケーションなど、データ転送に関する様々な要因を考慮する際に利用され、偽陽性の削減や、ポリシー強制の正確性の改善に役立つ
5. 部分的文書マッチング: この手法は、異なるユーザーがフォームの複数バージョンに入力する際に、あらかじめ設定されたパターンに部分的にマッチするファイルを探し出す
6. 統計学的分析: ここでは、違反のきっかけとするために、ベイジアン分析など、機械学習またはその他の統計学的手法が利用される
7. 事前組込型カテゴリー: あらかじめ組込まれたカテゴリーは、機微性やセキュリティ要求事項に基づいてデータを特定する、医療提供組織（HDO）のデータ分類に基づいたルールを利用する
8. ユーザー行動分析: この手法は、疑わしいエンドユーザーの行動にフラグを立てる

次に「DLPのタイプ」では、DLPソリューションとして、以下の3タイプを挙げている。

1. ネットワークDLP: データが移動している時に、抽出を監視、検知、ブロックする（例. 悪意あるインサイダーが、機微な企業情報を悪意のあるアクターにメール送信したり、退社時に知的財産を個人メールに送信したりする）。
2. エンドポイントDLP: 従業員が機密データをリムーバル機器(例. USBドライブ)にコピーするのを防止する。また、エンドポイントで、ローカルに検知を実行するデータ損失ポリシーに基づいて、機微データをキャプチャするために、ファイルやネットワークの共有をスキャンする場所で、ローカルエージェントを介した保存データをスキャンする。
3. クラウドDLP: データ抽出や偶発的なファイル共有に対して保護する。また、境界ベースのネットワークから、ユーザー・アプリケーション中心のネットワークに変換する際に、オンプレミス型DLPソリューションは、クラウドベースのDLPに置き換わっていく。これにより、アウトバウンドデータの調査が可能になり、ユーザーエクスペリエンスにマイナスの影響を与えることなくトラフィックをブロックするか否かの判断が容易になる。

医療業界の場合、世界保健機関(WHO)が管理・発行する医学的分類に関する変更を時系列的に組み込んでいく必要がある。そして、FDAが確認した医薬品、医師診療行為用語(CPT)／国際疾病分類(ICD-10コード)、医療診断用語などを含む文書の転送を追跡し、ブロックする際には、しばしば医療用語のDLPへの取込みが要求される。これらの用語は、EDM（正確なデータマッチング）やIDM（インデックス文書マッチング）のような機能を介して、取り込むことが可能である。

DLPソリューションの鍵を握るデータ分類と脅威インテリジェンス

データ分類は、特にDLPソリューションと合わせて、機微データを特定、追跡、保護する際にギャップを埋める橋渡し役を担う。DLPベンダーの多くは、各社固有のデータセキュリティソリューションを強化するために、データ分類サービスに依存しており、通常、固有の製品またはサードパーティ統合の形態で提供される。データ分類の標準規格は、成功するDLPプログラムの基盤であり、企業データの機密性を明確にして、データリスクを評価する基礎となる。適切にラベリング・タグ付けされたデータは、DLPプロセスを簡素化して、組織が機微データを機微でないデータと区別し、DLPのパフォーマンスを改善することを可能にする。このようなことから、データ分類機能は、DLPプログラムの統合コンポーネントとなり、DLP製品と組み合わせて提供する形態が増えている。

次にDLPソリューションとの連携が期待されるのが脅威インテリジェンスである。たとえば、脅威インテリジェンスチームがユーザー行動分析機能を強化すると、データの移動を認識する手段を達成して、データ抽出よりも前にフラグを立てることができる。DLPポリシーは、インサイダー脅威に関して、リスクのあるユーザーをモニタリング・警告するために設定することが可能であり、外部からデータ転送の監査や遮断などの行動をモニタリングできる。さらに、ファイルサイズを制限すると、ユーザーが閾値を超えるか、単独ユーザーによるファイル抽出のパターンが認識された場合、アラートのきっかけとすることができる。

ロケーションによるデータの取扱とIAM・IRM

コンプライアンスに関連して、複数の厳格な地域的・国際的規制(例.コロラド州プライバシー保護法(CPA)、欧州一般データ保護規則(GDPR)、フロリダ州デジタル権利法(FDBR)など)が、ロケーションに基づくデータ転送を管理している。将来のDLPソリューションがデータを自動的に分類・追跡する可能性はあるが、現時点では、予期しない漏えいの発生に備えて、ポリシーに基づいた特定の地域など、個人データの全タイプについてデータ保護とコンプライアンスの重要性を理解することが必要となっている。

データの共有が必要な場合、データに関する責任を有する組織は、セキュリティを保証しなければならない。データ利用に際しては、アイデンティティ／アクセス管理(IAM)がセキュリティ上重要となる。最低限、DLPソリューションには、データ利用状況のモニタリングを組み込むべきだとしている。DLPは、機微なデータを損失したり、誤用したりしていないかを保証するために利用される。DLPソフトウェアは、規制された機密データを分類し、組織や、HIPAA、PCI-DSS、GDPRのような規制遵守に従ってあらかじめ設定されたポリシー集の範囲内で、明らかなポリシー違反を特定する。加えて、組織は、情報権利管理(IRM)を考慮する必要がある。IRMは、不正なアクセスから、機微な情報を含む文書を保護するセキュリティ技術である。

DLPの保護策

DLPベンダーは、ネットワークゲートウェイにおける基本的なコンテンツフィルタリングから、複雑なネットワーク／ホストベースのモニタリングソリューションまでの広範囲なソリューションを提供する。組織は、機微な情報リソースを保護するために、ポリシーをモニタリング、発見、導入する。そのために必要な抽出の手段として、電子メール、Webブラウザ、クラウドファイル共有、インスタントメッセンジャー、ソーシャルメディア、ポータブルストレージデバイス、スクリーンキャプチャを挙げている。

DLPは、平文のパケットを調査し、調査時にデータが暗号化されていないことを要求するので、暗号化の戦略や要求事項と直接コンフリクトを起こす可能性がある。もしDLPが誤ったレイヤに導入されたり、不適当に構成されたりすると、実際に脅威ポイントを作り出すことになる。そこで本文書では、以下のような留意事項を挙げている。

1. データの暗号化: データを暗号化することにより、適正な復号鍵を持たない者が判読できないようにする。暗号化は、リアルタイムで検索可能な暗号に対してクラウド上の牽引力を持つ他の手法が存在するので、機微情報に対する不正アクセスを防止するために役立てることができる。

・対称暗号 – 暗号化と復号化の双方に単一鍵を利用する。

・クラウド上でのデータ断片化 – データの復号化に必要な暗号鍵を削除することによって、データを判読不可能にする。

・トークン化、準同型暗号(PHE) – 機微なデータ要素を代替値やトークンに置き換える。

・ポリモーフィック型暗号 – 複数の鍵で保護された複数フォーマットによるデータの暗号化。

・準同型暗号 – 復号化の必要なく、暗号化データのあるところで操作や検索ができる。

2. アクセス制御 – 不正なデータアクセスを防止するためのユーザー認証や許可。
3. ユーザー行動分析 – ユーザー行動分析を有効活用して異常または疑わしいデータアクセスパターンを検知して、潜在的なインサイダー脅威を特定するのに役立つ。
4. 定期的な監査の実行 – 定期監査は、データ損失に関する脆弱性や潜在的な領域を特定するのに、役立てることができる。
5. データのモニタリングと分析: データ侵害を特定・防止するために、リアルタイムのデータモニタリングとコンテンツ分析を実行する。
6. トレーニング – セキュリティのベストプラクティスに関する従業員向けトレーニングは、偶発的なデータ損失を防止するのに役立てることができる。たとえば、テンプレートの電子メールをユーザー宛に発行して活動を周知し、データを外部に公開するリスクに関する特別なメッセージを利用し、四半期ごとに常習者を対象としたセキュリティ意識向上トレーニングを実施する。

データセキュリティの強化に向けたDLPのベストプラクティス

本文書では、DLPのベストプラクティスについて、技術、プロセス制御、知識のあるスタッフ、従業員の意識を組み合わせたものだとして、以下の通り、効果的なDLPプログラムを構築するための指針を挙げている。

1. 単一の中央集中型DLPプログラムの実装 – 単一の中央集中型DLPプログラムを実装することにより、一貫したデータモニタリングを保証し、よりよい可視性をデータ資産に提供して、組織全体のデータセキュリティを強化する。
2. 内部リソースの評価 – DLP計画を実装するために、医療提供組織は、DLPリスク分析、データ侵害への対応・報告、データ保護法規、トレーニング・意識向上などの経験を有する人材を必要とする。
3. 在庫管理や評価の実行 – DLPプログラムの実装において、データのタイプや価値の評価は重要である。評価には、どのようにデータを処理し保護するか、どのように転送し保護するか、どこに保存し保護するかなど、データやコンプライアンス(HIPAA、PCI、PII)、ビジネス上の機微性の特定が含まれる。
4. 段階的な実装 – DLPは長期的プロセスである。段階的な実装が最善である。
5. 分類システムの構築 – 医療提供組織は、DLPポリシーを構築・実装する前に、分類フレームワークを構築しなければならない。
6. データ処理・救済ポリシーの設定 – 分類フレームワークの構築後に、異なるデータのカテゴリーを処理するためのポリシーを構築（または更新）する。
7. 従業員の教育 – セキュリティポリシーや手順に対する従業員の意識や受容が不可欠である。

DLPポリシー展開のベストプラクティス

さらに、医療提供組織がDLP投資を最大化するのに役立ち、ソリューションが組織の既存のセキュリティ戦略や既存の対策に合致していることを保証するようなベストプラクティスとして、以下のようなことを推奨している。

1. 第一目的の決定 – DLPは、医療提供組織が、HIPAAのような複雑で進化するコンプライアンス基準を満たせるように、多くの医療提供組織で採用される。これは1つの重要機能であるとともに、包括的なソリューションが、データ保護、インシデント防止、可視性、インシデント対応能力など、医療提供組織に対するその他の支援を提供する。柔軟なソリューションにより、医療提供組織が優先順位に応じてカスタマイズすることが可能になる。
2. 医療提供組織のセキュリティアーキテクチャや戦略に合わせたDLPの保証 – DLPソリューションを設計・実装する時、医療提供組織は、凝縮された統合型のセキュリティアーキテクチャを保証する互換性を決定するために、ファイアウォール、モニタリングシステムなど、レガシーなセキュリティ技術注意深く評価しなければならない。
3. 規則的な頻度のセキュリティレビュー構築 – 医療提供組織は、DLPソリューションのパフォーマンスを継続的に評価する必要がある。新たな機能や能力が追加され、上市する際に評価する必要がある場合がよくある。
4. 変更管理ガイドラインの設定 – 医療提供組織は、ステークホルダー間で取り決められた構成について、実装前に統一の承認を受ける必要がある。
5. 検証 – DLPソリューションが意図通りに稼働することを保証するために、定期的な監査と包括的なテストが重要であり、対策中に潜在的な脆弱性やギャップを特定し、処理する。

ランサムウェア対策として注目されるリアルタイムのDLP

1. リアルタイムのデータモニタリング: DLPソリューションは、医療提供組織のネットワークやシステムを通じてデータが流れる際にリアルタイムで、継続的にデータをモニタリングする。たとえば、DLPは、機微データ向けのファイル転送をモニタリングし、転送を遮断する。それは、ネットワークの出口ポイント、ユーザーのエンドポイント(例.ラップトップ、デスクトップ)、クラウドアプリケーションなど、異なる地点で遮断することができる。
2. コンテンツ調査・分析: DLPソリューションは、コンテンツ調査を実行し、それを通してデータを分析する。機微データを発見したら、通過から遮断する。それは、明確なポリシーや分類に基づいて機微データを分類するために、キーワードマッチング、正規表現、データ指紋、機械学習アルゴリズムなど、様々な手法を利用する。
3. コンテキスト分析: DLPソリューションは、データ転送やアクセスのコンテキストを考慮することによって、偽陽性を回避し、正確なポリシー強制を保証する。機微データの転送を発見したら、ソリューションはそれを遮断する。ソリューションは、ユーザーの役割、ロケーション、利用されるデバイス、目的地、利用されるアプリケーションなどの要因を分析する。
4. ポリシー強制: DLPソリューションがポリシー違反を特定または潜在的に特定すると、リアルタイムに強制する。ポリシーは、機微データ転送の遮断、データの暗号化、ユーザーや管理者へのアラート、詳細な分析向けのインシデントのログ付けなど、構成の設定に合わせて様々な行動を引き起こすことができる。
5. インシデント対応: DLPソリューションは、ポリシー違反が発生すると、インシデント対応ワークフローの引き金となる。対応には、セキュリティ要員への通知、問題のエスカレーション、リスク低減とさらなるデータ露出防止のために必要なステップをとることなどがある。
6. 報告: DLPソリューションは、ポリシー遵守報告、インシデント報告、傾向分析hポウ国など、詳細な報告書を生成する。これらの報告は、データ保護活動、ポリシー違反、組織全体のデータセキュリティポスチャに関するインサイトを提供する。
7. 継続的な更新と改善: DLPソリューションは、新たなパターン、出現する脅威、規制変更に対して、最新の状態を維持するために、最新のデータベースやアルゴリズムを必要とする。定期的な更新は、そのソリューションが、新たに出現するリスクを効果的に特定し、保護することを保証する。

DLP成熟度の自己評価モデル

本文書では、最後に、医療提供組織のDLPプログラムを効率化する方法を理解するために、HCLテクノロジーズが策定したDLP成熟度の自己評価モデルを紹介している。ここでは、データ損失防止プログラム成熟度の重要な要素を、以下の通り6つにカテゴライズしている。

CE1 – プログラムガバナンス – プログラムガバナンスは、DLPのビジネス利用、実装、組織ポリシーに関する戦略的・戦術的意思決定のガイダンスを組織に提供する一連の階層、プロセス、ポリシーである。
CE2 – エンタープライズカバレッジ – エンタープライズカバレッジは、組織のネットワーク、ユーザー、データ空間に渡るDLP保護の範囲である。
CE3 – ポリシーカバレッジ – ポリシーカバレッジは、組織に関連するデータのタイプのスコープ全体に渡るDLPの検知・保護の幅を表す。
CE4 – インシデント救済策 – インシデント救済策の成熟度は、妥当性のあるDLP保護ポリシーに違反したユーザー、データ、ネットワークの活動への組織的対応を定義するプロセス、要員、トレーニング、サブプログラムをカバーする。
CE5 – セキュリティ意識 – この明確な目的向けに定義されたセキュリティ意識は、セキュリティ、データセキュリティ考慮事項、DLPツーリングのセキュリティ組織的意識、必要性、価値、セキュリティに関連したDLPメトリクスやツールの内部利用に対するエンドユーザー従業員の意識を定義する。
CE6 – メトリクスと報告 – データ損失防止プログラムは、確実なROIと明白なセキュリティ改善へのデータ駆動型の道筋を保証するために、追跡可能で報告可能な成功のメトリクスを有する必要がある。

他方、これら各要素の成熟度評価指標については、前述のHCLがカーネギーメロン大学の能力成熟度モデル統合(CMMI)を適用して策定した、以下の5つの成熟度レベルを紹介している。

1. 初期(Initial) – プロセスは、予測不能で、制御が難しく、リアクティブだとみなされる。この段階の組織は、リスクや非効率性の拡大を招くような予測不能な環境にある。
2. 管理された(Managed) – プロセスは、プロジェクトにより特徴づけられ、リアクティブなことが多い。
3. 明確な(Defined) – プロセスがよく特徴づけられ、よく理解されている。組織はリアクティブ以上にプロアクティブであり、組織全体の標準規格がガイダンスを提供する。
4. 定量的に管理された(Quantitatively Managed) – プロセスが評価され、制御されている。組織は、定量データを利用して、組織の目標を満たすような予測可能なプロセスを実装する。
5. 最適化している(Optimizing) – プロセスが安定して、柔軟性がある。組織的なフォーカスが、継続的改善と変化への対応に当てられている。

このようなことを踏まえて、結論では、データ保護が、すべての個人・組織、特に様々なコミュニケーションチャネルにおいて重要であり、データおよびその周りにある課題を認識するための堅牢なプラットフォームを設定することが鍵だとしている。デジタル化の最前線にある医療業界はDLPの重要市場の1つであり、データの境界のモニタリングやデータオーナーとの継続的な連携により、予防策を拡張するとともに、データ損失につながる攻撃面を縮小するメリットがあるとしている。

なおCSAでは、一般的なクラウド環境のデータ損失防止利用動向に関連して、2023年3月14日、「データ損失防止とデータセキュリティ調査報告書」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-and-data-security-survey-report/)を公開するなど、積極的に取組んでいる。

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

 

2023年10月4日、クラウドセキュリティアライアンス（CSA）の健康医療情報管理ワーキンググループは、「医療／ライフサイエンスにおけるデータ損失防止(DLP)」(https://cloudsecurityalliance.org/artifacts/data-loss-prevention-in-healthcare/)を公開した。ここでは、DLP導入の前提条件となるデータの分類・管理プロセスの標準化動向や、医療／ライフサイエンス分野のユースケースについて概説する。
米国NISTがデータ分類の標準化に関する文書草案を公開

2023年11月15日、米国立標準技術研究所（NIST）は、「NIST IR 8496 データ分類の概念とデータ収集向上のための考慮事項」公開草案初版を発表した（https://csrc.nist.gov/pubs/ir/8496/ipd）。この文書草案は、データ分類における基礎的な専門用語を定義し、基本的な概念を説明して、皆が利用するための共通言語とすること、そして、データ分類において考慮すべきことに対する認識を高め、組織がデータ保護アプローチの品質や効率性を向上させる際に役立てることを目的としている。最初に、データ分類の定義について、「持続性のあるラベルを利用してデータ資産を特徴付けて、それらの資産を適正に管理できるようにするために、組織が利用するプロセスである」としている。そして、データ分類のプラクティスを実装することによって、以下のようなメリットがあるとしている。

組織のデータ資産に対するサイバーセキュリティとプライバシー保護の要求事項の適用を可能にする
データ資産を、パートナー、契約先およびその他の組織と安全に共有する
特定のデータ資産に適用される、法律、規制、契約書およびその他のソースからの要求事項を知る
ゼロトラストアーキテクチャおよびその他のサイバーセキュリティ・プライバシー技術の実装をサポートするような、データ資産および個々の資産の重要性に対する認識を維持する
組織の知的財産へのアクセスおよび転送に関する制限を強制する
生成人工知能（AI）技術（例．大規模言語モデル（LLM））で消費されるデータ資産のソースに関するメタデータをキャプチャする
現時点で必要ないが、将来必要になる可能性があるような時、データ資産のメタデータを特定して記録する（例．量子対応準備や低減計画向け）

草案は、以下のような構成になっている。

1. イントロダクション
1.1. 目的とスコープ
1.2. 本書の構成
2. 背景
2.1. データライフサイクル
2.2. 構造化、非構造化、半構造化データ
2.3. データガバナンスとデータ管理
3. データ分類の機能
3.1. データ分類ポリシーの定義
3.2. 分類するデータ資産の特定
3.3. データ資産向けのデータ分類の決定
3.4. データ資産のラベリング
3.5. データ資産のモニタリング
参考文献
附表A. 記号、略語、頭字語の一覧
附表B. 用語集

このうち「2. 背景」についてみると、まず「2.1. データライフサイクル」で、組織は、以下の4段階から構成されるデータライフサイクルを通じてデータ資産を管理するとしている。
特定: 組織は、データ資産を特定する
利用: 組織は、一部またはすべてのデータ資産にアクセスして、閲覧、共有、修正する
維持: 組織は、時間とともにデータ資産を保持する
廃棄: 組織は、データライフサイクルの最後にデータ資産を廃棄する

次に「2.2. 構造化、非構造化、半構造化データ」では、データ構造の観点から、以下のように、「構造化データ」、「半構造化データ」、「非構造化データ」の3つのカテゴリーを提示している。

構造化データ: データが表現される方法や表現を翻訳すべき方法を記述した物理的データモデルに続くものである。構造化データは、データベース、または個々のデータフィールドに含まれる情報のタイプが何かを明確に示すようなその他のメカニズム（例．顧客IDまたは一部の番号）の中に見られることがある。構造化データは、意味を保証するために、データモデルに対して検証することができる。
半構造化データ: 自らのデータモデルを記述する（自己記述型）。半構造化データは、プロプライエタリなデータセットを共有するための拡張可能なマークアップ言語（XML）やJSON（JavaScript Object Notation）、機微な構成パラメーターなどのフォーマットで表現される。
非構造化データ: ビジネスモデルに対して意味のあるような詳細なデータモデルに続くものではない。非構造化データは、プロプライエタリな文書フォーマットや、標準規格ベースのビデオフォーマットなど、特別なフォーマットに保存される場合がある。たとえば、ビデオは、患者の治療手順や、人々の施設への入退室、新入職員向けのトレーニングコースなどを見せることが可能である。非構造化データを有する文書は、ほぼすべてのタイプの情報を含むだけでなく、その中に組込まれた他のデータのタイプ（画像や映像など）を有しておいる場合があり、各々は1つ以上のデータのインスタンスを含むことになる。

さらに「2.3. データガバナンスとデータ管理」では、データガバナンスおよびデータ管理の役割について、以下のように説明している。

データガバナンス: データ資産が適切に管理されていることを保証するために組織が実行する必要があるアクションを強化する。データガバナンスのために特に重要なデータ分類の視点は、組織のデータ分類ポリシーおよび関連するデータ保護の要求事項を明確化して、組織内および組織外双方における役割や責任など、これらのポリシーを実装し、強制すべき方法を決定する。
データ管理: データガバナンスから生じるポリシーやプラクティスの実装および強制である。データ管理は、データライフサイクルを通して、すべてのデータ資産に起きるべきである。メタデータはデータの形式であり、管理を必要とする。データ管理の一部としてのデータ分類の役割を理解するためには、以下のようなデータ管理領域に対する基礎的な理解が必要である。
データの定義: データ資産を管理するために、組織はまずデータを定義する必要がある。データの定義は、データ資産によって様々であるが、通常、適用可能なデータのタイプやデータモデルに加えて、データ資産の由来、性質、目的、品質に関連したメタデータを特定する作業（データカタログの作成）が含まれる。データの定義は、組織がデータ分類を確実なものにできるように、データ資産に関する十分な情報を収集するために努力している。データの定義の形式や厳格さは、データ資産の中で大幅に異なるが、それは、データ資産が構造化されているか、半構造化されているか、非構造化されているかに関係している。
データの分類: データ資産のためのデータ分類は、以下の3つのうち1つ以上に基づいて、選定され、割り当てられる: データの定義、カタログ化されたメタデータ、コンテンツのレビューまたは分析。
データの保護: 一度データ分類が割り当てられると、組織は、個々の分類に関連したデータ保護の要求事項を強制する。これらは、分類に応じて個々のデータ資産を保護するために必要なすべての制御をカバーする。事例としては、保存時および転送時にデータ資産を暗号化するために要求事項に関連したデータの分類があり、なりすましを検知するデータの完全性のメカニズムを利用して、特定グループのメンバーだけにアクセスを認め、データが取得された日付から少なくとも2年間データ資産を保持する。
データのモニタリング: データのモニタリングは、データ分類／データ保護に対する変更を必要とするようなデータ定義またはデータ資産自体に対するすべての変更を特定するために必要である。またデータのモニタリングは、データ管理を向上させる可能性があるようなリアルワールドデータの分類や保護の経験からの教訓を特定する。

その上で、「3. データ分類の機能」において、以下の通り、データ分類のプロセスに必要な5つの機能を提示している。

データ分類ポリシーの定義: データ資産のタイプの用語集と個々のタイプのデータ資産を特定するためのルールを記した、組織のデータ分類ポリシーを定義する
分類するデータ資産の特定: 組織が分類すべきデータ資産を特定する
データ資産向けのデータ分類の決定: データ資産を分析し、個々にとって適切なデータ分類を決定する
データ資産のラベリング: 個々のデータ資産に、データ分類ラベルを関連付ける（一度ラベルが割り当てられると、個々のデータ資産に対して、適用可能なサイバーセキュリティおよびプライバシーの要求事項を強制することができる）
データ資産のモニタリング: データ分類および／またはデータ分類ポリシーを更新する必要があるような変更に関して、個々のデータ資産をモニタリングする

このようなデータ分類プロセスの効率化・自動化を図るために、「Microsoft 365」(https://learn.microsoft.com/en-us/compliance/assurance/assurance-create-data-classification-framework)、「Google Workspace」(https://support.google.com/a/answer/9843931)、「Salesforce」(https://help.salesforce.com/s/articleView?id=sf.dato_harmonize_classify.htm&type=5)など、主要クラウドサービスプロバイダーは、様々なサポート機能を提供しており、その中に、データ損失防止(DLP)機能も含まれる。

以下では、医療／ライフサイエンス分野におけるデータ分類・管理に係る具体的な事例を紹介する。
事例1: 米国マウント・サイナイ・アイカーン医科大学のデータ分類参照ガイド

マウント・サイナイ・アイカーン医科大学は、米国ニューヨーク市マンハッタン区にある私立の医科大学であり、マウントサイナイ医療センター(ベッド数:　約1,200床)を併設している。参考までに、OWASP／クラウドセキュリティアライアンスの「OWASP セキュアな医療機器導入基準Version 2.0」(2018年8月発行)( https://cloudsecurityalliance.org/artifacts/owasp-secure-medical-devices-deployment-standard/)や、クラウドセキュリティアライアンスの「医療機器インシデント対応プレイブック」(2021年11月8日発行)( https://cloudsecurityalliance.org/artifacts/csa-medical-device-incident-response-playbook/)のプロジェクトリードを務めたクリストファー・フレンツ氏は、傘下のマウント・サイナイ・サウスナッソー病院の情報セキュリティ責任者である。フレンツ氏は、米国医療情報管理システム学会(HIMSS)などで、精力的に情報セキュリティやゼロトラストアーキテクチャに関する啓発活動を行っている。

同大学では、全学共通のデータ分類参照ガイド (https://icahn.mssm.edu/research/portal/resources/rit/data-classification) を策定・運用している。このガイドでは、以下のように、データの機微性のレベルに沿って4段階の分類を設定している。

[保護対象(Protected)] 機微性・最高レベル:
法規制により情報の保護が要求される、または情報への不正なアクセスがあった場合、大学に対して政府への自己報告および／または個人への通知が要求される
＜データの事例>
-保護対象保健情報(PHI)
-個人識別情報(PII)
-個人／従業員データ(例．従業員の補償金、就業不能給付金請求)
-ディレクトリ情報に含まれない学生データ(例．学生ローン情報)
-ビジネス／金融データ(例．クレジットカード番号)

[機密(Confidential)] 機微性・高レベル:
マウントサイナイが所有権を有するデータ、情報、知的財産; または契約上の義務により保護されたデータ
＜データの事例>
-機密または制限対象データにアクセスする情報リソース(ユーザ名とパスワード)
・アカデミック／研究情報(例．助成金申請書、被験者情報、詳細な年間予算情報)
・データ管理(例. 利益相反開示)
-ビジネス／金融データ(例．機密保持契約書によりカバーされる情報)

[制限対象(Restricted)] 機微性・中レベル:
一般的に公が利用できないデータまたは情報
＜データの事例>
-ビジネス／金融データ(例．機密データを含まない金融取引)
-アカデミック／研究情報(例．未公表の研究または機密データ扱いの研究詳細／結果、プライベートファンディング情報)
-管理データ(例．医療センターの投資情報)
-システム／ログデータ(例. サーバーのイベントログ)

[公開(Public)] 機微性・低レベル:
プライバシーまたは機密性が期待されないデータ
＜データの事例>
・オーナーがプライベート扱いを意図していない特定のディレクトリ／契約情報
・学生固有のもの(例．学年、キャンパス活動・スポーツへの参加)
・ビジネスデータ(例．キャンパスマップ、公開出版物リスト)

参考までに、ニューヨーク州では、2023年11月1日、同州金融サービス局(NYDFS)が、改正サイバーセキュリティ規則「23 NYCRR Part 500」(https://www.dfs.ny.gov/reports_and_publications/press_releases/pr202311011)を施行して、ビジネス／金融データに係るサイバーセキュリティ要求事項が厳格化された。州内の医療保険会社や、Healthtech／Medtechスタートアップ企業に投資するプライベート・エクイティ・ファンドも、NYDFSの監視対象である。
事例2: 米国NIHのデータ管理・共有ポリシー施行

米国立衛生研究所（NIH）は、2023年1月25日、「データ管理・共有（DMS）ポリシー」を施行した(https://grants.nih.gov/grants/guide/notice-files/NOT-OD-21-013.html)。DMSポリシーは、科学における信頼性と透明性を高めるために、研究データの利用可能性と再利用性を最大化する一方、研究データの管理・共有の規範を構築することを目的としており、NIHの研究資金を受けて、科学データを利用した研究を行うプロジェクト（米国外を含む）に適用される。

NIHは、科学データについて、「データが学術出版物をサポートするために利用されたかに関わらず、研究成果を検証し再現するために十分な品質があると、科学コミュニティに共通して受け入れられたデータ」と定義しており、研究成果を検証し、再現するために必要なすべてのデータが含まれるとしている。そしてNIHの研究資金を求める研究者に対して、以下のような要求事項を定めている。

科学データおよび付随するメタデータの管理／共有方法の概略を提示し、プロジェクトに適用される可能性がある潜在的な制限や限界を考慮したDMS計画（その他の資金調達元省庁向けのデータ管理計画と同等）を提出する
NIH内部の資金調達元研究所またはセンターが承認したデータ管理／共有計画を順守する

また、DMS計画に含まれる要素として、以下のような項目を推奨している。

データのタイプ
関連するツール、ソフトウェアおよび／またはコード
標準規格
データの保存、アクセス、関連するタイムライン
アクセス、配布、再利用の考慮事項
データ管理／共有の監視

なお、ゲノムデータを利用した研究プロジェクトについては、NIHの「ゲノムデータ共有ポリシー」（https://sharing.nih.gov/genomic-data-sharing-policy）に準拠して、以下のような対応策を講じることが推奨される

DMS計画の一部として、ゲノムデータ共有のための計画を策定し、提供する
ヒューマンデータで作業する場合、ジャストインタイムで機関認証フォームを提供する
迅速な方法で、ゲノムデータを適切なリポジトリに提出する
責任を持って、アクセス制御されたデータを利用する
発行物やプレゼンテーションでは、アクセス制御されたデータを適切に引用する

参考までに、2022年9月15日に発表された「対米外国投資委員会による国家安全保障リスクの進展に対する堅牢性の考慮の確保に関する大統領令」(https://www.whitehouse.gov/briefing-room/presidential-actions/2022/09/15/executive-order-on-ensuring-robust-consideration-of-evolving-national-security-risks-by-the-committee-on-foreign-investment-in-the-united-states/)では、特に米国の国家安全保障に影響を及ぼす領域として、マイクロエレクトロニクス、AI、バイオ技術／バイオ製造、量子コンピュータ、先進的クリーンエネルギー（蓄電池、水素など）、気候適応技術、重要な素材（リチウム、レアアース希土類元素など）、食品安全保障に影響を与える農業産業基盤の要素および米国のサプライチェーンに関する大統領令第14017号（2021年2月24日）(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/02/24/executive-order-on-americas-supply-chains/）で指定されたその他のセクターを挙げている。これらの領域で、NIHの資金助成を受けた科学データ研究プロジェクトに関わる日本の教育・研究機関や企業は、米国の国家安全保障に関する大統領令の適用範囲となる。データ侵害インシデントへの対応などを誤ると、外交問題に発展しかねないので、特に注意が必要である。

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

前編では、米国連邦政府主導で進む医療分野のゼロトラストモデル導入、サイバーセキュリティ大統領令を起点とする医療機器ライフサイクル管理へのソフトウェア部品表(SBOM)導入など、政策的な動向を紹介したが、後編では、具体的な技術的対策をめぐるCSAの取組や、最新の医療機器サイバーセキュリティ規制の動きを取り上げる。

CSAゼロトラスト成熟度モデルを医療機器管理に適用

2023年5月8日、クラウドセキュリティアライアンス（CSA）の健康医療情報管理ワーキンググループ／ゼロトラストワーキンググループ／SDPワーキンググループは、「ゼロトラストアーキテクチャにおける医療機器」(https://cloudsecurityalliance.org/artifacts/medical-devices-in-a-zero-trust-architecture/)を公開した。本文書の作成プロジェクトでは、医療産業の視点から健康医療情報管理ワーキンググループが執筆を担当し、ゼロトラストアーキテクチャの視点からゼロトラストワーキンググループ／SDPワーキンググループが成果物のレビュー作業を実施している。

参考までに、CSA本部のゼロトラストワーキンググループは、以下の9つの分科会(ZT Research Workstream)から構成されている。

1. 理念としてのゼロトラストと指導原則
2. ゼロトラストの組織的戦略とガバナンス
3. 柱(Pillar): アイデンティティ
4. 柱(Pillar): デバイス
5. 柱(Pillar): ネットワーク／環境
6. 柱(Pillar): アプリケーションとワークロード
7. 柱(Pillar): データ
8. 自動化、オーケストレーション、可視性、分析
9. ゼロトラストアーキテクチャ、実装、成熟度モデル

以下の通り、本文書は、ゼロトラストWG傘下の複数の分科会を横串にしたような構成になっている。

• 要約
• はじめに
• ゼロトラスト
• 医療機器管理プログラム
• アイデンティティ
• デバイス
• ネットワーク
• アプリケーション
• データ
• 結論
• 参考文献

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)のゼロトラスト成熟度モデルや国防総省(DoD)のゼロトラストフレームワークに基づくCSAのゼロトラスト成熟度モデルを、ゼロトラスト環境下の医療提供組織(HDO)における医療機器管理(MDM)プログラムに適用しているのが特徴だ。

まず、医療機器管理プログラムを取り巻く背景について、以下のように整理している。

1. 医療提供組織の大半は大量の医療機器をかかえているため、手作業による医療機器管理は労働集約的になる
2. 医療提供組織は、ネットワークのマイクロセグメンテーション、ポリシーの強制、脆弱性の特定、エンドポイントの検知・対応を管理するためのツールを必要としている
3. 医療機器管理プログラムは、すべての機器の可視性や在庫(ロケーションを含む)を提供するために、必要とされる
4. プログラムは、有効な認可に係る意思決定向けの機器フィンガープリンティングを含むべきであ
5. 医療機器管理向けに利用可能な特定製品があり、その中には、脆弱性やリスクを得的できるものもある
6. 選定されたツールは、医療機器エコシステムに関する包括的な視点を提供すべきである

ゼロトラスト成熟度モデルからみたセキュアな医療機器管理策

その上で、CSAゼロトラスト成熟度モデルの5つの柱(1. アイデンティティ、2. デバイス、3. ネットワーク、4. アプリケーション、5. データ)からみた、医療提供組織がゼロトラスト環境の医療機器を管理する際の留意事項を、以下のように整理している。

[1. アイデンティティ]

1. アイデンティティは、ゼロトラストアーキテクチャ成熟度モデルの第一の柱である
2. 認証、アイデンティティストア、リスク評価は、アイデンティティ成熟度モデルの機能である
3. 医療提供組織は、適正なユーザーや機器が、適正な時間、適正なリソースへアクセスすることを保証しなければならない
4. 医療提供組織は、接続された機器を認証し、個々の機器が信頼されることを保証する必要がある
5. 医療機器の通信は、マシン・ツー・マシン(M2M)であり、認証および認可のために、マシンベースのプラクティスを必要とする
6. 医療提供組織は、環境下のすべての医療機器を発見し、分類し、棚卸しするために、信頼できる手法を必要とする

[2. デバイス]

1. ゼロトラストアーキテクチャ成熟度モデルの第二の柱は、デバイスである
2. 接続された医療機器は、患者と医療提供組織を危険に晒すセキュリティ問題を提示する
3. 医療提供組織は、完全で正確な機器の発見とリスク評価、最小のアクセスポリシー、継続的モニタリングで、機器のセキュリティ課題を処理する
4. 個々の機器のセキュリティポスチャ、ネットワーク状態、ロケーション、機器の稼働率のプロファイリングなど、包括的な可視性が必要である
5. 拡張型検知・対応(XDR)は、医療提供組織全体に渡る脅威の可視性を改善し、セキュリティオペレーションを加速して、リスクを低減することを可能にする
6. 動的セグメンテーションにより、適正なセキュリティポリシーの構築を可能にし、マイクロセグメンテーションとの意味のある統合により、デプロイメント前のバリデーションを実現する

[3. ネットワーク]

1. ゼロトラストアーキテクチャ成熟度モデルの第三の柱はネットワークであり、内部ネットワーク、無線、インターネットが含まれる
2. 医療提供組織は、暗黙の信頼の代わりに、ネットワークのセグメンテーションと保護をアプリケーションワークフローと連携させる必要がある
3. IEEE 802.1X標準規格は、ポートベースのアクセス制御と、固定系・無線系ネットワークのために利用される
4. 医療機器がセキュアな認証手法を利用できない場合、MACアドレスを利用してクライアント機器を認証するために、MAC認証バイパス(MAB)が利用される
5. マイクロセグメンテーションは、セキュアなゾーンを構築して、個々のワークロードを分離し、脅威の横方向の移動を防止する
6. 医療機器管理プログラムとセキュリティ監視・対応ソフトウェアを利用してすべての医療機器のトラフィックを監視するとともに、すべてのネットワークトラフィックを暗号化すべきである

[4. アプリケーション]

1. ゼロトラストアーキテクチャ成熟度モデルの第四の柱はアプリケーションであり、アクセスの認可、脅威の保護、アクセシビリティ、アプリケーションセキュリティの機能を担う
2. 医療提供組織は、適切なセキュリティのために、保護をアプリケーションワークフローと密に統合する必要がある
3. 必要な保護: アクセス前の認証、最小の特権アクセスモデル、マイクロセグメンテーション、継続的な検証／監視、データ暗号化
4. マイクロセグメンテーションは、付与された者だけがデータ閲覧のためにアクセス可能にするとともに、不正な横方向の移動を防止することによってリスクを低減する
5. 医療機器管理プログラムとXDRによる継続的なモニタリングが、以上を検知し、対応するために要求される
6. 転送時および保存時のデータ暗号化は、アプリケーションセキュリティに不可欠である

[5. データ]

1. 第五の柱はデータであり、在庫管理、アクセス決定、暗号化の機能を担う
2. 医療提供組織は、すべてのデータ資産のセキュリティ、特定、分類、棚卸しに対して、データ中心のアプローチをとるべきである
3. 医療機器は、転送時、保存時の双方で保護しなければならないような大容量の電子保護対象保健情報(ePHI)を生成する
4. ゼロトラスト環境では、機微なデータを特定して、すべてのデータフローがマッピングされ、すべてのストレージが特定されるようにしなければならない
5. ゼロトラストアーキテクチャ内で異常検知と機械学習を利用した予測分析により、すべてのアクセスの試みをログ付けし、異常行動または疑いのある活動のための試みを分析する
6. 医療提供組織は、機器制御、コンテンツ認識型制御、強制された暗号化、データディスカバリーを提供するデータ損失保護(DLP)ソリューションを実装すべきである

今後、医療現場のクラウド化、ゼロトラスト化が進展すると、アクセス制御、ポリシーデシジョンポイント(PDP)、マイクロセグメンテーション、拡張型検知・対応(XDR)、データ暗号化、データ損失保護(DLP)といったセキュリティソリューションの位置づけや使い所も変わっていく。

米国FDAの市販前医療機器サイバーセキュリティ指針とSBOMの関係

他方、医療機器規制の領域では、2023年9月27日、米国食品医薬品局（FDA）が、「医療機器のサイバーセキュリティ管理に関わる承認申請手続の内容 – 業界および食品医薬品局スタッフ向けガイダンス」(2014年10月2日公開)の改訂版となる「医療機器のサイバーセキュリティ：品質システムの考慮事項と承認申請手続の内容 – 業界および食品医薬品局スタッフ向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions)を公開した。

今回公開した改訂版ガイダンスは以下のような構成になっている。

Ⅰ. イントロダクション

Ⅱ. スコープ

Ⅲ. 背景

Ⅳ. 一般原則

1. サイバーセキュリティは機器の安全性および品質システム規制の一部である
2. セキュリティ向けの設計
3. 透明性
4. 申請の文書化

Ⅴ. SPDF(セキュア製品開発フレームワーク)を利用したサイバーセキュリティリスクマネジメント

1. セキュリティリスクマネジメント
2. 脅威モデリング
3. サイバーセキュリティリスク評価
4. 相互運用性の考慮事項
5. サードパーティ製ソフトウェアコンポーネント
6. 未解決の異常のセキュリティ評価
7. TPLCセキュリティリスク管理
8. セキュリティ・アーキテクチャ
9. セキュリティ制御の実装
10. セキュリティ・アーキテクチャのビュー
11. サイバーセキュリティ・テスト

VI．サイバーセキュリティの透明性

1. サイバーセキュリティリスクのある機器向けラベリングの推奨事項
2. サイバーセキュリティ管理計画

附表1. セキュリティ制御の分類および関連する推奨事項

附表2. セキュリティアーキテクチャ・フロー向けの申請の文書化

附表3. 臨床試験使用機器免除（IDE）向けの申請の文書化

附表4. 一般的な市販前申請文書化の要素とリスクによるスケーリング

附表5. 用語

• ソフトウェア部品表(SBOM)の観点からみていくと、FDAは、「Ⅴ. SPDFを利用したサイバーセキュリティリスクマネジメント」の「A. セキュリティリスクマネジメント」の中で、セキュリティリスクマネジメント計画および報告書に関連して、SBOMに言及している。
• 製造業者に対し、医療機器システム向けのセキュリティリスクマネジメント活動を文書化するために、セキュリティリスクマネジメント計画および報告書を作成するよう推奨する(「AAMI(米国医療機器振興協会) TIR57 医療機器セキュリティ向け原則 – リスクマネジメント」参照)( https://webstore.ansi.org/standards/aami/aamitir572016)。
• 製造業者は、機器の安全性や有効性を示すのに役立てるため市販前申請に、セキュリティリスクマネジメント報告書(セキュリティリスクマネジメントプロセスのアウトプットを含む)を含めるべきである。セキュリティリスクマネジメント報告書は、安全性や有効性に関して合理性のある保証を示すというセキュリティリスクマネジメントプロセスをサポートするのに十分であるべきである。
• この報告書には、システム脅威モデリング、サイバーセキュリティリスク評価、コンポーネントのサポート情報、脆弱性評価、未解決の異常評価が含まれるべきである。
• 上記の文書化要素を含めることに加えて、セキュリティリスクマネジメント報告書は、以下のようにすべきである。
  • リスク評価手法およびプロセスを要約する
  • セキュリティリスク評価からの残存リスクの結論を詳述する
  • 製造業者のリスクマネジメントプロセスの一部としてとったリスク低減活動を詳述する
  • 脅威モデル、サイバーセキュリティリスク評価、SBOM、テスト文書の間のトレーサビリティを提供する

またFDAは、「A. セキュリティリスクマネジメント」の「4. サードパーティ製ソフトウェアコンポーネント」向けのツールとしてSBOMを挙げている。特にSBOMは、サプライチェーンリスク管理や、機器に組込まれたソフトウェアの特定および追跡の際に役立つツールであり、その概要および文書化に関して、以下のように記述している。

(a)ソフトウェア部品表(SBOM)

・SBOMは、ソフトウェアスタックを通して存在するサイバーセキュリティ管理で支援することができる。堅牢なSBOMには、製造業者が開発したコンポーネントとサードパーティ製コンポーネント(例.購入した／ライセンスされたソフトウェアおよびオープンソースソフトウェア)がある。

・SBOMは、ソフトウェアコンポーネントの脆弱性による影響を受ける可能性がある稼働中の機器やシステムを特定するメカニズムを提供することによって、リスク管理プロセスを容易化するのに役立つ。

・脆弱性管理は、機器のセキュリティリスクマネジメントプロセスの重要な一部なので、SBOMまたは同等の機能は、機器の構成管理の一部として維持されるべきであり、上市された機器におけるソフトウェアの変更を反映して定期的にアップデートされ、文書化されるべきである（例. 21 CFR 820.30(j) (設計履歴ファイル)や820.181 (機器マスター記録)で詳述したタイプ）。

・FDAがサイバーセキュリティに関連する安全性および有効性について、機器のリスクおよび関連するインパクトを評価する際に役立てるために、FDAは、市販前申請にSBOM文書化を含めるよう推奨する。サイバー機器の場合、SBOMが要求される(連邦食品・医薬品・化粧品法第524B(b)(3)条参照)。またSBOMは、ラベリング制度の一部として潜在的リスクのあるユーザーに対する透明性のための重要なツールとなり得る。

(b)ソフトウェア部品表をサポートする文書化

・FDAの「医療機器における汎用(OTS)ソフトウェア使用」(2023年8月)(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices)や、「汎用(OTS)ソフトウェアを含むネットワーク医療機器向けサイバーセキュリティ」(2005年1月)(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networked-medical-devices-containing-shelf-ots-software)のガイダンス文書では、製造業者がソフトウェアライフサイクルの完全な制御を主張できないソフトウェアコンポーネント向けの市販前申請において提供されるべき情報について説明している。

・製造業者は、これらのガイダンスの推奨情報に加えて、国家電気通信情報局(NTIA) の「ソフトウェアコンポーネントの透明性の枠組: 共通ソフトウェア部品表(SBOM)の確立」(2021年10月)( https://www.ntia.gov/sites/default/files/publications/ntia_sbom_framing_2nd_edition_20211021_0.pdf) で特定された最小要素(ベースライン属性)と一貫性のある機械判読可能なSBOMを提供すべきである。

・製造業者は、NTIAの最小要素に加えて、SBOMに含まれる個々のソフトウェアコンポーネントについて、以下の情報を市販前申請に含めるべきである。

-ソフトウェアコンポーネント製造業者からのモニタリングやメンテナンスを通じて提供されるソフトウェアのサポートレベル

-ソフトウェアコンポーネントのサポート終了日

・製造業者がSBOM情報をFDAに提供できない場合、製造業者は、その情報を市販前申請に含めることができない理由の根拠を提供すべきである。

・市販前申請の一部として、製造業者は、機器およびソフトウェアコンポーネントに関連するすべての既知の脆弱性(例.CISAの既知の悪用された脆弱性(KEV)カタログで特定された脆弱性)を特定すべきである。製造業者は、個々の既知の脆弱性について、評価手法が十分堅牢であったかどうかを示すために、脆弱性が発見された方法を記述すべきである。

・製造業者は、既知の脆弱性があるコンポーネントに関して、市販前申請時に以下のような情報を提供しなければならない

-個々の既知の脆弱性に関する安全性およびセキュリティリスク評価(機器およびシステムのインパクトを含む)

-脆弱性を処理するために適用可能な安全性およびセキュリティリスクのコントロール。リスクコントロールが補完的コントロールを含む場合、適切なレベルの詳細まで記述すべきである。

SBOMは医療機器のセキュリティラベリングをサポートするツール

またFDAは、サイバーセキュリティリスクのある医療機器のラベル表示をサポートするツールとして、SBOMを掲げている。たとえば、「VI．サイバーセキュリティの透明性」の「A. サイバーセキュリティリスクのある機器向けラベリングの推奨事項」では、連邦食品・医薬品・化粧品法第502(f)条で要求される適正な使用方法を含んだラベリングや、同法第502(a)(1)条に従ってラベリングが特に虚偽または誤解を招く場合に医療機器が不正表示とみなされるケースなどを例示した上で、以下のように、ラベリングの利点を整理している。

・サイバーセキュリティリスクのある機器については、ユーザーに対する重要な情報の告知が、このようなリスクに関わるラベリング要求事項を遵守する有効な方法となり得る。
・ラベリングを通じてセキュリティ情報をユーザーに告知することは、重要な設計・開発活動であり、サイバーセキュリティリスクを低減して、機器の継続的な安全性と有効性を保証するのに役立つ。
・製造業者は、市販前申請に含まれるラベリングの原案を作成する際に、すべての適用可能なラベリング要求事項や、ラベリングを通じたユーザーへの告知が、サイバーセキュリティリスクを管理し、機器の安全で有効な使用を保証するために有効な手法となるよう考慮すべきである。
・ユーザーに移転されたあらゆるリスクについて詳述し、ユーザビリティテスト中のタスクに含めるよう考慮して、ユーザーのタイプがこれらのリスクを管理するために適正な行動をとる能力があることを保証するようにすべきである。

さらに、「VI．サイバーセキュリティの透明性」の「A. サイバーセキュリティリスクのある機器向けラベリングの推奨事項」において、SBOMの有効活用を含む様々な対策を推奨している。

・意図する使用環境にとって適切な推奨されたサイバーセキュリティの制御に関連した機器の指示および製品仕様(例. マルウェア対策ソフトウェア、ファイアウォールの使用、パスワードの要求事項)。
ユーザーによる推奨されたサイバーセキュリティ制御の実装を可能にするのに十分な詳細なダイアグラム。
・データの送受信が見込まれるネットワークポートおよびその他のインタフェースの一覧表。このリストにはポート機能の説明が含まれ、認可された目的地のエンドポイントに従って、ポートが受信、送信または双方かが示される。
・機器が意図した通り稼働できるようなインフラストラクチャ要求事項のサポートに関するユーザー向けの特別なガイダンス(例. 最小限のネットワーク要求事項、サポートされた暗号化インタフェース)。必要な場合、このガイダンスには、セキュアなネットワーク展開とサービス提供を認める技術的指示と、サイバーセキュリティ脆弱性またはインシデントの検知に対応する方法に関するユーザー向けの指示が含まれる。
・「Ⅴ. SPDFを利用したサイバーセキュリティリスクマネジメント」の「A. セキュリティリスクマネジメント」の「4. サードパーティ製ソフトウェアコンポーネント」で指定された、または業界が受け入れたフォーマットに従ったSBOMにより、医療機器システムに対して特定された脆弱性の潜在的インパクトを理解し、機器の安全性と有効性を維持するための対策を導入する。製造業者は、ユーザーに対して、SBOM情報を継続的に提供するか、利用可能にすべきである。オンラインポータルを利用する場合、製造業者は、ユーザーが正確な情報を含む最新のリンクを有することを保証すべきである。SBOMは、機械判読可能なフォーマットにすべきである。
・ソフトウェアが利用可能な時にユーザーが知る方法の説明など、バージョン識別が可能な製造業者認可済バージョンのソフトウェアやファームウェアを、ユーザーがダウンロードするためのシステマチックな手順に関する説明。
・設計が、異常な状態を検知した時(例. セキュリティイベント)に機器が対応できるようにする方法の説明。これには、ユーザーに対する通知と重要な情報のロギングが含まれるべきである。セキュリティイベントのタイプは、構成の変更、ネットワークの異常、ログインの試み、異常なトラフィック(例.未知のエンティティに対するリクエストの送信)となる可能性がある。
・重要な機能(例.バックアップモード、ポート／通信の無効化)を保護する機器機能のハイレベルの説明。
・認証された構成を復元するためのバックアップ・復元機能と手順の説明。
・認証・認可されたユーザーによる機器構成の保持と復旧のための方法の説明。
・医療機器システムに対するセキュリティリスクを拡大する可能性があるような、出荷した機器のセキュアな構成、ユーザーが構成可能な変更のための指示、ユーザーが構成可能な変更の特定。セキュアな構成には、マルウェア対策、ファイアウォール／ファイアウォールのルール、許可リスト、不許可リスト、セキュリティイベント・パラメータ、ロギング・パラメータ、物理的セキュリティ検知など、エンドポイントの保護と、それらの周辺の資格情報の再設定が含まれる可能性がある。
・意図した使用環境にとって適切な場所における、セキュリティイベント向けに保持するログファイルなど、フォレンジックのエビデンスをキャプチャする方法に関する説明。ログファイルの説明には、いつ、どこで、どのようなフォーマットで、ログファイルを配置、保存、再利用、アーカイブ化すべきか、またどのようにして、自動分析ソフトウェア(例. 侵入検知(IDS)、セキュリティ情報・イベント管理(SIEM))を利用できるようにするかが含まれるべきである。
・機器セキュリティ(コンポーネントを含む)のサポート終了やライフサイクル終了に関して、既知または予測された情報。サポート終了時、製造業者は、セキュリティパッチやソフトウェア・アップデートを十分提供できない場合がある。サポート終了後のサービスで機器が維持される場合、製造業者は、エンドユーザーにとってのサイバーセキュリティリスクが時間とともに拡大すると想定されるところに焦点を当てたリスク移転のプロセスを、事前に設定し、あらかじめ伝達しておく必要がある。
・機微、機密で、独自のデータ・ソフトウェア製品の無害化により、セキュアに機器を廃止することに関する情報。

なお、医療機器に該当しない一般消費者向けIoT機器／ソフトウェアについては、連邦通信委員会(FCC)が、サイバーセキュリティラベリング制度の導入に向けた準備作業を行っており (https://www.fcc.gov/document/fcc-proposes-cybersecurity-labeling-program-smart-device) 、そこでもSBOMが重要な役割を担っている。日本でも、経済産業省の産業サイバーセキュリティ研究会のワーキンググループ3(IoT製品に対するセキュリティ適合性評価制度構築に向けた検討会)が、制度的な仕組みづくりに関する議論を行っており、日米の対応動向が注目される。

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

2023年5月8日、クラウドセキュリティアライアンス（CSA）の健康医療情報管理ワーキンググループ／ゼロトラストワーキンググループ／SDPワーキンググループは、「ゼロトラストアーキテクチャにおける医療機器」(https://cloudsecurityalliance.org/artifacts/medical-devices-in-a-zero-trust-architecture/)を公開した。ここでは、米国の医療ICTプラットフォームにおけるゼロトラストモデルや、その上で稼働する医療機器のサプライチェーンセキュリティを支えるソフトウェア部品表(SBOM)やハードウェア部品表(HBOM)の導入動向やその背景について概説する。

連邦政府主導で進む医療分野のゼロトラストモデル導入

米国で、医療機関のゼロトラストモデル導入に強い関心を示してきたのは、保健福祉省（HHS）である。たとえば、同傘下の保健医療セクターサイバーセキュリティ調整センター（HHS HC3）は、2020年10月1日に「医療におけるゼロトラスト（Report #: 202010011030）」（https://www.hhs.gov/sites/default/files/zero-trust.pdf）を公表している。その中で、ゼロトラストの定義について、2010年にフォレスターリサーチのジョン・キンダーバグ氏が提唱した概念を引用して、現在のIT環境や職場環境に取り組むために、境界防御型の城と堀のセキュリティモデルからシフトした手法だとしている。そして、デバイス、ユーザー、ワークロード、システムの全てについて、稼働する場所に関係なく、セキュリティ境界の内側、外側のいずれに関わらず、デフォルトで信頼できないものだと想定している。

HHS-HC3は、従来の境界防御型セキュリティモデルの境界を越えたゼロトラストアーキテクチャの新たなアイデンティティ境界の事例として、在宅勤務、モバイル機器、個人用機器、クラウドアプリケーション、ハイブリッドクラウド、ベンダー／外部委託先を挙げている。

将来的に、IoMT(Internet of Medical Things)、拡張現実、ロボットなどを実装した相互接続環境を想定すると、現在、多くの医療機関が利用している境界防御型セキュリティモデルがもはや有効でないことは明らかだ。医療機関が、このようなトレンドの先を行くためには、基盤投資を継続的に行いながら、「城と堀」のアプローチからゼロトラストモデルへの根本的なシフトを実行する必要があるとしている。そして、ゼロトラストモデルは、データ、ワークロード、アイデンティティに注力することによって、医療機関が、より効果的な方法でアクセスを設定する際に役立つとしている。

なおHHSは、ゼロトラストセキュリティの対象技術領域として、以下の7つを挙げている。

1. デバイス・セキュリティ
2. ネットワーク・セキュリティ
3. データ・セキュリティ
4. ワークロード・セキュリティ
5. アイデンティティ・アクセス管理
6. 可視化ツール
7. オーケストレーション・プラットフォーム

米国大統領令を起点とする連邦政府のゼロトラスト導入政策

他方、米国連邦政府全体のレベルでは、2021年5月12日に大統領行政府が発出した「国家サイバーセキュリティに関する大統領令第14028号」(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)を受けて、米合衆国行政管理予算局(OMB)が、2022年1月26日に「M-22-09米国連邦政府のゼロトラスト原則への移行」(https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf)を公表した。OMBは、HHSを含む各連邦政府機関に対し、サイバーセキュリティ・インフラストラクチャ庁(CISA)のゼロトラスト成熟度モデルversion 1 (https://www.cisa.gov/news-events/news/cisa-releases-cloud-security-technical-reference-architecture-and-zero-trust)で設定された以下の5つの領域について、2024会計年度末までにゼロトラストセキュリティの目標を達成するよう求めた。

・領域1. アイデンティティ
(目標)連邦政府機関のスタッフは、作業で利用するアプリケーションにアクセスする際に、エンタープライズ管理型のアイデンティティを利用する。
・領域2. デバイス
(目標)連邦政府は、政府利用のために運用し、認可するすべてのデバイスについて完全に在庫を把握し、これらのデバイスに関するインシデントの防止、検知、対応ができる。
・領域3. ネットワーク
(目標)各省庁は、自らの環境内におけるすべてのDNSリクエストやHTTPトラフィックを暗号化し、分離した環境に境界をブレイクダウンする計画の導入を開始する。
・領域4. アプリケーションとワークロード
(目標)各省庁は、すべてのアプリケーションをインターネット接続されたものとして取り扱い、日常的に厳格な実証試験を受けて、外部からの脆弱性報告を歓迎する。
・領域5. データ
(目標)各省庁は、完全なデータ分類を利用した保護策を展開するために、明確で共有されたパスに向かう。各省庁は、機微データへのアクセスをモニタリングするために、クラウドセキュリティサービスを有効活用して、組織全体のロギングや情報共有を展開してきた。

このような流れを受けて、HHS傘下で医療機器・医薬品を所管する米国食品医薬品局(FDA)は、2022年3月30日に「モダナイゼーション・イン・アクション2022」(https://www.fda.gov/about-fda/reports/modernization-action-2022)を公表し、最も優先度の高いテーマとして、ゼロトラストモデルの導入を掲げた。

その後2022年11月17日には、FDA傘下の情報セキュリティ室とデジタルトランスフォーメーション室(ODT)が、「サイバーセキュリティ現代化行動計画(CMAP)」(https://www.fda.gov/about-fda/office-digital-transformation/cybersecurity-modernization-action-plan)を公表した。この計画で提示した重要なアクションは以下の通りである。

• 新たなデジタルサービスと現代化の取組みを促進するために、包括的なゼロトラストアプローチを確立する。
• 開発ライフサイクルの全段階でセキュリティ対策をカバーするために、ソフトウェア保証のベストプラクティスを促進する。
• FDAおよび公衆衛生のパートナー全体に渡って、相互運用性がありセキュアなデータ交換と協力を強化する。
• 人工知能／機械学習（AI／ML）技術を活用して、サイバー検知および対応機能を強化する。カウンターインテリジェンスとインサイダーリスクの原則をゼロトラストモデルと統合して、インテリジェンス駆動型アプローチを可能にする。
• FDAのサイバーセキュリティ労働力を優先順位付けして投資する。

これらのアクションを達成することによって、CMAPは、以下のような改善点をもたらすとしている。

• カスタマーエクスペリエンスの向上
• パフォーマンスの向上
• 視界や状況認識の強化
• 脅威保護の強化
• クラウドに対するレイテンシーと速度の低減

なおクラウドセキュリティに関しては、「連邦情報セキュリティマネジメント法(FISMA）」(2002年12月制定）に基づき策定された連邦政府共通のクラウドサービス調達のためのセキュリティ基準「FedRAMP」(https://www.fedramp.gov/)が適用される。ただし国防総省傘下の各機関については、国防情報システム局（DISA）がFedRAMPに独自の要求事項を加味した「クラウドコンピューティングセキュリティ要求事項ガイド(SRG)」(https://public.cyber.mil/dccs/dccs-documents/)が適用される。

米国大統領令を起点とする医療機器ライフサイクル管理へのSBOM適用

米国立標準技術研究所(NIST)は、前述の「国家サイバーセキュリティに関する大統領令第14028号」に対応して、2021年6月2～3日に「ソフトウェアサプライチェーン強化に関するワークショップおよびポジションペーパー募集」(https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/workshop-and-call-position-papers)を公表した。

このNISTの公募に対して、FDAが2021年5月26日に回答したのが、「FDA CDRHと医療機器サイバーセキュリティ：連邦政府のサイバーセキュリティ向上に関する大統領令［第14028号］についてのNISTへの回答書」(https://www.fda.gov/media/149954/download) である。FDAの回答項目は以下の通りである。

• “重要ソフトウェア”を指定する基準
• 連邦政府調達向けの標準規格とガイドライン
• 連邦政府の重要ソフトウェア使用に適用されるべきセキュリティ対策の概要を示したガイドライ
• ソフトウェアのソースコード検証向けの初期における最小限の要求事項
• ソフトウェアのインテグリティチェーン・来歴向けガイドライン

このうち「2. 連邦政府調達向けの標準規格とガイドライン」の中で、FDAが、国際医療機器規制当局フォーラム(IMDRF)や共同セキュリティ計画(JSP)と協力して、グローバルな医療機器規制フレームワーク全体に渡ってサイバーセキュリティをハーモナイズし、一貫性をもたらすことを意図したプロジェクトが、ソフトウェア部品表(SBOM)である。その活動の成果物が、IMDRFの「医療機器サイバーセキュリティ向けソフトウェア部品表(SBOM)の原則と実践」(https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity)や、JSPの「医療機器とヘルスITの共同セキュリティ計画」(https://healthsectorcouncil.org/wp-content/uploads/2021/11/HSCC-MEDTECH-JSP-v1.pdf)である。

さらにFDAは、2023年9月27日、「医療機器のサイバーセキュリティ：品質システムの考慮事項と承認申請手続の内容 – 業界および食品医薬品局スタッフ向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions)を公開した。これは、FDAは2014年10月2日に公開した「医療機器のサイバーセキュリティ管理に関わる承認申請手続の内容 – 業界および食品医薬品局スタッフ向けガイダンス」の改訂版であり、以下のような構成になっている。

Ⅰ. イントロダクション
Ⅱ. スコープ
Ⅲ. 背景
Ⅳ. 一般原則
A. サイバーセキュリティは機器の安全性および品質システム規制の一部である
1. セキュア製品開発フレームワーク(SPDF)がQS規制を満たす手段の1つとなる可能性がある
B. セキュリティ向けの設計
C. 透明性
D. 申請の文書化
Ⅴ. SPDFを利用したサイバーセキュリティリスク管理
A. セキュリティリスク管理
1. 脅威モデリング
2. サイバーセキュリティリスク評価
3. 相互運用性の考慮事項
4. サードパーティ・ソフトウェア・コンポーネント
5. 未解決の異常のセキュリティ評価
6. TPLCセキュリティリスク管理
B. セキュリティ・アーキテクチャ
1. セキュリティ制御の実装
2. セキュリティ・アーキテクチャのビュー
C. サイバーセキュリティ・テスト
VI．サイバーセキュリティの透明性
A. サイバーセキュリティリスクのある機器向けラベリングの推奨事項
B. サイバーセキュリティ管理計画
附表1. セキュリティ制御の分類および関連する推奨事項
A. 認証
B. 認可
C. 暗号化
D. コード、データ、実行整合性
E. 機密性
F. イベント検知とロギング
G. 強靭性と復旧
H. ファームウェアとソフトウェアのアップデート
附表2. セキュリティアーキテクチャ・フロー向けの申請の文書化
A. ダイアグラム
B. アーキテクチャ・ビュー向けの情報の詳細
附表3. 臨床試験使用機器免除(IDE)向けの申請の文書化
附表4. 一般的な市販前申請文書化の要素とリスクによるスケーリング
附表5. 用語

ソフトウェア部品表(SBOM)の利用については、「VI．サイバーセキュリティの透明性」の「A. サイバーセキュリティリスクのある機器向けラベリングの推奨事項」、附表2の「B. アーキテクチャ・ビュー向けの情報の詳細」、「附表4. 一般的な市販前申請文書化の要素とリスクによるスケーリング」で取り上げている。

消費者IoTサイバーセキュリティラベリング制度も起点は米国大統領令

なお、前述の「国家サイバーセキュリティに関する大統領令第14028号」では、NISTに対し、消費者向けIoT機器およびソフトウェア開発プラクティスのサイバーセキュリティ機能に関する自主的なラベリングプログラムづくりに着手するよう指示していた。これを受けたNISTは、連邦取引委員会(FTC)と連携しながら、2022年2月4日、「消費者向けIoT製品のサイバーセキュリティラベリングに関する推奨基準」（https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.pdf）および「消費者向けソフトウェアのサイバーセキュリティラベリングに関する推奨基準」(https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-1.pdf)と題するホワイトペーパーを公表している。

「消費者向けIoT製品のサイバーセキュリティラベリングに関する推奨基準」は、以下のような構成になっている。

1．イントロダクション
1.1 背景
1.2 スキームとスキームオーナー
1.3 文書のスコープと目標
1.4 文書の構造
2．ベースライン製品基準
2.1 IoT製品のスコープ
2.2 推奨されるベースライン製品基準
2.3 推奨される基準に関連するIoT製品の脆弱性
2.4 リスク、仕立て、層化における考慮事項
2.5 既存の標準規格、プログラム、スキームの活用
2.6 ハーモナイゼーションの考慮事項
3．ラベルリングの考慮事項
3.1 推奨されるラベリングのアプローチ
3.2 ラベリングの表現
3.3 消費者教育
4．適合性評価の考慮事項
参考文献

　他方、「消費者向けソフトウェアのサイバーセキュリティラベリングに関する推奨基準」は、以下のような構成になっている。

1．イントロダクション
1.1 背景
1.2 文書のスコープと目標
1.3 ラベリングスキームとスキームオーナー
1.4 文書の構造
2．消費者ソフトウェアラベリング向けベースライン技術基準
2.1 手法
2.2 推奨される基準
3．ラベリング基準
3.1 バイナリラベリング
3.2 階層化アプローチ
4．適合性評価基準
参考文献
附表A – ラベリング基準の追加コンテキスト
附表B – 省略されたSSDFの例

これらの推奨基準策定作業に先立って、2021年7月12日、商務省傘下の国家電気通信情報庁（NTIA）が、大統領令第14028号を受けた「ソフトウェア部品表（SBOM）向けの最小要素」(https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom)を公表し、 2022年2月3日、NISTが、「SP 800-218 セキュアソフトウェア開発フレームワーク(SSDF)第1.1版」(https://csrc.nist.gov/pubs/sp/800/218/final)を公表している。SBOMやSSDFは、消費者向けIoT製品および消費者向けソフトウェア双方のサイバーセキュリティラベリング推奨基準の共通開発フレームワーク／コンポーネントとして組み込まれている。

その後大統領行政府は、2023年7月18日、消費者向けIoT製品および消費者向けソフトウェア向けのサイバーセキュリティラベリング制度を来年より正式に導入することを発表した(https://www.whitehouse.gov/briefing-room/statements-releases/2023/07/18/biden-harris-administration-announces-cybersecurity-labeling-program-for-smart-devices-to-protect-american-consumers/)。

連邦政府機関が急ピッチで進めるゼロトラストモデルの導入も、医療機器や消費者向けIoT製品・ソフトウェア向けサイバーセキュリティラベリング制度を支えるSBOMのいずれも、大統領令第14028号を起点としており、米国市場で事業を展開する医療機器企業やデジタルヘルス企業は、迅速な対応が求められている。

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

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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司