医療情報セキュリティ
03.Jan.2025
医療機器におけるサイバーセキュリティの新しい規格を導入するにはどうすればいいのか?Onward SecurityがSDLとIEC 81001-5-1の適用について説明します
2023年9月に米国FDAにより「医療機器におけるサイバーセキュリティ:品質システムの考慮事項および市販前申請の内容(Cybersecurity in Medical Devices:Quality System Considerations and Content of Premarket Submissions)」の最終版が公開されました。これにより、IEC 62304規格を導入した医療機器メーカには、FDAのサイバーセキュリティ要件を満たすための、より明確な方向性が示されたことを意味します。しかし、それを実行・実現するためにはまだまだ大きな課題が残っています。
Onward Securityの最高技術責任者、劉作仁氏は「この問題を解決する鍵は、間違いなくIEC 81001-5-1の規格にある」と語っていました。彼は、IEC 81001-5-1はIEC 62304に基づいており、製造メーカが製品のサイバーセキュリティ(Product cybersecurity)を実現するためのガイドとして、IEC 62443-4-1のアプリケーションセキュリティソフトウェア開発ライフサイクル(SDL)の要件が加わったものだと指摘していました。
Onward Securityの最高技術責任者、劉作仁氏は「この問題を解決する鍵は、間違いなくIEC 81001-5-1の規格にある」と語っていました。彼は、IEC 81001-5-1はIEC 62304に基づいており、製造メーカが製品のサイバーセキュリティ(Product cybersecurity)を実現するためのガイドとして、IEC 62443-4-1のアプリケーションセキュリティソフトウェア開発ライフサイクル(SDL)の要件が加わったものだと指摘していました。
医療機器は人命に関わり軽視することは許されない、SDLの徹底を継続する必要がある
劉作仁氏は、台湾には医療機器の製造に携わるメーカが多数存在し、そのほとんどは製品を各国に輸出しており、当国の規制に従わなければならないと述べていた。ますます厳しくなるコンプライアンスプレッシャーに直面し、多くの企業は、規定のニーズを守るためにはどのような対策を講じる必要があるか知りたがっています。
市場調査会社Statistaによれば、世界の医療機器市場において、米国はGDP占比で最大のシェアを占めており、法令遵守の面において業界関係者にとっては重要なターゲットとなっていることは間違いありません。したがって、2023年にFDAが提案した新しいサイバーセキュリティ規制は、当然ながら最優先事項となります。
公平に言えば、医療機器メーカであろうとその他の製品メーカであろうと、利益を追求し、コスト支出に非常に敏感になるのは避けられません。しかし、強制的な規制要件が制定されると、製造メーカは基本的な製品検証の要求を満たすために必然的にある程度の費用を支払わなければならなくなります。特に医療機器のサイバーセキュリティの分野において、EU、米国、台湾、日本などから、既に対応すべき要件と関連する国際規格が統合され提示されており、業者にははっきりしない余地もないのは明らかです。今後、医療機器の開発プロセスにおいて、確実により多くの検査メカニズムと管理措置を組み込む必要が出てきます。
ここで触れておくべきのは、以前であれば、多くの製造メーカは、製品の安全性試験に合格すれば、それ即ちクリアしたとことになり、法令遵守のプレッシャーから解放されると考えられていました。しかし、医療機器は命に深く関わるものなので、安全性(Safety)とセキュリティ(Security)の両方を真剣に受け止め、どちらにも配慮する必要があります。FDAが定義するSPDM(安全な製品開発フレームワーク(Secure Product Development Framework))とTPLC(製品全体のライフサイクル(Total Product Life Cycle))はどちらも、製品開発ライフサイクルを製品安全管理の範囲に含めることを提案しており、それは企業が製品安全に対して行うことはテストの実行だけでなく、その後の製品開発プロセスにおいても要件分析、システム設計、安全性テストなどの関連プロセスの実行も含まれることになります。これらすべての内容を見ると、基本的にはIEC 62443の要件分析や脅威モデリング、システム設計、実装、テストなどの概念に近いことがわかります。
市場調査会社Statistaによれば、世界の医療機器市場において、米国はGDP占比で最大のシェアを占めており、法令遵守の面において業界関係者にとっては重要なターゲットとなっていることは間違いありません。したがって、2023年にFDAが提案した新しいサイバーセキュリティ規制は、当然ながら最優先事項となります。
公平に言えば、医療機器メーカであろうとその他の製品メーカであろうと、利益を追求し、コスト支出に非常に敏感になるのは避けられません。しかし、強制的な規制要件が制定されると、製造メーカは基本的な製品検証の要求を満たすために必然的にある程度の費用を支払わなければならなくなります。特に医療機器のサイバーセキュリティの分野において、EU、米国、台湾、日本などから、既に対応すべき要件と関連する国際規格が統合され提示されており、業者にははっきりしない余地もないのは明らかです。今後、医療機器の開発プロセスにおいて、確実により多くの検査メカニズムと管理措置を組み込む必要が出てきます。
ここで触れておくべきのは、以前であれば、多くの製造メーカは、製品の安全性試験に合格すれば、それ即ちクリアしたとことになり、法令遵守のプレッシャーから解放されると考えられていました。しかし、医療機器は命に深く関わるものなので、安全性(Safety)とセキュリティ(Security)の両方を真剣に受け止め、どちらにも配慮する必要があります。FDAが定義するSPDM(安全な製品開発フレームワーク(Secure Product Development Framework))とTPLC(製品全体のライフサイクル(Total Product Life Cycle))はどちらも、製品開発ライフサイクルを製品安全管理の範囲に含めることを提案しており、それは企業が製品安全に対して行うことはテストの実行だけでなく、その後の製品開発プロセスにおいても要件分析、システム設計、安全性テストなどの関連プロセスの実行も含まれることになります。これらすべての内容を見ると、基本的にはIEC 62443の要件分析や脅威モデリング、システム設計、実装、テストなどの概念に近いことがわかります。
開発ルールにソースコードスキャンを加えることにより、プログラミングエラーによる脆弱性の発生を防止
劉作仁氏は、企業がSDLを実践するためには、前述のFDA SPDFフレームワークの規定に従うほかに、他のフレームワークを選択することも可能であると述べていた。例えば、IEC 81001-5-1は、製品の安全性試験への要件を提案するだけでなく、潜在的な問題を特定するために、全体のライフサイクルに基づいて分析を実行する必要があることを強調したよく見られる一般的な規格です。さらに、設計、実装、テストのプロセスを通じて製品安全を実践することで、潜在的なサイバーセキュリティのリスクが解決されます。
欧州医療機器調整グループ(MDCG)より、医療機器メーカにサイバーセキュリティ要件を満たすことを要求するガイダンスが発行されました。しかし、製造メーカや認証機関にとっては、要件を満たす方法を理解させるためにはこのガイダンスだけでは不十分とされています。そのため、EU製造メーカと認証機関により明確なガイドラインを提供するため、IEC 81001-5-1を組み込んだ整合規格を発表しました。
実際、IEC 81001-5-1と非常によく似た規格が他に2つあります。まず1つ目は、IEC 62443-4-1規格です。IEC 81001-5-1と同じく、製造メーカは製品の安全性を確保するために開発プロセスにセキュリティ活動を適用する必要があると強調しており、対応のための明確な規格を提供しています。違いは、IEC 81001-5-1は医療機器または医療用ソフトウェアに適用されるのに対し、IEC 62443-4-1は産業用制御システムと自動化の分野に適用されることです。製造業者がIEC 62443の規格を採用している場合、サイバーセキュリティ開発プロセスの導入を加速し、IEC 81001-5-1の規格を満たすことができます。
2つ目は、IEC 62304規格です。これも62443-4-1の精神を引き継いでおり、ソフトウェア検証の目標を達成するためにソフトウェア開発プロセスにて特定の安全対策を実施することを要求しています。ソフトウェア検証とサイバーセキュリティは方向性が必ずしも同じではありませんが、既にIEC 62304を導入したメーカは、元の基礎をベースにサイバーセキュリティのリスク評価と制御のための新しいメカニズムを確立し、段階的にIEC 81001-5-1に準拠した完全なアーキテクチャを構築することができます。
欧州医療機器調整グループ(MDCG)より、医療機器メーカにサイバーセキュリティ要件を満たすことを要求するガイダンスが発行されました。しかし、製造メーカや認証機関にとっては、要件を満たす方法を理解させるためにはこのガイダンスだけでは不十分とされています。そのため、EU製造メーカと認証機関により明確なガイドラインを提供するため、IEC 81001-5-1を組み込んだ整合規格を発表しました。
実際、IEC 81001-5-1と非常によく似た規格が他に2つあります。まず1つ目は、IEC 62443-4-1規格です。IEC 81001-5-1と同じく、製造メーカは製品の安全性を確保するために開発プロセスにセキュリティ活動を適用する必要があると強調しており、対応のための明確な規格を提供しています。違いは、IEC 81001-5-1は医療機器または医療用ソフトウェアに適用されるのに対し、IEC 62443-4-1は産業用制御システムと自動化の分野に適用されることです。製造業者がIEC 62443の規格を採用している場合、サイバーセキュリティ開発プロセスの導入を加速し、IEC 81001-5-1の規格を満たすことができます。
2つ目は、IEC 62304規格です。これも62443-4-1の精神を引き継いでおり、ソフトウェア検証の目標を達成するためにソフトウェア開発プロセスにて特定の安全対策を実施することを要求しています。ソフトウェア検証とサイバーセキュリティは方向性が必ずしも同じではありませんが、既にIEC 62304を導入したメーカは、元の基礎をベースにサイバーセキュリティのリスク評価と制御のための新しいメカニズムを確立し、段階的にIEC 81001-5-1に準拠した完全なアーキテクチャを構築することができます。
脅威モデリングから実装まで:効果的なサイバーセキュリティ管理の土台を構築
IEC 81001-5-1の導入プロセスとして、製造メーカにはまずは社内および社外のコンサルタントに脅威モデル分析の実施をサポートしてもらい、現在使用しているサイバーセキュリティツールライブラリが有効かどうかを判断することを推奨しています。続いて、次のステップで品質システム構築段階に入り、まずは、血糖値や血圧の測定など、製品に求められる機能の特性を確認する必要があります。これらの機能要件に加えて、製造メーカはサイバーセキュリティの機能要件も確認する必要があります。それらに基づいて、脅威モデリングによって特定された問題を、識別および認証制御(Identification and Authentication Control, IAC)、暗号化、データ保存など、FDAが確立した基本的なセキュリティ管理項目と組み合わせて、サイバーセキュリティ機能の実装の基礎とすることができます。
IEC 81001-5-1のコンプライアンスプロセスをどのように定義すればいいのか?どのような管理や制御対策が必要なのか?劉作仁氏は、起こりうる問題をできるだけ早く発見するためには脅威モデリングに大きく依存する必要があると改めて強調した。彼は、STRIDEモデルを通じて、製品開発のデータフローに対応する脅威を手動または自動で生成し、それらの脅威を完全に排除するための効果的な制御対策を策定することを提案しました。
この過程で、企業もベストプラクティス(Best Practices)を定義し、それをRDチームに参考資料として提供し、実装内容の正確性を確保する必要があります。まずは、SEI CERTコーディング標準(Coding Standards)とOWASPセキュアコーディングプラクティス(Secure Coding Practices)を参照し、対応するコーディングガイドライン(Coding Guideline)を作成して、エンジニアが誤ったコードの記述方法を特定して回避できるようにすることで、潜在的なセキュリティ脆弱性のリスクを軽減できるようにすることをお勧めします。次に、ソースコードスキャンメカニズムを組み合わせて、人の手でプログラミングされたことで発生する可能性のある人為的なセキュリティ上の脆弱性を最小限に抑えます。
IEC 81001-5-1のコンプライアンスプロセスをどのように定義すればいいのか?どのような管理や制御対策が必要なのか?劉作仁氏は、起こりうる問題をできるだけ早く発見するためには脅威モデリングに大きく依存する必要があると改めて強調した。彼は、STRIDEモデルを通じて、製品開発のデータフローに対応する脅威を手動または自動で生成し、それらの脅威を完全に排除するための効果的な制御対策を策定することを提案しました。
この過程で、企業もベストプラクティス(Best Practices)を定義し、それをRDチームに参考資料として提供し、実装内容の正確性を確保する必要があります。まずは、SEI CERTコーディング標準(Coding Standards)とOWASPセキュアコーディングプラクティス(Secure Coding Practices)を参照し、対応するコーディングガイドライン(Coding Guideline)を作成して、エンジニアが誤ったコードの記述方法を特定して回避できるようにすることで、潜在的なセキュリティ脆弱性のリスクを軽減できるようにすることをお勧めします。次に、ソースコードスキャンメカニズムを組み合わせて、人の手でプログラミングされたことで発生する可能性のある人為的なセキュリティ上の脆弱性を最小限に抑えます。
