ソフトウェア・インテグリティ

 

安全と同様にセキュリティを扱う:FDAによる UL 2900-2-1:2018 の認定は、開発者にとってどのような意味があるのか

UL 2900-2-1 は医療機器のセキュア設計とセキュリティ・テスト求めています。では、FDAによるUL規格の採用はみなさんの開発チームにとってどのような意味を持つのでしょうか?

元の記事はDan Lyon およびGarrett Sippleによって執筆されました。

また、この記事は MedTech Engineに掲載されています。

ネットワーク接続型の医療機器におけるサイバーセキュリティ(数十年もの間、不十分であることが知れ渡っている)は、グローバルにおける規制組織のセキュリティに対する姿勢の改善によってようやく改善の兆しが見えてきました。2018年6月6日、FDAは 医療機器の市販前申請手続きの変更の発表は控えめでした(数万ページもの連邦官報のわずか11ページだけでした)が、FDAがUL 2900-2-1を「コンセンサス・スタンダード」として採用したことによる影響は、製造業者や患者にとって非常に大きなものです。

UL 2900-2-1 は、何年もかけ、Synopsysを含む複数の利害関係者からの意見を集めて作り上げられた一連の文書群の一部で、米国国家規格協会(ANSI)によって承認されたものです。この規格は「構造化されたペネトレーション・テスト、製品ソースコードのレビュー、ソフトウェア部品表の分析」およびセキュリティ管理策、ライフサイクルにおけるセキュリティプロセスや使用目的についての文書が求められます。

この新しい規格では、設計またはテストをどのように行う必要があるかを正確に説明していませんが、明確なことは、適切に実行しないと製品を売れなくなる可能性があるということです。 また、FDAは米国市場だけではなく、他の地域、EU、中国および日本などで、市販前申請(日本では薬事法に基づく製造販売承認申請)においてセキュリティも含めて検討されるということです。

脅威と将来への備え

医療機器製造業者とよく話し合う1つの問題は、変化する脅威の状況にどのように対応するかです。セキュリティの課題は常にニュースで取り上げられており、定期的に新しい脆弱性が公開されています。規制当局は状況の変化に対応する必要のある立場にあり、製造業者もそのように期待しています。つまり、製造業者は絶えることのない脆弱性の進化に対応できるよう、開発プロセスを将来に渡って担保する必要があります。しかし、年単位での機器開発に対して、セキュリティの変化のスピードは早すぎます。果たして適切な対応ができるのでしょうか?

答えはUL 2900のように承認された規格と製造業者の開発プロセスを揃えることです。 また、セキュリティ専門家の専門知識をプロジェクトチームに提供することです。

開発プロセスを将来に渡って担保するために、セキュリティ・プログラムの作成と成熟のための専門のセキュリティ担当チームが必要です。全体的な取り組みとが必要なのは、UL 2900に基づくさまざまなセキュリティ活動は、互いに補完し合うことで、システム内のさまざまなセキュリティ上の欠陥を見つけられるからです。

UL 2900は、ライフサイクルのさまざまな局面でセキュリティ・リスクを発見するのを助けてくれる特定の分析やテストの手法を推奨しており、以下を含みます:

  • セキュリティに特化した静的解析(SAST):バッファ・オバーフローのようにソースコード内の問題を検知。
  • ソフトウェア・コンポジション解析(SCA):サードパーティやオープンソース・ソフトウェアの仕様における問題の検知。
  • ファジング・テスト:予期せぬ入力を処理する際の問題の検知。
  • 動的アプリケーション・セキュリティ・テスト(DAST):アプリケーションの実行に伴う問題、例えば認証に関連する問題の検知。
  • インタラクティブ・アプリケーション・セキュリティ・テスト(IAST):Webアプリケーションの脆弱性を確認して検知。

単にテスト技術を組み合わせるだけでは、医療機器の提出または寿命におけるセキュリティを確保するには不十分です。セキュリティを適切に検討するには、設計段階で特定のスキルや専門知識が必要です。たとえば、暗号化などの領域は、効果的に適用するためによく理解していなければなりません。

セキュリティの複雑さ

製造業者がシステムに安全をどのように作り込むのかを見ることで、セキュリティを理解するのは時に有効です。安全のように、セキュリティは複雑なシステムの突出した特性でもあります。したがって、ライフサイクルの全ての局面で、セキュリティにも同様に注力する必要があります。

開発ライフサイクルの最後に一回だけテストしたからといって、その製品が安全で効果的であることを保障することはできません。それは「故障モード」を見つけて対処する作業を行なったとは言えないからです。同様に、単一のセキュリティに特化したペネトレーション・テストを最後に実施したところで、製品が安全であることを保証できるわけではありません。

安全リスクと同様に、セキュリティ・リスクの特定と削減のプロセスをすべての開発活動と局面に組み込むことは、受け入れ可能な結果を得るために必要です。それこそが、市場に出荷するまで何年もかかる安全な製品の開発を、将来にわたって担保するための答えなのです。

いずれかの世界中の開発組織が安全を構築するのと同様にセキュリティを構築するためにこのような考え方を取り入れたとしたら、規制当局の認可を得るために必要な成果物の作成は当たり前のことになります。セキュリティ・リスク管理 を正しく行うということは、業界で認められたツールや手法を駆使してリスクの証拠を見つけ出し、リスクを低減するための適切な管理策を導入するということなのです。

セキュリティに対する全体的な取り組みを確立することは簡単ではありません。それは組織の変化と成熟度を伴わなければならない旅であり、成し遂げるためには、時間、リソース、そして予算を必要とします。十分に機能するセキュリティ・プログラムの構築には数年を要しますが、最も重要なのは構築のプロセスを開始するということなのです。

ネットワーク接続型の医療機器をセキュアにする方法

 

この著者によるその他の情報