Securing HealthCare.gov & Tackling Fourth-Party Vendor Risks

PODCAST TRANSCRIPT

Brian Selfridge: [00:00:19] Hello. Welcome to The CyberPHIx, your audio resource for information security, privacy, risk and compliance specifically for the healthcare industry. I'm your host, Brian Selfridge. In each episode, we bring you pertinent information from thought leaders and healthcare, cybersecurity and privacy. In this episode, we'll be speaking to Bart Layton. Bart is the vice president of product at CORL Technologies. CORL is the healthcare industry's leading provider of third party vendor risk management solutions. And prior to CORL, Bart has extensive experience in product development in the federal sector as well as healthcare and other industries. I'll be speaking to Bart today about his experience leading product development for the high profile healthcare.gov site, as well as the topic of managing cybersecurity risks for the healthcare supply chain specifically related to fourth party risks. This is a great conversation. I'm very excited to share it with you. And so let's dive into another great conversation with yet another amazing guest. 

Brian Selfridge: [00:01:24] Hello. Welcome to the CyberPHIx, the leading podcast for cybersecurity risk and compliance, specifically for the healthcare industry. I'd like to welcome my guest, Bart Layton. Bart is the Vice President of Product at CORL Technologies, and I'll read from CORL's description here just to give you a sense of the organization and what they do. CORL is a service centered technology solution for vendor risk management, compliance and governance that is 100% focused on the unique needs of the healthcare space, driven by the belief that third party vendor risk should be about business acceleration and not business prevention. CORL is the only platform and partner in the market to enable the velocity and validation needed for healthcare organizations to simultaneously achieve their digital goals and contain their digital risks. So quite a mouthful there, but a lot that CORL does. And for full disclosure, CORL is also the sister company to Meditology Services who hosts this podcast. 

Brian Selfridge: [00:02:13] Prior to CORL technologies, Bart was responsible for product development for HealthCare.gov, which you will most likely have heard of before if you live in the United States. I hope a pretty high profile organization and site there. And Bart's going to tell us more about healthcare.gov when we get into the conversation. So I'll save it for that. I'm excited to be speaking to Bart today about two major topics. The first is around the journey of healthcare.gov and the challenges and solutions for securing this massively critical platform for the US health insurance and health infrastructure. The second topic we're going to cover is around the daunting challenge of managing fourth party cyber risks. This goes back to that whole CORL technologies, things in the healthcare ecosystem. Bart is an incredibly talented and experienced pro in our space and is uniquely positioned to speak on these topics. So I'm really excited to pick his brain and share his insights with you. So with that, let's dive into another interview with another amazing guest on the CyberPHIx, Bart Layton. So Bart, thank you so much for joining us today. 

Bart Layton: [00:03:12] Thank you, Brian. Very glad to be here. 

Brian Selfridge: [00:03:14] All right, great. So first off, I'd like to level set with the listeners a little bit. Can you tell us a little bit about what is healthcare.gov? I've alluded to it, but what is it? Who runs it? What's it do and who can use it? And just anything you want to tell us. 

Bart Layton: [00:03:28] Sure thing. So I'll start off with kind of the high level and then dig into it a little bit more because there's much more under the surface. So the short answer, healthcare.gov is the federally run website where Americans can shop for health insurance outside of employer based coverage. For those that might not have that option or might not have an affordable variant of that option, and they can get help in the form of advance payment tax credits to make that coverage more affordable. The site covers about two thirds of the states. Some states run their own site. In addition, there are some private companies that run broker sites that leverage healthcare.gov functionality but ultimately drive the same net effect. Now, it is much more than just that Web site, really. There's a whole bundle of technology under the hood that supports the Affordable Care Act beyond the website, which includes review and certification of the health and dental plans that are offered their payment to various health insurance entities on behalf of the enrollees that seek coverage through their generation of tax forms, integration with the health insurance companies, brokers, and several federal agencies to verify eligibility and the various workforces that use healthcare.gov and back end technologies to help those consumers get coverage. 

Brian Selfridge: [00:04:52] Awesome. Hopefully, most of the folks here have had some interaction with healthcare.gov, either for themselves or folks that they know. Can you tell us a little bit about the evolution of healthcare.gov? I imagine it wasn't born overnight as no large technology ever is. And, you know, there were perhaps some challenges getting off the ground. From what I understand me, I don't want to get too far into that. But can you tell us a little bit about how this whole got started and sort of the evolution of healthcare.gov? 

Bart Layton: [00:05:21] Certainly. So it was a very ambitious vision for sure, both from a policy perspective and a technology perspective, immense complexity. And that complexity took time to realize. So even if it's in its simplified form, Medicaid rules are complex. And while the entirety of the complexity of Medicaid wasn't at play here, there was a significant amount of that complexity present merged with the new policy requirements and regulations associated with the Affordable Care Act. So weaving in new policy and technologies relatively new to the global market, let alone the federal sector, so limited expertise to tap into in the form of federal contractors that had depth in both the federal policy space, Health and Human Services. And these new technologies play with, of course, unprecedented integration across federal agencies and the private sector. Fold in with that the mantras of no wrong door. So whether you go to your local Medicaid state agency or to the website or to a navigator or to a broker, all of those experiences should take you successfully through the flow with no negative impact by choosing one over the other, including email or phone as an option and leaving no one behind. So ruthless prioritization is not in the DNA of the federal government. These are public servants committed to helping everyone. And even if you come in with a bit of that mindset of ruthless prioritization, it rubs off on you. These are intensely empathetic folks who are out there trying to do the best for everyone, and as a result, that's a very tall order to deliver on to help the entirety of the American populace in need of affordable healthcare. What that translated to is an immense need to scale. So thousands of simultaneous users significant data volumes with intense security requirements, significant logic and processing. 

Brian Selfridge: [00:07:44] Wow. I can't imagine what the phone registration process would have been like for a registration ready registering for health insurance maybe needed to develop. It was too far ahead for the the API auto bot that could answer and register for you. So I understand there was an overhaul of the site at some point, maybe in the 2013, 2014 timeframe. What was that all about? Sort of what were the drivers for that? And at what point in the process did you get involved? And what was your role in in that whole, quote unquote, overhaul? 

Bart Layton: [00:08:12] Sure. So in that overhaul, essentially that we were addressing a couple of key challenges that the site was facing at the time. One of the big ones that I alluded to earlier was scale. There were significant challenges supporting the volume of users that were going through the site simultaneously and the logic more so than the tech, really the way that the tech was implemented was in such a manner that it was calculation intense and very compute heavy and a chatty experience between the front end and the back end. That ultimately meant long lag times and responsiveness of the UI and meant limitations on the users that were able to actually log in and complete the process. So that was kind of challenge number one. Challenge number two was addressing key gaps in that complexity of the policy and its implementation. There were a number of features that had been postponed in the rollout, so making good on those features was absolutely critical. And then in terms of my role, so I started as the lead of business architecture for eligibility and enrollment, and that quickly evolved into leading product management and development for the implementation of those new consumer impacting technology features associated with new policy and developing operational needs. 

Brian Selfridge: [00:10:00] So you mentioned scale, which is, I think, something that a lot of our listeners struggle with when they're dealing with large, complex health systems and multiple locations and systems they need to secure. So I want to dig into that a little bit more. My understanding in reading up on this and again, you can correct me if I if I missed something, but my understanding is there were more than 500 professionals brought in to overhaul the site, a pretty aggressive deadline, something like six weeks for major pieces of functionality. How did you and the team managed to stay in sync and coordinate that much activity with that many people in such a short period of time. 

Bart Layton: [00:10:34] So it's funny when you've been through an experience like that, I'm not sure those statistics that I'm sure those are accurate and reasonable, but it's funny how the mind blurs some of the pain over time. But in terms of how we coordinated so much activity in such a short time frame, constant contact, no lines between the teams, there was no badge. There was no delineation between federal employee contractor, different contractor teams, different federal divisions. Those didn't matter. We were all in the same place either in most cases, physically, in many times in the same place for way too long. There was sleeping under desks during those early hours and days for sure. And I know that it's a bit anathema to the current world with the incredible amount of work from home and remote work. But I think particularly at that time, in those initial months having everyone there so that the moment a new feature was ready you from a development perspective the tester was right there next to that person ready to move. And that same approach went through the entirety of the life cycle with the operations team and security experts right there. From the moment that we started designing something as the code was being created, someone over the shoulder saying, Oh, that's a good idea. I'm going to make sure I put in a log statement to capture that and start building the monitoring tools for that immediately because it was absolutely high paced. 

Brian Selfridge: [00:12:28] Well, how many people can you fit in a room? Like I've been in war rooms doing development and building stuff. You've got 500 people at some point. First off, the personal hygiene thing becomes a problem, I think a little bit. And this is pre pre-COVID spreader events like how did you guys have a big cube farm? How did you keep everybody in the same general area? 

Bart Layton: [00:12:47] So we had a number of pods doing simultaneous development and that was I think the structure of the teams was a key thing to make this possible. If we didn't align into clear domains with well-defined boundaries where we really understood those integration points between the boundaries and had the folks to bring together the vision and integrate across those domains, that separation is only valuable if it can still be brought together that next level up. So. There were independent pods, but there was constant traffic between the pods and just a rotation around the clock. 

Brian Selfridge: [00:13:35] Wow. It seems like an amazing undertaking, all told. So let's let's switch gears and talk a little bit about the security considerations. Right. That's what our our team here likes to think and talk about quite a bit. So we'll, of course, refrain from asking you about any specific vulnerabilities or control gaps that obviously we're not going to get into to that level. We'll stay kind of high level. But this idea of a complete overhaul of the site, rapid development go to market, everybody's sleeping in their pods and so on, usually does not mean good outcomes from a security standpoint, traditionally. So you obviously did it well and did it securely. So what kind of security considerations did you have to factor into the conversation, either during requirements and design or just throughout implementation? What were some of the things that had to be thought about and built in? 

Bart Layton: [00:14:22] Can I say all of them? Just all, every single one imaginable. At least it felt that way. We had pretty rigid security standards to meet associated with both the healthcare and the financial industries, because there were dollar transactions occurring with the Treasury and federal standards like Fedramp. So we were protecting PII, which will be very familiar to folks here and to some extent less so than of course most of our core clients. But also federal tax information or FTI has a number of specific regulations applying to it. And it really in with those things in mind and with the overall security and with the Paperwork Reduction Act, minimizing the data that we ask for was kind of central to all of this, minimizing what we ask for, what we provide, what we use. Also, we were connecting with other federal agencies and private companies, insurance companies and brokers and other customer support workforces. So that added a layer of complexity there. But we were thinking of a couple of key areas. All highlight access control was critical authentication, both from the public user perspective and the internal worker perspective and really emphasizing that minimum necessary access I referred to earlier bandwidth and the peaks so that we avoid a denial of service situation where yes, we were expecting high volumes of users, but it's critical to put certain checks in place in our monitoring to be able to identify, say, bot traffic versus human traffic and to prevent that kind of access that might signify something bad either happening or about to happen. And then traditional practices like code scanning and pen testing just with the dial turned up to 11, both in terms of the level of scrutiny, the frequency of those activities. So really kudos to the operations team for incredible foresight on the monitoring and constant education of the broader team in terms of security practices and how to think regardless of your role, how to think, how do I put security first in what I'm doing in every daily activity that was critical? 

Brian Selfridge: [00:17:07] He was there any concern that healthcare.gov might have a target on its back? I mean, do the level of hacking activities against the healthcare industry even back then, it was still raising the site to that level of profile. We now know that there's entire groups in nation states and criminal hackers that have had their eye on us for some time. Did that factor into the team's planning at all, that that sort of potential target on the back factor or were not so much you just doing all the right things regardless? 

Bart Layton: [00:17:37] Uh, one word. Absolutely. I mean, you could not be. There was no way to be more aware of the fact that there was a constant feeling of that target on our backs in so many ways. From the moment you show up at the office, walking through the gauntlet of press workers to just that constant reminder of take, for example, there was around that time the OPM breach, and that was just a key example that put into such clear relief in our minds. For those of you who are not already at level 11 of heightened responsiveness and preparedness, we had to get there. There was just no option. 

Brian Selfridge: [00:18:30] You talked about uptime and managing the volume of traffic and peak times and all that. I want to dig into that a little bit more, if we can. Like what? How important was the business continuity and disaster recovery security domain throughout the build and launch of HealthCare.gov? 

Bart Layton: [00:18:51] So I'll say in the beginning, disaster recovery was certainly part of the plan, but it was not realized immediately. I mean, first we had to get to operational during standard business hours. And during those initial months after the first rollout, that was no small undertaking. We did over time then get to a place where we had zero unplanned, unplanned downtime during open enrollment zero, which was quite the achievement. That's 45 days at times that's been longer than 45 days that the open enrollment period has run and to have truly zero unplanned downtime during that entire span for a system being hit so heavily by intended use and having that target on its back, as I mentioned, that was no small undertaking. But the disaster recovery plan really was implemented over time and is rather robust now. 

Brian Selfridge: [00:20:06] It's my understanding is that at least part of the healthcare.gov website or site was hosted using Amazon Web services. You know, so we talk about CORL and managing healthcare third party vendor dependencies and stuff. That must have been a pretty significant dependency on in this case Amazon. But your cloud service provider to operate the site. What kind of security considerations, if any did you have to sort of take into account the dance that had to happen with a cloud provider like that in creating such a large scaled implementation? 

Bart Layton: [00:20:41] Well, I'd say, number one, Amazon was a terrific partner in that space. But no matter how strong the partner, I think it's key to bear in mind that kind of mentality of trust but verify. It's not a move it to the cloud and it's the cloud providers problem kind of a situation. And that went both ways. I mean, we were absolutely tightly integrated with, again, from across federal workers, contractors and US representatives. It was by no means the Oh, let's put this over the fence. It was, we are all in this together. We succeed together, we fail together. And that mentality was critical to succeeding together. 

Brian Selfridge: [00:21:35] I'm going to skip one of the prep questions I have and move to the last one just in the interest of time on this topic before we move to the next one, if that's okay. So we've got a lot of ground to cover today. I won't do one more question with you on healthcare.gov before we talk a little bit more about fourth party risk and third party risk. So this is actually kind of related. So I read somewhere. I read somewhere. It must be true that HealthCare.gov leveraged a variety of third and fourth party software components using GitHub and talked about Amazon, Splunk, JIRA, you know, a lot of the Python, fortify, a lot of things that you would expect to be in a large scale development implementation. So with the recent breach of GitHub and other fourth party suppliers we've seen, does that raise the alarm for sites like HealthCare.gov that could be vulnerable to these escalating supply chain breaches now that all that stuff's kind of baked in there from the outset? Not that healthcare.gov is unique to that, but is that something that you think raises potential risk either then or now? 

Bart Layton: [00:22:35] So I'd say yes and no in that I think it raises the alarm further. But that alarm was already constantly going off in our minds. It's the idea that we can so tightly secure and work hard to improve our posture of what we have directly built. But having that knowledge that you are only in true control of so much and that you are dependent on these third party, fourth parties to provide quality products. So that was, I think, a key factor in our evaluation of what products we would use and what products they were using in turn. And that went through rigorous scrutiny by both our core technology team and representatives from the federal government. And there was no shortage of eyes on that, both in the initial selection process and in terms of the ongoing monitoring and maintenance of those products. And constant communication. 

Brian Selfridge: [00:23:55] Seems to be a theme, this continual communication. And I think we're already taking notes on that for our own benefits. Now, I did jump right into this idea earlier of using the term fourth party risk, and I should maybe take a step back from that. I don't want to lose any listeners here who have totally glazed over as I'm throwing around these terms, some of which relatively sort of nuanced and new. So maybe you could you take a second just to define exactly what a fourth party is and how that may differ from a third party and from a security standpoint? 

Bart Layton: [00:24:29] Sure. So. Third party, I think of in the typical parlance as being that a provider of software services to a client and ultimately then the fourth party being that next relationship removed. So as a provider of, say, a cloud software solution to in our current world a hospital network, if that software solution that I am offering is dependent on, say, Okta, to quote a recent example, Okta would then be, in this example, considered a fourth party. 

Brian Selfridge: [00:25:18] Makes perfect sense. And I know we'll sort of dig into this a little bit more. Just moving away from the healthcare.gov context for a moment and digging into more of your choral experience, because that's where I think everybody hopefully that's listening to this has some exposure to third and fourth party risk. So we really want to kind of dig into that fourth party aspect. What are some examples that you're aware of prominent fourth party breaches that have impacted healthcare entities in recent history that maybe would give us some illustration of what that looked like. You mentioned Okta, but are there others? 

Bart Layton: [00:25:53] Sure. So going back a little bit more, Solar SolarWinds was certainly a promise or a prominent one, rather. And Log4j. I'll call out as one that was particularly interesting in terms of interesting and or awful in terms of the way that it was handled and understood by many organizations because there was a great deal of complexity understanding at the top level. Some folks heard Apache Log4j and said, Oh, I have Apache, am I impacted? And then of course, the answer to many of those was no. And it was, Well, do I have Apache Log4j installed? Oh, I do. Well, is it installed and running on a live production server with this version. And I think that level of attention to detail is critical. But when there is a situation that drives panic, it's not always easy to find that trusted source of information and to get the right answer. And there can be a lot of headaches at worst, at best, or damage done if the facts aren't swiftly identified and the right courses of action aren't taken. But there can be a lot of noise generated by any of these situations where it is more complex than just, Oh, I have Apache. 

Brian Selfridge: [00:27:35] Well, apart from the noisy-ness of this and just the confusion that happens when a big incident like that happens, everybody's scrambling. What are some of the other challenges that you see healthcare organizations struggling to tackle with respect to securing fourth party data platforms and the like? 

Bart Layton: [00:27:55] So I think disclosure is a big challenge both initially and of updates to the fourth party make up of a third party solution and the evolution of new discovery of vulnerabilities and the speed to which those are communicated. So a lot of times this is happening by attempting to pull the information and when you are pulling by game of telephone pulling information from someone that you're asking to pull from someone else within their organization to pull from yet another person, you can see where that starts to break down over time, where even the best of intentions it becomes very difficult to manage and then making that information trackable, traceable in a way that systems and humans can use it and finding out how deep that rabbit hole goes. Because when we say fourth parties, you quickly find that, well, fourth parties might themselves have components within their solution offering that go that next level. So we start talking about fifth parties and parties. The rabbit hole can go rather deep. So the complexities of obtaining the requisite information, even just from that first layer, that's a significant challenge. 

Brian Selfridge: [00:29:27] So I've noticed that the Federal Government's getting really active in the arena of supply chain risk and security for critical infrastructure, which is defined to be inclusive of healthcare. What kind of actions have you seen the federal government taking? And and how can healthcare organizations benefit from the investment and maybe the pressure that the federal government is putting around figuring out this third and fourth party supply chain risk issue? 

Bart Layton: [00:29:54] So certainly a lot of activity there, both us federal government and looking more broadly with the EU and other global standards at play here. But I mean there's one the latest report from the US Cybersecurity and Infrastructure Security Agency defending against software supply chain attacks. Generally good guidance to the broader world in that, but I'll highlight some specific things from the executive orders from President Biden. So there's been recent mandates of security risk assessments across key departments, especially Health and Human Services, focusing on sensitive data, complex supply chains, and the digital and emerging technologies that present potential higher risk of vulnerability as the adoption cycles and the development cycles are so rapid. Then also closely related to that, a later executive order where one of the specifications within it referencing providing a purchaser a software bill of materials or SBOM for each product directly or by publishing it on a public site. And I think that that is a strong lead that we in the private sector can follow, though there's some already are with the adoption of formats like Cyclone. And I think putting those into standard use across the industry just makes that earlier problem that I was referring to about the communication, the transparency and the disclosure that much simpler because if there's clear systematic disclosure of this information, it lessens the burden on everyone involved. 

Brian Selfridge: [00:32:05] We'll take a moment here to make a quick plug. Actually, since you mentioned the whole presidential directive on supply chain, we did a whole episode dedicated to that here in the CyberPHIx. That gave a rundown of the ins and outs of that order and some of those pieces. So for our listeners, if you want to go back into the archives there to was that probably late 20, 20, 2021, somewhere around there that could be could be wrong in the dates. But go check that out and you can learn more about that one. So this is clearly a tough challenge, right, with a high degree of complexity, as you've just that whole ninth party challenge, just you can curl up into a ball and give up. When you start looking at the face of how challenging this is and how complex it is and high degrees of complexity generally, as I'm sure you know, everyone else does that they don't mean good things for security. Complexity is a lot harder to secure. So what kinds of emerging solutions or approaches and I'll talk about coral specifically since this is your world, what have you seen developed or seen percolating in the market to address fourth party risks that we might be able to share with the listeners here, even if they're in their early stages of development. 

Bart Layton: [00:33:12] So I think going back to that last point, definitely the software bill of materials intake we see as a critical part of our roadmap to help reduce some of the pain associated with that lack of transparency and the challenge of communication. Additionally, providing greater visibility into the fourth and ninth party relationships between various parties within the ecosystem for particular client and greater visibility into known indicators of risk. And in both our own methodologies for measuring risk and for other partners that we integrate with that provide sort of statistics and measures related to risk providing that level of data insight for not just the third-party vendors that folks are looking at in the current world, but also for those fourth parties and and the party views. 

Brian Selfridge: [00:34:23] So who's doing that kind of coordination? Right. Is this on every single health system to maintain a database of party relationships? Or how do you see that being orchestrated in reality in a way that's usable and scalable? 

Bart Layton: [00:34:41] So absolutely see this as something that's got to be done by a different party within the ecosystem. So it isn't efficient for a vendor to be managing that worldview entirely themselves and to communicate that to every single one of their clients. Or vice versa. A hospital network to track that down individually for any one of their every one of their vendors and fourth parties. So that's where coral comes in. We are simplifying the exchange of information by gathering that world of vendors and fourth parties and that world of clients and marrying up the information that each respectively need to see. 

Brian Selfridge: [00:35:33] That's great. Well, we appreciate you taking on the yoke of that burden for the industry and helping us figure it out. So we've covered a lot of ground today, and I want to make sure we didn't leave any stone unturned. Are there any sort of closing thoughts or takeaways you'd like to make sure we focus on as we think about either healthcare.gov and that whole journey or as it parlays into fourth party and party risk. Anything you'd like to share with us as we wrap up here? 

Bart Layton: [00:36:04] Well, I think I'll put in here a plug for both. A few themes, actually. I'll say one for all of you out there dealing with the challenges of fourth party risk and complex security requirements. I encourage, especially in this virtual world that we're in, that constant communication theme is no less true and applicable, if anything more so right now. So be in close contact with your security teams and the folks helping keep your organization secure and really put that into the mantra of folks who are not necessarily in the field of security. I cannot emphasize that strongly enough. If we empower folks throughout the broader organization to act as stewards and protectors of security, there's no doubt you'll see rising tides all around. In terms of healthcare.gov, I will provide a shout-out to say Every day I'm finding new people who are not aware that healthcare.gov could in fact help them meet their health insurance needs. So by all means, if you're uninsured and you're worried, reach out there. If you have friends that have those problems getting affordable coverage, please make sure that they're aware of healthcare.gov or their state-based exchange. And then with regard to coral. Exciting things on the roadmap and the future ahead of us. So stay tuned. I'm sure you'll be hearing more from Brian on CyberPHIx and looking forward to getting more out there for everybody out there who needs it so greatly. 

Brian Selfridge: [00:38:02] Yes. And for those looking to sign up for healthcare.gov, get out your rotary dial telephone. We know that it can handle phone calls and registrations. Maybe maybe it can't anymore, but. Well, the fantastic part. Thank you so much for taking the time to be here with us today. It was just great, great conversation. I want to thank my guest. Bart Layton is a VP of product at CORL Technologies for a fantastic discussion on securing healthcare.gov and large, complex ecosystems and fourth-party risk. We covered a lot today. So, Bart, thanks so much for your time. This is great. 

Bart Layton: [00:38:34] Thank you. 

Brian Selfridge: [00:38:34] Again, I would like to thank my guest, Bart Layton, who is the vice president of product for CORL Technologies. I really appreciated Bart's insights into both of the major topics we cover today around HealthCare.gov and fourth-party risk. A few areas that stuck with me were the criticality of open lines of communication for large and complex projects. It's almost cliche to say as much, but it's also extremely rare to see implemented in practice across healthcare entities that kind of a degree of communication and open lines, particularly when it involves business and clinical stakeholders that are too often left out of the conversation. I also appreciated Bart's concept of having a central entity like CORL that can serve as the broker between all parties involved in the supply chain to track that relationship and the interdependencies between third parties, fourth parties, and the parties and all the tech in between, particularly when those large scale cybersecurity breaches or vulnerabilities come to town for those third and fourth and fifth party platforms. 

Brian Selfridge: [00:39:30] As always, we'd like to have your feedback and hear from you, our listeners. Feel free to drop us a note about what topic you'd like to hear about or a thought leader you'd like to hear from. Our email address is [email protected]. Thanks again for joining us for this episode of the CyberPHIx, and we look forward to having you join us for another session coming up soon.