Transcript
I'm your host, Rick Vanover, the Rickitron. Today, Rick Orloff is joining us to share fresh perspectives to wake up to. Thanks for joining us, Rick. Thank you for having me. So, 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. Sure. Rick Orloff, Vice President CISO at Everpure, which is formerly Pure Storage. And I'm responsible for all of the cybersecurity, the zeros and ones, and bits and bytes. It's funny, I'm glad you said Everpure, because I know I would have messed it up, formerly Pure Storage. Household name in the Veeam neighborhoods, if you know what I mean. So, long-time 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 to you to challenge me on it, but kind of what's your thought about data and the trust level today? 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 accessible from anywhere, anytime, it's really about what are you trying to do with it, and which set should you be hooking into? That's a really important point, accessible anywhere, anytime. I mean, I've heard the proverbial phrase that the walls of the data center aren't really there anymore, and from a connectivity standpoint, yes, they're there, but in terms of how people access and the accessibility, I mean, at least what we do at Veeam and 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 let me start kind of with a generic question. When you look at data, IT professional practices that you and your teams work with, and I'm sure you work a lot with 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? From an overall governance program and data, 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 on the governance side, I really think about it as a swim lane, as an analogy, where 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. Oh, I love that analogy. That speaks 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 it's kind of a similar thing where you go into it with those two guardrails and then that speed. From a GRC and then a pure security side and the technology thrives in the middle of that. 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, do you ever see groups maybe hesitant on going the extra mile to really fully unlock and enable? Because really, that velocity is business benefit with compliance in mind, with security. Have you ever managed scenarios where you might have inhibitors of going the extra mile to do that to its full potential? Generally, the folks that might be inhibitors, and this is interesting from a security perspective, but there's kind of two views for the security space. There's leaders that are risk adverse and leaders that understand how to accept calculated risk. Usually, an inhibitor is somebody that is risk adverse, potentially because they don't necessarily have the right tools or controls, where my view is we should be enabling the business as best we can in a secure envelope. 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 one of those things that has to be kind of managed in front of or such? 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, so I don't really get into the skills gap piece. That's great, because I think certain organizations struggle with the hiring, 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 running site reliability engineering type roles, and the big challenge was not so much we can get people, but getting the right people. Being selective, I think, is super important on that to get the right people for the role. I think a hiring plan is the right way to get at that. Yeah, and if I can add to that just a little bit, if you have a really solid team and technology is moving like what's happened with AI, enterprise data cloud, if you have the right people and you have a solid company, then the company should be investing in the training programs and development programs for those folks. At Everpure, that has just not been an issue for us. We continuously train. Yeah, 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 security screening, and it's going frustratingly slow, and I'm the most patient person that you will ever meet, but there are some other fellow people in the enhanced security line that were not as patient as I, and then we got up close, and we determined that they were training someone on the equipment, and honestly, the other passenger was kind of dismissing that, and then one of the persons, she said, we train every day, and I actually love that mindset. I love that mindset, and I think you could apply that to building teams, investing in teams every day, and you've actually motivated me already to train up on something, so I like that. Well, and you can train without having a negative impact to your stakeholders. In your example, the customers coming through are the stakeholders. The training is important, but you ought not be impacting negatively your stakeholders. That's true. I mean, I think running an IT operation or Checkpoint C might be a little bit different, but I think that that would be 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, 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, 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? So that's interesting, because this really starts to get into, you know, critical activities. When you have something that's been running forever, and it's the status quo, 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, 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. I think that will naturally just discover blind spots in the processes. 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. And you know, in your role as a CISO, does that get into 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 interworkings? How's that look in your practice? The workings are really tight, in a good way. 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 it 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. 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 an us versus them. Have you had that maybe, or have you solved for that, or had to fix that in those scenarios? I've been doing this a long time. I've certainly seen those environments. It's us versus them. A lot of times, an olive branch goes an awfully long way to kind of reset. Usually those environments don't last. At some point, it's going to get corrected. And it really takes 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. I have a quick story of where us versus them is no good. I was 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 offsite? 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, this was a part of this healthcare provider that was acquired, and it was kind of hastily integrated. You may or may not have seen that story play out. Anyways, long or 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 storage team, was not talking to the server team, was not talking to the network team, all those uses and thems, right? And what happened was, luckily, and you never want to bank on luck, but luckily, the client had a reseller partner, when they implemented their 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. It's just dangerous. There's really two points that I'd like to comment on, right? The difference between teams talking to each other and understanding what their different capabilities are instead of this us versus them stuff, when they do that and they have a better understanding of each side of the fence, so to speak, it's really 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, yet today, the way backup and data cloud is working, 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. 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 that's really one of those signs of a leader when you can like take a circumstance and a scenario. I've been 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, 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. 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 priorities around AI, but are you seeing that 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 how it's moved and how it's created. There's a lot to it, but before I get into AI a little bit more, what's kind of your assessment of the current state? The velocity of AI is amazing, and I think from a security perspective, we 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. 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 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 a 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. Oh, I love that because I think, and this is something that's elevated to be central to the Veeam message nowadays around enabling safe AI at scale and more, so I think that practical perspective is really, really on point. I started with the question about untrustworthy data. If you take these scenarios with AI initiatives and data moving around at high velocity, what's your take on the quality of the data, the relevance of the data, do we even need it? Is it maybe obsolete? There's a lot of data out there. What about the quality of the data for AI projects today? It's a great question. When it comes to the quality of the data, let's just take an example of a really huge data set. You're running some AI agentic service. 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. A hundred percent. I think one example that folks can really relate to is take your copilots, your GPTs, your Geminis, your Clods, whatever, I don't want to 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. That is very true. It's not like just doing a web search where a couple of words would 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. 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 prompts. When we look at the data, 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. I personally think that's kind of risky sometimes, 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? I do. I think that when you have platforms where you can get to any data from anywhere, and you can move data around, ever pure as Enterprise Data Cloud, and you start complementing that with AI tooling, you can start to identify 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 can reduce your footprint. The other thing with data that's sitting out there, as you're describing, that also generates risk. 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? The answer is probably yes. Now you have a database that hasn't been touched, but yet would be risky if it were exposed. AI tooling, being able to move data from anywhere to anywhere, is an opportunity to really reduce that risk. I love the risk reduction mindset there. 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. From my perspective anyway, having the right controls in place, we want to do two things. Stop the bleeding. Let's not create disparate databases anymore. That's one. Then two, go ahead and start cleaning up the technical debt as a structure. If I were to advise in a company, that would be the path. Hey, Rick, thanks so much for joining us here today on the podcast. Really appreciate having me on. I had a great time. That wraps this episode of the Wake Up Podcast, powered by Veeam. Join this episode and more at a podcast platform near you, and more information to wake up to at veeam.com.
