We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Ethics Village - Coffee Talk

00:00

Formal Metadata

Title
Ethics Village - Coffee Talk
Title of Series
Number of Parts
335
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Presentations from the DEF CON 27 Ethics Village
Right angleInformation securityAreaBitCASE <Informatik>SurgeryQuicksortWave packetNeuroinformatikIterationDecimalExistenceProcess (computing)Lecture/ConferenceMeeting/Interview
Term (mathematics)Dependent and independent variablesPerspective (visual)BitMultiplication signUniverse (mathematics)AreaCartesian coordinate systemHazard (2005 film)Product (business)Type theoryDifferent (Kate Ryan album)MereologyOrder (biology)Process (computing)Field (computer science)Denial-of-service attackFrequencyOffice suiteEvent horizonRegulator geneInformation securityTheory of relativityPerformance appraisalConnected spaceService (economics)Thread (computing)Software frameworkPersonal digital assistantIntegrated development environmentMatching (graph theory)Lecture/ConferenceMeeting/Interview
Motion captureCartesian coordinate systemArithmetic meanDecision theoryPattern recognitionCycle (graph theory)TelecommunicationOrder (biology)Physical systemDifferent (Kate Ryan album)Total S.A.Group actionVulnerability (computing)Product (business)Video gameFunctional (mathematics)Dependent and independent variablesMultiplication signHazard (2005 film)Modal logicOffice suiteStaff (military)1 (number)MereologyTerm (mathematics)Information securitySoftwareExpert systemEntire functionCybersexGoodness of fitProcess (computing)SpacetimeView (database)Type theoryFile archiverEquivalence relationImage resolutionSystem administratorNational Institute of Standards and TechnologyOperator (mathematics)Software frameworkHacker (term)AreaSound effectLecture/ConferenceMeeting/Interview
Vulnerability (computing)Self-organizationFrame problemExpected valueBitAreaType theoryDependent and independent variablesHacker (term)Vertex (graph theory)Physical systemInformation securitySpacetimeMultiplication signWeb crawlerSoftwareValidity (statistics)Order (biology)Group actionElement (mathematics)Point (geometry)MereologyDifferent (Kate Ryan album)Table (information)System callRight angleData managementUniverse (mathematics)Software frameworkOpen setFrequencyExpert systemOnline helpLecture/Conference
TelecommunicationGroup actionVulnerability (computing)Type theoryMereologyDiscrete groupSystem administratorGame controllerOrder (biology)InformationMeasurementShared memoryProcess (computing)Capability Maturity ModelMathematical analysisSelf-organizationVector potentialExpected valueEntire functionInformation securityMultiplication signResultantValidity (statistics)Context awarenessArithmetic meanCondition numberNumberNatural numberCASE <Informatik>Event horizonComplex (psychology)Lecture/ConferenceMeeting/Interview
Entire functionPhase transitionSheaf (mathematics)Control flowExpert systemLevel (video gaming)Perspective (visual)Vulnerability (computing)Spring (hydrology)Group actionInformation securityTable (information)Flow separationReal-time operating systemPlanningExpected valueContinuum hypothesisType theoryDifferent (Kate Ryan album)Process (computing)BitMereologyAreaEndliche ModelltheorieSystem callHidden Markov modelSimulationFrame problemSet (mathematics)CASE <Informatik>WritingCybersexMathematical analysisWhiteboardExistenceSpacetimeMultiplication signPoint (geometry)Lecture/ConferenceMeeting/Interview
AreaPattern recognitionMultiplication signSoftwareFunctional (mathematics)Maxima and minimaExpected valueConnectivity (graph theory)Product (business)Endliche ModelltheorieGroup actionDirection (geometry)MereologyVulnerability (computing)Element (mathematics)Process (computing)AuthorizationMoment (mathematics)Computer clusterTerm (mathematics)Artificial neural networkMathematicsNumberWhiteboardSelf-organizationTotal S.A.ArmMaterialization (paranormal)DampingInclusion mapCASE <Informatik>Physical systemComputer hardwarePerspective (visual)CybersexInformation securityMeasurementEntire functionLecture/ConferenceMeeting/Interview
MereologyProcess (computing)PhysicalismMusical ensembleDifferent (Kate Ryan album)Point (geometry)Information privacySelf-organizationInformation securityFinite differenceVulnerability (computing)CoroutineAuthorizationPattern recognitionPatch (Unix)Functional (mathematics)Regulator geneComputer hardwareSound effectMathematicsCategory of beingInformationPerspective (visual)Game controllerDivision (mathematics)Physical systemHazard (2005 film)Address spaceLecture/ConferenceMeeting/Interview
Vulnerability (computing)Multiplication signUniverse (mathematics)Different (Kate Ryan album)Drag (physics)Physical systemCybersexScaling (geometry)Business modelOrder (biology)Computer configurationLecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
Thank you all for being here. I'm Andrea Matusian. I'm a professor at Penn State. And it is my distinct pleasure to share the next hour with Dr. Suzanne Schwartz of the FDA. And I realize I owe Anthony Ferrante a mug,
because this is a right to promise everyone. So there is a de minimis mug that shall be yours. Maybe when Q&A starts, I'll produce the mug. Like habeas corpus, oh my habeas smugus. I don't know, whatever. Anyway, so today we'll discuss with Suzanne some of the current FDA approaches to security
and learn a little bit about where we see things going in with respect to medical devices and security. But first I'd love to start with just asking Suzanne, how did you become interested in security? You weren't born doing your role.
You arrived in your role. So tell us a little bit about sort of your history and how you went from prior iterations of self to your current job and your deep engagement with this area. And I will say, without a citation,
the FDA is probably the most active agency right now in security, and kudos to the agency on that. And you're looking at one of the main reasons for the FDA's deep interest and forward-looking approach in security. So I'd love to hear the story of how you became yourself.
Thank you. And I have to say that, no, I wasn't born into security. I think when I was born, computer security actually didn't exist. I'm dating myself here. In any case, I'm a physician, and my background in training actually clinically is in the area of surgery, general surgery,
specifically burn injuries and trauma, which is far afield from the area of cybersecurity. I've done a lot of work as both an academic, what's called a surgeon scientist. I spent quite a bit of time actually within an academic clinical center in New York City, Weill Cornell Medical Center,
which is part of kind of the New York Presbyterian complex, doing both burn-related and general wound repair-related clinical care and research. And one thing I would say just about myself is the desire to pursue research and innovation
and looking at new approaches, new technologies that can further benefit patients. And that's a common thread really throughout my entire career. Aside from the work that I had done on the clinical side
in the hospital setting, I've also been on the industry side. Before coming to the FDA, I worked in the private sector as a medical director of a startup company, a startup that was involved in actually producing and testing a tissue engineered skin, skin for burn injuries and wound repair.
And it was just kind of over the next few years, this kind of realization that for me, being able to straddle multiple sectors of the universe, the research and science side and technology and understanding of the clinical needs, a desire to see technologies get to the bedside.
And in that role as a medical director, I did a lot of interfacing with the FDA in order to get clinical trials through and to be part of putting applications together. So there's a certain nexus there that for me was very appealing in terms of pursuit
of what can I do to be more impactful? What can I do from a more general, broader public health perspective in seeing patients get new therapies? And so fast forward a bit, in 2010, I came to the FDA in a role
that's called the Commissioner's Fellowship. It's actually unfortunately been phased out or it's in the process of being rebirthed as something a little bit different. But the idea of a FDA Commissioner's Fellow, we came in as a cohort, were to really bring in individuals with varying subject matter expertise
in different disciplines that may be lacking at the agency. And by bringing in individuals with different subject matter expertise, certainly that benefits the agency by helping us with some of these newer, more advanced methodologies and technologies to help in review of those and an assessment of those.
And at the same time, the fellowship would enable the individual to be exposed to the regulatory framework and what's happening with the FDA. So whether that individual then ends up going back out to the private sector and acting or serving
as an ambassador to the environment in which they're gonna work, where they understand how regulation in the medical product area works, that's one benefit. The other benefit is for those individuals where it was determined to be a really mutually beneficial match.
So for myself, I was very excited about the work that I was assigned at the FDA when I came as a Commissioner's Fellow and I saw a huge opportunity to have impact. Very, very challenging and novel emerging areas
and an opportunity to learn more and be that continuous constant learner, which is something also that's important to me in whatever I do. So that at the end of every day, I feel, wow, I've learned something new or been challenged with something different and tomorrow's a new day and who knows what that's going to bring.
In my journey at the FDA, although I came in as a Commissioner's Fellow and then because I'm a physician, that translates to being a medical officer, because I was also representing a field that was a very unique field that you don't have that many surgeons around that are burn surgeons.
It is a small field, but there were connections to the area of national security and hall hazards types of response. And this was a time period that the FDA was embarking on a medical countermeasures initiative as part of the nation being better prepared
to deal with all different types of hazards. And the FDA's role in that is in the regulation, the review, regulation, evaluation of what are called medical countermeasures for biologics, for chemical, for rad nuc related types of events. Because of my burn background,
I was brought in to this effort and introduced to it on the rad nuc side because of the burn injury nexus. But this opened up a whole new vista for me, as far as the ability to kind of work across agencies, work across other parts of government and exposed me to areas or fields and disciplines
that were really outside of what I trained in. And I found it fascinating. I found that really being able to work across different parts of government, whether it's within the Department of Health and Human Services with their Assistant Secretary of Preparedness
and Response and CDC and BARDA, whether it's with DOD assets, whether it was with other, again, other parts of the government, Department of Homeland Security, this to me was extremely exciting and intriguing because I felt that we have not only important role
to play and that there is a value that we can add here in a manner that hadn't been really quite captured. For me, this was more fascinating than simply doing reviews of pre-market applications or submissions, although I enjoyed seeing that
and being closely involved in seeing or being directly responsible for new technologies coming on the market. This was just a more 100,000 foot, 200,000 foot view of what's happening within the entire kind of healthcare and public health, critical infrastructure
is what we call it. One of the 16 sectors of critical infrastructure is healthcare and public health. So when an opportunity arose for me at the center where I am, the Center for Devices and Radiological Health to assume the role of Director of Emergency Preparedness, Operations, Medical Countermeasures,
I applied for that, I got into that, and it was within that role that we were dealing with, again, all hazards types of issues, preparedness and response. And I probably was in that role for maybe no more than six months, six or eight months when we were faced with a inquiry that had come in,
actually it was essentially a delivery of a package of vulnerabilities, security vulnerabilities of medical devices that was brought forward to us by two very prominent security researchers
who worked in medical devices. And between their kind of providing this to our center, along with the communication that came separately from Department of Homeland Security's, what was called then ICS-CERT, the Industrial Control System CERT, Cyber Emergency Response Team. This was rather, this blindsided us,
I will be very honest with you because we had never dealt with that before. And we had to quickly figure out what does this actually mean? One of these, you know, bring 400 vulnerabilities to our attention across all these medical devices, we weren't certain even how to interpret that
and what does that mean as far as next steps, action taken. And it was decision made by FDA leadership at the time because this was part of a response role, a response responsibility at the time that this would reside in my shop.
Did you wanna ask something? Yeah, that was 2013. So the thought was we already had demonstrated with respect to other hazards and other public health emergencies around medical devices that were brought to our attention, good processes and capabilities
that this should also reside in our shop. But I will tell you that I had a small team, this our emergency medical countermeasures team of individuals who really had no, also like myself, no visibility on this area. Again, I'm a burn surgeon, okay, doing other things,
but certainly not a cybersecurity subject matter expert or anyone who really had any interfacing with security engineering. And what we needed to do was very quickly mobilize, mobilize a team, a mobilized working group across the center of experts that really took us
through the equivalent of the total product life cycle. So folks who were involved in terms of understanding security engineering and software pre-market, as well as post-market surveillance compliance on the policy side, we have within FDA,
surprise, surprise actually, we have an entire office of science and engineering laboratory, which is involved in what's called regulatory science research. So the researchers, the staff there who are researchers, many of them have these capabilities too. And we quickly established this working group
and by necessity worked together with DHS ICS-CERT in partnership and had to come to terms with what do these vulnerabilities mean? What are the actions that we're going to take with manufacturers and how are we gonna come to some resolution on that?
This was, again, spring, summer 2013. The timeframe is important because this was during the Obama administration in February 2013, there was an executive order that the Obama administration had issued around the notion of strengthening cybersecurity across critical infrastructure,
public and private sector working together. There was a lot of emphasis on partnership between the public and private sector. There was a lot of emphasis on also the role that NIST would have, they were mandated at that time to put together through a public private effort
a framework, a framework for cybersecurity, strengthening critical infrastructure and they were gonna convene workshops around the country. And then DHS at that time was also given several mandates through this executive order to undertake, to pull together from across government as well as through the private sector,
different work groups that were gonna be assigned different functions and so when this hit us, one of the first things that we also recognize is we need to throw ourselves in here, we need to roll up our sleeves, raise our hands to volunteer and say, this is the way that we are going to learn, this is the way that we are going to understand our landscape best and learn through doing
and partnering and collaborating. And that kind of brought us to over time, the recognition that there's traditional stakeholders in our ecosystem and then there were new non-traditional ones who we had never interacted with before, security researchers, white hat hackers,
whatever one wants to term them, our feeling was this is a community with whom we've not engaged, they don't know us, we don't know them, there's a necessity to work together, the value that hackers bring to the medical device space
is enormous and I emphasize that because medical device manufacturers have the capability of being able to design devices with safety in mind, with safety and effective performance but the notion of building security in by design was something kind of a very new and foreign concept
and here we were gonna need to really shift the culture and the way of thinking around new devices coming on the market. So we probably released the pre-market guidance draft got written and released in literally like six weeks,
that is a just something that was a miracle that like never happens but it was recognition that policy has to be, the policy needed to be in place and we subsequently finalized it over the course of the year and convened our first public workshop in 2014
around medical device cyber security and it's an interesting workshop if you were to go back and watch the webcast or listen to it or look at the archives because there are a lot of the stakeholders in the room who viewed themselves somewhat adversarially in years past.
Security researchers, manufacturers, healthcare organizations, other government agencies and the idea of this was to really foster open dialogue and to allow for the pain points that different stakeholder groups are experiencing
for them to be vocalized and to not necessarily come up with solutions, we weren't gonna have that happen in two days but we had to give voice to everyone who deserves a seat around the table and that has been a critical principle that we continue to amplify over the years
this importance of hearing from every stakeholder that's involved and recognizing the value that different stakeholder groups bring particularly because we know that cyber security
within this space as in other spaces is one of really that shared ownership or shared responsibility that we talk a lot about. So we've emphasized whole of community not just whole of government began by really reaching out to security researchers, I am the cavalry has been had a major,
major impact on the work that we've done in these years, really back from 2013, 14 to the present and I can't even kind of quantify what extraordinary benefit we've derived from that relationship that we have
with I am the cavalry and the role that they had not only in having educated us around the challenges that are faced in the hacker universe, but also an opportunity for them to help inform us with respect to policy issues
and areas in other sectors, in other industry verticals that we are able to learn from and to take those experiences and apply them within the healthcare and medical device space. Yeah. How did the approach to the post-market guidance that was really subsequently changed
from the way that the pre-market guidance was? Yeah, so very thoughtful and deliberate and intentional. So while we were kind of going through all this, we also are continuing, let's remember to get vulnerabilities brought to our attention, things just don't stop and we have to think about
what, how are we handling these vulnerabilities? How are we managing them? What are our expectations of manufacturers? Because we had already established a lot in the way of a network of friends, it's like call a friend, right? Being able to have a very broad network
of subject matter experts to help support and inform the policy approach we were going to take was very, very different than where we were a year and a half, two years prior. And so while we issued the post-market initially as draft
in early 2016, we'd been already working and socializing the concepts and a framework behind it for at least the 12 months prior. And that was critical because the way FDA works with regard to guidances, if we'll issue something
as draft, there's an open comment period, a public docket that is opened. It's generally a common period of around 90 days. Sometimes it's extended for longer than that. And then we'll look at those comments, digest them and determine in finalizing the guidance of what is appropriate, what we think is going to make for a more robust guidance, one that is implementable.
The implementable piece is also critical and that plays a very important role with the post-market guidance. So the fact that we had done all of this kind of socializing and homework in advance made it much easier to finalize this guidance. It was issued in January, 2016.
It was finalized by December, 2016 also. A very, very quick turnaround for government within a year to go from draft to final. But it's because we had already addressed a fair amount of what we thought would be feasible and what we thought would be the right approach to take.
But importantly, there were certain ambitious goals that we had set forth in the draft that the hacker community had come to us and said, based upon what's observed in other industrial control system sectors, don't think that you're gonna get that. You may wanna think about the crawl, walk, run approach.
You may wanna think about while you're really bringing industry up to speed here and raising the bar, that's done more incrementally. And some of the expectations that might've been set in the draft may have been a bit too ambitious. And we took that in mind and did further tweaking on it
and have since reissued it. I think we still have an ambitious goal there, but we're seeing that manufacturers for the most part are striving to attain that goal. The other piece of it that was important
is to build in a regulatory incentive. So that was another element of the post-market guidance that we thought was really very, very important that it'd be clearly articulated some of the differences that you have in traditional medical device related management and what our expectations were with cybersecurity
that manufacturers be far more nimble, that they accelerate the type of assessment of vulnerabilities, validating them and remediation of those vulnerabilities. And they do that in a much more accelerated timeframe than what would otherwise perhaps happen
with other types of device-related malfunctions. And so that was one of the reasons why we built in certain incentives to try to push or drive for a faster type of response, which as you can imagine in cybersecurity becomes really critical to do.
So yeah, the question was I hadn't made the distinction that in the draft guidance, we put a very, very ambitious timeframe down in the final guidance, we pulled it back a little bit. So if I'm remembering correctly,
and Seth is here as well, in the draft, I think that we had only inserted like kind of a sense of a 30-day timeframe all around for really being able to, once the vulnerability was discovered and reported to the manufacturer at being time zero, they really needed to be able to do a full assessment,
validation, determine what needs to be done in order to reduce the risk of that vulnerability and communicate it out and take that action in a 30-day timeframe. So that's pretty aggressive. What we did was we still wanted to kind of demonstrate
and really push industry to understand that what we're talking about, where security and safety are crossing over and safety issues are really critical to us here. So we offered, we provided a 30, what we call the 30, 60-day timeframe. So 30 days being from time zero again,
from when awareness of the vulnerability going through the assessment and all of that process with the expectation that manufacturer communicate by the end of 30 days around this vulnerability, what its potential impact is, and at minimum, what compensating controls or temporizing measures would be available
in order to reduce risk. And then in the following 30 days, so that would be 60 days total, that a more definitive fix would be available and for deployment and subsequent communication with that. So that was the more measured, if you will, or more modified timeframe, yeah.
So the post-market guidance comes out and there have subsequently been actions taken by the FDA, including some recalls. Can you talk to us about some of those recalls? Yes, yes. So I referenced the fact that we built in a regulatory incentive. So I need to just explain what that incentive is
to explain what the recalls are about. The regulatory incentive is to kind of drive towards a compressed timeframe. And we put in three criteria within the post-market guidance, that if you meet that timeframe, that you, and that secondly, that there have been no adverse events, no injuries or fatalities as a result of this vulnerability,
therefore it's not been exploited to the manufacturer's awareness. And the third one was, the manufacturer must be a active participant in what we call a medical device ISAO, vulnerability ISAO, information sharing analysis organization. That parenthetically, the ISAO concept
also came out of the Obama administration. It was through an executive order that ISAOs kind of formed as kind of small satellite communities where there would be information sharing across those. And we recognize the criticality of information sharing within and across industry as a means of being able to disseminate information
more rapidly around vulnerabilities that may not necessarily impact one manufacturer, but may impact many to really try to, again, institute a more proactive posture. So those were the three criteria that we described in the post-market guidance.
Manufacturer, if you meet those three criteria, then we will not enforce what's called part 806, corrections and removals, which is essentially a voluntary recall, that we would use enforcement discretion. And for a manufacturer, that would be a good thing because going through a voluntary recall process brings a lot of attention.
There's a lot of administrative stuff that goes along with that. So if there's another way to do that, which is going to accelerate a fix and alleviate for the manufacturer the need to go through this formal process, that would be good. At the same time, what's therefore implied,
actually stated within the guidance, if you're not able to meet all three criteria, and we provided examples of that in an appendix, well, then you're obligated to go through the normal part 806, corrections and removals. Then you're going through a voluntary recall process. And we recognized dealing with
a rather immature ecosystem anyway, and some very difficult challenges with some medical devices, that 60 days is likely not going to be enough for certain devices to have permanent fixes associated with them. So by nature, we knew that there are gonna continue to be recalls over time,
because it's just going to be a difficulty for manufacturers of certain types of devices to be able to not only do that full validation and assessment, but to actually be able to create an appropriate update or patch or fix that has to also be tested, right?
It's gotta be tested to make sure that it's not going to interfere with the device's safe performance. So that within 60 days may represent an impossibility in certain situations. And in those cases, a manufacturer's going to need to undergo a full part 806 with a recall.
So I can't quote you a percentage. What I would say to you is the following from anecdotal from our experiences thus far. And that is that the,
well, there are a few conditions here to talk about. Number one, the implanted, the implantable devices represent the hardest fixes. So if you wanna think about the pacemakers, the ICDs, the implanted defibrillators, neuromodulators, deep brain stimulators,
things that are implanted are going to represent a much more complex fix and deployment. So now they don't represent a huge percentage as we were looking across the entire medical device portfolio of devices that we regulate. That's not a huge chunk.
But you have that as one consideration. The other important consideration which is relevant to this discussion also is that we've seen a fair amount, particularly with these high consequence types of vulnerabilities, what can be debate or disagreement across researchers and manufacturers
or researchers, manufacturers, and government with regard to what we like to call ground truth. Is this vulnerability, first of all, real in the sense of, does this exist? Has there been an ability to validate its presence and more importantly, or by taking it a step further,
the impact of that vulnerability and the severity of that impact where its capability of introducing patient harm that we call uncontrolled risk or risk that we would consider to be not tolerable from the agency's perspective.
Not tolerable in the way it exists and therefore requires manufacturer to do something with that device to reduce that risk to an acceptable level. So when you have disagreement across parties with regard to how to assess the assessment
of that vulnerability and its impact, that already is going to prolong the timeframe out of the 60 days. So that's the other piece also that has resulted in some of the recalls that have been public. Getting to that ground truth has been a very complicated process and because it's well exceeded 60 days,
it's been months in some cases, we've had a few that have gone a year and a half or longer, that has necessitated a recall. And so now we have draft pre-market guidance as an update. Can you tell us a little bit about that draft and what the next steps will be? Yeah, yeah.
So one of the also important principles where we started out from is that with cybersecurity really rapidly evolving and knowing where we and the ecosystem were starting, we recognize that this is an area that we're gonna need to iterate on on a continuum. And then what we issued back a few years ago,
that's fine for a foundation that was appropriate as a baseline kind of setting, but given everything that we have observed, everything that we have learned and that we've experienced over the past few years, whether it's WannaCry as an example or NotPetya that was talked about earlier, whether it's vulnerabilities that have been brought to our attention by security researchers,
we recognize through those learnings that, yeah, we gotta be continuing to raise the bar and our expectations of manufacturers are that much more rigorous than they were in 2014. So 2014 sets the floor and the principles upon which we continue to build.
Did you have a question?
Yes, yes. And those are examples of where we've had this protracted phase of trying to get to ground truth around vulnerabilities where we have had to insert ourselves as part of that process, working together with the security researchers,
working with subject matter experts that are technically capable of being able to further understand exactly what the researchers have been able to demonstrate and working with the manufacturer. And that is a challenging space, one that I'll take a detour for a second
is a reason why we put forward in 2018 in the spring a medical device safety action plan for medical devices in general with an entire section on cybersecurity and we put forward a proposal there
for something that we call the SIMSAB, a Cyber Med Safety Analysis Board. And the concept behind the Cyber Med Safety Analysis Board is just that, recognizing that we are challenged today, we have a gap of knowledge and understanding within the ecosystem where you can have
vehement disagreement across different parties as to not just the vulnerabilities existence, I think that we can get to that point, but what is the impact of that vulnerability from a clinical perspective and therefore what action would need to be taken. So having an entity that's more of a neutral body,
a neutral entity that's a public private model that includes technical experts, clinical experts, engineering experts, security experts, that government has a seat at the table as well, but government doesn't own this entity,
think somewhat like akin to an NTSB model, not exactly like that, but the idea and not waiting for something bad to happen, but rather when a vulnerability of this high consequence is brought to our attention, we find ourselves having to reach out to multiple parties
trying to get to this place of understanding really what the impact of that vulnerability is. How much better would it be if there was a pre-positioned body of experts that are able to come together in real time to fully assess through each kind of expert's lens
through different disciplines really what the impact is of that vulnerability and what are the necessary next steps to take. So that is something that we are proposing for initial seed funding. We're hoping that we can get some funding for that with the idea of it being subsequently owned
and operated by the public private sector, kind of through a public private sector model. Going back to the new pre-market update, so in reflecting on what we've learned, we come to three basic principles. We call them trustworthiness, transparency and resilience, recognizing that we've got to build
those foundational principles into everything that we do. It has to start with the pre-market, but it really goes throughout the entire post-market lifespan of a device. However, you're only gonna get to that if you build it from the start, from scratch, with all of those concepts in mind.
And so we released that in October. Some of the key elements there that were really important, aha's for us, number one, was the concept of bill of materials, right? So WannaCry had transpired and recognition that you can only protect what you know that you have.
For an end user organization, for customers, for healthcare organizations that have thousands upon thousands, if not in some cases, millions of medical devices residing on systems, how can they possibly protect their systems, protect the devices in terms of their performance if they do not know what the composition is,
the components are of those devices and whether there are vulnerabilities that have already been identified within those devices. So while we are heavily engaged in a fantastic effort, a multi-stakeholder effort through NTIA,
Department of Commerce, the SBOM, or the Software Transparency Initiative, which is fantastic. At the time, we also thought we were gonna kind of even raise it a bar further and say, well, it's not just software, we're concerned about hardware as well. So we called it the CBOM in the draft guidance, the Cybersecurity Bill of Materials,
with the expectation that manufacturers actually would have to provide that to their customers, not just to us, to their customers. We've had a workshop since, our docket as well, the comments have come in, and there have been recognition across the board by people that are a lot more knowledgeable and experienced than us,
that that's great and that's aspirational, but that's maybe taking it down the road. Really what you wanna start with is, let's get that SBOM, let's get that software bill of materials in place. So as we're in the process right now of revising and kind of taking into account the comments
that came into the guidance draft that we updated, the update that we issued in 2018, we're gonna put that back as SBOM as opposed to CBOM. And once we get there, then we'll move forward to CBOM as we continue to iterate and make things more rigorous.
Some of the other pieces that were important there was putting in an expectation that manufacturers have to include threat modeling and documentation of threat modeling in the design of their devices. Third item that was really important was, manufacturers need to include
in their pre-market submissions, evidence that devices are capable of being updated and patched through the lifetime of their device. We are dealing with the pain of legacy devices right now that has been an area that is gonna be very difficult
to address over the next few years. What we can do while we're trying to address that through one arm, certainly with new devices coming on the market, the expectation that they have greater resilience, that they are capable of being updated and patched, we want to see that as part of the pre-market submission,
not to find out once a device is in use that this device is brittle and any attempt to trying to update it is actually going to knock over the device. So those are some of the concepts that we incorporated within the new pre-market guidance. And we're, again, once more in the process
of revising it right now with the hopes of being able to release it again by the end of this calendar year. Okay, and to maximize time for questions, I will open it up. Are there any other questions that we can engage on?
Could you use the mic? Thanks.
Yeah, really good question. I think right now we are also dealing with the reality at FDA that we are responsible for making changes that were mandated by 21st Century Cures Act as well,
which brings into account a lot of interesting questions around products that have some functions that are considered medical device functions upon which we have direct authorities and some functions now which may not actually
be considered medical devices. So you can imagine how sort of convoluted that can be as far as how to approach that from a cybersecurity perspective. Trying to create an artificial walling parts of it off from what we would look at
versus what we wouldn't look at is very complex. We're working through some of those challenges now. But what I would say is the following, and I had this aha moment actually when I was sitting and listening to Alan Friedman the other day at B-Sides, talk about the Software Transparency Initiative, the effort, and the group's work in terms of defining,
well, what exactly is SBOMB? What really is it? And he said where the group had come to was X includes Y. Let's not talk about functions right now or let's talk about what's included within that. And for me, that really resonated because that meant
the SBOMB is really intended to be that protective measure, that ability to mitigate for the end user, for the customer. And so trying to separate out or divorce out pieces of it that would not necessarily be under our authority doesn't make sense. As we look towards SBOMB, we would be looking at the product in its totality,
even those components of the product that may not necessarily have a direct medical device performance function. But that wouldn't matter to the end user, right? Their concern is for the vulnerability and their exposure. So that's kind of how we're thinking about it right now.
I was curious about the scope of the vulnerabilities that your team is responsible for addressing. Is it just physical hazards or the function of the hardware device or do you also look at things like user privacy,
for example, or other? Yeah, that's a really great question. I didn't cover that at all. So the interesting thing is that across the Department of Health and Human Services, different agencies, different operating divisions have different authorities that they are responsible for.
ONC, I'm sorry, not ONC, the OCR, Office of Civil Rights, within HHS is responsible for HIPAA privacy and security. That's not under our remit. And so while we would not minimize the importance of privacy, of patient information,
clearly that's very important. Our authorities and our mission is specific to the safe and effective performance of devices and protecting patients from physical harm if the device was not performing properly or was not performing at all. So what we did in guidance that we've previously
issued though is we state very clearly manufacturers, you are still under other obligations that you need to abide by including HIPAA privacy and security. Here's what we're doing to make it easier for you to abide by that. So we have something called controlled vulnerabilities,
vulnerabilities that in their assessment don't necessarily result in a patient harm. What we've said there is that changes that are made solely to strengthen cybersecurity and data privacy related issues would fall in that category.
They are considered from our perspective routine updates and patches. They do not come to the agency for re-review. Manufacturer, you should just go and do that. You should just take those proactive steps to make sure that you can then be in compliance with the other regulations under other parts of government
that you are required to abide by and we're not going to impede that process. We're not gonna delay that because we say we need to see those. We do not need to see those. Other questions?
What do you foresee to be the biggest challenge going forward in the next five years for the FDA to the point of security? Biggest challenge? There's a few of them. Some of them are wrapped together. I think that, I think holistically across the ecosystem,
so it's not just FDA's challenge and this is where we really have to bring other parties together. It is the legacy system and the legacy device issue. And I mentioned that because of the economics associated with that as well. And the recognition that while new devices
can be made available to healthcare organizations, healthcare organizations are not necessarily well poised financially or through their business models to be able to take in those new devices in order to get rid of the old legacy drag.
And so you're left with certain systems that are not capable of being updated and patched. And you're left therefore with certain exposures and vulnerabilities and recognizing that a cyber campaign can occur at any time
and can exploit these vulnerabilities that leaves our critical infrastructure vulnerable. So how do we address that from a multiple facets? Recognizing that, yeah, we have some tools in our back pocket that we could pull out.
Some of them are a little bit drastic that we would rather not move to. We'd like to figure out through efforts of the public and private sector working together. And there are a lot of different consortia doing that under even what's called the big umbrella, the Healthcare Sector Coordinating Council to really analyze some of the economics here
and then what are the options, what might be the incentives that could be put forward to get these really older devices out of use and bring newer devices that are more rigorous and more secure in place. I don't know, Seth, if there's anything that you wanna add,
but that's, we've got lots and lots of challenges of different scale, but when I think of something that's really big scale that's gonna require a whole universe of effort, that's probably one of the biggest ones. And with that, we will have to wrap things up. Let's all thank Dr. Suzanne Schwartz for joining us today.
And let me thank you by encouraging you to take a sticker on your way out. Thank you. Thank you. Thank you.