2018年10月、米国食品医薬品局(FDA)は、医療機器製造業者向けのセキュリティ勧告の草案の更新版を発表しました。この勧告は、セーフティと並んで、セキュリティが開発プロセスにおけるデザインインプットとなるべきであると製造業者に助言しています。セキュリティとセーフティは似ているため、FDAのガイダンスでは、安全リスク管理と同様に、サイバーセキュリティのためのリスク管理アプローチを推奨しています。
本ガイダンスには、透明性と情報共有への動きを示す注目すべき追加事項が含まれています。医療機器に関連するリスクは、製造者、医療提供組織、患者の間で共有された責任から生じているため、製造業者が情報を共有し、すべての関係者がそれぞれの責任領域でリスクを軽減できるようにすることが重要です。例えば、製造業者が製品の部品表を伝え、セキュリティに特化したラベル付けをすることは、医療提供組織のリスク管理を支援するための前向きな一歩です。
FDAのガイダンスで提示されている新しい概念の1つは、医療機器に対し 2 層(ティア)のシステムを確立することです。ティア1 機器はリスクが高く、ティア2 機器は比較的リスクが低いことを表します。ティア1 と 2 の違いですが、ティア2 では、関連するセキュリティ管理策はリスク分析を通じて正当化できることを示し、ティア1 では、文書に記載されているすべての管理策を必要としていることを暗示しているように思われます。しかし、実際にはすべての管理策を識別してリスク評価すべきです。
安全かつ効果的な運用を確保するため、医療機器のセキュリティ管理策には制限があります。ティア1 と ティア2 の正当性や根拠は等しく適用されるべきです。安全リスクと同様に、自動ロックアウトやパスワード認証などのセキュリティ 管理策がもたらすリスクを理解する必要があるからです。
しかし、リスクを適切に評価するための重要な概念がFDAのガイダンスには欠けています。その概念とは、医療機器システムのリスクを評価する際に、適切な分野の専門知識を確実に活用するための経営陣の責任です。AAMI TIR 57では、ISO 14971から派生したこの概念について論じています。
ISO 14971規格は、医療機器の安全リスク管理に焦点を当てています。この規格では、経営陣が安全リスク管理に適切な専門知識を確実に活用することを要求しています。この専門知識がなければ、安全リスクを正確に理解することはできません。セキュリティに関する専門知識と、それをサポートする経営陣の責任は、AAMI TIR 57に反映されています。この専門知識がなければ、組織はセキュリティリスクを適切に特定することができません。これは直感的なことのように思われますが、企業は、専門知識を構築、調達することの意味を理解する必要があります。
組織がしばしば苦労する一般的なシナリオとして、経営陣がセキュリティの専門知識のために必要な投資を認識していないことが挙げられます。セキュリティは他の領域と同様に、真の専門知識の構築には時間がかかり、開発のすべての領域で異なるスキルセットを必要とします。多くの製造業者は、ソフトウェアアーキテクチャ / ソフトウェアエンジニアリング / テストエンジニアリング分野における複数の職種を有しています。セキュリティはこれらの分野に存在しなければならず、セキュリティテストやペネトレーションテストに熟練している人は、アーキテクチャやコーディングのスキルを持ち合わせていないかもしれません。
例えば、既存の外部装着機器ではなく埋め込み型機器という全く新しいドメインの機器を設計しているとしましょう。そのためには、開発プロセスに多くの新しいデザインインプットが必要となります。例えば、潜在的な安全性リスクを特定するためには、生体適合性の専門家が必要です。セキュリティも同様です。システム・セキュリティアーキテクチャ、セキュア・ソフトウェアエンジニアリング、セキュリティテストの専門家は、開発プロセス全体を通してインプットを提供する必要があります。
また、FDAは、医療機器のセキュリティに関する申請の審査を容易にする手段として、UL 2900-1とUL 2900-2-1を認めています。UL 2900シリーズの文書、FDAの勧告、AAMI TIR 57これらすべてでリスクベースのアプローチを推奨しています。リスクベースのアプローチに違いはなく、UL 2900を遵守することで、製造業者はFDAが求めるリスクの特定と管理策の裏付けを提供できます。しかし、これらの規格のいずれかを採用するだけで十分なのでしょうか?
これらの規格が混乱を招くことを認めるのは私たちが初めてではありません – この記事のために、3つの規格の内容を勉強しなおさなければなりませんでした。では、製造業者はどのようにして矛盾に対処すればよいのでしょうか?また、これらの標準規格以外のセキュア開発の状況における新たな進歩を知るにはどうすればよいのでしょうか?
ひとつの解決策は、異なる規格や要求事項から共通の要求事項を導き出すことです。製造業者は、製品やプロセスを構築しているチームに、開発プロセスや設計中の製品に対する共通の要件セットを提供することができます。
この活動では、様々な基準を見直し、コンプライアンスのニーズを満たすために組織が解釈した単一のアウトプットを生成します。これは、さまざまな業種のソフトウェアセキュリティの現状を調査しているBSIMM(Building Security In Maturity Model)のアクティビティSR1.3「コンプライアンスの制約を要件に変換する」で証明されているように、多くの組織が実施している活動です。SR1.3は、組織がより安全なソフトウェアを構築するための支援を目的としたBSIMMで測定された116の活動のうちの1つに過ぎないことに注意してください。
BSIMMには、他にも必要な活動が含まれています。主題に関する専門知識と経営陣の責任を例に挙げてみましょう。これらの概念は、BSIMM 活動 T1.5「役割に固有の上級者向けカリキュラムを提供している」及び CP2.5「上級幹部がコンプライアンスやプライバシー義務を確実に認識している」で対処されています。
システムにセキュリティを組み込むための包括的で先を見越したアプローチを開発することは、製造業者にとって、より安全な製品を構築するだけでなく、複数の機関が発行する医療機器規格に準拠していることを証明するための最良の方法です。BSIMMは、ノイズをかき分け、セキュリティと安全性のプロセスに焦点を当て、市場に送り出す製品が可能な限り安全で確実なものであることを保証するための素晴らしいリソースです。
BSIMMレポートは、AppSecの成熟度評価の基準を提供し、セキュリティ専門家同士をつなぐコミュニティの役割を果たし、対策アクションプランの策定を支援する推進モデルです。