Threat Modeling and Risk Assessment Webinar.pdf

Threat modeling and performing a risk assessment are required by the FDA as part of a 510(k) pre-market submission and will tell you what cybersecurity is needed to make sure your medical device is secure.

Using an example based on a medical device from the MITRE and MDIC’s Playbook for Threat Modeling Medical Devices, webinar presenters will go step-by-step through a threat model and risk assessment for a number of attack paths to clearly show how it is done.

1. 1
Threat Modeling
and Risk
Assessment:
A Step-by-Step Example
September 26 | 1 pm EDT

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'sexperience 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 cybersecuritytasks
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 medtechspace 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 MedicalPrograms &
Cybersecurity

4. Cybersecurity in Medical Devices: Practical Advice for FDA’s 510(k)
Requirements Webinar Series
4
1.On DemandPractical Advice for FDA’s 510(k) Requirements
https://www.ics.com/webinar-demand-practical- advice-fdas-510k-requirements
2.On DemandSecure-by-Design -Using Hardware and Software Protection for FDA Compliance
https://resources.ics.com/webinar/secure-product-development-frameworks
3.On Demand Secure-by-Design-Using Hardware and Software Protection for FDA Compliance
https://resources.ics.com/webinar/secure-by-design- hardware-software-protection
4.Threat modeling and risk assessment–First step in risk management
5.Cyber-testing –What the FDA expects
6.Defense- In-Depth–Securitycontrol categories called for by the FDA
7.Cybersecurity documentation -eSTARsubmissions
8.Post Market Requirements–Fixing Vulnerabilities: SBOM –Updates -Monitoring
9.Bolting On Security –Is there anything that can be done if I already have a design
Today’s Presentation
November

5. Agenda
•Why should threats be modeled, and risks assessed
•Overview of the device used in the example
•Threat modeling steps
•Risk assessment steps
•Steps to implement controls
•Sign up for 1 on 1, hands-on threat modeling & risk
analysis session
5

6. Threat Modeling & Risk Assessment Working Sessions
A Head Start for Your Next Medical Device Seeking Pre-Market Approval
Offering educational/working sessions using threats & risks related to your device
•These processes can be complicated and that is why we offering these sessions
•We’ll apply techniques presented today, for your medical device
•After the session, we’ll leave the spread sheet with you so have a head start
Sign up on Calendly, at the link below, for a 30 minute session
•Here is the link and we’ll put it in the chat

7. 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:
What aspects of threat modeling and risk assessments do you already know?
•Please respond now
•We’ll also ask at the end to see if your perspective has changed
7
MULTIPLE CHOICE ANSWERS TO POLL QUESTION
a.I’m new to these processes so all aspects are helpful
b.Threat modeling but notfor medical devices
c.Threat modeling for medical devices
d.Risk assessment for medical devices
e.Risk assessment andthe iterations between security and safety
f.All aspects of threat modeling and risk assessment for medical devices

8. Threat Modeling and Risk Assessment
Where Are We?
8
FDA’s Cybersecurity in Medical Devices Guidance 2023
ThreatModeling Cybersecurity
Risk Assessment
Foundational
•Identify Assets
•Identify Threat
•Diagrams
Supports
Systematic
•STRIDE
•PASTA
•DREAD
•Attack Trees
Systematic
•Reduce bias with a
mechanical method
•Helps you know
when you’re done
•Semi-quantifiable
scoring method
•Integrates with
Safety Risk
Assessment
Security Risk Management

9. Threat Modeling and Risk Assessment
Why it’s needed?
An important part of a “Secure-By-Design” approach
•Perform threat and risks assessment at the beginning of a new medical device development
Results in integrated solutions which are harder to defeat than add-on solutions which are more vulnerable
•Identifies the security features that will have the biggest impact (based on mitigating the highest risks)
Prioritizing development budget
Required by the FDA for a pre-market submission
•Referred to in eSTARas “Risk Management –Threat Model” and “Risk Management – Cybersecurity Risk
Assessment”
•Feeds 4 of 9 eSTARrequirements for 510K submission
Required by MDR
•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)

10. Medical Device Lifecycle
Threat Modeling & Risk Assessment Used Throughout
Diagram is from
MDCG 2019- 16
Guidance on Cybersecurity for Medical Devices
Threat modeling and a risk
assessment needs to be
performed whenever new
threats are identified……..
……and that can be at any
point in the lifecycle of a
medical device.
Update when:
•Adding new product features
•Obsolescence- driven hardware changes
•Connectivity changes
•New operating environments
•SBOM driven vulnerabilities
•Report of new critical threats response time

11. Security vs. Safety
If it doesn’t impact patient safety, can it
be a severe security issue?
Security Objectives that devices are graded
against:
•Authenticity, which includes integrity;
•Authorization;
•Availability;
•Confidentiality; and
•Secure and timely updatability and
patchability
11
AAMI TIR57:2016/(R)2019

12. Definition of Cybersecurity Risk
Cyber-Attack Feasibilityand Impacton Patient Safety/Harm
‘risk’ means the combination of the probability of occurrence of harm and the severity of that
harm EU MDR
3.31 risk
combination of the probability of occurrence of harm (3.16) and the severity (3.41) of
that harm (3.16)
Unpacking probability:
-Includes exposure to hazard and limits to harm
-statistical probability
not acceptable, proxy of exploitabilityor likelihoodis OK
Unpacking harm (Appendix B.4):
-Includes breach of data, systems security, reduction of effectiveness
(consider resident on system but not active)
based on an evaluation of the likelihood of exploit, the impact of exploitation on the device’s safety and essential performance, and the severity of patient harm if exploitedFDA
AAMI SW96

13. Considerations When Performing Threat and Risk Analysis
Conditions/scenarios that the FDA expects for analysis
•Different operating modes of the medical device
•The software update process
•Scenarios where multiple patients can be harmed with one attack
•Multi-user scenarios
•Lifecycle –Development, Manufacturing, End of life, Service
Environment that the medical device will be used in
•Doctor’s office, clinic, hospital, ambulatory (variation in attackers)
•SaMD (running on different platforms)
•Connectivity (air-gapped, hospital network)
* Hospital general network = hostile environment
Intended use
•Example: data acquisition for off-line, non-real time review, vs.
•immediate decision making/action
4 Architectural Views
(Required)

14. Steps We’ll Go Through In Our Example
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation
Order can
be switched

15. Threat Modeling - STRIDE
STRIDE model. (2023). Retrieved September 24, 2024, from https://en.wikipedia.org/wiki/STRIDE_model
15

16. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

17. Our Example is From
MITRE / MDIC Medical Device Threat Modeling Hand Book
We’ll focus on a Bluetooth
example from Playbook.
Threats are identified in the example in the Playbook…..
……we’ll take it through risk assessment
and security control mitigations

18. Example Ankle Worn Stroke Detection Data Acquisition
AMPS from the MITRE / MDIC Medical Device Threat Modeling Hand Book
We’ll focus on Bluetooth in
our example
The red dashed lines are the
threat boundaries

19. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

20. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

21. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

22. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

23. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

24. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

25. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

26. Tracking Progress Through Our Example Using The Spreadsheet
1.Review system diagram and its intended function
2.Draw threat boundaries
3.Identify assets
4.Use STRIDE to identify threats
5.Score safety impacts of threats
6.Identify attack paths
7.Score the feasibility/difficulty of attack paths
8.Calculate risk score
9.Risk treatment: mitigate, transfer, accept, eliminate
10.Determine risk mitigation

27. Ankle Monitor and Predictor of Stroke System (AMPS)

28. Typical Challenges
1.Concept Phase: Size up your Assets & Threat Vectors = Build a Threat Model, do a Risk Assessment
Challenge: Catalogue your assets and threat vectors for your device, measure the risks associated with your device
2.Sourcing Phase: Managing shifting requirements
Challenge: Transmitting key cybersecurity requirements to internal sw& hwarchitects or external suppliers and
stakeholders or regulators can be costly and time-consuming. Vendors may struggle to keep up, resulting in delays and
unplanned costs
3.Development Phase: Resource-intensive cybersecurity specs
Challenge: Defining detailed cybersecurity specifications requires significant time and resources. Many teams lack the
expertise to produce detailed, compliant requirements early in development, causing delays to time to market
4.Implementation Phase: Lack of cybersecurity prioritization due to lack of knowledge and understanding
Challenge: Cybersecurity efforts often take a back seat to time to market due to a lack of understanding and training.
This will lead to missed FDA cyber certifications, delayed product launches & lost revenue & market share
5.Production Phase: Difficulty in managing security updates and assets
Challenge: Governing and operating the cybersecurity of products in production is complex. Identifying which devices
have vulnerabilities, require updates, or have specific software versions becomes difficult without robust asset management
systems
28

29. Risk Assessment

30. End-to-end Product Cybersecurity Lifecycle
Product Concept
Define target pragmatic product
requirements based on your
architecture and threat model
Sourcing
Simplified supplier vetting and
delegated data collection
Product Design Constellation
Define the cyber blueprint for your product,
collect required Bill of Materials
Connection
to Key Management
Seamlessly implement & integrate
cyber controls with your supply chain
Asset
Management
Track the cyber production lifecycle
and manage vulnerabilities
Assets /
Updates
Perform investigations, Updates and
analysis.
End of life product decommissioning
Concept
Development:
Preliminary Design
Development:
Detailed Design
System Integration
System Deployment /
Operation
System Sustainment /
End of Life

31. The Solution: Cumulus
31
Cumulus is an asset management platform for
managing, tracking, auditing & securing any
device’s End-To-End Product Development
Lifecycle

32. Cumulus: End- to-end Product Cybersecurity Lifecycle
Cumulus Product Concept
Define target pragmatic product
requirements based on your
architecture and threat model
Cumulus Sourcing
Simplified supplier vetting and
delegated data collection
Cumulus Product Design
Constellation
Define the cyber blueprint for your product,
collect required Bill of Materials
Cumulus Connection
to DLM Trust
Seamlessly implement & integrate
cyber controls with your supply chain
Cumulus Asset
Management
Track the cyber production lifecycle
and manage vulnerabilities
Cumulus Assets /
DLM Update
Perform investigations and analysis.
End of life product decommissioning
Concept
Development:
Preliminary Design
Development:
Detailed Design
System Integration
System Deployment /
Operation
System Sustainment /
End of Life

33. Cumulus is the “Easy Button” to meet
FDA’s section 524B
33
524B
The ISS Security Levels
incorporates the overall guidelines
from FDA Cyber Section 524B and
adds our organization’s rigorous
ongoing lifecycle management
parameters

34. 34
First, define your device structure
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

35. 35
Choose the desired security level for the device...
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

36. 36
...to drop in our pre-defined cybersecurity requirements
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

37. 37
Then, delegate the cybersecurity requirements to your
component team contact
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

38. 38
Assign editing permissions to component team contacts
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

39. 39
Team contact receives a magic link email to easily log in
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

40. 40
Team contact adds off-the-shelf
cybersecurity controls for your device
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

41. 41
Easily review the submitted capabilities
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

42. 42
Track your compliance documents process to
streamline approvals
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

43. 43
Export & send your premarket submission
package with a few clicks
Concept
Development:
Preliminary
Design
Development:
Detailed Design
System
Integration
System
Deployment /
Operation
System
Sustainment/
End of Life

44. 44
Mapping the original risks to cybersecurity controls verifies
that your concept is sufficient

45. Cumulus Core Benefits
•Reduce time to market, costs & complexity
•Manage hardware & software component suppliers
•Track vulnerabilities at component level
•Shorten regulatory certification by cataloging all assets from product
concept phase to EOL
•Train internal & external resources to build FDA certifiable
components from day 1
45

46. Poll Question
What aspects of threat modeling and risk assessments do you already know?
•Please respond now
Multiple Choice Answers to the Poll Question
a.I’m new to these processes so all aspects are helpful
b.Threat modeling but notfor medical devices
c.Threat modeling for medical devices
d.Risk assessment for medical devices
e.Risk assessment andthe iterations between security and safety
f.All aspects of threat modeling and risk assessment for medical devices

47. Threat Modeling & Risk Assessment Working Sessions
A Head Start for Your Next Medical Device Seeking Pre-Market Approval
Offering educational/working sessions using threats & risks related to your device
•These processes can be complicated and that is why we offering these sessions
•We’ll apply techniques presented today, for your medical device
•After the session, we’ll leave the spread sheet with you so have a head start
Sign up on Calendly, at the link below, for a 30 minute session
•Here is the link and we’ll put it in the chat

48. Thanks for Attending!
48
David Sequino
Founder & CEO
Colin Duggan
Founder & CEO
Milton Yarberry
Director of MedicalPrograms &
Cybersecurity

49. 49
Link to previous webinars:
Cybersecurity in Medical Devices – Practical Advice for FDA’s 510(k) Requirements
https://www.ics.com/webinar-demand- practical-advice- fdas-510k-requirements
Deep Dive into Secure Product Development Frameworks (SPDF)
https://resources.ics.com/webinar/secure- product-development-frameworks
Secure- by-design: using Hardware and Software Protection for FDA Compliance
https://resources.ics.com/webinar/secure- by-design- hardware- software- protection