November 14, 2023 • 27 mins
Security from cyberattack for medical devices is paramount. And the FDA wants you to have a plan for it. Becky Ditty and Donna-Bea Tillman tell you how to be prepared.
Guidance documents:
- Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions: Guidance for Industry and Food and Drug Administration Staff. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
- Postmarket Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
- Cybersecurity in Medical Devices: Refuse to Accept Policy for Cyber Devices and Related Systems Under Section 524B of the FD&C Act: Guidance for Industry and Food and Drug Administration Staff (related to the requirements per the Consolidated Appropriations Act, 2023) https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-refuse-accept-policy-cyber-devices-and-related-systems-under-section
- Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-networked-medical-devices-containing-shelf-ots-software
Playbook for Threat Modeling devices https://www.mitre.org/publications/technical-papers/playbook-threat-modeling-medical-devices
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
James C Taylor (00:02):
Cyber security is important, particularly when it
comes to medical devices and theFDA has clear expectations of cyber
security for pre market submissions.
What do they want andhow can you get it done?
We'll find out with BeckyDiddy and Donna B Tillman.
I'm James C.
Taylor and this is Insight at biologics.
(00:28):
And here with me now are Becky andDonna Bea and ladies, why don't
you tell people about yourselves?
Becky Ditty (00:34):
Hi, I'm Becky Ditty.
I am a medical device regulatoryconsultant at Biologics Consulting.
I have been in the industry for 20 years.
And in that whole time, I'vebeen doing regulatory work.
My specialty is focusing on premarket submissions, and a lot of
(00:54):
those submissions include software.
DonnaBea Tillman (00:57):
And I am Donna Bea Tillman.
I am a biomedical engineer,and I was at FDA for 17 years,
and I've been here at BiologicsConsulting for the past 12 years.
Like Becky, I am a medical device, aregulatory consultant, and I work with
many clients on software enabled devices.
James C Taylor (01:20):
Well, I thank you both for being a part of this podcast and
speaking of this podcast, Becky,why don't you frame for everybody
what we are and maybe even whatwe aren't going to talk about?
Becky Ditty (01:33):
The purpose of this podcast is to provide an
introduction to FDA's cybersecurityexpectations for medical devices.
especially as it relates tothe information needed to
support a pre market submission.
The intent is not to have a discussionabout specific cybersecurity
techniques or mitigations, and itisn't intended to cover every aspect
(01:57):
of FDA's cybersecurity Guidances.
This is an introductionto FDA's expectations.
James C Taylor (02:06):
Okay.
All right.
So with that said, where would yourecommend a medical device developer to
start when it comes to cybersecurity?
Becky Ditty (02:15):
The first place to start is to become familiar with FDA's guidance
documents as they relate to cybersecurity.
These guidance documents includecybersecurity and medical devices.
Quality system considerations andcontent of pre market submission.
This will be referred to as thePremarket Cybersecurity Guidance.
(02:38):
There's also the post marketmanagement of cybersecurity and medical
devices, guidance for industry andFood and Drug Administration staff.
And this will be referredto as the Postmarket
Cybersecurity Guidance Document.
There's also the Cybersecurity andMedical Devices Refuse to Accept
Policy for Cyber Devices and RelatedSystems under Section 524B of the
(03:05):
FD& C Act, Guidance for Industry andFood and Drug Administration Staff.
And this relates to therequirements per the Consolidated
Appropriations Act of 2023.
And finally, there's the Cybersecurityfor Networked Medical Devices
Containing Off the Shelf Software.
(03:26):
In the show notes, you will find linksto these guidances and other documents
I referenced throughout this discussion.
One other important aspect is that youreally need to have a cybersecurity
expert on the team or actively workingwith an external cybersecurity expert.
Gone are the days when you can justtry and throw something together to
(03:48):
address FDA's cybersecurity needs,
recommendations.
James C Taylor (03:51):
No flying by the seat of your pants.
Becky Ditty (03:55):
No, no, they, they really dig in.
James C Taylor (03:59):
All right.
So now once you have your cybersecurityguidance documents, what's next?
What kind of designdocumentation is needed?
Becky Ditty (04:08):
First, you want to start early
to be secure from the get go.
You don't want to address cybersecurityat the end of design development.
It should not be an afterthought.
You want to include cybersecuritymitigations into the device from
the onset, as it can be harder toadd in mitigations after the fact.
(04:31):
It also helps you provide amore secure device by designing
security in from the beginning.
You'll want to start withdoing a threat analysis.
And you want to make sure to followan industry recognized method.
DonnaBea Tillman (04:45):
Yes, and in terms of the industry recognized methods, one of
the questions we get a lot is, is therea particular method that FDA requires
medical device companies to follow?
And the short answer is no.
FDA doesn't require anyparticular methodology.
But they do require that you actuallypick a formal methodology to follow.
(05:08):
Some of the common methodologiesthat we see medical device
companies use are stride, attacktrees, kill chain, and dread.
So as long as you pick a wellestablished methodology and follow it,
you generally should be okay with FDA.
Becky Ditty (05:24):
And doing a threat analysis is part of your cybersecurity
risk management process as a whole.
And it's important to note that performinga security risk management is distinct
from performing safety risk management.
As identified in the premarketcybersecurity guidance document,
(05:46):
safety risk management focuses onphysical injury, damage to property
or the environment, or delayand or denial of care due to the
device or system unavailability.
Security risk management, on the otherhand, includes risks that can result.
indirectly or directly to patient harm.
(06:07):
Additionally, risks that areoutside of FDA's assessment of
safety and effectiveness, suchas those related to business or
reputational risks, may also exist.
FDA recommends generating asecurity risk management plan,
a security risk management report,and a company documentation.
(06:28):
This is detailed in section VA of thePremarket Cybersecurity Guidance Document.
When doing a threat analysis, youwant to first begin with the story.
Discuss the general architecture andcybersecurity architecture first to
help the reviewers understand thecybersecurity framework of the system.
(06:51):
In the architecture discussion,be sure to point out software
controls and hardware controls.
You are going to be using this threatmodel as a tool to help you identify where
your risks are, how your design currentlymitigates cybersecurity risks, and
(07:11):
where additional mitigations are needed.
Have you built into the softwaremethods to identify an incident that
took place or one was attempted?
Do you have audit logs to helpidentify who is taking which actions?
We will talk aboutmitigations more in a minute.
You may also want to refer to the Playbookfor Threat Modeling Medical Devices.
(07:37):
As an educational resource that wasdeveloped by MITRE and discusses best
practices for understanding basic threatmodeling concepts and processes and
how to apply them to medical devices.
FDA commonly references this resource.
So in your threat model, you'll alsowant to talk about the vulnerabilities
(08:02):
and threats and mitigations.
Make sure you're thinking big.
There are obvious risks, but be sureto capture risks introduced through,
for example, the supply chain, suchas risk introduced through off the
shelf software, risk introduced throughmanufacturing, you know, how are
(08:23):
your systems secure, interoperabilitywith other devices, and so forth.
So make sure not just tothink about the obvious risks.
but go outside the box.
And then I recommend classifyingmitigations into the grouping
FDA has in their CybersecurityPremarket Draft Guidance.
(08:46):
That includes authentication,authorization, cryptography, code
data and execution integrity,confidentiality, Event detection and
logging, resiliency and recovery,updatable, updatability, and patchability.
(09:08):
FDA often focuses deficiency questionsbased on mitigation classification types.
So grouping mitigations by type, one,helps make sure you have thought through
all types of mitigations, and two, makesit easier for the reviewer to access and
understand your cybersecurity controls.
(09:29):
Mitigations are not just abouthow the system is designed, but
the processes and procedures acompany has in place to identify and
respond to cybersecurity incidences.
How are you monitoring thecybersecurity environment and
your device vulnerabilities?
or newly identified vulnerabilitiesof any off the shelf software?
(09:53):
Do you have communication pathwaysin place to notify users of new
cybersecurity weaknesses or events?
Do you provide users with the propercybersecurity information in the labeling?
A few of these examples are:
Including cyber security best practices.
Don't leave the computeror mobile device unlocked.
(10:15):
Use antivirus software, firewalls.
Don't write down passwords,
etc.
This may seem like commonknowledge, but it is a...
good practice to communicate it tousers, just like all those pharmaceutical
commercials where they tell you not totake the drug if you are allergic to it.
By now you would think most peoplewould know this, but FDA thinks it is
(10:39):
important enough to bear repeating.
Same with cybersecurity best practices.
If applicable, make sure you're labelingprovides a description of systematic
procedures for users to downloadversion identifiable software and
firmware, including how a user willknow when the software is available.
(11:00):
Provide technical instructions topermit secure network development and
servicing, and instructions for userson how to respond upon detection of a
cybersecurity vulnerability or incident.
These are just some examplesof what to include in labeling.
This does not cover everything you need.
DonnaBea Tillman (11:20):
So that's a lot of really great information, Becky.
There is a lot to consider, itsounds like, when thinking about
cybersecurity risk management.
A lot of things that companies need to do.
And I also think it's also importantwhile you're doing this to not only
think about what you need to be doing aspart of your quality management system,
(11:41):
But to also be thinking about how thisinformation is ultimately going to be
reviewed in a premarket submission.
FDA is moving more and more towardssmart templates, things like the E
STAR that is now required for 510ksubmissions that require you to provide
information in a more structured manner.
(12:02):
And so it's important that you arewell aware of these smart templates
that FDA has implemented and thatwhen you prepare your premarket
submission, your 510k, or your denovo, that you make it easy for FDA to
find the information that they need.
You need to provide all of these,this information that is required,
(12:23):
but you can't just dump a wholebunch of documents on FDA and expect
them to find their way through it.
It is important with cybersecurity asit is with really any part of anything
you're going to give to FDA, to makesure that you tell the story around your
cyber security process, and that youhold FDA's hand and explain what you've
(12:44):
done and how it supports your device.
So, I think, you know, as Beckycontinues to talk about these items,
and what is needed based on the guidancedocuments, it's also important to
think about how you're going to bepresenting it to FDA in a way that
makes it easy for them to do their job.
James C Taylor (13:00):
Right.
Right.
Reviewers don't have a lot of timewith anything that's submitted.
And so if you can make the reviewer's lifeeasier, that's tremendous and helpful.
Now, once you have threatanalysis developed, what other
things do you need to consider?
Becky Ditty (13:19):
So after your threat analysis, you'll have to do your
cyber security risk assessment.
And this is, as I was talking aboutbefore, a security risk assessment
is different than your safety riskassessment, but it's similar in how
it's presented in a table, typically.
You'll want to follow a commonlyacceptable cybersecurity
(13:42):
risk analysis method.
One such method is CVSS.
This takes a lot of information fromthe threat model and puts it into
a risk table and then assigns riskscores to the various vulnerability
and threats, and identifies explicitlyhow each threat is mitigated.
Unlike safety risks, cybersecurityrisks are evaluated using a non
(14:07):
probabilistic approach because it isnot possible to assess and quantify
the likelihood of an incident occurringbased on historical data or modeling.
Note, any cybersecurity risks that involvepatient harm also need to be assessed
in your safety risk management process.
(14:27):
Even though these are two independentprocesses, they do link together.
You want to provide a traceabilitythroughout your cybersecurity
documentation, whether it's inherentlyincluded in your documentation or
you include a traceability matrix.
And it needs to link your actualcybersecurity controls, such as software
(14:51):
requirements or labeling requirements thatare implemented in your labeling document
to the cybersecurity vulnerabilityand risks that they are mitigating.
You'll also need to develop a softwarebill of materials called an SBOM.
This is not the same document you use toaddress all the requirements from the FDA
(15:16):
Off the Shelf Software Guidance Document,which is a separate guidance document we
are not talking about in this discussion.
But it is so important to note that theSBOM and the documentation to address
the off the shelf software guidancedocument are two different documents.
(15:38):
Many people try and combine thisinformation, but that is not the
appropriate way to approach this.
The off the shelf software guidancedocument requires detailed information
about your off the shelf softwarecomponents, how they're integrated
into your device, how you managethem, what a user needs to know about
(15:59):
them, and how you tell them thatinformation, and how you test the
off the shelf software, and so on.
An SBOM, on the other hand, is ultimatelypart of your labeling to the user.
It tells them what software the device isusing, including off the shelf software,
and a few details about it to help thembetter manage their cyber security.
(16:25):
It should follow anindustry recognized format.
Well, the documentation you puttogether for the off the shelf
software guidance may include someof the details needed for the SBOM.
An SBOM should be a separate document.
I can't say that enough.
And it should be part of your labeling.
(16:47):
Per the pre market cybersecurity guidance,manufacturers should provide machine
readable SBOMs consistent with the minimumelements, also referred to as baseline
attributes, identified in the October2021 National Telecommunications and
(17:08):
Information Administration Multitaskholderprocess on software component
transparency document framing softwarecomponent transparency, establishing
a common software bill of materials.
I know that is a mouthful and again, thiswill be provided-- a link to this will
(17:29):
be provided in the show notes In additionto the minimal elements identified by
what we call NTIA, for each softwarecomponent contained within the SBOM
manufacturers should include in the premarket submission the software level of
support provided through monitoring andmaintenance from the software component
(17:50):
manufacturer, such as the softwareis actively maintained, no longer
maintained, abandoned, and the softwarecomponent's end of life support date.
You also want to provide FDAinformation on how you keep the
device malware free from the beginningof development through shipping.
(18:12):
You need to document your planto ensure the medical device
is shipped without malware.
Describe the controls that are in placeto assure the FDA that the medical device
software will remain free from malware.
Start from the beginning.
Of when you write the code throughmanufacturing and putting the software on
(18:32):
the device and shipping the device out.
Be specific.
Don't just say you use tools.
Identify the tools you use.
Identify how you provide and removeaccess to different team members
in which team members get access.
If the software is downloaded by the user,make sure to discuss where the software
(18:55):
is housed for them to access the downloadand how you verify the software has
been downloaded and installed correctly.
Again, be specific.
You also need to make sure yourlabeling addresses cybersecurity,
as we talked about before.
Document the labelingassociated with cybersecurity.
(19:16):
This will include device instructions foruse and product specifications related
to recommended cybersecurity controlsappropriate for the intended user.
You'll also need to includea vulnerability analysis.
So think about your off-the-shelfsoftware components, and review
(19:37):
their known vulnerabilities.
In the submission,
you need to provide a safety andsecurity risk assessment of each
known vulnerability, including deviceand system impacts and details of
the applicable safety and securityrisk controls that you've implemented
to address these vulnerabilities.
(19:58):
If the risk controls include compensatingcontrols, which are measures taken
to address any weakness of existingcontrols, or to compensate for the
ability, inability to meet specificsecurity requirements due to various
different constraints, these compensationcontrols should be described in
an appropriate level of detail.
(20:19):
Again, some of this may be tellinga user they need to use a firewall,
or additional steps a user mayneed to take, such as locking their
phone or turning off Bluetoothwhen not using the device at home.
These would be things that theyare doing on their end to provide
(20:42):
additional security because on thedevelopment side, those are things
you can't develop into the device.
James C Taylor (20:50):
Right, right.
All right.
So a manufacturer doesall of this to this point.
What kind of testing is needed?
Becky Ditty (21:01):
So a.
Important piece of this ispenetration testing, where you're
trying to break into the device.
There's also vulnerability analysisand testing, which we discussed above.
Static analysis and then evidence ofsecurity effectiveness of third party
off the shelf software in the system.
(21:22):
And it's important to note thatwhen doing the penetration testing
I mentioned, FDA wants to see thatit's tested by individuals who
are not familiar with the device.
If your company is large, you may haveindependent departments such as an
independent test lab or cybersecuritytest team who performs this.
(21:45):
Or if you are a small company or don'thave Independent departments who are
not involved with the developmentof the device, then you may want
to have an independent test labperform this penetration testing.
DonnaBea Tillman (22:00):
Yes, and I, in addition to the penetration testing
and the, and the vulnerability testingthat Becky's talking about, which is
typically done as part of your designcontrol process in the pre market setting
FDA is also interested making surethat you've got testing that addresses
what's happening with your device.
Once it's out on the market in thepost market setting, and this has
(22:23):
to do with how you respond to cybersecurity threats and incidents.
One of the questions that we havebeen recently seeing FDA ask fairly
commonly is that they want to knowwhat testing or information you have
showing that your methods and yourplans for post market cyber security
(22:43):
incident management are sufficient.
And so it's not uncommonto see them ask that.
And we are generally recommending thatpeople at least provide some basic
information about what they've done.
to validate their post marketincidence response plans in
their pre market submissions.
Becky Ditty (23:01):
And those post market incident response plans are part of
your plan for continuing support.
And it is a requirement that youdocument your plan for continuing
to keep the medical devicesecure once it is on the market.
You want to make sure that planidentifies how frequently you
reperform cyber security testing.
(23:23):
It's not you do penetrationtesting once and you're done.
You will continue to do itsporadically throughout the life of
your product as the cyber securityenvironment is always changing and
new threats are always emerging.
You should summarize plans for validatingsoftware updates and patches that may
(23:45):
be needed throughout the life cycle ofthe medical device to continue to secure
the device from cyber security threatsto assure safety and effectiveness.
And you will also identify howyou will respond to incidents and
communicate with the customers.
This is where the post marketcyber security guidance is really
(24:07):
helpful as it identifies itemsyou want to include in that plan.
Additionally, Section V6 of the Pre MarketCybersecurity Guidance document addresses
other total product lifecycle securityrisk management components to consider,
such as demonstrate effectivenessof a manufacturer's security process
(24:29):
and potential metrics you'll want toconsider while evaluating your, the
effectiveness of your security process.
That's a lot of information.
James C Taylor (24:41):
Yeah.
Yeah.
But, but that, that's the wonderfulthing about you two is that you
can help people with that andthey can get in touch with you.
But before we give them the means to getin touch with you, why don't you just
summarize what we've been talking about?
Becky Ditty (24:58):
It's important to make sure you think of
cybersecurity early and often.
It isn't something that youaddress once and then it's done.
You also want to make sureyou are familiar with FDA's
cybersecurity guidances.
They have a lot of information in thereand they also give you a lot of examples.
They can be very helpful.
The cybersecurity environment and securityrequirements are always changing, so
(25:23):
it's important to stay up to date.
You'll also want to be familiar withthe cybersecurity related elements
in eSTAR, which is the pre marketsubmission document you need to complete.
And watch for eSTAR updates.
It is likely FDA will update theeSTAR soon based on the new pre
(25:45):
market cybersecurity guidance.
The cybersecurity risk managementprocess that we have been discussing
today includes documents such asyour cybersecurity threat model
and risk analysis and associatedcomponents, traceability, cybersecurity
labeling, vulnerability analysis,
(26:05):
testing, SBOM, information on how youkeep the device malware free from the
beginning of development through shipping,and a plan for continued support.
These may not be the onlyelements you need, but they
are some of the main elements.
We hope the information we providedyou gives you a good start to dealing
(26:26):
with cybersecurity in your device.
James C Taylor (26:30):
Thank you, Becky and Donna Bea for coming on the show as
Becky and Donna Bea have said a lotof these documents that they have
referred to will be linked to in ourshow notes so you can consult them.
But if you want to have someone tohelp guide you through this process,
you can also literally consult
Becky and Donna B and you cancontact them or me for that matter
(26:54):
at insight@biologicsconsulting.com.
That's insight at biologicsconsulting, all one word, dot com.
And also we'd love it if you'd likesubscribe to rate and review our show.
The executive producer of Insightat Biologics is Kris Kraihanzel.
This episode was producedand edited by James C.
Taylor and the technicalsupervisor is Jeff Wease.
(27:16):
The Insight at Biologicstheme is by Tom Rory Parsons.
I am James C.
Taylor.
Thank you for joining us and pleasecome back for more Insight at Biologics.
Cyber security is important, particularly when it
comes to medical devices and theFDA has clear expectations of cyber
security for pre market submissions.
What do they want andhow can you get it done?
We'll find out with BeckyDiddy and Donna B Tillman.
I'm James C.
Taylor and this is Insight at biologics.
(00:28):
And here with me now are Becky andDonna Bea and ladies, why don't
you tell people about yourselves?
Becky Ditty (00:34):
Hi, I'm Becky Ditty.
I am a medical device regulatoryconsultant at Biologics Consulting.
I have been in the industry for 20 years.
And in that whole time, I'vebeen doing regulatory work.
My specialty is focusing on premarket submissions, and a lot of
(00:54):
those submissions include software.
DonnaBea Tillman (00:57):
And I am Donna Bea Tillman.
I am a biomedical engineer,and I was at FDA for 17 years,
and I've been here at BiologicsConsulting for the past 12 years.
Like Becky, I am a medical device, aregulatory consultant, and I work with
many clients on software enabled devices.
James C Taylor (01:20):
Well, I thank you both for being a part of this podcast and
speaking of this podcast, Becky,why don't you frame for everybody
what we are and maybe even whatwe aren't going to talk about?
Becky Ditty (01:33):
The purpose of this podcast is to provide an
introduction to FDA's cybersecurityexpectations for medical devices.
especially as it relates tothe information needed to
support a pre market submission.
The intent is not to have a discussionabout specific cybersecurity
techniques or mitigations, and itisn't intended to cover every aspect
(01:57):
of FDA's cybersecurity Guidances.
This is an introductionto FDA's expectations.
James C Taylor (02:06):
Okay.
All right.
So with that said, where would yourecommend a medical device developer to
start when it comes to cybersecurity?
Becky Ditty (02:15):
The first place to start is to become familiar with FDA's guidance
documents as they relate to cybersecurity.
These guidance documents includecybersecurity and medical devices.
Quality system considerations andcontent of pre market submission.
This will be referred to as thePremarket Cybersecurity Guidance.
(02:38):
There's also the post marketmanagement of cybersecurity and medical
devices, guidance for industry andFood and Drug Administration staff.
And this will be referredto as the Postmarket
Cybersecurity Guidance Document.
There's also the Cybersecurity andMedical Devices Refuse to Accept
Policy for Cyber Devices and RelatedSystems under Section 524B of the
(03:05):
FD& C Act, Guidance for Industry andFood and Drug Administration Staff.
And this relates to therequirements per the Consolidated
Appropriations Act of 2023.
And finally, there's the Cybersecurityfor Networked Medical Devices
Containing Off the Shelf Software.
(03:26):
In the show notes, you will find linksto these guidances and other documents
I referenced throughout this discussion.
One other important aspect is that youreally need to have a cybersecurity
expert on the team or actively workingwith an external cybersecurity expert.
Gone are the days when you can justtry and throw something together to
(03:48):
address FDA's cybersecurity needs,
recommendations.
James C Taylor (03:51):
No flying by the seat of your pants.
Becky Ditty (03:55):
No, no, they, they really dig in.
James C Taylor (03:59):
All right.
So now once you have your cybersecurityguidance documents, what's next?
What kind of designdocumentation is needed?
Becky Ditty (04:08):
First, you want to start early
to be secure from the get go.
You don't want to address cybersecurityat the end of design development.
It should not be an afterthought.
You want to include cybersecuritymitigations into the device from
the onset, as it can be harder toadd in mitigations after the fact.
(04:31):
It also helps you provide amore secure device by designing
security in from the beginning.
You'll want to start withdoing a threat analysis.
And you want to make sure to followan industry recognized method.
DonnaBea Tillman (04:45):
Yes, and in terms of the industry recognized methods, one of
the questions we get a lot is, is therea particular method that FDA requires
medical device companies to follow?
And the short answer is no.
FDA doesn't require anyparticular methodology.
But they do require that you actuallypick a formal methodology to follow.
(05:08):
Some of the common methodologiesthat we see medical device
companies use are stride, attacktrees, kill chain, and dread.
So as long as you pick a wellestablished methodology and follow it,
you generally should be okay with FDA.
Becky Ditty (05:24):
And doing a threat analysis is part of your cybersecurity
risk management process as a whole.
And it's important to note that performinga security risk management is distinct
from performing safety risk management.
As identified in the premarketcybersecurity guidance document,
(05:46):
safety risk management focuses onphysical injury, damage to property
or the environment, or delayand or denial of care due to the
device or system unavailability.
Security risk management, on the otherhand, includes risks that can result.
indirectly or directly to patient harm.
(06:07):
Additionally, risks that areoutside of FDA's assessment of
safety and effectiveness, suchas those related to business or
reputational risks, may also exist.
FDA recommends generating asecurity risk management plan,
a security risk management report,and a company documentation.
(06:28):
This is detailed in section VA of thePremarket Cybersecurity Guidance Document.
When doing a threat analysis, youwant to first begin with the story.
Discuss the general architecture andcybersecurity architecture first to
help the reviewers understand thecybersecurity framework of the system.
(06:51):
In the architecture discussion,be sure to point out software
controls and hardware controls.
You are going to be using this threatmodel as a tool to help you identify where
your risks are, how your design currentlymitigates cybersecurity risks, and
(07:11):
where additional mitigations are needed.
Have you built into the softwaremethods to identify an incident that
took place or one was attempted?
Do you have audit logs to helpidentify who is taking which actions?
We will talk aboutmitigations more in a minute.
You may also want to refer to the Playbookfor Threat Modeling Medical Devices.
(07:37):
As an educational resource that wasdeveloped by MITRE and discusses best
practices for understanding basic threatmodeling concepts and processes and
how to apply them to medical devices.
FDA commonly references this resource.
So in your threat model, you'll alsowant to talk about the vulnerabilities
(08:02):
and threats and mitigations.
Make sure you're thinking big.
There are obvious risks, but be sureto capture risks introduced through,
for example, the supply chain, suchas risk introduced through off the
shelf software, risk introduced throughmanufacturing, you know, how are
(08:23):
your systems secure, interoperabilitywith other devices, and so forth.
So make sure not just tothink about the obvious risks.
but go outside the box.
And then I recommend classifyingmitigations into the grouping
FDA has in their CybersecurityPremarket Draft Guidance.
(08:46):
That includes authentication,authorization, cryptography, code
data and execution integrity,confidentiality, Event detection and
logging, resiliency and recovery,updatable, updatability, and patchability.
(09:08):
FDA often focuses deficiency questionsbased on mitigation classification types.
So grouping mitigations by type, one,helps make sure you have thought through
all types of mitigations, and two, makesit easier for the reviewer to access and
understand your cybersecurity controls.
(09:29):
Mitigations are not just abouthow the system is designed, but
the processes and procedures acompany has in place to identify and
respond to cybersecurity incidences.
How are you monitoring thecybersecurity environment and
your device vulnerabilities?
or newly identified vulnerabilitiesof any off the shelf software?
(09:53):
Do you have communication pathwaysin place to notify users of new
cybersecurity weaknesses or events?
Do you provide users with the propercybersecurity information in the labeling?
A few of these examples are:
Including cyber security best practices.
Don't leave the computeror mobile device unlocked.
(10:15):
Use antivirus software, firewalls.
Don't write down passwords,
etc.
This may seem like commonknowledge, but it is a...
good practice to communicate it tousers, just like all those pharmaceutical
commercials where they tell you not totake the drug if you are allergic to it.
By now you would think most peoplewould know this, but FDA thinks it is
(10:39):
important enough to bear repeating.
Same with cybersecurity best practices.
If applicable, make sure you're labelingprovides a description of systematic
procedures for users to downloadversion identifiable software and
firmware, including how a user willknow when the software is available.
(11:00):
Provide technical instructions topermit secure network development and
servicing, and instructions for userson how to respond upon detection of a
cybersecurity vulnerability or incident.
These are just some examplesof what to include in labeling.
This does not cover everything you need.
DonnaBea Tillman (11:20):
So that's a lot of really great information, Becky.
There is a lot to consider, itsounds like, when thinking about
cybersecurity risk management.
A lot of things that companies need to do.
And I also think it's also importantwhile you're doing this to not only
think about what you need to be doing aspart of your quality management system,
(11:41):
But to also be thinking about how thisinformation is ultimately going to be
reviewed in a premarket submission.
FDA is moving more and more towardssmart templates, things like the E
STAR that is now required for 510ksubmissions that require you to provide
information in a more structured manner.
(12:02):
And so it's important that you arewell aware of these smart templates
that FDA has implemented and thatwhen you prepare your premarket
submission, your 510k, or your denovo, that you make it easy for FDA to
find the information that they need.
You need to provide all of these,this information that is required,
(12:23):
but you can't just dump a wholebunch of documents on FDA and expect
them to find their way through it.
It is important with cybersecurity asit is with really any part of anything
you're going to give to FDA, to makesure that you tell the story around your
cyber security process, and that youhold FDA's hand and explain what you've
(12:44):
done and how it supports your device.
So, I think, you know, as Beckycontinues to talk about these items,
and what is needed based on the guidancedocuments, it's also important to
think about how you're going to bepresenting it to FDA in a way that
makes it easy for them to do their job.
James C Taylor (13:00):
Right.
Right.
Reviewers don't have a lot of timewith anything that's submitted.
And so if you can make the reviewer's lifeeasier, that's tremendous and helpful.
Now, once you have threatanalysis developed, what other
things do you need to consider?
Becky Ditty (13:19):
So after your threat analysis, you'll have to do your
cyber security risk assessment.
And this is, as I was talking aboutbefore, a security risk assessment
is different than your safety riskassessment, but it's similar in how
it's presented in a table, typically.
You'll want to follow a commonlyacceptable cybersecurity
(13:42):
risk analysis method.
One such method is CVSS.
This takes a lot of information fromthe threat model and puts it into
a risk table and then assigns riskscores to the various vulnerability
and threats, and identifies explicitlyhow each threat is mitigated.
Unlike safety risks, cybersecurityrisks are evaluated using a non
(14:07):
probabilistic approach because it isnot possible to assess and quantify
the likelihood of an incident occurringbased on historical data or modeling.
Note, any cybersecurity risks that involvepatient harm also need to be assessed
in your safety risk management process.
(14:27):
Even though these are two independentprocesses, they do link together.
You want to provide a traceabilitythroughout your cybersecurity
documentation, whether it's inherentlyincluded in your documentation or
you include a traceability matrix.
And it needs to link your actualcybersecurity controls, such as software
(14:51):
requirements or labeling requirements thatare implemented in your labeling document
to the cybersecurity vulnerabilityand risks that they are mitigating.
You'll also need to develop a softwarebill of materials called an SBOM.
This is not the same document you use toaddress all the requirements from the FDA
(15:16):
Off the Shelf Software Guidance Document,which is a separate guidance document we
are not talking about in this discussion.
But it is so important to note that theSBOM and the documentation to address
the off the shelf software guidancedocument are two different documents.
(15:38):
Many people try and combine thisinformation, but that is not the
appropriate way to approach this.
The off the shelf software guidancedocument requires detailed information
about your off the shelf softwarecomponents, how they're integrated
into your device, how you managethem, what a user needs to know about
(15:59):
them, and how you tell them thatinformation, and how you test the
off the shelf software, and so on.
An SBOM, on the other hand, is ultimatelypart of your labeling to the user.
It tells them what software the device isusing, including off the shelf software,
and a few details about it to help thembetter manage their cyber security.
(16:25):
It should follow anindustry recognized format.
Well, the documentation you puttogether for the off the shelf
software guidance may include someof the details needed for the SBOM.
An SBOM should be a separate document.
I can't say that enough.
And it should be part of your labeling.
(16:47):
Per the pre market cybersecurity guidance,manufacturers should provide machine
readable SBOMs consistent with the minimumelements, also referred to as baseline
attributes, identified in the October2021 National Telecommunications and
(17:08):
Information Administration Multitaskholderprocess on software component
transparency document framing softwarecomponent transparency, establishing
a common software bill of materials.
I know that is a mouthful and again, thiswill be provided-- a link to this will
(17:29):
be provided in the show notes In additionto the minimal elements identified by
what we call NTIA, for each softwarecomponent contained within the SBOM
manufacturers should include in the premarket submission the software level of
support provided through monitoring andmaintenance from the software component
(17:50):
manufacturer, such as the softwareis actively maintained, no longer
maintained, abandoned, and the softwarecomponent's end of life support date.
You also want to provide FDAinformation on how you keep the
device malware free from the beginningof development through shipping.
(18:12):
You need to document your planto ensure the medical device
is shipped without malware.
Describe the controls that are in placeto assure the FDA that the medical device
software will remain free from malware.
Start from the beginning.
Of when you write the code throughmanufacturing and putting the software on
(18:32):
the device and shipping the device out.
Be specific.
Don't just say you use tools.
Identify the tools you use.
Identify how you provide and removeaccess to different team members
in which team members get access.
If the software is downloaded by the user,make sure to discuss where the software
(18:55):
is housed for them to access the downloadand how you verify the software has
been downloaded and installed correctly.
Again, be specific.
You also need to make sure yourlabeling addresses cybersecurity,
as we talked about before.
Document the labelingassociated with cybersecurity.
(19:16):
This will include device instructions foruse and product specifications related
to recommended cybersecurity controlsappropriate for the intended user.
You'll also need to includea vulnerability analysis.
So think about your off-the-shelfsoftware components, and review
(19:37):
their known vulnerabilities.
In the submission,
you need to provide a safety andsecurity risk assessment of each
known vulnerability, including deviceand system impacts and details of
the applicable safety and securityrisk controls that you've implemented
to address these vulnerabilities.
(19:58):
If the risk controls include compensatingcontrols, which are measures taken
to address any weakness of existingcontrols, or to compensate for the
ability, inability to meet specificsecurity requirements due to various
different constraints, these compensationcontrols should be described in
an appropriate level of detail.
(20:19):
Again, some of this may be tellinga user they need to use a firewall,
or additional steps a user mayneed to take, such as locking their
phone or turning off Bluetoothwhen not using the device at home.
These would be things that theyare doing on their end to provide
(20:42):
additional security because on thedevelopment side, those are things
you can't develop into the device.
James C Taylor (20:50):
Right, right.
All right.
So a manufacturer doesall of this to this point.
What kind of testing is needed?
Becky Ditty (21:01):
So a.
Important piece of this ispenetration testing, where you're
trying to break into the device.
There's also vulnerability analysisand testing, which we discussed above.
Static analysis and then evidence ofsecurity effectiveness of third party
off the shelf software in the system.
(21:22):
And it's important to note thatwhen doing the penetration testing
I mentioned, FDA wants to see thatit's tested by individuals who
are not familiar with the device.
If your company is large, you may haveindependent departments such as an
independent test lab or cybersecuritytest team who performs this.
(21:45):
Or if you are a small company or don'thave Independent departments who are
not involved with the developmentof the device, then you may want
to have an independent test labperform this penetration testing.
DonnaBea Tillman (22:00):
Yes, and I, in addition to the penetration testing
and the, and the vulnerability testingthat Becky's talking about, which is
typically done as part of your designcontrol process in the pre market setting
FDA is also interested making surethat you've got testing that addresses
what's happening with your device.
Once it's out on the market in thepost market setting, and this has
(22:23):
to do with how you respond to cybersecurity threats and incidents.
One of the questions that we havebeen recently seeing FDA ask fairly
commonly is that they want to knowwhat testing or information you have
showing that your methods and yourplans for post market cyber security
(22:43):
incident management are sufficient.
And so it's not uncommonto see them ask that.
And we are generally recommending thatpeople at least provide some basic
information about what they've done.
to validate their post marketincidence response plans in
their pre market submissions.
Becky Ditty (23:01):
And those post market incident response plans are part of
your plan for continuing support.
And it is a requirement that youdocument your plan for continuing
to keep the medical devicesecure once it is on the market.
You want to make sure that planidentifies how frequently you
reperform cyber security testing.
(23:23):
It's not you do penetrationtesting once and you're done.
You will continue to do itsporadically throughout the life of
your product as the cyber securityenvironment is always changing and
new threats are always emerging.
You should summarize plans for validatingsoftware updates and patches that may
(23:45):
be needed throughout the life cycle ofthe medical device to continue to secure
the device from cyber security threatsto assure safety and effectiveness.
And you will also identify howyou will respond to incidents and
communicate with the customers.
This is where the post marketcyber security guidance is really
(24:07):
helpful as it identifies itemsyou want to include in that plan.
Additionally, Section V6 of the Pre MarketCybersecurity Guidance document addresses
other total product lifecycle securityrisk management components to consider,
such as demonstrate effectivenessof a manufacturer's security process
(24:29):
and potential metrics you'll want toconsider while evaluating your, the
effectiveness of your security process.
That's a lot of information.
James C Taylor (24:41):
Yeah.
Yeah.
But, but that, that's the wonderfulthing about you two is that you
can help people with that andthey can get in touch with you.
But before we give them the means to getin touch with you, why don't you just
summarize what we've been talking about?
Becky Ditty (24:58):
It's important to make sure you think of
cybersecurity early and often.
It isn't something that youaddress once and then it's done.
You also want to make sureyou are familiar with FDA's
cybersecurity guidances.
They have a lot of information in thereand they also give you a lot of examples.
They can be very helpful.
The cybersecurity environment and securityrequirements are always changing, so
(25:23):
it's important to stay up to date.
You'll also want to be familiar withthe cybersecurity related elements
in eSTAR, which is the pre marketsubmission document you need to complete.
And watch for eSTAR updates.
It is likely FDA will update theeSTAR soon based on the new pre
(25:45):
market cybersecurity guidance.
The cybersecurity risk managementprocess that we have been discussing
today includes documents such asyour cybersecurity threat model
and risk analysis and associatedcomponents, traceability, cybersecurity
labeling, vulnerability analysis,
(26:05):
testing, SBOM, information on how youkeep the device malware free from the
beginning of development through shipping,and a plan for continued support.
These may not be the onlyelements you need, but they
are some of the main elements.
We hope the information we providedyou gives you a good start to dealing
(26:26):
with cybersecurity in your device.
James C Taylor (26:30):
Thank you, Becky and Donna Bea for coming on the show as
Becky and Donna Bea have said a lotof these documents that they have
referred to will be linked to in ourshow notes so you can consult them.
But if you want to have someone tohelp guide you through this process,
you can also literally consult
Becky and Donna B and you cancontact them or me for that matter
(26:54):
at insight@biologicsconsulting.com.
That's insight at biologicsconsulting, all one word, dot com.
And also we'd love it if you'd likesubscribe to rate and review our show.
The executive producer of Insightat Biologics is Kris Kraihanzel.
This episode was producedand edited by James C.
Taylor and the technicalsupervisor is Jeff Wease.
(27:16):
The Insight at Biologicstheme is by Tom Rory Parsons.
I am James C.
Taylor.
Thank you for joining us and pleasecome back for more Insight at Biologics.
Popular Podcasts
1. Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
2. Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations.
3. Crime Junkie
If you can never get enough true crime... Congratulations, you’ve found your people.