コンフィデンシャルコンピューティングとクラウドデータセキュリティ

CSAジャパン理事 諸角昌宏
2023/2/5

本ブログは、最近注目を集めているコンフィデンシャルコンピューティングについて、クラウドのデータセキュリティの観点から説明する。特に、クラウド環境での暗号化の基本である利用者鍵管理との関係について触れる。

  1. コンフィデンシャルコンピューティングとクラウドデータセキュリティ
    コンフィデンシャルコンピューティングの詳細については、様々な資料や情報が出ているのでそちらを参照していただくとして、ここではクラウドのデータセキュリティの観点からコンフィデンシャルコンピューティングを説明する。

    コンフィデンシャルコンピューティングを推進しているConfidential Computing Consortium(CCC)では、「ハードウェアベースの信頼できる実行環境Trusted Execution Environment(TEE)で計算を実行することで使用中のデータを保護する」と定義している。そうすると、コンフィデンシャルコンピューティングによって、利用者はデータがどのように保護されているかを気にしなくてもすむようになる。

    これを、クラウドにおけるデータセキュリティの観点で説明すると以下のようになる。
    クラウド(だけではないが)でのデータセキュリティを考える場合、以下の3つのデータの状態を考慮する必要がある。

    • 保存中のデータ(Data At Rest)
    • 移動中のデータ(Data In MotionあるいはData In Transit)
    • 使用中のデータ(Data In Use)

データを保護するためには暗号化が重要な技術となる。暗号化することで、マルチテナント環境における隔離を超えたアクセスや不正アクセスに対してデータを保護することができる(情報を保護するといった方が正しいが、ここではデータと情報を特に区別しない)。これらの3つの状態において、保存中と移動中のデータに対しては暗号化を行うことができるが、使用中のデータには暗号化を行うことができない。それは、アプリケーションが暗号化されたデータを処理することができないためで、アプリケーションが処理を行うためには暗号化されたデータは必ず復号する必要がある。クラウドにおいてはこれが特に問題となる。クラウド上のアプリケーションは仮想マシンなどの仮想環境で動作しているのがほとんどであるため、ハイパーバイザや仮想マシンを狙った攻撃により、暗号化されていない使用中のデータが狙われる可能性がある。コンフィデンシャルコンピューティングでは、この使用中のデータを保護するため、プロセッサ上の隔離された環境でプログラムを実行し、データに不正アクセスしたり書き換えたりすることができないようにしている。これにより、使用中のデータを保護することが可能になる。

このように、コンフィデンシャルコンピューティングにより、データの3つの状態のすべてにおいてデータを保護することが可能になる。すでにAWS, Azure, Google等で採用されているように、コンフィデンシャルコンピューティングを提供することはクラウドサービスプロバイダにとって重要なこととなると思われる。

  1. コンフィデンシャルコンピューティングと利用者鍵管理

    クラウドにおけるデータ保護としてもう1つ考慮する必要があるのが鍵の管理である。これは、データの暗号化に使用される鍵の管理方法の問題で、クラウドにおいては利用者が鍵を管理することが必要である。それは、プロバイダが鍵を保持した場合、クラウド側のインサイダー(管理者)による情報侵害などの問題を引き起こすからである。一方、利用者が鍵を保持した場合、アプリケーションがそのデータを処理できないという問題が発生する。特にSaaS環境においてはこの問題に直面する。そこで用いられているのが、「利用者鍵管理」という方法で、プロバイダが暗号化エンジンを管理するのに対して、利用者が自身の鍵を管理できるようにする仕組みである。BYOKやHYOKという言葉を耳にすることも多いだろう。この詳細については、以下のブログを参照していただきたい。
    https://cloudsecurityalliance.jp/newblog/2022/02/09/%e3%83%87%e3%83%bc%e3%82%bf%e3%81%ae%e6%9a%97%e5%8f%b7%e5%8c%96%e3%81%ab%e3%81%8a%e3%81%91%e3%82%8b%e5%88%a9%e7%94%a8%e8%80%85%e9%8d%b5%e7%ae%a1%e7%90%86%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/

    利用者鍵管理では、一時的にせよプロバイダが鍵を保持することになる(一時的というのは、実装の仕方は様々なのでこの言い方を取る)。また、その鍵を使用して復号し、アプリケーションが処理を行うことになる。したがって、使用中のデータに対する保護はできない。
    一方、コンフィデンシャルコンピューティングでは、使用中のデータの保護はできるが、アプリケーションが処理した後のデータの保存時の暗号化を行うことはできない、というか、暗号化はプロバイダが管理する鍵を用いて行うしかない。そうすると、コンフィデンシャルコンピューティングを利用したとしても、引き続き利用者鍵管理は必要となると考えられる。

  2. まとめ

    使用中のデータの保護と保存時のデータの暗号化を両立させる方法としては、完全準同型暗号が解となる。完全準同型暗号については、先のブログに記載しているのでそちらを参照していただきたい。しかしながら、完全準同型暗号が一般的に利用されるようになるまでにはまだ時間がかかりそうである。
    コンフィデンシャルコンピューティングは、使用中のデータの保護として非常に重要な技術であり、引き続き理解を深めていく必要がある。また、利用者鍵管理も引き続き必要となるし、特に、ISMAP等の要求事項となっているので、こちらの理解も深めていく必要がある。

以上

 

バイオ/医療データの相互運用性とプライバシーエンジニアリング技術(前編)

米国のバイオ/医療領域では、クラウドサービスの利用が拡大するとともに、様々な機器やシステムから集約されるデータの利活用やリスク管理における前提条件として、相互運用性の標準化動向に注目が集まっている。

CSAが医療データの相互運用性に関するレポートを公開

クラウドセキュリティアライアンス(CSA)のヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2022年9月26日に「医療の相互運用性」(https://cloudsecurityalliance.org/artifacts/healthcare-interoperability/)を公開している。「相互運用性(Interoperability)」という言葉は、医療ITシステムが相互に継ぎ目なくデータを交換する場合に参照される。受け取った電子健康記録(EHR)が読み取り可能で受け入れられることを認識したところで、標準化されたフォーマットを利用して情報を移転させる時、相互運用性が発生する。本文書では、共有するデータが、受け取る側の医療機関にとって、正確にデータを表現するコンテンツとコンテキストについての十分な評価を有することを目標としている。このようなデータは、正確な患者ケアだけでなく患者安全にとっても、非常に有益である。

「医療の相互運用性」は、以下のような構成になっている。

  • 謝辞
  • 要約
  • イントロダクション
  • 相互運用性
  • 相互運用性の現状
  • クラウドにおける相互運用性
  • 今後の進め方
  • 結論
  • 参考文献

CSA-HIM WGは、相互運用性について。「情報を交換し、交換した情報を利用するための2つ以上のシステムまたはコンポーネントの能力」と定義している。言い換えると、相互運用性は、異なるタイプの情報通信技術(ICT)システムが、読み取り可能で使えるフォーマットで、データを正確に、効率的に、一貫して交換する能力である。この文書では、相互運用性について、以下の4つのレベルを提示している。

  1. 基礎的(レベル1):システムまたはアプリケーションが、安全にデータを伝達し、他からのデータを受け取るための相互接続性を定義する
  2. 構造的(レベル2):解釈のためのデータフィールドのレベルなど、データ交換のフォーマット、構文、組織を定義する
  3. 意味的(レベル3):公に入手可能な値設定やコーディングの語彙からの標準化された定義を持つデータ要素の利用など、共通の基本的モデルやデータの成文化のために提供し、理解の共有やユーザーに対する意味を提供する
  4. 組織的(レベル4):組織や主体、個人の内部や相互間の、安全で、継ぎ目のない、タイムリーなデータ通信を促進するためのガバナンスやポリシー、社会的、法的、組織的な考慮事項を含む

電話に匹敵するようなレベルの総合運用性が医療に適用できれば、誰が機器やシステムを作ったか、どこに設置されているかに関わらず、医療機関がやりとりできる機能を持つことができる。加えて、医療機器からのデータを直接EHRにとりこむことができれば、患者のアウトカムや患者安全に様々なベネフィットを提供することができる。

「医療の相互運用性」では、EHRのユースケースとして、以下のような事例を挙げている。

  • 医療機関は、異なるEHRを利用する可能性がある他の医療機関に記録を送付する機能が必要である。データの構造と完全性を維持しながら、この種の転送を遂行しなければならない。
  • 外部ソースからのEHRコピーの要求と、オリジナルの詳細を保持するような標準的なフォーマットによる記録の返却。
  • 標準的なフォーマットによるHIEへの情報提供により、医療機関が他の医療機関からの患者記録の閲覧を可能にする。これには、患者の病歴を有する医療機関が含まれ、アウトカムの改善における重要な要因となる。

米国政府による医療データの相互運用性標準化推進策

なお、米国保健福祉省(HHS)は、病院の医療情報へのアクセス向上を通じで患者に権限を付与するとともに患者の電子健康記録へのアクセスを改善し、供給者が簡単に患者との時間を費やせるようにすることを目的とした「相互運用性の促進(Promoting Interoperability)」ルールの標準化を推進している。

その一環としてHHSは、2020年3月9日、「国家医療IT調整室(ONC)21世紀治療法最終規則(ONC規則)」 (https://www.hhs.gov/about/news/2020/03/09/hhs-finalizes-historic-rules-to-provide-patients-more-control-of-their-health-data.html)と「メディケア・メディケイド・サービス・センター(CMS)相互運用性および患者アクセス最終規則(CMS規則)」 (https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index)を公表している。ONC規則では、国際HL7協会が策定した電子保健医療情報の相互運用性に関わる標準規格であるHL7 FHIR(Fast Healthcare Interoperability Resources)4.0.1版を採用し、認証電子健康記録技術プログラムの一部であるアプリケーション・プログラミング・インタフェース(API)の利用を支援することによって、患者が、スマートフォンを利用しながら、医師のEHRから、重要な医療情報にアクセスすることを可能にするとしている。また、CMS規則では、規制対象となるすべての保険者が、患者アクセスAPI経由で請求・照合データの患者による利用(PHR)を可能にすることによって、患者が必要な時に必要な方法でPHRを利用しながら、医療におけるよりよい意思決定者や知識に基づくパートナーとなることを促進するとしている。一般のデジタルヘルススタートアップ企業でも、HL7 FHIR ベースで電子医療記録(EMR:Electric Medical Record)やEHRとデータ連携すれば、経済インセンティブの恩恵を受けられることから、相互運用性標準化の加速要因となっている。

このような動きと並行して、ONCは、2020年10月30日、「2020-2025年連邦医療IT戦略計画」(https://www.healthit.gov/topic/2020-2025-federal-health-it-strategic-plan) を公表している。2020-2025年計画では、以下のようなビジョンとミッションを掲げている。

  • ビジョン:情報を利用して、個人を関与させ、費用を低減し、高い品質のケアを提供し、個人および全住民の健康を向上させる健康システム
  • ミッション:それが最も重要な時や場所で、アクセス可能な技術・健康情報を利用して、個人やコミュニティの健康とウェルビーイングを向上させる

その上で、以下のような目標および目的から成るフレームワークを提示している。

目標1:保健とウェルネスを促進する

目的1a:個人の利用可能な保健情報へのアクセスを向上させる
目的1b:医療ITを通じて健康で安全なプラクティスを進化させる
目的1c:保健と福祉サービスの情報を統合する

目標2:ケアの提供と経験を強化する

目的2a:医療ITを活用して臨床プラクティスを向上させ、安全で高品質のケアを促進する
目的2b:医療ITを利用して、アクセスを拡張し、患者をケアにつなぐ
目的2c:医療における競争、透明性、負担可能性を育む
目的2d:提供者における規制や管理の負担を低減する
目的2e:医療ITリソースの効率的管理と、自信を持って医療ITを利用した国全体の労働力を可能にする

目標3:研究とイノベーションを加速させるためにセキュアなデータ駆動型エコシステムを構築する

目的3a:個人および人口レベルの保健データ移転を進化させる
目的3b:個人および人口レベルで医療ITとデータを利用した研究と分析を支援する

目標4:医療を健康データとつなぐ

目的4a:医療IT機能の開発と利用を進化させる
目的4b:データ共有への期待を創出する
目的4c:技術と通信のインフラストラクチャを強化する
目的4d:個人のプライバシーを保護するセキュアな保健情報プラクティスを促進する

バイオ/医療R&Dで重視されるAPIと相互運用性の標準化

ONCは、医療IT戦略計画の一環として、バイオ/医療R&D 領域におけるAPIの開発・標準化への取組をリードしながら、電子健康情報へのアクセスや交換、利用の負荷を低減することを目的として、以下のようなステークホルダー向け報告書を公表している。

各報告書とも、以下のような点に注目することによって、標準化されたAPIとヘルスケアアプリケーションに対する理解と利用を加速させるとしている。

  • どのようにして個人が、APIで可能になるアプリケーションを利用して、セキュアに自分のEHRデータにアクセスできるか
  • どのようにしてAPIが、研究者のために保健医療データへのアクセスを改善するか
  • どのようにしてデータアグリゲーターやデータインテグレーター、アプリケーション開発者が、APIを通して市場におけるイノベーションや競争を牽引できるか
  • どのようにして医療機関が、APIを利用してさらにケアを支援できるか

たとえば、「科学的発見に向けて加速するAPI:アプリケーション開発者とデータイングレーターの視点」は以下のような構成となっている。

  • イントロダクション
    • より大きな相互運用性へのシフト
    • 手法
  • 調査結果
    • 採用と利用の現状
      • 標準化されたAPI利用の動機づけ要因
      • 拡張されたデータセットとユースケース
      • モバイルプラットフォーム統合
      • 開発者ツールとリソース
    • 展開と統合の課題
      • 展開と検証サンドボックス
      • 独自APIとカスタム統合
      • データマッピングとデータの完全性
    • APIプロセス向上の機会
      • 集中型ツールとリソース
      • 業界教育と連携
      • 医療組織向けガイダンス
    • プライバシーとセキュリティの考慮事項
      • 粒度の細かいコンセントとワークフロー
      • データガバナンス
      • データセキュリティリスクと責務
  • 結論
  • 参考文献

CSA-HIM WGも、API利用をバイオ/医療データの相互運用性の中核に据えている。APIは、異なるアプリケーションから、アプリケーションの機能やデータにアクセスすることを可能にするエントリーポイントである。HL7 FHIRには、完璧な相互運用性ソリューションを構築するために拡張されたWeb標準規格と現代的な情報交換に基づくAPI向けの仕様が含まれる。APIとEHRの統合件数は増加傾向にあるが、FHIRデータ交換をサポートするAPIの割合は横ばい傾向にある。アプリケーションの中には、データ交換規格向け支援機能を利用・記述していないものがある点が、この要因と考えられる。加えて、FHIRリソースは、特定のデータ要素の交換を促進するにとどまっており、FHIRサポートのバリエーションに寄与していない可能性がある。特に、初期バージョンのFHIR標準規格にこれが当てはまる。FHIRリソースおよびサポートされたデータ要素の数が増えれば、FHIR向けのサポートも成長するとみている。

ただし、EHRと比較して医療機器の場合、事情が異なってくる。過去10年間多くのソリューションが推進され、標準規格が構築され、製品ソリューションも生産されてきたが、臨床現場の医療機器はEHRと通信するだけでなく、相互間で交換可能であることから、相互運用性がより複雑になっている。相互運用性によってケアが改善する可能性がある反面、データを生成する各機器やEHRシステムとの間を効率的にやりとりできるとは限らないので、注意が必要だ。

医療クラウドの普及がAPIや相互運用性に及ぼす影響と課題

さらに、バイオ/医療分野におけるクラウドコンピューティングの導入によって、データを供給し、利用可能なフォーマットで組み合わせることが可能になってきた。医療機関は、医療産業をサポートするデータ分析で利用する大容量データを保存・加工・共有することができる。

ただし、地理的に分散した場所にある様々なシステムにおいて、異なるソースから複数のデータタイプを有する医療データをクラウド上に集約すると、相互運用性のあるシステムを構築することがますます難しくなる。このような課題を解決するために、クラウドサービスプロバイダー側も、FHIR向けAPIとの相互運用性確保に向けて取組んでいる。また、クラウドは、臨床情報とともに、医用画像や医療機器からのメタデータを提供するので、より強力な結果をもたらすことも可能になる。

CSA-HIM WGは、相互運用性のあるシステムを構築するためには、以下のようなものが必要だとしている。

  • 共通のデータスキーム
  • 病院が大量のリアルワールドデータを共通のデータスキームにもたらすメカニズム
  • 共通のデータスキームに対する質問に答えるメカニズム

2011年、共通のFHIRデータモデルやAPI標準規格が、業界内で同じデータ言語と会話できる単一のデータスキーマに対する回答として提供されて以降、Google、AWS、Azureに代表される大規模クラウドサービスプロバイダー(CSP)は、医療機関が複雑なデータセットを収集し、検索できる手段を提供する技術プラットフォームの開発に尽力してきた。

医療機関がクラウドベースのサービスに移行するにつれて、ポイントツーポイントのカスタマイズなしで、アプリケーションやサービスを迅速に開発・接続・稼働するための機能が必要になってくる。FHIR向けAPIは、医療機関の情報技術チームが自らの製品を強化する際に役立つ。このようなソリューションによって、医療機関は、FHIRの標準化されたAPIで統合することによって、データをモバイル機器やWebポータルに素早く転送することができるとしている。

モバイル機器やWebブラウザ上で稼働するアプリケーションの多くは、API向け基盤として、REST(Representational State Transfer)情報交換規格を利用する。FHIRは、APIにおけるデータ交換向け基盤としてRESTを利用する。医薬品、観察、患者といった保健医療データのタイプは、自らのリソースによって表現される。このようなリソースについては、必要となる正確な情報を発見し、取得するために利用できる検索や要求のような相互作用に加えて、RESTFul HTTP APIコマンドを介してリクエストすることができる。サーバーは、FHIR APIがサポートできるリソースや相互作用のタイプによってプログラミングされる。FHIR APIを利用するサードパーティアプリケーションは、EHRに統合することによって、医療機関のワークフローに直接送り込むことが可能となる。

FHIR APIを利用した個々のリクエストは、リソースや、必要となるデータを特定するインディケーター、コマンドまたはパラメーターを提供する。FHIRのリクエストは、単独の患者のような情報ソースを返して、患者に関連する医療保険や医薬品または全患者のデータのような大量データの束に代表される情報の束を返す。リクエストは、どのタイプの、どれくらいのデータが必要かをアプリケーションに伝えるために、構造化される。

クラウドを利用することにより、医療機関は保健医療データをセキュアに管理できるようになる。FHIR向けAPIは、ネイティブなFHIRフォーマットにより、HIPAAの保護対象保健情報(PHI)の管理・保存向けに、拡張性のある安全な環境を提供するHL7 FHIR仕様に基づいており、一貫性のあるRESTful APIを介したデータ交換を可能にする。このようなFHIR向けAPIの特性により、EHRからの臨床データや、臨床医・患者ダッシュボード、遠隔モニタリングプログラム、医療機関の外部にあるデータベースを統合・正規化し、機械学習を適用するツールとして利用することもできる。

また医療機関は、無比のセキュリティインテリジェンス機能でPHIを保護することができる。データは、APIインスタンス毎に、独自のデータベースに分離して保護される。FHIR向けAPIは、階層型の多層防御と先進的なデータからの脅威保護機能を展開できる。加えて、医療機関は、連携型のロールベースアクセス制御(RBSC)機能を利用してデータを管理することができる。このように、相互運用性は、プライバシー/セキュリティの観点からも、医療機関がクラウドサービスに対するニーズを判断する際に重要な考慮事項となりつつある。

(後編に続く)

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

 

 

 

医療のサードパーティベンダーリスク管理(後編)

前編では、医療のサードパーティベンダーリスク管理のうち、SaaS事業者を含むサードパーティベンダーに対するリスク評価に焦点を当ててきた。後編では、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)の「医療におけるサードパーティベンダーリスク管理」(2022年7月29日公開)(https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/)の中で、検知、対応、復旧といった後半のフェーズを取り上げる。

検知フェーズを支える継続モニタリングと脅威インテリジェンス

サードパーティベンダーリスク管理における「検知」フェーズでは、サイバーセキュリティイベントを特定するために、適切な制御や活動を構築・展開するフェーズである。医療提供組織は、継続的モニタリングプログラムを設定して、サードパーティのリスクに対する最新の理解を維持・改善していく必要がある。医療提供組織は、ベンダーがインターネット上に露出する脆弱性を継続的に観察することによって、セキュリティ質問票への回答の妥当性を確認し、リスクの経験的・継続的なエビデンスに基づいて、プロアクティブなガバナンスプラクティスを設定することができるとしている。
CSA HIM-WGは、継続モニタリングプログラムの設定により、以下のようなベネフィットがもたらされるとしている。

  • ベンダーに対するリアルタイムの洞察を通して、プロアクティブなアプローチを可能にする
  • 人的ミスや不正確さを防止するために客観的なコンテキストを提供する
  • 遅くて費用のかかる人手による評価を実行するのとは反対に、時間や資源を節約する
  • 簡単なカスタマイズを可能にして、自動化とデータインテリジェンスを利用し、評価がベンダーや産業、コンプライアンスのニーズに合わせられる
  • 最高のリスクのみに焦点を当てるのを可能にする

継続的モニタリングの一環として重要なものに、脅威インテリジェンスがある。脅威インテリジェンスでは、数多くのWebサイトやフォーラム、マーケットプレイスをモニタリングしたり、サードパーティパートナーの膨大なリスト向けに悪意のあるネットワーク活動を追跡したりする必要があるが、医療提供組織は、このようなモニタリングのためのリソースを持っていない。

そこで重要な役割を果たすのが、脅威インテリジェンスだ。脅威インテリジェンスサービスプロバイダーは、インターネット上のソース(例.公開Web/ダークWeb上のWebサイト、フォーラム、マーケットプレイス、ランサムウェア恐喝サイト、貼り付け・なりすましサイト、ニュースソース、ブログ、ソーシャルメディアアカウント、脅威インテリジェンスデータベース)から情報を引き出すために、スキルやリソースを提供する。それによって、医療提供組織は、検証可能で客観的なリスク評価情報を利用して、サードパーティベンダーリスク管理プログラムを実行することができる。

対応フェーズの指針となるインシデント対応プレイブック

サードパーティベンダーリスク管理における「対応」フェーズでは、検知されたサイバーセキュリティイベントに関する活動を構築・展開する必要がある。しかしながら、サードパーティベンダーが関わるインシデントはまちまちであり、それらへの対応も異なる。そこで、医療提供組織は、インシデント対応プレイブックを構築する必要がある。最も重要なことは、以下のような内容を含むプレイブックを実行することによって、組織における影響の損害を抑制する点にある

  • アクセスを遮断する。企業は、サイバー攻撃の影響を受けるサードパーティへのアクセスを遮断できるようにする必要がある。医療提供組織は、残りのネットワークからサードパーティのサイバー資産を分離しなければならない。
  • サードパーティによる侵害が自組織に影響を及ぼしたか否かを判断する。もし影響があれば、次のステップは、インシデントの範囲や影響度を理解するために、フォレンジック分析を実施することになる。
  • サードパーティの侵害への関与からの信頼性を評価し、契約条件を確認する。
  • 損害を低減する。これは、追加的なセキュリティタスクや、自システムへのさらなる侵入を最小化するツールを通して実現可能になる。
  • 起きたことや影響度、復旧計画について、ステークホルダーに伝達する。
  • インシデントに重要インフラストラクチャの侵害が含まれていたら、72時間以内に、国家安全保障省(DHS)のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)に報告しなければならない。これは、2022年3月に成立した法律の要求事項である。
  • インシデントの再発を防止する方法を決定するために、根本原因分析(RCA)を実施する
  • 何が機能したか、何が機能しなかったか、どんな改善が必要かといった組織の対応や、次回に展開するための計画を文書化する。
  • 内製化を継続する。医療提供組織は、インシデントが発生した時に、内製化でサービスを稼働するための計画を持つべきである。

医療機器インシデント対応準備におけるSBOMの役割と国際標準化

なおCSAでは、2021年11月8日に「医療機器インシデント対応プレイブック」(https://cloudsecurityalliance.org/artifacts/csa-medical-device-incident-response-playbook/)を発行している。

このプレイブックは、医療提供組織の以下のようなサイバーセキュリティスタッフおよび臨床リーダーを対象としている。

  • チーフ医療情報オフィサー(CMIOs)
  • チーフ看護情報オフィサー (CNIOs)
  • チーフセキュリティオフィサー (CSOs)
  • チーフ情報セキュリティオフィサー (CISOs)
  • チーフ情報オフィサー (CIOs)
  • ITディレクター
  • セキュリティ管理者
  • インシデント対応者
  • セキュアな医療機器の実装・運用に責任があるセキュリティエンジニア
  • 医用生体工学スタッフ

そして、以下のような構成になっている。

  • イントロダクション
  • ユースケースの例
    • ユースケース1:医用画像機器の違反
    • ユースケース2:個人向け埋込み型機器
    • ユースケース3:ネットワーク型輸血ポンプの可用性または機能の損失
  • アプローチ
  • 医療機器インシデント対応プロセス
    • 準備フェーズ
      • シナリオの理解
        • デバイスの棚卸しとデバイス構成の文書化
        • 機器の臨床考慮事項と影響度の分類
        • データと影響度の分類
        • データレポジトリの構築
      • チームの準備
        • インシデント対応(IR)チームとステークホルダーの組立と文書化
        • クラウド統合の文書化とSLA(Service Level Agreement)の策定
        • ツールの収集
        • チームの訓練
        • セキュリティ認識の強化
        • インシデント対応(IR)机上演習の実施
      • プロセスの準備
        • コミュニケーション手順の文書化
        • 医療機器インシデント対応のエスカレーションと通知の手順
        • 通知手順の構築
        • 協調的脆弱性開示(CVD)プログラムの設立と文書化
        • 期待される成果物の明確化
      • ネットワークの準備
        • DNSログとシンクホールの展開
        • ネットワークセグメンテーションアーキテクチャの設計とネットワークアクセス制御(NAC)の構成
        • ネットワークトラフィックのモニタリングと分析
      • 機器の準備
        • ソフトウェア/ファームウェア向けの既知で優れたバックアップまたはインストールデスクの準備
        • 機器構成バックアップの準備
    • 検知、分析、コンテキスト化
      • 脅威インテリジェンスと脅威共有プログラムの維持
      • 脆弱性管理プログラムの維持
      • セキュリティイベント向けのモニタリング
      • 行動プロファイリングと分析の展開
    • 包含、根絶、復旧
  • インシデント対応(IR)の分類
    1.  患者とネットワークから機器を切断するための安全
    2. 患者ではなくネットワークから機器を切断するための安全
    3. 臨床のインパクトにおけるネットワークの結果からの切断
    4. 大規模な患者安全の意味におけるネットワークの結果からの停止または切断
    5. 患者から安全に削除できない機器
    6. 埋め込み型医療機器
    7. 遠隔医療機器
  • インシデント後の分析
    • フォレンジック調査/証拠
    • 教訓
  • 共有と更新
    • 技術の共有
    • 同意書の共有
    • 関係性の共有
  • 計画/プレイブックの更新
  • 結論
  • 参考文献
  • 附表1 – 医療機器インシデント対応(MDIR)フェーズとガイダンス

医療機器インシデント対応準備において、医療提供組織とサードパーティベンダーとしての医療機器企業をつなぐ役割を果たすのが、ソフトウェア部品表(SBOM)である。たとえば、上記の「医療機器インシデント対応プロセス」の「デバイスの棚卸しとデバイス構成の文書化」において、機器の構成や構造に関連するデータをSBOMから取り込むことができれば、後のプロセスにおいて、侵害される可能性があるライブラリ/バージョンを有する機器を特定するのに役立てることができる。

また、「検知、分析、コンテキスト化」の「脆弱性管理プログラムの維持」において、医療機器製造業者と連携しながら、機器で利用されるライブラリを文書化したSBOMを入手し、これらのライブラリに関連する共通脆弱性識別子(CVE)をモニタリングすることによって、新たな脆弱性を発見できる可能性がある。

なお、米国連邦政府レベルでは、2021年5月12日にホワイトハウスが発出した「国家サイバーセキュリティに関する大統領令」(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)に呼応して、米国医薬食品局(FDA)が2022年5月26日に「FDA CDRHと医療機器サイバーセキュリティ:連邦政府のサイバーセキュリティ向上に関する大統領令[第14028号]についてのNISTへの回答書」(https://www.fda.gov/media/149954/download)を公表し、国際医療機器規制当局フォーラム(IMDRF)や共同セキュリティ計画(JSP)と連携して、ソフトウェア部品表(SBOM)の国際標準化に取組むことを表明している。その後2022年7月、IMDRFは「医療機器サイバーセキュリティ向けソフトウェア部品表の原則と実践」草案(https://www.imdrf.org/consultations/principles-and-practices-software-bill-materials-medical-device-cybersecurity)を公表しており、日本にもSBOM国際標準化の波が押し寄せるのは時間の問題だ。

復旧フェーズで求められるマルチステークホルダーコミュニケーション

サードパーティベンダーリスク管理における「復旧」フェーズでは、どのような手段で迅速に通常業務に戻すかを考える必要がある。医療提供組織のサードパーティベンダーがインシデントから復旧する場合、患者に対するケアを継続することが必要不可欠である。インシデント対応チームがイベントを特定したら、影響を受けたベンダーが提供するサービスの代替ソースを特定するために、積極的にベンダーを関与させる必要がある。

サービスが停止しなくても、医療提供組織のデータが公開されるようなケースも想定される。法令により、定められた期間内に当局への報告や当事者への通知が求められることがあるので、インシデント対応プレイブックは、このような要求事項をカバーすべきだとしている。

復旧の取組中、コミュニケーションは重要であり、内外双方のステークホルダーと情報を共有する必要がある。復旧は、事業を迅速に再開するにとどまらず、できる限り安全性を維持することしながら、顧客や患者との信頼性を構築していくことが求められる。

サードパーティベンダーとしてのクラウド事業者をどう管理するか

最後に、「医療におけるサードパーティベンダーリスク管理」では、クラウドに関連する考慮事項として、以下のような項目を挙げている。

  • データセキュリティと制御:他のサードパーティ管理者とともに、プロバイダーは、クラウドベンダーの内部統制の強度を評価しなければならない。
  • データ転送:データは、インターネットや無線ネットワーク経由で転送される可能性がある。医療組織は、クラウドコンピューティングベンダーを選定する際に、すべての法令の要求事項を遵守しなければならない。データが転送・保存される場所を特定することを忘れてはならない。
  • マルチテナント性:これは、医療組織に対して、共有されたハードウェア上でデータが混じり合う可能性を考慮するよう求める。
  • ロケーション:データをクラウド上に移転することは、ハードウェアプロバイダーが制御できない遠隔地に資産を移転することを意味する。加えて、データは米国外に保存される可能性がある。
  • 信頼性:クラウドのような共有リソースに依存する場合、医療組織は、必要な時にリソースが利用できないというリスクに直面する。
  • 持続可能性:医療組織は、万一クラウドが故障した場合に業務を継続する手段を理解するために、クラウドプロバイダーの災害復旧・事業継続計画が適正であるかを判断すべきである。

加えて、医療組織に求められるセキュリティ対策として、以下のような機能を挙げている。

  • 多要素認証
  • 保存時・転送時双方のデータ暗号化
  • 適応型アクセスやアイデンティティプルーフィングなどの連携型アクセス制御
  • クラウド環境におけるユーザーの行動を管理するデータセキュリティポリシーの開発・展開

昨今は、複雑化・高度化するサードパーティベンダーリスク管理の負荷を軽減する自動化ソリューションの開発・提供も進んでいる。自動化には、以下のようなメリットがある。

  • 効率性:自動化プログラムは、効率的な評価時間、制御されたプロセス、一貫したワークフロー、正確な文書化を可能にする。
  • 透明性:すべてのサードパーティの記録をスクリーニング・モニタリングすることによって、医療提供組織は、現実のリスクに対応できる。自動化されたリスクベースのプログラムで重要なのは、適切にデータを利用し、リスクを上手に低減するためにリソースを適用することにある。
  • ポリシーの組織化と分類:文書へのアクセスを表すために利用する構造によって、文書を分類する。構造は検索可能である必要がある。
  • 迅速な通知:自動化プログラムは、違反やリスクを直ちに報告することができる。

自動化をサードパーティベンダーリスク管理に統合することは容易でないが、サードパーティに関するデータを正確に収集・スクリーニングする業務の複雑化や、デューデリジェンスの高度化を考えると、リスクを低減し、費用を削減するためには、自動化以外に選択肢はないのが実情だ。これは、医療に限った問題ではなく、業種横断的な取組が要求される。

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

 

医療のサードパーティベンダーリスク管理(前編)

昨今、医療・ライフサイエンス業界では、業務プロセスの一部を外部のサードパーティベンダーと契約してアウトソーシングする形態が増えている。その典型的な例が、SaaS(Software as a Service)モデルの利用である。業務効率化、費用削減といったメリットがある反面、高度化するサードパーティベンダーの契約管理、継続的なモニタリングといったリスク管理策の負荷も大きくなっている。

容易でない医療分野のサードパーティベンダーリスク管理

クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2022年5月11日に「医療サプライチェーンのサイバーセキュリティリスク管理」(https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/)、2022年7月29日に「医療におけるサードパーティベンダーリスク管理」(https://cloudsecurityalliance.org/artifacts/third-party-vendor-risk-management/)を公開している。前者では、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示しており、それを受けた後者では、特にサードパーティベンダーに対するリスク評価・管理に焦点を当てている。

「医療におけるサードパーティベンダーリスク管理」は、以下のような構成になっている。

  • 謝辞
  • 要約
  • イントロダクション
  • 特定
    • サードパーティベンダーの特定と優先順位付け
    • サードパーティの関係性からの潜在的リスク
  • 保護
    • リスク評価
    • セキュリティに関する質問
    • リスク処理
  • 検知
    • モニタリング
  • 対応
    • 対応
  • 復旧
  • 追加的考慮事項
    • クラウド
    • 自動化
    • プログラムの効果の追跡と改善
  • 参考文献

「イントロダクション」の中で、医療におけるサードパーティベンダーリスク管理が失敗する理由として、以下のような点を挙げている。

  • 手動のリスク管理プロセスにおける自動化と信頼性の欠如によって、医療で利用されるデジタルアプリケーションや医療機器のサイバー脅威と拡散に追いつくことが困難になっている
  • ベンダーリスク評価は、時間と費用を要し、ごくわずかの組織だけが全ベンダーのリスク評価を行っている
  • 重要なベンダー管理のコントロールやプロセスは、部分的に実装されているか、実装されていない

医療機関が取扱う電子医療データの容量が拡大し、複雑化する中、機微データの処理に関わるサードパーティベンダーの数は増えている。特に、インフラストラクチャやマネージドアプリケーション、データ管理といった領域で、サードパーティベンダーへの依存度が高まっており、アクセス管理や変更管理、データ運用管理などの業務も高度化・複雑化している。

「医療におけるサードパーティベンダーリスク管理」では、サードパーティベンダーリスク管理のフレームワークとして、「重要インフラのサイバーセキュリティを向上させるためのフレームワーク(NISTサイバーセキュリティフレームワーク)1.1版」(2018年4月16日)を参照しながら、「特定」、「保護」、「検知」、「対応」、「復旧」のカテゴリーをベースに、議論を展開している。

サードパーティベンダーの特定と優先順位付け

「特定」フェーズでは、新たな外部ベンダーや既存の外部ベンダーにおける変更を特定することが、サードパーティベンダーリスク管理プログラムの第1歩だとしている。加えて、サードパーティベンダーを評価するために、当該ベンダーが組織内で、データをどのように保存・処理・転送しているかを理解する必要があるとしている。

サードパーティベンダーを特定したら、提供するサービスや処理するデータの重要性などを考慮しながら、各ベンダーのリスクを評価し、優先順位(例.重要(Critical)、高(High)、中(Moderate)、低(Low))を付けて分類する必要がある。

医療機関にとって、業務のサードパーティベンダーへのアウトソーシングは、事業戦略の一環である。サードパーティベンダーの役割が拡大するにつれて、医療機関は、ベンダーが直面する潜在的な脅威を低減するために、様々なリスクを継続的にモニタリングすることが不可欠となる。ここでは、医療機関が認識すべきサードパーティベンダーのリスクとして、以下のようなものを挙げている。

  • サイバーセキュリティリスク:サードパーティベンダーのサイバーセキュリティ制御の不備により、組織のデータの機密性、完全性、可用性が影響を受けるリスク
  • レピュテーションリスク:サードパーティベンダーが関与するインシデントが発生した場合、医療機関のブランドレピュテーションにネガティブな影響が及ぶリスク
  • コンプライアンスリスク:事業を遂行するために組織が従わなければならない法律や規制、内部プロセスの違反から生じるリスク
  • プライバシーリスク:サードパーティベンダーと共有する個人データに対する権限のないアクセスが可能となるリスク
  • オペレーショナルリスク:サードパーティベンダーの業務は医療機関の業務と絡み合っており、ベンダーのサービス提供ができなくなると医療機関も日常活動を遂行できなくなるリスク
  • 戦略的リスク:医療機関の戦略目標と合致しないビジネス意思決定をサードパーティベンダーが行った時に生じるリスク
  • 財務リスク:サードパーティベンダーが医療機関の収入に損失を与えるリスク(例.製品リコール)

上記以外にも、様々なリスクが存在するので、医療機関は、将来を見越した拡張性のあるサードパーティベンダーリスク管理プログラムを構築・運用することが求められる。

サードパーティベンダーのリスク評価

次に、「保護」フェーズの柱となるのは、サードパーティベンダーに対するリスク評価であり、リスク分析(リスクの特定、推計、評価)のプロセスが重要になる。本文書では、以下のようなプラクティスを、推奨事項として挙げている。

  • ベンダーの分類:サードパーティベンダーを分類する手法を開発し、個々のベンダーのリスク評価に割り当てる
  • サードパーティ評価頻度の設定と固有のリスク評価に基づくスコープ:サードパーティリスク評価は、一度限りのプロセスでなく、継続的なモニタリングや再評価を必要とする
  • 認識された標準規格を利用したサードパーティ評価の実施:評価をベンダーおよび内部ステークホルダーと共有し、ベンダーが課題に取組み、評価結果をリスク登録に記録することを保証する
  • パフォーマンスの評価
  • 財務リスクの評価
  • 事業継続リスクの評価:サードパーティが中断すると、事業継続のリスクとなる可能性がある

さらに、医療機関は、ベースラインとなるサードパーティベンダー向けセキュリティ質問票を策定しておくことが望まれる。。質問には、以下のような項目も追加するよう推奨している。

  • HITRUST認証
  • SOC2レポート
  • NISTサイバーセキュリティフレームワークなど、認識された標準規格に対するサードパーティ評価
  • 内部セキュリティ統制に関する記入済質問票

サードパーティベンダーとしてのSaaS事業者に対するリスク評価

医療・ライフサイエンス業界に限らず、昨今、クラウドサービスの中で成長著しいのは、SaaSである。反面、IaaS(Infrastructure as a Service)事業者やPaaS(Platform as a Service)事業者と比較して、サードパーティベンダーとしてのSaaS事業者のリスクを評価するための指針やベストプラクティスは少ないのが現状である。そこで、クラウドセキュリティアライアンスは、2022年6月8日、「クラウド利用者のためのSaaSガバナンスのベストプラクティス」(https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2022/08/SaaSGovernanceBestPracticesforCloudCustomers_J.pdf)を公開している。同文書は以下のような構成になっている。

  1. はじめに
  2. 概要
  3. 情報セキュリティポリシー
  4. 情報セキュリティ組織
  5. 資産管理
  6. アクセス制御
  7. 暗号化および鍵管理
  8. 運用セキュリティ
  9. ネットワークセキュリティマネジメント
  10. サプライヤーとの関係
  11. インシデント管理
  12. コンプライアンス
  13. CASBの機能と今後の展望
  14. 結論

SaaSサービスを初期評価する場合、重要な要素は、「使用するSaaSサービスが、自組織のリスクプロファイルおよびエンタープライズアーキテクチャに潜在的に適合しているか」を評価することだとしている。SaaSアプリケーションは、プライベートクラウドやパブリッククラウド、ハイブリッド環境に実装され、専用または共有リソース(シングルインスタンス、マルチテナント)で提供される。複数のクラウドアプリケーションをAPI経由で連携させてサービスを提供する形態もあるが、個々のSaaSによって、責任共有モデルが異なる点に注意する必要があるとしている。

また、上記の「10. サプライヤーとの関係」の中で、サードパーティベンダーとしてのSaaS事業者に係るリスク管理ポリシーに盛り込むべき項目として、以下のような点を挙げている。

  • サードパーティとの関係に対して、組織内で説明可能な単一の役割または立場
  • サードパーティ製品またはサービスに依存する業務運営の重要性について、できれば定量的に、その役割または立場を担う人物が書面による評価を提供することを要件とする
  • 上記で特定した重要性を考慮し、事故がそのようなサードパーティに影響を与える可能性およびそのような事故が組織の業務に与える影響を評価するための方法論
    • 外部監査およびセキュリティレビュー
    • セキュリティスコアリング/評価ベンダーのツール
    • 顧客組織による監査、侵入テスト、プロバイダの製品またはインフラに対する自動スキャンツールの使用など、直接的な技術デューデリジェンス
  • 上記に基づいて設定されたリスク閾値は、サードパーティがこれを超えた場合、サードパーティ側(契約で義務付けられている)、組織自体(何らかの補償的管理を通じて)、またはその両方による是正措置の要求の引き金となる
  • 上記の閾値を超えるリスクを受容する権限を有する、組織内の単一の説明可能な役割または地位、並びにそのようなリスク受容を文書化し正当化するための透明性のあるプロセス

さらに、SaaSの安全かつ信頼性の高い運用を確保するために、個々のサプライヤーに合わせた契約書の作成に際して、以下のような点に留意する必要があるとしている。

  • 製品の可用性だけでなく、基礎となるデータの機密性と完全性についてのサービスレベル合意書(SLA)の作成
  • 組織が監査や侵入テストなどの外部検証プロセスを受け、その結果を提供することの要求
  • 客観的なリスク評価システムに基づいて、組織が特定した脆弱性を、所定の期間内に解決または低減策を特定する要求事項。
  • 組織が脆弱性の重大性または悪用の可能性を低減するために代償措置を適用できるような脆弱性をサプライヤーが特定した場合,サプライヤーは特定の期間内に組織に通知するという要求事項
  • 組織のデータの機密性、完全性、可用性に影響を与えた、または与える可能性のあるインシデントの調査及び是正において、サプライヤーが組織に協力するための要求事項
  • データセンターの新規立地を通知し、好ましくない立地を拒否する権利をサプライヤーに求める要件

ただし実際には、サードパーティベンダーとしてのSaaS事業者の特定、優先順位付け、リスク評価といったプロセスを踏むことなく、ユーザー部門主導でSaaSを導入したケースが多く見受けられる。このような場合、シャドーIT化したSaaS利用の実態を把握することが、サードパーティベンダーリスク管理の第1歩とならざるを得ないので要注意だ。

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

 

 

バイオ/医療サプライチェーンのサイバーセキュリティリスク管理(後編)

クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)が2022年5月11日に公開した「医療サプライチェーンのサイバーセキュリティリスク管理」(https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/)について、前編では、サプライヤーに対するリスク管理や継続的なモニタリングの重要性を提示した、後編では、実務的なサプライチェーンリスクの取扱や対応計画策定上の留意事項、欧米のサプライチェーンセキュリティ標準化動向などについて概説する。

サプライチェーンリスクの取扱と情報共有

医療機関は、組織の規模に見合ったサプライチェーンリスク管理のためのプログラムを設置する必要がある。サプライチェーンリスク管理(SCRM)プログラムは、組織の規模に関係なく不可欠であり、ひと度リスクを特定したら、効果的にリスクを低減するために管理する必要がある。

その際には、サプライチェーンベンダーを関与させながら、リスク管理に必要な戦術およびシステムのセキュリティパフォーマンス評価に取組む必要がある。また、リスク管理パフォーマンス基準を満たすために求められるサプライチェーンを維持することによって、リスクの露出を抑制しなければならない。そして、ベンダーに対する迅速かつ適切で実用的なフィードバックは、サプライチェーンベンダーが的確なことを実行するために、強力な動機付けとなる。加えて、医療機関は、サプライチェーンベンダーに対して、リスクにより優先順位付けされた行動計画を提供する必要がある。

なおCSAは、サプライチェーンリスクの取扱に関連したベストプラクティスとして、以下のような対策を挙げている。 続きを読む

バイオ/医療サプライチェーンのサイバーセキュリティリスク管理(前編)

医療分野では、医療機関の委託を受けた臨床検査サービス機関やオンラインストレージベンダーなどから、患者の個人情報が外部流出するインシデントが続発している。また、新型コロナウイルス感染症(COVID-19)ワクチン開発に関わる研究開発組織や製造・物流施設、市販前/市販後規制当局、公衆衛生行政機関など、ワクチンサプライチェーン全体を狙った高度標的型(APT)攻撃に対して、世界各国・地域の当局が共同で注意喚起を発出するケースも起きている。

医療サプライチェーン全体に渡るリスク管理プログラムの必要性

このように、世界レベルで医療のサプライチェーンセキュリティに注目が集まる中、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2022年5月11日に「医療サプライチェーンのサイバーセキュリティリスク管理」(https://cloudsecurityalliance.org/artifacts/healthcare-supply-chain-cybersecurity-risk-management/)を公開している。この文書は、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示したものである。

本文書では、最初に、医療分野においてサプライチェーンリスク管理プログラムが失敗する理由として、以下のような点を挙げている。 続きを読む

医療におけるAI利用とクラウド(後編)

後編では、医療機関における人工知能(AI)の利活用とともに顕在化するリスク課題のうち、倫理的・法律的側面やクラウド環境特有のセキュリティ・プライバシー課題を取り上げる。

サイバーセキュリティ/プライバシーと密接に関わる医療AI倫理

米国保健福祉省(HHS)は、2021年1月に公表した「人工知能(AI)戦略」の中で、「AIに即応した労働力を開発しAI文化を強化する」、「保健のAIイノベーションと研究開発(R&D)を推奨する」、「基礎的なAIツールとリソースを民主化する」と並んで、「倫理的で信頼されるAIの利用と開発を促進する」を注力領域に掲げている。そこでは、組織の枠を超えて、市民のプライバシーやデータセキュリティを尊重した、信頼性があり、説明可能で、バイアスのない、セキュアなAIシステムを展開すると同時に、既存のサイバーセキュリティフレームワークのAIユースケースへの適用を促進・支援し、適用されたAIの正確性や有効性、健康の公平性に関する評価を推進する姿勢を打ち出している。

このような背景を反映して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)の「医療における人工知能」(https://cloudsecurityalliance.org/artifacts/artificial-intelligence-in-healthcare/)でも、医療AIの倫理的課題を取り上げている。具体的には、以下の3点を挙げている。 続きを読む

医療におけるAI利用とクラウド(前編)

医療は、人工知能(AI)の有望な利活用領域として期待されており、世界各国・地域が積極的な研究開発投資を行っている。クラウド環境を利用したAIアルゴリズムの開発や、臨床現場向け診断・治療支援ソリューションの提供・運用も拡大しつつあるが、バイアス、倫理、法務、セキュリティ、プライバシーといったリスク課題も抱えている。

米国政府が積極的に推進する医療AI

米国の医療分野では、2019年2月11日に制定された「人工知能(AI)分野における米国の優位性を維持し一層促進するための大統領令」に基づき、保健福祉省(HHS)が、2021年1月に「人工知能(AI)戦略」を発表し、チーフAIオフィサー室(OCAIO)を新設している。

同戦略では、AIについて、「日常的なタスクを自動化し、データに基づく洞察を引き出し、人間行動を拡張させることができるソリューションを提供するために、通常は人間のインテリジェンスを要求するようなタスクを遂行できるコンピュータシステムの理論および開発」と定義している。その上で、HHSは、アカデミアや産業界、政府機関のパートナーとともに、AIを活用して、米国の人々の健康・ウェルビーイングにおける進化を継続的に先導することによって、従来解決できなかった課題を解決し、保健福祉サービスのエコシステムにわたるAI利用に対応し、部門を越えた信頼できるAI採用をスケーリングすることを目標に掲げている。 続きを読む

医療クラウドにおけるランサムウェア攻撃予防対策(後編)

前編はこちら

NISTの「重要インフラのサイバーセキュリティを向上させるためのフレームワーク1.1版」(日本語訳:https://www.ipa.go.jp/files/000071204.pdf)では、フレームワーク・コアの機能(Function)として、「特定(Identify)」「防御(Protect)」「検知(Detect)」「対応(Respond)」「復旧(Recover)」を定義している。以下では、CSAが各機能ごとに整理した、医療クラウドならではのマルウェア対策上の留意事項を紹介する。

特定(Identify):

  • 資産、ビジネス環境、ガバナンス、リスク管理、サプライチェーンの特定は、医療機関のサイバーセキュリティプログラム構築の基盤となる。医療機関がクラウド上にデータを保存する場合、ランサムウェア攻撃被害の復旧対策上、データがどこに保存され、その場所でどんな規制が適用されるかを把握しておかないと、データ損失の事態を招きかねない。そのためには、すべての文書や手順、プロセスを確実に文書化しておくことが求められる。

続きを読む

医療クラウドにおけるランサムウェア攻撃予防対策(前編)

医療機関を標的にしたランサムウェア攻撃対策に関連して、クラウドセキュリティアライアンスのヘルス・インフォメーション・マネジメント・ワーキンググループ(HIM-WG)は、2021年9月に「医療クラウドにおけるランサムウェア」(https://cloudsecurityalliance.org/artifacts/ransomware-in-the-healthcare-industry/)を公開している。この文書は、医療クラウド上で拡大するランサムウェア脅威に対して、医療機関が、NISTサイバーセキュリティフレームワークに準拠しながら取組むべきリスク低減策を紹介することを目的としている。

米国MITREが医療ランサムウェア対策支援ポータルを開設

医療機関を標的にしたランサムウェア被害が続出する米国では、2021年3月2日、連邦政府の支援を受けた非営利団体MITREが、ランサムウェア対策支援センター「Health Cyber」(https://healthcyber.mitre.org/)を公開Web上に開設したことを発表している。

Health Cyberは、医療機関の経営管理部門、臨床技術部門、IT/セキュリティ実務家の3つのカテゴリーに合わせたコンテンツ作成・発信を行っている点が特徴である。たとえば、経営管理部門向けには、以下のようなメニュー構成の情報発信を行っている。

  • ランサムウェアに関する学習
  • 感染回避のためのスタッフ向けトレーニング
  • サイバー対応計画の評価
  • サイバーセキュリティ業務の評価
  • 敵対者の理解

続きを読む