タグ別アーカイブ: クラウドセキュリティ

ゼロトラストアーキテクチャにおける医療機器とSBOM(後編)

前編では、米国連邦政府主導で進む医療分野のゼロトラストモデル導入、サイバーセキュリティ大統領令を起点とする医療機器ライフサイクル管理へのソフトウェア部品表(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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

ゼロトラストアーキテクチャにおける医療機器とSBOM(前編)

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

CCAKの合格者経験記

《CCAKの合格者経験記》

2023年9月20日
三優監査法人
システム監査技術者、CCAK
堺 由美子

🔳CCAK取得の目的と経緯

クラウドセキュリティの監査について体系的に学ぶこと、「英語で勉強・英語で資格取得」に慣れることを主な目的として、新設されたCCAKに挑戦することを2021年春に決意。途中、別の資格試験を優先したり業務多忙で勉強を中断したりの後、2023年7月初旬にようやく受験、合格しました。

🔳どこからスタートだったか

  • CCAKは「CCSKをベースにして、それを補完する内容」とされていますが、CCSKは未取得(未勉強)でした。
  • システム監査やITガバナンス、情報セキュリティの知識、データセンター・クラウドの各種認証取得実務の経験がありました。
  • 技術者ではありません。
  • 英語は、読むのがそれほど苦ではない(何度も同じ単語を辞書で引いても折れずに読み続けられる)レベルでしたが、英語での勉強・受験は未経験でした。

🔳使用した教材

  • CCAK Study Guide
  • 諸角さんの講演資料(「クラウド監査人向けクラウドセキュリティ認定資格 CCAK(Certificate of Cloud Auditing Knowledge) 解説」, 2022年1月24日)。本資料はこちらからダウンロードできます
  • CCAK Questions and Answers Collection(200問の問題集)
  • CSAおよびCSAジャパンの各種ドキュメント(セキュリティガイダンス v4.0他)
  • UdemyやLinkedIn Learningの「XX入門」講座(DevOps等、そもそも不足していた知識の補強)
  • また、会社(当時)でMicrosoft Azureの資格試験を受ける機会があったので、ボキャブラリ獲得と英語受験の練習としてMicrosoft Azure Fundamentals (AZ-900)を英語で勉強・受験しました。

🔳学習方法

当初はStudy Guideの目次と各章冒頭にあるOverviewで全体の構成を把握し、気になる箇所・知識不足の箇所を中心に読んでいこうとしましたが、”Governance”や”Compliance”がいろいろなところに出てきたりして構成があまり頭に入って来ず、捗りませんでした。

そこでQuestions and Answers Collectionに取組み、正答できなかったところをStudy Guideで確認、惨敗なところは一旦中断してCSAジャパンの翻訳資料を参照したり、Udemy等の入門講座をあたりました。Questions and Answers Collectionは3回くらい繰り返したと思います。

🔳CCAK取得に挑戦中/取得を検討中の方へのTIPS

  • Study Guide
    • PDF版がおすすめです。ダウンロードで即入手できますし、わからない単語を調べたり翻訳したりが簡単です。(読み上げツールも試しましたが、起きていられませんでした。)
      とはいえ断然紙の方が勉強しやすいので、PDFファイルを好きなところで分割し、ネットのプリントサービスで製本して利用しました。
  • Questions and Answers Collection
    • ブラウザで利用するので、ページの翻訳が使えます。英語で読んで英語で回答しないと試験対策になりませんが、解いた後の回答確認・解説は適宜翻訳して日本語で読み、脳の負担を減らしました。
    • 回答の解説は、残念ながら日本の情報処理技術者試験の問題集のようには全く充実していないです。
    • 購入すると12ヶ月間アクセス可能ですが、6ヶ月単位で延長できます(39ドルでした)。
  • 受験申込み
    • 購入すると有効期限が12ヶ月あります。準備万端となっていなくても購入し、自分を追い込むのも一手です。(有効期限が近づくと「これをもう一回受けるのはイヤだ!(受験料も高いし円安だし)」が強烈なモチベーショとなり、壮絶なまでの締切効果を得て乗り切れました。)
  • 受験当日(オンライン)
    • CCSKとは異なり、試験中は何も参照できません。
    • 試験官やカスタマーサポートも外国人で英語、本人確認に国内の免許証等は使えません。
    • (ISACAに旧姓で登録しているのにGovernment Issued ID Family Nameが空欄のままだったので、パスポートでも本人確認してもらえないことにチェックイン時になって気づき、試験直前に英語サバイバル訓練を余儀なくされてかなり消耗してしまいました。)
    • 早めにISACA Certificate Programs Exam Guideをよく読み準備しておくことをおすすめします。

🔳受験を終えて

以前から効率的な知識習得のために資格試験を利用していましたが、今回も「無知の知→勉強」を繰り返し、英語訓練もできたので、大変でしたが挑戦して良かったです。

CSAジャパンの豊富な翻訳資料・講演資料に大いに助けられました。どうもありがとうございました。

以上

ロボット支援手術(RAS)システムの脅威モデリング(後編)

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

ロボット支援手術(RAS)システムの脅威モデリング(前編)

2023年1月30日、クラウドセキュリティアライアンス(CSA)のIoTワーキンググループ/健康医療情報管理ワーキンググループ/クラウドインシデント対応ワーキンググループは、「遠隔手術机上演習ガイドブック」(https://cloudsecurityalliance.org/artifacts/telesurgery-tabletop-guide-book/)を公開した。ここでは、脅威モデリングの観点から、ロボット支援手術(RAS)システムに代表されるクラウドコンピューティングを利用した医療機器のサイバーセキュリティについて考察する。

米国の医療機器市販後安全管理策に位置づけられた脅威モデリング

脅威モデリングに関連して、米国食品医薬品局(FDA)は、2016年12月28日に「医療機器におけるサイバーセキュリティの市販後管理 – 業界および食品医薬品局スタッフ向けガイダンス」(https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices)を公開している。本ガイダンスは以下のような構成になっている。

Ⅰ. イントロダクション
Ⅱ. 背景
Ⅲ. スコープ
Ⅳ. 定義

A.補完的な制御
B. 制御されたリスク
C. サイバーセキュリティの日常的なアップデートとパッチ当て
D. サイバーセキュリティの兆候
E. 悪用
F. 患者の害
G. 救済策
H. 脅威
I. 脅威モデリング
J. 制御されないリスク
K. 脆弱性

Ⅴ. 一般原則

A. 市販前の考慮事項
B. 市販後の考慮事項
C. 安全性と不可欠なパフォーマンスの維持

Ⅵ. 医療機器サイバーセキュリティリスク管理

A. サイバーセキュリティ脆弱性の悪用可能性の評価
B. 患者の害の重大度の評価
C. 患者の害のリスクの評価

Ⅶ. サイバーセキュリティ脆弱性の救済策と報告書作成

A. 患者の害の制御されたリスク
B. 安全性と不可欠なパフォーマンスに対して制御されないリスク

Ⅷ. PMA(市販前承認)時系列報告書に含むのに推奨されるコンテンツ
Ⅸ. ISAO(情報共有・分析組織)における製造業者による活発な参加を明確化するための基準
Ⅹ. 附表: 有効な市販後サイバーセキュリティプログラムの要素

A. アイデンティ
ⅰ. 安全性と不可欠なパフォーマンスの維持
B. 保護/検知
ⅰ. 脆弱性の特徴づけと評価
ⅱ. リスク分析と脅威モデリング
ⅲ. 脅威ソースの分析
ⅳ. 脅威検知能力の取込
ⅴ. すべての機器に関する影響度評価
C. 保護/対応/復旧
ⅰ. 補完的制御の評価(検知/対応)
D. 安全性と不可欠なパフォーマンスのリスク低減策

 このうち、「Ⅴ. 一般原則」の「A. 市販前の考慮事項」では、医療機器市販前の考慮事項として、以下のような点を挙げている。

  • 資産、脅威、脆弱性の特定
  • 機器の機能とエンドユーザー/患者における脅威や脆弱性の影響度評価
  • 脅威や脆弱性が悪用される確率の評価
  • リスクのレベルと適切な低減戦略の決定
  • 残存リスクと許容リスクの基準の評価

また、B. 医療機器市販後の考慮事項」では、以下のような点を挙げている。

  • サイバーセキュリティの脆弱性とリスクの特定・検知に関するサイバーセキュリティ情報ソースのモニタリング
  • 以下のようなメカニズムを含む堅牢なソフトウェアライフサイクルプロセスの維持
    • -機器のトータル製品ライフサイクルを通した新たな脆弱性の関するサードパーティ製ソフトウェアコンポーネントのモニタリング
    • -汎用(OTS)ソフトウェア関連など、脆弱性の救済に利用されるソフトウェアのアップデートやパッチに関する検証やバリデーションの設計
  • 脆弱性の存在や影響度に対する理解、評価、検知
  • 脆弱性の取込や処理に関するプロセスの確立と伝達
    • (注: FDAは、「ISO/IEC 30111:2013: 情報技術 – セキュリティ技法 – 脆弱性対応手順」を認知してきた)
  • サイバーセキュリティリスクから保護、対応、復旧する低減策の構築によって、機器の安全性および不可欠なパフォーマンスを維持する方法を明確に規定するための脅威モデリング利用
  • 協調的脆弱性開示ポリシーおよびプラクティスの採用(FDAは、「ISO/IEC 29147:2014: 情報技術-セキュリティ技法- 製造業者にとって有益な可能性がある脆弱性開示」を認知してきた)
  • 初期および悪用される前にサイバーセキュリティリスクに取組む低減策の展開

なおFDAの市販後ガイダンスでは、「脅威モデリング」について、目標と脆弱性を特定し、システムに対する脅威の影響を防止または低減する対策を明確にすることによって、ネットワーク/アプリケーション/インターネットセキュリティを最適化するための手法と明記している。医療機器の場合、生産ラインにある製品や、患者に害を引き起こす可能性がある組織のサプライチェーンから、特定製品に対する脆弱性や脅威を明らかにすることによって、セキュリティ強化のために脅威モデリングを利用できるとしている。

そして、製造業者に対し、個々の機器向けの脅威モデリングを含むサイバーセキュリティリスク分析を実行し、これらの分析を経時的にアップデートするよう推奨している。脅威モデリングは、伝統的なリスクマネジメントと故障モード分析のパラダイム、そして、活発な敵対者/悪意ある利用からの脅威を評価するフレームワークを提供するものである。個々の脆弱性に関して、リスク分析と脅威モデリングの情報を簡潔に要約したサマリーレポートを作成すべきだとしている。また、分析の周期的な性質上、情報は、関連した文書化に追跡可能であるべきだとしている。

参考までに、日本の厚生労働省が、2023年3月に公表した「医療機器のサイバーセキュリティ導入に関する手引書(第2版)」(https://www.mhlw.go.jp/content/11120000/001094636.pdf)をみると、「5. 市販前の考慮事項」の「5.1. セキュリティ要求事項及びアーキテクチャ設計」の中で、脅威モデリングに関する記述があるが、「6. 市販後の考慮事項」にはそのような記述が見当たらない。

MITREの医療機器向け脅威モデリングガイダンス

FDAのガイダンスを受けてMITREは、2021年11月30日、医療機器イノベーションコンソーシアム(MDIC)と共同で「医療機器脅威モデリングプレイブック」(https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices)を公開している。このプレイブックは、FDAの資金助成を受けて、MITRE、MDIC、脅威モデリングの第一人者であるアダム・ショスタック氏が連携し、医療機器エコシステムを通して脅威モデリングに関する知識と理解を向上させるために実施した脅威モデリングブートキャンプの知見に基づいて開発されたものである。

プレイブックでは、「脅威モデリング」について、セキュリティ及びプライバシーの特性に関する懸念に焦点を当てたシステム表現の分析だとしている。ハイレベルでみると、脅威モデリングを行う際に、以下の4つの設問に答えることが必要だとしている。

設問1. 我々は何に関する作業を行っているのか?

設問2: 何が悪い結果をもたらし得るか?

設問3: 我々はそれに関して何をしているか?

設問4: 我々はよい仕事をしたか?

そして、各ステークホルダーが以下に挙げるような活動を行う際に、プレイブックを役立てることができるとしている。

  • 製品ラインマネージャーが、脅威モデリングを既存のプロセスに適合させる方法を理解する
  • システムエンジニアが、脅威モデリングを設計要求事項の中で周知する方法を理解する
  • 設計エンジニアやアーキテクトが、脅威モデリングを設計上の選択に周知する方法を理解する
  • 設計検証/妥当性確認(V&V)エンジニアが、設計テスト戦略に脅威モデルを利用する方法を理解する
  • 規制専門家が、脅威モデルを表現し、文書化する方法を理解する
  • 脅威モデリングの経験がない可能性がある外部委託先製造業者やコンサルタントと契約する

プレイブックでは、脅威モデリングを実行する時、システムにどんな問題が起こり得るかを認識し始めることになるとしている。また、システムのライフサイクルにおける早期段階か、それとも全体を通してかどうかなど、低減策を必要とするような設計・実装時の課題を指摘することを可能にする。脅威モデルのアウトプットは、脅威として知られており、あとに続く設計、開発、検証、実装後フェーズにおいて行う可能性がある意思決定に必要な情報を提供するものとなる。

なお、「医療機器脅威モデリングプレイブック」は、以下のような構成になっている。

  1. イントロダクション

1.1. プレイブックの開発

1.2. プレイブックの利用

  1. 脅威モデリングの概要

2.1. 架空の事例1: 脳卒中向け足関節モニター予測機器(AMPS)

2.2. 4つの設問(概要)

2.3. 設問1. 我々は何に関する作業を行っているのか?

2.3.1. データフローダイアグラムによる構造化モデリング

2.3.2. スイムレーン図と状態遷移図による構造化モデリング

2.3.3. 多重モデリング手法の活用

2.3.4. 次の段階に移行する時を知るためのティップス

2.4. 設問2: 何が悪い結果をもたらし得るか?

2.4.1. STRIDEによる脅威の特定

2.4.2. (事例) STRIDEのAMPSシステムへの適用

2.4.3. アタックツリーによる脅威の特定

2.4.4. キルチェーンとサイバー攻撃ライフサイクルによる脅威の特定

2.4.5. ATT&CKフレームワーク

2.4.6. 想定と結果の文書化のためのティップス

2.5. 設問3: 我々はそれに関して何をしているか?

2.5.1. 除去のアプローチ

2.5.2. 低減のアプローチ

2.5.3. 受容のアプローチ

2.5.4. 転嫁のアプローチ

2.5.5. リスク低減戦略のトラッキング、文書化、評価

2.5.6. 脅威からのリスクの決定と順位付け

2.6. 設問4: 我々はよい仕事をしたか?

2.6.1. “よい仕事”向けのフィードバック・ソース

2.6.2. 文書化における”よい仕事”の評価向けのチェックリスト

  1. 脅威モデリング実装のための考慮事項

3.1. 脅威モデリングと製品安全リスク管理(品質システム)

3.1.1. 脅威モデリングとサイバーセキュリティリスクモデリング

3.1.2. 脅威モデリングのセキュリティリスク評価へのマッピング

3.2. 組織の採用

3.2.1. 組織的アプローチ

3.2.2. 課題と現行のプラクティス

  1. 要約

附表A. 追加的な架空の医療機器事例

A.1.1. 架空事例2: 脳卒中向け神経情動撮影システム(SNAP)

A.1.2. 架空事例3: 脳卒中向け足関節・つま先運動エクササイズ機器(SKATE)

附表B. 架空の医療機器事例からの追加的考慮事項

附表C. 参考文献

プレイブックでは、データフローダイアグラム(DFD)、スイムレーン図、状態遷移図、STRIDE (S:なりすまし、T: 改ざん、R:否認、I:情報漏えい、D:サービス拒否、E:権限昇格)、キルチェーンといった脅威分析手法を医療機器セキュリティの領域に適用している。

また、「3. 脅威モデリング実装のための考慮事項」では、「ISO 14971:2019(JIS T 14971:2020) 医療機器 – リスクマネジメントの医療機器への適用」に準拠しながら、脅威モデリングを製品安全リスクマネジメントプロセスに統合する方法に焦点を当てている。ここでは、危険および危険な状態の特定に基づいて、医療機器の安全性のリスクを評価するためのプロセスや、害をもたらす可能性がある一連のイベントを定義している。個々の危険な状態は、危険の重大度と危険が発生する確率の組合せで推定される。サイバーセキュリティのリスク評価も似ているが、必ずしも同じではない。サイバーセキュリティリスクが害をもたらす確率や可能性を推定することは困難であり、悪意のあるアクターの評価ができないために、誤った方向に導かれる可能性がある。

このような状況下で、脅威モデリングは、医療機器およびそれが稼働するネットワーク化された臨床環境に対するサイバーセキュリティ脆弱性や弱点、脅威をシステマチックに特定する有益なアプローチを提供する。また、脅威モデリングは、悪用の可能性、そして順番に緊急の必要性を評価するのに役立つ。製造業者は、機器のリスク管理全体へのインプットとして、脅威モデルを利用することができる。たとえば、サイバーセキュリティリスクを特定し、これらのリスクを制御するための最善のアプローチを決定し、リスクが安全上の懸念を示す可能性がある時を決定し、セキュリティや安全性の制御によってもたらされる潜在的リスクを評価することが可能である。

「AAMI TIR57: 医療機器サイバーセキュリティの原則 – リスクマネジメント」および米国医療・公衆衛生セクター調整委員会(HSCC)・共同サイバーセキュリティワーキンググループの「医療機器・医療IT共同セキュリティ計画(JSP)」の双方とも、サイバーセキュリティリスク管理とリスク評価向けに、ISO 14971リスクマネジメント原則適用のためのフレームワークを推奨している。一般的に、リスク管理プロセスは、リスク分析から始まり、リスク評価が続いて、必要があれば、制御対策を実装する。このプロセスで重要なのは、リスク制御対策が、新たなリスク源をもたらさないよう保証することだとしている。その他のリスク管理プロセスには、設計要求事項のバリデーション・検証と、市販後モニタリングが含まれる。

加えて、「附表B. 架空の医療機器事例からの追加的考慮事項」では、以下のような考慮事項を挙げている。

  • 故障モードは、必ずしも直ちに表面化するとは限らない
  • サイレントリスクの転嫁を回避する
  • 外部主体との間で確立されたコネクションに細心の注意を払う
  • クラウドは、必ずしも排他的に外部主体であるとは限らない
  • 重要なデータフローをエンドツーエンドで特定し、文書化する
  • セキュリティ制御が最も効果的に実装された可能性のある信頼境界に焦点を当てる
  • すべての特定された脅威が文書化されていることを保証する
  • 脅威に取組むための戦略の強さを過大評価しない
  • 脅威モデリングプロセスの脅威モデル
  • すべてのモデルが誤っていても、中には有益なモデルがあることを忘れてはならない

専門チームによるクラウド固有の考慮事項に配慮した脅威モデリングが必要

クラウド環境の脅威モデリングに関連して、CSAのトップスレッドワーキンググループは、2021年7月29日、「クラウド脅威モデリング」(原文: https://cloudsecurityalliance.org/artifacts/cloud-threat-modeling/、日本語版: https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/10/Cloud-Threat-Modeling_J.pdf)を公開している。本文書は、クラウドのアプリケーション、サービス、およびセキュリティに関する意思決定において、脅威モデリングを可能にし、推奨することを目的としており、以下のような構成になっている。

  • はじめに
  • 目的
  • 想定読者
  • 主な論点
  • 脅威モデリング
  • 脅威モデリングの目的:
  • コアとなる脅威モデリングの取り組み:
  • クラウド脅威モデリング
  • クラウド脅威モデリングの目的は、非クラウド脅威モデリングとは異なりますか?
  • クラウド脅威モデリングプロセス
  • クラウド脅威モデルの作成
  • どのようにしてゼロから始めるか
  • クラウド脅威モデルリファレンス
  • おわりに
  • 付録1:脅威モデリングレポート作成に関する詳細なガイダンス
  • 付録2: クラウド脅威モデリングカード

クラウド環境の脅威モデリングでも、オンプレミス環境時と同様の手法を利用するが、以下のようなクラウド固有の考慮事項に配慮する必要があるとしている。

  • 範囲: クラウドのシステムやサービスの脅威モデリングの範囲に関する考慮事項として、アイデンティティ管理、クラウドサービス構成、さらには基盤となるクラウドアカウントについて考慮する
  • 資産: データ、主要なシステムコンポーネント、金銭的な価値のある機器、及びアイデンティティに加えて、クラウドアカウント、SaaS サブスクリプション、サービスといった新しい資産も導入されている
  • 脅威: クラウドシステム、アプリケーション、および環境に対する脅威に加えて、インスタンスメタデータサービスやクロスアカウント IAM アクセスフェデレーションなどの新技術が登場しており、様々な攻撃がそれらに対して実行可能である
  • 実施されるコントロール: クラウドのシステムやサービスは、組み込まれたコントロールの恩恵を受けるが、クラウドサービスプロバイダー(CSP)に組み込まれている場合もあれば、CSP の責任範囲から外れている場合もある
  • 格付け: クラウドを範囲内にするかどうかに関係なく、重大度による脅威の格付けは必要であり、同じ考慮事項が適用される(システムが特定の脅威に対してどれほど脆弱であるか、どの資産が影響を受けるか、そしてどの程度か。クラウドアカウント、システム、およびサービス品質によって、クラウドにおいて本質的に深刻な脅威もあれば、そうでないものもある)
  • 提案される緩和策: 異なる脅威にさらされていることから、クラウドのシステムやアプリケーションによって大きく異なり、特定のクラウドシステムやアカウントでしか利用・適用できない対策(例. AWS アカウントのサービスコントロールポリシー)や、新しい独自技術(例.メタデータサービス保護、CSPM5)も考慮に入れる必要がある

クラウド脅威モデリングの成果物やアウトプットは、オンプレミス環境の場合と同様であり、以下のようなものがある。

  1.  脅威モデル(Excel シートまたはツリー型マッピングなどのビジュアルモデルを介して提示される)
  2.  優先順位がランク付けされた緩和コントロール
  3. セキュリティとデザイン上の決定、またはより明確かつ詳細な実施項目

クラウド脅威モデルの構築に関しては、システムの全体的なアーキテクチャ、コンポーネント/サービス、インフラストラクチャ、ビジネス状況の理解と、対象システムまたは設計に関連する敵対的な視点を有するセキュリティとクラウドの専門人材から構成されるチームが、責任を持つべきだとしている。

クラウドを利用した医療機器やロボット支援手術システム、SaMD(Software as a Medical Device)などの脅威モデリングにおいても、同様のことが当てはまるが、日本国内の研究開発や臨床開発の現場では、それに必要な人材や経験、知見が圧倒的に不足している。

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

ゲノムデータのサイバーセキュリティとアクセス制御(後編)

ゲノムデータベース利活用のエコシステムでは、産官学の様々な組織・コミュニティの専門家がアクセスし、共同作業を行う形態が多く見られる。そこで大きな課題となるのがアクセス制御に代表されるアンデンティティ/アクセス管理である。

CSAガイダンスからみたアンデンティティ/アクセス管理

はじめに、クラウドセキュリティアライアンス(CSA)が2011年11月に公開した「クラウドコンピューティングのためのセキュリティガイダンス V3.0」(https://www.cloudsecurityalliance.jp/j-docs/csaguide.v3.0.1_J.pdf)では、 「第12章 アイデンティティ、権限付与、アクセス管理」において、以下のような内容で概説している。

12.1 この文書で使用する用語
12.2 クラウド環境におけるアイデンティティ序論
12.3 クラウド用のアイデンティティアーキテクチャ
12.4 アイデンティティ連携
12.5 アイデンティティと属性のプロビジョニングとガバナンス
12.6 権限付与プロセス
12.7 承認とアクセス管理
12.8 アイデンティティと属性の提供者とインタフェースするためのアーキテクチャ
12.9 アイデンティティと属性の信頼レベル
12.10 クラウドシステム上のアカウントプロビジョニング
12.11 Identity-as-a-Service
12.12 コンプライアンスと監査 (IDaaS)
12.13 アイデンティティのためのアプリケーション設計
12.14 アイデンティティとデータ保護
12.15 利用者化とアイデンティティの挑戦
12.16 アイデンティティサービス提供者
12.17 推奨事項

次に、CSAが2017年7月26日に公開した「クラウドコンピューティングのための
セキュリティガイダンス v4.0」(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.1_20180724.pdf)では、「DOMAIN 12 アイデンティティ管理、権限付与管理、アクセス管理」において、以下のような内容で概説している。

12.0 はじめに
12.0.1 クラウドにおけるIAMの違いは何か
12.1 概要
12.1.1 クラウドコンピューティングにおけるIAM標準
12.1.2 クラウドコンピューティングのためのユーザ、アイデンティティ管理
12.1.3 認証と資格情報
12.1.4 権限付与管理とアクセス管理
12.1.5 特権ユーザ管理
12.2 推奨事項

  • CSAガイダンス v4.0では、以下のような、アイデンティティ管理、権限付与管理、アクセス管理の推奨事項を提示している。
  • 組織は、クラウドサービスでアイデンティティと認可を管理するための包括的かつ公式な計画とプロセスを開発する必要がある。
  • 外部のクラウド事業者に接続する場合は、可能であれば ID 連携を使用して、既存のアイデンティティ管理を拡張する。内部のアイデンティティに結びついていないクラウドプロバイダ固有のアイデンティティ管理を最小限に抑えるようにする。
  • 適切であれば 、アイデンティティブローカの使用を検討する。
  • クラウド利用者は、アイデンティティプロバイダを管理しアイデンティティと属性を定義する責任を負う。
  • これらは権威のあるルートソースに基づくべきである。
  • オンプレミスのディレクトリサーバが利用できないあるいは要件を満たしていない場合、分散した組織ではクラウドホスト型のディレクトリサーバの使用を検討する必要がある。
  • クラウド利用者は、すべての外部のクラウドアカウントに対して多要素認証(MFA)を選択し、認証連携を使用する場合にはMFAステータスを属性として送信するべきである。
  • 特権を持つアイデンティティは、常にMFAを使用することが望ましい。
  • クラウド事業者とプロジェクト毎に、メタ構造や管理プレーンへのアクセスに重点をおいた権限付与マトリクスを開発すること。
  • クラウド事業者またはプラットフォームでサポートされている場合は、権限付与マトリクスを技術ポリシーに組み入れること。
  • クラウドコンピューティングではロールベースアクセス制御(RBAC)より属性ベースアクセス制御(ABAC)を優先すること 。
  • クラウド事業者は、オープンな標準に基づく内部アイデンティティと ID連携の両方を提供する必要がある。
  • 魔法のプロトコルはない。まず、ユースケースを取り上げて制約条件を洗い出し、次に適切なプロトコルを見つけること 。

米国防総省の調達基準としての多層防御型ICAM戦略

他方、アクセス制御に関連して米国防総省(DoD)は、2020年3月30日、「アイデンティティ・資格情報・アクセス管理(ICAM)戦略」(https://dodcio.defense.gov/Portals/0/Documents/Cyber/ICAM_Strategy.pdf)を策定している。

この中で国防総省は、イデンティティ・資格情報・アクセス管理(ICAM)について、デジタルアイデンティティの生成および関連する属性の維持に関連する幅広い範囲の活動であり、人間/人間以外の主体向けの資格情報の発行、資格情報を利用した認証、認証されたアイデンティティおよび関連する属性に基づくアクセス管理制御に係る意思決定だとしている。その上で、以下のようなICAM戦略の目標を掲げている。

・目標1: データ中心のアプローチを実装して、アイデンティティおよびその他の属性を収集、検証、維持、共有する

  • 目標1.1: 収集時の属性データを検証するための標準規格を設定して、属性データの正確性を維持し、すべてのローカルデータレポジトリの改ざんに対して属性値を保護する
  • 目標1.2: 属性データの共有に関する意思決定をする際に、データレポジトリを利用するためのプロセスやサービスレベルアグリーメント(SLAs)の言語を設定する
  • 目標1.3: 信頼されるレポジトリへの書込みアクセス向けの標準規格を設定する

・目標2: 共通の標準規格、共有サービス、連携を通して、DoDネットワークおよびリソースへの認証を向上し、可能なものにする

  • 目標2.1: アプリケーションオーナーが、DoDおよび外部の資格情報を活用して、DoDネットワークやリソースにアクセスするためのリスクベースのガイドラインを開発・維持する
  • 目標2.2: DoD従業員、外部委託先、退職者、扶養家族など、すべてのタイプのユーザおよびすべての環境向けに資格情報を提供するケーパビリティを実装する
  • 目標2.3: クラウドサービスをサポートするためのICMケーパビリティを実装する
  • 目標2.4: DoDネットワークの境界で、連携した外部信用情報を介して、米国政府、米国以外の政府、商用パートナーなど、認証されたミッションパートナー向けの共有サービスを実装する

・目標3: 共有サービスを実装して、エンタープライズICAMの導入を促進する

  • 目標3.1: 法律、規制、ポリシー、ミッション、リソースへのアクセスを統治するローカルの要求事項を統合するデジタルポリシーフレームワークを設定する
  • 目標3.2: DoDリソースへのアクセスのためのコアのデジタルポリシールールを実装するために必要な属性および値を設定する
  • 目標3.3: DoD内部およびミッションパートナーとの間双方で属性を交換するためのシンタックスおよびセマンティックを定義する
  • 目標3.4: 属性交換、デジタルポリシー管理、ポリシー意思決定など、プロビジョニング自動化・動的アクセス制御を導入するために、エンタープライズ共有サービスを実装する

・目標4:インサイダー脅威および外部攻撃を検知するために、一貫したモニタリングとロギングを可能にする

  • 目標4.1: 情報リソース、ミッション、データに対するアクセス、特権、リスクの評価および考慮をサポートするために、DoDマスタユーザレコードを設定し、進化させる
  • 目標4.2: 認可データを提供して、特別なインシデント、不適切な認可、行動異常の周りで協働するための監査体制を認める
  • 目標4.3: 現代化した監査のケーパビリティに対するICAMインフラストラクチャのサポートを進化させる
  • 目標4.4: ミッションパートナーとともに、協働型監査をサポートする

・目標5:エンタープライズICAMソリューションの開発・採用を促進するために、ガバナンス構造を強化する

  • 目標5.1: エンタープライズICAMソリューションの定義・実装に関するDoD CIOやUSCCと、サービスおよび政府機関の責任を定義する
  • 目標5.2: サービスおよび政府機関のステークホルダー間のコミュニケーションや協力関係を促進するために、統合プログラムチーム(IPT)を構築する
  • 目標5.3: コアのジョブ機能としてICAMを促進するために、トレーニングおよびパフォーマンス管理を特定する
  • 目標5.4: 現行のICAM関連活動の実装・維持への支出に関するエンタープライズ全体の見積を策定する

・目標6:アイデンティフィケーション、資格証明、認証、認可のライフサイクル管理向けの要求事項を明確に定義するために、DoDポリシーおよび標準規格を構築する

  • 目標6.1: 外部発行の資格情報との相互運用性など、リスクのレベルおよび環境的な制約上、適切な資格証明技術の利用をサポートするために、既存のDoDポリシーをアップデートする
  • 目標6.2: 情報システムが 資格証明、認証、認可向けのDoDエンタープライズソリューションの利用をサポートすることを実現するために必要なDoDポリシーを構築する
  • 目標6.3: 連携、相互運用性、資格証明、認証、認可、予期せぬユーザ向けサポートに関する国防総省全体の技術標準規格を定義し、維持する
  • 目標6.4: データへのアクセスを許可するために、属性やデジタルポリシールールを活用する際に、リスク管理および責任のためのDoDポリシーを構築する
  • 目標6.5: すべての情報システム向けの調達プロセスへのICAM標準規格の強制を取り入れる
  • 目標6.6: エンタープライズICAMの達成に向けて、進歩を実証・追跡するメトリクスを特定し、収集する

・目標7: ミッションの目標を実行するというDoDコンポーネントのニーズと、DoDリソースを確保するというDoDエンタープライズのニーズをサポートするために、ICAM活動の実行と進化を維持する

  • 目標7.1: ミッションの目標をサポートするICAMケーパビリティの統合を保証するために、DoDエンタープライズICAMサービスの実装を調整する
  • 目標7.2: ミッションの目標を達成し、特定された要求事項を優先順位付けし、適切な実装向けエンタープライズサービスと要求事項を調整するために、DoDコンポーネントが必要とするICAM関連要求事項を収集し、関係づけるようなプロセスを設定し、維持する
  • 目標7.3: 継続的な改善手法をICAMエンタープライズサービスに取り入れることによって、技術進歩を取り入れるとともに、進化するDoDコンポーネントのミッションの要求事項に取組むために、維持モードにおけるサービスを評価して改善できるようにする
  • 目標7.4: ICAM関連プロセスおよび技術: ICAM関連プロセスおよび技術を専門とするサイバー労働力の開発・維持に投資する
  • 目標7.5: 作戦保全(OPSEC)を、ICAM関連活動の計画策定、実行、評価に統合する

国防総省は、ICAM戦略を調達基準の一部と位置づけて、属性ベースアクセス制御(ABAC)に必要な基盤構築や、マルチステークホルダーエコシステムを前提とする監査対応準備など、多層防御的なソリューションを積極的に実装・運用している。

ICAM実装支援のための参照設計書を開発・提供

ICAM戦略を受けて、国防総省CIO室(DoD CIO)は、2020年6月に「DoDエンタープライズのアイデンティティ・資格情報・アクセス管理(ICAM)参照設計」(https://dodcio.defense.gov/Portals/0/Documents/Cyber/DoD_Enterprise_ICAM_Reference_Design.pdf) を策定している。本参照設計書では、以下のような目的を掲げている。

  • ミッションのオーナーが、ミッションパートナーによる認可されたアクセスの実現など、ミッションのニーズを満たせるように、ICAM要求事項を理解し、現状および計画におけるDoDエンタープライズICAMサービスを記述することによって、ICAM実装に関する意思決定を可能にするよう支援する
  • DoDエンタープライズICAMサービスのオーナーやオペレーターが、これらのサービスを有効に相互作用させてICAMケーパビリティをサポートできるよう支援する
  • DoDエンタープライズサービスがミッションのニーズを満たさない場合、DoDコンポーネントが、DoDエンタープライズICAMサービスを利用する方法や、DoDコンポーネント、COIまたはローカルレベルのICAMサービスを運用する方法を理解する際にサポートする

その上で、本参照設計書は、以下のような構成になっている。
(DISA=国防情報システムセンター、DMDC=国防マンパワーデータセンター、NSA=国家安全保障局)

1.イントロダクション

  • 1.1目的
  • 1.2適用
  • 1.3 DoDコミュニティ
  • 1.3.1. DoD内部コミュニティ
  • 1.3.2. 外部ミッションパートナー・コミュニティ
  • 1.3.3. 受益者
  • 1.3.4. 他の主体
  • 1.4 DoDの計算処理環境
  • 1.5参考文献
  1. ICAMケーパビリティの概要
  • 2.1 トランスフォーメーションの目標
  • 2.2 ICAMケーパビリティ分類の概要(DoDAF CV-2)
  • 2.2.1. コアICAMケーパビリティ
  • 2.2.1.1 アイデンティティ管理
  • 2.2.1.2 資格情報管理
  • 2.2.1.3 アクセス管理
  • 2.2.2. アクセス説明責任ケーパビリティ
  • 2.2.2.1 ログ収集と集約
  • 2.2.2.2 アクセスのレビュー
  • 2.2.2.3 アイデンティティの解決
  • 2.2.3. コンタクトデータ・ケーパビリティ
  • 2.2.3.1 コンタクトデータの収集
  • 2.2.3.2 コンタクトデータ・ロックアップ
  • 2.3 DoDエンタープライズICAMサービスの利用
  • 2.3.1. DoDエンタープライズICAMサービスの利用からのDoDエンタープライズのベネフィット
  • 2.3.2 DoDエンタープライズICAMサービスの利用からの情報システムのベネフィット
  • 2.3.3 DoDエンタープライズICAMサービスの利用に対する課題の低減
  1. ICAMデータフロー
  • 3.1 コアICAMケーパビリティ
  • 3.1.1. アイデンティティ管理
  • 3.1.1.1 人間主体
  • 3.1.1.2 人間以外の主体(NPE)
  • 3.1.1.3 連携主体
  • 3.1.2. 資格情報管理
  • 3.1.2.1 内部資格情報管理
  • 3.1.2.2 外部資格情報登録
  • 3.1.3. アクセス管理
  • 3.1.3.1 リソースアクセス管理
  • 3.1.3.2 プロビジョニング
  • 3.1.3.3 認証
  • 3.1.3.4 認可
  • 3.2 アクセス説明責任ケーパビリティ
  • 3.2.1. ログの収集と集約
  • 3.2.2. アクセスのレビュー
  • 3.2.3. アイデンティティの解決
  • 3.3 コンタクトデータ・ケーパビリティ
  1. ICAMパターンと関連するユースケース
  • 4.1 アイデンティティと資格情報のパターン
  • 4.1.1. 非機密エンタープライズDoDの内部初期登録
  • 4.1.2. 非機密エンタープライズミッションパートナー主体の登録
  • 4.1.3. 利害関係ユーザコミュニティの登録
  • 4.1.4. 利害関係人間主体アイデンティティプロバイダの登録
  • 4.1.5. DoDおよび連邦政府機関向け機密エンタープライズ登録
  • 4.1.6. 連邦政府機関以外のミッションパートナー主体向けの機密エンタープライズ登録
  • 4.1.7. 短期の人間以外の主体(NPE)の登録
  • 4.1.8. DoD受益者の登録
  • 4.1.9. DoD応募者の登録
  • 4.2 アクセス管理のパターン
  • 4.2.1. DoD管理下のリソースへのアクセス
  • 4.2.2. 予期せぬ主体向けのアクセス
  • 4.2.3. 特権ユーザアクセス
  • 4.2.4. ゼロトラスト
  • 4.2.5. Software as a Service (SaaS)クラウドマネージドシステムへのアクセス
  • 4.3 アクセス説明責任のパターン
  • 4.3.1. ロギングとモニタリング
  • 4.3.2. アクセスのレビュー
  • 4.3.3. アイデンティティの解決
  • 4.4 コンタクトデータ・ルックアップ
  1. DoDエンタープライズICAMサービス
  • 5.1 DoD ICAMエンタープライズサービスの概要
  • 5.2 プロダクションDoD ICAMエンタープライズサービス
  • 5.2.1. 個人データレポジトリ(PDR) (*DMDCが運用)
  • 5.2.2. アイデンティティ解決サービス(*DMDCが運用)
  • 5.2.3. トラステッド・アソシエイト・スポンサー・プログラム(TASS) (*DMDCが運用)
  • 5.2.4. DoD公開鍵インフラストラクチャ(PKI)(*DISAとNSAが運用)
  • 5.2.5 リアルタイムの自動本人確認システム(RAPIDS) (*DMDCが運用)
  • 5.2.6. 非機密インターネットプロトコルルータ(NIPRNet)エンタープライズ代替トークンシステム(NEATS)/代替トークン発行管理システム(ATIMS) (*DMDCが運用)
  • 5.2.7. Purebred (*DISAが運用)
  • 5.2.8. DoDセルフサービス(DS)ログオン(*DMDCが運用)
  • 5.2.9. エンタープライズアイデンティティ属性サービス(EIAS) (*DMDCが運用)
  • 5.2.10. アイデンティティ同期サービス(IdSS)(*DMDCが運用)
  • 5.2.11. milConnect(*DMDCが運用)
  • 5.2.12. エンタープライズディレクトリサービス(EDS)(*DISAとDMDCが運用)
  • 5.2.13. グローバルディレクトリサービス(GDS)(*DISAが運用)
  • 5.3 計画されたDoD ICAMエンタープライズサービス
  • 5.3.1. ミッションパートナー登録(MPR)(*DMDCが開発中)
  • 5.3.2. アイデンティティプロバイダ(IdP)(*DISAが開発中)
  • 5.3.3. 多要素認証(MFA)登録サービス(*DMDCが開発中)
  • 5.3.4. EIAS(強化型)
  • 5.3.5. バックエンド属性交換(BAE) (*DMDCが運用)
  • 5.3.6. DSログイン(強化型)
  • 5.3.7. 自動アカウントプロビジョニング(AAP) (*DISAが開発中)
  • 5.3.8. マスタユーザレコード(MUR) (*DISAが開発中)
  1. ICAM実装責任
  • 6.1 DoD ICAM共同プログラム統合室(JPIO)の責任
  • 6.2 DoD ICAMサービスプロバイダの責任
  • 6.3 DoDコンポーネントの責任
  • 6.3.1. DoDコンポーネントレベルのICAMガバナンス
  • 6.3.2. DoDエンタープライズICAMサービスのサポート
  • 6.3.3. DoDエンタープライズICAMサービスの利用
  • 6.3.4. COIとローカルICAMサービスの運用
  • 6.4 外部連携ICAMサービスプロバイダに関連する責任
  1. ICAMサービスギャップの概要

上記からわかるように、国防総省は、様々なアイデンティティ/アクセス管理関連サービスを開発・運用している。複数サービスが並列する中で、関与する各ステークホルダーの組織的責任体制を明確化しており、国防総省関連のバイオ技術・バイオ製造プロジェクトにおける外部委託先となるユーザ企業にとって参考になる点も多い。

加えて国防総省は、2021年7月29日、「国防総省(DoD)クラウドネイティブ・アクセスポイント(CNAP)参照設計(RD)第1.0版」(https://dodcio.defense.gov/Portals/0/Documents/Library/CNAP_RefDesign_v1.0.pdf)を策定している。CNAPは、ゼロトラストアーキテクチャ(ZTA)を活用して、どこでも、いつでも、どのデバイスからも、認可されたDoDユーザやエンドポイントによる、商用クラウド環境内のDoDリソースへの安全な認可されたアクセスを提供することを目的としている。

この参照設計書は、CNAP内部における一連のケーパビリティ、基盤コンポーネント、データフローを記述し、定義することを目的としている。本書は、CNAPを実装、接続、運用するための論理的設計パターンおよび派生的な参照実装を提供するものであり、戦闘軍司令官、軍事機関、国防情報システム局(DISA)およびその他の国防機関、商用クラウドおよび政府クラウドにおいてDoDリソースへのアクセスを必要とするミッションパートナーを対象としている。

内容

  • 1.1. 目的
  • 1.2. スコープ
  • 1.3. 対象読者
  • 1.4. ハイレベルのユーザストーリー
  1. 想定と原則
  • 2.1 想定
  • 2.2 原則
  1. ケーパビリティの概要
  • 3.1. CNAPケーパビリティ分類の概要(DoDAF CV-2)
  • 3.2. コアCNAPケーパビリティ
    • C.1 – 認証・認可された主体
    • C.2 – 認証されたIngress
    • C.3 – 認可されたEgress
    • C.4 – セキュリティのモニタリングとコンプライアンスの強制
    • 3.2.4.1 モニタリングと救済策
    • 3.2.4.2 コンプライアンス監査と強制
    • 3.2.4.3 CSSP/DCOによる統合型可視性
    • 3.2.4.4 継続的な運用認可(cATO)
  1. データフロー
  • 4.1. CSPポータルアクセス
  • 4.2. SaaSアクセス
  • 4.3. 認可されたIngress
  • 4.4. 認可されたEgress
  • 4.5. セキュリティのモニタリングとコンプライアンスの強制
  1. 論理的設計パターン
  • 5.1. ミッションオーナー(MO)のクラウドエンクレイブへのアクセス
  • 5.2. SaaSサービスへのアクセス
  1. 実装責任
  • 6.1. DoDエンタープライズの責任
  • 6.2. ミッションオーナー(MO)の責任
  • 6.3. ミッションパートナー
  • 6.4. クラウドサービスプロバイダ(CSP)の責任
  1. 参考文献
  • 附表A – 頭字語
  • 附表B – 用語集
  • 附表C – 推奨されるポリシーのアップデート

なお、CSAのゼロトラストリサーチ・ワーキンググループでは、ZTワークストリーム・アイデンティティ(ZT3)が、「IAM向けのゼロトラスト原則とガイダンス」を作成中であり、近日中に公開予定である(https://cloudsecurityalliance.org/artifacts/zero-trust-principles-and-guidance-for-iam/)。この作成作業においても、国防総省の各種ドキュメントが参照されている。これに先立ちCSAでは、「ゼロトラストアーキテクチャにおける医療機器」(https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2023/05/Medical-Devices-In-A-Zero-Trust-Architecture_050423-J.pdf)を公開している。

米国の場合、連邦政府機関のみならず、大規模な医療施設や教育・研究機関においても、ゼロトラストアーキテクチャの実装に向けた動きが活発化している。ゼロトラストアーキテクチャは、アクセス制御と密接に関わっており、この領域での新たなソリューション開発に対する期待が高まりつつある。

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

ゲノムデータのサイバーセキュリティとアクセス制御(前編)

次世代シーケンサーや再生医療に代表されるバイオ技術/バイオ製造の領域では、電子制御技術/OTと情報通信技術/ITの融合が進む一方、セーフティとサイバーセキュリティの両面でリスクをどのように管理するかが大きな課題となっている。

大統領令で加速した米国のバイオ技術/製造R&D推進策

2022年9月12日、米国大統領行政府は、「持続可能な安全でセキュアな米国のバイオエコノミーのために進化するバイオ技術/バイオ製造に関する大統領令」(関連情報)を発表した(https://www.whitehouse.gov/briefing-room/presidential-actions/2022/09/12/executive-order-on-advancing-biotechnology-and-biomanufacturing-innovation-for-a-sustainable-safe-and-secure-american-bioeconomy/)。この大統領令は、以下のような構成になっている。

第1条.政策
第2条.調整
第3条.さらなる社会的目標に向けたバイオ技術/バイオ製造R&Dの利用
第4条.バイオエコノミーのためのデータ
第5条.活気のある国内バイオ製造エコシステムの構築
第6条.バイオベース製品の調達
第7条.バイオ技術/バイオ製造の労働力
第8条.バイオ技術規制の明確性と効率性
第9条.バイオセーフティとバイオセキュリティの進化によるリスクの低減
第10条.バイオエコノミーの評価
第11条.米国のバイオエコノミーに対する脅威の評価
第12条.国際的な関与
第13条.定義
第14条.一般規定

サイバーセキュリティ/プライバシー保護の観点から大統領令をみると、「第1条.政策」の中で、以下のような政策を掲げている。

(b)バイオ技術/バイオ製造のイノベーションを進化させる生物学データエコシステムを促進する一方、セキュリティ、プライバシー、責任ある研究規範の原則を順守する
(j)脅威やリスク、潜在的脆弱性(外国の敵対者によるデジタル侵入、操作、流出の取組など)を評価、予想することによって、また、技術的リーダーシップや経済的競争力の保護目的で共同してリスクを低減するために、民間セクターおよびその他の主要なステークホルダーと連携することによって、前向きでプロアクティブなアプローチを採用し、米国のバイオエコノミーをセキュアにし、保護する
(k)米国の原則や価値と一貫した方法で、また安全でセキュアなバイオ技術/バイオ製造の研究やイノベーション、製品開発、利用のためのベストプラクティスを促進する方法で、バイオ技術R&Dにおける協力関係を強化するために、国際的なコミュニティに関与する

さらに、「第4条.バイオエコノミーのためのデータ」では、セキュリティ、プライバシーおよびその他のリスク(悪意のある誤用、操作、流出、削除など)を特定し、これらのリスクを低減するためのデータ保護計画を提供するとしている。また、国土安全保障省長官は、国防総省長官、農務省長官、商務省長官(NIST長官を通じて行動する)、保健福祉省長官、エネルギー省長官、行政管理予算局(OMB)長と調整しながら、国家サイバーセキュリティの向上に関する大統領令第14028号(2021年5月12日付)(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)および関連する法律に従って、連邦政府情報システムに保存された生物学的データ向けの適切なサイバーセキュリティベストプラクティスを特定し、提供するとしている。さらに、商務省長官は、NIST長官を通じて行動し、保健福祉省長官と調整しながら、大統領令第14028号の規定に従って、米国連邦政府に販売するソフトウェア開発向けベースラインセキュリティ標準規格を設定する際に、研究器具、計装機器、データマネジメント向けソフトウェアを含むバイオ関連ソフトウェアを考慮すべきであるとしている。

米国防総省のバイオ推進策に組み込まれたサイバーセキュリティ強化

この大統領令を受けて、国防総省(DoD)は、同月14日、「新たなバイオ技術大統領令は、米国の経済・国家安全保障のために国防総省のバイオ技術を進化させる」(https://www.defense.gov/News/Releases/Release/Article/3157504/new-biotechnology-executive-order-will-advance-dod-biotechnology-initiatives-fo/)と題した声明文を発表している。

その中で国防総省は、バイオ製造向けに総額12億米ドルの新規投資を行うことを発表した。新たなバイオ製造能力は、国防総省の複数のミッション領域に渡る物流課題への取組を支援するとしている。具体的なメリットとしては、以下のような点を挙げている。

  • 脆弱なサプライチェーンに依存することなく、重要な材料を国内で供給する
  • 極超音速機から潜水艦まで、新たな特性を有する材料を開発する
  • 材料やエネルギー製品の開発のために、必要なポイントで製造することにより、物流や再供給のタイムラインを大幅に削減する

また、国防総省は、今後5年間で総額10億米ドルをバイオ産業の国内製造インフラストラクチャに投資し、米国のイノベーターがアクセス可能な国内バイオ産業の製造基盤構築を促進する計画を発表した。これが、民間および国防双方のサプライチェーンにとって重要な製品の製造能力を拡大するための官民連携パートナーシップに対するインセンティブとなるとしている。加えて、これらの施設のバイオセキュリティやサイバーセキュリティのポスチャーを強化するために、総額2億米ドルを投入するとしている。

さらに国防総省は、バイオ技術におけるプロトタイピングや運用の実証、迅速な生産を加速させるために、以下のような施策を踏襲するとしている。

  • バイオ技術ソリューションをミッションのニーズに結びつけて提供する
  • データ共有、標準的なワークフロー、自動化能力を実現する共有基盤により、迅速なプロトタイプのパイプラインを構築する
  • バイオ倫理、バイオセーフティ、バイオセキュリティにおいてリードする
  • 将来に向けて、多様で学際的な労働力を育成する
  • 産業やアカデミック、国際的なパートナーと効果的に連携する

特に、バイオ技術の進化において重要な役割を担うのが、国防総省傘下の製造イノベーション研究所(MIIs)である。ここでは、2016年12月、国防長官府により創設された先進再生製造研究所(ARMI)傘下のBioFabUSA(https://www.armiusa.org/)と、2020年10月に創設されたバイオ産業製造・設計エコシステム(BioMADE)(https://www.biomade.org/)を挙げている。

米国防総省がバイオ製造戦略および付随するRFIを公表

その後2023年3月22日、国防総省傘下の研究工学担当国防次官室は、「国防総省バイオ製造戦略」(https://www.defense.gov/News/Releases/Release/Article/3337235/dod-releases-biomanufacturing-strategy/)を発表した。国防総省のバイオ戦略は、以下の3つの原則より構成される。

  • 早期段階のイノベーションのために移行パートナーを確立する:
    本戦略は、バイオ製造能力を求めるDoD顧客の確立がDoD技術投資を導く。早期段階の科学が、作戦指揮官のミッション達成に役立つような能力の進化を目的としている点を保証するために、正式な要求事項の構築プロセスなどを活用する。
  • イノベーションの実践と適用を通して、バイオ製造を構築する:
    本原則は、国防総省が、バイオ製造業を国内で構築し、同盟者やパートナーとともに、自立した国内バイオ製造エコシステムを構築して、国防上のニーズを満たすだけでなく、現場における米国の継続的な競争力を保証するよう仕向けるものである。
  • バイオ製造エコシステムをマッピングし、将来の国防総省によるバイオ製造R&Dの取組を支援するようなメトリクスを追跡する:
    バイオ製造エコシステムは、比較的新しいため、現行のエコシステムを評価し、構築に合わせて変更を追跡することが不可欠である。それにより、将来の投資を優先順位付けし、導入リスクを低減するのに役立つような知識を提供する。

これと合わせて国防総省は、バイオ製造戦略の支援措置として、国防上のニーズへの取組を支援し、国防総省の投資により開発および商用化の取組が可能となるようなバイオ製造製品およびプロセス能力に関して、正式な情報提供依頼(RFI)(https://sam.gov/opp/8fec24f77b6046c9ae28dc99b2417e42/view)を発出している(募集期間:2023年4月23日まで)。具体的には、バイオ製造に関して、以下のようなソリューションに関する情報を求めている。

  • 国防総省が必要とする特殊化学品・素材(例.バイオ製造燃料およびエネルギー前駆体、スパイダーシルク、ポリマー、天然ゴム/ラテックスゴム、溶媒などの生合成ファイバー)を、利用可能で手頃な方法により製造する
  • バイオ複合・生体材料(例.強化特性を備えた調整可能な素材、自己修復型素材)を通じた、物流の費用、時間、エネルギーの削減を可能にする
  • 持続的な人体及び環境のインテリジェンス(例.水質モニタリング向けセンサー、海事システムにおけるバイオベースのエネルギー採取)のために、一貫したセンシング能力を維持する
  • パフォーマンスや保護に影響を及ぼす人間拡張システム(例.テーラーメイドのタンパク質)
  • 製品パフォーマンスの要求事項を充足または越えながら、環境面のインパクトを低減するような方法で、国防関連材料の製造を可能にする

国防総省がバイオ技術/製造関連企業に求めるセキュリティ調達要件

政府調達時のサイバーセキュリティ基準からみると、国防総省を含む連邦政府機関のサプライヤーとなる企業は、前提条件として、「NIST SP 800-53 連邦政府情報システム、および連邦組織のためのセキュリティ管理策とプライバシー管理策」(https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)の遵守が不可欠である。加えて、国防総省は、契約企業および再委託先企業に対して、国防総省調達規則附則(DFARS) の要求事項を遵守するよう求めている。国防総省傘下の教育・研究機関や医療施設とバイオ関連製品・サービスについて契約する企業も適用対象となる。

代表的なDFARSとしては、以下のようなものがある。

DFARSが参照する代表的な標準規格としては、「NIST SP 800-171 非連邦政府組織およびシステムにおけるCUI(管理対象非機密情報)の保護」(https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final)や、サイバーセキュリティ成熟度モデル(CMMI)フレームワーク(https://dodcio.defense.gov/CMMC/)がある。なお、NIST SP 800-171については、現在改訂第3版の改定作業が行われており(https://csrc.nist.gov/publications/detail/sp/800-171/rev-3/draft)、今後の動向を注視する必要がある。

国防総省独自のクラウドセキュリティ認証制度とFedRAMPの関係

クラウドセキュリティに関して、国防総省では、連邦情報セキュリティマネジメント法(FISMA)に基づくFedRAMP(Federal Risk and Authorization Management Program)(https://www.fedramp.gov/)とは別個に、国防情報システム局(DISA)が、国防総省指示に基づく「クラウドコンピューティングセキュリティ要求事項ガイド(SRG)」(最新版は2022年1月14日に発行されたVersion 1, Release 4)(https://public.cyber.mil/dccs/)に準拠した認証制度を運用している。最新版のSRGは、以下のような構成になっている。

1. イントロダクション

1.1 目的と対象読者
1.2 権限
1.3 スコープと適用可能性
1.4 SRGs/STIGs
1.5 SRGとSTIGの配分
1.6 文書改定と更新のサイクル
1.7 文書の構成

2. 背景

2.1 重要な用語
2.2 クラウドコンピューティング、クラウドサービスとクラウドデプロイメントモデル
2.3 クラウドサービスプロバイダー(CSP)とクラウドサービスオファリング(CSO)
2.4 国防総省リスク管理フレームワーク(DoD RMF)
2.5 連邦リスク認証管理プログラム(FedRAMP)
2.6 FedRAMP Plus
2.7 国防総省暫定認証

3 情報セキュリティ目標/インパクトレベル

3.1情報インパクトレベル

4. クラウドサービスオファリングのリスク評価/認証

4.1 エンタープライズ利用向け商用および国防総省以外のクラウドサービスの評価
4.2 国防総省編成&運用部門クラウドサービスおよびエンタープライズサービスアプリケーションの評価
4.3 クラウドサービスオファリングとミッションオーナーのりスク管理
4.4 CSPのCC SRGバージョン/リリースから最新のCC SRGバージョン/リリースへの移行
4.5 RFPへの対応と契約締結に関連する国防総省暫定認証:DFARSの翻訳
4.6 クラウドサービス対マネージドITサービス

5. セキュリティ要求事項

5.1 国防総省のセキュリティ制御関連ポリシー
5.2 法的考慮事項
5.3 継続的評価
5.4 CSPの国防総省公開鍵インフラストラクチャ(PKI)利用
5.5 ポリシー、ガイダンス、運用上の制約
5.6 物理的施設と人員の要求事項
5.7 データ漏えい
5.8クラウドサービスオファリングからの終了のためのデータ検索と破壊
5.9ストレージメディアとハードウェアの再利用と廃棄
5.10 アーキテクチャ
5.11 商用クラウドストレージにおける保存データの暗号化
5.12 バックアップ
5.13 国防総省の契約企業/国防総省コンポーネントのミッションオーナーのパートナーによるクラウドサービスオファリング利用
5.14 クラウドにおける国防総省ミッションオーナーのテストと開発
5.15 ポート、プロトコル、サービス、管理とクラウドベースのシステム/アプリケーション
5.16 モバイルコード
5.17クラウドベースのシステム/アプリケーション向けのレジストリとコネクション
5.18 サプライチェーンリスク管理評価
5.19 電子メールの保護

6. サイバー空間防衛とインシデント対応

6.1 サイバー空間防衛の概要
6.2 クラウドコンピューティング向け情報インパクトレベルの概念変更
6.3 サイバー空間防衛活動
6.4 サイバー空間防衛の役割と責任
6.5 サイバーインシデント報告と対応
6.6 警告、戦術指令と命令
6.7 継続的モニタリング/行動計画とマイルストーン(POA&Ms)
6.8 計画的停止の通知
6.9 サイバー空間防衛目的のPKI
6.10 脆弱性・脅威情報の共有

附表A. 参考文献
附表B. 用語集
附表C. 役割と責任
附表D. 暫定認証向けCSP評価パラメーター値
附表E. プライバシーオーバーレイ比較のコントロール/コントロール強化表と数値表

当初SRGのインパクトレベルは6段階が設定されていたが、現在はレベル2・4・5・6の4段階が使われている。各レベルの概要は以下の通りである。

  • インパクトレベル2:管理対象外非機密情報(FedRAMPモデレートベースライン(MBL)認証)
  • インパクトレベル4:管理対象非機密情報または管理対象外陽機密情報(インパクトレベル2認証+管理対象非機密情報固有のテーラーメイド設定による認証、またはFedRAMPハイベースライン(HBL)認証)
  • インパクトレベル5:管理対象非機密情報および非機密国家安全保障情報(U-NSI)/国家安全保障システム(NSS)(インパクトレベル4認証+国家安全保障システム(NSS)固有のテーラーメイド設定により認証する)
  • インパクトレベル6:機密情報でSECRET扱いの国家安全保障システム(NSS)(インパクトレベル5認証+機密情報のオーバーレイにより認証する)

その他、サイバーセキュリティのベストプラクティスに関連して、米国防総省傘下の国防情報システム局(DISA)は、「セキュリティ技術導入ガイド(STIGs)」(https://public.cyber.mil/stigs/)を公開している。国防総省は、「国防総省指令8500.01」により、DISAに対して、セキュリティ技術導入ガイド(STIG)のほか、コントロール相関識別子(CCI)、セキュリティ要求事項ガイド(SRGs)、そして国防総省のサイバーセキュリティポリシー、標準規格、アーキテクチャ、セキュリティコントロール、バリデーションの手順とともに導入した、一貫性のあるモバイルコードリスクカテゴリ・利用ガイドを構築・維持することを求めている。また同指令は、国防総省コンポーネントに対して、国防総省管轄下のすべてのITが、適用されるSTIGs、セキュリティ構成ガイド、SRGsを遵守するよう求めている。これらの規定は、国防総省向けにバイオ技術/バイオ製造関連製品・サービスを提供するサプライヤー企業にも適用される。

米国立衛生研究所(NIH)で、バイオ技術/バイオ製造領域のサイバーセキュリティに関わる専門家をみると、その多くが国防総省出身者であることがわかる。ミリタリーグレードのサイバーセキュリティ専門家をインハウスに抱えるNIHと同等レベルの体制を、日本国内に構築・運用することは容易でない。ここでキャッチアップできなければ、プラットフォーム力における日米間格差はさらに拡大することになる。日本のバイオテクノロジーは、まさに正念場を迎えている。

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

医療におけるITガバナンス・リスク・コンプライアンス(IT-GRC)(後編)

前編に引き続き、クラウドセキュリティアライアンス(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)のポリシーが有効であることを保証するために、医療提供組織は、最初に、適用される法律や規制を理解する必要がある。コンプライアンスからスタートすることによって、確固たる基盤を持ったプログラムの構築を確実なものにする。

第2ステップとして、包括的なリスク評価とギャップ分析を実行する。リスク分析では、医療提供組織が、(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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

 

グローバルプロバイダが日本語CAIQ評価レポートを登録する方法

2023年4月3日
CSAジャパン 諸角昌宏

本ブログは、すでに英語のCAIQ自己評価レポートをCSAのSTAR Registryに登録しているプロバイダ(グローバルにクラウドサービスを展開するプロバイダ)が、日本語でのCAIQ自己評価レポートをSTAR Registryに登録する方法について記載します。

  1. 日本語CAIQとSTAR Registryの状況
    まず、STAR Registryへの日本語CAIQ評価レポートの登録についての状況について説明します。

    • STAR Registryへの登録に必要なCAIQ評価レポートの内容(EXCELシートに書き込む言語)は、英語でも日本語でも可能です。
    • STAR Registryのサイトは英語でできているため、登録方法、運用はすべて英語になります。登録時の手順(ウエブの登録用画面等)はすべて英語になります。また、STAR Registryの検索等の運用もすべて英語になります。

この状況を踏まえて、CSAジャパンでは、「日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について」というブログで、日本語で評価したCAIQをSTAR Registryに登録する方法を紹介しています。しかしながら、こちらはあくまで日本のプロバイダがSTAR Registryに登録する場合を想定していますので、すでにCAIQを英語で登録されているプロバイダが日本語CAIQを追加する方法が分かりません。そこで、その方法について説明したものが本ブログになります。

  1. すでに英語版のCAIQ評価レポートを登録されている場合の日本語CAIQ評価レポートの登録方法CSAグローバルに確認したところ、複数言語に対して、以下の対応を行っています。
    STAR Registryの登録ページの以下のDocument Upload ページで、Supporting Documentにアップロードすることでできます。

    以下のようにすることで、英語版と日本語版の両方をアップすることができるとのことです。
    Primary Document: 英語版CAIQ
    Supporting Document #1: 日本語版CAIQ

    STAR Registryそのものはマルチリンガル対応していないのですが、複数のCAIQ評価レポートを公開する仕組みはできているので、これを使うことが可能になるということです。
    なお、登録自体は本社(英語版を登録した部署)の方でSTAR Registryを担当されている方と共同して行っていただく必要があります。

  2. 日本語版CAIQ評価レポート登録後のCSAジャパンの支援
    STAR Registryでは、日本語でCAIQ評価レポートを登録しているのを検索することができません。つまり、プロバイダが日本語で公開しているかどうかは、STAR Registryで該当するプロバイダの登録内容を確認してみないと分からないということになります。そこで、CSAジャパンでは、日本語でCAIQ評価レポートを公開しているプロバイダが一目でわかるように、また、日本語でCAIQ評価レポートを公開していることを周知できるように、以下のように支援しています。

    • CSAジャパンの以下のウエブページから、日本語版CAIQ評価レポートを公開しているプロバイダを紹介します。https://www.cloudsecurityalliance.jp/site/?page_id=19811
      現在、「準備中」ということで、プロバイダの情報が整い次第公開を開始します。
    • CSAジャパンのホームページの新着情報として紹介します。
    • CSAジャパン会員及び連携団体向けメールニュース配信を行います。
    • CSAジャパンのフェースブックグループから紹介します。
  1. 今後について
    CSAジャパンは、上記の方法による登録について、CSA本部の担当者およびSTAR/CCM/CAIQの責任者と連絡を取って対応します。従いまして、何か問題が発生した場合には、CSA本部と連携を取りながら対応していきます。
    それから、STAR Registryそのものをマルチリンガル対応にしていくことが必要と考えています。これに関しても、CSA本部と協議を進めていきたいと考えています。

以上

 

 

 

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

クラウドネイティブにおける新しい責任共有モデルとセキュリティの考え方

2023年3月29日
CSAジャパン クラウドセキュリティ自動化WG 諸角昌宏

クラウドの責任共有モデルは、サービスモデル(IaaS, PaaS, SaaS)に基づいて説明されてきた。しかしながら、新たに登場してきたコンテナ、サーバーレス等を用いたクラウドネイティブの環境における責任共有モデルを考えた場合、既存のサービスモデルに基づいた考え方ではカバーしきれないのではないかという懸念がある。CSA Silicon Valley Chapterでは、クラウドネイティブにおける新しい責任共有モデルの考え方を説明したThe Evolution of Cloud Computing and the Updated Shared Responsibilityというブログを2021年2月に公開した。これはCSAジャパンにより日本語化されクラウドコンピューティングの進化と新たな責任共有モデルとして公開されている。
ここでは、上記資料で説明されている新しい責任共有モデルに対して、CSAが公開した以下の資料におけるセキュリティの考え方を対応させることで、クラウドネイティブの責任共有モデルの考え方とそのセキュリティの考え方について統合して理解できるようにしたい。

なお、このクラウドネイティブの責任共有モデルは、標準として定められているものではなく、あくまで現段階における1つの考え方として提供されているものであるということは注意していただきたい。今後、NISTやISOにおいて、標準としてのクラウドネイティブの責任共有モデルが定義された際は、その標準に基づいて改めて考えていく必要がある。

  1. クラウドネイティブにおける新しい責任共有モデルの概要
    ここでは、まずクラウドネイティブにおける新しい責任共有モデルについて、「クラウドコンピューティングの進化と新たな責任共有モデル」の下図を用いて説明する。なお、ここで記述されているモデルをここからは便宜上「CNCFモデル」と呼ぶことにする。また、ここでは要点だけ説明するので詳細は上記資料を参照していただきたい。なお、下図は上記資料では英語で表記されているが、分かりやすくするため日本語に翻訳して表記している。
    図1 CNCFモデル(「クラウドコンピューティングの進化と新たな責任共有モデル」より引用、作成)

図の左で「CNCFレイヤー」と記載されているのはCloud Native Computing Frameworkとして、既存のサービスモデルのレイヤーに新たに追加されたクラウドネイティブのレイヤーである。これらのレイヤーは以下の内容になる。

  • プロビジョニングサービスプレーン
    このレイヤーは、コントロールプレーンにあたる。ここでは、Kubernetesで説明されているが、Dockerコントロールプレーンでも同様に扱うことができる。プロビジョニングサービスプレーンでは、コンテナの稼働や停止等の運用や、コンテナの配置、デプロイ時のコンテナ入れ替えや仮想ネットワークの提供等を行う。
    セキュリティの観点からは、コンテナのセキュリティを実装されるために必要となる機能およびアーキテクチャを提供するレイヤーとなる。
    このレイヤーは、IaaSを除くすべてのモデル(K8s-aaS, CaaS, FaaS, NoCode, SaaS)においてプロバイダの責任となる。IaaSにおいては、このレイヤーにあたるKubernetesやDockerを利用者がインストール・設定・運用・管理を行うため、利用者側の責任となる。
  • マネージドサービスランタイム
    このレイヤーは、データプレーンにあたる。コンテナが稼働する実行環境、もしくはサーバーインスタンスそのもので、コンテナランタイムを管理する。コントロールプレーンが提供する機能を実際にコンテナランタイムに対して実施するレイヤーとなる。
    サーバーレスの観点では、コントロールプレーンとデータプレーンの両方をプロバイダが管理することで、利用者はコンテナクラスタや仮想マシンなどのインフラストラクチャを管理しなくてもクラウドネイティブサービスに簡単に移行できるようになる。したがって、このマネージドサービスランタイムのレイヤーまでをプロバイダが管理するモデル(CaaS, FaaS, NoCode)がサーバーレスのモデルということになり、K8s-aaSはサーバーレスではないことになる(注:SaaSはアプリケーションを含むクラウド全体をプロバイダが管理するので、サーバーレスのカテゴリーからは除くこととする)。
  • アプリケーションビルドとパッケージ化
    このレイヤーは、コンテナイメージの作成、コンテナ環境への移動・実施といういわゆるビルドチェーンを管理する。クラウドネイティブの観点では、このレイヤーを利用者が管理する(CaaS)のか、あるいはプロバイダが管理する(FaaS, NoCode)のかということになり、サーバーレスの責任共有を考える上では重要なレイヤーとなる。後ほどサーバーレスの章で説明する「コンテナイメージベースのサーバーレス」(CaaS)と「機能ベース(ファンクションベース)のサーバーレス」(FaaS, NoCode)として、それぞれの責任を明確にすることが必要となる。
  • アプリケーション定義と開発
    このレイヤーは、アプリケーションのコードロジックを定義・開発する。アプリケーションの仕様と構成からコードを生成する際に、利用者が自身でコードロジックを作成する(FaaS)のか、あるいは、プロバイダが利用者の作成した仕様と構成からコードを生成する(No-Code)に分類される。クラウドネイティブの観点からは、この2つのモデルの差はあまりなく、FaaSの場合には利用者がビジネスロジックを直接コード化する(Python等を用いる)のに対して、No-Codeの場合にはプロバイダが提供するGUI等を用いてドラグ&ドロップなどによってコードロジックを作成する。No-Codeに対してLow-Codeという方法もありこれはGUIだけでなく一部のコードロジックについては直接作成する。
    セキュリティの観点では、このレイヤーは基本的に利用者が管理を行うが、No-Codeの場合にはGUIを提供する部分がプロバイダの責任となる。責任共有の観点からはあまり区別する必要は無いと思われる。
  1. コンテナセキュリティ
    ここでは、CSAが公開している「安全なアプリケーションコンテナアーキテクチャ実装のためのベストプラクティス」に基づいてコンテナセキュリティについて説明する。この資料では、コンテナのセキュリティについてアプリケーションの開発者および運用者の観点で書かれているので、上記のモデルのK8s-aaSを対象として考えるのが分かりやすい。つまり、この資料の登場人物である「開発者」を利用者、「運用者」をプロバイダと読み替えることで、K8s-aaSの責任共有モデルとして表現できる。

    • CNCFレイヤーとコンテナセキュリティ
      まず、本資料で記述しているコンテナセキュリティの構成要素をCNCFレイヤーに対応付けると以下になる。

      • プロビジョニングサービスプレーン
        プロビジョニングサービスプレーンを構成しているのは、プラットフォーム管理、コンテナ管理で、運用者がこれらの機能を提供している。
      • マネージドサービスランタイム
        プロビジョニングサービスプレーンで提供されている機能を用いて、開発者がコンテナランタイムの管理を実施する。
      • アプリケーションビルドとパッケージ化、アプリケーション定義と開発
        この2つのレイヤーは、アプリケーションの設計、開発、ビルド、実行を行うもので、開発者が管理する。
    • コンテナセキュリティの内容
      ここでは、コンテナセキュリティについて、主なポイントとなる点を説明する。詳細については上記資料を参照していただきたい。

      • 開発者のアプリケーションセキュリティ
        • 開発環境全体(開発、品質保証、テスト、本番)のコードプロモーションのセキュリティ対策として、コンテナイメージに署名し信頼の起点(root of trust)を確立する。
        • 開発プロセスの一部として脆弱性スキャンを行う。
        • イメージの中には必要なコンポーネントのみを入れる。
        • アプリケーションにログ機能、フォレンジック機能を含める。
        • アプリケーションにシークレット管理機能を取り込む。
        • コンテナイメージの暗号化、保存データの暗号化を行う。
      • 運用者のアプリケーションセキュリティ
        • ビルドチェーンの完全性を確保するため、デジタル署名を使用し検証するための機能を提供する。
        • 署名され承認されたイメージだけを使用許可するための機能を組み込む。
      • 運用者のホストセキュリティ(ホストセキュリティは開発者は無し)
        • 通信の暗号化を行う。
        • コンテナを特権モードで実行しない。
        • 基本的に、コンテナランタイムにホストファイルシステムへのアクセスを許可しない。
        • 限定的なcapability設定でコンテナを起動する。ユーザが必要な機能以外を使用できないようにする。
      • 開発者のプラットフォームセキュリティ
        • コンテナで実行されるアプリケーションのバージョン管理を行う。
      • 運用者のプラットフォームセキュリティ
        • ログの送信、集中管理の基盤を提供する。
        • コンテナのライフサイクル(起動から破棄まで)のイベントを開発者に通知できるようにする。これにより、開発者は適切な対応が取れるようになる。
        • リソースの消費を監視し、最適化する。
      • 開発者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性(暗号化)および双方向TLS等の相互認証メカニズムを使用する。
        • ネットワーク監視機能を使用する。
        • コンテナのフォレンジック機能、ログ機能を、アプリケーションにログ機能を含める。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。
      • 運用者のコンテナセキュリティ
        • ホストとコンテナ間の通信の機密性(暗号化)および双方向TLS等の相互認証メカニズムを提供する。
        • コンテナのフォレンジック機能、ログ機能を提供する。
        • コンテナのトラストチェーンの維持。OS およびコンテナイメージの完全性検証、脆弱性検査を実施する。
        • コンテナのリソース管理、ボリューム監視を行う。
        • 通信トラフィックの分離を行う。
        • シークレット管理機能を提供する。
        • データのバックアップとして、データの保存場所の特定、バックアップの定期的な実施、また、コンテナが消滅する前にバックアップされることを確認する。

以上のようなポイントを考慮してコンテナのセキュリティを考えていくことが必要である。

  1. サーバーレスセキュリティ
    サーバーレスは、CNCFモデルではCaaS, FaaS, No-Codeの各モデルが対象となる。サーバーレスのセキュリティとしてCSAが公開している資料は、「安全なサーバーレスアーキテクチャを設計するには」であり、ここではこの資料とCaaS, FaaS, No-Codeの各モデルをマップして説明する。サーバーレスセキュリティの基本的な考え方は、クラウド利用者(注:「安全なサーバーレスアーキテクチャを設計するには」では「アプリケーションオーナー」と表記)がデータの保護およびアプリケーションの保護のみの責任を持つ。一方、クラウドプロバイダ(注:「安全なサーバーレスアーキテクチャを設計するには」では「サーバーレスプラットフォームプロバイダ」と表記)がサーバーの立ち上げ、OSのパッチ適用、アップデート、シャットダウンなどのサーバーやそのセキュリティの管理の責任を持つ。これにより、アプリケーションオーナーはインフラの管理を気にせずにアプリケーションに集中することができる。「安全なサーバーレスアーキテクチャを設計するには」では、サーバーレスを2つの名称に分けて表現しており、1つは「コンテナイメージベースのサーバーレス」で、もう1つが「機能ベース(ファンクションベース)サーバーレス」である。この2つの名称をCNCFモデルに当てはめると以下のようになる。

    • コンテナイメージベースのサーバーレス: CaaS
    • 機能ベースのサーバーレス: FaaS, No-Code

機能ベースのサーバーレスにFaaS, No-Codeの2つのモデルを当てはめているが、FaaS, No-Codeの違いは「アプリケーション定義と開発」レイヤーにおける責任の一部の違いであり、サーバーレスのセキュリティを考える上では同じものとして扱うことで問題ないと考える。

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス(CaaS)ではアプリケーションオーナー(利用者)の責任となるが、機能ベースのサーバーレス(FaaS, No-Code)ではサーバーレスプラットフォームプロバイダ(プロバイダ)の責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス(CaaS)、機能ベースのサーバーレス(FaaS, No-Code)のどちらにおいても利用者の責任となる。

この責任の考え方については、「安全なサーバーレスアーキテクチャを設計するには」で表現されている以下の2つの図が分かりやすい。「コンテナイメージベースのサーバーレス(注:この図では「イメージベースのサーバーレスの責任共有モデル」と表現)」(左図)では、コンテナイメージの責任がアプリケーションオーナー、つまりクラウド利用者となっているのに対して、「機能ベースのサーバーレス(注:この図では機能ベースのサーバーレス(FaaS)の責任共有モデル」と表現)」(右図)では、このコンテナイメージの責任がサービスプロバイダとなっている。この違いは、CNCFモデルにおける「アプリケーションビルドとパッケージ化」レイヤーの責任の違いとなる。

図2 「安全なサーバーレスアーキテクチャを設計するには」より引用

なお、これらをAWS、Azure、Googleのサービスに照らし合わせると以下になる。

  • コンテナイメージベースのサーバーレス(CaaS)
    AWS Fargate、Azure Container Instances(ACI)、GoogleCloudRunなど
  • 機能ベースのサーバーレス(FaaS, No-Code)
    FaaS: AWS Lambda、Azure Functions、Google CloudFunctions
    No-Code: Azure Power Apps、Google AppSheet、AWSHoneycode

これをCNCFレイヤーとサーバーレスのセキュリティを対応付けると以下になる。

  • アプリケーションビルドとパッケージ化
    コンテナイメージベースのサーバーレス(CaaS)ではアプリケーションオーナーの責任となるが、機能ベースのサーバーレス(FaaS, No-Code)ではプロバイダの責任となる。
  • アプリケーション定義と開発
    コンテナイメージベースのサーバーレス(CaaS)、機能ベースのサーバーレス(FaaS, No-Code)のどちらにおいてもアプリケーションオーナーの責任となる。

「アプリケーションビルドとパッケージ化」におけるセキュリティは、「2. コンテナセキュリティ」で説明した内容となるのでそちらを参照していただきたい。あくまで、これがアプリケーションオーナーの責任になるかプロバイダの責任になるかの違いである。
「アプリケーション定義と開発」におけるセキュリティについて、「安全なサーバーレスアーキテクチャを設計するには」では、アプリケーションオーナー(つまり、利用者)のセキュリティとして、ワークロードへの脅威の観点で以下の3点を挙げている。

  • セットアップフェーズの脅威
    アプリケーションオーナーがワークロードを準備し、コード、イメージ、CI/CD作業、デプロイに関する脅威のことを言う。最小特権原則を維持していない呼び出し、およびセキュアでない構成管理の問題となる。
    サーバーレスにおいてはワークロードが小さな呼び出し可能なユニットに分割され、それぞれにセキュリティを管理する一連のパラメータ(ユーザの認証情報/アクセス件、呼び出し可能なユニットの認証情報/アクセス権、モニタリングなど)が設定される。これらに対して、最小権限の原則を維持することが必要である。また、この分割が増えることで、サプライチェーンの脆弱性の問題が起こる。ベースイメージの脆弱性、リポジトリに対する不正アクセス、ビルド/デプロイツールに対する攻撃などへの対応が必要である。
  • デプロイフェーズの脅威
    アプリケーションオーナーによるワークロードのデプロイフェーズでの脅威のことを言う。
    サーバーレスでは、様々なリソースからの膨大なイベントを利用する。イベントの一部として呼び出し可能なユニットに渡される情報はデータインジェクションの脅威となる。また、呼び出し可能なユニットが必要とするトークン、シークレットなどはグローバルコンテキストを必要とし、このグローバルコンテキストのリークが発生する脅威がある。
    また、サーバーレスで使用するコンピュートリソースは従量課金であるため、適切な感じと処理を行わないとリソースの枯渇等の問題が発生する。
    サーバーレスのワークロードは、データと制御パスの一部をサービスプロバイダにオフロードするため、開発とテストをクラウド上で行う必要がある。デバッグなどが制限される可能性もある。したがって、エラーメッセージが重要になる。
  • サービス事業者による脅威
    サービスプロバイダが使用するコンポーネントスタック全体および関連サービスの脅威が含まれる。
    まず重要なのがマルチテナントを維持するための隔離の問題である。サーバーレスでは、プロバイダが分離を確立する必要がある。また、インスタンスの起動/終了のオーバーヘッドを削減するために呼び出し可能なユニットの再利用を行う場合があるため、呼び出し可能なユニットの呼び出し間の漏洩および残留データの漏洩というサーバーレス固有の脅威もある。
    また、責任共有の問題として、サーバーレスではコードの設計、ランタイムのセキュリティの責任をアプリケーションオーナーが持つが、その中で機能ベースのサーバーレスの場合、プロバイダが提供する呼び出し可能なユニットの脆弱性が発生する可能性がある。コードの設計やイベントシステムのセキュリティだけでなく両者の相互作用についても考える必要がある。

以上が、アプリケーションオーナーのワークロードへの脅威の観点でのサーバーレスのセキュリティとなるが、「安全なサーバーレスアーキテクチャを設計するには」ではKubernetesのセキュリティからアプリケーションのセキュリティまでを詳細に記述している。Kubernetesのセキュリティは、「2. コンテナセキュリティ」でも記述されている部分になるが、より詳しくKubernetesの機能に基づいて記述しているので、参照していただきたい。

  1. まとめ
    以上、CNCFモデルをベースに、CSAが公開しているコンテナおよびサーバーレスのセキュリティに関する資料を参照しながら説明してきた。コンテナのセキュリティについては整理されてきているが、サーバーレスについてはまだ適切なセキュリティが明確になっていない。今後、様々な形で情報が提供されてくるので、それを見ていきながらサーバーレスとしてまとまった形でのセキュリティについて説明できるようにしていきたい。

以上