Vulnerability Exploitability eXchange はいかに医療機関のサイバーセキュリティ リスクの優先順位付けに貢献できるか

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

慢性的な痛みの診断と治療は、複雑で困難であり、患者と担当医にとって不確実な要素に満ちています。患者の病状と医師の知識次第で、正しい診断を下すのに時間がかかり、さまざまな治療法を試す必要がある場合があります。

この試行錯誤のプロセスのために、最良の治療法が指示されるまで、患者は痛みと当惑の世界に置き去りにされる可能性があります。今日のセキュリティ運用チームの多くが直面している日々の苦闘と似た状況です。

パッチを適用すると、クラッシュ、非互換性、またはダウンタイムなど、さらに深刻な問題をまねく可能性を、セキュリティ チームが判断できない場合もあります。そのような状態で「パッチを当てろ！」と山頂から叫んでも、あまり助けにはなりません。慢性的な痛みがある患者のように、自分たちのシステムの痛みの原因を把握していないかもしれません。どの脆弱性を優先してパッチを当てるか判断し、その修正によってシステムの安全性を確実に向上させることは、セキュリティ チームが直面する最も困難なタスクの一つです。ここで、Vulnerability Exploitability eXchange（VEX）の出番です。

VEX の狙い

以前のブログで、患者の安全とテクノロジーに対する可視性と理解を確立して、レジリエンス（復元力）のある医療システムを構築することが、いかに重要であるか説明しました。ソフトウェア部品表（SBOM: software bills of materials）を Google のソフトウェア アーティファクトのためのサプライ チェーン レベルのフレームワークと組み合わせることが、復元力を実現する安全性を高めたテクノロジーの構築にいかに役立つかも見てきました。

SBOM は、使用しているソフトウェアとその所在の可視性を提供します。一方、SLSA は、構築するソフトウェアの整合性と安全性を向上させるガイドラインを提供します。VEX を使用すると、迅速な診断評価をその方程式に追加できます。電気通信情報局（National Telecommunications and Information Administration）は、VEX を SBOM と共存する「コンパニオン」のドキュメントと表現しています。

医療の例えに戻ると、VEX は、ソフトウェア プロバイダがセキュリティ チームに痛みの原因を探す場所を伝えるメカニズムです。インベントリおよび脆弱性データを特定の時点でキャプチャする必要がある場合、VEX データは、ソフトウェア監査に役立ちます。また、そのデータを自動化されたセキュリティ ツールに埋め込むと、脆弱性のパッチを適用する優先順位付けを容易にできます。  

SBOM は薬のボトルの調剤ラベル、SLSA は薬の安全性を保証する安全キャップや不正開封防止シール、VEX はボトルに書かれた注意事項と考えることができます。診断の補助として、VEX は、悪事を働く者より先に、セキュリティ チームが「害を及ぼす可能性があるもの」とシステムの弱点について正確な診断を行えるように支援します。

しかし、その脅威モデルを正確に評価することは、特にシステムの実行に使用するソフトウェアを検査する場合、困難なものになり得ます。組織の弱点と課題を素早く正確に評価する能力は、脆弱性に急いで対応し、サイバー攻撃が破壊的になる前に阻止するために不可欠です。VEX は、ソフトウェア サプライ チェーンを保護する方程式の重要な要素であると考えています。

例として、2021 年 12 月に明らかになった Apache Log4j の脆弱性が挙げられます。Apache の Log4j 2 ロギング システムに、比較的単純な脅威による攻撃で、素早く侵入してシステムを乗っ取ることができるほどの脆弱性があることが判明し、医療機関を含む全世界の業種がまた打撃を受けました。Google が実施した調査と CISA が提供ている情報によると、Log4j 2 はほぼユビキタスに利用されているため、Log4j 2 という単一のソフトウェア コンポーネントへの脆弱性が、それに依存するソフトウェアを使用している何千もの企業に影響を与える可能性があるという例について説明しました。

VEX はゼロデイ脆弱性をキャプチャしませんが、セキュリティ チームに Log4j 2 の他の既知の脆弱性を知らせることができます。脆弱性が公開されると、セキュリティ チームは SBOM を使用して、その脆弱性を見つけ、VEX を使用して、修復が優先事項かどうか把握できます。

VEX が可視性の手助けとなる理由

SBOM や SLSA などの可視化メカニズムに焦点を当てる主な理由は、リスクを把握できるようになるからです。保護する必要があるものを見抜く力がなければ、リスクを迅速に軽減する方法を判断するのが難しくなる可能性があります。

可視性は、悪意のあるハッカーを阻止するのに欠かせない最初のステップです。しかし、コンテキストがなければ、可視性はセキュリティ チームに手に負えないほどの大量のデータを残すことになります。なぜでしょうか。Open Source Vulnerabilities データベース（OSV）によると、オープンソース ソフトウェアに影響するものに限っても、既知の脆弱性は 30,000 あります。これを低減しようとする場合、どこから始めればよいかわからなくなります。NIST の National Vulnerability Database（NVD）は、181,000 近くの脆弱性を追跡しています。「すべてにパッチを適用する」アプローチを導入すれば、次の千年紀までパッチを適用し続けることになります。

すべての脆弱性に個別対処することは不可能です。進歩をとげるために、セキュリティ チームは、検出結果に優先順位を付け、最も大きな影響を与えるものをまず追跡する必要があります。VEX アーティファクトの目的は、優先順位付けを少し簡単にすることです。

SBOM は、ビルドに含まれるマテリアルが更新されるときに作成または変更されますが、VEX は、新しい脆弱性または脅威が変更されたときに変更および配布されることを目的としています。つまり、VEX と SBOM には個別の管理が必要です。セキュリティ研究者や組織は、常に新しいサイバーセキュリティの脆弱性や脅威を発見しているので、VEX のようなより動的なメカニズムは、ビルダーやオペレーターが確信を持って、使用しているソフトウェアのリスクを迅速に突き止めるのに役立ちます。

では、CycloneDX からのこの VEX の例を掘り下げてみましょう。発見された脆弱性、その脆弱性を追跡および報告するサードパーティ、および CVSS ごとの脆弱性評価のリストを確認できます。また、最も重要なこととして、VEX を読み取っているオペレータにとって、悪用可能で保護が必要な脆弱性のガイドとなるデベロッパーの声明も確認できます。下部で、VEX が SBOM に「影響する」ことがわかります。

この情報により、VEX ドキュメントのユーザーは、関連する SBOM を参照できます。必然的に、VEX は SBOM から意図的に分離されています。VEX と SBOM は、異なるタイミングで更新する必要があるためです。新しい脆弱性が発生した場合は、VEX ドキュメントの更新が必要です。メーカーがソフトウェアに変更を加えた場合は、SBOM の更新が必要です。VEX と SBOM は、個別に更新が可能ですし、その必要もあるのですが、ドキュメントはリンクされているため、各ドキュメントのコンテンツは連携したままにできます。

可視性による復元力の向上 - SBOM+VEX+SLSA

VEX は、セキュリティの脆弱性の処理方法を劇的に改善する可能性があります。オペレーターが脆弱性に専念して、修正が必要なものを的確に推測し、数十ページ（場合によっては数百ページ）のドキュメントを理解することで、影響が最も少ない最適な修正を決定しようとすることは珍しくありません。

SBOM+SLSA+VEX を使用することで、オペレーターは直感や推測に頼る代わりに、ソフトウェア主導のメカニズムを活用したリスクの分析や評価が可能になります。SBOM+SLSA+VEX の 3 点によるアプローチにより、注意が必要な事項に関する最新のリストと展望が提供されます。これはセキュリティの革新的な進歩であり、チームは脆弱性の緩和により適切に対応できるようになり、脆弱性が最も害を及ぼす可能性があるところから開始できます。

医療機関などの重要なインフラストラクチャに対するサイバー攻撃が繰り返されることで、行政機関の規制当局は、ソフトウェアのセキュリティとサプライ チェーンにより関心を寄せるようになりました。米国で SBOM の有効性を強化することは、

新たに提案された Protecting and Transforming Cyber Health Care（PATCH）Act の中で重要な要素となっています。この法律は、医療機器メーカーに対し、自社製品において最低限のサイバーセキュリティ基準を遵守することを求めるものです。この基準には、デバイスの SBOM の作成や、デバイスの全期間に発見されたサイバーセキュリティの脆弱性をモニターしてパッチを適用する計画が含まれています。

一方、FDA からの医療機器サイバーセキュリティ ガイダンスの新しい草案では、医療機器メーカーに自社製品のサイバーセキュリティに対する復元力を向上させるよう、積極的な働きかけを続けています。ホワイトハウスも SBOM の支持を表明しました。2021 年 5 月の大統領令では、安全なソフトウェア開発の要件が明示されています。そこには、連邦政府が使用するソフトウェアの SBOM の作成と配布が含まれています。

このような新政策がどのように展開するかにかかわらず、Google は、SBOM+SLSA+VEX によって提供されるような制御が、ソフトウェアを保護し、復元力のある医療機関のエコシステムを構築するために重要であると考えています。このアプローチでは、セキュリティ チームに詳細で重大なリスク エクスポージャー データを提供するため、セキュリティ チームは、緊急のリスクと長期にわたるリスクを減らすのに必要な措置を講じることができます。

ご提案

Google では、Open Source Security Foundation と協力して SBOM の開発をサポートしています。Google の安全なソフトウェア開発に関する Know, Prevent, Fix（知る、防ぐ、修正する）レポートは、防ぐことが可能な脆弱性からオープンソース ソフトウェアを保護することについての Google の考え方をより広範な概要で示しています。Google Cloud でワークロードを保護するための取り組みについて詳しくは、Cloud アーキテクチャ センター をご覧ください。SLSA Level 2 までのビルド アーティファクトの生成に使用できる Google Cloud サービスである Cloud Build をご確認ください。

多くのお客様は、オープンソース ソフトウェア（OSS）に依存しているため、脆弱性を完全に可視化して制御することが困難です。Assured Open Source Software（Assured OSS）は、チームが使用する外部 OSS パッケージを保護し、回避可能な脆弱性をコードベースから排除するだけで克服できる Google Cloud サービスです。最後に、世界有数のセキュリティ アドバイザリ チームである Google のサイバーセキュリティ対応チームについてと、行政機関、重要なインフラストラクチャ、企業、中小企業のセキュリティとデジタル トランスフォーメーションをサポートするその特異な使命についてご質問をお寄せください。

お客様がソフトウェアのサプライヤーの場合は、上記の提案をご検討ください。サプライヤーであってもなくても、次のことを始める必要があります。

• SBOM+VEX+SLSA（または同等の）アーティファクトをすべての新しいソフトウェアに提供することを契約で義務付けること。

• 購買決定を行うために、SBOM+VEX+SLSA を求めて使用するように調達担当のチームをトレーニングする。組織が、既知の回避可能な問題を抱えたソフトウェアまたはハードウェアを調達する理由はありません。たとえそうしたとしても、これらのメカニズムが提供する情報は、設備がネットワークに入る前に、セキュリティ チームがリスクを許容できるかどうかを判断するのに役立つはずです。

• 調達の決定を管理する人が、購入するソフトウェアに関連するリスクを認識し、そのリスクを負っていることを確認するガバナンス プログラムを確立すること。

• セキュリティ チームがパイプラインを構築して、SBOM+VEX+SLSA アーティファクトをセキュリティ運用に取り込み、それを使用して軽減活動を戦略的に勧告し、推進できるようにすること。

Google では、復元力を高める道のりは、重要な最初のステップとして、ソフトウェア、ハードウェア、設備に可視性と構造的認識を構築することから始まると考えています。VEX が広く導入されるかどうかは、時間が経たなければわかりませんが、その背後にある狙いは変わりません。可視化しなければ、自分たちがいかに脆弱か知ることができません。この点に関して、VEX は重要なコンセプトです。

来月は、ギアを少しシフトして、患者とプロダクトにこだわりを持つセキュリティ文化を確立することによる、復元力の構築に焦点を当てます。