医療機器のセキュリティリスク評価の実施

FDA は、医療機器のサイバーセキュリティに関する最新のガイダンス「品質システムの考慮事項と市販前提出の内容」を 2025 年 6 月末にリリースしました。このガイダンスの中で FDA は、サイバーセキュリティのリスクと脆弱性が脅威モデルで対処されることへの期待を強調しています。初期設計から耐用年数終了まで製品をサポートするためのサイバーセキュリティ手順を実装する必要があります。適切なサイバーセキュリティ保護は、開発中の設計入力で対処する必要があり、開発完了後に「追加」する必要はありません。

あなたがコネクテッド医療機器を担当している、またはこれから担当する開発者またはメーカーの場合、サイバーセキュリティ プロセスに今すぐ力を注ぐ必要があります。

ANSI/AAMI SW96:2023 や IEC 81001-5-1:2021 など、米国および EU で広く認知されている複数の規格があり、医療機器ソフトウェアのサイバーセキュリティ リスク評価に関してどのような活動と成果物に対処する必要があるかを詳しく規定しています。この短い記事では、サイバーセキュリティ脅威モデルの中核となる分析の実行方法に焦点を当てています。この記事の目的は、医療機器または医療機器ソフトウェアの寿命全体に影響を与えるセキュリティ リスク分析の実施に関する洞察を提供することです。

デバイスのサイバーセキュリティ計画

市場投入前の観点から見ると、セキュリティ分析の重要な要素は次のとおりです。

_{図 1 – リスク分析におけるサイバーセキュリティのステップ}

医療機器企業は、サイバーセキュリティの計画に加えて、品質システムに選択したフレームワークを導入する必要があります。一部の企業は、コンプライアンスの水準に追いつくために、1 つのツールですべてを実行できるソフトウェア オプションに投資してコンプライアンスに対処するという間違いを犯していますが、これでは組織内のサイバーセキュリティに対処する真のニーズを見逃してしまう可能性があります。全体的なソリューションは、製品ライフサイクル全体 (TPLC) 全体にわたるアクティビティとタスクに対処する安全な製品開発フレームワークのアプリケーションです。プロセスと SOP を開発および更新するためにリソースを委託する必要がありますが、堅実なプロセスの核心は、効果的かつ効率的なリスク評価方法を確立することです。リスク評価方法は、図 1 の分析セクションではセキュリティ リスク評価として表されています。

セキュリティ分析表で資産に焦点を当てる

セキュリティ リスク評価は、潜在的なセキュリティ リスク制御を特定し、脆弱性を特定するために使用されます。セキュリティ リスク管理を特定して維持するリスク評価テーブルと、現在の脆弱性を追跡する進行中の脆弱性テーブルの 2 つのテーブルを確立する必要があります。 2 つの分析テーブルは、テーブルの長期管理を可能にするフィルタリング機能と並べ替え機能を備えているため、単純なスプレッドシート上の別々のタブに配置できます。リスク評価表の内容は、セキュリティ管理を扱う表 1 に反映されています。

_{表 1 – セキュリティ リスク評価の分析表}

セキュリティ リスク評価の焦点は、セキュリティ アーキテクチャで定義された資産と、脅威がどのように脆弱性を悪用して資産を侵害するかに焦点を当てる必要があります。

資産は、ユーザー、患者、ユーザー組織、およびビジネスにとって価値のある、セキュリティに関連する要素です。資産には通常、次のものが含まれます。

• 製品で処理および保存されるデータ (ログ、顧客または運用データ、構成データなど)
• 個人的な性質のデータ (例: 保護された健康情報/PHI)
• 資格情報 (パスワード、資格情報、キーなど)
• 製品のソフトウェア/ファームウェア
• サードパーティのサービス (クラウド サービス、オープン ソース ライブラリ、API など)。

分析には、各資産に対する合理的に現実的な脅威を含める必要があります。 STRIDE モデルを適用すると、各分析行で潜在的な脅威を特定できます。標準の STRIDE モデルと必要なセキュリティ プロパティを以下の表 2 に示します。

_{表 2 – ストライドの定義}

脆弱性の特定

前述したように、セキュリティ リスク評価に加えて、別の進行中の脆弱性テーブルを維持する必要があります。この表には、デバイスで特定された既知の脆弱性が含まれています。脆弱性とは、潜在的な脅威源によって悪用される可能性のある欠陥または弱点です。脆弱性は次の方法で特定できます。

• セキュリティ リスク評価での脆弱性の特定
• サイバーセキュリティ侵入分析と製品のテスト
• SAST (静的アプリケーション セキュリティ テスト) ツールを使用した社内開発ソフトウェアの静的分析スキャンによる
• DAST (Dynamic Application Security Testing) ツールを使用した動的分析スキャンによる
• Common Vulnerabilities and Exposure List、National Vulnerability Database (NVD)、National Health ISAC、SOUP/COTS のリリース ノートなどの既存のカタログをレビューします。
• OTS またはオープンソース コンポーネントの SCA (ソフトウェア構成分析) ツールを使用した脆弱性スキャンによって特定されます。

既知の脆弱性の評価は、製品のリリース前に必要であり、製品が廃止されるまで維持されます。脆弱性が特定され、対処されると、進行中の脆弱性分析テーブルから削除される場合があります。脆弱性に対するアクションは、脆弱性の重大度の決定と CVSS スコア。 CVSS スコアリング モデルは、特定された脆弱性ごとにマトリックス内の 6 つの基本項目を特定します。攻撃ベクトル (AV)、攻撃の複雑さ (AC)、必要な権限 (PR)、ユーザー インタラクション (UI)、スコープ (S)、および影響 (CIA) で、機密性、完全性、可用性の損失を測定します。

脅威の影響を判断する

安全性リスク分析では、リスクが危害の重大度と確率の組み合わせであることがわかっています (リスク = P x S)。ただし、セキュリティ リスク分析の場合、FDA は、潜在的な脆弱性の悪用可能性と、攻撃が成功する確率の使用を考慮することを推奨しています。悪用可能性は、システムが侵害に対してどの程度脆弱であるかに基づいて判断する必要があります。セキュリティ管理が優れているほど、リスクは低くなります。資産に対する脅威と脆弱性の受容性評価は、表 3 のような表マトリックスに基づいて、危害の重大度と悪用可能性によって決定される必要があります。

_{表 3 – セキュリティの悪用可能性と重大度の決定表}

リスクが高い場合は、悪用可能性と全体的なリスクを軽減するために、セキュリティ リスク評価表にリスク管理を文書化する必要があります。リスク制御は設計の要件を推進する必要があり、その後の設計検証中に有効であることが検証されます。

結論

リスクと脆弱性のセキュリティ分析は 2 つのテーブルで維持する必要があります。1 つはセキュリティ リスクを特定して維持するために必要であり、もう 1 つはリリース後に定期的な更新が必要な継続的な脆弱性のリストであるからです。これら 2 つの分析テーブルは定期的に更新され、継続的な脆弱性リストにより、製品メンテナンス中にパッチと顧客への通知が推進されます。

あなたの会社が立ち始めたばかりであっても、堅牢で効率的なサイバーセキュリティフレームワークを達成するというサイバーセキュリティ成熟度の高い段階にある場合でも、優先事項としてフォーマットと分析のコアプラクティスに焦点を当てることは、ツールに関するより適切な意思決定と、プロセスの効率と能力の向上につながります。

写真：トレイトフ、ゲッティイメージズ

ボブ・バレット、システムエンジニアリング担当副社長 フルスペクトルは、経験豊富なエンジニアリング リーダーであり、結果を重視するチーム ビルダーです。彼は、医療機器システム エンジニアリング、システムとソフトウェアの検証、安全性リスク分析、品質管理、プロジェクト管理において 30 年以上培ってきた技術的強みを持っています。ボブは、バクスター社のドラッグデリバリー部門で 15 年間勤務し、システム エンジニアリング グループを率いていました。ボブはフル スペクトラムでプレーヤー コーチの役割を担っており、システム エンジニアリング チームを率いて、クライアントに直接深い洞察を提供しています。ボブは、リズム主導のプロジェクト管理手法を強く信じています。実践的な役割を果たしたり、部門を超えたチームをリードしたりできる彼の能力により、クライアントの医療開発プログラムがコンセプトから市場リリースまで加速されます。

この投稿は、 メッドシティのインフルエンサー プログラム。誰でも、MedCity インフルエンサーを通じて MedCity News でヘルスケアにおけるビジネスとイノベーションに関する視点を公開できます。 方法を確認するにはここをクリックしてください。