Surprise! IoT, Medical Device or Both

Alright, we'll move on. This one's more hard. A bone growth stimulator with a factory serial part. Who thinks this can connect to the internet? Or is your hand? Give it already a few more seconds. Believe it or not, yes! This can plug into a computer, which can be connected to the internet. Alright. What do I? Bone Growth Simulator, the factory on this airport, with a cover that needs a tool to remove. Can this connect to the internet? Is this… is this a cyber device under the FDA? Everybody a few more seconds. Yeah, turns out it's on the border, but probably. I have seen situations where this counts as a cyber device.

They interpret this…. Unbelievably broadly. Um, the current guidance. That was kind of a trap, though, Mark. I'm just gonna say, I mean, I'm just gonna call it out. Come on, man. Yeah. And that's the trap I see everybody, all… lots of our clients fall into, is they go to the FDA, and they. Yep, this is a cyber device. And they're like, ah! Um, and so their guidance…. So, the best post that I saw about this was, is your device made out of solid wood? Okay. If yes, it's not a cyber device. If no, it's probably a cyber device. Oh my. Wow. Exactly. So, tongue… wooden tongue depressors are not cyber devices. Everything else is.

My favorite is a thermometer. Serial Park, cyberdevice. Got it. Wow. Um, and so it's, does this device contain ANY external wired or wireless communication interfaces? That's what's on the FDA's refuse to accept checklist. That's the checklist that they use. To evaluate whether your 510K is going to get kicked back. And then you get one of those nice templated form letters where they check the boxes and give you lots of paragraphs of information. Um, and so, of course, my… what we often see is people say, oh, I already have my 510K, I don't need to worry about this. Uh, turns out, still need to comply. All devices, even with 510Ks.

Already issued, need to comply for this. Place where this comes up is usually when. You are making a change that requires. Refile of a 510. Um, a substantial change, and you come back, and you're like, oh great, I only added this new mode, here's all my clinical data. And they're like, that's awesome, where's all your cybersecurity compliance? You're like. This was made 20 years ago. Um, that…. They are going to require all of this information. So, uh, there are, uh, there are 5 top. Engineering requirements. That the FDA has that are going to blow up your budget. Um, and uh, we'll go through them one by one. So the first one is updatability, patchability.

The FDA requires rapid, secure. Verification, validation, and distribution of patches and updates. Um, this, uh…. Uh, this isn't, oh…. You know, we'll send a technician out the field, we'll send it back to the factory, all that kind of stuff. You know, sending it back to the factory is not going to cut it. This is not going to meet the requirements of the FDA. You need this to be a feature in your product. To allow you to meet this requirement for rapid, secure verification, validation, and distribution. We've often seen products who. Can't, for example, do secure. Updates, because they can't run the cryptography required. To meet the current best standards. We've seen.

Products that don't have interfaces or software support, and it would be more complicated. Then the entire product blowing up their development timeline and budget to add this to their product. Um…. The next one here is logging. And intrusion detection. So the FDA requires you to be able to detect, recognize, log. Notify people, and act upon. Anomalous conditions during normal use. And the main reason for this is because. In addition to all of the safety reasons that you're probably already thinking about. It's to identify cyber events. You know, to figure out, have people been…. Interacting with my device in an unexpected way. That could indicate that they've compromised it.

They could compromise it, they're sniffing around, that kind of stuff. Or to say, hey, all of a sudden, my devices are doing something weird. Which could indicate a compromise is going on. You know, they're…. Operating 10 times as much as they should be. They're…. Um, uh, you know, being used in the middle of the night when there never were before. Uh, those kinds of things. Those are all the kinds of things that they want. Um, and uh, people often say. Oh, we'll ask our…. Field sales reps. To do this. And, you know, I saw something weird 6 months ago, when you asked the doctors. This question, and you document it, that's not going to cut it. That does not meet the requirements.

Of this. It needs to be automated, it needs to be detailed, record keeping. To meet these requirements. Um, the next one is authentication. So…. They require that you use NIST-compliant. Mutual authentication and encryption. All external connections. Um, this means that you can't just…. Uh, some people are like, oh. We used a CRC to check if the packets messed up, or we used, uh…. You know, we plugged it into a device with a special connector, so nothing else can plug in. Or we. Use… own the server, that kind of thing. It… those will not meet these requirements. You have to use.

The current best NIST standards for all of your authentication, all your encryption. Everything for your external connections. Um, and this often drives the hardware and software for your product. If you made decisions early in your design. But I'm going to use this really great, cheap, small microcontroller, and it's connecting externally. Those devices may not support. May not be powerful enough to run the required. Encryption, authentication algorithms, that kind of stuff. And the next one…. Access control. So they require you to enforce. Access controls for different users. Um, like doctors, patients, and manufacturers. So your manufacturer….

Uh… settings…. Things that should never be changed except by the OEM. Cannot be accessible to… to…. Your doctors. And things like patient settings. Uh, can't change. Stuff that a doctor should only be able to change. And one thing I see is I buried it in the settings. I buried it in the settings, it's not gonna cut it. That does not meet…. The FDA's requirements for enforcing the right access control, enforcing the right separation of responsibilities. Um…. And the last one, one of the most important ones. Is integrity. And this requires you to use… to…. Make sure that your device, the boundary of it, that the whole design.

Is… has not been breached, has not been tampered with. People haven't opened it up and done something. Um, they require secure boot. They require tamper resistance, both physical and electronic. And they require unique cryptographic keys. And they also require the ability to do secure backup and restore of settings. You need to be able to. Get the device back to the state that it was in from the factory. Without, uh, the possibility that it's been tampered with. And my favorite is, no one's gonna bother. People say. Well, my device is only an X, no one's gonna bother opening it up to do something bad, or.

Uh, another one is…. Well, in the instructions for use, we put, keep it in a secure area of the hospital. That's not gonna cut it. The FDA requires you to consider. The hospital, the networks. To be a…. Hostile place. It's not a safe place. Um. Alright, so…. We're also going to talk about a couple of other. Security schemes around the world that require security for IoT devices. Um, there are a couple more. So the first one we're going to talk about is the Cyber Resilience Act. So this is actually…. In the EU, and so it grants the EU member states the legal mandate to regulate cybersecurity.

And this is going to go into force. In December of 2027. And so this, um…. Applies to all products, with…. Some caveats, sold in the EU. With a digital element capable of processing, storing, or transmitting digital data. Another one of those really broad. Vague definitions that I love so much. And a direct or indirect connection to a device or network. Just another one of those great regulatory activities. Uh, the…. This doesn't apply, generally, to products. That already have their own separate cybersecurity regulations. So, the big ones are medical, automotive.

Um, there are a couple of other more niche ones that have little carve-outs for the CRA. But other than that, every device sold in the EU is going to need to comply with this. Um, all consumer devices, industrial, that kind of stuff. And it's gonna drive similar complexities and rework. To the medical regulations. I think there's also different tiers of punishment, punitive actions. Based on, like, how much they're charging, like, for violations and stuff like that, but I think medical, for sure, is like. Yes. Yeah. And like you said, um…. Way up there. Medical infrastructure, stuff like that.

The way they do all of their regulations now is, as a fraction of your revenue. Um, for the income. So, it's not, uh… you can't have large companies that are like, oh, $100,000 fine, whatever, it's a cost of doing business. Um, it's much more extreme. So we'll talk about the applicability. So if it has software, it's a digital element. If you're… if you're wondering, is this a digital element? The answer is yes. Um, the second one…. A direct or indirect connection? Is, uh, they define connection as. Using physical means through electrical, optical, mechanical interfaces, wires, or radio waves.

Uh, so this, this probably includes things like smoke signaling as direct or indirect connections. Um, so this is basically almost anything. So if you're… if you're saying, gosh. I want to make my device not require compliance to the CRA. You are trying to fly a very narrow keyhole. Um, and so I won't go through all their requirements, but it turns out they're actually extremely similar. To the FDA's requirements, the CRA. Um, they require a couple of things, like secure by default, it has to…. Ship in a configuration that is secure. And it has to be able to have those reset functions. Has to have access control, encryption, integrity, all the same stuff.

Um, they require you to limit the attack surface specifically. Uh, and they also require. Auto-updates slightly more strong than the FDA. Um, and they also require you to have strong. Clear mechanisms to disable those updates as well. Um…. Alright, so now we'll move on. To the UK, uh, PSTI. And so, it's, uh, similar, the product security and telecommunications Infrastructure Act. And it grants, uh, their regular… when their regulatory offices. The legal mandate to regulate cybersecurity, and this is actually already in force in the UK. Went into force, uh, April 2024. And it applies to products sold in the UK that directly connect to the internet.

Or that use a protocol that can connect two or more products at the same time. Um, and directly connect the internet, they'd actually define this in a peculiar way. They define this as products that use. Any of these connectivity protocols at all? Any…. Tcp UDP, that kind of stuff. So even if it's internal, you actually still fall under this. Um… and…. This connecting two or more of the devices is more narrow than the other ones, than the CRA. The FDA, that kind of stuff. It basically includes. Uh, most wireless protocols, Bluetooth, Zigbee, that kind of stuff. The only things that it excludes.

It's really trying to exclude stuff like USB. Where you're connecting directly from one thing to another, and you can't connect. To multiple things at the same time as part of the protocol. Um, and so it's actually quite narrow. Uh, it doesn't have any login intrusion detection requirements, there's no access control requirements, no integrity requirements. Um, they have just a couple of narrow requirements, is that. You have to clearly publish a fixed end date for security updates. And they have… you have to make that understandable, and once you announce that, you can't shorten it. However, that… that…. The amount of time you should patch and update it can be zero. You just have to cover that up front.

Hey, my product will never receive security updates, is valid under this law, you just have to tell people that. Um, you have to provide a vulnerability reporting program. And you have to have…. Passwords, and really the main requirement is it can't be. Part… it can't be derived from your serial number, things like that. So compared with the FDA and the CRA. The PSTI is actually quite…. Light. The last one that we're going to talk about today is the CyberTrustmark. This is the U.S. Program. Similar to those two. And so the FTC already has the authority to. Create this voluntary cybersecurity program. And so it's kind of been pushed back a couple of times. It's expected to start around early 2026. Some people will sell you late 2025. I think that's unlikely.

Um, and the executive order that put this into place. Uh, says that they will only buy CyberTrustmark-certified IoT devices. Starting in 2027, um, you know, I think. Those kinds of things have been flexible over time, so we'll see. Uh, if and when that comes into force, but that's one of the forcing functions for why people would want to. Use this voluntary compliance program for their products. And so, the…. Cybertrustmark applies to consumer products only. That are interconnected, and…. Have at least one sensor or actuator interacting with the physical world. Which is quite an interesting…. Requirement. Internet connected is defined pretty narrowly in this case. They don't include.

The same second hop, or could connect to something else. It's just, is your device talking to the internet? Um, it's, like I said, it's optional. There's no requirement that you have this. Except for that requirement that's expected to go into force. Uh, to sell. These kinds of products to the U.S. Government. Uh, sensor and actuator are actually pretty defined. They reference the NIST standard for those. And so Sensor is capable of providing an observation. Of the physical world, and an actuator is capable of changing something in the physical world. I think this actuator definition is quite broad. For example, if I store something on a hard drive, did that change something in the physical world? Because it's physically stored, um….

I don't know, but uh…. It seems very broad. Um, it's based on compliance with a…. With the NIST cybersecurity standards for the minimum requirements for IoT, and so it does require updatability, patchability. It does require logging, it has less strict intrusion detection requirements, it requires the same. Strong authentication. Access control, um, and for integrity, they don't require the same. Level of…. Compliance and complexity. As, uh, the…. The FDA or the CRA, you only have to document your integrity and how you decided to do that. But your documentation could say. We decided to do a bad job.

And that's acceptable as long as you communicate that. Um, alright. I'll hand over to Chris, talk about IoT. Sure, yeah. So, I mentioned at the beginning, Goliath is an IoT SaaS platform, so, um, you know, we have. White label, we have enterprise instances as well, especially for, you know, more sensitive applications like medical. Um, things like that. But generally, we…. Every day, I talk to devices that are cellular Wi-Fi, Bluetooth, all of these different things. And these are all usually, you know, in a consumer context, usually called IoT, but if you go to the next slide. Uh, I usually just call them connected devices, and that is kind of.

A relevant thing in this discussion here, because. As Mark said, it is much broader than just. The traditional IoT things, right? Usually it's…. When I define IoT, it's usually, you know, a fleet of sensors that might be spread out over a factory. A field, depending on your application space, they're all talking back to the cloud, you're collating that data in a database, then you're using that for some kind of collective intelligence for. You know, tracking trends over time, or taking action based on that. So, like, you know, we have…. Many users that are doing things like. Hvac monitoring, temperature, coils, coil currents, things like that. But ultimately, it's to….

Save money, it's to introduce new features to users, things like that. In a medical context, it's often much broader than that, and it's more of the. Goliath being a device management solution as well, usually those sorts of things start to get into that space as well. So, Goliath being a platform that can. Talk down to the various types of devices that are out there, but then do other things like. Over-the-year updates, command and control, collecting data, all of these different things here. So, next slide, please. One thing, uh, I'm a hardware person myself. I do a lot more firmware these days, and I am very capable of connecting things to the internet now.

But, you know, thinking about me from 5 years ago to me today. Um, you know, in the past, 5 years ago, me would have just been like, well. Look, there's a modem on board, I'm set, right? I've got a Wi-Fi modem, a cellular modem, a Bluetooth module, whatever it is. Uh, it's just not enough, right? If you need to do all of the things that we're talking about here, you really need to be pulling all these decisions forward, and be thinking about them. At the beginning of your process, as you're planning out your, you know, your entire system architecture. Because often, the ability… you know, it's not something you can just kind of.

Chuck over the wall to the software folks, or even just the firmware folks, you need to really be thinking about, how does my cloud talk all the way down to my device? And I'm not just saying this as a, you know, person who works at a cloud company. You know, regardless of what service you use, you need to be thinking about how you're going to be structuring all this stuff. How you're pulling in all these features in order to make an accessible device. Especially when it is a constrained device, right? So something super low power, something that is, you know, cost-constrained, that sort of thing.

The complexity is often lurking below the surface. And as Mark and his whole team could tell you, it's the things you don't know about that are really gonna… really gonna bite you later. And so thinking about an IoT system, you need to be thinking holistically, you need to try and prototype all the way up the stack, all the way back down. Uh, especially so that you just… you understand kind of where the pitfalls are. Next slide, please. One thing we've been kind of talking about here is kind of IP devices, right? So, like. Like, uh, Mark Slides talked about, uh, some of the regulations talk about things that are kind of on the broader internet, or even on.

Private, um, you know, VPNs, things like it. Those are talking over internet protocol, right? Udp, TCP, all of these different layers of the stack that might be. Uh, there. If they're talking back to, for example, a cellular device, a Wi-Fi device that's talking back to the Goliath Cloud, those are IP devices, I can directly talk to them. Um, you know, either public or private IP addresses, you know, depending on where they are in the ecosystem. But, um…. These are what I call IP devices, and it's…. Uh, that's really gonna be… if you're… if you're on the broader internet, you know, not just saying you have open ports for everything that anybody can talk to you, but even, like, a cellular device, I could, uh, it has a private IP address, usually.

Behind a cellular NAT server, and I can't necessarily tunnel to that and see that. It's not like it's out there. But there's additional scrutiny overall, because you need to then kind of. Get out to, uh, an additional server from there. And so. That's really something you need to be thinking about if you are at that level. I have the feeling that, you know, just from the complexity. Of the medical space, it's not as common of a thing, because then you have to deal with. You know, cellular data plans, you need to deal with IT groups inside hospitals, um, you know, really, it does…. Ramp up your complexity even more. And so that's why, at least from my experience, I've seen a lot of, um, you know, connected devices that are.

Bluetooth devices, that is a much more common thing, um, that I've seen in the medical space. Obviously not. True across all devices. Next slide, please. So, non-IP, right, this would be things that, uh, do not… are not directly accessible. From an IP address, um, you know, so something like a Bluetooth device is a good example. It has to talk through a phone, it's that second hop, like Mark talked about. But that then adds additional complexity when you are trying to add other features, right? So now you're trying to push. A firmware update down to a Bluetooth device, well, first you have to push to the phone, and then the phone has to push it down to the various devices that are there.

And so, this is actually a new paradigm that Kaleid's working on, really just thinking about non-IP communication. So, it doesn't have a direct IP address… it doesn't have a… it's not talking over IP, that's fine. But, you could still implement a lot of these updates, you can. You can still talk over the wire. For connected devices. These are still connected to the internet, as the definition says. But, uh, this new pouch paradigm at Goliath basically allows us to talk to things that are like Bluetooth, or. Cereal, or can, or all the different things that are out there that are not necessarily IP.

But they are still connected back to the cloud somehow, often through that second hop, and so we can start thinking about it and how we. Implement some features that make it easier to comply with a lot of these regulations, things like. Over the year updates for firmware updatability, and things like command and control, and. Collecting data, so all of these different things there. So, um, this is just something I wanted to mention because, you know, if you start thinking about it. Um, if we just accept the fact that connected devices are connected regardless of whether or not they're IP. That you could start to implement additional, both cloud and device-side capabilities.

That make it easier to comply with regulations later. That when you come to the documentation time, you can also start to point to these capabilities and say, hey, I can update this, even though it's a Bluetooth device, or even though it's a CAN device. Because I have A, B, C, and D in place. I think that's it on these slides, I think it's under the, um…. Oh, we have this one more, the what this means for you. Is that it, Mark? Oh, yeah, got it, got it, got it, yes. This is the point I was already making there, but, you know, basically, if you want to. Lower your operational overhead. Thinking about this sort of thing, this not, you know, accessing non-IP devices, having some.

Some, uh, schema, some paradigm for talking to them, being able to update them. I think updates are probably the most important thing in this context. Probably the toughest to do end-to-end. And thinking about that up front is really going to save you a lot of headaches later, because. Building that custom from scratch, as we're going to talk about here in a second. That's where you really start to, you know, the… how hard could it be? Uh, very hard, is the answer. And you don't want to figure that out 3 years later. Um, alright. So we'll talk about…. Some examples of what happens when you do it yourself. So I think if you're an engineer who hasn't worked on this before.

Or, if you're working with some engineers who have not worked. On these kinds of systems before. Like Chris said, it's actually surprisingly challenging. It's… it seems so tantalizingly easy to add these features yourself. We'll just implement them, we'll design them, that kind of stuff. It's actually… these… the complexity of adding all these features. Can often exceed the complexity of your whole device itself. Um, and so we have some examples about. When people did it…. Did a bad job, or did it themselves, and what those implications and outcomes were. Um, and we have a mix of mostly medical devices, but also some other IoT devices, to get a little bit broader scope.

So the first one is the, uh, some of you may be familiar with the Abbott. They have these RF pacemakers, and so these are, you know, implantable Class III devices. And they ship these without, uh, uh. A path for a secure update. Um, this wasn't really part of their…. Design, it wasn't considered in their implementation. And so, um…. They had about 465,000 of these implanted in the world. When these vulnerabilities surfaced. And these vulnerabilities allow, uh, could allow people to remotely change settings, disrupt them. Cause serious patient harm. Um, and when they did these updates, they had to be done.

In a clinician's office or in an inpatient setting. On a cardiac monitor, and one of the reasons for that is because they evaluate… there's a 1 in 30,000. Risk of complete functionality loss to the device doing this update. And so, for those of you doing the math at home, that means that they expected 14 of these across their fleet. 14 of these implanted devices. To completely stop working. Um, and, uh. You know, if you're talking about. I implemented… I didn't implement firmware update, or my firmware update process wasn't tested. And all of a sudden, now 14 people have to have surgery, uh, or could have a serious risk of injury, just from your update.

Um, then, uh, you know, that's a really…. You're not doing a good job implementing secure update. Um. Yeah, I always think about, uh, the fact…. You know, I… I'll ship something out, it's, you know, out in the field somewhere, it's like, oh, I gotta drive out there. A little bit different than if you have to, like, you know. Open the chest cavity, yeah. Get it out. Yeah, right, yeah, that's a… yeesh. So, just as a reminder, this is the regulatory need, right? Devices must detect, recognize, log, notify, and respond to anomalies during. This looks like…. This is the wrong one. Sorry, this is… this was copy-pasted wrong, my bad. This is basically the ability to update. I must have, uh….

Oh, yeah. Copy-paste the wrong one here. But, uh, but basically, you need to be able to send… secure… securely send updates down to the devices. And, uh, basically. At Goliath, uh, we have an OTA service. This is something that is part of our device-side SDK and our cloud service. So, uh. You know, you go and try out the Goliath firmware SDK, you put it on your device, it's…. Basically already there, registering, listening for updates. The Goliath Cloud says. If you register with version 1.0.0, you know, up to the cloud, and now 1.0.1 is available, it'll send a notification out of the device, the device then starts to fetch.

And, um, you know, just the ability to do that, this is often a thing that people. Say, I will get to this someday, and often it's at the end of a project, and it can be detrimental. For thinking about this sort of thing. And so thinking about this with both a, um…. You know, not just a, you know, a cellular device, a Bluetooth device, a CAN device, anything across the range, even, you know, a serial device. The ability to go as soon as it plugs in, as soon as it talks to anything, it's able to go and query whether it has the latest, whether it's been updated. And we have something called cohorts to be able to do, um.

Groups of devices. So, you know, you might have a set of test devices that don't want to get the latest firmware update because it's still in test. That's fine, you can mark certain devices as the test group, or then more widely roll them out to all devices. It is all based on versioning. And then, in terms of how it actually. You know, make sure that it is a good update. It uses something called MCU Boot. On Zephyr, at least, and, um…. Pulls down the binary, puts it into memory. Tries to boot up, if it doesn't work, it reverts back to the last one. Um, and so, uh, there's also support for signed firmware images, we'll talk a little bit more about that at the integrity.

And I… and I think one of the things to go through is you have the. Group of things. You can do a slow rollout of your updates as well, right? And that's, yeah, that's a…. That's right, exactly. Yeah, so you could have…. Yeah, stage rollouts using cohorts, that sort of thing. You can… it's all scriptable. So basically, if you had a thousand devices, you only say the first 5 are going out to the test group that's in the lab. And then the next 20 are going out to the group that. You know, within a known beta tester group that have opted in, that sort of thing. And I think one of the things is, uh. Though we've seen with people who do firmware update as they roll it themselves, they get it out.

And without those kinds of features, that slow rollout. You can press a button, deploy to all 1,000 devices. And only then realize there's a problem where it breaks your firmware update or something like that, and now you…. Right, exactly. That's right, yeah, yeah. You've broken your whole fleet all at once. Um…. Yes, test, test, test. That is… that is an important piece there, and there's a lot of tooling around it as well, in terms of. Automation and, you know, but ultimately, you need. You know, your engineer's looking at it, double-checking on things, you know, both on… from their own code, but also from just the.

The deployment and making sure that everything's healthy as the…. The OTA rolls out. And OTA, just again, is over the air, sorry about that. That's over-the-air updates, firmware updates, effectively, yes. Suresh? And so next we have the logging intrusion detection. So, Vertica is a camera IoT system. And I like this example because they had attackers access more than 150,000 cameras. You can see a tweet here from one of the. Attackers, here's a screenshot of a camera in Cloudflare's HQ. Um, and uh, so they had… they didn't have any anomaly alerts. Um, they didn't have the right reporting to detect this. And, uh, so they're… they… they figured out they were under attack when the screenshots hit Twitter.

And I hope that none of you guys find out that your devices are under attack from Twitter. And this is… this is one of the reasons why. This kind of logging intrusion detection is so critical. Um, you know, we…. The FDA wants you to, uh, end the…. The EU regulatory Authority, the FCC, they want you to know early and often if something's gonna happen. Nothing's ever perfect. Um, and that's the reason why. They want you to detect this stuff, they want you to be able to rapidly create patches, update, that kind of thing. If it takes you a year to walk out to every hospital and update stuff, you're not going to stop.

A, uh, an attacker. Yeah, I believe the CRA also has a, um…. A reporting requirement back to the central authority as well, that they're still working through. Yep. Absolutely, yeah. Yeah. Yeah. Okay, so this is the correct regulatory need. They must detect, notify, log, notify, and respond to anomalies during normal operation. Alright, there we go. Um, yes, and so, in terms of things that we have available, um, you know, obviously not the only ones out there, but logging, so we have a logging subsystem, basically. So, if you have a Zephyr device, like this is a Zephyr device right here, uh, Zephyr has a logging subsystem there. You can actually tie that into the Goliath backend.

We then compressed that data, we send that up to the cloud. So, much like you might have logging go out to a serial port, which you. Are definitely turning off in production, because you want to make sure you're secure there. You can also have that logging sent up. Cloud, you can then also turn it down so that you're not sending as much data. You can selectively say what is or isn't sending data up to the cloud. That's from a, you know. Warning, error, debug, um…. Info logging kind of paradigm there. But, uh, that's one way that you can do logging and intrusion detection, just, am I seeing anomalies on different devices? You can then.

Send that out to other services, you can just look at the device records and say, this device here had a particular debug error that's unexpected. I might go and take action on that. Probably more likely, though, is something like a custom pipeline. So, Goliath also has the idea of a stream, so a device might be streaming normal sensor data up, right? If this is just a temperature sensor, it might be streaming the temperature up to the cloud. Well, uh, you might also have something like a light sensor on board, and when the case has been opened, you can detect light onto that sensor, send that on a different.

A different path that we call it, so, like, a topic, but really a different path. So you might have just a. You know, a path like. Like detected, you send that data up to the cloud. And then you could start to take action on that, right? So that pipeline, you then set up a pipeline so that can go out to different notification services. You could do, uh, you know. Collate the data over time using AI services and things like that for anomaly detection, but ultimately, you can have different paths of sending different data, maybe normal and out-of-band. Type of data, and then you can take action on that on the cloud side.

I think it's so important to look at this data and get it out into other services, and that…. And all those integrations, that setup. That's all so challenging, and lots of people are like, oh, it's only one more thing, one more thing, and…. Yeah. Well, if it takes a week to do one more thing, and you have 10 one more things, all of a sudden, you're mishing your ship deadlines, you're missing your regulatory deadlines, that kind of stuff. Yeah. Yes. Yeah, on the pipeline side as well, really, that is, like, uh. I kind of think about it like a switchboard, or like a, you know, kind of directing fire hoses towards different places. You might be sending it to a.

You know, Amazon queuing service, right? That's a common destination for data that's flowing out, just like that temperature data's flowing out. Through the Amazon queuing service for the normal type of operation, but in, you know, the out-of-band type of thing, like, you detect light on a sensor and it goes to the out-of-band path. Well, that might go to something like, uh, um…. Oh, I forget the… you know, like a webhook. Out to a notification service, that sort of thing. And then you can immediately get a phone call, get a text, get a Slack message, all of the different things that you can do for immediate action.

And I hope your immediate action doesn't come from your Twitter, so…. And that's all configurable cloud-side with pipelines. Yeah, right, don't send it to Twitter. Alright, so in other words, authentication. So, the Medtronic MiniMed insulin pump. And I kind of did them dirty. This is an image of their newer product. I didn't… couldn't find any images of their older products. So these… these remote pumps had an unauthenticated RF interface. Um, and so, attackers could silently overdose on insulin. There are some details about exactly when and where and how. Um, but it was definitely common enough. That the FDA.

Issued a recall with around 64,000 units affected. Um, and the core reason for this is because they did not have. The proper authentication, they did not have the proper. Anti-replay, they did not have the proper, you know. Connectivity to make sure that messages were only sent by an authorized source. And so then, you could silently. Overdose on insulin, you know, issue 100, 1,000 times. The… the recommended dose and cause the potential for serious injury and harm. Uh, to your users. Yep, so mutual authentication and NIST-compliant encryption for all external communications. I think in this case, I mean, like, that example that Mark just said is, like, there was… that was just an open channel, right? Basically, that was, like, someone was….

You know, re-hitting the garage door kind of button, that sounds like what that was. Yep. That's, uh, kind of a true open channel. So not that common, but even, I think. As you go, you know, as you kind of move up the stack, you send, uh, you know. Broader and broader communication. Command and control back down to devices, you need to have even stronger encryption, because it's just on the… on the broader internet. And actually, one of the many met at some other ones, they had some examples where even they had strong encryption. But they didn't have, uh, uh, what we call this anti-replay. So you could….

Yeah, replay attacks, yeah. Get this… get this same… you record a message, very similar to garage… some garage door attacks. Yeah. You record a message that says, oh, administer insulin. I just play that back. 20 times in a row, really fast, and all of a sudden, I've done 20 times more insulin. And even though that message was. Yeah. Signed and authenticated. There weren't the proper mechanisms. That NIST, you know, really smart people have thought about how do we prevent these kinds of attacks. So you can't play the same message over and over. Yeah. Yeah, you talk to a security researcher, first thing they're doing is a replay attack. Like, that is, like, the beginning of their toolkit, for sure, and uh, yeah, it's….

Yeah. Uh, so in terms of what we do, basically, you cannot, you know, so say you are a device talking to the cloud, um. In this case, this is a cellular device, for instance. This cannot talk to the cloud without it being encrypted traffic. Basically, every packet is. Is encrypted. There's no way to peek into it unless you have the keys for that. And we have both PSK support. This pre-shared keys, that's, uh, mutual, and then there's certificate support as well. We are working on. Asynchronous. Asynchronous, sorry. Uh, but we're working on some even more complex stuff as well, and we do work with PKI providers.

Basically thinking about this where, you know, you want to be, you know, again, use Goliath, you don't use Goliath, you want to make sure that your traffic is encrypted. I once talked to a cellular provider, and they said, well. We don't encrypt our packets because, you know, we're on a private network for cellular, and we want to save data. And it's like, okay. That's great, but that's actually not… like, it's not that hard to view cellular traffic. Not common, but it's, uh, it's not that hard to do that, and, uh, and then once they get through these various layers of communication. If you get to the end packet, and that's just not encrypted at all, that's basically leaving the front door open.

Um, and so, um. Yes, we are, uh…. Definitely very focused on security and making sure that everything's sent up that is encrypted. You know, I mentioned the non-IP stuff as well. We, um…. We have some certificate-based auth on Bluetooth devices, so again, you can rely on something like a secure Bluetooth channel. We're actually not even. We're not, uh, relying on that. We're saying that a packet sent from a Bluetooth device through a standard gateway up to Goliath. That first packet has to be encrypted cloud down to device. Before it can be sent for all these channels. That's really what Pouch is doing. Pouch is wrapping it up with an additional layer of encryption. It transits through trusted or semi-trusted gateways all the way up to the cloud.

But because the cloud has the keys, and the device has the certificate that was generated from those keys. And again, we don't own those keys. That's something like a PKI provider can hold for you. Ultimately, that is… that piece of device that's transited through. Trusted or untrusted all the way up, it's still encrypted from cloud to device. Uh, so the next one we talk about is access control. So the…. This is the contact CMS800, it's a. Patient monitor, and. What happened was network users. Permissions. We're not locked down. They weren't restricted to. Only what should be able to be accessed. They weren't restricted to accessing.

The things that were required. They allowed you. To, uh, get access, unlimited access to the machine. And then, using those credentials that were only intended to be used for. A limited set of functionality. You can now export patient health information. You can now remotely control the device. You could upload new firmware that lied to the providers about the patient's health state. Um, and this was actually subject. Of an urgent, coordinated disclosure by CISA, uh, and the FDA. I sincerely hope that none of you have your devices be subject to an urgent coordinated disclosure. Urgent, yeah. Yeah.

Of CESA and the FDA. Um, that's a…. You did have a bad time. Yes, and so you must enforce access controls for different stakeholders. And, you know, this device, the…. The contact device specifically, um, you know, basically having full permissions, uh, for any user that's a no-no, but even… even just thinking about what your device can do. Um, is… is potentially problematic. So, device side, most of the time, you know, say you had a connected device that's on Goliath. But you had, like, an admin menu on it, you know, maybe a little screen. If you have no, you know, limited controls there for the UI, for whatever the button interface is there.

Ultimately, that is for the device manufacturer, right? You have to have some kind of way to do that. There's nothing that Goliath does on that side of things. But we do have what's called Setting Service, and so if you wanted to basically have everything locked down. Until the cloud side talks down through the various layers to the device and says, only unlock. When the cloud says it's unlocked, because you have some kind of, you know, maybe the keycard scan, or you have a…. Device-side password, or some kind of other… other authentication mechanism. That's for the user, based on their permissions, right? So, you know.

Dr. Jones is, uh, you know, trying to access the IP stack on this tiny device here. Well, he has to go to his. You know, Microsoft Server to say that he's allowed to do that. Then it talks to Goliath, then it's…. Unlocks the setting all the way down to the device, right? That is…. That's one way you could do that sort of thing. Yeah, go ahead, Parker. I was gonna say, I think it's actually extremely common for, um. Technician access, where you say, hey, uh, the technicians, they come into the hospital, and they authenticate. Yeah, that's a good one. Right, right. Separately, through the cloud, and push down to the device. So that way, you know that your technician is on-site, standing in front of it, and then you.

You can centrally distribute that access, um, and under no other circumstances are you allowing. You know, the kind of service access that might cause patient harm or change settings, that kind of stuff. Exactly. Right, right. And one thing I've seen in the past is, like, well, we put a password on the admin menu, right? It's like 1234. It's like, okay, well…. Uh, that's not, you know, that can be shared, there's no actual, like, check that it's going back to the database that this person is. Has authenticated to a truly secure service, that they're part of some kind of Active Directory. There's nothing there, right? It's just a 1, 2, 3, 4, and that is not enough. And that's, again, that comes to the device manufacturer, what they implement there.

But then you could push down from the cloud and say that sort of thing. In terms of who can actually auth…. Authorize this to happen, right? Goliath has API keys in order to control the REST API. That's ultimately going to be how a lot of. External applications are going to control devices out in the field, and so we have, you know, a full API key scheme in order to securely manage that sort of thing. You can reject keys. And that, um, you know, for different apps and devices, and have different levels of. Capabilities on the cloud side. But, uh, you know, if you wanted to have a…. Doctor who had a… just a…. Normal phone that's talking backup to the cloud, and then maybe down to the device that's sitting next to them.

That is, you know, the fact that the doctor can. Can or cannot activate a pump that's sitting right next to them. That is up to the maker of that app, right? They're checking the Active Directory, they're checking the user permissions for that sort of thing, and then because that app. Has access to the REST API through the API keys, then that sort of thing is transited. And I think it's always going to be this kind of. Multiple layers, multiple stakeholders, software, firmware, app developers, all of these things. You need to be thinking about this. From the Goliath perspective, we're from the cloud down to the device.

And if someone has an API key for the Goliath Cloud, and they know which device to talk to, they are allowed to do that sort of thing. So the last one is the integrity, and this is actually one of the most important. Parts of it, because if we don't… if we can't trust ourself. We can't trust…. We can't… we can't know that we've done a good job implementing all the other things that we trust. Um, so, uh. Hrk Vision has…. They, uh, a fusiker, they had this. Magic string that was included on their devices, and it allowed you to bypass the authentication, the firmware signing. And as a result of that, hundreds of thousands of cameras.

Were hijacked for botnets, and this required owners to manually go to the camera. Unplug it, reflash the devices. Um, and in order to remediate and send it out. And it's really…. An example that's so important about why. This kind of integrity is important. This is an example of a, like, digital integrity, where we need to make sure that you can't. Load new firmware, like this enabled you to do. That lets you do bad stuff, things that you never intended. Um…. And, uh, you know, this is just kind of one of those aspects of integrity. Yeah, I think just on the, um, you know, one of my earlier points, too, of, like, it's not just the hardware, right?

I'm sure, you know, it was not done maliciously, but I'm sure at some point, right, the hardware maker, right, might have been separate from the software maker, and they said, well, we need some way to change. All of the admin settings, so they put the string in there. Who would ever find this? You know, who would ever decompile the firmware? Who would ever do this sort of thing? And the thing is, if you don't take it out, if you don't have it out, if you don't have this, if you're not thinking about this full end-to-end. How things will be used at the beginning, it can be really. Problematic. So the need here, you must support secure boot, tamper resistance, unique cryptographic keys.

And secure backup slash restore. In terms of, uh, how Goliath does this, so, you know, Goliath, uh…. Requires a, uh, unique device record, so in terms of, like, unique cryptographic keys, you can't have multiple devices. Sending on the same, uh, the same. Certificate of the same key, that sort of thing, that just…. That won't, uh, work there. In terms of, uh, secure boot. Goliath doesn't actually, uh, enable Secure Boot, because that is up to the device manufacturer, but we can send. You know, we can send device firmware packages down over the link. It will be encrypted all the way down. We can….

And that can be the firmware image itself can be encrypted so that Goliath never has any knowledge of what's going on inside that firmware package. And ultimately, it's up to the device maker to validate it on boot, right? We can load it in… we can help you. Show how to load it into memory, but then when it reads it back out of memory to boot up, you need to do, um. To do key checking and that sort of thing on that image. So, really, a lot of this stuff is up to the device manufacturers. Uh, in terms of, uh. The ability to restore. I mentioned the setting service as well. When a device boots up.

It will actually go out and query settings, you can just set those all back to default as well. So there is, uh, audit and, uh. And I think one of the important parts of TakerD is not just. Persistence of settings across time as well. On-boot self-integrity. You have to get your firmware updates to the device with integrity, and have. Make sure that those channels are… are encrypted, and make sure that they're authenticated and all those things, so…. Yeah, that's right, yep. Um, yeah, so I think we have time for a few questions here. Um… let's see, I think…. The… you know, yes. Does a cyber trustmark consider. Medical devices for home use as consumer devices? And the answer is….

Kind of know with an asterisk. Um, the Cybertrust mark has a specific carve-out for medical devices regulated by the FDA. So, um, uh…. However, lots of devices. May not actually fall under that category. So if you're talking about home health. Or support, or wellness. Um, those devices. Will fall under the CRA if there are, uh…. Not the CRA, I should say, the, uh…. Ctm? Of course. Cybertrustmark, if they are… if they are, uh. If they are, you know, connected devices. Um…. Let's see… I think there's a…. And that would be, like, someone using, like, a therapy device, a therapeutic device, you're saying, that isn't….

A question about…. That's exactly right. Class 1, 2, 3, what I, uh…. Yeah. Yeah. I think there was a question about, um, you know, is Goliath. You know, like, what kind of solution? Uh, is Goliath, you want to talk a little bit about that? Sure. I mean, Goliath is a… primarily a cloud solution, and so…. If you look at, you know, kind of under the hood, often devices are talking back. Um, again, securely up to our co-op. Co-op backend, um, so they're DTLS encrypted all the way up, and we offer these different endpoints and services on the cloud side. Now, in terms of. Me as a hardware person, that's not that useful to me, because I would have to go and re-implement all this stuff. Collab also has a open source.

Firmware SDK, which basically gives both examples, but then all of the tooling that's necessary to actually… for device makers to go and. Talk to those cloud-side services, because that's really critical. If you just have the cloud-side services, okay, okay, I gotta go rewrite all this stuff. Uh, you know, in Zephyr or, you know, FreeRTOS or similar. That stuff is all, uh, open source, you can go and do that right now. But, uh, often you'll see. You know, you'll see lots of examples from me and my coworkers showing a device talking end-to-end. So, for example, this is a… this is a cellular device, this is the Thing91X.

This thing on day one has over-the-year updates, it's able to stream its sensor data up, I can. You know, turn LEDs on and off using our setting service. I could send commands down to the device using something called. Remote procedure calls, and ultimately, this is a, you know. Example hardware like this, talking up to the cloud, kind of shows you that full end-to-end device-to-cloud, and then whatever you want to do with that data once it's on the cloud. Yeah, I think, you know, there's another question about how important is the physical tamper resistance for devices. It's actually quite important, because. If you can't trust the hardware you run on, all the software in the world isn't going to save you, so, um….

The FDA likes to see that you have, uh, tamper-resistant seals. Over the openings for your device to make sure that. Your clinicians, uh, you know, your technicians can tell. If something has been tampered with. Because ultimately, you could always open the box and replace everything. With your own hardware or software that's… that could be harmful. Um, and so…. Yeah, exactly. The nice thing is it's… it's…. The ship of Theseus hardware, huh? Versus everything else we've talked today, it's by far the easiest. You tell your manufacturing engineers, hey, we gotta put these stickers over everything.

Yeah, right. Um, so, uh, that's, uh…. That's… that's the best remediation, uh, you know, versus we need to redesign it. I do think, uh…. You can also have various forms of intrusion detection as well. You could have it both on firmware side, but even, like I said, light detection. Once the case is buttoned up, as soon as it sees light, it means somebody's probably in there, they're similar, you know, switches, there's a…. You know, a whole field of tamper…. Actually, there's a whole, uh, section at DEFCON of the tamper-resistant Village, I believe, and, uh. Yep, yep, the tamper village. Basically, yeah, trying to bypass that sort of thing from a, you know, a reverse engineer context.

But you could go there and learn what does and doesn't work as well. And so…. You could, uh, start to…. Start to implement these things, and it's kind of like door locks on your house, right? Not every lock is going to keep everybody out, but if you start having this connectivity in there as well, you can also tell. When that door lock has turned, and that might be enough from a…. Being able to tell that there's been something, some kind of. Bad behavior, and then either discounting that data or. Uh, you know, sending someone out to fix it. I think, you know, maybe our last one for today is, uh.

We asked about how does the CRA apply to medical devices? And, um, I think the answer is the CRA does not apply to medical devices that are under the. The MDR, the European Medical Device Regulations. But the same kind of carve-outs apply, where. If you don't fall under that as a therapeutic device, something like that, um, they do…. They… you are required to follow the CRA guidance. Or, for example, some people cross-list products. As both recreational and medical devices, those kind… that kind of thing, so…. Thank you both. Um, we're about out of time. We're gonna try to respond to the remaining questions, uh, via email from.

The speakers, and… let's see, um, if you forgot to request your certificate of attendance, please. Um, drop that into the, uh, chat with your name and email address, or send it to me at. You know, through… through LinkedIn, um…. And I'd like to thank both of you, uh, for an excellent presentation. I learned a lot. I hope everyone else did, too. Please take the survey, and remember to subscribe to MedTech Leading Voice. Gentlemen? Thank you for your time. Thanks, everyone. Good being here. Thanks