What the FDA Wants in Security Architecture Views for Devices | Ep. 29

Chapters

1. 0:00Hello and welcome back to the Med Device Cyber podcast
2. 3:28Uh, typically when we're talking about architecture views, this is coming from
3. 6:58So, I think that it the software documentation does lead in as
4. 10:26I think you referred to the mobile app as a companion app
5. 14:04That's further expand further expanded upon the updatable ability which I don't
6. 17:29This is what each of these components is responsible for
7. 20:51And I think that's why the FDA wants us to focus on
8. 25:07So I I don't I don't think the FDA has that looks

Hello and welcome back to the Med Device Cyber Podcast. We're going to be talking about a very interesting topic today, looking at device security architecture. So, we're going to go into how we define the scope of a device, how we're considering security on all these entry points, these internal components, and then looking at what the FDA is really concerned about as far as any specific use cases and how we're addressing security there. Joined by our co-host Christian Espinosa. How are you doing today, Christian? Christian: I'm pretty good. A little bit jet-lagged. I traveled about 20 hour, 28 hours, uh, this weekend. And I haven't slept much, but it's all good. Trevor: Have the same flight, but I got in on Friday, so I got to recover this weekend. You got in yesterday, right? Christian: Uh, I got in Sunday night. So... Trevor: Yeah, yeah, that's a little bit rough. Christian: Cool. Yeah, I'm excited to talk about, uh, this topic. And I know the FDA defines the security architecture reviews, there's four of those, which are commonly misunderstood. So, um, how are you doing? Have you recovered from your jet lag before we jump into the topic? Trevor: Yeah, I have my secret patented recipe for avoiding jet lag, and it's don't sleep for 48 hours during the flight process. And then you're so tired when you land, it doesn't matter what time it is, you'll just wake up. So, and then a healthy dose of caffeine throughout the day to make sure that I don't break the pattern. Christian: Yeah, maybe I should try that. I just had a nitro cold brew. I finished all of it, so. Trevor: There you go. Yeah, so with these architecture views, there are four main ones that the FDA wants to look at, and we'll get into each one. First is the global system view, what is the device? Next is the updateability and patchability view, how are you providing software updates to the device? And then we're looking at multipatient harm view. So what situations can lead to multiple individuals, multiple products, multiple systems getting harmed with one attack? And then secure use case views, which that one is, I think, the most difficult one to really fully wrap your head around. That's when the FDA wants to see, you have all these different use different states for the device, different functionalities, different process flows, and how are you addressing security for each one of those different areas? Uh, typically when we're talking about architecture views, this is coming from software documentation terms. And software documentation is usually going to be more mature than cybersecurity documentation. And I feel like this is where a lot of engineers can get a bit confused with the distinction. If you say architecture view for software, it's purely what is the device? How can we outline a data flow diagram, an architecture diagram? The architecture diagram is all the components, what's the barrier for the device, where do we consider something to be out of scope versus in scope for the device? And so I think that that can be a bit of a misconception that leads to a lot of confusion when building out this cybersecurity documentation is that the terms are used interchangeably. And it's something that can be not just confined to architecture documentation, just having these interchangeable terms throughout cybersecurity and software, but I think that personally that's a big area that leads to efficiencies coming up or any problems with this documentation. Christian: Well I think the clarity needs to be around the FDA specifically defines security architecture views and those four, four, four views you mentioned, which is very different than, like you said, a typical architecture diagram for a software or device, for a software or device. Trevor: Right. Yeah, and I think the further that we can divide the two terms and so saying security architecture views, often times it'll just get abbreviated to architecture views when handling the documentation. And then architecture diagram, architecture views are close enough that there can be definitely that misconception there and a little bit of confusion. Um, but yeah, I agree. The more that we have that distinction, the better. Now where it does sort of blend in is when we're looking at that first security view. That's that global system view. That's going to actually be fairly similar to an architecture view under a traditional software scope. We're looking at what is the total scope of the device, what is each component within the device, and that helps us build into some of those further discussions on what are individual use cases, how can we harm multiple patients, what's the interoperability components. So I think that the software documentation does lead in as a very valuable first step to the cybersecurity documentation. Christian: Yeah, so you're saying the, the, the FDA security architecture review that's the most, I guess related to a typical architecture reviews is the global system view. So that's there's four of them, and that's the one we're talking about now, the global system view, which does include the overall architecture, but includes more than just that. It's the internal components, any connections to a cloud service, a mobile app, and also the update infrastructure. So it's like the whole view of the system, right? Trevor: Exactly. And this is, you know, this leads into it could be its own conversation entirely, but defining what is the scope of your device. Uh, often times you'll, it's a very common situation now to have sort of a three-piece suit with a medical device, medical device connects to a companion app, that companion app connects to a cloud service in AWS or in Google Cloud provider, whatever it may be. And so where are you drawing the line, what is the scope of the device? Is the phone that the mobile app is sitting on part of that scope? Is that going to be something included in the global system view? Is it just referenced as an interoperable component? But I think that a lot of manufacturers will just draw the line around the device when it needs to include, like you mentioned, the update infrastructure, these cloud components, any additional accessory apps. Uh, we also need to talk about what's going to connect to the device. So we'll say this app can sit on a mobile phone. Do we have to address the mobile phone itself as far as security? That's out of scope. That's going to be handled by Apple or Samsung or whoever's creating the phone. But how are we interacting safely with it? How are we interacting with a printer that the device can connect to or to a workstation that it can connect to? So we need to reference these as part of our global system view even if we don't necessarily have control of them. We need to figure out what we do have control of. Christian: And with the global system view, you talk about the three-piece suit, the, uh, device, the mobile app, the cloud, which is very typical. I think you referred to the mobile app as a companion app. The update infrastructure is something that I feel is part of a global system view, it is, but it's often completely overlooked. So you want to like expand upon that a little bit, and I can give you my opinion as well. Trevor: Totally. And this will tie right into the next view that we have to cover that updateability and patchability view. But the FDA wants to see the total product lifecycle security considerations. This is start to finish. So as soon as you have, you know, the idea for a product, as you're developing it, as you're designing the product, you should design security into it. Moving throughout the full lifecycle all the way down to decommissioning. And at some point between those two areas, we have to talk about what if we need to make a change to the device. The FDA wants to see devices are able to be updated, able to be patched in the field in case of a vulnerability to prevent the need for like a total recall or some major drastic change and major difficult process like that. If we can make a simple software update, removes the need for a lot of complicated, uh, recalls and collection and security advisories. So, even still, we need to figure out how security is addressed there. What if there is a malicious insider that's tampering the binary going out to the device? What if someone can hack into the update server and change what gets sent down to the device? What if someone can intercept the connection and see exactly what's being changed and then make their own changes? There are a lot of things that can go wrong with an update process, even if you don't have remote infrastructure. If a service technician's doing it on site with a USB stick, what if they go to the bathroom, they leave that USB stick unattended, someone changes what goes on to the device. All of these different problems need to be considered when we're looking at that total product lifecycle. And so, however the update procedure is handled, you need to address security with it and make sure that you're covering all of your bases depending on your specific implementation. Christian: Yeah, this is an area I feel like, um, there's not enough scrutiny in even by the FDA. I, I feel like the biggest concern with this area, we've seen this with some of our clients is a lack of a secure environment to develop the update and push the update to the device. So, many we've had clients that their update environment was connected to their corporate network, which made it inherently insecure. So, I I don't, I don't think the FDA has, looks at enough scrutiny as far as the environment which pushes the updates to the device. I think they focus more on, like you said, a CRC or some sort of hash to make sure that the update has integrity. But if the update is is compromised at its source, the integrity doesn't matter because you're verifying a malicious update basically. So I mean what are your what are your thoughts around that? Or am I going too deep in the rabbit hole on this topic? Trevor: No, it is important to think about. If we're looking at the manufacturers' environment themselves, it's still part of that total product lifecycle. It's the end-to-end security considerations. And so if the manufacturers' environment is inherently insecure, unsecure, I feel like we go back and forth on this every time. Christian: Well, I I prefer unsecure, but you called me out on it one episode and said it's not actually a word, but since we're talking about updateability and patchability, maybe we should go back to unsecure. Trevor: Yeah, I think we can, if the FDA can make up words, so can we. We'll, we'll go with unsecure. So if your development environment's inherently unsecure, then it's very easy for risks to get introduced into the system. We see a lot of different compromises across all sorts of different industries. We've seen major casino hacks, we've seen healthcare infrastructure hacks, finance systems, um, even, you know, critical infrastructure, oil pipelines, things like that. And more often than not, this comes from social engineering against an adjacent system. So, maybe trying to interact with a help desk or a sales representative, taking their credentials and seeing that that network, that environment is inherently just poorly designed. There are a lot of opportunities for an attacker to move through the system. So how can you verify that your development environment, what it's connected to, who else is interacting with it is secure, is safe, and is going to be essentially, um, hardened against any cybersecurity attacks. So it does go down to a fairly deep level. Since if an attacker is able to modify that development environment without the proper checks in place or the restrictions to prevent them from getting that access, they might be able to do something pretty nasty. Christian: Yeah, especially if it's an OTA or over-the-air update which is just automatically pushed out there. Cool, so we covered the global system view, the updateability patchability view, and the multi-patient harm view. The last view, according to the FDA, is the security use case views, and this one is the one that's most commonly misunderstood. I think is what you said earlier. Trevor: It sort of acts as a catch-all for what does not fit into the other buckets. When the FDA is talking about secure use case views, they have a an appendix at the bottom of the FDA guidance, which is a list of just a ton of different examples and it's probably covers 80, 90 different items as just examples of, here are things you may want to consider as part of your secure use case views. What we're really looking at are any specific functionalities, data flows, processes, it's states of the device, and how security is addressed. So, how are we seeing different views for security on power up versus power down, in operation, while it's at rest, if you're adding a new patient to a database, if you're removing a patient to a database. So this is such a broad area, it's such a wide net that you're casting depending on your device. It's essentially for anything the device can do, how are you addressing security. Christian: Yeah, every use case of the device. Like a use cases, I powered up or I shut it down, right? So how is security addressed in that scenario, right? Trevor: Exactly. And, as I'm sure you can imagine, every device does something different. So there is no one-size-fits-all solution for this. Christian: Right. And some devices have thousands of use cases. Uh, and some devices only have a few. So yes, this is a a very difficult one, but if you just logically think through every, like you said, function or use case of the device that someone interacts with or it transmits data or it's getting an update or it's delivering a therapy, you know, how is all that done securely? That's basically where we're looking at, how is everything on the device done securely? That includes the user interaction. If a user's interacting with a touchscreen, how is this touchscreen secured so the user can't do a certain pattern to get to an administrator mode as an example? Trevor: Exactly. I think a, sort of a little cheat code that some manufacturers can use is, as you're designing your product, you have your functional requirements. What does the device need to do? And you can use those as a good starting point to figure out what your secure use cases need to do. Every single one of these states of these functionalities, of these data flows is going to be covered in your functional, um, requirements for the device. And so, you take those requirements and you say, for each functional requirement, how can we build in security requirements? And that's going to essentially allow you to build these secure use case views out as you're going through the process, which I think is an easy way to prevent a lot of regression work and going back and trying to retrofit all these use case views and having to retrofit security to begin with. If you identify that you have a functionality where security isn't covered, that may lead the FDA to saying, well, we don't think that you're addressing security seriously enough. And so we're not going to accept the device in its current state. Christian: Exactly. So we covered the four cases, uh, or sorry, four security architecture views, the global system view, updateability, patchability view, multi-patient harm view, and the security use case view. Awesome. Uh, well, I think we'll wrap up this episode. For so, thanks everyone for tuning in to the Med Device Cyber Podcast. We hope to see you on the next one.