AWS on why CISOs should track 'the metric of no'

Enterprise security teams have long fought against being labeled "the Department of No," and a new approach could help their cause.

Clarke Rodgers, director of enterprise strategy at AWS, is urging CISOs to measure what he refers to as "the metric of no" -- the number of times the security team must deny a line-of-business request within their organization. Rodgers believes that tracking the metric of no will benefit CISOs by helping them build a stronger security culture and more effectively communicate risk to the rest of the organization.

The metric of no is especially important with the rapid rise of generative AI, which many enterprises are adopting in a variety of ways. Rodgers said CISOs can't be obstacles to such projects and need to find ways to embrace generative AI tools and large language models while also maintaining a strong cybersecurity posture and culture within their organization. Tracking the noes versus yeses and providing context around those decisions will help them achieve that, he said.

In an interview with TechTarget Editorial, Rodgers discusses the concept behind the metric of no, how CISOs can use it as an effective tool and how generative AI has changed the landscape for enterprise security teams.

Editor's note: The following Q&A was edited for length and clarity.

Conventional wisdom in the industry is that security professionals, and CISOs in particular, shouldn't be playing the role of Dr. No in their organizations, telling everyone that they can't deploy this app or they can't use this cloud service. Talk about the metric of no and why it's important.

Clarke Rodgers

Clarke Rodgers: The place you're coming from is spot on. As we've seen the CISO role evolve over the years, it used to be the IT security person in the basement that you only called when something bad happened and they have to go fix it. And then at the other end of the spectrum is the person with the cybersecurity background who's a business leader, who has the seat at the table with the executive suite, reports to the board regularly and speaks in terms of business risk -- and rarely, in that context, talks about the bits and the bytes and the vulnerability management and those sorts of things. If those are the two extremes, the majority of the customers that I interact with are on their path toward the latter, and never want to be the former again.

The types of discussions I have with them are that they absolutely can no longer afford to be the Department of No. They need to be 'the Department of Yes, but' or 'Yes, and,' where you're saying, 'Absolutely, I can support your business objective. However, you need to understand the risks that are there. Allow me to put the mitigations in place if they're not already there, and work together toward a successful business and security outcome.'

The majority of the customers I speak with get it -- that's where they want to be. And if that's what your goal is, then you have to think about how you justify a lot of these decisions, because they are the good noes. Start thinking about policies and about how you can use those noes -- the good noes -- to your advantage.

For example, 'No, we can't do that because it's too risky. It doesn't align with our business risk appetite. I don't have these particular technical implementations or cultural implementations that I'm looking for to actually support your ask.' If I start tracking those noes, then I can have a very impactful business conversation with my leadership to say, 'I understand your risk appetite, and I understand that this product needs to get out the door very quickly because of a competitor or business opportunity, and it's worth $10 million. However, because we either don't have something in place that I control, or we don't have something in place that you control, this is entirely too risky to your appetite. And if we do this, that $10 million that you're looking to get might be a negative $10 million.' That's the idea behind it.

What's been the reaction from the customers you talk to?

Rodgers: When I ask CISOs, 'Do you count how many times you say no?' it sets them back a bit because, again, they're thinking about why they shouldn't be the Department of No. But then they start thinking, 'If I add up enough noes, I'm going to get some yeses.' I've told people in the past that if you give me an unlimited budget, I can buy every tool that's out there and I can implement every process. It's out there. But I can't go buy the culture. And it's investing in that culture, plus those other things, that allows you to say yes more often than ever. One example that I use that resonates very well with customers is the years-old problem dilemma -- do we get features out the door, or do we get them out the door securely?

You have that product manager who says, 'Hey CEO, I'm trying to get these features out the door very, very quickly, but the security team is blocking me every time I go to production. They run a scan, and they find out there are this many critical vulnerabilities, and so they're a blocker to me and they're a blocker to the business.'

Perspective comes into play there, but the CISO has an opportunity. The CISO says, 'I don't want to say no anymore. But we need to work together. What if I build out a pipeline that your team can use that has all the security checks in there? I also want to start building a security culture program, a security awareness program, and a security guardians or ambassadors program within the organization.' We're now pushing the responsibility and the ownership of the security down to that first line, to that developer or even before that at the project level.

Now, security is built into the pipeline, the developer had some ownership around it, and let's assume the culture has been built out. Now, the security problems are being caught earlier in the process. When it comes time for production, there are no surprises. All the scans have been done, things have been fixed. And now, all of a sudden, you're releasing features faster and more frequently. You're meeting the business objectives while remaining secure. You're taking that story and presenting it to leadership and telling them this is what we could be. That resonates in today's C-suites who understand business risk and increasingly understand cybersecurity risk.

A lot of this is cultural and a lot of this is programmatic. But we can step back and start looking at some of the technologies that are available that can help that developer be more successful. For example, leveraging generative AI tools like [Amazon] CodeWhisperer. The developer now has the ownership around the security, he or she is building that feature set, and now has a tool sitting by his or her side helping them code securely. This all together works as a package to lower the risk of the entire business and actually speeds them up and is more secure at the same time.

Let's say you're engaging with CISOs who have started tracking the metric. And there's concern because looking at the batting average, the noes-versus-yeses is really not flattering. How do you make sure they understand the data in context so that they can communicate that context to their organizations' leadership?

Rodgers: There are a couple of ways to answer that. The first part is for the organization as a whole. And I don't think this is fully baked across every industry, but I'd say the more highly regulated industries get this natively, and others are coming to grasp it -- the idea that the business owns the risk. And the business owns the risk appetite for whatever endeavor that they're going in. Security owns the job of understanding that risk and putting in the appropriate mitigations to meet that level of risk.

A lot of people think security departments own the security. No, they're the security experts. They're the ones who advise. But they don't own the risk. So that is a big hurdle for many organizations to realize. And then the other part of that is the idea -- and we've been quite vocal about this at AWS -- that security is everyone's responsibility. The security organization has a responsibility and an education component to make sure that the rest of the organization understands that. And it could be as specific as drilling down to the different job descriptions and saying, 'In this job, here are your security responsibilities.'

In my previous life as a CISO, when we were trying to achieve a SOC 2 Type 2 [certification] for the organization, one of the aspects was an HR component. How do you demonstrate that security is part of everyone's job? I put a security paragraph in every job description, and everybody had to reaccept their job descriptions. When you have those two parts working together, then that shifts the overall focus of both the security organization and the rest of the organization where they understand what their responsibilities are. And none of what we've talked about is a 'talk about it on Tuesday and implement it on Wednesday' kind of deal. This takes time. It can take months, and it can take years. It takes leadership from the top, and it takes ownership from the bottom.

But when all of those cogs are working together, then you get the outcome that we've been describing during this conversation. And consistently, I see that happening throughout the conversations I have with customers.

Has the recent evolution of the threat landscape contributed to the creation of the metric of no? Or is this something you and AWS came to independent of what threat actors are doing?

I would say the cloud of today is generative AI. Every business that I talk to either has a generative AI project or projects going on, or they're trying to figure out how they can leverage it.

Rodgers: The threat landscape is definitely a part of it. I would not say it's the main thing. If we look back 10 or 15 years ago, when cloud services were coming around, there were unfortunately a lot of CISOs who said, 'No, you're not doing cloud. Are you out of your mind? This is somebody else's data center -- I have no control over it, I have no visibility. There's no way we can do this.' So what happened? People made an end run around the CISOs with the shadow cloud, and then the CISOs were put in a position where they're wondering if the crown jewels are in the cloud. Now you've got to figure out how to secure it after the fact. CISOs have learned. And I would say the cloud of today is generative AI. Every business that I talk to either has a generative AI project or projects going on, or they're trying to figure out how they can leverage it.

The modern CISO cannot afford to be in a position where they say no to generative AI. They have to embrace the business, they have to lean in and say, 'What's the use case? How can I be supportive? How can we make this as least risky as possible?' Whatever the next big thing is after generative AI, the CISO and the security team need to be seen as people that are going to help the business succeed and help the rest of the company get to this business objective. They're not blockers. The business needs to understand that when they say no, there's a reason behind it. It's not just because it's a power trip or anything like that. It's because they're looking at the larger risk profile, and they're trying to mitigate that risk.

That's why you want to be tracking how many times you say no -- it can help you get there because you actually have the data to support it. You have to track it in order to see how you can eventually turn those noes into yeses.

Rob Wright is a longtime reporter and senior news director for TechTarget Editorial's security team. He drives breaking infosec news and trends coverage. Have a tip? Email him.