2022年8月23日

近年、医療部門を対象としたサイバー攻撃が驚くほど増加しています。
昨年だけでも、 FBI は148件のランサムウェア攻撃が医療機関への侵入に成功したと報告しました。
それは他のどの業界よりも多い結果となっています。

実行できる手順はITインフラストラクチャの保護から、資格情報に対するより優れたセキュリティプラクティスの実装までたくさんありますが、医療専門家が扱う増大するコネクテッドデバイスを保護することほど重要なことはほとんどありません。

さまざまなレベルのネットワーク認証で動作し、サイバー脅威が急速に進化する領域では、膨大な量のコネクテッドデバイスを保護する必要があります。FDA の Suzanne Schwartz とそのチームはそれを知っています

Dr. Schwartz’s interview on Left To Our Own Devices

医療機器製造業者(MDM)は、業界全体のサイバーセキュリティ慣行を強化するよう企業に求めるバイデン政権の呼びかけに耳を傾けています。 FDAに影響を与える2022年12月の包括的法案 に加え、国際医療機器規制当局フォーラム(IMDRF)のソフトウェア部品表(SBOM)の原則と実践がこれを達成するもう1つの方法です。

IMDRF WG / N73草案:2022:医療機器サイバーセキュリティのためのソフトウェア部品表の原則と実践 はまだ草案ですが、生きている SBOM を作成および管理する方法に関して、MDMに新鮮な外観を提供します。

それはMDMと医療施設(HCF)の両方に実装に関する実践的な提案を提供します。 しかし、具体的なSBOMメンテナンス手順を明確に定義する際には依然としてとらえどころのないままであり、企業が内部慣行を見直し、最適なものを選択するよう奨励しています。

この文書で提起された関心事は、ドキュメント自体に関するものではなく、各デバイスバージョンに最も関連するドキュメントに簡単にアクセスできるようにすることに関するものでした。

最近の草案から5つの重要なポイントをまとめました。

#1: なぜSBOMが必要なのですか?

業界関係者として我々は、医療機器を操作するソフトウェアの多くはオープンソースまたはサードパーティベンダーからのものであることを理解しています。 これによりコストが削減され、市場投入までの時間が短縮されますが、潜在的なサイバーセキュリティの脆弱性は公開されたままになります。

IMDRFは各デバイスの潜在的な弱点だけでなく、それらが施設ネットワークにもたらす脅威を理解する上で、SBOMが重要な要素だと見なしています。 これは非常に重要であるため、MDMが既知の脆弱性を共有することを含め、すべてのSBOMが NTIA 要素で構成されている必要があると彼らは信じています。

「上流のコンポーネント X がソフトウェア Y に含まれているという関係を特徴付ける」ことは、SBOMの重要な要素の1つです。MDMは脆弱性の長いリストを作成するだけでは不十分です。彼らは現在および将来のさまざまな環境でどのように影響を受ける可能性があるかを検討し、報告する必要があります。

最終的には、攻撃や脆弱性が発見された場合にソフトウェアコンポーネントの所有権を明確に定義する単一の共有リソースを作成するため、SBOMが必要です。

#2: すべての医療機器にはSBOMが必要です

SBOMの生成は、開発者にすべてのソースを要求し、それらをリストに書き込んで公開する、それくらい簡単なはずです。

実際には、SBOMの作成はそれほど簡単ではありません。

ますますソフトウェア定義のデバイスは、コードへの依存度を高めています。 さまざまな理由から、企業はデバイスコード開発の全部または一部を雇うことを選択できます。 加えて、サードパーティのソフトウェア、オープンソースライブラリ、およびソフトウェアのマルチソースパケットに依存しているため、元の作成者のセキュリティ知識を追跡することは不可能です。
つまり、既存デバイスのSBOM開発では、答えよりも多くの疑問が生じる可能性があります。

デバイスの基礎部分の多くは外部ソースに依存しているため、企業はいつSBOMの作成を開始する必要があるでしょうか?

答えはシンプルです。今すぐ始めることです。

デバイスがまだソフトウェア開発ライフサイクル(SDLC)を実施しているか、すでに市場に出ているかに関係なく、企業は所有しているものは何でも収集を開始する必要があります。草案には以下のようにあります。

「標準とツールは進化し成熟し続けています。MDMはこれらが「確定」されるのを待つべきではありません。
むしろ、基本的な/基礎となるSBOMの概念を適用した最初のSBOMドキュメントを生成する必要があります。」

#3: SBOMのサイバーセキュリティリスク削減のユースケース

この草案の最も興味深い部分の1つは、全体を通して維持されている二つの視点です。絶え間なく進化する状況を認識して、製造業者と医療提供者(HCP)の両方の視点を考慮することをIMDRFは要求しています。

これはリスク管理について議論するときに見られます。製造業者は以下を実施する責任があります：

ハザード分析－ 既存のSBOMを確認して、使用されているソフトウェアコンポーネント内の脆弱性を特定します。

リスク評価－ 脆弱性、潜在的な悪用可能性、および影響を特定します。時にはこれは避けられないことであり、HCPに認識させることが重要です。

リスク管理－ 新たに発見された脆弱性で既存のSBOMを継続的に更新します。

評価と監視－ 更新後の新しいソフトウェアでSBOMを更新します。

ライフサイクルリスク管理－ 購入時、TPLC全体、および製品のサービス終了(EOS)まで、製品セキュリティドキュメントに含める必要があるHCPへの情報の引き渡しについて説明したものです。さらに、これはMDMが脆弱性の特定と修復手順書の適時性と精度を向上させるのに役立ちます。

一方、HCPにも責任があります。これは、調達前プロセスの一環としてSBOMを取得することに重点を置いており、ネットワークに適用する必要のあるリスクと軽減策を理解できるようにすることです。
「これによりHCPは、TPLCを進める際のデバイスの利点とリスク、およびデバイスのライフサイクル全体でリスク管理対策と緩和戦略をより効果的に適用する方法をよりよく理解できるようになります。」

#4: SBOMの最小要件

最近のデバイスに対する最小要件でもMDMとHCP間の完全な透明性の機会としてSBOMの使用を推進しています。
契約では、レガシーデバイス( セクション#5 を参照)に真の最小要件を提示しており、将来のデバイスに向けた内部出発点としてできる限り多くのものを維持することを提案しています。

レガシーではないすべてのデバイスについては、既存のNTIA要件が引き続きここに適用されます。
このIMDRF草案は変更管理についても言及しており、「...サードパーティ製コンポーネントの変更管理は、ほとんどの製造業者にとって新しい分野です。」コンプライアンスを維持するには、SBOMを見直し、製品またはバージョンの変更ごとに最新の状態に保つ必要があります。これには、サードパーティ製コンポーネントの脆弱性やパッチ、新機能などの検出が含まれます。
またチームは、サポート終了の決定や新しいバージョンのリリースといった計画されたイベントに関係なく、このドキュメントを維持する必要があります。

SBOM基準の現在の流動性を認め、IMDRF草案は文書を最新の状態に保つための手順を明示的に示しておらず、それが必要であることだけを示しています。
これにより、企業や個々のチームはその規模に関係なく、デバイスに何らかのソフトウェアアップデートがあるたびに手順を設計する必要があります。

#5: レガシーデバイスの将来の保証とポストプロダクションセキュリティ

レガシーデバイスはコンポーネントが使用中の可能性がある一方、もうサポートを受けられないため、SBOM開発に独自の課題をもたらします。 これはその経過した年数の結果かもしれませんし、ソフトウェア開発者はもはやビジネスを行っていないかもしれません、あるいはオリジナルの作成ツールを見つけることはエンジニアに無駄な追求をさせるかもしれません。

草案はこれを認め、でき得る最善の範囲でデバイスを保護する責任をMDMに課しています。草案には以下のようにあります。
「... 範囲と深さを縮小する可能性はありますが、オペレーティングシステム、COTSソフトウェア、OSSなどの主要なソフトウェアコンポーネントを可能な限り取り込んで、SBOMを構築することが依然として望ましいです。」

これは製品ライフサイクル全体(TPLC)を通じて潜在的な相互運用性の問題を特定するのに役立つだけでなく、将来のデバイスバージョンの基盤も作成します。

IMDRF WG/N73草案:2022:医療機器サイバーセキュリティのためのソフトウェア部品表の原則と実践を実装する

サイバーセキュリティのベストプラクティスとSBOM生成の開発がプリプロダクションで標準になりつつあり、それがWG/N73がすでに現場で動作しているデバイスに取り組む理由かもしれません。

この草案では、最新の規制に準拠している場合と準拠していない場合があるコネクテッドデバイスについて論じており、それはハッカーがHCPのネットワークに侵入するための主要なターゲットになっています。
より広範なネットワークを保護するために、各デバイスには基本的な情報とセキュリティの洞察を提供するSBOMが必要です。
SBOMが導入されデバイスが理解されると、チームはメンテナンスと更新を含む完全な製品ライフサイクルに移行できます。

このプロセスを整然と保つことは困難な場合があります。
見落としがないように、SBOMの作成とメンテナンスは、開発プロセスの早い段階で標準化および自動化する必要があります。
これは、新しいソフトウェアが導入されたときにSBOMを自動的に追加することで、開発者にメリットをもたらします。
そうして初めて、HCPはSBOMが最新であり、脅威が軽減されていることを確認できます。

デバイスセキュリティの専門家がデバイスのセキュリティとコンプライアンスを確保するのにCybellumの製品セキュリティプラットフォームがどのように役立つかを知りたいですか? デモを予約してください！