The Connected Device Oversight Assessment Workshop

Hello, and welcome, everybody. My name is Sean Smith. This is the Connected Device Oversight Assessment Workshop. Our featured guest today is Mark Omo from Marcus Engineering, and a couple housekeeping announcements while we're getting started. Let's see, I hope I'm… Written here. This session will be recorded. The recording and slides and handouts will be made available to all registrants. If you would like a certificate of attendance, please put your name and email address in the chat file, not the QA file, the chat file. And, we will make sure that you get that within a day or two. Let's see…

If you have questions during the webinar, please put them in the QA function. We'll try to get to questions at the end. If we're not able to get to your question, we'll follow up with you afterwards. And the last thing is to be sure to use the chat function to communicate with me. Check the messages in the chat function, because there are gonna be handouts, there. I'm uploading a handout in a moment, which will allow you to follow along. with, the webinar. It's actually really cool. This is the first time we've done this, so, Thank you, Mark, for helping with that. And I am going to hand it over to Mark now, I think. Oh, yeah, upcoming events. So Thursday, there's an IVDR,

transition webinar, make sure you register for that, I'll put the link in. And then, Friday, James Pink is gonna be speaking, on the Friday call, so super excited about that, about QMSR, or QMS. So, I'm gonna put those links in as well. Anything I'm forgetting, Mark?

I think so.

Okay, well, I'll hand it over to you. Thank you.

Yeah, good morning, everybody. Today we're going to talk about the connected device oversight. And so, my name is Mark, I lead the engineering team at Marcus Engineering. So we do lots of embedded security, we, produce embedded, connected products, we work in a number of fields, you know, primarily medical, but also industrial, airspace, consumer, those kinds of fields. And so I'm not the Mark in Marcus Engineering, that's my boss, Patrick Marcus. So today, we're going to talk about connected devices, and so the first thing that I want to talk about is what is a connected device? And the FDA has a really broad view of what connected devices are.

And so today we're talking about devices. They have Bluetooth, they have Wi-Fi, they have Ethernet. or they're connected to a server, or they're connected to a record system, or an EHR, they're connected to a hospital network, or they're connected to anything outside of themselves. Those are things that are all connected devices, especially in the view of the FDA. And so, the biggest question about, like, why is connected devices its own category? And the biggest reason is because they're really hard. They have a ton of moving pieces. You know, traditional devices, it's everything inside the box. It's this bounded problem.

And connected devices break that mob, they reach all the way outside, and that's the primary reason to care is because there's a ton of new areas for risk for connected devices. They have a bunch of categories of risk that are not present with traditional devices, you know, above and beyond those risks. And sometimes they can be substantial risks that you're taking on in addition. And so the question I get a lot from regulatory people is, how do I know if my device is connected? You know, as non-technical people, some of these things that are really obvious. to technical folks are not obvious to people who are not experts in the areas. And so, what I want you to listen for is when you're talking to people.

you should really have your ears perk up whenever you hear things like Bluetooth, Wi-Fi, Ethernet, or even people don't talk about those directly sometimes. They'll talk about, oh, it's going to connect to the server, it's going to connect to the EMR, the EHR, you know, the electronic medical records, the electronic health records. It's going to connect to the network. you know, we're going to be able to access it remotely, or monitor it remotely. It's going to integrate with the hospital systems. Those are all things that you should think to yourself, My device, this device is probably connected, and you… you want to go dig into that and understand that aspect, because that's going to be a big area of risk.

And so the… one of the first things that we hear is we'll have the technical team say, well, it's not connected. Or like, well, it has Wi-Fi, but we're not using it. Or it has Bluetooth, and we're not using it. If you have any of these functions, Wi-Fi, Bluetooth, Ethernet, USB, If you're not using it. remove it. Do not include it at all. And sometimes people will say, Well, maybe we want to use it in the future, we want to expand it, or have it in there. You know, that's the same thing as saying, I want to have future risk with no reward today. You know, you take all the risk and complexity of having this connectivity, if you include it in your product, and if you don't use it, then you get none of the upsides of having it in your product. The only thing you're doing is making your product more risky.

You know, you should take every effort to remove these functions from your products unless there is a good reason to have them in your product, because they have a ton of risk involved. And so I want to take a sidestep here, and talk about, some, some current events. So, there, recently, on March 11th, so, about two weeks ago, a little less than that, Stryker was attacked by the Iran-backed group Handala, which is a, Iranian-linked, hacking group. And so, this is a very recent development in how you should think about the… your positioning and the risk of having a connected device. And so the… in this hack, they compromised Stryker's central IT systems, and they use them against itself.

to wipe out tens of thousands of devices at Stryker all at once. And one of the big changes that occurred here is in the past, there was a lot of, cyber espionage. You know, people hacking into companies, people hacking into you know, systems to get information, to, you know, maybe steal your designs, to steal intellectual property, those kinds of things. But this is a big, a big change, a recent shift. This is cyber warfare, and they didn't hack into Stryker to steal their IP, they didn't hack into Stryker to extort them for money. They hacked into Striker to have an effect, you know, to attack and disable their systems. And so this is a big, big shift in how

You know, cybercrime and cyber warfare have evolved, especially, you know, as it starts spilling over into the rest of the world. And so we're going to talk about this at the very end, and how, you know, this should kind of shift how you're thinking about it. But I wanted to touch on it up here at the front, so you can keep it in mind as we go through the rest of this here. So the biggest question is, so how do these connected devices work? So when we talk about, things, it can often be obvious an implicit for the technical team, there are a lot of parts of a connected device, lots and lots of subsystems that all interact differently. But very rarely do we see,

you know, people sit down with the non-technical team and explain, here are all the boxes, here's how they go together, and very, very rarely are you going to hear, here are all the questions you should ask that people may not want you to ask because they're not going to have good answers for you. And I want to arm everybody with the basic knowledge about what are all the moving pieces, how do they fit together, and what are those questions you should be asking? You know, the questions you didn't even know to ask, to help understand the system, the risks, what's going on, those kinds of things.

So, this is the most common pattern we see for connected devices, where you have your device. It connects to a phone, and then that phone connects to the cloud. So, easy versions, you know, like here of a connected pulse oximeter. You might have a connected continuous glucose monitoring device. You might see all kinds of connected diagnostic tools operating this way. This is very common, especially in the consumer space. This is how basically every device is connected. And so what we're going to do is we're going to dig into this step by step. The first area we're going to look at is the device, and this is one that's common across all the different ways of connecting devices.

And so when we think about the device, sometimes people think about it as this one thing, it's just a big blob. And this isn't how I want you to think about it. Devices have a… specially connected devices have a couple of common blocks inside that you should be looking at and thinking about. As you're trying to understand, how does this work, what are the risks, what are the implications? And so, the… the first one we have is the sensors and the effectors. This is what your device does. you know, this is, like, sensing, EEG, EKG, sound, vibration, pulse ox, pupil size, you know, everything. It could have an effector instead. You know, maybe it's a implantable pump, maybe it's electrocarbury, maybe it's a ventilator, ultrasound.

Without this part, your device is just a box. It doesn't have any effect. You know, this is the most traditional part of a device that even, you know, non-connected devices will have, because they all do something. And so, when you're thinking about this area of the device, the biggest question is, like, what does your device do? You know, sometimes, I figure out that people only have the vaguest notion about what this thing even does, and more importantly, like, how it does it. You know, it might be… we sense in this unique way, or we affect the body in this unique way, or things like that. And having just a little bit of an understanding about what it does clinically, and how it accomplishes that, can really help you understand the risks involved.

Another one is what data does it collect? So if this is a sensing device, it may collect a lot of types of data, even those that are, like, peripheral to its core function. The next one is, how can this device affect the world? Which is a little different than what does this device do? Because, in order to understand the risk. you need to understand what it can actually do. You know, you might say, oh, it's, you know, it relieves pain by applying a very mild electric current. And you're like, well, okay, could we apply a giant current? And you engineers might look at you and be like, well, well, sure, but just don't do that. You know, those are all things you want to understand to help understand the risk this device could pose. And then that relates in the last thing, which is what is the worst thing that can happen?

And sometimes people can be not inventive enough about how bad or what the worst thing that can happen is. you know, you could have behavior that's, like, intentionally bad. You know, we could intentionally have bad diagnostics, or, you know, under-report things, or over-report things. You know, you should cast a really broad net to understand this, and this is really important to understanding What risk could occur if you have a breach of cybersecurity? And so the next one is the processing and the storage. And this is… I like to call this, this is where the data gets turned into information.

You know, you might say, well, we have a microphone that listens to, a patient's heart and tells you if it has a arrhythmia or something like that. And… you know, the microphone, the list… that raw data is really kind of the data, and the information, the secret sauce might be turning that into information, you know, making the clinical info… the clinical outcomes, you know, driving the decisions, those kinds of things. And so… you know, you're processing the information from the inputs, from the effectors, and turning it into the outputs. And this generally makes up the bulk of device software. And this can also be the opposite, where we use very special algorithms to affect the device and sense it, go back and forth.

You know, some kind of, like, advanced electrocery, where we're Detecting the perfect cut on a vessel without, overdoing it, or things like that. And the other important part is the storage. And so, you can have a lot of different types of data, or storage of data, things like that. The most common ones are just, like, the raw data, the readings, the settings, you know, oh, I want this to operate in this mode or this mode. But the next one is, PII, Personally identifiable information. you know, stuff like name, ID, birthdate, that kind of stuff. And this can be both from the patient, you know, maybe you're collecting the data so you can link, hey, Jane Doe had this result on this day, that kind of thing. Or it might be from the clinician.

where, you know, you say, oh, this is, this doctor, logged in on this time, or this technician, those kinds of things. And then the next area, which you're almost certainly going to have, is, security information. So there's going to be at least things like keys, passwords, identifiers, firmware, those kinds of things that are stored on there. And all of these different types of data and different types of processing are really important to keep top of mind. And so the biggest things that you should be asking your engineers is, where is the thinking done? And so, one thing is that sometimes devices process that data into information on the device.

But sometimes, this, devices process this data into information on the cloud. They may send information up to get processed using, you know, magic algorithms, or using, processing that's far too complicated to do on the device, or that you don't want to do on the device for, like, IP protection reasons, those kinds of things. And that helps you understand You know, where… where does this risk occur? Where are the… the issues likely to be? The next one is, do we store any patient information? And this is… this could be a pretty broad net. You know, if you say, hey, we have to collect the date of birth, or the year of birth.

to help, you know, because one of our algorithms is patient age. Well, that's… that's patient information. You know, if we have to collect information on their gender, that's patient information. You know, there's a… there's a lot of categories of information, and not all of them… People might obviously think, oh, that's patient information, but all of those little tidbits can Independently may not seem like a lot, but when you put a big list together, you might say, oh, we have a lot of exposure, or there's a lot of information that we could keep glean from this. The next one is, you know, what security-related information do we store? And this is not a common category, that if you ask, hey, what do we store on the device that people are going to be thinking about? But it's actually one of the more important categories of information.

You know, as you connect, there's all kinds of, you know, keys, there's all kinds of ways we tell the server is the real server, there's all kinds of ways that we, transmit data, that we encrypt data. Those are all really important settings on the device, really important bits of information, and you want to make sure that you actually know what all of those are, where they all are, what's going on, that kind of thing. The next one is the… the SBOLB, the Software Bill of Materials. And so, the SBOM is a required element to be delivered to the FDA for connected devices with software. And the… if your engineers don't have this, then that's a really bad sign, because, like I said, it's a required bit of information, and it's just, just as important

as the rest of the device. If somebody… if you ask somebody, well, what are all the parts of this device so we can build another one? And they said, oh, I don't know, you know, that would be a crazy answer. And it's the same for software. You know, you want to hear from this, you know, you're not going to receive this document and necessarily look at it and understand it deeply yourself. But you want to hear from them that they have a quick answer, a positive answer that says, oh yeah, it's right here, and it's in a place that people have actually looked. You know, I think lots of people know the difference between documentation that people actually use and documentation that

is there because it's required to be there, but may not actually be well-referenced. You want to make sure that this is a well-referenced document, or that you hear from people, hey, this is automatic, this is generated, those kinds of things. That's what you want to hear about your device. The last one is, how do we update this? And oftentimes, we hear from people. You know, well, we'll do that at the end, or, well, it's not important, or, you know, it's not a thought-through answer, and updating devices is another core function that the FDA requires you to have, and it's a core function for how we design in security. You want to understand that it's a use case that

The engineering teams are thinking about, the people know how they're going to update devices, and that they know what that's going to look like. Because, for example, you might design a device, and you realize at the end, oh, we needed a feature to update it, or we needed this thing to update it, and all of a sudden, you're doing more product development to meet these regulatory requirements. This is a thing you want to hear right from the beginning. And so the last part here is the transmission. And so, this is the part that makes your device connected. And this could be… Intentional or unintentional. Sometimes you'll say, well, we use this thing that has Wi-Fi built in, but we're not using it. That's a… that's a… that's a really sad thing to hear, like we talked about before. And sometimes this is quite intentional. You know, this could be Bluetooth, or Wi-Fi, or Ethernet.

And one misconception we hear a lot is that these are only wireless technologies, like Wi-Fi, Bluetooth, those kinds of things. This includes wired technologies as well. If you have an Ethernet port, or a USB port, or things like that, that makes it just as connected as if you had Wi-Fi or Bluetooth, those kinds of technologies. and other wireless technologies that you may not think about as connected, like, you know, some kind of RF, field that's used for implantables. That makes your device connected. Or if you have a, You know, sometimes devices use optical or ultrasonic data transmission. That makes your device connected.

And so when you're thinking about the connectivity part of the device, you know, you really want to ask your engineers, you know, is this connection required to function? And… you know, this can be a really important and subtle part, because connections are fallible. They can always stop. And the next question is more pointed at that effect. You know, sometimes we say, hey, this is a, we have a… endoscope camera that's connected over Wi-Fi, and that makes it easy and fast, and, well, what's the risk if that Wi-Fi connection gets disrupted? You know, I don't know about you guys, but, I have my Wi-Fi drop out all the time, and if your patient's life is depending on that.

Then you at least need to take a really hard look at that area, or really consider the risks and design changes that might be driven By mitigating that risk, or eliminating that failure mode. The next one is, how does this get it connected? And this can be a really important part of the process that, make it kind of forgotten in development, where… You're doing the device, and in development, it's always kind of connected, those kinds of things, by default, but all of a sudden, when it goes into the real world, there's a whole bunch of challenges. And, you know, getting things connected to a hospital network, for example, can be a weeks-long process where you're working with the IT department, you're working with systems,

all kinds of aspects, and there's also significant risk in this area. For example, if you have a Bluetooth monitoring device, and you need it in an emergency, and, oh, but first we have to connect it to our phone and get it paired and stuff, you know, that's gonna be a bad time. You know, that's gonna drive risk in your device. And this could be a flow that can also be really frustrating or hard to document. And so these are all things that you want to do. If you've ever, used your car's Bluetooth, and it's always been really annoying and frustrating for me, and, I suspect for some of you as well,

those car manufacturers put millions and millions of dollars into designing those connected systems, and I want you to think about your guys' development budget versus those guys' development budget. And that kind of tells you about, you know, this is a tricky area to get right, and you want, for sure, want to make sure that it's out of the line of fire for any kind of risk or process in your device. The next one is, can we connect in more than one way? Lots of devices have multiple connection methods, they'll have Bluetooth and Ethernet, they'll have Wi-Fi, they'll have USB. And maybe your device is Wi-Fi connected. That's what you advertise, that's how you designed it, that's how you intended it. But it also has USB. Well, that USB is just as important for your security, for your risk, for your analysis, even if you're not using it.

Or if you have Bluetooth and Wi-Fi, but you don't really use the Wi-Fi, same thing. Every type of transmission is part of your risk profile, needs to be part of the things that get considered in development. You really don't want to hear, well, we don't use this part, or oh, well, that doesn't matter, those kinds of things. There should be clear, concise answers from the technical team about how they deal with these things. And the last one is one of the most important ones, which is, did we reinvent the wheel? Lots and lots of engineers. really love making new things. Making old things work is much more boring than making a new cool thing.

And this is a trap that people will fall into, where they say, well, gosh, you know, Wi-Fi or Bluetooth is insecure. We're gonna do our own different thing. And this should scare you. And… The main reason is because… you know, thousands of people on the planet, the smartest engineers in the world, built Bluetooth. Those same thousands of engineers, you know, were attacking it, finding vulnerabilities, all kinds of little issues. And when you make a new thing, what you're doing is not making something without the vulnerabilities and the issues that come with Bluetooth or those other technologies. You're making something that has all that stuff that has already been solved.

you just don't know about it yet. It's a common aspect where people People… See all the vulnerabilities and all of the work and stuff that has gone into it, and they miss the part that, that's there because people worked on it, not because it's inherently a bad technology. And so this is a really good example about where this is. So this is the Boston Scientific Deep Brain Stimulation System. And, you know, you see down here, communication, Bluetooth. And some people are like, oh man, Bluetooth, that's, like, in my car. Do I really want that connecting, you know, into my chest, into my head? That seems really scary. And this, is much, much better than the alternative.

Like I said, because thousands and thousands of the smartest people on the planet designed this protocol, attacked this protocol, and when you implement it, you see the vulnerabilities, you at least know the surface, exactly what's going on. And you know, you have this pattern that the smartest people in the world have made about how to attack and defend this. when you see these older technologies, so this is the Ascent, RF, pacemaker, and so this… pacemaker was designed with a custom RF protocol by engineers, who, you know, tried to design something secure, but did not have all the expertise of the smartest people on the planet. And there were 529,000 of these implanted. And what happened was, there was a, security vulnerability in the wireless communication itself.

And this, this security vulnerability required a whole chain of updates and changes to mitigate the risk in this. And as a result of this, I reviewed the, the FDA, mod reports. and found that there were at least 11 times these peacemakers were removed and replaced as a result of this decision, and at least 18 additional hospitalizations as a result of this, this issue. You know, this is a really good example of why you should never, ever, ever Make stuff yourself. Because there will be issues, you just don't know about them yet. And if you hear people say, we're gonna do it faster and better than anybody else.

That… that should make you afraid.

Can I interrupt for one second?

Absolutely.

So we have a question, can you please elaborate on the security-related information stored in the device, perhaps with an example? And while you're thinking about that, I'm going to run the, poll… question if I can figure out how to do that. Let's see… polls and quizzes. So, there's a short poll. Please participate in the short poll. Also, a reminder, I put a link in, the chat for the, handout, so please, use that. Mark, you can just minimize this on your screen so that it's not blocking your view. And, if I need to put the link in again, just write… put the link in again. Please, feel free to submit questions with the Q&A, and, back to you, Mark. Sorry for the interruption.

Yeah, so we talked about security-related information on a device. The… I talked about a few categories a few slides ago, but one of the big ones that's top of mind is the security keys that you use to communicate with a server, or with the connected device. Those are easily going to be in every single connected device, and those are… that's one of the big pieces of information you want to understand. How does it get stored? How do they get in there? How do we secure it on the device? Those kinds of things. You know, just to help understand, give you context about that whole subsystem in the… the device.

Let's see… so the next connection pattern we have, so when we're talking about the disconnection pattern, the next area we want to look at is the phone. And so, you know, people, when they design phone apps, they think about, like, oh, my app is the only thing this phone does, and then, I don't know, maybe there's something else on there. But, you know, I've seen real phones by real people. This is the reality. You know, you have your app, it's just a small part of all of these other… potentially wildly insecure applications that run on the phones. You know, apps you haven't used in years, you know, the apps that your grandparents have installed in their phones, you know, stuff that you should be afraid of.

And… You know, when you're looking at this, everything else running on the device is a big security risk. And the biggest question you need to be asking to your team is, how do we manage the security risks of running on an uncontrolled device? Lots of… you know, your app, if you're running on a phone, is not the only thing that it does. And all these other apps can pose risk, pose problems to your device, to your, To your app, and you need to really consider, hey, do we need to make any decisions, or think about, you know, how do we deal with the security of all the other applications on the phone?

And if people… you know, you want to hear a confident answer to this, there are lots of good ways to deal with this, but if people haven't considered this, or they're like, well, it's… it's, you know, it'll kind of take care of itself, those are things that you should be quite worried about hearing. So… and there are a couple of ways that phones get used that you should try to think about. The biggest one is the TV screen. This is where the phones are just used to view device data. There's no control, there's no processing on the device. You know, these are things like Bluetooth thermometers, you know, a pulse oximeter, things like that, where they're, they're just like a second screen, or maybe the only screen, just for viewing data.

And so, when you're thinking about phones used in this way with your devices, you know, you want to think about, like, is the data live? And what happens if it's not? You know, there are lots of risks related to, well, we took the pulse again, you know, took the heart rate again, and it was fine the second time, while you're really just seeing old data from the first time. You know, are alerts critical? So, and how do users get them? I… I miss… alerts on my phone all the time. And if you're relying on somebody's phone going off for a critical or a life-saving alert, especially if that's the only way that that alert gets out, you know, you should be really, really, concerned about that.

You know, phones are… are fickle things. You know, the next part is what parts of the phone do we rely on? You know, there are thousands of models of phone in the world. If the more parts of a phone you rely on, the more validation, the more work you need to do, and the more issues you're going to have as you roll it out. If all you rely on is Bluetooth, that's already plenty. That'll have tons of challenges to get there. But if you rely on things like the accelerometer, or the lights, or the magnetometer, or all kinds of things in your phone, you're gonna start having lots of challenges in the real world.

The next one is, do we get data from the cloud or the device? It might be surprising to some of you that if you have a phone connected to a device, connected to the cloud. that the phone is displaying data, not from the device at all, it actually goes to the cloud, and then the data that you're viewing on your phone is from the cloud. This is how, for example, a Fitbit works. You know, it'll connect to your phone, and it'll connect to the cloud. But the… that data doesn't transfer directly from the device to your phone. It actually goes all the way to the cloud, then comes back down to your phone. And that might be how your device works. And so this is a good question to ask for you to understand the risks. You know, maybe you would say, well, gosh, all I need to do is, get…

the… if we lose internet connectivity, it's not a risk. Well, it might… it might turn out to be a risk, because nobody considered, hey, this data is actually from the cloud. So the next way people use them is, as a remote control. So, this is where your phone not just views data, but you can control the device as well from your phone. You know, like a Bluetooth-connected blood pressure cuff, or maybe you can start a measurement. Bluetooth surgical lights, you know, where you can… the doctors can tune the color temperature to their liking, or the brightness, those kinds of things. And when you're thinking about devices that you can control from your phone.

You know, you should be able to ask, what's the risk of not being able to set commands? Like, what happens if your clinician phones die, or it loses connection, or things like that? You know, there's this availability risk. If there's no way for you to adjust your surgical lights, except from your phone, and the phone loses connection, you know, you could have a big problem. You know, next one is, what's the worst possible message? You know, some people might say, well, gosh, we have this command to make the lights go into disco mode, but that's never gonna happen, because we'll never tell the lights to go into disco mode.

But, well, your device might not, but your attackers might say, oh gosh, we're gonna turn the lights on and off and make them flash in a harmful and distracting way. And another related one is, is there an override? So, for example, if you were to have something happen, whether it's a technological glitch or an attacker, can we stop the device? Can we change its behavior, without using a phone? And this is a really important Thing you want to make sure is considered, because this is an easy way to sidestep a lot of risk, and a very common pattern for people. The next one is, could this cloud send a command? If you have a device, and it's connected to your phone and your cloud.

It's one thing if bad commands could be sent from the phone, you know, that could be potentially bad, all kinds of bad scenarios, but it's way worse if you could have the cloud set commands. If all of a sudden your cloud can reach down to your device and cause things to happen, then you have this massive cybersecurity risk from people attacking your cloud, and they could cause bad things to happen on every device, everywhere, all at once. You know, this huge change in risk profile. And the next one is, does the phone have special access? You know, is the phone that's paired different than a regular… than any phone or, you know, selected phones. And so, you know, maybe if you could walk up and just pair to a device with a pairing button or something, and all of a sudden, now I can cause all these bad things to happen.

Versus, I need to connect a device, and enter a password, or be an authorized user, that kind of stuff. You know, there's a different risk profiles, especially in areas like hospitals, where, you know, access is controlled, but it's not, you know, there are plenty of opportunities for people to walk up to devices and interact with them that you may not expect. That can cause all kinds of problems. And so the next pattern here we have is the brain. You know, this is where the phone runs processing for the device. A good example of this is Bluetooth is continuous blood glucose meters. A subset of these work by having processing on the phone

That helps determine the dosing and the schedule and things like that. Where it also… where it communicates, controls, and does processing. And so, the biggest one is, you know, what devices have you tested? What phones have you tested your device with? And if they tell you, I don't know, all of them, or, you know, it's compatible with all phones, that's… that should make you worried, because that is… that is not true at all. There are so many phones in the world, you will never test them all. They're gonna be… so many challenges with that. You want to hear them have a short list, a concise list, and physically show you all the phones that they have. They're like, oh, we support these 4 Samsung phones and these two iPhones, and we have them in the lab right here. That's gonna make you feel warm and fuzzy.

Your next one is, what happens if the phone is too slow? So, lots of phones will have lots of apps installed, they might be old, they might be, challenged in other ways, and all of a sudden, if your device has a risk. Because your phone is too slow, or the processing can't keep up, you know, that's a big area that you want to be at least considering and thinking about and understanding when you're talking about how do you manage risk on the device. The next one is, what happens if the app stops suddenly? And this… this may not be something that people strongly consider, but your phone actually kills apps all the time.

to manage its battery life, to manage what's running, those kinds of things. And if you rely on your app running 100% of the time, or, you know, being open or continuously connected, you know, those assumptions are going to break down in the real world. The next one is, how do we validate the system? And… and you want to hear… things from your technical team about real-world testing, testing across devices, testing in all kinds of situations with different phones. You want to make sure that you don't hear, well, we have the one phone in the lab. And it works with that. You know, that's all too common when you start getting into the real world and bad stuff happens.

The next one is, how much does the device do on its own? You can imagine for a Bluetooth continuous, meter, or for a, you know, something that takes action. If your phone is disconnected, or it dies, or it gets broken, and all of a sudden the device is useless, that's gonna at least drive you know, your users and how they change devices, but if this is controlling an important function, this could also be its own area of risk. You know, the phone is not continuously available. And the last one here is, do we store PII, that personally identifiable information, on the phone? You want to really understand where PII gets stored everywhere, even if it's only transiently there, even if it's only there for a few minutes.

Those are important parts in the chain of control for the device. The next one here is the courier. So this is where your phone just passes information to the cloud. And so, you know, this is how, like I mentioned, fitness trackers work. Like, a Fitbit uses your phone just as a stepping stone to get to the cloud. And, you know, one of the areas is what happens to the data when we're not connected to the internet? So if your device is monitoring, for example, if that data gets lost when you're not connected to the internet, maybe that's okay if this is a device that's used for a few minutes in clinic. You know, we're going to record some data and be done. But that might not be okay at all if this is a, you know, a…

a patient monitor that's continuously monitoring, heart health for a cardiologist over 30 days. If somebody says to you, well, after 10 minutes, we start losing data, you know, that's… that's going to be a challenged use case for sure. And the next one is, you know, do we store data, and do we store PII? Do we pass this information along? Those kinds of things. There are lots of ways to mitigate the risk of passing information from the device to the cloud. You and I hear from your technical team that they understand if they're doing that, and then if they're doing that, do they have a plan, a strategy to handle it?

You want to make sure that this is something they've really considered. The next one that's most important is how do we authenticate the device, and how do we authenticate to the cloud? When your phone connects, it may not be connecting to the real cloud, or it may not be connecting to the real device, or your device may not be connecting to a real phone that's running your software. Every one of those leaks in the chain needs to have a strategy behind it about how that link gets secured. And you want to hear that you That your team is using some well-understood technology. It's a very common thing to secure those connections, because those are going to be the technologies that are, you know, battle-tested, the ones that people really understand and have really tried to secure.

So, I want to touch on some other device patterns here. So we talked about phone connected. I want to talk briefly about what we call 8 gateway connected, and the last which was hospital and internet connected. So when we say gateway connected, this is kind of similar to a phone connection, except we connect to a, gateway. Piece of hardware whose only purpose in life is to bridge the device to the cloud. And so, a common pattern for these is that implantables that have continuous monitoring and reporting often work in this way. Infusion pumps can work in this way as well, for sure. You know, when you're thinking about these devices that use a gateway, some

Device that's built for this purpose. You know, similar questions about, do we store data? Do we store the PII? Do we pass this PII through our gateway? You know, how does this gateway authenticate with the device? How does the device authenticate the gateway? How does the authentication with the cloud happens? you know, what's the worst thing that we can do? Can the cloud command the device? Can the gateway command the device? You know, those are all risk areas you want to understand. the, you know, how do we update all the parts? You know, people may think about updating the device, because that's clear. Well, you'll be… you might… you may or may not be surprised how long the gateway is part of your medical device.

Because it's probably essential for it to function, or at least essential for it to provide some of its functions, like the connected ones, and that means your gateway needs to be updatable as well. And the last one is, how do we secure these wireless communications? Gateways are almost always wireless devices, and you want to hear that you're using some well-understood technology. You know, Bluetooth, Wi-Fi, you know, maybe LoRa or something like that. something that people have worked on hard, and that people have done in technologies. They say, we have a custom protocol. Like I mentioned before, that's something you should be afraid of. You know,

St. Jude Medical has, you know, had to do surgeries on people because they made that decision. Don't, don't, make those decisions again. The last one is the hospital or internet connected. This is where your device connects directly to the cloud, with nothing in between. And, this is… this is the most dangerous, most complicated, most security-intensive pattern that you can adopt. When you see these kinds of devices, these are the areas that you need to have experienced teams with serious cybersecurity expertise. If, you have people who are not cybersecurity experts on your team, you should really be worried.

So, things like surgical robots have this pattern. Ventilators, infusion pumps, plenty of them are connected. And people might say, well, we're in the hospital network. That's okay, that's a safer area. The FDA's explicit guidance is that you cannot rely on the security of the hospital network. You should consider it Just as hostile as the open internet. And when you see these kinds of patterns, you know, the main… the first question is, who are the security experts? And the worst answer you can get is, oh, well, the software engineers, the software team is taking care of that. Software engineers are not security engineers.

You know, some of you, if you're in the regular fire space, might be like, well, the engineers are writing all the regulatory documentation. Like, they're like, oh man, it's gonna be… it's gonna be a wild ride. You should think the same thing about software engineers and security engineers. These are different disciplines that require different expertise. You know, software engineers build things, security engineers break things. You know, do we have experts in securing internet-connected devices? You know, these are… These are subtly different experience areas than other things, and you want to make sure that people have experience in this problem domain.

The next one is, you know, who is handling post-market security? So, engineering teams may traditionally think about, we built the device, we ship the device, and we're done. And then, I don't know, stuff happens after it gets to market, but it's not important. The post-market is the most important area of security. You want to hear that there's a plan with people who you can point to and name whose job it is to handle security. after you get to market. And not just, well, it's kind of their normal duties, but there's this extra stuff. You know, this really requires people to think about dedicated resources that spend… who are paid to spend time securing devices after they get to the market.

The last one is, who is handling penetration testing? So, penetration testing is part of security, you know, where you go and you try to break into devices. It's, verification of security. You might have lots of validation of specific security limitations. Does this work? Do we reject things? But this is really verification by an independent team, an independent party, hey, my device is secure, is good, or isn't good, those kinds of things. And the, you know, this is… penetration testing is recommended at various levels, but when you get to this kind of cloud, directly internet-connected device, directly network-connected device.

These are the kind of devices that are banner examples of when this is required and necessary for your testing. And you want to hear that there are independent people who have the requisite background, experience in testing and security who are handling this process. So, I want to come back to the… talking about the striker cybersecurity. And so, you know, we're thinking about, you know, I'll call it wartime cybersecurity, you know, where people are not just attacking for, where people are not just attacking to get information, they're not just criminals attacking, hey, we're gonna attack your network, and we're gonna ask you to pay us a bunch of money to recover, those kinds of things. You know, when we have attackers who are…

funded by nations who have, you know, serious resources. You know, they don't care about making money, they don't care about this proportional risk, they only care about having an effect. And so, you know, in normal cybersecurity, security risk is proportional to reward. And in cyber warfare, we don't have this. You know, people might not attack devices that are low risk, or that are smaller. Or that don't have much data, because, well, if they're cybercriminals, maybe you don't have the money to pay them, and they're gonna go hit a juicier target. Or things like that. But in cyber warfare, you attack not to make money, not to, do things, just to cause terror.

Just to cause issues. You know, and IoT devices are really where cyberspace meets the real world. You know, I'll call it meat space, you know, where this is how you can have these virtual attacks reach out and touch the world. And the biggest area you should be worried about is an attack on central systems. You know, this is exactly what happened to Stryker. They didn't go out and attack 20,000 devices, 80,000 devices individually. They attacked one system whose job was to affect 80,000 devices all at once. And what you should really be afraid of is somebody doing something like compromising your firmware update process. All of a sudden, they could push an update to every device in the world and cause

harm. And they could cause harm in a way that you can't easily fix. If they update all of your devices, they can update them to reject updates from you, and all of a sudden, you have to walk physically to every single box in the whole world to update it, to mitigate these harms. You know, these are… these are huge opportunities for risk, and, you know, a shift in the way that people… you should be thinking about what your exposure is and what your risk is. And when you're thinking about these kinds of questions, you know, the biggest one is, who are the security experts? You know, do you have people, do you have consultants who have at least evaluated what you're doing, who can tell you about where the risks are?

Who can help you with the highest priority, the highest impact things. you know, when you're thinking about what's the worst thing an IoT device can do? You know, you might say in a fusion pump, there are easy things. Hey, I can command my fusion pump to, in… to… pump suddenly everything that it's connected to as hard as it can, as fast as possible. You know, it should cause serious injury or death. But if you have, like, a surgical light, for example, maybe it, goes into disco mode randomly in the middle of a surgery. you know, when you could cause all kinds of patient harm and death, or even a lack of availability. You know, if you have a hospital network that all of a sudden has to go to paper medical records,

You can easily have patient risk, patient death as a result of the friction and challenges of operating a modern hospital using pieces of paper instead of the modern tools we have today. You know, the next one is really important, just, do we have a response plan? Cybersecurity is not perfect. There will always be things, there will always be gaps, and the biggest one is… do we have a plan in place for what happens if these things happen? you know, if you are thinking about it for the first time, as your phone is blowing up because something bad is happening, because this is not the time to be finding new vendors, to be trying to figure out what we're doing. You want to have these plans in place ahead of time.

And those plans are not worth the paper they're written on unless you've tested them, unless you have tried them out to see if they work. You know, the next two are about these central updates. How do we secure the firmware updates? Do we think about these as the most secure, most important parts of our system? Where we should be placing lots of thought and care in the control. And what other central systems do we have? You know, do we have central IT systems? Do we have central cloud systems that can be compromised to cause mass harm or mass unavailability. You know, those are all the areas that you should be thinking to yourself about and looking into as you're considering these kinds of nation-state risks, you know, as we progress through time.

So I'll leave you at the end here. So we have, You know, I get lots of silly questions from people, you know, who they're afraid to ask their engineering team, because they're like, this is way too dumb. So one thing that we've been playing with is that we created, this chatbot, you know, connectedchat.markuscentering.com, where you can go ask it your dumb questions about how devices work, how to connect to them. You know, say, you know, you could practice talking to your engineers, it'll be much nicer than some of those people are. Or if you want to speak with a human being, you can feel free to shoot me an email. I'm always happy to chit-chat and hear about, your devices and, you know, what you guys are doing and how we can help.

Yeah.

So, we've also prepared two other documents. One is the 30 questions, document, which, we'll email to all of you, later today, and the other document is, the… 10, cyber warfare questions that you need to be asking your, your team right now. And you can just forward that to your team. and, you know, say, hey, I attended this webinar, it was really helpful for me, they suggested this, how do you feel about it? You know? And, See what they say. it'd be an interesting experiment. And, so, yeah, and I'd also, want to make sure that everybody downloaded the handout that's been attached 3 or 4 times during the webinar. And, please give us your feedback on that, because, yeah, we…

Yes, I'll email the handout as well. make sure that you get a chance to look at that. There are a few questions. One that I saw earlier was, for home-based medical devices, the security Risks or attack surfaces are considered treated lower compared to clinics, hospital networks, enabled devices, question mark. FDA.

Yeah, I think, the… Home-based devices are not treated as any kind of lower risk. You know, your home-based device probably doesn't have staff. IT staff that monitors and secures it. You know, those would be the same kinds of risks as a hospital-connected network, as the open internet. You know, there's no presumption of security anywhere, is really one of the core tenets of the FDA here.

Hmm. So, I heard a situation where, somebody was on an aircraft carrier in the… in the… in the Straits of Hormuz, and uploaded his… went for a 7-mile run, and uploaded his status, and it gave the exact location of the aircraft carrier to the entire world, or… You know, I thought that was kind of interesting.

Yeah, the, Strava attack, Where it actually happens a lot, where people have, record their runs, because, you know, some of these are fitness people, and they, all of a sudden, you see, gosh, a hundred more special operations people recording runs in this base, in this southern part of the world. Hmm, something might be going on. Or, like you said, we turned on our run in the middle of the ocean. you know, this is the kind of stuff that military operational security people worry about all the time. Yeah.

And there's one last question. Systems with components that store and connect internal FPGA to a central medical device processor. How vulnerable is FPGA technology? I don't even know what FPGA technology is.

FPGA technology, it's called Field Programmable Gate Arrays. It's a kind of internal hardware used for processing, especially, like Scott mentioned here, in video areas, that kind of thing. And FPGAs, I wouldn't say, are inherently more or less secure. They… They can let you make your own bits of hardware, which can be, you know, just as insecure as any other things that you make yourself. And you know, I would… I wouldn't say that it changes at all how you should think about what you're doing, how you should think about the types of vulnerabilities you have. And you might even be more worried about it, because you're building your own hardware. If you're not using other people's well-tested hardware, you could be inadvertently making new vulnerabilities, so…

Well, we're about out of time. I'd like to thank Mark, first of all, for sharing all this knowledge with us, this timely webinar. Very, very helpful, and I would like to thank all of you who took time out of your busy day. to, attend and share with us. We really appreciate your feedback, so please take part in the survey that's gonna pop up on your screen. And yes, we will be… emailing all of you with links and plenty of helpful documents. I strongly encourage you to reach out to Mark if you have any questions or concerns, he's always happy to chat, he's very friendly, and

Yeah, thank you all.

Thanks, bye-bye.