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

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

前編では、医療のサードパーティベンダーリスク管理のうち、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/)を公開している。この文書は、医療分野のサプライチェーンに潜むサイバーリスクを最小化するために、医療機関が、適切なリスク管理プラクティスを実践し、サプライヤーやサードパーティベンダーに対するリスク評価を行う際の課題や対策の方向性を示したものである。

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

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

前編はこちら

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つのカテゴリーに合わせたコンテンツ作成・発信を行っている点が特徴である。たとえば、経営管理部門向けには、以下のようなメニュー構成の情報発信を行っている。

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

続きを読む

データの暗号化における利用者鍵管理について

データの暗号化における利用者鍵管理について

2022年2月9日
データセキュリティ WGメンバー: 諸角昌宏

本ブログでは、クラウド利用において必要となる利用者鍵管理について解説する。

  1. 利用者鍵管理の必要性について

    クラウドでは共有責任モデルとしてユーザーがデータセキュリティの責任を持ちます。そのデータを保護する技術として「暗号化」が有効な技術であることが各法規制やガイドライン等で言及されており、多くの情報システムにおいて暗号技術は活用されています。
    また暗号化技術を利用する場合には「暗号鍵」もユーザーの責任で保護する必要があり、ユーザー自身の責任で鍵管理技術を理解して実装方法を選択して運用する必要があります。」(引用: Cloud Data Protection, https://www.cloudsecurityalliance.jp/site/wp-content/uploads/2021/08/Cloud_Data_Protection2_V10.pdf

    また、クラウドコンピューティングのためのセキュリティガイダンス V4.0(https://cloudsecurityalliance.jp/j-docs/CSA_Guidance_V4.0_J_V1.2_clear_20200806.pdf)では、利用者が管理できる鍵(Customer-Managed Keys)」という手法の説明として、「利用者が管理できる鍵は、クラウド事業者が暗号化エンジンを管理するのに対して、クラウド利用者が自身の暗号鍵を管理できるようにする。例えば、SaaSプラットフォームの中でSaaSデータを暗号化するのに利用者自身の鍵を使う。クラウド事業者の多くは、デフォルトでデータを暗号化するが、事業者自らの完全な管理下にある鍵を使う。一部の事業者では、利用者が自分の鍵に差し替えて事業者の暗号化システムに組み入れることを許している。利用する事業者のやり方が利用者自身の要求条件と合致するか確認する必要がある。」と記載している。

    クラウドにデータを暗号化して保存する場合において、プロバイダーが鍵を管理すると以下のような問題が発生する可能性がある:

    • クラウド側のインサイダー(管理者)による情報侵害が発生する可能性がある
    • クラウド上に暗号化データと暗号化鍵の両方が存在するため、クラウド環境が侵害された場合(例えば、利用者間の論理境界が破られるなど)に情報漏洩につながる可能性がある
    • 召喚状等によりプロバイダーが利用者データの開示を求められた場合、クラウド上に暗号化して保存していたデータであっても、プロバイダーが復号して提供することが可能になる

半面、利用者がデータを暗号化し暗号鍵を保持する場合、アプリケーション(クラウドサービス)がそのデータを処理できないという問題が発生する。IaaSにおいては、利用者がアプリケーションとデータの両方を管理できるため、利用者が暗号化鍵を管理することが可能だが、SaaS環境においてはこの問題に直面する。

そこで考えられたのが「利用者による鍵管理(以下、利用者鍵管理と呼ぶ)」という方法で、プロバイダーが暗号化エンジンを管理するのに対して、利用者が自身の暗号鍵を管理できるようにする仕組みである。本ブログでは、この利用者鍵管理についての規制等の要求事項、利用者鍵管理の手法、動作の例などについて説明していく。

  1. 利用者鍵管理に関係する規制・要求事項

    以下に、代表的な規格における利用者鍵管理の要求事項を記載する。

    • ISO/IEC 27017
      • 10.1.2:  クラウドサービスカスタマは,自らの鍵管理を採用する場合又はクラウドサービスプロバイダの鍵管理サービスとは別のサービスを利用する場合,暗号の運用のための暗号鍵をクラウドサービスプロバイダが保存し,管理することを許可しないことが望ましい。
    • CSA CCM V4
      • CEK-08: CSPはCSCがデータ暗号鍵を管理できる機能を適用しなければならない。
    • ISMAP
      • 10.1.1.9.PB: クラウドサービス事業者は、クラウドサービス利用者に、当該利用者の管理する情報の暗号化に用いる暗号鍵を当該利用者が管理し消去する機能を提供し、または、当該利用者が暗号鍵を管理し消去する機能を実装するために必要となる情報を提供する。
  1. 利用者鍵管理(BYOK、HYOK)とは?

    利用者鍵管理の構成として、前述の「Cloud Data Protection」では以下のように2つのタイプ(BYOK、HYOK)が記述されている。

    • BYOK(Bring Your Own Key)

      • ユーザー自身が暗号鍵を作成してクラウドサービスに持ち込むシステム構成
      • 持ち込んだ後の暗号鍵はクラウドサービス事業者内で管理
      • APIが公開されることが多く、オンプレミスのHSM等で作成した鍵をアプリケーションを開発することで持ち込むことが可能
    • HYOK(Hold Your Own Key)

      • クラウド事業者のサービスがユーザーの鍵管理システムを利用
      • ユーザーの暗号鍵はクラウドサービス事業者外部で管理

ここで、BYOKとHYOKの違いを明確にすると以下のようになる:

  • BYOKは、ユーザー自身が暗号鍵の作成・管理を行うが、プロバイダー側(つまり、クラウドのアプリケーション)が復号を行うにあたって、利用者から鍵を受け取る。受け取った鍵は、プロバイダー側で管理することになる。したがって、一度プロバイダーに渡された鍵を利用者が管理することはできない。
  • HYOKでは、利用者はプロバイダーの鍵管理システムを利用するが、暗号鍵の管理は利用者自らが行い、利用者の管理のもとプロバイダーは暗号鍵を扱うことができるようになる。したがって、利用者が常に鍵を管理することが可能になる。なお、このHYOKを提供する方法は、Microsoft Azureの2重キー暗号化 (Double Key Encryption) 、 Google Cloud External Key Manager、Salesforceキャッシュのみの鍵サービス(Cache-Only Key)などがあり、主なプロバイダーが提供している。

このBYOKとHYOKを明確にすることが重要であり、ここが利用者鍵管理として混同されている点である。特に、BYOKがバズワードとなっていて、利用者鍵管理=BYOK と扱われてしまっていることが問題となる。先に述べた様々な規格の要求事項は、HYOKが必要となることでありBYOKでは不十分であるということを理解する必要がある。

  1. 利用者鍵管理(HYOK)の動作例

    ここでは、HYOKの動作の1つの例を以下の図を使って説明する。

    まず、この図に表示されているそれぞれの鍵について説明する:

    • DEK(Data Encryption Key): データ暗号化鍵。データを暗号化および復号に使用
    • 暗号化DEK(Encrypted DEK) :DEKを暗号化したもの
    • KEK(Key Encryption Key):DEKの暗号化に使用される鍵
    • マスターキー:KEKの暗号化に使用される鍵

利用者から送られたデータを暗号化してストレージに保存する手順は以下になる:
(1) アプリケーションに利用者からデータが送られる
(2) アプリケーションは、KMSに対して、データ暗号化用の鍵(DEK)を要求する
(3) KMSは、DEKを作成し、KEKを使って暗号化DEKを作成し、DEKと暗号化DEKの両方をアプリケーションに送る
(4) アプリケーションは、DEKを用いてデータを暗号化し、暗号化されたデータと暗号化DEKをストレージに送る
(5) アプリケーションはDEKを削除する

次に、データを復号する手順は以下になる:
(1) アプリケーションは、ストレージから暗号化されたデータと暗号化DEKを入手する
(2) アプリケーションは、暗号化DEKをKMSに送る
(3) KMSは、KEMを用いてDEKを作成し、アプリケーションに送る
(4) アプリケーションは、DEKを使ってデータを復号する
(5) アプリケーションはDEKを削除する

以上の流れにおいて、プロバイダーがDEKを保有するのは、暗号化および復号の作業を行うときのみになる。また、一連の流れとして、利用者が鍵の管理を行うことができる。

  1. 利用者鍵管理に向けての考慮事項

    • BYOK  利用者鍵管理 について

      以上、説明してきたように、クラウド環境で必要とする利用者鍵管理はHYOKであり、BYOKでは不十分である。しかしながら、BYOKを利用者鍵管理として説明している資料も多数あるのも事実である。ここは悩ましいところであり、現状でこれを明確にしていくことはかなり難しいかもしれない。もちろん、BYOK、HYOKを正確に伝えることは重要であるが、ある程度BYOKとHYOKを区別せずに、HYOKとして必要な要求事項をベースにしてBYOKを説明することもやむを得ないと思われる。
      また、BYOKとHYOKを厳密に区別することが、逆に、利用者鍵管理は不要であるという印象を与えてしまっているケースもある。CSAが公開している「クラウドサービスの鍵管理(原書:Key Management in Cloud Services)」では、まとめとして、「いわゆるBYOK(Bring Your Own Key)や同様のモデルをクラウドサービスで使用したBYOKの意味は、通常期待される結果が得られないことを示しています。これらのいわゆるBYOKモデルを使用しようとしているほとんどの組織は、クラウドサービスプロバイダが利用者のデータを裁判所や法執行機関などの第三者に引き渡すことを強制できないことを期待しています。ただし、いわゆるBYOKモデルのほとんどのベンダーにおける実装では、クラウドサービスがデータ暗号化鍵を使用しているため、必要に応じてエクスポート用に暗号化されていないデータを生成できるので、実際にはその結果を防げません。」と記述している。これは、BYOKとHYOKを明確に区別した上でBYOKでは不十分であることを指摘しているのであるが、HYOKを含めた利用者鍵管理すべてが不十分であると理解されてしまっているところがある。この辺りは、CSAとしても明確に記述する必要があったと思われる。
      また、ISMAPのFAQ(https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010098&sys_kb_id=cfb60af91baebc1013a78665cc4bcb12&spa=1)において、「暗号鍵の管理に関するクラウドサービス事業者内部からの不正アクセス対策を別の手段で実現すること。①1.2(権限分離)、②7.2.1(従業員・契約相手へのセキュリティ)及び③9.2.3(特権的アクセス権の制限)を適切に実施…」という代替策を記述している。しかしながら、この代替案では、先に挙げたプロバイダーが鍵を管理する場合の問題点に対する対策にはならない可能性が高く、あくまでリスク管理上可能であれば取れる代替案であることを理解しておく必要がある。

    • SaaSにおける利用者鍵管理の実装について

      SaaSプロバイダーが利用者鍵管理を提供する場合、以下の2つのケースが考えられる:

      • SaaSプロバイダーが、第三者ベンダーが提供している利用者鍵管理機能を実装する。
      • SaaSプロバイダーが、インフラとして利用しているIaaS/PaaSプロバイダーが提供している利用者鍵管理を用いて実装する。

なお、SaaSプロバイダーが利用者鍵管理を評価・実装するには、ユースケースを含めた詳しい情報が必要であると思われる。利用者鍵管理を提供しているベンダーおよびIaaS/SaaSプロバイダーは、利用者鍵管理に関する情報を積極的に発信していただきたい。本ブログにおいても、今後、できるだけ情報発信できるようにしていきたい。

6. 暗号化の代替手段

これまで、利用者鍵管理について記述してきたが、利用者鍵管理が必要となるそもそもの暗号化について、その代替手段として以下の2つが考えられる。

  • トークン化

    トークン化はクレジットカードの保護等で実績がある仕組みであり、従来からの暗号化技術と同様検討に値する技術である。
    暗号化の問題は、アプリケーションが暗号化されたデータを処理できないという点である。利用者鍵管理の問題以前に、クラウド上のアプリケーションは、何らかの形で復号しないと処理できないという根本的な問題を抱えており、クラウドのマルチテナントを維持しなければならない環境において問題となる。トークン化されたデータは、元のデータと同じサイズ/形式で保管されるため、トークン化されたデータを保管するためにデータベースのスキーマやプロセスを変更する必要はない。データのトークン化により、クラウドやビッグデータ、外部委託環境に移行する際も、制御機能やコンプライアンスを維持することが可能である。ここでは、トークン化について詳しく述べないが、1つの代替手段と考えられる。

  • 完全準同型暗号

    アプリケーションが、暗号化データを復号せずに処理できる方法として、(完全)準同型暗号が考えられる。まだ、あまり一般に商用化されていないが、今後、幅広く利用されてくる可能性もある。今後の展開に注目したい。

以上、クラウド上のデータの暗号化として必要となる利用者鍵管理について記述した。これから先、新たな情報が得られれば、また、情報発信していきたい。

以上

Log4Shellとゼロトラスト

本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

Log4Shellとゼロトラスト

このブログは、Appgateのこちらの記事を元にしています。
著者:Jason Garbis、Appgate

Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが(関連する問題はまだいくつか残っています)、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA(Zero Trust Network Access)技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

管理者からサーバーへのアクセス(アップデートや設定変更など)には、ITサービスマネジメント(ITSM)のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます:

  • 例えば、SPA(Single Packet Authorization)を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
  • デバイスとユーザーのリスクへの対応:きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーデバイスに適切な権限を調整し付与することができます。
  • サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」(例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など)として知られる、リソースのやり取りに対するユーザー/デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです(例:リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム)。この両方をサポートするZTNAプラットフォームを見てください。
  •  幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM(Security Incident and Event Management)ソリューション、EDR(Endpoint Detection and Response)プラットフォーム、ITSMソリューションなどと統合する必要があります。
  • エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

日本語での評価レポートの公開方法およびLevel1セルフアセスメントの重要性について

本ブログでは、STAR Level1セルフアセスメントの重要性および日本語での評価レポートの公開方法について記述します。

2021年10月20日
CCM/STAR WGメンバー 諸角昌宏

クラウドサービスプロバイダが、提供するクラウドサービスのセキュリティ情報を公開することは非常に重要です。クラウドセキュリティにおける責任共有モデルにおいては、クラウドサービス利用者は、自身が管理するセキュリティとプロバイダが管理するセキュリティの両方を把握し説明責任を果たすことが必要で、そのためには、利用するクラウドサービスのセキュリティレベルを把握する必要があります。これは、利用者がプロバイダに直接確認することで行えますが、たくさんの利用者を抱えているプロバイダが、利用者ごとの問い合わせに対応することは非効率です。そこで、プロバイダが、提供しているクラウドサービスのセキュリティ情報をあらかじめ公開することで、利用者は公開された情報に基づいてクラウドサービスのセキュリティレベルを把握することができます。また、プロバイダは、利用者からの個別の問い合わせに対応する作業を削減することができますし、セキュリティ情報を積極的に公開することにより、セキュリティをビジネス上の差別化要因とすることができます。

STAR Level1セルフアセスメントは、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionnaire)に、プロバイダが自己評価した結果を記述し、それを公開するウエブサイト(CSA STAR Registry: https://cloudsecurityalliance.org/star/registry/)を提供しています。このCSA STAR Registryには、STAR認証が提供する3つのレベルの情報が公開されていますが、CAIQの評価レポートは、STAR Level1 セルフアセスメントとして公開されています。STAR Level1 セルフアセスメントのようなセキュリティの透明性に対する取り組みは、特に欧米のプロバイダは積極的に行っています。CSA STAR Registryには、1000以上のクラウドサービスが登録されていますが、その大部分がSTAR Level1セルフアセスメントとしてCAIQ評価レポートを公開しています。

CSAジャパンでは、日本のプロバイダが積極的にセキュリティ情報を公開できるように支援していきます。以下の2つのアプローチになります。

  1. 日本語CAIQ評価レポートの登録手順を日本語で提供
    STAR Level1 セルフアセスメントの登録手続きは、英語で行う必要があります。会社名やクラウドサービス名、およびそれらの概要等は、英語で記述する必要があります。CSAジャパンでは、日本語CAIQ評価レポートの作成から、STAR Level1 セルフアセスメントの登録までの一連の手順を日本語で記述しました。以下のウエブサイトを参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005
  2. 日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開
    CSA STAR Registryには、すべてのクラウドサービスの情報がアルファベット順にリストされています。この中から、日本語CAIQ評価レポートを公開しているプロバイダ及びクラウドサービスを探すことは難しいです。そこで、CSAジャパンでは、CSAジャパンのウエブサイトから、日本語 CAIQ評価レポートを公開されているプロバイダとクラウドサービスの情報を公開することとしました。以下のウエブサイトになります。
    https://www.cloudsecurityalliance.jp/site/?page_id=19811
    なお、日本語 CAIQ評価レポートを公開されているプロバイダ及びクラウドサービスをすべて把握することが難しく、このサイトの情報はCSAジャパンが把握できているもののみになります。日本語 CAIQ評価レポートを公開されていて、このサイトにリストされていないものがありましたら、以下のメールアドレスまでご連絡ください(注意: @の前後のクオーテーションを削除してください)。 info’@’cloudsecurityalliance.jp

以上

CSAの認証制度:STAR認証について

STAR認証について

2021年10月7日
CCM/STAR WGメンバー: 諸角昌宏

本ブログでは、CSA(Cloud Security Alliance)が提供するSTAR(Security, Trust & Assurance Registry)認証について、その概要、特徴、利用方法、CSAジャパンの活動について説明します。特に、STARレベル1(セルフアセスメント)について、プロバイダがクラウドサービスの自己評価レポートをCSA本部のウエブサイトより公開する方法について記述します。

  1. STAR概要

    STARは、CSAが提供するクラウドセキュリティの認証制度です。大きなフレームワークは以下の図1で示すように、3つのレベルを持っています。また、それぞれのレベルに対して、「セキュリティ認証」と「プライバシー認証」の2つのカテゴリーがあります。

    図1 STARフレームワーク

まず、「STAR認証レベル」について説明します。

  • STAR Level1

    STAR Level1はセルフアセスメントです。これは、クラウドサービスプロバイダが、CSAが提供しているCAIQ(Consensus Assessment Initiative Questionaire)に基づいて、自身が提供するクラウドサービスのセキュリティを独自に評価し、CSAのウエブサイト(https://cloudsecurityalliance.org/star/registry/)から公開するものです。CAIQは、CSAが提供するクラウドセキュリティの管理策集であるCCM(Cloud Control Matrix)のそれぞれの管理策について、いくつかの質問形式にブレークダウンしたものです。質問形式になっているため、クラウドサービスプロバイダは「YES」「NO」で回答することができます。また、回答に対するコメントを入力し、追加の情報を記述することができます。
    STAR Level1の特徴は、クラウドサービス利用者が、利用しようとしているクラウドサービスが自組織のセキュリティ要求事項を満たしているかどうかを、公開されている情報をもとに確認できることです。つまり、プロバイダの透明性が実現できているということになります。また、プロバイダの立場では、セキュリティ情報を積極的に公開することで、たくさんの利用者に対して統一したメッセージを出すことができますし、この情報をビジネス上の差別化要因として利用することもできます。
    STAR Level1の登録方法について、以下のウエブサイトに日本語で記述していますので参照してください。
    https://www.cloudsecurityalliance.jp/site/?page_id=1005

 

  • STAR Level2

    STAR Level2は、第三者評価になります。クラウドセキュリティの評価としてCCMを使用しますが、以下の示す他の業界認定や標準を基にして、クラウドセキュリティを評価しています。

    • CSA STAR CERTIFICATION: ISO/IEC 27001
    • CSA STAR ATTESTATION: SOC2
    • CSA C-STAR: GB/T22080-2008

STAR Level2の特徴は、認証だけでなく成熟度も評価していることです。クラウドサービスの成熟度を「ブロンズ」「シルバー」「ゴールド」のレベルとして認定します。
以下の図はSTAR CERTIFICATIONを表しています。

図2 CSA STAR CERTIFICATION 成熟度モデル

  • STAR Level3

    STAR Level3は、継続的モニタリングです。認証取得後も、その対応状況を継続的にモニタリングし保証する制度で、FedRAMPなどのハイレベルの情報を扱う際に要求されているものです。こちらは、まだ準備中になりますので、提供され次第ご案内できると思います。

それから、Level1、Level2には、Continuous Self-assessmentがあります。これは、通常の1年に1回の認証に対して、より頻度を上げた認証を行うようにしたものです。

次に「セキュリティ認証」と「プライバシー認証」について説明します。

  • セキュリティ認証

    セキュリティ認証は、上記で記述したように、CCMあるいはCAIQを用いて認証を行うものです。

  • プライバシー認証

    プライバシー認証は、クラウド環境におけるデータ保護法令遵守に必要な要件を定義した管理策であるCode of Conduct for GDPRを使用して認証を行うものです。GDPR向けの行動規範に準拠しているかどうかを認証します。

 

  1. STAR認証の特徴

    STAR認証では、今までの認証制度の課題として以下の3点を挙げ、それぞれに対して取り組んでいます。

    • 認証の継続性

      認証は「ある時点 (point-in-time)」あるいは「ある期間 (period-of-time)」を対象とするアプローチです。これは、変化の激しいクラウド環境においては不十分であることが指摘されています。STAR Level1/Level2 Continuous Self-assessmentでは、頻度を上げた形での認証を行うことで、より現実に近い認証を行っています。これにより、クラウドサービス利用者に対して、セキュリティ管理策の実施状況に関する詳細な最新情報を提供できるようになります。また、STAR Level3が提供されるようになると、よりリアルタイムに近い認証が実現できることになります。

    • 認証の透明性

      第三者認証(STAR認証ではLevel2)では、クラウドサービスの可視化を高いレベルで確保することが難しいです。STAR認証の各レベルは、それぞれ独立して運用するのではなく、組み合わせることでより高いレベルの認証を実現できます。たとえば、Level1とLevel2を組み合わせることで、高い保証(第三者認証)と高い透明性(セルフアセスメント)の両方を実現できます。以下の図は、STAR認証の各レベルの関係を表現したものです。

      図3 保証と透明性

    • 相互認証スキーム

      STAR認証のベースになるCCMは、数多くの国単位/分野単位の基準/規格へのマッピングを提供しています。CCMでは、各規格とのマッピングとリバースマッピングを提供し、それぞれの規格との差異(ギャップ)を分析し、その情報を公開しています。理想としては、1つの認証を取得することで、その他の認証に関してはギャップ分だけやればよいことになり、1つの認証の取得から別の認証の取得までの労力を最小化することができます。あくまで最小化のレベルであり、これで相互認証できるというわけではないことは注意が必要ですが、様々な組織(EU-SECやFedRAMPなど)とのフレームワークの検討が進んでいますので、その進捗に期待したいと思います。

  2. STAR認証に対するCSAジャパンの取り組み

    CSAジャパンでは、以下の取り組みを行っています。

    • STAR認証に関する情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=429

    • CCM/CAIQの日本語化および情報発信

      以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=2048#ccm

    • STAR Level1(セルフアセスメント)の日本語での公開

      CAIQの評価レポートを日本語で作成し、それを公開する手順について以下のウエブサイトを参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=1005

    • 日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの公開

      CSAジャパンでは、STAR Level1 セルフアセスメントの登録において、日本語CAIQ評価レポートを登録されたプロバイダおよびそのクラウドサービスに関する情報を公開しています。CSA本部のSTAR Registryでは、CAIQ評価レポートとして日本語で提供されているかどうかを判断するのが難しいです。そこで、CSAジャパンでは、日本語CAIQ評価レポートを登録されたプロバイダ・クラウドサービスの情報を公開することで、日本の利用者が利用できるようにしています。
      公開ウエブサイトは以下になりますので参照してください。
      https://www.cloudsecurityalliance.jp/site/?page_id=19811

以上