米国 食品医薬品局 (FDA) 医療機器におけるサイバーセキュリティ：品質システムに関する考察と市販前申請の内容：産業界と食品医薬品局スタッフのためのガイダンス（案） (2022.04.08)

こんにちは、丸山満彦です。

米国 食品医薬品局が医療機器におけるサイバーセキュリティについてのガイダンス案を公表し、意見募集をしていますね。。。SBOMも内容に含まれていますね。。。

● Food and Drug Administration: FDA

・Guidance Documents (Medical Devices and Radiation-Emitting Products)

・2022.04.08 Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

・[PDF]

I. Introduction	I. はじめに
II. Scope	II. 対象範囲
III. Background	III. 背景
IV. General Principles	IV. 一般原則
A. Cybersecurity is Part of Device Safety and the Quality System Regulations	A. サイバーセキュリティは機器安全および品質システム規制の一部である
B. Designing for Security	B. セキュリティのための設計
C. Transparency	C. 透明性
D. Submission Documentation	D. 提出書類
V. Using an SPDF to Manage Cybersecurity Risks	V. サイバーセキュリティリスクを管理するためのSPDFの利用
A. Security Risk Management	A. セキュリティリスク管理
1. Threat Modeling	1. 脅威のモデル化
2. Third-Party Software Components	2. サードパーティソフトウェアコンポーネント
3. Security Assessment of Unresolved Anomalies	3. 未解決の異常に対するセキュリティ評価
4. Security Risk Management Documentation	4. セキュリティリスクマネジメントの文書化
5. TPLC Security Risk Management	5. TPLCセキュリティリスクマネジメント
B. Security Architecture	B. セキュリティ・アーキテクチャ
1. Implementation of Security Controls	1. セキュリティコントロールの実装
2. Security Architecture Views	2. セキュリティ・アーキテクチャ・ビュー
(a) Global System View	(a) グローバルシステムビュー
(b) Multi-Patient Harm View	(b) マルチペアレントハームビュー
(c) Updatability and Patchability View	(c) 更新性・パッチ適用性ビュー
(d) Security Use Case Views	(d) セキュリティユースケースビュー
C. Cybersecurity Testing	C. サイバーセキュリティテスト
VI. Cybersecurity Transparency	VI. サイバーセキュリティの透明性
A. Labeling Recommendations for Devices with Cybersecurity Risks	A. サイバーセキュリティリスクのある機器に対するラベリング推奨事項
B. Vulnerability Management Plans	B. 脆弱性管理計画
Appendix 1. Security Control Categories and Associated Recommendations	附属書 1. セキュリティ管理カテゴリーと関連する推奨事項
A. Authentication	A. 認証
B. Authorization	B. 認可
C. Cryptography	C. 暗号技術
D. Code, Data, and Execution Integrity	D. コード、データ、実行の整合性
E. Confidentiality	E. 機密保持
F. Event Detection and Logging	F. イベントの検出とログ
G. Resiliency and Recovery	G. 回復力およびリカバリ
H. Firmware and Software Updates	H. ファームウェアとソフトウェアの更新
Appendix 2. Submission Documentation for Security Architecture Flows	附属書2．セキュリティアーキテクチャフローの提出書類
A. Call-Flow Diagrams	A. コールフロー図
B. Information Details for an Architecture View	B. アーキテクチャビューの情報詳細
Appendix 3. Submission Documentation for Investigational Device Exemptions	附属書 3. 治験機器申請書類について
Appendix 4. Terminology	附属書 4. 用語解説

SBOM関係

2. Third-Party Software Components	2. サードパーティソフトウェアコンポーネント
As discussed in the FDA guidances “Off-The-Shelf (OTS) Software Use in Medical Devices”[25] and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software,”[26] medical devices commonly include third-party software components including off-the-shelf and open source software. When these components are incorporated, security risks of the software components become factors of the overall medical device system risk management processes and documentation.	FDAのガイダンス「Off-The-Shelf (OTS) Software Use in Medical Devices」[25]や「Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software」[26]で述べられているように、医療機器には一般的に市販のソフトウェアやオープンソースを含む第三者のソフトウェアコンポーネントが含まれています。これらのコンポーネントが組み込まれると、ソフトウェアコンポーネントのセキュリティリスクは、医療機器システム全体のリスク管理プロセス及び文書化の要素となります。
As part of demonstrating compliance with quality system design controls under 21 CFR 820.30(g), and to support supply chain risk management processes, all software, including that developed by the device manufacturer (“proprietary software”) and obtained from third parties should be assessed for cybersecurity risk and that risk should be addressed. Accordingly, device manufacturers are expected to document all software components[27]of a device and to mitigate risks associated with these software components.	21 CFR 820.30(g)に基づく品質システム設計管理への準拠を実証する一環として、またサプライチェーンのリスク管理プロセスを支援するために、機器メーカーが開発したソフトウェア（「専有ソフトウェア」）や第三者から入手したソフトウェアを含むすべてのソフトウェアは、サイバーセキュリティリスクを評価し、そのリスクに対処する必要があります。したがって、機器メーカーは、機器のすべてのソフトウェアコンポーネント[27]を文書化し、これらのソフトウェアコンポーネントに関連するリスクを軽減することが期待されています。
In addition, under 21 CFR 820.50, manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s requirements. Such information is documented in the Design History File, required by 21 CFR 820.30(j), and Design Master Record, required by 21 CFR 820.181. This documentation demonstrates the device’s overall compliance with the QSR, as well as that the third-party components meet specifications established for the device. Security risk assessments that include analyses and considerations of cybersecurity risks that may exist in or be introduced by third-party software and the software supply chain may help demonstrate that manufacturers have adequately ensured such compliance and documented such history.	さらに、21 CFR 820.50に基づき、メーカーは、サプライヤーがメーカーの要件に適合することを保証するためのプロセスとコントロールを導入する必要があります。このような情報は、21 CFR 820.30(j)で要求される設計履歴ファイル及び 21 CFR 820.181 で要求される設計マスターレコードに文書化される。この文書により、機器が全体的にQSRに準拠していること、及び第三者の部品が機器に対して設定された仕様を満たしていることが証明される。サードパーティ製ソフトウェア及びソフトウェアサプライチェーンに存在する、又はそれらによってもたらされる可能性のあるサイバーセキュリティリスクの分析及び考慮を含むセキュリティリスク評価は、製造業者がそのようなコンプライアンスを適切に確保し、その履歴を文書化していることを証明するのに役立つ場合があります。
As part of configuration management, device manufacturers should have custodial control of source code through source code escrow and source code backups.[28] While source code is not provided in premarket submissions, if this control is not available based on the terms in supplier agreements, the manufacturer should include in premarket submissions a plan of how the thirdparty software component could be updated or replaced should support for the software end. The device manufacturer is also expected to provide to users whatever information is necessary to allow users to manage risks associated with the device.	28] 市販前申請ではソースコードは提供されないが、供給者契約の条件に基づいてこの管理が利用できない場合、製造者は市販前申請に、ソフトウェアのサポートが終了した場合に第三者のソフトウェアコンポーネントをどのように更新または交換できるかの計画を含める必要があります。また、機器メーカーは、ユーザーが機器に関連するリスクを管理できるようにするために必要なあらゆる情報をユーザーに提供することが期待されています。
One tool to help manage supply chain risk as well as clearly identify and track the software incorporated into a device is a Software Bill of Materials (SBOM), as described below.	サプライチェーンのリスクを管理し、機器に組み込まれたソフトウェアを明確に特定し追跡するのに役立つツールの1つが、以下に説明するソフトウェア部品表（SBOM）です。
(a)  Software Bill of Materials	(a) ソフトウェア部品表
A Software Bill of Materials (SBOM) can aid in the management of cybersecurity risks that exist throughout the software stack.  A robust SBOM includes both the device manufacturer developed components and third-party components (including purchased/licensed software and open-source software), and the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software. An SBOM helps facilitate risk management processes by providing a mechanism to identify devices that might be affected by vulnerabilities in the software components, both during development (when software is being chosen as a component) and after it has been placed into the market throughout all other phases of a product’s life.[29]	ソフトウェア部品表（SBOM）は、ソフトウェアスタック全体に存在するサイバーセキュリティリスクの管理を支援することができます。 堅牢なSBOMは、デバイスメーカーが開発したコンポーネントとサードパーティのコンポーネント（購入/ライセンスされたソフトウェアとオープンソースのソフトウェアを含む）、およびプロプライエタリ、購入/ライセンス、オープンソースのソフトウェアが要求/依存する上流のソフトウェアの依存関係の両方を含んでいます。SBOMは、開発中（ソフトウェアがコンポーネントとして選択されるとき）と、製品のライフサイクルの他のすべての段階を通じて市場に投入された後の両方で、ソフトウェアコンポーネント内の脆弱性によって影響を受けるかもしれない装置を識別するメカニズムを提供することによって、リスク管理プロセスの促進を支援する[29]。
Because vulnerability management is a critical part of a device’s security risk management processes, an SBOM or an equivalent capability should be maintained as part of the device’s configuration management, be regularly updated to reflect any changes to the software in marketed devices, and should support 21 CFR 820.30(j) (Design History File) and 820.181 (Design Master Record) documentation.	脆弱性管理は、機器のセキュリティリスク管理プロセスの重要な部分であるため、SBOMまたは同等の機能は、機器の構成管理の一部として維持され、市販の機器のソフトウェアのあらゆる変更を反映するために定期的に更新され、21 CFR 820.30(j) （設計履歴ファイル）および820.181（設計マスターレコード）文書をサポートする必要があります。
To assist FDA’s assessment of the device risks and associated impacts on safety and effectiveness related to cybersecurity, FDA recommends that premarket submissions include SBOM documentation as outlined below. SBOMs can also be an important tool for transparency with users of potential risks as part of labeling as addressed later in Section VI	サイバーセキュリティに関連する機器のリスクおよび安全性と有効性への関連した影響のFDAによる評価を支援するために、FDAは市販前申請に以下のようなSBOM文書を含めることを推奨しています。SBOMはまた、セクションVIで後述するように、ラベリングの一部として潜在的なリスクをユーザーに透明化するための重要なツールになりえます。
(b)  Documentation Supporting Software Bill of Materials	(b) ソフトウェア部品表をサポートする文書
FDA’s guidance documents “Off-The-Shelf (OTS) Software Use in Medical Devices”[30]  and “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software”[31] describe information that should be provided in premarket submissions for software components for which a manufacturer cannot claim complete control of the software lifecycle.  In addition to the information recommended in those guidances, for each OTS component, the following should also be provided in a machine-readable format in premarket submissions.	FDAのガイダンス文書「医療機器における既製（OTS）ソフトウェアの使用」[30]と「既製（OTS）ソフトウェアを含むネットワーク型医療機器のサイバーセキュリティ」[31]は、メーカーがソフトウェアのライフサイクルを完全にコントロールできないとするソフトウェアコンポーネントについて市販前申請で提供すべき情報を記述しています。 これらの指針で推奨される情報に加えて、各OTSコンポーネントについて、以下の事項を市販前申請の際に機械可読形式で提供することが望ましい。
A.  The asset(s) where the software component resides;	A. ソフトウェア・コンポーネントが存在する資産
B.  The software component name;	B. ソフトウェア・コンポーネントの名称
C.  The software component version;	C. ソフトウェアコンポーネントのバージョン
D.  The software component manufacturer;	D. ソフトウェアコンポーネントの製造元
E.  The software level of support provided through monitoring and maintenance from the software component manufacturer;	E. ソフトウェア部品製造業者による監視と保守を通じて提供されるソフトウェアレベル
F.  The software component’s end-of-support date; and	F.  ソフトウェア・コンポーネントのサポート終了日
G.  Any known vulnerabilities.[32]	G. 既知の脆弱性[32]。
Industry-accepted formats of SBOMs can be used to provide this information to FDA; however, if any of the above elements are not captured in such an SBOM, we recommend that those items also be provided, typically as an addendum, to FDA for the purposes of supporting premarket submission review. Additional examples of the type of information to include in a SBOM can be found in the Joint Security Plan - Appendix G (“Example Customer Security Documentation”)[33] and Sections 2.3.17 and 2.3.18 of the Manufacturer Disclosure Statement for Medical Device Security (referred to as MDS2 or MDS2)[34].	SBOMの業界標準のフォーマットを使用してFDAにこの情報を提供することができます。しかし、上記の要素のいずれかがSBOMに含まれていない場合、市販前の申請審査をサポートする目的で、それらの項目も、通常は補遺として、FDAに提供することをお勧めします。SBOMに含めるべき情報の種類の追加例は、共同セキュリティ計画-付録G（「顧客セキュリティ文書の例」）[33]および医療機器セキュリティに関する製造業者開示声明（MDS2またはMDS2と呼ばれる）[34]のセクション2.3.17および2.3.18で見つけることができます。
As part of the premarket submission, manufacturers should also describe how the known vulnerabilities (item (G) above) were discovered to demonstrate whether the assessment methods were sufficiently robust. For third-party components with known vulnerabilities, device manufacturers should provide in premarket submissions:	また、製造業者は、市販前申請の一部として、評価方法が十分に堅牢であったかどうかを示すために、既知の脆弱性（上記項目（G））がどのように発見されたかを説明する必要があります。既知の脆弱性を有するサードパーティーコンポーネントについて、機器メーカーは市販前申請で提供する必要があります。
•       A safety and security risk assessment of each known vulnerability; and	・各既知の脆弱性に関する安全性及びセキュリティリスク評価
•       Details of applicable safety and security risk controls to address the vulnerability.  If risk controls include compensating controls, those should be described in an appropriate level of detail	・ 脆弱性に対処するために適用される安全性およびセキュリティリスクコントロールの詳細。 リスクコントロールに代償コントロールが含まれる場合,それらは適切なレベルで詳細に記述されるべきです。
For additional information and discussion regarding proprietary and third-party components, see section V.B.2., Security Architecture Views, below.	専有部品及び第三者部品に関する追加情報及び議論については、以下の「V.B.2.セキュリティアーキテクチャービュー」を参照のこと。
[25] See FDA guidance Off-The-Shelf (OTS) Software Use in Medical Devices available at: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices.  26	[25] 医療機器における既製（OTS）ソフトウェアの使用については、https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices にあるFDAガイダンスを参照。 26 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networkedmedical-devices-containing-shelf-ots-software にあるFDAガイダンス「Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software」を参照のこと。
[26] See FDA guidance Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software available at: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networkedmedical-devices-containing-shelf-ots-software.	[26] FDA ガイダンス「Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software」を参照（https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networkedmedical-devices-containing-shelf-ots-software）。
[27] The use of “component” in this guidance is consistent with the definition in 21 CFR 820.3.	[27] 本ガイダンスにおける「コンポーネント」の使用は、21 CFR 820.3における定義と一致している。
[28] While some suppliers may not grant access to source code, manufacturers may consider adding to their purchasing controls acquisition of the source code should the purchased software reach end of support or end of life from the supplier earlier than the intended end of support or end of life of the medical device.	[28] 供給者によってはソースコードへのアクセスを認めない場合もあるが、製造者は、購入したソフ トウェアが供給者からのサポート終了又は医療機器の意図したサポート終了又は寿命より早く終 了する場合には、ソースコードの取得を購買管理に加えることを検討してもよい。
[29] For additional information see the Department of Commerce National Telecommunications and Information Administration’s multi-stakeholder process for software transparency.	[29] その他の情報については、商務省電気通信情報局のソフトウェアの透明性に関するマルチステークホルダー・プロセスを参照してください。
https://www.ntia.doc.gov/SoftwareTransparency	https://www.ntia.doc.gov/SoftwareTransparency
[30] See FDA guidance Off-The-Shelf (OTS) Software Use in Medical Devices available at: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices.	[30] FDAガイダンス「Off-The-Shelf (OTS) Software Use in Medical Devices」を参照（https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-medical-devices）。
[31] See FDA guidance Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software available at: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networkedmedical-devices-containing-shelf-ots-software.	[31] https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networkedmedical-devices-containing-shelf-ots-software にあるFDAガイダンス「Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software」を参照すること。
[32] Known vulnerabilities are vulnerabilities that are published in the public National Vulnerability Database (NVD) or similar software vulnerability and/or weakness database. NVD is available at https://nvd.nist.gov/vuln/full-listing	[既知の脆弱性とは、公開されているNational Vulnerability Database（NVD）または同様のソフトウェア脆弱性・弱点データベースで公開されている脆弱性を指します。NVD は、https://nvd.nist.gov/vuln/full-listing で利用可能です。
[33] Medical Device and Health IT Joint Security Plan (JSP) is available at https://healthsectorcouncil.org/the-jointsecurity-plan/.	[33] 医療機器と医療ITの共同セキュリティ計画（JSP）は、https://healthsectorcouncil.org/the-jointsecurity-plan/ で入手できます。
[34] The Manufacturer Disclosure Statement for Medical Device Security is available at https://www.nema.org/standards/view/manufacturer-disclosure-statement-for-medical-device-security.	[34] 医療機器セキュリティに関する製造者開示説明書（Manufacturer Disclosure Statement for Medical Device Security）は、https://www.nema.org/standards/view/manufacturer-disclosure-statement-for-medical-device-security。