We tackle the question of what is a SPDF for medical device cybersecurity. We look to provide actionable advice that clarifies implementation, and you can apply in your day-to-day tasks.

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

30. Poll Question, Q&A