Q&A with Loma Linda University Health CISO Pat Voon: “Right Sizing the Right Framework Can Go a Long Way”

Health systems are being asked to do more with less, and the CISO has not been immune from such belt tightening, according to Pat Voon, CISO at Loma Linda University Health. But while the process may be less than pleasant, there is a sensible way to move forward. Voon, who’s been plying his trade for 30 years, says start with picking a framework and then “right-sizing” it so things don’t seem out of reach. In this wide-ranging interview with healthsystemCIO Founder & Editor-in-Chief Anthony Guerra, Voon also covers how he vets research partners, the organization’s approach to application rationalization, and why having clinicians on the IT team is now stakes-to-play.

All opinions and views expressed by Patrick Voon are his own and do not represent that of Loma Linda University Health

LISTEN HERE USING THE PLAYER BELOW OR SUBSCRIBE THROUGH YOUR FAVORITE PODCASTING SERVICE. 

Podcast: Play in new window | Download (Duration: 40:53 — 28.1MB)

Subscribe: Apple Podcasts | Google Podcasts | Spotify | Android | Pandora | iHeartRadio | Stitcher | Podchaser | Podcast Index | Email | TuneIn | RSS

TOC

• Research in Focus
• Baking in Application Rationalization
• The Doctor is In (IT, that Is)
• Appreciating the Needs of the Enterprise
• Pick a Framework & Right-Size It

Anthony: Welcome to healthsystemCIO’s interview with Pat Voon, chief information security officer with Loma Linda University Health. I’m Anthony Guerra, founder and editor-in-chief. Pat, thanks for joining me.

Pat: Happy to be here.

Anthony: Very good. Alright, Pat, you want to start out by telling me a little bit about your organization and your role?

Pat: Sure. So I’m with Loma Linda University Health. We are an academic healthcare center in Southern California in the Inland Empire, so basically that’s just east of LA. We have two main business lines, one being the academic side of the house. We have a teaching university that teaches medicine. And in practice, we have a number of hospitals as well as clinics across the Inland Empire. And so not only do we provide healthcare to the population in the Inland Empire, but we also teach our students in practice.

And we are a faith-based organization. We also include a spiritual aspect to what we practice. And I’ve been with Loma Linda coming up on seven years now as actually their first CISO since I started about seven years ago. So there’s been a lot going on, obviously, with the pandemic and at the same time trying to help them build a formal office of information security. But, yes, there’s never a boring day, how about that? I’ll put it that way.

Anthony: That sounds about right from what I hear. Yes, that sounds about right. Do you have a research arm? Do you guys do research?

Pat: Yes, we do a significant amount of research; we get a number of grants. So, yes, we are very active in the research field.

Anthony: Now, we’re not leaking any private information by saying that. I’m sure everybody knows you do research. But there is a connection I hear from many CISOs that research versus non-research will change your threat profile. Organizations that do research have a higher threat profile because there’s some nation state bad actors, especially with COVID vaccine stuff; I don’t know if it’s all related to that. But research certainly gives you a different threat profile, let’s put it that way; is that accurate?

Research in Focus

Pat: Yes. I would say that’s accurate because there’s a lot of what I would consider proprietary information that we want to protect. And so that was one of the areas that I wanted to focus on when we started the infosecurity program because prior to taking the helm as the CISO, the focus was a lot about the HIPAA stuff, the medical business, and not so much focused on even research. Now it may be medical research, but a lot of times we de-identify the data for that. But I don’t think the focus was sufficient enough on the actual research that was being done, the results and whatnot. So definitely we’ve been looking closer at that and protecting that intellectual property to the same degree as we protect PHI, protected health information. So intellectual property, yes.

Anthony: Right. So one of the challenges that CISOs have is they’re working in an entity even in the regular health system that wants to share information. We want to share information and the government is saying you have to share information. Certain things you have to do. You have to allow records to move around. I would imagine that’s especially acute in research where they want to share information. They’re doing research. They want to protect it and share it, and this is the classic problem in cybersecurity. We have to allow movement of data, freedom of data while protecting it. It’s an interesting tight line and I would imagine it’s even more intricate in the research realm; is that true? Tell me a little bit about that.

Pat: Yes. I mean, obviously, we have to, number one, make sure there are sound and complete type of agreements with whoever we’re sharing the data with. And it works both ways, two-way street, meaning if we’re getting data from our other partners that we have research partnership together on, then we also need to make sure we keep that data secure. So it’s really a two-way street. But where it’s a one-way street, we definitely, number one, start by making sure that our data use and data sharing agreements are mutually acceptable and meet our requirements. And so a lot of it is having a good agreement, a sound agreement, that also considers specifying things like what security requirements are expected and required of both parties. So those kinds of things are the nitty-gritty that we have to figure out together when we look at these kinds of partnerships because it is very tricky.

The other part of it also is depending on the length of the research or the study, we want to make sure, especially if we’re sending information to another party, that that party is actually implementing and operating the security requirements that we agreed on. So we can’t just say, ‘oh, okay, we trust you to do that’, the good old adage is trust and verify. So that’s what we look at as well, especially if it’s a long-term type study.

Anthony: So is it similar to the dynamic of third party vetting with a vendor? So let’s say you’ve got a department separate from research, you just have a regular department and they say, “We love this software, it’s the best. We don’t have anything like it” and you say, “But you have seven apps that do the same thing” and they say, “No, this is the one and we need it…

Pat: This is one, yes, exactly. (laughing)

Anthony: And it’s made by three people in the garage, and they don’t know what…” I’m exaggerating for humor.

Pat: I know. I know.

Anthony: They say, “We don’t know what security means.”  So you’ve got the regular, as I’ll call a traditional third party risk management program where you have to vet that, hopefully earlier in the process and moderate expectations of your users. You might have to say, “Hey, I need some time here. We’re not turning this on tomorrow, we have to look at it”, so you’ve got that there. Is the process of when you have folks doing research and they want to share data with other researchers at other organizations, they say we want to share this data; is the process of vetting that entity similar to the process of vetting your traditional vendor? I would imagine they’re probably quite dissimilar. They’re very different programs, but there are some similarities there in the sense that I need to review this entity, whether it’s a software vendor or another hospital that you’re sending the data to; I need to check everything out and make sure everybody’s secure and we’ve all had agreements. What are the similarities and differences there?

Pat: So the way I look at that, Anthony, is that we have a formal IT third party risk management program. So third party is inclusive of vendors and business partners or if we’re partnering on a research, we do that. So I would say there are more similarities than not. Obviously, the terms of the agreement in the contract, that differs some in terms of purpose of use and all that. I’ll say it’s actually more similar because we have to, not necessarily vet the partner because in most cases we’ll know who the partner is, and usually they’re the larger type institutions like this. And so it’s not a question of the viability and whatnot because with the vendors we have to make sure they are financially viable, they’re not going to close shop, or sell themselves after a year. So that is, I think, the differences between vendor versus our research partners.

Anthony: Right. So if it’s a health system, we’re not so concerned that they’re going to go out of business tomorrow; but if it’s a small vendor, we want to check that out a little bit and make sure. So that’s I think what you’re saying.

Pat: Yes. But I’ll say that we have a core set of questions that we present to both our vendors and research partners. There may be one or two things that we’ll say not applicable, but in general we have a same core set of questions to make sure we cover all the security domains and make sure they have the right security framework that they do adopt and implement.

Anthony: So what’s your process internally? What do you do? What do you think works? What’s your advice for other CISOs on managing internal expectations around time? So, for example, the example I gave you of an internal department ‘we love this software, we need this software, it’s going to save lives, we want it as soon as possible’, I assume you’re going to work as quickly as possible to get that reviewed. And if things need to be done to that software before you are willing to take it live, then there has to be some back and forth with the vendor perhaps. I don’t know if your internal user gets in the middle there to where you’re communicating with your internal user who is then communicating with the vendor, or if they step out and it’s you communicating with the vendor. But I think my bigger question is you want to satisfy your internal customers while protecting the health system. So what do you do to make that process as smooth as possible?

Baking in Application Rationalization

Pat: So first of all, you mentioned a little earlier, we have a policy at Loma Linda that if we have a current solution that meets about 80% of what you need to achieve to help your business functionally, then we would recommend going with that solution because it’s in place and it’ll be much faster than trying to look at another solution to add onto our already huge proliferation of applications. So you mentioned that, right?

Anthony: Right. Absolutely.

Pat: And that’s not sustainable. You cannot have all kinds of applications out there that basically do the same thing. Maybe one does a little bit more than the other one, but that’s not worth the time and effort trying to maintain all of these applications and systems. The way we engage our business customers internally is we’ll look at that first, so we’ll say, what is it you’re trying to achieve? We understand you’ve looked at this technology or solution, and then we will very quickly look through our solutions to see if that fits. And obviously we would explain the benefits of that, like what I just said. It’ll be a faster deployment and longer term more sustainable. It’s going to cost the company less so we’re saving. So we would do that.

Now, if the solution they’re looking for is indeed net new, a number of functionalities and outcomes they’re looking for that we do have an existing solution but it would take us months to enhance that solution to give you the outcome that you’re looking for, then we need to have that conversation and a deeper dive with the vendor. Normally, it’s a partnership; we call it shared risk meaning IT will share the risk with the business. So we need to take a holistic risk approach and look and see what the vendor can provide and offer.

And obviously from a security and privacy perspective, we have that core set of requirements that we will review with them and get them to give us a response to our questions. And then we’ll dig deeper. If there are any responses that we think requires a little more scrutiny, then we will reach out with them. But for the most part, that one, we deal directly with the vendor. The business owner pretty much steps aside. We’ll involve them obviously and keep them in the loop to say, here’s where we are with our security review. Here’s what we are seeing, no concerns yet. There are one or two things we just need to verify.

So definitely communication is key. And, again, we want to partner with the business. We don’t want to come across like security says no, you can’t proceed type of approach, that we want to avoid that. We desire, and I think we’ve done this, to present ourselves as partners in terms of helping enable the business rather than coming across as the traditional security, “they are always stopping us from doing what we need to do.” So we don’t want to be roadblocks; we want to be enablers.

But at the end of the day, it’s helping the business owners understand risks. So we will highlight maybe certain things that we are concerned about, and we will describe the risks related to that. But we will also work with them to develop compensating controls or mitigating controls. Let’s say a particular security control is preventative in nature and the vendor can’t do it, it can’t be automated, well then there’s maybe a manual procedure or a manual process that we can put in place to mitigate that risk. And at the end of the day, I would have to sign off along with the business where there are any exceptions if we have identified sufficient compensating and mitigating controls. So again it’s a shared partnership, shared risk.

Anthony: Wow, there’s so much there. Really interesting. No, there’s a lot there.

Pat: Yes, I know. (laughing)

Anthony: No, it’s great. It’s fantastic. So I have a billion like follow-up questions. You talked about the 80%, if you can get 80% from an existing solution, we think you might want to go with the existing solution. Who is coming up with that percentage number? I don’t know if it’s you guys. Is it IT security saying… I mean, no, I can’t imagine.

Pat: No, no, no, this is functional, right?

Anthony: Right. So are you saying to them ‘here’s our suggestion. Please take a look at these, which we have and we think may be similar. So I’m just going to give you the names of these apps that we know we have. If you think that 80% of what you need is in these apps, we think it would be a great idea if you just went with that.’ So what I’m saying is it’s very much a ‘we’re going to help you have a framework for how we think you should look at this decision, and now you get back to us and let us know what you think.’ Is that correct?

Pat: Somewhat. So we go a step further, Anthony. What we do is we do just a quick analysis internally within IT. This is not security specific, this is overall IT. We have teams that collaborate together to do these kinds of reviews; and obviously security is part of that team. And so what we would do is say, okay, looks like our current EMR – electronic medical record system – can actually do this for you. And so we would actually schedule a demo with them because, number one, we would collect their business requirements to understand what outcomes they want. And then we would make sure we set up a demo environment and show them here are the things that you asked for, here’s how it looks like in our existing solution, and here are the two things that are missing that we can enhance. We can update and enhance the system to do what you need to do but it would take three months. Is that acceptable to you to meet the other 20%? So, number one, they need to confirm and validate that they agree that, “Oh, yes. Okay, this will meet 80%.”  So it’s not just us saying it, it’s having them validate that this is what we are seeing, we think it’ll meet 80%, and they’ll come back; and after the demo, they say yes or no. And if it’s no, then we need to understand, okay, what else is missing, right?

Anthony: Right. You’re not just going to accept a ‘no, it doesn’t work’; give us a little more why doesn’t it work. (laughing)

Pat: Right. ‘Oh, this workflow just will not work’, then we would say, ‘Oh, okay. Well, we can reconfigure workflows very easily. It’s just turning off this knob or switching this button on to off’. So then they say, ‘Oh, okay. Well, if you can do that, then yes, I guess it’ll meet 80%.’

The Doctor is In (IT, that Is)

Anthony: So that’s really, really interesting. And when I hear you say that, it makes me think how much clinical knowledge you need in the IT department, CMIOs, CNIOs, all kinds of clinicians, because otherwise you’re not going to have the knowledge necessary for that type of analysis; you just won’t.

Pat: Absolutely. So we’ve had so many operational folks come and join IT and that has been tremendous. And obviously we have chief medical info officer – he’s great, very supportive. I think since I’ve been there, we have two different ones and they were both really, really great partners, especially representing the physician community. And then obviously we have a number of nurses that are actually full time with IT. They came and joined us. So, yes, you hit the nail on the head there, Anthony. You need that knowledge and expertise. And the feedback we get from our business owners is we’re so glad so-and-so is on your team. They really understand our business and our workflows. So that has been tremendous to help us be successful.

Anthony: How sensitive do you think the operational folks are when you make an enterprise argument; when you say, yes, we understand, in a perfect world this might be perfect for you but there are some enterprise issues. There’s some reasons from an enterprise level why if you can get 80% and you can give up that other 20%, you’re going to help the organization as a whole. Is there a sensitivity there to that? I’m going to bring this book up again.

Another CISO I interviewed the other day, Phil Alexander, and it just went live on the website, if you want to listen to it. There’s this book called Extreme Ownership written by a Navy SEAL, and I’m just listening to it now and he recommended it like three days ago. And the idea in that book is if you’re a leader and something under your purview isn’t working out, look at yourself. Look at yourself first.

And the context that that came up in is if you are not getting buy-in, if you are not getting people on board with what you’re trying to do; rather than look at them, you have to look at yourself and say, “Am I not explaining it correctly? Am I not being persuasive enough? Am I not speaking their language?”  So I guess overall in the context of are you seeing a sensitivity to enterprise arguments, are people saying, okay, that makes sense. Or are people so mired in their world they go ‘I don’t care. I want my hundred percent; I don’t care about your 80%.’

Appreciating the Needs of the Enterprise

Pat: It really differs I’ll say, Anthony. For the most part, our business leaders are very understanding: Number one, they hear what the CEO, the COO, and the CFO are all saying. It’s like we have to watch our overhead cost. We have to reduce even our investments because our revenues are down, our profit margins have always been narrow, so it’s like this is the reality today. And let me share with you how tough it is. Even with what I have in my security stack today, I am constantly looking at new solutions, alternate solutions that can perhaps combine some of these technologies. But the idea is looking at alternate solutions that will help us reduce our costs, even though they’re working as we desire, our current capabilities. It’s not that they’re not working, it’s not that the vendor is performing poorly, but out of due diligence we are being asked, you need to just look. And so that takes up a lot of my time and my team’s time because we’re going around doing research and reading analysis and papers. And then at some point we’ll say, okay, let’s do a bake-off, for a proof of concept, with maybe a couple of vendors to see how they perform. And then it’s the matter of, okay, we’re going to rip that one out and replace it with this one. So it’s tough.

But I think in general, going back to your question about sensitivity, I’m thankful that a lot of our business leaders are very understanding. There may be, I would say maybe one or two that are a little more adamant, but at the end of the day we provide them with enough data points. And as you mentioned, it’s important to speak their language. And for me, from a security perspective, it’s important for me to articulate to them the risks. If you do go ahead with that, I’m going to be putting down in my statement formally when I sign off to say I don’t agree with this because maybe they’re not willing to look at the compensating controls. So I’ll say I don’t agree with this unless those compensating and mitigating controls are in place. So that would be my position. As a CISO, I’m not going to sign off on it. When I’ve advised you a certain way and you want to go here and proceed, then I’m afraid you’re going to have to take that risk. But the good thing is we’ve never come to that point.

Anthony: Okay. That’s good.

Pat: Because when this goes to the CFO or legal or general counsel, they’re going to say, no, we are not going to take that risk. So even if the business leader is willing to take that risk, the overall senior leadership team has the right to say yes or no.

Anthony: I can’t even imagine a CEO who would approve a project that was wanted by a department leader where the CISO said, “I do not recommend we do this.”  This day and age, that would be very shocking to me with the amount of risk and what can happen. I mean, that would be stunning, right?

Pat: Yes. That is stunning. That’s why I say that we haven’t faced anything like that, thankfully.

Anthony: Right. And they have to know that. So the department heads who are requesting the software, “If Pat comes back and says, ‘This is a no on my end’, essentially, I cannot support this.”  I’d be very surprised if anybody tried to continue to push it.

Pat: Yes.

Anthony: But what you might want is you might say…tell me if this dynamic happens where you’re interacting with the vendor, as you said the business user comes to the side a little bit out of it, you’re interacting with the vendor talking about ‘okay, here’s really what we need to see, here’s what we need you to do. We want to work with you, our users love you, but here’s what we need you to get to.’ And perhaps you are not getting either the responsiveness or you’re not getting the engagement, you’re not seeing them wanting to come around; and the business user reaches out to you “Pat, what’s going on? We’re waiting for that software” and you say, “Listen, it’s not me. It’s not me. We’re not getting anywhere. Maybe you want to jump back in since you’ve talked to these folks and see if you can get anywhere.”  Did things happen like that on the ground sometimes?

Pat: Yes. So what you just described did happen indeed. Again, I’m always keeping the business leader in the loop. So when we’re not getting responses or when we’re getting responses that write us off and like pretty arrogant, we will tell the business owner that. We are going to say, hey, based on our current interactions with the vendor, we are not getting a comfortable feeling. Look at their responses here, quick responses, short, and not engaging at all. Those are all red flags.

Anthony: Yes.

Pat: No, you’re right. We definitely bring the business leader in and say, “Hey, you had the initial relationship. Can you help us out here?”  But these are red flags; we will tell them these are red flags.

Anthony: Right. If you could tell maybe it was a cut and paste job from some boilerplate they have. They didn’t really answer your question. It was like almost a data dump like, here, go away.

Pat: Yes. Exactly. That’s a red flag.

Anthony: Pat, amazingly we’re just about at the half hour that I wanted to keep us to. I’m going to open it up and ask for a final thought from you. So here’s how I’ll phrase this up. Now, I wanted to ask you about this and you could touch on in your final answer. You mentioned it at the beginning, almost seven years your tenure, which is pretty darn good for a CISO, maybe not a lot with seven-year tenure so you’re doing something right. You’re obviously very engaged, very pleasant, very personable so that’s obviously good stuff. What would be your advice to…and the way I usually frame this up is to a CISO at a comparable-sized health system because you can’t give advice to somebody with 50 hospitals and vice versa, right? So we got to frame it up as someone with similar resources. So what’s your best advice to that individual based on your tenure, that things you’ve found to be successful and helped you do what you’ve done, what’s your best advice to them?

Pick a Framework & Right-Size It

Pat: Well I, I think, number one, is truly understand your business risk profile. So look at what attacks are happening, be aware of those, and then have consistent continuous monitoring on your environment. So visibility is key. One of the best ways I think to establish a formal information security or cybersecurity program and I’ve done this is, number one, make sure you at least adopt a common framework whether it’s NIST or whatever it is. I’ve been a consultant prior to being a CISO, and depending on the size of the organization I could say you just have a light program if you’re small to medium business. And all this means is you need to understand what the HIPAA security and privacy requirements are and what are the specifications that are required, what are addressable, make sure you do everything that is required. And that can mean different things because at the end of the day, even the HIPAA security and privacy requirements they allow you or give you the latitude to manage it based on risk.

So that’s to the organization’s advantage. You don’t have to spend millions of dollars like a large healthcare organization. Even at Loma Linda, I do this by right-sizing everything. Number one, understanding what the threats and risks are and making sure I have preventive, detective, corrective, or responsive type of controls in place so basically layered controls from an infrastructure perspective, technology perspective – the whole security stack from network to your gateways to your endpoints. What are you doing there for preventive, detective, corrective, responsive controls or recovery-type capabilities because with ransomware, that’s absolutely as we all know, not a matter of if but when.

So there’s so much to unpack here, Anthony. I mean, I can probably go on for hours because we’re talking about a holistic approach in building a cybersecurity program. One of the things I have done successfully that’s really been helpful at Loma Linda is to build out a rolling three-year security roadmap and strategy. So I lay out a three-year program and roadmap strategy. And I’ll have different work streams that basically cover the administrative safeguards, the technical safeguards, and the physical safeguards because I have to talk HIPAA; you’re in the healthcare environment.

But what I’ve also done is build the program that’s inclusive of intellectual property because prior to me being a CISO there, there was like no such program, everybody was doing their own thing; I mean they were being very reactive, I’ll put it that way. So not the most optimized security program. And that’s why the CIO said, “Well, if you develop this three-year roadmap, then can you come implement it?” and that’s how I ended up joining Loma Linda. And so with that three-year roadmap, in one slide, it’s very busy but you can see where we are headed, where we are at, what we are behind on. So if I need to ask for additional resources or funds, then I can use that to say, ‘we are way behind on this particular workstream. We need to ramp it up and here’s what I need.’

And within that slide, I specifically call out which of the capabilities, I don’t like to necessarily call them…well, solutions, yes, but definitely not products. I do not speak products. I will give them the product name but they need to understand what is it we’re getting out of that product. And normally I like to use the term ‘solution’ or ‘capabilities’ because then I cover not just the technology but the people needed and the processes needed to support that.

So it’s a lot to unpack. But I think my advice is make sure you right-size everything that you’re putting in. Number one, you have to show that it is reducing the risk and then you continue to report on how well you’re doing or how well you’re not doing, and what adjustments you need to make if it’s not getting the outcome you intended to see. So I think those are all the important things. And at the end of the day, it is all about risk management and understanding your business leaders and their service lines, what their outcomes are, and articulating the risk in their language, you said that earlier. It has to be in their language. No acronyms; no blinky-blinky things that they will have no idea. They don’t understand firewalls. They don’t understand all kinds of technical solutions or products that we may need, but you need to articulate it in a way, like I mentioned, ‘Oh, here’s how it’ll prevent that threat from happening. Here’s how it would detect it and automatically alert our staff, so very quick response.’  That’s what we need. We can’t have attackers come in and dwell in our network and move around in our network and do discovery and then we are ultimately going to be exposed and a breach will occur.

So those are the kinds of things; I think that would be the advice I would give to other CISOs. But I mean if you are a CISO, you’ve been doing this for a while, hopefully. For me, I’ve been doing security for over 30 years so it’s like I have all the battle scars. I learned from the mistakes and just learned from real world experience; that’s invaluable. But I would say stand firm and fight the fight; it’s for a good cause. And even though our attackers oftentimes have more resources and time to work on their attacks, we have to keep pace with them, if not look ahead of what they’re going to do. So a good example is AI. Sure, they use AI and ML – well we can use AI and ML too to combat and battle that. So then it’s a matter of who has the better model and knowledge base around that.

Anthony: Such good stuff, Pat. Such good stuff. I think people are really going to appreciate this, and it’s been an absolute pleasure. So thank you so much.

Pat: Yes. Thank you for inviting me. I’m happy that I can share my thoughts.

Anthony: Alright, Pat. Have a great day. Thank you.

Pat: Alright. You’re welcome. Thanks, Anthony. Bye.