前編に引き続き、クラウドセキュリティアライアンス（CSA）のヘルス・インフォメーション・マネジメント・ワーキンググループ（HIM-WG）が、2021年10月15日に公開した「医療における情報技術のガバナンス、リスク、コンプライアンス」（https://cloudsecurityalliance.org/artifacts/information-technology-governance-risk-compliance-in-healthcare/）を概説する。

データライフサイクルを起点とする医療のセキュリティリスク管理

前編で取り上げたように、医療提供組織は、データライフサイクルの6ステージを起点として、リスク管理を行うことになる。

1. 生成：新たなデータが生成された時または既存のデータが修正された時
2. 保存：データは、ストレージのレポジトリに関わる
3. 利用：どんな活動でも、データを処理、閲覧または利用する時
4. 共有：データや情報を他者がアクセスできるようにする
5. アーカイブ：長期ストレージに置かれたデータ
6. 破壊：データが必要なくなった時、物理的に破壊する

この文書では、リスクについて、金銭的損失の可能性と捉えており、イベントが収益の減少をもたらす確率だとしている。サイバーセキュリティリスクは、ビジネスリスクのサブセットであり、ビジネス用語で語るべきものだとしている。医療提供組織にとって、情報リスクは組織的リスクの一部であり、その制御の目的はリスクの低減にある。ただし、100％安全な情報システムは存在しないので、受容できるレベルまでリスクを最小化することが目標になる。

リスク選好度（Risk Appetite）／リスク許容度（Risk Tolerance）

リスク選好度は、組織がリスクに対して有する許容範囲であり、組織がどの程度のリスクを受け入れられるか、組織がリスクを管理するためにどの程度の投資や支出ができるかが焦点になる。他方、リスク許容度は、組織が受け入れ可能なリスクの程度または不確実性の程度であり、組織的なリスクの枠組みの不可欠な要素である。組織のリスク許容度のレベルは、受け入れ可能なレベルまでリスクをとれるデータやシステムの量で決まる。明確なリスク許容度のレベルがあれば、経営層が、機密性、完全性、可用性の侵害に対する保護に関して、セキュリティプログラムで組織に要求するレベルを理解していることを意味するとしている。

脅威（Threats）

脅威は、情報の不正アクセス、破壊、開示および／またはサービス拒否（DoS）を介したシステムを通じて、組織の業務や資産、個人またはその他の組織にマイナスの影響を及ぼす可能性がある状況やイベントのことである。医療提供組織は、脅威イベントを理解することによって、特定の脅威ソースに関連する機能を検討することができ、潜在的な攻撃の意図や標的を知ることによって、最も関連する脅威イベントに絞り込むことができるとしている。

脆弱性（Vulnerability）

脆弱性は、脅威ソースにより悪用される可能性がある情報システムやシステムセキュリティ手順、内部統制、実装の弱点である。脆弱性があるからといって攻撃者が利用するとは限らないし、悪用がなければ潜在的な問題にとどまる。情報システム内にある脆弱性は、組織的なガバナンス構造、環境、外部との関係を通じて発見することができる。脆弱性の例としては、以下のようなものがある。

1.  物理的：施錠していないスイッチのある部屋
2. 環境的：洪水
3. 外部との関係：通信障害

イベントが脆弱性を利用するとリスクが発生する。医療提供組織は、脅威モデルを利用して、脅威ソースが脆弱性を悪用する方法を示すことが必要である

発生可能性（Likelihood）

発生可能性は、イベントが発生する確率であり、確率は不確実なイベントの発生可能性または機会である。リスク分析において、脆弱性を悪用する脅威の発生可能性を決定する際には、複数の要因を考慮する。リスク分析者は、脅威インテリジェンスをレビューして、発生確率を決定する際に、脅威の能力、動機づけ、悪用可能性、実装されたこの情報を制御および利用を理解する。分析者は、発生確率を推計するために、以下のような質問に答える必要がある。

1. 悪用は可能か？
   1. 悪用を実行するためには、どんな技術的スキルが要求されるか？　技術的スキルがなくても、誰かが実行できるか、それとも高度なスキルが必要か？
   2. 悪用は、遠隔で実行できるか？
2. 動機は何か？
   1. 活動家からの脅威は？
   2. 悪用は利益のためか？
3. 脆弱性を低減するために、制御を設定しているか？

このような質問への回答により、分析者は悪用の確率を理解できる。本文書では、以下のような数値を評価に当てはめて定量化する手法を提示している。

• 数値：相対的評価指標（説明）
• 0.1：非常に低い（可能性が非常に低い）
• 0.3：低い（可能性が低い）
• 0.5：中程度（やや可能性がある）
• 0.7：高い（可能性が高い）
• 0.9：非常に高い（ほぼ確実）

参考までに、医療における定量的なリスク管理については、米国保健福祉省（HHS）傘下の保健セクター・サイバーセキュリティ調整センター（HC3）が、「医療サイバーセキュリティ向けの定量的なリスク管理」（2020年5月7日）（https://www.hhs.gov/sites/default/files/quantitative-risk-management-for-healthcare-cybersecurity.pdf）を公表している。

影響度（Impact）

確率に加えて重要なファクターが影響度であり、リスクを分類して優先順位付けするのに役立つ。中には、影響度が高いがまれにしか起きないリスクがあり、中程度の影響度だが頻繁に起きるリスクがある。もし、脅威が現実化すれば発生し得る害の大きさが、脅威の影響度である。

医療提供組織は、侵害のように、潜在的に不利益な行動によって影響を受ける方法を明確に定義すべきである。そして、影響を受けたデータに基づいて影響度を決定すべきであるとしている（例．公的に開示可能な情報を含むシステムへの影響度は、機微情報を含むシステムへの影響度よりも小さい）。

リスクプロファイル（Risk Profile）

情報リスクプロファイルには、発生確率が相当高く、それが実現すると保健医療組織の業務に重大な影響を示すような特定の情報リスクファクターに関する現状分析が含まれるべきである。また、リスクの説明は、簡潔で、ビジネスおよび技術双方のリーダーに認識・理解できる言葉で表現されるべきだとしている。

現状の説明には、医療提供組織のリスク管理に対する見方や期待、要求事項（例．ビジネスリーダーやステークホルダーの意見、情報リスク・セキュリティに対する見方、現在のビジネス状況の説明、現在の脅威・脆弱性分析の結果、外部ステークホルダーの期待）を含めるべきであるとしている。

また、医療提供組織には数多くのビジネスプロセスがある反面、それらを保護するリソースや帯域幅には限界があるので、情報リスクプロファイルの中で、業務に重大な影響を及ぼす可能性があるような、最も重要なビジネスプロセスやケーパビリティを特定することが不可欠だとしている。

情報を保護する費用は価値を越えるべきでないというのが、情報リスク管理の基本原則である。情報リスクプロファイルは、データ資産の適正価値を定量化する必要はないが、適正なレベルの分類や制御を定義できるように、一般的な値の説明を作成する必要がある。

情報管理を簡素化するためには、データ処理の要求事項を特定する制御目標や責務に関連した、理解しやすいコンテナに分類することが不可欠である。このための分類スキーマは、情報リスクプロファイルや一般的な医療提供組織の活動に役立つように、できるだけ簡単であるべきである。情報リスクプロファイルには、医療提供組織のデータ分類スキーマと、制御の要求事項および関連する目標の概要を含むべきであるとしている。

参考までに、具体的なサイバーセキュリティ／プライバシー制御に係るリスク管理については、米国標準技術研究所（NIST）の「SP 800-53A Rev. 5 情報システムと組織におけるセキュリティ／プライバシー制御の評価」（2022年1月25日）（https://csrc.nist.gov/publications/detail/sp/800-53a/rev-5/final）で詳述している。

法令遵守／コンプライアンス（Compliance）

医療の法令遵守は、すべての法的、倫理的、専門的な標準規格を充足するための継続的なプロセスである。すべての医療提供施設は、機密の保健医療情報を取扱うので、米国の医療保険の携行性と責任に関する法律（HIPAA）や欧州連合（EU）の一般データ保護規則（GDPR）に準拠したポリシーの策定・統合が要求される。加えて、医療提供組織は重要インフラに該当するので、データのロケーションや越境移転に関連する法規制を注視する必要がある。

また米国では、新型コロナウイルス感染症（COVID-19）パンデミック緊急対応時に、ホワイトハウスや保健福祉省傘下のメディケア・メディケイド・サービス・センター（CMS）が、医療施設への訪問なしで医師からの医療サービスが受けられる遠隔医療へのアクセス拡大を促進する施策をとった。医療提供組織のサイバーセキュリティポリシーや手順は、このような変化も反映させるべきだとしている。

ここでは、HIPAA規則の遵守項目として、以下のような例を挙げている。

＜リスク評価の実施＞
1. プロジェクトリスク評価を実施する
2. 処理・保存・転送するHIPAAデータを特定する
3. 脆弱性、脅威、リスクを特定する
＜暗号化＞
4. いかなる期間も保護対象保健情報（PHI）を保持する場合、暗号化する
＜システム構成＞
5. PHIにアクセスするシステムはすべて、利用前にハードニングしなければならない
＜ソフトウェア開発プロセス＞
6. アプリケーション開発を内製化する時は、厳格な開発プロセスやセキュアなコーディングガイドラインを利用する
＜セキュアなユーザーアクセス＞
7. すべてのアクセスが固有のアカウント情報を要求することを保証する
8. ソフトウェア展開のアクセス制御を保証する
9. すべての遠隔アクセスに多要素認証が利用されることを保証する
＜ソフトウェアテスト＞
10. 脆弱性スキャニングを実行する
11. ペネトレーションテストを実行する

医療機関の外部委託先としてのクラウド事業者への要求事項

なお、医療提供施設におけるクラウド利用時のセキュリティ／プライバシー対策については、米国保健福祉省（HHS）が、「HIPAAとクラウドコンピューティングに関するガイダンス」（2016年10月7日）（https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html）を公開している。同ガイダンスはQ&A形式で、以下のような構成になっている。

1. HIPAAの適用対象主体（CE）または事業提携者（BA）は、電子保護対象保健情報（ePHI）を保存または処理するために、クラウドサービスを利用可能か？（回答＝Yes）
2. クラウドサービスプロバイダー（CSP)が暗号化されたePHIのみを保存し、復号化鍵を持たない場合、それはHIPAAの事業提携者か？（回答＝Yes）
3. CSPを、郵便サービスのような「導管」であり、従ってHIPAA規則の遵守義務がある事業提携者でないと考えることはできるか？（回答＝No）
4. どのCSPが、HIPAA遵守のクラウドサービスを提供しているか？（回答＝NA）
5. HIPAAの適用対象主体(または事業提携者）が、最初にCSPとの間で事業提携契約書（BAA)を締結することなく、CSPを利用してePHIを維持した場合、どうなるか？（回答＝NA）
6. CSPが、HIPAAの適用対象主体または事業提携者のePHIを含むセキュリティインシデントを経験した場合、そのインシデントを適用対象主体または事業提携者に報告しなければならないか？（回答＝Yes）
7. HIPAA規則は、クラウド上でePHIにアクセスするために、医療提供者がモバイル機器を利用することを認めるか？（回答＝Yes）
8. HIPAA規則は、適用対象主体または事業提携者向けサービスの提供を終了した後の一定期間、CSPに対して、ePHIの維持を要求するか？（回答＝No）
9. HIPAA規則は、適用対象主体または事業提携者が、米国外のサーバー上にePHIを保存するCSPを利用することを認めるか？（回答＝Yes）
10. HIPAA規則は、事業提携者であるCSPに対し、適用対象主体または事業提携者である顧客のセキュリティプラクティスについて、文書化の提供を要求したり、監査を認めたりするか？（回答＝No）
11. CSPが、HIPAAプライバシー規則に従って非識別化された情報のみを受け入れ維持する場合、それは事業提携者に該当するか？（回答＝No）

加えて、事業提携者としてのCSPに対するアクセス制限に関連して、以下のような留意点を挙げている。

• 顧客がePHIへのアクセスを認証する責任を有すると両者間で同意していても、CSPに対して、情報システムの運用に重要なリソース（例：ストレージ、メモリ、ネットワークインタフェース、CPU）を管理する管理ツールへの認可されたアクセスだけを保証するために、適切な内部制御の実装を求める可能性がある。
• 事業提携者であるCSPは、リスク分析およびリスク管理プロセスの一部として、システム運用に影響を及ぼし、顧客のePHIの機密性、完全性、可用性に影響を及ぼす可能性がある、システム管理ツールへの不正アクセスの悪意ある行為者のリスクを考慮して処理する必要がある。
• CSPは、パッチを当てていない時代遅れの管理ツールを利用するリスクを考慮する必要がある。
• 各自がセキュリティ規則の要求事項に取り組む方法について、事業提携契約書またはその他の文書のいずれかの書面で確認する必要がある。

評価（Measurement）

ビジネスプロセスと同様に、評価も最重要のテーマである。コンプライアンス報告書は、コンプライアンス活動において、医療提供組織内で規制や内部統制を効果的に充足する領域やそうでない領域を明確化するものである。コンプライアンス指標や重要業績評価指標（KPI）は、医療提供組織の組織的ポリシー（内部および外部）や政府規制と協調する能力を評価するものである。

通常のコンプライアンス機能としては、内部監査、コンプライアンストレーニング、ポリシー強制、リスク管理、コンプライアンスKPIなどがある。このようなことを知ることによって、医療提供組織のリーダーシップが、リソースの割当や、リスク管理、将来の戦略的計画に関する効果的な意思決定を行うことができるとしている。

モニタリングと報告書作成（Monitoring and Reporting）

モニタリングは、基礎的なレベルで、組織の業務が進むべき方向に機能していることを保証するものである。加えてモニタリングは、法令を遵守していない領域を特定することができる。モニタリングは、コンプライアンスのパフォーマンスまたはその他のプロセスを強化するために不可欠な最初のステップであり、コンプライアンスの現状の理解は重要なスタート地点となるとしている。

他方、報告書作成手法には、NISTサイバーセキュリティフレームワーク（CSF）（https://www.nist.gov/cyberframework/framework）やプライバシーフレームワーク（PF）（https://www.nist.gov/privacy-framework）を利用した、医療提供組織における現状のプライバシーおよびセキュリティのポスチャの特定が含まれる。このプロセスを通じて、医療提供組織は、現在のポスチャ（As-Is）と将来のポスチャ（To-Be）を比較することが可能になる。2つのフレームワークは、医療提供組織が、ビジネス要求事項、リスク許容度、リソースを装備して、プライバシーおよびセキュリティの活動を調和させ、優先順位付けをするのに役立つ。また、標準規格、ガイドライン、有効なプラクティスを組み合わせることによって、プライバシーとセキュリティにアプローチするための共通ストラクチャを提供する。このようにして、医療提供組織のリーダーシップ向けに、標準的な報告書作成手法を提供するとしている。

医療クラウドにおけるGRCの管理手法

ガバナンス、リスク、コンプライアンス（GRC）のポリシーが有効であることを保証するために、医療提供組織は、最初に、適用される法律や規制を理解する必要がある。コンプライアンスからスタートすることによって、確固たる基盤を持ったプログラムの構築を確実なものにする。

第２ステップとして、包括的なリスク評価とギャップ分析を実行する。リスク分析では、医療提供組織が、(1) コンプライアンスの要求事項を充足する、(2) 適切なセキュリティを提供する の2点についてどう表現しているかが焦点になる。リスクとコンプライアンスのギャップを完全に認識したら、医療提供組織は、組織的ポリシーや手順の欠点に取り組んでいることを保証すべきだとしている。本文書では、例として、「NIST SP 800-53 連邦政府情報システムおよび連邦組織のためのセキュリティ管理策とプライバシー管理策」（https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final）を参照している。

医療提供組織は、同様のプロセスに従って、この制御に関連するプライバシーポリシーを作成する。このプロセスでは、コンプライアンス要求事項、セキュリティおよびコンプライアンスの双方を提供するセキュリティ制御、制御を実装するためのポリシーを有する。最後のステップは、ポリシーがビジネスミッションと整合している点を保証することである。今日の競争的な医療環境では、ITオペレーションとビジネス戦略およびITリスク管理の連携が責務となっている。ITガバナンスは、ITミッションの連携を達成する手法だと言える。

なお、クラウドセキュリティアライアンスは、2010年11月17日、CloudAudit、Cloud Controls Matrix（CCM）、Consensus Assessments Initiative Questionnaire（CAIQ）の3つから構成される「GRC Stack」を公表している（https://cloudsecurityalliance.org/press-releases/2010/11/17/cloud-security-alliance-unveils-governance-risk-management-and-compliance-grc-stack/）。

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