Is Your CISO Holding You Back - Or Setting You Free? Wake Up | S02E07

Speaker A: Foreign.

Speaker B: This is the Wake up podcast powered by Veeam. I'm your host, Rick Vanover. The Ricatron. Today, Rick Orloff is joining us to share fresh perspectives to wake up to. Thanks for joining us, Rick.

Speaker A: Thank you for having me. Appreciate it.

Speaker B: So, uh, first time on the show. I'm a longtime fan, but take a moment and introduce yourself, your role and what your current responsibilities are.

Speaker A: Sure. Uh, Rick Orloff, Vice, uh, President, CISO@everypure, uh, which is formerly Pure Storage. And I'm responsible for all of the cybersecurity, the zeros and ones and bits and bytes.

Speaker B: It's funny, I'm glad you said Everpower, because I know I would have messed it up. Formerly, uh, Pure Storage, you know, household name in the Veeam neighborhoods, if you know what I mean. So, longtime partnership. But what we want to talk about here today are some really interesting perspectives that you have in your role, which is unique because as CISO and your prior experience, you've seen some things. So I say we jump into it. And the first thing I want to highlight is really a claim that data may not be fully trustworthy or even untrustworthy. Welcome, uh, to you to challenge me on it. But kind of, what's your thought about data in the trust level today?

Speaker A: I understand the reference to the question because it used to be that you'd have somewhat two types of data. You would have your source of truth data, and then you have copies of that data that other people manipulated. And so depending on what you were trying to do, you may be tying to the wrong piece of data. Today, with data, uh, accessible from anywhere, anytime, it's really about what are you trying to do with it and which set should you be hooking into?

Speaker B: That's a really important point. Accessible anywhere, anytime. I mean, I've heard the, you know, the proverbial phrase that the walls of the data center aren't really there anymore. Uh, from a connectivity standpoint, uh, yes, they're there. But in terms of how people access and the accessibility, I mean, at least what we do at Veeam and what, you know, a lot of the orgs I work with, yeah, everything is very available. So I could see that perspective. And then one of those next things that I want to kind of bring up is around the compliance of these conditions. So, uh, let me start kind of with a generic question. When you look at data IT professional, you know, practices that you and your teams work with, and I'm sure you work a lot with like a CIO type Group and department and such. But what does audited and compliant mean from your management perspective today when it comes to IT services and more

Speaker A: from uh, from an overall governance, uh, program. And at the end of the, at the end of the day, what we want is access to the data in a secure, compliant fashion. And so the way I structure programs, I think about it, uh, on the governance side, I really think about it as a swim lane for, as an analogy where the, the rail on the left is the GRC compliance rail, the rail on the far right is real world technical security. And if you control the two rails, then the business can go as fast as they want in that swim lane. They can race or they can tread water. Right. But we own the rails.

Speaker B: Oh, I love that analogy. That speaks uh, a lot to one of the things I say about AI programs. A lot of people we are going to talk about AI, but not just yet, but when I talk about AI programs with folks, I use this phrase, business benefit first compliance always. And that's kind of a similar thing where you go into it with those two guardrails and then that speed. I love that. From a GRC and then a pure technology, uh, side. And the technology thrives in the middle of that. That's, that's really good. Hey, he's almost an expert in these things. That might be why he's on our show. But when you look at that type of approach, Rick, do you ever see, um, groups maybe hesitant on going the extra mile to really fully unlock and enable because that really, that velocity is business benefit with compliance in mind with security.

Speaker A: Right.

Speaker B: Do you ever, you know, have you ever managed scenarios where you might have inhibitors of going the extra mile to do, do that to its full potential?

Speaker A: Generally the folks that might be inhibitors or uh, this is interesting from a security perspective, but there's kind of two views to the security space. Uh, there's leaders that are risk adverse and leaders that understand how to accept calculated risk. And so usually an inhibitor is somebody that is risk adverse, uh, potentially because they don't necessarily have the right tools, uh, or controls. Uh, where my view is we should be enabling the business, uh, as best we can in a secure envelope.

Speaker B: Do you ever see maybe the skills gap come in to be a factor here? You mentioned some of the tools and I'm kind of digging into that as one outlet. But is the skills gap for staff, is that a factor sometimes or is it um, one of those things that has to be kind of managed in front of or such?

Speaker A: I don't really Think of it as a skills gap. I think of it as a hiring plan. Right. You should be hiring for the skills that you need today and tomorrow. Uh, so I don't really get into the skills gap piece.

Speaker B: That's great because, you know, I think certain organizations struggle with, um, the hiring, um, let's just say the fulfilling, getting the right people in the roles. I was talking to one of the development teams here at Veeam, and specifically, uh, running site reliability engineering type roles. And the big challenge was not so much we can get people, but getting the right people. So, you know, being selective, I think is super important on that to get the right people for the role. So I think a hiring plan is the right way to get at that.

Speaker A: Yeah. And if I can add to that just a little bit, uh, if you have a really solid team and technology is moving, like what's happened with AI, enterprise, data, cloud, uh, if you have the right people, uh, and you have a solid company, then the company should be investing in the training programs and development programs for those folks, uh, at Everpure. That has just not been an issue for us. We continuously train.

Speaker B: Yeah. Uh, I'll share a joke. One time I was at the airport and I actually love this mechanism and love or hate the airport. You can appreciate the takeaway here, but I was going through, you know, security screening and it's going frustratingly slow. And I'm, I'm the most patient person that you will ever meet. But there are some other fellow people in the, uh, you know, enhanced security line that were not as patient as I. And then we got up close and we determined that they're training someone on the equipment. And honestly the other passenger was kind of dismissing that. And then the one, one of the persons, she said, we train every day and actually love that mindset. I love that mindset. And I think you could apply that to building teams, investing in teams every day. And, uh, you've actually motivated me already to train up on something, so I like that.

Speaker A: Well, and you can train without having a negative impact to your stakeholders in your example. Right. The customers coming through are the stakeholders. Uh, the training is important, but you ought not be impacting negatively your stakeholders.

Speaker B: That's true. I mean, I think running an IT operation or, you know, Checkpoint C might be a little bit different, but I think that, you know, that's a, that would be, um, a business benefit to kind of put at the onset of not disrupting the overall service and output. Super. Now if I was to ask about disrupting the status quo. Uh, I think it's probably something you've had to deal with at some point in your career. But sometimes when you look at systems that have just been there, run well, forever, not had to fiddle with it for years, um, have you ever had to disrupt this, you know, question the status quo or even ask stakeholders what would happen if something went wrong with this.

Speaker A: So that's interesting because this really starts to get into, you know, critical, critical activities. When you have something that's been running forever and it's the status quo, uh, really the standard ought to be is your data persistent? Is your identity persistent? Are your critical services redundant and resilient? And the standard I kind of get to is, can you take the data that you need for this critical function, move it or stand it up somewhere else and continue to run the function? And if it's been status quo, uh, often companies haven't tested the services that are required to run that. And that's really kind of the next layer that people need to get to.

Speaker B: I think that will naturally just discover blind spots in the processes.

Speaker A: Correct, but the challenge is you don't want to be discovering those blind spots while you're trying to recover from some sort of a hardware outage or a system outage that ought to have been tested, reviewed and mapped out ahead of time.

Speaker B: And you know, in your role as a ciso, does that get into, uh, dealing with like the CIO side of your operation or. You know, I'm starting to see, personally, I'm starting to see a lot of organizations combine what may have been some of the infrastructure CIO type functions into CISO Org functions. Are you seeing any type of, or at least tighter inner workings? Uh, how does that look in your practice?

Speaker A: Uh, the workings are really tight. Uh, in a good way, uh, good CISO programs. The CISO really should be cutting across the entire business. It should be moving horizontally through every vertical of the business because the fact that they're there means there's something critical that they're performing for the company, whatever that is, we need to identify and make sure it's backed up, it's resilient, all those types of things. So there's a lot more probably under the umbrella of a CISO today than I think most people realize.

Speaker B: And that is something to wake up to. When you look at those types of under the umbrella. I love that phrase when you look at those types of responsibilities is, you know, it probably, okay, I don't want to lead the witness, but I've seen a lot of organizations where it is us versus them. You know, have you had, had that maybe or have you solved for that or had to fix that in scenarios.

Speaker A: I've been doing this a long time. I've certainly seen those environments. Uh, it's us versus them. And uh, a lot of times an olive branch goes an awfully long way uh, to kind of reset. Uh, usually those environments don't last. At some point it's going to get corrected. And it really takes uh, both organizations to align on what is the mission for the business. It's not you versus us. Right. What is the mission of the business? And let's go get aligned on that.

Speaker B: I have a quick story of where us vs them is no good. I was uh, debriefed of a ransomware scenario of a healthcare provider. And this particular client of Veeam uses a storage integration very similar to what we have with Everpure. And our support team was going on and on. Do you have another copy? No. Do you have anything off site? No. Which by the way are number one and number two rules broken. Did you use different credentials? No. Okay, that's number three. Don't use that. So everything that was the worst practice. It was, this was uh, a part of this health care provider that was acquired and it was kind of hastily integrated. You may or may not have seen that story play out. Anyways, long of the short, our support team was running out of questions and just getting no and no and no and kind of the last guess answer was are you using the storage integration? And the client said what's that? Turns out who was the classic Veeam administrator, was not talking to the um, storage team, was not talking to the server team, was not talking to the network team. All those us's and thems, right? And what happened was luckily, and you never want to bank on luck, but luckily the client had uh, a reseller partner when they implemented the storage automatically. Take I think a four hour storage snapshot for a week and they were able to stand up a new Veeam server, plug those in, recover everything. I mean it's luck. That's just dangerous.

Speaker A: It's really two points uh, that I like to comment on, right. The difference between uh, teams talking to each other and understanding what their different capabilities are instead of this us versus them stuff. When uh, they do that and, and they have a better understanding of each side of the fence so to speak, it's really uh, a force multiplier on what all the different capabilities are. The time to discover that like what you were Describing the time to discover that is not in the middle of an incident. So had they had all these conversations and worked collaboratively prior to that. Right. They probably would have had a better plan faster to recover. Today, the way, uh, backup and data cloud is working, uh, it's really easy to be able to go grab your data, fall back to it from five minutes ago, two weeks ago, whatever you need to do, and get up and running. It's a lot easier. But collaboration helps.

Speaker B: Yeah. You know, I don't know that much about you, Rick. We just met, but I feel like you're talking to me in technology terms. Like some of my favorite TV football coaches, you know, they see things that most don't. Right. And, and that's really one of those signs of a leader when you can, like, take a circumstance in a scenario. And I've told that story about luck probably five times, but I've never thought about it the way you just explained it. So that's fantastic. It's like, uh, it's our own personal, you know, sports show here where we're like, breaking down the plays in ways you never thought. So that's great perspective. Um, I want to change a little bit to this thing that's happening nowadays, AI. And, you know, everyone's got their story and their explanation and their kind of, um, priorities around AI. But are you seeing that as a, as a priority? Are you managing or putting the guardrails, as you said, around AI initiatives with your stakeholders? You know, there's a data explosion, both, um, how it's moved and how it's created. There's, There's a lot to it. But, uh, before I get into AI a little bit more, what's kind of your assessment of the current state?

Speaker A: Uh, the velocity of AI is amazing. And I think from a security perspective, we, uh, want to embrace it and enable it. Right. You have enterprise data cloud. You can get to any data from anywhere. You can move it, shift it, recover it. Uh, you have to embrace that with the different AI tools now. And I start to fall back into the two rails I explained earlier of GRC and Identity, uh, or the technical controls. And now with AI, what really seems to be magnified is how well you're controlling identity. What identity is being used by the AI tools and platforms, and what data is the identity services being pointed at or the AI services being pointed at? Is it, uh, system of truth data? Is it a copy of the data? It's really important to have a clear understanding of what the AI is doing and what the AI should not be doing well.

Speaker B: I love that because I think, and this is something that's elevated to be central to the V message nowadays around enabling safe AI at scale and more. So I think that practical perspective is really, really on point. You know, I started with the question about untrustworthy data. If you take these scenarios with AI initiatives and you know, data moving around at high velocity, what's your take on the, on the quality of the data, the relevance of the data? The um, just even the. Do we even need it? Is it maybe obsolete? You know, there's a lot of data out there. Um, what about the quality of the data for AI projects today?

Speaker A: It's a great question when it comes to the quality of the data. Let's just take an example of, ah, a really huge data set. You're running some AI, uh, agentic, uh, service. Uh, it's really important that the fidelity of that database is what you're intending it to be. There could be another version of that database that's been augmented with several other pivots. And if you didn't know that and you're connecting to the wrong database, you're not going to get the intended result 100%.

Speaker B: And I think one example that folks can really relate to is take your copilots, your GPTs, your Geminis, your clauds, whatever kind of, I don't say consumer, but single user interaction AI tool. I found that if you spend a little bit more time with a better prompt, you get a much better answer. Right?

Speaker A: That is very true.

Speaker B: And it's not like just doing a web search where a couple of words will get you to where you need to be. But if it's more of a. In fact, I personally like to use the speech narration. Uh, I'm pretty good on typing, but I can talk faster than I can type and I find it easier to explain that way. So just a little pro tip, if you're looking to build better, but when we look at the data, um, you know, I don't know if you get into this too much, but I feel like every IT professional IT organization out there has an opportunity to kind of get their, I don't want to say their head and their mind, but get their IT practice aligned to looking at redundant, obsolete or trivial data. What we call ROT data. Um, I personally think that's kind of risky sometimes. If it, first of all, if it exists and then second of all if it's fed into AI models, and then third of all, it might make the whole estate that much bigger and harder to manage and protect and consume resources and stuff. Do you have any perspectives on this notion of ROT data?

Speaker A: I do. I think that, uh, I think when you have platforms where you can get to any data from anywhere and you can move data around, you know, everpeer is, you know, enterprise, uh, data cloud, uh, and you start complementing that with AI tooling, you can start to identify, uh, the databases that are sitting out there, maybe really aren't useful anymore. Maybe you can push them out, maybe you can get rid of them. You, uh, can reduce your footprint. And the other thing with data that's sitting out there as you're describing, uh, that also generates risk. And it's the type of risk where you've got a bunch of different databases sitting out there. Maybe nobody's touched them in a while. However, if that database was suddenly published in the media, would that be a problem for you? And the answer is probably yes. So now you have a database that hasn't been touched but yet would be risky if it were exposed. So AI tooling and being able to move data from anywhere to anywhere is an opportunity to really reduce that risk.

Speaker B: I love the risk reduction just mindset there and I guess, uh, leading the witness a little bit. But I'd say it's worth the effort to just disrupt the status quo to get that right, to prevent and reduce those types of risks.

Speaker A: Yeah, the. From my perspective anyway, uh, you know, having the right controls in place, we want to do two things. Stop the bleeding. Let's not create disparate databases anymore. So that's one, and then two, go ahead and start cleaning up the technical debt as a structure. Uh, if I were advising a company, that would be the path.

Speaker B: Hey Rick, thanks so much for joining us here today on the podcast.

Speaker A: Really appreciate it having me on. Had a great time.

Speaker B: All right, that wraps this episode of the Wake Up Podcast, powered by Veeam. Find this episode and more at a podcast platform near you and more information to wake up to@veeam.com.