Effective Cybersecurity Management with Vertiv’s Mike Orosz | Qualys QSC 2023

This is Textron tv. Hello and welcome back to the Qualys Security Conference, America's event. We're here with Mike Orzo, who's vice President of Product and Information Security for Vertiv.

They are a company that specializes in helping companies build very large data centers for some of the best known hyperscalers out there. And we're gonna be talking about, well, how to measure security and how to talk to the board. Mike, welcome to the show.

Yeah. Hey, thank you for having me. I appreciate it.

We are obsessed with metrics as we all do. We measure every little thing, but sometimes it's hard to measure security in the right way. We have people talking about KS and KPIs and there's no shortage of things to put in a report.

What is your advice to folks in the security side about what to measure in a way that's meaningful to somebody else? So from a perspective of what people should be measuring, I think a few basic items. You know, that I would call KPIs, which are mean time to detect and mean time to remediate or patch, especially when it comes to vulnerability management.

And what makes a security practitioner indispensable to their leadership is their ability to translate all those operational things they see into, uh, a piece of communication that can be used to elicit a decision. I feel like a lot of times security people are held accountable for a metric that they don't have control over because somebody else is executing effects or remediation. So how do you kinda really take responsibility for something that you don't have control over?

Well, security management should be setting their own KPIs and do it proactively. Don't, don't wait for somebody to assign it to you. And when it comes to using tools like Qualys, VMDR, vulnerability management, you have the ability to look at once you detect it and how you communicate it, the time at which it takes to actually remediate it.

And if those security teams aren't going on the offensive and communicating to all the teams that need to do the work, well then maybe, maybe there's some truth that says that they should be held accountable for not properly communicating the risk. Right. Is it possible for the security people to take more control of that process in certain instances?

'cause I feel like, you know, the other guys are just as busy sometimes. Sure. And they don't have the time to go fix something.

Absolutely. When it comes down to governance, which, which means that leadership is paying attention to what's going on in, in any organization, uh, there should be a top down approach. So whoever's in charge of the security function should work with people like the CIO.

If they don't work for the CIO, they should become best friends with the CIO who manages those IT teams and ensures that they're, they're keeping the systems up to date. A key aspect to the operation of any system, whether it be an application or a physical infrastructure, is keeping it healthy. And security is a core element to health.

Mm-Hmm. You talked about communication. Um, a lot of CISOs in particular have either now report to ACEO or they talk to the board more frequently, but it doesn't feel like they're all having the same conversation.

So I don't think the board's gonna change. So how does the CSO talk to a board in a way that the board can comprehend? That's a really great question.

I'll say that you have to recognize when you speak to a board member or a board of directors or an audit committee within a board, you have to realize these are mostly finance people. And finance people are very driven by numbers. They're working off real numbers, real numbers to quantify revenue, whether or not we're meeting expectations of Wall Street or whether or not you're meeting the expectations of investors if you're not publicly traded.

And with that in mind, I prefer KPIs because they quickly understand whether or not the operation is effectively operating based on what they see in the numbers alone. And they can very quickly discern a good number from a bad number. And it's time for security professionals to take advantage of that knowledge of numbers.

And with that, you can communicate whether or not we're meeting, uh, expectations we set for ourselves, like mean time to detect and to patch. And those are SLAs service level agreements that you make within an organization where everyone is aligned. If you're not meeting expectations, that has to be communicated to the board.

So if there's another business priority reprioritization can happen. Do different security events require slightly different ways of measuring? I might have a zero day vulnerability that's crucial, like log four J and I gotta respond to that immediately versus something that's not quite as severe.

So how do I kind of, uh, apply some balance to the equation? Well, I think it all boils down to how you organize your security group and how you define how you react to critical events. Like let's say a zero day For us, I treat zero days as incidents.

So if you have a system that's compromised or has malware, I treat actually a zero day a little bit higher because there's nothing you can do technically to patch it. So what you have to then do is assess the criticality of that device like you would during an incident scenario. And you have to spin up a group of people to respond to it and take action.

And generally when it comes to responding to a zero day, you have to make technical changes in the deployment of that, that thing that's vulnerable to prevent it from being exploited by a bad guy. So I thoroughly believe that zero day should be treated like incidents. And you also have to define that.

Mm-Hmm. What is the acceptable level of risk? 'cause the good guy's gotta be right a hundred percent of the time and the probability assessment that is zero.

So how do I kind of, you know, set an expectation that's reasonable given the cyber criminal gangs, the nation states and you know, the kid next door, all these people are trying to bang on something. You're right, you're right. So I mean it comes down to having a effective working group that's comprised of both business people as well as other people within IT and executive leadership.

And that's something which we have in place today had for years. And it's something I learned a long time ago. You have to include the business in that decision because again, it boils down to priorities and what's most important to the business.

Generally speaking, if you're managing and maintaining systems that are critical to revenue recognition or processing customer orders, they're gonna have a higher sense of priority. And you should collect that priority through the process called business impact analysis. And it's a standard disaster recovery method of assessing and understanding your infrastructure and deciding what's most critical.

The business has to tell you that it is only a custodian of business information and systems. We're there to maintain it, keep the lights on and keep it patched. It's a securities team obligation to scan it, find those risks, communicate, and then get that decision made at multiple levels.

The business agreement that if you have to take a system down to fix it, you need to get that from the business so they understand that you're gonna take their systems down and then it, you need the consensus to ensure that they're gonna divert resources to fix it when it needs to be fixed. And if things aren't getting fixed and it's presenting an impact to business operations, that has to be bubbled up to executive leadership for a decision. Business leaders will sometimes ding security people for being in the office of No.

And they're trained to think about things in terms of risk in general. They're go to business school. Sure.

It's four years of how to measure and balance risk at the end of the day. Cybersecurity though seems to be a different type of risk that they don't understand, or it's not, it's not something they've been trained on. So how do we kinda like bring them up to speed on this whole conversation beyond just looking at the metrics, but looking at it and saying, how do we kinda understand cybersecurity the same way we understand other risks?

Well, there's two different, you know, sides of this coin here. There's the non-publicly traded company side, and then there's the publicly traded company side. The SEC has come out with a whole new set of regulation, which requires boards to be accountable for understanding the materiality of risk, which means that you have to quantify cyber risks and you have to properly react and treat, treat those things.

Now, non-publicly treated organizations, there are many in the hundreds of millions of revenue all over the world. So you have to then be able to have finesse in explaining what the potential impact would be if someone takes advantage of this versus the cost of the remediation of it. If it's a bus business decision around dollars and cents, what make, what makes sense, you know, to fix versus the cost or the cost of the loss, then you have to make a decision.

Is it cheaper for me to fix it now or is it cheaper to me to go through the breach and all the work that comes with it? So I think it boils down to explaining the device, the criticality of it, and the potential loss of it to make people understand their decision to maybe not fix something, could return these financial results, leave people without the ability to recognize revenue, leave people without the ability to manufacture things or service customers. And it's ultimately the business and the senior leadership decision at the CEO level to make a decision whether or not, you know, the juice is worth the squeeze.

So they say, Do we need to go back into all these MBA programs and train them on cybersecurity risk? I think it should be a critical element in an MBA program. But you know, I think most CFOs out there who are then people who become board members, they have a pretty darn acute sense of risk because they're on the hook to make numbers work and meet expectations, whether it's Wall Street or investors.

And if they don't, you know, they're gonna get walking papers just like everybody else, including CISOs. We have seen a lot of regulations come down the pike recently. Are the folks who are writing the regulations understand what's really being asked on the execution side of that.

'cause it seems like there's more pressure being ratcheted up on the CISO side of the house. That's a great point. I think they came to a compromise.

I think the SEC wanted to regulate a a lot more than they ended up doing. You know, there's still a lot of groups out there who want, you know, want one thing or another. Maybe they're lobbyists and and whatnot.

But I think ultimately cybersecurity gives a boardroom discussion and it, it would make sense for boards to seek out relevant cybersecurity expertise to advise them at that level. Because I think whichever way the communication gets to the top, there's always some sort of decision making around what's relevant to the board meeting. Because these people only meet every so often.

They're not there day in, day out and they don't know the true story all the way down to a single vulnerability which might start a ripple effect that leads to some major incident and some se serious revenue impact and things like that. So I think that there could be some more focused regulation that comes out, mandating expertise, be present within a board. I think that would be great and it would help push that, you know, more effective risk treatment.

However, where I work, our chairman of the board is very acutely aware of risk and he's taking all the appropriate actions and I'm happy to be part of the, the company where I work. Last question. Are we setting unreasonable expectations on CISOs?

Because there's a tendency whenever there's an issue to fire the ciso and yet if there's a big fire, we don't fire the head of the fire department. So is there just another way to think about the role here? Because I think we're kind of asking CISOs to do things that is not feasible.

Yeah, I think it boils down to what an organization feels, you know, is the best way to treat cybersecurity risk. Lots of organizations have enterprise risk management functions, and with that, uh, there's very well established processes. So I think what's most advantageous to avoid for any CISO to avoid being in a position of being singularly held accountable is to have a very effective relationship with that enterprise risk management function and to simply be another element or aspect of risk that the company has to treat or deal with.

And that's really important because you're not just placing the decision on yourself to accept or to treat, or, you know, to mitigate the risk or whatever, whatever you wanna say. You're making it the decision of the village of everyone involved. And you're following a defined enterprise level process that has decision points from the CISO to the CIO, to the CEO, to the audit committee and the board of directors.

So there should be very well defined sets of, uh, levels of who can treat what, what risk where, and the CISO should be acutely able to very specifically identify and escalate risk and have defined processes to do just that. All right, folks. You heard it here.

I think we need the CISO edition of how to wing friends and influence people, because that's pretty much what the job's becoming. Mike, thanks for coming by. Yeah, thank you very much.

Thanks for having me.