A Deep Dive into Secure Product Development Frameworks.pdf
0 likes871 views
The document discusses cybersecurity best practices for medical devices, emphasizing the need for a Secure Product Development Framework (SPDF) to comply with FDA requirements. It outlines the critical components of SPDF, including monitoring post-market vulnerabilities, providing Software Bills of Materials (SBOM), and conducting risk assessments. The document also details upcoming webinars that will cover essential cybersecurity topics relevant to FDA compliance and device safety.
A Deep Dive into Secure Product Development Frameworks.pdf
- 1. 1 Cybersecurity in Medical Devices Practical Advice for FDA’s 510(k) Secure Product Development Framework (SPDF)
- 2. About Us – Complementary Partners 2 INTEGRITY Security Services (ISS) is a wholly owned subsidiary of Green Hills Software LLC., established to provide best practice embedded security products and services for the protection of smart devices in all industries from cyber security attacks. ISS's experience enables them to provide the world’s first Secure Platform for Medical (SPM) which dramatically reduces time and resources for medical device OEMs to meet Omnibus Act Section 3305 and FD & C Section 524B. BG Networks equips embedded engineers and penetration testers with easy-to-use software automation tools to streamline cybersecurity tasks including hardening, detection, and testing. BG Networks automation tools are designed to help with adherence to regulations from the FDA, NIST, ISO, and the EU. ICS supports our customers with software development, User experience design, platform and regulatory support to build next generation products. We provide a number of services focused on the medtech space including human factors engineering with a 62366 compliant process, hazard and risk analysis, 62304 compliant software development, and platform support including cybersecurity. Cybersecurity Services Cyber-Testing Detection Hardening Risk Management
- 3. Speaker Introductions 3 David Sequino Founder & CEO Colin Duggan Founder & CEO Milton Yarberry Director of Medical Programs & Cybersecurity
- 4. Topics for Upcoming Webinars In This Series Following are topics for upcoming webinars June 20th Secure-by-Design - Using Hardware and Software Protection for FDA Compliance Threat modeling and risk assessment – First step in risk management Security by design & defense in depth – Security control categories called for by the FDA Cyber-testing – What the FDA expects Cybersecurity documentation - eSTAR submissions Post Market Requirements – Fixing Vulnerabilities: SBOM – Updates - Monitoring Bolting On Security – Is there anything that can be done if I already have a design 4
- 5. Agenda • What does FD&C Act, 524B, say about SPDF • What is a SPDF • Introduction to a SPDF foundation • Example of application of a SPDF • SPDF documents the FDA has asked for 5
- 6. Questions For Us - A Question For You – Link to Previous Webinar Questions for us • Put your questions in the Q&A • For questions we don’t get to, we’ll write answers and make them available after A question for you How confident are you that your medical devices processes meet FDA’s SPDF expectations? • Please respond now • We’ll also ask at the end to see if your perspective has changed For reference here is the previous webinar in this series and the answers to questions asked • Link to previous webinar: https://www.ics.com/webinar-demand-practical-advice-fdas-510k-requirements • Link to previous Q&A: https://www.ics.com/questions-answers-fdas-510k-requirements-webinar • We’ll put both in the chat 6
- 7. Primary goal of SPDF To manufacture and maintain safe and effective devices From a security standpoint, these are also trustworthy and resilient devices
- 8. Sponsors Must • Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits • Provide a software bill of materials (SBOM) • Design, develop, and maintain processes to ensure device and related systems are cybersecure and provide postmarket updates and patches Effective March 29, 2023, the FD&C Act was amended to include section 524B "Ensuring Cybersecurity of Devices” that is introducing cybersecurity provisions for devices meeting the definition of a cyber device. Cyber device means a device that: 1. includes software … as a device or in a device; 2. has the ability to connect to the internet; and 3. contains any such technological characteristics … that could be vulnerable to cybersecurity threats YES, this includes devices only with a USB port Text 524B
- 9. Slide 9 Example Safety & Security Verticals Slide 9 9 IEC 62443 UNR 155/6 ISO 21434 NIST 800-53 DO – 326A DO – 355 ARINC 667 ARINC 835 NIST 800-53 Many TCG Stds FD&C Section 524B EU MDR DO – 178B NIST 800-53 NIST 800-53
- 10. Slide 10 • Patient Harm • Patient confidence in Health Delivery Organizations • Authenticity, which includes integrity • Authorization • Availability • Confidentiality • Secure and timely updatability and patchability Safety & Security go “hand in hand” Slide 10 Safety Security
- 11. 11 Cybersecurity SPDF | Highest Level View Process Documents Image from flaticon.com The FDA won’t inspect your SPDF cybersecurity processes for 510(k) clearance… (but they would for a PMA or routine FDA inspection) … but you want to make sure your processes ensure safety and effectiveness And it results in documents that match expectations for the FDA’s review
- 12. Device Lifecycle Must be Considered in Your SPDF Design/Develop/Test Manufacture Test/Provision/Release Support/Update/Decom Supply Chain Sites / Phases Assets Across Supply Chain Users Devices Digital Assets Sites Users Devices Digital Assets Sites Users Devices Digital Assets Sites Users Devices Digital Assets Sites
- 13. 13 Elements that Make Up a SPDF | Many Ingredients Blended Together SPDF Inputs Cybersecurity Specific Medical Device SPDF Patient Safety & QMS Should Reference SPDF Docs
- 14. Requirements Management SBOM Features Dev. Code Quality CI / CD Pre-Production Testing Post-Production Supporting End of Life Competence Development Threat Modeling Risk Assessment Implement cybersecurity features Static analysis, MISRA C, etc.. Generation CWE/CVE check Validation Pentesting Code Signing Release / Delivery Key Management Locking Hardware Vulnerability Monitoring Feedback / Incident Response Software Updates Diagnostic Tools Secure Decommissioning Software Development Lifecycle Security Development Lifecycle Legend 14 Secure Product Development Framework (SPDF) Based on IEC 81001-5-1
- 15. Overview of IEC 81001-5-1 And AAMI SW96:2023 How They Can Be Used As a Foundation for SPDF
- 16. Developed to Complement Your Existing QMS and Risk Processes QMS SPDF
- 17. IEC 81001-5-1 | Overview – A Software SPDF IEC 81001-5: Finalized in December 2021 • Derived from an existing industrial cyber-security standard but adapted for medical devices • IEC 62443-4: Product Security Development Lifecycle Requirements IEC 81001-5 developed to be an extension to IEC 62304 • IEC 62304: Medical Device Software – Software Life Cycle Processes Recognized around the world • FDA Consensus standard • EU MDR is adopting • Required in Japan A couple of items to keep in mind • Does not exactly match FDA guidance and documentation required for pre market submission • Risk Management section is light-weight (reason to complement with AAMI SW:96)
- 18. AAMI SW96: 2023 | Security Risk Management For Medical Devices • SW96:2023 is a full standard based on Technical Information Reports : TIR57 and TIR97 • Developed to work within the ISO 14971 risk framework • SW96:2023 has a broader definition of harm than ISO 14971 From ANSI/AAMI SW96:2023 Pg 27
- 19. Example Overview of SPDF Steps
- 20. M Cybersecurity Process Secure Product Development Framework (SPDF) Design Controls Design Inputs Cyber ReqA Cyber ReqB Design outputs Cyber SpecX Cyber SpecY Cyber SpecZ Binaries Verification Tests Cyber TestX Cyber TestY Cyber TestZ Mitigations MitigationX MitigationY MitigationZ Threat Assessment ThreatX ThreatY ThreatZ Security Architecture Architecture Diagrams Component Analysis Connectivity definitions Use Case Views Code Known Abnormalities (test failures) Static Software Code Analysis Source SCA Binary SCA SBOM Triage & Justifications Vulnerability Report Penetration Testing (independent white hat) Post Market Vulnerability Management Plan Customer Transparency Plan Published Vulnerabilities Threat Mitigation Testing (vs. ReqA, ReqB) Vulnerability Testing (i.e. malformed input, fuzzing, etc.) Cybersecurity Assessment Security Risk Management Report (PMA - Annual) Security Risk Management Plan Security Risk Test Plan 20 SPDF composition Mitigations
- 21. Example Ankle Worn Stroke Detection Data Acquisition AMPS from the MITRE / MDIC Medical Device Threat Modeling Hand Book Threat Modeling • We like data flow diagrams • They make it easy to see trust boundaries • Good start to 4 architectural views the FDA has mandated Example : Bluetooth • On the AMPS device • An important interface to keep secure! FDA Submission Document Architectural Views Guidance Section : V.B
- 22. Threat Modeling STRIDE – Asset - Attack Path – Attack Feasibility 1) STRIDE 2) Asset 3) Attack Path 4) Score FDA Submission Document Threat Model Guidance Section : V.A, V.B, Appendix 1,2 1. Attacker pairs via bluetooth to AMPs device 2. Attacker reverse engineers code update API 3. Attacker uses API to install mallicious code <= two weeks Expert Restricted Easy Standard 12 Medium-High Attack Path Window of Opportunity Equipment Difficulty Score (lower means easier to hack) Attack Potential Knowledge of TOE Elapsed Time Expertise Overall Attack Potential Score High 0 Medium-High 10 Medium 14 Low 20 Very low 25 Control plane code execution Wrong data provided to Bluetooth app from AMPS device Asset Name Threat Scenario
- 23. Impact - Risk Rating - Requirements (Inputs) Asset Name Damage Scenario Adverse Consequence Control plane code execution Wrong data provided to Bluetooth app from AMPS device 1) Incorrect data provided to doctor to determine patient's risk of stroke 2) Manufacturer could be legally liable 3) AMPS device functionaliy impaired Reduce 1) Implement authentication scheme for Bluetooth access Goal Goal 1: Bluetooth access requires authentication Requirement 1: Use Bluetooth LE Secure Connections based on Elliptic Curve Diffie Hellman challenge-response. Requires screen and yes/no buttons for user interface Cybersecurity Goal(s) or Claim Goals or Claim Summary Goal Requirement(s) Risk Treatment Decision Risk Treatment Details 5) Consequence 6) Impact 7) Risk Rating 8) Requirement FDA Submission Document Cybersecurity Risk Assessment Guidance Section : V.A FDA Submission Document Requirements Guidance Section : V.B.1, App.1 Safety Financial Operational Privacy Moderate Major Major Moderate Major S: Patient could be at risk of a stroke but is not treated F: If could be proven that the wrong data is being sent the medical device manufacturer could be liable O: Device is not functioning correctly P: Vital signs and stroke related data stolen Impact Categories Overall Impact Impact Justification Attack Feasibility Rating Very low Low Medium Medium-High High Impact Rating Severe 2 3 4 5 5 Major 1 2 3 4 5 Moderate 1 2 2 3 4 Negligible 1 1 1 1 2 Major Medium-High 4 Impact Rating Attack Feasability Rating Risk Value (1 - 5)
- 24. SBOM FDA Submission Document SBOM Guidance Section : V.A.4, VI.A FDA Submission Document Vulnerability Assessment and Software Support Guidance Section : V.A.4 Common formats? • SPDX (older, licensing focus) • CycloneDX (lightweight, open source focus) • SWID (software tracking focus) What’s in it? • Types of info: • SW Component data fields • SBOM Author • Automation fields How created? • OS + commercial SW + open source • From build system • Component analysis tools • Vulnerability scanning tools • Simpler with managed packages How used? • Lookup in National Vulnerability Databases – (nvd.nist.gov/vuln/search) • Automation tools intended for this purpose JSON YAML Tag, Value
- 25. Cyber-Testing - Verification of Outputs Four Types of Testing Called for by the FDA FDA Submission Document Testing Guidance Section : V.C TYPES OF TEST DESCRIPTION BLUETOOTH EXAMPLE Security Requirements Testing • Verification of input/requirement for security features • Testing of functionality including boundary cases • Positive and negative tests of Elliptic Curve Diffie Helman challenge-response • Verify that programming API and device characteristics are available only after auth. Threat Mitigation Testing • Validation/system level testing • Tie back to threat model • Consider global system, multi-patient harm, patchability • Test security of keys from brute force attacks • Consider break-one-break-them-all scenarios if unique keys per device not specified • Test for authentication bypass (e.g. pairing accepted without correct response) Vulnerability Testing • Testing for malformed inputs • Unexpected inputs • Vulnerability Chaining • Fuzzing, scanning, encryption check, static & dynamic code analysis • NIST NVD and CISA Known Exploited Vulnerabilities Catalog for Bluetooth vulns. using CPE. Penetration Testing • Testing done by personnel who have not worked on the design • White box testing recommended : more efficient & accepted by FDA • One week of pentesting on Bluetooth interfaces • MITM attacks, key extraction from app, key extraction for AMPS device (e.g., JTAG, USB, UART), malformed inputs, DoS, etc…
- 26. Cybersecurity Risk Management Report Risk Management Report Vulnerability/Threat Mitigation/Penetration Testing SBOM Threat Modeling Threat Intelligence (e.g., CISA Vulnerability Catalog) FDA Submission Document Cybersecurity Risk Management Report Guidance Section : V, VI.B FDA Submission Document Unresolved Anomaly Assessment Guidance Section : V.A.5 FDA Submission Document Traceability Guidance Section : V.A, V.B, V.C, VI.A Overview • 3 Report Descriptions • FDA Submission Document: V, VI.B • TIR57, sec. 8. • SW96 Appendix C • Terms and concepts from the three sources are slightly different • Summary and References • Risk Management Report should succinctly SUMMARIZE the risk management process followed, and details of the outcome • Full analysis, assessments, models are REFERENCED in report Report Contents • System Description • Device Intended Use • Operating Environment • Threat Model • Security Risk Assessment • SBOM • Vulnerability Assessment • Unresolved Anomalies Assessment • Risk evaluation methods and processes • Residual Risk conclusions • Risk Mitigation activities • Component support information • Traceability: threat model / risk assessment / SBOM / testing documentation
- 27. Labeling FDA Submission Document Labeling Guidance Section : VI.A Labeling as applied to cybersecurity • How to securely configure/set secure passwords • Document risks that are transferred • Security information of IT cybersecurity staff • Device identification on a network and how to track • Logging and attack detection information • Instructions to obtain software updates • Date of end of life support • How a device under attack will notify user • Protections against catastrophic events Labeling for example • How to set password in BT phone app • No risks transferred – all BT risks mitigated • Security information of IT cybersecurity staff • Unique device IDs tracked through app to cloud • IDS alerts provided on detection of attacks • URL on company website for software updates • End of life date negotiated between medical device manufacturer and HDO Labeling for user to help manage security risks - “Manufacturers should provide or make available SBOM information to users on a continuous basis” - Online portal to publish SBOM information, vulnerability information. Updated. Accurate.
- 28. Post Market FDA Submission Document Cybersecurity Management Plans Guidance Section : VI.B FDA Submission Document Measures and Metrics Guidance Section : V.A.6 Cybersecurity Management Plans • Personnel responsible • Post market vulnerability monitor plan and sources of threat intel • Update process and time to patch • Vulnerability disclosure to manufacturer & communication to HDOs • Communicate through Online portal Measures & Metrics • Percentage of vulnerabilities that are patched • Time from vulnerability identification to patching • Duration from when a patch is available to implementation in devices deployed
- 29. One Result of your SPDF Documentation for FDA Pre-Market Submission – Appendix 4