Why Cybersecurity and Quality Are One and the Same

Host: Hello there and welcome back to another episode of the Med Device Cyber podcast. Host: I'm your host Trevor Slattery and unfortunately our co-host Christian Espinosa is not able to make it on this one. He's tied up with some flight delays. Host: Today we're going to be talking about some regulatory strategies and ensuring that we're getting quality systems put into place early and effectively in medical products. Some of the common regulatory pitfalls that we see a lot of manufacturers face. And then of course, how these regulations are going to apply to emerging technologies, namely AI and machine learning. Host: Uh, I'm joined here by Ashkon from Ingenious Solutions. Um, how are you doing today? Guest: Doing well. Thanks for having me on, Trevor. Host: Perfect. Well, I'd love to hear a little bit about what you guys do over at Ingenious Solutions and then of course a little bit about yourself as well. Guest: Yeah, and you know, the two stories obviously intertwine. Um, my, my name's Ashkon Rasooli, I'm the principal and founder of Ingenious Solutions and I have a long history of working on medical device software. Guest: I belong to that niche group of people that understand regulatory requirements and software requirements intimately because I've kind of dabbled in different roles in the software development life cycle. Um, I've had roles coding, testing, product managing. And then most of my career ended up being in quality management system and regulatory affairs. Guest: And all of that led me to creation of Ingenious Solutions which is a boutique consulting firm focused on medical device software development. And so what we do is we help early to mid-sized companies with quality management system or early regulatory strategy uh, consulting for medical device software. Host: Got it. So you're ensuring that they're essentially getting their ducks in a row as far as their quality system, making sure that they're identifying any of the regulatory approaches that they'll need to take, of course the regulations that they adhere to and kind of helping them along that path. Guest: One hundred percent exactly. You see, the requirements around software are basically very different from hardware. However, a lot of the regulations are old frameworks from the prehistoric old software for firmware days. And so it is a whole art and its own specialty to try to have a very streamlined approach to software quality management systems, and so that's what I specialize in. Host: Definitely. Yeah, there's obviously a ton of complexity in software. And as the medical device landscape is evolving, pretty much everything has a software component now. Everything's connecting to the internet in one way or another. Host: And so when we're introducing that software component, we're introducing a little bit of risk as well. And that's where it can tie into the cybersecurity side of things. Host: Oftentimes, I feel like that is, they're portrayed as separate problems. You have your software issues, you have your cybersecurity issues. But they're very closely related. Host: In my mind, cybersecurity is essentially evidence of quality software. If you have secure software, you have good software. And so, ensuring that you're building out your software with these considerations in mind is important, but it can be a little bit difficult. The guidance documents are complicated. There are, you know, how many ever standards floating around that manufacturers have to try to adhere to. So I'm sure there's a lot involved with getting that QMS set up properly. Guest: One hundred percent. I think the idea that quality management system and cybersecurity are two different entities is flawed at its core and actually results in a lot of overhead. When you think about what a quality management system is about, uh, you know, 13485 was based on 9001 and at the end of the day, the stated objective of a quality management system is to meet customer requirements. Guest: And when you look at the FDA regulations, you know, they talk about safety and effectiveness. And cyber security fits throughout all that. Guest: Essentially, if you were actually being diligent long before the FDA got very stringent on cybersecurity, came out with all the guidances, with all the detailed requirements. If you were being diligent enough in terms of meeting your customer requirements, safety and effectiveness requirements, in your QMS, you would have already done almost all of the things that the FDA is asking you to do on the cybersecurity front. And so I really see the two as one and the same. Host: I definitely agree. Yeah, and the whole point, you know, the, the standards that we're adhering to under FDA guidance, these aren't very new standards. The FDA guidance of course was came out in September of 2023, which is still fairly recent. But everything that it's based upon, um, you know, ISO 62304 and then AC 81001-5-1, uh, these aren't new. These are older than the FDA pre-market guidance. UL2900 is another example of that. Host: And so manufacturers that had been adhering to these were already going to be compliant. Host: I think one issue with cyber security though is it's never going to be the priority. It's essentially, you know, an unfortunate thing that manufacturers and companies have to deal with. Nobody wants to deal with cyber security. It doesn't add value to the product. It simply costs. Host: But of course, you know, that's a flawed mindset of thinking because if you have a product and you don't implement cybersecurity and something goes wrong with it, then you're going to be liable to a lot more than you would have been just dealing with cybersecurity in the first place. But it comes back to your original point. If you had been adhering to these guidelines before, you'd already be fine with what the FDA is expecting, but now the FDA is just actually mandating that you adhere to these guidelines. Guest: Yeah, and you know, maybe mandating is not the term they use, but it is what we see in practice in the field, right? Host: It's a recommended. Guest: Recommended, strongly advised and justify otherwise if for whatever reason you decide not to do it. So 100%. Host: Yeah, and I think even just that wording, you know, it brings up a good point. A lot of manufacturers can get a bit caught up in the wording that the FDA uses. Host: Another thing that we hear all the time is, well, we don't think our device is a cyber device, because if you look at the FDA's website, you can totally understand where manufacturers is coming from. It has a list of ANDs. It says, you need to have a software component and you need to be network connected and you need to be running an operating system. Host: And in effect, it's an OR, and really the only one that matters is the first point. Do you have software? Do you have firmware? Either one of those, you're a cyber device in the eyes of the FDA. So the wording that is used and what is seen in practice, there's a bit of a disconnect which I think adds to the struggle that a lot of manufacturers are facing right now. Guest: Yeah, 100%. And you know what happens in practice, you know, I mentioned how QMS and cybersecurity are kind of one and the same. And you see also the same challenges across the board for QMS and cybersecurity. And, you know, there's a list of challenges, but one of them is QMS being thought of too late, QMS engineers being brought in too late. Same happens to cybersecurity. Guest: Creatively speaking, the very first step in establishing any system, quality management system, and then the security system within it, is planning. And part of planning is going to be identifying what are my requirements. Guest: With cybersecurity, there is often a misconception that it is a checklist activity to get to the market, meet the FDA's bar. And it is thought of that way. Guest: Essentially, manufacturers start thinking about it when they start thinking about the 510Ks or, you know, if it's a PMA, going to market essentially. Guest: But the question that should be asked in the reality on the ground is, what is the bar I need to meet? Guest: Just like the QMS, there are three primary factors that impact the design of your QMS, they also impact the design of your cybersecurity management system. It is, uh, essentially your product design, your business model, and, you know, the location where you're planning to implement that business model so the geographies, right? Guest: So, you know, just like we talked about, uh, FDA versus EUMDR, uh, we talked about, does the product have software or not software? Because if it doesn't have software, something like 62304 doesn't apply. Then in the same way, your cyber security requirements are mandated by regulations which everyone's, you know, aware of, things like HIPAA, things like the FDA. Guest: But then what location, what is your business model? For example, are you going to be selling into the hospital systems in the United States? High trust is a very recognized and required standard, then you want to make sure you acknowledge that up front. It is not so much so, let's say in the EU. Guest: Are you going to be selling into the government? Then, you know, NIST is often asked for, you know, compliance with NIST is often asked for in that business model. And then, you know, there's the question of product design. Do you have a product with a cloud component? Is it a product that has a mobile app? Is it a product that is just firmware? Guest: Based on the answer to those questions, for example, SOC 2 may become relevant, you may decide that you need to actually do a SOC 2 compliance. And so an activity that needs to be done early on, uh, as a part of your quality planning is going to be identifying the bar you need to meet for cyber security. Host: Definitely. Yeah, the kind of the first step is what problems are we going to encounter and how are we getting across them. And even right now the, you know, everything is changing so quickly in that cybersecurity landscape. I think the community is getting a little bit wiser to it and the regulations are catching up a bit faster than they had been previously. Host: And we're seeing new things, uh, coming out every day. We have the Cyber Resilience Act in Europe, the Cyber Trust Mark in the US now. And those are starting to mandate, you know, consumer electronics and even branching into government acquisition. I know that uh, come 2027 is their target, any consumer electronic products entering US government's anything is going to require the cyber trust mark. Host: And so all of these regulations, and of course, this is a little bit off the topic of the medical space, but it just goes to show that it's changing very quickly. You have to identify what space are you in. Even within the medical space, are you going to be subject to the radio equipment directive? Um, are you going to be part of IVDR or MDR? What space are you going down in that path? How are you getting your product class? Host: So it's a very complicated problem. I think that it's a very key first step to try to figure out when you're identifying what do I need to do for the regulations, for the quality systems. But I'd be really curious to hear your thoughts on what you think are some of those really important first items that a manufacturer or an innovator should be considering as they're moving toward developing their product. Guest: Yeah, so you know, as a very first point, I did mention, you know, business model, product design, you know, location, kind of your customer profile, who you're going to be selling to. And that, you know, kind of helps identify the cyber security requirements that you can successfully go to market with. Guest: Now, when you look at the different frameworks that are out there, you may identify multiple that you need to comply with. You know, uh, there's, you know, the regulations, the privacy regulations, the security regulations, standards, you know, the total life cycle standard 81001 that you mentioned. Guest: But you will find that there's a lot of overlap across the security standards. There's just, uh, basically marginal work additional, um, for compliance, but also just for the auditing and certification of it. Guest: And so at the minimum, I would make sure that there's a risk management mentality across the team. You know, uh, I have a, uh, manifesto, uh, for Ingenious Solutions that guides every single service that we do. It's called the non-BS manifesto. Uh, applies across the QMS and the BS is kind of a nod to FDA's at least burdensome guidance. So the BS is really burdensome. Guest: But, um, you know, there's four principles modeled after the Agile Manifesto. One of them is talking about culture over mandates. And it is extremely important for a medical device manufacturer to establish a culture of quality which includes cybersecurity, right? Guest: You need to have a team that understands that cybersecurity for a medical device is of utmost importance because, and to your point, this is not just a medical device thing, we are a safety critical industry. As a safety critical industry, a cybersecurity failure could also be a safety failure. Guest: And this is not necessarily attackers compromising assets, gaining access to assets. This could simply be attackers bringing down safety critical equipment that was necessary to deliver care. So in our industry, your device not working, delayed treatment is more than just lost revenue. It translates to actual patient harm. Guest: And so for everyone to treat cybersecurity with that urgency, with the risk management mindset is the very first step. Um, obviously, there's deliverable, there's activities you got to go through. You know, there's the plan and the software architecture and the SBOM and the pen testing and all that. But that all ends up only being effective if you've got that culture in the, in the team, kind of like ingrained, because, you know, a checklist document is really easy to generate and it is effective. It is extremely ineffective. Host: Right. And I feel like that was an approach that a lot of manufacturers were taking before the current FDA guidance dictated that there should be a different approach. It was just more of a tick-the-boxes, you know, we have a little Excel sheet, do we have passwords on our device? Great, moving on. Host: And I think that's, you know, it's like you said, it's a very dangerous mentality. Um, obviously, attackers are evolving really fast and so defenders have to evolve faster. Host: I know, um, a very hot topic in cybersecurity is the whole concept of ransomware. That obviously is one of the big things that gets mainstream attention, um, with the oil pipeline attacks, with the United Healthcare attacks. Um, there have been a lot of really notable ransomware events. And I was looking at a really interesting study the other day that University of California San Diego put out on what actually happens to the patients if a hospital gets ransomware. Host: And so they were looking at incidence rates of cardiac arrest in the surrounding hospitals. And of course, if there's a full ransomware attack in a hospital, they effectively have to shut down. Patient care can't happen, administrative tasks can't happen, reimbursement doesn't happen. Nothing happens when everything gets ransomware. So they have to send all their patients to other hospitals. And they noticed even outside of just, you know, standard influx of a larger quantity of patients, there was an 80% uptick in cardiac arrest rates and a significantly reduced survival rate for these cardiac arrest events, all because of ransomware attacks. And so it's a real problem. Host: It's not just a conceptual issue. You know, of course, cybersecurity is relevant in every industry, but seeing cybersecurity in the financial sector, of course nobody's going to want to lose their money and there can be major risk there, but it's unlikely that someone's going to die directly as a result of that cyber security attack whereas major harm or even death is a very real possibility in this space. Guest: 100%. And you know another example of this that we had um where, you know, defibrillators, you know, implantables were really easy to hack. You know, this was years back. Um, examples of that are abundant. You know, we in the cybersecurity space, we're very familiar with the DDoS term, you know, the denial-of-service term. And what, uh, you know, we need to fully acknowledge in a safety-critical system, particularly medical devices, uh, denial of service attack, uh, results in denial of healthcare service. And so you're going to have patients that are going to be denied healthcare, which could be time-sensitive, which could be life-saving if a, I'm going to put it on under the DDoS, but, you know, any kind of attack that results in loss of service actually succeeds on a on a medical system. Host: There was uh, not too long ago an attack against a transfusion center in the UK under the NHS and they were completely shut down. They got ransomed, they refused to pay the ransom, the attackers refused to give up. And so for several weeks they were unable to administer any care and this was often to late stage cancer patients who were down to, you know, down to a matter of months or weeks and they weren't able to get any treatments and so people were dying pretty quickly due to the fact that they couldn't get their treatment for an obviously extremely fast and dangerous disease. Host: And so, yeah, it goes to show that's that denial of care. And even branching outside of denial of care, we typically look at the CIA triad in cybersecurity. Confidentiality, integrity, availability. The confidentiality, that's going to branch a little bit more into the HIPAA side of things. Nobody wants their, you know, health records to be disclosed. And so finding a way to protect health information is critical. Host: But I think integrity is something that can often be a little bit overlooked and it's really important in this space. If you look at a diagnostic system, if you're able to trigger a misdiagnosis and, you know, either a false negative or a false positive, then it's can be pretty dangerous. If you say, you know, yes, 100% this patient has cancer. Yes, they have cancer, yes, they have cancer. And you're able to keep reproducing that effect, the doctor might prescribe them with chemotherapy and radiation treatments which are obviously extremely, extremely hard on you even if you do have cancer and not very good for you if you don't have cancer. And the inverse, if someone has a very time-sensitive problem. Like let's say we're trying to chase a sepsis diagnosis and we're able to say that this is not septic tissue and continually say this is not septic tissue, they're not going to get the treatment they need and that could be down to a matter of hours that they have to survive. Guest: 100%. Yeah, and what you're talking about is something that's usually captured in the risk management file. You know, for every standard and regulation in a quality management system for safety, there's also a standard that is parallel in cybersecurity. So we talked about 81001, it kind of maps to 62304 in terms of just being a total lifecycle approach to cybersecurity. You know, we talk about 14971, you know, it is basically just the risk management framework. There's a parallel framework in the NIST standard. You know, but just threat modeling as a whole is basically what 14971 asks for in terms of risk identification and analysis and control. And so what you just said would typically translate to delay in treatment or over treatment. That is basically how we capture that in the risk management file. which, every manufacturer is required to, this is now in the text of even 14971, they even redefined, they changed the definition of harm and risk in 14971 in the 2019 update. But you are also required to make sure you trace any cybersecurity, you know, risk that you identify to the safety risk and vice versa, back and forth. Guest: 100% what you're saying then is something that a medical device manufacturer should already be capturing in their risk process, in their risk management process, in their risk management file. So when I think about the harm of over treatment or mistreatment or delay in treatment, there's going to be a number of hazardous situations that could lead to that and I'm using 14971 terms now. Uh, but those hazardous situations could include a cybersecurity attack as successful. Host: 100%. Yeah, and that, um, you know, back and forth between the two. I know in the current FDA guidance they like to see TIR 57 as sort of that security risk management approach. And you read through that one, you read through ISO 14971 and they're very, very similar. I mean, there's, you know, almost like 70, 80% overlap between the two. And they talk about where you're sliding from one side into another because they're so closely related. Cyber security risks can easily translate into safety and vice versa. Host: Um, one thing you mentioned the update to 14971. And I think another very key point of that is their view on probabilistic scoring of risk which is something that the FDA, you know, explicitly says you cannot do at all. You can't use probabilistic measures. And instead you want to move towards the exploitability factors which are becoming a bit more industry standard. And so, really objectively, how does this happen? You know, do you need credentials to do this? Do you need to touch the device? Can you do it, you know, can you attack a hospital in New York from Kansas? Um, you know, what level of access do you need to get? How complex is this attack? Do you need to attack the person or attack the device? Host: And so all of those playing to making things a little bit easier to follow as far as a risk management approach, I think it's, you know, a little bit less subjective. We always going with a probabilistic approach, it's pretty easy to see two assessors argue about who's correct and say I think it's one in a thousand. Well, I think it's one in 10,000. And you know, who's to say who's right? There's no evidence behind it. Anyone can just try to make their point. So I think this shift, um, you know, moving from that update in 2019 is a little bit of it's a good direction for the industry in general to be following. Guest: No, 100%. So, you know, 14971, when it came to probability assessment left it a little higher level in that it talked about the concepts of P1, P2. P1 being the likelihood of a hazardous situation happening, and P2 being the likelihood of the hazardous situation leading to harm. Guest: So, you know, P1 would be cybersecurity breach happening successfully and P2, you know, that cybersecurity breach leading to some sort of a harm. Um, this, you know, understandably did not completely apply to cybersecurity in the sense that it did apply. However, fundamentally there's a difference between safety risk assessment and cybersecurity in the sense that with safety, we are not thinking, you know, at least the majority of the time, uh, about an intentional bad actor trying to, you know, harm a particular device manufacturer. We're often thinking about, you know, for example, when we do a DFMEA, we're talking about passive failures in the design. Passive failures, you know, unintentional misuse for example in usability. You know, what happens if someone, you know, makes a mistake in the PFMEA, in the the process of manufacturing the product. And so we are not thinking about someone's intent to cause harm. We're talking about, you know, just passive unintentional failures. Guest: And so this was recognized by the way before the FDA uh, put out this guidance, even in, you know, the NIST framework, we had two likelihoods that would essentially have to work together to lead to P1, which would be, you know, you know, the likelihood of exploitation and likelihood of success. So, likelihood of the attack happening, how lucrative is this for someone to even try? And likelihood of this attack if happening succeeding because, you know, you've got a range of a spectrum of bad actors or, you know, hackers who would attempt something lucrative. But obviously, you know, it ranges from, you know, what we call script kiddies all the way to, you know, state sponsored actors who are very methodical and abundant in resources. And the question becomes, you know, how far, you know, does your security, essentially like if your security is a moat around the castle, you know, can you just handle, you know, bows and arrows or, you know, catapults or missiles, what is it that your cyber security castle can handle? And so this is why the FDA decided, you know, the 14971, the P1 model just wasn't enough by itself. We need to actually deep dive and talk about why do you think the likelihood of this is acceptable? Host: Definitely. Yeah, you bring up a really interesting point on how lucrative an attack can be. Um, I think one thing that is a little bit of a misconception as far as cybersecurity risk is a lot of people say, "Well, who would target, do a targeted attack against this device?" And the answer is probably not that many people. Host: Like, truth be told, we don't really see targeted attacks against a specific device to cause harm. Um, you know, frankly, hacking's not easy and it's a very small scale, like terrorist effort would be really the only thing that would lead to that risk. Host: Really what the main risk is is just non-prolific, you know, non-targeted, just prolific attacks, trying to spread ransomware through an entire network, and you never want to be the weakest link in the chain. Host: And so I feel like that's a little bit of um, something that can just be a bit of a misconception is, oh, who's actually doing this attack? Because you're not making money from attacking just a single person unless you're trying to ransom them and then you're trying to ransom everyone because, you know, you're looking for it. The way that threat actors are typically operating, not at the nation state level, that's usually going to be a lot more directed but ransomware gangs, you know these hackers out of Russia and China and wherever else, they're usually just looking for the lowest hanging fruit. They're looking for someone left their password out online, you know, severely misconfigured VPN, whatever they can find, just the quickest, you know, easiest cash grab. They want to make their hourly rate as good as they possibly can. Host: And so, you know, it seems weird to say but you don't really have to be perfectly secure. You don't have to be trying to defend against that nation-state level threat actor, who's trying to do anything they can to get into this product. That's not the use case we're looking at. We are looking at non-prolific attacks just trying to look for anything to grab on to, and we have to be smarter than them. Guest: 100%. And I agree, that that's the most common. I mean, there might be like specific scenarios and not that one I can think of right now, but there might be specific scenarios where you decide when you do for example an asset driven threat model that you decide that your asset is of the kind that a state sponsored, you know, hacker might actually be interested in. Uh, but you know, this is exactly why you need to put the framework of risk analysis in place and account for it, account for that particular line item. Guest: Um, I do agree Trevor, I think the most common category of uh, risks we see for medical devices in practice is you don't want to be, you know, the weakest uh, you know, link in the chain. You don't want to be passively compromised with ransomware. And um, I think the other thing we do see is uh stealing of health information because that can be sold and that can be also, you know, monetized. That's the other part of this. So in terms of, you know, anonymity, security protections, um, that has also been another lucrative asset that medical device manufacturers often have. Guest: Um, but you know, it is rare that, you know, a powerful actor targets one particular medical device, um, you know, intentionally trying to compromise it. Host: There was a, not too long ago, an attack against a transfusion center in the UK under the NHS. And they were completely shut down. They got ransomed, they refused to pay the ransom, the attackers refused to give up. And so for several weeks they were unable to administer any care. And this was often to late stage cancer patients who were down to, you know, down to a matter of months or weeks and they weren't able to get any treatments and so people were dying pretty quickly due to the fact that they couldn't get their treatment for an obviously extremely fast and dangerous disease. Host: And so, yeah, it goes to show, that's that denial of care. And even branching outside of denial of care, we typically look at the CIA triad in cybersecurity. Confidentiality, integrity, availability. The confidentiality, that's going to branch a little bit more into the HIPAA side of things. Nobody wants their, you know, health records to be disclosed and so finding a way to protect health information is critical. Host: But I think integrity is something that can often be a little bit overlooked and it's really important in this space. If you look at a diagnostic system, if you're able to trigger a misdiagnosis and, you know, either a false negative or a false positive, then it's can be pretty dangerous. If you say, "You know, yes, 100%, this patient has cancer, yes they have cancer, yes they have cancer," and you're able to keep reproducing that effect, the doctor might prescribe them with chemotherapy and radiation treatments, which are obviously extremely, extremely hard on you even if you do have cancer and not very good for you if you don't have cancer. And the inverse, if someone has a very time sensitive problem, like let's say we're trying to chase a sepsis diagnosis and we're able to say that this is not a septic tissue and continually say this is not septic tissue, they're not going to get the treatment they need and that could be down to a matter of hours that they have to survive. Guest: 100%. Yeah, and what you're talking about is something that's usually captured in the risk management file. You know, for every standard and regulation of quality management system for safety, there's also a standard that is parallel in cybersecurity. So, you know, we talked about ISO 1001, it kind of maps to 62304 in terms of just being a total lifecycle approach to cybersecurity. You know, we talk about 14971, you know, it is basically just the risk management framework. There's a parallel framework in the NIST standard. You know, but just threat modeling as a whole is basically what 14971 asks for in terms of risk identification and analysis and controls. And so, what you just said would typically translate to delay in treatment or over treatment. That is basically how we capture that in the risk management file which, you know, every manufacturer is required to, this is now in the text of even 14971, they even redefined, they changed the definition of harm and risk in 14971 in the 2019 update. But you are also required to make sure you trace any cybersecurity, you know, risk to the safety risk and vice versa, back and forth. 100%. And you know, we're talking with, this is a safety critical system, particularly in medical devices, uh, denial of service attack, uh, results in denial of healthcare. The denial of service attack, um, could be, it's not necessarily a malicious user, it could be a malicious user, or it could be a malicious user. I mentioned how Q and cyber security are kind of one and the same, and you see also the same challenges across the board for QMS and cyber security. And you know, there's a list of challenges, but one of them is QMS being thought of too late, QMS engineers being brought in too late, same happens to cyber security. Guest: At the end of the day, you hear the concept of "shift left" often. Shifting left meaning involve stakeholders early on. There is a question of how early is too early. And so I think it's worth talking about that a little bit. Guest: At the end of the day, there is a phase very early on in the product development process where your concept is changing too often, your architecture is, you know, evolving, you've got iterations happening to the point of thinking about threat modeling, thinking about quality assessment and risk management would be inefficient because your inputs keep changing to that. Guest: But there needs to be an understanding early on that there needs to be a line in the sand where we say, okay, we think we've got feasibility down, we know where we're going at the high level, this is not changing too much anymore. And at that point, think about quality management system, cybersecurity. Guest: You know, I talked about regulations, product design and the geography playing a role in setting the bar. One other thing, you know, that kind of relates to all of that is just the management's position on how they want to bring the product to market because when you think about quality and security in terms of a positioning statement, your product may only have quality and security at the level required to sell in the market, which is the first three things that I talked about. But you may also want to position yourself, and this is what, you know, an easy example to think about is Apple. You know, your security and quality end up being also your differentiating advantage that you sell on and you charge a premium for. Because at that point, what you need to do is set your quality objectives around cybersecurity to not just meet the first three, but also whatever it is required for you to stand out in the market. Guest: And so drawing the line on when we're going to figure that out is extremely important and then stick into that because, you know, these projects are months long projects and if you bring people in too late, you're going to have a lot of rework and you're going to have a lot of cost. Host: Completely agree. Yeah, typically I always say that cyber security should be addressed early and often and quality should be addressed early and often. Uh, you know, quality and cybersecurity are super, super tied together, like you keep saying. And I think that cybersecurity is just evidence of a quality product. So, awesome. Host: Well, it's been fantastic to have you on the podcast today. And uh, yeah, thank you so much. Guest: Absolutely, same here. Thanks for having me, Trevor. And uh, we'll be talking soon, I'm sure.