From Audit to the CISO Seat

Thanks for tuning in to Simplifying Cyber.

I'm Aaron Pritz.

And I'm Cody Rivers.

And today we're happy to be here with Brian Waltz, most recently CISO at Cardinal Health. Welcome to the show, Brian. How are you doing today?

Doing well. Pleasure to be here. Appreciate you having me.

Awesome. Well, we like to start off every episode with just getting getting to know our guests. So we've met you before, but we want our guests to have the chance to meet you. So give us a little bit of an overview of the Brian Waltz story and specifically your journey to CISO and into cyber. I know when we first met, we shared some audit lineage in our history, but give us the quick and dirty.

Yeah, absolutely. Appreciate it. So I actually started my career in public accounting working for EY for the first 6 years of my career, kind of splitting time between financial and IT audit. And, uh, at that point in time, uh, as typical consultant was doing tons of traveling and decided I wanted to get off the road and, and find something a little bit, uh, closer to home. So moved to Cardinal Health where I spent, um, probably 22+ years in that organization, kind of starting in IT audit but quickly pivoted into IT after a couple years there. And I think that was kind of the great thing was the opportunity to try different things and move into different areas of the business. And so Moved into a role that was primarily focused on risk management, compliance, governance type roles. So kind of leading our SOX program office, building out some FDA capabilities and things like that. And did that for about 7 years and got to the point where I was just like, I'm tired of telling people what they're doing wrong. I actually want to go build something. And so it did kind of a career pivot for me, probably spent the next, you know, 7 to 9 years in more traditional IT roles, deploying things like ServiceNow and ITIL capabilities across the organization, doing a stint through infrastructure, and then switched into a couple more business-facing IT roles where I was an IT business partner, you know, helping to build out IT-enabled business strategy, putting together business cases, and then executing large projects to help the business move forward. And then probably about 6 years ago, got a call from our CISO at the time who I had worked for in a prior role, and she's like, hey, I'm creating a deputy CISO role. Is that something that you would be interested in? and I said absolutely, would love to get back into security. So kind of the security has been the bookends of, of my career so far, but, uh, have absolutely enjoyed my time in it.

Oh, that's great. And yeah, we both shared, as when we first met, that kind of early career audit background. And I know, um, for me it was, it was formative to kind of understand internal controls and both the process side as well as the technical side, uh, of controls. What What impact did audit have in kind of shaping you as a cyber leader and specifically as an IT practitioner as well?

Yeah, well, I think the first and foremost, right, like just being skeptical, right? And it's not that you're just like the negative Nancy, right? But I think you've got to have that view on everything as you kind of do your work, right? Is understand like the what could go wrongs. And I think that's very much the same way it is with security, right? You're always looking for those holes that could be breached in your in your security posture, right? And it's kind of like Swiss layering layers of Swiss cheese on top of each other to make sure that you've got enough layers to close those holes and make sure that you're in good shape to protect the business.

Yeah, awesome. Well, I have a question kind of going from the audit and like, I think of like GRC as a kind of a resurging topic in a lot of cyber programs, but looking at yourself with two decades of perspective at one of the world's largest companies, you've seen GRC evolve. Is GRC finally becoming the GPS that tells us where to spend our next dollar, or are we still just using it as like a rearview mirror?

Yeah, I mean, I think it is about how you look forward on there too. And I think cyber has a bigger seat at the table than we've ever had before, right? And the opportunity to help influence the business, right? And it's been interesting to kind of see, you know, nobody was really talking about cyber as a risk. Then it started to show up on enterprise risk management. Lists out there. But then when you start to dig into it and pull the layers back and ask the business, like, what are you most concerned about? They're like, I don't know, I read a lot about it in the newspapers and I see stuff online and I know it's a risk to the business, right? So that's when you really have to start to kind of peel those layers of the onion back and start to dig in and understand, well, are you concerned about operational disruption, right? Are you concerned about data loss, etc.? And so I think those have been very rich discussions to really help them understand how we view cyber risk and making sure that they understand it's not just the CISO or the CIO that owns it, right? Like it is a collaborative discussion and collaborative ownership around those risks, right? Because we may have a part in the remediation or the mitigation step that we put in place, but part of that could also be on the business as well with continuity plans or diversifying their, you know, their supplier base and things like that. So, so I do, I do. While you can always learn from history, I do view it more as like, how do you move the business forward and manage that risk for them.

Yeah.

Yeah.

So two decades in healthcare, and I was on the pharmaceutical side, you're on the payer healthcare side for the two decades. What, for you, what makes human health and healthcare unique in cyber? And why did you choose for two decades to focus on that sector?

I think for me, it's just more of a personal thing, right? Like the mission of healthcare, right? To help people get better. Is very personal to me. And I, you know, I always kind of put myself in that seat no matter what role I was in. Right. And I think just even going back to my time in infrastructure, I led our enterprise database team, right? 7,000+ databases. And nobody gives you a lot of kudos when things go well. But when that thing goes down, right, like you're hearing lots of noise about it. And I remember one time we had a pretty major outage on one of our key systems in our nuclear pharmacy business. and it ended up stopping, um, you know, us getting prescriptions out to a particular hospital to run diagnostic tests, right? And so they ended up having to send some, uh, patients home who couldn't get those diagnostic tests, right? And so you kind of just step back and say, that could have been me, could have been one of my family members, right? And you just don't ever want that to happen again. Same thing with security, right? Um, clearly you don't want to have any disruptions or data loss in there that could negatively impact those patients and their their families, right? And so you take that mission very personal. I think that, that's what kept me at Cardinal as long as I was there.

That's awesome. Talk to me about translating risk into business language. And obviously, um, GRC, a lot of the art of it is in how you tell the story and communicate things to non-technical audiences. For you, uh, one, how did you form those skills as you were coming up in your career? And to like, do you have examples of where the way that you communicated something made, made the difference of whether, you know, an initiative moved forward or it didn't?

Yeah, I think it's, it's difficult. Some of those conversations are very difficult, right? Trying to be able to translate a very technical topic into something that they can really understand. But I think, as I mentioned before, just starting to ask the question around like, hey, Help me understand what a bad day looks like for you. Is it your systems are down for a period of time? Is it, you know, a file with, you know, patient information in it getting exfiltrated? Is that what you're most concerned about? Right. And just helping them understand what are the regulatory and compliance risks associated with that. But then also, like, what does that process look like? Right. Like, if you were to have a major incident like that, you've got to spend some time to help them understand that. And translate that risk into something that's more business-oriented. Numbers talk, right? So making sure they understand like what is the financial and operational impact of that, I think is usually beneficial to doing as well. I think in terms of kind of, you know, maybe stories or instances of us having conversations with the business, one that kind of comes to mind from a GRC perspective was, you know, we had a business unit that was, getting close to signing a contract with a pretty major customer for them. And as they engage the security team, and we're looking at some of the contractual language and understood that the customer is requiring HITRUST compliance, right, within a period of 2 years. Now, for anybody that's gone through that, is a pretty lengthy and time-consuming process to be able to do that, you know, not only understanding what the current state looks like, but then also remediation that you need to do going through the certification process. And so They were in a hurry to get this contract signed and we kind of just said, hey, time out. One, this is a big deal. So you need to understand and recognize the investment that you need to make to satisfy this contractual requirement, but also recognize that this customer is also one of our largest customers or the largest customer in another business unit of the organization. So whatever decision you make impacts those folks as well. And so while we were kind of operating at senior management level of that one particular organization, it got escalated all the way up to our CEO and CFO before we made that, you know, that decision on whether we were going to invest the money and then move forward with the, you know, the contract as it was. And we ended up doing that and got the support we needed to, you know, to get that HITRUST certification in place. But again, it is really about making sure you've got collaboration across the business to surface those risks and make sure that you're making some educated decisions.

That's awesome. I love that you had, um, that business area one at— you guys were at the table reviewing the contracts, calling that out early. We've had examples of, of, of clients and people within our networks that have, uh, the business has made a decision on a contract and they found out about it afterwards, and sometimes with a lag in the time period that they had given them to, to make it down that journey. So maybe give us a little bit more about the the decision process that you, you know, you, you probably had high trust. Is it going to be for the entire company end to end? Is it specific to that business unit? Is it, um, only for that specific client? So how did you walk through its scope to get it to the right size to be both effective and scalable?

Yeah, I think as we kind of walk through that, um, that, that request or that requirement wasn't coming up in any of our other contracts with that customer. So we kind of just made the decision early on we were going to really just focus on certification for that one business unit. And then to your point, it was a matter of then talking through, well, what from a system impact, what are the, what are the applications we want to bring in scope for that too? And so we tried to take a minimalist approach to that to say, hey, what are the, what are the items that the customer cares about and the data they care about? And let's make sure that we use that as kind of the, you know, how we orient the scoping for that. So we ultimately determined that we could leverage that to our advantage, right? Like, I think as we kind of made that determination of, you know, HITRUST certification, yes or no, is like, hey, this could be a market differentiator for us if we're kind of first to market with this. And so we can use that as we go out and, and try and win additional business. So that's kind of how we, we viewed it is like, you know, that would be available for any potential future client out there. But the one thing I would say, and you kind of brought it up, is like, You definitely don't want to get notified of these situations after the contract's been signed. So like that collaboration across the business, across procurement and legal is extremely important. And I think if nothing else, like you're looking out for each other's best interests to say, hey, you know, I saw something coming down the pipe that's got some privacy concerns around. Let me make sure I get our head of enterprise privacy engaged in this to at least understand, do they know, are they aware of this particular contract and piece of business that we're trying to to sign off on. And so I think that, that was extremely important for us, um, in that situation.

Well, and leaning into this HITRUST thing, I'd say it's a yes, but, you know, we know HITRUST is the Iron Man of security certifications. But if a company, for our listeners, is just starting out that journey because a contract requires it, uh, what's the one mistake they make in the first 90 days that costs them the most later from your experience?

Um, I think scoping could be that, right? Because again, it's not only the kind of pre-assessment you need to do to understand like, hey, are my controls good or bad and where do I need to go, um, you know, take some remediation steps, right? If you don't scope that right, you could be creating a bunch of work that doesn't add a ton of value to that certification or doesn't need to be part of it, right? So I do think that's an important part of it is taking your time to kind of lay, put a ring fence around what you're going to go and certify out there. At least for, you know, based on our experience.

Yep.

Yep.

And I, I think too, kind of going into kind of changing here a little bit here, like the resilience versus security mindset, you know, you've mentioned that cyberattacks in healthcare aren't just IT issues, they're patient safety issues. But when you're talking to the board about like cyber resilience, resiliency, how do you shift the conversation away from like preventing breaches to surviving them without losing the trust of the customer?

Well, I think honestly, like, we, we spent a lot of time with our sales team too, as they were engaging with customers on some of this stuff. And it even got to the point where we participated in like some of their resiliency exercises as well to kind of talk about like, hey, if, if we were down, like, what would you guys do? And vice versa, like, how would we, how would we partner together? So I think that's an important part of it as well. But in terms of like talking to the, the board and the executive leadership, team around that. Um, one of the things that I had done, like, early in my tenure as CISO there is we had brought in an external speaker into our board, and the message he kind of delivered to them was like, it's not a matter of if but when a cyber event happens. Like, you can't expect Brian and the CIO at the time to prevent every single incident out there, right? So it's about how do you— how quickly do you understand what's going on and, uh, and, and stop the attack, but then obviously recover if some of your systems are impacted. And so I think it was good orientation for the, the board to understand that. And then I think you've got to put some programs in place to help measure the maturity of your resiliency program out there. And so kind of within the scope of my remit, I owned all of the disaster recovery planning and things like that and crisis management. And so a lot of what that team did was working with the business to understand like what are the critical systems. And I think that's probably the most important thing is to understand like everything isn't created equal, right? Because if everything's a priority in that situation, nothing's a priority. And so we really had to spend a lot of time kind of going through the business impact assessment and understanding, you know, critical processes for the— for the businesses and then what systems support them and making sure we could weave that into the plan. And then from there, It's about understanding what types of recovery plans do you have in place? How frequently are you testing them? Clearly, something that's more critical, you want to test it more frequently and understand that you could go and execute in some kind of a, a disaster scenario. Um, and then, you know, making sure that you're scorecarding that and, and reporting that out to the business. And like, one of the things that I thought was kind of genius from, from my team was starting to, to to look at it more from like a letter grade, right? And so everybody understands what's an A, a B, a C, and a D, right? Like we've all been in school and so we understand that. And so they started to kind of put that lens on it for our internal leadership team to understand it too and to really drive action because in, you know, in a more or a less mature organization or program, you're probably doing a lot of heavy lifting for those teams, right? They don't understand how to write good DR plans and what all the components need to be. And so we did a lot of that handholding for them. And we did a lot of that, like fingers to keyboard, as we, as they were executing tests in their non-prod environment. And we kind of got to the point where we said, hey, listen, if we have a major incident, it's all hands on deck. Like our team can't support thousands of applications being recovered, right? And so you've got to understand your own plan. You've got to be able to execute it and you should be able to execute it in your production environment. And so we created kind of a formula to help measure each of those steps in the maturity journey around resiliency for those teams. And then we would scorecard it and put that in front of the leadership team on a quarterly basis. And it's always interesting to see, like, you know, it's a very competitive culture there. Like, people don't like seeing Cs and Ds associated with their name, right? So, so that tended to drive action for them and help improve the current state for them.

Yeah. So what you're talking about, we see it a lot of companies where the cyber team or risk management owns business continuity planning and What you hope that means is you own coordination, but the true business leaders that are going to need to run those functions when IT is down in a major crisis or cyberattack or whatever, but there's still a lot of the central ownership where everyone's having it done for them. And it sounds like in your story, you knew that that wouldn't scale and you needed to both one, federate the ownership to the true leader that should be responsible, but then two, put a measurement system in place to gamify or give them some, some drive to not be that C. Is there any other kind of tips along the way to kind of when you transition from the former state to the future state, how did you get that ownership shift to happen?

Well, I think part of that is making it part of folks' performance goals. And so we didn't necessarily describe like, hey, you've got to have an A for all your critical systems. But, you know, we, we kind of looked at just overall like a percentage maturity and we kind of said, hey, you need to improve X percent over the course of this next fiscal year. And so we tried to drive it into performance goals, which obviously is tied to compensation and your year-end performance review. And so that, that tended to get the action that we needed in those particular scenarios.

What about time? How about, let's see, when do you have to be the bad guy? Let's see, let's get, you know, you had to tell a business not to sign a contract because of X requirements were a bridge too far. Give us that. How did that go? I'm sure that wasn't a message well received, but how do you kind of handle that conversation when the answer is we shouldn't do this?

Yeah, I would say there are very few times that we've had to go there and it's not easy, right? But I think one, you've got to build trust with those folks in the business too so they understand like you are doing this in the best interest of the organization it's going to create problems down the road if we go and enter into this agreement. And so we kind of just take a very factual view of like, hey, we did a third-party risk assessment, and that we did have one vendor in particular that we kind of said, hey, this, you know, this is a no-go for us. Um, and so we kind of just laid out and said, hey, we, you know, we had X number of criteria, you know, 20, let's say 20 criteria that we evaluated them on. They, you know, passed on 10 and they failed on 10, and these are this is why these 10 matter for you, right? And, you know, based on the, maybe the HIPAA data that you're putting into this application, right? There's a high chance that there could be some kind of a breach at the vendor. And obviously that has a major impact on us as a healthcare organization. So again, it was just coming to the table with some data points to have that conversation with the business. And I think they understood and they were quite honestly, they were prepared with 2 or 3 other alternatives that worked for them and they were able to move forward with it. So it wasn't like we stopped the project, but, you know, maybe it wasn't the exact vendor that, uh, that they wanted. Sure.

Sure.

Well, great, great, good. Excellent answer. So like very seasoned executive answer there. So now like you get a phone call to Brian of 20 years ago, you know, just starting out his career, kind of getting going. What's a couple nuggets of advice you're giving yourself? You know, the, hey, I didn't know now that I can tell you now, hey, here's some nuggets. So what's, what's the Brian of now telling Brian of then?

That's a great question. And like, I think for me, you know, knowing I spent the first 6 years of my career in public accounting and then the first couple at Cardinal in audit, um, was like, be uncomfortable, right? Like push yourself outside of your comfort zone, right? Because, um, after I moved out of audit, I was still doing risk and compliance stuff, right? So I was still the auditor. I had my auditor hat on trying to find problems and you know, get people to, to care about it and go do something. Um, and it wasn't until I made that transition into more, the more traditional IT roles that I felt like I really started growing, um, as a leader. And it was because I was being put in situations where I wasn't the expert and I had to rely on a lot of other really smart people to do their jobs, to make the team successful. And so, like, I'll never forget when I was, um, uh, approached about the database role there. And I had a conversation with my VP at the time and I was like, dude, the last time I looked at a database, I was in college, right? So I have, I have no idea how to manage people who've been doing this for 20+ years. And you know, what he told me was like, the issues, the challenges they have are more around lack of process, morale of the team, and those kinds of things, which you're really strong at. And so view it as a compliment to that team that you can help them get through that and get to a better end state. And so, you know, I, I took that as a challenge, but then I also had to kind of just roll up my sleeves and spend a lot of time on phone calls at night, you know, where we were having outages to understand their world, right? And to be able to not know it, but know how to ask the right questions and maybe challenge them to think differently. And so I probably grew more in that 3 years and like it was a long time to be in that role as a meat grinder, but I probably learned more about myself and my leadership capabilities doing that than if I had just stuck in that, that audit type role for, you know, for 3 more years. I don't know that I would have necessarily been on the same trajectory from a career perspective.

Yeah, there's a lot of debate in the industry of like, and it's usually technical leaders debating that a CISO must be you know, have worked in a SOC and reverse engineered malware. And then there's another faction that would be like, that's been the model for decades. Like business, you know, we need people that can talk in boardrooms. And obviously the answer is somewhere in the middle, but, um, given your experience and kind of what you've seen work, work well, what, what is that right balance? And kind of similar to your reason why I thought to ask this question, like your leader for the database team was like, we're not looking for a, 20-year database leader. We're looking for someone that can lead teams and help to have the right conversations to get barriers reduced.

Yeah. Yeah. I mean, it's a great question. I think part of what I tried to do is just establish trust with those people too, right? I think that's an important part of going into those kinds of situations is making sure you establish trust. They understand you've got their best interests at heart. You're going to listen. You're going to learn. You're going to try and understand. The challenges that they have on a daily basis. And I think about like when I went into the deputy CISO role, that was, I would say, more operational. So again, I may not have had the experience as a leader of a security operations center or, you know, some of the application security or whatever. Like I had managed teams that they worked with on a daily basis, right? Like clearly one of the key teams that we worked with or we work with in security is infrastructure. Application security teams are working with the app teams to make sure they're writing better, more secure code, right? And so I had led those teams and understand how to work with them and maybe what types of messages would help resonate with them, right? So I think it's, it's really just trying to make sure your team understands like, hey, here's what I bring to the table that I can help you to be successful in here. It's not necessarily to your point that I know how to reverse engineer malware. We've got lots of really smart people that do that. Do that, but it's helping to understand like, what does that mean for the business if something bad happens or if malware gets loaded on a laptop? Like, what does that mean? What are they— what are we going to expect them to do in those particular situations? And I think maybe that's what I learned having spent time in those traditional IT roles is I've been on the other side of the table from those or helped with an incident investigation and could translate, you know, what is— what's the impact to the business or be there to have that conversation with the business of, hey, we've we've got a, we've got a problem. Here's what we need to do to, to go resolve this, right? And so again, you've got to build that trust ahead of time so that makes those decisions and those conversations a little bit easier. So hopefully, hopefully that answered your question there. Oh, that's awesome.

Uh, one last question before we go. Uh, we'll make it a fun one. What is one thing that most people, maybe that even work with you, don't know about you that you want to unveil? And I didn't prep you for this question, but what's that one fun fact, uh, or surprising thing?

Oh my gosh, one surprising thing. Um, dude, I'm, I'm boring, man.

Like, I— everybody asks me like, you can juggle, man, you know, who knows? Think of that. Yeah, I don't, I don't have—

I mean, I can't, I can't juggle. Um, unfortunately, I'm like, I'm a Cleveland sports fan, so that's not fun. Like, that's, that's pretty much misery, um, 365 days a year. You built resilience though over the year, and that's what I— yeah, that's what My wife says all the time, like, hey, why did you raise your kids to be Cleveland sports fans? Look at how miserable you are. I was like, two points helps you build resiliency. Like, you learn how to deal with disappointment. There's lots of good life lessons to be learned, um, rooting for those types of sports teams. But, uh, um, yeah, like the golf, travel, all those kinds of fun things.

But, uh, favorite, favorite vacation or favorite travel location?

Oh gosh, well, we just— we did a big, uh, a big family vacation to Europe last year to celebrate our son's high school graduation. A couple other milestones we had in the family. So it was the whole Clark Griswold vacation with the, you know, the 5-page itinerary. And so we hit it all pretty much the same, the same cities they were in too. So. Very cool.

Well, awesome. Thanks, Brian, for coming on the show today. It's been great to get to know you a little bit better. And hopefully we talked about some topics that revealed some answers and options for people that are facing some similar challenge to like the high trust or compliance level thing, or trying to get business ownership from their resiliency program or BCP program. Appreciate you coming on.

Yeah, appreciate it. Thanks for having me.

Thanks, Brian.