SLSA と SBOM はいかに医療分野におけるサイバーセキュリティのレジリエンスに貢献できるか

※この投稿は米国時間 2022 年 6 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

訓練を受けた医師以外の指示で処方薬を服用することは非常に危険です。病院の運営、医薬品製造施設の管理、そして最近では患者の病状を治療するためのテクノロジーを選択する場合にも同様のことが言えるでしょう。

適切な薬を選ぶために、医師は薬の成分や総合的な治療効果、患者の状態などを慎重に考慮する必要があります。医療分野におけるサイバーセキュリティのリーダーも同様に、サイバーセキュリティの脅威から患者の安全を守るために、患者の医療記録の管理、配合薬の製造、患者の治療のために組織が使用するテクノロジーの内容を把握している必要があります。

患者の安全確保、最新の医療で利用されるテクノロジーの可視性とアウェアネスの確立、レジリエンスに優れた医療システムの構築には、処方薬の場合と同じようにテクノロジーを慎重に吟味し、選択することが必要です。

今回と次回のブログでは、レジリエンスの構築に欠かせない 2 つのトピック、ソフトウェア部品表（SBOM）と Google のソフトウェア アーティファクトのためのサプライ チェーン レベル（SLSA）フレームワークに焦点を当て、それらを使ってテクノロジーを安全にする方法を紹介します。ソフトウェアのサプライ チェーン、つまり利用しているソフトウェアの供給元を保護することは、防御側にとって重要なセキュリティ上の優先事項であり、Google は組織のこうした活動を支援するために尽力しています。

利用するテクノロジーを深く掘り下げる

医療システムを保護するためのサイバーセキュリティの優先順位は通常、保護対象保健情報（PHI）のような機密性の高い医療情報の保護にのみ焦点が当てられています。患者の記録のプライバシーを維持することは重要な目標であり、データおよびシステムを保護することがこの目標達成に関して大きな役割を担っています。

医療システムのリーダーやその他の意思決定者は、データ保護を最優先事項（場合によっては唯一の優先事項）とする規制基準を満たすテクノロジーやサービス プロバイダを選択するにあたって、しばしばサイバーセキュリティの専門家をよりどころとします。そのため、あまり詳しく調べることなく、購入したテクノロジーを製造しているベンダーの評判やコンプライアンス プログラムに信頼を置きがちです。主要なヘルスケアとライフ サイエンスのテクノロジーやサービス プロバイダを選ぶ際は、リスクや重要性が高いものとして意思決定を行う必要がありますが、購入したテクノロジーが医療現場に組み込まれる前にセキュリティを「深く」吟味するスキル、リソース、時間を持ち合わせる医療機関はほとんどありません。

検討には、ソフトウェアとハードウェアのあらゆる側面、アーキテクチャとエンジニアリングの品質、構成されるすべての部品の来歴、各コンポーネントのリスク評価に関する徹底的な分析を含む必要があります。そのためには、医療機器の脅威に関する深い技術的スキルと高度な知識が必要な場合もあり、その習得は容易ではありません。多くの組織は、ネットワークやシステムを保護するための追加投資を行う代わりに、よりシンプルな方法を選択しています。

リスクに対する技術的な影響を適切に評価しなかったために、医療機関やその患者は、予防可能であったかもしれないさまざまな安全やセキュリティの問題にさらされてきました。PTC（医療機器用ソフトウェア メーカー、旧称 Parametric Technology Corporation）は、3 月に 7 つの脆弱性を公表しました。この脆弱性は、ロボット放射線手術に使用される機器に影響を与えました。2019 年 10 月には、VxWorks の Urgent 11 で一連の脆弱性が発表され、ヘルスケアとライフ サイエンスの分野で多く使用されている 10 億台以上のコネクテッド デバイスが影響を受けました。脆弱なコンポーネントが含まれていることが判明した医療機器やソフトウェアのその他の例は、FDA のサイバーセキュリティ ウェブサイトやリコール データベースに掲載されています。

医師が薬を理解し、選択し、処方するための方法は、Google が技術を選択する際にこれまでに述べたような懸念に対処するアプローチと類似しています。最近の FDA ガイダンスでは、メーカーは医療業界でマーケティングおよび販売しているテクノロジーについて、早急により高度な可視性を提供する必要があると示唆しています。ここで、重要な可視化の仕組みである SBOM の登場です。

SBOM のメリットおよび SBOM 改善に向けた Google の 支援

米国商務省電気通信情報局は、SBOM を「ソフトウェアのためにネストされたインベントリ、ソフトウェア コンポーネントを構成する要素のリスト」と定義しています。

SBOM のコンセプトは、1990 年代にソフトウェア メーカーを支援することから始まったようですが、もともとは先見性のあるエンジニア兼教授の W. Edwards Deming 氏が広めたアイデアに端を発しています。その後、コンセプトとしての SBOM は進化し、現在では SBOM を生成して共有するための複数の規格が使用されています。

長年にわたる SBOM の改善と活用への注力の結果、防御側が SBOM を使用してソフトウェアとそのコンポーネント、来歴、含まれるセキュリティ脆弱性を追跡し、患者の治療に影響を与える前にこれらの脆弱性が悪用されるのを阻止する機能を大規模に装備することがずっと簡単になると想定しています。

テクノロジー主導のプライマリケア プロバイダ VillageMD の最高情報セキュリティ責任者 Dan Walsh 氏はこう言います。「ソフトウェア部品表は、現在非常に多くの医療機関がパッチの適用されていない未知のソフトウェアやコンポーネントを運用していることで生じている知識のギャップを埋めるのに役立ちます。セキュリティのリーダーにとって、SBOM はそのソフトウェアが購入されたか構築されたかにかかわらず、アセット インベントリおよび管理機能の延長であるべきです。VillageMD では、第三者ベンダー評価プログラムの一環として、PHI を保存、送信、受信、処理するベンダーに SBOM を要求しています。」

現在の SBOM は、ほとんどの場合、ソフトウェア デベロッパーがソフトウェアの作成を完了し、プロダクトを組み立てる（あるいはソースコードからアプリケーションを作成する）際に生成される基本的なテキスト ファイルです。このテキスト ファイルには、プロダクトのソフトウェア コンポーネントとサブコンポーネント、それらのコンポーネントとサブ コンポーネントの来歴とオーナーについての情報が含まれています。しかし、医薬品を作るための成分表とは異なり、たとえば、SBOM はコンポーネントやサブコンポーネントのソフトウェア バージョンも追跡します。多くの場合、SBOM は以下を記録します。

• サプライヤー名

• コンポーネント名

• コンポーネントのバージョン

• その他の固有の ID

• 依存関係

• SBOM データの作成者

• タイムスタンプ

以下は、SPDX v2.2.1 規格で生成された SBOM のフォーマットです。

あらゆる業界の技術生産者、意思決定者、事業者は、この情報を利用してプロダクトが患者や医療システムにもたらすリスクを詳細に理解できます。たとえば、SBOM により、医療機器に使用されているソフトウェアが単に古いだけなのか、それとも安全な使用に影響を与えるようなサイバー攻撃に対して脆弱性があるのかが読み手に示されます。

Google は、米国政府機関、Open Source Security Foundation、Linux Foundation との提携により、SBOM の使用方法など、ソフトウェア サプライ チェーンのセキュリティ確保に焦点を当てた多くのイニシアチブを後援しており、これには、SBOM の構築と配布に焦点を当てたプロジェクトも含まれています。SPDX プロジェクトや Cyclone DX についてご確認いただき、ISO/IEC 5962:2021 規格（SPDX 用）、ISO ISO/IEC 19770-2:2015（SBOM を提供する別のアーティファクトである SWID 向け）やその他の Linux Foundation のトレーニング リソースをお読みください。

追加対策として、SBOM を使用する医療機関にとって、利用している SBOM がメーカーによって作成された後に変更されていないことを確信できるものとする必要があります。これには、ソフトウェア メーカーが SBOM に暗号で署名することで、SBOM の最初の公開後に悪意を持って変更されたかどうかを容易に特定できるようにすることが可能です。

米国の大統領令 14028 号では、SBOM を連邦政府が義務付けるものとしており、多くの組織がその指令をソフトウェア本番環境のワークフローに取り入れ始めていますが、多くの問題や障害は未解決のままです。Google では、SBOM を使用することで、医療施設に入り込むテクノロジーの重要な可視化を実現し、防御側には患者の安全と患者のデータ プライバシー両方をより効果的に保護できる能力が備わるようになると考えています。

SLSA の詳細

Google は、レジリエンスに優れた組織にはレジリエンスに優れたソフトウェアのサプライ チェーンが必要だと考えています。残念ながら、SBOM のような単一のメカニズムでは、この結果を達成することはできません。そのため、Google は SLSA フレームワークや Assured Open Source Software のようなサービスを作成しました。SLSA は、ソフトウェアのサプライ チェーンを保護する Google 自身のプラクティスに基づいて開発されました。

SLSA は、監査可能なメタデータを自動的に作成できる、段階的かつ強制力のある一連のセキュリティ ガイドラインを使用して、ソフトウェアのサプライ チェーンを保護するためのガイダンスです。このメタデータは、特定のパッケージやビルド プラットフォームに対する「SLSA 証明書」となります。これは、消費者に対して、使用するソフトウェアが改ざんされていないことを保証する検証可能な方法であり、現在広く存在しないものです。SLSA の仕組みについては、最近の SLSA の基本や SLSA の詳細のブログ投稿で詳しく説明しています。

同様に、Assured Open Source Software により、組織は Google が自社のソフトウェアを構築するために使用しているのと同じ、定期的にテストおよび保護されたソフトウェア パッケージを使用できます。SBOM と組み合わせて使用することで、技術メーカーは信頼性が高く、安全で、検証可能なプロダクトを作成できます。地域の医療システムを運営しているようなほとんどの技術購入者は、同じメカニズムを使用して、技術の安全性と使用に対する適合性を可視化できます。

今後の取り組み

患者を治療するために使用する技術を構成するコンポーネントを可視化することが極めて重要です。データのプライバシーだけを優先していては、レジリエンスを備えた医療システムを構築することはできません。最優先事項のリストにレジリエンスと安全性を加える必要があります。医療システムのネットワークを形作る技術を詳しく理解することは、私たちが行うべき重要な方針転換です。SBOM と SLSA がこの転換に役立ちます。しかし、どちらか一方だけでは十分ではないことを忘れないでください。VillageMD の Dan Walsh 氏が言うように、SBOM はまだ道半ばです。

「SBOM はすべての問題を解決できるわけではありません」と同氏は警告します。ただし、適切に使うことで「SBOM は社会の安全を守る重要なシステム上で動作するソフトウェアの可視性を向上させるものであり、普及が進むことを嬉しく思います」とも述べています。

しかし、SLSA や、次に取り上げる VEX（Vulnerability eXploitability Exchange）などのトピックで補完することで、レジリエンスをより高めることができます。