Saying No to Insecure IT Projects with AWS’s Clarke Rodgers

This is Textron tv. Hey guys, thanks for the throne. We're here with Clark Rogers, who's director of enterprise strategy for AWS.

And we're talking about a new, well, maybe not so new powerful metric that, uh, CISO should be implementing more often. The metric is called the Word No. Clark, welcome to the show.

Hi, Mike. Thanks for having me. You are advocating that CISO should use this term more freely and more forcefully.

And I guess the question I have is just to get started with, for a long time now, we were chatting security people for being in the office of No. And, uh, the focus was supposed to be now on enabling the business to absorb a certain level of risk and do things hopefully more safely. What is the right stance for a security leader these days?

Well, Mike, you're absolutely right. And, and when I speak to our customer, CISOs, it's exactly that. We want to get out of the business of being part of the department of no and being part of the department of Yes, but right where we're, uh, enabling with the business and making sure that they understand that, uh, there are risks, uh, to what's going on.

And please allow the security program or the security department to help mitigate those risks so the business can move forward. So, um, there are, there are clearly good nos and there are bad nos, right? So, hey, uh, security department, we'd love you to open up all the firewalls and not require passwords.

'cause it would make it easier, easier to develop software. Clearly that's a good no, that security continues to need to do and say, no, that's just too risky. We're not gonna let that happen.

But then when we think about enabling the business as a whole, and we have line of business leaders coming to us saying, Hey, I really wanna do X or Y you really need to think about it as a security leader, why are you saying no, right? Are you saying no because it's too risky and it's bad, you know, it aligns with the risk appetite for the business and not something you want to move forward with? Or are you saying no, because maybe you don't have the security culture in place, maybe you don't have the security capabilities in place to actually reduce that risk to the point where it's acceptable for the business to move forward.

So that's the no, I'm talking about, and when I speak with customer CISOs, they're well on that path to being that CISO business leader. That that person who has the seat at the table with the executives is meeting with the board regularly, understands risks, can articulate it in terms of business risk. They get that.

But there's a lot of CISOs who are still making that, uh, transition, right? They're making that path along from, Hey, 10 years ago I was down in the basement and they only ever called me when there was something bad happening, right? And I had to go fix it to now, you know that they're that business leader.

So as you're making that transition, CISOs ask me, well, how, how do I think about that? How do I make the case from a business perspective that I need more funding, I need more people, I need more capability. We as an organization need these capabilities.

And the thing that I keep talking to 'em about is how often are you saying no and are you tracking it moving forward and using that to articulate your business case, uh, to move forward Beyond just saying no. However, you seem to be also making a position that I should count the number of times that I say no and tracking it as a metric, because what does that tell me? Well, it it can, it can tell you quite a bit.

Um, it can tell you how the security culture is in your organization. So if, if, uh, an example I like to use, excuse me, is that, you know, a line of business leader who, uh, is running product and, and, and he or she has a mandate from the CEO to get that product out the door features out the door a lot quicker than they're doing it today. Today it may be the case that security is not even looked at until it's time to go to a production, right?

So it's a couple nights out, let's run a security scan. Oh my goodness, there's a lot of criticals and, and, and highs there. Can we let it go?

Or not? Security might be saying, no, you can't 'cause it's entirely too risky. But then what you need to do is look about, look, look at the whole paradigm that you have there.

Why aren't we investing in security at the beginning of the development cycle and the ideation of it? That first, uh, bit of code when that developer is, is, uh, writing that code. Why is he or she not using something like Code Whisperer to see, Hey, am I developing this in a secure manner when I'm pushing it through the CICD pipeline?

Why isn't that first track pushing back saying, Hey, you are meeting, or you're, or you're not meeting the security bar. We all know that if we catch security early off, early enough in the development process, it saves us expensive rework. And it actually over time allows us to, uh, accelerate releases into production To the degree that, you know, the CEO may may be demanding, uh, for that software to be released.

Do you think that there's more stringent regulations seem to be coming down the pike, the latest of which is the SEC rules? Is that making it easier for cybersecurity people to say no because well, they are being held more accountable, Easier to say? No, I, I, I wouldn't say so.

I think there's more support from the board of directors and the c-suite in saying no because of the risk appetites that's changing because of the SEC rules. So it's, it's, again, it's supportive of the security program. You of course are one of the leaders in the whole cloud movement.

What do you wish people appreciated more about cloud security specifically? 'cause it seems to me it's not a question of whether a platform is more secure than another, but the processes are, are just fundamentally different, and I guess we have to figure out how to master them. Um, I I think there's a couple ways to answer that question.

The, the first is, you're absolutely right. The, the technology that's in the cloud today is different than what people have been used to on-prem for, for securing their environment. However, um, when you think about security outcomes, right?

And the bigger picture of what I'm trying to do as a security professional, that hasn't really changed as much. Uh, what you really need to be thinking about is what is the security outcome I'm trying to achieve? How does that align with the, the business imperative, the business, uh, risk appetites that there, what, what is the business trying to do?

And then how do I marry the two? Right? But the, the, the core components around identity and logging and monitoring and infrastructure security and data protection, incident response, those, those are the same whether you're on-prem or in the cloud.

And the idea is how do I get to that, uh, security outcome when I'm in the cloud versus, versus the on-prem paradigm. We talk a lot about shift left, and a lot of the developers kinda on the one hand say, yeah, I understand the need. On the other hand, they resent the increase in cognitive load, and frankly, it's not clear to me that they have enough security expertise to adequately provision things without leaving vulnerabilities that can be exploited.

How do we strike a balance between some need for adult supervision and the fact that, you know, we don't wanna put too many processes in the way of actually spinning up cloud workloads. So, uh, one th one thing, uh, one way I've seen this addressed is, uh, through the development of like a security guardians or a security ambassador program where, um, the security team will own sort of the education of different members across the development pipeline and make sure that they understand what's important from a security perspective. What are best practices?

Maybe it's pointing them to the OAS top 10. Maybe it's providing a tool like code whispers. Maybe it's owning the CICD pipeline, so security owns it, or maybe the builder tools team owns it.

And then that in combination with building out a strong security culture where, uh, everybody has a responsibility for the security within the organization, you start putting that all together. And over time, what you get is a developer who understands security, understands that he or she is actually responsible for the security of the product that they build. And then with that ownership they have, they can focus on the feature sets that they're trying to develop and the security at the same time.

So as, as we talked earlier, when I'm pushing code from, uh, development into test and that that scan is running, and ideally I've not had to build the CICD pipeline 'cause security owns it, or the builder tools teams owns it, I get that feedback immediately with, you know, the three reds, two greens, the yellow, whatever it is. And I don't look at it as, uh, you know, security's getting in my way or security's causing me a trouble. It's this is an opportunity for me to be a better developer, right?

A developer that can, uh, develop securely is what we're looking for throughout the enterprises. Uh, then certainly that's what our customers are looking for, Right? I think to your point, the resentment built from the fact that we're not engaging the developer at the point when they're writing the code or merging into a build process, the security feedback is coming back too late and they've moved on and they've lost context, so they not sure what to do next.

So how do we kinda That, that certainly can happen, that that certainly can happen. And that's, uh, that's a combination of, you know, the leadership of the, the security org, the CTO's org, uh, top down from the CEO that security is important, right? It's that, that it's just as important that we get, uh, secure features out the door as we get new features out the door.

Uh, again, it's, uh, changing security culture is not, you can't just buy it, right? You have to make the investments into that and you have to, um, meet the developers where they are. They, you have to give them the tools, you have to give them the training, and eventually you want to give them that ownership at, at AWS you know, we're famous for our two pizza teams where, uh, developers own everything about their product, right?

From the security to the feature functionality to the backlog, to how customers are, uh, engaging with it. And it's, it's that kind of, uh, transformation that more and more customers are embracing 'cause they realize the benefits of building security, uh, early into the product pipeline. There's a lot of effort required.

Do you think that at some point, hopefully soon, AI may seem as from ourselves, can we start automating more of these functions? Uh, there's there's a lot of capabilities, uh, coming around with, with AI as you well know, and it's, you know, sort of support the human, uh, as they're developing, right? So I mentioned Code Whisper earlier, which allows, uh, developers to, uh, have their code checked and get best practices from a security perspective at reinvent.

In 2023, we announced, uh, AI enhancements for Amazon inspector and Amazon detective, which again, for those, uh, uh, soc uh, security professionals, they're going to allow AI to sort of do some of the initial triage for them so then they can focus on really what what's important from a human perspective. Um, I think tools like that, we're gonna see, um, all, you know, all the boats, uh, get raised after a while from a security perspective, both the development side and then the protection side. And then of course, you know, customers are very interested in building out their own AI capabilities based on their own data.

And of course we have tools like, uh, Amazon Bedrock for that. So what's that one thing you wish most organizations would pay more attention to when it comes to cloud security? You've been doing this for a while.

What's that thing that still makes you shake your head and go, folks, we're better than this? Uh, I think fundamentally it's making sure that you're doing the security that you're implementing. There's a, there's a business impact and a business reason for doing it there.

It, it's very easy to look through a laundry list of all the different things you can do from a security perspective, and you can implement them all over the place. That'll give you some degree of security. However, when you really understand how your business makes money, what the risk appetite is for your business, and then you can demonstrate that your security investments actually have significant business outcomes, that's where it makes sense.

All right, folks. Well, you heard it here. As we all know, the word no is one of the most powerful in any language.

The trick is figuring out how to use it wisely. Hey, Clark, thanks for being on the show. Thank you.

Back to you guys in the studio.